[00:32] <catbus1> Hi, when will be 14.04.4 released? I don't find it on https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[00:35] <sarnold> catbus1: if 12.04 LTS serves as a guide, february looks likely https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
=== G__ is now known as g
=== g is now known as G
=== imcleod is now known as imcleod_zzz
[05:09] <pitti> Good morning
[05:09] <pitti> jdstrand: a "problem" only insofar that there was a looong test request queue
[05:10] <pitti> jdstrand: the KDE package tests take awfully long, and we got several hundreds of them yesterday, so a lot to catch up with
[05:10] <pitti> bah, yesterday the queue was at 250, now at 340, what happened
[05:11] <pitti> ah, more KDE uploads
[05:11] <pitti> jdstrand: so, it'll catch up eventually
[05:24] <tjaalton> so is mesa stuck in proposed because of the freeze or something else?
[05:33] <tjaalton> ok found it in update_excuses.html, but why doesn't http://autopkgtest.ubuntu.com search show any hits?
[05:37] <tjaalton> sigh arm is slow
[05:37] <pitti> tjaalton: see scrollback from 20 mins ago
[05:38] <pitti> tjaalton: there's also the libopengl-perl regression
[05:40] <tjaalton> which failed three days ago too
[05:40] <tjaalton> so not really a regression
[05:40] <tjaalton> in mesa at leaset
[05:40] <tjaalton> *caused by
[05:42] <tjaalton> though failed for some other reason, now the deps can't be fulfilled
[05:43] <pitti>  libgl1-mesa-glx : Breaks: libopengl-perl (< 0.6704+dfsg-2) but 0.6704+dfsg-1 is to be installed
[05:43] <tjaalton> oh :)
[05:43] <tjaalton> yeah let's sync that then
[05:44] <pitti> tjaalton: https://tracker.debian.org/news/707796 ? looks sensible
[05:44] <tjaalton> yes, forgot the breaks got added recently
[05:46] <tjaalton> is there a way to test these locally first?
[05:47] <pitti> so, I added a second worker on each arm machine
[05:47] <pitti> while this slows down individual tests, this will be a net win on throughput, I do the same on the ppc64el boxes
[05:48] <pitti> tjaalton: build and install it in a wily-proposed schroot?
[05:48] <tjaalton> ah
[05:50] <zyga> good morning
[06:14] <dholbach> good morning
[06:18] <seb128> hey dholbach
[06:20] <dholbach> salut seb128
[06:27] <pitti> infinity: please let me know if you want me to disable testing on armhf temporarily, the backlog is huge (about a day, I'd say)
[06:27] <pitti> infinity: if you want to build beta images today or so
[06:29] <infinity> pitti: Disabling armhf wouldn't hurt, yeah.
[06:29] <pitti> infinity: okay
[06:29] <pitti> seb128, Saviq: ^ FYI
[06:30] <Saviq>  tx
[06:30] <seb128> pitti, thanks
[06:32] <pitti> done
[06:32] <pitti> next britney run should stop showing/caring about armhf
[06:50] <pitti> infinity: ok, lots of valid candidates now
=== nudtrobert1 is now known as nudtrobert
[06:54] <seb128> wgrant, cjwatson, still no wily langpack update, do you know if webops did an export retry yesterday?
[06:56]  * pitti also overrides the boottest regressions while he's at it
[07:00] <wgrant> seb128: 2015-09-22 16:46:06 INFO    Registered the language pack.
[07:01] <wgrant> Looks there to me.
[07:01] <pitti> yes, it's on https://translations.launchpad.net/ubuntu/wily/+language-packs
[07:01] <pitti> seb128: want me to start a manual cron run?
[07:02] <pitti> (for wily it usually runs Friday, as we expect the exports on Thu)
[07:25] <seb128> pitti, yes please, I would like to have those on the beta image
=== tsdgeos_ is now known as tsdgeos
=== athairus is now known as athairuzzz
[08:20] <pitti> seb128: https://launchpad.net/ubuntu/wily/+queue?queue_state=1 is getting the uploads; is there something which you expect in particualr?
[08:22] <seb128> pitti, I was just checking the -fr source
[08:22] <seb128> yes, I was looking to know if evo/eds-3.16 were included
[08:22] <seb128> the .po are in the source
[08:22] <seb128> let's see if that ends up in the binary
[08:31] <seb128> pitti, looking good
[08:31] <seb128> let's see if we can get the langpack updates approved for beta, that would be nice
[08:33] <pitti> seb128: I was going to accept them now
[08:34] <seb128> danke
[08:34] <seb128> can you approved unity-control-center (fix for blutooth pairing) and user-setup (fix for autologin on new installs) as well? ;-)
[08:34] <pitti> infinity: ^ hm, is that alright?
[08:35] <pitti> I just realized the beta is already tomorrow, not next week
[08:35] <seb128> yeah, I got confused by the wiki calendar
[08:35] <seb128> I though the freeze was tomorrow
[08:37] <pitti> seb128: so, I'm not sure how frozen we are; if I get a green light from the RT I can approve the langpacks and the others
[08:37] <seb128> pitti, thanks
[08:37] <seb128> let's see
[08:38] <seb128> I'm still unsure why we freeze things like that rather than just getting in proposed and blocking migration
[08:38] <seb128> like those langpacks could already build
[08:38] <seb128> they are going to be in before release in any case
[08:39] <cjwatson> the reason there's still a short freeze even on -proposed is to avoid people complaining that they needed to build their urgent fix but it FTBFS due to junk in -proposed
[08:39] <cjwatson> that doesn't seem to apply to langpacks though
[08:40] <pitti> I asked in #u-release
[08:40] <cjwatson> that said, there's no -proposed block in place at the moment
[08:48] <pitti> cjwatson: the disabled ("cleaning") lgw builders with the "ongoing neutron problem investigation" is still ongoing, I take it?
[08:48] <pitti> https://launchpad.net/builders/lgw01-11/+edit is a bit confusing
[08:48] <pitti> as the builder seems to be enabled, but in "cleaning"
[08:50] <pitti> then again, lots of other builders are also in "cleaning" and haven't built anything for a week and don't have this note
[08:50] <pitti> https://launchpad.net/builders/lcy01-08/+history -> last build on Sep 18
[08:53] <cjwatson> pitti: Occasionally we run into incidents where the reset request gets lost for one reason or another; it has nothing to do with the previous neutron problem.
[08:53] <cjwatson> pitti: disable/enable typically clears these up; I'll do that now.
[08:54] <pitti> cjwatson: ok, good to know for the next time; thanks
[08:54] <cjwatson> pitti: But "haven't built anything for a week" is just because we have plenty of builder capacity now - the whole build farm has been clean more recently than that.
[08:54] <pitti> so in general that's safe as long as the builder is marked as enabled?
[08:54] <cjwatson> pitti: Well, best leave it to LP folks in case there's some known incident
[08:54] <pitti> cjwatson: ah, ok; (and BTW, this is amazing!)
[08:54] <cjwatson> But normally should be
[08:54] <pitti> ack
[08:56] <cjwatson> pitti: should all be unstuck now
[08:57] <cjwatson> Nice for the special case of being able to build all your language packs in parallel, I suppose :)
=== hikiko-lpt is now known as hikiko
[09:43] <FourDollars> Is it possible to revoke 1.4.10-1ubuntu1 of https://launchpad.net/ubuntu/+source/modemmanager? It didn't fix any issue.
[09:45] <pitti> FourDollars: the only way is to upload an -1ubuntu2 with the change reverted
[09:46] <pitti> FourDollars: or in this case, an -1wily1 (or anything which is bigger than 1ubuntu) so that the next time it auto-syncs
[09:46] <FourDollars> pitti: OK. I see. Thanks for your information.
[09:46] <pitti> 1-1+build1
[09:47] <pitti> FourDollars: 1.4.10-1+build1 is a better version number; it's clearer, and bigger than 1ubuntu1
[09:47] <FourDollars> pitti: I agree.
[09:48] <FourDollars> @BinLi Could you help to do this for wily first? ^^
[09:48] <udevbot> Error: "BinLi" is not a valid command.
[09:48] <FourDollars> BinLi: Could you help to do this for wily first? ^^
[09:52] <FourDollars> pitti: BTW, what is the next version after 1.4.10-1+build1 if we want to fix some issue?
[09:53] <pitti> FourDollars: 1+ubuntu1, I figure
[09:53] <FourDollars> pitti: Thx.
[09:53] <pitti> FourDollars: OTOH, if the last version isn't actually a regression, just a no-op, you don't need to bother much
[09:53] <pitti> FourDollars: would just be nice to somehow remember that this can be synced at the next occasion, instead of merged
[09:54] <FourDollars> pitti: OK.
=== nudtrobert1 is now known as nudtrobert
[09:55] <FourDollars> pitti: Thx for your information again. :)
[10:25] <pitti> tjaalton: ah, new libopengl-perl works again, so mesa propagated
[10:30] <tjaalton> pitti: yeah
[10:38] <BinLi> FourDollars: ok
[11:25] <pitti> PSA: I have to reconstruct http://autopkgtest.ubuntu.com/ again, results will come back in the next hour or two; sorry
[11:59] <tjaalton> pitti: hey, would adding some udev rules for steam controllers belong to systemd?
=== DW-10297 is now known as Teduardo
=== pat_ is now known as Guest88770
=== imcleod_zzz is now known as imcleod
[12:43] <pitti> tjaalton: what do they do?
[12:45] <tjaalton> pitti: good question, the bug doesn't have it attached
[12:45] <tjaalton> https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1498655
[12:45] <ubottu> Launchpad bug 1498655 in systemd (Ubuntu) "Steam Controller support: need read-write access to Valve-owned input event device nodes." [Undecided,New]
[12:45] <tjaalton> but looks like systemd got added already
[12:46] <mdeslaur> pitti, tjaalton: one sec, I'll attach it, I extracted it to take a look
[12:46] <tjaalton> ok good
[12:48] <mdeslaur> attached
[12:55] <jdstrand> pitti: ok, thanks for getting back to me :)
[12:55] <jdstrand> pitti: and hello :)
[12:55] <pitti> hey jdstrand, how are you?
[12:55] <pitti> jdstrand: FTR, I temporarily disabled armhf in britney to not block final beta; and the arm queue is down to 68 now
[12:56] <jdstrand> pitti: I'm doing well, yourself?
[12:56] <jdstrand> pitti: re britney, ok, thanks
[12:56] <pitti> jdstrand: quite fine, thank you
[12:57] <pitti> wrestling with britney still :)
[12:57] <jdstrand> (it looks like the 3 packages I was looking at all migrated)
[12:57] <jdstrand> heh
[12:57] <jdstrand> well, don't let me distract you! :)
[12:59] <sil2100> pitti: hey, checked the langpacks generated by langpack-o-matic manually here locally and all seems ok, I have the UITK updated po files etc.
[12:59] <sil2100> pitti: I'll modify the cron.daily.rtm script now
[13:00] <sil2100> pitti: just one question - in the old cron.daily.rtm, after the ./import command, there's also a call to ./merge-touch-upstream-translations
[13:00] <sil2100> What does that script do?
[13:00] <sil2100> Is it required?
[13:00] <sil2100> Since I never really ran it before, the resulting tarballs are just good
[13:00] <pitti> sil2100: this was for the time when we didn't have translations in the ubuntu (or RTM) packages, only in trunk
[13:00] <sil2100> Aaah
[13:00] <sil2100> Ok, so I can just get rid of that
[13:00] <pitti> sil2100: and IIRC this was down to one or two projects anyway, no? it started out with 15 projects to pull translations for
[13:00] <pitti> cool
=== dholbach_ is now known as dholbach
[13:24] <seb128> quadrispro, pitti, should we sync the new libmtp from debian for wily? it seems to mostly fix bugs and add device ids
[13:25] <pitti> seb128: sounds good to me; libmtp hardly grows actual features
[13:59] <pitti> seb128: did you actually mean sync? i. e. did upstream take our "add arale device" patch?
[13:59] <pitti> seb128: and bq?
[14:00] <seb128> pitti, https://packages.qa.debian.org/libm/libmtp/news/20150605T162243Z.html
[14:00] <pitti> yay
[14:03] <sil2100> pitti: https://code.launchpad.net/~sil2100/langpack-o-matic/new_overlay_cron/+merge/272111 - this would need the multi merge branch to land as well :)
[14:04] <pitti> sil2100: yay, thanks
[14:05] <pitti> sil2100: I haven't yet done the previous MP, sorry; it now looks even more complicated than before, I'll see to making this easier
[14:05] <sil2100> Oh, I need to correct one thing in it
[14:05] <pitti> sil2100: or merge it if you carefully tested it with two and multiple tarballs
[14:05] <pitti> but right now it's rather hard to understand
[14:06] <sil2100> I used it for merging 3 tarballs and it worked
[14:06] <pitti> ok
[14:06] <pitti> so then maybe I'll just merge this "blindly", and rewrite the damn thing from scratch
[14:06] <sil2100> At least, I got the proper langpacks from langpack-o-matic ;p
[14:07] <sil2100> It's not so complicated, I'm doing the exact steps you did just sequentially, one argument after another
[14:07] <pitti> sil2100: yeah, wasn't blaming you really -- this script is horrible
[14:07] <pitti> all this find/copying stuff around is massively overkill
[14:07] <pitti> sil2100: your idea with cat'ing the mappings to .merged and sort -u at the end is nice, and so much easier
[14:08] <pitti> with that we can just untar all tarballs on top of each other
[14:09] <sil2100> Thanks, actually yeah, we might get rid of the find call that way even now I suppose
[14:09] <sil2100> Well, let's do that later :)
[14:13] <rbasak> infinity: I've just uploaded new backports for docker.io, to trump the existing packages in -proposed for some upgrade issues that kickinz1 found. They're fixed in Wily and re-backported.
[14:15] <pitti> sil2100: I'm trying to spot what you changed in the ./import line
[14:16] <pitti> +find pkgs/ -name changelog -exec sed -i 's/ 15.04;/ vivid;/' "{}" \;
[14:16] <pitti> sil2100: ^ that looks like a debugging leftover? shouldn't that be s!pkgs!$dir/sources-touch! or something like that?
[14:16] <sil2100> Argh!
[14:16] <sil2100> Yes!
[14:16] <sil2100> uh!
[14:17] <pitti> sil2100: oh, I see it: $TAR → $TARM, of course
[14:17] <pitti> that's what I like about PRs on github, the actually changed chars have a stronger color
[14:29] <teward> if a package is compiled with sse2 instruction set support but not sse support, is that a bug that should be filed?  (generic question based off a discussion in #ubuntu-bugs right now)
[14:34] <seb128> mardy, thanks for eds oauth refresh patch, that fixes my indicator-datetime not listing calendar events, I backported the fix to wily ;-)
[14:35] <mardy> seb128: oh, thanks for that!
[14:35] <seb128> yw!
[14:35] <seb128> it's funny that you filed that bug/patch today, I started looking at why my calendar was buggy yesterday and filed some upstream bugs with valgrind logs
[14:36] <seb128> just backported some fixes from Milan for those and your patch as well
[14:38] <rbasak> teward: I think that depends on what we define to be the minimum instruction set that we support. I'm not sure where that might be documented.
[14:38] <rbasak> doko might know maybe? ^
[14:39] <melodie> hi
[14:41] <melodie> I have installed Bento Openbox Remix in a very old laptop, Compaq Presario 920 with a proc amd athlon XP 2000+, which as the sse flag but no sse2 flag and a few programms don't start there but crash. Is it a bug or are they expected to not work with a non sse2 capable proc? This is glxgears and glxinfo
[14:41] <melodie> $ LANG=C glxinfo
[14:41] <melodie> name of display: :0
[14:41] <melodie> Illegal instruction (core dumped)
[14:41] <melodie> (for example)
[14:43] <highvoltage> 1/win 12
[14:52] <ryao> Is the SRU process used for kernel updates in both LTS releases and non-LTS releases or just LTS releases?
[14:54] <cjwatson> ryao: Both (although the kernel is a special case for SRUs, https://wiki.ubuntu.com/KernelTeam/KernelUpdates)
[15:07] <teward> rbasak: it's related to melodie's issue
[15:08] <teward> rbasak: i know that for an instruction set to be supported on any given system the CPU needs to support it, but that doesn't answer the ultimate question of minimum supported instruction set.  If that's documented somewhere, great, if not, well then meh
[15:09] <melodie> teward, it seems for now, that only glxgears and glxinfo can't start and spit a 'core dump illegal instruction' message.
[15:09] <melodie> I have tried several programs so far
[15:10] <rbasak> I suspect the minimum supported set is known by someone somewhere.
[15:10] <melodie> including pcmanfm, xchat, synaptic, sakura, libreoffice writer
[15:10] <seb128> cyphermox, would https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch/+bug/1498805 be one for you or for infinity?
[15:10] <rbasak> Just not by me.
[15:10] <ubottu> Launchpad bug 1498805 in usb-modeswitch (Ubuntu Wily) "Please merge usb-modeswitch 2.2.5+repack0-1 from Debian unstable/testing - current 2.2.3 version in Wily has regressions with lots of Huawei modems" [High,Triaged]
[15:10] <seb128> it claims that the 2.2.3 update in wily regressed things
[15:10] <rbasak> Maybe ask the ubuntu-devel ML?
[15:11] <teward> rbasak: indeed, I may.  melodie: perhaps ask the ML?
[15:12] <teward> rbasak: fwiw i don't ever really have any issues, my proc supports sse and sse2 as well as probably others.  Modern processors are modern :)
[15:12] <melodie> teward, I am unsure if I should suscribe there... do you think you could ask the question?
[15:12] <teward> I don't think I'm subbed either
[15:15] <melodie> then I guess I should :)
[15:15] <melodie> just one more for the todo list
[15:15] <melodie> :)
[15:15] <melodie> humm
[15:16] <melodie> yes that's the point, "minimum set supported"
[15:18] <cyphermox> seb128: it's for anyone who wants to tackle it. It involves looking at the diff between the versions of the tcl program, and re-doing those in our C rewrite
[15:19] <cyphermox> the regression might be something else, like interaction with systemd
[15:20] <seb128> k
[15:20] <seb128> cyphermox, well, I was mostly pointing it so it's doesn't get un-noticed
[15:20] <seb128> I tagged it rls-w-incoming as well
[15:21] <cyphermox> I would suggest someone very familiar with systemd take a look, in case, even before doing any other update :/
[15:21] <melodie> thanks, I have to quit now
[15:21] <seb128> cyphermox, that means pitti? ;-)
[15:21] <sil2100> pitti: hmmmm
[15:21] <cyphermox> seb128: not necessarily, but I'm afraid I might not be the best person to look at it
[15:22] <seb128> k, no worry
[15:22] <cyphermox> as I recall, it was already "fixed" to deal with systemd and udev in the "new way", but maybe something's still off
[15:22] <teward> did the latest galculator get on the beta2 image or no?
[15:22] <teward> (see #ubuntu-bugs, and poke phillw or melodie for more details)
[15:22] <sil2100> pitti: so I tested the cron script that I prepared just now, and I think there might be something wrong with the tarballs we get through the +latest-*-language-pack link
[15:24] <sil2100> pitti: since when I manually downloaded the tarballs from LP through the webbrowser and ran ./import, the resulting packages had proper UITK .po files - but when I run the cron script, those are missing as in your case
[15:24] <sil2100> pitti: looking into that now
[15:24] <pitti> sil2100: wow -- so I'm not seeing ghosts?
[15:25] <sil2100> pitti: it's really really strange! Since the cron script does the same things I did manually, with the only difference being how the tarballs got downloaded
[15:25] <sil2100> I'm downloading them now here to see if that's really the case
[15:27] <cyphermox> pitti: can you ping me when you have a moment, we can team up against usb-modeswitch and see what might be wrong with the version in wily before we consider updating?
[15:28] <teward> tjaalton: ping, if you're around
[15:28] <teward> if not someone else who knows the galculator package will do
[15:28] <pitti> cyphermox: we are mostly non-overlapping (no time any more today, sorry); what's wrong with it?
[15:28] <pitti> cyphermox: I fixed a few segfaults earlier in wily which made it work at least for me
[15:28] <cyphermox> not always running the switching for huawei modem
[15:29] <cyphermox> if you say it works for you, perhaps this is limited to huawei
[15:29] <cyphermox> in which case I won't need your help :)
[15:29] <sil2100> pitti: oh, wait, I think I see the potential problem
[15:29] <sil2100> Let me test (will take a while)
[15:29] <pitti> cyphermox: I actually have a huawei stick too, I just never used it (except for testing this, like twice a year)
[15:30] <tjaalton> teward: ?
[15:30] <cyphermox> pitti: ok
[15:30] <cyphermox> well, not today is fine too
[15:31] <pitti> cyphermox: so this is triggered via udev rules, right?
[15:31] <cyphermox> yes
[15:31] <pitti> cyphermox: the main gotcha I'm aware of is that udev rules must never try to launch a process into the background
[15:31] <pitti> it'll just get killed after a second or so
[15:31] <teward> tjaalton: galculator complaints, apparently, but it's a proxy report of a problem.  last activity was yesterday, now ubuntu-bug supposedly doesn't see the package as an actual package from the repos
[15:32] <pitti> cyphermox: but under systemd it should trigger usb_modeswitch@.service, does it?
[15:32] <cyphermox> pitti: maybe, I don't recall
[15:32] <cyphermox> in any case, I'll debug it here
[15:32] <teward> tjaalton: any idea why it wouldn't be read as official, etc. with trying to report new bugs?
[15:32] <cyphermox> I may have a huawei modem around somewhere
[15:32] <pitti> cyphermox: so what's really worrying is that the whole /lib/udev/usb_modeswitch runs in teh backgroud
[15:32] <ryao> cjwatson: Thanks.
[15:32] <pitti> cyphermox: that cries for race conditions and getting killed prematurely
[15:33] <teward> tjaalton: since you last synced it, i thought i'd bug you first.
[15:33] <pitti> cyphermox: we had a similar problem with ifup@.service, if DHCP took more than 3 seconds or so it was killed
[15:33]  * teward is attempting to reproduce now
[15:33] <cyphermox> yes, it runs the usb-modeswitch service
[15:34] <tjaalton> teward: what's the issue? ubuntu-bug galculator seems to work here
[15:34] <tjaalton> don't even have it installed
[15:34] <teward> tjaalton: phillw reported that "in paper mode, you cannot type anything in"
[15:34] <teward> tjaalton: he tried ubuntu-bug and it said it wasn't an official package
[15:34] <teward> again i'm trying to repro (but my VMs died >.<)
[15:35] <tjaalton> the old version perhaps?
[15:35] <tjaalton> i've never used it myself, synced because it was on the sponsor queue
[15:35] <teward> tjaalton: ack.  may just say manually file, and then do apport-collect
[15:36] <teward> or w/e it is to get the apport data
[15:36]  * teward has it written somewhere
[15:36] <tjaalton> so how to init paper mode?
[15:36] <tjaalton> oh got it
[15:36] <tjaalton> seems to work here
[15:36] <teward> crud i need to redownload the iso >.<
[15:36] <teward> stupid corruption >.>
[15:37] <tjaalton> ubuntu-bug not doing it's thing probably means something is out-of-date
[15:37] <teward> tjaalton: indeed
[15:37] <tjaalton> so first upgrade to current wily and try again..
[15:37] <tjaalton> it's fine here
[15:38] <teward> ack
[15:39] <teward> tjaalton: looks like you're off the hook, phillw's gonna poke ianlorin about it, but i'm still going to see if I can reproduce with the beta 2 iso
[15:39] <teward> after it redownloads xD
[15:39] <tjaalton> i have wily on four systems, it's fine :P
[15:40] <teward> indeed.  i have power-user'd 14.04 on this laptop, but VMs galore for the other versions xD
[15:43] <rbasak> stgraber: I've re-uploaded kimchi with the debian/copyright fix. Diff is: http://paste.ubuntu.com/12531981/
[15:58] <stgraber> rbasak: thanks
=== athairuzzz is now known as athairus
[18:35] <catbus1> Hi, anyone know when 14.04.4 will be released?
[18:45] <jtaylor> is there a good way to disable the grub quick_boot? grubs save_env is buggy and often ends up waiting for user input when it fails
[18:45] <jtaylor> without a timeout
[18:45] <jtaylor> very annoying with a headless server
[18:47] <jtaylor> only thing I see in the source is a compile time option or editing the etc/grub.d files ..
[18:49] <cjwatson> GRUB_RECORDFAIL_TIMEOUT in /etc/default/grub
[18:50] <jtaylor> cjwatson: doesn't work
[18:50] <jtaylor> or at least assuming it has a default that is not infinity
[18:50] <jtaylor> its not the grub menu that is the problem, save_env fails which then seemingly goes into some code that does not have a timeout attached
[18:55] <jtaylor> bug 1311247 bts
[18:55] <ubottu> bug 1311247 in grub2 (Ubuntu) "[Grubenv] error: malformed file, press any key to continue" [High,Fix released] https://launchpad.net/bugs/1311247
[18:55] <jtaylor> the fix released should get removed
[18:57] <cjwatson> cyphermox: ^-
[18:57] <cjwatson> needs actual analysis, reproduction recipe with recent Ubuntu releases, etc. rather than just saying "grub's save_env is buggy"
[18:57] <cjwatson> perhaps better to file a new bug rather than piling onto an existing one
[18:58] <jtaylor> probably, but having a workaround in that bug is useful because thats what you find with google
[18:58] <jtaylor> the other stuff is questionable
[18:59] <jtaylor> e.g. changing the default entry used
[18:59] <cjwatson> well, except that you've just stuck a workaround in that bug which will probably persist on people's systems forever because conffiles
[18:59] <cjwatson> even after the bug is long fixed
[18:59] <cyphermox> jtaylor; perhaps it would indeed be best to file a new bug
[19:00] <cyphermox> that one was indeed showing a "malformed file" error, and seemed to be because of the blocklists, maybe there's something else
[19:01] <cyphermox> though I agree it needs an SRU
[19:01] <jtaylor> sure, what do you need to debug it?
[19:01] <jtaylor> note I'm using 14.04
[19:01] <cyphermox> so you're not on grub2 ending with -21?
[19:02] <jtaylor> 2.02~beta2-9ubuntu1.3
[19:02] <cyphermox> it's a little confusing on that bug because I read at least one comments says they're already on the right version for that fix
[19:02] <cyphermox> ok
[19:03] <jtaylor> the first partition starts at block 63 btw, I know that sometimes causes issues
[19:04] <cjwatson> cyphermox: I don't believe this fix was ever SRUed to trusty
[19:04] <cyphermox> cjwatson: no, it wasn't
[19:04] <cjwatson> so that may be all there is to it
[19:04] <cyphermox> that's the problem
[19:04] <cyphermox> yes
[19:05] <cyphermox> just got lost in the noise of new rush things coming it :/
[19:06] <jtaylor> ah there is a fix, I can test that quickly
[19:06] <jtaylor> missed that changelog entry in the huge bug ..
[19:32] <jtaylor> wow grub takes long to build oO
[19:43] <jtaylor> cyphermox: the patch from -21 backported solves my issue
[19:54] <sil2100> pitti: hey! If anything, I pushed the required change to the cron branch of langpack-o-matic and now everything seems to work as expected ;) UITK translations present ;p
[21:23] <nelhage> !regression-alert
[21:23] <ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
[21:23] <nelhage> bug #1499075; python 3.4 SRU broke botocore and awscli in Trusty
[21:23] <ubottu> bug 1499075 in python3.4 (Ubuntu) "python3.4.3 SRU breaks awscli" [Undecided,New] https://launchpad.net/bugs/1499075
[21:23] <nelhage> looks like the SRU went out with bug #1348954
[21:23] <ubottu> bug 1348954 in python3-defaults (Ubuntu) "update Python3 for trusty" [Undecided,New] https://launchpad.net/bugs/1348954
[21:42] <mdeslaur> smoser: ^
[21:42] <mdeslaur> smoser: perhaps a awscli fix is required there ^
[21:43] <nelhage> Yeah, following the rabbit hole further it looks like the fix probably has to go into botocore.
[21:45] <broder> i just dropped https://launchpadlibrarian.net/218689089/python-botocore_0.29.0%2Brepack-2ubuntu0.1.debdiff on the bug
[21:45] <broder> it seems like it would be nice if the behavior change in python3.4 could be reverted though?
[21:45] <broder> surely botocore isn't the only package using inspect
[21:47] <sarnold> though having a differnt behaviour than other python 3.4.1 or later environments might also lead to bugs
[21:48] <mdeslaur> yeah, I'm conflicted on that as well
[21:48] <mdeslaur> it's the SRU team's call
[21:48] <broder> hmm, probably, though my suspicion is that _not_ throwing an exception seems less likely cause problems? but hard to say
[21:49] <sarnold> it might be worth poking barry too: https://launchpad.net/bugs/1499075  https://launchpad.net/bugs/1348954
[21:49] <ubottu> Launchpad bug 1499075 in python3.4 (Ubuntu Trusty) "python3.4.3 SRU breaks awscli" [Critical,Confirmed]
[21:49] <ubottu> Launchpad bug 1348954 in python3-defaults (Ubuntu) "update Python3 for trusty" [Undecided,New]
[21:52] <Unit193> robert_ancell: Now that /etc/lightdm/lightdm.conf isn't edited by anything, can you install the example file ( /usr/share/doc/lightdm/lightdm.conf.gz currently) there?
=== juliank0 is now known as juliank
[21:52] <robert_ancell> Unit193, the convention for Debian / Ubuntu packages is to install example configuration into /usr/share/doc
[21:53] <robert_ancell> Unit193, and putting a file in /etc/ gets a bit confusing when upgrading packages (it will prompt you to replace any local changes with the package provided one)
[21:57] <mdeslaur> broder: debdiff looks good, did you test it?
[21:58] <Unit193> robert_ancell: https://packages.debian.org/sid/i386/lightdm/filelist but yes I did think of the second part, wouldn't be ideal.
[21:58] <broder> mdeslaur: i've tested it locally off sbuild
[21:59] <broder> i'm...a bit rusty at the processes :)
[21:59] <Unit193> (Usually you have a config file in /etc/ to edit, you don't usually have to create it.  Leads people to hunt down config files in /usr/share/ and edit.)
[22:00] <mdeslaur> broder: ok, I'll upload it to the queue for the sru team, one sec
[22:11] <mdeslaur> nelhage, broder: I've upladed the python-botocore fix for approval by the sru team and I've asked in #ubuntu-release
[22:11]  * mdeslaur -> away
[22:51] <doko> broder, mdeslaur, there was some discussion what the best thing would to be. but afaicr, the expectation to have that the same behaviour as with the upstream version would be better