=== kitterma is now known as ScottK
[01:59] <pitti> Good ... ungodly hour of the day
[02:00] <sarnold> hey pitti :) a pal in duesseldorf went to bed just two hours ago..
[02:00] <sarnold> you're up entirely too early even by your usual standards :)
[02:01] <pitti> yeah, I know.. I've been tossing around for an hour already, can't sleep
[02:02] <sarnold> I hate that :(
[02:02] <pitti> slangasek: you mean the regressions on i386/amd64? as arm and ppc always failed; that can't be LXC, as these are full VMs
[02:03] <pitti> slangasek: "OSError: [Errno 14] Bad address" in the two test.test_socket.Recvmsg* tests, hmm; doesn't immediately tell me anything
[02:03] <pitti> should even be the same kernel (trusty) on build and test
[02:06] <pitti> weird that .2 has never been run
[03:11] <slangasek> pitti: hmm ok.  I'm inclined to pass them to get this python3.4 SRU out, given that they passed on the package build; unless you see a reason not to
[03:11] <slangasek> sadly, one of the SRU-linked bugs is specifically about testsuite enablement
[03:12] <slangasek> (LP #1264554)
[03:12] <ubottu> Launchpad bug 1264554 in python3.4 (Ubuntu Trusty) "python3.4 autopkg test failures" [High,Fix committed] https://launchpad.net/bugs/1264554
[03:21] <sunweaver> robert_ancell: hi!
[03:22] <sunweaver> I have just seen that you requested access to collab-maint a while ago.
[03:22]  * sunweaver writes with his Debian Frontdesk hat on.
[03:22] <sunweaver> You normally need a DD or a DM to sponsor such requests.
[03:25] <sunweaver> As I have seen various portions of your code (actually, in one of my upstream projects I have started forking Unity Greeter... ähemm...) I can imagine signing that request for you.
[03:25] <sunweaver> If you have a DD around you, who could send that mail, that would be more appropriate, though.
[04:27] <pitti> slangasek: FWIW, this reproduces perfectly well in local qemu, so it's not related to the production environment
[04:33] <slangasek> pitti: ok.  does it happen to also be reproducible with the ~14.04.1 package that previously passed?
[04:34] <hyperair> huh, collab-maint requires DD/DM sponsorship now?
[04:34]  * hyperair thought anyone could join collab-maint
[04:35] <pitti> slangasek: that's not published anywhere, but I'll re-run, fish out hte debs from LP and downgrade; hang on
[04:35] <Unit193> hyperair: https://lists.debian.org/debian-devel-announce/2015/08/msg00008.html
[04:37] <hyperair> i see
[04:37] <hyperair> thanks
[04:37] <Unit193> sure thing.
[04:37]  * hyperair should pay more attention to d-d-a
[04:39] <Unit193> Not actually subscribed, I follow via archives.
[04:45] <pitti> slangasek: nope, they fail the same way; kernel or underlying lib change?
[04:45] <slangasek> not too many other libs underneath
[05:59] <dholbach> good morning
=== marcusto_ is now known as marcustomlinson
=== enrico_ is now known as enrico
[06:44] <tjaalton> is there a bug about nfs mounts not getting mounted on wily?
[06:44] <tjaalton> just installed a fresh machine and seeing this
[06:46] <tjaalton> seems like a race
[06:46] <tjaalton> trying to mount before it can resolv the server hostname
=== shuduo-afk is now known as shuduo
[07:01] <seb128> tjaalton, I didn't see one, doesn't mean there isn't though ;-)
[07:02] <seb128> dpm, pitti, wgrant, saw my question yesterday about evolution translations?
[07:02] <wgrant> seb128: Are you sure they haven't been imported and pruned already?
[07:02] <dpm> morning seb128
[07:03] <pitti> seb128: sorry, missed it
[07:03] <dpm> sorry, I didn't have the chance to look at it last night
[07:03] <seb128> wgrant, unsure
[07:03] <pitti> seb128: répéter SVP?
[07:03] <dpm> seb128, when did you do the manual import?
[07:03] <seb128> wgrant, https://translations.launchpad.net/ubuntu/wily/+source/evolution/+imports has no .po import listed
[07:03] <seb128> pitti, ^ why is that not importing the .po from the source
[07:03] <wgrant> https://translations.staging.launchpad.net/ubuntu/wily/+source/evolution/+imports
[07:03] <pitti> the "failed" you mean?
[07:03] <seb128> no
[07:03] <wgrant> There were some pot autoimports on the 15th
[07:04] <seb128> it doesn't import the actual upstream translations
[07:04] <seb128> I mean the translations
[07:04] <wgrant> What are the paths in the tarball?
[07:04] <seb128> not the template
[07:04]  * wgrant goes digging.
[07:04] <seb128> the template is fine
[07:04] <seb128> but e.g fr misses some 570 strings
[07:04] <seb128> where the package has the translations
[07:05] <dpm> seb128, hm, there still seem to be 2 templates. For which one did you do the manual import, for 'evolution' or 'evolution-3.16'?
[07:05] <seb128> dpm, I tried to upload a fr.po yesterday, but apparently nowadays launchpad rejected those if they are not tagged
[07:05] <seb128> dpm, I didn't do manual imports
[07:05] <dpm> seb128, I'll removed the '*-3.16' one now
[07:05] <seb128> thanks
[07:05] <seb128> there were 2 templates in the import queue
[07:05] <seb128> and I accepted them
[07:05] <wgrant> Downloading the tarball to investigate, will be a few minutes.
[07:05] <seb128> for some reason the default template name was -3.16
[07:05] <seb128> wgrant, thanks
[07:06] <dpm> yeah, it's a bit of a bummer that the template name is versioned, that doesn't go well with LP :/
[07:06] <dpm> we need to fix it every single release
[07:06] <dpm> same for e-d-s, IIRC
[07:06] <seb128> yeah, but we had fixed it
[07:06] <seb128> we discussed that in september if you remember
[07:07] <pitti> seb128: would it perhaps be more practical to patch evo to use an unversioned template name? or too much to patch?
[07:07] <tjaalton> uh, default crypted install creates a ridiculously small /boot (237M)
[07:07] <seb128> pitti, I guess we could
[07:08] <pitti> meh, bluez fails to install in a VM now
[07:08] <dpm> that'd help us in not having to manually do the changes every release in LP, then the templates would be imported correctly on a new release and avoid the duplicate templates
[07:09] <pitti> bluetoothd[1640]: Failed to access management interface
[07:09] <pitti> bluetoothd[1640]: Adapter handling initialization failed
[07:09] <pitti> and that fails apt
[07:09] <dpm> wgrant, I'm going to move the -3.16 template out of the way and fix the path on the 'evolution' template to point to 'po/evolution-3.16'
[07:09] <wgrant> dpm: Be wary of the POs, though.
[07:09] <wgrant> Those paths must match also, and they're not versioned.
[07:09] <wgrant> So if the current -3.16 template's POs have stolen the paths, we're in trouble.
[07:10] <pitti> ah, bug 1506774
[07:10] <ubottu> bug 1506774 in bluez (Ubuntu) "package bluez 5.35-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1506774
[07:10] <dpm> wgrant, not sure if they have, if they have, then I'll just have some fun doing manual .po file approvals :/
[07:11] <wgrant> I wonder if the POs might have been skipped because they would have tried to import into the disabled template, or something.
[07:11] <seb128> dpm, well the .po are not in the queue atm
[07:11] <wgrant> There's nothing else obvious wrong.
[07:11] <dpm> but it seems they might not have, as the Catalan translation for -3.16 is empty
[07:12] <seb128> https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server/+imports
[07:12] <seb128> I guess that is buggy as well?
[07:12] <dpm> oh, the path is already 'po/evolution-3.16.pot' on the 'evolution' template, so it seems we had fixed it indeed
[07:12] <seb128> but that one only has one template
[07:12] <dpm> so I think the issue is that I still hadn't moved the 'evolution-3.16' template out of the way, so LP was seeing two differently named templates with the same path
[07:13] <wgrant> dpm: Where did you put the evolution-3.16 template?
[07:13] <wgrant> I can't find it now.
[07:13] <dpm> wgrant, I haven't put it anywhere yet
[07:13] <dpm> I was going to, though
[07:13] <dpm> wgrant, https://translations.launchpad.net/ubuntu/wily/+source/evolution/+pots/evolution-3.16/+edit
[07:13] <wgrant> Oh it helps if I don't typo it.
[07:14] <dpm> :)
[07:14] <dpm> wgrant, so I'm going to do this now with this template ^ https://wiki.ubuntu.com/UbuntuTranslationsCoordinators/Actions/LpTemplateAdministration#Moving_templates_out_of_the_way
[07:14] <wgrant> Hm.
[07:14] <wgrant> I'm a little surprised that it allows them both to have the same path...
[07:14] <wgrant> Yeah, moving it away is "fine" for now.
[07:19] <dpm> wgrant, seb128, done. I assume the next upload (manual or via packages) should import all translations fine. Looking at e-d-s now
[07:19] <seb128> dpm, before yesterday only one template was listed, I seemed to have created the other one by accepted  the .pot in the queue, but translations were not imported, did you change something wrong on the non -3.16 template?
[07:20] <dpm> seb128, for which package now, evolution or e-d-s?
[07:20] <seb128> evolution
[07:20] <seb128> e-d-s I didn't touch
[07:20] <seb128> so it's in a less confusing state
[07:20] <dpm> me neither
[07:20] <seb128> like no duplicate template there
[07:20] <dpm> seb128, I think here's what happened:
[07:21] <dpm> - evolution was fine: it had the right template name ('evolution') and the right path 'po/evolution-3.16'
[07:22] <dpm> - On manually approving the 'evolution-3.16' template in the queue, LP created the second, duplicate template, and named it 'evolution-3.16'
[07:22] <dpm> - Both templates had a path of 'po/evolution-3.16.pot', that's what LP looks at when importing the PO files and deciding where they should go
[07:22] <dpm> - On seeing that the evo source package had two templates with the same path, it didn't know what to do
[07:23] <dpm> that's my guess
[07:23] <seb128> k
[07:23] <seb128> well that can't be the issue with e-d-s
[07:23] <dpm> In general it's best not to manually approve - it might take a while, but LP will do the auto-approval
[07:23] <seb128> and that one also fails to import translations
[07:24] <dpm> yeah, I don't know what's up with e-d-s
[07:24] <dpm> it looks fine as far as I can tell
[07:24] <seb128> :-/
[07:24] <dpm> just one template, with the correct path
[07:24] <seb128> evolution was in the same state before I screwed up things yesterday
[07:24] <seb128> so I guess up for wgrant to debug on the launchpad side
[07:25] <dpm> let me try to do a manual upload myself
[07:51] <pete-woods> pitti: morning. I've got yet another bugfix for the network-manager template here: https://github.com/martinpitt/python-dbusmock/pull/16/files
[07:57] <dpm> wgrant, I tried to manually upload translations to the evolution template and got OOPS-7aeb70f9bcfa7221a50373627e365a97 - could you tell me if the upload was nevertheless successful, or should I do another upload?
=== oSoMoN_ is now known as oSoMoN
[07:58] <wgrant> dpm: That was a timeout on the browser upload. You'll need to retry.
[07:59] <dpm> ok, retrying
[07:59] <dpm> still timeout :(
[07:59]  * dpm tries chromium
[08:01] <dpm> wgrant, hm, tried it with Chromium, similar result, but this time the upload was finished (Chromium showed me the percentage), but got LP "Timeout error" with OOPS-967981d90913c8f6e9b989c83b5fbdcd
[08:02] <wgrant> dpm: I suspect it's unlikely that such a large upload (many files, mostly) will succeed :/
[08:04] <dpm> wgrant, hm, so that effectively means that we cannot do manual translation uploads anymore? (i.e it's not uncommon for packages to have 40+ po files)
[08:04] <wgrant> dpm: This hasn't changed since 2011 or so.
[08:05] <dpm> wgrant, I've done manual uploads in the past, although the last one I did might have well been 1 or 2 years ago
[08:05] <wgrant> How many files in total does the tarball contain?
[08:05] <dpm> let me check
[08:05] <wgrant> The total data size also matters somewhat.
[08:05] <dpm> wgrant, 96 files, ~14MB
[08:06] <wgrant> Hmm.
[08:06] <dpm> well 14MB compressed, that is
[08:06] <wgrant> dpm: I can try increasing the timeout once sysadmins are a bit less tied up.
[08:08] <dpm> wgrant, or happy to provide the .tar.gz file if the translations can be uploaded in any way. seb128, I assume you tried a manual upload because we cannot do uploads so close to the release date, was your tarball as big as mine and did it not time out?
[08:10] <seb128> dpm, I only tried to upload the fr.po but at first it's because I though french translations were outdated for some reason
[08:10] <seb128> dpm, wgrant, what's the next step to figure out why e.g e-d-s is not importing translations from package uploads?
[08:10] <wgrant> dpm: There's no other way.
[08:10] <wgrant> seb128: I need to find time to look through the uploader to work out why the files are being skipped.
[08:10] <wgrant> They don't meet the obvious blocking criteria.
[08:10] <pitti> pete-woods: ah, thanks! note that wily is in final freeze, this might not land any more
[08:10] <dpm> seb128, oh, I can just do the fr.po upload for test, that shouldn't time out
[08:11] <seb128> dpm, I could as well, I just need to add a tag so launchpad doesn't reject it
[08:11] <seb128> since apparently there was some feature added to block upload of non-launchpad-exported .po files
[08:11] <seb128> or import of those rather
[08:11] <seb128> dpm, but I'm not really interested in fixing french only
[08:12] <dpm> seb128, yes, or if you upload it in a tarball together with the .pot file it should work, though
[08:12] <dpm> seb128, well, but at least that will confirm whether the deduplication of the template worked
[08:13] <seb128> dpm, e-d-s has no template duplication and the same issue
[08:13] <seb128> but yeah
[08:16] <dpm> seb128, yeah, as I said, after looking at it, I don't know what I could possibly do with e-d-s, but it'd be good to confirm if evolution uploads are workin
[08:16] <dpm> g
[08:16] <dpm> :)
[08:16] <seb128> +1
[08:17] <dpm> seb128, wgrant, https://translations.launchpad.net/ubuntu/wily/+source/evolution/+imports - I uploaded the 3 files, will be watching in the next couple of hours if the importer does its work
[08:18] <pete-woods> pitti: the stable overlay ppa is open for both vivid and wily now
[08:18] <pete-woods> so you can land it there for both series?
[08:18] <pete-woods> I think the plan is then to migrate all the wily packages from the PPA into X
[08:54] <infinity> sitter: Around?
[08:55] <sitter> infinity: yes
[08:55] <infinity> sitter: Looking at your ubuntu-release-upgrader upload.  If you're hitting a 403 for the release notes, that might be a bug on our end? :P
[08:55] <infinity> sitter: Do you have the URL it's reuqesting?
[08:55] <infinity> requesting, too...
[08:56] <infinity> Oh, or it might be the new python-versus-urllib mandatory ceritificate verification thing, if it's https.
[08:57] <sitter> infinity: http://archive.ubuntu.com/ubuntu/dists/wily/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html?lang=en_US&os=ubuntu&ver=15.10
[08:57] <Laney> BTW I accepted it but will leave it blocked in the hope that we can fix it this end
[08:59] <infinity> sitter: urllib gets a 403 on that?  That makes no sense...
[09:00] <sitter> tell me about it :P
[09:01] <rbasak> hallyn_: you just need a DD to sponsor your netcf FTBFS fix, right, and then we can sync it in?
[09:01] <sitter> I also tried with the vivid URL and that also yields 403, so I am not convinced this actually ever worked (I think I switched to the HTML URI in vivid)
[09:01] <rbasak> hallyn_: maybe doko can help with that if xnox is unavailable?
=== zequence_ is now known as zequence
[09:03] <sitter> infinity: it should be 100% reproducible with python3-pyqt5 installed and sudo do-release-upgrade -m desktop -f DistUpgradeViewKDE
[09:03] <Laney> In [9]: urllib.request.urlopen('http://archive.ubuntu.com/ubuntu/dists/wily/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html?lang=en_US&os=ubuntu&ver=15.10').code
[09:03] <Laney> Out[9]: 200
[09:03] <sitter> sudo do-release-upgrade -m desktop -f DistUpgradeViewKDE -d even
[09:09] <sitter> http://paste.ubuntu.com/12875585/
[09:09] <sitter> oh god
[09:10] <sitter> Laney, infinity: it's apt-cacher intercepting and mangling the request
[09:11] <Laney> ...
[09:11] <infinity> sitter: Right, deleting from proposed then? :P
[09:11] <sitter> infinity: yes please
[09:12] <sitter> infinity: also SRU 1:15.04.14.3 from vivid-proposed
[09:14] <infinity> sitter: Both gone.
[09:14] <sitter> thanks and sorry for the noise
[09:16] <Laney> sitter: Might be worth an apt-cacher bug though
[09:25] <sitter> yup, but 1507953
[09:25] <sitter> bug 1507953
[09:25] <ubottu> bug 1507953 in apt-cacher-ng (Ubuntu) "cacher mangles release notes queries when set as proxy" [Undecided,New] https://launchpad.net/bugs/1507953
[09:26] <rsalveti> apw: were you able to check my latest upload for rtl8812au? license should be fine now
[09:27] <apw> rsalveti, ahh not seen it will have a look
[09:27] <rsalveti> apw: cool, thanks
[09:53] <dholbach> Laney, could it be that http://reqorts.qa.ubuntu.com/reports/sponsoring/ is broken?
[09:54] <Laney> ES KANN NICHT SEIN
[09:54] <Laney> ah crap :)
[09:54] <Laney> can you run it manually and see what happens?
[09:54] <Laney> I changed to the devel api - maybe needs re-authing?
[09:55] <dholbach> hum
[09:57] <Laney> I thought I checked after pushing that it was working...
[09:57]  * Laney sucks
[09:57] <dholbach> no you don't
[10:14] <apw> rsalveti, i assume you have a device and have tested the resulting binaries from this source ?
[10:18] <jamespage> pitti, I think we can drop golang-go.net-dev source package - the new source package has a transitional package for golang-go.net-dev
[10:22] <dholbach> Laney, "No such source package: 'ubuntu-cve-tracker'."
[10:22] <Laney> huh
[10:22] <Laney> let me look at this
[10:30] <rsalveti> apw: yup, that's how I'm accessing internet here :-)
[10:31] <pitti> jamespage: oh, indeed; I'll remove the old one then, thanks
[10:31] <jamespage> pitti, np - thankyou
[10:33] <pitti> jamespage: done
[10:35] <infinity> rsalveti: Accepted.
[10:35] <rsalveti> infinity: apw: awesome, thanks
[10:36] <infinity> rsalveti: Sorry about the delay but, hey, I promised it would make the release, and here you are. ;)
[10:36] <rsalveti> infinity: haha, indeed, thanks man
=== _salem is now known as salem_
[11:59] <Laney> dholbach: hopefully fixed...
[12:32] <rsalveti> infinity: just missing the bin new approval now :-)
[12:57] <Laney> dholbach: ya, it's up to date
[12:57] <Laney> and quite large :/
[12:57] <Laney> part of that is because my new code picks up more branches now
[13:06] <dholbach> Laney, does that mean I should run it a bit less often now?
[13:06] <Laney> dholbach: nope, it means we should clean out more stuff
[13:06] <dholbach> right
[13:06] <Laney> I mean large in terms of number of items
[13:07] <dholbach> I'll send a mail to u-devel
[13:07] <dholbach> asking for some last-minute cleanup and stuff we want in as opposed to getting it in via sru
[13:31] <rbasak> Is there a component-mismatches report for movements from main to universe?
[13:31] <rbasak> python-jingo is in main, but AFAICT isn't seeded or pulled in by a seed.
[13:32]  * rbasak isn't sure what he's missing
[13:34] <cjwatson> That's kind of what the component-mismatches report is.
[13:34] <rbasak> That's what I thought, but I don't understand why python-jingo doesn't appear in there.
[13:34] <cjwatson> It's a build-dependency of python-django-compressor.
[13:35] <rbasak> But http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.wily/rdepends/python-jingo/python-jingo doesn't seem to go any further than that - doesn't end up at a seed?
[13:35] <cjwatson> That'd just be a bug in the rdepends output
[13:36] <cjwatson> Follow to http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.wily/rdepends/python-django-compressor/
[13:36] <cjwatson> Then http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.wily/rdepends/python-django-compressor/python-compressor gets you a seed
[13:37] <rbasak> Ah OK, that is what I was missing. I assumed that no rdepends output meant that python-django-compressor was in universe.
[13:37] <rbasak> Thanks.
[13:51] <hallyn_> rbasak: i think xnox did it last night, but thanks
[13:57] <xnox> hallyn_: well, and it was rejected cause i uploaded the old one, instead of the new one.
[13:57] <xnox> hallyn_: i re-uploaded again this morning
[13:57] <xnox> hallyn_: you should have accept email about it.
[13:59] <hallyn_> xnox: thanks.  yeah i saw that reject last night, but this morning saw the package list on mentors was empty, so assumed you'd pushe dit
[14:02] <rbasak> hallyn_: thanks. Not sure what that means to fix the FTBFS in Ubuntu though. Is that upload suitable to sync during final freeze?
[14:03] <xnox> hallyn_: Serge Hallyn <serge.   hallyn@ubuntu.com>,
[14:03] <xnox> netcf_0.2.8-1_source.changes ACCEPTED into unstable
[14:03] <hallyn_> rbasak: did i not push a fix for the ftbfs to ubuntu?
[14:03] <hallyn_> maybe i didn't, as i was waiting fo rhtis
[14:04] <xnox> hallyn_: and https://tracker.debian.org/news/720083 with as almost built everywhere https://buildd.debian.org/status/package.php?p=netcf
[14:04] <rbasak> hallyn_: not that I'm aware of but maybe I'm missing something?
[14:05] <hallyn_> rbasak: prolly not.  i can push the minimal fix.
[14:05] <rbasak> OK. Thanks!
[14:06] <xnox> hallyn_: so... are you ready to be a DM with upload right to the package just by yourself in debian?
[14:06] <hallyn_> xnox: was replying to email.  i am, i had asked slangasek about that for netcf+cgmanager
[14:06] <hallyn_> (but he's pretty busy :)
[14:06] <xnox> hallyn_: yeah interviewing people
[14:06] <hallyn_> heh
[14:07] <xnox> lol
[14:07] <hallyn_> suppose it could be worse, i.e. if no applicants
[14:07] <xnox> hallyn_: i guess i should sign your key as well to get you into the debian web of trust.
[14:07] <xnox> hallyn_: well, i don't know. looking at canonical job feed the foundation postings seems to be ever open.
[14:08] <hallyn_> xnox: at fosdem maybe?
[14:08] <xnox> hallyn_: i think i said i would, but i didn't i don't think
[14:08] <xnox> hallyn_: my main key is offline, so i'll need another location based reminder to do it.
[14:10] <hallyn_> not sure what that means -s end you a postcard? :)
[14:20] <pitti> dholbach: uh, MPs from 2012 ;)
[14:20]  * pitti cleans up a bit
[14:20] <dholbach> time to reject :)
[14:20] <dholbach> thanks pitti!
[14:27] <bdmurray> pitti: there seem to be some outstanding language-pack SRUs - https://launchpad.net/ubuntu/+source/language-pack-ja. infinity mentioned you usually take care of them...
[14:28] <pitti> bdmurray: yes, these are the ones that didn't get tested, so we never published them (https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA)
[14:29] <bdmurray> pitti: bug 1311396 mentions testing ja.
[14:29] <ubottu> bug 1311396 in language-pack-ug (Ubuntu Precise) "broken translations results in traceback in new release notification" [High,Triaged] https://launchpad.net/bugs/1311396
[14:31] <pitti> dholbach: what was that fix, btw? all those MPs like https://code.launchpad.net/~soren/nova/essex-stable-catchup/+merge/108049 are *not* against ubuntu
[14:31] <pitti> bdmurray: ah, thanks!
[14:32] <Laney> pitti: It lists all merges that uploading teams can do
[14:33] <Laney> so ~ubuntu-server-dev has to take care of this MP
[14:33] <pitti> Laney: that seems a bit excessive
[14:33] <Laney> well it's a merge proposal that has been ignored for years
[14:33] <pitti> Laney: well, maybe it's just because of all the old cruft and it'll get useful in the future
[14:33] <Laney> which is pretty crap for the person that proposed it
[14:33] <Laney> at least now it is in a list
[14:33] <pitti> *nod*
[14:33] <pitti> but most sponsors won't be able to actually do such a thing
[14:34] <pitti> i. e. merge into a non-ubuntu branch
[14:34] <pitti> it woudln't actually land anywhere
[14:34] <pitti> and most folks won't have commit rights either
[14:34] <Laney> well their review is requested
[14:34] <Laney> one way to close it is to deal with that one way or another
[14:36] <Laney> It's still tied to upload rights - i.e. core-devs should be able to take care of the MPs there
[14:37] <Laney> should be more useful after we clean up all these old ones at the top
[14:38] <Laney> jamespage: can your team help us to clear out the ancient openstack MPs that I just made come up on http://reqorts.qa.ubuntu.com/reports/sponsoring/ maybe? :)
[14:38] <Laney> or should we mass-reject them all, or something?
[14:41] <pitti> Laney: I'm going through invidividually ATM
[14:41] <pitti> Laney: and check if they were already uploaded through some different means, are obsolete, etc.
[14:42] <pitti> e. g. the ubuntu-server test cases have some fairly recent commits by cyphermox; not sure if that is still a thing, I thought we moved everything to autopkgtest
[14:42] <pitti> but I'd keep these for now
[14:43] <Laney> yeah, we have those still for the iso smoke testing
[14:44] <Laney> pending -> current thingy
[14:45] <cyphermox> pitti: that still was used for the pending-current job
[14:45] <cyphermox> yep
[14:45] <cyphermox> and I intend to fix it harder during the X cycle.
[14:51] <pete-woods> pitti: found another bug in the settings management of the NM template: https://github.com/pete-woods/python-dbusmock/pull/7/files
[14:52] <pete-woods> (hmm, I think I stacked the changes badly :$)
[14:55] <pitti> Laney: ah, e. g. https://code.launchpad.net/~adri2000/python-heatclient/bash-completion/+merge/254921 is the first that actaully seems good and relevant :)
[14:56] <Laney> sorry for the noise :(
[14:56] <Laney> we would have not missed e.g. https://code.launchpad.net/~logan/ubuntu-gnome-default-settings/eog-override/+merge/259707 if we had this earlier
[14:57] <pitti> Laney: yeah, seems good overall -- we just need to get the relevant teams to actually look at this
[14:57] <Adri2000> pitti: interesting, I completely forgot about that :)
[15:14] <xclaesse> mardy, after upgrade 15.04->15.10 my google account disappeared from evolution
[15:14] <xclaesse> mardy, it's still configured in UOA
[15:33] <jamespage> Laney, yeah - I'll look
[15:34] <Laney> jamespage: thanks - pitti said he'd closed a load too
=== dgadomski_ is now known as dgadomski
=== bladernr_ is now known as bladernr
[15:39] <mardy> xclaesse: is evolution enabled there (in the account)?
[15:41] <xclaesse> mardy, yes
[15:42] <xclaesse> mardy, just rebooted now, and my account is back...
[15:42] <xclaesse> hm, but it re-download all my emails :(
[15:43] <mardy> xclaesse: did you install some additional package meanwhile?
[15:44] <xclaesse> nothing related to evolution
[15:44] <Riddell> mvo: this ok? seems to contain a suspicious amount of noise http://launchpadlibrarian.net/221784898/ubuntu-release-upgrader_1%3A15.10.11_1%3A15.10.12.diff.gz
[15:48] <mvo> Riddell: that looks ok, the demotion detection is automatcially run during build
[15:49] <Riddell> mvo: thanks, accepted
[15:50] <infinity> Riddell: I rejected it, actually. :P
[15:51] <infinity> Riddell: And you accepted it from the rejected queue?
[15:51] <infinity> Riddell: rly?
[15:51] <Riddell> um, I'm pretty sure I didn't
[15:51] <Riddell> why was it rejected?
[15:51] <infinity> Riddell: Your email explained it. :P
[15:52] <infinity> Riddell: The .11 changes weren't reverted.
[15:52] <infinity> Riddell: Despite .11 being explicitly removed from -proposed as a bad change.
[15:52] <infinity> Riddell: So, please give me a .13? :P
[15:55] <Riddell> infinity: ah, someone didn't update bzr, I'll do that now
=== nhh is now known as nhandler
[16:21] <chiluk> infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481490 has now dropped into -updates for linux-lts-utopic, are you going to have time to integrate those kernels?
[16:21] <ubottu> Launchpad bug 1481490 in linux-lts-utopic (Ubuntu) "Add sfc to nic-modules udeb" [Undecided,Fix committed]
[16:22] <infinity> chiluk: I can find time, probably, but also in the middle of release week, so a bit swamped.
[16:27] <dholbach> can somebody moderate my mail to u-d-a@ through?
[16:27] <cjwatson> dholbach: done
[16:27] <dholbach> thanks!
[16:30] <coreycb> arges, can you reject horizon from the vivid upload queue?  we have an update coming to that.
[16:30] <arges> coreycb: ok
[16:30] <chiluk> infinity: yeah I figured as much.. just wanted to remind you.
[16:30] <coreycb> arges, thanks
[16:30] <arges> coreycb: done
[16:42] <rbasak> doko: https://launchpad.net/ubuntu/+archive/test-rebuild-20151001/+build/8057346 should succeed with the python-django in Wily now. Not sure if that'll get synced from Wily to the test archive?
[16:42] <infinity> pitti: You still around?
[16:44] <cjwatson> rbasak: that would only be needed if the fix was in python-jingo - the test rebuild uses the primary archive for its build-deps
[16:44] <cjwatson> rbasak: I've retried that build
[16:51] <cjwatson> (and built)
[17:02] <rbasak> cjwatson: ah. Thanks!
[17:32] <hallyn_> ok an glib ppl around who could tell my why the string "/user.slice/user-1000.slice/session-1.scope" (read from a procfile with getline()) would be used as "[Invalid UTF-8]" ?
[17:45] <hallyn_> d'oh
[17:45] <hallyn_> nm
=== Tm_Tr is now known as Guest5920
[17:58] <rcj> arges, Where are the directions for building the kernel package?  I need to build wily patched with https://lkml.org/lkml/2015/8/11/742 to see if my external thinkpad keyboard starts scrolling again.
[18:00] <rcj> arges, I'm asking because I'm finding 4 different kernel wiki pages and can't recall which is the right one to build the same code you'd get from installing the wily kernel
[18:18] <arges> rcj: patch it, ensure you have deps installed and run 'dpkg-buildpackage -d' (that will be _everything_)
[18:18] <arges> rcj: i do 'make deb-pkg -jN' for quick local packages though
[18:23] <rcj> arges, thanks
=== greyback__ is now known as greyback
=== salem_ is now known as _salem
=== _salem is now known as salem_
[20:09] <smoser> anyone know how to make systemd not switch vts back and forth during boot ?
[20:10] <smoser> i'm booting a system like:
[20:12] <smoser>  qemu-system-x86_64 -enable-kvm -device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 -m 1024 -curses -drive file=boot.img,if=virtio -kernel my.kernel -initrd my.initrd -append 'root=/dev/vda1 console=ttyS0'
[20:13] <smoser> and it quite obnoxiously flipps back and forth between vts. i'd like to be able to use the scrollback buffer (shift pg-up). but since vts have been switched thats gone.
[20:15] <arges> smoser: could you add 'vga=current' to kernel cmdline?
[20:15] <smoser> will try
[20:15] <barry> bdmurray: say, could you take a look at https://code.launchpad.net/~barry/ubuntu-release-upgrader/lp1485093 - it might be too late for wily, but i'd like to get it in asap for x so i can upload a fixed pex package
[20:16] <smoser> arges, seems like systemd thinks i want to look at the seabios information.
[20:17] <smoser> $ cat /proc/cmdline
[20:17] <smoser> root=/dev/vda1 ds=nocloud-net;seedfrom=http://104.130.21.57:40885/ console=ttyS0
[20:17] <smoser>  vga=current
[20:17] <bdmurray> barry: I'll have a look.
[20:24] <barry> bdmurray: thanks
=== salem_ is now known as _salem