[02:48] <tsimonq2> is there a list of packagesets and packages that belong to those packagesets somewhere?
[02:49] <tsimonq2> I also wonder if I can use the Launchpad API to look at that...
[05:52] <pitti> Good morning
[05:52] <Unit193> Howdy.
[05:53] <pitti> apw: FYI, I reopened bug 1626436, -17 still boots a lot slower than 4.4 and with high loads; although a lot less severe than the previous -14
[06:07] <didrocks> good morning pitti!
[06:10] <pitti> bonjour didrocks, ça va ?
[06:12] <didrocks> pitti: ça va bien, et toi ? :)
[06:13] <pitti> didrocks: je vais bien aussi; salutations de Berlin, je reste chez larsu :)
[06:13] <didrocks> pitti: oh, c'est vrai ! Dis-lui bonjour de ma part :)
[06:14] <pitti> didrocks: je vais le faire, merci ! (il encore dort)
[07:52] <pitti> happyaro1, cyphermox: I didn't get around to creating a NetworkManager DNS plugin for resolved this cycle, got diverted by too many other things; at this point I'd just revert NM back to using dnsmasq, like we had before; is that ok for you?
[10:51] <tsimonq2> pitti: morning, could you please take another look at https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html ?
[10:51] <tsimonq2> (afair you said you would take a look today)
[11:06] <sil2100> cjwatson_: hey! I was wondering - there's such a strange situation we have right now in -proposed, ubuntu-keyboard 0.100+16.10.20160921-0ubuntu1 is there but the binary for ubuntu-keyboard-data for this version is not, even though it was not removed or anything
[11:06] <sil2100> cjwatson_: tested in an yakkety-proposed amd64 chroot with apt-cache policy and even launchpad acts strangely here
[11:07] <sil2100> https://launchpad.net/ubuntu/yakkety/+package/ubuntu-keyboard-data <- this only shows the old version
[11:07] <sil2100> https://launchpad.net/ubuntu/yakkety/+package/ubuntu-keyboard <- while here's the main ubuntu-keyboard binary from -proposed
[11:07] <sil2100> cjwatson_: do you know what could be the cause of it?
[11:07] <sil2100> cjwatson_: does it mean someone removed the binaries from -proposed?
[11:10] <cjwatson_> https://launchpad.net/ubuntu/yakkety/amd64/ubuntu-keyboard-data is more useful
[11:11] <cjwatson_> that says it was superseded by ubuntu-keyboard 0.100+16.10.20160921-0ubuntu1
[11:11] <cjwatson_> er, wait, what
[11:11] <cjwatson_> this may have been a race of some kind, let me dig through logs a bit
[11:11] <sil2100> Strangeness I see, 0.100+16.10.20160921-0ubuntu1 should have ubuntu-keyboard-data but it doesn't, even though on the LP build page I see it being generated
[11:12] <sil2100> This also basically blocks ubuntu-keyboard and unity8 in -proposed
[11:12] <sil2100> Since, yeah, the autopkgtests can't run since it can't install ubuntu-keyboard-data for the -proposed ubuntu-keyboard, since the binaries are not there! ;)
[11:13] <cjwatson> there are two copy records here which suggests something like a double-override accident
[11:14] <sil2100> uh, sounds scary
[11:15] <sil2100> Thanks for looking into that!
[11:16] <Mirv> @pilot in
[11:17] <cjwatson> certainly seems to have been copied rather a lot
[11:17] <cjwatson> celeryd-production_launchpad_job.log-20160923.gz:[2016-09-22 15:37:07,396: INFO/Worker-1] Running <PlainPackageCopyJob to copy package ubuntu-keyboard from ~ci-train-ppa-service/ubuntu/1974, RELEASE pocket, in ubuntu yakkety to ubuntu, PROPOSED pocket, in ubuntu yakkety, including binaries> (ID 33200448) in status Waiting
[11:17] <cjwatson> celeryd-production_launchpad_job.log-20160923.gz:[2016-09-22 22:45:27,787: INFO/Worker-2] Running <PlainPackageCopyJob to copy package ubuntu-keyboard from ~ci-train-ppa-service/ubuntu/1974, RELEASE pocket, in ubuntu yakkety to ubuntu, PROPOSED pocket, in ubuntu yakkety, including binaries> (ID 33204726) in status Waiting
[11:17] <cjwatson> celeryd-production_launchpad_job.log-20160924.gz:[2016-09-23 23:46:15,121: INFO/Worker-1] Running <PlainPackageCopyJob to copy package ubuntu-keyboard from ~ci-train-ppa-service/ubuntu/1974, RELEASE pocket, in ubuntu yakkety to ubuntu, PROPOSED pocket, in ubuntu yakkety, including binaries> (ID 33200448) in status Waiting
[11:17] <cjwatson> celeryd-production_launchpad_job.log-20160924.gz:[2016-09-23 23:46:16,081: INFO/Worker-3] Running <PlainPackageCopyJob to copy package ubuntu-keyboard from ~ci-train-ppa-service/ubuntu/1974, RELEASE pocket, in ubuntu yakkety to ubuntu, PROPOSED pocket, in ubuntu yakkety, including binaries> (ID 33204726) in status Waiting
[11:18] <sil2100> Oh!
[11:18] <sil2100> I think I was doing the copy, and I remember that it hanged on the last package
[11:18] <sil2100> Like, the copy-package script
[11:18] <sil2100> I think I aborted and re-run again, but that should cause 2 copies at max I guess?
[11:19] <sil2100> Since the bileto publish job was busted I had to publish some packages manually through copy-package
[11:19] <cjwatson> the first two of those copies were suspended, i.e. held in UNAPPROVED
[11:19] <sil2100> (I feel so bad since it might have been me that busted things)
[11:19] <cjwatson> so I think you did a double copy, both ended up in the queue
[11:20] <cjwatson> then when they were accepted, two copies of the same package were accepted simultaneously (literally - two celery workers were processing those two copies in parallel)
[11:20] <cjwatson> and our locking isn't always what it could be
[11:20] <cjwatson> so, easy to fix, I'll just copy it over itself
[11:22] <cjwatson> done, should hopefully sort itself out in a bit
[11:23] <sil2100> cjwatson: thanks!
[11:24] <sil2100> Sorry for the commotion, I didn't know if the first run copied everything since it seemed hanged so I preferred to just do a second copy, as I didn't expect it to cause two entries in UNAPPROVED
[11:24] <sil2100> Now I know it's not so low-risk as I thought it is
[11:54] <ogra_> oh man ...
[11:55]  * ogra_ has a failed 14.04 -> 16.04.1 server upgrade and in the middle of sending the error report lp goes down ... 
[11:55] <ogra_> must be my lucky day
[11:58] <ogra_> sigh
[11:58] <Laney> no bug here, move along
[12:01] <ogra_> oh man
[12:01] <ogra_> ogra@aleph:~$ sudo reboot
[12:01] <ogra_> sudo: reboot: command not found
[12:01] <ogra_> that ugrade went *really* wrong
[12:02] <ogra_> (it tried to do a lot of insserv stuff, re-ordering sysv scripts and so on ... )
[12:07] <ogra_> hmm, not even remotely a trace of systemd on that machine ...
[12:07] <ogra_> thats rather unexpected ... specifically since i used do-release-upgrade
[12:12] <Laney> Anyone know of a dpkg gotcha when replacing directories with symlinks? https://paste.debian.net/841984/
[12:12] <Laney> It becomes an empty directory instead of a symlink
[12:13] <Laney> Do I have to do it in postinst?
[12:14] <jamespage> Laney, I think there is a helper todo that
[12:14] <cjwatson> Laney: Yep, that's standard.  dpkg-maintscript-helper can help
[12:14] <cjwatson> (via dh_installdeb, probably)
[12:14] <cjwatson> dir_to_symlink
[12:14] <Laney> aha
[12:14] <Laney> Not sure I've come across this particular one before
[13:09] <Mirv> sil2100: are you landing the ubuntu-touch-meta part of bug #1625023 ? (asking with my patch pilot hat on)
[13:14] <cyphermox> pitti: no objections
[13:19] <Mirv> @pilot out
[13:23] <sil2100> Mirv: yeah, I'm on it
[13:24] <sil2100> Mirv: for now no action required there, we'll do the switch in the nearest days
[13:28] <Mirv> sil2100: ok
[13:41] <ogra_> oh sigh
[13:42]  * dholbach hugs Mirv 
[13:42] <ogra_> pitti, so i just had my server eat itself completely doing a 14.04->16.04.1 do-release-upgrade ... i now have a ton of insserv complaints every time i use apt ... systemd wasnt installled at all ... grub ended up with only memtest in it ...
[13:42] <ogra_> pitti, can i just purge insserv ? iirc we dont need it
[13:42] <ogra_> (i just manually installed grub and systemd so i got at least back to ssh support)
[13:43]  * ogra_ thinks that was the worst ubuntu expirience he had yet ... just using official tools :(
[13:50] <pitti> ogra_: hm, you can purge insserv in 16.10, but not yet in 16.04; what did it say? some broken sysv script somewhere without LSB headers?
[13:50] <ogra_> pitti, about 200 lines every few seconds ...
[13:50] <ogra_> yeah, LSB header noise
[13:51] <ogra_> now that i got back to a working system (after installing grub by hand from an old 11.04 CD i had around since mini.iso from USB was to new for the BIOS on that old iron) i just noticed that dist-upgrade wants to still upgrade ~600 packages
[13:52] <ogra_> so i guess the insserv thing was caused by a half upgraded system ... i'll see that i get to normal first
[13:52] <ogra_> still pretty bad that do-release-upgrade can get you into such a state
[14:07] <pitti> Launchpad, where are thou
[14:20] <caribou> This may sound as a silly question, but what is the normal procedure to generate a _sources.changes file for a debian native package ? dpkg-genchanges -S ?
[14:22] <LocutusOfBorg> caribou, yes, I do that usually
[14:22] <LocutusOfBorg> actually -S -d
[14:22] <LocutusOfBorg> :)
[14:22] <LocutusOfBorg> and -sa when needed
[14:23] <caribou> LocutusOfBorg: good, thanks!
[14:23] <LocutusOfBorg> yw!
[14:24] <Mirv> sitter: note that this is coming from snappy newbie who is mostly having fun and learning the tool, but I started with https://github.com/tjyrinki/qt-ubuntu and it's available in edge channel (just not sure if any useful at the moment for anything). my main wish is to have a snap that contains the Qt as known in Ubuntu world (hence, "qt-ubuntu"), with all the patches we've wanted to cherry-pick or
[14:24] <Mirv> backport for our products.
[14:24] <cjwatson> pitti: network failure
[14:25] <ogra_> stuck in the cable ?
[14:28] <sitter> Mirv: seems reasonable. for KDE the current plan (really just vision) is to have an own Qt though to tighter control patches etc.
[14:30] <Mirv> sitter: right, mine can also be called mostly a vision at the moment. it's really up to how will the eventual needs seem to be - snap does allow a lot of flexibility in all directions, meaning not everyone needs to use the common one, but still eg snapcraft work can be shared
[14:31] <sitter> Mirv: agreed
[14:46]  * ogra_ glares at his sever removing config files for usplash 
[14:47] <ogra_> hmm, i knew this install was old ... i wasnt aware *how* old actually
[15:00] <bdmurray> flexiondotorg: Is there a reason you mark bugs like bug 1601874 as Incomplete?
[15:01] <rbasak> !dmb-ping
[15:12] <flexiondotorg> bdmurray, When LP comes back I'll take a look.
[16:05] <ogra_> oooh ... LP is back (at least for the bug i just reloaded)
[16:06] <pitti> -ish (slow, but stuff is coming through)
[16:18] <pitti> smoser:
[16:18] <pitti> +Before=NetworkManager.service
[16:18] <pitti>  Before=network-pre.target
[16:18] <pitti> smb: that's a no-op and looks like some red herring
[16:19] <pitti> smb: ifupdown, NM, networkd, and similar things all run after network-pre.target (that's its purpose)
[16:19] <smb> smoser, ^
[16:19] <pitti> sorry, smoser ^
[16:20] <smoser> pitti, added for redhat
[16:20] <smoser> as you say, shoudl be a noop
[16:20] <smoser> right?
[16:21] <pitti> smoser: oh, is their NM not doing After=network-pre.target?
[16:22] <smoser> i think that network-pre.target is an ubuntu-ism, no?
[16:22] <pitti> no
[16:22] <pitti> both the target and NM.service are the upstream units
[16:22] <pitti> we don't have ubuntu specific targets
[16:23] <pitti> (well, in the systemd package -- obviously there are some from packages like cloud-init)
[16:24] <smoser> hm..
[16:24] <smoser> pitti, how'd you see this ?
[16:24] <pitti> smoser: doing yakkety unapproved queue review
[16:25]  * pitti felt like some punishment in the evening before dinner :)
[16:25] <pitti> also, the DC is coming back, so catching up with stuff
[16:25] <smoser> yea
[16:27] <pitti> smoser: so, as this shuldn't be different in RH I was just curious what it should do, and if there maybe is some "real" bug somewhere
[16:28] <smoser> pitti, want to join #cloud-init and see if harlowja will respond ?
[16:28] <smoser> he is who did this, and uses cent.
[16:29] <pitti> smoser: done; I'll be AFK for dinner RSN, but I'll get backscroll
[17:07] <nacc> coreycb: fyi, ftfbs from doko's last e-mail for cinder, I think it's because you need a build-dep on python-pep8 or python3-pep8 for the tests?
[17:07] <nacc> coreycb: https://launchpadlibrarian.net/285536781/buildlog_ubuntu-yakkety-amd64.cinder_2%3A9.0.0~b2-0ubuntu1_BUILDING.txt.gz
[17:24] <coreycb> nacc, I think that is fixed by rc1 which is in proposed
[17:25] <nacc> coreycb: ack, thanks!
[17:29] <coreycb> nacc, yw, it is great when things are already fixed :)  btw that is stuck in proposed based on a few dependencies we're fixing up.
[17:31] <nacc> coreycb: np, i'm just trying to keep an eye on the  ubuntu-server ftbfs list
[17:53] <smoser> pitti, i would like your opinion on https://bugs.launchpad.net/ubuntu/+source/gce-utils/+bug/1627789
[18:09] <nacc> doko: for the ftbfs for libecap, i think the 3 symbols mentioned in https://launchpadlibrarian.net/285536159/buildlog_ubuntu-yakkety-i386.libecap_1.0.1-3ubuntu3_BUILDING.txt.gz (same for all the arch's build logs) are no longer present. `pkgkde-symbolshelper` parsing the build-log as input does seem to want to just elide those 3 -- but I'm inexperienced in this area?
[18:10] <bdmurray> flexiondotorg: so about bug 1601911 - why is it incomplete?
[18:12] <flexiondotorg> bdmurray, Reagarding 1601874 you mentioned ealier, it is from an old package from a PPA.
[18:14] <flexiondotorg> As for 1601911, I've never encountered it and can't reproduce it.
[18:16] <bdmurray> flexiondotorg: bug 1601874 also occurered with version 16.04.9.1 which is the Xenial version of the package...
[18:18] <bdmurray> flexiondotorg: I'm trying to understand why you marked a whole bunch of crash reports from the Error Tracker as Incomplete.  Its hard to tell just based off the bug.
[18:19] <flexiondotorg> bdmurray, The rationale for marking those bugs incomplete is we've spent about 5 days testing Ubuntu MATE Welcome.
[18:19] <flexiondotorg> The version in Xenial and the version we've been preparing for Yakkety.
[18:20] <flexiondotorg> None of the team were able to excercise Ubuntu MATE Welcome is such a way to cause those errors :-(
[18:21] <bdmurray> flexiondotorg: and what about engrampa or atril? e.g. this crash with 340 instances https://errors.ubuntu.com/problem/bf4ee7bcedb2e9da402d6486d69fe3cf5fc783f7
[18:26] <flexiondotorg> bdmurray, I just requested access errors.ubuntu.com
[18:26] <bdmurray> flexiondotorg: Maybe we should mark the bugs as New then, rather than causing them to expire in 60 days?
[18:27] <flexiondotorg> bdmurray, Can you help me understand the correct way to interact with bugs I can't reproduce please?
[18:27] <flexiondotorg> OK, I can mark them New.
[18:28] <bdmurray> flexiondotorg: I think the first step would be to look at the crashes, let me give you access to errors.
[18:29] <bdmurray> flexiondotorg: Can you access this now? https://errors.ubuntu.com/problem/bf4ee7bcedb2e9da402d6486d69fe3cf5fc783f7
[18:30] <flexiondotorg> Yes. Excellent!
[18:31] <bdmurray> flexiondotorg: So we can see a Stacktrace there which has details.  Those don't get put in the bug report since it might contain sensitive information.
[18:31] <bdmurray> flexiondotorg: If you look at the Occurences table there are links to the individual crash reports e.g. https://errors.ubuntu.com/oops/2da4c81a-8358-11e6-8a94-fa163e30221b
[18:32] <bdmurray> flexiondotorg: That contains the apport crash report information like ProcCmdline which might be useful in recreating the crash
[18:32] <flexiondotorg> bdmurray, Thanks, this is great.
[18:33] <bdmurray> flexiondotorg: the version table can also be useful in determining which releases are affected, however just because you don't see it affecting Yakkety doesn't mean it won't.  There aren't a lot of yakkety users yet.
[18:33] <flexiondotorg> I thought I'd registered for errors before but that just let me manipulate the graphs.
[18:34] <bdmurray> That doesn't require any special permissions.
[18:39] <bdmurray> flexiondotorg: if you have any questions about the error tracker or feedback please let me know
[18:39] <flexiondotorg> bdmurray, Will do.
[18:46] <nacc> doko: looking at libpam-radius-auth ftbfs, but i'm not able to reproduce it.
[19:12] <nacc> doko: nm, PEBKAC for libpam-radius-auth, would still appreciate your input on libecap
[19:17] <nacc> doko: http://paste.ubuntu.com/23234756/ for libpam-radius-auth, does it look sane?
[19:27] <doko> nacc: I'll NMU that to Debian too, fabbione package ...
[19:27] <nacc> doko: ok
[19:28] <nacc> doko: so you'll handle both libpam-radius-auth and libecap?
[19:29] <doko> nacc: libecap, yes these destructor symbols are not part of the ABI
[19:29] <nacc> doko: ack
[19:31] <doko> nacc: are you able to upload libecap yourself? Not sure why we don't see that in Debian
[19:32] <nacc> doko: yeah, i can
[19:32] <nacc> doko: i just wanted to check with you first
[19:37] <nacc> doko: http://paste.ubuntu.com/23234825/ ? also, do you normally file a bug for every ftbfs so it's clear what the failure was?
[19:39] <doko> nacc: for Ubuntu? no, I gave up on this, because these bugs are then not rracked. maybe we should do that again for main for every package
[19:40] <nacc> doko: i have been filing them for myself so i have a place to link the logs
[19:40] <nacc> just wasn't sure if there as a 'best practice' already
[19:46] <doko> nacc, ahh, libecap in debian doesn't have symbols file ...
[19:46] <nacc> doko: yeah, i just realized it's a delta
[19:46] <nacc> doko: did the above debdiff seem reasonable?
[19:47] <nacc> i can upload now, if so
[19:53] <nacc> doko: i noticed that with libpam-radius-auth, it's orphaned in debian and we're on a different upstrema there too
[19:53] <jbicha> nacc: if you use the LP tag 'ftbfs', the bug will show up on http://qa.ubuntuwire.org/ftbfs/
[19:54] <nacc> jbicha: yep, i realized that last night, so i've been modifying them :)
[20:00] <nacc> doko: presuming you ack, i can upload both libecap and libpam-radius-auth for yakkety
[20:18] <nacc> doko: ok, llvm-toolchain-3.6 now :) -- seems like gcc 6.1/6.2 isn't provide gcc-6.1/gcc-6.2, but gcc-6? so do we need to adjust that regex to be 5|6?
[20:18] <nacc> http://paste.ubuntu.com/23234972/
[20:51] <pitti> smoser: LP is oopsing on me again -- I guess I'll have a look tmw morning then
[20:51] <smoser> pitti, fair enough
[20:51] <smoser> thanks
[20:52] <pitti> smoser: hmm, https://launchpad.net/ works, but https://launchpad.net/bugs/1627789 oopses
[20:52] <pitti> smoser: can you open it?
[20:53] <smoser> no. it had worked earlier today
[20:53] <smoser> interestingly, the private one works :)
[20:54] <pitti> smoser: https://bugs.launchpad.net/ubuntu/+source/gce-utils/+bug/1627789/+text also works -- I just cannot comment on that
[20:56] <pitti> smoser: looks ok to me; probably all the cloud-init-ish stuff should perhaps rather be installed into cloud-init.target than multi-user, but surely fine for an SRU
[20:58] <smoser> pitti, right, but i think they want to run even if cloud-init is not present.
[20:59] <pitti> smoser: oh, ok; then that looks right
[22:14] <doko> nacc: isn't 3.6 already fixed in Debian, and can be merged? but yes, this should be fixed the same way as in newer llvm's
[22:44] <nacc> doko: i'll check
[22:45] <nacc> doko: we're already merged to current llvm-toolchain-3.6 in debian
[22:45] <nacc> afaict
[23:29] <nacc> doko: it's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835582
[23:36] <nacc> doko: fyi, +1 on the idea of auto-opening ftbfs bugs for packages in main
[23:45] <lfaraone> is there anything I can do to help LP #1571456 (xenial SRU for glibc) get looked at? (waves at infinity :))
[23:52] <Odd_Bloke> barry: doko: Any idea what the status of bug 1443704 is?
[23:55] <doko> nacc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838945
[23:55] <doko> so once applied, this is syncable
[23:55] <nacc> doko: ack, i'll watch for it
[23:56] <nacc> doko: i went ahead and submitted the small patch for now, i hope that's ok -- and we can presumably sync once debian is updated
[23:56] <doko> barry: dropped, because I never had the time to finish it. feel free to pick it up again, but then maybe with the package/version from xenial
[23:57] <doko> Odd_Bloke: ^^^
[23:58] <nacc> doko: mako is a debian bug as well (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830178)
[23:59] <Odd_Bloke> doko: I'm asking for someone else at a sprint; what approach were you taking to make it work?