summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-07-21propellor spinJoey Hess
2019-07-21commentJoey Hess
2019-07-19commentJoey Hess
2019-07-19propellor spinJoey Hess
2019-07-19Added a comment: probably low level is neededdavid
2019-07-19(no commit message)david
2019-07-18Added a comment: A first attemptdavid
2019-07-18(no commit message)david
2019-07-17add news item for propellor 5.9.1Joey Hess
2019-07-17releasing package propellor version 5.9.1Joey Hess
2019-07-17Merge branch 'master' of ssh://propellor.branchable.comJoey Hess
2019-07-17clean up after mergeJoey Hess
2019-07-17Added a commentspwhitton
2019-07-16propellor spinJoey Hess
2019-07-16standard sources.list for pellJoey Hess
2019-07-16propellor spinJoey Hess
2019-07-16pell is actually still using i386Joey Hess
2019-07-16propellor spinJoey Hess
2019-07-16propellor spinJoey Hess
2019-07-16propellor spinJoey Hess
2019-07-16setting up joeyconfig after mergeJoey Hess
2019-07-16Systemd.machined: Fix a bug that caused the systemd-container package to not ↵Joey Hess
be installed when used with Debian buster. jessie (oldoldstable) is the only still supported release to have a systemd from before the systemd-container package was split out.
2019-07-16update from Stable "stretch" to Stable "buster" in some examplesJoey Hess
2019-07-16Apt.update: Pass --allow-releaseinfo-change when updating Unstable or TestingJoey Hess
So that code name changes that happen in those suites during a stable release don't prevent updating the rolling suites.
2019-07-16use security.debian.org/debian-securityJoey Hess
There's supposed to be a /debian-security path in the url, according to various sources, including https://www.debian.org/security/ I tried it both ways for both stable and testing and oldstable, and it works with and without it for both. Presumably some url rewriting is fixing it up on the back end.
2019-07-16remove /updates from security urlJoey Hess
According to Ansgar Burchardt's mail, it should look like: deb http://security.debian.org/debian-security bullseye-security main Kept as it was for oldstable etc.
2019-07-12Merge branch 'master' of ssh://propellor.branchable.comJoey Hess
2019-07-12use "-security" suffix for bullseye and upJoey Hess
The suite for stable releases from bullseye on will be suffixed with "-security". Only 3 past stable releases continue to use the old unsuffixed name.
2019-07-12Added a commentspwhitton
2019-07-12(no commit message)maerwald
2019-07-10seeking advice from DDsJoey Hess
2019-07-10Apt: Debian has changed the name of the suite for testing security updates ↵Joey Hess
from testing to testing-security. The testing-security suite appeared 4 days ago. I don't know where this change is documented; wish I had known about it before the stable release, as now stable has a propellor that doesn't work with testing.
2019-07-02add news item for propellor 5.9.0Joey Hess
2019-07-02releasing package propellor version 5.9.0Joey Hess
2019-07-02clean up after mergeJoey Hess
2019-07-02closeJoey Hess
2019-07-02propellor spinJoey Hess
2019-07-02setting up joeyconfig after mergeJoey Hess
2019-07-02use ConstraintKindsJoey Hess
This is just a bit prettier code than manually needing to use constraint ~ True
2019-07-02improve changelogJoey Hess
2019-07-02reword to be more like ghc wordingJoey Hess
2019-07-02better explain Property <unknown>Joey Hess
I had thought it could happen when passing the wrong type to a Property constructor, but happily that is not the case. For example & osDebian Unstable False Still produces a good error: • Couldn't match expected type ‘Architecture’ with actual type ‘Bool’ So Property <unknown> only happens when too many or too few parameters are passed, eg: & osDebian Unstable X86_64 False & osDebian Unstable Before commit 14f6ae30809d8bbdb10b91cc59757e865a365df8, the former of those resulted in: • Couldn't match expected type ‘[Char] -> p0’ with actual type ‘Property (HasInfo + Debian)’ • The function ‘osDebian’ is applied to three arguments, but its type ‘DebianSuite -> Architecture -> Property (HasInfo + Debian)’ has only two Unfortunately, it's now just Property <unknown>. This is the only reversion I've identified from commit 14f6ae30809d8bbdb10b91cc59757e865a365df8. My ghc bug https://gitlab.haskell.org/ghc/ghc/issues/16894 isn't quite explaining this problem yet, and I need to find a minimal case of it. As to the latter with too few parameters, it used to result in a massive ugly useless error. Now it is also Property <unknown>, which is an improvement.
2019-07-02use DelayErrorJoey Hess
Syrak looked at this branch and said: Cool! I'd suggest that if it's working, that's an accident! You probably want IfStuck e (DelayError err1) (DelayErrorFcf err2) rather than IfStuck e (TypeError err1) (TypeError err2)
2019-07-02Revert "Revert "custom type error messages""Joey Hess
This reverts commit 665ea0d3d9e1b0e90278fd659dee0ef8642030da.
2019-07-02Merge branch 'joeyconfig' into custom-error-typesJoey Hess
2019-07-02point to branchJoey Hess
2019-07-02Revert "custom type error messages"Joey Hess
This reverts commits 14f6ae30809d8bbdb10b91cc59757e865a365df8 de21ef26861db458b0dfb0212cf501f9f8ed459b e20662e6a8881db55394a6366be17ca4e509bc2a Until this bug is resolved, these custom error types hide more basic errors. https://gitlab.haskell.org/ghc/ghc/issues/16894
2019-07-02clean up after mergeJoey Hess
2019-07-01fix build with ghc 8.0.1Joey Hess
Something in commit 14f6ae30809d8bbdb10b91cc59757e865a365df8 ghc 8.0.1 in a few cases unable to infer types when ensureProperty or tightenTargets is used. Newer versions of ghc, including 8.4.4 were able to infer these types. Perhaps it tries harder, or an inference bug was fixed. Seemed best to work around the problem to keep supporting ghc 8.0.1 and the current Debian stable. Since only 3 uses out of hundreds in propellor were affected, it's pretty unlikely it will affect user's properties, but I mentioned in in the changelog anyway. Hopefully a new Debian release will soon mean I no longer need to support 8.0.1, but the code changes also generally made it clearer and easier to read. And, I made custom type errors suggesting adding annotations to help any user who does encounter it. (Included in commit de21ef26861db458b0dfb0212cf501f9f8ed459b; may also help with other cases than an old ghc.)
2019-07-01optionally use type-errors to detect stucknessJoey Hess
Use the type-errors library to detect when the type checker gets stuck unable to reduce type-level operations on MetaTypes, and avoid displaying massive error messages in such a case. But, since type-errors is a new library not available in eg Debian yet, added a WithTypeErrors build flag. When the library is not available, cabal will automatically disable that build flag, and it will build without the type-errors library. This is most often used when combining properties of different types. If the MetaTypes don't have an OS in common, the error message used to be "Property " followed by pages of MetaTypes operations. Now it looks like this: • Cannot combine Properties: Property <unknown> Property HasInfo + Debian + Buntish + ArchLinux + FreeBSD (Property <unknown> is often due to a partially applied Property constructor, or due to passing the wrong type to a Property constructor.) Also it's used in ensureProperty to detect a case where the outer MetaTypes need to be inferred in order to check if the inner MetaTypes match, but the type checker is unable to infer it: • ensureProperty outer Property type is not able to be inferred here. Consider adding a type annotation. • When checking the inferred type writeConfig :: forall (outer :: [Propellor.Types.MetaTypes.MetaType]) t. And it's used in tightenTargets to detect when ghc is unable to infer the desired type of Property: • Unable to infer desired Property type in this use of tightenTargets. Consider adding a type annotation. • When checking the inferred type mk :: forall (tightened :: [Propellor.Types.MetaTypes.MetaType]).