[01:06] <bryceh> wazzah, bugbot lives:  https://launchpad.net/~bugbot
[01:06] <bryceh> heya nigelb
[01:06] <bryceh> lessee
[01:08] <bryceh> nigelb, neither; looks like the patch is against xserver-xorg-input-evdev
[01:08] <bryceh> nigelb, however be careful; I think some input devices prefer the axes oriented the way they are
[01:09] <bryceh> it may be that a more sophisticated patch is needed to cover this corner case without breaking the general case
[01:09] <bryceh> but I haven't looked at it too deeply
[01:10] <bryceh> nigelb, probably would be wise to package the patch in a ppa and get a few people with different kinds of mice to test it before putting it in for sponsorship
[01:12] <bryceh> nigelb, or alternatively forward the patch upstream to bugs.freedesktop.org for review
[01:18] <nigelb> bryceh: I'll forwards \o/
[01:18] <nigelb> Thank you for looking :)
[01:19] <bryceh> no prob
[01:19]  * nigelb hugs bryceh :)
[01:20]  * bryceh hugs nigelb
[01:20] <nigelb> :)
[01:20] <bryceh> fwiw, we get axis fiddling patches like that one for the input drivers quite a lot... one set of users send patches to flip the axis one way, another note a regression and send patches to flip them back.  :-D
[01:21] <nigelb> haha
[01:21] <bryceh> upstream knows the right way to do things
[01:22] <bryceh> Sarvatt, RAOF, prepare for an onslaught of bugbot spam :-)
[01:22] <bryceh> Sarvatt, RAOF, at least now it's more easily procmailable
[01:23] <nigelb> bugbot? email bugs?
[01:23] <Sarvatt> bryceh: whats bugbot? I've already got 23k unread in my ubuntu-x-swat folder :D
[01:23] <bryceh> Sarvatt, prepare for 23k more
[01:24] <bryceh> bugbot is basically a new launchpad user account I'm going to use for running my arsenal scripts
[01:24] <bryceh> so all the arsenal spam will be nicely disassociated from me now
[01:24] <bryceh> my karma shall suffer greatly.  ;-)
[01:25] <nigelb> lol
[01:25] <nigelb> bryceh: you worked on lp team for a cycle, shoulda put in a hack to increase your karma :p
[01:27] <bryceh> hmm, well I don't think I can fiddle my karma score directly, but I certainly can disable the accounts of anyone with more karma than I...
[01:27]  * bryceh rubs hands together "bwahahaha"
[01:28] <nigelb> haha
[02:02] <Sarvatt> bugbot has only gotten 2 mails through to my inbox so far :)
[04:48] <RAOF> Why did I put maverick's mesa on the ubuntu-maverick branch??
[10:30] <apw> RAOF, Sarvatt, yo ... do you remember the discussion on which AGP drivers we needed built-in ... the notes say (only 4) but there are no hints as to which 4
[10:31] <RAOF> It was intel, amd, nvidia, via, right?
[10:35] <apw> RAOF, hrm i don't think we really talkaed about it, i am happy with those four though
[10:36] <RAOF> I only recall saying that we needde them built in, honestly, but I think those are the ones we need.
[10:36] <apw> RAOF, thats good enough for me :)
[10:36] <apw> i will start with those and you can tell us if thats not suffiicient :)
[10:40] <tseliot> RAOF: built-in? I guess this won't cause issues with proprietary drivers since we blacklist those drivers in the initramfs, right?
[10:41] <RAOF> That's a good question; the binary drivers have their own agp drivers, don't they?
[10:42] <tjaalton> probably a non-issue, since airlied thought about making them mandatory anyway
[10:42] <tjaalton> some time ago
[10:42] <RAOF> I understand that fedora builds in the agp drivers, so yeah.
[10:42] <tjaalton> right
[10:42] <apw> well if they are builtin that won't let you blacklist them anymore
[10:42] <apw> well if fedora does it  i guess we must be ok :)
[10:45]  * apw warns you that the next upload of the kernel will carry the switch from =m to =y for these AGP drivers
[10:50] <RAOF> tseliot: fglrx and nvidia are actually working in natty at the moment, right?  We'll be able to spot any problems this might cause?
[10:50] <tseliot> RAOF: yes, they are
[10:51] <tseliot> apw: if we cannot blacklist them, then it's not fine
[10:51] <apw> how does fedora handle this i wonder
[10:52] <jcristau> why would you blacklist an agp driver?
[10:52] <RAOF> These are the agp drivers, not the video drivers - are you sure they're a problem?
[10:52]  * apw cirtainly has no idea
[10:52] <apw> tseliot, do you have an example of what we blacklist when we enable prop drivers ?
[10:53] <RAOF> I don't think we currently blacklist any agp drivers in the proprietary driver voodoo; we blacklist nouveau in nvidia and radeon in fglrx, but that's different.
[10:54] <apw> yeah not proposing anything that high in the stack gets built-in
[10:54] <tseliot> apw: we simply blacklist nouveau and the other proprietary nvidia flavours when enabling nvidia.
[10:54] <apw> so i think we are probabally ok then
[10:54] <apw> but we do need to watch out when the next kernel goes in to be 100% sure
[10:55] <tseliot> RAOF, apw: ah, sorry, I misread what you wrote. I missed the "agp" part
[10:55] <jcristau> i certainly haven't heard of any issues since we started having the agp drivers builtin
[10:55] <tseliot> that's ok
[10:55] <jcristau> (we = Debian)
[10:55] <apw> tseliot, i assume you have some h/w you could test on, if I made up some test kernels
[10:55] <apw> jcristau, thats a good information point
[10:55] <apw> (thanks)
[10:55] <tseliot> apw: sure, I can test things here but, as I said, it should be ok to build in agp drivers
[10:56] <apw> ok ... done ... thansk
[10:58] <RAOF> apw: thanks.
[13:47] <Sarvatt> intel_agp.sucks=1 passed to grub, blacklisted :)
[13:48] <jcristau> way to prevent stuff from working :)
[13:49] <Sarvatt> ah hah
[13:49] <Sarvatt> agp=off
[13:50] <Sarvatt> then nvagp loads
[13:50] <Sarvatt> with agp :)
[17:27] <kklimonda> hey
[17:29] <kklimonda> would it be possible to contact ati/nvidia and ask them to add a command some line argument, to their driver installers, like "--i-am-aware-that-by-installing-those-drivers-i-void-the-ubuntu-warranty" or something similar, and refuse to install on newer Ubuntu systems without it being set?
[17:30] <kklimonda> no single week passes without me helping some poor soul fix their system after installing those drivers..
[17:30] <tseliot> kklimonda: in theory there's already a hook for something like that. It only works if the nvidia packages are already installed though (I guess)
[17:31] <tseliot> this applies only to nvidia
[17:32] <kklimonda> tseliot: apparently, that's not enough :/
[17:33] <tseliot> kklimonda: I can't really force more invasive changes into their installers though. I should really work to improve the situation though. The main problem is my lack of time
[17:33] <tseliot> it's still on my todo list though
[17:34] <kklimonda> tseliot: can't you just ask? their current installers pro-actively break systems ;)
[17:34] <kklimonda> and for some reason people blame us :/
[17:35] <tseliot> kklimonda: I already did. Which is why I said that I "can't" do that
[17:35] <bjsnider> tseliot, it only works if the nvidia-common package is installed. i think it should be put into jockey.common
[17:36] <tseliot> bjsnider: see, I don't even remember how I implemented the whole thing...
[17:36] <bjsnider> hahaha
[17:36] <bjsnider> i didn't expect that response
[17:36] <bjsnider> i think the flaw was putting the hook into a package that is not automatically on everyone's system (nvidia-common)
[17:37] <bjsnider> but it was a good idea
[17:37] <tseliot> bjsnider: maybe, as you said, jockey is a better place for that
[17:37] <bjsnider> i think it should be in a package that is part of ubuntu-desktop or the like
[17:39] <bjsnider> that way the user would have to seriously bork their system to even try the nvidia-installer
[17:41] <bjsnider> kklimonda, there's a thread on the nvforums website created by the nvidia devs which tells users not to use their installer, but to use the distro installers instead. nobody cares i guess.
[17:41] <tseliot> bjsnider: that could still be overridden with an option in the installer, something like --override-distro-hooks
[17:41] <bjsnider> yes but regular users wouldn't know that without a lot of research
[17:42] <kklimonda> bjsnider: that's why I've suggested actually modifying the installer - it's been proven that users don't read and are generally bunch of.. -ECOCINCOMPATIBLE
[17:42] <kklimonda> tseliot: if people use such an argument we can just tell them to contact the person who told them to do that.
[17:43] <tseliot> kklimonda: the installer already supports that argument that I mentioned (even though maybe that's not the exact name). It's just a matter of making sure that the hook is there when Ubuntu is installed
[17:44] <kklimonda> tseliot: ah, I see - but only nvidia for now, right?
[17:45] <Sarvatt> what the heck, swapped out the HDD in my 8400M GS laptop and now the nvidia blob works on both linux and windows, I haven't been able to use the blob on that thing since karmic because it had nasty corruption and lockup problems and would blue screen on boot in windows. I thought the GPU was just screwed
[17:46] <tseliot> kklimonda: yes, only nvidia. fglrx (when it generates deb packages) uses more or less the same sources of the packages in Ubuntu (since I maintain both). The problem is when it acts like the Nvidia installer I guess (i.e. without generating packages)
[17:47] <tseliot> Sarvatt: err... maybe the blob was indeed screwed, physically speaking
[17:47] <Sarvatt> put the 200gb 7200RPM drive back in and did a fresh install, still can't use the blob
[17:47] <tseliot> oh
[17:47] <tseliot> maybe it's a controller thing?
[17:48] <Sarvatt> HDD pulling too much power and killing the GPU, thats a new one
[17:48] <tseliot> that would be weird
[17:48] <tseliot> I was thinking of some messed up BIOS
[17:49]  * tseliot likes blaming it on the BIOS
[17:49] <Sarvatt> me too, it almost always is anyway :)
[17:50] <tseliot> :)
[17:53] <Sarvatt> 200gb hitachi 7200rpm drive = cant use blob, 250gb WD 5400rpm drive = blob works fine. on more than one OS.. anyway the wife is happy she can play her minecraft again, nouveau 3D wasn't quite fast enough :)
[17:55] <bjsnider> does the smart data on the larger drive say it's screwed?
[17:59] <Sarvatt> dunno, can't check now. will check later though
[18:06]  * bryceh waves
[18:06] <Sarvatt> morning bryce
[18:45] <bjsnider> kklimonda, it ooks l ike the nvidia installer hook is a file -- /usr/lib/nvidia/pre-install. it is a one-line shell script. now, if it were moved from nvidia-common to jockey-common it would be more effective.
[18:52] <Sarvatt> dang, the JumpyCursorThreshold patch for synaptics is awesome now that I have a huge touchpad that constantly freaks out
[19:04] <Sarvatt> hmm actually, wonder if its even needed now with http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e
[19:22] <Sarvatt> ugh, touchpad acceleration is all kinds of screwed up in current synaptics still, JumpyCursorThreshold isn't needed though \o/
[19:29] <Sarvatt> guess I still need to revert http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=4e0e53fcba6fd99d458df1905d055d63360155c0 , it's unusably jumpy/slow. move the cursor in a straight line in a smooth motion and it accelerates/decelerates constantly
[19:32] <Sarvatt> maybe the gnome knobs mentioned in http://who-t.blogspot.com/2010/06/new-synaptics-acceleration-mechanism.html would help but the default is still crap here
[20:29]  * bryceh updates https://wiki.ubuntu.com/Wayland with more faqqage
[20:34] <bryceh> Sarvatt, I also added your bits to the X Update section at https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-23
[23:14] <bryceh> https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/346289/+activity
[23:14] <bryceh>  ^ this user is irritating me
[23:14] <bryceh>  I wrote up a lengthy explanation of the bug, and he keeps reverting the description
[23:14] <ubot4> Launchpad bug 346289 in flashplugin-nonfree (Ubuntu) "MASTER: Choppy Flash playback in full screen (affects: 26) (dups: 3) (heat: 200)" [Undecided,New]
[23:17] <Sarvatt> yeesh
[23:18] <Sarvatt> he'll probably edit the duped bug if you make another one the master too
[23:18] <bryceh> Sarvatt, speaking of bug 346289, I'd appreciate if you took a quick look at my Discussion and Ideas sections there
[23:18] <ubot4> Launchpad bug 346289 in flashplugin-nonfree (Ubuntu) "MASTER: Choppy Flash playback in full screen (affects: 26) (dups: 3) (heat: 200)" [Undecided,New] https://launchpad.net/bugs/346289
[23:19] <bryceh> see if I missed anything.
[23:19] <bryceh> I'm gathering there is nothing we can do, and the two ideas I've had seem a bit kludgy.  But I'd like to hear your take
[23:19] <bryceh> (and technically, no I don't think this is an X issue)
[23:20] <Sarvatt> bryceh: unredirect fullscreen windows option in compiz :)
[23:20]  * Sarvatt slaps natty for making all URL's open in firefox
[23:21] <RAOF> Unredirect fullscreen windows isn't going to make flash start GPUing, though.
[23:21] <bryceh> morning RAOF
[23:22] <RAOF> Morning bryceh :)
[23:22] <RAOF> Is mesa ready to review? :)
[23:22] <Sarvatt> what the heck!
[23:22] <Sarvatt> [    17.845] (II) VESA(0): Not using built-in mode "1856x1392" (no mode of this name)
[23:22] <Sarvatt> [    17.845] (II) VESA(0): Not using built-in mode "1792x1344" (no mode of this name)
[23:22] <bryceh> I'd like that chocolateboy to revert me one more time...
[23:23] <RAOF> Sarvatt: That's… interesting.  Is that a crazywierd VBIOS?
[23:25] <RAOF> It might be fun to apply that ‘where does this mode come from, anyway” patch and try  again :)
[23:25] <Sarvatt> yeah this is crazy, http://sarvatt.com/downloads/Xorg-maverick.txt
[23:25] <bryceh> RAOF, well I fixed the one mesa bug but found another...
[23:25] <RAOF> You're building from master, right?
[23:25] <bryceh> RAOF, I'd love it if you want to take a look at it now, I feel like it's 95% there
[23:26] <bryceh> yeah
[23:26] <bryceh> well specifically I'm deriving from one of Sarvatt's xorg-edgers builds
[23:26] <bryceh> maybe in reviewing it you'll spot whatever I did wrong
[23:26] <bryceh> RAOF, https://launchpad.net/~xorg-edgers/+archive/wayland/
[23:26] <RAOF> I'm merging 7.9+repack-1 from debian, and doing the gallium/classic selection stuff now, so more mesa is in my headspace :)
[23:27] <Sarvatt> RAOF: probably need to merge ubuntu-maverick into ubuntu before merging 7.9+repack-1
[23:27] <RAOF> Sarvatt: Yup.  I noticed that.  Fortunately, merges are commutative :)
[23:28] <Sarvatt> 5a3ac74 needs to be reverted for mesa 7.10 to compile too in case ya hadn't seen
[23:29] <Sarvatt> tormod brought it up on mesa-dev but no one responded
[23:36] <RAOF> There's got to be a better way of doing patches than quilt.
[23:42] <bryceh> bzr?  ;-)
[23:43] <RAOF> Quite possibly.
[23:43] <RAOF> bzr looms would work.
[23:43] <RAOF> Man.  That patch compiles first time!
[23:43] <RAOF> I'm on fire!
[23:45] <RAOF> Hm.  The option should probably be documented, though.
[23:46] <bjsnider> what's wrong with quilt?
[23:48] <RAOF> I always forget to “quilt add” a file before editing it.
[23:50] <ilmari> hm, no xorg-edgers/drivers-only ppa for maverick?
[23:57] <Sarvatt> drivers-only doesn't really work these days in the world where every new driver release needs a new libdrm, etc :)
[23:58] <Sarvatt> tormod updated that and haven't seen him around lately


[01:52] <mwhudson> vorlon: i sent email too but i think the glibc autopkgtest failures are an upstream testsuite bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25652
[02:11] <mwhudson> (i think this one gets filed under "shell is bad")
[02:11] <sarnold> so bad
[02:18] <mwhudson> i assume https://sourceware.org/git/?p=glibc.git;a=commit;h=7db1fe38de21831d53ceab9ae83493d8d1aec601 is to blame without any particular evidence
[03:50] <vorlon> mwhudson: thanks.  I don't want to migrate glibc with failing autopkgtests however, and it needs another upload still anyway to get the predepends on libcrypt1; would you want to take a stab at fixing the missing ld, or should I just XFAIL these for now?
[03:51] <vorlon> (fwiw I tried to reproduce the failures and haven't gotten as far as managing to get the invocation correct so that I can even reproduce the failure outside of a full 'make check')
[04:20] <vorlon> doko, xnox: soooo libxcrypt doesn't build multilib variants
[04:28] <vorlon> doko: hmm I'm not sure what to make of the i386 dbus-glib autopkgtest regression, but it looks somehow related to glibc despite the log showing no packages being pulled from -proposed<EMAIL_ADDRESS>[06:21] <vorlon> doko, mwhudson: I have a glibc -0ubunut4 staged here and ready for upload, but I want to let the autopkgtests for -0ubuntu3 complete on all archs so we get a clear picture before I upload (provided -0ubuntu3 is good wrt autopkgtests, I will skip all the tests with 0ubuntu4 aside from glibc itself).  there are still some autopkgtest regressions listed on
[06:21] <vorlon> https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses_by_team.html#foundations-bugs that I don't have a handle on - clearcut, gnudatalanguage, libseccomp, rtags
[06:44] <mvo> rbasak: hey, do you think you could have a look at the SRU of snapd in unapproved?
[06:46] <doko> vorlon: dbus-glib is becase cross-toolchain-base already migrated, having mismatched glibc versions for cross/native. did you retrigger with glibc from -proposed?
[06:47] <doko> I've been working on the regressions triggered by glibc yesterday. will continue today
[06:48] <doko> vorlon, xnox: multilib, are you worried that we don't drop the glibc crypt code for the multilib variants?
[06:52] <doko> given back dbus-glib with the glibc trigger
[07:05] <doko> vorlon: please ignore the gcc-arm-none-eabi/i386 test failure
[07:06] <doko> and the force-reset-test binutils-arm-none-eabi/13 hint can be removed, fixed
[08:22] <tjaalton> could someone remove the glslang-dev/-tools binaries from s390x, it's not supposed to build on big-endian anymore as spirv is broken there
[08:22] <tjaalton> also spirv-tools should be removed
[08:22] <tjaalton> from s390x..
[08:29] <seb128> tjaalton,
[08:29] <seb128> $ reverse-depends -b glslang-dev
[08:29] <seb128> Reverse-Build-Depends
[08:29] <seb128> [08:29] <seb128> * libplacebo
[08:29] <seb128> * renderdoc
[08:30] <seb128> * vulkan-validationlayers
[08:30] <seb128> tjaalton, the first and third build on s390x
[08:31] <seb128> tjaalton, also https://paste.ubuntu.com/p/62n3D4vPDQ/ for tools
[08:31] <tjaalton> seb128: remove those too
[08:31] <tjaalton> I'll fix mesa
[08:32] <tjaalton> vulkan-* are in proposed
[08:32] <tjaalton> meh
[08:32] <tjaalton> or just ignore that it's broken are restore the build.. dunno
[08:32] <seb128> I would rather do that...
[08:34] <seb128> in any case for removal I think a bug would be best since it's not trivial
[08:34] <tjaalton> right
[09:13] -queuebot:#ubuntu-release- Unapproved: xf86-input-wacom (bionic-proposed/main) [1:0.36.1-0ubuntu1 => 1:0.36.1-0ubuntu1.1] (desktop-core, xorg)
[09:34] -queuebot:#ubuntu-release- Unapproved: zfs-linux (eoan-proposed/main) [0.8.1-1ubuntu14.3 => 0.8.1-1ubuntu14.4] (core)
[09:53] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.24]
[10:00] -queuebot:#ubuntu-release- Unapproved: rejected lz4 [source] (xenial-proposed) [0.0~r131-2ubuntu2.1]
[10:01] -queuebot:#ubuntu-release- Unapproved: rejected lz4 [source] (bionic-proposed) [0.0~r131-2ubuntu3.1]
[10:24] -queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (xenial-proposed) [9.5.21-0ubuntu<IP_ADDRESS>]
[10:29] -queuebot:#ubuntu-release- Unapproved: accepted quassel [source] (xenial-proposed) [0.12.2-0ubuntu<IP_ADDRESS>]
[11:24] <LocutusOfBorg> apw, can I please have coq removed in some architectures? it follows a debian removal bug. it might come back, but maybe not in time for focal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953408
[11:25] <LocutusOfBorg> the list and reverse-deps is on that bug, basically coq armhf i386 s390x, with also prooftree why3 and libaac-tactics-ocaml
[11:26] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1035.38~16.04.1] (kernel)
[11:40] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1035.38~16.04.1]
[11:53] -queuebot:#ubuntu-release- Unapproved: drbd-utils (bionic-proposed/main) [8.9.10-2 => 8.9.10-2ubuntu0.1] (ubuntu-server)
[13:36] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.30]
[13:52] -queuebot:#ubuntu-release- Unapproved: accepted sg3-utils [source] (bionic-proposed) [1.42-2ubuntu<IP_ADDRESS>]
[13:53] -queuebot:#ubuntu-release- Unapproved: accepted sg3-utils [source] (eoan-proposed) [1.44-1ubuntu1.1]
[14:48] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20200211.1-0ubuntu<IP_ADDRESS> => 1:20200311.1-0ubuntu<IP_ADDRESS>] (no packageset)
[14:48] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20200211.1-0ubuntu<IP_ADDRESS> => 1:20200311.1-0ubuntu<IP_ADDRESS>] (no packageset)
[14:48] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20200211.1-0ubuntu<IP_ADDRESS> => 1:20200311.1-0ubuntu<IP_ADDRESS>] (no packageset)
[15:42] <vorlon> doko: cross-toolchain-base vs dbus-glib> ah thanks, I hadn't tried triggering against -proposed because I didn't understand why it would help
[15:42] <vorlon> doko: gcc-arm-none-eabi, I'll have a look
[15:44] <vorlon> doko: gcc-arm-none-eabi/i386 hinted, thanks
[16:06] <doko> vorlon: before you upload glibc, I'm testing a fix for 1861353
[16:06] <vorlon> doko: ok
[16:07] -queuebot:#ubuntu-release- Packageset: Added wpebackend-fdo to i386-whitelist in focal
[16:09] <vorlon> doko: any ideas on the failing autopkgtests that I flagged last night?  There's a collection of failures on armhf which concern me that we may have arch-specific regressions in glibc
[16:11] <doko> no, I gave back now gnudatalanguage with empty test queues. let see if that helps
[16:11] <doko> yes, but the only tests ignored for arm were the soft-float tests
[16:22] -queuebot:#ubuntu-release- Packageset: Added mozjs68 to i386-whitelist in focal
[16:35] <doko> vorlon, xnox: LP: #1861353 has a patch
[16:40] <xnox> doko:  looks good, i'm not sure if we want current glibc to migrate or upload again?!
[16:42] <doko> steve wants to upload afaik
[16:43] <vorlon> xnox: upload again, getting the pre-depends, the autopkgtest fix, and the multiarch fix
[16:44] <vorlon> xnox: but I am still looking to bottom out on the remaining revdep autopkgtest regressions
[16:44] <vorlon> xnox: and when I upload -0ubuntu4 I will flush the irrelevant re-tests
[16:46] <vorlon> rtags is weird, I can reproduce it but when I run autopkgtest with -s and then re-run the test from a shell, it succeeds
[16:54] <xnox> vorlon:  i don't see cd build logs https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/focal/?C=M;O=D but forexample there were images built on the 11th of march
[16:54] <xnox> any idea why build-logs are not getting updated?
[16:56] <vorlon> no idea, but looking
[16:57] <vorlon> xnox: because someone landed a move from python2 to python3 and mirror-image-build-logs is not python3-clean
[16:58] <vorlon> ;)
[16:58] <vorlon> (and not covered by unit tests)
[16:59] <vorlon> xnox: doing a one-off run under python2 now
[17:00] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu22 => 2.04-1ubuntu22] (core)
[17:01] <vorlon> xnox: and fixed
[17:04] <cjwatson> universal_newlines=True and str would be better style, but OK :)
[17:04] <cjwatson> (IMO anyway, not that it matters much)
[17:17] <vorlon> ok I'm going to turf the rtags/amd64 autopkgtest regression, given that I can't reproduce it in an interactive shell I don't believe it points to an actual regression in glibc but is a buggy test of some sort
[17:24] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu22 => 2.04-1ubuntu22] (core)
[18:00] -queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.6-1ubuntu<IP_ADDRESS> => 3.9-1ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[19:32] <vorlon> glibc uploaded
[19:32] <vorlon> (a half hour ago)
[19:32] <vorlon> if we can figure out what's up with those remaining arm failures and let this in, great
[19:32] <vorlon> if not and we have to reupload, not much time wasted
[19:32] <vorlon> (after jettisoning the autopkgtest queues)
[19:36] <doko> if it's build, please retrigger libseccomp with the one from -proposed
[19:36] <doko> built even
[19:38] <doko> vorlon: the arm64 autopkg tests triggered by perl don't seem to make any progress
[19:45] <vorlon> doko: why do you expect a different result for a libseccomp retrigger?
[19:47] <vorlon> doko: perl/arm64> I had dumped all of those tests from the queue after analyzing the root cause of the libc preinst failure.  it seems LocutusOfBorg has re-queued them and I see progress being made now.
[19:54] <kanashiro> I sent a message about the autopkgtest testbed earlier in #ubuntu-devel but got no answer, let me copy and paste it here to see if someone can help me
[19:54] <kanashiro> hi, I am investigating the gem2deb/1.0.5 autopkgtest failure on armhf and it is complaining (reprotest actually) about the kernel version<EMAIL_ADDRESS>[19:54] <kanashiro> if you check the log you will find: autopkgtest [01:38:52]: testbed running kernel: Linux 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:21:09 UTC 2019
[19:55] <kanashiro> is linux 4.15.0 expected in an ubuntu focal testbed?
[19:56] <mwhudson> is glibc/yt/arm64 ooming?
[19:57] <mwhudson> would it make sense for autopkgtest artifacts to include syslog
[19:57] <vorlon> kanashiro: yes, because the armhf autopkgtest runners are containers, running on an LTS host
[19:58] <vorlon> complaining about the kernel version: that sounds like a wrong test
[19:58] <vorlon> no userspace packages in focal should fail with the bionic kernel
[19:58] <vorlon> so a wrong test or a right test exposing wrong code
[20:02] <vorlon> mwhudson: so what's surprising to me is that yt should oom consistently on arm64 but not on other archs, given that we allocate the same size VM for all
[20:02] <vorlon> but we could try adding it to the 'huge' config and see if that fixes it?
[20:02] <mwhudson> vorlon: seems worth a shot
[20:06] <mwhudson> vorlon: er i think yt _does_ oom on other arches
[20:06] <mwhudson> is it badtested?
[20:07] <mwhudson> eg<EMAIL_ADDRESS>[20:08] <mwhudson> ubuntu-release:force-reset-test yt/3.5.1-3/amd64
[20:08] <mwhudson> that version has passed though, so i don't know why it's marked "always failed" in excuses
[20:08] <mwhudson> ANYWAY i need to get on the bus
[20:11] <kanashiro> vorlon, ack, I'll see what I can do about it
[20:18] <LocutusOfBorg> vorlon, it wasn't my intention, stuff like llvm-9 had tests "running" but not really running, queues were empty, so I rescheduled only running tasks that were lost. In case something is missing, please reschedule them :)
[20:19] <vorlon> LocutusOfBorg: ok
[20:19] <vorlon> mwhudson: yt passed on armhf and on s390x; armhf would not have the memory limit, but s390x would
[20:20] -queuebot:#ubuntu-release- Unapproved: util-linux (bionic-proposed/main) [2.31.1-0.4ubuntu3.5 => 2.31.1-0.4ubuntu3.6] (core)
[20:20] -queuebot:#ubuntu-release- Unapproved: util-linux (eoan-proposed/main) [2.34-0.1ubuntu2.3 => 2.34-0.1ubuntu2.4] (core)
[21:00] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.14 => 2.02-2ubuntu8.15] (core)
[21:01] <LocutusOfBorg> vorlon, any idea? https://launchpad.net/ubuntu/+source/puma/3.12.4-1ubuntu2/+build/18828540
[21:01] <LocutusOfBorg> chroot problem due to glibc?
[21:01] <LocutusOfBorg> same arm64 ppc64el s390x
[21:02] -queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.15 => 1.93.15ubuntu1] (core)
[21:04] <xnox> Fetched 69.0 MB in 1s (81.4 MB/s)
[21:04] <xnox> E: This installation run will require temporarily removing the essential package libc6:ppc64el due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
[21:04] <xnox> E: Internal Error, Could not early remove libc6:ppc64el (2)
[21:04] <xnox> doko:  vorlon: juliank: ^
[21:07] <mwhudson> vorlon: yeah, not saying it makes sense
[21:09] <juliank> xnox: weeeeeeeeeee
[21:09] <juliank> xnox: Did we add libc6 pre-depends libcrypt1?
[21:09] <juliank> and is that the result?
[21:09] <mwhudson> y
[21:09] <mwhudson> at least that's what the .changes said
[21:10] <juliank> ok I guess we gotta revert
[21:10] <mwhudson> yay another glibc upload?
[21:10] <juliank> wondering why that happens
[21:11] <juliank> exactly, another glibc upload
[21:11] <juliank> Or figuring out the other side of the loop and removing that if possible
[21:11] <juliank> but meh
[21:11] <juliank> idk
[21:12] <juliank> I suggested removing the libc6 depends from libcrypt1
[21:12] <mwhudson> it's going to take an aa to remove glibc from proposed before anything can build now isn't it?
[21:12] <mwhudson> ubuntu-archive: halp
[21:12] <LocutusOfBorg> yes ^^ doko
[21:22] <xnox> wgrant:  are you up already?
[21:22] <xnox> wgrant:  rm glibc from focal-proposed
[21:22] <xnox> wgrant:  and copy in the previous one?
[21:23] <vorlon> xnox: context?
[21:23] <xnox> vorlon:  see highlight above
[21:23] <xnox> vorlon:  cannot install libc6
[21:23] <vorlon> xnox: yes, where is that quoted from? an autopkgtest log, a build log?
[21:23] <juliank> Build log
[21:23] <mwhudson> https://launchpad.net/ubuntu/+source/puma/3.12.4-1ubuntu2/+build/18828540
[21:24] <vorlon> also why does it say conflicts when there are not
[21:24] <vorlon> ah
[21:24] <juliank> Meh who says messages are accurate anyway
[21:24] <vorlon> >_<
[21:25] <mwhudson> https://launchpad.net/ubuntu/+builds?build_text=&build_state=all
[21:25]  * wgrant isn't quite awake yet
[21:25] <mwhudson> (from which we can see the order the various architectures got published in)
[21:26] <vorlon> ok, removing
[21:27] <vorlon> xnox, juliank: is the Breaks: strictly required?  should it be only Replaces: instead? then there would be no loop
[21:27] <juliank> we don't know
[21:27] <juliank> I guess
[21:27] <juliank> you probably need it for partial upgrades, but we don't support those
[21:28] <vorlon> juliank: Breaks: + Replaces: is generally advisable so that if one installs the replacing package, then removes it again, one doesn't have files go unexpectedly removed from the filesystem
[21:28] <vorlon> however that seems unlikely here
[21:28] <vorlon> and I don't see any other reason to need it
[21:28] <juliank> you just can't have libcrypt1 migrated before libc6
[21:28] <vorlon> so the question is whether we would prefer dropping the Breaks: and allowing someone to manually install+remove libcrypt1 without upgrading libc6 and thereby breaking their syste
[21:28] <vorlon> m
[21:29] <vorlon> or if we would prefer dropping the Pre-Depends: and leaving open the possibility of wrong ordering on upgrade
[21:29] <xnox> vorlon:  libcrypt1 is priority required, thus i don't think one can "simply" remove it?
[21:29] <juliank> apt doesnt care
[21:29] <juliank> apt only cares about essential / xb-important
[21:29] <xnox> i thought apt wants one to type "Do as i say"
[21:29] <xnox> hm
[21:30] <xnox> is libcrypt1 essential yet?
[21:30] <vorlon> no, and runtime libraries never are
[21:30] <mwhudson> presumably removing a dependency of essential: yes is non-trivial?
[21:30] <vorlon> they're only "virtually essential"
[21:30] <juliank> well from apt's side it is essential once libc6 depends on it
[21:30] <vorlon> mwhudson: correct, but that only helps you /after/ you've upgraded libc
[21:30] <juliank> apt's understanding of essential is transitive
[21:30] <juliank> :D
[21:31] <vorlon> if you shoot yourself in the foot by installing and removing libcrypt without upgrading libc, it doesn't protect you
[21:31] <xnox> yeah, cause i don't see essential set on libc6 itself
[21:31] <juliank> heh just mark it xb-important: yes :D
[21:31] <mwhudson> vorlon: if the libc on disk doesn't depend on libcrypt1 how does that matter? or is this about what happens during upgrades?
[21:32] <vorlon> mwhudson: it's the fact that it's taking over files that previously belonged to libc
[21:32] <juliank> then remove the bit in focal+1
[21:32] <vorlon> that's why we want the pre-depends in the first place
[21:32] <mwhudson> ah
[21:32] <xnox> mwhudson:  we are splitting libc6 into libc6 & libcrypt1, with libcrypt1 taking over file from libc6
[21:32] <xnox> on upgrade
[21:32] <xnox> we got it a bit wrong 3 times now =)
[21:32] <mwhudson> xnox: i think i had missed the fact that libcrypt1.so was already on disk
[21:33] <xnox> mwhudson:  right, it used to be provided by glibc (they had their own implementation) but libxcrypt implementation is better
[21:33] <mwhudson> yeah i get all that, but i didn't realize the soname was the same
[21:33] <xnox> vorlon:  juliank: can we just use tarball component of libxcrypt and build it as part of glibc source build and avoid this mess? =)
[21:33] <juliank> should have just added libxcrypt to glibc source package as extra tarball and called it ad ay
[21:33] <xnox> or like Built-Using, and make libc6 copy-in and ship libxcrypt's libcrypt1 =)
[21:34] <juliank> but to be more serious, my understanding from the last discussion is that it's unlikely for Depends to go wrong ordering wise, and the only thing we need to fix is the file path
[21:34] <xnox> riht
[21:35] <juliank> I'd kind of prefer us to have the same issues debian has over making up our own ones
[21:35] <xnox> and we thought we needed predepends, whilst autopkgtest VMs, had wrong version strings in breaks/replaces which were incorrect for ubuntu
[21:35] <xnox> and it migrated by accident
[21:35] <juliank> hence I was slightly surprised that we did the pre-depends upload after all
[21:35] <juliank> but then I don't have a straight view of the timeline
[21:36] <juliank> and I'm not exactly fully conscious at the moment
[21:38] <mwhudson> vorlon: so without breaks the failure mode is something like:
[21:38] <mwhudson> person running eoan updates apt sources to focal
[21:38] <mwhudson> they upgrade libcrypt1 only from focal
[21:38] <mwhudson> then apt remove libcrypt1 will not complain but also will break their system
[21:40] <juliank> right, or focal to focal more likely
[21:40] <juliank> we'vce got a ton of people on there now
[21:40] <mwhudson> making the version of libcrypt1 in focal un-removable would be a bit of a hack but close this hole
[21:40] <vorlon> right
[21:41] <mwhudson> i.e. essential: yes or whatever xb-important is :)
[21:41] <juliank> Still I'd prefer to do what Debian does, because it _should_ be fine, and I don't want to get into a different mess than they'd be in
[21:41] <mwhudson> juliank: does debian have an actual plan here?
[21:41] <juliank> mwhudson: debian thinks they're approach is fine
[21:41] <mwhudson> because i was wondering if debian is watching our flailing here
[21:41] <mwhudson> juliank: which is?
[21:41] <juliank> mwhudson: oh we told them
[21:42] <juliank> mwhudson: libcrypt1 breaks/replaces old libc6, libc6 depends on libcrypt1, perl preinst gets changed to ignore libcrypt1 loading error IIRC
[21:42] <juliank> i.e. sdome debconf questions were made optional
[21:42] <mwhudson> uh huh ok
[21:43] <juliank> The assumption is that it's highly unlikely that they'll end up in a broken situation
[21:43] <juliank> because you know, apt will configure libc6 immediately anyway
[21:43] <juliank> there's no real difference to a pre-depends _in practice_
[21:44] <juliank> but it avoids having to break the loop which apt barfso n
[21:45] <juliank> but anyway I'm too tired to think much
[21:46] <mwhudson> i am conscious that i've never really understood this end of things
[21:47] <juliank> I might understand it if I was actually awake
[21:47] <xnox> i am confused why libcrypt1 doesn't have Depends libc6 >= 2.31
[21:47] <xnox> Depends: libc6 (>= 2.25)
[21:47] <xnox> Breaks: libc6 (<< 2.31)
[21:47] <xnox> Replaces: libc6 (<< 2.31)
[21:47] <xnox> is bogus
[21:48] <vorlon> juliank: no difference in practice> even if other virtually-essential packages were also unconfigured at the time and apt were to try to decide to configure them before libc6?
[21:48] <juliank> vorlon: that seems unlikely to happen, as they'd be all immediately configured or apt would tell you it can't immediate-configure them
[21:48] <juliank> AFAIUI
[21:48] <juliank> don't trust a sleepy juliank
[21:48] <vorlon> hmm
[21:49] <juliank> xnox: makes no difference
[21:49] <vorlon> does immediately-configured imply one at a time?
[21:49] <juliank> i think so
[21:49]  * xnox goes to watch the latest episode of "keeping up with coronavirus"
[21:49] <juliank> xnox: Depends and Breaks both other the same thing in practice
[21:50] <xnox> hm i wonder if predepends is impossible
[21:50] <xnox> because we cannot configure libcrypt1, only unpack it?!
[21:50] <juliank> that is correct, there is a loop with Pre-Depends
[21:50] <vorlon> dpkg will break a pre-depends/depends cycle
[21:51] <vorlon> it will configure it despite the dep being unsatisfied
[21:51] <juliank> dpkg's loop breaking might be irrelevant in essential
[21:51] <juliank> because apt will break the loop itself, or try to and fail
[21:51] <juliank> because the whole immediate configure thing
[21:51] <juliank> E: This installation run will require temporarily removing the essential package libc6:ppc64el due to a Conflicts/Pre-Depends loop
[21:52] <juliank> I think that's the reason it says that
[21:53] <juliank> A {Pre-,}Depends-Unpacked would solve such issues and simplify a lot of stuff
[21:58] <vorlon> juliank: does apt not implement the same loop-breaking logic as dpkg then, regarding pre-depends+depends loops?
[22:00] <juliank> vorlon: i don't know
[22:00] <vorlon> so I could test this
[22:01] <vorlon> by uploading libxcrypt, dropping the Breaks
[22:01] <vorlon> and reviving glibc
[22:01] <vorlon> and seeing what happens
[22:04] <juliank> sure
[22:04] <juliank> in any case, I'll try to get some sleep, maybe I get lucky
[22:05] <juliank> a good night's sleep is about the same level of difficulty as this library split
[22:21] <ahasenack> were you talking about E: This installation run will require temporarily removing the essential package libc6:amd64 due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option. ?
[22:24] <mwhudson> ahasenack: yes
[22:27]  * doko hates debugging broken autopkg tests
[23:07] <vorlon> juliank, xnox, mwhudson: libxcrypt without Breaks: unblocks us, so I'd like to proceed from here
[23:08] <mwhudson> vorlon: yay
[23:10] <mwhudson> vorlon: is britney going to try to schedule <austin-powers>1 million</austin-powers> autopkgtests again?
[23:10] <vorlon> yes
[23:10] <vorlon> and then I'm going to murder them all
[23:10] <vorlon> and manually reschedule the ones we want
[23:11] <mwhudson> vorlon: and did you think at all about ways to cheat and make libcrypt1 unremovable?
[23:11] <mwhudson> (seems low priority though)
[23:11] <vorlon> mwhudson: no; I think that particular corner case is unlikely
[23:11] <mwhudson> https://launchpad.net/ubuntu/+builds?build_text=&build_state=chrootwait <- i guess i'll retry the ones of these from today
[23:12] <mwhudson> unless chroot problems get autoretried somehow?
[23:12] <vorlon> mwhudson: they don't afaik
[23:12] <mwhudson> hm wait someone already did this?
[23:12] <mwhudson> https://launchpad.net/ubuntu/+source/puma/3.12.4-1ubuntu2/+build/18828540 is successful now
[23:12] <vorlon> yeah it was really only puma that landed in the window afaik
[23:13] <mwhudson> vorlon: or did you retry some to test things were ok?
[23:13] <vorlon> and I retried them thinking it would be a test case
[23:13] <vorlon> and they built with glibc 2.30 instead
[23:13] <vorlon> so that was a fail :P
[23:13] <mwhudson> ha
[23:13]  * mwhudson retries the others
[23:19] <tumbleweed>  /32
[23:19] <tumbleweed> grr
[23:21] <mwhudson> ok they all built now
[23:22] <mwhudson> well bar one but that'll be fine i'm sure
[23:58] -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (bionic-proposed/universe) [0.164 => 0.175~18.04.1] (no packageset)


[10:42] <brousch> http://yro.slashdot.org/story/12/03/17/0142219/websites-can-detect-what-chrome-extensions-youve-installed
[14:01] <snap-l> I'm so glad we chose Javascript for our web language. :)
[14:03] <snap-l> I was worried when we decided to move from PHP to other languages that we'd make the web more secure. ;)
[14:20] <rick_h> psh, what security issue is it you've run into?
[14:20] <snap-l> See scrollback from brousch
[14:22] <rick_h> this isn't anything JS related, just how chrome does extensions
[14:27] <jrwren> i'm learning things about python that i'd never thought about before.
[14:27] <jrwren> like from module import name <-- what that ACTUALLY does.
[14:27] <jrwren> its interesting
[14:27] <jrwren> very C like, very java/c# unlike
[14:28] <jrwren> gonna be hard to get a buffer overflow in js :)
[15:58] <rick_h> jrwren: heh, import magic!
[16:01] <snap-l> rick_h: Yes but the extensions are written in JS, correct?
[16:04] <rick_h> snap-l: right, js and html, but he's reading your manifest.json file, which is required for the extension. So chrome should just prevent access to that file to the running website
[16:04] <snap-l> True, this is a problem with how Chrome handles extensions
[16:04] <rick_h> right, and nothing to do with JS security
[16:04] <rick_h> :P
[16:05] <snap-l> rick_h: I can see this getting worse before it gets better. :)
[16:05] <snap-l> Javascript is extremely powerful and very well integrated into the browser.
[18:16] <greg-g> don't use chrome :)
[22:29] <snap-l> Good evenning
[23:01] <rick_h> party
[23:50] <snap-l> http://blandvargar.bandcamp.com/ <- And this is why I don't play much black metal
[23:50] <snap-l> although this isn't the worst I've heard.


[00:46] <ajmitch> is code browsing temporarily broken?
[00:47] <lifeless> did you get an OOPS ?
[00:47] <ajmitch> 503 error
[00:47] <ajmitch> no oops shown
[00:47] <ajmitch> was trying to browse to http://bazaar.launchpad.net/~markjtully/askubuntu-lens/precise/files
[00:48] <Anxi80_> is a team required for starting a project on launchpad or can I just jump right in as a lone dev?
[00:51] <lifeless> you can just jump right in.
[00:54] <spm> lifeless: ^^ it's only ajmitch, I'm inclined to ignore the reporting of issues.
[00:54] <spm> bah. it's 503ing for me too.
[00:54] <ajmitch> spm: be a good boy & fix it for me :P
[00:54] <spm> heh
[00:55] <spm> restarting CB2, as a Q&D check
[00:55] <spm> no change, CB1 bouncing
[00:56]  * ajmitch mashes refresh
[01:00] <lifeless> alerts posted.
[01:00]  * ajmitch obviously did a good job of breaking it then
[01:10] <spm> ajmitch: should be super green again
[01:11] <ajmitch> thanks, works for me
[01:50] <cody-somerville> Did branches on lp use to have a rss feed of commits? I thought they did but I can't seem to find how to access it for a branch.
[01:52] <spm> cody-somerville: pretty sure they did. lemee check my feeds
[01:53] <spm> http://feeds.launchpad.net/<project?>/branches.atom"
[01:54] <spm> revisions.atom was another
[01:54] <spm> this still seems to be in the source of code.lp.net/project too
[01:54] <spm> html source, as in.
[01:57] <cody-somerville> cool, thanks
[01:58] <wgrant> cody-somerville: Browsers handily dropped the RSS icon that they all used to have.
[02:00] <michaelh> lifeless: hey, bzr branch lp:gdb-linaro/7.4 inside a shared repo is terribly slow.  Would you mind seeing if you see the same?
[02:03] <lifeless> michaelh: a shared repo of gdb, or?
[02:03] <michaelh> lifeless: mkdir gdb-linaro; cd gdb-linaro; bzr init-repo .; bzr branch lp:gdb-linaro/7.4
[02:04] <lifeless> well, I'd expect the first one to be a bit of a doozy.
[02:04] <lifeless> there is a known bug where branching into an empty shared repo does too much history walking before streaming.
[02:05] <michaelh> lifeless: OK.  It's sitting there at 1 kB/second.  Cloud is a bit faster at 4 kB/s as the round trip is less
[02:07] <lifeless> thats glacial isn't it
[02:07] <lifeless> let me ask around a bit
[02:08] <lifeless> michaelh: how long as it been doing that ? Like, when did you start the operation ?
[02:08] <michaelh> lifeless: half an hour ago?
[02:08] <lifeless> ok, so post the shenanigans
[02:09] <michaelh> "  5688kB     1kB/s |"
[02:09] <michaelh> It's no faster from inside the DC.  bzr 2.1.4 on peony is sitting at 1 kB/s
[08:16] <czajkowski> wgrant: is this possible to do for soren ? https://answers.launchpad.net/launchpad/+question/202182
[08:23]  * maxb doubts it
[08:24] <wgrant> Yeah, not really. We could do it with a bit of fairly awful SQL, but it's not yet a week old, so it can't be that ingrained...
[08:27] <soren> wgrant: Failing that, can we rename the user so that I can create a team in its place?
[08:27] <czajkowski> soren: morning
[08:27] <wgrant> soren: You can rename the user if you delete the PPA.
[08:28] <soren> wgrant: Ah, ok. I thought it required special privs when there were (even deleted) PPA's involved.
[08:28] <soren> czajkowski: o/
[08:28] <wgrant> soren: No. You just have to wait 10 minutes or so for the PPA to be completely removed from disk
[08:29] <soren> wgrant: Cool.
[08:29] <soren> wgrant: How awful would it be to transplant the gpg key?
[08:30] <soren> wgrant: Like on a scale from 0 to I'd-rather-gorge-my-eyes-out-with-a-rusty-spoon?
[08:30] <wgrant> soren: That is evil, but we can probably do it.
[08:34] <soren> wgrant: Is it something you can do or do I need to track someone else down? I'd like to have that bit happen rather soon after I rename the user and create the team instead, so I'll wait until it's a good time for you (or whoever).
[08:43] <wgrant> soren: Talking to people about it.
[08:58] <soren> wgrant: Wonderful, thank you.
[09:35] <wgrant> soren: So, I have approved SQL to do the key copy. We've got a DB update in 25 minutes, so we should probably do the actual time-sensitive bit after then. But you can start deleting the PPAs, renaming the person and creating the new team whenever -- just don't create the new PPA yet.
[10:27] <diwic> Hi, code imports usually start really quickly, but this one does not even though the code import machines seem not to be extremely busy: https://code.launchpad.net/~ubuntu-audio-dev/alsa-driver/tiwai-trunk2
[10:31] <wgrant> diwic: They're running at capacity.
[10:32] <diwic> wgrant, fair enough. How long do you expect me to wait (just a rough measure - minutes, hours, days)?
[10:33] <wgrant> diwic: Probably another 10-20 minutes.
[10:33] <diwic> wgrant, okay. Thanks.
[10:35] <wgrant> There's a small backlog due to the DB upgrade and some codehosting issues earlier.
[11:02] <soren> wgrant: sorry, got pulled away for other stuff. Are you still around?
[11:05] <wgrant> soren: Sure.
[11:06] <soren> wgrant: Cool. I'll start deleting PPA's.
[11:06] <wgrant> soren: So, the time-critical thing is that we coordinate creating the PPA and copying the key across. There's a */20 cronjob that we need to avoid, or you'll end up with a new kety.
[11:07] <soren> wgrant: Heh. Ok.
[11:08] <soren> wgrant: I've deleted the PPA's. I guess the job that removes them from disk is a */10 one?
[11:08] <wgrant> soren: */5, but it occasionally gets skipped.
[11:08] <soren> wgrant: Ok. As soon as that has run, it should let me rename the user?
[11:11] <wgrant> soren: Yep.
[11:11] <soren> wgrant: Anyways, it'll probably let me rename the user in a few minutes. I'll do so and at :22 past the hour, I'll create the new team.
[11:11] <soren> That should give us plenty of time for the transplant.
[11:12] <wgrant> Indeed.
[11:14] <soren> User renamed.
[11:18] <wgrant> Excellent.
[11:22] <soren> wgrant: Team created.
[11:22] <wgrant> soren: Ready to go?
[11:22] <wgrant> Great.
[11:22] <soren> wgrant: Do I need to create a PPA first, too?
[11:23] <wgrant> Yep, in a sec.
[11:23] <soren> Alright.
[11:24] <wgrant> soren: Go for it.
[11:24] <wgrant> Just one for now.
[11:24] <wgrant> The other one will inherit it if it's created after the first one is set.
[11:25] <soren> wgrant: https://launchpad.net/~cisco-openstack-mirror/+archive/cisco-proposed
[11:26] <wgrant> soren: https://launchpad.net/api/devel/~cisco-openstack-mirror/+archive/cisco-proposed looks good.
[11:30] <soren> wgrant: Indeed. I'll try uploading something to see how it goes.
[11:48] <soren> wgrant: I've made a couple of uploads... They're not turning up.
[11:48] <soren> wgrant: Nor am I getting rejection e-mails.
[11:51] <wgrant> soren: Ah, someone's uploaded a few hundred language packs that are clogging up the queue.
[11:52] <wgrant> 713 so far...
[11:52] <wgrant> Must be nearly done.
[11:53] <wgrant> It's just finished.
[11:56] <wgrant> soren: 2012-07-04 11:56:13 DEBUG     Subject: [PPA cisco-openstack-mirror-cisco-proposed] [ubuntu/precise] qemu-kvm 1.0+noroms-0ubuntu13+cisco1 (Accepted)
[12:02] <soren> wgrant: Ah, lovely.
[20:26] <beuno> abentley, hi!  do you happen to have any secret plans to allow setting a commit message on merge proposals with lp-propose?
[20:26] <abentley> beuno: Specify -m
[20:27] <beuno> abentley, of course, I should learn to read
[20:27] <beuno> yay
[20:27] <beuno> thanks
[20:27] <abentley> :-)
[20:27] <abentley> beuno: np.