[00:06] <TheMuso> c
[00:06] <Unit193> d
[00:13] <TheMuso> :)
[00:37] <TheMuso> B/c
[00:37] <TheMuso> gah there I go again. :
[04:37] <pitti> Good morning
[06:12] <Unit193> didrocks: There you are!  Did you by chance ever poke Debian with http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/xorg/wily/revision/189?
[06:13] <didrocks> Unit193: IIRC, I did this when we introduced this all session stuff, but there was no traction on the debian side (it was covering too many components to have an widespread agreement)
[06:14] <Unit193> Dang, that really stinks.  Thanks for trying though.  (Was recently looking at why it all wasn't working, had to ship that file another way.)
[06:16] <didrocks> Unit193: I think they will see the value in that one day, maybe now would be better as we have multiple environments based on the same component (compared to the fact that it was only Unity at the time…)
[06:17] <Unit193> It's also nicer in that you can easily ship different default config without clobbering or diverting.
[06:19] <didrocks> indeed
[06:25] <dholbach> good morning
[07:01] <pitti> cjwatson, wgrant, infinity: I noticed that despite LP doing ddebs now, the buildds still create ddebs.txt indexes with the ddebs, and we additionally pull them in the old way
[07:02] <wgrant> pitti: Yeah, I thought I'd disabled that, but apparently misremembered 2009 a little.
[07:02] <pitti> do we still have any release where ddebs are *not* built using LP? in other words, can we retire the apaches and parsing ddebs.txt now, or do we still need that for anything?
[07:02] <wgrant> pitti: It'll all go away soon when we upgrade sbuild.
[07:03] <wgrant> (new sbuild will roll out to scalingstack this week, then we'll do a main test rebuild before rolling it out to non-virts)
[07:03] <pitti> it just seems brittle to download them twice
[07:03] <wgrant> Right, I'd disable the apache download path now and see if anyone whinges.
[07:04] <pitti> ok
[07:08] <pitti> cjwatson: why does ddeb_retriever.py call lpinfo.get_binary_publications() without the real_threshold arg?
[07:08] <pitti> cjwatson: testing leftover?
[07:09] <pitti> cjwatson: or on purpose? There's a loop afterwards to filter the recent ddebs manually
[07:17] <pitti> wgrant: LP ddebs are on for RTM too?
[07:18] <wgrant> pitti: Yep (I originally missed their primary archive, but Colin turned it on a week or two ago)
=== oSoMoN_ is now known as oSoMoN
[08:37] <rbasak> backportpackage currently doesn't call update-maintainer. Should it? https://wiki.ubuntu.com/DebianMaintainerField suggests to me that it should.
[08:37] <rbasak> (for when preparing an Ubuntu upload)
[08:39] <pitti> utlemming: can you please set up the /current symlink on http://cloud-images.ubuntu.com/wily/ ?
[08:48] <infinity> rbasak: Not if it's a no-change backport, IMO.
[08:50] <infinity> rbasak: Although, apparently my opinion doesn't mesh with the vote from 2006. :P
[08:59] <infinity> rbasak: Anyhow, it's a spirit of law and letter of law thing.  We tend to never change Maintainer (in the source) on a rebuild, since the source didn't change except adding a changelog entry.  We always change maintainer on binaries, but that's not something that requires action from you.
[09:00] <infinity> rbasak: So, in my mind, we're doing the right thing on a no-change backport by not changing the maintainer in the source too, but one could argue either way, based on the poor wording of the ballot options 9 years ago. :P
[09:01] <rbasak> infinity: well I can't be bothered to patch backportpackage, so I'll do it your way :)
[09:01] <smb> infinity, Today my Trusty install offered to try removing grub-efi-amd64-signed for some reason. Is that again a mess up on my part somehow?
[09:03] <infinity> smb: Are you running with -proposed on?
[09:03] <smb> Yes, do get things early on
[09:04] <infinity> smb: Right, that's why probably, cause signed hadn't been uploaded to match.
[09:05] <smb> infinity, Ok, thanks. Was suspecting that. So I just delay the update until later
[09:05] <infinity> smb: Lemme fix that right now, since I can't sleep.
[09:06] <smb> infinity, Thanks... though maybe you better tried counting penguins... or so...
[09:11] <infinity> cyphermox: Fixed for you this time, but do remember to update grub2-signed after a grub2 upload.
[09:11] <infinity> smb: Should be happy in 30m or so.
[09:11] <smb> infinity, \o/ Thanks again
[09:13] <cjwatson> pitti: The created_since_date argument to lpinfo.get_binary_publications is a leftover from an earlier query strategy and is currently unused.  I suppose we could go back to passing it, but I haven't tested the query with that included and it's easy enough to test later.  It means we fetch a few more publications than we need, but only up to the end of the current batch.
[09:14] <cjwatson> pitti: It would probably be OK to add it, but test that the query still performs reasonably.
[09:14] <pitti> cjwatson: ah, this looks like it would currently iterate over all builds, ever
[09:15] <cjwatson> pitti: No
[09:15] <pitti> and thus get slower over time?
[09:15] <cjwatson> pitti: It's batched
[09:15] <pitti> cjwatson: ah, then nevermind
[09:15] <cjwatson> pitti: You get the first 75 until you ask for the next 75, etc.
[09:15] <cjwatson> I *have* performance-tested the current set of queries :-)
[09:16] <cjwatson> It might be a slight optimisation to let it cut the batch off a bit earlier, but I should confirm.
[09:17] <pitti> cjwatson: ah, I'm not worried about that at all; I just wondered if this wouldn't traverse years of builds each time
[09:17] <pitti> thanks for clarifying! I didn't take the dynamic nature of these lists into account
[09:25] <infinity> smb: All built and published.  Once your mirror finishes its next update pulse, life should be back to normal.
[09:27] <smb> :) Ok, well should be the main archive mirrored locally by apt-cacher-ng. But I probably give it a few minutes regardless
[09:38] <cjwatson> pitti: OK, I've confirmed that the query has exactly the same plan either way (which makes sense, datecreated is in the index it's already using for ordering, but I wanted to make sure), so pushed a change to pass created_since_date.
[09:39] <pitti> cjwatson: thanks! looks less confusing that way indeed
[09:39] <cjwatson> pitti: (and deployed on germanium)
[09:40] <pitti> cjwatson: FTR, I'm doing a run with rebuilding the db, at least some utopic ddebs got a wrong checksum
[09:40] <pitti> in case you wonder why it's taking so long
[09:40] <pitti> db5.1_dump seems fairly useless for actually changing values in the db
[09:41] <pitti> and occasionally we should clean it up anyway, especially after dropping a release (lucid)
[09:41] <infinity> pitti: Cleanups should happen properly if you do the same thing we do in LP.  But if you had a format break or whatever, a rebuild is necessary, yes.
[09:42] <smb> infinity, ok, we have normality :)
[09:42] <infinity> smb: \o/
[09:43] <pitti> infinity: Colin and I actually tried that, and it stumbled over some DB corruption
[09:43] <pitti> infinity: so, another reason for rebuilding it :)
[09:43] <infinity> pitti: I would assume that means the DB was already broken.
[09:43] <pitti> infinity: but in principle we have a config now for cleaning it up
[09:43] <infinity> pitti: I meant, in the future, once they're known-good, doing the LP cleanup thing should be enough.
[09:43] <pitti> infinity: exactly
[09:45] <cjwatson> pitti: OK
[09:46] <cjwatson> pitti,infinity: Well, although I fixed the DB format-level corruption, a cleanup also didn't actually reduce the size of the ddebs DBs much.
[09:46] <cjwatson> So I decided not to spend much effort on that.
[09:46] <pitti> cjwatson: I'm hoping that it does shrink now that lucid got removed
[09:47] <infinity> cjwatson: A badly-corrupted bdb file can end up with a lot of dead space that can't be recovered.  It's possible it was just too far gone.
[09:47] <infinity> With fresh caches, the a-f cleanup should DTRT.
[09:47] <infinity> It certainly has been working on ftpmaster for years now.
[09:50] <rbasak> infinity: so, these Docker backports. A couple of packages have had their source packages renamed (s/-dev$//) since Trusty. Previously I think jamespage renamed them back when backporting to Trusty. Is this necessary? I have 25 backports to track now, so it'd be a bit easier if I didn't have to manually rename anything.
[09:50] <cjwatson> infinity: Could be, yes.
[09:50] <rbasak> The binary package name (there's only one in each case) hasn't changed.
[09:58] <infinity> rbasak: If it's something you're going to have to do again, scripting it would help.
[09:58] <infinity> rbasak: But, generally, I'd say keeping with the same names as trusty for things that already exist is correct, and using new names for new packages is fine.
[09:58] <rbasak> infinity: I'm already scripting 25 calls to backportpackage. I want to save myself the trouble of scripting the rename unless I have to do it.
[09:58] <rbasak> infinity: OK. I'll do the renames.
=== Riddell_ is now known as Riddell
[10:10] <cjwatson> Unit193,infinity: So, as of germinate 2.20 (uploaded to unstable), germinate has git support.  Would it be worth my while preparing a history conversion of all the relevant things?
[10:11] <cjwatson> The way I've structured it means that each flavour will get a separate repository (which makes sense for separate ownership/ACLs etc.) but each series will just be a branch within that repository.
[10:15] <infinity> cjwatson: Wouldn't hurt my feelings if you did.  And that layout sounds correct to me.
=== oSoMoN_ is now known as oSoMoN
[10:47] <zyga> ogra_: hey, do you know (by any chance) why nexux 7 shuts down if left unused for a while (with full battery)
[10:47] <ogra_> zyga, nope, havent touched any tablet in a yeah
[10:47] <ogra_> *year
[10:47] <zyga> ogra_: thanks
[10:48] <ogra_> probably popey knows more, i know he still has a flo in use sometimes
[10:48] <zyga> popey: ^^ any idea?
[10:48] <popey> hmm?
[10:48] <zyga> popey: (use case: charged flo, idle, leave on desk for a day, it will shut down, you can turn it back on again, has lots of power left)
[10:49] <popey> not seen that, but my flo has been in a bag, switched off, for a few weeks
[10:49] <zyga> my suspicion is some kernel crash that just turns the device off
[10:50] <zyga> that doesn't happen if the device is plugged in to a computer
[10:51] <infinity> zyga: If it doesn't happen when it's plugged in, it sounds more likely that it's going a bit nutty and thinking the battery is either not present or flat, just long enough to make it shut down.
[10:52] <infinity> zyga: Which wouldn't happen when it's plugged in, since, well, no need for a bettery when on external power.
[10:52] <infinity> Nor a battery...
[10:52] <zyga> infinity: ah, perhaps I could log upower activity then
[10:53] <ogra_> zyga, if it is plugged in it will always hold a wakelock
[10:53] <ogra_> (read: it never really goes to sleep)
[10:55] <ogra_> zyga, after it crashed immediately boot into recovery and check /proc/last_kmsg ... that holds dmesg of the last boot and probably reveals something
[11:01] <zyga> ogra_: ah, thanks for the tip!
=== benedikt_ is now known as Guest64809
=== _salem is now known as salem_
=== salem_ is now known as _salem
[12:48] <mitya57> pitti: hi, can you please retry wily-adt-php-react-promise on amd64?
[12:48] <pitti> mitya57: done
[12:48] <mitya57> thanks!
=== oSoMoN_ is now known as oSoMoN
[13:05] <pitti> mitya57: FYI, it just exploded some more, CI is on it
[13:08] <mitya57> Yes, I see that something got wrong
[13:16] <pitti> mitya57: all good now
[13:44] <seb128> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
[13:47]  * dholbach hugs seb128
[13:47]  * seb128 hugs dholbach back
[13:48] <seb128> Riddell, hey, could you look at https://launchpad.net/bugs/1455990 ? seems like the Debian package doesn't specify the rsa key length, not sure why the Ubuntu one does (it's not mentioned in the changelog it seems)
[13:48] <ubottu> Ubuntu bug 1455990 in quassel (Ubuntu) "quassel-core generates an insecure certificate upon installation" [Undecided,New]
[13:55] <seb128> grrr launchpad keep timeouting, can't comment on that bug
[13:57] <mitya57> pitti: Great, thanks again! A big list of packages including my sphinx-rtd-theme now migrated :)
=== oSoMoN_ is now known as oSoMoN
[14:19] <pitti> infinity: do you mind if I steal your sysvinit merge? this needs to happen in lockstep with merging util-linux, as some of the tools moved
[14:54] <seb128> smoser, hey, are you still looking at https://code.launchpad.net/~niedbalski/ubuntu/vivid/curtin/fix-1263181/+merge/250163? you wrote that you would take another look but seems you didn't?
[14:56] <seb128> kirkland, hey, do you think you could review https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940 ?
[14:56] <ubottu> Ubuntu bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New]
[14:57] <seb128> dholbach, do you feel strongly about the old changelog entries on https://bugs.launchpad.net/ubuntu/+source/openstack-pkg-tools/+bug/1455985 ?
[14:57] <ubottu> Ubuntu bug 1455985 in openstack-pkg-tools (Ubuntu) "Merge openstack-pkg-tools 24 (main) from Debian unstable (main)" [Wishlist,Confirmed]
[14:58] <dholbach> seb128, no, not very - I just thought they might be good to have
[14:58] <seb128> dholbach, well, I usually just drop them as well on desktop merges, but I know some people seem to care that's why I'm asking
[14:59] <seb128> I'm just going to upload if you don't say me to not :-)
[14:59] <dholbach> seb128, I know you do - I remember ;-)
[14:59] <dholbach> feel free to upload
[14:59] <seb128> dholbach, in practice we could have synced the package and then needed a change again
[14:59] <seb128> and we wouldn't have reapplied the old changelog entries doing that
[14:59] <seb128> dholbach, k, doing that then
[15:05] <seb128> slangasek, hey, could you review https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1314095 or recommend somebody know about pam who could? (that's a SRU request waiting in the sponsoring queue since february)
[15:05] <ubottu> Ubuntu bug 1314095 in nss-pam-ldapd (Ubuntu) "Unity Lockscreen in 14.04 can't unlock when using LDAP account" [Undecided,Confirmed]
[15:07] <seb128> cyphermox, hey, https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141 ... did you plan to upload the SRUs as well?
[15:07] <ubottu> Ubuntu bug 1401141 in isc-dhcp (Ubuntu Vivid) "DHCP server does not work for IPoIB (Infiniband)" [Undecided,Confirmed]
[15:09] <seb128> hallyn_, hey, about https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/1445036 ... do you plan to review the debdiff more/handle the update/sponsoring?
[15:09] <ubottu> Ubuntu bug 1445036 in libcgroup (Ubuntu) "Please merge libcgroup 0.41-6 (universe) from Debian testing (main)" [Undecided,Confirmed]
[15:14] <seb128> jdstrand, hey, could somebody from the security team review https://code.launchpad.net/~tiagosh/ubuntu/wily/telepathy-mission-control-5/allow-getprop-execution/+merge/259174 ?
[15:17] <infinity> pitti: Go nuts.
[15:24] <tseliot> pitti or anybody else who uses sbuild. Are you experiencing any problems when trying to create an sbuild chroot for wily? I am, so ideas are welcome, please: http://pastebin.ubuntu.com/11207968/
[15:26] <tseliot> I'm using mk-sbuild
[15:26] <tseliot> infinity: ^
[15:27] <infinity> tseliot: That looks like you asked it to build a cross-compile chroot.
[15:27] <infinity> tseliot: And it's not wrong, there aren't any amd64 cross-compilers.
[15:28] <tseliot> infinity: oh, so it must be the --target parameter that's causing this
[15:28] <tseliot> i.e. me using that parameter
[15:28] <infinity> tseliot: Yeah, --target is for cross.  Don't use it for native chroots.
[15:29] <tseliot> infinity: ok, it makes sense, thanks
[15:31] <dobey> ick. libOpenCL.so is gone from ocl-icd-libopencl1 in vivid/wily, but it seems like ocl-icd-dev doesn't provide a symlink for it either. :-/
[15:31] <infinity> One could argue that it should ignore target if target==arch, but it's easy enough to just not specify it.
[15:32] <tseliot> right
[15:35] <jdstrand> seb128: done
[15:35] <seb128> jdstrand, thanks
=== oSoMoN_ is now known as oSoMoN
=== _salem is now known as salem_
[16:16] <seb128> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[17:07] <hallyn_> seb128: urgh, i' dlike to, but i don't know when i can get to it
[17:08] <hallyn_> i've put it on my list, but if someone has time to get to it before that that'd probably be good
=== soee_ is now known as soee
=== salem_ is now known as _salem