| HimeHaieto | LeePen: reposting this from #devuan, but I just noticed that oldstable/chimaera's release file contains a couple errors setting the origin/label to "None" instead of "Devuan" and it's kinda messing with my pinning preferences...see here: http://deb.devuan.org/devuan/dists/oldstable-security/InRelease | 00:48 |
|---|---|---|
| HimeHaieto | actually, for that matter, now that I'm looking into some things a bit more deeply, even beyond that issue it looks like the entire way the release files are handled is different from standard debian practice, particularly for making it appear to be impossible to, say, making pinning rules based on generic releases (eg stable/testing) vs named ones (eg daedalus) | 01:21 |
| HimeHaieto | if I already have pinning rules in place for "release o=Debian*, a=stable", I appear to have no way to make a semantically equivalent rule akin to "release o=Devuan, a=stable" - it would have to be "release o=Devuan, a=daedalus", which would cause surprise breakage between releases unless/until manually changed to the next name | 01:24 |
| HimeHaieto | or for that matter, it kills pinning in a rolling release style of setup in the first place, even if using devuan's merged repos | 01:25 |
| HimeHaieto | debian stable's InRelease: http://http.us.debian.org/debian/dists/stable/InRelease | 01:25 |
| HimeHaieto | devuan stable's (daedalus) InRelease: http://deb.devuan.org/devuan/dists/stable/InRelease | 01:26 |
| HimeHaieto | if the "Suite" fields were simply set to the appropriate generic release name (stable here) like with debian instead of being duplicates of the codename, it could all work well | 01:27 |
| HimeHaieto | looks like testing actually does this, not sure what all does or doesn't now at this point | 01:31 |
| HimeHaieto | http://deb.devuan.org/devuan/dists/testing/InRelease | 01:32 |
| HimeHaieto | there's also an excalibur-proposed-updates, whose release file uses the suite value of testing-proposed-updates, but there is no testing-proposed-updates in the dists directory | 02:28 |
| HimeHaieto | so good on the suite part, but curious about the missing dist | 02:28 |
| LeePen | HimeHaieto: Why are you using deb.d.o/devuan? | 06:13 |
| LeePen | It should be deb.d.o/merged | 06:14 |
| HimeHaieto | devuan exists to provide only the packages that are altered from debian - the rest I get from debian proper | 06:16 |
| HimeHaieto | both approaches are perfectly valid | 06:16 |
| HimeHaieto | though you raise an interesting point - I hadn't checked the merged dists as well, and it looks like there's also a merged/devuan discrepancy - this may be an issue that is exclusive to the devuan dists, but I haven't checked all the merged ones | 06:18 |
| LeePen | Just use /merged. That is exactly what that does. | 06:18 |
| LeePen | afk | 06:18 |
| HimeHaieto | thanks for the suggestion I guess, but that doesn't really address the problem and I'm not using merged | 06:21 |
| LeePen | You are the only person I know of who has tried to do their own merge. I have never tested it. | 06:21 |
| HimeHaieto | that just suggests to me that any possible harm for fixing the fields is substantially more likely to be negligible | 06:23 |
| HimeHaieto | so cool, bonus points toward a potential solution | 06:24 |
| LeePen | I can have a look, but it won't be for a while as I have to rebuild my mail server first. | 06:24 |
| HimeHaieto | but the testing part is precisely part of the whole point - no matter how stellar devuan development is, you can't really compete with the size and power of debian proper and all of its testing | 06:25 |
| HimeHaieto | if I'm running debian but only need ten packages from devuan to get all I need whilst avoiding the systemd plague, then awesome...I just need those, and the rest can come from a source maintained and publicly battle tested by far more | 06:27 |
| HimeHaieto | no offence, I love devuan | 06:27 |
| HimeHaieto | and time is something I have, no worries | 06:27 |
| HimeHaieto | also...I'm shivering a bit wrt the mail server...been there a bit, some pain could be involved... | 06:28 |
| onefang | That's the point of "merged", so that the packages that drag in systemd are "fixed" by Devuan, or banned, the "fixed ones come from Devuan servers, and the rest that are identical to Debian packages come from Debian servers. | 06:31 |
| HimeHaieto | yes, I know what merged is and the difference between it and the devuan dists | 06:36 |
| Nietz | meet | 15:12 |
| Nietz | ^whoops . . . apolos | 15:12 |
| xrogaan | Could somebody with greater knowledge highlight something for me. Should the Package.gz file update every day? http://deb.devuan.org/merged/dists/daedalus-security/main/binary-amd64/ | 17:25 |
| xrogaan | received this email yesterday: https://lists.debian.org/debian-security-announce/2023/msg00286.html | 17:36 |
| xrogaan | I'd assume the security repository to be high priority, since it can leave existing systems exposed to threats. | 17:37 |
| * xrogaan pokes LeePen | 17:40 | |
| fsmithred | HimeHaietoif the "Suite" fields were simply set to the appropriate generic release name (stable here) like with debian instead of being duplicates of the codename, it could all work well | 20:37 |
| LeePen | HimeHaieto: I think you misunderstand how the debian packages in /merged are used. | 20:54 |
| LeePen | They are the very same ones you are downloading directly from debian, we don't recompile unforked packages, we HTTP redirect to debian mirrors. You are just doing that work manually, which is fine, if you prefer. | 20:55 |
| Nietz | golinux: meet today? | 21:28 |
| plasma41 | Meeting time! | 21:33 |
| fsmithred_ | HimeHaieto, sorry, I got pulled away before I was done. If you (or we) used the generic suite names, it would not work well when debian released its next stable and the forked packages in devuan were not all ready. We don't go stable until after debian does. | 21:53 |
| fsmithred_ | I have to go. Can't be at meeting. Sorry. | 21:53 |
| fsmithred_ | afk | 21:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!