| sahid | jamespage, coreycb: about Train, head-dahsboard does not support python3-django > 2, in eoan we well have 1:1.11, but in eoan-proposed we have 2:2.2.4 | 07:26 |
|---|---|---|
| LocutusOfBorg | Unit193, hello, what is your feeling about a assaultcube sync? | 07:26 |
| sahid | how are we going to handle that? | 07:26 |
| Unit193 | LocutusOfBorg: Hah! I happened to voice that in -motu just earlier today. :P | 07:27 |
| LocutusOfBorg | aaand? sync? | 07:27 |
| LocutusOfBorg | we will loose some bits by syncing | 07:27 |
| Unit193 | LocutusOfBorg: tl;dr: No benefit now, Debian version is *weird* for a couple reasons. | 07:27 |
| LocutusOfBorg | so, forward patches to Debian? | 07:27 |
| Unit193 | (For the longer description, perhaps check logs) | 07:30 |
| LocutusOfBorg | mwhudson, hello, should golang-1.11-race-detector-runtime move to 1.12? | 07:50 |
| EoflaOE | Hello, can someone explain to me what is this channel? For requesting updated versions or what? | 07:51 |
| jamespage | sahid: does horizon support django >= 2 ? | 08:15 |
| sahid | jamespage: yes it looks like since the build success | 08:20 |
| jamespage | sahid: that might not be much of a guide - I don't think we run any testing for horizon during the build | 08:24 |
| jamespage | sahid: indeed "Django<2.1,>=1.11;python_version>='3.0' # BSD" | 08:26 |
| mwhudson | LocutusOfBorg: yes, need to check which revision 1.12 was built with i guess | 09:03 |
| mwhudson | LocutusOfBorg: oh, looks like the same revision as 1.11 so it's just upload with a new package name it seems | 09:04 |
| LocutusOfBorg | mwhudson, shouldn't this one go in Debian? | 09:49 |
| LocutusOfBorg | the freeze is now over :( | 09:50 |
| LocutusOfBorg | :) | 09:50 |
| mwhudson | LocutusOfBorg: yes but i never had the energy to go through the itp process | 09:50 |
| mwhudson | LocutusOfBorg: if you do, go for it! | 09:50 |
| LocutusOfBorg | mwhudson, what does it need? the packaging is already there, right? | 10:09 |
| LocutusOfBorg | just open a bug and I can sponsor it | 10:09 |
| LocutusOfBorg | lamont, hello, can you please do an inspircd merge? did you never upstreamed the patches? the new version is quite a lot different, and I don't know how to check if your patches are still needed or not... | 11:00 |
| === Wryhder is now known as Lucas_Gray | ||
| rbasak | sil2100: I like your block-proposed handling in pending-sru :) | 12:07 |
| === ricab is now known as ricab|lunch | ||
| sil2100 | rbasak: thanks, glad you like it! Although it was Brian's idea to use the blockade emoji ;) | 12:33 |
| === ricab|lunch is now known as ricab | ||
| rbasak | bionic-security has distro-info-data 0.37ubuntu0.5 that Breaks: distro-info (<< 0.18ubuntu0.18.04.1~). | 13:40 |
| rbasak | distro-info >> 0.18ubuntu0.18.04.1~ only exists in bionic-updates. | 13:40 |
| rbasak | Therefore, distro-info in bionic-security has become uninstallable on bionic-security only systems. | 13:40 |
| rbasak | infinity: you TIL ^ | 13:41 |
| rbasak | Wanna bug? | 13:41 |
| rbasak | Looks like the Breaks was introduced in 0.37ubuntu0.3 | 13:43 |
| infinity | Oh fun. | 13:44 |
| infinity | rbasak: Lemme just sanity check the distro-info build and copy it to security if it's clean. | 13:44 |
| rbasak | Looks like it's been like that for a while. Does the lack of report mean that nobody actually does security-only installs any more? | 13:47 |
| infinity | I've asked that question every time something like this comes up three months after we break it. :P | 13:47 |
| infinity | https://launchpad.net/ubuntu/+source/distro-info/0.18ubuntu0.18.04.1/+publishinghistory | 13:49 |
| infinity | rbasak: ^-- It'll fix itself shortly. | 13:49 |
| rbasak | Thank you! | 13:49 |
| infinity | rbasak: Anyhow, I think I've expressed in the past that I feel the updates/security thing is a mess, and if we could come up with a clever way to tag updates as security-or-not, we should collapse them to one pocket and be done with it. | 13:51 |
| rbasak | Some kind of metadata that an apt pin can pick up perhaps | 13:51 |
| infinity | Which sounds simple on the surface ("Just add it to the control data!"), until you realise a user could be two revisions out of date, and the current one in Packages.gz *isn't* tagged security, but the previous was. | 13:51 |
| rbasak | Good point :) | 13:52 |
| rbasak | It'd have to be control metadata with a version string stating when it was last updated for security | 13:52 |
| infinity | So, indeed, another set of stream data that's just package:version pairs of every security update ever, and we fuzzy match between installed and available, or some such. | 13:52 |
| infinity | Or maybe what you say. | 13:52 |
| rbasak | Have fun implementing that in Launchpad :) | 13:53 |
| infinity | Anyhow, if anyone felt like coming up with an elegant solution to that for LP->apt->unattended-upgrades/update-manager, I'd love to ditch the split pockets that aren't really split anyway. | 13:53 |
| rbasak | (or, actually, maybe just in the source package, and Launchpad then wouldn't need to care?) | 13:53 |
| infinity | If security was actually forked from release, that would be one thing, but we always FFWD against updates anyway to save the pain and horror of maintaining forks. | 13:54 |
| infinity | And yeah, LP doesn't necessarily need to know anything here. It could well be implemented at the package level. | 13:55 |
| infinity | It's an extra step for the security team to get right, though. | 13:56 |
| rbasak | What does Debian do on the fast forwarding point? | 13:56 |
| rbasak | The security team would merely need to flag every upload they do as a security update. Tooling could do that. | 13:56 |
| infinity | Whereas something more automated that tags things coming into a specific queue would get it more right more often, maybe. | 13:56 |
| infinity | Debian doesn't FFWD until point releases, where they FFWD literally the whole archive. | 13:57 |
| infinity | As in, stable is replaced with the merge of stable+stable-proposed-updates+stable-security. | 13:57 |
| infinity | Then a new empty spu and ss begin. | 13:57 |
| rbasak | So before a point release, they maintain two forks of each package - spu + security? | 13:58 |
| infinity | Yep. | 13:58 |
| infinity | But there's not much software in spu, compared to what we ship in updates. | 13:58 |
| infinity | So it's not that onerous. | 13:58 |
| rbasak | Yep | 13:58 |
| rbasak | rafaeldtinoco: in https://salsa.debian.org/debian/dbconfig-common/merge_requests/4, did you miss my comment about the changelog? | 13:59 |
| cjwatson | If you're trying to tag updates as security or not, Launchpad would probably have to care because it would have to keep more than one version live in a single pocket. | 13:59 |
| infinity | At any rate, I think it's a cross-team discussion worth (re)having. Maybe even having it in earnest well before 20.04, in case we decide to stop the insanity. | 13:59 |
| infinity | cjwatson: Why? | 13:59 |
| infinity | cjwatson: My take is "if a version between your installed one and the available one was a security update, you get the new one, HTH, HAND." | 14:00 |
| rbasak | cjwatson: I had assumed that the only option available to a user after having missed the security upload in the archive would be to update to an even newer SRU | 14:00 |
| rbasak | Yeah what infinity said | 14:00 |
| cjwatson | Oh, I see. Maybe | 14:00 |
| infinity | People who want to install current-1 to obtusely get only the security update aren't people we really want to cater to. | 14:00 |
| rbasak | Because security already fast forwards so users get arbitrary SRUs | 14:00 |
| cjwatson | That "version between" bit skates over tricky implementation though | 14:01 |
| rbasak | The only current benefit to following only security updates is less regression-risk disruption | 14:01 |
| rbasak | In terms of numbers of updates | 14:01 |
| rbasak | And we'd be maintaining that | 14:01 |
| infinity | cjwatson: I mean, it's a simple dpkg version compare on the client side. | 14:01 |
| cjwatson | Depends on how the tagging is | 14:02 |
| cjwatson | done | 14:02 |
| infinity | Wouldn't get a rollback right, but we shouldn't ever be counting backwards. | 14:02 |
| cjwatson | If client has 2, 3 was tagged security, 4 wasn't tagged security and is current, the client needs some way to know about the tag on 3 | 14:02 |
| rbasak | Hypothetically, a "Last-Security-Update: <version string>" in the binary control file is what I was thinking. | 14:02 |
| rbasak | Though perhaps that's not generic enough for apt | 14:02 |
| infinity | Robie's suggestion of "Last-Security-Update: ${version}" in binary control would DTRT. | 14:02 |
| cjwatson | Sounds fiddly to maintain | 14:02 |
| infinity | Jinx. | 14:02 |
| cjwatson | And easy to get wrong | 14:02 |
| rbasak | I don't think it'd be that fiddly. | 14:02 |
| cjwatson | I do :) | 14:03 |
| infinity | I think it's totally fiddly if it's up to the uploader to get right. | 14:03 |
| rbasak | Mostly it's just security bumping it, and nobody else bumping it. | 14:03 |
| infinity | If it could be injected via security coming in from another queue, or having a more generic tag on it, that's less fiddly. | 14:03 |
| rbasak | Tooling can do that. | 14:03 |
| rbasak | Not sure about release upgrades though. | 14:03 |
| cjwatson | I think we should try to do better than something that requires uploader-side tooling | 14:03 |
| rbasak | Maybe it can be completely ignored for those, since apt is upgrading everything anyway. | 14:03 |
| infinity | rbasak: It's ignored in those situations today, so... | 14:04 |
| rbasak | Get security to continue uploading to the securit pocket. | 14:04 |
| cjwatson | We have plenty of stuff that does already, but that's not a reason not to put thought into doing better when designing a new thing | 14:04 |
| rbasak | And have automation in the upload processing check that it was bumped. | 14:04 |
| infinity | The only reason to "know" about security updates right now is (a) people who pick "sec only" in unattended-upgrades, and (b) so update-manager can highlight "important updates". | 14:04 |
| infinity | Neither of those apply to full dist upgrades. | 14:04 |
| rbasak | cjwatson: I don't really see this as a hack. The source package seems like the appropriate canonical source of this information to me. | 14:05 |
| rbasak | It's already effectively done in debian/changelog | 14:05 |
| rbasak | We'd just be making it machine readable. | 14:05 |
| infinity | Any time you carry a version in more than one place in a source package, the odds of getting it wrong are high. | 14:05 |
| cjwatson | Your proposal is totally a hack compared to having something automatically scan it and work it out centrally | 14:05 |
| infinity | Without explicit tooling and very disciplined uploaders. | 14:05 |
| cjwatson | And I don't quite understand why you're pushing it :) | 14:06 |
| rbasak | It's only a weak suggestion :) | 14:06 |
| infinity | I'd definitely prefer *either* security tagged in changelog (ie: urgency=security), or a queue/target to upload to, but either way, LP would then figure it out. | 14:06 |
| cjwatson | (Not that I'm immediately volunteering; this feels like quite an early stage of discussion ...) | 14:06 |
| rbasak | Working it out centrally seems like a hack to me, because the actual source of the information must come from the uploader in the first place. | 14:07 |
| infinity | I actually prefer just setting a new imaginary urgency, I think. | 14:07 |
| rbasak | Oh | 14:07 |
| infinity | Or declaring that one of the existing ones is now the security team's, so we don't break existing parsers. | 14:07 |
| rbasak | If the canonical location of the information is in debian/changelog, then sure. | 14:07 |
| cjwatson | It's better for the source of information to be "this thing that I'm uploading right now is a security upload" rather than "the last version that was a security upload was <foo>" | 14:07 |
| rbasak | That fits. | 14:07 |
| cjwatson | is what I'm trying to say | 14:07 |
| infinity | cjwatson: Fully agreed. | 14:07 |
| rbasak | Then the control field could be automatically generated from debian/changelog | 14:08 |
| rbasak | Either by Launchpad or at package build time. | 14:08 |
| cjwatson | FWIW the changelog format does already permit multiple tags as well as urgency | 14:08 |
| cjwatson | Whether existing parsers handle it I don't exactly know, but if they don't they're buggy per policy :) | 14:09 |
| rbasak | https://tracker.debian.org/news/1041443/accepted-mysql-57-5726-1-source-into-unstable/ | 14:09 |
| rbasak | mysql-5.7 (5.7.26-1) unstable; urgency=high (security fixes) | 14:09 |
| rbasak | That works fine FWIW | 14:09 |
| cjwatson | now I think that isn't pedantically correct even though it might work | 14:09 |
| rbasak | IIRC it's documented and specified somewhere | 14:09 |
| cjwatson | AFAICS the spec says "multiple keyword=value pairs separated by commas" | 14:10 |
| rbasak | IIRC it's a separate free form comment field | 14:10 |
| cjwatson | https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog | 14:10 |
| coreycb | jamespage: sahid: i just checked with amotoki and django 2.2 support is planned upstream for the openstack "U" release (ubuntu 20.04 cycle) | 14:10 |
| cjwatson | Ah, there's https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-urgency | 14:10 |
| cjwatson | Dunno whether that's better. As a matter of principle I'd prefer using a new tag over imposing new mechanical interpretation on a free-form field | 14:11 |
| coreycb | jamespage: sahid: so not quite sure how to move forward on this one for eoan | 14:11 |
| infinity | Ahh, so urgency=high (security) would get the job done. | 14:11 |
| cjwatson | Unless it's already very widespread practice | 14:11 |
| cjwatson | e.g. urgency=high, security=yes | 14:11 |
| cjwatson | feels better | 14:12 |
| coreycb | beisner: fyi django ^ | 14:12 |
| infinity | I'd be fine with inventing urgency=security (but ick, might break tools) or just deciding that "emergency" or "critical" now mean something. | 14:12 |
| rbasak | cjwatson: over imposing new mechanical interpretation> agreed | 14:12 |
| rbasak | I was just pointing out that this is a form that might be useful and doesn't currently break anything | 14:12 |
| cjwatson | I'd prefer not overloading urgency | 14:12 |
| cjwatson | Yep | 14:12 |
| rbasak | How about Last-Critical-Urgency: <date>? | 14:12 |
| rbasak | Would you consider that overloading? | 14:13 |
| infinity | I don't like gratuitously breaking format like your example just did. :) | 14:13 |
| cjwatson | infinity: how does my example gratuitously break format? | 14:13 |
| cjwatson | it matches the spec | 14:13 |
| infinity | But also, I'm wondering if urgency=[current-values] might be what we really want anyway. | 14:13 |
| cjwatson | I mean, for once we have a format that already supports multiple key/value pairs, and then we try to ram everything into one key? | 14:13 |
| cjwatson | doesn't seem right | 14:13 |
| infinity | That is, maybe what "security only" people really want is "only urgent SRUs". | 14:13 |
| infinity | urgency=critical because it corrupts data is just as important as urgency=critical because it's remote root. | 14:14 |
| infinity | cjwatson: I don't see it matching the spec? Maybe I'm reading a different part of policy. | 14:14 |
| sahid | coreycb: hum yeah, several -dashboard packages are in cause | 14:14 |
| rbasak | infinity: that's sort of what I mean, yes. | 14:15 |
| infinity | cjwatson: I mean, okay, it's alluded to as maybe being okay "commas are used to separate..." | 14:15 |
| infinity | cjwatson: But the bit in parens pretty much immediately invalidates that. | 14:15 |
| rbasak | We get to define what urgency means exactly for our stable releases | 14:15 |
| coreycb | sahid: yes something we're very unlikely to be taking on ourselves | 14:15 |
| rbasak | And it isn't overloading the field for us (Ubuntu) to have a policy on that. | 14:15 |
| rbasak | And then users can follow that policy if we publish the "Last-" in a control field. | 14:15 |
| rbasak | Assuming that urgency has an understood ordering. | 14:16 |
| coreycb | sahid: fwiw nobody will likely deploy horizon on eoan but of course we still want a solution here | 14:16 |
| cjwatson | infinity: the bit in parens is part of the urgency key's value | 14:18 |
| cjwatson | infinity: so urgency=foo (bar), some-other-tag=some-value is valid | 14:18 |
| infinity | cjwatson: I meant the parens at the end of the sentence I was quoting. | 14:18 |
| cjwatson | infinity: that's just a matter of the keys that are currently defined; it doesn't preclude defining new ones | 14:19 |
| infinity | cjwatson: Given that there's only ever been one key=pair value of any note, the odds that tools are robust enough to assume more would be naive. | 14:19 |
| infinity | key=value pair, even. | 14:19 |
| cjwatson | there aren't that many such relevant tools; easy enough to check | 14:19 |
| * infinity shrugs. | 14:19 | |
| rbasak | We'd notice at build time | 14:20 |
| infinity | I still maintain that this is an opportunity to revisit what we (and users) really mean with "security-only". | 14:20 |
| rbasak | We could start doing it well in advance of any implementation | 14:20 |
| cjwatson | In fact there used to be closes= | 14:20 |
| cjwatson | many many years ago | 14:20 |
| infinity | Because, for my money, what I mean is "I want high urgency stuff NOW, and I can wait on other stuff until I've read the changelogs." | 14:20 |
| rbasak | git-ubuntu has had fun with parsing old changelog formats | 14:20 |
| infinity | Not strictly security. | 14:20 |
| infinity | But security-only is the only approximation we have of "high urgency" today. | 14:21 |
| infinity | Note that MS has a similar urgency setting hidden in their updates. | 14:21 |
| rbasak | With urgency in heavy use in Debian's testing migration, I wonder if there's any potential for future conflict with that | 14:22 |
| cjwatson | If what we actually want is semantically urgency, then I don't mind overloading that | 14:22 |
| infinity | Which gives you everything from "won't touch it until a user clicks a button" to "will install in the background when the machine isn't busy" to "will install now, but maybe not take hold until reboot" and ultimately "will install NOW and reboot NOW, and also fuck you slightly, but this is important." | 14:22 |
| rbasak | There's nice separation in that this would only be for our stable releases | 14:22 |
| infinity | They've backed off a lot on using the last one, thankfully. | 14:22 |
| rbasak | But what if Debian start wanting to do something with their stable releases and also use the urgency field? | 14:22 |
| infinity | rbasak: What if? | 14:23 |
| cjwatson | dpkg-parsechangelog parses "urgency=medium, security=yes" fine, although it issues a couple of warnings because it doesn't know about that particular field name | 14:23 |
| cjwatson | FWIW | 14:23 |
| infinity | Yeah, I didn't assume dpkg would have any issues. | 14:23 |
| rbasak | infinity: it might result in tooling changes that affect our use of the field, perhaps? | 14:24 |
| infinity | I'm willing to bet there are people out there that have their own changelog reading madness, though. | 14:24 |
| infinity | To do crazy things like feed into RT for sysadmins to look at incoming updates, and who knows what other crazy. | 14:24 |
| infinity | rbasak: I kinda doubt it? | 14:25 |
| infinity | rbasak: urgency has always had more meaning in Debian than in Ubuntu. If we started using it, we'd be aligning, not diverging. | 14:25 |
| infinity | rbasak: Assuming we did so with a bit of thought behind it. | 14:25 |
| infinity | Anyhow, I think this is a good start for a baseline cross-team discussion for another time. | 14:26 |
| infinity | I definitely think the changelog would be the right place for this magical data to live and be extracted from. | 14:26 |
| infinity | We also didn't posit the idea of free-forming another bug syntax, which would skip some of the potential "we might break tools" issues. | 14:27 |
| infinity | LP-SEC: #123455 | 14:27 |
| infinity | Or whatever. | 14:27 |
| rbasak | own weird changelog reading madness> oh you mean like this: https://git.launchpad.net/usd-importer/tree/gitubuntu/git_repository.py#n434 | 14:28 |
| infinity | Has the downside of requiring a bug for every security upload, but honestly, we probably should have anyway. | 14:28 |
| cjwatson | I think the only good reason for bugs to be annotated the way they are is to allow them to go alongside the prose description of their fix. It wouldn't make sense for something that's essentially a flag on the version. | 14:28 |
| infinity | Probaby true, was just giving a less invasive (from a formatting POV) option. | 14:29 |
| cjwatson | (There's a non-trivial amount of hairy stuff associated with bug closures in LP.) | 14:30 |
| infinity | Anyhow, I think the base level discussion (should we collapse pockets, and why, and what would be the end goal of flagging versions (security, or urgency, or some combination of both)) needs to happen before we bikeshed anymore about how to flag versions. :) | 14:30 |
| cjwatson | Yeah, agreed | 14:30 |
| cjwatson | End goal before anything else :) | 14:30 |
| === Wryhder is now known as Lucas_Gray | ||
| santa_ | ddstreet, rbalint: good evening, systemd >= 242 fixed my autopkgtest hangs, thank you. but I found yesterday a new issue with latest 243 from -proposed: | 18:40 |
| santa_ | udisks2 fails to install in a LXD container because the postinst script fails | 18:41 |
| santa_ | udisks2 postinst executes "udevadm trigger --subsystem-match=block --action=change", and this command fails like this (inside an LXD container): | 18:42 |
| santa_ | m | 18:44 |
| santa_ | https://paste.ubuntu.com/p/5shmRgGRy3/ | 18:44 |
| santa_ | udisks2 installation inside an LXD container (with -proposed enabled): | 18:45 |
| santa_ | https://paste.ubuntu.com/p/jTmJNpVwkY/ | 18:47 |
| santa_ | ... and last but not least, syncing udisks2 from debian wouldn't solve the problem | 18:50 |
| santa_ | (I've just tested that with this package here: https://launchpad.net/~panfaust/+archive/ubuntu/kde-test-good) | 18:51 |
| rbalint | santa_, there are other issues with 243, hopefully we can resolve those as well soonish | 20:32 |
| mwhudson | good morning #ubuntu-devel | 21:02 |
| connor_k | o/ | 21:14 |
| genii | Hi, just wondering if someone could clarify what video mode is being set in OEM install mode which may differ from regular install video mode. In regular install for instance, I can see the entire window but in OEM mode the bottom is cropped off ( on a netbook screen which is 1024x600 it seems like the windows are a non-resizable fixed at maybe 1024x768) | 21:26 |
| santa_ | rbalint: ack, thanks | 21:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!