=== boiko__ is now known as boiko [00:16] juliank, mvo, xnox: added my comments to bug 1615482 [00:16] bug 1615482 in apt (Ubuntu) "apt-daily timer runs at random hours of the day" [High,Fix committed] https://launchpad.net/bugs/1615482 === mbarnett_ is now known as mbarnett === tsimonq2alt is now known as tsimonq2 [06:49] rbasak, I uploaded the patches I've tested on bug #1641203, I can't get a debdiff working [06:49] bug 1641203 in sssd (Ubuntu Xenial) "SSSD can't process GPO from Active Directory when it contains lines with no equal sign" [Medium,Triaged] https://launchpad.net/bugs/1641203 === arune_ is now known as arune [06:58] hloeung: Let's see how 1 hour delay works out (it's still twice as much as before) for a few weeks. If I'd guess the peak would be around 50% to 75% of where it used to be (it really depends on how long the update is). The only way to solve bandwidth issues and really still maintain a sensible time window is to provide pdiff support on the archive (which reduces download size by like 90%). [07:12] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2014-February/014793.html (Continued into the next month.) - LP 214612 [07:12] Launchpad bug 214612 in Launchpad itself "Provide pdiffs for apt-get update" [Low,Triaged] https://launchpad.net/bugs/214612 [07:21] I like this bug description "There's a glitch in binaries." [07:21] :-) [07:22] Unit193: There are a lot of difficulties with pdiffs here, basically. [07:23] juliank: Just pointing to it, though might be helpful to some during the dev cycle. [08:52] hloeung, juliank, mvo: end-users care about predictable times when the upgrade happens; end-users do not care (usually) about mirror spikes. mirror administrators care about mirror spikes... but not when the end-user upgrades happens. I fight for the user! [08:53] hloeung, about the mirrors. Could you elaborate as to how they are deployed. I would have thought that for example on big clouds, there would be a local bucket/cdn used to serve the mirror at blazing speeds with no need to spin up any instances. [08:54] xnox: heh except when it's heavily loaded, end users will most likely miss out on important updates [08:54] xnox: I think we need input from IS here (you are seeking it already so +100 for that). my understanding is that we have a lot of mirrors on ISPs, univesities etc that care about spikes [08:55] xnox: they're deployed using juju, ubuntu-repository-cache charm (which is basically squid-deb-proxy) [08:56] These things are easily changeable via a drop-in unit. Large organizations that can tolerate more variance can easily roll out a config file choosing whatever they want. [08:56] xnox: note that I don't really mind either way, we need to decide what is more important and if we can find a middle ground. in the old days before systemd iirc the randomization was 6am + 2h so maybe we could go back to something like that. i.e. not spread over the entire day but only within ~2h or 4h or something [08:56] hloeung, mvo: we had a customer outage were mid-day upgrades killed customer workloads in a dedicated ($$$) hosting provider. The change from one hour window, to unpredictable window is streated as a severe regression and has been escalated to me. [08:56] hence we are reverting back to previous behaviour for now. [08:56] mvo: xnox: It was 30 minutes, 6:00-6:30, actually [08:56] AFAICT [08:56] right. [08:57] Now it's 6-7 [08:57] and i think 1h is accetable, random throughout the day is not. [08:57] xnox: all we, IS, asked for was a larger window than the 30m [08:57] 1 hour is larger [08:57] hloeung, but e.g. debian has an archive mirroring onto aws cloudfront these days. I'll try to find if that code is available, and if we can jujufyit. [08:57] juliank: ok then, we'll see how 1hr goes. Thanks! [08:58] Now, assume an update takes 4 minutes, you can calculate how much the load will be relative to 30 minutes [08:58] juliank: you are right, I misremebered [08:58] hloeung, it's blazing fast, at least for me. [08:59] Though 4 minutes is probably too much. Most updates take like 90s I'd think [09:00] and with a local mirror, things are even faster [09:00] Our accuracy is 1 minute, so we have 60 options at which to start updates [09:01] (could improve accuracy to 1s or so, but given the duration of an update, there's likely no benefit) [09:02] Let's assume you have 10,000 clients, each taking 2 minutes to update (for ease of calculations). How many clients will be active at the same time? [09:02] hloeung, should the clouds with spikes problems have their cloud images modified with a larger update window? e.g. we can totally make cloud images for cloud $foo region $bar to have a larger update window. [09:03] hloeung, but my preference is to actually use cdn-like mirrors rather than instance-cpu powered ones. [09:03] xnox: yeah, if you can do that, then that will definitely help [09:03] xnox: costs $$$ :( [09:03] hloeung, former / latter / both? [09:03] ah. [09:04] xnox: if it's easy to have cloud images randomise over a larger window [09:04] I thought about providing a package for changing the default to a longer period [09:05] Like apt-config-long-maintenance-window [09:05] Could do updates between 0 and 7 [09:06] It's a bit silly as it's one file with like 5 lines, but people apparently can't figure that out themselves, so maybe that's what is needed [09:06] I'd love to do pdiffs, but I've never been able to sort out how it would work with the much faster archive cycle we have than Debian. === cjwatson_ is now known as cjwatson [09:07] I don't want to end up having to keep a zillion little files around. [09:07] cjwatson: Yeah, that's really the main issue. You gotta do merged pdiffs then, and keep less ones around. [09:07] juliank, well, imho cloud-init for the cloud should realise that X UTC is not the best time to update the whole world, and that it should figure out the cloud/region it is in, and use "machine-local timezone; cloud-region timezone; utc" to spread the update load. [09:08] Whatever works for you, I was just thinking about the general case. [09:09] What I realised yesterday is that 6-7 might not be the best time for Indian users. IIRC, they have a lot of cheaper-at-night data stuff, and would prefer something more midnighty? [09:09] Ah yes, 0-6 [09:10] juliank, there is a bit of information about the mirror spikes problem. For a few clouds, canonical operates the mirrors - which all fallback to the Canonical UK country mirror. Meaning a DDOS at 6:00am =) [09:10] juliank, yes, as soon as i saw the 6am-7am UTC i was like that's a bad time for anybody between Moscow, India, Oceania. [09:10] Maybe we should have picked 5-6 [09:10] but the argument there is that 6am-7am localtime is good enough, and is close enough to a revert. [09:11] for a general case; and people on metered connections probably also have their devices off; or specifically schedule things overnight (e.g. torrents, updates, what not) [09:11] We can still have apt-night-update which configures a 0-6 time or something. [09:11] because it's a lot more hands-on. [09:11] Sure, it would be interesting to get some feedback on that. [09:11] juliank, as a command maybe, rather than a package with one drop in. [09:12] xnox: I am close to thinking about a debconf question: When do you want automatic updates to occur? [09:12] juliank, at the moment the feedback is that mass majority uses the default; for a niche users that causes mirror spikes / slow apt update; for another niche of users it causes sysadmin stress over not knowing when the updates will strike. [09:13] juliank, no such prompt will be in ubuntu; we default to automatic updates, because we want our users to be secure. [09:13] plus cloud images do not do debconf =) they are all non-interactively launched and configured, and are by far the largest % of users. [09:13] xnox: Well, it would still have automatic updates, it just asks you at which time :D [09:14] On the cloud, you'd set the selection and reconfigure the package. [09:14] * xnox giggles [09:15] But well, we can ship a bunch of drop-ins in /usr/share/apt and build a selector that looks at the descriptions, lists them all and allows you to choose one. [09:15] juliank, the cloud provider, should be dictating imho cloud policy via the vendor meta-data in the config drive; such that cloud-init can read it and dictate the policy. The cloud guests, have ability to disable vendor data and place their own overrides. [09:15] Or, well, just use update-alternatives for that [09:16] juliank, most people never login to reconfigure a package in the cloud. Most deploy their workloads via things, and scale up/down. [09:16] xnox: This is just a way to give systemd its config files. How you start that is another topic [09:16] juliank, whilst nice for end users on the console, most people will be annoyed by it, and it will not at all mitigate mirror spike from large clouds. I don't think. [09:17] juliank, imho for regular people; solving the running of apt-updates on resume with networking is imho a much larger priority than debconf prompts to assist people on how to update systemd timers schedules =) [09:18] That's true I think. [10:41] xnox: So, the plan is to go ahead with the 6-7 SRUs, then and do something special for cloud? I'd prepare them later today then. [10:42] juliank, yes. [10:43] Alright :) [10:43] juliank, mean while i'm trying to reproduce and/or fix the autopkgtest failures that are blocking the release of the SRUs. [10:43] there are "regressions" one down, one to go. [10:43] xnox: They alway happened, we always ignored them [10:43] https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/1686064 [10:43] Launchpad bug 1686064 in sbuild (Ubuntu Artful) "sbuild ADT test can only pass in devel series" [Undecided,New] [10:44] xnox: yep, that's the issue :) [10:44] xnox: Fixing that will make all SRUs faster :D [10:47] and i am retrying the autopkgtest package adt failure, triggered by apt in xenial. as i cannot reproduce it. [10:47] xnox: The AssertionError: 16 != 0 ? [10:48] yeah [10:49] xnox: that has been happening in all previous SRUs as well, so a retry should not fix it :( [10:52] xnox: Did you just see what harry33 did it in the timer bug report? [10:54] people these days [10:55] juliank, yeah well done. [10:55] juliank, also i think it is wrong that systemd doesn't do login before everything is up; they argue everything should be up before one is allowed to login. [10:56] Maybe there is some dependency somewhere between multi-user target or dm and the timer target? [10:56] or something. [10:56] It should not block at all on timer services, that's silly [10:57] * xnox laughs [10:57] juliank, systemd is silly..... =) [10:58] xnox: I like systemd, just some minor issues here and there [11:02] xnox: Also does not happen on my (Debian) system [11:05] I could not login though, but that might be unrelated [11:06] xnox: https://paste.ubuntu.com/24453611/ I call BS on does not reproduce :-) [11:06] Laney: Oh, if you can reproduce it, you can probably also fix it :D [11:07] No. [11:07] :( [11:08] If I can reproduce it, someone else can was my message [11:53] horum. [12:03] Laney, to counter your reproducibility - sudo ./tests/adt-run ChrootRunner.test_setup_commands_string passes on xenial =) [12:03] clearly the autopkgtest infra interferes with autopkgtest test suite =) i wonder if there are environment variables that leak into the tests, causing it to fail. [12:04] run it in the same way that the testsuite runs it? [12:24] trying $ autopkgtest -s autopkgtest -- lxd autopkgtest/ubuntu/xenial/amd64 [12:27] I have -s -U --apt-update=proposed=src:apt autopkgtest [12:27] oh and --test-name adt-run to just run that one [12:29] but if it's ~always failed then the SRU team might be willing to overlook it === JanC_ is now known as JanC [12:33] so doing it without -U and without --apt-update, but with -s [12:33] i get the failure, but the temp dirs are cleaned up already [12:34] rerunning ./tests/adt-run ChrootRunner.test_setup_commands_string passes.... [12:34] so i am confused a bit. and the temp dirs have been cleaned up by the test =( [12:39] you can past -B and run autopkgtest from within the source package to run the tests from there [12:40] like hack the script to delete all the other tests and any teardown stuff you don't want [12:40] (delete 'autopkgtest' from the commandline to do that) [12:44] yeah =/ [12:44] let me finish sbuild tests first, to sru that (that is a simple cherrypick) [12:53] libelf-dev : Depends: libelf1 (= 0.166-2ubuntu1) but 0.168-0.2 is to be installed [12:53] looks like some binary packages aren't ok in zesty ? [12:53] source package makes -dev depend on same binary version [12:58] xnox: the timer "adding random time" messages are still a bit much in the log: https://paste.debian.net/929242/. Why oh why does it pick a new delay every 10,20, or 30 minutes? [13:02] somehow my libelf1 was from artful (even using zesty only repository), weird. fixed. [13:04] juliank, i have opened a bug report about that to investigate. honestly crap like that does not belong in kern.log / dmesg. [13:05] I know [13:06] not in my kernel log, though, I don't think that's normal :D [13:25] how can i get an ubuntu source package with history in bzr/git? [13:26] http://packaging.ubuntu.com/singlehtml/ says : bzr branch ubuntu:flash-kernel [13:26] but it does not work [13:27] i'm about to review all the Ubuntu deltas and seeing the accurate history would be helpful in some cases [13:28] rbalint: I don't think it's possible? The bzr one stopped a year or two or so ago [13:28] There are some git repos, but I don't know if they are ready yet? [13:28] xnox: My boot test was flawed actually. I did not have anything in the network-online.target - my NetworkManager-wait-online.service was disabled. Will reboot later and see what it actually looks like [13:29] juliank: will the bzr one be restarted? [13:29] nah [13:29] juliank: i would cut that part from the howto then [13:30] juliank, you are racing with udev, as our networking does come up udev based on resume, i am suspecting. at least ifupdown is triggered by udev on resume. [13:30] Interesting [13:30] http://lintian.ubuntuwire.org is also down [13:31] juliank: is there anyone who i can ask regarding the git repos? [13:31] idk [13:32] xnox: Just suspended and resumed, but status (on Debian) says: "Active: active since Tue 2017-04-25 13:01:24 CEST; 2h 30min ago" - not sure if anything is changed in the Ubuntu version of systemd :) [13:33] But I think it would be easy to just stop and resume that target, but that's really something for upstream to decide :) === alan_g is now known as alan_g_ [13:50] nacc: hey! Do you know who could help verifying the LP: #1564778 SRU? It's in -proposed for 25 days already with another SRU waiting in queue already [13:50] Launchpad bug 1564778 in sane-backends (Ubuntu Yakkety) "package libsane-common 1.0.25+git20150528-1ubuntu2 failed to install/upgrade: trying to overwrite '/etc/sane.d/hp.conf', which is also in package libsane:i386 1.0.23-3ubuntu3.1" [Undecided,Fix committed] https://launchpad.net/bugs/1564778 [14:00] xnox: try cbac107 [14:01] Laney, hm? [14:02] it's a commit [14:02] I bet it works [14:02] ah [14:02] ok [14:04] Laney, yes, that sounds right. [14:04] :D [14:04] I guess the problem when you ran it is that you don't set that variable [14:04] and it's the -z thing that fails [14:04] yeap, will sort this out for the sru. [14:05] sbuild yakkety, is in the unapproved queue. [14:05] awesome [14:05] fixing tests, what a thing! [14:05] juliank: reported the issues, will see what happens: LP: #1686100, LP: #1686096 [14:05] sbuild xenial fails - because i bet i need to tweak things for xenial now, and again the thing doesn't reproduce in the fail shell =( [14:05] Launchpad bug 1686100 in Ubuntu Packaging Guide " bzr branch ubuntu:hello stopped working" [Undecided,New] https://launchpad.net/bugs/1686100 [14:05] Launchpad bug 1686096 in Ubuntu Packaging Guide " http://lintian.ubuntuwire.org is down" [Undecided,New] https://launchpad.net/bugs/1686096 [14:05] Laney, i know, i don't think i like ever done this! [14:06] I ran it with that cherry pick btw [14:06] passes [14:06] could upload if you want? [14:07] Laney, sure. do a bug, sru template, the whole lot. and we need it just in xenial i think, no? [14:07] it's in yakkety's version already [14:09] do I have to explicitly request syncs from experimental->artful if one was done before, or will they happen automatically? [14:10] Explicit every time. [14:10] ah, thanks [14:46] doko: Whatever happened to bug 1644363 - the linker crashing on arm64 in trusty? It's been 4 months now, and the SRU for bug 1422795 is blocked by this (not to mention other SRUs that might be linking the wrong code because ld failed in some configure tests) [14:46] bug 1644363 in binutils (Ubuntu Trusty) "[trusty/arm64] binutils segfaults on bash gettext configure test" [Undecided,Confirmed] https://launchpad.net/bugs/1644363 [14:46] bug 1422795 in bash (Ubuntu Trusty) "bash crashes often if inputrc contains revert-all-at-newline" [High,In progress] https://launchpad.net/bugs/1422795 [14:51] It should just be a matter of bisecting eglibc between the broken and working versions, and fixing it? [14:53] Although, maybe it is indeed a bug in binutils, and fixed by this commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=99d190fac4d2aab238cfc798dc5c28ab41456882 [14:53] At least that's what https://git.busybox.net/buildroot/commit/?id=4210c49357b216705a85734293023d8d5683bb49 says [14:56] * juliank added that as a comment. Not sure if it helps - don't know if the patch even applies :) [14:56] infinity: ^ (since you were the one doing the initial debugging) [14:57] * juliank does not have an arm64 to test this on :/ [14:57] sil2100: i can try today, yeah -- i was never affected [15:00] I guess I'll just try applying the patch [15:01] Patch applies :) [15:04] nacc: thanks! [15:07] sil2100: np, thanks for the poke [15:09] Uploaded binutils to https://launchpad.net/~juliank/+archive/ubuntu/lp1644363+1422795, let's see if that works out [15:10] If it does, I'll re-upload it to trusty proper, and then we can finally build bash on arm64 :) [15:17] juliank: Oh shiny. [15:20] tinoco: From artful-proposed, even. Well done. [15:20] infinity, is anybody going to announce the opening of the new serie on the devel list? [15:21] seb128: Oh, I suppose I could send the email. I think after opening on Friday, my carefactor was low. :P [15:21] infinity: Regression potential = "ld will stop crashing in some cases, which could potentially change some dependencies for SRUs (if their configure test failed due to an ld crash)."? [15:22] juliank: That's more of a progression potential. [15:22] Trying to SRUify the bug report [15:23] infinity, that would be nice, thanks [15:23] juliank: "[Justification/Impact] Fixes stuff [Regression Potential] Might break other stuff." [15:23] juliank: There, I've just written all your SRU bugs for the next decade. [15:23] Lol [15:24] Should have went for a walk while binutils was building :/ [15:25] Ah well, I can go now, it will take some time before its published anyway. So I'll upload bash to the PPA in 50 mins or so then, and then we'll see if it helped [15:30] juliank: Fingers crossed. It's likely a valid fix regardless, but it would be nice if it fixes that specific bug. :P [15:42] rbalint: yeah, packaging guide speaking quite so loudly about bzr was on my list to look at too -- thanks for doing that! :) [15:42] rbalint: in what context are you "about to review all the ubuntu deltas"? Do you mean for every source package? [15:51] nacc [15:51] nacc: yes, exactly [15:51] rbalint: we probably should sync up :) [15:52] nacc: my idea is pulling all Debian Vcs history and all Ubuntu (package?) history to a single git repo [15:52] rbalint: right, we (server team) are doing that [15:52] nacc: using git, git-remote-svn, git-remote-bzr, etc [15:52] rbalint: e.g., https://code.launchpad.net/~usd-import-team/+git [15:52] rbalint: we use the launchpad publishing history rather than the debian vcs, though [15:52] nacc: nice [15:53] rbalint: since we have it for both (we can eventually add debian as a trusted remote once we get there) [15:53] nacc: is there any doc on the effort? [15:53] rbalint: always a good question [15:53] rbalint: i've posted a few times to ubuntu-devel, i plan on posting again soon [15:54] rbalint: there some generic stuff about the toolling (for merges): https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow [15:55] rbalint: there is also the SPECIFICATION and some README in the https://git.launchpad.net/usd-importer/tree/ [15:55] rbalint: it's available as a snap now (usd-nacc) [16:01] rbalint: "all Debian vcs history" makes some odd assumptions about what's authoritative. [16:01] yeah, which is why we initially aren't trusting it [16:02] rbalint: The only authoritative sources are the Debian archive and the Ubuntu archive, which I believe is what nacc's machinery assumes. [16:02] well "trusting" it -- launchpad shows us what was published in the archive(s) [16:02] yeah [16:02] nacc: thanks! [16:02] if we could do some 'rich history' lookup we can parent basically anything in (with some new code) -- but it's not clear how to do it 'right' for all cases, etc. [16:03] I am unable to understand the difference between maintainer scripts like postrm v/s postrm.debhelper [16:03] which one to use and when ? [16:03] what does .debhelper in the end signify ? [16:03] infinity: yes, the vcs repo is sometimes outdated, but I'd like to use the result for preparing patches based on the Ubuntu delta [16:04] infinity: considering a well maintained package the vcs repo is correct and may already contain extra patches [16:04] rbalint: It's not a question of outdated, or anything else, really, it's that most packages in Debian (and Ubuntu) don't have a VCS, and even when they do, the only authority on what's actually uploaded is the archive itself, as we do not build from VCS. [16:04] infinity: meeting? [16:05] mdeslaur: Err, oh, yes. [16:05] infinity: i got those [16:05] rbalint: we want users to be able to rely that what we 'import' as a given version is exactly that version as uploaded [16:05] viral_mutant: *.debhelper are autogenerated files that you don't touch manually. They're removed on clean. [16:05] nacc: this is ok [16:05] rbalint: everything else is ancillary so far :) (but i'm 100% on board with you filing a bug/feature request for other cases against the importer -- note the 'other vcs' case is already reported) [16:06] viral_mutant: General guideline is, wherever possible, try to let debhelper write your maintainer scripts for you by way of its automatically-emitted snippets, but if you have to then you put your own code in debian/postrm (etc.). [16:06] viral_mutant: If you do that, you should include a #DEBHELPER# line which dh_installdeb will replace with the collected autogenerated code from various other debhelper commands. [16:07] viral_mutant: (see "man dh_installdeb") [16:08] cjwatson: so if I have prerm.debhelper and my own prerm.debhelper, both will be executed ? In which order ? [16:08] yes, I referred the man page but could not understand the #DEBHELPER# comment [16:09] sorry, I meant my own prerm [16:10] viral_mutant: You must not write your own prerm.debhelper. [16:10] viral_mutant: If you need to write your own prerm code, it goes in debian/prerm, and you put a #DEBHELPER# comment somewhere in it. Where you put that comment controls what order things go in. [16:11] viral_mutant: See https://anonscm.debian.org/cgit/pkg-man-db/man-db.git/tree/debian/postrm for example [16:11] viral_mutant: When the package is built, all of the automatic stuff is substituted into that script at the point where it says #DEBHELPER#. [16:12] the #DEBHELPER# comment is mandatory ? [16:12] viral_mutant: You would almost always be very foolish to omit it. [16:13] viral_mutant: If you have no manual code to write in a maintainer script, though, it's fine to leave it out of your source package entirely (so you don't need e.g. a debian/prerm that basically has nothing but a debhelper substitution comment). [16:15] cjwatson: ah I see. actually the task I have at hand is to create DEB package from source. that source has been used till date to generate RPMs only [16:16] so I tried 2 methods to generate the deb package [16:16] one is using ‘alien’ tool on generated RPM which generates the post/pre inst/rm files [16:17] and other is to use settools bdist_deb which generates .debhelper scripts [16:17] wtf to both [16:18] if it's a python package then just find a reasonable existing python package to crib from; most of that is well-automated by now [16:18] I guess the .service files disable/remove etc will be automatically taken care of [16:18] dh_installinit usually handles that kind of thing in normal packages [16:18] I have no idea what weirdo tools like alien or bdist_deb would make of it [16:18] I need not write my own post/pre rm scripts, right [16:19] in the general case; sometimes there are exceptions depending on exactly how things are laid out [16:20] the design of modern debhelper (dh(1) etc.) is that it handles common cases and you generally only need to tell it about things that are in some way unusual relative to most packages [16:25] cjwatson: thanks. that really helps [16:27] infinity: got curious, actually less than 20% of packages in Debian don't have vcs: http://upsilon.cc/~zack/stuff/vcs-usage/ [16:27] infinity: bash built. binutils in trusty-proposed unapproved queue, needs approval! [16:28] juliank: \o/ [16:28] infinity: this is still a significant amount, but not "most" [16:29] rbalint: Weeeeeell, it's a more interesting story than that, though. [16:29] rbalint: As they don't all use VCSes the same way. [16:29] rbalint: debian-dir-only versus full unpack being the biggest difference. [16:29] infinity: this is true [16:29] rbalint: Either way, the VCS is not authoritative, period, is the only point I was making for this exercise. [16:30] rbalint: If the VCS and archive don't match, the VCS is by definition wrong. [16:30] (And they often don't match... More than you'd think) [16:30] infinity: Still worth including the Debian VCS history though where it matches; in such cases it's going to be a richer source of history than anything we can put together automatically [16:30] infinity: yes, saw many cases of that [16:30] infinity: (Or even where it doesn't match, as a partial history) [16:31] cjwatson: Sure, but that's also a Very Hard problem to solve. [16:31] Or, can be. [16:31] cjwatson: and we can cherry-pick fixes from Debian easier [16:31] Sometimes, it's easy to match tag->tag with ver->ver and say "yup, these are byte-identical, inject the commits", and sometimes... Not. [16:31] infinity: Also a problem that quite a few people have been working on solving for some time :-) [16:32] And with git it's much easier to get away without being perfect. [16:32] Indeed. nacc being one of them. [16:33] Honestly, I just want to get us to a point in Debian *and* Ubuntu where we can release-from-vcs, but I'm also a hippie free love lover of choice in tooling, which complicates things a lot when you can't say "you must use VCS X in layout Y" [16:34] Having the VCS actually be authoritative would be lovely, but until it is, I knee-jerk when people act as though it is, that's all. [16:35] yeah, the biggest issue i've run into is there is not a canonical (little c) way to do version lookups -- if the maintainer uses dgit without options, i think there is -- but not everyone does [16:36] so we'd need to store all this metadata about the vcs whenever we add a new one (that doesn't follow some standard) and that gets messy [16:36] but it's all on my backburner because what we have is 'good enough' for now [16:36] Yeahp. [16:36] we do have the notion of 'upload tags' as well, which allows ubuntu developers to provide rich history for a given upload to ubuntu [16:36] (we being the usd tooling) [16:36] And I think my pipe dream of anyone being able to upload-from-tag from any VCS and any layout is probably BS, and it'll only work if we impose rigid standards. [16:36] yep [16:37] "dak and LP will scan registered repositories for this exact tag layout on this release branch, and if they find signed tags, you get an upload, if it's not laid out this way, sucketh to be thee" is probably the only way it'll work. [16:40] infinity: yep, that's sort of our plan, i think [16:42] being able to upload-from-tag> I think this is achievable. [16:42] mhm mhm sru-review -s trusty binutils :D [16:43] rbasak: Oh, it's definitely achievable. I was doing in in Maemo almost a decade ago. [16:43] We're almost at the stage where the imported git tree correctly represents canonical archive history. [16:43] * juliank is too excited about this SRU, oddly enough [16:43] juliank: I'm not ignoring you. [16:43] When it does, then we could switch Launchpad to primarily taking uploads from signed tags instead [16:44] infinity: That's wonderful :) [16:44] And to support old workflows, it could accept dputs still but give that to the importer to resolve into a importer-signed tag that it can trust. [16:44] juliank: I mean, I'm also not running the command. But I'm not ignoring you! [16:44] (running the command) [16:45] It's not really very far at all from where we want at the moment, apart from perhaps confidence in reliability. [16:45] from where we *are* at the moment [16:45] juliank: That update-maintainers mangling of control seems superfluous. [16:45] * juliank needs something done before preparing the xenial/yakkety/zesty apt and cracklib2 SRUs [16:45] :D [16:46] infinity: It's from the prev upload, actually [16:46] juliank: Oh, then never mind. [16:47] rbasak: i wonder if `usd build*` needs updating for the .buildinfo files from dpkg? [16:47] rbasak: as well as our wiki pages [16:47] juliank: This fix is amazingly generic. I'm somewhat shocked we never saw the issue on other arches. [16:47] ack [16:47] I've not been following the buildinfo stuff [16:47] rbasak: just based upon infinity's email today [16:47] * rbasak reads up [16:48] rbasak, nacc: do the already existing repositories match the ubuntu uploads? [16:48] rbasak, nacc: i see the bugs with the failed imports [16:48] rbalint: as of when the importer last run, yes [16:48] rbalint: i'm catching them up now [16:48] nacc: great! :-) [16:49] rbalint: and if you need something imported, feel free to ask here [16:49] juliank: My only question now is if we should do this through the security-proposed PPA instead, as this is a regression in security *and* updates. [16:49] mdeslaur: ^ [16:50] infinity: the repo/upload mismatch stats in Debian to support your case :-) https://qa.debian.org/cgi-bin/vcswatch [16:50] Ehm, yes, the last upload already was a no-change rebuild from updates to security [16:51] It might make sense to directly go to security this time around [16:51] On the other hand, I don't really care. I just want to get bash building again :) [16:52] rbasak: also, i had a side idea for a `usd m-o-m` which i think would work (and wouldn't require any of the clone, etc. steps) -- it would just look at the current repo and see if it can do the next merge automatically -- user would still have to verify the diff, history, etc. [16:53] infinity: you want to just build it there but still go through the SRU process? [16:53] It might not even be a security regression, though. It could be just bad luck [16:54] Ehm yes. [16:55] No? [16:55] heh [16:55] that covers all your bases, juliank :) [16:55] It certainly only happens with a new enough glibc as well [16:56] I think what doko wrote is that it worked with -...14, but failed with the no-change rebuild for -security in -14.1 [16:56] unless he downgraded the eglibc. [16:57] But well, as I said, I just want to finally get this bash upload I sponsored last year building :) [16:58] If you want to push it as a -security regression fix, that's your call [17:00] juliank: AFAICT, 14 had the issue, but it was masked until a glibc update. Given that glibc and binutils are both high enough in the security pocket to trip this, I think the SRU also belongs in security. [17:01] mdeslaur: Yeah, that. I'll upload it to security-proposed, then copy it to the archive for regular SRUyness. [17:01] infinity: ack, sounds good [17:23] juliank, current apt sru's should be released soon (i got slangasek on the hook for that later in the day) and we do have sbuild/autopkgtest in unapproved fixing the adt test failures to make future srus less pain. === deltab_ is now known as deltab [17:24] xnox: Wonderful. New SRUs coming soon :) [17:27] juliank: Is there a workaround for bug 1681231? [17:27] bug 1681231 in cracklib2 (Ubuntu Zesty) "package cracklib-runtime 2.9.2-3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Triaged] https://launchpad.net/bugs/1681231 [17:27] bdmurray: dpkg --configure -a and continue? [17:28] bdmurray: I don't really know, but I plan to upload SRUs for that. [17:29] juliank: Okay, I was looking at the bug and somebody had asked how to sort themselves out. [17:30] bdmurray: Does the release upgrader include -updates when doing the upgrade? [17:30] * juliank has no clue about that [17:30] juliank: Hmm, it might only if they are enabled. [17:31] bdmurray: The thing is if we fix this via an SRU; and that's not used, then we can just not fix it [17:32] juliank: It is used, but it doesn't add -updates if people don't have it enabled so we'd want it in -security too. [17:32] Oh dear [17:33] Maybe someone else should do it then. For zesty and yakkety, it's as simple as changing the version in the changelog entry [17:34] This abuse of -security is fun :D [17:48] cpaelzer: rbasak: for `usd merge` -- do you think we should just avoid the need to drop the empty/redundant commits (pocket copies)? [17:48] cpaelzer: rbasak that is, i can drop the flags from our cherry-pick [17:54] nacc: yeah could do. I see no need to keep them. [17:56] rbasak: ack [17:56] cpaelzer: i've updated the workflow wiki for the new `usd merge` subcommands === JanC_ is now known as JanC [18:33] is there a "right way" to do release upgrade testing with -proposed? [18:33] for a specific package fix [18:34] I've always done it with a manual swap of sources.list and dist-upgrade, rather than with do-release-upgrade. I'd love to know if there's a better way too. [18:36] rbasak: good point, will do that for now, though [18:40] rbasak: and if that is the 'right way', then i think we should put it on the wiki somewhere [18:42] It's almost "right". It should work closely enough for most cases, except for stuff that do-release-upgrade does. [18:43] rbasak: yep [19:01] slangasek: xnox: 1.3.6 (yakkety): https://github.com/Debian/apt/compare/1.3.y...julian-klode:1.3.y?expand=1 - 1.2.21 (xenial): https://github.com/Debian/apt/compare/1.2.y...julian-klode:1.2.y?expand=1 [19:02] I think they are actually the same diff... [19:02] I can create an additional bug to track the parts not explicitly covered by an LP bug yet, if preferred [19:03] (These are one word / one line added, though) [19:04] xnox: I assume we can actually drop the config change for xenial, you said the problem with spaces in dirnames and apt-key in bug 1672710 only happens in yakkety [19:04] bug 1672710 in apt (Ubuntu Yakkety) "apt fails to verify keys when Dir has space, and set via cmdline" [High,Triaged] https://launchpad.net/bugs/1672710 [19:06] But then again, maybe something else uses that, and it does create invalid config files it can't read back, so it's probably good to keep it in [19:07] And zesty just gets the current version re uploaded with ~17.04.1 appended [19:22] CI passed [19:22] So I'm ready to go :) [20:50] juliank, re:spaces yes because xenial uses old gpg and old apt-key and it handles spaces correctly i believe. [20:50] juliank, push the button. [20:52] Rockets launching in about a minute [20:55] Rockets launched. [20:56] xnox: All rockets reached their unapproved queue [20:56] queues, even [20:57] * xnox shakes fist at the queue [20:57] Launching rockets at launchpad, nice. [20:57] Unit193: Yeah, they parked now but will be relaunched their :D [20:58] xnox: That was the record for mass APT releasing === _salem is now known as salem_ === salem_ is now known as _salem [21:01] xnox: I can say one thing: Ubuntu really needs more people who can approve stuff :) [21:02] or rather :( [21:02]