#ubuntu-release 2010-03-19
<slangasek> davmor2: migration-assistant is higher priority (ubuntu amd64)
<davmor2> slangasek: no probs I'll hit that after this xubunt 32bit wubi
<slangasek> ev: the wubi 'stable' link points to r176, but davmor2 says he's been testing r174 - which am I meant to be publishing?
<ev> 176 fixes the UNR is now UNE issue
<ev> 174 fixes the crash
<ev> I think we can get away with just 174 and telling UNE users to wait until beta 2
<slangasek> davmor2: you've been testing 174?
<davmor2> slangasek: yeap but I can run une and a couple of other on 176 if you want to release on that one instead?
<slangasek> no, let's go with 174
<cjwatson> err, is the release meeting in 7 minutes or 67 minutes?  this is Google Calendar Confusion Week
<slangasek> 67 minutes
<pitti> cjwatson: 67 usually
<cjwatson> goodd
<davmor2> slangasek: would you like me to test 176 for une to ensure that works?
<slangasek> davmor2: it's not pertinent to beta1, though it should certainly be tested at some point
<davmor2> slangasek: Well m-a on 64bit ubu is 50% installed now so I can do it after that
<slangasek> GrueMaster: bug #541399> loaded from USB?  That seems to defeat the purpose of a netboot image
<ubottu> Launchpad bug 541399 in linux-mvl-dove "netboot image fails to boot." [Undecided,New] https://launchpad.net/bugs/541399
<GrueMaster> slangasek: It's irrelevant how the kernel gets loaded by uboot.  The fact that the kernel wouldn't execute is the issue.
<GrueMaster> I don't have a tftpboot server set up at the moment.
<GrueMaster> But this is perfectly valid.  We have an img file for babbage that gets loaded from SD card for the same image.
<slangasek> GrueMaster: ah, ok
<slangasek> davmor2: how long do you expect the m-a test to take to finish?
<davmor2> 95% now
<davmor2> 98%
<slangasek> cool
<davmor2> restart
<davmor2> slangasek: done
<slangasek> sweet
<slangasek> smoser: could you update the ec2 webpages, please?  (publicize-build running now)
<smoser> slangasek, with --make-public ?
<smoser> i will update ec2 pages now.
<slangasek> smoser: isn't that implicit in the 'publicize' command?
<slangasek> (I'm going by the wiki page...)
<smoser> oh. shoot. no, you're right.
<slangasek> ok, good :)
<smoser> i was thinking you were running 'promote-daily'
<smoser> thanks.
<smoser> slangasek, pages updated.
<slangasek> smoser: thanks!
<cjwatson> slangasek: shall I kill queuebot?
<slangasek> oh, probably :)
 * ScottK imagines cjwatson with a large revolver.
<cjwatson> I've got Control and C keys, if those are equivalent
<cjwatson> nhandler: I've registered queuebot now
<ScottK> slangasek: You may want to look at 538860 and decide if you want to retroactively approve it or get it reverted.
<slangasek> ScottK: ah, actually I approved that one from the queue by hand after a review, I just didn't comment the bug :)
<ScottK> slangasek: OK.  No problem then.
<doko__> please promote python3-defaults and python3.1 (now needed by distribute as b-d). will have to seed python3-all-dbg
<nigelb> if an apport hook is added, worth a beta freeze exception?
<nigelb> or do I wait till lucid+1?
<cjwatson> I don't think that needs a freeze exception
<nigelb> ok, I'll get to work on it soon then :)
<slangasek> doko__: is there an MIR for this?
<doko> slangasek: hmm, no, in the past we never had MIR's for new versions. maybe we could have one for pybsddb3, but this is a new version of something we already have in the python2.6 package as well
<doko> let me know what you prefer; I'll write it over the weekend. away now
<slangasek> doko: well, python3 is a substantial enough change, and going in parallel, that I would be more comfortable having an MIR for it
<doko> ok, will do over the weekend
<slangasek> thanks
<AnAnt> slangasek: Hello, regarding LP 402874, is there anything else needed other than than upgrade & install logs ?
<ubottu> Launchpad bug 402874 in sl-modem "Sync sl-modem 2.9.11~20100303-2 (restricted) from Debian unstable (non-free)" [High,Incomplete] https://launchpad.net/bugs/402874
<cjwatson> pitti: I'd like to go ahead with the grub2 SRU in bug 477104; it's definitely the right fix for grub2 itself, even if there are some problems getting the update applied to wubildr
<ubottu> Launchpad bug 477104 in grub2 "After 9.10 grub update can not boot into Wubi install" [Critical,Fix committed] https://launchpad.net/bugs/477104
<cjwatson> pitti: WDYT?  The latter might be covered by my lupin upload
<cjwatson> I could upload that to -proposed if that would help
<cjwatson> ... uploaded
<cjwatson> pitti: see my most recent comment on the bug
<slangasek> AnAnt: yes, the information described on the FreezeExceptionProcess page
<slangasek> # A description of the proposed changes, with sufficient detail to estimate their potential impact on the distribution
<slangasek> # A rationale for the exception, explaining the benefit of the change
<slangasek> # Any additional information which would be helpful in considering the decision
<asac> FYI, bug 542141
<ubottu> Launchpad bug 542141 in ubuntu-release-notes "Lucid Beta 1 release notes mention non-product "Mozilla"" [Undecided,New] https://launchpad.net/bugs/542141
<cjwatson> asac: does the default search change affect other Mozilla products, or just Firefox?
<asac> cjwatson: just firefox
<asac> cjwatson: mozilla prefers if we name it "Mozilla Firefox"
<asac> rather than Firefox
<asac> commented that on bug
<cjwatson> asac: can we trade it for them not referring to "Ubuntu Linux" on mozilla.org? :-)
<asac> haha
<asac> where is that?
<asac> or you want them to refer to Ubuntu rather than just "Linux"?
<pitti> cjwatson: this bug keeps confusing me. A lot of people applied workarounds, but I didn't see any testing of the proposed package yet
<pitti> hmm, unapproved queue still not flushed? any particular reason?
<cjwatson> asac: google "Ubuntu Linux" site:mozilla.org - various wiki pages and such but some official things too
<cjwatson> pitti: I think the lupin package I uploaded to karmic-proposed unapproved should help - it should fix upgrade to work the way it's meant to and rewrite wubildr automatically
<cjwatson> the lack of that is probably why we haven't got real testing yet, but both parts are needed
<asac> cjwatson: so they should just refer to "Ubuntu"?
<asac> or what should i suggest?
<cjwatson> I'll follow up
<cjwatson> (to the bug)
<asac> k
<nhandler> cjwatson: Is there a draft of the next beta announcement? I want to s/FreeNode/freenode/g
<slangasek> nhandler: feel free to copy https://wiki.ubuntu.com/LucidLynx/Beta1Announcement to https://wiki.ubuntu.com/LucidLynx/Beta2Announcement and tweak
<nhandler> slangasek: Will do
#ubuntu-release 2010-03-20
<jcastro> slangasek: around?
<doko> slangasek, pitti: python3 MIR is bug #542372
<ubottu> Launchpad bug 542372 in python3.1 "MIR for basic python3 stack" [Undecided,New] https://launchpad.net/bugs/542372
<slangasek> jcastro: nope!
<AnAnt> slangasek: Hello, I've added the remaining info for LP 402874
<ubottu> Launchpad bug 402874 in sl-modem "Sync sl-modem 2.9.11~20100303-2 (restricted) from Debian unstable (non-free)" [High,New] https://launchpad.net/bugs/402874
#ubuntu-release 2010-03-21
<slangasek> pitti, cjwatson: did one of you accept simple-scan from the unapproved queue?  it was pending an FFe, so I left it in the queue yesterday when flushing, and whoever accepted it didn't comment on the FFe bug
<robbiew_> jcastro: ping
<robbiew_> jcastro: neverming
<robbiew_> and nevermind :P
<nigelb> can someone from release team give me an ack on bug 543139
<ubottu> Launchpad bug 543139 in galrey "[FFE] Please sync galrey 1.0.2-4 from debian unstable" [Undecided,New] https://launchpad.net/bugs/543139
<ScottK> nigelb: No FFe needed.  I commented in the bug.
<nigelb> ScottK: oh yeah, bug fix.  I forgot.  thanks :)
<cjwatson> slangasek: not I
<AnAnt> slangasek: hello
#ubuntu-release 2011-03-14
<ogra_> lamont, were there any probs with the armel image builders on the weekend ? i got empty build failure mails since the 12th and no logs on either sycamore or acorn for any build attemts since then
<ogra_> *attempts
<ogra_> (a manual build i just triggered seems to run fine)
<pitti> skaet: can you please have a look at bug 734894? I commented on it, but would appreciate a second pair of eyes
<ubot4`> Launchpad bug 734894 in gnome-settings-daemon (Ubuntu) "FFe: DBus time API should control ntpdate, not ntpd (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/734894
<skaet> pitti, ok,  will do.
<pitti> cheers
<skaet> pitti,  marked it approved,  should be release noted though.
<pitti> great, thanks
#ubuntu-release 2011-03-15
<joshuahoover> pitti: ping
<pitti> hi joshuahoover
<joshuahoover> pitti: hi! can you take a look at bug #726597 an sru for desktopcouch in lucid
<ubot4`> Launchpad bug 726597 in desktopcouch (Ubuntu Lucid) (and 3 other projects) "desktopcouch can start multiple times leading to several running couchdbs (affects: 2) (heat: 255)" [High,Fix committed] https://launchpad.net/bugs/726597
<pitti> joshuahoover: is that fixed in maverick/natty?
<joshuahoover> pitti: yes, afaik
<pitti> joshuahoover: it's still shown as open; can you please check and close?
<joshuahoover> pitti: sure...where are you seeing it as open for maverick/natty? (must be missing it)
<pitti> joshuahoover: the main ubuntu package task is "in progress", as well as the upstream tasks
<joshuahoover> pitti: ah, ok...yeah, let me make sure it's fixed in maverick/natty and i'll update
<pitti> joshuahoover: aside from this, just upload it to the queue; much easier to review/accept from there
<pitti> (or, rather, it _must_ be reviewed from the queue anyway)
<joshuahoover> pitti: got ya...ok
<joshuahoover> pitti: ok, i verified bug #726597 is fixed in maverick/natty and marked the bug appropriately...we have an upload waiting for approval - https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
<ubot4`> Launchpad bug 726597 in desktopcouch (Ubuntu Lucid) (and 3 other projects) "desktopcouch can start multiple times leading to several running couchdbs (affects: 2) (heat: 14)" [High,Fix committed] https://launchpad.net/bugs/726597
<pitti> joshuahoover: cool, thanks
<joshuahoover> pitti: thank you :)
<Riddell> someone is doing ~ubuntu-archive package removals?
<GrueMaster> skaet: Did I miss something?  I was told we weren't assigning bugs to teams?  Re:  Bug 727468.
<ubot4`> Launchpad bug 727468 in webkit (Ubuntu Natty) (and 5 other projects) "ubiquity-slideshow tears down oem-config on armel (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/727468
<skaet> GrueMaster,  30-40 unassigned high/critical bugs makes it hard to figure out if 1) bug is on a team's radar, just no-one available to work on it.  or 2) its in limbo,  and we need to find an owner.   Assigning to teams at least lets us flesh out the limbo ones.
<GrueMaster> I have no problem with this.  Just checking to see if I had missed a proc change.  :P
<GrueMaster> I am trying to monitor the armel tagged bugs on a weekly basis.  A lot of cruft in the older releases that I am working to either bring current or close completely.
<skaet> There seem to be many different processes in place...  so I'm trying to standardize them a bit.
<GrueMaster> Sounds good.
<ogra_> we usually subscribe ubuntu-armel during the triage but thats indeed less easy to see than an assignment
<GrueMaster> If you ever have any questions on armel related bugs, don't hesitate to ask.
<skaet> Do you want me to add armel tags as well,  when I spot cross team ones?
<ogra_> armel tags shouldnt be bound to teams
<ogra_> onyl to the HW
<GrueMaster> No.  bugs should only have armel tags when they are specific to armel.
<GrueMaster> When I go through and triage current bugs, I sometimes remove that tag if I can reproduce it on x86 & amd64.
<GrueMaster> The other thing I should point out is that not all armel bugs are worked on by the canonical-arm team.  Most toolchain bugs are worked on by linaro for example.
<ogra_> many others too
<skaet> GrueMaster, ogra_ https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/721531 is this likely to get fixed for Natty?
<ubot4`> Launchpad bug 721531 in gcc-4.5 (Ubuntu Natty) (and 2 other projects) "[armel] gcc computes wrong address for main() at build time (affects: 1) (heat: 172)" [High,Triaged]
<ogra_> skaet, up to linaro
<skaet> ogra_,  thanks.
<slangasek> that's incorrect
<ogra_> they own toolchain and compiler
<slangasek> rather, if it's up to linaro then the answer is "no" - this is an upstream gcc 4.5 issue that Linaro is not able to commit to fixing
<slangasek> (as noted in https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/721531/comments/11)
<ubot4`> Launchpad bug 721531 in gcc-4.5 (Ubuntu Natty) (and 2 other projects) "[armel] gcc computes wrong address for main() at build time (affects: 1) (heat: 141)" [High,Triaged]
<ogra_> right, but essential linaro is our channel to talk to upstream or about any toolchain/compiler issues
<ogra_> essentialy
<GrueMaster> So it is correct that linaro is the first point of contact for this issue, but it doesn't look like it will be fixed in natty.
<ogra_> thats what the last comment says
<ogra_> (in the bug)
<GrueMaster> yep
<slangasek> skaet: so I don't think assigning it to the Linaro TCWG is correct as they've already indicated they don't have the resources to work on that this cycle
<slangasek> s/correct/useful/, I should say
<skaet> slangasek, okie,  I'll move it to oneiric.   It was useful in that it forced this discussion to happen ;)
 * skaet trying to identify the bugs in limbo, and get them moved...
<slangasek> ogra_: I'm not sure why you would limit yourselves to using Linaro as a conduit for talking to upstream; if the bug is reproducible in FSF gcc 4.5, and Linaro TCWG aren't working on the issue in question, they're just a middleman
<slangasek> skaet: right, ok :)
<skaet> GrueMaster, do you know if anyone's actively looking at https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/726811
<ubot4`> Launchpad bug 726811 in emacs23 (Ubuntu) "[natty] emacs23/armel FTBFS (affects: 1) (heat: 247)" [Critical,Confirmed]
<ogra_> skaet, FTBFS is currently mostly handledby janimo
 * ogra_ shakes his head about "Critical"
 * GrueMaster changed it to high.
<GrueMaster> Critical is when it ftbfs on all platforms and is needed for image building.
<ogra_> hmm, looks like compiler or toolchain looking at the build log
<ogra_> or buildd :P
<GrueMaster> Didn't we get a new gcc recently?  Maybe retrigger the build?
<ogra_> yup
<ogra_> given back, lets see
<skaet> ogra_, GrueMaster - have marked it as canonical arm developers,  since it your team is working it right now.   Feel free to assign directly to janimo if appropriate if it looks to still be an issue after the builds.
<ogra_> i'm not working on it, i clicked a button on a website :P
<GrueMaster> but that involves work, right?
<ogra_> and i'm fairly sure it will just build
<skaet> https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/726827  looks similar
<ubot4`> Launchpad bug 726827 in mutter (Ubuntu Natty) (and 1 other project) "[natty] mutter/armel FTBFS (affects: 1) (heat: 10)" [High,Confirmed]
<GrueMaster> I mean, you had to move the mouse or something.
<ogra_> GrueMaster, its 11pm here, i dont work at that time of day
<GrueMaster> :P
<ogra_> so it must have been a sparetime confision of my mouse :)
<ogra_> *confusion
<skaet> :)
#ubuntu-release 2011-03-16
<Daviey> Hello friendly release team!  Would someone be able to look at the FFe for bug #727342.  Essentially, a new upstream snapshot which is ahead of Debian Sid because the current version works with Debian kernel, but not ours.  The version string is still less than Sid (due to version scheme change), so we won't have problems syncing when Debian catch up.
<ubot4`> Launchpad bug 727342 in open-vm-tools (Ubuntu) "FFE: open-vm-tools kernel module failed to build (affects: 25) (dups: 32) (heat: 352)" [Critical,New] https://launchpad.net/bugs/727342
<Daviey> Serge has tried to cherry pick a patch, but it was taking a long time, seemed large (concerns of instability, with a large diff)
<Daviey> I'm also concerned launchpad is going to run out of bug numbers, based on the incoming dupes. :)
<ScottK> So is the plan for touch related packages and FFe's "Meh, whatever" this cycle?  They seem to be a bit late to the party with a lot of stuff.
<slangasek> lamont: what's wrong with errno.h on allspice? http://launchpadlibrarian.net/66510432/buildlog_ubuntu-natty-amd64.e2fsprogs_1.41.14-1ubuntu2_FAILEDTOBUILD.txt.gz
<stgraber> skaet: when you have a minute, can you look at: bug 736227 ?
<ubot4`> Launchpad bug 736227 in software-center (Ubuntu) "Feature Freeze Exception for weblive support in software-center (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/736227
 * skaet looking
<doko> slangasek: are there any processor specific optimizations? allspice is newer hardware
<slangasek> doko: it's simply failing to find the errno definition... I don't know why that would be processor-specific
<lamont> slangasek: because it's now a function, not an extern int.
<lamont> ?
<lamont> I wonder if it builds on osageorange?
<lamont> which should be same-class hardware as allspice
<slangasek> lamont: e2fsprogs is /trying/ to include errno.h; it has worked in all my local builds, worked in ppa - but I did see this same failure on one of the metallic ppa buildds (osmium?  thorium?), cleared up when I retried and it got built on a different machine
<lamont> slangasek: so I'd expect it to reproduce on osageorange in the natty dchroot.  if not, holler and I'll dig into it on allspice.  ok??
 * lamont is neck deep in some other stuff atm
<GrueMaster> pitti: I just finished testing the new imx51 kernel for bug 605042.  Works fine.  It can be released at your earliest convenience.
<ubot4`> Launchpad bug 605042 in eglibc (Debian) (and 14 other projects) "[armel] java fails to start with eglibc-2.12-0ubuntu4 (affects: 2) (heat: 22)" [Unknown,Unknown] https://launchpad.net/bugs/605042
<pitti> GrueMaster: thanks, can you please mark v-done?
<GrueMaster> There was no v-needed tag, but sure.
<pitti> uh, process fail then
<GrueMaster> Why fail?  Kernel works.
<slangasek> lamont: ah, didn't recognize osageorange as a porter box name, I don't think I've ever used the x86_64 porterbox :)  right, will dig into it, thanks
<pitti> GrueMaster: I mean, it should have gotten a v-needed tag together with the "plz test me" comment
<pitti> GrueMaster: (nevermind)
<GrueMaster> ah.  :P
<GrueMaster> Well, added v-done for scripting purposes.
<lamont> slangasek: osageorange is the new ronne
<slangasek> ack
<doko> GrueMaster: re-openened the eglibc task
<GrueMaster> why?
<GrueMaster> doko?
<doko> GrueMaster: because the back-out of the eglibc checkin should be reverted
<slangasek> lamont: not reproduced on osageorange
<GrueMaster> Ah.  Now I see it in the changelog.
<Daviey> Is anyone from the release team able to look at the FFe posted waaaaay above?
<skaet> Daviey,  looked at it earlier this morning, and felt a bit intimidated by the scope of changes, so was hoping that one of the other members of the release team who may have more familiarity with the open-vm-tools could comment.   It looked to me like there were some API changes, and am wondering about the testing with it so far.   Have added comments to that effect into the bug directly.
<Daviey> skaet, I appreciate it!
<Daviey> hallyn, ^^
<lamont> slangasek: sigh
<hallyn> skaet: Daviey: AIUI it provides both the server and client so api changes shouldn't matter.  A few commenters on the bug have tested it.  I don't have/use vmware so haven't yet...  i can try installing it next week, but note that 'regression' can't apply to the merge since it's unusable now.
<hallyn> skaet: thanks for taking a look :)
<slangasek> lamont: when you have a moment, could you tell me what crabapple's hw specs and kernel version are?  Trying to diagnose another unreproducible build failure
<lamont> bbg3 for starters
<skaet> hallyn,  before we pull it in, would like to know its not going to cause issues with current kernel we're using.
<lamont> Processor       : ARMv7 Processor rev 5 (v7l)
<lamont> Hardware        : Freescale MX51 Babbage Board
<lamont> Linux crabapple 2.6.31-608-imx51 #22-Ubuntu Fri Feb 4 20:50:41 UTC 2011 armv7l GNU/Linux
<lamont> slangasek: going to lunch shortly, btw
<slangasek> lamont: ok, thanks
<hallyn> skaet: oh, i could run ltp on a host with the modules built in.
<slangasek> lamont: have a good lunch :)
<hallyn> skaet: though i'm off after today, so afraid again that's working into next week :(
<pitti> GrueMaster: copied to -updates
<GrueMaster> Cool, thanks.
<lamont> slangasek: kakadu == crabapple, fwiw
<slangasek> lamont: righty-o
<skaet> hallyn,  makes me feel a bit better that ltp on a host can run.  :)
<lamont> the arm buildds are currently {*aceae,amelanchier}:beaglexm, else bbg3
<slangasek> lamont: still, that means I can't pass the bug off to a Linaro assignee who doesn't have kakadu access, AIUI
<lamont> slangasek: building a chroot on allspice now, will try e2fsprogs in it after lunch
<skaet> hallyn,  on the other hand, pulling it in now, and you not being around for a few days if things go south, doesn't sound like a great idea ;)
<GrueMaster> lamont: New kernel for the bb3 pool.  Should help with some issues, namely openjdk.
<slangasek> ah, so if the kernel's being updated anyway, perhaps that makes my question go away
<lamont> GrueMaster: is that built in -proposed or so?
<lamont> dammit... lunch.  afk
<lamont> I have a meeting that I need to be back for
<hallyn> skaet: yeah, today might not be the best day.  Mind you I don't really have any knowledge on vm-tools anyway, I just attacked it bc it looked like kernel module build fixup work
<hallyn> skaet: if we wait until next week, that not necessarily too late?
<hallyn> if so, then i'll aim to install vmware so i'm ready for more testing
<skaet> hallyn,  its definitely a balancing act.   no easy answers.
<hallyn> skaet: ok, well it definately seems too late for this week.  I'll try for monday then.  thanks
<hallyn> Daviey: thanks
<Daviey> Well, could things with that package go any further south?
<Daviey> Am i mistaken that this is stuff for use within a virtual machine?
<Daviey> Currently, it's totally non-functional.  Worst case scenario is renders a natty vmware virtual machine non-functional, surely.
<hallyn> Daviey: partially.
<hallyn> Daviey: the kernel modules go on teh host.  the userspace package sits int he guest and talks to the host
<Daviey> Ah, that changes things.
<Daviey> I can see the concern now.
<hallyn> Daviey: still, the kernel modules would only affect users who install the modules of course
<hallyn> yeah so ltp seems a worthwhile check
<hallyn> but 'couldn't go any further south' still seems right
<Daviey> hallyn, I assume you have installed the package, not just had others test it?
<hallyn> Daviey: yes, i've installed it on my machine.  I have not however ran vmware to test the guests
<hallyn> Daviey: note that i'm in no way emotionally attached or invested in the bug or the merge, so anyone who wants to test, change, merge something different, or make changes to mine and propose, should feel free :)
<Daviey> heh, it's just the bug count that is frustrating my inbox :)
<hallyn> lol
<slangasek> skaet: multiarch lib uploads progressing; the biggest problem we've seen is that cmake doesn't like having libraries moved outside the search path it knows about, so koffice now FTBFS because /usr/lib/libc.so is gone (no bug report filed yet AFAICS)
#ubuntu-release 2011-03-17
<slangasek> boo, gcc-4.5 ftbfs on powerpc because of a wrong path for the spu build
 * slangasek does a test build on davis for the fix while waiting for armel to finish
#ubuntu-release 2011-03-18
<lool> skaet: Oy
<lool> skaet: I was wondering if you had comments on the armhf FFE
<ScottK> slangasek: Did you get your cmake bug?
<slangasek> ScottK: yes, debfx filed it
<ScottK> Thanks.
<slangasek> bug #737137
<ubot4`> Launchpad bug 737137 in cmake (Ubuntu) "find_library fails to locate multiarch libraries (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/737137
<slangasek> lamont: if there's any manual processing nowadays to get pkgbinarymangler updated on the buildds, I'd appreciate it if you'd poke pkgbinarymangler 93 into place in the morning so that the various multiarch package builds are actually multiarch-clean
 * cjwatson fixes up mklibs for multiarch
<lamont> slangasek: pkgbinarymangler is out of the doghouse, and autoupdates again
<ScottK> skaet: I just remembered one thing I forgot at the meeting.  I approved Bug 737596 for uploads to the Beta 1 freeze.  It's worth some thinking now about if the armhf fixes should still go in after that (I'm inclined to yes, but I think it needs some consideration).
<ubot4`> Launchpad bug 737596 in ubuntu "armhf FFE (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/737596
<skaet> ScottK,  thanks for head's up.   I'll do a bit of homework and get back to you.
<slangasek> lamont: ack, thanks
<lamont> slangasek: (as of quite a while ago)
 * slangasek nods
<slangasek> I vaguely remembered this, but things might've changed again while I wasn't looking :)
#ubuntu-release 2011-03-19
<stgraber> hello, with betafreeze on Thursday, I'd really appreciate it if I could get an answer on bug 736227 quite soon. Thanks a lot !
<ubot4`> Launchpad bug 736227 in software-center (Ubuntu) "Feature Freeze Exception for weblive support in software-center (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/736227
<ScottK> stgraber: I think it's OK as long as mvo is good with the patch.  If you can get him to bless it, I'll approve it.
<stgraber> ScottK: would an IRC log work for you ?
<stgraber> 17:37 <mvo> if you could do the paperwork, that would rock
<stgraber> 17:37 <mvo> just asking skate might be enough :)
<stgraber> 17:37 <mvo> if she is fine, then I'm all for it
<ScottK> stgraber: Sure.  Just copy it in the bug.
<ScottK> Ping me when you've done that and I'll approve it.
<stgraber> added to the bug
<ScottK> stgraber: Approved.
<stgraber> thanks
<stgraber> ul8
<stgraber> oops ;)
#ubuntu-release 2012-03-12
<micahg> ScottK: re anki, it's an arch all package, so I think the python dependency is proper in B-D-I
<ScottK> micahg: You still need to satisy clean from build-depends.
<ScottK> The rule for b-d is needed for arch any or clean.
<ScottK> If you don't need it for clean (I'd be surprised) then it's fine.
<micahg> ScottK: how do I check that, just try to build a source in a chroot without python?
<micahg> *source package
 * micahg doesn't get a warning in the chroot except for the lack of locale, also, there's nothing python related in the clean rule save for the manual .py[co] removal
<ScottK> micahg: That's the simplest way.
<micahg> ScottK: ok, did that, doesn't seem to be a problem, do I need to do a full build first?
<ScottK> Shouldn't.
 * micahg actually just ran debian/rules clean
<ScottK> As long as you made sure 'python' was not installed.
<ScottK> That should be sufficient.
<micahg> grr, was already in the chroot
<micahg> ah, I have devscripts in my chroot for some reason
<micahg> clean rule still worked without the python package
<ScottK> OK.
<ScottK> Never mind me then.
<micahg> ok, thanks :)
<pitti> cjwatson cdimage docs> cheers!
<cjwatson> Xubuntu daily poked again following build failure, and I've moved it five minutes earlier to try to reduce the risk of running into LP downtime which is what I think the last two failures have been
<jamespage> Daviey: I think bug 948993 is now ready for review
<ubot2`> Launchpad bug 948993 in rabbitmq-server "[FFe] [MIR] rabbitmq-stomp, rabbitmq-erlang-client" [Undecided,Confirmed] https://launchpad.net/bugs/948993
<Daviey> jamespage: okay, will look in the next 1hr or so
<jamespage> Daviey: ta
<mvo> pitti: hey, sorry for nagging, but could  we get software-center into oneiric-proposed ? the preicse version is uploaded and IIRC you looked at it last friday and the blocker was the missing precise upload, right?
<pitti> mvo: ah, good; sure
<pitti> mvo: bug 938736 is still open
<ubot2`> Launchpad bug 938736 in software-center "For-purchase apps not showing up on Oneiric" [High,In progress] https://launchpad.net/bugs/938736
<pitti> mvo: bug 949725 as well
<ubot2`> Launchpad bug 949725 in software-center "whats new does not refresh on db changes" [Medium,In progress] https://launchpad.net/bugs/949725
<cyphermox> hey, could someone please review https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/950313
<ubot2`> Launchpad bug 950313 in network-manager "[FFe] Update NetworkManager to a recent snapshot in prevision for the 0.9.4 release." [Undecided,New]
<pitti> mvo: did you see my response above?
<mvo> pitti: ups, sorry, missed that, I updated the bug with the commits that fixed the issue
<pitti> mvo: ah, thanks
<pitti> mvo: hm, 949725 is still open
<pitti> and no recent comment from you
 * mvo looks
<mvo> pitti: updated this one as well, sorry again
<pitti> mvo: thanks; seems they don't always find their way into the debian/changelog?
<mvo> that was sloppiness on our part :/
<stgraber> infinity: any luck with the metalink generation for Edubuntu dailies?
<infinity> stgraber: Nope, my weekend turned out to actually be busy.  Diving into cdimage today.
<stgraber> infinity: ok :) I wasn't around much either so I only had a quick look now. As long as I get something to test before beta2 I'm happy with that.
 * infinity nods.
<infinity> stgraber: I think the only work I got done on the weekend was making qtwebkit-source build.
<infinity> stgraber: Which was less about working, and more about checking back every 8 hours to see if I'd done it right.
<phillw> Not sure if I'm asking even the right question, but would access to the 16G model http://www.kimsufi.co.uk/ help you guys in anyway? It's currently sat twiddling its thumbs at about 1% cpu time. Currently CentOS, but popping on a Ubuntu VM would not be a big job?
<scott-work> do i need to provide more information or documentation for ubuntu studio's LTS consideration?
<micahg> scott-work: that's a TB question, not a release team question :)
<scott-work> yes, sorry, you are obviously correct, i'll respond to the mailing list then
<cyphermox> ScottK: thanks for looking into the ffe for nm-applet. note that it bring in a difference from what the plasma applet exposes to the users
<ScottK> OK.
<ScottK> I was first concerned about the impact on nm-applet.
<cyphermox> sure.
<cyphermox> I was only adding that because it's relevant if both UIs don't show the same options
<ScottK> Right.
<ScottK> It might be useful to talk to the p-w-nm devs and see if they would support it.
<cyphermox> what's the best way to contact them for this kind of thing?
<ScottK> cyphermox: Ask Riddell who to ask would be my plan.
<cyphermox> ScottK: Thanks.
<ScottK> Would someone please respin Kubuntu desktop now that the farsight thing is resolved?  I'd like to see how it looks now.
<ScottK> (i386 or amd64 is enough)
<cjwatson> ScottK: running
<ScottK> cjwatson: Thanks.
<cjwatson> (I just did the lot, less typing)
<ScottK> Right.
<GrueMaster> stgraber: When you (or someone else) gets a chance, can you remove the armel images from the daily tracker (except netboot armel+omap4).  We are no longer making these images, so testing is fruitless.
<stgraber> GrueMaster: doing now
<GrueMaster> Thanks.  I don't always do daily image smoke testing (can't readily automate it yet), but today was a special case.  Lots of users complaining about omap issues.
<stgraber> GrueMaster: done, only armel left is Core which stills build daily
<GrueMaster> Yep.  netboot armel+omap4 should also remain, as it is an easy way to test the armel pool.
<stgraber> ah, right, let me restore that one then
<GrueMaster> stgraber: ^^^
<GrueMaster> ok.  (thought you had wandered off again).  :P
<stgraber> restored
<GrueMaster> Thanks.
<GrueMaster> Now I need to figure out why server omap image blows up.  sigh.
<infinity> We have netboot armel+omap as well.
<infinity> stgraber: netboot omap images seems to have gone from the tracker entirely.
<infinity> stgraber: armel and armhf..
<GrueMaster> infinity: Yes, this I know.  The odd thing is the desktop image works, and so does the omap4 server image.
<infinity> GrueMaster: Oh, that wasn't in response to your server comment.
<infinity> GrueMaster: armhf+omap server is acting up?
<GrueMaster> infinity: We are only testing omap4 netboot actively at this time.  We'll probably keep the images for other netboots, but they will be mostly ignored.
<infinity> Oh, yeah, if we're not testing them, fair enough.  No need to track them.
<infinity> stgraber: Ignore me.
<GrueMaster> And yes, ubuntu-server armhf+omap goes poof on second boot.
<GrueMaster> No indications as to why in the logs that I can see.
<infinity> Weird, given that it does nothing different from the desktop image up to that point.
<infinity> Maybe there's just something goofy with today's daily.
<GrueMaster> I hope it is a random thing.  btw, md5sums???
<GrueMaster> pretty please???
<infinity> Got a bit side tracked today, but yeah, looking at it tonight.
<GrueMaster> Ok.
<infinity> After I take some time out to reset my brain with a movie or something.
<GrueMaster> I know the feeling.  I was supposed to be working on some automation scripting.  Got stuck with this, armadaxp kernel goofiness, etc.
<GrueMaster> Need something like "mirror /dev/gruemaster".
<infinity> Nah, just need to take a bit of "you" time and relax.
<GrueMaster> Can't.  Weather sucks too much to do anything.  40f degrees and raining.  hard.
<GrueMaster> I did take ~3 hours of me time yesterday...and did my taxes.  wheeee.
<infinity> Hahaha.
<infinity> Yeah, I did that over the weekend, too.
<infinity> Because when you travel to another city to help with a funeral, the only way to possibly make that more depressing is to bring your taxes with you.
 * infinity is smart.
#ubuntu-release 2012-03-13
<stgraber> oh right, I guess I should do mine eventually... I've had all the paperwork stacked on my desk for a while now, just need to find the CRA login/password I somehow manage to loose every year and then some motivation...
<knome> stgraber, i could be your paid assistant to remember passwords
<knome> stgraber, silence is acceptance?
<GrueMaster> I like that idea.
<knome> :)
<stgraber> knome: the problem with that password is that I received it on some sheet of paper and I'm really efficient at loosing anything that's on paper ;) I guess I should just e-mail it to myself, then it'll be properly indexed :)
<knome> stgraber, or, send it by mail to me, and i'll archive it for you. for a small compensation.
<GrueMaster> Heh.  I need to find my pin for my student loan info so I can work on consolidating them.
<GrueMaster> It was mailed to me on a 3x5 card.  No name on the card, just on the envelope.
<knome> that's why you both should really process everything through computers right away.
<GrueMaster> I plan on saving mine to floppy once I find it.  Oh, wait....
<knome> the floppy or the card?
<GrueMaster> Does it matter?
<knome> hmmh. i think it does :)
<cjwatson> mercifully I haven't yet tripped any of the triggers that would cause me to have to fill out manual tax returns (touch wood), which is just as well since I have the bureaucracy-related organisation levels of a deranged chipmunk
<GrueMaster> Fortunately, I can do mine in a Windows VM (only reason I keep it around still).  But every few years, my wife does something that inadvertently screws up our ability to e-file.  Last year, she took a month of sick pay due to surgery.
<cjwatson> ... which reminds me it's actually kind of important that I register my son's birth within the legal time limit.  I should go do that tomorrow ...
<GrueMaster> yea, that might be important.  Wouldn't want animal control to think he was a stray.  :P
<cjwatson> I think if you have to fill out a manual tax return in the UK it at least can be on paper.
<GrueMaster> (congrats btw).
<cjwatson> ta :)
<infinity> cjwatson: I (and any Canonical employee in Canada who isn't in Quebec) am stuck filing manually, sadly.
<mdeslaur> infinity: seriously, you have to file it _manually_?
<mdeslaur> infinity: do they need you to mail stuff to them, or what?
<infinity> mdeslaur: Quebec has my provincial taxes, the feds have no record of that, so I need to file manually, send in my Releve 1, and let them battle it out.
<infinity> mdeslaur: It's a serious pain in the butt.
<infinity> mdeslaur: But we're all taxed as if we're Quebecois, regardless of our which province we live in. :/
<infinity> s/our //
<mdeslaur> infinity: so you get a crapload of money back :)
<infinity> mdeslaur: There's that.  I get an okay return.  But it's still an annoying hassle.
<infinity> mdeslaur: If Quebec could just play nicely with others, it wouldn't matter.
<mdeslaur> infinity: damn baby boomers :)
<knome> enlight me on PAE. will it be default for 12.04 already? if yes, can people with older computers install 12.04 at all?
<doko> now, is the unity/staging repository built for every commit? I think that's not acceptable
<stgraber> knome: yes it'll be the default, the non-pae kernel will still be in the archive. It's probably ok for flavours to choose to go with pae by default but it'll need some tweaking
<ScottK> mdeslaur:  "I get an OK return" is another way of saying "I gave the government an interest free loan".
<stgraber> knome: others will need to use a d-i mini.iso (netinstall) to get the non-pae kernel
<knome> stgraber, so, derivatives will use non-pae by default?
<ScottK> knome: Not unless they decide to.
<knome> i'm confused :D
<ScottK> He was saying that was a choice different flavors might take, not that they had.
<knome> he said: "probably ok for flavours to choose to go with pae by default"
<knome> which lead me thinking derivatives don't have pae
<stgraber> knome: everyone is PAE only by default but you can ask to go non-PAE on a per-image basis (I think, I'm not exactly sure where the changes needs to happen to be honnest ;))
<knome> stgraber, okay. that's in 12.04 already?
<stgraber> yes
<knome> stgraber, if yeah, how was i able to run 12.04 in vbox with no pae enabled?
<knome> or is that supposed to work too
<stgraber> knome: either because vbox was lying or because it was a very old image ;)
<knome> something around 0301
<knome> march, that is :P
<stgraber> hmm, that should have been pae-only
<knome> could've been 2802..
 * knome changes timestamp syntax on-the-fly
<stgraber> hmm, confirmed that all xubuntu images are currently using the PAE kernel
<knome> okay...
<stgraber> so it should have failed to boot in vbox if it indeed simulated a non-pae environment
<knome> mmh. okay...
<knome> weird
<knome> i need to bring this up on our community meeting
<stgraber> I think it'd make sense for xubuntu or at least lubuntu to go with a non-pae kernel by default, otherwise we'll basically end up having no ubuntu flavours that's bootable on old hardware
<stgraber> (where "old" includes 1.6Ghz pentium M, so really not that old)
<stgraber> and pointing to a d-i netinstall image isn't that great as it's definitely harder for the user to install and doesn't provide a live environment
<knome> stgraber, yup
<knome> anyway, i'll get back to you with this later ;)
<knome> now i need to sleep, so nighty
<doko> infinity, I turned on the old arm buildds to catch up
<Riddell> hmm libical-dbg in New has a curious debugging file system e.g. usr/lib/debug/.build-id/bc/e20ac21fa0ba1123c73c4dded2ade72a4f136b.debug
<Riddell> anyone seen that before?
<Riddell> fabo: yours? ^^
<pitti> Riddell: yes
<pitti> Riddell: that's the new debhelper 9 style
<pitti> arguably it looks crap
<fabo> it's debhelper 9
<fabo> using build id
<pitti> but apparently it's the new glib/gdb way
<pitti> Riddell: please don't accept that yet, though
<pitti> Riddell: the package FTBFSed on arm* and powerpc, so seb128 ought to fix that first (I think he requested the sync)
<pitti> we should only binNEW it once it's built on all arches, otherwise library transitions will be a pain
<Riddell> interesting, I'll have to google that
<Riddell> pitti: leaving libdbg, I'll do the source new packages
<Riddell> leaving libical-dbg I should say
<pitti> Riddell: do you have an opinion on bug 343363? i. e. adding the recommends of cryptsetup-bin to udisks, so that this works out of the box instead of producing error messages?
<ubot2`> Launchpad bug 343363 in cryptsetup "FFe: gnome functional depends on cryptsetup, but not in package management" [Low,Fix released] https://launchpad.net/bugs/343363
<Riddell> pitti: seems like a good thing, what's the downside?
<pitti> Riddell: none known to me
<pitti> well, 100 kB CD size of course, but we can spend that
<pitti> it's a long-standing wrt
<pitti> wart
<pitti> but now we have the cryptsetup package split, so we can add it without affecting boot time etc.
<Riddell> it has my blessing :)
<pitti> Riddell: I just wanted a second pair of eyes on it as I'm biased there
<pitti> Riddell: ok, thanks
<Riddell> according to https://wiki.ubuntu.com/StableReleaseUpdates#Procedure when a SRU is in -propsed I can just accept it if sane without having to wait for ubuntu-sru to approve
<Riddell> is that right?
<pitti> I'd rather have the SRU team do this; but if it's trivial and obviously correct, go ahead
<pitti> but please make sure the bug tasks are all present, it's fixed in precise, and run sru-accept.py
<Riddell> it's not trivial so I'll update the documentation to make that clear
 * Riddell changes to "The ~ubuntu-sru team will review and approve then the archive admins will accept your upload."
<knome> hey! we at xubuntu are planning a slight changes to our logo (or as some people like to point out, a change in the logo is not slight), and would like to upload that for beta2. that would not affect *ANY* layouts or strings, so i'm asking how closely would you like us to follow the UIFe process, which basically ensures translators and documentators know about it, but this isn't relevant for them. so is it enough to ask the release team, and if 
<knome> ^ we also don't have any translations from launchpad, so for xubuntu, this translators+documentators process is useless anyway
<knome> ^ the change is http://temp.knome.fi/xubuntu/precise_logo/logo_comparison.png to make the logo easier to use on various backgrounds + make it a bit brighter.
<jamespage> any archive admins around? could do with some opinion/guidance on bug 928501
<ubot2`> Launchpad bug 928501 in ebox "[FFe] Upload new Zentyal packages (was Precise will ship totally broken ebox packages)" [High,New] https://launchpad.net/bugs/928501
<cjwatson> Could somebody process libidl through binary NEW?  It'll be making libidl0 on !i386 uninstallable until that happens, I think
<pitti> cjwatson: done
<cjwatson> ta
<Riddell> jamespage: it's the release team you're after for FFes
<tumbleweed> Riddell: I offered him an FFe, but it needs archive-admin volunteering
<Riddell> tumbleweed: what sort of volunteering?
<tumbleweed> NEW review
<Riddell> that'll be me
<jamespage> Riddell, tumbleweed: also I'd like to know that the archive admin team is happy with the proposed native package format BEFORE I upload
<jamespage> (so as not to waste everyones time :-))
<tumbleweed> jamespage: IMO, we bikeshedded that enough, and it's up to you as the sponsor
<Riddell> jamespage: Zentyal is now an ubuntu project?
<jamespage> tumbleweed, well I am
<jamespage> Riddell, Zentyal is an Ubuntu only project
<Riddell> mm reading comments now
<jamespage> Riddell, ta
<Riddell> fine with me in that case
<Riddell> give me a ping when it needs New review
<jamespage> Riddell, probably also worth pointing out that is really a rename of the ebox packages
<jamespage> tumbleweed: want to firm up on that FFe? I'll upload to NEW now if so.
<tumbleweed> jamespage: already done
<jamespage> tumbleweed, thankyou
<tumbleweed> np
<Riddell> jamespage: remember to file removing bugs for ebox as well
<jamespage> Riddell, on it now
<jamespage> Riddell, OK if I add tasks to bug 928501?
<ubot2`> Launchpad bug 928501 in ebox "[FFe] Upload new Zentyal packages (was Precise will ship totally broken ebox packages)" [High,Triaged] https://launchpad.net/bugs/928501
<Riddell> jamespage: for removal?  I think I'd prefer a new bug for that
<jamespage> Riddell, ack
<infinity> jamespage: If there's a rename going on, are there also transitional packages?
<jamespage> infinity, the package set is self contained so I don't think it actually requires any transitional packages
<jamespage> the packages have appropriate Replaces: fields so that they superceed their ebox-* equivalent
<tumbleweed> jamespage: the users won't be upgraded to the new packages without transitional packages
<jamespage> tumbleweed, infinity: you are quite correct; my oversight
 * jamespage wonders whether his brain is to full sometimes
<mvo> hi, I uploaded a release-upgrader-apt to lucid-proposed with a fix for #940396 - it would be great if someone could have a look and accept so that the auto-upgrade-tester can use this apt version to verify that it fixes the bug and also that there are no regressions from it
<mvo> bug #940396
<ubot2`> Launchpad bug 940396 in apt "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [Critical,Confirmed] https://launchpad.net/bugs/940396
<infinity> mvo: Done.
<mvo> ta!
 * mvo is *really* curious for the output of the upgrader tester tomorrow
<ScottK> Hmmm.
<ScottK> No Kubuntu live images today.
 * ScottK got no failure logs in email, however.
<ScottK> Would someone please see where they went?
<infinity> I don't see any failures...
<infinity> ScottK: Last successful images were ~10 hours ago... How fresh did you want 'em?
<ScottK> infinity: It helps if I look in the right directory. Sorry for the noise.
<ScottK> Those are plenty fresh.
<infinity> ScottK: How about I just update the timestamps every few minutes? ;)
<infinity> (Which I'm about to do for ubuntu-core, while testing something...)
<ScottK> Well, I still won't find them if I'm in daily and not daily-live, so probably not worth it.
<infinity> stgraber: Oh, hrm.  I think I see the oops.  dvd builds aren't "foo-dvd", but just "dvd".
<infinity> stgraber: Going to test a 1-char fix. :P
<stgraber> ;)
<infinity> (It seems that sometimes, they're also foo-dvd, or even bar_dvd... Because consistency is awesome... I'll use *dvd)
<stgraber> well, at least they're all called dvd ;)
<infinity> stgraber: Should be fixed.
 * infinity goes and commits his cowboyed changes properly.
<infinity> stgraber: Well, should be fixed when the mirrors finish rsyncing.  But I assure you it's correct on cdimage. ;)
<stgraber> infinity: yep, looks good here (well, only amd64 is here but that's because rsync is still running)
<pitti> mvo: will the auto-upgrade tester use the proposed version?
<pitti> mvo: there's noting in lucid-proposed
<infinity> pitti: There sure it.
<infinity> s/it/is/
<pitti> https://launchpad.net/ubuntu/lucid/+queue?queue_state=1 ?
<infinity> https://launchpad.net/ubuntu/+source/release-upgrader-apt
<infinity> pitti: I already accepted it.
<pitti> ah, someone already accepted it then?
<pitti> ah, thanks
<pitti> no bug refs, hmm
<pitti> mvo: ^ you'll need to poke me for sending this to -updates manually
<mvo> pitti: will do, thanks!
<knome>  
<knome> oops :)
<ScottK> Nice to see Canonical upstreams doing their usual job of meshing their development efforts with the distro release schedule.
<infinity> That sounded sarcastic.
<infinity> Did I miss a groanworthy announcement?
<ScottK> Only one word was sarcastic.
<ScottK> Multiple FFes for new packages needed for MaaS in the release team bug list.
<infinity> Ahh, I haven't opened that search page today.
<infinity> And now I shall continue to not do so.
<ScottK> It was in bug mail for me.
<infinity> My bug mail is a mess, and tends to land in /dev/null.
<ScottK> Apparently the "the srcNEW reviewers", whoever they are, are aware of it.
<infinity> As in, the archive admins?
<infinity> I just got a new imaginary title!
<ScottK> That would be my guess.  "the srcNEW reviewers" is the term used in multiple bug reports.
<ScottK> Two, IIRC.
<stgraber> can I get a quick release team ack on bug 750134?
<ubot2`> Launchpad bug 750134 in ubiquity "[UIFe] "Try Ubuntu" and "Install Ubuntu" icons differ widely in size" [Medium,Triaged] https://launchpad.net/bugs/750134
<stgraber> docteam already +1ed
<Laney> you have something to upload?
<Laney> that patch looks ... concise.
<stgraber> Laney: the change is simply replacing the .png with the one from the bug
<stgraber> Laney: his debdiff is indeed kind of pointless ;)
<Laney> OK, just thought I'd check. Looks good.
<NCommander> infinity: ping, can you approve a FFE for linux-armadaxp (3.0->3.2?)
<infinity> NCommander: That's pre-approved.
<stgraber> jbicha: hey there, could you have a look at bug 950206?
<NCommander> oh great, saves me a bug
<ubot2`> Launchpad bug 950206 in friendly-recovery "[UIFe] add LVM and APT information to system-summary" [Undecided,Confirmed] https://launchpad.net/bugs/950206
<infinity> NCommander: As in, linux-armadaxp wouldn't be in main at all if it wasn't for the assumption that it would rev to 3.2
<jbicha> stgraber: done
<stgraber> jbicha: thanks. I'll do a quick test here and upload it then.
#ubuntu-release 2012-03-14
<jbicha> hi, cogl failed to build on arm & I don't know enough to fix it
<jbicha> so, how does the new queue work for new binary packages?
<jbicha> can we reject cogl until we figure out how to get it to build on ARM? as the new cogl will break gnome-shell
<infinity> jbicha: I can reject the binaries, sure.
<slangasek> rejecting new binaries should really only be done for wrongly named packages that have to be done anyway, or very grave bugs
<slangasek> is there a bug open for this gnome-shell issue?
<infinity> slangasek: In this case, the request to reject until he fixes the FTBFS, so he doesn't have to deal with skew in one direction or the other doesn't hurt my feelings. :)
<infinity> slangasek: The issue is, I assume just that gnome-shell needs to be updated for the new cogl.
<infinity> jbicha: That said, you could just make sure gnome-shell has versioned build-deps, and it would be dep-wait on arm*
<slangasek> jbicha: is it the skew you were worried about?  that wasn't clear to me
<jbicha> and I think continuing the gnome-shell/clutter transition wouldn't be a good idea
<infinity> slangasek: Ahh, I had a bit more context from the ARM channel.
<infinity> slangasek: cogl->clutter->gnome-shell is the dependency chain, and if cogl's broken, there's not much point in carrying forward until it's fixed.
<slangasek> ah
<jbicha> slangasek: the cogl/clutter transition bug is bug 941617 by the way
<ubot2`> Launchpad bug 941617 in clutter-1.0 "FFe: Update clutter/cogl to 1.9" [Wishlist,Confirmed] https://launchpad.net/bugs/941617
<slangasek> ack
<infinity> jbicha: Anyhow, bug me about help with cogl tomorrow afternoon if janimo hasn't magically fixed it overnight for you. ;)
<jbicha> infinity: thanks
<knome> stgraber, ?
<knome> stgraber, if the non-pae kernel is doable for xubuntu, we're all in!
<cjwatson> please file a bug on the ubuntu-cdimage project asking for it, and assign it to me
<knome> okay, thanks :)
<greyback> skaet: Hi, as agreed, Unity2D are working on releasing a mini-release today. We're in final testing mode now, but can you please look at https://bugs.launchpad.net/unity-2d/+bug/954175
<ubot2`> Launchpad bug 954175 in unity-2d "[FFe] [UIFe]: Multimonitor support for Unity-2d" [Undecided,New]
<greyback> skaet: I'm off for luch now, will be back in 45 mins or so
<knome> cjwatson, https://bugs.launchpad.net/ubuntu-cdimage/+bug/955009
<ubot2`> Launchpad bug 955009 in ubuntu-cdimage "Use non-pae kernel on i386 for Xubuntu 12.04" [Undecided,New]
<cjwatson> saw it in mail, thanks
 * ogra_ really likes to see the "highlighting-kate" package on -changes every now and then ... its the "get release manager attaention" tool, right ? :)
 * Laney is an attention seeker
<Laney> that transition is more than half done nowâ¦ should go below 200 todayâ¦
<greyback> skaet: ping
<skaet> greyback,  have gone in and approved.   Thanks.
<greyback> skaet: many thanks to you
<skaet> Riddell,   MIR - fontskanjistrokeorders,  is there someone working on resolving the issues flagged in the bug?    I'm not sure it meets the definition of critical priority though, am adjusting to high.
<Riddell> skaet: what's the bug number?
<skaet> https://bugs.launchpad.net/ubuntu/precise/+source/fonts-kanjistrokeorders/+bug/918289
<ubot2`> Launchpad bug 918289 in fonts-kanjistrokeorders "[MIR] fonts-kanjistrokeorders" [High,Incomplete]
<Riddell> mm right, I guess he marked as critical because it's illegal to ship it like that
<Riddell> I'll take a look when I can
<skaet> thanks
<skaet> Daviey,   looking at the MIRs for server,  there seem to be some server ones without priority (netcf, python-keystoneclient, python-cherrpy, vblade-persist, ceph)  could you take a pass and prioritize?
<Daviey> skaet: Oh aye.. Expect them to double within the next two days. :(
<skaet> Daviey, *sigh* not what I wanted to hear....  :P   please prioritize the ones there now,  so our precious MIR resources focus on the most important ones then.
<infinity> skaet: But Daviey loves all his children equally.
 * ogra_ wasnt aware Daviey had reproduced already
<skaet> didrocks,  whats' the current ETA for compiz 0.9.7.2 (was expecting it on monday?)
<didrocks> skaet: compiz? no
<didrocks> skaet: we landed a trunk snapshot in monday
<didrocks> which is 0.9.7.0+bzrâ¦
<didrocks> but never planned to announce it as 0.9.7.2
<didrocks> who told that?
<skaet> Compiz 0.9.7.2 planned for Monday  was in last week's status...
<skaet> https://wiki.ubuntu.com/DesktopExperienceTeam/ReleaseStatus
<didrocks> well, I'm not the one filing thisâ¦ I told dbarth that wasn't accurate
<didrocks> so you get a new compiz
<didrocks> which is basically "trunk"
<didrocks> on Monday
<didrocks> not sure how it was officially mixed with a 0.9.7.2 release, which is just a tag at the end :)
<skaet> thanks for clarifying.
<skaet> am trying to figure out what's left to land.
<skaet> unity 5.8,  unity-2d 5.8 (both bug fix releases) is on my radar for next week.
<didrocks> right
<skaet> will there be a compiz or nux drop?
<didrocks> and unity-2d with multimonitor, as we discussed, this week
<skaet> yes
<didrocks> (testing ending)
<didrocks> yeah, when we talk about unity, it's in fact:
<didrocks> dee, libunity, nux, unity-lens-files, unity-lens-applications, unity-lens-music, unity, (and some compiz pieces)
<didrocks> ah, and bamf
<skaet> are some bits landing before, or is it all going to hit simultaneously?
<didrocks> skaet: no, all components are intermixed unfortunately
<didrocks> but when we do community testing
<didrocks> it's on all the bits as well
<didrocks> so we are quite clear about the "stack" statuts
<didrocks> status*
<skaet> where should I be looking for the plans?
<didrocks> what do you mean by "the plans"?
<skaet> which bits of the stack are dependent on each other and tested together.
<didrocks> skaet: basically all of this are tested together
<didrocks> skaet: if you want to see what the packages are updataed:
<didrocks> https://launchpad.net/~unity-team/+archive/staging
<didrocks> when we launch the test:
<didrocks> https://launchpad.net/~unity-team/+archive/ppa
<didrocks> so basically, every components that are not "grey" (meaning, there is a higher version in the ppa than in precise) is planned to be released, for now
<didrocks> like you can see, there has been no new bamf commit for now (the line is grey)
<skaet> didrocks,  yes, understand they're tested together - trying to get forecast though of what's being assembled together.   Where bug fixes emerging, etc.
<didrocks> skaet: ah bug fixes, that's different
<didrocks> skaet: so, I have a distro priority list:
<didrocks> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuMtju1x8UoEdDNCT1U5MlVodjIwNGJPdnU5YVltVmc#gid=1
<didrocks> those are all the bugs that are due/important for precise ^
<didrocks> for what is planned, you have the milestoned:
<didrocks> https://launchpad.net/unity/+milestone/5.8.0
<didrocks> but unfortunatly, there are too many bugs that they can close in the milestone
<didrocks> so keep an eye on the "fix committed" ones (when upstream updates the status, which is, unfortunatly, not everytime the case)
<skaet> didrocks, I'll go do some cross checking and get back to you,  am a bit worried about some of the bugs that are indicated as critical from a release perspective and have been lingering.
<didrocks> skaet: what do you mean, the bugs that you have on your list?
<didrocks> skaet: if you have concerns about the rate of fixing (that I do have as well), please see with thumper
<didrocks> so that I'm not the lonely voice :)
<skaet> didrocks,  :)   bugs that have been indicated as blockers for the release (ie. milestoned/critical/release targetted)...   checking on them now.
<didrocks> skaet: ah ok ;)
<didrocks> skaet: normally, they should be on the priority list as well (but it's better if you ping me with the list)
<skaet> didrocks,  will do.
<skaet> knome,  re: the logo question yesterday,   as long as you let the docs folk know about it,  it should be fine as long as it lands this week. (so time to catch the oop's next week ;) )
<skaet> knome,  please let me know the bug number to sign off on.
<knome> thanks skaet, will file a bug right after the xubuntu community meeting and get back to you with it :)
<knome> skaet, https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/955396
<ubot2`> Launchpad bug 955396 in xubuntu-artwork "New Xubuntu logo" [Undecided,Confirmed]
<skaet> slangasek,  netboot images,  just noticed the ones on the daily image tracker are pretty old/stale,  and paths aren't matching where the current ones are being posted.    Was there a decision made not to keep them on cdimage at some point?
<skaet> current images: http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/
<skaet> is linked to from: http://cdimage.ubuntu.com/netboot/precise/
<slangasek> skaet: the netboot images have never been stored on cdimage; not sure I understand the question
<slangasek> where are they linked on the daily image tracker? http://iso.qa.ubuntu.com/qatracker/milestones/204/builds only shows omap4
<skaet> am trying to cut/paste but its not cooperating... :P   just a sec
<skaet> http://cdimage.ubuntu.com/netboot/daily/VERSION/precise-netboot-amd64.iso
<skaet> showing up as a download link for amd64..
<slangasek> really?
<slangasek> because that doesn't exist on the server
<slangasek> (nusakan)
<slangasek> where do you see that link?
<slangasek> it's never been correct AFAIK
<skaet> looking in the iso tracker.
<slangasek> ok, where in the ISO tracker :)
<skaet> http://iso.qa.ubuntu.com/admin/config/services/qatracker/products
 * slangasek looks
<skaet> under Netboot amd64 - download link, from admin page
<slangasek> aha
<skaet> am also noticing others are missing completely,  so
<slangasek> yes, that's incorrect
<skaet> cleanup time I think.
<slangasek> yes, looks like cut'n'paste error at some point; cleaning up
<skaet> awesome.  thanks!
<skaet> you going to handle them all,  or do you want me to take some.
<skaet> ?
<slangasek> I'll get 'em all
<skaet> coolio
<skaet> :)
<slangasek> http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/47/downloads should be more meaningful now
<slangasek> ogra_, infinity: ^^ I'm trying to work out which bits from http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/20101020ubuntu118/images/omap/netboot/ (et al) should be linked from the ISO tracker... do these files really have to all be downloaded individually?
<slangasek> ogra_, infinity: or is the boot.img-* an all-in-one netbootable image?
<slangasek> skaet: so the one thing missing from my perspective is that the "daily testing" page (http://iso.qa.ubuntu.com/qatracker/milestones/204/builds) links to version 20120113... that's not a version number for the netboot images, which only get rebuilt when the installer is uploaded
<slangasek> so the real version number is 20101020ubuntu118
<slangasek> is that getting auto-populated somewher?
<slangasek> stgraber: ^^
<stgraber> slangasek: they are currently manually added, so whoever last added them (might well have been me) did it with the current date
<stgraber> slangasek: so you're saying we should use whatever's the latest version of debian-installer for that? if so, I'll add it to a cron here so it's checked once an hour and bumped if needed
<slangasek> stgraber: yeah, I think that's the only value that makes sense there for a version
<slangasek> since if we're testing the netboot image, that's the granularity that matters
<stgraber> slangasek: ok, writting the script now. Please keep the broken version for now, I'll test the script on it to make sure it works
<slangasek> ok
<stgraber> slangasek: done
<slangasek> yay, thanks
<Laney> please could somebody process bug #955204 :-)
<ubot2`> Launchpad bug 955204 in haskell-binary "Remove from Precise -- included in GHC" [Undecided,Confirmed] https://launchpad.net/bugs/955204
<slangasek> looking
<Laney> having it in makes some builds break
<slangasek> removed
<Laney> i'm filing some others, but they aren't urgent
<Laney> cheers
<skaet> slangasek, stgraber,  re: netboot.  Thanks.
 * skaet just catching up on IRC after phone calls....
<ogra_> slangasek, boot.img should be an SD card image, youu wont boot a beagle XM without SD (or a directly attached USB OTG server)
<ogra_> that we have the contents separately available too helps with qemu-system
<slangasek> ogra_: SD card image? I don't understand; these are labelled 'netboot'
<ogra_> well, they are netinstall images, the beagle XM cant actually do a real netboot since you need MLO and u-boot locally
<slangasek> so they're being packaged in the wrong directory in d-i?
<ogra_> and there is no NADA
<ogra_> err
<ogra_> NAND
<slangasek> if there's no support for actually booting kernel+initrd over the network here, it shouldn't be in a directory called "netboot", that's just confusing
<ogra_> well, kernel and initrd can be used over the network and run a netinst d-i session
<slangasek> used over the network how?
<ogra_> to do that you would create an SD where you put MLO, u-boot and boot.scr in place, in boot.scr you define that it should PXE boot
<ogra_> u-boot then pulls kernel and initrd via tftp
<slangasek> and the uImage and uInitrd that are shown in that directory can be booted via tftp that way?
<ogra_> using the boot.img you can avoid the SD creation if you want
<ogra_> right
<slangasek> how does boot.img let you avoid it?
<slangasek> (is any of this documented somewhere?)
<ogra_> its just for convenience (though i think NCommander includes kernel and initrd in the boot.img, which actually makes it a "netinst iso")
<slangasek> ok, so the boot.img is a dd'able image containing the MLO, u-boot and boot.scr
<slangasek> plus, maybe, the uImage and uInitrd
<ogra_> i dont think its largely documented, i worte documentation for the very first implementation i did for lucid
<ogra_> but that very likely was removed during a wiki cleanup
<slangasek> heh
<slangasek> http://testcases.qa.ubuntu.com/Install/ARM/NetBoot
<ogra_> yeah, right, you can (or better should be able to, i havent tested that in ages, GrueMaster uses it though) use it for a real netboot with SD "jumpstart"
<slangasek> ogra_: ^^ that's what's linked from the iso tracker - could you review it please and see if anything needs improving?
<ogra_> will do
<slangasek> ta
<GrueMaster> slangasek: It looks right for omap4.  I'll need to edit it when we add armadaxp to the tracker though.
<ogra_> yeah, looks fine
<GrueMaster> Considering I wrote it last cycle.  :)
<ogra_> the variant where you create your own SD from the separate parts should be documented somewhere though
<slangasek> the NAND limitation is beagle-only, isn't it?  IIRC panda has NAND
<ogra_> nope
<ogra_> nothing has nand nowadays
<slangasek> ogra_: right, but "assemble your own" doesn't need to be documented in the test case... that can go elsewhere
<ogra_> you have either eMMC (if you are lucky) which is a lot cheaper than NAND ... or nothing and an SD slot
<slangasek> GrueMaster: ah, ok :)
<GrueMaster> the nand limitation only affects BeagleBoard.  Not XM or newer.
<GrueMaster> The only change to the test case is for armhf.
<ogra_> i dont think even linaro has any boards that have NAND atm
<slangasek> ogra_: well, I'm less interested in the specific flash technology built in than I am in whether it's present and loaded with a netboot-capable u-boot :)
<slangasek> so eMMC vs. NAND shouldn't matter?
<ogra_> indeed
<ogra_> as in: both are persistent storage it wont matter indeed
<GrueMaster> afaik, the only officially supported netboots going forward are omap4 and server platforms as they come online.
<ogra_> nontheless, we dont support any such devices atm
<slangasek> GrueMaster: sure
<ogra_> right, we shouldnt drop omap3 (huge community behind it) but we dont need to officially support it
<slangasek> anyway, it sounds like I'm already pointing to the right files now on the ISO tracker as a happy coincidence
<ogra_> (we also get it for free from the mainline kernel)
<slangasek> GrueMaster, ogra_: thanks for confirming
<ogra_> :)
 * ogra_ vanishes again for some late dinner
<GrueMaster> Ah, I see you added armadaxp and omap to the tracker.  Not sure if we will continue testing omap.  omap4 for sure and armadaxp (I was actually going to ask for it to be added as soon as the 3.2 kernel hits the pool).
<GrueMaster> At any rate, I have to leave for the day.
#ubuntu-release 2012-03-15
<mhall119> I have a couple of FFe's, if somebody could take a look at them.  Just version updates to fix a couple of bugs. https://bugs.launchpad.net/singlet/+bug/955317 and https://bugs.launchpad.net/ubuntu/+bug/955330
<ubot2`> Launchpad bug 955317 in singlet "Update unity-singlet to version 0.2.2" [Undecided,New]
 * skaet spots pitti looking at them...
<pitti> hehe
<mhall119> cjwatson: it seems pitti is already on the case though, thanks pitti
<mhall119> pitti: I can't change the "affects" on https://bugs.launchpad.net/ubuntu/+bug/955330, but the package is quickly-unity-lens-template
<ubot2`> Launchpad bug 955330 in ubuntu "Update quickly-unity-lens-template to version 0.0.3" [Undecided,New]
<mhall119> pitti: scratch that, I can change it, I just wasn't looking at the right place
<mhall119> updated now
<skaet> pitti,  http://paste.ubuntu.com/884888/ - figured it might be useful to be explicit that we'll not be switching over, and target the ubuntu-devel mail list with this info as well.   ( and forward Laura's email with it),   any tweaks you want to add?
<cjwatson> that's a pretty content-free mail.  how about we say WHAT feature? :)
<cjwatson> (also, I don't get the conservatism in this case; work item updates are not critical-path for release so I don't see why we shouldn't go ahead)
<Laney> If this is about WI tracking in blueprints, then indeed I don't see why we shouldn't go ahead. Slightly more conservative would be to wait a week or so to see how Linaro's rollout goes.
<mhall119> pitti: can I get your +1 on bug #955330 as well?
<ubot2`> Launchpad bug 955330 in ubuntu "Update quickly-unity-lens-template to version 0.0.3" [Undecided,New] https://launchpad.net/bugs/955330
<cjwatson> Another way to look at it is that broken work item handling would actually be *more* painful after release than before (when we want to start planning new feature development), so we'd be better off going ahead now while it doesn't really matter.
<skaet> cjwatson,  its more a case of not wanting to loose the tracking through a bad transition.
<skaet> yes,  concervative
<mhall119> does this new work-items feature have an API that can be used by status.ubuntu.com?
<cjwatson> skaet: but it's conservative at exactly the wrong time to be conservative
<mhall119> probably should ask that in an launchpad channel...
<cjwatson> we're sufficiently far past feature freeze that it doesn't matter if we lose tracking at this point, surely?
<skaet> cjwatson,  actually it does,  there are some events we need to straighten out,  and want to consult before setting up the q plans.
<cjwatson> whereas if it broke stuff while people were trying to put together plans for Q just post-release, that would annoy lots of people
<cjwatson> there are quite a few well-understood things that can be written up without further consultation
<skaet> cjwatson,  timing we're likely looking at is a month from now.   That gives things a bit of a chance to settle down,  and find issues, before we create the work items at UDS
<cjwatson> quite a few WIs can be written up pre-UDS, and I think we should be encouraging that when possible
<skaet> cjwatson,  am fine with it being used for new workitems - that should be enabled now.   Its the conversion of existing ones to the new form that has the risk of loss.
<cjwatson> oh, I see
<cjwatson> OK, that makes more sense
<ogra_> the arm team used to start writing up WI drafts about a month before final release during the last few cycles
<ogra_> i bet there are other teams doing that too
<cjwatson> in that case the mail should explain exactly what's happening - if I didn't know that I suspect most of the intended audience won't either
<skaet> cjwatson,  ogra_ good points though,  I'll ad that clarification to the email.    :)
<skaet> cjwatson,  I was going to forward Laura's email with the note,  which gave an overview of the change.   I'm not sure of the distribution list it went to,  since it was sent to a launchpad group members...
<cjwatson> ok, thanks.  mails to ubuntu-devel-announce probably ought to assume that people haven't read that.
<skaet> however,  will attempt to add a bit more clarity and context.  :)
<skaet> ubuntu-devel-announce or ubuntu-devel?
 * skaet was planning on ubuntu-devel,  but you may have a point...
<cjwatson> well, either way
<cjwatson> maybe just devel
<skaet> ok,  I'll stick with devel for now,  and we can use devel-announce when we do switch over.
<greyback> skaet: hi, Unity2D mini-release delayed, we found an issue with ATI hardware that we need to fix. didrocks proposes delaying release until Monday, to make sure we get everything right. That ok?
<skaet> greyback,  yes, that's ok.   Thanks for letting me know.
<greyback> skaet: np, good to keep you in the loop
<pitti> skaet: not sure, we now have a fixed WI tracker which can deal with both (it hasn't rolled out yet)
<pitti> skaet: but if you want to hold it back, no real objection from me
<skaet> pitti,  yeah,  I figure a week after Beta 2,  most of the key issues should be resolved is probably a good time for those who want to manually do the switch,  and then get the automated migration to occur around release candidate time.
<pabelanger> Coming from ubuntu-motu; I've just done my first FFe (bug 956188) and hoping when somebody has a minute to confirm I have all the required information? Thanks
<ubot2`> Launchpad bug 956188 in rebuildd "FFe: Sync rebuildd 0.4.1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/956188
<pitti> skaet: TBH I'd never switch existing blueprints
<pitti> skaet: I'd just keep the ones that we have as they are, and then start using the decidated WI field for the 12.10 specs
<skaet> pitti,  what about the ones that were postponed for P,  that folks want to rework for Q?
<skaet> those were the ones I was thinking might get targetted for the transition.
<pitti> they shouldn't be too hard to update, and AIUI LP will even migrate them automatically
<skaet> hmm... I've been using the term transitition in the context of "migrate them automatically",  sorry to be unclear.
<skaet> agreed by the way,  don't see any point in moving the historical ones over.   Only those from Q forward.
<skaet> pitti, ^
<pitti> *nod* (sorry for lagging, I'm in a meeting)
<ScottK> Daviey: Could you have a look at Bug #956167  please?
<ubot2`> Launchpad bug 956167 in opendkim "FFe: Upgrade to opendkim 2.5.0.1" [Undecided,New] https://launchpad.net/bugs/956167
<Daviey> ScottK: done.
<ScottK> Daviey: Thanks.
<Daviey> Does anyone know why these binaries were rejected?
<Daviey> https://launchpad.net/ubuntu/+source/quantum/2012.1~e4-0ubuntu1/+build/3261167
<Daviey> no mention on ubuntu-archive
<Daviey> jdstrand: I don't suppose that was part of the mass-reject that happend beginning of March? ^^
<jdstrand> Daviey: I don't recall, but think it might have been a binary (quantum-common?) that was provided by another package, both with the same version. I told zul
<Daviey> jdstrand: Ahhh, yes!  Thanks
<Daviey> jdstrand: It was a transitional thing, i think.. without proper Breaks/Replaces
<Daviey> jdstrand: thnaks
<jdstrand> np
<stgraber> skaet: do you know if any UIFe has been granted for the changes to ubiquity-slideshow-ubuntu?
<stgraber> skaet: I was considering doing a translation update and noticed quite a few changes that appeared in the branch after UI freeze: http://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/changes
<stgraber> my last commit (tag:53) was UI freeze, everything after that was during UI freeze
<skaet> stgraber, not remembering any, but need to do some homework to confirm.   My memory could be flawed here.
<skaet> Xubuntu is changing their logo, and that was approved.
<knome> \o/
<stgraber> skaet: I see a few other string changes in that branch, so if we choose to go with them, we should upload it ASAP so that translators have time to catch up
<knome> it might be my mistake to pull them in - sorry
 * knome blushes
<knome> i just pulled and pushed
<skaet> stgraber,  yeah, we need to get this sorted, and give the translators a chance here.
<stgraber> knome: all the png changes are fine as they are either optimizations or covered by your UIFe
<stgraber> knome: http://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/revision/437 is a string change though
<stgraber> and so are a few changes from Dylan
<knome> mmh. i wonder if my pulling and pushing merged those too
<stgraber> knome: the main branch is lp:~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html  so if that's what you used, then no
<knome> i did
<knome> ok :)
<knome> phew
<stgraber> knome: can you update debian/changelog for your changes too?
<knome> i've never done that, but i can.
<stgraber> knome: I can do it for you if that's easier
<knome> that would be great, i'm not even on my desktop :)
<knome> thanks!
<stgraber> knome: do you have a bug number for your UIFe (for the logo)?
<knome> just a sec...
<knome> that would be https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/955396
<ubot2`> Launchpad bug 955396 in xubuntu-artwork "UIFe: New Xubuntu logo" [Undecided,In progress]
<stgraber> thanks
<knome> np :)
<stgraber> skaet: this one changes the first slide of the slideshow: http://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/revision/431
 * knome is still a bit jammed after a huge back pain + migraine
<skaet> stgraber, some of the twitter stuff looks like Dylan's work,  not remembering a UIFe about it, https://bugs.launchpad.net/ubiquity-slideshow-ubuntu/+bug/942046
<ubot2`> Launchpad bug 942046 in ubiquity-slideshow-ubuntu "Hide Twitter stream for non-English slideshows" [Wishlist,Fix committed]
<knome> i think there's one change by me that isn't under UIFe, but it's minor for us, so if it doesn't get fixed, it's okay
<knome> i'm also afraid we might need an another UIFe for the ubuntu studio slideshow :/ need to check that with the US devs though and will ask them to file it
<skaet> stgraber,  hmm,  pangolin logo, but not aware of a UIFe for changing it...
<stgraber> skaet: http://paste.ubuntu.com/885625/
<stgraber> skaet: reverse-engineered changelog with comments inline :)
<skaet> stgraber,  am not spotting any UIFe's from Dylan in the last 30 days.. https://bugs.launchpad.net/~ubuntu-release/+subscribedbugs?orderby=-datecreated&start=0
<skaet> there's an old one in there from Oneiric time frame that should be closed (currently incomplete)
<stgraber> ouch, translations have been behind quite a bit ... just merged a new tarball and that's 500 of them being updated/added
<stgraber> skaet: so what should we do here, nag them to file UIFe or just revert?
<stgraber> I could probably file a generic bug though but I'm not the author of these changes so can only comment based on what I see in the branch...
<stgraber> my job is usually limited to updating translations and uploading the branch
<skaet> stgraber,  sorry to be slow,  thinking...
 * knome should probably know more about translating to know how much it sucks to have UIFe's all the time
<stgraber> if we're fair, everyone was expecting the first slide of the slideshow to change as it contained the ocelot
<skaet> would prefer to revert, but not sure if we're just going to make the problem worse, but the delay.
<stgraber> the added "!" if we're lucky will be merged automatically by LP as a fuzzy string and we'll be fine
<stgraber> the rest should get translated pretty quickly if we inform dpm
<skaet> ok,  go ahead and apply,  and we'll see if we can get the UIFe situation cleaned up,  and some education.
<stgraber> skaet: I'll file a generic UIFe bug and subscribe documentation + translations so they're aware of the changes that happened
<stgraber> and I'll subscribe the slideshow guys too so they know they would have needed a UIFe :)
<skaet> stgraber,  thank you - that would be much appreciated.
<skaet> interestingly enough there was one filed by Dylan in the Oneiric timeframe, so not sure why he didn't now... :P
<stgraber> skaet: bug 956554
<ubot2`> Launchpad bug 956554 in ubiquity-slideshow-ubuntu "[UIFe] Changes accumulated in the slideshow branch after UI freeze" [Undecided,New] https://launchpad.net/bugs/956554
<knome> thanks stgraber
<skaet> stgraber, I've subscribed ubuntu-release, and approved it.
<stgraber> skaet: thanks, just to confirm, you're fine with me uploading it without waiting for the doc team?
<stgraber> (would have poked jbicha but for some reason he isn't around ;))
<skaet> stgraber, I'll post in the #ubuntu-doc channel and let them know we had some string changes,  but yes go ahead.
<stgraber> skaet: ok, thanks
<stgraber> skaet: uploaded
<stgraber> I'll prepare another one next Thursday so we have the new translations for beta2
<skaet> stgraber, thanks.
<skaet> slangasek,  if you have time, could you take a look at https://bugs.launchpad.net/ubuntu/+source/rebuildd/+bug/956188,   I'm not sure of all of the implications of this at this point in the cycle.
<ubot2`> Launchpad bug 956188 in rebuildd "FFe: Sync rebuildd 0.4.1 (universe) from Debian unstable (main)" [Wishlist,New]
<pabelanger> hey, that's my request :)
<slangasek> skaet: it's a leaf package in universe, so the implications should be self-contained
<stgraber> ogra_, infinity: any of you two now if bug 567200 still applies to our current ARM images?
<ubot2`> Launchpad bug 567200 in ubiquity-slideshow-ubuntu "On Netbook Edition installer shows apps that are not installed" [Undecided,Confirmed] https://launchpad.net/bugs/567200
<slangasek> skaet: sorry, don't have time to look at it beyond that at the moment - but at first blush it looks reasonable to me
<skaet> slangasek, thanks.
#ubuntu-release 2012-03-16
<pabelanger> skaet, thanks for triaging the FFe
<stgraber> skaet: oh, slideshow discussion on -release ;)
<pitti> jibel: I guess I'll respin the server images, they fell prey to the broken python-defaults this morning apparently?
<pitti> running
<jibel> pitti, thank you
<Riddell> should release team meeting team updates go the day before or on the day?
<pitti> Riddell: somewhere between Thursday evening and Friday morning
<Riddell> oh that means I have a good 10 hours yet, it's still Friday morning in the US for that long :)
<ogra_> stgraber, i dont think it does, feel free to close (or i will just do it myself)
<pitti> jibel: ok, ubuntu-server tests are happy again
<stgraber> ogra_: ok, thanks, closed.
<skaet> Daviey,  not spotting an Server update in the mail list,  since arosales is on vacation today - are you handling?
<Daviey> skaet: Hmm, yes, yes i am
<skaet> Daviey, ta.
<Daviey> skaet: I thought i had sent it, still a draft. soory.
<pitti> skaet: good morning
<skaet> good morning pitti
<pitti> skaet: my calendar currently gives two times for the release meeting, probably due to DST skew
<pitti> skaet: is it in one or two hours?
<pitti> i. e. is it tied to UTC, US DST, or EU DST?
<skaet> it was supposed to be tied to UTC
 * skaet sighs
<pitti> or should we compromise and start at :30
<ScottK> GMT would be more fun.
<pitti> or a weighed average by number of community people on each side of the pond? :-)
<skaet> pitti,  I like that compromise
<skaet> I'll send out email.
<pitti> skaet: so, from my POV I'm just fine with "in an hour"
<pitti> skaet: mail> thanks
<skaet> pitti,  yes,  was thinking for European folk it might be better to move it an hour earlier for the DST period.
<pitti> yes, absolutely
<skaet> it was a question I wanted to ask.
<pitti> it's late enough as it is
 * skaet nods
<pitti> and in two weeks it'll be at the same time as usual
<pitti> I just wondered what happens today and next week
<pitti> 6-7 pm seriously cuts into pub time :)
 * skaet really doesn't like DST time skew.... :P
<skaet> pitti,  agreed.
 * pitti takes a huuge big hammer and makes the world flat again, as it used to be
<pitti> problem solved
<skaet> lol
 * skaet needs to take lessons in solving problems from pitti.  :)
<ScottK> Make it later now and earlier in the winter to maximize the inconvenience.
<pitti> skaet: wasn't me, was Terry Pratchett :)
 * ScottK - being fortunately situation somewhat in the middle - isn't much affected.
<pitti> ScottK: east coast?
<ScottK> Yes.
<stgraber> well, with the DST change it was now moved to my usual lunch time, but I can live with waiting an extra hour for food ;)
<ScottK> So anything that's remotely OK for Europe or the west coast US, WFM.
<Daviey> skaet: can we just do the meeting twice?
<ScottK> stgraber: Are you the platform person for today's meeting?
<pitti> oh yes, more meetings!
<Daviey> pitti: wait, we can just decide something like this.. lets schedule a call to discuss what structure to have a meeting to decide how to do it.
 * pitti imagines Daviey with pointy hair
<ScottK> Well, you don't want to just jump into the pre-meeting without planning it.
<ScottK> (that last, ironically enoug, was a Dilbert quote)
<Daviey> good point, ScottK - can you form a working group to compose an agenda?
<skaet> Daviey - hmm,   one special one for those who want to ask questions about the missing server report  - is that what you want? ;)   j/k
<Daviey> skaet: suuuuure
<pitti> . o O { TGIF! }
<skaet> pitti,  +1 ;)
<pitti> skaet: server report just hit the mail archive
<skaet> Daviey,  pitti - thanks.
<Daviey> Friday makes me sad.. it's a firm reminder yet another week has passed, with more yet to do. :(
<tumbleweed> tying it to UTC would suit me :) (but then friday evening is non-ideal for me anyway)
<Riddell> Daviey: I think that's a feature of the Julean calendar rather than skaet's meeting schedule :)
<pitti> Daviey: we have a saying in Germany -- "our errors of today are our bread of tomorrow" :)
<ScottK> stgraber: Assuming you are, I think we ought to discuss where to go re bug 934593 at the meeting.
<ubot2`> Launchpad bug 934593 in python3-defaults "python-all-dev, python-dev must be Arch: any for multiarch" [Undecided,Fix released] https://launchpad.net/bugs/934593
<Daviey> Great.. bread for breakfast, lunch and dinner over the weekend :(
 * Riddell tried to apply pitti's saying to the Euro
<pitti> Riddell: hm, it's really an engineer's motto; doesn't work so well for financial markets, I think
<Riddell> ah :)
<pitti> for those it's probably more like "our errors from today I care a rat's ass about" or so
<ogra_> as long as my money piles up right now :)
<stgraber> ScottK: cjwatson is doing foundations again now that he's back
<pitti> oh, I thought cjwatson said he's off today
<ScottK> OK.  Thanks.
<ScottK> He did.
<stgraber> ah, ok:)
<stgraber> then maybe I'm supposed to do foundations and nobody told me ;)
<ScottK> He said to reply to he mail with questions, but this is about something that came up sense, so not sure.
 * pitti goes back to untangling pygobject
<ScottK> I guess as long as slangasek is there, we can resolve it.
<pitti> s/sense/since then/ ?
<apw> pitti, what time is the release meeting today, i was expecting it to be 16:00 GMT but its in my cal an hour early
<pitti> apw: snap!
<pitti> apw: I was just pointing this out, skaet said she'll mail about that
<skaet> apw,  DST skew time... :P   I've just sent out notes.
<Riddell> apw: see scrollback :)
<skaet> we'll have it at 1500 UTC today,  and lets discuss in meeting if we want to keep it there through the summer or not.
<pitti> so, 1500 it is
<Riddell> I just worked out what DST stands for, not a british english term that
<pitti> Riddell: oh, what do you say?
 * skaet curious too...
<Riddell> "summer time" and specifically "british summer time" is what we call our shift
<pitti> we just call it (literally) "summer time"
<Daviey> Riddell: With devolution, you don't call it Scottish Summer Time?
<pitti> which kind of makes sense, given that it doesn't actually save daylight :)
<Riddell> Daviey: not yet but I expect when England finally gets independence from us they'll take the opportunity to stay on BST all year round
<Daviey> Riddell: did you hear Scotland was thinking of dropping BST?
<pitti> *chuckle*
<Riddell> Daviey: that crops up every year, some bored English politician says "we should use BST all year" and some bored Scottish politician says "err it's not healthy for it to be dark until 09:00 each morning"
<skaet> brendand, will you or ara be representing cert at the meeting today?   (time will be at 1500, btw)
<brendand> skaet, me from now on
<apw> skaet, is this meeting still a Q&A only ?
<skaet> apw,  yes,  meeting is Q&A style again,  it seemed to work fairly well last week, so the experiment will continue.
<skaet> brendand,  coolio.   thanks (and noting)
<skaet> apw,  could you take a look at Cert's blocker bugs before the meeting - would like to know how many of them are going to get fixed before Beta 2,  and if there are some that just flat out aren't going to make the release.
<skaet> ?
<brendand> apw -https://chinstrap.canonical.com/~hwcert/blockers-precise.html
 * apw suspects that is a tall ask in 15m
<apw> though actually only one is marked for precise ?
<brendand> apw - they only show up on the report if they have 'precise' and 'blocks-hwcert' tags
<apw> stupid report saying those other releases
<brendand> apw - ah, you mean the series column
<brendand> apw - i have no idea where it fishes that from
<brendand> apw - it's based off the kernel reports so...
<apw> a cirtain orifice by the looks of it
 * brendand whispers 'blame launchpad'
<brendand> apw - be assured they are all precise blockers though
<slangasek> ScottK, stgraber: ah, I'm covering foundations today; cjwatson is off, yes
<ScottK> slangasek: He is, so see you in #ubuntu-meeting ...
<Laney> What do you think to me manually syncing a package I just uploaded to Debian to avoid having to wait for LP to notice it? It's NEW in Ubuntu.
<Daviey> Laney: is it accepted into Debian?
<Laney> yes :-)
<Laney> I would quite like to upload this and then give-back the rdep before EOD
<infinity> Laney: If it's NEW in Ubuntu it's going to need some manual intervention anyway.
<infinity> Laney: Or do you just mean binary NEW?
<Laney> No, I mean "Source NEW and copious hassle" :P
<ScottK> Laney: Is it in incoming?
<Laney> I would expect so
<ScottK> Get infinity to sync it from incoming the old fashioned way.
<Laney> http://incoming.debian.org/haskell-llvm-base_3.0.0.0-3.dsc
<ScottK> We really should minimize the touching of stuff that's supposed to be a sync.
<infinity> Laney: If it's source NEW anyway, just wait and sync it normally.
<infinity> Laney: And poke me later/tomorrow and I'll review it.
<Laney> roger
<GrueMaster> infinity: Can you publish the armadaxp image?
<GrueMaster> It is waiting approval.
<infinity> GrueMaster: Done.
<GrueMaster> thx.  can I also beg for a netboot reroll before the weekend???  Pretty please?
 * GrueMaster flitters eyelids.
<infinity> Maybe.
<infinity> GrueMaster: There's an ABI bump in the pipe for linux and linux-ti-omap4 as well, so no point doing multiple d-i uploads.
<infinity> GrueMaster: Once all those metas are revved and such, we can bump them all in d-i.
<GrueMaster> Works for me.
#ubuntu-release 2012-03-17
<ogasawara> cjwatson: when you have a moment, could you add linux-backports-modules-3.2.0 to the acl list for kernel upload rights.  I'm currently unable to upload.
<stgraber> ogasawara: looking
<stgraber> ogasawara: done
#ubuntu-release 2012-03-18
<Laney> if someone has 2 minutes today there are some haskell packages in NEW
<Laney> (syncs)
<ogasawara> whenever someone has a moment, could I get the linux-backports-modules-3.2.0 packages approved in the New queue
<ScottK> Laney: Done.
#ubuntu-release 2013-03-11
<cjwatson> Image build errors: #is has fixed up iso.qa.ubuntu.com and I've re-posted the affected images
<cjwatson> Wow, thanks to whomever almost cleared out component-mismatches
<slangasek> y/w - they were all demotions, so it didn't require much thought ;)
<slangasek> cjwatson: hey, I saw you landed support for UbuntuKylin in livecd-rootfs; what else is needed before we can turn on dailies?  Does it just need a properly-crafted cron entry?
<cjwatson> slangasek: general cdimage support; I'll be working on that today
<slangasek> ok
<infinity> slangasek / cjwatson: Yeah, I've been shy about c-m, since it doesn't report on proposed, but I suspect most of the stuff in there was rather old and known-wrong by now.
<xnox> slangasek: i was hoping to keep clvm in main, until we have an HA available solution without clvm.
<xnox> and filed a seed change to that affect, but didn't get it mergerd.
<xnox> will I need a M.I.R. now?
<jpds> xnox: No, you can't use mir for HA.
<jpds> ;-)
<xnox> M.I.R.  - main inclusion reports != Mir display server
<jpds> I was pulling your leg.
<xnox> =) evil
<xnox> this is a second unfortunate name clash. Mir vs M.I.R. and UDD vs UDD
<Laney> Other RT members: Has anyone had thoughts on the logind FFe?
<tumbleweed> I was avoiding thinking about it. My gut feeling was: "as decided at the last UDS", you mean "as decided at the UDS 2 days before FF" (although I know it's been in progress for longer than that)
<Laney> there were some WIs about it from Copenhagen but the detailed implementation plan was decided last week I believe
<Laney> I'll write down what I understand to be the steps in the bug but I'm not confident enough to take the decision
<cjohnston> The upgrade of VirtualBox to 4.2 in raring broke vagrant. Vagrant has a new upstream release that isn't yet in debian. Would you guys rather just have a patch to fix what is broken, or the upstream release? I am assuming due to FF just a patch?
<xnox> cjohnston: patch, please =)
<cjohnston> ack
<tumbleweed> cjohnston: if you have a simple patch, sure. But it's still early days of the FF, and vagrant is a leaf package, so your FFe would almost certainly be accepted
<cjohnston> either way, debian does not have the 4.2 fix or the new upstream version, and there is nothing else that's released that we need to my knowledge, so I'll do a patch to make it quicker.. we already have one patch in from upstream
<cjohnston> thanks guys
<jbicha> does goffice need to be manually kicked to migrate out of -proposed? now that we have goffice0.8 there shouldn't be anything keeping it back, right?
<stgraber> jbicha: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows that migrating goffice would break a whole bunch of stuff
<jbicha> stgraber: but it's lying, right?
<ScottK> jbicha: Why do you think that?
<jbicha> goffice0.8 should be providing everything that gnucash & gnome-chemistry-utils needs
<jbicha> do we need a no-change rebuild to unconfuse britney?
<ScottK> Do they need rebuilding for the new version?
<ScottK> Britney is rarely actually confused.  It's more commonly unclear about what is upsetting it.
<cjwatson> Let me check
<cjwatson> I suspect goffice and goffice0.8 need to be hinted in together.  I'll try that
<cjwatson> A no-change rebuild will not help
<cjwatson> Hinted.  Let's see how that works.
<stgraber> smoser,utlemming: are you planning on doing a beta1 release for the cloud images (just wondering as you've done alpha2)?
 * smartboyhw wonders about Xubuntu too
<stgraber> smartboyhw: xubuntu is participating
<smartboyhw> stgraber, /me doesn't see email
 * smartboyhw throws his GMail
<stgraber> smartboyhw: it wasn't a public e-mail
<smartboyhw> stgraber, weird:P
<smartboyhw> sorry then
 * smartboyhw thinks almost everyone is in (except Desktop) 
<cjwatson> jbicha: That worked
<stgraber> JackYu: ok, I marked both you and ypwong as contact for UbuntuKylin beta1
<jbicha> cjwatson: great!
<stgraber> JackYu: starting today at 21:00 UTC, images will start showing up under the beta1 milestone on iso.qa.ubuntu.com, you can test them there and report your results. Once you're happy with the images, let me know and I'll mark them ready for you.
<stgraber> JackYu: for the announcement, I'll also need an URL to include pointing to some kind of announcement and release notes for UbuntuKylin
<cjwatson> Well.  Hopefully
<cjwatson> If I can make the builds work
<cjwatson> I'm currently waiting for ubuntu-meta 1.296 to reach raring before I try again
<JackYu> stgraber: thanks.
<ScottK> cjwatson: Is there any chance of Ubuntu Gnome images today or is that the next iteration post-beta 1?
<stgraber> cjwatson: I created the product on the iso tracker and updated the python branch to know where to push it. So hopefully the first succesful build should get properly published the whole way through
<cjwatson> ScottK: I have to wait for https://code.launchpad.net/~cjwatson/launchpad/add-ubuntu-gnome/+merge/152548 to be reviewed/landed/tested/deployed
<cjwatson> I plan to bug the Australians about it as soon as I see them online
<ScottK> OK.  So later.  Thanks.
<cjwatson> stgraber: Thanks.  I added a test case to match
<JackYu> stgraber: any requirement of the URL? is the Wiki page OK? https://wiki.ubuntu.com/UbuntuKylin or the forum website: http://www.ubuntukylin.com/ ?
<rtg_> why is linux (3.8.0-12.21) still in -proposed ? shouldn't britenny have kicked it loose ?
<rtg_> or is it spelled brittany ?
<rtg_> doesn't look right either
<stgraber> JackYu: most flavours give a URL to a specifc announcement, something like http://www.ubuntukylin.com/news/ubuntukylin-13.04-beta-1-announcement
<stgraber> JackYu: that way the page remains relevant in the future and covers specifically what was done for the milestone
<stgraber> JackYu: but that's up to you ;) if you prefer to simply point to the website or wiki, I'll just do that
<cjwatson> rtg_: it's spelled "proposed-migration" :-)
<cjwatson> (The tool on disk is spelled "britney")
<rtg_> hmm
<cjwatson> d-i hasn't been updated, for one thing.  I'll do that now
<rtg_> cjwatson, is promotion dependent on d-i ?
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt has a list of packages broken
<cjwatson> Yes
<rtg_> ok
<JackYu> stgraber: Sure. please use the website first. I will create a page soon and update the URL.
<cjwatson> Yeah, it's just d-i.  Scroll down to the end of update_output.txt where it tries all of linux, linux-meta, and linux-signed at once
<stgraber> JackYu: ok, let me know when you have the final URL. I don't technically need this until Thursday.
<JackYu> stgraber: ok:)
<rtg_> cjwatson, ok, guess I should learn how to update d-i
<rtg_> I think apw has done it as well
<cjwatson> meh, Adam and I are both fine with doing it, and it often needs to go along with archive admin too
<rtg_> wfm
<apw> rtg_, yeah it all goes wrong cause you need the aa to new things anyhow
<cjwatson> d-i's on its way now
<slangasek> xnox: binaries don't require an MIR
<xnox> slangasek: ack.
<xnox> slangasek: now the question is, how do I seed clvm into server-supported, without it appearing on the server.iso?
<xnox> or shall I simply seed it into supported.
<slangasek> xnox: "*supported" is unrelated to what goes on the ISO
<stgraber> xnox: just use supported-misc-servers
<stgraber> xnox: or one of the other supported-* if it's not server-specific
<stgraber> supported-server is based on: supported-misc-servers supported-hardware-common supported-installer-common supported-network-common supported-sysadmin-common build-essential supported-development-common supported-kernel-common
<xnox> awesome thanks.
<xnox> that should do it, I hope.
<stgraber> utlemming, smoser: so I'm going to remove the cloud images from the beta1 manifest for now. Let me know if you want to participate and I'll add you back in.
<xnox> it worked =)
 * slangasek promotes
<infinity> rtg_, apw, cjwatson: FWIW, I'm not against the kernel team learning to do d-i ABI bumps after the override/promotion bugfix is landed, but right now d-i promotions (well, more precisely: kernel promotions) explode the whole world and need an AA to babysit, so not much point.
<rtg_> infinity, ack
<infinity> cjwatson: Speaking of, I'll get this override race.  Thanks for the upload.
<cjwatson> infinity: you might not have to
<infinity> cjwatson: Oh, did your fix land?  In that case, I'll check and see if I have to, and do a happy dance if I don't. :)
<cjwatson> infinity: yeah, deployed this afternoon, but please do check
 * infinity nods.
<cjwatson> (maybe we should do that d-i meta-udeb magic before encouraging more people to do d-i bumps, too)
<infinity> Yeah.  I'll do that this week and upload it after stgraber's beta to avoid being disruptive.
<infinity> Oh, the other minor gotcha is the part where amd64 builds silently ignore linux-signed if it's out of sync.
<infinity> I think maybe we should just make that a hard failure instead of a WTF.
<infinity> Otherwise, people will get caught by signed being unbuilt or NEW again and again.
<cjwatson> infinity: There was a tedious syntactic problem in pkg-list
<cjwatson> It's optional because otherwise other architectures break ...
<cjwatson> So I need to fix that properly
<infinity> cjwatson: Sure, but one could just do a test in Makefile and error out.
<infinity> cjwatson: Since there's already a part where we copy signed if it's there.
<cjwatson> I guess, but that sucks when we have all this fancy pkg-list stuff.
 * infinity shrugs.
<cjwatson> But be my guest :)
<infinity> If you want to make pkg-list do something fancy, go nuts, I just want the build to not silently succeed and be broken. :)
 * cjwatson fixes the cause of that Lubuntu image build failure
<cjwatson> Kylin looking more promising ...
<phillw> cjwatson: thanks :)
<ScottK> stgraber: I think we're about at the time where migration freezes should go in place.  Since you volunteered to take care of that ....  If you look in the bzr history for the block I put up for Alpha 1/2, please just use that one again.
<stgraber> ScottK: ok, will do
<ScottK> Riddell: ^^^
<ScottK> Thanks.
<Riddell> aww I wanted to upload one last thing
 * Riddell hurries
<ScottK> Riddell: We can still force stuff through as needed.
<Laney> unblock overrides block afaik
<stgraber> damn lillypilly is really slow today... I've been waiting for rmadison results for the past 3min ;)
<cjwatson>  17:38:15 up 93 days, 19:56,  9 users,  load average: 21.35, 24.57, 19.35
<stgraber> Riddell: what's up with your qtwebkit-source force hint? it's been there for a while now and the package is still in proposed
<ogra_> cjwatson, oh, a pandaboard compiling webkit ?
<ogra_> (on SD card)
<cjwatson> no, lillypilly, I fear
<ogra_> ouch
<Riddell> stgraber: dunno, I've not looked into it alas
 * ogra_ hopes they didnt secretly replace lillypilly with a panda then 
<cjwatson> Oho!  http://cdimage.ubuntu.com/ubuntukylin/daily-live/current/
<ogra_> whee
<stgraber> and it published to the tracker, success!
<ogra_> oversized though ... better drop all the asian langpacks :P
<xnox> ogra_: more like german, french and spanish.
<ogra_> pfft, you cant install without having german, french and spanish installed :)
<ogra_> Riddell, so somehow that nexus7 kubuntu image fell under the radar due to everyone being busy with blogposts ... should we start digging back in during this week ? or do you prefer to wait until after your beta
<stgraber> Riddell: hmm, can't find anything obviously wrong with it or reference to the source/binaries in the britney output. I'm pretty new at that stuff though so may be worth having cjwatson take a look to see what's wrong.
<stgraber> anyway, not really beta1 related ;)
<cjwatson> Hmm
<Riddell> ogra_: I still haven't got my nexus to wake from the dead, I just ordered another one but that'll take a few days to arrive so I can't see it happening for beta 1
<ogra_> Riddell, ok, i'll keep it on my todo
<Riddell> stgraber: yes nothing in excuses or update_output.txt
<cjwatson> Riddell: 16:22 <cjwatson> Oh, and if you're adding a new file there you need to edit britney.conf in lp:~ubuntu-release/britney/britney2-ubuntu/
<cjwatson> you didn't do that
<Riddell> aah
<cjwatson> see e.g. r324 in that branch
 * Riddell makes it so
<stgraber> ScottK: the block is now in place
<stgraber> will be extended if any other flavour sends me a list, though the current one appears to cover most of the core bits
<bdmurray> slangasek: I'm inclined to release the fix for bug 780602 to precise although there is not fix for Q yet.  cyphermox is working on it though last I heard.
<ubot2`> Launchpad bug 780602 in OEM Priority Project precise "nm-applet leaks memory and stops functioning after a while" [High,In progress] https://launchpad.net/bugs/780602
<slangasek> bdmurray: yeah, seems reasonable to me
<ScottK> stgraber: Thanks.  To the extent it doesn't cover all the core bits, I messed up.  Please feel free to extend it.
<phillw> stgraber: I'm not sure what you require - do you want a list of what is on lubuntu iso's ?
<ScottK> phillw: By source package.
<phillw> I know Julien has the list somewhere... I'll go dig :)
<stgraber> phillw: if there are source packages you want to make sure won't change between now and the release of beta1, send me a list and I'll update the hints. If those are packages that only you guys maintain, it's probably fine just not to upload them
<phillw> stgraber: on my last chat with Julien over the weekend, he assured me that he was finished with any updates pertaining to 'LX' stuff and was 'good to go' for Beta 1.
<phillw> whilst I am a 'release' manager, I'm there only for when he isn't available :)
<stgraber> slangasek: do you think introducing the 3 missing user jobs to make upstart user sessions usable requires a FFe? (they wouldn't be used by default, it's only for those who want to turn on user sessions by modifying /etc/upstart-xsessions)
<xnox> imho, we agreed that it's fine =)
<xnox> but I am expecting all those packages blocked by beta1 now.
<xnox> (although shouldn't affect them at all...)
<stgraber> xnox: yeah, they are, but I'd still upload to -proposed just so I don't have to remember to do it later ;)
<xnox> stgraber: I'd say "got for it", but I don't have the appropriate hat to say that.
<tkamppeter> Due to the Rolling Release discussion and the UDS last week I did not succeed to do all version updates in time for FF last Thu. Especially Ghostscript 9.07 is missing as it depends on the fix of bug 1126427 which RAOF will work on tomorrow (today is a holiday in AU). Can I update Ghostscript after this fix without a formal FFe, probably tomorrow (Tue) or Wed?
<ubot2`> Launchpad bug 1126427 in lcms2 (Ubuntu) "LCMS2 needs multi-threading fixes to work with the new Ghostscript 9.07" [High,New] https://launchpad.net/bugs/1126427
<xnox> Files a new FFe bug 1153731
<ubot2`> Launchpad bug 1153731 in ubiquity (Ubuntu Raring) "[FFe] Ubuntu One sing in or up or skip plugin" [High,New] https://launchpad.net/bugs/1153731
<seb128> tkamppeter, it's better to file a FFe bug I think, that shouldn't take too much time and will make review easier, just state the content of the update and the rational
<infinity> tkamppeter: Do you have a quick summary of changes from 9.06 to 9.07?
<infinity> tkamppeter: New libgs, for instance?  API changes, or just ABI?  Massive new untested features?
<stgraber> infinity: oh, since you're around :) do you have an opinion (FFe or not) on those 3 upstart user session jobs I'd like to push (dbus, gnome-session and gnome-settings-daemon)? they don't cause any change to the default user, they just make it possible for those who want to test user sessions (after they enabled them in /etc/upstart-xsessions)
<seb128> hum
<seb128> speaking of which
<seb128> is there any chance we change the ubuntu session to be an upstart user session in raring? ;-)
<infinity> stgraber: I'd rather you get vorlon's opinion on that, as he's been closer to the development and testing of those features.
<infinity> seb128: See above.
<stgraber> seb128: not sure, that change would definitely need a FFe though :)
<seb128> infinity, do you avoid using slangasek on purpose or just old debian habit? ;-)
<seb128> stgraber, ok, do you plan to file a ffe then?
<infinity> seb128: He's still vorlon on OFTC, I don't context switch well.
<infinity> seb128: I don't still call cjwatson Kamion because he isn't Kamion anywhere anymore.
<stgraber> seb128: it mostly depends on the state of the user jobs for the other gnome bits. The upstart feature is in and with the jobs I have here (dbus, gnome-session and gnome-settings-daemon) it makes it all usable.
<seb128> stgraber, well, a few desktopers have been running it for some weeks without issue
<seb128> so I would +1 changing the unity session
<seb128> it = whatever was in your ppa when you called for testing
<seb128> does that include those jobs?
<Laney> it also seems to work under shell here so perhaps the gnomers would be interested in that
<stgraber> seb128: ok, good to know. I wasn't sure whether we actually felt like this would bring us anything for 13.04 (as in, actual advantage vs standard gnome-session since we don't have packages shipping jobs yet)
<phillw> cjwatson: I'm sorry for repeating, as you could already have answered when my link was down (it is dying regularly today), is there any news on the lubuntu alternates.. can you repeat an answer to balloons in case I disappear again.
<seb128> well, it's a chicken-egg thing
<seb128> if you don't enable it we can't start shipping jobs
<stgraber> Laney: yeah and I remember testing with fallback too and it worked. I guess anything using gnome-session should be fine
<cjwatson> phillw: Dinner intervened
<Laney> Hmm, actually there was something
<phillw> cjwatson: I have no issues at all with dinner... glad that I'm able to use the microwave for mine after the earlier power cuts :D
<cjwatson> phillw,balloons: Lubuntu alternates building again now
<Laney> Replacing or otherwise using the other Xsession.d snippets - here {ssh,gpg}-agent and im-config
<stgraber> seb128: ok, so I'll try to get the missing bits (dbus, gnome-session, gnome-settings-daemon) in today (with or without FFe, depending on how slangasek feels). Then I'll send another e-mail to ubuntu-devel saying that people can test using what's in the archive by just changing /etc/upstart-xsessions and if it all looks good, we'll do the switch post-beta1 (Friday-ish). Sounds good?
<Laney> I didn't check if the final package brings those back
<cjwatson> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<cjwatson> 19:52 <cjwatson> phillw: Dinner intervened
<cjwatson> damn, sorry
<cjwatson> 19:53 <Laney> Hmm, actually there was something
<cjwatson> 19:53 <phillw> cjwatson: I have no issues at all with dinner... glad that I'm able to use the microwave for mine after the earlier power cuts :D
<cjwatson> touchy touchpad
<Laney> stgraber: ^
<stgraber> Laney: nope, I haven't dealt with those yet. Those should be converted to upstart jobs in their respective package + add a '[ -n "$UPSTART" ] && return' statement to their Xsession scripts
<stgraber> Laney: do we have a list of those?
<Laney> Then you'll have to move the script back to 59upstart?
<seb128> stgraber, Laney: sounds good to me
<Laney> you should be able to use apt-file or whatever to see what puts scripts in Xsession.d
<stgraber> Laney: nope, we have 00upstart that sets UPSTART in the environment and 99upstart that sets STARTUP
<Laney> But currently upstart wipes $STARTUP out anyway so there's not much point making them conditional
<stgraber> Laney: hmm, indeed :) so we just need matching user jobs for them
<Laney> It appears to make sense to me to support them in $STARTUP up until they get converted to jobs and then [ -n ... ] them out once that happens
<stgraber> Laney: well, yes and no, the problem at least with the IM stuff is that they have a tendency to start a dbus session bus, which creates a bit of a mess as upstart spawns dbus-daemon too. So while in theory we could simply append to STARTUP, it was far safer to just override it, thereby ensuring we at least get a working session everytime (even if some bits are missing)
<Laney> so we have to make sure to get a job for that one ;-)
<Laney> It seemed hard to me in my ignorant poke though - spawns three processes IIRC
<stgraber> since we're talking about a bit more than just the 3 missing user jobs, I'm going to file a generic FFe for that stuff, so I don't need to nag people for every affected package (as I'm guessing we'll find a few more as we go)
<Laney> I think doing the basic three jobs is fine for now
<slangasek> stgraber: 3 missing user jobs> I don't think that warrants FFe paperwork, it's obviously low-risk
<stgraber> slangasek: ok, good. I'll finish testing then and just push those to the archive
<cjwatson> phillw,balloons: Lubuntu alternate build succeeded
<phillw> cjwatson: thanks :)
<utlemming> stgraber: cloud images are going for B1 for raring
<utlemming> also, does anyone know when Hardy Server EOL's?
<stgraber> utlemming: ok, adding them back to the manifest then
<utlemming> stgraber: did someone tell you otherwise, or no ack?
<stgraber> utlemming: nope, I just dropped it earlier today as I wasn't explicitly told you'd do beta1. (Those milestones are opt-in, so I need to be told who participates ;))
<utlemming> stgraber: right, okay, good to know. Please opt in the cloud images for Beta-2 and RC as well then.
<stgraber> utlemming: ok
<infinity> utlemming: hardy EOL is around raring release, give or take a week or two.
<utlemming> infinity: ack, thanks...and that's what I thought :)
<infinity> utlemming: From a support perspective, it's effectively EOL already except for critical security issues.
<Daviey> infinity: hey, can you weigh in on - bug 633109.  I see you commented on it before.  Can you follow up further.  It's in the queue, and would be nice to either reject or process it.
<ubot2> Launchpad bug 633109 in dput (Ubuntu Precise) "No progress bar for sftp uploads" [Undecided,New] https://launchpad.net/bugs/633109
<infinity> utlemming: (Not that we wouldn't take paid support for it, of course, but you know what I mean, developers gave up a while ago on SRUs)
<utlemming> infinity: right. I'm just looking forward to turning hardy off
<utlemming> infiinity: for cloud image builds
<infinity> Daviey: Running out the door for a doctor's appointment, but I'll weigh in when I get back later and either reject or accept, yeah.
<Daviey> infinity: thanks
<stgraber> cronjobs disabled for the flavours taking part in beta1
<stgraber> ScottK, Riddell: are you ready for your first beta1 candidate or are you waiting for some packages to finish building?
<tkamppeter> infinity, API of libgs does not change, update is practically only bug fixes. No important new features.
<tkamppeter> infinity, the usual every-six-months update of GS.
<infinity> tkamppeter: If there's no ABI or API bump, and no massive new changes, I'm fine with it.  In fact, other than the version number, that doesn't sound like it has "features" worthy of an FFe in the first place.
<Daviey> stgraber: Did we stop bzr committing cron changes?
<stgraber> Daviey: no, but we usually don't commit the changes done temporarily during milestone testing
<stgraber> so that on Thursday I can simply do a bzr revert and have nusakan back to normal
<tkamppeter> infinity, see release notes on http://www.ghostscript.com/doc/current/News.htm
<ScottK> stgraber: AFAIK we're ready.
<stgraber> ScottK: good. I'll make sure everything is built or building before I EOD then (in 45min or so)
<ScottK> Thanks.
<tkamppeter> infinity, do you know about the differences of the GNU Affero General Public License (AGPL) to the GPL? Can we still ship GS?
<Daviey> stgraber: Ok, I thought i was criticised previously for not committing a change like that before.  bzr reverting to a revision shouldn
<Daviey> 't  be problematic. :/
<stgraber> Daviey: ah, I don't think I ever complained when people made temporary changes during milestone testing. I usually complain when there are leftovers after a milestone is out ;)
<jdstrand_> can someone push chromium-browser 25.0.1364.160-0ubuntu1 from raring-proposed to raring?
<jdstrand> it is stuck in -proposed because it ftbfs on armhf. that is being worked on
<jdstrand> (we did this last time fwiw)
<stgraber> jdstrand: I'll do that
<jdstrand> stgraber: cool, thanks :)
<stgraber> jdstrand: pushed the britney hint so it should get migrated to raring with the next run
<jdstrand> perfect, thanks again :)
<robert_ancell> ScottK, can we remove the block from lightdm? It was a few hours late to the feature free and I asked for an exception. I'm not sure who I have to convince it's good to go, but there don't seem to be any problems coming from -proposed
<ScottK> robert_ancell: Did you file an FFe and was it approved?
<robert_ancell> The changes are mosly bug fixes and one major improvement (adding Qt5 support)
<seb128> ScottK, there is no FFe material in there...
<seb128> or nothing impact on current installs at least
<robert_ancell> ScottK, I was going on the "we will be lenient due to the confusion around 13.04" and it was just a few hours late
<seb128> you can consider binding fors Qt5 as a new feature, but that will not break anything existing
<seb128> and it was only a few hours late
<ScottK> OK.
<robert_ancell> ScottK, ta
<seb128> ScottK, thanks
<ScottK> I dropped my block.  It may be caught up in the Beta 1 block though.
<ScottK> If it isn't, it probably should be.
<ScottK> Yes.  It is.
<seb128> ScottK, thanks, I was surprised that you blocked it, that was not obvious
<seb128> I had to go look at what was happening when robert_ancell pointed it didn't move to raring
<seb128> seems a bit harsh to have blocked it this way on friday morning, there was nothing disruptive, it was not that late and we were told there would be some slack on friday to compensate for the vUDS delays
<ScottK> I told everyone I was blocking it at the time.
<seb128> everyone who was on IRC at the time I guess
<ScottK> It was blocked because ogra_ said things needing FFes could be uploaded safely since the queue was frozen (which wasn't and isn't the case)
<ScottK> So I was _TOLD_ it needed an FFe.
<seb128> ok, blame ogra_ then:
<seb128> !
<seb128> not sure where he got that from
<ScottK> He was deeply confused.
<seb128> we never queue bloqued for FF
<ScottK> We straightened him out.
<ScottK> Yep.
<ScottK> He was mixing up Beta freeze and FF.
<cjwatson> stgraber: cron> careful of ogra's temporary phablet hack, too
<cjwatson> stgraber: Oh, did you figure out the Edubuntu/amd64 build problem?  What was it?
<stgraber> cjwatson: no idea, just triggered a new build :)
<stgraber> cjwatson: oh, actually it looks like it failed and just published an old livefs. I'll have to investigate then
<stgraber> highvoltage: or you if you have more time than I do ^
<highvoltage> ok
<cjwatson> *something*'s installing the kernel one phase too early, but I couldn't quite see what
<highvoltage> I can tomorrow afternoon (well, morning EDT)
<highvoltage> hmm, that sounds familiar
 * cjwatson hits it with set -x
<cjwatson> no, wait, I've misunderstood something here
<stgraber> cjwatson: hmm, did something recently changed in grub2? I had a very quick look at the build failure for Edubuntu and this matches another failure I've been told about in upgrade testing (when running under lxc though, so really not sure if that's the same problem)
<cjwatson> No
<cjwatson> And linux-image-extra-blah is installed at nearly exactly the same point in the (working) Ubuntu build
<cjwatson> I wish I could remember my analysis of a similar problem before
<cjwatson> First failed build was 20130221; there was a grub2 upload that day but it was later
<cjwatson> So I think even circumstantial evidence rules out grub2 being the direct cause
<cjwatson> Matches linux 3.8.0-6.14 -> 3.8.0-7.13 but there's nothing that looks relevant in its changelog
<cjwatson> It might just be a configure ordering problem :-(
<cjwatson> In at least two successful cases, grub-pc is configured after linux-image-extra-blah; in at least two failing cases, vice versa
<cjwatson> And something caused the order to flip, but that could be practically anything and there's clearly an undefinedness problem anyway
<stgraber> hmm, so much for quickly reading through grub's postinst, that thing is massive!
<cjwatson> stgraber: I think perhaps http://paste.ubuntu.com/5606413/
<cjwatson> That matches the postinst
<cjwatson> And, although I haven't proven it directly, my argument is that matching the postinst should be good enough, because the postinst succeeded a bit earlier
<stgraber> yeah, I think that'd make sense. It's just really weird that we haven't seen that problem earlier, I guess we've been lucky with the resolver on all the other images ;)
<cjwatson> I'd be more comfortable with a better proof ...
<cjwatson> But I think this is correct on its own merits anyway; we shouldn't be calling update-grub if there isn't already a grub.cfg to update
<cjwatson> stgraber: OK, uploaded.  I decided to let it ride along with a merge I had queued up; the diff is fairly substantial but the actual effective change is pretty near minimal
<cjwatson> And our delta is almost approaching sane now
<cjwatson> (My goal is to eradicate it - I'm bored of merges)
<cjwatson> stgraber: So, assuming I didn't screw it up and fail to build, could you unblock it at some point and try another build?
<cjwatson> And with any luck we'll be back to all images building cleanly again
<stgraber> cjwatson: yep, I'll push an hint once it's done building
#ubuntu-release 2013-03-12
<phillw> It seems like a bug installed by others... every time I ask about beta it falls over. It's okay.. http://iso.qa.ubuntu.com/qatracker/milestones/261/builds is alive. Can you let me know the etherpad link for the respins, thanks
<phillw> stgraber: do you have the link to ether pad for while we are in beta 1, or is not being used?
<cjwatson> I hope we have thrown etherpad in the bin it deserves
<phillw> cjwatson: so, I guess we do not know what re-spins are planned :(
<cjwatson> stgraber may not share my dislike
<cjwatson> phillw: as if there are no other means of communication
<phillw> cjwatson: I'm all ears! how do the iso testers know about what re-spins are due during a 'alpha', 'beta', 'RC' are being scheduled?
<stgraber> no etherpad
<stgraber> when people want respins they ask for them and I mark them as such on the tracker
<cjwatson> personally I find chisel on stone more usable than etherpad.  (I like the idea but the implementation is awful.)
<phillw> cjwatson: stgraber which means also, that the other people actually testing the ISO's can have an ISO respun while they are testing. There is a lack of letting people know if ISO's are due to be re-spun?
<cjwatson> Of course they can have an ISO respun while they're testing; that's unavoidable
<cjwatson> And if they're due to be respun they can be marked as such on the tracker
<phillw> I liked the ether pad, as there was at least some discussions on what the causes would be. But, you're the boss'es here :)
<cjwatson> Editing the etherpad was unusably awful and confusing
 * stgraber is out for the next 30min
<phillw> cjwatson: could you throw me a threw crumbs, we ask people to test the ISO's, they start the sequence and part way through there is a re-spin arrives thus resetting all their tests. This is extremely frustrating for the testers.
<cjwatson> The pad doesn't help with that
<cjwatson> It's reload one page vs. reload a different page
<cjwatson> Reloading the tracker stands a better chance of being a page they're on anyway
<cjwatson> And for discussion we can/should use things better suited for discussion - IRC for transient things, maybe a wiki if we need something more persistent
<phillw> cjwatson: it would at least let them know what was planned? I know it was not perfect. Do we have a better system?
<cjwatson> Clinging to the pad isn't the answer
<cjwatson> Planning - we very often only decided to respin immediately before actually respinning anyway.  I don't think giving people a false sense of security is especially helpful
<phillw> cjwatson: indeed, but respinning immediately with no notification?
<cjwatson> And if we know we're going to respin for something but are batching up a few different problems, we can just do a better job of marking test cases disabled in the tracker in a timely fashion
<cjwatson> Which we didn't necessarily do before
<phillw> cjwatson: where are such announcments made?
<cjwatson> Here, and I'm sure stgraber would be happy to copy them to #ubuntu-testing too
<cjwatson> And on the tracker
<phillw> cjwatson: I'm only trying to update the sequence :)
<phillw> cjwatson: stgraber, so the only pre notification of a 'planned' respin is when the ISO tracker strikes them out for a re-spin?
<phillw> no prior notification for people part way through the tests?
<xnox> phillw: what we are trying to say is that we can push the prior notification directly to iso tracker, well in advance of the respin.
<cjwatson> Indeed
<xnox> phillw: as iso tracker is become more and more flexible than it was before.
<cjwatson> And there's no purpose in waiting further if we know we're going to respin anyway
<xnox> s/become/becomming/
<cjwatson> That would only waste *more* of testers' time
<cjwatson> The best things we can do are (a) notify as early as possible on the tracker, (b) respin as soon as we can while minimising the total number of respins
<phillw> xnox: in what way? Honest, guys, I'm not being awkward... I just do not want the ISO testers to test, and then find that their work was for naught.
<cjwatson> "prior notification" is not a useful goal
 * xnox lately is having hard time typing. I should measure the frequency i post a sed commands.
<cjwatson> Not in isolation
<cjwatson> Because if we have notified as early as possible on the tracker, then the only way that we can give more prior notification is to artificially push the respin later simply for the purpose of being able to say that testers had more notice, and that helps precisely nobody
<xnox> phillw: instead of "etherpad" -> "wait for uploads" -> "publish uploads" -> "rebuild images" -> "iso tracker wipes the results". We know have "Notice on iso tracker that respin will happen (warning dialogs on top that you may have seen in the past)" -> "wait for uploads" -> "publish uploads" -> "respin" -> "iso  tracker updates/wipes"
<cjwatson> The problem in the past is that we've been so busy messing about editing the etherpad that we've forgotten to update the tracker
<cjwatson> Partly because the etherpad was so bureaucratically complex to edit
<xnox> Note the timeline, it starts with a notice on the iso tracker, such that it will put off people starting tests, and maximise the warning period.
<cjwatson> (At least, that's been my experience)
<phillw> cjwatson: I agree, totally, but is http://iso.qa.ubuntu.com/qatracker/milestones/261/builds up to saying 're-spins' are arriving? (I know it can).
<cjwatson> I can't speak for any particular URL.  I know the iso.qa front page can and does
<cjwatson> Ah, yes, that's a milestone front page
<phillw> cjwatson: xnox I agree with both of you.
<cjwatson> Then yes, the products in question show as struck out
<xnox> phillw: at the moment. see "notice board" no message, all is good.
<cjwatson> And as xnox says we have a notice board for brief announcements
<xnox> stgraber: can you put a placeholder  (beermug?) message: "current images are being tested as potential candidates, no respins planned at the moment"
<phillw> xnox cjwatson stgraber are we okay to TELL people testing ISO's to go in that way so that they have the "latest news "?
<xnox> ? =)
<cjwatson> phillw: Yes
<cjwatson> I'm quite surprised that they aren't being told that already
<phillw> So, no short cuts... send them to http://iso.qa.ubuntu.com/qatracker/milestones/261/builds
<cjwatson> Since it's the one-stop-shop for recording test results
<xnox> phillw: we may have a quick chatter/consensus here first and then onces agreed update tracker straight away to push the message out to the testers. As our testers is always highest priority.
<phillw> cjwatson: a lot of the testers are using http://iso.qa.ubuntu.com/qatracker/milestones/243/builds
<cjwatson> phillw: That's fine for daily build testing, but it will be disregarded for beta prep
<cjwatson> phillw: I would actually suggest just telling them to go in through the iso.qa.ubuntu.com front page and select the proper milestone, but YMMV
<phillw> you should really have a think... maybe have http://iso.qa.ubuntu.com/qatracker/milestones/243/builds redirect to http://iso.qa.ubuntu.com/qatracker/milestones/261/builds during betas
<phillw> cjwatson: testers get used to the shortest link to zsync.
<cjwatson> They shouldn't have been told that that was the place to go for all time in the first place
<phillw> and the one that they use is the one that they use
<cjwatson> Tell them otherwise
<cjwatson> IME testers are not as inflexible as you suggest
<cjwatson> xnox: Not to disrespect testers, but testing is a means to an end; the highest-quality release is the highest priority :-)
<phillw> Hey, I can email the lubuntu team as to where everyone else goes for daily builds... pass.
<phillw> cjwatson: and asking them to change their links for zsycnking all the time does not endear the -release team to the testers :D
<cjwatson> phillw: The links on cdimage have been constant for ages.  I can't help it if people keep making trouble for themselves by using more complicated systems
<cjwatson> In other words it's not me who's asking them to change their links, dude
<phillw> cjwatson:  I suggest you and iso tracker make peace?
<cjwatson> I have no problem with the ISO tracker; but if people want constant links for downloads they should go straight to cdimage
<xnox> cjwatson: "we value the manual testing a lot and fast-track information to them as best as we can, since manual testing is a scarce resource" | gcc -O3
<xnox> we respect everyone =)
<cjwatson> xnox: Indeed
<phillw> I think this a good point for me to tip toe away from the discussion of 'dailies' becoming "RC's"
<cjwatson> And BTW, it's got very little to do with zsync URLs and much more to do with where to record results
<cjwatson> In any case, we can always just watch the "Raring Daily" milestone to see if there are lots of misrecorded results there, and worry about it then
<phillw> cjwatson: I know, but some people only come 'on board' for testing when they think we have ironed out most of the bugs..... I know this is wrong in theory, but we can get extra testers on board when it hits Beta.
<cjwatson> Sorry, you say that as if it contradicts something I said but I don't see what?
<phillw> I've not had a fail of able to boot on 13.04
<cjwatson> (And it seems perfectly reasonable to me)
<phillw> cjwatson: as to reporting from iso-tracker, it is dismal and in effectual. There is a bug raised against it.
<cjwatson> You mean reporting Launchpad bugs starting from iso.qa?  That wasn't what I was talking about.
<phillw> cjwatson: nah, it was about the ability for a person to actually search for results.
<cjwatson> Sure, I'm aware that that is poor, but it doesn't seem to have anything to do with the above
<phillw> cjwatson: it is actually a lot to do with it.  https://bugs.launchpad.net/ubuntu-qa-website/+bug/1126449
<ubot2> Launchpad bug 1126449 in ubuntu-qa-website "Getting a historical results report for a product is difficult" [Undecided,New]
<cjwatson> It's *possible*, it's just not pleasant
<cjwatson> But for this purpose it doesn't have to be pleasant
<cjwatson> (Existence proof: stgraber can do SQL queries on the database ...)
<phillw> You see, they have, a feeling of reporting stuff is just not carried over.
<cjwatson> Well, on the daily builds it's not really
<phillw> cjwatson: ut, heck, we were going to chat about this in UDS-S, and then look what happened :D
<cjwatson> Realistically, I don't think iso.qa is a particularly effective way to report daily build problems right now
<xnox> phillw: daily milestone is active for products that are not doing beta1, that's why at the moment both milestones are active.
<phillw> cjwatson: well, it is frozen for beta. but I'm always open to ideas from
<cjwatson> Which is one reason I think it's a little ... ambitious to have directed testers at the daily milestone in the first place
<xnox> when everything is doing a milestone it will be easier.
<phillw> xnox: as in rolling release?
<xnox> phillw: no, as in beta2 where ubuntu when all images will be doing milestone release.
<cjwatson> I mean, I would like it to be usable for daily build reporting, but we're not really there
 * phillw please drop future and get 13.04 out
<phillw> xnox: 13.04 will happen
<cjwatson> phillw: I mean specifically the "Raring Daily" milestone, in case that wasn't clear
<cjwatson> Obviously it's the way to go for the beta
<xnox> phillw: i'm not sure you understood me right. We currently have two active milestones: (a) beta1 for all products that are participating in beta1 (b) daily milestone for the rest. And we need both active right now, for everyone to be able to report results against all images.
<xnox> Just because lubuntu is doing beta1, it shouldn't stop testers from reporting bugs against daily ubuntu server images =)
<phillw> cjwatson: I may have lost something, but as we used to hit alpha's we did a freeze, then relax it when the alphas were released. As it got to Beta 1, most stuff was frozen... then we got Beta 2... at which pint even the brass monkey's balss were frozen without special permission?
<xnox> once beta1 is out - we will only have raring daily active, then at beta2 time - only beta2 milestone will be active as I believe at the moment everyone will be participating.
<phillw> xnox: I recall kubuntu closing down the general releases for an alpha release?
<xnox> phillw: we no longer do "full freeze", we only freeze participating products. E.g. stuff that is on ubuntu server images only is not frozen.
<stgraber> xnox: nope, it's not done that way anymore ;)
<stgraber> xnox: even for beta-2 and final we'll keep the daily milestone active
<cjwatson> Well.  We no longer do full-freeze for milestones; we will still do it leading up to the full release
<xnox> stgraber: is that an implementation detail, or we have two sets of images?
<phillw> stgraber: cjwatson thanks for the update :)
<xnox> (daily and candidates) ?!
<cjwatson> The daily milestone thing was a change from https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-prior-release-feedback
<stgraber> xnox: implementation detail. It's just that in the past we couldn't share builds between milestones on the tracker. Since early this cycle we can, so there's no reason to disable the daily milestone.
<stgraber> xnox: results reported against the daily milestone for products part of a milestone will show up in the milestone view automatically
<phillw> So, as lubuntu has chosen beta, you are still going to build dailies?
<cjwatson> stgraber: Ah, so there we go, phillw's concern is moot then
<cjwatson> phillw: Every single image we ever release is a "daily" in some sense
<phillw> OMFG
<cjwatson> phillw: The "Raring Daily" vs. "Raring Beta 1" thing on the tracker - think of that just as a tag
<cjwatson> They're the same underlying image
<stgraber> though we don't necessarily build "daily" images, well, "daily" :) which may be slightly confusing :)
<xnox> phillw: doesn't matter where the bug is reproted (daily or beta1) on the iso tracker, as long as the buildstamp matches it's a bug affecting that image and hence affecting all milestones it's part of.
<phillw> cjwatson: is daily === beta 1
<cjwatson> stgraber: Well, sure, same mechanism though
<phillw> and I mean ===
<cjwatson> phillw: The beta will be *a* daily
<cjwatson> It would be extremely foolish of us to have a separate mechanism for building release builds
<phillw> cjwatson: the beta is already there
<cjwatson> phillw: No, candidates for the beta are there
<xnox> phillw: ~= there are less images on the beta 1 vs daily, but for those that are in both they are the same.
<cjwatson> Those candidates are identical to the current daily build
<phillw> continuing to build dailies would cause confusion?
<stgraber> milestone testing is just a matter of building a bunch of "daily" images (but not necessarily at a 24h interval), until one is considered good enough, which becomes the milestone image (by the simple fact of being copied to another directory basically)
<cjwatson> The products that are participating in the beta are on manual-build-only
<cjwatson> Any build == a respin
<xnox> phillw: we rename daily build to be lubuntu--raring-beta1-amd64.iso once we are happy with that daily build. hence zsync urls, download locations, etc are all the same. it's only the iso tracker that is in "special" mode.
<cjwatson> We have only one mechanism for builds, i.e. "trigger a 'daily' build", so it wouldn't be a good idea to keep on doing cronned builds that aren't necessarily going to be beta
 * xnox feels like i'm not helping, but just adding to the confusions and missunderstandings.
 * xnox shuts up now.
<cjwatson> I don't think it would be helpful for /daily-live/current/ not to point to the images currently being tested
<phillw> I'm now really confused.... when the daily was plucked to be the mile-stone RC, the daily build (cron job) was turned off. Only a respin would occur manually? I seem to have missed out on what has changed :(
<cjwatson> This is how it's always been
<phillw> brb
<cjwatson> We disable cron jobs leading up to milestones
<stgraber> phillw: nothing has really changed. At the moment there are no automated builds for the products participating in beta-1. The only small difference is that if someone asks for a respin, it'll show up under both beta-1 and daily on the ISO tracker (where in the past it'd only show up under beta-1).
<cjwatson> The most important changes this cycle in this general area are essentially (a) the presentation in the ISO tracker (b) most Canonical products not taking part in milestones (c) freezes being a bit more fine-grained
<cjwatson> But the way in which we execute and organise the actual image builds hasn't changed materially
<stgraber> oh wow, I didn't realise grub was taking so long to build on x86!
<stgraber> I was expecting it to be done building by the time I got back home
<cjwatson> common, emu, pc, coreboot, efi-ia32, efi-amd64, ieee1275, firmware-qemu
<cjwatson> takes a while
<cjwatson> hmm
<ScottK> cjwatson: Also I think that being able to block transitions vice prevent uploads during freeze periods is a significant change.
<cjwatson> no, I think it's stuck in the test suite :-(
<cjwatson> ScottK: that was (c), I think
<cjwatson> I was abbreviating :)
<ScottK> Ah.
<ScottK> OK.
<phillw> stgraber: thanks for the information.
<cjwatson> stgraber: I'll run a test build here - in the meantime I doubt I will be able to fix this before (my) tomorrow as I really need to sleep soon
<phillw> So, guys, can i announce that the beta 1 is out and about?
<stgraber> cjwatson: ok, no worries. Edubuntu 64bit is pretty quick to test and we're pretty used to only getting to testing it late on Wednesday :)
<ScottK> phillw: Candidate.  Not Beta 1.  It's Beta 1 once it's released.
<phillw> ScottK: sorry, when on this channel, I tend to ignore the RC bit :) I'm asking for the testers to test it :D
<ScottK> OK.  Just trying to make sure we're clear.
<phillw> ScottK: amongst my many sins, I am the TL for lubuntu-qa and one of the the lubuntu-release-managers ;)
<xnox> infinity: hppa build queue is out of control =) 3 jobs in the queue and the builder is off /o\
<phillw> stgraber: it has taken this long to ask about the difference between the 'Beta 1' and daily builds. Sorry to be a pain, but I still do not get this new system. :'(
<xnox> phillw: look at cdimage.ubuntu.com/ notices a few builds of isos. notice that current is a symlink simply pointing to a latest build. check iso tracker - notice how there are two milestones, check the build numbers of the same image in both milestones, notice that they are the same.
<xnox> conclude - all roads lead to rome. the last build daily is the current candidate for beta1 milestone and at the same time the last/current built daily.
<xnox> thus reporting results against either of the milestones will rightfully affect both of them, as there is only one image.
<xnox> phillw: all of the above has always been the case. no change to the system.
<xnox> one can figure out that current/ is just a symlink to the last built, by comparing the checksums, they are the same.
<phillw> xnox: sorry, as we adjoin beta's and I wish to get Iso's installed as secondarily mirror.
<phillw> xnox: I have them installed as zsync, I then keep them updated.
<ScottK> phillw: You can just zync current and you'll always have the right one.
<infinity> xnox: Yeah, we're either going to recover a parisc machine, or just delcare it EOL a tad early, depending on effort required.
<infinity> xnox: It's technically EOL anyway, since it wasn't a supported arch, so no one's terribly fussed.
<micahg> I still deny that archs are EOL early due to being unsupported at all, support can be EOL early (armel on lucid), but something like powerpc on lucid was never supported, so to say that it's EOL due to being unsupported seems imprecise
<antarus> have you tried simply asking debian?
<antarus> I think they have a bunch of parisc stuff
<phillw> ScottK: with the greatest respect, when testing dailies.. they can be a case of you are 3 /4 tests into the spin and then it gets re-spun (https://wiki.ubuntu.com/Lubuntu/Testing#When_do_they_build.3F )
<micahg> I would agree that it might not be worth resurrecting the hardware, especially if there aren't any users
<phillw> xnox: https://wiki.ubuntu.com/Lubuntu/Testing#QA_testing_of_Milestone_releases
<phillw> now, do tell me where the link 'magically' changes?
<infinity> antarus: Not worth sourcing hardware for the last 1.5 months, but I'm working on a duct tape solution right now.
<infinity> micahg: No, in general, I'm with you on the "don't count arches out early" thing, but this late in hardy's support cycle, it's not worth resurrecting hppa for its 0.3 users unless it's low-effort.
<antarus> the best i got for parisc is a 552mhz PA 8600
<antarus> but I'd probably have to bribe vapier with free gropes to get you access
<infinity> antarus: Access to hardware isn't a huge issue, I have a machine in my garage identical to our buildds.
 * antarus nods
<antarus> ok then ;)
<micahg> infinity: I would tend to agree FSVO low effort
<antarus> props for having weird kit then
 * antarus got rid of all his ;p
<infinity> micahg: Yeah, we're putting a tiny bit of effort into it as we speak.  Literally as we speak.
<infinity> micahg: Trying to wrap some duct tape around kohnen to get it to survive a month or two, since primero's well and truly dead.
<micahg> infinity: I'm sure you're doing what you can to revive it
<infinity> micahg: I have no hard data to support this, but I suspect that the only users of Ubuntu/hppa were lamont and I, which sort of explains why literally no one cared about it when we stopped caring. :P
<phillw> xnox: have you managed to get a 10.04 server updated yet?
<infinity> (There may have been a few other experimenters, but not "users", per se... Like, Carlos had Ubuntu chroots, but runs Debian, etc)
<micahg> infinity: makes sense, I suppose you could count how many time the hppa Packages file is read on the ports server
<antarus> yeah Gentoo has the same sort of deal with the weird arches
<antarus> 1 guy maintains them, about 3 people care
<antarus> they are always behind at building / stablizing stuff
<infinity> antarus: Well, given how relatively easy it is to pass the Debian release arch criteria, I think it's pretty telling when a Debian arch flips from official to ports, which parisc did a long while back.
<phillw> hay, look on the bright side of things, my / partition went 100% when CentOS 6.3 went to CentOS 6.4... I'm sure ubuntu would 'never' fill a 10 GB / area .....
<antarus> haha hahaha they have 'criteria'
<infinity> antarus: They do.  It was originally designed (he says bitterly, in an unfair accusaion of conspiracy against his work) as a way to drop m68k, but seems to have become a decent set of guidelines for supportability of an arch.
<infinity> antarus: http://release.debian.org/wheezy/arch_policy.html
<slangasek> infinity: naw, it was designed as a way to drop m68k /and arm/ ;)
<infinity> slangasek: And then ARM went and became relevant.  Jerks.
<slangasek> so see, you have the Debian cabal to thank for ARM getting their act together
<infinity> slangasek: In fact, I suspect that the "only 2 buildds" thing is still not true for ARM.
<slangasek> if we hadn't demanded faster buildds, nothing would have happened!
<ScottK> And, IIRC, when Debian dropped hppa, it was the last major distro to support it.
<infinity> slangasek: Though it may be some day.
<slangasek> infinity: hmm, I think Debian relaxed the "only 2 buildds" requirement though?
<ScottK> phillw: I don't see your point.  /current is still always what you want.  If /current gets updated, then test that.
<infinity> slangasek: It's still in the wheezy list.
<slangasek> hmm
<slangasek> well, ok
<antarus> ScottK: hey hey hey, Gentoo still supports hppa ;)
<ScottK> antarus: I stand by my statement.
<infinity> slangasek: I'm guessing it's just ignored if the rest of the bullet points get hit.
<ScottK> ;-)
<slangasek> infinity: I think generally, it's ignored if DSA don't have to spend large amounts of Quality Time babysitting a dogsled team of buildds
<infinity> slangasek: Well, back when the proposal was first written, DSA didn't manage many buildds at all.
<slangasek> infinity: wasn't it required that the security buildds be DSA-managed?
<infinity> slangasek: AFAIK, they're all ldaped now, though day-to-day is still handled by porters.
<slangasek> dunno, my memory is fuzzy
<infinity> slangasek: Oh, yeah, kullervo was ldapped (though still managed by me, just had DSA access)
 * antarus cringes at ldap
<infinity> antarus: ud-ldap is only ldap in name, really.
<infinity> antarus: More appropriate to call it libnss-db at the host level.
<infinity> (Cause it is)
<slangasek> infinity: as for hppa moving to ports, ISTR there were some big pthreads problems that may have prompted this
<antarus> infinity: thank god
<antarus> nss_ldap is a sin
<antarus> and should be burned
<infinity> slangasek: Yeah, upstream parisc support in glibc was awful for a while.
<infinity> slangasek: Carlos fixed most of the glaring issues, but I doubt anyone cared/cares enough to re-propose it as an official arch.  I know I don't anymore.
<infinity> antarus: I tend to think (especially in a distributed network like Debian's) that any auth system that relies on remote machines is a sin.
 * antarus was surprised by how many dev machines debian had
<antarus> gentoo has so few :/
<infinity> antarus: The ud-ldap setup has a central ldap DB and pushes updates to machines via SSH triggers, which they then build into Db files for libnss-db, so the machines don't neet to rely on a remote network to work.
<antarus> infinity: there are always trade-offs ;)
<antarus> yeah I know how libnss-db works
<antarus> we wrote our own thing of course
<antarus> because thats what we do
<infinity> I think everyone has.
<infinity> Well, ud-ldap actually got some traction in other places, but every one of those places was because Debian developers had influence (freedesktop.org was my fault, canonical/ubuntu was elmo's fault, etc)
<antarus> yeah
<antarus> we built nsscache
<antarus> and then I gave it to Gentoo
<antarus> so gentoo uses it
<antarus> unsure if anyone else did
<antarus> just like everyone manages their own bind zonefile mess
 * antarus cringes
<infinity> I admit that I write bind zonefiles by hand, but I also understand why that's entirely untenable for people with millions of zones in constant flux.
<infinity> Not that the format is hard to write a quick read/write parser for, if you introduce artificial constraints.
<antarus> The Gentoo zones are maintained in git, and there is magic to build them and DNSSEC sign them
<antarus> magic perl that I do not understand
<antarus> if the author gets hit by a truck; I will have a bad time :/
<infinity> Heh.
<infinity> Turns out that there are a lot fewer programmer-seeking trucks out there than we generally fear.
<ScottK> fear/hope in some cases.
<infinity> *cough*
<antarus> hey now
<micahg> infinity: fortunately, there aren't a lot of Agent Smiths' driving around :)
 * infinity takes micahg's apostrophe and crushes it under his heel.
<tkamppeter> infinity, have you seen my messages about GS 9.07?
<infinity> tkamppeter: If it's AGPLv3 (or if the license reads "vN or later"), then it should be fine.
<infinity> tkamppeter: If it's AGPLv1, we have a small problem in that we can't link pure GPL code with it and distribute the result.
<infinity> tkamppeter: Which would make it a bit difficult to, say, distribute gimp.
<tkamppeter> infinity, this is OK, GS is AGPL v3+
<infinity> tkamppeter: Kay, then just make sure debian/copyright gets a treatment to still be correct, and it should be fine.
<tkamppeter> infinity, OK, thanks, waiting for RAOF to fix the bug ...
<tkamppeter> infinity, another question, foomatic-db and foomatic-db-engine are still in raring-proposed, what moves them into raring?
<infinity> tkamppeter: They're in the frozen list for beta-1, they'll migrate after Thursday.
<infinity> tkamppeter: See http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<didrocks> cjwatson: hey, do you know if the LP API enable us to retrieve a source package from a ppa (like downloading it)?
<didrocks> sourceFileUrls maybeâ¦
<Daviey> didrocks: Yes, we do something for mythbuntu https://github.com/MythTV/packaging/blob/master/deb/debian/LP-get-orig-source.py
<didrocks> Daviey: oh excellent, thanks for the link!
<didrocks> yeah, so once I get my getPublishedSources(), just calling sourceFilesUrls and urlretrive it
<didrocks> urlretreive*
<Daviey> didrocks: people seem to be moving away from urllib in favour of python-requets
<didrocks> Daviey: interestingâ¦ never looked at that one. Will definitively give it a look, thanks!
<Daviey> As you can't do *.changes signature validation, you probably should do https validation
<Daviey> (which requests does better than urllib)
<tumbleweed> by doing it at all...
<xnox> tumbleweed: can we have pull-ppa-source please?
<xnox> =)
 * Laney hands emacs ubuntu-dev-tools/pull-ppa-source to xnox
<xnox> phillw: i don't understand your argument about "3/4 of tests in and 'daily' arrives". During milestone, images are not triggered/build daily, instead they are build on manual, only when we decide to respin and push the notice to the iso tracker, etc. And yes it will be the same location as usual /current.
<cjwatson> He's offline
 * xnox needs to brew coffee.
<cjwatson> stgraber: I've screwed up cdimage fairly massively, apparently - bug 1153992, currently trying to figure out full impact
<ubot2> Launchpad bug 1153992 in debian-installer (Ubuntu) "Raring server and precise d-i installations fail at the clock configuring step" [Undecided,New] https://launchpad.net/bugs/1153992
<Riddell> anyone know why kubuntu-settings isn't getting into -released ?  I can't work out what update_output.txt is saying about it
<cjwatson> update_excuses.html says "kubuntu-settings-desktop/i386 unsatisfiable Depends: kubuntu-qtquick1-components" which is probably a more immediately useful hinit
<cjwatson> No such package AFAICS
<xnox> please wait for matching tcltk-defaults.
<phillw> Hi folks, has AMD64+Mac been dropped from the ISO's?
<cjwatson> phillw: No change there
 * cjwatson fixes bug 1153992 and tries to work out what to respin
<ubot2> Launchpad bug 1153992 in Ubuntu CD Images "Raring server and precise d-i installations fail at the clock configuring step" [Critical,In progress] https://launchpad.net/bugs/1153992
 * cjwatson sticks a notice on the iso.qa board
<cjwatson> Raring respins as follows: Lubuntu Alternate *, Ubuntu Server * (I think the latter isn't taking part in the beta though)
<cjwatson> Precise respins as follows: Kubuntu Alternate *, Ubuntu Alternate amd64+mac amd64 i386, Ubuntu Server *, Xubuntu Alternate *
<cjwatson> All marked on the tracker.
<cjwatson> JackYu: Not quite sure whom to tell about this, but the bugs quoted for UbuntuKylin Desktop i386 on http://iso.qa.ubuntu.com/qatracker/milestones/261/builds are mostly quite broken.  Just hover over them and you'll see what I mean.
<phillw> cjwatson: I know you're busy, but is https://wiki.ubuntu.com/Lubuntu/Testing#Rebuilding_a_Release_Candidate now correct (I've removed reference to the Ether Pad).
<cjwatson> Aside from grammar, yes :)
<cjwatson> (Though I've only checked that entry, not the rest of the page)
<phillw> cjwatson: thank you grammar nazi :P It now is structured correctly
<cjwatson> Hey, you asked
<phillw> no worries, I usually have a guy in Brazil do my grammar checking ;)
<lamont> infinity: the buildds also use the hppa bits.  and they get mirrored by a few people (who mirror ports) and yeah, at its high point, I think we may have had 5-endusers (developers/experimenters all) that actually used machines for other than supporting the effort of building the bits in any way
<infinity> lamont: *nod*
<infinity> lamont: Anyhow, I just followed up to that ticket (59816) saying that kohnen seems to be chugging/hobbling along reasonably well enough to get us to hardy EOL, so feel free to close it off.
<stgraber> cjwatson: good thing we don't have that many non-live products then.
<cjwatson> Indeed
<JackYu> cjwatson: thanks, we are dong it:)
<xnox> please denew tcl8.5 together with tcltk-defaults, and if autohinter fails -> hint them together. This is a package split for multiarchification
<xnox> infinity: ^
 * xnox hopes i got all the symlinks rights
<infinity> xnox: If the autohinter fails, it's almost certainly because the packages are broken.
 * infinity notes that 99% of the time people ask for a hint, they're really asking me to debug their packaging.
<xnox> infinity: well this is all -> any transition with a split. Last time around, that failed autohinting. Although I may be missing replaces & conflicts on the -lib package, not sure.
<infinity> xnox: If you're missing replaces, please fix.  britney doesn't look at package *contents*, it won't catch that.
<xnox> infinity: yeah, will test once above is published =) easier that way ;-)
<infinity> xnox: If the lib package only contains things in a multi-arch path where they never existed previously, you're fine.
<xnox> true.
<xnox> i like that =)
<infinity> Yeah, that looks fine to me.
<infinity> (Just downloaded the deb to look)
<xnox> infinity: note that tk was not multiarched yet, so at some point in the future there will be tk & tcltk-defaults combo ;-)
<infinity> xnox: Plus, you get to do this in 8.6 as well (and push to Debian).
<jokerdino> hi guys. what's the procedure for reviewing new packages in the archive? :)
<xnox> phhhh enough of tikle for me for the day.
<infinity> Heh.
<jokerdino> one of our package is in the new queue for a week now. it kinda feels bothersome.
<infinity> jokerdino: Which one?
<xnox> jokerdino: what's the package name?
<xnox> snap
<jokerdino> unity-tweak-tool
<jokerdino> ^^
<xnox> jokerdino: i'd rather see it in myapps to be honest, as unity <=> treak-tool can rapidly break comparability. How do you handle if unity moved on and is not what unity-tweak-tool is expecting? e.g. settings names moved & renamed?
<xnox> e.g. last time around a tweak-tool was removed because unity changed and the tweak-tool ended up (a) crashing new unity (b) crashing itself as well and thus ended up at the top of the errors.ubuntu.com
<jokerdino> xnox: uhm, myunity was in universe though no?
<xnox> keyword "was"
<jokerdino> well, we have done better work than that.
<xnox> it kind of also implies that we potentially don't want it in the archive.
<tumbleweed> xnox: IIRC that was actually removed because it wasn't ported to a newer gambas
<xnox> jokerdino: so why not go the myapps route and publish for stable series only, where you know that unity is stable and will not rapidly change?!
<tumbleweed> but yes, we want packages in the archive to be actively maintained. and packages like this seem to need more maintainance than most
<infinity> xnox: Given that it's been getting reviewed by the desktop team, I'm not going to pass "don't want it in the archive" judgement.
<jokerdino> we can maintain. i promise.
<xnox> jokerdino: also note that I'm nobody, just a bystandard =)))) (I'm not an ArchiveAdmin and really don't have any say as to what gets accepted into archive)
<jokerdino> infinity: it's been passed onto the desktop team?
<xnox> s/bystandard/bystander/
<infinity> jokerdino: I was referring to mterry's reviews in the bug.
<jokerdino> oh, that.
<infinity> I'm curious about the native packaging without a strong version->commit mapping, but whatever.  Not my package.
<infinity> And, hypocritically, I maintain a similar package with random upstream commits pulled into it.
<jokerdino> infinity: heh, we are using git tags for version -> commit mapping.
<infinity> jokerdino: Oh, are you?  That didn't seem to be implied from the bug log, where previous reviews were of 0.0.3, and that's the version of the current upload.
<jokerdino> infinity: hm, the one uploaded is 0.0.3 with all the fixes incorporated.
<infinity> jokerdino: Right, but the earlier ones were also 0.0.3
<infinity> jokerdino: Which seems to contradict the claim that tags match versions. :)
<jokerdino> yeah, we were a bit too flexible.
<infinity> jokerdino: Unless you deleted the tag.
<smartboyhw> Uh oh
<infinity> jokerdino: (Which is generally a Bad Idea in git)
<jokerdino> no, the tag was only added after it was uploaded ;_)
<cjwatson> All the respins seem to be done now.  I only hand-checked Lubuntu.
<infinity> jokerdino: Ahh.  Kay.  That's fair.
<cjwatson> Though server amd64 looks fine too.
<jokerdino> infinity: yeah, we are stingy about tags though.
<infinity> jokerdino: I'll give it a proper review in a bit.  Do keep in mind that if it does end up being problematic and breaking the world, the knee-jerk reaction if it's not fixed fairly promptly will be to tear it out of the distro again.  We've had some pretty bad experience with such things in the past. :/
<jokerdino> i can fix it on a daily basis as long as i get sponsors :)
<jokerdino> and thanks for reviewing!
<infinity> jokerdino: Sure, "fixed" doesn't mean "uploaded".  Filing a bug with "oh god, it broke, can someone please sponsor 0.0.5 from git://foo" would be fine.
<jokerdino> hm, so we are talking about fixing in a developer sense?
<jokerdino> that wont be an issue. we got a small team of devs across the time zone :)
<infinity> jokerdino: Good to know.  If there's a reasonable commitment to keep it not broken, then I'll just review it for general packaging sanity and ignore my fears about tweak tools being evil.
<infinity> ogra_: Aww, you dropped a pointless character from your nick.
<infinity> ogra_: Does this mean that in another six months, you might actually be "ogra" again?
<ogra_> yeah, no idea how that got there
<jokerdino> infinity: heh, it's not as evil as you think. it passed at least three MOTU reviews for good.
<ogra_> i'm to lazy to convince nickserv to play with bip, else i would already
<infinity> ogra_: Ditch bip and use irssi as a proxy.
<infinity> ogra_: Then you have all of irssi's script-fu at your fingertips.
<ogra_> well, i'm happy with bip ...
<jokerdino> and do drop by ask ubuntu as and when you have time. :)
<ogra_> its just the reconnects that make me grow a tail ...
<ogra_> i doubt irssi would cope much better with that
<tumbleweed> you can script it to cope with it
<ogra_> if the former ogra is still registered nickserv simply refuses to let me have that nick
<jokerdino> ghost the ogra out?
<ogra_> yeah, i know with ghosting etc
<jokerdino> ghosting makes me feel geek-y. impresses the new folks :P
<jokerdino> you can probably script the ghosting too.
 * xnox uses znc, haven't tried any other proxies.
<dobey> what are the exact dates for EOL for Lucid Desktop and Oneiric?
<tumbleweed> dobey: wiki.ubuntu.com/Releases
<dobey> tumbleweed: i was just there. it only says "April, 2013" no exact dates
<xnox> dobey: https://wiki.ubuntu.com/#Releases
<tumbleweed> dobey: ah, the same day of the month taht it released on
<tumbleweed> (usually)
<xnox> dobey: usually towards the end of the month, when it's quiet, not during freeze week for devel release, and when IS is free to like move the archive & cdimages around to old-releases and things like that.
<xnox> dobey: usually we try to EOL, before releasing next-devel, so i'd expect those to be EOL before april 22nd.
<cjwatson> IS moves the archive, but we (well, usually I) move cdimage
<xnox> interesting.
<xnox> also hardy server is going EOL.
<infinity> xnox: We try to EOL before releasing next-devel?  Really?  I tend to err in the other direction.
<infinity> Overlaps are better than gaps and all.
<tumbleweed> I don't think this is going to be a useful overlap for lucid. but possibly for oneiric
<xnox> i distincly remember karmic to go a little ahead of it's time.
<xnox> disk space issue maybe at the time?
<xnox> (not sure if it was archive or cdimages or both though)
<infinity> There could have been a cdimage space panic.  We've had a few.
<cjwatson> I don't think it really matters - there aren't usually updates happening anyway
<infinity> Shouldn't be an issue currently.
<infinity> But yeah, it largely doesn't matter when the EOL announce or the various moves happen, as long as it's about the right time, ish. :P
<ogra_> rsalveti, well, the phablet sync script would run every hour at :35 *if* not someone had removed it from crontab for whatever reason
 * ogra_ knew he should have kept it in his personal crontab instead, i dont even remember the line i used 
<cjwatson> I was very careful not to.  I suspect somebody blatted it using the one in bzr
<cjwatson> EVERYONE: DO NOT DO THAT
<cjwatson> # Ubuntu Phablet sync from jenkins (interim solution)
<cjwatson> 35 * * * *      /home/ogra/sync-phablet-images
<cjwatson> ogra_: ^- I happened to have that in scrollback
<ogra_> ah, thanks :)
<rsalveti> :-)
<ogra_> it didnt feel right to put it into bzr since its a hack
<cjwatson> Agreed
<cjwatson> Also since the code it's calling isn't in bzr
<ogra_> yeah
 * ogra_ put it in a README.crontab in his home 
<infinity> Maybe stgraber blatted it when he disabled things for Beta.
<ogra_> restored ...
<infinity> stgraber: If it was you, please don't install crontab from bzr without diffing against production.
<cjwatson> I tweaked the comment a bit since I preferred the old one :-), and added a line break to try to make it clearer
<ogra_> heh
<stgraber> infinity: yeah, must have been me. I wrongly assumed that etc/crontab on nusakan would have contained the changes too (as uncommited changes) but I guess that's just how I do things and not how the rest of us do
<xnox> infinity: well I'm getting c-m for tcl-lib, can that be put in main please? =)
<xnox> at least something broke, lol =)
<cjwatson> Eh, that's a c-m saying "move to universe"
<cjwatson> If you want it in main, needs seeding somewhere
<cjwatson> *if you want it to stay in main
<infinity> cjwatson / xnox: Err, does nothing depend on it?
 * infinity is failing to see how this multiarching can possibly work if tcl doesn't depend on tcl-lib.
<xnox> infinity: correct.
 * xnox goes to fix it.
<xnox> i feel more confident, now that there is finally a bug found in my upload.
<infinity> xnox: Why is there a tcl-lib at all, actually?
<infinity> xnox: I can't fathom why someone would want to install that on their own to have "the default tcl-lib".
<infinity> xnox: It would be like gcc-defaults producing an unversioned "libgcc" just in case someone wants the "default" one.
<infinity> xnox: As long as tcl depends on tcl8.5 and tcl8.5 depends on tcl8.5-lib, that all seems sane.
<xnox> infinity: version-less .so file somebody can depend on? (e.g. tcl.so vs tcl8.5.so)
<xnox> so tcl-lib ships that symlink.
<infinity> xnox: Oh, that used to exist in the pre-MA packages?  Icky.
 * infinity wonders why that was considered a good idea, but lets it drop.
<xnox> which seems wrong, as moving the default breaks the world. I'm not sure why pre-MA tcl-dev did that as well. I wonder if the tcl world is broken and did not expect to support multiple co-installable tcl releases.
<infinity> The unversioned .so seems like a strange thing, for sure.
<xnox> infinity: I'm no tcl expert by any extend, but i'd consider dropping it in 8.6 transition and will poke debian people about it.
<infinity> I suppose for people who like to dlopen with reckless abandon.
<infinity> Maybe there are some weird upstream projects that do such things.
<infinity> Or, or more likely, upstream build systems that don't expect the versioned .so when searching/linking.
<infinity> So, there might be a slightly valid reason for it.
<infinity> Ish.
 * xnox totally broke that -defaults upload *sigh*
<stgraber> cjwatson: had any luck with grub2 so far?
<cjwatson> stgraber: I've yak-shaved my way through that problem to the point where I'm reading the ACPI spec
<cjwatson> (Don't ask, you really don't want to know)
<cjwatson> Whatever it is is triggered by raring's seabios
<stgraber> hmm, ok. "ACPI spec" is usually enough of an indication that I don't want to know ;)
<cjwatson> It's my first direct exposure
<stgraber> I've heard mjg59 complain enough about it that I never had any kind of willingness to read it ;)
<xnox> cjwatson: pitti: the email is wrong though, it's titled "universe -> main" yet it's actually reverse.
<xnox> hence my confusion.
<cjwatson> Ah, could be.  Patch to lp:ubuntu-archive-tools welcome
<xnox> cjwatson: hm... i see the report generator (and the report is correct), what does "diff" & email notification?
<cjwatson> Oh, sorry, that's apparently only in lillypilly:~ubuntu-archive/bin/
<phillw> a quick question.. why is a beta 1 iso pulling in lots of files when it is at the 'configuring apt' stage? (lubuntu alternate AMD64)
<cjwatson> It typically updates from the network archive at that point if it can
<cjwatson> In order that, for example, it can install localisation packages that aren't on the image if it needs to
<phillw> okies, thanks :)
<blitzkrieg3> would it be possible for someone to sponsor bug 1025508
<ubot2> Launchpad bug 1025508 in OEM Priority Project precise "Some keys in keyboard layout show duplicate character labels" [Medium,In progress] https://launchpad.net/bugs/1025508
<Riddell> new ubiquity uploaded
<infinity> blitzkrieg3: You want #ubuntu-devel, and the patch pilot listed in /topic
<blitzkrieg3> infinity: thank you
<xnox> release team, FFe for bug 1148014 pretty please =)
<ubot2> Launchpad bug 1148014 in mksh (Ubuntu) "FFe: Please merge mksh 44-1 (main) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/1148014
<infinity> xnox: changelogs look reasonable to me.
<xnox> infinity: thanks.
<zequence> I marked the ubuntustudio isos for beta1 to be rebuilt, but wondering how that works. It says rebuilding, but when is the build done?
<infinity> zequence: Marking them doesn't actually respin them, it's just a UI thing that means "don't test these ones, we're respinning".
<infinity> stgraber: zequence needs a studio respin.  I'm off to nap, so can't babysit.
<stgraber> zequence: did you confirm the packages you need are all built and ready in the archive?
<zequence> stgraber: Yep
<stgraber> zequence: ok, building now then
<zequence> stgraber: Thank you
#ubuntu-release 2013-03-13
<Riddell> cjwatson: any idea what went wrong with my ubiquity upload?
<Riddell> http://starsky.19inch.net/~jr/tmp/ubiquity_2.13.14.dsc
<Riddell> "Rejected:
<Riddell> ubiquity 2.13.14 in raring (source has no binaries to be copied)"
<xnox> Riddell: those ubiquity files need chmod +r  =) Forbidden at the moment.
<xnox> Riddell: do you want me to try an upload?
<Riddell> xnox: permissions changed
<Riddell> xnox: yes that would be good
<cjwatson> xnox: Eh, hang on
<cjwatson> Let me investigate Riddell's failure first
<cjwatson> That is a truly strange error
<xnox> ok.
<cjwatson> The question is why proposed-migration thought it was suitable to copy
<cjwatson> Because it wasn't built yet
<Riddell> I had a force on it
<Riddell> could that have caused it to go early?
<cjwatson> Yes, you broke it, please don't do that
<cjwatson> Please in general don't force things unless there is no alternative
<cjwatson> "I'm in a hurry" isn't a good enough reason
 * cjwatson tries to work out if it is possible to clean up this mess
<Riddell> how about "I want it in the beta"?
<cjwatson> Not good enough
<cjwatson> The only excuse for a force is that proposed-migration won't accept it due to some problem you've checked with other members of the release team first
<cjwatson> They really need peer review
<cjwatson> As it is, you *delayed* having this in the beta
<xnox> Riddell: well "i want it in the beta" sure, but you didn't get it in beta, and instead powerpc & armhf have not build.
<cjwatson> If you want to bypass the general freeze migration, use "unblock", never "force"
<cjwatson> xnox: the latter *may* be fixable
<xnox> interesting =) how?
<cjwatson> I'll tell you if it works :)
<Riddell> ah, sorry
 * xnox is pondering if it's trigger a rebuild, or sneakily copy-binaries back into the archive.
<cjwatson> No, unfortunately that didn't work.  I changed Riddell's hint to be unblock rather than force, then undeleted the packages from -proposed in the hope that I could then trigger a rebuild of armhf/powerpc and proposed-migration would copy it to release again when those were done.
<cjwatson> However, that isn't enough to resurrect a SUPERSEDED build record.
<cjwatson> It might be possible to recover this with DB surgery, but I'm not willing to attempt that when it isn't strictly necessary.  I suggest reuploading. :-(
<slangasek> stgraber: libreoffice is currently blocked in -proposed; we ought to take the update, since it fixes coinstallability of language support
<stgraber> slangasek: agreed
<slangasek> stgraber: can you handle the unblock? (since you already have a hint file handy :)
<stgraber> slangasek: yep, will do
<slangasek> ta!
<Riddell> cjwatson: I'll upload a new version then
<cjwatson> Thanks
<cjwatson> You'll need to bump the unblock version in your hint of course
<phillw> cjwatson: I was under the mis-understanding that AMD64+Mac was bug 1153992, with that working for alternate (lubuntu) there is still no build for the AMD64+Mac. I'm sorry if I 'nag', but do you have any update on it?
<ubot2> Launchpad bug 1153992 in Ubuntu CD Images "Raring server and precise d-i installations fail at the clock configuring step" [Critical,Fix released] https://launchpad.net/bugs/1153992
<cjwatson> phillw: It's on the Raring Daily milestone.  As to why it's not on the Raring Beta 1 milestone on iso.qa, that would be something for you to discuss with stgraber.
<cjwatson> phillw: The cdimage side of things appears to be working fine.
<stgraber> phillw: that'd be because the product lead didn't ask for +mac to be on the manifest
<phillw> cjwatson: thanks, I'll catch up with stgraber and ask him to mirror it over (I'm guessing it is due to this 'freeze' thingie :P )
<cjwatson> phillw: 1153992 was indeed entirely unrelated to this matter.
<stgraber> the manifest was generated from what was released in 12.10 and apparently you didn't have +mac back then
<phillw> stgraber: he did not?
<stgraber> or it wasn't addded to the manifest for 12.10 anyway
<xnox> stgraber: yes, due to no lack/absence of +mac testers.
<phillw> stgraber: https://help.ubuntu.com/community/Lubuntu/GetLubuntu
<phillw> We did, as far as I can see?
<phillw> xnox: we have a very dedicated +Mac tester, it was he who alerted me to the missing ISO.
<stgraber> phillw: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest disagrees
<stgraber> phillw: anyway, if you get gilir to ask for +mac, I'm happy to add it
<phillw> stgraber: without wanting to start a row, http://cdimages.ubuntu.com/lubuntu/releases/quantal/release/ says we have.
<cjwatson> That's a different matter.
<cjwatson> Builds != releases
<phillw> stgraber: I'm actually in the rare position of being able to ask for it :) I knew what he did to me would be handy one day...https://launchpad.net/~lubuntu-product-managers
<cjwatson> Wait, that is a release, wtf
<cjwatson> well, I suppose this is just one more way the old manifest scheme didn't work
<phillw> cjwatson: you've lost me there. We had builds, we have had releases, what is the need to ask for it to be resurrected 3/4 the way through 13.04?
<cjwatson> I'm on my phone, accuracy is optional
<cjwatson> we should kill off the old manifest scheme ... oh wait, we did :)
<stgraber> ;)
<phillw> asides of that, can we please have the +Mac on the beta 1 testing area? Pretty please :D
<cjwatson> I suspect that the tracker and the manifest got out of sync near the tail end of the 12.10 release and nobody noticed.
<phillw> cjwatson: as I recall, we were still testing PPC stuff when you were moving them to 'final release'. It was some what of a crazy day :)
<cjwatson> Or possibly I got confused while doing the publishing.
<cjwatson> shrug
<cjwatson> Not likely to be debuggable from this distance in time
<phillw> cjwatson: heck, they all got out there and bug reports were what was in the release notes....
<cjwatson> No release is perfect
<phillw> if it were, you'd all be out of a job :)
<stgraber> oh no, I'm sure we'd still have enough work even if the releasing process was perfect
<phillw> stgraber: I was not referring to the release process, I was referring to what is released :P
<phillw> But, I will leave you good people in peace. thank you, as always, for tolerating me on here :)
<phillw> or maybe not... Have I used up my allotted time to ask about things?
<phillw> I'll email it, as it something I cannot see an answer to as a bug.
<phillw> stgraber: / cjwatson can you remove the notice "Respins upcoming for bug 1153992; will affect at least most server/alternate images." from http://iso.qa.ubuntu.com/ Thanks :)
<ubot2> Launchpad bug 1153992 in Ubuntu CD Images "Raring server and precise d-i installations fail at the clock configuring step" [Critical,Fix released] https://launchpad.net/bugs/1153992
<stgraber> I'm waving through the grub binary in Unapproved so I can then have this migrate to raring
<stgraber> respinning Edubuntu for new grub2, that will hopefully fix amd64
<stgraber> cjwatson: edubuntu-dvd-amd64 on kapok.buildd finished at 2013-03-13 04:16:05 (success)
<RAOF> You know what would be awesome? If people could say âverifed on preciseâ or âverified on quantalâ rather than just âverifiedâ on bugs SRUd to both Precise and Quantal.
<RAOF> Hm. We don't _really_ support Oneiric now, do we.
 * RAOF eyes off the SRUs awaiting verification for 200+ days
<micahg> technically for about another month
<RAOF>  !!! There are 3 packages in the oneiric-unapproved queueâ½
<ubot2> RAOF: I am only a bot, please don't think I'm intelligent :)
<RAOF> infinity: Were you the one who didn't want be rejecting gcc-4.6 from the precise-unapproved queue because you wanted it there as a reminder to fix it?
<infinity> RAOF: Yeah, but go ahead and reject it, and doko and I can discuss it later.
<RAOF> Oh, god. Webservices.
<RAOF> Oh dear lord, unity-2d's mega sru.
<cjwatson> stgraber: woo
<didrocks> infinity: hey. grrr, it seems that the killing all process fix didn't work. Do you mind killing https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4365076 please?
<JackYu> Hi, I am Jack from UbuntuKylin team. We are wondering how could we customize the first show when installing? we created a branch lp:syslinux-themes-ubuntukylin, but don't know how to use it...
<seb128> JackYu, hey, what do you call "first show"? the installer slideshow?
<seb128> or the screen at the very beginning of the boot?
<JackYu> seb128: the screen at the very beginning of the boot.
<ShineHuang> is the first screen of install process
<JackYu> seb128: how could we customize it? thanks.
<seb128> JackYu, I'm not sure, but cjwatson can probably help you (not sure if he's around yet)
<JackYu> seb128: thanks. I will ping him:)
<seb128> JackYu, you can considered him pinged
<seb128> he reads this channel and his nickname got mentioned
<seb128> I'm sure he will read it when he's around ;-)
<JackYu> oh, i see. so I will wait for his response.
<cjwatson> JackYu: I would rather not have a separate package - all other flavours share a single implementation
<cjwatson> JackYu: do you just need to replace the graphic?
<maclin> Hi watson, we also want to replace the dialog for F1
<JackYu> cjwatson: yes, we need replace the graphic and the F1
<JackYu> cjwatson: so we submit the graphic and the content to you? is it ok?
<cjwatson> I'm not sure you can replace F1 straightforwardly
<cjwatson> It would depend what you wanted to do with it
<cjwatson> maclin: FYI Watson is my family name - my personal name is Colin
<cjwatson> or just "cjwatson" is fine
<maclin> I'm sorry
<cjwatson> For the graphic, yes, send that to me
<JackYu> cjwatson: we only replace the 'Ubuntu' to 'UbuntuKylin' in F1
<cjwatson> I'll have to check how feasible that is right now.  I don't think we replace it in other flavours
<cjwatson> In some places it's talking about the Ubuntu project as a whole
<JackYu> sure, thanks. if not easy, just keep the F1.
<JackYu> I will send the graphic to your email asap.
<cjwatson> If we change anything there, it should be some kind of general change for all flavours, rather than a specific hack for UbuntuKylin
<cjwatson> IMO
<cjwatson> Are you still seeing that problem with ubuntukylin-default-settings not being installed on the target system?  That was pretty surprising ...
<cjwatson> maclin: That's OK, I know ordering conventions differ
<cjwatson> But better to say early :)
<JackYu> yes, it works ok when we build locally
<penghuan> we tried ubuntukylin-default-settings locally, it works well.
<cjwatson> I mean the cdimage.u.c builds, not something local
<JackYu> en, we are also wondering why it not work on cdimage...
<cjwatson> OK, so I'll try to reproduce that this morning
<JackYu> Thanks. do you have any logs on the iso build process?
<JackYu> BTW, we are working to update some packages. I will file bugs to these exceptions:)
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntukylin/
<cjwatson> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntukylin/raring/
<cjwatson> former for the squashfs part, latter for the main ISO
<JackYu> well, thanks
<cjwatson> hmm, weird black bar on the boot menu
<cjwatson> JackYu: do you want to have the same behaviour as Ubuntu where you have to press a key if you want the boot menu, but otherwise it boots straight into a graphical "try" or "install" screen?
<cjwatson> maclin: regarding bug 1153917, it's always a good idea to report separate problems as separate bugs; version updates need to be tracked separately
<ubot2> Launchpad bug 1153917 in UbuntuKylin "UbuntuKylin Default Settings do not worked as expected" [Undecided,Confirmed] https://launchpad.net/bugs/1153917
<JackYu> cjwatson: We prefer the same behavior as Ubuntu...
<cjwatson> OK, I can arrange that
<cjwatson> Drat, why doesn't this laptop have KVM support turned on
<maclin> I find the following log:
<maclin> The following packages will be REMOVED:
<maclin>   libreoffice-help-zh-cn ubuntukylin-default-settings
<cjwatson> Are you sure that's current?
<cjwatson> I thought I'd fixed that
<cjwatson> Ah, yes, it is
<cjwatson> In that case this'll be fixed by the new libreoffice
<cjwatson> So I think a plain rebuild will fix this - I'll sort out your boot menu and then do that
<maclin> cjwatson: I think it maybe about 'apt-get autoremove' libreoffice-l10n-zh-cn
<cjwatson> No
<cjwatson> It was a Conflicts in libreoffice which we analysed and fixed the other day
<cjwatson> But it took a while to build everywhere
<cjwatson> Because libreoffice
<cjwatson> I'm building new images now
<JackYu> it's great:)
<maclin> OK. Another question: this is found in the log of 20130311.2 while the image we test is 20130311.3. Is that OK?
<cjwatson> Yes, the livefs build IDs and the CD build IDs are not necessarily in sync
<cjwatson> Because it's possible to build a new image without building a new livefs
<maclin> Good, we will  expect new image to test, thanks cjwatson!
<tumbleweed> what rationale did stgraber use for his beta-1 block? there are packages seeded in flavours participating in the beta that he hasn't blocked, and people are requesting FFes for
<xnox> tumbleweed: whatever the product owners asked to block.
<xnox> no more / no less.
<cjwatson> I think stgraber said it was incomplete ...
<Laney> right, and based on what ScottK had before
<tumbleweed> what am I getting at, is should we be deferring FFes for a couple of days, or adding to the block list
<xnox> but there are first-time flavours this time around, and hence the block possibly needs to be expanded.
<tumbleweed> also, some of these things are insane. did people forget about FF again?
<xnox> (first-time with blocks that is)
<cjwatson> Laney: do you think the verification in bug 1041432 is sufficient for both precise and quantal?  you just applied the general v-done tag
<ubot2> Launchpad bug 1041432 in gst-plugins-good0.10 (Ubuntu Quantal) "Any application which uses v4l2src element can be froze when recording video (e.x. cheese)" [High,Fix committed] https://launchpad.net/bugs/1041432
<Laney> reviewing "New Unity stack" are we? :-)
<tumbleweed> Laney: well, it came past :P
<Laney> cjwatson: I couldn't rememeber what the format was (v-d-precise?) and figured that the promoter would just do precise and then flip it back
<cjwatson> Don't rely on that :)
<cjwatson> tweaked the tags now
<Laney> merci
<cjwatson> And yes, v-done-precise
<cjwatson> Package: gnome-shell
<cjwatson> Task: ubuntu-gnome-desktop
<cjwatson> oh good, that's in place
<Laney> tumbleweed: I think I'm going to approve stuff and block it
<tumbleweed> Laney: thanks. I've got intermittent access to my e-mail atm
<Laney> e.g. shotwell
<tumbleweed> yeah, I'm ok with the yorba stuff
<tumbleweed> nautilus sounds sane too
<Laney> will leave unity to you :-)
<tumbleweed> pffff
<Laney> seb128: ^ so you don't need to hold off uploading that stuff as I've blocked it until after the beta
<seb128> Laney, thanks
<Laney> or I would have... diverged branches
 * Laney just found some worcestershire sauce which expired in 2008
<Laney> probably fine, right?
<Daviey> for sure.
<Riddell> stgraber: could you spin up new kubuntu images?
<cjwatson> Riddell: What are the changes, so I can mention them on the tracker?
<cjwatson> (I expect stgraber isn't up yet)
<Riddell> cjwatson: ubiquity fixes, kubuntu-settings and kde-workspace
<cjwatson> Riddell: Kubuntu Active too, or just desktop?
<Riddell> cjwatson: yes active too please
<cjwatson> OK, marked for rebuild
<cjwatson> And rebuilding now
<highvoltage> have anyone come across this bug testing today's images yet? https://bugs.launchpad.net/ubuntu/+bug/1154539
<ubot2> Launchpad bug 1154539 in ubuntu "[raring-beta1] Live system does not boot to LightDM when a disk is attached with swap" [Undecided,New]
<JackYu> cjwatson: I have filed two separate bugs for  Chinese-calendar and indicator-china-weather to Upgrade to latest version , i.e., bug #1154542 and bug # 1154523. Would you please help us to check them?
<ubot2> Launchpad bug 1154542 in chinese-calendar (Ubuntu) "Upgrade to chinese-calendar 0.7.6 in Raring" [Undecided,New] https://launchpad.net/bugs/1154542
<cjwatson> JackYu: I'm afraid I have no experience with either package - you probably want somebody a bit more desktopy?
<cjwatson> Or maybe whoever uploaded them last
<cjwatson> I mean, the bugs themselves are fine
<JackYu> cjwatson: it said that 'Once the Feature Freeze Exception has been ACK'd by a member of the Release Team, the status will be changed to TRIAGED. '
<cjwatson> Do you have a conventional tag for bugs that UbuntuKylin is interested in?
<cjwatson> Ah, yes
<cjwatson> You might want to put '[FFE]' or something at the front of the bug subject to indicate that that's what you're looking for
<JackYu> so we need somebody to TRIAGED them:)
<cjwatson> I'll amend these ones now
<JackYu> Ah, thanks:)
<JackYu> cjwatson: the other one is bug # 1154523 :)
<JackYu>  bug #1154523
<ubot2> Launchpad bug 1154523 in indicator-china-weather (Ubuntu) "Upgrade to indicator-china-weather 1.0.4 in Raring" [Undecided,New] https://launchpad.net/bugs/1154523
<cjwatson> Yeah, I know, I was just interrupted by the computer recycling man turning up
<JackYu> :)
<cjwatson> study[cjwatson] -= 4 * monitor
<cjwatson> JackYu: Don't worry about it for this time, but for future reference, excluding the .bzr directory from your diffs would be very helpful
<cjwatson> If it's in bzr anyway, you could just use 'bzr diff' with appropriate arguments, rather than creating a -new directory and diffing the old-fashioned way
<cjwatson> But, failing that, --exclude=.bzr
<cjwatson> Triaged now but I have some comments on 1154523 that really ought to be addressed
<xnox> JackYu: http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ is good intro into what bzr is, what it can do, and how does it help.
<JackYu> cjwatson: nice. I got it. will follow your suggestion next time:)
<JackYu> cjwaton: we have downloaded the newest image and found that 1) the default-setting package still dose not take effect, e.g., the wallpaper is still the same as ubuntu;  and 2) the screen at the very beginning of the boot when installing doesn't show as we expected.
<ScottK> tumbleweed: The goal of the block (and it's coverage is not as complete as it should be) is to block transitions of packages on the participating product ISOs.  I gave stgraber an initial hint for Kubuntu + base.  He's added other packages for other flavors, AIUI.  No, you don't need to defer FFes.  In theory stuff should just sit in proposed until the block is listed with no harm.
<JackYu> cjwatson: but this time, we did not find any error in the log.
<cjwatson> JackYu: I noticed the boot screen problem myself and have just committed a fix
<cjwatson> (gfxboot has fairly limited PCX parsing; I ran 'mogrify -colors 256' over it to fix it)
<JackYu> thanks for that.
<tumbleweed> ScottK: ok, I didn't have a hints file at the time, but I created one now (assuming that doesn't still need a bzr up on teh other side). so I'll block things I approve, as needed
<cjwatson> JackYu: As for the wallpaper, please can you describe the exact sequence of steps you took all the way from the boot screen?  There are a few possibilities and I need to make sure I'm checking the right one.
<cjwatson> It seems odd to me that the calendar pops up in the middle of the desktop when you start.  Is that intentional?
<ScottK> tumbleweed: You do have one.  When I bzr pull the hints directory, I got your file.
<cjwatson> tumbleweed: bzr up is automatic; you're fine
<tumbleweed> cjwatson: ta
<JackYu> yes:). But we have changed in the latest version of calendar.
<tumbleweed> ScottK: there's the config side to tell britney about it (in the early, days, I believe that was manual)
<ScottK> Oh.
<ScottK> Didn't know.
<cjwatson> JackYu: I seem to get the proper wallpaper in my simple test (i.e. boot live CD in "Try UbuntuKylin without installing" mode)
<JackYu> cjwatson: the wallpaper is in the default-settings package, and default-setting will install ubuntukylin-theme. but they did not show...
<cjwatson> JackYu: But it does show for me, so if you want me to investigate it then I need a precise sequence of steps to reproduce the problem.
<JackYu> really?
<cjwatson> We're obviously not doing the same thing.  I've told you what I did; now you tell me what you did
<JackYu> we run the iso using virtual box and try ubuntukylin without installing, but the wallpaper doesn't show
<cjwatson> Can I have a screenshot?
<JackYu> a moment
<cjwatson> Also, i386 or amd64?
<JackYu> i386
<cjwatson> Likewise
<cjwatson> JackYu: So, after I move the calendar out of the way, it looks like this for me in virtualbox: http://people.canonical.com/~cjwatson/tmp/ubuntukylin.png
<cjwatson> That's your wallpaper, isn't it?
<JackYu> cjwatson: email you
<JackYu> Yes!
<cjwatson> I'll just respin to fix the boot screen
<JackYu> you are using which image?
<cjwatson> JackYu: http://cdimage.ubuntu.com/ubuntukylin/daily-live/20130313/raring-desktop-i386.iso
<JackYu> ok, we will try this one again.
<cjwatson> The link on iso.qa looks correct too
<JackYu> sure. thanks.
<cjwatson> (I typically use rsync though)
 * stgraber waves
<cjwatson> yo
<cjwatson> JackYu: there we go, that fixes the boot screen
<cjwatson> (20130313.1)
<cjwatson> no changes to the live filesystem
<JackYu> ok, we will try the latest one:)
<cjwatson> JackYu: So this is why I wanted you to give me exact steps - you didn't tell me that you'd let the boot menu proceed without pressing a key, and then selected "Try UbuntuKylin" from the graphical menu; as opposed to pressing a key at the boot menu and selecting "Try UbuntuKylin without installing"
<JackYu> cjwatson: without pressing a key, it goes to the selection screen.
<cjwatson> Indeed.  But you didn't tell me that that was what you were doing :)
<cjwatson> And that was what I needed to know.  I worked it out from the screenshot ..
<cjwatson> Do you see what I mean now?
 * ogra_ hands cjwatson hos spare crystal ball 
<ogra_> *his
<JackYu> oh, i see. sorry for your time:0
<cjwatson> Well, no, I'm not trying to be sarcastic, just trying to make bug reporting more effective :)
<JackYu> thank you. I will do it better next time:)
<cjwatson> JackYu: OK, ubiquity bug, fix committed for the next upload (2.13.16)
<cjwatson> should only have affected the wallpaper during installation / live session, not the rest of it
<JackYu> cjwatson: yes.
<stgraber> can I get someone to review bug 1154601 fairly quickly?
<ubot2> Launchpad bug 1154601 in edubuntu-live (Ubuntu) "[FFe] Disable the edubuntu-server bits on the Edubuntu media" [Undecided,New] https://launchpad.net/bugs/1154601
<stgraber> edubuntu as it currently is isn't in a state we'd feel like releasing for beta1 so I'm preparing a bunch of changes that I hope will address that. If I make it any worse, we'll simply skip beta1, if I somehow get it all right, we'll have something worth shipping.
<stgraber> Sorry for the last minute notice but I only just found a few minutes to look at it now after highvoltage did an initial test of the images generated yesterday...
<cjwatson> stgraber: acked in the bug
<stgraber> cjwatson: thanks
<cjwatson> Damn, too slow, ScottK beat me
<ScottK> ;-)
<ScottK> Seemed like an easy decision to make.
<ScottK> Anyone on u-release have an opinion on this new Unity stack FFe?
<ScottK> It seems to me exactly the kind of thing we said we'd say no to when we moved feature freeze later in the cycle.
<stgraber> I'm really annoyed that they haven't learned from the past cycles... and I don't think they can get away with the "vUDS and release discussions" argument because they're essentially telling us they'll only be ready in a month...
<tumbleweed> ScottK: I think we should push back hard, yes. We said we would
<highvoltage> stgraber: I think for Edubuntu, it might make sense to skip beta1 for tomorrow, and then aim to have a beta quality image early next week
<highvoltage> (probably not even worth while to make a big deal about it either)
<stgraber> highvoltage: well, I'll still do the cdimage, artwork and installer fixes now and respin. We should have another image early this afternoon and can decide then. I know that if I don't do those changes now they'll get moved to the bottom of my TODO and we'll be in the exact same state for beta2
<highvoltage> stgraber: imho the swap partition problem is a blocker
<highvoltage> https://bugs.launchpad.net/ubuntu/+bug/1154539
<ubot2> Launchpad bug 1154539 in ubuntu "[raring-beta1] Live system does not boot to LightDM when a disk is attached with swap" [Undecided,New]
<stgraber> highvoltage: I'm trying to reproduce that one now. I find it hard to believe we would have missed this if it was as simple as "any swap partition"
<highvoltage> stgraber: yeah, hopefully that's not the case
<stgraber> highvoltage: appears to be pretty consistently reproducable... I'll have to test with Ubuntu next
<stgraber> highvoltage: the reason why I never noticed is that I usually use virtio devices and casper doesn't know about those, so simply skips them
<stgraber> highvoltage: Ubuntu isn't affected... odd...
<stgraber> highvoltage: I'm going to ignore that problem and fix everything else first, then respin and hope the problem will just vanish ;)
<stgraber> highvoltage: the only thing I can think of that may cause casper to do weird things on Edubuntu is the multiple squashfs and I just fixed that by removing the server one from the cdimage scripts
<highvoltage> stgraber: ok. could you confirm it on edubuntu?
<stgraber> highvoltage: yeah, I definitely have it on edubuntu
<jokerdino> infinity: hey, around? :)
<stgraber> highvoltage: I'm reverting edubuntu-live to the 12.10 version, that should fix all our current issues
<stgraber> highvoltage: that should fix the lightdm config bug in the process
<stgraber> highvoltage: revert of edubuntu-live uploaded. I'll trigger a new build once it lands.
<stgraber> highvoltage: unless we broke anything else, this should bring us back to where we were with 12.10
<stgraber> highvoltage: edubuntu rebuilding now
 * Laney stabs affects-metoo for process bugs
<jbicha> cjwatson: I noticed that http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/ is live, thank you!
<cjwatson> Oh, yes, I set that up earlier today - didn't notice you coming online
<jbicha> I don't think we plan to support powerpc at this time, I'm not sure if we have people to test the amd64+mac images or not
<cjwatson> jbicha: Do you want the boot menu to behave like Ubuntu's (the "press a key" screen)?
<cjwatson> and then into ubiquity with a try/install choice if you don't press anything?
<cjwatson> Yeah, I was going to check on architectures
<cjwatson> jbicha: So http://paste.ubuntu.com/5611239/ ?
<didrocks> joshuahoover: hey, please do not update the FFe bug without asking
<didrocks> joshuahoover: adding lenses we are not waiting to install by default this release
<jbicha> cjwatson: yes to those archs
<joshuahoover> didrocks: my understanding was we want those in by default
<didrocks> joshuahoover: it's not the list communicated by PS to me
<didrocks> joshuahoover: did you check with them? are they ready? is the packaging fixed as we did for the others?
<cjwatson> you know it's OK to have multiple FFE bugs if there's some disagreement about whether things are connected ...
<joshuahoover> didrocks: i will double check, but i was talking to thostr_ earlier and he wanted me to double check the list for client scopes that are said to be ready to go
<didrocks> joshuahoover: ok, tell him to send me an email, I spent a day updating 40 components, so if you want those in, please update with the same fixes I had to do on the others
<didrocks> joshuahoover: I'm removing them meanwhile, feel free to update if the double checking is positive :)
<joshuahoover> didrocks: will do, sorry for the confusion :)
<didrocks> joshuahoover: no worry, as the bug is polemic already, I prefer we avoid noise ;-)
<joshuahoover> heh
<cjwatson> jbicha: OK, I've applied that and removed the amd64+mac and powerpc images
<infinity> jokerdino: Am now.
<xnox> infinity: what do you want me to do to get openssl accepted into quantal|precise-proposed? write autopkgtests to abuse webservers over https? anything else?
<infinity> xnox: Talk to Rob Herring to see what testing he's done?
<infinity> xnox: I'm not sure how autopkgtests factor into it, unless you happen to have an autopkgtest environment on ARM (I thought it all relied on KVM or something).
<xnox> infinity: does this mean I get to go and see motocorss races with him?
 * xnox ponders if I got wrong Rob Herring......
<infinity> xnox: :P
<stgraber> hallyn: hey, just so you know, we found a very very odd bug on Edubuntu :)
<stgraber> hallyn: mountall will fail at boot time if cgroup-lite is installed and you have a swap in /etc/fstab
<stgraber> hallyn: preventing the media from booting completely
<stgraber> hallyn: removing the swap from /etc/fstab OR removing cgroup-lite fixes the issue
 * slangasek squints
<slangasek> is this related to the new change to add cgroups to /lib/init/fstab?
<hallyn> a SWAP in fstab?
<hallyn> that seems random
<stgraber> slangasek: not impossible. We may be getting some kind of race between mountall and cgroup-lite to mount /sys/fs/cgroup.
<slangasek> yes, since cgroup-lite is 'start on mounted MOUNTPOINT=/sys'
<stgraber> hallyn: actually, looking at it, we probably want to change the start condition for cgroup-lite. that maybe the problem
<infinity> And mounting (or not) your swap partition is altering the timing of the race? :)
<slangasek> there's certainly a race there
<stgraber> hallyn: we'd want MOUNTPOINT=/sys/fs/cgroup
<slangasek> right, cgroup-lite's upstart job should be changed, and cgroup-lite should add a versioned depends on mountall
<stgraber> slangasek: good, we seem to agree then ;) Changing that in my test VM to see if that fixes it
<hallyn> stgraber: good point, now that that is always a mountpoint, we can do that, cool.
<hallyn> stgraber: if it fixes it for you do you mind pushign the fix?
<slangasek> (or we can add a versioned Breaks: on old cgroup-lite, if people think cgroup-lite Depends: mountall is wrong)
<stgraber> infinity: it's a very very reliable race though. I reproduced it 10-15 times here and highvoltage reproduced it using a different VM solution on a different machine, apparently just as reliably :)
<infinity> stgraber: Cute.
<stgraber> hallyn: if that works, I'll push the fix immediately, then respin Edubuntu so we have a working image for beta1
<infinity> slangasek: The Breaks is definitely more correct.
<slangasek> infinity: is it?  The new version of cgroup-lite will have a no-op upstart job in the absence of the new mountall
<hallyn> still it might be worth figuring out what is the actual cause of the hang...  cause that feels like a workaround for a bad bug
<slangasek> so it might be that both are equally correct
<infinity> slangasek: Oh, if the job ends up actually depending on mountall, then the dep is fine.
<slangasek> infinity: well, cgroup-lite being "start on mounted $anything" implies a dependency on mountall
<stgraber> eventually cgroup-lite should make its way to Debian and be used with something else than upstart, but for now, versioned Depends works for me
<infinity> slangasek: I was thinking of this more from the Debian multiple swappable init systems perspective, where forcing mountall on people is wrong, but if our cgroup-lite is actually useless without mountall, the dep is correct.
<infinity> slangasek: Moreover, it's all academic, since mountall is Essential in Ubuntu anyway.
<slangasek> stgraber: nah, eventually cgroup-lite should make its way to Debian and Debian should be using upstart for everything
<slangasek> infinity: no it isn't :)
<slangasek> upstart is not Essential, and neither is mountall
<infinity> slangasek: Transitively, isn't it?  Oh, sorry, required, not Essential.
<slangasek> ah, required, yes
<stgraber> ok, MOUNTPOINT=/sys/fs/cgroup works fine. I'll push that along with a versioned Depends on mountall
<infinity> Hrm, have we actually removed anything that depends on upstart out of the Essential set?  I was sure it used to be.
<infinity> That's shiny news for people who want to fiddle with init swapping at some point.
<stgraber> highvoltage: ETA ~2h for working Edubuntu images
<infinity> (Though I'd rather do that in Debian anyway)
<xnox> infinity: i think i added upstart-job dependency to shadow, which i should remove probably.
<infinity> xnox: Not to login, which is the only Essential part of shadow.
<slangasek> xnox: you added it manually?
<slangasek> anyway, the fix for that is to make upstart-job go away
<xnox> slangasek: we've been through this.... dh_installinit did that for me.
<infinity> slangasek: No, he added it by giving passwd an upstart job. :P
<slangasek> by 1) fixing remaining init scripts to work with insserv, 2) un-neutering insserv, 3) merging sysvinit
<xnox> remember the locked shadow dbs bug.....
<slangasek> xnox: right, thought so, but maybe my memory was playing tricks on me :)
<slangasek> xnox: yeah, I remember the job in question - was just wondering about "added upstart-job dependency" and making sure you didn't do it manually
<stgraber> hallyn: cgroup-lite uploaded
<hallyn> stgraber: saw it - thanks
<hallyn> but i think i'll set up a vm to test the old in.  it's weird
<hallyn> i can't reproduce it...
<stgraber> hallyn: the easiest reproducer is current edubuntu amd64
<stgraber> hallyn: boot it on a system that has a disk containing a swap partition (connected over SATA, not VIRTIO as a casper bug makes VIRTIO work just fine ;))
<hallyn> aw look at that, google gives me a nice pic of you :)
<stgraber> (casper doesn't try to setup swap partitions for vda devices. I have a fix staged in ubuntu:casper to fix that post-beta1.)
<stgraber> hallyn: yeah, google does that sometimes...
<highvoltage> hallyn: the scary thing is when I google myself and get pics of stgraber
<hallyn> :)
<hallyn> identity theft can strike anyone
<cjohnston> Laney: ping
#ubuntu-release 2013-03-14
<stgraber> utlemming: hey, you appear to be missing a few test results for the cloud images on iso.qa.ubuntu.com, are you missing some of the regions in your script?
<stgraber> Riddell, ScottK, zequence, knome, highvoltage, JackYu, utlemming: Sorry, I've been pretty busy with non-beta1 stuff so haven't had a chance to draft the announcement yet. I'll do so tomorrow morning and share it with you. Please make sure to have your links ready by then. It'd also be appreciated if you could get the products you intend to release as Ready on the tracker (or ask me if you can't do it yourself).
<JackYu> stgraber: got it.
<JackYu> stgraber: the announcement of ubuntukylin could be set to: https://wiki.ubuntu.com/UbuntuKylin/1304-beta-1-ReleaseNote
<highvoltage> stgraber: the current edubuntu images look good for beta release, I'm marking as ready
<Laney> hi cjohnston
<Laney> contentful pings work better in general :-)
<smartboyhw> Can I ask: Where is the Ubuntu Studio Beta 1 release notes in?
<smartboyhw> And release team: Can the Ubuntu Studio release team remove all the upgrade testcases by this stage?
<smartboyhw> First "release team" = The main Ubuntu one
<tumbleweed> there is only one release team :)
<smartboyhw> tumbleweed, em stgraber helped many flavours set up their own release management teams for their OWN flavours in the ISO QA Tracker:P
<smartboyhw> And BTW just asking my original question...
<highvoltage> stgraber: you asked for news links, the edubuntu one will be http://www.edubuntu.org/news/13.04-beta1
<cjohnston> Laney: thanks for the reply on the bug.
<Laney> np
<cjohnston> I commented my specific reason for wanting it. :-)
<xnox> Laney: looks like that failed-to-boot bug is fixed by pitti.
<Laney> yes
<xnox> Laney: when will raring-proposed be unblocked?
<xnox> Laney: or can we still be respinning?
<Laney> some time after the point of no return
 * smartboyhw wonders can he actually remove the upgrades
<Laney> the testcases?
<smartboyhw> Laney, yep (for Ubuntu Studio)
<smartboyhw> Just wondering if it is too late
<Laney> why do you need to?
<zequence> smartboyhw: All tests are done now
<smartboyhw> zequence, the upgrades?
<smartboyhw> Wow:)
<zequence> smartboyhw: Not the upgrades
<smartboyhw> zequence, ah OK
<smartboyhw> Laney, um 1. We don't recommend it, 2. Not enough testers (at all times)
<Laney> I don't think you need to remove them just because nobody has done them yet
<smartboyhw> Laney, well but we don't actually recommend it as we said
<Laney> you'll see Lubuntu and Edubuntu are in the same state
<Laney> you don't recommend upgrading?!
<smartboyhw> Laney, yep
<smartboyhw> zequence, am I correct?:P
<zequence> We haven't put any time on investigating the problems around upgrading
<smartboyhw> yep
<zequence> From my personal experience, it's not a flawless experience
<smartboyhw> Can't we just remove it for Beta 1 at least?
<zequence> So, since we have no data, and no actions against any bugs that might appear, we should not recommend upgrading
<xnox> zequence: i think you can just mark image as ready with or without upgrade tests, if you are happy to release that.
<zequence> However, for any release after raring, it would be wise to do some research on this
<smartboyhw> zequence, I think I am OK marking it ready now:)
<zequence> smartboyhw: Yep. Fine by me
<smartboyhw> xnox, ACK from zequence + me:)
<smartboyhw> OK zequence I marked them as ready now:)
<zequence> smartboyhw: ok
<smartboyhw> zequence, so do we still want the upgrade testcases for beta 1 ONLY?
<zequence> I think we can remove it for now. Perhaps we do have some time to do it before final beta. That might be worth the effort
<smartboyhw> zequence, OK:)
<smartboyhw> zequence, removed
<Laney> IMO it would be a good thing to do for your users, even if just to document the bugs
<Laney> you'll not get everyone reinstalling
<smartboyhw> Laney, well I think they wouldn't upgrade now anyway:P
<smartboyhw> And we can fix it before Beta 2
<Laney> not right now, but in general
<zequence> I agree on finding bugs
<knome> is the "auto-resize" option supposed to be dropped?
<knome> or do you need non-ubuntu installation on the disk before the installer suggests that?
<JackYu> Laney: I updated the diff file of bug #1154999.
<ubot2> Launchpad bug 1154999 in ubuntukylin-default-settings (Ubuntu) " [FFE] Upgrade to ubuntukylin-default-settings 1.0.2 in Raring " [Undecided,New] https://launchpad.net/bugs/1154999
<smartboyhw> knome, you mean Ubuntu Studio or?
<knome> i mean generally.
<smartboyhw> Um no I think
 * smartboyhw saw it in UbuntuKylin
<cjwatson> knome: auto-resize is only offered in some circumstances, which are a bit complex to fit into an IRC channel
<knome> cjwatson, is there any documentation for it anywhere?
<cjwatson> knome: among other things, the MBR partition table format is sufficiently lame that it's simply not always possible to offer it
<cjwatson> I don't recall
<knome> okay
<cjwatson> The short answer is that it shouldn't be considered a testing bug if you don't get it
<cjwatson> I thought there was something somewhere in the testcase docs but it's been a while ...
<knome> that stops me from running that test then
<cjwatson> Yes, it would
<knome> but i'll make a mental note to not worry about that too much
<cjwatson> But realistically it's probably good enough if it's run on at least one flavour for the relevant ubiquity frontend
<knome> i'll just test other things, like upgrades
<cjwatson> ISO testers tend to run into the limitations more than most - for example they stand a greater chance of already having four primary partitions, or not being able to get an extended partition into the area that would be freed by resize because there's already an extended partition elsewhere and the area in question is separated from it by a primary partition
<cjwatson> MBR constraints are pretty silly
<knome> mhm.
<JackYu> cjwatson: would you please add '--locale zh_CN' when building UbuntuKylin?
<cjwatson> Not quite that simple - that's an ubuntu-defaults-image option and UbuntuKylin isn't built using ubuntu-defaults-image
<cjwatson> What exact change are you trying to effect?
<JackYu> after entering the try or install show, the default language is English. we want it be Simplifed Chinese
<knome> stgraber, do you have an estimate of the time you're going to release?
<cjwatson> JackYu: Right, gfxboot default language.  Sure, I can do that
<cjwatson> (I thought that was probably it but wanted to confirm)
<JackYu> good, thanks.
<cjwatson> JackYu_: https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/675
<cjwatson> (uploaded)
<JackYu_> correct
<JackYu> cjwatson: we reported two FFE bugs to update ubuntukylin-default-settings and ubuntukylin-theme, i.e. bug #1154999, bug #1154988, would you please help to check them?
<ubot2> Launchpad bug 1154999 in ubuntukylin-default-settings (Ubuntu) " [FFE] Upgrade to ubuntukylin-default-settings 1.0.2 in Raring " [Undecided,New] https://launchpad.net/bugs/1154999
<ubot2> Launchpad bug 1154988 in ubuntukylin-theme (Ubuntu) " [FFE] Upgrade to ubuntukylin-theme 0.4.2 in Raring " [Wishlist,Triaged] https://launchpad.net/bugs/1154988
<ScottK> JackYu: They are both approved.
<JackYu> ScottK: great, thanks!
<ScottK> FYI, unblocked muon since the current one is badly broken.  Waiting to hear from Riddell to see if we'll respin for it.
<stgraber> knome: I'm hoping for a release in the next 4 hours or so
<knome> stgraber, ok. i'm just running the upgrade tests. desktop amd64 can be marked ready.
<knome> (i still need to run one little test on i386, will do that once the i386 upgrade tests finishes)
<Riddell> ScottK: in the middle of an upgrade, should be able to test in a wee bit
<ScottK> OK.
<Riddell> stgraber: so aye, we'd like a respin of kubuntu i386 and amd64 when muon 1.9.97 is in the archive
<stgraber> Riddell: ok
<stgraber> JackYu: hey, are you expecting to have something to release for beta1 (in around 3 hours)? looking at the tracker, it looks like you haven't got a lot of test results and those you have look pretty bad
<JackYu> stgraber: we are updating packages. Currently, only one left.
<cjwatson> It was maybe a bit ambitious to do a beta a couple of days after starting daily builds :)
<smartboyhw> That's why Ubuntu GNOME didn't join in the fun:)
<stgraber> JackYu: ok, so you are planning a last minute respin? (note that it takes around 30min to do a rebuild and may take an hour for the bits you need to publish in the archive, so you'd be left with just a bit over an hour to test it all)
<JackYu> correct:)
<JackYu> stgraber: yes:)
<ScottK> stgraber and JackYu: I've also put a transition block on the updated packages you put in an FFe for.  If those are needed, they will need an unblock.
<ScottK> default settins and theme ...
<stgraber> ScottK: ok, sounds to me like they want those in as the current images don't look too good. Can you remove your block or do you prefer me to add an explicit unblock?
<JackYu> I'am asking Zhengpeng Hou to upload,  and the default-settings in ready.
<ScottK> stgraber: I put it in your block (for consistency).  I can remove it.
<stgraber> ScottK: ah ok, probably best to keep it there so we have it next time and just add an explicit unblock then
<stgraber> ScottK: I'll take care of that
<stgraber> (just noticed ubuntukylin-theme hitting raring-changes)
<ScottK> OK.
<ScottK> That's why I added it to your block, so we'd have it in the history to start from.
<stgraber> JackYu: so what packages do you need updated? (I need to whitelist them)
<freeflying> stgraber: ubuntukylin-theme ubuntukylin-default-settings, chinese-calenda, just uploaded
<stgraber> freeflying: ok good, that matches what I saw on -changes, thanks
<JackYu> stgraber: Zhengpeng just done
<freeflying> stgraber: np
<stgraber> JackYu: so should I respin as soon as those 3 are in raring?
<JackYu> stgraber: yes
<JackYu> thanks
<JackYu> it should be ok, since we tested them locally:)
<stgraber> Riddell: looks like muon has now been published. Triggering a kubuntu desktop respin
<Riddell> stgraber: groovy
<ScottK> stgraber: Nice.  I was just typing a ping that you could do that.
<utlemming> Ubuntu Cloud Images are ready to go.
<stgraber> utlemming: ok. Can you mark them as such? (I "think" you now have the rights)
<utlemming> stgraber: looks like arosales is still the man for that
<JackYu> stgraber: would you please give our release team (https://launchpad.net/~ubuntukylin-release-team/) rights on the ISO QA Tracker?
<stgraber> JackYu: yep, I'll do that in a bit
<arosales> utlemming: is this for the release manifest
<stgraber> utlemming: aren't you in ~cloud-images-release-managers?
<utlemming> stgraber: yup, I am
<stgraber> utlemming: if so, you should be able to tick them on the tracker and mark them ready
<cjwatson> arosales: the release manifest has been superseded by new facilities on iso.qa.ubuntu.com, FYI
<stgraber> utlemming: hmm, or maybe not, let me triple-check the ACLs
<arosales> cjohnston: ah, thanks
<stgraber> utlemming: the ACLs look good, so it should work
<utlemming> stgraber: I don't see anyway to mark ready. Perhaps I am looking in the wrong spot.
<stgraber> utlemming: do you see tick boxes on http://iso.qa.ubuntu.com/qatracker/milestones/261/builds?
<utlemming> stgraber: negative, I do not.
<stgraber> utlemming: ah. Try to logout and login, making sure that the cloud-images-release-managers team is selected on the SSO page
<knome> stgraber, xubuntu i386 is ready.
<xnox> infinity: i'd appreciate for lvm2 precise SRU to be published, as I have another one comming up.
<utlemming> stgraber: after logging in an out a couple times, i only see test boxes on the tests.
<xnox> infinity: about openssl, it was inconclusive if Rob has any further testing of all and each asm enabled hash algo.
<stgraber> utlemming: yeah, according to the DB, the tracker didn't receive the team membership from SSO...
<stgraber> utlemming: what do you see on the SSO page, does it list team membership?
<utlemming> stgraber: the SSO page didn't ask about membership
 * arosales also doesn't see any checkboxes @ http://iso.qa.ubuntu.com/qatracker/milestones/261/builds
<stgraber> utlemming: can you add the "ubuntuqa" account to the team on LP? that's my test account when debugging that kind of weirdness
<utlemming> stgraber: done. login/logout yields same results
<stgraber> utlemming: ok, I'll test in a sec
<stgraber> Riddell, ScottK: there you go ^
<knome> stgraber, xubuntu i386 upgrades are ready.
<ScottK> stgraber: Thanks.
<JackYu> stgraber: is the rights of ubuntukylin-release-team set?
<stgraber> JackYu: no
<JackYu> I see:)
<JackYu> stgraber: all packages are ready, would you please  rebuild ubuntukylin?
<stgraber> JackYu: they're not ready
<stgraber> JackYu: they've been uploaded but they aren't done building and publishing
<stgraber> JackYu: I expect them to be in 30min or so
<JackYu> oh, i see
<JackYu> hi all, æè¦åå®¶å»äºï¼å°å®¶åä¸çº¿ï¼è·¯ä¸å¤§æ¦äºååéï¼å¦æè¿æé´stgraberæé®é¢ï¼åå¸®æåç­ä¸ä¸
 * Laney blinks
<cjwatson> JackYu: wrong channel ...
<JackYu> sorry, wrong channel
<JackYu> :(
<stgraber> utlemming: ok, it's going to take me a little while to figure out what's going on. I'll just mark your products as ready for now ;)
<utlemming> stgraber: ack and thank you
<stgraber> utlemming: my guess is that there's some kind of limit in the number of team membership we can retrieve from LP and as the tracker is asking for a dozen or so, we may be hitting that limit
<knome> stgraber, xubuntu amd64 upgrades are done. and you probably want to look at bug 1155167
<ubot2> Launchpad bug 1155167 in ubiquity (Ubuntu) "Upgrade from image prompts creating a new user" [Undecided,Confirmed] https://launchpad.net/bugs/1155167
<stgraber> knome: do you know where you'll be posting the beta1 announcement?
<stgraber> Riddell, ScottK, zequence, utlemming: you too ^ (I only have the URLs for edubuntu and kylin at the moment)
<knome> stgraber, i'll get that to you in the next 15 minutes (i'll need to write one first)
<stgraber> knome: ok
<utlemming> stgraber: B1 annoucnements for cloud images will not be happen. They are silent releases as a data-point for reference.
<stgraber> utlemming: ok
<smartboyhw> stgraber, I will try to draft up one...
<smartboyhw> zequence is bb for a couple of hours
<JackYu> stgraber:  we prepare a simple notes for ubuntukylin: https://wiki.ubuntu.com/UbuntuKylin/1304-beta-1-ReleaseNote
<Riddell> stgraber: voila https://wiki.kubuntu.org/RaringRingtail/Beta1/Kubuntu
<stgraber> Riddell: thanks
<smartboyhw> stgraber, release notes: https://wiki.ubuntu.com/RaringRingtail/Beta1/UbuntuStudio Annoucement: http://ubuntustudio.org/2013/03/ubuntu-studio-13-04-beta-1-released/
<utlemming> stgraber: I mis-spoke. I'll get the URL for you shortly
<stgraber> utlemming: ok
<stgraber> smartboyhw: thanks
<ScottK> Sigh.
<ScottK> I guess when we said we were going to be strict about FFe approval because we moved feature freeze later, no one really believed us.
<Laney> The message will get through
<tumbleweed> the excuses have been amusing
<tumbleweed> apparently 2 days of vUDS delayed everyone by a week
<stgraber> yeah, I'm really annoyed by it... we warned them and we moved the FF to allow for more dev time, so allowing any big feature to land now is more dangerous than ever...
<stgraber> tumbleweed: or more, look at the Unity one, it's a whole month for them :)
<ScottK> Personally, it appears to me that everyone assumed Rick's proposal would be approved and started operating to it.
<tumbleweed> stgraber: yeah. and of course they should have been aiming for 2 weeks before FF anyway :P
<knome> stgraber, will there some other url or is http://cdimage.ubuntu.com/xubuntu/daily-live/20130311.1/ the "official" beta link?
<smartboyhw> cdimage.ubuntu.com/xubuntu/releases/13.04/beta-1 I think
<stgraber> right, after publishing the images will be under releases/13.04/...
<knome> ok! :)
<cjwatson> knome: yes, never permanently link to .../daily-live/DATE/, they get removed after a few days!
<knome> cjwatson, yeah, sure. thanks :)
<stgraber> do we have anyone from Lubuntu around here?
<smartboyhw> stgraber, Lubuntu -> phillw
<stgraber> phillw: hey, do you have an URL to the beta1 announcement for Lubuntu?
<stgraber> phillw: also, do you have any product that should be marked as ready for release now?
<smartboyhw> phillw, you do know that Beta 1 is to be released in 1.5 HOURS not 24!?
<phillw> stgraber: soz, been afk.
<phillw> I thought deadline was tomorrow. let me have a look
<stgraber> ??? we've always been releasing on Thursday
<smartboyhw> ...
<Laney> did "Status tracked in Raring" go away?
<phillw> stgraber: just me having a 'blonde' moment... My days are a bit messed up this week :D
<xnox> phillw: Thursday UTC time has always been the case. As releasing on Friday is impractical as it's the weekend for many people on the east side towards datetime line.
<smartboyhw> phillw, now you really need testers:P
<TheLordOfTime> smartboyhw, you should consider NOT crossposting the "we need testers!" thing across multiple channels
<phillw> stgraber: I'm happy with: Alternate AMD64, Alternate i386, Desktop AMD64, Desktop PPC
<phillw> the others can stay as daily spin (i.e. no beta 1 release).
<knome> stgraber, xubuntu b1 release annoucement will be at http://xubuntu.org/news/raring-beta1
<knome> stgraber, will there be a "general" wiki page as usually?
<smartboyhw> TheLordOfTime, the one in this channel is targetted "only" to phillw
<smartboyhw> That one is to everyone
<stgraber> knome: I don't think we had a general wiki page for the past two opt-in milestones so I'm not planning on making one.
<utlemming> stgraber: https://wiki.ubuntu.com/RaringRingtail/Beta1/UbuntuCloudImages
<stgraber> knome: I'll prepare a standard announcement and have it go to the usual mailing-lists, get it picked up on fridge/planet ubuntu and release blog
<knome> stgraber, ok, thanks fine :) just checking if i need to point to some place
<stgraber> utlemming: thanks
<stgraber> who marked Kylin ready?
<smartboyhw> stgraber, that's the question...
<stgraber> because it clearly isn't, they haven't got the respin yet
<smartboyhw> I and JackYu are mystified
<stgraber> balloons: why did you mark UbuntuKylin as ready?
<smartboyhw> balloons, .....
 * stgraber marks them for respin
<JackYu> yes, we need the respin:)
<stgraber> yeah, waiting for your new packages to get copied, that should happen this publisher run, then they should be ready in the next, then we can respin
<stgraber> hmm, hold on, there's something weird going on with britney
<cjwatson> oh?
<smartboyhw> uh oh
<stgraber> cjwatson: the report was last updated at 14:06
<cjwatson> one moment
<cjwatson> stgraber: you need versions on your unblocks
<cjwatson> its failure mode is entertainingly terrible if you forget those
<stgraber> oops, fixing...
<JackYu> oh...
<cjwatson> tell me when and I'll rerun manually
<stgraber> fixed
<cjwatson> running
<cjwatson> logs are in lillypilly:~ubuntu-archive/proposed-migration/log/ for the record
<cjwatson> I should get round to making those web-accessible too
<stgraber> cjwatson: ah, good to know. I should have looked at the timestamp earlier and notice that I messed up something in my hints
<cjwatson> stgraber: all three copied; you just need to wait for the publisher now
<stgraber> cjwatson: perfect, thanks
<stgraber> JackYu: I'll trigger your rebuild in the next 30min (as soon as the publisher is done)
<JackYu> sure, thank you. We're waiting for it.
<knome> stgraber, when you release, will you also ping pleia2? thanks.
<knome> stgraber, i got to run now. thanks for everything! :)
<stgraber> knome: ok, will do. bye
<JackYu> stgraber: seems all 3 packages are ready
<stgraber> no
<stgraber> they've been copied but not published yet
<stgraber> should happen any minute though
<JackYu> i see
<JackYu> BTW, could you set our release team the rights:)
<stgraber> it takes time and I'm busy trying to get this thing out, so not now
<JackYu> sure, it's ok
<stgraber> ScottK, Riddell, highvoltage, phillw, zequence, knome, pleia2, JackYu, utlemming: Draft of the announcement: http://pad.ubuntu.com/raring-beta1-announcement
<ScottK> stgraber: I marked on it a bit.  Seems good.
<highvoltage> stgraber: what will the URL for that be?
<highvoltage> (would like to link to it)
<stgraber> highvoltage: some URL under lists.ubuntu.com. That's an e-mail announcement
<highvoltage> ok
<highvoltage> stgraber: are you also taking care of moving the cd image to the right place on the cdimage host?
<JackYu> stgraber: it's pretty. thank you.
<zequence> stgraber: Looks good to me, thanks
<stgraber> highvoltage: yep, once kylin has been respun, tested and is ready to get published
<Riddell> it's ready!
<stgraber> JackYu: respin in progress for kylin
<JackYu> nice
<highvoltage> Riddell: ^5
<phillw> stgraber: I have only just started on a draft for lubuntu beta 1, it will be completed today if you want me to add the link into the etherpad and mark the page up as 'Still in Progress'?
<yofel> Riddell: you can mark our upgrades as ready too if it matters
<pleia2> stgraber: thanks, just made a tiny edit to xubuntu url
<stgraber> JackYu: the build failed
<pleia2> oops, no it was correct
 * pleia2 coffee now
<JackYu> oh, may i take a look the log?
<stgraber> P: Begin executing hooks...
<stgraber> ./config/hooks/100-default-language.binary: 3: ./config/hooks/100-default-language.binary: cannot create binary/isolinux/lang: Directory nonexistent
<stgraber> E: config/hooks/100-default-language.binary failed (exit non-zero). You should check for errors.
<stgraber> P: Begin unmounting filesystems...
<Laney> sounds like https://launchpadlibrarian.net/134156070/livecd-rootfs_2.112_2.113.diff.gz
<stgraber> yep
<stgraber> apparently we are missing livecd-rootfs in the block list...
<stgraber> cjwatson: ^
<JackYu> yes, if that's the problem, please remove it.
<cjwatson> stgraber: https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview - skeleton draft
<cjwatson> JackYu: removing it isn't the answer - I'll fix it
<cjwatson> (unless you think having no build script is better!)
<JackYu> nice, thanks:)
<stgraber> JackYu: how long will it take you to test the images once you have them?
<cjwatson> hmm - of course I will have to *revert* that because I was stupid.  this should never have been done in livecd-rootfs in the first place
<JackYu> ten minutes
<cjwatson> belongs in cdimage/debian-cd
 * cjwatson <- idiot
<stgraber> JackYu: ok. I'll wait till 19:00 UTC then release whatever is ready at the time. I'm not willing to delay beta1 any more than that.
<JackYu> stgraber: OK
 * ogra_ points cjwatson to the code of conduct ... we dont call people idiots in here 
<ogra_> :)
<highvoltage> ScottK: heh, I also don't think it's very polite to change a bug status if you're not a release manager on a release bug
<JackYu> cjwatson: thanks.
<Riddell> yofel: oops I removed them instead, la la
<stgraber> Riddell: I'll fix that
<cjwatson> ogra_: if I'm offended I shall complain about myself :)
<JackYu> cjwatson: is the build restarted?
<stgraber> JackYu: it'll take an hour or so
<JackYu> oh...
<stgraber> as cjwatson needs to revert the change in livecd-rootfs, upload it, wait for it to build, get copied, published, ... then do the change in debian-cd, push that to nusakan and finally respin
<cjwatson> I've done all my side of it now
<cjwatson> But indeed it needs to build/publish/copy/publish
<JackYu> ou, huge work, thanks a lot:)
<JackYu>  so maclin and I may sleep a while. it's 1am here but we are excited for our beta-1.
<stgraber> cjwatson: http://paste.ubuntu.com/5614141/ (not quite worth a MP)
<stgraber> JackYu: well, you can sleep for an hour or so if you want, but after that you'll have to start testing ;)
<Laney> |-gnome?
<cjwatson> stgraber: committed, thanks
<cjwatson> and Laney is right, I'll take care of that
<JackYu> it's fine. i will wait here
<cjwatson> space gnome in this case I think since it's for the iso tracker
<stgraber> yeah, I think it'll be " gnome" on the tracker
<cjwatson> done
<Laney> ah
<stgraber> we really need some automation for the milestone archiving part of the process :)
 * stgraber disables sync-mirrors on nusakan and starts the archival of previous milestones
<stgraber> cjwatson: hmm, my memory is failing me here. Do we archive the old alphas or just wipe them from disk?
<cjwatson> archive
<cjwatson> /srv/cdimage.ubuntu.com/old-images IIRC
<stgraber> cjwatson: ah yeah, here they are (I was looking for the raring alpha-1 images in www/ but forgot that we move them to the tape backup and not to something publicly visible)
<stgraber> alright, starting to move things around then
 * xnox looks at libnih migrating into raring-release, while the rest of $base stuff seems to be under a block
<stgraber> yeah, it was missing in the blocks
<cjwatson> xnox: lvm2> done
<xnox> cjwatson: thanks. I shall have my hwe lvm2 upload soonish =)
<stgraber> I added livecd-rootfs and libnih in the blocks. I'll push the change once livecd-rootfs is done migrating
<xnox> cjwatson: can you please _reject_ this one https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=lvm2 ? i'll be uploading a different one shortly.
<cjwatson> xnox: ok, done
<xnox> thanks.
<ScottK> highvoltage: I think it was just a misunderstanding.
<blitzkrieg3> hi, would someone on the sru team please take a look at bug 445872
<ubot2> Launchpad bug 445872 in OEM Priority Project precise "disable-disconnect-notification option ignored" [High,In progress] https://launchpad.net/bugs/445872
<blitzkrieg3> it was blocked by the update to 780602 forever and so users have been waiting a long time for the fix
 * xnox is not happy =(
 * ogra_ comforts xnox 
 * Laney hugs xnox
<Laney> there, there
 * xnox was hoping for Laney to hand out an FFe
<Laney> we did say at UDS ...
<xnox> Laney: i do want to merge the code with feature turned off though, to avoid bit rot.
<Laney> can't you branch for raring and continue developing on trunk?
<xnox> it's a non-lts, we only branch out lts for ubiquity as those are the only onces that get updates for point releases.
<JackYu> cjwatson: how long left?
<xnox> Laney: we preffer the trunk to stay for current dev release / bugfixes for release.
<stgraber> JackYu: I should be able to start the respin in the next 30min (waiting for last publisher run)
<JackYu> ok
<highvoltage> stgraber: I might disappear soon but most things are pretty much sorted out afaict, if I'm away and you publish on the website, remember to check the timestamp, I think sometimes it doesn't get updated then edubuntu shows up way last on planet :)
<stgraber> highvoltage: yeah, I usually wipe the date field which resets it to posting time
<knome> highvoltage, what's wrong with being the last? :)
<stgraber> highvoltage: I'm still planning to release in an hour, I have everything good to go here, just waiting for Kylin
<cjwatson> JackYu: please coordinate with stgraber rather than me, since he's running this beta and I'm about to finish for the day
<JackYu> sorry for that:)
<cjwatson> JackYu: meh, it was my fault ...
<highvoltage> knome: well, we like being /first/ on planet for releases, but when we do it's not nice that it's already 20 posts behind :)
<JackYu> sure.
 * knome sets the publish time very much later than edubuntu's ;)
<highvoltage> that's cheating!
<stgraber> JackYu: rebuild started
<JackYu> how long it takes?
<stgraber> JackYu: 15min is my guess
<JackYu> sure:)
<stgraber> maybe 20, not sure as the last one failed I didn't get the exact timing
<cjwatson> More like 15 I think
<JackYu> ok. hope in 15 min
 * infinity tries to sort out what our rationale was for having Beta1 and Beta2 be only two weeks apart, and curses this messing with his need to book a vacation between not and the end of March.
<infinity> s/not/now/
<slangasek> hrrmmm, I thought there had been discussion about fixing that spacing
<slangasek> did that not get acted on?
<infinity> I thought so too.
<infinity> Was that in email?
<slangasek> maybe?
<Laney> wasn't on the release list
<slangasek> yeah, it wasn't
<infinity> Message-ID: <CAF-=TbDhABZV2Yw39SgbNs0nq458wW0reeZtbjdu3opFe+33kQ@mail.gmail.com>
<infinity> Pete said he'd fix it and forgot.  I'll just do that now. :P
<slangasek> ScottK had emailed me about it and I forwarded it on to pgraner
 * jokerdino waves to infinity. :>
<slangasek> consensus was that there was no good reason for the current spacing
<JackYu> great!
<infinity> slangasek: That look more like what we discussed?
<stgraber> JackYu: ^ I'll extend what I said earlier and will wait till 19:30, so that leaves you 40min to test it all and get back to me
<infinity> slangasek: Of course, that bumps into the part where many people are away over a 4-day long weekend leading up to that, but meh.
<infinity> (me included)
<slangasek> infinity: ScottK had proposed final beta "two weeks before release"; three weeks is also ok by me; 4 weeks is definitely too long
<infinity> slangasek: 3 weeks is what we had in that email thread, as suggested by you. :P
<slangasek> infinity: this change probably needs to be announced, since the schedule of record is changing so late; can you send something to ubuntu-devel-announce?
<JackYu> stgraber: thanks
<infinity> slangasek: I'm not against it being a week later either.
<slangasek> infinity: I'm not finding that part of the thread in my own mailbox, and as I said "three weeks is also ok by me" :)
<infinity> slangasek: But betas have been pretty lightweight so far, the long weekend probably won't hurt it any.
 * infinity just about sent that to ubuntu-devel-announce@lists.debian.org ...
<maclin> Thanks stgraber.
<infinity> Stupid finger autocomplete.
<slangasek> infinity: don't forget to pgp sign the mail, and send it from your whitelisted ubuntu.com address
<infinity> slangasek: Everything to UDA needs to be signed?  SRSLY?
<infinity> (I moderate the list, I can post whatever I want...)
<slangasek> infinity: no, only things sent to ubuntu-devel-announce@lists.debian.org
<infinity> slangasek: Oh, right. :P
<infinity> slangasek: Announce sent and moderated.
<slangasek> infinity: cheers!
<infinity> And now I get to have a holiday the week before.  \o/
<infinity> Which I'd planned all along, but forgot about the schedule. :P
<jbicha> infinity: yay! I just realized yesterday that I was going to be completely swamped Wed & Thurs at the end of the month with POSSCON so the extra week helps :)
<JackYu> stgraber: we have tested this build. We think It's ready for release.
<ypwong> JackYu, yay
<JackYu> stgraber: please mark it to be ready. Is there any other thing we should do?
<stgraber> JackYu: ok
<stgraber> alright, starting to publish now. Will send the announcement in around 30min
<ypwong> stgraber, cool, thanks a lot for helping our first release today
<stgraber> np
<JackYu> good job, thank you.
<stgraber> cjwatson, infinity: hmm, the usual "cp -al www www.prev" gave me a bunch of operation not permitted this time around (for some old stuff)
<stgraber> http://paste.ubuntu.com/5614554/
<stgraber> I'm continuing the publishing anyway, but I'm wondering what happened there as I can't remember seeing this last I did it
<stgraber> Riddell, ScottK: you are aware that your kubuntu active image is oversized right?
<stgraber> phillw: same for Lubuntu desktop powerpc
<stgraber> JackYu: and UbuntuKylin
<phillw> stgraber: hmm, I'll put it into the release notes. I know Julien had mentioned that it seems to be a ppc-kernel issue (possibly more than one on the build list).
<stgraber> phillw: ok
<stgraber> cjwatson: could it be that the rewrite of post-qa (being moved to the python cdimage) broke the oversizedness test? as far as I can tell, none of the oversized images were flagged as such on the tracker
<JackYu> stgraber: i see. will do as phillw.
<stgraber> JackYu: ok
<stgraber> Riddell, ScottK: just waiting on your go/no-go for the oversized active before triggering the mirror sync
<phillw> stgraber: I'm a little perplexed, we *used* to get a notice warning if an ISO was over size at http://iso.qa.ubuntu.com/qatracker/milestones/261/builds/39543/testcases
<phillw> was this dropped when the new Notice Board went live?
<phillw> something like "warning this ISO is oversized, this should never happen for a milestone ISO"
<bdmurray> slangasek, infinity: shouldn't a SRU be done for Q and P not just P? bug 1020317
<ubot2> Launchpad bug 1020317 in telepathy-gabble (Ubuntu Precise) "telepathy-gabble crashed with SIGSEGV in tp_base_channel_close()" [High,In progress] https://launchpad.net/bugs/1020317
<slangasek> bdmurray: our standard SRU policy says it should; I'm of the opinion that we need to revisit this policy however, in connection with the discussion about reducing our support length for 6-monthly releases
<stgraber> phillw: did you see what I told cjwatson 10 minutes ago?
<phillw> stgraber: soz, I'll scroll back, I'm in PM with someone and prepping up my server to accept ubuntu kylin :)
<slangasek> bdmurray: I guess we really ought to do that revisiting rather than just dropping quantal on the floor, though...
<bdmurray> I'm also of the opinion that most P -> Q upgrades have already happened
<slangasek> right, exactly
<stgraber> Riddell, ScottK: based on Riddell's comment on the tracker "it's a tech preview", I'm going ahead with publishing of the oversized kubuntu active
<ScottK> stgraber: That should be fine.
<phillw> stgraber: Ahh, sorry, I see it now :)
<stgraber> alright, publishing done, mirrors syncing now
<stgraber> will wait for rsync to finish, make sure the pages look good, then will send the announcement
<bdmurray> slangasek: what is the next step?
<slangasek> bdmurray: well, we should have the discussion on a public mailing list - probably ubuntu-release ? - about changing SRU policy
<slangasek> bdmurray: I don't know what to do with the SRU in the meantime; I don't think it makes sense to go back to the SRUer and demand a quantal upload if we think it's going to be superseded by a policy change
<bdmurray> well we could let into -proposed while the discussion happens
<slangasek> yep
<infinity> slangasek: I don't think the intent was to drop the support lifetime for Q, was it?  We've already somewhat committed to that being 18mo.
<infinity> (That said, I stil think it's not a good use of time to SRU every bug to P and Q, only the most critically broken regressions)
<slangasek> infinity: not drop the support lifetime, but if we recognize that the normal expected cycle is that users on the 6-month releases upgrade soon after release, and our justification for SRUing to the 6-month releases when we SRU to the LTS is so that they don't get regressions when upgrading, it doesn't seem a good use of time to require Q SRUs for every P SRU
<slangasek> security support for Q is still at 18mo
<infinity> slangasek: Ahh, yes.  I think we're on the same page there.
<infinity> slangasek: Though, I'd suggest our 18mo (or 7mo, down the road) support lifetime should include both security and *critical* SRUs.
<infinity> slangasek: The key being "critical"
<infinity> slangasek: While lots of what we do for an LTS is polish and perfection, not critical sky-is-falling fixes.
<slangasek> sure
<infinity> Anyhow, given that we're basically agreeing using different words, and we're both sensible and clever people (*cough*), I suspect there won't be much argument or even discussion if we propose a formalisation of a "no non-critical fixes after the next release ships" policy.
<infinity> Given that, informally, a lot of people basically do that already anyway.
<infinity> Certainly they do for LTS->LTS scenarios, where they'll fix precise, but not lucid and hardy.
<infinity> Etc.
<slangasek> well, this is somewhat the other way around where we're saying "fix precise and raring but not quantal"
<slangasek> anyway, to the list
<infinity> It's still the same thing.  You're just saying "fix the latest LTS and the latest non-LTS, but none of the older ones", instead of just "only the latest LTS", that's all.
<infinity> ie: track the two "tips".
<stgraber> yay, rsync finally finished!
<stgraber> and everything appears to be there. Sending the e-mail now
<stgraber> pleia2: please publish http://xubuntu.org/news/raring-beta1
<pleia2> stgraber: done, thanks
<stgraber> cjwatson: please moderate my e-mail to ubuntu-devel-announce
<infinity> stgraber: Done.
<stgraber> infinity: thanks. Good to know you're also a moderator, gives better timezone coverage (with both of you covering 80% of the available timezones ;))
<infinity> stgraber: More like 160%.
<stgraber> infinity: do you also have the credentials for http://release-blog.ubuntu.com by any chance? (I wonder whether we shouldn't just kill that blog...)
<pleia2> fwiw, currently I x-post the announcement to fridge.ubuntu.com (working on that now)
<stgraber> pleia2: right, I think that's enough to poke someon to take the ML announcement et post it to the fridge, instead of having yet another blog just so that the announcement shows up on planet
 * pleia2 nods
<stgraber> beta1 freeze lifted
<stgraber> Laney, tumbleweed: can I remove your two b1-specific hints too?
<stgraber> 3 actually, shotwell, nautilus and gnome-control-center
<slangasek> infinity, stgraber: so the beta1 release announcement went out with the now-obsolete final beta date; fwiw :)
<tumbleweed> stgraber: sure
<stgraber> slangasek: oops :) as it's the same mailing-list, we can hope the readers will have seen Adam's e-mail :)
<infinity> Ahh, I missed that when I read it.  Oops.
<xnox> slangasek: should hwe sru's be ever done for non-lts releases, or it is ok to do that in lts & current-dev?
<slangasek> xnox: well, certainly if it's install-critical hwe, it doesn't make sense to do a non-lts sru
<xnox> slangasek: cause even 7month support cycle implies - lts, current-stable, dev-release. (which is a big improvement), but I'd rather see 7month security support, and only 1 month SRU support (aka 0day SRU and a bit)
<infinity> xnox: Define "hwe".  The kernel team occasionally enables/fixes drivers and such as part of the normal kernel SRU cadence, but we certainly don't go above or beyond that for non-LTSes.
<slangasek> xnox: "support cycle" does not imply "everything we SRU to the LTS in this period is also SRUed to LTS+1"
<infinity> xnox: If we expect "normal" users to not be using the dev release (and that's true right now), cutting off all but security support before the next release is out is probably a bit harsh.
<infinity> But it's a case-by-case thing.  I think the threshold should be different for LTS and not.
<infinity> Critical is critical for all of them.
<infinity> Certain cosmetic bugs and whatnot, it's not world-ending if they regress from LTS to non-LTS, as long as they're fixed in devel, so it's not a permanent regression.
<xnox> slangasek: infinity: I guess from my point of view, I need a clear regression policy between LTS->LTS and LTS->in-betweeny.
<slangasek> I don't think "cosmetic" is the right word since a cosmetic fix wouldn't be an SRU candidate, but yes.
<infinity> Clear policies don't work.  This is very much a common-sense + ask-if-unsure type thing.
<infinity> Because every bug is different, and I can't tell you in advance what yours is.
<xnox> bug 1122445
<ubot2> Launchpad bug 1122445 in lvm2 (Ubuntu) "Update device_types in lvm2 filters to support Micron PCIe SSD, among many others" [High,In progress] https://launchpad.net/bugs/1122445
<xnox> fixed in raring, pending britney migration.
<xnox> Should it be SRUed into precise only, or precise/quantal?
<xnox> those new devices can be enabled manually in /etc/lvm/lvm.conf but I want to see support out of the box for Micron PCIe SSD, FusioIO cards and etc in precise 12.04.3
<xnox> (that is LVM VGs on those devices)
<infinity> Yeah, I don't see that as critical to Q.  I doubt I'd reject it if you uploaded it, but I also wouldn't demand a Q fix if you only uploaded P.
<slangasek> xnox: if this is enabled in 12.04.3, and a user puts their rootfs on one of these devices, then upgrades to quantal, what happens?
<slangasek> (if Q doesn't have the fix)
<infinity> There's also that, yes.
<infinity> That could make it critical. :P
<xnox> slangasek: they will for example fail to boot / bring up expected mount-points and have to vgscan by hand, twiddle with /etc/lvm/lvm.conf from booted machine or most likely from initramfs/busybox.
<cjohnston> If the only feature added to the new version of python-django-auth-openid is to make it work with python-django 1.4 (what is in raring), does that make it a feature which needs a FFe or does that make it a bug fix?
<slangasek> cjohnston: bugfix
<infinity> cjohnston: Bugfix, assuming it's not an intrusive change that modifies behaviour (intentionally or otherwise).
<xnox> cjohnston: I hope "make it work with python-django 1.4" is not an obscure way to say "ported to python 3" ?
<xnox> since django 1.4 is the first one to have python3 support?! or did I get that version number wrong?
<cjohnston> no xnox
<cjohnston> 1.5 semi has python3 support is my understanding.. it fixes tests/updates things to work with 1.4 correctly.. still maintains support for the same previous versions of python-django as well
<xnox> cjohnston: fair enough =)
<stgraber> tracker updated, cronjobs restored, we're all done with beta1 now
<phillw> thanks everyone :) And I'll ensure I do not lose track of the day of the week for beta 2 :)
<knome> stgraber, now that you got rid of beta1 business, do you have a new upload and the update of translation strings scheduled for ubiquity slideshows?
<xnox> Laney: are you still blocking systemd due to lack of testing or due to RC bug?
<stgraber> knome: yeah, I'll make sure to upload before UI freeze
<knome> stgraber, good, thanks :)
<ScottK> xnox: rc bug.
<xnox> ScottK: hmmm reference? /me thought it was fixed already.
<ScottK> Dunno.
<ScottK> Maybe he just dropped it.
<ScottK> err forgot to drop it.
<xnox> Looking at https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/laney just "pitti" doesn't explain it all =)
<ScottK> pitti asked for the block due to an issue.
#ubuntu-release 2013-03-15
<slangasek> Laney, xnox, ScottK: the systemd RC bug is resolved now (bug #1154813)
<ubot2> Launchpad bug 1154813 in initramfs-tools (Ubuntu) "Boot broken with initramfs-tools 0.103ubuntu0.5b1 - wait-for-root doesn't wait" [Critical,Fix released] https://launchpad.net/bugs/1154813
<xnox> slangasek: I also noticed pitti's comment on the FFe "block is in place until after beta1 is shipped"
 * xnox would like the block lifted, but I guess Laney/pitti should be lifting it.
<xnox> 38 packages held.
<xnox> Laney: wasn't chromium-browser was supposed to be let through even without up to date armhf build?!
<ScottK> slangasek: OK.  At this point I'm not sure I want to be the one that let libudev1 into raring on Friday, so I'll wait for Laney to remove the block.
<infinity> xnox: chromium-browser isn't being held up because of armhf.
<tumbleweed> aah, unity was sabdfl'ed
<jamespage> Daviey, we need to push a point release of python-quantumclient to raring for the upcoming rc's of openstack core projects
<jamespage> 2.1.2 -> 2.2.0
<jamespage> we have been using this in the CI lab for some time  - I've also been testing with trunk of everything for the last four days and I've seen no issues with the new client version
<jamespage> Daviey, do we need a FFe?
<Daviey> jamespage: is 2.1.2 not compatible ?!
<Daviey> jamespage: Compatibility aside, before the client broke out - we'd have tracked it to final.. so 2.2.0 is the version we should be carrying.  I think you should proceed.
<jamespage> Daviey, it does not have support for newer bits and pieces in quantum that landed since 2.1.2
<jamespage> Daviey, ack
<Laney> xnox: repeated pinging at 02:20 isn't likely to get it done
<Laney> it was a block for pitti so I was waiting for pitti to ask me to lift it himself, which came this morning
<xnox> Laney: ack. \o/ yeah, stuff I care about has migrated ;-)
<cjwatson> stgraber: I fixed up ownership of various files, which was the source of your 'cp -al www www.prev' problem; not sure why that didn't happen last time
<cjwatson> stgraber: I *thought* I'd preserved the oversizedness note; I don't have a specific test case for it, though, so I'll look into that
<cjwatson> slangasek: So I wrote in https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview that people need to upgrade to 12.10 first, and this was largely just from inertia; do we want to declare that you can upgrade directly from 12.04 LTS, to avoid encouraging further upgrades via 12.10?
<seb128> cjwatson, don't we only support LTS to LTS+1 et <n> to <n+1>?
<seb128> et->and
<seb128> cjwatson, e.g do we do any testing for 12.04->13.04?
<cjwatson> Well, sure, right now, but we can't continue that practice if we're going to be de-emphasising non-LTS releases
<cjwatson> jibel: ^- How hard would it be to set up precise-to-raring upgrade tests in jenkins?  I don't see any right now
<jibel> We don't test this ATM, but it shouldn't be hard if it is supported by the upgrader. I'll have a look.
<infinity> cjwatson: Given that we need to support 12.04->14.04 anyway, I think it's the Right Thing to always make sure that we support LTS->current, it makes our jobs MUCH easier when prepping the next LTS if we haven't been ignoring it for two years.
<infinity> cjwatson: So, I'm all in favour of a QA and culture shift there.
<cjwatson> That was much my thought
<cjwatson> It's in our interest regardless of any release cycle changes; and it should be in users' interests
<infinity> *nod*
<cjwatson> jibel: Also, has the Content-Type of jenkins autopkgtest logs changed, or something?  e.g. when I try to view logs from https://jenkins.qa.ubuntu.com/view/Raring/view/All/job/raring-adt-bzr/ARCH=i386,label=adt/ in firefox, I now get told that it's a "BIN file" and I only have the choice to cancel or save to disk, which is rather less convenient than it showing up as text in my browser
<infinity> cjwatson: Not that it changes the fact that jenkins is spewing bogus headers and should be fixed, but you really want http://spasche.net/openinbrowser/
<infinity> cjwatson: It's made my life so much more pleasant.
<cjwatson> ah, cool
<cjwatson> thanks :)
<jibel> cjwatson, it didn't change AFAIK, when did you notice this change?
<cjwatson> jibel: I haven't looked at autopkgtest output for *ages* until today
<cjwatson> So just today, but that doesn't tell you much
<Laney> I've noticed that behaviour for a long time
<infinity> It could be that the Content-Type never changed, but Fifefox got stricter about how it deals with it.
<cjwatson> Or I guess it could be that my new laptop has a different browser configuration somehow (though I did sync over my profile
<cjwatson> )
<jamespage> please can an someone reject d2to1 from precise-proposed - forgot to add the ppa target to the upload
<jamespage> doh!
<cjwatson> jamespage: done
<jamespage> cjwatson: ta
<jamespage> Daviey, I also need to upgrade python-django-compressor to 1.2 to fixup horizon with firefox (see bug 1130610)
<ubot2> Launchpad bug 1130610 in python-django-compressor (Ubuntu Raring) ""SyntaxError: invalid increment operand" when parsing JavaScript using Firefox" [High,In progress] https://launchpad.net/bugs/1130610
<jamespage> 1.1.2 -> 1.2
<jamespage> I confirmed it fixes the issue; only rdepends is horizon
<cjwatson> stgraber: Well, I'm confused.  The oversized handling looks right and I even just added a test for it.  Where's it supposed to show up on iso.qa?
<cjwatson> stgraber: Ah, wait, it's broken for non-Ubuntu flavours
<cjwatson> stgraber: Fixed, with a better test case - thanks for the report
<Daviey> jamespage: Nothing else uses this, and 1.2 seems to have had more upstream exposure to this, please carry on.
<jamespage> Daviey, ack
<Daviey> jamespage: surprised it's still not in debian?
<jamespage> Daviey, I suspect its in the experimental new queue
<Daviey> ah, yes.
<jamespage> Daviey, yeah - its in git.debian.org but not accepted
<stgraber> cjwatson: thanks for tracking the bug down and fixing!
<stgraber> cjwatson, infinity: who's our webteam contact? I've had multiple reports that we ought to update http://www.ubuntu.com/testing
<infinity> stgraber: That's a good question that I'm not sure I have the answer to.
<infinity> I also didn't know that page existed until today...
<stgraber> infinity: I pinged #web-team on the internal IRC, hopefully someone will react
<stgraber> infinity: the link was added in the announcement "template" since alpha-2 apparently
<infinity> stgraber: If all else fails, bugging Peter Mahnke might get it done.  But I'm not sure who we're "supposed" to bug.
<infinity> stgraber: But, ideally, everything after "Thank you" should probably just be removed, so it can remain static content.
<infinity> stgraber: And the wiki updated with whatever bits we think it should have.
<stgraber> infinity: yeah, I tried to ping Peter first (per Daviey's suggestion) but he appears to be offline at the moment. Anyway, I agree that the list of releases isn't terribly useful and we could probably just have that removed and keep the page static.
<cjwatson> stgraber: I think Peter and/or that channel is correct
<infinity> cjwatson: Hrm.  Seems like a misfeature on britney's part that it cares about outdates for an arch that's already outdated.
<infinity> (Though, maybe I should just put some time in today to fix chromium-browser on ARM instead of continuing to fudge it)
<cjwatson> Possibly, yeah
<cjwatson> (On both counts :) )
<cjwatson> NOTE: I'm changing the buildlive interface to be a bit more standard in cdimage terms, so the project and series should now be passed in through the environment (e.g. DIST=precise for-project ubuntu buildlive daily-live')
<cjwatson> I've also made most of cron.* have --live options, so normally, you can just adjust expectations as follows:
<cjwatson> -31 7 * * *     buildlive ubuntu daily-live && for-project ubuntu cron.daily-live
<cjwatson> +31 7 * * *     for-project ubuntu cron.daily-live --live
<cjwatson> Some of the odder builds (wubi, livecd-base, core, chinese-edition) still call buildlive directly in crontab
<infinity> I wonder if there's still any value in livecd-base.
<cjwatson> This also means that you don't have to remember about cases where the livecd-rootfs project is called *-dvd, so the direct buildlive call for Edubuntu would go from 'buildlive edubuntu-dvd dvd' to 'for-project edubuntu buildlive dvd'
<infinity> It used to really just be a good, quick "is the machinery working as expected?" test, but core does that just as well.
<cjwatson> And it means that buildlive is now in the public cdimage branch at long last
<cjwatson> infinity: Originally, it was a request from lamont (but of more general utility) to provide a squashfs base for customisation
<cjwatson> I don't know whether core is just as good for that; maybe it is
<infinity> Yeah, I know what it was *originally*, but I doubt anyone uses it for that.
<infinity> I could be wrong, though.
<infinity> It's not like it eats a ton of resources.
 * infinity shrugs.
<lamont> I'd be happy with core
<infinity> cjwatson: So, I notice that, like me, you've avoided NEWing libgmpada, I assume for the same reason (-dev seemed to bump SOVER, but library package didn't, WTF?)
<infinity> cjwatson: Were you chasing that up with the Debian maintainer(s) at all?  Should I?
<cjwatson> livecd-base> Yeah, it's a little hard to say
<cjwatson> infinity: I hadn't put any thought into it, actually :)
<cjwatson> I tend to routinely NEW anything that new-binary-debian-universe supports - anything else rather less frequently
<infinity> cjwatson: Ahh, I just assumed you were avoiding it intentionally, since you seem to do a lot of binNEW batch processing (as do I).
<cjwatson> So I haven't chased it up at all
<infinity> Let me have a poke at the actual contents of those binaries to see WTF is up.
<cjwatson> The -dev does look weird
<infinity> Cause the weird bump on -dev but not lib is confusion.
<infinity> confusing, too.
<infinity> It's not the first one, either.  The previous version had lib2 and lib3-dev :P
<infinity> I think the Debian maintainer may be very confused about libraries.
<infinity> cjwatson: So, that bizarre -dev package version comes from Debian ADA policy.  It's doesn't relate to the ABI of the library at all, but some magic ADA-only API rev.
<infinity> cjwatson: Vomitously icky, and I wish I hadn't read it.  At least working on chromium will now seem like an improvement on my day.
<cjwatson> How bizarre.  Fortunately I have managed to avoid ada.
<slangasek> cjwatson: good question.  Will the upgrade machinery *allow* us to upgrade users from 12.04 to 13.04?
<infinity> slangasek: We can make it allow us.  I think the original point was in making sure it's possible, however.
<infinity> slangasek: Or, rather, that it doesn't break when attempted.
<ScottK> For Kubuntu, we supported upgrades from 8.04 -> 8.10, 8.04 -> 9.04, 8.04 -> 9.10, and 8.04 -> 10.04 because the early KDE4 releases were so rough.  It wasn't that difficult to do.
<ScottK> Mostly it was just added upgrade testing.
<infinity> Indeed.
<ScottK> infinity: Someone should reply to the TB thread proposing this be part of the new release model ....
<infinity> And as Colin and I were both agreeing on last night, even if we weren't changing support cycles, making sure LTS->current works is always a good thing anyway, so we don't have that sille LTS->LTS "hey, nothing works" panic due to people ignoring upgrade paths for 18-24 months in between.
<ScottK> Yeah.
 * infinity doesn't read the TB list, but is positive that he and Colin are very much on the same page here, and Colin's on the TB, so...
<ScottK> It also gives a way out in the new model for someone who's on LTS and a year later decides they want current.
<micahg> ScottK: I'd prefer we don't have it officially part of the new release model as that will require backports go through the intermediate releases again
<infinity> micahg: Eh?
<micahg> if there's an upgrade path, you need the backport through it
<ScottK> micahg: With the proposed shorter support lifetime, it greatly simplifies that.
<infinity> ^
<ScottK> The path becomes ~ LTS  and current.
<infinity> And the argument from Colin and I is that we should be making sure the upgrade path WORKS, regardless of if we need to support it.
<micahg> sure, but current might not be valuable
<slangasek> infinity: cjwatson's original question was whether to change the tech overview, and I think the answer to that is yes + get it autotested, provided we can make update-manager DTRT
<infinity> Though, with the shorter support cycles, we would need to support it, I think.
<infinity> micahg: I'm not sure what you mean by "current might not be valuable".
<micahg> infinity: in terms of backporting certain software
<infinity> micahg: If all backports are from current, and the only supported release other than current is an LTS, you only backport from current to LTS, and done.
<micahg> infinity: it's common to want to backport from the development series
<infinity> micahg: I thought you had a policy of not backporting from devel, because it makes post-backport support a nightmare?
<micahg> infinity: I was not aware of such a policy where the version being backported was a stable one
<ScottK> infinity: No.  The requirement is it has to be in the archive.  Devel series is fine.
<infinity> ScottK: Ahh, kay.  I misunderstood somewhere along the way.
<ScottK> The support model is if a backport is broken, backport the newer thing that fixes the broken.
<infinity> So, sure, you might need to backport to $current and $latest_lts, if your ultimate target is $latest_lts, that shouldn't be a big deal, mind you.
<ScottK> Considering the testing standard is builds/installs/runs, it's not hard.
<micahg> infinity: it just means you need to find someone with interest on $current to test, that can be problematic sometimes
<ScottK> It gets hard for libraries, but then it's supposed to be hard ...
<ScottK> infinity: I think we'll also want to adjust SRU policy too, but it can wait until the details of the larger plan are sorted.  I'm thinking for non-LTS releases, only SRU regressions from the previous release.  For other things hit the development series and last LTS.  The regular release user can get the fix when they upgrade after the next release.
<infinity> ScottK: Again, preaching to the choir.
<infinity> ScottK: Many of us think lots of these things are somewhat self-evident, so I suspect we might be able to just have a Release Team pow-wow about it all and present a unified front on a few things like this.
<ScottK> Agreed.
<ScottK> FWIW, Kubuntu (as a project) had a meeting on the topic and I just sent the project feedback to the TB list.
<infinity> Yeah, I'm catching up with the list archives now.
<ScottK> It would be nice to have a version of http://people.canonical.com/~ubuntu-archive/proposed-migration without Laney's haskell stuff in it.
<ogra_> poor Laney, nobody likes his haskell
<ogra_> (though i usually complain about the -changes spam)
<Laney> There's a good way to get it clear of haskell stuff.
<Laney> If you say "remove it" you get a Stern Look
<infinity> remove-package ghc?
<infinity> Jinx.
<micahg> I think if someone doesn't find time in the next 2 weeks, anything haskell package with no rdeps that's blocking the transition should be removed, that can be done recursively, then a handful will be left that hopefully someone has time to fix
<cjwatson> I've already been removing some binaries that are broken on non-primary architectures
<Laney> I think if all of the ppc/armhf busticacted ones are removed then the remaining list looks a lot more tractable
<Laney> I've already ported a few packages for 7.6 too and hope to get to as many of the rest as possible
<Laney> In some cases I've been syncing older versions of stuff (syncpackage -V) and also undoing ports to new APIs to avoid starting new sub transitions
<jokerdino> hey, i know you guys are super busy and stuff but, can one of you spare some time and help us review the unity-tweak-tool stuck in the new queue. :'(
<jokerdino> i will be grateful.
<infinity> jokerdino: It's still on my TODO.  I guess since I managed to pass chromium off to chrisccoulson, I can look at it this afternoon.
<jokerdino> infinity: oh thank you very much. it just feels a little dejected getting no response for quite some time now.
<jokerdino> and i feel low having to nag :(
<rtg_> infinity, new raring kernel crack headed your way. I remembered the orig tarball this time.
<infinity> rtg_: Mmm, crack.
<xnox> infinity: sometimes I'm not sure when you are joking ;-)
<infinity> xnox: In reference to?
<ogra_> crack ?
<infinity> ogra_: Well, it's either crack or wearing floral prints to work.  I'm not sure what his context is.
<ogra_> oh, you waer floral prints ?
<xnox> ogra_: no, i do.
<ogra_> tsk ... that hangout thing
<xnox> anyway. turns out my PC woes was the beginners mistake of using PSU that is bundled with the case....
 * ogra_ would rather call it a mistake to buy a bundle :)
<infinity> Unless it's an Antec, yeah.
<ogra_> do they have special silent fans ?
<infinity> The lovely PSU company that realized they could triple their profit margins by wrapping their power supplies in pretty aluminum.
<infinity> ogra_: They have pretty much anything you can imagine.
<ogra_> ah, cool
<infinity> (I tend to buy my Antec cases and PSUs separately anyway, to mix and match what I want, but you probably wouldn't go wrong with a bundle, as long as you don't stupidly underspec your power draw)
<ogra_> well, if the case suits me :)
<infinity> I've been using these ones a lot lately.  Ridiculously cheap, well made, nice to work with, and somewhat pretty: http://www.memoryexpress.com/Products/MX37673
<ogra_> getting a PSU thats powerful enough and quiet for that case http://www.silverstonetek.com/product.php?pid=291wasnt so easy
<infinity> Ahh, you like yours a bit more compact, I see. :)
<ogra_> yeah, and in some atypical shape
<infinity> I'm still an old skool overclocker and modder at heart, even though I don't do either anymore.  But I still purchase as if I might.
<ogra_> i would have bought it in a bigger size if they had it
<ogra_> still enough for playing steam games on my triple head setup :)
<xnox> This is what I got: http://www.ebuyer.com/235611-coolermaster-elite-430-all-black-case-with-elite-500w-psu-rc-430-kwp500
<xnox> it even has blue LED front fan
<ogra_> heh
<infinity> Kids these days.
<ogra_> thats what made alienware a success :)
<infinity> xnox: CM isn't known for their quality.  Just trading on a silly "overclocking friendly" brand that never measured up, sadly.
<ogra_> siny LEDs on the cases
<ogra_> *shiny
<infinity> xnox: Not that quality matters for a case, if you think it's pretty and it doesn't slice all your fingers open.  But it matters for the power, as you've found out.
<ogra_> it shouldnt rattle all the time ... so minor quality is required
<infinity> Heh, fair point.
<xnox> infinity: yeah. First troubleshooting step: take the motherboard out of the case.
 * xnox was all *sigh* about that.
<infinity> But you can fix that with a bit of puffy double-sided tape in the right spots, if you REALLY like the look of it.
<ogra_> yeah, or cardboard
<infinity> Heh.
<infinity> I still have a laptop with one of Thom's business cards embedded in it.
<infinity> Replaced a shim between the case switch and the internal power switch that broke off.
<ogra_> my basement is fully equipped with tools to build a case ... one day i might build my own
<ogra_> haha
<ogra_> wow, that must be old
<ogra_> like 7 years or so
<infinity> Did the repair in Sydney.
<infinity> Whenever that was... 2005, I guess.
<infinity> ogra_: Dude, we're old.
<infinity> ogra_: Well, I'm old.  You're really old.
 * slangasek passes out canes
<ogra_> hahaha, yeah
 * infinity misread passes as pisses and was really confused.
<ogra_> LOL
<ScottK> infinity: For power supplies, I'm either for Antec or PC Power and Cooling (although I think it's been close to a decade since I bought from them).
<ScottK> Actually no.  I bought one recently.
<ScottK> I replaced a circe 2005 PP&C supply that failed.  I was happy enough though that it failed safe so it was just a matter of dropping a new power supply in.
<Noskcaj> just don't buy Aywun power supplies
<Noskcaj> ocz make good PSUs too.
<infinity> OCZ has good warranties.  The part where I know that makes me shy away from them, but I could have just had bad luck.
<Noskcaj> my ModXtream works great, just mmy cooling isn't enough for my OC so my PC is near unuseable
 * infinity decides to go to the pharmacy to get some drugs, and hopes the channel will get back on topic in his absence.
<ogra_> heh
<Noskcaj> infinity, won't happen
#ubuntu-release 2013-03-16
<darkxst> How would we go about getting Ubuntu GNOME added to the iso-tracker?
<phillw> darkxst: Is it not on the daily builds?
 * phillw goes looks
<phillw> darkxst: you're right, it is not there.
<phillw> http://cdimages.ubuntu.com/ubuntu-gnome/daily-live/current/ has them,
<phillw> darkxst: I'm not too sure what the -gnome team has arranged for iso-tracker, I do recall them saying that they wanted a beta 2 out.
<darkxst> phillw, yes but how do we get testcases listed on the iso-tracker?
<darkxst> we haven't arranged anything, thats why I am asking :)
<phillw> darkxst: the best guy to chat to would be stgraber
<darkxst> ok, thanks
<phillw> to have it listed, balloons can help with getting test cases allocated to it once it is on the iso tracker
<balloons> indeed
<phillw> balloons: is it stgraber who needs to list it on the iso tracker?
<balloons> involving him and the release team is best
<phillw> balloons: while you are briefly here, can you remove the "" from the start of the topic on -quality and the " from the end, the latter is causing a fail on URL :)
<balloons> I saw that
 * cjwatson fixes the excessive livefs build attempts on inappropriate architectures that caused a few build failure mails
<infinity> Alright, so.  udev/systemd have been violently jammed into raring.  For better or worse.
<cjwatson> Ubuntu GNOME builds cronned, starting at 15:32 UTC daily
#ubuntu-release 2013-03-17
<JackYu> cjwatson: hi, is there any statistics about the number of downloading for our beta-1?
<cjwatson> JackYu: I don't have access to such things; you'd have to ask Canonical sysadmins
<cjwatson> (any statistics that may exist would be only an estimate, because cdimage.ubuntu.com is mirrored on many systems that we don't control)
 * cjwatson gets the diff between the public cdimage branch and the one actually deployed on nusakan down under 1000 lines
<cjwatson> I may be able to eradicate it yet ...
<JackYu> cjwatson: I see. thanks:)
#ubuntu-release 2014-03-10
<sergiusens> can someone please look at https://bugs.launchpad.net/ubuntu/+bug/1290351
<ubot2`> Launchpad bug 1290351 in Ubuntu "[FFe] Sync golang-go-xdg 0~bzr20140219-1 (universe) from Debian unstable (main)" [Wishlist,New]
<Laney> sergiusens: you don't need to immediately ping ...
<sergiusens> Laney, right; sorry 'bout that
<Laney> I'll spend some time on the queue later on today
<Laney> (not to say that someone else can't process things)
<ogra_> stgraber, so i had some massive probs today to promote images ...
<stgraber> ogra_: ah, what kind?
<ogra_> stgraber, it took endlessly long .... and it seems it deleted the tarball for some arches during the process
<stgraber> ogra_: hmm, I really need to figure out a better way to deal with that case...
<stgraber> ogra_: what happened is that as you didn't promote an image in quite a while, the 194 image in trusty-proposed was expired a while back including all deltas it had
<stgraber> so when you did the copy earlier, there wasn't any of the 194 => 226 pre-generated deltas which make the copy very quick and they all had to be regenerated during the copy
<stgraber> trusty-proposed stores the last 20 images, 226-194 = 32, so that indeed seems to be the problem
<ogra_> stgraber, sorry, doorbell
<stgraber> (back when we set those values, it seemed unimaginable that it'd take us more than 20 tries before we get a promotable image, guess we were wrong...)
<ogra_> stgraber, http://paste.ubuntu.com/7067819/
<ogra_> thats my full terminal log from trying to promote all images
<stgraber> hmm, still looks like import-images running cleanup_tree under our feet, though the lock should prevent that from happening... I guess I'll have to do some tests of the locking mechanism, something seems wrong there
<ogra_> yeah, i could see the tarballs actually show up and vanish again on system-image.ubuntu-com in the browser
<ogra_> i show down the cronjob in the end
<ogra_> stgraber, i messed up the flo release by missing -k to copy-images, can we fix that ?
<stgraber> ogra_: yeah, give me a minute I'll fix it
<ogra_> no hurry :)
<stgraber> ogra_: should be good now
<stgraber> ogra_: http://paste.ubuntu.com/7067901/
<ogra_> stgraber, gracias !
<bdmurray> Can I get the release of ubuntu-release-upgrader in saucy-proposed fast tracked to -updates?
<infinity> bdmurray: Seems likely.
<infinity> bdmurray: Done.
<bdmurray> infinity: thanks!
<infinity> bdmurray: Is the Ubuntu task on #1289604 valid?
<infinity> bdmurray: If not, maybe that should be marked Invalid instead of In Progress...
<infinity> bdmurray: Or, if this needs fixing in trusty, please do. :P
<bdmurray> infinity: I did fix it but I'm not sure it really needs it, since we can convert the release upgrader to use python3 when development on U starts.
<infinity> bdmurray: But isn't this about new release-upgraders needing to run on old systems?
<infinity> bdmurray: And the trusty one needs to run on precise...
<infinity> Or, oh.  I guess the trusty tarball will work on precise, but doesn't need the dep.
<bdmurray> right because the tarball doesn't install deps
<infinity> (But then, yeah, it needs python2.7 because it's not python3, because it needs to run on precise...)
<infinity> bdmurray: So, is this *only* about the tarball contents, and not at all about any tools that might be run on a trusty system?
<bdmurray> No, this is about python-apport not being installed on saucy and the special traceback handler in the upgrader not working because it can't import python-apport code.
<infinity> bdmurray: Right, but will that be invoked at py3 on a trusty system then?
<infinity> s/at/as/
<infinity> I guess the release-upgrader deps on trusty certainly imply that.
<bdmurray> When a Trusty system tries to upgrade to U, then it could and should be invoked as python3 provided we change the U tarball creator.
<bdmurray> So that's why I think the Trusty change to depend on python-apport is unnecessary.
<infinity> Right, unnecessary, and bloaty.
<bdmurray> Okay, I'll remove that then.
<infinity> I had a buildd install a bunch of python2 stuff on upgrade the other day, I guess that's why?
<bdmurray> If the other day was Saturday or Sunday, probably.
<infinity> It was yesterday, yeah.
<infinity> Brought in python-apport, launchpadlib, etc.
<bdmurray> yep
<infinity> So, yeah, if you want to maybe prep a branch in advance of "the first U upload of release-upgrader" that flips all the right switches to py3 tarballs, and keep that rebased until T releases, then we can stuff it in as soon as we open, and everyone wins.
<infinity> Since some strange people always pester us until do-release-upgrade works, even when no packages have changed yet. :P
<bdmurray> heh, did you you see my email about the pgp signature for the release upgrade tarball?
<infinity> I did, and it confused me.
<infinity> That should be atomic, from a mirror's POV, why do you care if the times are mismatched?
<infinity> (ie: it hits disk, some other publisher stuff happens, then it's signed, but at no point is that intermediate step mirrored to the world)
<bdmurray> There is a period of time where there is an upgrader and no signature, then upgrades fail.
<infinity> If the timestamp mismatch is an issue, we can fudge it with touch, but I don't see why it would be.
<infinity> bdmurray: That's the part I don't believe.
<infinity> bdmurray: This all happens in dists.in-progress during the publisher, and is atomicly copied to dists before we push mirrors.  Unless we have a bug where we're signing in the NEXT publisher run, but that seems unlikely.
<bdmurray> infinity: I'm sorry you don't believe that upgrades fail or that there is a lag?
<infinity> bdmurray: I don't believe that upgrades fail because of the lag, because the lag shouldn't be visible to anyone outside the datacentre.
<bdmurray> infinity: okay, I was trying to upgrade on Friday and it failed because the .gpg file was missing. If I make this change to the upgrader and upload it soon, you should see it.
<bdmurray> It being the issue.
<infinity> bdmurray: I'm not discounting that upgrades fail, nor am I implying there's no lag between writing to disk and signing, I'm saying that I'd like some evidence that you actually see the disparity on a mirror, except if you literally catch them mid-rsync, and they don't do atomic dists mirroring.
<infinity> (And people who don't do atomic dists mirroring are people we can't fix)
<cjwatson> Also, the signing is done strictly before the mirror push
<infinity> cjwatson: Yeah, I covered that.
<cjwatson> Oh yes
<bdmurray> I'm still verifying but I don't think mirrors are used to get the release upgrader.
<cjwatson> opaque proxies are possible though
<infinity> bdmurray: Everything is a mirror, but I assume you mean "no mirrors other than archive/ports".
<bdmurray> infinity: yes, it just uses archive.ubuntu.com
<infinity> bdmurray: Right, so those mirrors should be completely "safe" from a mirrors-not-doing-stupid-things perspective.
<infinity> bdmurray: They should never get one half of dists without the other, etc, unless something goes wildly wrong.
<bdmurray> infinity: well, I'll do this upload and ping you if I see the disparity.
<bdmurray> infinity: if you look here you'll see it http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/dist-upgrader-all/current/
<infinity> Hrm.
<infinity> Maybe that's being published early in the security-only run, but not signed until the full run.
<ogra_> stgraber, can we bump the amount of kept images on s-i to 50 (for -proposed) ? if we get into situations like today and people try to bi-sect back to the last promoted image 20 is not enough
<infinity> Yup, that's what's happening.  Erk.
<ogra_> (we do two images per day, keeping 20 means 10 days only)
<cjwatson> I guess it's published by process-accepted at the start
<cjwatson> Because custom uploads
<infinity> cjwatson: Yeahp, that's what the log implies.
<infinity> cjwatson: Maybe we need to build a signing run into the security-only pass.
<cjwatson> Seems odd for security-only to run finalize but not publish-distro though
<stgraber> ogra_: done. I was vaguely concerned by the disk usage but we're only at around 30GB now out of the 160GB we have on the target server, so that should be fine.
<ogra_> yeah
<infinity> cjwatson: Maybe it only runs publish-distro if *-security was actually dirty.  Which it usually isn'y.
<ogra_> stgraber, theoretically having some function that simply keeps all proposed builds between two promoted images would be the best
<cjwatson> infinity: I'd just got there, yes
<cjwatson> So it needs to run publish-distro either way, I guess
<stgraber> ogra_: yeah, that'd be the proper fix, I'd have to add some more channel relationship knowledge into the expiring code, should be doable though
<infinity> cjwatson: Or, more sanely, we don't need the security-only run at all if *-security isn't dirty (do we have a way to check that at the beginning and just not run?)
<ogra_> right, just sounds like a bunch of code
<cjwatson> infinity: It might be least invasive to have the various publish methods return a bool to say whether they did anything
<cjwatson> um, except that sometimes it'll do nothing else depending on options - not sure I have time/brainspace to work this out right now
<cjwatson> lib/lp/archivepublisher/scripts/publish_ftpmaster.py anyway, it's not horribly complicated
<infinity> cjwatson: I think I'll toss to cprov and wgrant.
 * cjwatson nods
<bdmurray> slangasek, infinity: could one of you review that?
<infinity> bdmurray: Is that byte-for-byte the same patch I just released to saucy?
<bdmurray> infinity: aside of the fact that it is the apport hook for update-manager due to the package split yeah.
<infinity> Oh, with s/ubuntu-release-upgrader/update-manager/
<infinity> bdmurray: Let me double-check the sameness of it, and wave it through.
<infinity> bdmurray: No "import re", was it already there in the precise version?
<bdmurray> infinity: yeah to get some aptdaemon log stuff
<infinity> Ahh, indeed it is.
<infinity> bdmurray: Accepted.
 * infinity goes to hunt for... Whatever meal this is.
<slangasek> I hope it's not fourthmeal
<infinity> slangasek: I run all my meals in OF.
<slangasek> twitch
#ubuntu-release 2014-03-11
<xnox> People with Powers, please retry rebuild archive build records for cyrus-sasl2 http://paste.ubuntu.com/7071009/ i believe it's buildable now.
<infinity> xnox: You'd be wrong.
<xnox> infinity: could you explain?
<infinity> xnox: Those packages are in universe.  Fixing.
<xnox> infinity: ah, and my builder has all components.
 * xnox really should invest into switching to stgraber's build with just main.
<mapreri> please, could someone look into https://launchpad.net/bugs/1283459 ?
<ubot2`> Launchpad bug 1283459 in xscreensaver (Ubuntu) "FFE: Please merge xscreensaver (5.23-1) from Debian unstable" [Wishlist,New]
<mapreri> I'm also wondering if make sense merge the last 5.26-1 (uploaded 4 days ago that I've not tested yet)
<bdmurray> slangasek: could you merge https://errors.ubuntu.com/problem/d2dd8ddd68b15cbf2c7a6e1dea241adf4a051ac0?
<slangasek> bdmurray: I'm lost, how do I merge an error bucket?  Was that the wrong link?
<bdmurray> slangasek: how about this then! https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater-traceback/+merge/210477
<slangasek> looks more promising! :)
<slangasek> bdmurray: done
<bdmurray> slangasek: thanks
#ubuntu-release 2014-03-12
<RAOF> Man I hate webapps SRUs :(
<jamespage> please could the MIR approved new dependencies for cinder, glance and ceilometer be pushed to main; I'd like to have all of OpenStack Icehouse b3 in archive so our testing is now skewed by version
<xnox> seb128: ^
<seb128> xnox, thanks
<seb128> xnox, accepted (but got an error, I think somebody beat me to it)
<infinity> seb128: Sorry, I beat you there.
<seb128> infinity, no worry ;-)
<infinity> bdmurray: By the way, your upgrader/signature skew bug should be fixed in production now.
<infinity> bdmurray: https://bugs.launchpad.net/launchpad/+bug/1290481
<ubot2`> Launchpad bug 1290481 in Launchpad itself "Gap between publishing custom uploads and signing them" [Critical,Fix released]
<bdmurray> infinity: cool
<bdmurray> infinity: can you fully phased the ubuntu-release-upgrader in -updates for saucy?
<infinity> bdmurray: Done.
<infinity> (Why was it at 0?)
<bdmurray> infinity: thanks, well because there were new crashes detected because I changed the format of the duplicate signature
<bdmurray> so of course they hadn't been seen before ;-)
<infinity> Ahh.  Whee.
<infinity> Working as written, but not as intended. ;)
<sergiusens> can someone take a look at this? https://bugs.launchpad.net/ubuntu/+bug/1290360 not sure why it's set as 'Opinion'
<ubot2`> Launchpad bug 1290360 in Ubuntu "[FFe] New Ubuntu Touch specific package: media-hub" [Undecided,Opinion]
<rbasak> sergiusens: I'll set it back for you. Without an explanation, I can only assume that it was done by accident.
<cjwatson> I already did
<cjwatson> John Kim has interfered with release bugs in the past
<rbasak> Thanks!
<sergiusens> thanks
<jamespage> infinity, could you do me a favor and promote the dependencies that are holding glance, cinder and ceilometer in proposed to main
<jamespage> all of the MIR's are approved
<jamespage> (pretty please :-))
<roaksoax> can someone please look at https://bugs.launchpad.net/ubuntu/+bug/1288897
<ubot2`> Launchpad bug 1288897 in Ubuntu "FFe: Sync python-seamicroclient 0.1.0-1 (universe) from Debian unstable (main)" [Wishlist,New]
<roaksoax> ?
#ubuntu-release 2014-03-13
<jamespage> any archive admins around? I really need the acked main inclusions blocking cinder glance and ceilometer to be pushed to main - http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<jamespage> right now testing is skewed as I have b3 for some components and b2 for others
<jamespage> not great
<jamespage> Daviey, ^^ ?
<jamespage> Daviey, don't worry - I found a volunteer in -devel
<Daviey> sorry jamespage, was AFK
<jamespage> Daviey, hey np - pitti sorted me out
<Daviey> great!
#ubuntu-release 2014-03-14
<xnox> qtdeclarative-opensource-src seems to have a weird binary split. For binaries that are in main, only those on i386/amd64/armhf are in main powerpc/ppc64el/arm64 are in universe which makes other packages depwait on powerpc/ppc64el/arm64
<infinity> xnox: Can fix.
<infinity> Though, I don't see this...
<infinity> Oh, cause it's in proposed, and my report only does the release pocket.
 * infinity hunts and fixes manually.
<xnox> infinity: yeah, it's quite confusing. Ideally we'd have an architecture-mismatches-proposed.txt report or something like that.
<infinity> No, ideally this wouldn't happen at all. :P
<xnox> =))))))))))))))))))
<infinity> But it's another fun side-effect of some bugs with copying from PPAs.
<infinity> Also, whee.  Maximising a window under LIM gives you NO MENUS.
<infinity> I kinda expected the top bar to become my menu/title bar...
<xnox> infinity: for me there are menus, they are just below the top bar, cause window is maximazied underneath it.....
<infinity> xnox: "below", as in Z-index, or you have a fat top bar?
<xnox> "Z-index"
<infinity> Cause it may well be Z below, but how would I know? :P
<xnox> but somehow at the moment i have both LIM and global menus simultaneously =/
<infinity> Cute trick.
<infinity> Alright, overrides fixed, as of the next publisher run.
<infinity> xnox: Do you know if there's already a bug for the LIM Z-Index I HAZ NO MENUS OR BUTTONS thing?
<infinity> Given all the users would wouldn't know how to use Alt-Space or similar, I guess they'd just be stuck with that window forever.
<xnox> infinity: i only saw seb128 saying they have dozens of bugs / duplicates about LIM and Lock Screen.
<infinity> Hrm, my screel lock seems to be fine.
 * infinity does one more pass on qt5 component mismatches.
<xnox> infinity: the most hallarious one is that one needs to use indicator to get unstuck from: alt+tab, release tab, keep pressing alt, press ctrl+l
<xnox> infinity: input keeps going into the session, yet lock screen is the highest on the Z-order and thus one can't see anything, nor unlock the lock screen =)
<infinity> xnox: Hahaha.  Cute.
<infinity> xnox: Doesn't seem like something I'd do by accident, but fun to do on purpose.  If I was at a sprint right now, I'd so be locking people's machines that way and waiting for passwords in IRC.
<xnox> infinity: thanks for promotions, looks much better now. But why is this still failing? https://launchpad.net/ubuntu/+source/qt3d-opensource-src/5.0~git20130731-0ubuntu2
<cjwatson> xnox: that's just lack of upstream architecture support, isn't it?
<cjwatson> oh, it's a different failure from before
<xnox> cjwatson: it's failing to install dependencies, no?
<cjwatson> it is now, but previously in the PPA it failed with a real build error later
<cjwatson> so it isn't going to do better even if you fix this
<xnox> =(
<xnox> porter box doesn't have -proposed enabled, so isn't that useful either =(
<cjwatson> any of the recent qt5 landings were already tried on all arches; they're probably being retried again in the primary archive, but are unlikely to do better
<xnox> cjwatson: ok, there was architecture-component missmatch in proposed which infinity fixed now.
<cjwatson> yeah, I saw
<xnox> let me retrace my steps from proposed-migration report where i thought it might be a problem blocking the migration (once the block is lifted)
<cjwatson> hm, yeah, there is something still wrong
<cjwatson> attacking with chdist
<cjwatson> ah, this one is arch-indep
 * cjwatson promotes libqt5core5a qtbase5-doc-html to main
<infinity> I already got those.
 * cjwatson ctrl-cs quickly
<infinity> In my last pass.
<cjwatson> lucky my internet is slow ;-)
<infinity> I think...
<cjwatson> https://launchpad.net/ubuntu/trusty/i386/libqt5core5a doesn't show it
<infinity> Yeah, maybe not.
<infinity> The names all look the same.
<infinity> Ahh, indeed, those two are on c-m-p, they weren't before.  Or I missed them in my copy and waste run.
<infinity> Weird.
<infinity> Carry on.
<cjwatson> ok, doing
<xnox> qtsensors5-dev looks weirdly split as well.
<infinity> Anything that was NEW in those arches probably is.
<infinity> Let me see.
<xnox> (it's in main on primary arches, universe on ports arches)
<xnox> http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt for -proposed would be nice =)))
<infinity> xnox: I'll get the qtsensors ones.
<xnox> infinity: thanks.
<infinity> Alright, that source package is sorted.
 * infinity hunts for more.
<infinity> Alright, found more. :P
<infinity> Okay, missed that publisher run.  As of the next, I think all of qtdeclarative's rdeps should be in a sane state.
<xnox> cjwatson: so qt3d build on ppc64el fails on embedded copy of assimp, which did build fine in the archive, i wonder why embedded 3rdparty copy is used.
<cjwatson> ok, but probably best not to ask me :-)
<xnox> compiles well, after porting, and only two test failures on .3ds file format. will poke that more tomorrow.
 * xnox Zzzzz
<darkxst> I suppose its getting too late now to have any change of bug 1228765 happening?
<ubot2> Launchpad bug 1228765 in unity-control-center (Ubuntu) "[FFe] Implement DisplayConfig dbus interface and transition to gnome-desktop 3.10" [Low,In progress] https://launchpad.net/bugs/1228765
<slangasek> darkxst: has this been coordinated with the Ubuntu Desktop team?  The two linked branches for the unity packages are both marked 'disapprove'
<slangasek> I also don't understand the claim in the bug description that the move to 3.10 was blocked by the unity forks of g-s-d and g-c-c... it sounds like these "forks" are *still* entangled (and therefore blocking)
<slangasek> (so, what was the point in forking if they still have to be upgraded in lockstep?)
<darkxst> slangasek, desktop team wouldn't consider this work unstill things were forked
<darkxst> the whole point of forking was so ubuntu GNOME can have g-s-d/g-c-c 3.10
<slangasek> darkxst: I'm talking about the merge proposals that were specifically raised on the unity-control-center and unity-settings-daemon packages, which are the forked versions
<slangasek> if they're forked, why are they tied into this FFe request?
<darkxst> right, they need to be patched for the new gnome-desktop api
<darkxst> and they got marked disapproved because Noskcaj proposed merges without an FFe
<slangasek> I would want to see an explicit ack from the Desktop team that they're happy with letting this in, before I would sign off on this
<slangasek> obviously we don't want to be holding back Ubuntu-Gnome, but we are past FF and I'm not in a position to evaluate the impact on the desktop
<darkxst> they were ok with it when I proposed the FFe (a couple of weeks ago), but I can check with them if still ok
<slangasek> darkxst: that's not how I understand the comments in the bug log, where a member of the desktop team last week is calling it 'risky'
<darkxst> its seb's whole 1 step at a time policy, that made this end up so late!
<darkxst> I wanted to land this stuff a month ago, but Seb said it had to wait for u-s-d to be done
<slangasek> well, whatever the reason, it's now in a place where it needs a FFe; and I don't think any member of the release team is going to say "yes" to an FFe if the affected flavors are saying "no"
<slangasek> (and if it does require a new version of bluez, like bug #1267909 suggests, that's a whole new level of due diligence required)
<ubot2> Launchpad bug 1267909 in unity-control-center (Ubuntu) "Update Bluetooth panel" [Wishlist,Triaged] https://launchpad.net/bugs/1267909
<darkxst> slangasek, no intention to update BlueZ this cycle
<darkxst> all bluetooth changes were reverted in our packaging so it works fine with gnome-bluetooth 3.8
<slangasek> ah, and I see now that you said so on the bug - sorry for overlooking
<darkxst> anyway I will chat again with desktop team tonight and see if they will still ack this
<darkxst> infinity, around?
<didrocks> anyone available from the RT to override some packages for migrating?
<didrocks> (5.2 migration)
<Riddell> didrocks: yo, what's it need?
<didrocks> Riddell: hey, I had to go with the "removing binary packages" that will be reintroduced in next upload anyway (as the Qt 5.2 transition is big, I'm trying to ensure that we are well advanced before EOD)
<didrocks> I check all rdepends, and it won't introduce uninstallable packages
<didrocks> (as most of them are just new build in -proposed)
<Riddell> didrocks: let me know if I can help
<didrocks> Riddell: yeah, will do, thanks for the offer :)
<xnox> uploaded remaining 6 packages that didn't rebuild against libqt5core5a yet.
<xnox> that should make britney more happy about qt5.2 transition.
<didrocks> xnox: oh, Mirv did you miss those ^
<didrocks> I saw cordova-ubuntu
<didrocks> xnox: hum, why wallch?
<didrocks> it's qt4
<didrocks> same for qgo, isn't it?
<Mirv> didrocks: yes, it's possible, only last week I added peg-e, pokerth, mediscanner2 (which was new user as well)
<Mirv> and phonon
<Mirv> my fault was to use reverse build depends checks only most of the time
<Mirv> plus generally having enough stuff to do all the time to remember to check whether http://pad.ubuntu.com/qt52-dependencies was complete
<Mirv> not that I'd have seemingly found qgo anyway
<Mirv> I did see those phonon plugins, then forgot about them after I built the phonon itself :) nice that none of those missed ones were too big
<xnox> didrocks: wallch 4.0-0ubuntu3 depends on libqt5core5 (>= 5.0.2), libqt5gui5 (>= 5.0.2), libqt5network5 (>= 5.0.2), libqt5webkit5, libqt5widgets5 (>= 5.0.2)
<xnox> didrocks: thus it's qt5, and totally needed rebuild for libqt5core5a.
<Mirv> ah, so there's a 4.0 wallch in -proposed and that's why reverse-depends doesn't show it or qgo?
<xnox> didrocks: dito qgo.
<Mirv> and 3.0 was Qt4
<didrocks> xnox: ah, so they were stuck in proposed already
<xnox> didrocks: Mirv: yes, all of those were packages that were stuck in proposed, and got build against libqt5core5.
<Mirv> thanks xnox for spotting all of those
<didrocks> ok, making sense then
<didrocks> xnox: so, they were just being blocked I guess, not blocking Qt 5.2 migration itself?
<xnox> Mirv: well, proposed-migration did =) then I wrote a ben transition tracker that generate a list for me ;-) it's not like I scanned the archive by hand ;-)
<didrocks> as previous version in release were 4.0, they will just not migrated
<xnox> didrocks: i don't know, but these rebuilds should lower the uninstallable count and make the proposed-migratin page look more sane.
<xnox> didrocks: e.g. with libav britney was blocking on "leaf packages like above" for a long time, until it didn't and allows NBS into release pocket.
<xnox> didrocks: i hope you didn't do any removals to force qt5.2 transition in, did you?
<xnox> yeah, the list is now very small.
<xnox> i'll wait for phonon to build and then it should be clear what remaining couple of packages are that britney points out.
<xnox> cause e.g. britney still thinks that " ubuntu-touch" would become uninstallable =))))))
<didrocks> xnox: we had to remove some packages, this was discussed already as it's temporary and agreed on
<didrocks> (arm64/ppc64el and powerpc)
<xnox> didrocks: which ones were those? i don't see how those could be blocking qt5 transition, given that most of qt5 never built on those.
<xnox> (qtdeclarative and up)
<didrocks> xnox: qtdeclarative is fine, but not the sdk
<xnox> oh, right.
<didrocks> xnox: and there is another MP to fix the sdk, but colin told to go ahead and do that once the transition is done
<xnox> cool, there still looks something odd with libaccounts/signon stack though.
<didrocks> yeah, I did remove for libaccounts/signon
<didrocks> so should be fine
<didrocks> (part of the same set blocked by sdk and have no rdepends)
<didrocks> xnox: tell me if you see anything else bad, multiple eyes help :)
<mdeslaur> hrm, the archive is busticated
<mdeslaur> libdbusmenu-qt in now available, but was built against qt5.2 that's still in -proposed
<didrocks> I didn't touch that one
<didrocks> weird that it migrated?
<mdeslaur> yeah, quite weird
<didrocks> waow, you're right
<xnox> well, britney goes by uninstall count, thus removing a package can trade _anything_ into the release pocket.
<didrocks> ah I know, there are some magic IIRC
<didrocks> to remove the dep on qt5
<didrocks> so that we can have appmenu without bringing the whole qt4 and qt5 on the image
<didrocks> so that's why :/
<xnox> yeah, it is weird, it only _suggests_ qt5 libs.
<didrocks> yep
<didrocks> IIRC, that was that, was years ago (when appmenu was introduced)
<didrocks> xnox: hum, all those plugin on i386 is worrisome
<mdeslaur> I have a funny feeling this is going to break people
<mdeslaur> (well, it already broke ubuntu-sdk)
<didrocks> mdeslaur: yeah, and depends how long we are going to take before the transition ends
<xnox> didrocks: i wonder if it's just a hint missing, or something like that.
<mdeslaur> bug 1292487
<ubot2> Launchpad bug 1292487 in libdbusmenu-qt (Ubuntu) "libdbusmenu-qt can't resolve symbols" [Undecided,New] https://launchpad.net/bugs/1292487
<didrocks> xnox: yeah, can be, we need to try a chdist?
<xnox> didrocks: right there are hints missing, you'd want to hint for e.g.
<xnox> didrocks: signon-plugin-oauth2 to go in together with qtbase-opensource-src
<didrocks> xnox: I never did that (only block/unblock) in britney, mind doing or guiding me? :)
<xnox> didrocks: and i think that's it.
<didrocks> xnox: you just apt-get install both btw to confirm it?
<didrocks> mdeslaur: just for the note, if it's the only transient issue with this migration involving 122 packages, I will be happy ;)
<xnox> yeah, they are installable. plus hints are not forcing anything, it's just telling britney to consider the packages together in the analysis. So it would still validate that they are installable.
<didrocks> xnox: ok, I just:
<didrocks> hint signon-plugin-oauth2 qtbase-opensource-src
<didrocks> or something else?
<xnox> didrocks: it's like this: easy ubuntu-settings/14.04.4 gnome-session/3.9.90-0ubuntu11
<xnox> so:
<xnox> didrocks: wait that will not work =)
<didrocks> xnox: easy qtbase-opensource-src/5.2.1+dfsg-1ubuntu7 account-plugin-evernote/0+14.04.20140113.2-0ubuntu1?
<didrocks> weird
<didrocks> account-plugin-evernote is already in the release pocket
<xnox> didrocks: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html  signon-plugin-oauth2  has not satisfiable dependencies on arm64.
<didrocks> ah yeah, making sense that all plugins fail
<xnox> didrocks: which i think means that sigon-plugin-oauth2 should be removed on arm64 from trusty-release.
<didrocks> xnox: let me check rdepends
<xnox> didrocks: or better, fixed.
<didrocks> xnox: all that will be fixed in a second time
<didrocks> let's get everything in, there is already a followup silo for the sdk
<xnox> didrocks: so all are valid candidates, which is good, but signon-plugin-oauth2 on arm64.
<didrocks> xnox: yeah, I didn't grep multiple times the file to get to that state TBH :)
<didrocks> so account-plugin-tools
<didrocks> ok, only ubuntu-touch as a rdepends
<xnox> didrocks: account-plugin-tools is arch:all, that's fine for it to not be installable on one arch =)
<didrocks> yeah, arch:all
<xnox> and there is no ubuntu-touch on arm64.
<didrocks> so ok, seems only signon-plugins-oauth2
<didrocks> really? striking news! ;)
<xnox> didrocks: do you want me to upload ubuntu-touch-meta which builds on arm64? i can totally do this +)))))))
<didrocks> xnox: tsssssssss ;)
 * xnox dch -i "Didrocks said I should do this..."
<didrocks> ahah
<xnox> i'll sponsor it with your name ! =)
<didrocks> xnox: I bet you will be so evil to do that ;)
 * didrocks flushed signon-plugin-oauth2
<didrocks> ok, so arm64 will be happy
<xnox> yeah, so next britney run, hopefully it will migrate.
<didrocks> yeah, let's see ;)
<didrocks> xnox: at least, when I had my block, it was easy to grep on "didrocks"
<didrocks> common britney, refresh!
<didrocks> come on*
<xnox> 12:53?!
<didrocks> xnox: prediction of 30 minutes + 21s? :p
<xnox> didrocks: it will take more than 21s for britney to process the migration, if it migrates stuff =)
<didrocks> xnox: yeah, so you mean the longer we wait, the more hopeful we can be? :p
<didrocks> xnox: in case I removed the packages before it took them into account :p
<xnox> not this time =(
<xnox> the package is removed, yet britney still thinks it's out of date.
<didrocks> argh, refreshed
<didrocks> yeah
<xnox> oh!
<xnox> yeah =)
<xnox> Valid candidate =)
<didrocks> hum
<didrocks> still failed
<didrocks> failed: qtbase-opensource-src
<xnox> SUCCESS (129/0)
<didrocks> ah
<xnox> loads of stuff did migrate.
<didrocks> yeah :)
<didrocks> why the stenza after then?
<xnox> oh, there are NBS left around.
<didrocks> xnox: I'm not sure to follow you where you are seeing that
<xnox> didrocks: britney treis to remove "old packages" but that's mostly a lie in britneys brain, as those actions are not hooked up to launchpad api whats-so-ever.
<didrocks> ahah
<didrocks> ok, making sense
<xnox> published in release pocket =) no idea if it timedout doing copies, thus one publisher run might be partial ;-)
<xnox> didrocks: well done, sir! =) now the cleanup can proceed.
<didrocks> xnox: thanks for your help as well!
<didrocks> xnox: I'll still retake the list
<didrocks> and grep against next -excuses
<didrocks> to ensure nothing is left
<xnox> didrocks: we definately need another publishing cycle, as quite a few things didn't manage to finish copying. e.g. http://people.canonical.com/~ubuntu-archive/nbs.html is full of lies =)
<didrocks> xnox: yeah, seeing that, I've my grep ready as well :p
<xnox> what do you grep and how? =)
<didrocks> for p in `cat package_list`; do grep $p update_excuses.html; done
<xnox> retrying qtmultimedia-oepnsource-src on powerpc, hopefully sagari will do better (e.g. the one test-suite failure is not seen in debian build)
<didrocks> yeah :)
<apw> it seems that something odd happened maintainer side for hv-kvp-daemon-init, and in 0.4 they inadvertantly reintroduced the i386 build and then removed it, this has triggered an NBS on i386 for the later versions
<xnox> apw: affirmative.
<xnox> didrocks: could you please remove  hv-kvp-daemon-init version 0.4ubuntu0 suite trusty-proposed arch i386
<xnox> it's not-built-from source, yet we have no NBS report for things in -proposed.
<xnox> infinity: didrocks: please promote qt3d-oepnsource-src binaries on arm64/powerpc/ppc64el into main where same binaries are in main on other arches. (e.g. all packages but qtdeclarative5-qt3d-plugin)
<xnox> $ rmadison -S qt3d-opensource-src | grep trusty
<seb128> xnox, looking
<xnox> seb128: thanks.
<seb128> xnox, done
<xnox> seb128: thanks. both requests? =)
<seb128> xnox, no, the nbs thing seemed lower priority :p
<xnox> seb128: but but it's needed for Microsoft Hyper-V hypervisor support.
<xnox> seb128: what can I do for you to process that one as well? =)
<seb128> xnox, looking...
<seb128> $ ./remove-package -s trusty-proposed -a i386 -m "NBS" hv-kvp-daemon-init
<seb128> Removing packages from trusty-proposed:
<seb128> 	hv-kvp-daemon-init 0.4ubuntu3 in trusty
<seb128> 		hv-kvp-daemon-init 0.4ubuntu3 in trusty amd64
<seb128> hum
<xnox> no.
<seb128> what did I do wrong? ;-)
<xnox> $ rmadison -S hv-kvp-daemon-init | grep trusty
<xnox>  hv-kvp-daemon-init | 0.3ubuntu9         | trusty           | source, amd64
<xnox>  hv-kvp-daemon-init | 0.4ubuntu0         | trusty-proposed  | i386
<xnox>  hv-kvp-daemon-init | 0.4ubuntu3         | trusty-proposed  | source, amd64
<xnox> seb128: i only wanted the 0.4ubuntu0 and i386 removed.
<seb128> oh, -b
<seb128> xnox, I know, I was just wondering why it was listing amd64
<seb128> I did "n" that btw
 * xnox is not a trained AA at all, so i'm not sure about the utils much.
<seb128> I got confused, change-override defaults to binaries
<seb128> remove-package is the opposite, you need to -b
<xnox> yeah, -b seems to do the right things.
<seb128> $ ./remove-package -s trusty-proposed -a i386 -m "NBS" -b hv-kvp-daemon-init
<seb128> Removing packages from trusty-proposed:
<seb128> 	hv-kvp-daemon-init 0.4ubuntu0 in trusty i386
<seb128> Comment: NBS
<seb128> Remove [y|N]? y
<seb128> xnox, ^ done
<xnox> apart from: lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized, for me =)
<xnox> seb128: yeah, looks good! thanks =)
<seb128> yw!
<cjwatson> xnox: FYI the touch-release people are only supposed to have permissions to block/unblock, not to apply arbitrary hints
<xnox> cjwatson: ok, i thought didrocks was normal-release as well. I guess AAs are not actually included in ~ubuntu-release, despite the large overlap.
<apw> seb128, thanks
<seb128> yw!
<infinity> Anyone object to me breaking our "never release on Fridays" rule for tzdata, so I don't forget about it later and anger Turkey? :P
<ScottK> infinity: Please go ahead.
<infinity> Have our tools become sentient?
<infinity>   [ CI bot ]
<infinity>   * fixes the segfault occuring when the scale factor is < 1.0 (LP:
<infinity>     #1288166)
<mdeslaur> oh wow, can I fork that for a CVE fixing bot?
<dbarth> hey there
<dbarth> slangasek: hi, i guess that will fall on your plate somehow, but i'm trying to make sure you guys are aware of the FFE request for Oxide
<dbarth> on the desktop
<dbarth> https://bugs.launchpad.net/libunity-webapps/+bug/1290535
<ubot2> Launchpad bug 1290535 in webbrowser-app (Ubuntu) "[FFE] Webapps support for the new Oxide container" [Undecided,New]
<dbarth> alex-abreu can fill you in later in the day if you need info/status
<slangasek> dbarth: thanks for the info
<xnox> infinity: yes they have. =) i've noticed a few uploads like that ;-)
<xnox> infinity: at times, it steals my commits like that, because they are merged up due to conflicts and thus somehow the change gets attributed to the ci bot committer, instead of myself.
<rsalveti> can someone help getting qtcreator-plugin-cmake promoted?
<infinity> rsalveti: Yeahp.
<infinity> But first, explain this:
<infinity> +Depends: libc6
<rsalveti> thanks
<rsalveti> yeah, not sure yet
<rsalveti> oh, it's indeed in the dep list of debian/control
<infinity> rsalveti: Yes, that's just plain wrong.
<rsalveti> indeed
<infinity> rsalveti: Looks like dh_shlibdeps needs to be called to scan the plugin .so directory.
<infinity> Let me experiment a tad.
<rsalveti> great, thanks
<infinity> Erm, lolz.
<infinity> override_dh_shlibdeps:
<infinity>         # Qt Creator does not have shlibs, so this hack is needed to build this plugin
<infinity>         dh_shlibdeps -XlibCMakeProjectManager.so
<infinity> And that's why it has broken deps.
<infinity> WHY?
 * infinity tests without that to see what they were trying to work around.
<slangasek> is that a package in the archive and who can I have drawn and quartered?
<infinity> slangasek: Yes, and pick someone.
<infinity> slangasek: It's qtcreator-plugin-cmake
<infinity> Looks like you get to stab Mirv.
<slangasek> man
<slangasek> infinity: how did you assign blame?  These are all ppa copies, so launchpad shows nothing of who did what. :P
<infinity> slangasek: changelog.
<infinity> Anyhow, this is what happens without the hack:
<infinity> dpkg-shlibdeps: error: no dependency information found for /usr/lib/x86_64-linux-gnu/qtcreator/libExtensionSystem.so.1 (used by debian/qtcreator-plugin-cmake/usr/lib/x86_64-linux-gnu/qtcreator/plugins/QtProject/libCMakeProjectManager.so)
<slangasek> am I looking at the wrong package?
<infinity> Why the solution wasn't to FIX THE PACKGAE PROVIDING THE LIBRARY, I don't know.
<slangasek> no, I'm sure I cut'n'pasted qtcreator-plugin-cmake right
<slangasek> and bzoltan != Mirv
<infinity> slangasek: https://launchpad.net/ubuntu/+source/qtcreator-plugin-cmake/3.0.1-0ubuntu4 ?
<infinity> Looks Mirvy to me.
<slangasek> oh, because my apt-get source didn't look at -proposed, I really should fix that
<infinity> pull-lp-source, FTW.
<infinity> Lets you get rid of deb-src lines in sources.list too, which is a big win.
<slangasek> but then I have to trust https instead of gpg
<slangasek> (how's that for an off-the-cuff post-hoc rationalization?)
<Mirv> yep, me, the new upload just added the comment, and the manual dependency as suggested at ci-eng
<Mirv> it's the same as lp:qtcreator-plugin-ubuntu, from where the SDK Team copied the packaging
<infinity> Mirv: Really?  Who suggested a manual dep on libc6, so I can poke them with a broadsword?
<infinity> It seems there are attempts all over here to shoot yourselves in the foot.
<infinity> From qtcreator:
<infinity> override_dh_makeshlibs:
<infinity>         # qtcreator doesn't provide any public libraries
<infinity> So, if it's not public, why are other packages linking to it?
<infinity> If it is public, why are you skipping shlibs?
<infinity> This is pretty black and white.
<infinity> Mirv: So, I'm not entirely joking.  We should hunt down the origin of this manual libc6 dep and educate the person who was giving bad advice.
<Mirv> infinity: http://irclogs.ubuntu.com/2014/03/14/%23ubuntu-ci-eng.html#t09:09
<infinity> Mirv: And we also need to fix this "no shlibs for libraries that other packages are obviously linking with" mess.
<Mirv> it was probably not very well studied suggestion
<Mirv> within all the multitaskin at that point of time
<Mirv> infinity: upstream doesn't support 3rd party plugins, so it's a hack made by sdk team to be able to have something to build against
<Mirv> and to not need to ship the plugins in qtcreator source
<infinity> Mirv: If these are pure plugins, and you expect the qtcreator dep to satisfy all the deps it needs, that might be fine, but you still don't need a libc6 dep.
<infinity> Mirv: Unless you honestly think someone's going to sort out how to run dpkg and install qtcreator without having a C library installed.
<ScottK> There's even a lintian check for this.  http://lintian.debian.org/tags/package-depends-on-hardcoded-libc.html
<Mirv> yeah, it was substituting a lintian error with a warning
<Mirv> I guess it was the lintian error that made didier want to push to change something, just that the something was worse than not doing it
<infinity> Mirv: So, my take would be that qtcreator should have a shlibs that makes anything with a plugin dep depend on qtcreator >= $upstream, and then you could get all your deps from dpkg.
<Mirv> anyway, bzoltan + zbenjamin can look at it next week
<Mirv> a bug would be welcome, 11pm here
<infinity> This is quite important, as a plugin could depend on OTHER external libraries, and you're now skipping resolving those.
<infinity> I might do better than a bug, and instead submit patches.  We'll see how much my anger fuels me.
<Mirv> thanks
 * infinity keeps boggling at this packaging...
<roaksoax> infinity: howdy! did you happen to upgrade the firmware on the P8?
<infinity> +DEB_LDFLAGS_MAINT_APPEND  = -Wl,--as-needed
<roaksoax> err
<roaksoax> nevermind
<infinity> ^-- If only that were the toolchain default or something.
<infinity> roaksoax: The firmware I was asked not to upgrade?
<infinity> Err, also, ECHAN.
#ubuntu-release 2014-03-15
<zequence> I've got two UI freeze exceptions, that I'd need to get sponsored. Wallpaper change, mostly...
<zequence> bug 1292806
<ubot2> Launchpad bug 1292806 in ubuntustudio-default-settings (Ubuntu) "UI Freeze exception - wallpaper change for Trusty release" [Undecided,New] https://launchpad.net/bugs/1292806
<zequence> bug 1292805
<ubot2> Launchpad bug 1292805 in ubuntustudio-look (Ubuntu) "UI Freeze exception - wallpaper for Trusty release" [Undecided,New] https://launchpad.net/bugs/1292805
<darkxst> stgraber, infinity, slangasek: Do you want me to attend to the TB meeting on monday re Ubuntu GNOME LTS proposal?
<infinity> darkxst: Doesn't hurt to show up.  Unless it's the middle of the night for you.
<xnox> why is python3.3 still listed as supported?
<infinity> xnox: Because it is?
<darkxst> infinity, ok, will do, its actually a reasonably ok timeslot for me
<xnox> ..
<xnox> The output from $ rmadison webkit ; looks odd
<infinity> xnox: Looks like someone did an update in saucy only.
 * infinity just copies it forward.
<infinity> Oh, webkit needs a bison FTBFS fix in trusty anyway.
#ubuntu-release 2014-03-16
<xnox> infinity: yeah, i have that. will upload.
<infinity> xnox: Oh, shiny.  Please do.
<xnox> infinity: it's the same thing that was fixed in the other 4 webkits. yay for embedding broken 3rd party libs =)
<infinity> Heh.
<xnox> go
<infinity> xnox: That might still fail on ppc64el, BTW, I've got two local patches here for that.  Testing.
<xnox> infinity: yeah, probably.
<xnox> infinity: also are we not wasting time? e.g. isn't src:webkit replaced by src:webkitgtk ?
<infinity> Something's still holding it in main.  Didn't bother to look at why.
<xnox> infinity: both build same binary packages... thus sure all reports are going to say it's held up.
<infinity> Erm, you seem to be right...
<infinity> Perhaps I should double-check that and just remove the source. :P
<xnox> https://bugs.launchpad.net/ubuntu/+source/webkit/+bug/1261721
<ubot2> Launchpad bug 1261721 in webkit (Ubuntu) "RM: webkit -- ROM; renamed to webkitgtk" [Undecided,Confirmed]
<infinity> Yeahp, it takes over all the binaries.  La la la.
<infinity> Removing and cancelling all those builds.
<xnox> mine / your twiddling it re-introduced it in trusty-proposed, but it indeed is not in trusty =)
<xnox> ta =)
 * xnox goes to sleep, before doing more pointless things
<infinity> xnox: The source was in trusty, just not the binaries.
<infinity> xnox: Fixed now.
<xnox> cool.
<xnox> no idea why empathy is not migrating, it's clearly is installable.
<ogra_> it probably doesnt feel empathic enough today
<infinity> xnox: No it's not.
<infinity> Or, rather, it wasn't installable on all arches.  Did it just migrate anyway? :P
<infinity> Looks like.
<infinity> Oh, and not listed in uninst, so maybe it got sorted while I slept.
<xnox> well, i fixed some *signon* component, but then britney migrated them one-by-one, instead of trying them together =/ oh well.
<xnox> infinity: if only dee-qt got fixed, it would unblock a wave of packages.
<infinity> xnox: Yeah, if you want to take a stab at that, be my guest.  Colin was looking, but gave up, and I haven't had a chance yet.
<infinity> (And have some human interaction outside the house to deal with today)
#ubuntu-release 2015-03-09
<ScottK> SpamapS: ^^^
<shijing>  
<sil2100_> Hello! Could anyone from the ubuntu-mir team take a look at https://bugs.launchpad.net/ubuntu/+source/qtquickcontrols-opensource-src/+bug/1429836 ?
<ubot93> Launchpad bug 1429836 in qtquickcontrols-opensource-src (Ubuntu) "[MIR] qtquickcontrols-opensource-src" [Undecided,New]
<sil2100_> It's currently blocking desktop builds
<bzoltan_> mlankhorst: ping
<mlankhorst> pong
<bzoltan_> mlankhorst: I have forwarded a mail to you. We have been reported a serious looking sdk issue.
<bzoltan_> mlankhorst: https://askubuntu.com/questions/592614/cant-install-ubuntu-sdk-after-installing-ubuntu-14-04-2
<mlankhorst> *looks*
<mlankhorst> I seem to have no problem with the one from the archive on my machine, so adding a bunch of hints to the package might help
<bzoltan_> mlankhorst: I have checked with all possible people (Mirv, alex-abreu and myself) that we did not touch the SDK specific bits or the Qt packages in LTS anywhere.
<bzoltan_> mlankhorst:  First of all :) I would love to understand what the problem is... and what causes it
<mlankhorst> probably that some of the -dev packages don't install with the lts-utopic stack enabled
<bzoltan_> mlankhorst:  how can that happen?
<mlankhorst> -dev packages are a weird corner case
 * bzoltan_ is ashamed for his ignorance on the topic
<mlankhorst> the packages on the lts stack are renamed and stuff
<mlankhorst> so xxx-dev becomes xxx-dev-lts-utopic
<mlankhorst> but other packages might still require xxx-dev, to handle that I add a provides: xxx-dev, but if that package is not installed you're out of luck..
<bzoltan_> mlankhorst: what do you suggest to do? broken SDK is far from fun :)
<mlankhorst> sec
<mlankhorst> running updates in my chroot first
<popey> mlankhorst: I tested this in a clean 14.04.2 vm, which is where the paste in the au post came from
<mlankhorst> yeah
<mlankhorst> # apt-get install ubuntu-sdk libegl1-mesa-dev-lts-utopic  libgles2-mesa-dev-lts-utopic libgbm-dev-lts-utopic  libegl1-mesa-drivers-lts-utopic libgl1-mesa-dev-lts-utopic
<mlankhorst> or shorter.. # apt-get install ubuntu-sdk-libs-dev libgl1-mesa-dev-lts-utopic libgles2-mesa-dev-lts-utopic
<bzoltan_> mlankhorst:  good stuff, thank you.   Where should it be added? to the ubuntu-sdk?
<mlankhorst> no idea tbh :P
<bzoltan_> popey:  ^ would you please test this
<mlankhorst> it depends on whether you have the hwe stack or not
<popey> ok
<popey> mlankhorst: bzoltan_ http://paste.ubuntu.com/10568517
<popey> (from pasting your first command into a 14.04.2 vm)
<mlankhorst> that's correct right?
<mlankhorst> second command should work too, but shorter
<popey> well, it doesn't error...
<popey> and more importantly it doesn't want to remove anything
<mlankhorst> second command's probably the one you want
<popey> well, the command I really want is "apt-get install ubuntu-sdk" :)
<popey> http://paste.ubuntu.com/10568538/
<mlankhorst> what if you add depends: libgl1-mesa-dev-lts-utopic | libgl1-mesa-dev, libgles2-mesa-dev-lts-utopic | libgles2-mesa-dev to ubuntu-sdk-libs ?
<bzoltan_> popey: well, we need to convince the LTS edition of the ubuntu-sdk to do that
<bzoltan_> popey: who has the license to upload to Trusty a change like this?
<popey> usual SRU process
<popey> !sru
<ubot93> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<bzoltan_> !ok
<ubot93> You're welcome! But keep in mind I'm just a bot ;-)
<bzoltan_> Thanbk:D
<mlankhorst> bzoltan_: bah, explicitly adding the other -dev packages resulted in reverting back to unrenamed stack :(
<bzoltan_> mlankhorst:  crap
<bzoltan_> mlankhorst:  so if I add these dependencies to the ubuntu-sdk-libs-dev then it will revert to the unranemed stack when installed?
<mlankhorst> maybe if I add a bit more help to the resolver
<bzoltan_> mlankhorst: the ubuntu-sdk-libs-dev comes from the seeds... and SRU'ing a seed is something what turns opn big red lights and noisy sirens :D
<mlankhorst> ah second attempt works..
<ogra_> bzoltan_, well, we just have never done it before (i think) ...
<ogra_> it is likely solvable
<mlankhorst> bzoltan_: https://launchpadlibrarian.net/199746287/ubuntu-touch-meta_1.126.2~ppa1_1.126.2~ppa2.diff.gz
<cjwatson> That's a creative interpretation given that we SRU metapackages (via seeds) to introduce the HWE stacks in the first place
<ogra_> ah !
<ogra_> bzoltan_, see :)
<mlankhorst> hm works with the hwe stack, trying without..
<cjwatson> Well, as it happens it seems we haven't actually SRUed ubuntu-meta for the HWE stacks - but at any rate it's not true that it's some kind of forbidden thing
<cjwatson> It would be assessed like any other change
<mlankhorst> bah, breaks without the hwe stack..
<mlankhorst> cjwatson: any idea how I can give the resolver hints to solve this correctly?
<cjwatson> Not sure, sorry
<cjwatson> Try mvo
<mlankhorst> ok
<mlankhorst> bzoltan_: could it be done manually somehow?
<bzoltan_> mlankhorst: manually?
<mlankhorst> yeah
<mlankhorst> if iyou're on the hwe stack, use this command, else use this command
<bzoltan_> mlankhorst:  the installation guide of the SDK is pretty skinny https://developer.ubuntu.com/en/start/ubuntu-sdk/installing-the-sdk/
<bzoltan_> mlankhorst:  I do not think we can do that.
<mlankhorst> ok
<bzoltan_> mlankhorst:  the simple installation of the SDK is one of the fundamental requironment :(
<bzoltan_> mlankhorst:  as a workaround we can suggest to the victims of this problem to install those packages manually, but I would not canonize this as official installation
<mlankhorst> it's a pain regardless..
<mlankhorst> the apt solver would need to be changed to fix it
<tgm4883> Reading the backlog now. Is there an issue with the daily ISO builds? Trying to find the systemd images for testing
<cjwatson> tgm4883: yes, it was fixed earlier today, except for Ubuntu desktop which is blocked on https://bugs.launchpad.net/ubuntu/+source/qtquickcontrols-opensource-src/+bug/1429836
<ubot93> Launchpad bug 1429836 in qtquickcontrols-opensource-src (Ubuntu) "[MIR] qtquickcontrols-opensource-src" [Undecided,New]
<cjwatson> (the problem was that upstart was still priority: required and so was installed by debootstrap)
<tgm4883> cjwatson: ah, so the one that I looked at on cdimage.ubuntu.com that I thought would definitely be updated is the one that hasn't been
<tgm4883> but the rest do seem to be there :)
<tgm4883> cjwatson: thanks, I'll pull some down and do some testing
<bzoltan_> mlankhorst: It is pain indeed. I though that it could be escapated to the apt too.
<mlankhorst> *tests one more thing*
<mlankhorst> meh :/
<mlankhorst> I'll look at it more tomorrow
<bzoltan_> mlankhorst: Thank you.
<jamespage> please can a member of the release team review bug 1426761 and bug 1423601
<ubot93> bug 1426761 in pacemaker (Ubuntu) "[FFe] Upgrade pacemaker to 1.1.12" [Medium,New] https://launchpad.net/bugs/1426761
<ubot93> bug 1423601 in ceph (Ubuntu) "[FFe] ceph 0.93 -> hammer release" [High,New] https://launchpad.net/bugs/1423601
<jamespage> I'd like to get those landed asap if possible
<flexiondotorg_> cjwatson, If I wanted to add an armv7hf device to Ubuntu MATE, do I need to modify debian-cd, livecd-rootfs and ubuntu-cdimage?
<cjwatson> Probably just ubuntu-cdimage
<cjwatson> (etc/default-arches)
<flexiondotorg_> cjwatson, Thanks. That's enough to be me started.
<cjwatson> Also probably worth getting into the habit of calling it just "armhf", which is the Ubuntu architecture name for it
<flexiondotorg_> cjwatson, My Arch background seeping through. Sorry.
#ubuntu-release 2015-03-10
<doko> please could somebody hint doxygen? the libreoffice autopkg test seems to be unrelated
<slangasek> what generates http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg ?  I can't find any references to 'svg' in ubuntu-archive-tools
<doko> slangasek, it's a pitti thing
<slangasek> well I know he worked on it
<slangasek> but why is it not in the bzr repo?
<slangasek> doko: doxygen hinted in
<doko> thanks, will fix a rebuild test package
<slangasek> cjwatson: do you have any hints why the chart at the bottom of http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed has a scale from 0 to 3000 when the max value is somewhere in the vicinity of 50?
<LocutusOfBorg1> Hi release team, the problem is simple, somebody uploaded a mesa-lts-utopic into trusty, as well as a xorg-lts-utopic.
<LocutusOfBorg1> I would like to have a virtualbox-lts-utopic, since people are complaining about uninstallabilities
<LocutusOfBorg1> aka bug 1424769
<ubot93> bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Undecided,Confirmed] https://launchpad.net/bugs/1424769
<LocutusOfBorg1> I did the work, I just need to know if and how it can be uploaded :) thanks!
<LocutusOfBorg1> (BTW I'm the vbox maintainer, if that matters)
<jamespage> Laney, would you have capacity to review a couple of FFe's for me?
<Laney> jamespage: I will carve out some time later on
<jamespage> Laney, thanks - the bugs are https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1426761
<jamespage> and
<ubot93> Launchpad bug 1426761 in pacemaker (Ubuntu) "[FFe] Upgrade pacemaker to 1.1.12" [Medium,New]
<jamespage> https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1423601
<ubot93> Launchpad bug 1423601 in ceph (Ubuntu) "[FFe] ceph 0.93 -> hammer release" [High,New]
<cjwatson> slangasek: the svg is handled in lp:~ubuntu-archive-tools/+junk/scripts, archive-reports
<cjwatson> slangasek: as for the graph, there's a spike up to 3000ish clearly visible here, somewhere around late October / early November; maybe decide whether you want to trim that from the csv data, move the start point of the graph (but I think it's useful for the graph to cover at least a year, so that we can see patterns across multiple release cycles), or somehow clip the y axis?
<bzoltan_> mlankhorst: hello, do you have any news?
<mlankhorst> not yet
<mlankhorst> I've put up a package in my ppa that should probably work, but doesn't..
<mlankhorst> meh, maybe it's easier if I just allow the unrenamed -dev packages to work with the renamed stack
<mlankhorst> bzoltan_: I've uploaded a fixed mesa to ppa:mlankhorst/ppa I hope, it should allow the unrenamed -dev packages to work with the renamed stack
<LocutusOfBorg1> ping #release people
<bzoltan_> mlankhorst:  Cool, thanks
<mlankhorst> bzoltan_: can you verify it works with the ppa?
<bzoltan_> popey: ^
<popey> sure thing!
<bzoltan_> popey: thanks a lot
<popey> mlankhorst: bzoltan_ looks good - http://paste.ubuntu.com/10574337
<popey> np
<bzoltan_> mlankhorst:  it is a thumbs up
<mlankhorst> good
<mlankhorst> it's a bit of an awful hack but meh :p
<mlankhorst> shoe strings is all that's keeping it together
<mlankhorst> x
<slangasek> cjwatson: oh; strange, when I reloaded that page it rendered the spike this time, yes
<slangasek> cjwatson: can we do logarithmic scale with YUI?
<cjwatson> slangasek: http://yuilibrary.com/yui/docs/api/files/charts_js_NumericImpl.js.html#l86 suggests yes
<slangasek> right :)
<cjwatson> so in styles -> axes -> values I guess?  see make_chart
<cjwatson> (u-a-t, charts.py)
<elfy> back again after leaving you all alone for a while - last 2 days our images haven't got to desktop, digging it seems that reinstalling upstart-bin and restarting, once at a desktop you can install
<elfy> reboot after install and you have to reinstall u-bin and restart again
<infinity> elfy: I take it your desktop uses upstart user sessions?
<DalekSec> infinity: Yes it does.
<DalekSec> infinity: For some reason, though upstart-bin is installed, /sbin/initctl is missing.
<infinity> That seems... Special.
<DalekSec> Quite, had me wondering for sure.
<elfy> seems to be our cycle ...
 * infinity blames live-build, and goes digging.
<DalekSec> Thanks.
<infinity> Ahh, yeah.  I see the bug.
<elfy> \o/
<infinity> elfy: Is there a bug filed for this (I don't need one, just want to know if I should be closing one)
<elfy> infinity: no bug - had only really started looking in the last few hours, suspected systemd oddities yesterday
<elfy> so hadn't even thought about what to report it against
<infinity> elfy: Fix uploaded.
<elfy> infinity: thanks - you're awesome :)
<elfy> when you buy me the beverage you owe me - I'll get you one at the same time :p
<infinity> Hah.
<infinity> elfy: FWIW, if you're curious about live-build internals, this is my fix: http://launchpadlibrarian.net/199864700/live-build_3.0~a57-1ubuntu14_3.0~a57-1ubuntu15.diff.gz
<elfy> always curious - one day it might make sense to me too ...
<elfy> I'd be more curious perhaps to see where you went digging - as far as I've got is looking at the likes of http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/vivid/
<infinity> elfy: I just started with grepping livecd-rootfs and live-build sources for initctl. :P
<infinity> elfy: Though, the livefs log also hints at it.
<infinity> [2015-03-10 10:01:47] lb_chroot_upstart install
<infinity> P: Configuring file /sbin/initctl
<infinity> ^-- From the livefs build log, which traces back to the bit in live-build that I mangled.
<elfy> oh right ok
<ochosi> infinity: thanks a bunch for looking into (and fixing!) the issue elfy mentioned before!
<infinity> elfy: In parallel, I was also grepping /var/lib/dpkg/info/* for "initctl" on my laptop to see if maybe a postinst was doing something stupid.
<infinity> elfy: So, yeah.  Just a question of having a fairly good idea where to look.
<elfy> :)
<DalekSec> Ah, nice.
<DalekSec> infinity: And right, that's what I did, as well as checking dpkg-divert.
<jamespage> bdmurray, hey - I've been holding back on the ceph 0.80.8 point release sru verification as there was a performance regression - 0.80.9 is now out - are you OK for me to ref the same point release bug in the changelog?
<bdmurray> jamespage: that's fine, you might also look at bug 1420647 which is in the sponsorship queue.
<ubot93> bug 1420647 in ceph (Ubuntu Utopic) "Please apply nofile limit fix of ceph-osd to trusty, utopic" [Undecided,New] https://launchpad.net/bugs/1420647
<jamespage> bdmurray, already in testing with 0.80.9 :-)
<jamespage> rbasak had pinged me re that one
<bdmurray> okay, then I'll unsubscribe sponsors
<jamespage> bdmurray: ack
#ubuntu-release 2015-03-11
<bluesabre> All packages related to https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1424887 have been uploaded or rebuilt. Is there anything additional that needs to be done for these packages to exit -proposed?
<ubot93> Launchpad bug 1424887 in xfce4-settings (Ubuntu) "[FFe] Xfce 4.12 for Vivid" [Undecided,Triaged]
<infinity> bluesabre: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt implies that you may have missed some rebuilds.
<infinity> The following packages have unmet dependencies:
<infinity>  orage : Depends: libxfce4util6 (>= 4.9.0) but it is not going to be installed
<infinity> Etc, etc.
<infinity> bluesabre: I can help with a bunch of transition rebuilds tomorrow, but not tonight, I've been "asleep" for the last 5 hours (though, clearly not very well).
<bluesabre> infinity: ah, wasn't aware of this page.
<bluesabre> thanks
<infinity> bluesabre: Taking the output from that page and plugging it into apt gets you this: http://paste.ubuntu.com/10579534/
<infinity> bluesabre: Ask me tomorrow, and I'll do a bunch of no-change rebuilds for you.
<bluesabre> awesome, thanks infinity
<LocutusOfBorg1> ping: how can I have a virtualbox-lts-utopic into trusty? (built against lts-utopic packages) I already have it
<LocutusOfBorg1> (I'm the maintainer, I don't know if I need just a sponsor or something else)
<jamespage> Laney, thanks for the reviews - uploading pacemaker now and finding a willing AA for the new ceph binaries
<happyaron> can anyone prompt fcitx related packages to main (approved mir #1356222)? It's added as dependency of other main packages just now
<infinity> happyaron: Looks like extra-cmake-modules needs an MIR too?
<infinity> Though, it's probably a no-brainer.
<happyaron> infinity: I patched that package to not use ECM atm, and will file MIR for it later
<infinity> happyaron: And wxpython and wxwidgets?
<happyaron> avoided Build-Depends and uploaded, it's a runtime only dependency for a leaf package that we don't use, see bug 1430923
<ubot93> bug 1430923 in presage (Ubuntu) "Remove wxpython from build dependency" [Medium,Fix committed] https://launchpad.net/bugs/1430923
<infinity> happyaron: Ahh, that published 4 minutes ago.  You might be jumping the gun on asking me to review the situation. :P
<infinity> Need to wait for all the reports to settle and look sane.
<happyaron> ok, ;-)
<happyaron> infinity: report at component-mismatches looks good now
<infinity> happyaron: Promoted the 5 source packages that c-m was wanting to move, and closed the related tasks on the MIR bug.
<infinity> happyaron: Leaving the rest open, as I assume you have plans to pull in more later.
<happyaron> infinity: thanks!
<slangasek> cjwatson: I think I have to come to the conclusion that scaleType: logarithmic is just plain broken <sigh>
<xnox> ...
<xnox> why was btrfs-tools synced in?
 * xnox is confused
<xnox> and of course it claims that cjwatson's archive robot did it
 * xnox thought we were past automated debian syncs
<cjwatson> we are
<cjwatson> slangasek: ah :/
<cjwatson> xnox: note that the robot does proposed-migration too - you probably need to look one more entry back in the publishing history
<slangasek> I managed to get it to do /something/ by moving the scaleType declaration up out of 'styles' directly into an 'axes' property; but all it seems to do is botch the rounding of the scale rather than providing actual logarithms, somehow
<xnox> cjwatson: it really looks like https://launchpad.net/ubuntu/+source/btrfs-tools/+publishinghistory 3.17-1.1 was synced about 14h ago
<xnox> seems odd, that it was not e.g. sync-package like request with attribution as to who did it.
<cjwatson> xnox: no
<cjwatson> xnox: that's when it got past proposed-migration
<infinity> xnox: It was autosynced in november.
<xnox> oh i see now
<cjwatson> xnox: the SPPH in -proposed has published on 2014-11-22
<xnox> bah well, good that it's in now =)
<xnox> and thanks to however noticed and fixed that.
<xnox> when will we put pypy in main, to avoid patching out pypy packaging out of everything?
#ubuntu-release 2015-03-12
<bluesabre> infinity: I uploaded everything I had rights to, remaining items under PENDING on http://paste.ubuntu.com/10583712/
<bluesabre> knome has also completed the xubuntu slideshow, in case you're also up for uploading ubiquity-slideshow-ubuntu
<bluesabre> Heading to bed now, will be back in a few hours
<bluesabre> oh, and I did verify that all the items under PENDING continue to build as expected, so that is also out of the way
<bluesabre> let me know if you need anything additional from me :)
<mlankhorst> ty
<rbasak> I presume bug 1422892 is moot and doesn't need an FFe because Juju has an exception?
<rbasak> Any objections to me just uploading when ready?
<ubot93> bug 1422892 in juju-core (Ubuntu) "Exception for Juju 1.23 (systemd)" [Undecided,New] https://launchpad.net/bugs/1422892
<rbasak> Though it was provisional, and we've had one successful one now. So I guess I need to ask for it to be made full.
<infinity> rbasak: Yeah, go ahead, though it would be nicer if the systemd support landed sooner. :/
<rbasak> infinity: thanks. For systemd, I just updated bug 1409639 with the current plan.
<ubot93> bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] https://launchpad.net/bugs/1409639
<rbasak> AIUI systemd support is committed upstream but won't be released for a while yet. Beta expected very soon.
#ubuntu-release 2015-03-14
<wxl> hey infinity are you the one to bug to get https://wiki.ubuntu.com/VividVervet/Beta1 up?
<wxl> (seems you are) :)
<infinity> wxl: Get it up in what respect?  It seems to be there.
<darkxst> infinity, not to mention beta 1 has been and gnome ;)
<wxl> infinity: oops, meant https://wiki.ubuntu.com/VividVervet/Beta2
<infinity> wxl: That would be me, yes.
<infinity> darkxst: Can't decide if that was a terrible pun or a strange typo.
<wxl> infinity: ok, trying to get started ahead of time because i'm going to be gone next week as well as gilir so i will need to elect a replacement
<infinity> wxl: Well, it's a wiki, feel free to copy and waste from the previous beta and empty the fields. :P
<wxl> infinity: yes, dear. :)
#ubuntu-release 2016-03-14
<rbasak> infinity: opinion on bug 1528583 please?
<ubot5> bug 1528583 in mysql-5.6 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
<infinity> rbasak: My opinion without reading it is that we should probably do it for support longevitiy reasons, but I should read the bug first. :P
<flexiondotorg> infinity, Could I get an ack on an FFe please? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1556869
<ubot5> Launchpad bug 1556869 in ubuntu-mate-welcome (Ubuntu) "FFe: ubuntu-mate-welcome 16.04.4 new release [debdiff and tarball attached]" [Undecided,New]
<flexiondotorg> infinity, It is only seeded in Ubuntu MATE. Is specific to Ubuntu MATE. Has 3 developers. And we need this so we then translator are finished it can be multi-lingual.
<infinity> flexiondotorg: 1.2MB diff?  Impressive.
 * infinity groans at ./edgar-allan po
<flexiondotorg> Yeah, we just went with it ;-)
<infinity> flexiondotorg: It's entirely unreviewable, but seems fine in spirit.  And you have plenty of motivation to fix it if/when it explodes in your face, so go for it.
<flexiondotorg> infinity, Can I quote you in the comment of that bug :-)
<infinity> flexiondotorg: Yep.
<flexiondotorg> infinity, Thanks. And it is well tested and we absolutely are motivated to fix it.
<flexiondotorg> infinity, Where are you today?
<rbasak> infinity: did you manage to look at bug 1528583 please?
<ubot5> bug 1528583 in mysql-5.6 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
<infinity> rbasak: Okay, caught up on the bug.  LGTM, but please see the transition and migration through to completion ASAP.
<rbasak> infinity: ack. Thanks!
<infinity> rbasak: And I hope that this work with Lars is ending up back in Debian too.  I don't want to see us forking.
<rbasak> infinity: yes, it is. I'm DM for mysql in Debian now. Though this would be a new source package.
<infinity> rbasak: Sure, I just meant packaging changes in general shouldn't be forked if we can help it.  Carry on.
<coreycb> hello, can an archive admin please promote python3-osprofiler to main?  python-osprofiler is already in main.  this will help get some openstack packages out of dependency waits.
<coreycb> infinity, ^
<infinity> coreycb: On it.
<infinity> coreycb: And done.
<coreycb> infinity, thanks!
<andyrock> hey I would like to propose a FFe
<andyrock> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/676457
<ubot5> Launchpad bug 676457 in unity (Ubuntu Xenial) "[FFe] Launcher - Add 'launching' state to launcher icons" [Medium,In progress]
<andyrock> tell me if you need something more
<ogra_> infinity, eeek ... why multivers and not restricte for rpi ?
<ogra_> *restricted
<infinity> ogra_: Because the kernel is in universe.
<ogra_> :(
<infinity> ogra_: If the kernel moves, happy to move the firmware with it.
<ogra_> yeah, given thats our reference arch for snappy armhf it should really move to main
<infinity> Guessing some people don't want to get bitten by the omap4 reference arch thing where we committed to supporting a dead platform for 5 years. :P
<ogra_> haha, yeah
<infinity> (Almost done!)
<ogra_> * ppisati hat die Verbindung getrennt (Quit: leaving)
<ogra_> LOL !
<ogra_> we scared him away
<knome> infinity, what's yourr estimation on the possibility to see the xubuntu base stuff for beta 2?
<infinity> ogra_: The thing with universe is that we can still hold the kernel team to the same standard, Canonical can still claim and sell support, but we make no promises to the community.  So, if we only claim it's supported for, say, a year, we can give up after that.
<ogra_> funnily there are still people coming to #pandaboard ... even 4 years after it went out of prod.
<infinity> ogra_: Given that argument, I'd say universe is where BSP kernels belong.
<ogra_> yeah
<infinity> knome: Good.
<ogra_> i remember doing that for the ac100 video drivers back in the days
<knome> infinity, great to hear; be in touch if anything comes up
<ogra_> and with snappy it doesnt really matter much where the deb comes from ... as long as it lands in the snap store in the end
<infinity> ogra_: It matters where it comes from if you want provenance for the source. :P
<infinity> ogra_: But, yes, the component it comes from doesn't matter.
<ogra_> not even the deb as long as your snap description points to the git tree
<infinity> ogra_: Pointing to a git tree is a very sketchy way to "provide" source unless you control it.
<ogra_> in the snappy world debs are just interim steps after all
<infinity> (So, fine for Canonical trees that we promise not to break, abysmal for anything else)
<ogra_> yeah, indeed ... i meant kernel.ubuntu.com ... not some random github source :)
<infinity> kernel.ubuntu.com isn't the source for those kernels, though.
<infinity> Err.
<infinity> It is.
<ogra_> heh
<infinity> Somehow, I read kernel.org
<infinity> Even while typing ubuntu.com
<infinity> I'm not having the best day. :P
<ogra_> jetlag galore i guess ?
<infinity> Jetlag, evil abdominal pain, brain malfunction.  A bit of a mixed bad.
<infinity> s/bad/bag/
<apw> they really should be made into .debs so they get some review before we ship them, as snap seems to designed to avoid that
<infinity> It took me 7 tries to type my GPG passphrase earlier.
<ogra_> oh my
<ogra_> apw, sure, but the user doesnt care ... and snappy doesnt either ...
<ogra_> (we do, but thats a process thing)
<infinity> Indeed, but it's a handy way to QA, at least for now.
<ogra_> yeah
<infinity> Down the road, I assume we'll have sane automated QA for kernel snaps generated directly from source.
<infinity> We don't today.
<ogra_> and its indeed helful for flavours
<ogra_> *helpful
<ogra_> but after all tteh deb is just a by-product ...
<infinity> There's also, in this case, the promise that we're providing deb-based images too. :P
<infinity> So, then obviously doing the kernel once is smarter than twice.  So, build a deb, slam the binaries in a snap, everyone wins.
<ogra_> yeah, just talking from a snappy view here
<infinity> ogra_: Yeah.  But please be careful about selling the "snappy is the future, the distro is dead" thing, cause that (wrong) message has travelled pretty far, and we're trying to undo it.
<ogra_> it is definitely more convenient because we have pocesses around debs in place today ... but its not actually required from a tech POV
<infinity> ogra_: Mark seemed shocked at the last sprint to find out that journalists and users think we're going that way.
<infinity> So, for at least raspi2 and dragonboard, where we're also providing a deb-based ubuntu-server, the question is moot.  The deb isn't a "by-product", it's a real product and, indeed, the snap ends up a handy repackaging of the same binary.
<knome> infinity, maybe it would help if there was clear communication about the situation
 * ogra_ never said it is an exclusive way
<infinity> For OEM devices, doing a deb is probably pointless, and they can snap directly.
<knome> infinity, with flavors and all relevant teams too, not only with end-users
<infinity> knome: Yeah, the messaging was a mess a year ago or so, and I think there needs to be some cleanup to fix that.  I'll see if I can get the right people involved to undo some of that.
<knome> mhm, nice to hear that too :)
<infinity> knome: If it's any consolation, Mark's been adamant (to the point of nearly shouting at people) that the classic apt/deb distro is not going away, neither now, nor in the future.  It's here to stay until no one wants distros anymore or Ubuntu dies a horrible death for unrelated reasons.
<ogra_> i dont get where journalists would have gotten that ... it was made pretty clear in all the UOS talks, keynotes etc
<apw> i get that impression when listeing to discussions about snaps mostly, and i know better
<infinity> knome: The one caveat to that is that we might stop packaging a select few bits and require flavours to ship the snappy binary package to do snappy-on-desktop if they want to get those apps from us.  But we're still sorting out how all that might work (and, of course, you'd be free to get together and maintain those apps as debs if you prefer that option, no one would stop you).
<knome> infinity, yeah, i'm not worried about the situation itself, it's just that sometimes the message does get out the wrong way (as we know) and if these things aren't communicated to flavor teams and other teams linked to ubuntu, it also means that those teams do not have any more confidence in X than the end-user
<infinity> ogra_: Messaging around desktop-next hurt a lot.  People really thought we were dropping apt/deb entirely.  And even now, people refer to it as "snappy" and "classic Ubuntu" (and I've even heard "legacy Ubuntu").  Classic and legacy are not adjectives that make people think we want to keep the product around.
<ogra_> true
<infinity> Realistically, common sense says that we have millions of server/cloud users and tens of thousands of desktop users who would rise up with pitchforks and do Very Bad Things to us if we actually stopped producing the apt/deb distro, but that doesn't stop the FUD from spreading.
<ogra_> well ... and its a fact that the phone (and thus the convergence desktop) will at some point be snappy based
<ogra_> this might or might not extend to the normal desktop too, who knows ... but i dont think anyone of us ever claimed thats a done deal (or that debs wouldnt be supported in that case, they are today in snappy)
<ogra_> the actual prob are journalist assumptions around this ... and a very blurry definition of what snappy actually is ... even internally
<ogra_> infinity, btw ... your battling aginst the "classic" term might be a bit moot ... to enable deb support in todays snappy you literally have to run "snappy enable-classic"
<infinity> ogra_: Yeah, I know.
<ogra_> and thats a mark naming
<infinity> ogra_: Not only am I aware of that, but I also saw it wipe out utlemming's laptop live and in person!
<ogra_> lol
<infinity> Yeah, not so lol for him.
<ogra_> i'm not talking about the "snappy on classic deskktop" thing
<infinity> mvo fixed the bug an hour later, but lacking a time machine, that didn't get his home directory back.
<ogra_> i'm actually talking about the other way round
<ogra_> (deb support on a native snappy install)
<infinity> I know.  But "enable-classic" does/did Very Bad Things when run on a classic desktop.
<infinity> Which was entertaining from a distance.  Painful up close.
<ogra_> oh, he ran "snappy on classic deskktop" and there he ran snappy enable-classic ?
<infinity> Yep.
<ogra_> thats insane, we shouldnt support it
<ogra_> (there is definitely no need for such an inception ... )
<infinity> Anyhow, back to the original topic:
<infinity> apw: Do you concur that tossing BSP kernels in universe (combined with main-like quality requirements and Canonical statements of support) is the sane way to handle things so we don't get stuck supporting a BSP for 5 years again, a la omap4/amradaxp/keystone?
<apw> infinity, that sounds sane to me, as that lets us dial back support to product life
<infinity> apw: To me, it seems much saner, so long as from our end we act as if it were in main, but we're making no bold promises to the community about lifecycle.
<ogra_> omap4 wouldnt ave been that bad, had TI not decided to drop it completely right after 12.04 release :)
<apw> infinity, that fits my mental model ...
<infinity> ogra_: omap4 isn't actually hard to rebase/support (neither is armadaxp or keystone), but in all cases, the contracts ran out before the community support did, and that seems like a bit of a screw up.
<ogra_> well, effectively the omap4 work is wasted time
<ogra_> no matter if for contract or community ... the HW is gone
<ogra_> (since about a month after the release that brought the support)
<ogra_> infinity, apw, that remonds me, we'll have to look at the wifi firmware for the dragonboard too
<ogra_> i guess that will be in the same camp then
<ogra_> *reminds
<ogra_> paolo has a package in his embedded PPA already
<doko> infinity, do you have an idea about https://launchpad.net/ubuntu/+source/mmpong/0.9.1-3build2 ?
<infinity> doko:
<infinity> -- checking for one of the modules 'CEGUI-OPENGL'
<infinity> -- disabling mmpong-gl because of missing dependencies.
<infinity> doko: Not that the cmake output is very helpful about what it's looking for, but that cmake snippet is probably sort of readable.
<doko> oops, that was the wrong one. was looking for the uninstallability of the smc b-d's
<cyphermox> infinity: would you have time to review libcxl today?
<infinity> cyphermox: Dunno.
<flexiondotorg> infinity, Any news on Base?
#ubuntu-release 2016-03-15
<ginggs> Would someone look at an FFE for me please? LP: #1555586
<ubot5> Launchpad bug 1555586 in lazarus (Ubuntu) "FFe: Sync lazarus 1.6+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1555586
<doko> ginggs, done. please close the issue once built
<ginggs> doko: danke
<doko> when I'm looking at http://archive.ubuntu.com/ubuntu/dists/xenial/Contents-amd64.gz searching for vendor_ruby/2.2, I still see a lot of matches, while most of these packages were updated. why?
<ginggs> Would someone please look at another FFe to fix FTBFS please? LP: #1557527
<ubot5> Launchpad bug 1557527 in doublecmd (Ubuntu) "FFe: Sync doublecmd 0.7.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1557527
<mdeslaur> can someone please denew lynx? it's lynx-cur that got renamed
<mdeslaur> jdstrand: perhaps you? ^
<jdstrand> mdeslaur: looking
<mdeslaur> jdstrand: thanks
<jdstrand> mdeslaur: ok it is building in xenial-proposed: https://launchpad.net/ubuntu/+source/lynx/2.8.9dev8-4. I also moved it so main since lynx-cur was in main in wily
<mdeslaur> jdstrand: great, thanks
<jdstrand> idr if the binaries will have to be moved to main if the source already is. need to keep an eye on that. will need a binNEW as well
<jdstrand> mdeslaur: hmm, it seems to be ftbfs
<mdeslaur> jdstrand: ah crud, I'll take a look, thanks
<jdstrand> np
<seb128> https://bugs.launchpad.net/ubuntu/+source/wxwidgets3.0/+bug/1329779 needs a ffe right?
<ubot5> Launchpad bug 1329779 in wxwidgets3.0 (Ubuntu) "[ffe] Sync from Debian Unstable | Migrate to gstreamer 1.0" [High,Confirmed]
<seb128> it's about migrating wxwidgets3 from gstreamer 0.10 to 1.0
<seb128> which is a non trivial change
<seb128> Bryan Quigley argued on the bug that it's a "bugfix" change but it doesn't really sounds like one
<slangasek> seb128: I would agree that it's FFe material
<seb128> slangasek, thanks
<seb128> I've updated it to be one
<teward> so, i've got a pending nginx bug that needs FFe review before I upload; it's been there for about a month, and appears stuck somewhere in the queue, can anyone look at it?
<infinity> teward: #?
<teward> it'd help if i weren't putting all my RAM to pending sbuild runs, standby
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1549347
<ubot5> Launchpad bug 1549347 in nginx (Ubuntu) "[FFe Requested] Please update nginx to 1.9.12" [Undecided,New]
<teward> upload is ready to go, but i didn't want to upload without a review done (to avoid getting yelled at).  WOuld have asked earlier, but was ill the past week or so, which prevented it,
<infinity> teward: Commented.
<teward> infinity: thanks, as soon as the three workflow scripts which are running sbuilds for other things here are done, and extra cycles and RAM released back to the system, i'll upload.  :)
<teward> hmm, that's new, infinity can you take a peek at this and give insights?  https://launchpadlibrarian.net/248257573/buildlog_ubuntu-xenial-s390x.nginx_1.9.12-0ubuntu1_BUILDING.txt.gz
 * infinity raises his eyebrow.
 * teward has never seen a "cannot fork" error in any nginx build on any arch, even in Debian archs
<cjwatson> I'd guess accidental forkbomb.
<teward> hmm
<infinity> Indeed, but curious that it would accidentally bomb only one arch.
<infinity> The machine looks fine, though.
<cjwatson> Logic error in configure?
<infinity> Ima give it another try and hope for random luck.
 * teward starts scanning upstream redmine for weird arch config issues, just in case
<teward> s/redmine/trac/
<infinity> cjwatson: CANNOT UTIME.
<infinity> I'm afraid that error message has forever ruined the word "cannot" for me.  At least, when it comes from a computer.
<infinity> teward: Looks fine on a second pass, so whatever accidental bomb is in there, it's nondeterministic (and probably not arch-specific).
<infinity> Whee.
 * teward shrugs
<teward> infinity: it's odd, every other upload appears to get a nondeterministic failure for some odd reason
<teward> and it's never the same arch :/
<infinity> The sign of a quality upstream.
<teward> the nondeterministic failures I've seen are all ddeb related :/
<teward> never had it blow up in the configure stages
<infinity> Oh.  The sign of a quality distro? :)
<infinity> (or you have improper recipe dependencies in your debian/rules, which is more likely)
<teward> possibly, though it seems to be a recurring issue.  The debian/rules is essentially verbatim from Debian, minus http2 stuff per sec team request
<infinity> Oh look, that issue just hit your armhf build.
<teward> indeed
 * infinity doesn't retry it.
<teward> heheh
<infinity> Not yet anyway.
<teward> i'm going to let the others finish first :)
<teward> they'll either blow up, or succeed, then retry :)
 * teward appears to have a 'retry build' button :)
<infinity> Yeah, I'm intentionally not retrying, so I can sucker pitti into looking at it.
<infinity> It could well be a race in pkg-create-dbgsym.  Or it could be your fault.
<teward> I wonder if it's a race, or if it's in the way the system runs - at one point I think you said it may be a result of how the rules define how the build should run, but that was long enough ago I lost logs
<infinity> teward: See #-devel.  It's a bug in pkg-create-dbgsym that it doesn't have better locking, but could be worked around by not attempting to be so agressively parallel.  *shrug*
<teward> infinity: splitting time across five windows, standbly
<teward> infinity: ack
<teward> I'm curious why Debian is being aggressive with parallel builds, that part's from them
<teward> i think I'll poke them, and see if there's a specific reason they did it that way, before adding to the delta further
<infinity> teward: Nah, I wouldn't worry about it.  I think I'm getting a handle on why out tooling sucks.
<infinity> s/out/our/
<teward> indeed.  *is watching #-devel himself*
<flexiondotorg> infinity, Any news on Base?
<infinity> flexiondotorg: Not yet.  Patience (and slightly less pinging).
<flexiondotorg> infinity, OK. I was only pinging because I thought that was the instruction. I'll back off.
#ubuntu-release 2016-03-16
<superm1> can someone accept fwupdate* out of unapproved?  the uefi binaries don't appear to be landing at http://archive.ubuntu.com/ubuntu/dists/xenial-proposed/main/uefi/fwupdate-amd64/
<apw> superm1, cirtainly if it is in unapproved for uefi bits they will not be in dists till they are approved
<cjwatson> superm1: done
<superm1> Thanks
<ginggs> would someone look at firmware-extract in NEW please?  it's not really new, it was temporarily removed while python-support was being removed.
<zequence> Hi. We did a rename of a meta package recently, which is unfortunately keeping our ISOs from building. Could someone please replace ubuntustudio-font-meta with ubuntustudio-fonts in the live-build config for us?
<zequence> http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/config#L350
<cjwatson> zequence: done
<zequence> cjwatson: Big thanks
<sakrecoer> thank you very much cjwatson ! :)
<sakrecoer> and also, hi all! as of now i wont say much since i'm still learning, but i will stick arround and try absorbe as much info as possible
<sakrecoer> sorry also perhaps i should write i'm the next ubuntu studio project-lead, holding the flame after zequence. doing my best to catch up on everything :)
<cyphermox> could someone please review libcxl in xenial NEW ? it's been sitting there for a month ;)
<seb128> cyphermox, so go stuff are sitting since decembre, you are lucky ;-)
<cyphermox> haha ;)
<seb128> cyphermox, how is the n-m ffe going btw?
<cyphermox> I review go if you review libcxl?
<cyphermox> moving forward, at least the testing is getting done, it looks real solid so far
<cyphermox> last night I ported the dnsmasq patch to work again, I needed some alcohol to get that done
<cyphermox> down to fixing typos here and there, but the annoying part is done, so I'll get back to it tonight, or over lunch
<seb128> cyphermox, I can try to have a look once I'm done with the nautilus changes I'm working on (if nobody beats me to it)
<cyphermox> seb128: i wouldn't be able to ack go anyway
<seb128> cyphermox, don't bother about those, I was just pointing it out
<seb128> seems like we lack archive admin reviews this cycle (and probably not only that)
<infinity> cyphermox: I'll look at libwhosit.
<infinity> seb128: Yeah, doko and I had a chat about that at Connect.  Might be time to reinstate AA day rotations to at least make sure some people are sometimes processing the queue.
<seb128> unsure how well the rotations work with everybody been too busy, but people doing some work every now and then would be nice
<infinity> cyphermox: I'm surprised that in all this time, you didn't get it into Debian and just sync. :P
<seb128> I've been mostly trying to unblock people who asked about things/needed them to land features or other xenial work
<cyphermox> infinity: not my call, it's in mentors waiting for review, and I'm not a DD
<infinity> seb128: Rotations tend to lead to some people still slacking when super busy, but you get a bit more consistency (and a tiny bit of guilt).
<infinity> cyphermox: Oh.  But you'd be maintaining it in Debian?
<seb128> right
<infinity> cyphermox: You could have asked me to sponsor it there. :)
<cyphermox> infinity: no, frediz would, IIRC
<infinity> (Or did you, and I failed?)
<cyphermox> I may have
<cyphermox> or I foolishly thought that since it was in mentors already it would get sponsored sooner
<infinity> cyphermox: Yeah, mentors seems to be where a lot of packages go to die if you don't actively seek a sponsor.
<infinity>         make VERS_SONAME=$(VERS_SONAME) VERS_LIB=$(VERS_LIB)
<infinity> You're kidding me.
<cyphermox> infinity: I remember telling frediz he should ask around, I know he probably knows one or two DDs who could sponsor it
<infinity> That's not baked into the upstream makefiles?
<cyphermox> nope :/
<infinity> If I were you, I'd push back on them to fix that.  "make && make install" should Just Work.
<infinity> Having every distro declare the SOVER is asking for trouble. :P
<infinity> (And, indeed, if you're declaring SOVER=1, how do you know that's "right"?)
<ogra_> because ABIs are always backwards compatible indeed :P
<infinity>   * Removed libcxl.a from files to ship.
<infinity> cyphermox: ^-- Why?
<infinity> cyphermox: Nothing wrong with shipping a static lib in -dev
<seb128> hum
<seb128> the "current" daily image is from the 07
<seb128> is anyone looking at that?
<xnox> infinity, until broken cmake fails to use a perfect .so and goes into staticly linking all the things.
<infinity> seb128: I guess smoketesting exploded again.  Poke jibel, perhaps?
<seb128> jibel, ^
<infinity> xnox: cmake sucking won't stop me from shipping static libc. :P
<xnox> #rebelheart
<infinity> cyphermox: debian/outfile looks like a copy of debian/source/format for no discernable reason.
<cyphermox> outfile would be wrong, I may have messed up the building + rebuilding
<infinity> cyphermox: And yell at frediz for the license on debian/* not matching /*, the implied license that places on patches makes things awkward.
<xnox> infinity, "debian/outfile" is dh_make bug i think.
<cyphermox> well, it's a catch I didn't notice, anyway
<infinity> xnox: Might be, but dh_make also tells you to look through debian/ and delete what you don't need. ;)
<infinity> cyphermox: If he really cares about the license on debian/* (despite it being mostly uncopyrightable) being GPL-2+, he should probably also have a stanza for debian/patches/* as Apache-2.0, IMO.
<infinity> But that's nitpicking.
<infinity> Hah.  And no working "make install" either?
<infinity> Man, you need to kick IBM for the state of this project upstream being terribad.
 * cyphermox updates the bug
<cyphermox> infinity: thanks for the review
<infinity> cyphermox: So, other than all the above rant, the one thing I might insist on changing would be that they set the VER/SOVER to 0.3/0 until upstream actually bakes a proper SONAME in and agrees to track ABI properly.
<infinity> cyphermox: Cause SOVER 1 implies tracking and consistency across distros, and if we have to set it externally, I don't see how we can promise that.
<cyphermox> infinity: mind if I copy-pasta this verbatim?
<infinity> cyphermox: By all means.
<jibel> seb128, cyphermox was looking into it with max
<seb128> jibel, thanks
<infinity> jibel: current/ seems to break a lot.  Is it that we're producing a crappy distro for you to test, or is the infra a bit brittle and needs someone to actually give it some love?
<infinity> (Willing to believe either, or a mix of both, but I'm betting it's mostly the latter)
<cyphermox> infinity: it oscillates between the two. sometimes it's that we make a crappy distro, sometimes it's that the infra fails in marvelous ways
<cyphermox> this time it looks like it's the latter, and we're looking into it
<infinity> cyphermox: Ta.
<cyphermox> fwiw, I played with the image enough yesterday to know it probably should have automatically transitioned
<cyphermox> and I'm about to start with today's
<infinity> Right, the smoketests aren't particularly deep IIRC, so if it boots/installs/reboots, the fault is in the infra.
<cyphermox> there are also some limited LVM tests IIRC
<cyphermox> but I installed with LVM anyway ;)
<lamont> infinity: (et al): I'm planning (unless you scream) on uploading postfix-3.1.0 as part of my postifx 3 cleanup, since it's (1) minor changes from a very cautious upstream, that (2) we want all of which (3) has had a blanket approval for such things before it loosened up to be general
<lamont> infinity: in other news, bind 9.10.3-P2 ==> -P4 sometime soonish
<lamont> but first Imma fix 1556175
<infinity> LP: #1556175
<ubot5> Launchpad bug 1556175 in isc-dhcp (Ubuntu) "networking.service hangs on shutdown -- killing dhclient has no effect any more" [High,Triaged] https://launchpad.net/bugs/1556175
<infinity> lamont: Oh, yes.  Please fix that. :P
<lamont> infinity: you do not want to read what I did to fix it.
<lamont> upstream dropped the --enable-exportlib support from configure, since you know, dhcp is going to be "just fin"e
<lamont> just fineâ¢, only dhcp isn't there yet.
<infinity> lamont: I don't know postfix upstream well enough to know what I'd expect 3.0.4->3.1.0 to contain, but if it's not featureful and you're sure it's all things we really, really want, I'll trust your judgement.  Be prepared to fix it if it sucks.
<lamont> infinity: yep
<lamont> that won't be before mid-next week though.
 * lamont consults the schedule
 * lamont cries a little.  I guess it'll be Sunday afternoon
<lamont> once I review it more
<lamont> infinity: bind9 is building now (locally) at which point I'm tossing it at a PPA and getting isc-dhcp behind it, and then it'll hit xenial
#ubuntu-release 2016-03-17
<tai271828> hi, I noted desktop current download url is outdated. It provides the link to download xenial-desktop-amd64.iso (timestamp Mar. 3rd) instead of the one with timestamp Mar. 16  http://cdimage.ubuntu.com/ubuntu/daily-live/20160316/
<ginggs> Anyone from ubuntu-archive able to look at removing wine1.6 please? LP: #1558480
<ubot5> Launchpad bug 1558480 in wine1.6 (Ubuntu) "remove wine1.6 package" [Undecided,Confirmed] https://launchpad.net/bugs/1558480
<Odd_Bloke> Could someone accept ^, pretty please?
<apw> Odd_Bloke, your previous build also threw a 'make: py3versions: Command not found' is that resolved in this one ?
<Odd_Bloke> apw: It is not; let me address that.
<apw> Odd_Bloke, also you seemed to have some extraneous change in d/control though just whitespace
<infinity> Removing whitespace from control is a good thing.
<Odd_Bloke> apw: That whitespace was added in ...~12.04.1, so I was just cleaning it up; is that a problem?  (First time actually uploading a package myself, so apologies if I'm beeing a noob :p)
<apw> Odd_Bloke, no that sounds good then
<rbasak> ^^ src:mysql-5.7, FFe bug 1528583. There will be new binaries too (s/5.6/5.7/ and a libmysqlclient soname bump)
<ubot5> bug 1528583 in mysql-5.6 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
<rbasak> infinity: ^^ if you don't mind please.
<infinity> rbasak: Oh fun, a libmysql transition too?
<infinity> rbasak: Are you taking ownership of the transition, or hoping someone from Foundations takes pity on you and does it?
<infinity> rbasak: (please answer the former)
<andyrock> Laney Trevinho https://bugs.launchpad.net/unity/+bug/676457
<ubot5> Launchpad bug 676457 in unity (Ubuntu Xenial) "[FFe] Launcher - Add 'launching' state to launcher icons" [Medium,In progress]
<Laney> yes I keep having other things to do, sorry
<Laney> It would be good if someone else on the release team would look
<rbasak> infinity: I'll take care of it.
<rbasak> infinity: I did point it out in the bug. I thought that's what you were acking.
<infinity> rbasak: I must have missed that bit.
<rbasak> The ABI bump is mainly because they cleaned up symbols that shouldn't have been exported in the first place.
<rbasak> No API-level changes are intended.
<infinity> rbasak: So just a mess of rebuilds, hopefully.
<infinity> rbasak: I'll try to get to the new source sometime today, so we can attempt to get the rebuild madness done over the weekend.
<rbasak> infinity: yes. OK, thanks!
<rbasak> infinity: BTW, you'll probably notice https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/commit/?h=rbasak&id=32cf55d6aaed56b65a68cd07364e1bbd5d1dc3a6
<rbasak> I'm not sure what to do about that, although upstream (who provided it) pointed out that it's like that in libboost-dev also.
<rbasak> I figured that we're not making it any worse. Perhaps a bug against libboost-dev would be appropriate. Not that it's their problem since we're duplicating the headers, but might as well fix it the same way.
<infinity> xnox: WTF, mate, why is boost's copyright empty? :P
<xnox> Hahahaha =)
<xnox> infinity, did i do the last upload as well?! =)
<rbasak> infinity: oh and https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/log/?h=ubuntu/devel might be helpful to you generally if you want to follow packaging changes, as it's a ridiculously big diff otherwise.
<infinity> rbasak: Oh, it's a bit more complicated than that.
<infinity> Files: *
<infinity> Copyright:
<infinity> License: Boost
<infinity>  This software is a collection of libraries from the Boost.org site.
<infinity>  Most of the libraries use the Boost Software License 1.0, which
<infinity>  reads as follows.
<infinity> ...
<rbasak> "Most"
<infinity> rbasak: Yes, and then specific ones are listed later.
<infinity> rbasak: So, yeah, it might be nice if the license was actually checked properly and specified for whatever's bundled.
<infinity> rbasak: (Alternately, stop bundling and use the system boost?  But I'm guessing theirs is forked somehow)
<rbasak> I suspect that upstream's taking just a subset and so they may say that the current file is accurate, but I'll check.
<rbasak> They want to lock the version of Boost IIRC, and it's only the headers they need.
<rbasak> (for the lifetime of 5.7)
<rbasak> I think we discussed this?
<rbasak> I checked with someone, anyway.
<Skuggen> rbasak: o/
<rbasak> Skuggen: infinity was asking about debian/copyright for Boost.
<Skuggen> Yeah?
<rbasak> Skuggen: http://paste.ubuntu.com/15408607/
<rbasak> Skuggen: line 43
<Skuggen> Yeah
<Skuggen> We bundle boost because 5.7 requires 1.59. System version all over is 1.58
<Skuggen> But also because we want to lock it down in case future updates causes issues
<rbasak> Right
<Skuggen> The copyright field is empty because there are a huge number of contributors to boos
<Skuggen> boost*
<rbasak> But separate from that infinity was querying the licensing.
<rbasak> Anyway
<rbasak> Skuggen (upstream) will do what infinity requests. So I'm just trying to get out of the middle :)
<rbasak> BTW, we want to upload the same thing to Debian experimental. If that's relevant.
<rbasak> Debian ftpmasters will have a view on this too.
<Skuggen> Yeah, I left it empty on the assumption that since it's empty in libboost, that's ok
<infinity> Skuggen: "Copyright" is empty in libboost, but the license isn't.
<Skuggen> Wait, is the license empty?
<Skuggen> It shouldn't be
<Skuggen> Ah, the license text
<infinity> Skuggen: Yeah, it's only valid to have empty license text if the license is shipped in common-licenses.
<infinity> Which boost isn't.
 * rbasak thinks he sees a license text.
<rbasak> What am I missing?
<rbasak> https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/commit/?h=rbasak&id=32cf55d6aaed56b65a68cd07364e1bbd5d1dc3a6
<rbasak> Short name Boost, full text at the bottom.
<rbasak> Unless of course it's wrong.
<infinity> rbasak: Oh!
<Skuggen> rbasak, infinity: I'm looking at the copyright file for libboost
<infinity> rbasak: I should learn to scroll.
<infinity> Skuggen: So, uhm.  Nevermind.
<Skuggen> It has a couple of exceptions from the default boost license, but only for files we don't bundle
<Skuggen> Ah :D
<superm1> can someone release fwupdate from unapproved again?  also why does it keep getting put there?
<slangasek> superm1: because there's a signed efi binary artifact, which requires archive admin oversight
<superm1> ah gotcha
<superm1> so grub and shim go through the same thing then each time
<slangasek> yes
<superm1> related question - how is the signed fwupdate EFI binary going to be installed in xenial?  should this be something that happens from installer like happens with grub or should it be seeded and part of the livefs to start?
<slangasek> superm1: I think the expectation is that it would be seeded; I saw something about that in an MIR bug, but it seems only fwupdate was seeded so far, not fwupdate-signed
<superm1> OK, i'll make some relevant seed changes for that
<cyphermox> yes, things will need fwupdate-signed too now, possibly should depend on that rather than fwupdate
<cyphermox> superm1: that means perhaps it would be good to add a package that depends on the right fwupdate-$arch-signed per-arch
<cyphermox> so one can just depends on fwupdate-signed
<cyphermox> hrm, or Provides ;)
<superm1> cyphermox: yeah i was about to  say that sounds like Provides would be better
<superm1> although it's not clear to me that UpdateCapsule is really useful anywhere but amd64
<cyphermox> anyway, something prettier than having seeds depend on different named packages on different architectures, if it's avoidable
<superm1> at least I haven't heard of anything using that on arm yet
<cyphermox> superm1: in theory EFI is EFI; even if no arm boards don't have it, they eventually will
<cyphermox> I suppose we can burn that bridge when we get there ;)
<superm1> that's true, if the binary is building may as well get it all packaged up nicely
<cyphermox> hrm, it's really not that easy
<superm1> cyphermox: i don't see any raw uefi archives for any of the arm builds on the archive, something special needed for them?
<cyphermox> we shouldn't install fwupdate-signed on non-EFI amd64.
<superm1> oh no ESP, that's true
<cyphermox> uefi for arm: I don't know
<superm1> makes me think that it should actually get installed by grub-installer
<cyphermox> I lied, I know
<cyphermox> http://ports.ubuntu.com/dists/xenial/main/uefi/
<superm1> oh not published in archive.*, ports.* ok..
<cyphermox> superm1: I'm not sure grub-installer is the right place for it
<cyphermox> I mean, fwupdate is not grub.
<superm1> you won't actually know if it's an EFI system until you get to install time, so i'd think you either need it seeded in the image and pull it out if you're not an EFI system or don't seed it in the image but add it at install time
<cyphermox> of course
<cyphermox> but you maybe want to have lilo or $random_other_bootloader to boot in EFI and still use fwupdate, even if it's not something we officially support in ubuntu.
<cyphermox> grub-installer is probably the easiest, immediately obvious place one could add fwupdate-signed; but it's probably not the best
<superm1> does d-i give an option to use other bootloaders?  if not, then someone would have to install with grub, install some other bootloader and remove grub still
<cyphermox> d-i have other $bootloader-installer(s)
<cyphermox> s/have/has/
<superm1> oh.  i guess you could argue if someone is wandering down that path with something other than grub they probably don't want the signed fwupdate anyway though
<superm1> because they'd have to worry about signing the other bootloader themselves
<superm1> and then at that point they'll have to sign their own fwupdate anyway
<cyphermox> maybe what we really want for this is some kind of 'fwupdate-installer', that runs iif you're in efi *and* you have some ESRT
<cyphermox> (at least, for d-i. desktop would probably best have the package installed on the image, and removed if !(efi && esrt)
<superm1> once the MIR is done for fwupd and FFE is done for gnome-software i'd expect that fwupdate is going to end up on systems whether you have efi or not and ESRT or not
<superm1> the other interesting thing is it's possible to turn on ESRT for some systems that have it off already, so that's not the right toggle to look at  (https://github.com/rhinstaller/fwupdate/commit/3b08a1622e92c3a9c42f6773214dc3f41f13484b)
<cyphermox> yeah, we should fix that. that's up to ubiquity to figure out whether you're on efi or not
<cyphermox> I could live with the toggle being just "are we in EFI"
<infinity> cyphermox: Isn't that how we already choose to keep grub-signed/linux-signed?
<infinity> cyphermox: We don't require you to be in SB mode, for instance (I hope).
<cyphermox> infinity: moo?
<infinity> Since that would explode if you were in setup mode for install and then rebooted and enabled SB.
<infinity> Moo!
<infinity> cyphermox: Refering to 'I could live with the toggle being just "are we in EFI"'
<superm1> ok if that's the approach to go with, the way to go about this i'm thinking is add a Provides: fwupdate-signed, seed it so ends up in the pool on install media and then somewhere in ubiquity (plugininstall.py?) mark fwupdate-signed for installation if you're in EFI
<cyphermox> infinity: oh, right. but in the case of SB, we know it can be toggled, and we still do check for EFI
<cyphermox> infinity: I didn't remember you could toggle firmware updates
<infinity> Does fwupdate{,-signed} somehow do bad things if your firmware isn't in the right mode or doesn't provide the right interface?
<superm1> no it doesn't
<cyphermox> it just won't do anything
<infinity> If it's just dead code, then I say we just install for all EFI and be done with it.
<cyphermox> infinity: the question is more "do we want to install fwupdate-signed in grub-installer", and my initial reaction was "probably not, there ought to be another way"
<cyphermox> the install for all efi part is easy enough in ubiquity if it's already on the image, and just a little bit more complicated for straight d-i installs
<infinity> cyphermox: Its own installer package might be better for d-i flexibility reasons indeed.
<infinity> It would be trivial.
<cyphermox> right
<cyphermox> well I can cook one later, when I'm done with the upgrade things. or superm1 if you want to play with d-i ;)
<infinity> Anyhow, for the desktop case, you can just seed it to -live and worry about the removal bit.
<infinity> And that seems entirely doable for beta.
<infinity> d-i would be a nice bonus, though.
<cyphermox> yep
<cyphermox> the removal part is in scripts/install.py and scripts/plugininstall.py in ubiquity
<superm1> cyphermox: okay i uploaded fwupdate-signed 1.8 which should do packages all the others archs uefi packages now too and work with a Provides fwupdate-signed.  once AA clears fwupdate* that from the queues (unapproved and NEW) i'll seed that in -live
<cyphermox> cool
<lamont> who is my favorite AA today?  please NEW bind9, kthx
<infinity> lamont: Do you have a favourite?
<lamont> you know you're always my favorite
<lamont> we had to add libisccfg-exportNNN
<lamont> and udeb
<lamont> and once _that_ lands, then I'll upload isc-dhcp, and we can have a party
<infinity> lamont: Waiting on armhf to be done.
<lamont> doh.
<infinity> lamont: I assume you tested all of this somehow?
<lamont> lets go with "yes"
 * teward raises an eyebrow
<lamont> meanwhile, I'll confirm the CVE fixes
<lamont> infinity: your conditions are acceptable :/
<lamont> infinity: give me about 15 min and I will have reconfirmed that
<lamont> infinity: reconfirmed. it's all been tested and retested
<lamont> infinity: and all pending publication
<lamont> and e'rything
<infinity> lamont: Ta.
 * lamont fiddles rome untiul he can upload isc-dhcp
<lamont> isc-dhcp uploaded
<lamont> infinity: ta
<infinity> lamont: I feel like you may have jumped the gun on that upload...
<infinity> lamont: Unless it'll appropriately dep-wait.
<infinity> Which I don't think it will...
<infinity> Oh.  It will, because libbind-export-dev isn't in xenial.  Check.
<lamont> infinity: and it showed as published... not pending.
<lamont> but yeah, sihg
<infinity> lamont: LP lies.
<infinity> lamont: But the dep-wait works, so we're good.  I was about to cancel them all in a panic.
<lamont> worst case would have been a build1, but yeah
<lamont> I will remember that it lies
<infinity> lamont: rmadison is your friend in this case.
<slangasek> tumbleweed: hi, do you still maintain https://code.launchpad.net/~stefanor/+junk/reverse-deps -> http://qa.ubuntuwire.org/rdepends ? I have a feature request
<infinity> lamont: LP records it as "published" when it starts smacking it on disk on ftpmaster, which is long before dists is updated.
<tumbleweed> slangasek: put it this way, nobody else does :)
<slangasek> heh
<tumbleweed> so, if it's a simple feature request, sure
<tumbleweed> otherwise, patches welcome
<slangasek> tumbleweed: but how can I submit patches it's a junk branch!
<slangasek> tumbleweed: the request is that it would be really nice if the reverse-depends command showed when there were alternative deps
<tumbleweed> yeah
<tumbleweed> so, it doesn't track whether a dep is alternate or not
<tumbleweed> this probably means a protocol change
<slangasek> I was figuring it could be shoved into the depends field
<slangasek> i.e. instead of "Dependency": "openjdk-7-jre-headless", it could just say "Dependency": "openjdk-7-jre-headless | default-jre" - no protocol change
<tumbleweed> hrm, that'd work
#ubuntu-release 2016-03-18
<smb> infinity, hm just saw the uploads to bind and dhcp... is it still a lie that dhcp went through and bind is still in proposed?
<smb> practically it seems to work... a little scary though
<Odd_Bloke> Could I get an AA to migrate gce-utils from {wily,xenial}-proposed to {wily,xenial} in partner, please?  The versions in question are 1.3.3-0ubuntu2 and 1.3.3-0ubuntu1~15.10.0.
<apw> Odd_Bloke, should we expect the backport to wily to be an older version than that for xenial ?
<Odd_Bloke> apw: Oh, sigh, the xenial update didn't get backported like I thought it did; thanks for catching that.
<Odd_Bloke> apw: (ubuntu2 is removing a package which we're leaving in wily, and some packaging cleanup, but it's probably worth having them in sync)
<Odd_Bloke> apw: (Could we at least get xenial migrated whilst I fix up wily?)
<apw> Odd_Bloke, if there is a sensible reason xenial has moved on, for a xenail only fix that seems fine to be out of sync, it just looks ok at first view hese the question
<Odd_Bloke> apw: I do want to pull the changes back to wily, so hold off there; xenial is good to go though. :)
<smb> apw, Oh hm, were you thinking that we should send out uploads for apt-cacher-ng for P and T today so they can bake?
<apw> smb, that sounds familiar, vaguly ...
<Odd_Bloke> apw: This new wily gce-utils supersedes the ubuntu2 that's already in the queue. :)
<apw> Odd_Bloke, ack
<Odd_Bloke> apw: Thanks. :)
<infinity> smb: Uhh.  Something's very wrong with the isc-dhcp packaging.
<infinity> smb: Oh.  Or maybe actually bind9.  Hrm.
<smb> infinity, no I think it is kind of ok because the deps are only build deps... but odd
<infinity> smb: No, the deps should be deps.
<infinity> smb: dhclient is linked against those libs.
<smb> infinity, maybe statically?
<infinity> base)adconrad@nosferatu:~$ apt-cache show isc-dhcp-client | egrep '^Version|^Depends'
<infinity> Version: 4.3.3-5ubuntu10
<infinity> Depends: libc6 (>= 2.15), debianutils (>= 2.8.2), iproute2
<infinity> Version: 4.3.3-5ubuntu9
<infinity> smb: ^-- Ick.
<infinity> Depends: libc6 (>= 2.15), libdns162, libisc160, debianutils (>= 2.8.2), iproute2
<infinity> smb: Yes, it could be statically linked in the new build, but that would be a failure on bind9's part too, since dhcp didn't change.
<infinity> smb: What does ldd say on your system?  On mine (running ubuntu9), libdns and libisc are dynamically linked.
<infinity> (For /sbin/dhclient)
<smb> infinity,  a sec
<apw> infinity, oh .. those libdns* htings are all not installable in britney for bind9
<apw> oh no those are all -export versions, hrm
<smb> infinity, nothing of bind9
<infinity> apw: Yeap, looks like packaging errors galore here.
<infinity> smb: Okay, so it ended up statically linked.  Oops.
<infinity> smb: Sounds like lamont buggered up some things. ;)
<smb> infinity, maybe... I never checked for that. Though I did the revert of no-export libs for dhcp
<infinity> smb: Without looking, my assumption is that lib*-export-dev lack a .so
<infinity> And then there's the unrelated bit where the udebs have broken deps.
<infinity> And someone also might have failed to fix the shlibs to account for udebs, so the dhcp-udeb dep will end up right (but no proof of that, just a solid bet :P)
<infinity> lamaaaaaaaaaaaaaant!
<flexiondotorg> Could someone in the release team provide n ack for this FFe please - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1557229
<ubot5> Launchpad bug 1557229 in ubuntu-mate-artwork (Ubuntu) "FFe: ubuntu-mate-artwork 16.04.4 new release [debdiff and tarball attached]" [Low,New]
<smb> infinity, So doko was bringing up other rdeps on #ubuntu-devel. I am not aware of any. Would they not also show up in Britney if there would be any?
<infinity> smb: Why would they?  The bind upload didn't make anything uninstallable.
<infinity> (base)adconrad@nosferatu:~$ reverse-depends -b src:bind9
<infinity> smb: I see a few.  But whether any of them link to the offending library or need to use the export libs (or did in the past), I don't know.
<infinity> smb: Ahh, wily reveals all.
<smb> infinity, I thought maybe in one of the reasons that hold back the new bind9...
<infinity> smb: http://paste.ubuntu.com/15414142/
<infinity> smb: So, old rdeps never used export, it was always just dhcp.
<smb> ah
<smb> and nice... another command I had already installed but never properly used...
<lamont> infinity: it's always been statically linked, I thought
<infinity> lamont: Definitely not.
<infinity> lamont: Or, at least, not since the libbind-dev switch.  Let me check wily.
<infinity> lamont: If it was statically linked, though, you wouldn't need the udebs. :P
<lamont> check sid
<lamont> infinity: good point
<lamont> gar
<smb> fwiw it seems in Trusty it was statically linked as well
<infinity> (wily-amd64)root@nosferatu:~# ldd /sbin/dhclient
<infinity> 	linux-vdso.so.1 =>  (0x00007ffe9c36b000)
<infinity> 	libirs-export.so.91 => /lib/x86_64-linux-gnu/libirs-export.so.91 (0x00007f097f815000)
<infinity> 	libdns-export.so.100 => /lib/x86_64-linux-gnu/libdns-export.so.100 (0x00007f097f4e7000)
<infinity> 	libisc-export.so.95 => /lib/x86_64-linux-gnu/libisc-export.so.95 (0x00007f097f296000)
<infinity> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f097eecc000)
<infinity> 	libisccfg-export.so.90 => /lib/x86_64-linux-gnu/libisccfg-export.so.90 (0x00007f097ecbe000)
<infinity> 	/lib64/ld-linux-x86-64.so.2 (0x000055e4e44d1000)
<infinity> Definitely not static in wily.
<infinity> smb: Yeah, very statis in trusty, but I'd call that a bug, not a feature.
<infinity> The way it was in wily looks most "correct" to me.
<lamont> smb: 9.9.5-5 or -6ish is when the -export stuff came to be
<infinity> lamont: Anyhow, see #ubnutu-devel, doko's mangling it.
<smb> infinity, Yeah I would agree...
<lamont> before that it was a local copy of th elibrary source in dhcpd
 * lamont goes there
<doko> no debian import since two days. anything wrong on our side?
<cyphermox> doko: wasn't DIF on feb 18, or do we no longer do that?
<doko> cyphermox, sure, but we make new versions available, so we can syncpackage them
<Laney> It's a known error in Launchpad, which is being worked on
<cyphermox> oh, ok you mean importing data in LP
<cjwatson> doko: Yes, multiple problems due to Debian archive changes, all of which I'm working on
<cjwatson> In fact I just pushed the last of the necessary fixes up for review
<cjwatson> Dropping {Sources,Packages}.gz and Files/MD5sum fields in experimental caused some havoc in all kinds of places, Launchpad included
<cjwatson> doko: I suspect the fixes will roll out on Monday at this point, unfortunately - (a) most likely reviewer will be asleep now, (b) I was unlikely to get an LP deployment done on a Friday afternoon anyway
<doko> no haste, we can always sync manually if needed
<xnox> infinity, stgraber: could i trick you two into accepting https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1551952 ?
<ubot5> Launchpad bug 1551952 in multipath-tools (Ubuntu) "FFE: Please merge multipath-tools 0.5.0+git1.656f8865 from Debian unstable " [Undecided,New]
<xnox> it's a merge that fixes a bunch of horible things that we are ought to take.
<cyphermox> davmor2: fyi: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1555237
<ubot5> Launchpad bug 1555237 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 14.04.4â 16.04 dies midway taking out the session." [Critical,Confirmed]
 * cyphermox kicks the upgrader around some more
<davmor2> cyphermox: nice so it looks like it is a mix of screensaver and compiz wiping out the system then
<cyphermox> maybe.
<davmor2> willcooke: ^
<cyphermox> the screensaver blanking the screen might be doing something compiz doesn't like
<davmor2> cyphermox: indeed
<cyphermox> I've disabled the screensaver completely for now, we'll see if things carry on happily then
<cyphermox> it's not a fix, but it gives us something to look into
<davmor2> cyphermox: I still blame gcc just cause it doesn't get picked on enough :)
<cyphermox> *shrugs* it could be some really funky thing deep down in the entrails of software, I don't know, but in doubt I rather blame anything other than gcc until I know better.
<cyphermox> ie. if graphics fail, it's far more likely to be the graphics driver or the thing that makes things pretty than say, X, even if X has its own issues.
<cyphermox> then proceed from there with the more likely, once all the likely things are proven not to be the issue, proceed with the unlikely and outrageous ideas
<cyphermox> and I'm gonna need a veggie burger, so back after lunch ;)
<davmor2> cyphermox: yeah but don't forget in 14.04 and 16.04 we have completely incompatible versions of gcc so it could contribute :)
<willcooke> I tried disabling the screensaver during some testing last week
<willcooke> it just postponed the inevitable crash :)
<cyphermox> willcooke: dpms blanking doesn't seem to break the install, at least
<willcooke> O_o
<willcooke> oh
<willcooke> right
<willcooke> so thats good
<willcooke> I thinbk
<slangasek> tumbleweed: uhoh. does reverse-depends also not know about multiarch :any depends?  'reverse-depends -c main src:python-defaults' does not show python-bandit, which Depends: python:any
<tumbleweed> slangasek: it does not
<slangasek> :/
<tumbleweed> at the time, such syntax was not valid
<davmor2> cyphermox: enquiring minds need to know what happened with the upgrade with screensaver off?
<cyphermox> it eventually froze
<cyphermox> not crashed
<cyphermox> so I started over, waiting for the screensaver to come up now, and I think it just did
<cyphermox> yep
<cyphermox> updating compiz + libglib2.0-0 from xenial (and whatever packages that pulls) seems to be sufficient
<cyphermox> that certainly reduces the number of packages to look at already
<davmor2> cyphermox: I don't envy you but good man :) I wish you well in your quest
<cyphermox> davmor2: I reduced it to some 15-20 packages related to compiz and gnome in some way; ie. cairo/pango, unity, wayland, nux, fontconfig, gail, libgtk, libatk, and libbamf, basically
<cyphermox> all desktop stuff, so I'll let eleni look at compiz for now, and just make sure I was wrong about the screensaver not being disabled
<superm1> cyphermox: wouldn't it be safer to spin up a new session with a basic window manager and nothing for users to poke at and "use" to do the upgrade?  something that looked like the session that is used for ubiquity/oem-config
<superm1> you could at least better limit which libraries and apps are getting pulled out from under you
<infinity> superm1: Relogging into a lightweight "upgrade session" has been discussed a few times by a few people.  No one's really specced it or done the work, though.  And it's questionable if everyone would want the feature, so we'd probably still have to support live upgrades.
<infinity> superm1: Though, I think computers might be mostly fast enough today for us to get away with a 2-stage "we downloaded everything, now give us your computer for an hour while we upgrade" thing without people screaming too loudy.
<infinity> tumbleweed: For a closed arch, the simplest way to interpret foo:bar {build-,}deps is just to strip off ':.*' ... This is what Ubuntu's sbuild did, for instance, for a long time. :P
<superm1> infinity: yeah  2 stages is what i was thinking when i mentioned this, and it would allow for a simpler upgrade session that doesn't need network
<infinity> tumbleweed: That's likely the quickest solution for reverse-deps.
<tumbleweed> infinity: it's using python-debian
<tumbleweed> which I think used to choke on those?
<infinity> tumbleweed: Oh.  Well, python-debian knows how to DTRT.
<infinity> But it didn't always, indeed.
<superm1> but i guess it would take some time to spec that out and figure out implementation and that might be more than just bandaiding around the breakage found in live test
<infinity> superm1: Yeah, the big concern I have with it is the bandaid effect.  Yes, LTS->LTS is hard(er), but if people are writing sloppy postinsts and playing fast and loose with dependencies, eventually the same breakage will hit an SRU, which we want to live update by design.
<infinity> superm1: Cause I refuse to move to a Windows "we'll install your software on reboot, no really" model.
<cyphermox> infinity: well, you could tell: reboot to XYZ when you're ready to do the distro upgrade; and stop the user in grub when they do
<cyphermox> (reboot)
<cyphermox> not that pretty, but it could make it a very painfully obvious, limited environment in which to do upgrades
<cyphermox> but that's work, and our thing currently tends to work, ish, except when it doesn't
 * cyphermox kicks compiz
<infinity> cyphermox: Why reboot?  Having an upgrade target in systemd and gunning for it would do the same thing.
<cyphermox> or that, whatever
<infinity> cyphermox: But, yeah, such things encourage the idea that "the upgrader will fix it", which is wrong-headed.
<cyphermox> yeah, I know
<cyphermox> but at least we don't explode because some random very critical lib gets messed up underneat some other very critical piece
<infinity> cyphermox: Maybe if we wrote such a simple upgader environment, the compromise would be that we wouldn't enable it until a week before release, and the rest of the time, developers and power users are "stuck" doing live upgrades and fixing their effin bugs. :P
<cyphermox> wfm
<infinity> cyphermox: So the lightweight upgrader is there to paper over things we didn't notice, rather than paper over everyone being lazy.
<cyphermox> yeah
<cyphermox> I'm not sure this current crash (i'll blame compiz because I can) is about laziness though, really some obscure weirdness
<infinity> Fair enough.
<cyphermox> hah, so it really doesn't matter if there is a screensaver popping up or not, I got the crash anyway
<infinity> But most of those are usually about either undeclared ABI changes (eek) or dependencies not tight enough for other similar reasons, or applications that disagree with you swapping files out from under them, etc.
<cyphermox> I agree
#ubuntu-release 2016-03-19
<clivejo> hi folks, Im trying to open a FFE for kdeconnect-plasma - https://bugs.launchpad.net/ubuntu/+source/kdeconnect-plasma/+bug/1559538
<ubot5> Launchpad bug 1559538 in kdeconnect-plasma (Ubuntu) "FreezeException" [Undecided,New]
<clivejo> Im new to this process and would like some help if possible?
<infinity> clivejo: Your first step would be finding someone willing to package (or sponsor, if you've packaged it) the newer upstream version.
<infinity> clivejo: And then describe the diff, potential for explosions, etc.
<clivejo> its mainly a plugin to provide extra features
<clivejo> so potential for explosion is low
<infinity> clivejo: Sure.  I meant in the bug.  But the first bit is the packaging.  An FFe bug doesn't get the work done.
<clivejo> I just dont like the statement on their Google Play page "*NOTE for Ubuntu users: The Ubuntu folks are not updating their repos as fast as this app gets updated. Some features will not work if the KDE Connect version in you desktop doesn't match the one in your phone. "
<clivejo> I can package it
<clivejo> our Kubuntu CI is constantly building it from KDE Git
<infinity> Kay.  Attach a debdiff to the bug and explain it a bit, and we'll see.
<infinity> Though, if it always needs to be lockstep with the Android app, it may not matter much that it's a few months newer...
<clivejo> is the bug I opened the right way to do it?
<infinity> The bug you opened is the right way to get the release team's signoff, yeah.
<infinity> (I fixed the subject for you, but otherwise fine)
<clivejo> ok, so next step is to get it packaged
<clivejo> what did I do wrong there?
<clivejo> ah
<clivejo> thank you
<clivejo> infinity: do I assign the bug to myself?
<infinity> clivejo: If you're the one working on it, yeah.
<clivejo> can a debdiff be run on LP?
<clivejo> say if the new package is in my PPA, can I compare it to the archive version?
<infinity> You want to grab the old source package and new source package and "debdiff old.dsc new.dsc > foo.diff" and attach that to the bug.
<infinity> LP does generate some diffs, but unless it's generated the one you want, that's no help.  You can't ask it to generate arbitrary ones.
<clivejo> can debdiff handle urls?
<clivejo> apparently not!
<clivejo> ok so I attach this diff as a file to the bug?
<infinity> clivejo: Yep.
<clivejo> ok, attached to bug report
<infinity> clivejo: Seems vaguely reasonable to me.  Can you get a signoff from yofel (and obviously fix the version number to be 0.9+git20160315-0ubuntu1) and upload or find a sponsor?
 * infinity thinks yofel is the Kubuntu RM, but his brain is fried today...
<clivejo> he is indeed
<infinity> Righto.  So, get him to ACK it, fix the version, and upload away, IMO.
<clivejo> Im *trying* to take some of the pressure off him
<infinity> Feel free to copy/paste any of this into the bug. :P
<clivejo> can you highlight what is wrong with the version?
<infinity> The appended ~ubuntu16.04~ppaN obviously. :)
<infinity> Correct for a backporty PPA scenario, not for the archive.
<clivejo> oh thats because its in my PPA
<infinity> (Since the whole point in that version is to get yours to sort lower than the archive version 0.9+git20160315-0ubuntu1)
<infinity> Right.
<infinity> Anyhow, just make sure what gets uploaded is sanely versioned.
<clivejo> yeah sorry, I used the local version which was uploaded to my PPA
<clivejo> do I have upload rights?
<yofel> infinity: ACK from me
<infinity> yofel: Ta.
<infinity> clivejo: If you have to ask, the answer is almost certainly no.
<clivejo> LOL
<infinity> yofel: If you can help clivejo find a kubuntu sponsor for that, it would be lovely.
<yofel> certainly, thanks for the review
#ubuntu-release 2016-03-20
<infinity> superm1: *poke*
<infinity> superm1: +DEB_HOST_ARCH=$(dpkg-architecture -qDEB_HOST_ARCH)
<infinity> superm1: No can do in your postrm.  dpkg-architecture is from dpkg-dev.  I think what you were looking for was ${DPKG_MAINTSCRIPT_ARCH}
<superm1> infinity: yeah?
<infinity> superm1: Which is passed by dpkg to maintscripts based on the arch of the package.
<superm1> Okay I'll fixxy up in an upload this afternoon
<superm1> Thanks
<infinity> superm1: (Even discounting the dpkg-dev issue, your solution would have been wrong because I can install fwupdate-signed:amd64 on an i386 system, for instance)
<infinity> superm1: So, yeah. DPKG_MAINTSCRIPT_ARCH gets you the _$ARCH.deb arch, which is what you're actually after.
<infinity> superm1: Erm, similar issue with your postrm calling lsb_release.
<infinity> superm1: Perhaps bake the vendor in there with dpkg-vendor at build time, or just accept that Debian and Ubuntu will be forked for a little bit and hardcode the distro, or search both paths (which seems harmless)
<infinity> superm1: I'd probably go for the latter, and just 'rm -f /boot/efi/EFI/ubuntu/fwup$EFI_NAME.efi /boot/efi/EFI/debian/fwup$EFI_NAME.efi'
<infinity> superm1: And it looks like the package also needs a dep on lsb-release for the install script... But you might want to avoid that too.
<apw> infinity, it sounds slightly frightening to be removing things from debian ... you might have a dual boot debian/ubuntu
<infinity> Oh, point.
<infinity> Then it makes more sense to bake the distro into the maintainer scripts with dpkg-vendor at build time, IMO, so you *know* where the package came from and what it expects to install.
<infinity> Ditto with the install script, since it should match the postrm.
<infinity> superm1: ^
<superm1> infinity: OK baking it in won't be a problem, thanks apw
<superm1> infinity: ^ that should handle your comments in both packages
<infinity> superm1: You missed the updated build-dep on -signed. :)
<infinity> superm1: Toss me a 1.11 with the correct build-dep, and I think we're good.
#ubuntu-release 2017-03-13
-queuebot:#ubuntu-release- New binary: steam [i386] (zesty-proposed/multiverse) [1:1.0.0.54+repack-2ubuntu3] (no packageset)
<handsome_feng> Good morning! everyone! I'm a member of Ubuntu Kylin, Could someone help to approve the UKUI packages? or one of them first?  Thank you in advance! bug: #1663477, bug: #1664229, bug: #1664232, bug: #1664235, bug: #1664244, bug: #1664247, bug: #1664256
<ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
<ubot5> bug 1664229 in Ubuntu "[FFe] ukui-menu" [Wishlist,In progress] https://launchpad.net/bugs/1664229
<ubot5> bug 1664232 in Ubuntu Kylin "[FFe] ukui-indicators" [Critical,Fix committed] https://launchpad.net/bugs/1664232
<ubot5> bug 1664235 in Ubuntu "[FFe] peony" [Wishlist,In progress] https://launchpad.net/bugs/1664235
<ubot5> bug 1664244 in Ubuntu "[FFe] ukui-control-center" [Wishlist,In progress] https://launchpad.net/bugs/1664244
<LocutusOfBorg> hello, just to understand, is it ok to sync tzdata?
 * LocutusOfBorg sync'd it
<LocutusOfBorg> debdiff was translation-only updates and two timezones that are changing in may
<Laney> LocutusOfBorg: you want to handle SRUing it too, right? :-)
<LocutusOfBorg> Laney, maybe not :p
<LocutusOfBorg> I'm still not confident enough about such tzdata updates
<LocutusOfBorg> they don't even have an SRU bug in previous updates, I always thought they were using some special SRU handling
<cjwatson> LocutusOfBorg: https://wiki.ubuntu.com/StableReleaseUpdates#Data_Packages_Kept_in_Sync_with_Security
<LocutusOfBorg> as said, I would appreciate somebody else doing it :) thanks for the link, it is scary enough to keep me away
<LocutusOfBorg> :)
<apw> LocutusOfBorg, normally infinity does those
<LocutusOfBorg> yes, I hope he will take care, it is too difficult for my brain :)
<LocutusOfBorg> BTW, a quick MIR for libfolks-dummy25? it should already be in main, not sure what went wrong with it
<LocutusOfBorg> libfolks-dummy-dev/armhf unsatisfiable Depends: libfolks-dummy25 (= 0.11.3-2)
<LocutusOfBorg> folks is in main, and rmadison for the libraries is... don't know how to understand the answer
<LocutusOfBorg> not sure how the dev package can be useful with a library in universe (BTW the library has been in universe since the begin, but now somebody corrected the dependency in control file, so now it is picked up by britney)
<jbicha> I don't understand android-sdk-meta/zesty's upload errors
<jbicha> https://launchpad.net/ubuntu/+source/android-sdk-meta/25.0.0+3
<apw> LocutusOfBorg, i assume that is a new binary packag e?
<jbicha> apw: no, folks-dummy isn't new, it's just now being correctly depended on by its -dev package (and the -dev package was in main)
<jbicha> like Locutus said, I'm not sure why folks wasn't fully in main anyway
<Laney> jbicha: It's producing binary packages with the wrong version, or at least with version numbers that are already in use.
<jbicha> Laney: ok I see now (for the android pkg)
<jbicha> darktable/i386 is intentionally being dropped so please let it through zesty-proposed
<apw> jbicha, yeah that is producing binary packages for the previous version not its own version, that is pretty odd
<jbicha> yes it looks like it's fixed in 25.0.0+5 so I'll sync that later
<apw> LocutusOfBorg, libfolks-dummy25 sorted
<LocutusOfBorg> no apw :) (ETOOLATE)
<LocutusOfBorg> ta!
<apw> LocutusOfBorg, ?
<LocutusOfBorg> your question about the new package
<LocutusOfBorg> I was AFK
<apw> oh ... heh, derp, forgot i even asked
<ginggs> jbicha, apw: here' a bug for darktable LP: #1672020
<ubot5> Launchpad bug 1672020 in darktable (Ubuntu) "Please remove i386 binaries" [Undecided,New] https://launchpad.net/bugs/1672020
<apw> ginggs, that is seeded on the ubuntustudio dvd
<ginggs> apw: so should that be removed from ubuntustudio, or is it too late for that now?
<apw> ginggs, i think they need to do something if the package is no longer supported on that arch
<caribou> Repeating a question that went unnoticed : The clamav sync is stucked in -proposed on the MIR for tomsfastmath. MIR is apparently completed so is there anything else to be done to get this sync finalized ?
<apw> caribou, do you have the MIR bug # ?
<caribou> apw: LP: #1619239
<ubot5> Launchpad bug 1619239 in tomsfastmath (Ubuntu) "[MIR] tomsfastmath (runtime dependency of clamav)" [High,Fix committed] https://launchpad.net/bugs/1619239
<handsome_feng> Hi, Could someone in release team help to approve the UKUI packages ? bug: #1663477, Thank you!
<ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
-queuebot:#ubuntu-release- Unapproved: keepalived (xenial-proposed/main) [1:1.2.19-1ubuntu0.1 => 1:1.2.19-1ubuntu0.2] (ubuntu-server) (sync)
<jbicha> 2 metapackages recommend darktable; do we need to fix them before we remove darktable:i386?
<apw> jbicha, i think we do
<ginggs> jbicha: in my experience, recommends haven't been a problem
<jbicha> I'm asking because I think ubuntu-studio-meta's ./update script will automatically detect that darktable isn't available if it's not available
<jbicha> like how Firefox was removed from some ppc architecture just before yakkety was released
<apw> jbicha, yeah as they are mostly meta related, probabally if we have commitment from them to update them
<apw> then we might well be ok
<jbicha> I will follow up to update both metapackages
<apw> jbicha, ok thanks if you say that in the bug i'll get'er'done
<apw> jbicha, which is bug: #1672020
<ubot5> bug 1672020 in darktable (Ubuntu) "Please remove i386 binaries" [Medium,In progress] https://launchpad.net/bugs/1672020
<jbicha> commented on the bug
<apw> ginggs, and gone
<ginggs> apw, jbicha: thanks!
<tash> Hi, is there an exact date for 12.04 EOL?  April 2017 is a little vague.  Is that 4/1/2017?
<apw> tash, it is more normally nearer the say in april it origianally released
<apw> tash, but yes, there should be a formal date announced and soon
<tash> ok thanks
-queuebot:#ubuntu-release- New: accepted orthanc-dicomweb [amd64] (zesty-proposed) [0.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-dicomweb [armhf] (zesty-proposed) [0.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-dicomweb [powerpc] (zesty-proposed) [0.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-dicomweb [s390x] (zesty-proposed) [0.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-webviewer [arm64] (zesty-proposed) [2.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-webviewer [i386] (zesty-proposed) [2.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-webviewer [ppc64el] (zesty-proposed) [2.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-dicomweb [arm64] (zesty-proposed) [0.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-dicomweb [ppc64el] (zesty-proposed) [0.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-webviewer [armhf] (zesty-proposed) [2.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-webviewer [s390x] (zesty-proposed) [2.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-dicomweb [i386] (zesty-proposed) [0.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-webviewer [powerpc] (zesty-proposed) [2.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted orthanc-webviewer [amd64] (zesty-proposed) [2.2-1ubuntu1]
<jbicha> apw: uh, Debian's multimedia-photography is arch: all, so I could either 1) make it arch: any (and add [any-amd64 any-arm64] to Recommends: darktable), 2) drop darktable there
<jbicha> or 3) don't worry about it since it's not a very popular package on Ubuntu
<jbicha> (since multimedia-photography:i386 isn't popular)
-queuebot:#ubuntu-release- Unapproved: supervisor (xenial-proposed/universe) [3.2.0-2 => 3.2.0-2ubuntu0.1] (no packageset)
#ubuntu-release 2017-03-14
-queuebot:#ubuntu-release- New sync: genwqe-user (zesty-proposed/primary) [4.0.18-3]
-queuebot:#ubuntu-release- Unapproved: s390-tools (yakkety-proposed/main) [1.36.1-0ubuntu2 => 1.36.1-0ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8.2 => 1.34.0-0ubuntu8.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: account-plugins (xenial-proposed/main) [0.12+16.04.20160126-0ubuntu1 => 0.13+16.04.20161212-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center-signon (xenial-proposed/main) [0.1.8+16.04.20160201-0ubuntu1 => 0.1.9+16.04.20161212-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<acheronuk> Hi. could someone please take a look at bug #1672672
<ubot5> bug 1672672 in krita (Ubuntu) "[FFe] Krita 3.1.2.1 for zesty" [Undecided,New] https://launchpad.net/bugs/1672672
<acheronuk> thanks :)
<caribou> apw: we have an issue with makedumpfile 1.5.5 in Trusty : it only supports up to kernel 3.19
<caribou> apw: with the xenial_lts kernel, we're up to 4.4 so I'm not convinced that cherry-picking fixes would be viable
<caribou> apw: do you think that it would be acceptable to SRU the 1.5.9 version from Xenial into trusty ?
<caribou> question opened to any of the SRU team members of course
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.2 => 5.5.1+dfsg-16ubuntu7.3] (kubuntu, qt5, ubuntu-desktop) (sync)
<apw> caribou: it is fixing dumping for a supported kernel, so i think so
<caribou> apw: yes indeed
<caribou> I'll have a peek at the differences in commit,but it would be safer to bring the whole version in
<Mirv> hi. could you perhaps comment whether you could override the camitk i386 tests, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src ? the release has been stuck in proposed for some time.
<Laney> Mirv: http://autopkgtest.ubuntu.com/packages/c/camitk/zesty/i386 doesn't look too good for the new qtbase, does it?
<Mirv> Laney: it seems to except no warnings etc, thus parsing a long string wrong. that's why I asked for a comment and whether Trevinho should revisit the landing or if it's deemed that the test is a bit badly written.
<Mirv> c/p/
<Laney> Mirv: I'd imagine it's not too hard to fix the test if it's a parsing error, and then you can get some more confidence about your upload.
<Mirv> ok
<Mirv> Trevinho: ^ FYI
<oSoMoN> seb128, hey, webbrowser-app is blocked in -proposed because it depends on ubuntu-ui-extras which is in universe but has been approved for main inclusion: bug #1666556
<ubot5> bug 1666556 in ubuntu-ui-extras (Ubuntu) "[MIR] ubuntu-ui-extras" [Undecided,Fix committed] https://launchpad.net/bugs/1666556
<oSoMoN> could you by any chance unblock it by promoting ubuntu-ui-extras to main?
<sil2100> mterry: hey! Does an AA have to do the promotion or do ubuntu-mir guys have the power to do so? ^
<mterry> sil2100: need an AA
<sil2100> oSoMoN: so it didn't happen automatically in the end?
<mterry> oSoMoN: sil2100 : but it won't be promoted unless something is pulling it in
<mterry> Does anything depend on the extras package?
<sil2100> mterry: webbrowser-app now depends on it
<mterry> ah I see, that's the issue above  :P
<oSoMoN> sil2100, no it wasnât automatically promoted, IÂ had misremembered what ahayzen said
-queuebot:#ubuntu-release- New binary: ubuntu-mate-artwork [amd64] (zesty-proposed/universe) [17.04.2] (ubuntu-mate)
<ahayzen> Hey, I'm looking for a reviewer to do a "preNEW review" of two new packages (qtubuntu-print and ubuntu-printing-app) that I have in silo 2236 (https://bileto.ubuntu.com/#/ticket/2236), would anyone here be able to do this?
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20170214.1-0ubuntu0.12.04.1 => 1:20170314.1-0ubuntu0.12.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170214.1-0ubuntu0.16.04.1 => 1:20170314.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170214.1-0ubuntu0.14.04.1 => 1:20170314.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20170214.1-0ubuntu0.16.10.1 => 1:20170314.1-0ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (yakkety-proposed/universe) [0.15+16.10ubuntu1 => 1.0+16.10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [0.15+16.04ubuntu1 => 1.0+16.04ubuntu1] (no packageset)
<chrisccoulson> Is there anyone who can approve the adobe-flashplugin uploads in partner please?
<chrisccoulson> (for all releases)
-queuebot:#ubuntu-release- Unapproved: pam-mysql (xenial-proposed/universe) [0.7~RC1-4ubuntu2 => 0.7~RC1-4ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pam-mysql (yakkety-proposed/universe) [0.7~RC1-4.1ubuntu1 => 0.7~RC1-4.1ubuntu1.1] (no packageset)
<bluesabre> RAOF1, if you are around, would you be interested in releasing thunar into xenial- and yakkety-updates? https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1512120
<ubot5> Ubuntu bug 1512120 in thunar (Ubuntu Yakkety) "[SRU] thunar crashes on file renaming" [Undecided,Fix committed]
<jbicha> RAOF: please reject gnome-shell/xenial and /yakkety
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (xenial-proposed) [3.18.5-0ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (yakkety-proposed) [3.20.4-0ubuntu3]
<RAOF> jbicha: Done.
<RAOF> bluesabre: And done.
<RAOF> Thanks for the ping.
<bluesabre> RAOF, thank you very much!
<Beret> j #i3
<acheronuk> Hi. Could someone please the FFe in bug #1672672 thanks
<ubot5> bug 1672672 in krita (Ubuntu) "[FFe] Krita 3.1.2.1 for zesty" [Undecided,New] https://launchpad.net/bugs/1672672
<acheronuk> *please look at
#ubuntu-release 2017-03-15
<tjaalton> I've staged new xserver and driver rebuilds on a ppa. should they be copied to proposed or just uploaded normally? now that we have -proposed migrations and whatnot, the risk of packages slipping in -updates prematurely seems slim
<chrisccoulson> hi, could someone please approve yesterday's adobe-flashplugin updates (for all releases)
-queuebot:#ubuntu-release- New: accepted devhelp [amd64] (zesty-proposed) [3.23.92-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [armhf] (zesty-proposed) [3.23.92-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [powerpc] (zesty-proposed) [3.23.92-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [s390x] (zesty-proposed) [3.23.92-0ubuntu1]
-queuebot:#ubuntu-release- New source: hsail-tools (zesty-proposed/primary) [0~20170314-1]
-queuebot:#ubuntu-release- New: accepted devhelp [arm64] (zesty-proposed) [3.23.92-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [ppc64el] (zesty-proposed) [3.23.92-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [i386] (zesty-proposed) [3.23.92-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted steam [i386] (zesty-proposed) [1:1.0.0.54+repack-2ubuntu3]
-queuebot:#ubuntu-release- New: rejected genwqe-user [sync] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: rejected genwqe-user [sync] (zesty-proposed) [4.0.18-3]
-queuebot:#ubuntu-release- New: accepted ubuntu-mate-artwork [amd64] (zesty-proposed) [17.04.2]
-queuebot:#ubuntu-release- New: accepted genwqe-user [sync] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: accepted ubuntu-wallpapers [amd64] (zesty-proposed) [17.04.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted hsail-tools [source] (zesty-proposed) [0~20170314-1]
<jamespage> bdmurray: hello - covering for zul this week - have added a test case to bug 1567807 which was the second bug referenced in the changes for nova in xenial under bug 1668313
<ubot5> bug 1567807 in Ubuntu Cloud Archive mitaka "nova delete doesn't work with EFI booted VMs" [High,Triaged] https://launchpad.net/bugs/1567807
<ubot5> bug 1668313 in nova (Ubuntu) "[SRU] mitaka point release" [Undecided,Confirmed] https://launchpad.net/bugs/1668313
<jamespage> bdmurray: to confirm that's fix released in zesty (included in final rc for Ocata) and is included in the yakkety update for newton already in proposed - commented on the bug to that effect.
-queuebot:#ubuntu-release- New binary: genwqe-user [amd64] (zesty-proposed/none) [4.0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [i386] (zesty-proposed/none) [4.0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hsail-tools [ppc64el] (zesty-proposed/none) [0~20170314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [armhf] (zesty-proposed/none) [4.0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [ppc64el] (zesty-proposed/none) [4.0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [arm64] (zesty-proposed/none) [4.0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [s390x] (zesty-proposed/none) [4.0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hsail-tools [arm64] (zesty-proposed/none) [0~20170314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hsail-tools [amd64] (zesty-proposed/none) [0~20170314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hsail-tools [armhf] (zesty-proposed/none) [0~20170314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [powerpc] (zesty-proposed/none) [4.0.18-2] (no packageset)
<oSoMoN> can an AA please promote qtdeclarative5-ubuntu-ui-extras0.2 to main? its MIR has been approved (bug #1666556), and itâs blocking the migration of webbrowser-app from proposed
<ubot5> bug 1666556 in ubuntu-ui-extras (Ubuntu) "[MIR] ubuntu-ui-extras" [Undecided,Fix committed] https://launchpad.net/bugs/1666556
-queuebot:#ubuntu-release- New binary: genwqe-user [arm64] (zesty-proposed/none) [4.0.18-3] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [ppc64el] (zesty-proposed/none) [4.0.18-3] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [amd64] (zesty-proposed/none) [4.0.18-3] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [armhf] (zesty-proposed/none) [4.0.18-3] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [i386] (zesty-proposed/none) [4.0.18-3] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [s390x] (zesty-proposed/none) [4.0.18-3] (no packageset)
-queuebot:#ubuntu-release- New binary: genwqe-user [powerpc] (zesty-proposed/universe) [4.0.18-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted genwqe-user [amd64] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: accepted genwqe-user [armhf] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: accepted genwqe-user [powerpc] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: accepted genwqe-user [s390x] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: accepted genwqe-user [arm64] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: accepted genwqe-user [ppc64el] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: accepted genwqe-user [i386] (zesty-proposed) [4.0.18-2]
-queuebot:#ubuntu-release- New: accepted genwqe-user [amd64] (zesty-proposed) [4.0.18-3]
-queuebot:#ubuntu-release- New: accepted genwqe-user [armhf] (zesty-proposed) [4.0.18-3]
-queuebot:#ubuntu-release- New: accepted genwqe-user [powerpc] (zesty-proposed) [4.0.18-3]
-queuebot:#ubuntu-release- New: accepted genwqe-user [s390x] (zesty-proposed) [4.0.18-3]
-queuebot:#ubuntu-release- New: accepted hsail-tools [arm64] (zesty-proposed) [0~20170314-1]
-queuebot:#ubuntu-release- New: accepted hsail-tools [ppc64el] (zesty-proposed) [0~20170314-1]
-queuebot:#ubuntu-release- New: accepted genwqe-user [arm64] (zesty-proposed) [4.0.18-3]
-queuebot:#ubuntu-release- New: accepted genwqe-user [ppc64el] (zesty-proposed) [4.0.18-3]
-queuebot:#ubuntu-release- New: accepted hsail-tools [armhf] (zesty-proposed) [0~20170314-1]
-queuebot:#ubuntu-release- New: accepted genwqe-user [i386] (zesty-proposed) [4.0.18-3]
-queuebot:#ubuntu-release- New: accepted hsail-tools [amd64] (zesty-proposed) [0~20170314-1]
-queuebot:#ubuntu-release- Unapproved: fglrx-installer (trusty-proposed/restricted) [2:15.201.1-0ubuntu0.14.04.1 => 2:15.201.2-0ubuntu0.14.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: fglrx-installer-updates (trusty-proposed/restricted) [2:15.201.1-0ubuntu0.14.04.1 => 2:15.201.2-0ubuntu0.14.04.1] (ubuntu-desktop)
<braiam> Hi, I'm going to fill a bug against systemd so that units that use After=network-online.target start immediatly after ipv6 interfaces are UP, but these can't bind the address due DAD checks running. It is a good candidate for a SRU? Upstream report https://github.com/systemd/systemd/issues/2037
<jgrimm> rharper, ^^
<braiam> Upstream doesn't specify exactly which patches fixes the issue, so some detective work is needed
<rharper> surely networkd (or ubuntu networking) shouldn't reach network-oontline.target until networking is actually up
<braiam> rharper: as explained in the bug, the interface is UP, but with a tentative flag, due DAD checks. See https://www.agwa.name/blog/post/beware_the_ipv6_dad_race_condition for details
<rharper> braiam: yeah;  yet another delta between ifupdown (which does have dad timeouts and blocks until it's permament)
<rharper> braiam: that's definitely something that we're interested in w.r.t getting systemd/networkd on par with ifupdown networking;
<braiam> rharper: so, I use the template on the wiki for a SRU against systemd?
<rharper> braiam: have you filed a bug in launchpad (you can refer to the upstream bug in there)?  that's task that can be assigned to find the commits needed to pull in whats needed to xenial systemd
<rharper> the team will need to confirm if it's fixed in zesty (it appears to be given the info on the issue) and look at yakkety as well;
<rharper> with a fix identified then we can create an SRU from template and include how to reproduce and confirm that it's fixed;  whomever collects the fixes will need to apply and generate debdiff for the various releases, etc.
<braiam> no, I have the form filled, just waiting
<rharper> the form is the last bit of accounting; it sounds like there's other work first (identifying which patches are needed, confirming fixed/broken in zesty, yakkety and xenial)
<rharper> so we can start with a launchpad bug against systemd
<braiam> ok, then I will submit the bug as I have it and paste the link here in case there's something to modify/add (which I'm sure there will be)
<rharper> thanks!
-queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu9.1 => 2.1.0-1ubuntu9.2] (ubuntu-server, virt) (sync)
<oSoMoN> seb128, did you see my request to promote qtdeclarative5-ubuntu-ui-extras0.2 to main? could you let me know if anything is blocking? or maybe point me to another archive admin who would have time to look at it?
<braiam> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1673092
<ubot5> Ubuntu bug 1673092 in systemd (Ubuntu) "systemd doesn't wait until the tentative flag isn't removed before firing units depending on network-online.target" [Undecided,New]
<tjaalton> could someone mark analitza tests ignored on i386?
<tjaalton> keeps failing for some reason, blocks mesa
<rharper> braiam: thanks again!
<braiam> np
<sil2100> slangasek: hey! Could you help out oSoMoN with promoting some packages to main? The MIR has been accepted and now he's just waiting for someone to do the 'thing': https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-extras/+bug/1666556
<ubot5> Ubuntu bug 1666556 in ubuntu-ui-extras (Ubuntu) "[MIR] ubuntu-ui-extras" [Undecided,Fix committed]
<sil2100> webbrowser-app is now blocked in -proposed on htis
<oSoMoN> sil2100, thanks!
<slangasek> sil2100, oSoMoN: looking
<slangasek> sil2100, oSoMoN: done
<sil2100> slangasek: thank you!
<oSoMoN> slangasek, thanks!
-queuebot:#ubuntu-release- Unapproved: xen (xenial-proposed/main) [4.6.0-1ubuntu4.3 => 4.6.5-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: xen (yakkety-proposed/main) [4.7.0-0ubuntu2.1 => 4.7.2-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: xen (trusty-proposed/main) [4.4.2-0ubuntu0.14.04.9 => 4.4.2-0ubuntu0.14.04.10] (core, virt)
-queuebot:#ubuntu-release- Packageset: 64 entries have been added or removed
-queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer [source] (trusty-proposed) [2:15.201.2-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer-updates [source] (trusty-proposed) [2:15.201.2-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: nodejs (xenial-backports/universe) [4.2.6~dfsg-1ubuntu4.1 => 4.7.2~dfsg-1ubuntu3~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nodejs (yakkety-backports/universe) [4.2.6~dfsg-1ubuntu5 => 4.7.2~dfsg-1ubuntu3~16.10.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ltt-control (yakkety-proposed/universe) [2.8.1-1 => 2.8.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ltt-control (xenial-proposed/universe) [2.7.1-2~fakesync1.1 => 2.7.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openvswitch (xenial-proposed/main) [2.5.0-0ubuntu1 => 2.5.2-0ubuntu0.16.04.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.3-0ubuntu1]
<acheronuk> slangasek or other release team member about?
<acheronuk> following up from tjaalton request earlier, could you please skip the bad analitza i386 test for mesa here http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mesa
<acheronuk> this is not a mesa issue. just a test fail on another issue that blocks mesa unnecessarily.
<Laney> acheronuk: What happened to make it go from passing every time to failing every time?
<slangasek> FAIL!  : CommandsTest::testCorrect(range(a,b)) Compared values are not the same
<slangasek>    Actual   (last.toString()): "list { 0, 0.2, 0.4, 0.6, 0.8 }"
<slangasek> that's... impressive?
<slangasek>    Expected (result)         : "list { 0, 0.2, 0.4, 0.6, 0.8, 1 }"
<slangasek>    Loc: [/tmp/autopkgtest.Xt4fro/build.psW/analitza-16.12.3/analitza/tests/commandstest.cpp(422)]
<acheronuk> Laney: santa 'fixed' the test!
<slangasek> Laney, acheronuk: analitza/4:16.12.1-0ubuntu1 consistently fails with an abi-compliance-checker failure, which could be triggered by mesa or could be unrelated.  analitza/4:16.12.3-0ubuntu1 consistently fails with the above math test error
<slangasek> I would like a clearer understanding of the zesty failure than "keeps failing for some reason" if I'm to ignore this error
-queuebot:#ubuntu-release- Unapproved: thermald (xenial-proposed/main) [1.5-2ubuntu2 => 1.5-2ubuntu3] (core)
<Laney> slangasek: Looks to me like it's (partially) broken on i386, so suggest skiptest mesa rather than badtest analitza if you decide to skip it
<Laney> but I would also like to see some real analysis :-)
<acheronuk> slangasek: that abi compliance checker issue on 16.12.1 was just an issue with updated gcc-6
<acheronuk> fixed by: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/analitza/commit/?id=9dad53f96f7d0e3eb632d89c6d7664d030912bc3
<slangasek> ok
<slangasek> that's the info I needed, thanks
<acheronuk> we will look at the analitza tests against itself in the meantime. santa/jose is talking to upstream I think
<acheronuk> slangasek: thanks
<chrisccoulson> infinity, slangasek, or any other AA - could you please approve the adobe-flashplugin/partner uploads from yesterday?
<slangasek> chrisccoulson: looking
<chrisccoulson> slangasek, thanks. It's for precise -> yakkety (zesty is already done)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (precise-proposed) [1:20170314.1-0ubuntu0.12.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170314.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170314.1-0ubuntu0.16.04.1]
<Laney> slangasek: Uh, you badtested?
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20170314.1-0ubuntu0.16.10.1]
<slangasek> Laney: yes, because I'm satisfied with acheronuk's explanation that it is a bad test
<Laney> I think he said that they fixed the acc test, not the testsuite one
<acheronuk> Laney: that is correct
<slangasek> Laney: I only badtested the zesty version, not zesty-proposed
<acheronuk> not the same issue
<Laney> alright
<Laney> that makes sense, thx
<Laney> well, assuming mesa is tested against that one
<acheronuk> aha. ok
<Laney> which is isn't :)
<Laney> here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/a/analitza/20170315_084946_fd302@/log.gz someone ran the test with all-proposed
<slangasek> Laney: it happens that I already retriggered without all-proposed, so I guess it'll clear soon?
<acheronuk> ummmmm. I re-did the tests against 'all-proposed' this morning, to reduce it down to the i386 fail
<slangasek> ick, I really don't like all-proposed being used that way
<slangasek> "some collection of packages in -proposed, some of which may or may not migrate, got the tests to pass"
<Laney> Not sure that it will clear it
<acheronuk> sorry if that confused things. testing against 16.12.1 in release will fail on the abi compliance check, as that was uploaded and migrated before the gcc-6 change
<chrisccoulson> slangasek, thanks for approving those. Will you be around in a bit to move them from proposed?
<slangasek> chrisccoulson: yes
<tjaalton> slangasek: thanks for fixing analitza, now you'd still need to remove armhf binaries of openmw :) bug 1671129
<ubot5> bug 1671129 in openmw (Ubuntu) "remove armhf binaries for openmw to unblock mesa" [Undecided,New] https://launchpad.net/bugs/1671129
<slangasek> let's see
<tjaalton> mesa got rid of libgles1 which is about to be removed upstream anyway, openmw tried to make armhf to work with gles1 but failed
<tjaalton> also, while I'm here.. should xserver & driver rebuilds still be copied from a ppa or just rebuilt in -proposed?
<slangasek> tjaalton: I don't understand why you're asking
<tjaalton> back in the day they were built on a ppa and then copied to the archive
<tjaalton> it's been long enough that I don't remember how it was done :P
<tjaalton> last time
<slangasek> there's no requirement from the archive side that you do it one way or the other
<tjaalton> okay
<tjaalton> I just thought if one is preferred over the other
-queuebot:#ubuntu-release- Unapproved: openvswitch (yakkety-proposed/main) [2.6.0-0ubuntu2 => 2.6.1-0ubuntu0.16.10.1] (ubuntu-server) (sync)
<barry> slangasek: or other archive admin; can you please drop aptdaemon 1.1.1+bzr982-0ubuntu17 from zesty-proposed?  the bug it fixes is quite minor and the package isn't going to get promoted, so better to just drop it and i will close the bug as won't fix
<slangasek> barry: are you confident that we're never going to upload another aptdaemon package? because otherwise that's a lego on the floor for the next person who tries to upload it and gets a reject message from LP for picking the wrong version number
<barry> slangasek: i'm confident *i* will never upload another one :)  i can also update lp:aptdaemon to make it clear in the changelog that the next version should be used.  but yeah, if someone does an upload from apt-get source, it will break.  suggestions?  just let it linger in -proposed?
<barry> (and it's an easy enough fix if they do; just bump the version number)
<slangasek> barry: lp:aptdaemon... which is not listed in debian/control of the existing package, so why would the uploader look there? :/
<slangasek> barry: yeah, I'm ok with it lingering in -proposed until we properly solve the dependencies on aptdaemon
<barry> slangasek: yeah, i don't even remember how i stumbled on it
<barry> slangasek: wfm
<Ukikie> There seem to be a lot of dups for a "minor bug", fwiw.
<tsimonq2> Some guy got mad in a bug report about the lack of an up-to-date Qupzilla in the archive
<tsimonq2> infinity: Which reminds me, are you around to work on adding that PPA to that image?
<infinity> tsimonq2: Not super available for that sort of fiddling right now, no. :/
<infinity> tsimonq2: That said, if you have a PPA ready to go that I can have a look at, maybe I can JFDI.
<infinity> tsimonq2: Upload rights on the PPA shouldn't include anyone who can't upload the same packages to the archive, ideally.  So we're not distributing images with free-for-all WHEE stuff in them.
<tsimonq2> infinity: I have zero upload rights to the archive, but ideally once the work is done, I can get it in the archive once Zesty+1 opens for development, maybe then I'll apply for PPU.
<tsimonq2> infinity: But as of now, I would be the only person with upload access that doesn't have access to the archive.
<infinity> tsimonq2: So who sponsors your stuff generally?
<tsimonq2> infinity: gilir if it's Lubuntu stuff. Otherwise a few different people.
<infinity> tsimonq2: If one of your sponsors has upload rights to the PPA as well, and is willing to take responsiblity for whatever crack you put in there, I'll consider that close enough, given this is a "-next" image, not something we're shipping.
<tsimonq2> infinity: What do you need, an email?
<infinity> tsimonq2: ie: Just a verbal "yeah, Simon's okay, and I'll vouch for his uploads in that PPA" from gilir would work for me. :P
<tsimonq2> infinity: Ok, I'll talk to him.
<infinity> tsimonq2: Assuming, as you say, that you're the only non-archive-upload-rights person with access to said PPA.  Which PPA is it?
<tsimonq2> infinity: ppa:lubuntu-next/stable - as you can probably tell it's a WIP, was going to upload a test package there just so the image building mechanism has the ability to add the PPA, but I'm not done yet. And that being said, I probably should have waited an hour before giving you a ping... :|
<tsimonq2> infinity: But very soon, I'll make it so Lubuntu Next is a subteam of Lubuntu Developers (Lubuntu Developers has access but not vice versa) so gilir and anyone with Core Dev can upload to it, as a precautionary measure.
<tsimonq2> infinity: Regardless, I just sent gilir a ping, he'll let you know when he gives the thumbs up.
<infinity> tsimonq2: I don't think lubuntu-developers is a team with upload rights.
<infinity> jmarsden sure doesn't seem to have any.
<Ukikie> Oh?  Used to be MOTU.
<tsimonq2> infinity: I am aware, but it just gives all people who are in that team now and in the future access to it.
<infinity> Certainly isn't right now.
<infinity> tsimonq2: Yes, and I'm telling you I explicitly don't want that. :P
<tsimonq2> infinity: You don't want me to give ~lubuntu-dev access to it, only Julien?
<wxl> @infinity: what if we created a vetting process for it? it's not like anyone can just join the team.
<tsimonq2> wxl: But regardless we should talk to Julien about that other random person.
<tsimonq2> I'm not sure they should be in there.
<wxl> s/\(vetting\)/well-defined \1/
<wxl> @tsimonq2: agreed
<tsimonq2> wxl: I'll ping him about that as well.
<infinity> How you handle the team is your own issue.  But we just finished discussing "If we build images from the PPA, the only people with upload rights to the PPA should be people with archive upload rights and, if gilir vouches for you, also you (Simon)".  So adding more people via a team is a no-go. :P
<tsimonq2> infinity: Alright.
<infinity> It's perhaps not insane for ~lubuntu-dev to become a DMB-owned team and define upload rights for a lubuntu PPU packageset, but that's not what it is today.
<tsimonq2> infinity: I actually talked to gilir about that, he told me that it's a bit useless at the moment because he's the only active developer on that team, and since he is already a MOTU, that would be redundant. :P
<infinity> He's not wrong.
<tsimonq2> I don't think he is either.
<tsimonq2> But yeah, that's for another day I think.
<infinity> But if any lubuntu people decide to go for PPU instead of MOTU in the future, repurposing that team for that would be reasonable.
<infinity> (But that would remove it from your control and put it in the DMB's control)
<tsimonq2> Gotcha.
<tsimonq2> But, I think at the moment it's fine how it is. The only other person who would be interested in having that access is me, and I plan on applying for MOTU, not limiting my access to PPU.
<tsimonq2> infinity: But anyways, would you like me to invite MOTU, Core Dev, both, or neither to be a part of the team?
<tsimonq2> As in, has upload rights to the PPA.
<tsimonq2> "people with archive upload rights" - just curious if you're referring to any archive rights (so in this case it would be MOTU) or just people with access to all the things (Core Dev), infinity
<infinity> tsimonq2: Technically, if building images from it, it *should* be core-dev, since you could do silly things like replace glibc in your PPA.  In reality, given it's a test/next image, NOT a shipping product, and I happen to know the people involved, I'm willing to extend some trust that you won't do silly things. :P
<tsimonq2> infinity: Alright. If at any time you need/want access, I'll be happy to grant it. :)
<tsimonq2> infinity: Since you are an indirect Lubuntu Developer, please reject the invitation to ~lubuntu-next on behalf of Lubuntu Developers, I pressed buttons before "infinity> tsimonq2: Yes, and I'm telling you I explicitly don't want that. :P"
<tsimonq2> infinity: I mean, if you can.
<tsimonq2> infinity: Otherwise I'll ask gilir
<infinity> tsimonq2: You should be able to uninvite them, surely.
<tsimonq2> infinity: I wish I could...
<infinity> You're the team admin.
<infinity> https://launchpad.net/~lubuntu-next/+members
<infinity> Should have an option to remove.
<tsimonq2> infinity: There isn't one afaict
<tsimonq2> infinity: http://imgur.com/xQJRRQ7
<tsimonq2> infinity: This is on https://launchpad.net/~lubuntu-next/+members#invited
<tsimonq2> infinity: I can edit existing members, no invitations
<tsimonq2> Unless I'm just not looking in the right place?
#ubuntu-release 2017-03-16
-queuebot:#ubuntu-release- Unapproved: iproute2 (xenial-proposed/main) [4.3.0-1ubuntu3 => 4.3.0-1ubuntu3.16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: iproute2 (yakkety-proposed/main) [4.3.0-1ubuntu3 => 4.3.0-1ubuntu3.16.10.1] (core)
<superm1> AA's: fwupdate and fwupdate-signed don't seem to be migrating from proposed, i think some manual prodding might be needed.
<infinity> superm1: That would be because they're not built.
<infinity> Well, in upapproved.
 * infinity goes to fix that.
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (zesty-proposed) [9-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (zesty-proposed) [9-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (zesty-proposed) [9-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (zesty-proposed) [9-1]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-updates/universe) [2.23.1~14.04 => 2.22.6~14.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-updates/main) [2.23.1 => 2.22.6] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-updates/main) [2.23.1+16.10 => 2.22.6+16.10] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [sync] (trusty-updates) [2.22.6~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [sync] (xenial-updates) [2.22.6]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [sync] (yakkety-updates) [2.22.6+16.10]
<handsome_feng> Good Morning! Everyone! Could anyone help to approve the UKUI packages? Thank you! bug: #1663477
<ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.0+16.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (yakkety-proposed) [1.0+16.10ubuntu1]
 * smb wonders whether he can find a daring sru team member for approving Xen fun into T/X/Y
<acheronuk> apw: would you be able to look at bug #1673394
<ubot5> bug 1673394 in kde-l10n-engb (Ubuntu) "[FFe] upgrade KDE localisations/transations for KDE to 16.12" [Undecided,New] https://launchpad.net/bugs/1673394
<acheronuk> really want those in for the beat for wider testing ^^^
<acheronuk> *beta
-queuebot:#ubuntu-release- Unapproved: accepted pepperflashplugin-nonfree [source] (yakkety-proposed) [1.8.2+nmu1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted pepperflashplugin-nonfree [source] (xenial-proposed) [1.8.2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted pepperflashplugin-nonfree [source] (trusty-proposed) [1.3ubuntu1.1]
<acheronuk> apw: also bug #1672672 thanks :)
<ubot5> bug 1672672 in krita (Ubuntu) "[FFe] Krita 3.1.2.1 for zesty" [Undecided,Confirmed] https://launchpad.net/bugs/1672672
<wgrant> I've just reverted 16 kernel metapackages across {trusty,xenial,yakkety}-{updates,security} to avoid apt removal carnage from the snapd SRU reversion (https://launchpad.net/bugs/1673247). It's all published and my test systems are healthy, but let me know if anything looks awry.
<ubot5> Ubuntu bug 1673247 in snapd (Ubuntu) "package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1" [Critical,Confirmed]
<tsimonq2> AAs (cc infinity, slangasek): What is your stance regarding allowing packages with the Cat Supremacy License into the archive?
<tsimonq2> Debian says no, because "cats aren't superior" ^_^
<apw> wgrant: thanks for handling that for me ... appreciated
<acheronuk> tsimonq2: braillegraph 0.1?
<wgrant> apw: np
<cjwatson> "Cat Supremacy License"  no relevant hits on ddg that I can see
<acheronuk> after a little searching.... https://github.com/kilobyte/braillegraph/commit/a535c2d818bb8b60a80c53e527861c779611350b
<acheronuk> I guess that is what debian failed to agree with ;)
<cjwatson> the addition of the second para means that it's effectively just a simple permissive licence and should be fine, though I'd like to deprecate silly novelty licences in general
<tsimonq2> cjwatson: They rejected it on the basis that they can't print it if they don't love cats :P
<cjwatson> that's a clear misreading
<tsimonq2> acheronuk: You are correct
<cjwatson> given that the second para says they have the same rights "albeit grudgingly"
<cjwatson> anyway, stupid licence, just use the next version along with a more standard one
<tsimonq2> http://www.mail-archive.com/debian-curiosa@lists.debian.org/msg05476.html
<tsimonq2> cjwatson: I was thinking of using it, that's why I was asking :P
<cjwatson> in fact I'm not totally sure why you care about this given that the licence change was committed before any release was tagged.
<cjwatson> even 0.1 has the replaced licence shown in the commit above.
<tsimonq2> It just caught my eye when reading LWN *shrug*
<cjwatson> honestly this is time-wasting :P
<tsimonq2> cjwatson: Thank you for your value input, and praise The Superior Species \,o/
<tsimonq2> o/
<cjwatson> I mean, sure, I like cats, I have two, but. :-)
<cjwatson> (admittedly this is largely due to accident: one turned up and adopted us, then had kittens before we got round to neutering her)
<tsimonq2> <3
<jbicha> hi, could an AA allow steam to migrate to zesty? it intentionally introduces an arch:all that depends on an arch:i386
<jbicha> because steam itself is i386 only so it was unavailable to install in gnome-software (on especialy amd64) without this new arch:all package
<jbicha> pixfrogger is an example of another Debian/Ubuntu pkg that has this same arch:all to arch:i386 dependency
<xnox> wine does that too
<xnox> i think
<jbicha> it looks like wine64 only recommends wine32 now
<infinity> jbicha: We trick britney into doing that.
<infinity> jbicha: Fixed.  Maybe.
<jbicha> infinity: is that a permanent trick? or will that have to be manually done every time there's a new steam upload?
<infinity> jbicha: It's permanent.
<infinity> jbicha: Erm, oh.  But there's an added bit of broken here, you can't depend on "steam:i386", you just want to depend on "steam" and trust that'll grab the i386 package, since that's the only one that exists.
<infinity> jbicha: With my fix to britney, changing that dep will also fix you.
<jbicha> ok, I'll do that, thanks
-queuebot:#ubuntu-release- New sync: qtubuntu-print (zesty-proposed/primary) [0.1+17.04.20170301.2-0ubuntu1]
-queuebot:#ubuntu-release- New sync: ubuntu-printing-app (zesty-proposed/primary) [0.1+17.04.20170308-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (yakkety-proposed) [1.36.1-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (xenial-proposed) [1.34.0-0ubuntu8.3]
-queuebot:#ubuntu-release- Unapproved: accepted pam-mysql [source] (xenial-proposed) [0.7~RC1-4ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted pam-mysql [source] (yakkety-proposed) [0.7~RC1-4.1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted xen [source] (yakkety-proposed) [4.7.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ltt-control [source] (yakkety-proposed) [2.8.1-1ubuntu1]
<infinity> jbicha: FWIW, discussed it with guillem.  While a dep on "steam:i386" is valid from dpkg's POV, it's probably saner and more future-proof to have the unqualified dep anyway, as today it means the same thing (only i386 exists), and if tomorrow an amd64 build of steam shows up, it would DTRT and install that instead.
<infinity> jbicha: So pushing that fix back to Debian would be correct, IMO.
<infinity> (But we should probably also teach our tools to cope with the explicit dep for when someone comes up with a use-case where it makes sense)
<jbicha> maybe we'll see steam:amd64 around the same time as halflife3
<infinity> Heh.
<infinity> I imagine we'll see it around the same time as major distros decide to drop 32-bit support.
<infinity> Which I'd like to do in Ubuntu post-18.04, personally.
<wxl> :(
<infinity> 18.04 will be supported until 2023, if people are still using i386 CPUs after 2023, my sympathy for them isn't high.
<infinity> The harder argument will be armhf, because I'd like to drop *all* 32-bit support, not just x86.
<wxl> it's hard to say how far people will take lubuntu's aim of targetting old hardware
<infinity> But maybe the world will be sufficiently arm64 by then (at least, for platforms we care about).
<wxl> i guess we'll just have to see what happens
<infinity> wxl: Hey, I still run a machine from 1997 here (PowerMac G3), but we just dropped support for that (powerpc), and I'll live, somehow.
<infinity> wxl: Eventually, the cost of maintenance and electricity doesn't outweigh the percieved savings, IMO.
<wxl> eventually
<infinity> The only reason this one wasn't a huge burden on my electric bill was because I managed to replace the original CPU with a low power mobile part.
<wxl> but if, in the sense of a school system, the electricity is perhaps a given regardless of how it fluctuates (i'm not sure about this), then reusing old hardware might still be a good budget saving venture
<wxl> i think that's the main audience i'm concerned about rather than the casual user
<wxl> and if we're going with the flow of the rest of the linux world, then oh well
<infinity> wxl: But, realistically, x86 CPUs have been defaulting to amd64 for more than a decade (and almost two decades by 2023), so I don't think supporting 20 year old machines is a reasonable goal.
<wxl> i just don't want to be the snowflake
<infinity> But I won't be making the decision alone here, either.  I'm sure lots of people will object.  We need to sort out if the objections are based on statistical fact or passion, and go from there.
<wxl> yeah
<wxl> might be wise to collect the age of the machines of our users
<infinity> The biggest potential issue, IMO, isn't "old hardware", but 3rd party software.
<wxl> right
<infinity> But much like Flash didn't die until Apple refused to support it, we might just have to lead here and force the rebuilds.  We'll see.
<wxl> i think that's the least likely issue
<infinity> User metrics would also be handy.
<wxl> since mostly what people are trying to do is simple tasks like browsing and such
<infinity> bdmurray: Does errors.ubuntu.com collect enough data to determine what CPUs people are using?  So we can see how many i386 users *can* run amd64 but aren't?
<wxl> that's a really good idea
<wxl> we'd need flags from procinfo tho
<infinity> We might collect cpuinfo.  I don't recall.
<wxl> cpuinfo, sorry :)
<infinity> Though, I think we went through a similar dance when trying to decide the impact of dropping non-pae support.
<wxl> i don't think i was involved enough in those discussions to know how that was resolved
<infinity> Oh, which is also a valid data point.  The number of machines that support PAE but not amd64 isn't actually huge.
<infinity> As in, we dropped most i386 users with the PAE change already.  There's only a short gap of a few years' worth of hardware that supports PAE and not 64-bit.
<wxl> right
<wxl> admittedly we have instructions on dealing with that
<wxl> so if we had a similar solution for i386
<infinity> Do the instructions involve a custom kernel?
<wxl> !pae
<ubot5> Ubuntu provides only PAE-enabled kernels for 32-bit systems now. Some older CPUs may have issues with it. For more info and troubleshooting, see https://help.ubuntu.com/community/PAE
<wxl> no apparently
<infinity> So, that's not the hardware I mean. :P
<infinity> Yes, some PentiumM and CeleronM machines *do* support PAE but misreport it.  Those are fixed by those workarounds.
<infinity> Anything older, however, just plain doesn't support it.
<wxl> ah
<infinity> And won't boot.
<infinity> (Well, except for the original Pentium Pro, but anyone running one of those is very much not a user we target)
<wxl> admittedly we get very few people asking about it
<infinity> Anyhow, it's a talk I imagine we'll have a few times leading up to 18.04, and I think all involved have already agreed that we'll keep 32-bit *for* 18.04, so it'll at least live until 2023.
<wxl> it's pretty much become a bit of a non-issue
<wxl> that seems logic
<wxl> al
<infinity> Dropping 32-bit will solve some goldfish issues with software getting so fat that 32-bit machines can't be self-hosting anymore without tricks, which sucks.
<wxl> it would also be nice to know about those flags
<wxl> i have a 64-capable machine running i386
<infinity> (For instance, without some hackery, most webkit-based projects can't actually build *for* 32-bit *on* 32-bit)
<wxl> i would hate that to show up as a datapoint suggesting keeping i386
<wxl> (yes, i've been lazy about dealing with it)
<infinity> Plus, there's the impending doom of the 2038 epoch that we'd entirely side-step by just not having any supported series on 32-bit by then.
<infinity> 2038 used to seem very far in the future.  It really doesn't anymore.
<wxl> it will also allow users to use chrome proper, which is not an uncommon request
<wxl> good point
<cjwatson> i386> I still like being able to run Launchpad tests in an i386 chroot, because it makes a fairly big difference to memory usage.
<bdmurray> infinity: cpuinfo?
<cjwatson> er s/chroot/container/ but whatever
<infinity> cjwatson: If only x32 had been a thing from day 1. :/
<cjwatson> Yeah, x32 would be nice if we actually did the port.
<wxl> @bdmurray: /proc/cpuinfo
<cjwatson> But we can't be the only ones for whom userspace memory usage still matters at least a bit.
<infinity> cjwatson: So, I live in the same world as you, and I think, for instance, people running m.small AWS instances should all run i386 images.  Usage statistics, however, show that very few people think like you and I.
<infinity> Where "very few" is a number approaching 0.
<wxl> bdmurray: more specifically the flag "lm"
<bdmurray> It looks like only the cheese package hook collect cpuinfo and that looks broken, so no not in errors.
<infinity> bdmurray: Dang.  Maybe we should change that soonish, so we can collect some solid data over the next 6-12 months.
<infinity> bdmurray: Knowing the host CPU is sometimes handy for debugging too, but very handy for this sort of data mining.
<bdmurray> works for me
<wxl> i guess an alternative solution for 3rd party stuff is using an old distro in a virtual machine
<wxl> or a 32 bit chroot, as you guys were discussing
<wxl> but that's probably not a realistic sustainable solution
<infinity> No.  It needs to be supportable.
<infinity> I might talk with RH toolchain guys about this too.
<infinity> If RH can be talked into dropping 32-bit support along with us, 3rd parties will pretty much have no choice but to catch up, instead of just naming us the odd ones out.
<wxl> rh?
<wxl> oh
<wxl> derp nevermind :)
<bdmurray> infinity: I reported 1673557 re apport
<infinity> I certainly wouldn't mind if the advice for RH/Ubuntu was "if you need to run old, broken crap, use a Fedora/Debian chroot", though in an ideal world, F/D would also drop 32-bit. :P
<infinity> bdmurray: Huzzah.
<wxl> infinity: i thought at least Debian has been discussing this as well? or maybe i'm just hoping.
<infinity> It comes up from time to time, yes.
<infinity> I expect we'll lead on it, though.
 * wxl sighs
<infinity> If they drop support before us, it'll be a no-brainer for us, IMO.  We don't want to be responsible for all the potential issues.
<wxl> right. in an ideal world, that would be the sequence of events
<wxl> as with systemd
<wxl> and ppc
<infinity> systemd was a unique snowflake there, to be fair.  Because we'd already "led" with upstart.
<infinity> Had we not done that, we'd have moved to systemd while Debian was still discussing it.
<bdmurray> infinity: is there someway to shorten cpuinfo?
<infinity> bdmurray: In what sense?  To inline it?  I think we'd rather have it as a block, like we do with /proc/environ
<acheronuk> infinity: is there any chance you would have time to look at: bug #1673394 ?
<ubot5> bug 1673394 in kde-l10n-engb (Ubuntu) "[FFe] upgrade KDE localisations/translations for KDE to 16.12" [Undecided,Confirmed] https://launchpad.net/bugs/1673394
<bdmurray> infinity: at least on my cpu a lot of it seems redundant. all the processors are the same.
<infinity> acheronuk: If, as the bug title implies, it's just translations and docstrings, that freeze isn't until the 30th, and you need no exception.
<infinity> bdmurray: Oh, I see what you mean.
<acheronuk> infinity: ah. I thought that was just for ubuntu derived packages reading the wiki. thanks for the clarification :)
-queuebot:#ubuntu-release- Unapproved: accepted xen [source] (xenial-proposed) [4.6.5-0ubuntu1]
<infinity> bdmurray: One could perhaps employ some shell sort hackery to collapse all the same lines down.  On most systems, I'm not sure it matters, but I suppose on a 160-thread machine, it starts getting ugly.
<wxl> you could use awk for sure
<bdmurray> wxl: well if you are feeling clever feel free to add it to the bug.
-queuebot:#ubuntu-release- Unapproved: accepted ltt-control [source] (xenial-proposed) [2.7.1-2ubuntu1]
<wxl> or you could grep for the number of lines, too
<wxl> they should be static, no?
<wxl> er head
-queuebot:#ubuntu-release- Unapproved: accepted supervisor [source] (xenial-proposed) [3.2.0-2ubuntu0.1]
<infinity> bdmurray: lscpu might be more pleasant for this.  Need to confirm it DTRT on all platforms.
<cyphermox> bdmurray: lscpu
<wxl> head -n 26 does the trick here
<wxl> no flags, tho
<infinity> wxl: Cutting won't cut it, every CPU reports different numbers of lines (drastically so on other platforms).
<wxl> although i guess op mode should give you what's needed
<wxl> @infinity: really? given the fact there are null rows, i'm surprised
<infinity> lscpu is a bit underwhelming on ppc.
<infinity> wxl: It's not a machine-readable format, it changes a lot from machine to machine.
<wxl> bah
<cyphermox> infinity: aside from say, "CPU(s):                160"
<infinity> cyphermox: Missing clock, which is irksome.  But not the end of the world.
<infinity> cyphermox: Oh, also missing a proper model.
<cyphermox> yeah, I noticed that
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (xenial-proposed) [1.5-2ubuntu3]
<cyphermox> clock is there, but not very helpful
<infinity> cyphermox: http://paste.ubuntu.com/24190287/
<infinity> cyphermox: Though, that's trusty, maybe the machine you're using is less crap?
<cyphermox> we're not looking at the same system
<infinity> No, indeed we're not. :P
<cyphermox> http://paste.ubuntu.com/24190297/
<infinity> But my two complaints on the one I'm looking are are lack of clock (meh), and Model reporting machine model, but no CPU model.
<cyphermox> still missing model
<cyphermox> yep
<infinity> Ahh, no.  That has the info I'd want.
<infinity> Model name:            POWER8E (raw), altivec supported
<cyphermox> ah
<infinity> Is that xenial or zesty?
<cyphermox> I thought you wanted things like PowerNV
<wxl> sed -n '/./,/^$/{/^$/q; p}' will give you what's above the blank line
<wxl> i.e. tne 0th processor
<cyphermox> xenial
<wxl> ^^ on cpuinfo
<infinity> cyphermox: That does tell me it's PowerNV, if you read between the lines.
<cyphermox> infinity: I don't have your intimate knowledge of Power.
<infinity> cyphermox: "Model: 2.0 (pvr 004b 0200)"
<infinity> cyphermox: If it was a qemu machine, it would say "IBM pSeries (emulated by qemu)"
<cyphermox> oh, I suppose you're right
<infinity> wxl: Trust me, not helpful, every platform is different.
<cyphermox> well, I know ;D
<infinity> bdmurray: lscpu is the answer here.
<wxl> infinity: all it does is look for ANY character up until a newline. you mean to tell me some of them don't separate by newlines?
<infinity> wxl: Not in the same ways.  *and* I want the stuff after the newline.
<wxl> oh well then have fun XD
<bdmurray> infinity: cool, nothing collects that either yet. :-(
<cyphermox> ah, is that for apport?
<infinity> cyphermox: Yeah.
<cyphermox> wee
<infinity> lscpu on aarch64 is awful too.  No flags.
<infinity> I hate software.
<infinity> cpuinfo really would be better, but collapsing it on large machines would be nice.
<cyphermox> cpuinfo is already grabbed by apport sometimes
<infinity> Only by some hooks, apparently.
<infinity> Or so Brian says.
-queuebot:#ubuntu-release- Unapproved: accepted xen [source] (trusty-proposed) [4.4.2-0ubuntu0.14.04.10]
<cyphermox> yeah, well, those where we thought it mattered, so d-i and linux for sure.
<infinity> So, while format of cpuinfo isn't guaranteed, the platforms *we* care about seem to at least have paragraphs starting with "processor", and then sometimes a trailing one that doesn't.
<cyphermox> does it matter everywhere now?
<bdmurray> cyphermox: I didn't see any indication they collect that.
<infinity> So we could take the first of the former, append the latter, and call it good.
<cyphermox> bdmurray: data/package-hooks/source_linux.py:    apport.hookutils.attach_hardware(report)
<cyphermox> I might not be looking at the right thing though
<infinity> cyphermox: I want it everywhere for (a) some more useful debugging info and (b) installation metrics (ie: the above dicsussion about "how many people run i386 on amd64-capable CPUs")
<cyphermox> infinity: that's not my call. If you think it should be everywhere, it becomes easy to fix for all apport hooks
<infinity> Not everyone reports bugs on linux, but over the course a year, a very large subset of users will sumit *some* report to errors.u.c
<cyphermox> right
<cyphermox> I'll go back to my livefs now
<bdmurray> oh, I missed the attach_hardware function. its alot more than just linux - cups, bluez, x stuff, d-i
<infinity> bdmurray: I'm going back on my "use lscpu" comment. cpuinfo is indeed still better.
<infinity> bdmurray: And it looks like we already do it for a lot of stuff, as pointed out.  So maybe we should just do it for everything.
<infinity> bdmurray: And worry about collapsing it later. :P
<cyphermox> infinity: wouldn't it be pretty simple to fix lscpu for aarch64?
<cjwatson> base-installer has some per-arch cpuinfo scanning support IIRC
<infinity> cyphermox: lscpu is kinda still crap for a lot of arches, IMO.  Only x86 shows flags, for instance.
<cjwatson> maybe not on all arches though
<infinity> But, more to the point, apport already does cpuinfo, so doing it *more* isn't a big change here.
<cyphermox> infinity: sure, but what I mean is if x86 shows flags, the others could
<bdmurray> infinity: I don't think its actually made into the error tracker because its greater than 1k - we'd need to whitelist it.
<infinity> Making it better can be a secondary goal.
<cjwatson> yeah, doesn't look like it ever needed to be especially complete, so ignore me
<infinity> cyphermox: Not suggesting util-linux couldn't do with some patches to make lscpu less crap, just suggesting that's not a thing that matters to me today when cpuinfo has what I need.
<cyphermox> yeah, I understand
<infinity> I'm not sure lscpu's non-machine formats are really something people care about.
<infinity> 'lscpu -e' is the useful switch (and not at all useful for what we're doing)
<cyphermox> you're talking to someone who never uses lscpu
<cyphermox> oh, I think I maybe did patch that to work correctly on ppc64el though
<infinity> cyphermox: Heh.  Yeah.  I think the default of "vomit unformatted crap" should never have existed, -e and -p are the useful modes.
<infinity> e for humans, p for computers.
<infinity> bdmurray: So, whitelisting it would be nice.  Should I work on collapsing N cores down to 1 before you allow that?
<bdmurray> infinity: collapsing it might make less than 1k right?
<bdmurray> if that happened we wouldn't need to change whoopsie
<bdmurray> otherwise its a whoopsie and apport change
<infinity> bdmurray: In many/most cases.  In some x86 cases, it might still be larger (the flags line can get pretty huge).
<infinity> bdmurray: In fact, yes.  Isolating one CPU core here is 1063 bytes.  So, just over. :P
<infinity> Thanks, Intel.
<bdmurray> I don't know how we are doing on db storage but it'd be best if we collapsed it.
<infinity> bdmurray: Right.  I'll brush off my awk.  It should be a short 1-liner, I just need to remember how to live in 1979.
<bdmurray> Is there anybody actually reviewing stuff in the queue for -backports?
<bdmurray> caribou: bug 1342580 is missing Impact and Regression Potential, I see a test case in your reproducer comment.
<ubot5> bug 1342580 in tftp-hpa (Ubuntu Yakkety) "tftpd-hpa doesn't start on boot" [Medium,Confirmed] https://launchpad.net/bugs/1342580
<bdmurray> slangasek: When did the armhf autopkgtest infrastructure change? http://autopkgtest.ubuntu.com/packages/p/pbuilder/xenial/armhf
<slangasek> bdmurray: I think it was sometime last summer
<slangasek> bdmurray: so May-October 2016 would certainly cover the range
<bdmurray> great
<infinity> That error, on the other hand, seems pretty suspect.
<infinity> Especially given that s390x and armhf should, in theory, be similar setups.
<infinity> slangasek: Did pitti leave us with docs on how to get into those machines, or is this a "Laney and one or two other know and have access" thing?
<infinity> s/other/others/
<slangasek> infinity: there are docs of a sort; last time I tried to connect to them I was apparently going one proxy too deep
<infinity> My proxy depth is just right.
<infinity> At least, that's what Goldilocks told me.
<slangasek> mknod in a container, I'm surprised that works in s390x either?
<infinity> Well, that's my point.  It should either not work on s390x or it should work on armhf.  The disparity smells funny.
<infinity> xor, for the pedantic.
<infinity> (Weird side note: does anyone read a natural language 'or' as a logical 'or', or do we all read it as a logical 'xor'?)
<infinity> I tend to lean to the latter.
<infinity> In fact, I did so in my question. :P
<slangasek> you're right; this is inconsistent.  We should rename 'or' to 'bor' for 'boolean or', and 'xor' can be 'or'
<infinity> slangasek: Maybe we need an Si OiR.
<infinity> It's fun to say out loud.
<infinity> I think it's time to go install a shawarma in my face.
<jgrimm> howdy, can a release team member take a look at this FFe for ack or nack: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1668940
<ubot5> Ubuntu bug 1668940 in samba (Ubuntu) "[FFe] samba-vfs-modules misses ceph vfs module" [Medium,New]
<jgrimm> nacc, ^^ fyi
<infinity> jgrimm: Commented.
<infinity> jgrimm: The comment probably should have been split into "with a release team hat on" and "with an SRU team hat on", but I suspect readers can sort that out. :P
<acheronuk> infinity: could you maybe also have a look at https://bugs.launchpad.net/ubuntu/+source/krita/+bug/1672672
<ubot5> Ubuntu bug 1672672 in krita (Ubuntu) "[FFe] Krita 3.1.2.1 for zesty" [Undecided,Confirmed]
<infinity> acheronuk: The only major feature change there (other than some knew knobs, and better mouse handling) seems to be removing PDF export support.  Which kinda sucks, but if upstream won't support it, I don't think we should either, so +1.
<acheronuk> infinity: thank you :)
<jgrimm> thanks infinity +1 to your recommendation
<infinity> "knew knobs"?  What were my fingers smoking?
<jgrimm> infinity, can you change 1668940 to 'triaged' to seal your ACK?
<infinity> Okay, really shawarma time.  Maybe I'll learn how to spell "new" when I'm out.
<infinity> jgrimm: That's not generally part of my FFe workflow, but if it matters to you, go nuts and change it. :P
<jgrimm> cool, just following the wiki. :)
<infinity> Oh, we document these things?  Fancy.
<infinity> You'll note that my "workflow" often consists of people pinging me on IRC and copy/pasting my response into the bug, cause I can't be bothered to respond twice. :P
<jgrimm> heh, oh i'd noticed.. there is wiki process, and then how things really work. ;-P
 * acheronuk was about to do just that ^^^^ :P
<acheronuk> copy/paste infinity's response I mean
<infinity> acheronuk: Complete with my creative spelling of "new", no doubt.
<acheronuk> knobs included. sorry :P
<acheronuk> *knew knobs
<infinity> Future generations deserve to datamine my derp.  It's all good.
<nacc> jgrimm: thanks
<jgrimm> nacc.. as you'll see in backscroll,  you may want to ping here if you have other languishing FFes you'd like to nudge forward
<nacc> jgrimm: yep
<xnox> infinity, slangasek: armhf and s390x are different runners in adt; one is lxc1 the other one is lxd
<xnox> one is less secure than the other. I believe s390x is the lax one.
<tsimonq2> Ooh, Release Team, Final Beta coming up fast. Freeze on Monday!
<tsimonq2> (or Tuesday, but you probably get the point in me saying that...)
<slangasek> xnox: huh, why the laxity?
#ubuntu-release 2017-03-17
<slangasek> xnox: but yes, that would definitely match what we're seeing, with armhf-only failure
<xnox> slangasek, because lxd is better and has better apparmor containment and strong defaults
<xnox> lxc1 containments have not been strengthned lately by default; the way lxd is.
<xnox> i think s390x went with lxc1 as there were no lxd at the time; and maybe no lxd images.
<xnox> but pitti did manage to use lxc1 already with handcrafted tarballs.
<slangasek> xnox: right, the last bit is what I was trying to understand; I understand the reasons /not/ to let things in containers call mknod :)
<xnox> slangasek, what is the status of the new scalingstack in boston to move s390x to the cloud?!
<slangasek> great question
<slangasek> wgrant:
<wgrant> No progress, as far as I know.
<wgrant> (also I highlight on scalingstack, so I was already here :P)
<slangasek> hahaha
<xnox> i highlight on s390x
<handsome_feng> Hi, Could someone in Ubuntu Archive Admin team help to approve those UKUI packages? The final beta is coming soon, and we are waiting for this to do the next step, Thank you in advance ! bug: #1663477
<ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
-queuebot:#ubuntu-release- Unapproved: steam (yakkety-proposed/multiverse) [1:1.0.0.52-5ubuntu1 => 1:1.0.0.52-5ubuntu2] (no packageset)
<infinity> scalingstack: We need to talk about ppc removal Really Soon Now.
<wgrant> infinity: Hah
<wgrant> infinity: It's all ready for LP to nuke it, right?
<infinity> wgrant: If anything on our end blows up as a result, we're prepared to fix it, so sure.  Though, I think having me around when you do it might not hurt.
<infinity> (That said, you have access to ubuntu-archive@snakefruit, I believe)
<infinity> Or maybe you don't.
<infinity> But you could in a jiffy.
<infinity> wgrant: But yes, I think the next steps are "purge it with fire from zesty", "wait for garbage collection (or force early expiry and collection)", "manually tidy up dists", and interlaced in there "fix anything that breaks on snakefruit as it explodes". :P
<wgrant> infinity: I've never had snakefruit or pepo access.
<infinity> wgrant: Yeah, I realised that after I said it.
<infinity> wgrant: You meet the criteria to be in the UNIX group, if we decided that would be a good thing.
<wgrant> I do, it might be handy.
<infinity> (But I also like the precedent of not adding more people to a group where >0 members is already too many)
<wgrant> Quite.
<infinity> Hrm.  Why does sudo -l not have a flag to tell my WHY.
-queuebot:#ubuntu-release- Unapproved: steam (trusty-proposed/multiverse) [1:1.0.0.45-1ubuntu1.1 => 1:1.0.0.45-1ubuntu1.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: steam (xenial-proposed/multiverse) [1:1.0.0.48-1ubuntu3 => 1:1.0.0.48-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-6-cross-ports [i386] (zesty-proposed/main) [17ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: golang-github-grpc-ecosystem-go-grpc-prometheus [amd64] (zesty-proposed/universe) [1.1+git20160910.0.6b7015e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-grpc-ecosystem-grpc-gateway [amd64] (zesty-proposed/universe) [1.1.0+git20170127.54.6863684-1] (no packageset)
<handsome_feng>  Hi, Could someone in Ubuntu Archive Admin team help to approve those UKUI packages? The final beta is coming soon, and we are waiting for this to do the next step, Thank you in advance ! bug: #1663477
<ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
-queuebot:#ubuntu-release- New binary: rclone [amd64] (zesty-proposed/universe) [1.35-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rclone [s390x] (zesty-proposed/universe) [1.35-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rclone [ppc64el] (zesty-proposed/universe) [1.35-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rclone [i386] (zesty-proposed/universe) [1.35-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rclone [arm64] (zesty-proposed/universe) [1.35-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rclone [armhf] (zesty-proposed/universe) [1.35-1] (no packageset)
-queuebot:#ubuntu-release- New binary: abci [amd64] (zesty-proposed/universe) [0.0~git20170124.0.f94ae5e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rsc-letsencrypt [amd64] (zesty-proposed/universe) [0.0~git20160929.0.76104d2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: abci [ppc64el] (zesty-proposed/universe) [0.0~git20170124.0.f94ae5e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: abci [arm64] (zesty-proposed/universe) [0.0~git20170124.0.f94ae5e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: abci [i386] (zesty-proposed/universe) [0.0~git20170124.0.f94ae5e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint-go-p2p [amd64] (zesty-proposed/universe) [0.0~git20170113.0.3d98f67-1] (no packageset)
-queuebot:#ubuntu-release- New binary: abci [armhf] (zesty-proposed/universe) [0.0~git20170124.0.f94ae5e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: abci [s390x] (zesty-proposed/universe) [0.0~git20170124.0.f94ae5e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: abci [powerpc] (zesty-proposed/universe) [0.0~git20170124.0.f94ae5e-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dnss [amd64] (zesty-proposed/universe) [0.0~git20161126.0.162090e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnss [ppc64el] (zesty-proposed/universe) [0.0~git20161126.0.162090e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnss [arm64] (zesty-proposed/universe) [0.0~git20161126.0.162090e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnss [s390x] (zesty-proposed/universe) [0.0~git20161126.0.162090e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnss [armhf] (zesty-proposed/universe) [0.0~git20161126.0.162090e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-grpc-ecosystem-grpc-gateway [ppc64el] (zesty-proposed/universe) [1.1.0+git20170127.54.6863684-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnss [powerpc] (zesty-proposed/universe) [0.0~git20161126.0.162090e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-grpc-ecosystem-grpc-gateway [armhf] (zesty-proposed/universe) [1.1.0+git20170127.54.6863684-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-grpc-ecosystem-grpc-gateway [arm64] (zesty-proposed/universe) [1.1.0+git20170127.54.6863684-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-grpc-ecosystem-grpc-gateway [s390x] (zesty-proposed/universe) [1.1.0+git20170127.54.6863684-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-grpc-ecosystem-grpc-gateway [i386] (zesty-proposed/universe) [1.1.0+git20170127.54.6863684-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-grpc-ecosystem-grpc-gateway [powerpc] (zesty-proposed/universe) [1.1.0+git20170127.54.6863684-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnss [i386] (zesty-proposed/universe) [0.0~git20161126.0.162090e-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted abci [amd64] (zesty-proposed) [0.0~git20170124.0.f94ae5e-2]
-queuebot:#ubuntu-release- New: accepted abci [armhf] (zesty-proposed) [0.0~git20170124.0.f94ae5e-2]
-queuebot:#ubuntu-release- New: accepted abci [powerpc] (zesty-proposed) [0.0~git20170124.0.f94ae5e-2]
-queuebot:#ubuntu-release- New: accepted abci [s390x] (zesty-proposed) [0.0~git20170124.0.f94ae5e-2]
-queuebot:#ubuntu-release- New: accepted dnss [arm64] (zesty-proposed) [0.0~git20161126.0.162090e-1]
-queuebot:#ubuntu-release- New: accepted dnss [i386] (zesty-proposed) [0.0~git20161126.0.162090e-1]
-queuebot:#ubuntu-release- New: accepted dnss [ppc64el] (zesty-proposed) [0.0~git20161126.0.162090e-1]
-queuebot:#ubuntu-release- New: accepted abci [arm64] (zesty-proposed) [0.0~git20170124.0.f94ae5e-2]
-queuebot:#ubuntu-release- New: accepted abci [ppc64el] (zesty-proposed) [0.0~git20170124.0.f94ae5e-2]
-queuebot:#ubuntu-release- New: accepted dnss [armhf] (zesty-proposed) [0.0~git20161126.0.162090e-1]
-queuebot:#ubuntu-release- New: accepted dnss [s390x] (zesty-proposed) [0.0~git20161126.0.162090e-1]
-queuebot:#ubuntu-release- New: accepted abci [i386] (zesty-proposed) [0.0~git20170124.0.f94ae5e-2]
-queuebot:#ubuntu-release- New: accepted dnss [powerpc] (zesty-proposed) [0.0~git20161126.0.162090e-1]
-queuebot:#ubuntu-release- New: accepted dnss [amd64] (zesty-proposed) [0.0~git20161126.0.162090e-1]
-queuebot:#ubuntu-release- New: accepted golang-github-grpc-ecosystem-go-grpc-prometheus [amd64] (zesty-proposed) [1.1+git20160910.0.6b7015e-1]
-queuebot:#ubuntu-release- New: accepted golang-github-grpc-ecosystem-grpc-gateway [arm64] (zesty-proposed) [1.1.0+git20170127.54.6863684-1]
-queuebot:#ubuntu-release- New: accepted golang-github-grpc-ecosystem-grpc-gateway [i386] (zesty-proposed) [1.1.0+git20170127.54.6863684-1]
-queuebot:#ubuntu-release- New: accepted golang-github-grpc-ecosystem-grpc-gateway [ppc64el] (zesty-proposed) [1.1.0+git20170127.54.6863684-1]
-queuebot:#ubuntu-release- New: accepted golang-github-rsc-letsencrypt [amd64] (zesty-proposed) [0.0~git20160929.0.76104d2-2]
-queuebot:#ubuntu-release- New: accepted golang-github-grpc-ecosystem-grpc-gateway [amd64] (zesty-proposed) [1.1.0+git20170127.54.6863684-1]
-queuebot:#ubuntu-release- New: accepted golang-github-grpc-ecosystem-grpc-gateway [powerpc] (zesty-proposed) [1.1.0+git20170127.54.6863684-1]
-queuebot:#ubuntu-release- New: accepted golang-github-grpc-ecosystem-grpc-gateway [armhf] (zesty-proposed) [1.1.0+git20170127.54.6863684-1]
-queuebot:#ubuntu-release- New: accepted golang-github-grpc-ecosystem-grpc-gateway [s390x] (zesty-proposed) [1.1.0+git20170127.54.6863684-1]
-queuebot:#ubuntu-release- New: accepted rclone [amd64] (zesty-proposed) [1.35-1]
-queuebot:#ubuntu-release- New: accepted rclone [armhf] (zesty-proposed) [1.35-1]
-queuebot:#ubuntu-release- New: accepted rclone [ppc64el] (zesty-proposed) [1.35-1]
-queuebot:#ubuntu-release- New: accepted tendermint-go-p2p [amd64] (zesty-proposed) [0.0~git20170113.0.3d98f67-1]
-queuebot:#ubuntu-release- New: accepted rclone [arm64] (zesty-proposed) [1.35-1]
-queuebot:#ubuntu-release- New: accepted rclone [s390x] (zesty-proposed) [1.35-1]
-queuebot:#ubuntu-release- New: accepted rclone [i386] (zesty-proposed) [1.35-1]
<tjaalton> could someone review bug 1671799 so that I can start pushing this to proposed
<ubot5> Error: Could not gather data from Launchpad for bug #1671799 (https://launchpad.net/bugs/1671799). The error has been logged
<tjaalton>  FFe: xserver 1.19.3
<wgrant> I'm starting the removal of zesty/powerpc. Nothing should break, and packages won't vanish for a few days, but new builds and publications should have stopped. Let me know if anything seems awry.
-queuebot:#ubuntu-release- New binary: merkleeyes [i386] (zesty-proposed/universe) [0.0~git20170130.0.549dd01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: merkleeyes [s390x] (zesty-proposed/universe) [0.0~git20170130.0.549dd01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: merkleeyes [ppc64el] (zesty-proposed/universe) [0.0~git20170130.0.549dd01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: merkleeyes [amd64] (zesty-proposed/universe) [0.0~git20170130.0.549dd01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: merkleeyes [armhf] (zesty-proposed/universe) [0.0~git20170130.0.549dd01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: merkleeyes [arm64] (zesty-proposed/universe) [0.0~git20170130.0.549dd01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint [ppc64el] (zesty-proposed/universe) [0.8.0+git20170113.0.764091d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint [amd64] (zesty-proposed/universe) [0.8.0+git20170113.0.764091d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint [arm64] (zesty-proposed/universe) [0.8.0+git20170113.0.764091d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint [s390x] (zesty-proposed/universe) [0.8.0+git20170113.0.764091d-1] (no packageset)
<doko> apw: please could you consider overriding the linux autopkg test failures for binutils/gcc-6 again?
-queuebot:#ubuntu-release- New: accepted merkleeyes [amd64] (zesty-proposed) [0.0~git20170130.0.549dd01-1]
-queuebot:#ubuntu-release- New: accepted merkleeyes [armhf] (zesty-proposed) [0.0~git20170130.0.549dd01-1]
-queuebot:#ubuntu-release- New: accepted merkleeyes [ppc64el] (zesty-proposed) [0.0~git20170130.0.549dd01-1]
-queuebot:#ubuntu-release- New: accepted merkleeyes [arm64] (zesty-proposed) [0.0~git20170130.0.549dd01-1]
-queuebot:#ubuntu-release- New: accepted merkleeyes [s390x] (zesty-proposed) [0.0~git20170130.0.549dd01-1]
-queuebot:#ubuntu-release- New: accepted merkleeyes [i386] (zesty-proposed) [0.0~git20170130.0.549dd01-1]
-queuebot:#ubuntu-release- New: accepted tendermint [amd64] (zesty-proposed) [0.8.0+git20170113.0.764091d-1]
-queuebot:#ubuntu-release- New: accepted tendermint [ppc64el] (zesty-proposed) [0.8.0+git20170113.0.764091d-1]
-queuebot:#ubuntu-release- New: accepted tendermint [arm64] (zesty-proposed) [0.8.0+git20170113.0.764091d-1]
-queuebot:#ubuntu-release- New: accepted tendermint [s390x] (zesty-proposed) [0.8.0+git20170113.0.764091d-1]
<doko> although the ppc64el might be a real one ...
<jamespage> bdmurray (or any other SRU team member): the neutron task of bug 1664306 was blocked on resolution of bug 1668578 in zesty - this has now been done so please can the neutron update be accepted into yakkety so I can trigger the SRU testing process.
<ubot5> bug 1664306 in neutron (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,New] https://launchpad.net/bugs/1664306
<jamespage> cheers
<ubot5> bug 1668578 in neutron (Ubuntu Yakkety) "Newton package needs to bump dependency on python-pecan" [Medium,Triaged] https://launchpad.net/bugs/1668578
<cjwatson> Does anyone know what's up with these failed snapd autopkgtests that are stopping openssh from migrating?
-queuebot:#ubuntu-release- New binary: curry-base [i386] (zesty-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-base [ppc64el] (zesty-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-base [s390x] (zesty-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-base [amd64] (zesty-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-base [arm64] (zesty-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-base [armhf] (zesty-proposed/universe) [0.4.2-3] (no packageset)
<infinity> rtg: wgrant has a gift for you this morning.
<wgrant> rip powerpc
<infinity> rtg: As of an hour or two ago, we no longer create build records for powerpc in zesty, so your next zesty upload can drop PPC if you want.
<wgrant> At least I hope that's the gift.
<wgrant> Or I've made a terrible mistkae
<infinity> wgrant: It was either that or a lap dance.
 * wgrant shudders.
<rtg> infinity, oh gross
<infinity> Gross?
<infinity> Oh, the lap dance? :P
<rtg> he's all arms and legs. it would just hurt.
<infinity> He's a prodigy.  I'm sure he'd figure it out.
<rtg> infinity, anyway, -14 will have powerpc purged
<rtg> (maybe)
-queuebot:#ubuntu-release- New: accepted curry-base [amd64] (zesty-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted curry-base [armhf] (zesty-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted curry-base [ppc64el] (zesty-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted curry-base [arm64] (zesty-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted curry-base [s390x] (zesty-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted curry-base [i386] (zesty-proposed) [0.4.2-3]
<infinity> rtg: It doesn't have to.  But since you've already tried two or three times, just informing you that you really can this time. :P
<rtg> infinity, sforshee has enjoyed the process so much that I'm gonna let him do it again.
<sforshee> oh joy
-queuebot:#ubuntu-release- New: accepted qtubuntu-print [sync] (zesty-proposed) [0.1+17.04.20170301.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-printing-app [sync] (zesty-proposed) [0.1+17.04.20170308-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.2-0ubuntu0~16.04.1 => 2.2.6-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (yakkety-proposed/main) [2.2.2-0ubuntu0~16.10.1 => 2.2.6-0ubuntu1~16.10.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.2-0ubuntu0~14.04.1 => 2.2.6-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
<bdmurray> jamespage: should the neutron upload supersede the existing one in yakkety-proposed?
<jamespage> bdmurray: yes please -that should resolve the DEP-8 test failure (according to the bug)
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: curry-frontend [i386] (zesty-proposed/universe) [0.4.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-frontend [ppc64el] (zesty-proposed/universe) [0.4.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-frontend [amd64] (zesty-proposed/universe) [0.4.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-frontend [s390x] (zesty-proposed/universe) [0.4.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-frontend [armhf] (zesty-proposed/universe) [0.4.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-frontend [arm64] (zesty-proposed/universe) [0.4.2-5] (no packageset)
<bdmurray> slangasek: I'm looking at update-manager in -proposed for yakkety which is supposed to fix bug 1623856. I was never able to recreate it but the fix is just "+                        <property name="min_content_height">80</property>" which while it may not fix it doesn't hurt.
<ubot5> bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856
<slangasek> bdmurray: so when you trigger a dpkg conffile prompt, you can't reproduce it/
<bdmurray> slangasek: I want to do an SRU of update-manager to fix bug 1654008.
<ubot5> bug 1654008 in update-notifier (Ubuntu Yakkety) "/usr/bin/update-manager:OverflowError:/usr/bin/update-manager@117" [Undecided,New] https://launchpad.net/bugs/1654008
<bdmurray> slangasek: the description just talks about the details window which shows the log of the package download / installs
<bdmurray> slangasek: oh, hey I see it now on zesty
<bdmurray> slangasek: I guess I'll figure out how to fix it right then and bundle it with the other thing.
<slangasek> bdmurray: ok cool
-queuebot:#ubuntu-release- New binary: rustc [s390x] (zesty-proposed/universe) [1.16.0+dfsg1-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted curry-frontend [amd64] (zesty-proposed) [0.4.2-5]
-queuebot:#ubuntu-release- New: accepted curry-frontend [armhf] (zesty-proposed) [0.4.2-5]
-queuebot:#ubuntu-release- New: accepted curry-frontend [ppc64el] (zesty-proposed) [0.4.2-5]
-queuebot:#ubuntu-release- New: accepted curry-frontend [arm64] (zesty-proposed) [0.4.2-5]
-queuebot:#ubuntu-release- New: accepted curry-frontend [s390x] (zesty-proposed) [0.4.2-5]
-queuebot:#ubuntu-release- New: accepted curry-frontend [i386] (zesty-proposed) [0.4.2-5]
-queuebot:#ubuntu-release- Unapproved: rejected walinuxagent [source] (yakkety-proposed) [2.2.6-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected walinuxagent [source] (trusty-proposed) [2.2.6-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected walinuxagent [source] (xenial-proposed) [2.2.6-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: pakcs [i386] (zesty-proposed/universe) [1.14.1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (yakkety-proposed/main) [2.2.2-0ubuntu0~16.10.1 => 2.2.6-0ubuntu1~16.10.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.2-0ubuntu0~16.04.1 => 2.2.6-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.2-0ubuntu0~14.04.1 => 2.2.6-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted steam [source] (yakkety-proposed) [1:1.0.0.52-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted steam [source] (xenial-proposed) [1:1.0.0.48-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted steam [source] (trusty-proposed) [1:1.0.0.45-1ubuntu1.2]
-queuebot:#ubuntu-release- New binary: pakcs [armhf] (zesty-proposed/universe) [1.14.1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (yakkety-proposed) [2.2.6-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.6-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: pakcs [s390x] (zesty-proposed/universe) [1.14.1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.6-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (zesty-proposed/universe) [1.16.0+dfsg1-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pakcs [ppc64el] (zesty-proposed/universe) [1.14.1-4] (no packageset)
<slangasek> robru: at one point I remember discussion that the britney nagmails would happen periodically, not one time; was that idea abandoned?
<robru> slangasek: oh, uh, I don't recall that, sorry. the current implementation is just one-off emails
<robru> slangasek: do you want daily mails? I can make them happen daily ;-)
<slangasek> robru: ok, I believe I read a question about this in an email from you :)
<robru> slangasek: oh right, I remember asking that but I don't recall ever getting a reply
<slangasek> robru: *I* think daily emails are better than a one-off, but I didn't know if you had feedback from others
<jbicha> wow, daily
<robru> slangasek: I never got any feedback on that, no
<robru> slangasek: wouldn't be hard to implement, just need to change the cache from a boolean to storing age and then can send a new email every time the age increases by a day
 * slangasek nods
<slangasek> from my POV that would be better, because e.g. I might read the mail, do a thing, think it's fixed, be wrong, and never be told
<robru> slangasek: true. but if "do a thing" means "upload a new package" then there'd be a fresh timeout and fresh email for that
<slangasek> yes, but that's not always the thing I'd do
<robru> true
<slangasek> for instance, I just removed from s390x binaries
<slangasek> :)
<slangasek> s/from/some/
-queuebot:#ubuntu-release- New binary: pakcs [amd64] (zesty-proposed/universe) [1.14.1-4] (no packageset)
<Ukikie> 1. That really stinks for people without upload rights and stuff in the sponsoring queue.  2. I "fixed" a package so it builds on most arches rather than on none (now matching Debian), this would give me daily emails.  This would discourage those types of fixes IMO.  3. Can I opt-out of daily?
<robru> slangasek: ^
<nacc> Ukikie: why 1?
<Ukikie> nacc: Because you've already "fixed" it, it's pending on someone else to review, so daily reminders to fix something that you've already looked at and proposed a fix is only going to agitate one.
<nacc> Ukikie: oh i see what you mean now
<Ukikie> (And in the case of the latter, my goal was to make it better and bring it up to par with Debian, not fix the entire problem.  More specifically since the issue is in another package.)
<robru> Ukikie: well, whoever sponsored your upload will also get the same nag mail. so it's not just nagging you, at least
<slangasek> Ukikie: 1. the people being emailed are the ones who either uploaded or had sponsored the package that is stuck in -proposed; I think it's perfectly fair for those people to be asked to be responsible for following through, and if you have a package currently in this state you can point me at it and I'll sponsor it here and now
<slangasek> 3. no, you should opt out by filtering the mail on the receiving end
 * robru sighs a huge sigh of relief
<Ukikie> slangasek: Oh I agree, I'm not saying they shouldn't fix it.  Luckily I don't, I just could see how that can easily happen.  Yeah, if it goes daily I'll have to. :/  Thanks for following up.
<infinity> Daily might be excessive, but "I want to fire and forget an upload" is exactly why we're doing this.  So people stop forgetting. :P
<infinity> That is to say, I'm not sure I want uploads to be attributed to people who don't care to follow through.
<infinity> Patches, sure, but not uploads.
<Ukikie> slangasek: FWIW, the second case I gave actually does exist, I already got the second email. :P
<slangasek> sure
<slangasek> but it's only "fixed" if it lands in devel :)(
<Ukikie> infinity: If it makes you feel better, I got an upload sponsored because I knew that when gcc updated, it'd ftbfs.  So I got it fixed before it broke. :)
<slangasek> and someone who has the context to say the package is now fixed but needs manual action by an AA can tell us that
<Ukikie> (New package for Ubuntu, so the rest did migrate.)
<infinity> robru, slangasek: Anyhow, if we're to make the mails repeat (not the worst idea ever), might I suggest an exponential back-off?  Either 2^n or 3^n (where n=notified_count) would probably be a bit less ick.
<robru> infinity: you mean send an email every 2^n days?
<slangasek> infinity: if daily is too frequently, I think repeating at a fixed interval is better than an exponential backoff
<slangasek> I /want/ someone who has a package stuck in -proposed to be annoyed by the mails ;)
<robru> I'm open to whatever is decided
<infinity> Maybe I'm special, but I find that predictably repetitive emails end up deleted as noise.  "oh look, that again".  An exponential back-off lets you simmer down from your annoyance about useless email for a bit before it reminds you that, hey, you're still a slacker.
<infinity> So, it's partially about being less annoying for things stuck for a long time, but also a bit of a psychological warfare via rfc2822 game.
<slangasek> maybe we should ask how quickly we can reasonably expect someone to respond to such a mail
<slangasek> because it doesn't make sense to ever send the mails more frequently than that response time
<infinity> (And, really, if it's been stuck for 64 or 128 days, it's in the realm of "clearly there's a larger problem", and a daily/frequent nag WILL be ignored to the point where it's meaningless)
<slangasek> infinity: except in the case of the initial mails, where everything was stuck a long time and the mails have just started
<infinity> Though a cap on the back-off would also be reasonable, as eventually "every 3 years" is pointless too. ;)
<infinity> 2^n, capped at 32 seems like a reasonable straw man to me.
<robru> instead of a backoff based on the number of mails sent, it should be a backoff based on the existing age, as indeed there are already packages stuck for multiple hundreds of days that we probably don't want daily nags for
<infinity> Cause, yes, it's reasonable to expect people to respond in the first 1 and 2 days, but if they don't, they're not likely to suddenly find the time on day 3, hence the back-off, to balance nag with desensitizing them.
<robru> actually I'm liking this idea.
<infinity> robru: Assuming the cap, one could just one-time mangle the back-off DB to say all of that is at the 32 mark or whatever.
<infinity> robru: Err, on the other hand, your way is one state file less, so do that. :P
<infinity> robru: (We already have state for age, counting emails is silly)
<robru> heh
<infinity> Just means some stat and sloppy math to make sure you never miss an age "tick", but also don't count one twice.
<robru> slangasek: ^ so, uh, are we doing exponential backoff with a ceiling of monthly nag mails?
<robru> I already have the code written for daily but wouldn't be hard to change
<nacc> slangasek: so it seems like emacs25 stuck in -proposed occurred with 25.1+1-2ubuntu3 ... but not before. dannf was looking into it, but I don't think we have much progress on it yet :/. it's holding up imagemagick (which in turn is holding up emacs24)
<dannf> nacc: fwiw, been trying to repro on debian, no success so far
<Ukikie> robru: Hrm, I thought there was going to be a header for this?  I'm not seeing it.
<robru> Ukikie: yeah, should be X-Proposed-Migration
<robru> Ukikie: https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney2/policies/email.py#n25 this is the email that gets sent
<infinity> From the psychological perspective, powers of 2 not exactly matching week lengths also shuffles things around enough that you wouldn't be nagging a Friday uploader every Friday night.  Unpredictability is key to a successful nag.
<Ukikie> robru: Oh hrm, thanks.  That's not the message I got.
<infinity> And I've officially spent too much time thinking about this when I was meant to be napping.
<robru> Ukikie: then I dunno what you got but it's not a "stuck in -proposed" nag ;-)
<Ukikie> Indeed.  Guess a random rebuild one that came at a suspicious time. :P
<infinity> I did do a mass retry of FTBFS this morning.
<Ukikie> Fri, 17 Mar 2017 07:37:24; that'd be it.
<robru> brb
<nacc> dannf: darn! :/
<nacc> dannf: i get the feeling that the paralle=1 change was done for this reason before, and ithappened to fix it, but maybe was just masking it
<dannf> yeah, i can try dropping that to see if it makes it more reproducible
<nacc> dannf: it's hard to say if it was fixing/working around this issue or if it was any of the other arm64 failures we see :)
<dannf> oh, nm- parallel builds are enabled now - didn't realize that'd been restored
<dannf> what's the memsize of our arm64 guest builders again? i've tried w/ 1G & 2G of mem assigned
<dannf> w/ & w/o swap
<infinity> dannf: They should be 4cores/8gigs.
<nacc> dannf: https://launchpad.net/ubuntu/+source/emacs25/25.1+1-3ubuntu1 says it's parallel=1 on arm64?
<dannf> oh - yeah, it's because i'm using debian's source (since i was trying to repro in debian, to get a bug filed/help there)
<nacc> dannf: ack
<nacc> dannf: which i guess is even stranger, we use a stricter paralle and trigger it :)
<dannf> yeah, i probably need to get back to where i can reproduce it on ubuntu - but even then, it wasn't very reliable in my case
<dannf> or find someone that can actually debug emacs :)
<slangasek> robru: I am not convinced by the argument for a backoff; but a backoff would get us more mails than we get currently, so I'm ok to go ahead with that
-queuebot:#ubuntu-release- New binary: pakcs [arm64] (zesty-proposed/universe) [1.14.1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.175.1 => 3.175.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.8 => 1:16.10.9] (core)
-queuebot:#ubuntu-release- New binary: gcc-6-cross-ports [amd64] (zesty-proposed/main) [17ubuntu1] (ubuntu-desktop)
#ubuntu-release 2017-03-18
-queuebot:#ubuntu-release- Unapproved: rejected tftp-hpa [source] (xenial-proposed) [5.2+20150808-1ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected tftp-hpa [source] (trusty-proposed) [5.2-7ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: rejected tftp-hpa [source] (yakkety-proposed) [5.2+20150808-1ubuntu1.16.10.1]
-queuebot:#ubuntu-release- New: accepted gcc-6-cross-ports [amd64] (zesty-proposed) [17ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-6-cross-ports [i386] (zesty-proposed) [17ubuntu1]
-queuebot:#ubuntu-release- New: accepted pakcs [amd64] (zesty-proposed) [1.14.1-4]
-queuebot:#ubuntu-release- New: accepted pakcs [armhf] (zesty-proposed) [1.14.1-4]
-queuebot:#ubuntu-release- New: accepted pakcs [ppc64el] (zesty-proposed) [1.14.1-4]
-queuebot:#ubuntu-release- New: accepted pakcs [arm64] (zesty-proposed) [1.14.1-4]
-queuebot:#ubuntu-release- New: accepted pakcs [s390x] (zesty-proposed) [1.14.1-4]
-queuebot:#ubuntu-release- New: accepted pakcs [i386] (zesty-proposed) [1.14.1-4]
<wgrant> infinity: Is proposed-migration meant to not be triggering for zesty? It's been several hours. archive-reports logs reveal that component-mismatches is broken and the zesty(-proposed)-powerpc chdists need removing, but neither seems fatal given that p-m is still running OK for trusty/xenial/yakkety.
-queuebot:#ubuntu-release- New binary: rustc [i386] (zesty-proposed/universe) [1.16.0+dfsg1-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (zesty-proposed/universe) [1.16.0+dfsg1-1~exp1ubuntu1] (no packageset)
<infinity> wgrant: p-m for devel is a slightly different beast, it may well be not running due to other things in the pipe being broken.
<infinity> wgrant: I'll look after I've eaten... Whatever meal this is.
<wgrant> infinity: Hm, I thought the bit in a-r that triggered it looked pretty clear, but there are so many globals maybe I got lost
<wgrant> Maybe it is just the obsolete chdists. component-mismatches' trigger condition is different, which I hadn't realised.
<infinity> wgrant: Does that mean you figured it out while I was out fooding, or are you still stumped?
<wgrant> infinity: It's hopefully kicking off now...
<wgrant> infinity: Yeah, there we go.
<wgrant> Just needed to remove the two obsolete chdists. No idea why that took six hours to break...
<wgrant> Though component-mismatches will also need a fix.
<infinity> I'm looking at u-a-t right now.
<infinity> (including c-m)
<wgrant> Yep
<wgrant> Thanks.
<infinity> Kay, done.
-queuebot:#ubuntu-release- New binary: rustc [armhf] (zesty-proposed/universe) [1.16.0+dfsg1-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (zesty-proposed/universe) [1.16.0+dfsg1-1~exp1ubuntu1] (no packageset)
#ubuntu-release 2017-03-19
-queuebot:#ubuntu-release- New sync: matrix-synapse (zesty-proposed/primary) [0.19.2+dfsg-5]
-queuebot:#ubuntu-release- New binary: devhelp [amd64] (zesty-proposed/main) [3.24.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [ppc64el] (zesty-proposed/main) [3.24.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [i386] (zesty-proposed/main) [3.24.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [s390x] (zesty-proposed/main) [3.24.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [arm64] (zesty-proposed/main) [3.24.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [armhf] (zesty-proposed/main) [3.24.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted devhelp [amd64] (zesty-proposed) [3.24.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted devhelp [armhf] (zesty-proposed) [3.24.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted devhelp [ppc64el] (zesty-proposed) [3.24.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted matrix-synapse [sync] (zesty-proposed) [0.19.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (zesty-proposed) [1.16.0+dfsg1-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (zesty-proposed) [1.16.0+dfsg1-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (zesty-proposed) [1.16.0+dfsg1-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [arm64] (zesty-proposed) [3.24.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted devhelp [s390x] (zesty-proposed) [3.24.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (zesty-proposed) [1.16.0+dfsg1-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [i386] (zesty-proposed) [3.24.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (zesty-proposed) [1.16.0+dfsg1-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (zesty-proposed) [1.16.0+dfsg1-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New binary: matrix-synapse [amd64] (zesty-proposed/universe) [0.19.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New: accepted matrix-synapse [amd64] (zesty-proposed) [0.19.2+dfsg-5]
-queuebot:#ubuntu-release- New binary: golang-github-google-certificate-transparency [amd64] (zesty-proposed/universe) [0.0~git20160709.0.0f6e3d1~ds1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: juju-mongodb3.2 (xenial-proposed/universe) [3.2.9-0ubuntu1~16.04 => 3.2.12-0ubuntu1~16.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: juju-mongodb3.2 (yakkety-proposed/universe) [3.2.9-0ubuntu1 => 3.2.12-0ubuntu1~16.10] (no packageset)
<mapreri> I can't get the diffoscope autopkgtest on armhf to pass, it keeps timeouting.  In the past it used to pass after a retry or two, v80 doesn't seem to want to.  I know that the test will pass if it had some more minutes.  What should I do?
#ubuntu-release 2018-03-12
-queuebot:#ubuntu-release- New binary: python3-antlr3 [amd64] (bionic-proposed/universe) [3.5.2-4] (no packageset)
<handsome_feng> Hi, I'll appreciate it if someone could help to have a look at the ukwm in bionic new queue. Thank you in advance! LP: #1740252
<ubot5`> Launchpad bug 1740252 in Ubuntu Kylin "[FFe] ukwm" [Critical,In progress] https://launchpad.net/bugs/1740252
<foka> ginggs, thank you very much for retriggering the autopkgtests for golang-blackfriday/hugo/golang-github-chaseadamsio-goorgeous!
<foka> ginggs, as to where I went (haha), I rebooted my laptop to a pre-release daily build of Lubuntu that my friend installed on a new SSD he purchased.  He got the SSD on-sale for a local weekend Chinese school, but the first one died soon after installing Zorin OS on it (became unwritable), so he returned it and got another one, and this time I recommended Lubuntu (for an older computer).  He asked me to run some more tests to make sure the
<foka> SSD is OK this time.  Then there was a long retreat at our church today, so I was gone pretty much the whole day.
<foka> (I know, I should have gotten my IRC proxy back up and running, or get IRC working on my Android phone, but I was either too busy or too lazy, haha!
<foka> I did get your messages through https://irclogs.ubuntu.com/2018/03/11/%23ubuntu-release.html though, so, thank you again!  ;-)
<foka> I can go close https://github.com/gohugoio/hugo/issues/4350 now.  Thanks for helping getting the most recent and most stable version of Hugo into bionic!
<foka> handsome_feng, for FFe Sync requests, it might be easier if you had used the "requestsync" command...
<foka> handsome_feng, Oh wait, ukwm isn't in Debian yet!?  Why not?
<handsome_feng> foka: We are currently focusing on the Ubuntu platform, and the man who responsible for the uploads of new UKUI packages to Debian lost his gpg key, which led to the lag of plan...
<foka> handsome_feng, Nevertheless, for an "FFe", it seems you have forgotten to subscribe the ubuntu-release team to the bug.
<handsome_feng> Oh, Thanks! :)
<foka> handsome_feng: What!?  How did your team member lose his GPG key?
<foka> handsome_feng: Anyhow, if you need a sponsor for uploading to Debian, you can bug me.  ;-)
<foka> handsome_feng, about LP: 1740252, I think it would raise more attention if you mention that Ukwm is to become the *official* window manager for Ubuntu Kylin in bionic.
<ubot5`> Launchpad bug 1740252 in Ubuntu Kylin "[FFe] ukwm" [Critical,In progress] https://launchpad.net/bugs/1740252
<handsome_feng> foka: I don't know the details, :(. Thank you for your help! and sorry for that I am a bit slow to reply.
<foka> handsome_feng, æ²¡å³ç³»ï¼ä½ ä»¬é£è¾¹ç°å¨ææä¸äºå§ï¼ä¸å®æ¯å¾å¿ã No worries!  It must be Monday already in China, right?  You must be busy.
<handsome_feng> foka:woooh, your chinese is excellent. Not because it's busy, It is I am looking up the dictionary. :P
<foka> handsome_feng, ææ¯ä¸­å½äººâ¦â¦æèæ¯ä¸­å½é¦æ¸¯äººã
<handsome_feng> foka: å, å¼å¿å¾æµç¼æ³ª!
-queuebot:#ubuntu-release- New: accepted python3-antlr3 [amd64] (bionic-proposed) [3.5.2-4]
-queuebot:#ubuntu-release- New: accepted wsmancli [arm64] (bionic-proposed) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wsmancli [i386] (bionic-proposed) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wsmancli [s390x] (bionic-proposed) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wsmancli [amd64] (bionic-proposed) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wsmancli [ppc64el] (bionic-proposed) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wsmancli [armhf] (bionic-proposed) [2.6.0-0ubuntu1]
<LocutusOfBorg> hello release team this is something I think might be beneficial for everybody... what about grouping this page for year? http://people.canonical.com/~ubuntu-archive/auto-sync/
<LocutusOfBorg> having all the days since 2014 in the same page is... strange
<apw> LocutusOfBorg, i tend to use http://people.canonical.com/~ubuntu-archive/auto-sync/?C=N;O=D to have the useful ones right there and not worry
<LocutusOfBorg> apw, yes I know, but doing a "mkdir 2014; mv 2014* 2014" and so on, at least until 2017 might make the package more readable and faster loadable
<LocutusOfBorg> we can keep all the 2018 entries, but I don't think people needs older years, at least in the "homepage"
 * LocutusOfBorg finished his fast-internet mobile plan monthly queue, so will load that page at 128kb for some more days :p
-queuebot:#ubuntu-release- New binary: llvm-defaults [s390x] (bionic-proposed/universe) [0.41~exp4] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (bionic-proposed/universe) [0.41~exp4] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [ppc64el] (bionic-proposed/universe) [0.41~exp4] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [i386] (bionic-proposed/universe) [0.41~exp4] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [arm64] (bionic-proposed/universe) [0.41~exp4] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [armhf] (bionic-proposed/universe) [0.41~exp4] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-defaults [amd64] (bionic-proposed) [0.41~exp4]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [armhf] (bionic-proposed) [0.41~exp4]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [ppc64el] (bionic-proposed) [0.41~exp4]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [arm64] (bionic-proposed) [0.41~exp4]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [s390x] (bionic-proposed) [0.41~exp4]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [i386] (bionic-proposed) [0.41~exp4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu7.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu7.3]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (artful-proposed) [5.1.34-dfsg-0ubuntu1.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (artful-proposed) [5.1.34-0ubuntu1.17.10.1]
<sil2100> LocutusOfBorg: hey! You around? Looking at the artful virtualbox-ext-pack now and I see something I'd like to double confirm
<sil2100> LocutusOfBorg: in debian/postinst there's version=5.1.32 while the version of the package is 5.1.34 - is that ok?
<sil2100> LocutusOfBorg: same for debian/rules
<doko> apw: is the linux autopkg test failure rectified? blocks binutils
<apw> why does it block binutils ?
<apw> we should have stopped using libbfd
<doko> the use of libbfd doesn't affect the autopkg test
<apw> doko, oh the s390x thing, i think that is ok, but i will poke seth to confirm
<acheronuk> mwhudson: I may have a fix for casper re:kubuntu live session. if it tests of, where and how would be best to submit? bug with a debdiff?
<acheronuk> *tests ok
<cyphermox> acheronuk: yes
<acheronuk> ok. thx
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.2-0ubuntu1.1 => 2:11.0.2-0ubuntu1.3] (openstack, ubuntu-server)
<sforshee> doko, apw: the linux s390x failure is indeed ok, just a change to the content of /proc/kallsyms that will get changed back in the next upload
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu6 => 2:8.4.0-0ubuntu7.1] (openstack, ubuntu-server)
<apw> Laney, are you about, i am hearing the ppc64el jobs in bionic might be looping, for the kernel
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.1]
<xnox> slangasek, https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1755184 looks like it is ready to be removed, with an ack from seb.
<ubot5`> Ubuntu bug 1755184 in unity-scopes-api (Ubuntu) "RM: obsolete product" [High,Triaged]
<LocutusOfBorg> sil2100, thanks for vbox, please look at my reply wrt ext-pack, and also accept kbuild/xenial to make it build!
<sil2100> Yeah, in progress! Got preempted with DMB meeting...
<LocutusOfBorg> oooh sorry! I though it was a problem in my process
<LocutusOfBorg> people, AA, please KICK OUT node-rollup-plugin-commonjs from bionic-proposed
<LocutusOfBorg> it is not built, so I hope doable with not much effort
<LocutusOfBorg> I'm trying to rollup-bootstrap-rollup-and-itself-changing-bits, and discovered #892742
-queuebot:#ubuntu-release- New binary: libzstd [s390x] (bionic-proposed/universe) [1.3.3+dfsg-2ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libzstd [amd64] (bionic-proposed/universe) [1.3.3+dfsg-2ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libzstd [ppc64el] (bionic-proposed/universe) [1.3.3+dfsg-2ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libzstd [i386] (bionic-proposed/universe) [1.3.3+dfsg-2ubuntu1] (ubuntustudio)
<xnox> apw, slangasek, sil2100 - ^^^^ should unbreak btrfs-progs, as these need a libzstd1-udeb. Also package is fixed up to be in a good shape for MIR.
-queuebot:#ubuntu-release- New binary: libzstd [arm64] (bionic-proposed/universe) [1.3.3+dfsg-2ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted kbuild [source] (xenial-proposed) [1:0.1.9998svn2814+dfsg-2~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: libzstd [armhf] (bionic-proposed/universe) [1.3.3+dfsg-2ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (artful-proposed) [5.1.34-0ubuntu1.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.1]
<doko> apw, sforshee: please could you update the hint then?
-queuebot:#ubuntu-release- New: accepted libzstd [amd64] (bionic-proposed) [1.3.3+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libzstd [armhf] (bionic-proposed) [1.3.3+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libzstd [ppc64el] (bionic-proposed) [1.3.3+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libzstd [arm64] (bionic-proposed) [1.3.3+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libzstd [s390x] (bionic-proposed) [1.3.3+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libzstd [i386] (bionic-proposed) [1.3.3+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-pylxd [source] (xenial-proposed) [2.0.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected proftpd-dfsg [source] (xenial-proposed) [1.3.5a-1.1]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (artful-proposed) [2:11.0.2-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (artful-proposed) [0.6.5.11-1ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (artful-proposed) [0.6.5.11-1ubuntu3.2]
<jbicha> slangasek: please add /i386 to the end of this changed line (so we don't ignore all LO/bionic autopkgtest results) https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/2900
-queuebot:#ubuntu-release- Unapproved: accepted proftpd-dfsg [source] (xenial-proposed) [1.3.5a-1ubuntu0.1]
<acheronuk> slangasek or infinity: could we maybe get an ack on this? https://bugs.launchpad.net/ubuntu/+source/plasma-framework/+bug/1754825
<ubot5`> Ubuntu bug 1754825 in plasma-framework (Ubuntu Bionic) "[FFe] KDE Frameworks 5.44.0 into the Bionic Archive" [Undecided,Confirmed]
<tsimonq2> +1
<infinity> acheronuk: ACKed in the bug.
<acheronuk> infinity: superb. thanks you :)
<acheronuk> *thank
<estan> hi all. would it be possible for you folks to merge into artful c-blosc 1.14.0 from debian, once it hits unstable? i recently reported this to the debian maintainer and he was kind enough to quickly make a new package: https://salsa.debian.org/debian/c-blosc/merge_requests/1
<estan> the problem with the 1.11.1 version that is currently in unstable is that it's one of the "bad apple" versions that accidently broke forward compatibility with all older versions of the library.
<estan> (the upstream author has fixed it in 1.14.0, and also blogged about the incident here: http://blosc.org/posts/new-forward-compat-policy/)
<estan> err, s/artful/bionic/
<nacc> estan: have you filed  abug in ubuntu?
<slangasek> xnox: thanks, LP: #1755184 done
<ubot5`> Launchpad bug 1755184 in unity-scopes-api (Ubuntu) "RM: obsolete product" [High,Fix released] https://launchpad.net/bugs/1755184
<slangasek> jbicha: hint adjusted; btw I'm puzzled by the libreoffice results against dconf, showing "ignored failure"s that didn't match any of the versioned hints
-queuebot:#ubuntu-release- New binary: dh-runit [amd64] (bionic-proposed/universe) [2.7.1] (no packageset)
<estan> nacc: ah no. i guess i should do that. i just wasn't sure if it'll automatically trickle out to ubuntu, now that i set it in motion in debian. but i guess i should file an ubuntu bug to hurry it along.
<nacc> estan: we're after debian import freeze
<tsimonq2> OK, so what is going on here? Lubuntu's images aren't picking up our ship-live-share seed when it
<tsimonq2> *it's explicitly included in lp:ubuntu-cdimage.
<tsimonq2> Er, OK, so it's pulling the seed in, but it isn't installing most of the packages that are in here...
<tsimonq2> e.g. grepping the manifest doesn't return lvm2.
-queuebot:#ubuntu-release- New binary: prison-kf5 [s390x] (bionic-proposed/universe) [5.44.0-0ubuntu1] (kubuntu)
<tsimonq2> Er, I'm dumb.
<tsimonq2> Now to see if this bug is *actually* legitimate... >_<
<tsimonq2> Thanks for the rubber ducky I guess
<wxl> tsimonq2: which bug are you on about it again?
<tsimonq2> wxl: LVM installs not working.
<tsimonq2> If that works fine, my next thing is figuring out why in the heck encrypted LVM installs still try to assign unencrypted swap and then just error out...
<foka> Hi tsimonq2!  This might be off-topic, but after installing LibreOffice on Lubuntu bionic i386 daily live image, lowriter does not start properly.  No such problem on Lbuntu amd64 bionic.  (I probably should file a bug, but I'll need to reproduce it first and get some more data, haha)  By the way, Lubuntu works great!  It is *lighting* fast!  Thank you for your great work!
-queuebot:#ubuntu-release- New binary: prison-kf5 [amd64] (bionic-proposed/universe) [5.44.0-0ubuntu1] (kubuntu)
<tsimonq2> foka: Let's move this to #lubuntu :)
<tsimonq2> But thanks :D
<foka> tsimonq2, Good idea!
-queuebot:#ubuntu-release- New binary: prison-kf5 [i386] (bionic-proposed/universe) [5.44.0-0ubuntu1] (kubuntu)
<wxl> tsimonq2: interesting that the ubiquity issue seems to be something about lvm, even though adam calls it a red herring
<tsimonq2> wxl: I'm working on something unrelated.
<tsimonq2> Yeah, waaaaaaaat, LVM install fails...
<infinity> wxl: It has nothing to do with lvm.
<infinity> tsimonq2: lvm2 installs will indeed fail, but not related to the other issue.
<infinity> (And easily solved)
<tsimonq2> infinity: So, can ya give me a hint? ;)
<tsimonq2> lvm2 is indeed installed
<infinity> wxl: No it's not.
<infinity> Err.
<infinity> tsimonq2: No it's not. :P
<tsimonq2> Err.
<tsimonq2> What?
<tsimonq2> infinity: So... why?
<infinity> What makes you think it is?
<infinity> ship-live != live.
<tsimonq2> It's in the ISO pool.
<tsimonq2> Oh.
<infinity> Having a deb in a pool isn't the same as having it installed.
<tsimonq2> Maybe that... yeah.
<tsimonq2> Duh. :)
<tsimonq2> I'll... do the thing.
-queuebot:#ubuntu-release- New binary: prison-kf5 [arm64] (bionic-proposed/universe) [5.44.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: prison-kf5 [ppc64el] (bionic-proposed/universe) [5.44.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: prison-kf5 [armhf] (bionic-proposed/universe) [5.44.0-0ubuntu1] (kubuntu)
<infinity> That said, it should probably be in live-common if it's needed.
<infinity> So, hold up on hacking around in your seeds.
<tsimonq2> OK.
<tsimonq2> (And why in the heck is the option even available if lvm2 isn't installed? lolwat)
<infinity> It's possible that ubiquity should also depend on it instead of recommending, but happy to just seed it in common for now.
<infinity> ubiquity probably should do a better job of hiding that option if lvm2 isn't there, *or* not making it optional.
<infinity> Although, we already seed-instead-of-depend for xfsutils, jfsutils, etc, so I guess there's precedent here.
<infinity> tsimonq2: Committed.  And you probably don't need it in ship-live.
<tsimonq2> infinity: ACK.
<tsimonq2> infinity: Oh yeah, and Ubiquity lolwats at encrypted LVM because "Unsafe swap detected" so it still wants to do a thing with swap when that option's selected. I don't know yet if it's Just A Lubuntu Thing or a global thing, but ideas on fixing it would be cool.
<tsimonq2> Oh great, so it's just a Lubuntu thing.
<tsimonq2> Fun.
<tsimonq2> infinity: Oh, duh, the problem is that Lubuntu uses zram and Ubiquity thinks that it's a security risk (but it really ain't).
<tsimonq2> Let me see if I can throw you a patch.
<tsimonq2> Actually, it's partman-auto-crypto that seems to be doing the weird stuff.
#ubuntu-release 2018-03-13
-queuebot:#ubuntu-release- New: accepted dh-runit [amd64] (bionic-proposed) [2.7.1]
-queuebot:#ubuntu-release- New: accepted prison-kf5 [arm64] (bionic-proposed) [5.44.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted prison-kf5 [i386] (bionic-proposed) [5.44.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted prison-kf5 [s390x] (bionic-proposed) [5.44.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted prison-kf5 [amd64] (bionic-proposed) [5.44.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted prison-kf5 [ppc64el] (bionic-proposed) [5.44.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted prison-kf5 [armhf] (bionic-proposed) [5.44.0-0ubuntu1]
<estan> nacc: finally got around to reporting that bug: https://bugs.launchpad.net/ubuntu/+source/c-blosc/+bug/1755380
<ubot5`> Ubuntu bug 1755380 in c-blosc (Ubuntu) "Please sync c-blosc 1.14.0+ds1-1 from debian unstable to bionic (1.11.1 has format incompat bug!)" [Undecided,New]
<estan> would be great if this could be sneaked through, infinity (?) ^
<ginggs_> estan: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_upstream_versions
<estan> ginggs_: ah thanks, i'll make sure to go through those steps.
<infinity> estan: Don't worry about jumping through hoops, FFe approved and I'll sync it.
<estan> infinity: many thanks!
<Laney> apw: looking at that loop thing now
<Laney> if you want a sneak peek, https://paste.ubuntu.com/p/JBHVsV9SsZ/
<Laney> but I'll make it turn into a real failure
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (xenial-proposed/multiverse) [5.1.34-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.2] (no packageset)
<apw> Laney, that is really not anything at all is it .. hrm
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (xenial-proposed/main) [1.361.1 => 1.413] (core)
<apw> ^ that seems unlikely
<Laney> :D
<apw> cpaelzer, ^^ ??
<apw> and some !!s too
<cpaelzer> apw: Laney: what's up
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (xenial-proposed) [1.413]
<apw> cpaelzer, ^
<cpaelzer> the test linked above?
<cpaelzer> or the ubuntu-meta
<cpaelzer> ?
<cpaelzer> UUUH
<cpaelzer> I see
<cpaelzer> I see ++
<cpaelzer> please reject
<cpaelzer> of course not xenial
<apw> alerady gone
<cpaelzer> WTF could that happen
 * cpaelzer takes all ! needed for this
<apw> wrong branch perhaps ?
<cpaelzer> need to check in detail
<cpaelzer> didn't feel wrong while doing
<Laney> how did you enter the release into the changelog?
<apw> cpaelzer, yeah it was based on bionic so that part is right ...
<doko> apw: linux autopkg test override ping
<cpaelzer> Found the path that lead to this xenial in the CL
<cpaelzer> I built in a container to have the correct env /e.g. debootstrap version) which makes it an UNRELEASED entry, then on my system applied the change and ran dch --release to set the mail right
<cpaelzer> on the latter it defaulted to xenial (systems version)
<cpaelzer> after that neither myself nor on the review it was found
<cpaelzer> thanks to SRU queue to catch it
<cpaelzer> :q
<apw> it is the last line of defence
<cpaelzer> almost right window
<Laney> nah, proposed would have done too
<Laney> xenial switched to gnome shell(!)
<apw> well i'd prefer to avoid polluting -proposed with 'forward' versions
<cpaelzer> also in proposed my shame would have been around forever in publishing history - now it at least diminishes from this log and your minds :-)
<Laney> not the cleanest, but for sure you would have heard some screams
<Laney> cpaelzer: it's OK, https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=ubuntu-meta doesn't forget :D
<cpaelzer> hehe
<apw> heh yeah, it is never forgotten :)
<apw> and it makes diffs sad mostly
<apw> (if it has published)
<apw> doko, soz, sorted
<cjwatson> infinity,slangasek: Would one of you care to review https://code.launchpad.net/~cjwatson/ubuntu-archive-publishing/sign-parts/+merge/336347 ?  This is in service of https://code.launchpad.net/~cjwatson/launchpad/archive-signing-run-parts/+merge/336373, which is part of the work to add InRelease to by-hash directories
<cjwatson> (Remaining MPs in the arc are https://code.launchpad.net/~cjwatson/launchpad/refactor-archive-signing/+merge/336377 and https://code.launchpad.net/~cjwatson/launchpad/inrelease-by-hash/+merge/336675)
<cpaelzer> Laney: a while ago you cleaned up a case where all ppc64el builders where hanigng on clean up - I think it is happening again
<cpaelzer> test and build queues also match that
<cpaelzer> whatever you did back then, could you repeat that - or is it s a different case this time?
<cjwatson> cpaelzer: Builders or autopkgtest instances?
<Laney> cpaelzer: for buildds that can't have been me
<Laney> This person right here
<cjwatson> For builders it's being investigated at the moment
<cpaelzer> it was builders, but since it is investigated already I'll just wait
<cpaelzer> Laney: maybe you just knew who to ping to resolve back then, it was builders as well
-queuebot:#ubuntu-release- New binary: gcc-7-cross [amd64] (bionic-proposed/main) [17ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted gcc-7-cross [amd64] (bionic-proposed) [17ubuntu1]
<Odd_Bloke> nacc: rbasak: o/ It looks like my pending uploads from https://gist.github.com/OddBloke/08f68c18f2f3d63a002f2c1a26a765ac are still pending.
<Odd_Bloke> As I haven't seen any messages to suggest that they haven't passed a review or anything I assume they just dropped off the radar, so I'm popping them back on. :)
<rbasak> Oh, sorry.
<rbasak> I thought nacc was going to take over?
-queuebot:#ubuntu-release- New sync: javabeans-activation-framework (bionic-proposed/primary) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted javabeans-activation-framework [sync] (bionic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New binary: gcc-8-cross [amd64] (bionic-proposed/main) [6ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted gcc-8-cross [amd64] (bionic-proposed) [6ubuntu1]
-queuebot:#ubuntu-release- New binary: javabeans-activation-framework [amd64] (bionic-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted javabeans-activation-framework [amd64] (bionic-proposed) [1.2.0-1]
<cyphermox> Laney: I'm not sure if I had shared with you the result of my test w/ britney's update_output.txt outputting json?  https://paste.ubuntu.com/p/c53gXp2hRg/
<cyphermox> err
<cyphermox> yaml, I mean
<apw> cyphermox, what is intending to consume that
<cyphermox> I'm writing a script that can already parse excuses.yaml; it would be nice to continue on with parsing update_output for the rebuilds/whatnot that need to happen to fully unblock a transition.
<cyphermox> I have yet to talk about it with Debian people
<apw> cyphermox, sounds like a laudible goal to me
<cyphermox> scratch that last message, I have left a comment on a relevant open issue on Debian's britney2
 * tsimonq2 wonders if Ben could pick that up somehow
<cyphermox> tsimonq2: already started convo, so we're good for now I think
<tsimonq2> cyphermox: Cool cool
<Laney> cyphermox: nice
<Laney> I wonder if the format could be rationalised a bit
<Laney> there's probably more structure that could be introduced
<Laney> but I guess this is more or less directly spat out from the code now
<cyphermox> Laney: of course, I just did that by hand, to see if it was feasible without changing any of the output code
<Laney> â¥
<xnox> cyphermox, does https://bugs.launchpad.net/ubuntu/+source/libzstd/+bug/1755310 look roughly right? e.g. is it in the correct state to be noticed by MIR team?
<ubot5`> Ubuntu bug 1755310 in libzstd (Ubuntu) "MIR libzstd" [High,Confirmed]
<xnox> i see the link is up, on the components-missmatches-proposed.html page, but I'm not sure if i got the state / assignees / subscribers right, to "submit" the MIR for review.
<cyphermox> xnox: it's in the correct state, but you don't need to assign
<xnox> cyphermox, ack.
<juliank> xnox: oh, we can use it for initramfs too?
<juliank> xnox: Are you confusing that with lz4?
<xnox> juliank, with bionic's kernel, i believe you can, yes.
<juliank> hmm no, it's advertised
<xnox> $ cat config-4.15.0-10-generic  | grep ZSTD
<xnox> CONFIG_SQUASHFS_ZSTD=y
<xnox> CONFIG_ZSTD_COMPRESS=m
<xnox> CONFIG_ZSTD_DECOMPRESS=y
<juliank> there's just no announcement anywhere...
<xnox> decompress is built in, thus eligible for initramfs i believe....
<xnox> juliank, do you expect a CONFIG_RD_ZSTD or some such?
<xnox> squashfs is definately there.
<juliank> I just searched for zstd initramfs and did not find anything concrete
<xnox> so maybe we can speeding up live-installer, for reals.
<Odd_Bloke> rbasak: Yeah, I wasn't sure if I'd missed some discussion that you might have been privy to.
<xnox> juliank, grepping for e.g. RD_LZ4 i don't see if anything new gets compiled, apart from enabling kernel decompression as a built it.
<xnox> juliank, to me it looks like one can totally use zstd initramfs...
<juliank> xnox: I think I built one, though initramfs-tools does not advertise it yet
<juliank> took 16 seconds isntead of 23
<juliank> xnox: It definitely built, let's see if we can boot it
<juliank> xnox: seems to work in qemu. It's a bit too fast to read "Unpacking initramfs" now, though :D
<xnox> juliank, well, check dmesg?
<juliank> I only booted the kernel with initramfs, and did not have a rootfs :D
<juliank> both crashed not finding root, so that's good :D
<juliank> will reboot in real shortly
<juliank> rbalint: seems like zstd is a good choice for initramfs, too. compresses in same time as lz4, but smaller than gzip. probably not much slower than lz4 when decompressing for boot
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (artful-proposed/partner) [1:20180206.1-0ubuntu0.17.10.1 => 1:20180313.1-0ubuntu0.17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20180206.1-0ubuntu0.16.04.1 => 1:20180313.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20180206.1-0ubuntu0.14.04.1 => 1:20180313.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (xenial-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.16.04.1 => 5.1.34-dfsg-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (artful-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.17.10.1 => 5.1.34-dfsg-0ubuntu1.17.10.2] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.16.04.1 => 5.1.34-dfsg-0ubuntu1.16.04.2] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox (artful-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.17.10.1 => 5.1.34-dfsg-0ubuntu1.17.10.3] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.16.04.1 => 5.1.34-dfsg-0ubuntu1.16.04.3] (ubuntu-cloud)
<LocutusOfBorg> sil2100, can you please review the above packages?
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (xenial-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.16.04.1 => 5.1.34-dfsg-0ubuntu1.16.04.3] (no packageset)
<LocutusOfBorg> I just added a fix from bionic, the systemd startup script for the guest package
<LocutusOfBorg> it calls the init script, but I prefer the systemd wrapper right now
<sil2100> LocutusOfBorg: sure
<sil2100> LocutusOfBorg: hm, I'm confused, why .3 for artful?
<sil2100> LocutusOfBorg: I see two uploads there, one with version .2 and one with .3
<LocutusOfBorg> yes, I did a copy-paste issue, so I changed in -3
<LocutusOfBorg> if you want to reject all, I can reupload as -2 the three vbox and vbox-hwe
<LocutusOfBorg> otherwise accept all the .3 and you are fine, also for versionig
<LocutusOfBorg> same number makes my brain happy
<LocutusOfBorg> (the guest-additions-package needed a debhelper compat level change, sigh)
<sil2100> LocutusOfBorg: I don't think I understand, if you did a typo in the upload that went to the queue a version bump is not needed, you should have just kept .2
<sil2100> As long as they're still in Unapproved version numbers don't get used up
<LocutusOfBorg> seriously? I can override the queue? this is awesome
<sil2100> Yeah ;)
<LocutusOfBorg> wow :)
<sil2100> It's a neat safety net, I can basically accept the .3's if you as the maintainer don't care about the version jump
<LocutusOfBorg> if you want to reject, this is fine, I have the new -2 ready to go
<LocutusOfBorg> just accept guest-additions-iso
<chrisccoulson> hi, can someone please approve my flashplayer uploads? (and copy them to the release pocket later too)
<LocutusOfBorg> BTW I spent the whole morning testing it
<LocutusOfBorg> in the meanwhile we already got ~4 positive feedbacks
<LocutusOfBorg> :D
<sil2100> Ok, if they're ready then please upload, I'll reject the older ones (+ the guest-additions)
<sil2100> (I mean, approve guest-additions)
<sil2100> Or review first, even
<sil2100> ;)
<LocutusOfBorg> already uploading, don't forget to reject .3 and accept .2 then :p
<LocutusOfBorg> oops I dputted -f also the guest-additions with exactly the same changes file, meh :)
<LocutusOfBorg> sad, I did a looong post about all the tests I have done, and f5 on chrome lost it
<LocutusOfBorg> :/
-queuebot:#ubuntu-release- Unapproved: virtualbox (artful-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.17.10.1 => 5.1.34-dfsg-0ubuntu1.17.10.2] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.16.04.1 => 5.1.34-dfsg-0ubuntu1.16.04.2] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (xenial-proposed/multiverse) [5.1.34-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (xenial-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.16.04.1 => 5.1.34-dfsg-0ubuntu1.16.04.2] (no packageset)
<LocutusOfBorg> fine now ^^
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-guest-additions-iso [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.2]
<sil2100> LocutusOfBorg: thanks! Rejected what had to be rejected and will review those in a moment, just need to finish something quick
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (artful-proposed) [5.1.34-dfsg-0ubuntu1.17.10.2]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (artful-proposed) [5.1.34-dfsg-0ubuntu1.17.10.3]
<LocutusOfBorg> sure thanks
-queuebot:#ubuntu-release- Unapproved: patchelf (xenial-proposed/universe) [0.8-4 => 0.9-1~ubuntu16.04.1] (no packageset)
<Odd_Bloke> Can someone remind me how I would go about getting packages added to a packageset?  (Specifically, I'd like the other packages under https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vagrant added to the ubuntu-cloud packageset, so I can more effectively maintain vagrant.)
<rbasak> Odd_Bloke: email devel-permissions@ with the request.
<Odd_Bloke> On a related note, could someone with The Power please hit the retry URLs in here for me: https://paste.ubuntu.com/p/R5x8RykbTC/
<nacc> Odd_Bloke: doing so now
<Odd_Bloke> Thanks!
<Odd_Bloke> nacc: Oh, actually, never mind!
<Odd_Bloke> I just noticed that I have an i386 regression on Vagrant itself. >.<
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (xenial-proposed/multiverse) [5.1.34-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.2] (no packageset)
<xnox> Odd_Bloke, /usr/lib/ruby/vendor_ruby/spring/application.rb:156:in `fork': undefined method `reject!' for nil:NilClass
<xnox> so i think spring is b0rked, no?
<Odd_Bloke> xnox: <shrug asciimoji>
 * xnox loves this audio description
<xnox> is this alexa typing?
<Odd_Bloke> (My intent is to shepherd the things I was working on last week through, but I can't invest time in any new Ruby packages this week.)
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu4 => 2:9.1.2-0ubuntu6] (openstack, ubuntu-server)
<sergiusens> RAOF mind (please) taking a look at  patchelf (xenial-proposed/universe) ?
<Odd_Bloke> So I think https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=amd64&package=ruby-mustermann19&trigger=ruby-defaults%2F1%3A2.5%7E1000grauubuntu1 (and other arches) should clear that from blocking ruby-defaults.
<Odd_Bloke> xnox: ruby-turbolinks itself is blocked by an autopkgtest that's failing on the debug_inspector thing; are you still fixing that?
-queuebot:#ubuntu-release- Unapproved: horizon (trusty-proposed/main) [1:2014.1.5-0ubuntu2.1 => 1:2015.1.4-0ubuntu4] (ubuntu-server)
<xnox> Odd_Bloke, i believe i fixed that bit; but rails newapp test still fails, but now with this ruby-spring issue, upon trying to "boot" the brand new rails app.
<xnox> Odd_Bloke, at least it manages to create a brand new rails app now.
-queuebot:#ubuntu-release- Unapproved: horizon (trusty-proposed/main) [1:2014.1.5-0ubuntu2.1 => 1:2014.1.5-0ubuntu2.2] (ubuntu-server)
-queuebot:#ubuntu-release- New source: xorg-lts-transitional (bionic-proposed/primary) [3:14]
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (xenial-proposed) [2:9.1.2-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (trusty-proposed) [1:2014.1.5-0ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (xenial-proposed) [2:9.1.2-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (artful-proposed) [5.1.34-dfsg-0ubuntu1.17.10.2]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-guest-additions-iso [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (trusty-proposed) [1:2015.1.4-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: horizon (trusty-proposed/main) [1:2014.1.5-0ubuntu2.1 => 1:2014.1.5-0ubuntu2.2] (ubuntu-server)
<Odd_Bloke> xnox: Aha, good!  In that case, could you retrigger the failing tests under https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-turbolinks for me, please?
<Odd_Bloke> I _think_ they only rely on newapp running, not on the part of the rails test that is now failing.
<sil2100> LocutusOfBorg: eh, I just reviewed and accepted most virtualbox SRUs, but the virtualbox-hwe has an ugly changelog
<sil2100> LocutusOfBorg: for others you were overwriting the old changelog, here it's duplicated (and with the same version number actually)
<sil2100> LocutusOfBorg: could you fix that?
<xnox> Odd_Bloke, hm, we shall see then
<LocutusOfBorg> sil2100, I prefer to avoid a new changelog entry, but I can fix it, yes
<LocutusOfBorg> and... hwe is just to match the version numbers, to avoid useless diffs in case of subsequent uploads
<sil2100> Yeah, thanks!
<LocutusOfBorg> ack
<LocutusOfBorg> just one sec, wildo in 20min
<doko> LocutusOfBorg: did the gdbm maintainer explain, why gdbm needs linking with dietlibc?
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.2]
<slangasek> dietlibc? >_<
<LocutusOfBorg> yes doko, in the RFS bug
<LocutusOfBorg> but this solution should make everybody happy
<doko> LocutusOfBorg: what is the RFS bug?
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891005
<ubot5`> Debian bug 891005 in sponsorship-requests "RFS: gdbm/1.14.1-5 " [Wishlist,Open]
 * LocutusOfBorg goes afk for some minutes
<Odd_Bloke> rbasak: Thanks for the packageset update!
<rbasak> yw
<rbasak> Non-automatic packagesets are the easiest type :)
<Odd_Bloke> :)
<nacc> Odd_Bloke: ruby-parslet is already fixed, afaict (1.8.2-2)
<Odd_Bloke> nacc: Yep, agreed.
-queuebot:#ubuntu-release- Packageset: Added vagrant-cachier to ubuntu-cloud in bionic
-queuebot:#ubuntu-release- Packageset: Added vagrant-libvirt to ubuntu-cloud in bionic
-queuebot:#ubuntu-release- Packageset: Added vagrant-lxc to ubuntu-cloud in bionic
-queuebot:#ubuntu-release- Packageset: Added vagrant-mutate to ubuntu-cloud in bionic
-queuebot:#ubuntu-release- Packageset: Added vagrant-sshfs to ubuntu-cloud in bionic
<nacc> Odd_Bloke: sigh, ruby-rgen has CRLF line endings
<nacc> Odd_Bloke: so your patch fails to apply on its own (afaict0
<LocutusOfBorg> sil2100, reuploaded, with an added entry "build only guest packages with hwe stack"
<LocutusOfBorg> so we know that this is the same as virtualbox/proposed, plus the new stack packages
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (xenial-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.16.04.1 => 5.1.34-dfsg-0ubuntu1.16.04.2] (no packageset)
<Odd_Bloke> nacc: My patch seems to have the right line endings; are you losing them when you download it?
<nacc> Odd_Bloke: yeah possibly
<Odd_Bloke> nacc: Try https://gist.githubusercontent.com/OddBloke/08f68c18f2f3d63a002f2c1a26a765ac/raw/ce49b7ec843dccf26da4e749214a43f0fc18ec21/ruby-rgen.debdiff
<nacc> Odd_Bloke: since it's in a paste? can you .. yeah that
<nacc> Odd_Bloke: thanks
<Odd_Bloke> FWIW, "download as text" from paste.u.c seemed to WFM.
<nacc> Odd_Bloke: ack, i see that now
<sil2100> LocutusOfBorg: hmm, ok, this still looks a bit strange - before you were just overwriting the latest changelog entry, now the strange thing is that you have 5.1.34-dfsg-0ubuntu1.16.04.2 with almost the same changelog entries as 5.1.34-dfsg-0ubuntu1.16.04.2
<sil2100> LocutusOfBorg: normally what people do is, if they want to leave the previous version in the changelog, add a new one with just the entry they want (so the 'build only...' thing) + build the source package with -v
<sil2100> To get the previous changelog entry in .changes
<LocutusOfBorg> yes, but one refers to virtualbox, the other to virtualbox-hwe
<LocutusOfBorg> ack ok
<LocutusOfBorg> Indeed
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (xenial-proposed/multiverse) [5.1.34-dfsg-0ubuntu1.16.04.1 => 5.1.34-dfsg-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted patchelf [source] (xenial-proposed) [0.9-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.2]
<estan> infinity: i tested the c-blosc 1.14.0+ds1-1 you synced (https://bugs.launchpad.net/ubuntu/+source/c-blosc/+bug/1755380/comments/2). looks good! many thanks for dealing with it so quickly.
<ubot5`> Ubuntu bug 1755380 in c-blosc (Ubuntu) "[FFe] Please sync c-blosc 1.14.0+ds1-1 from debian unstable to bionic (1.11.1 has format incompat bug!)" [Undecided,Fix released]
<estan> (would be nice to have in artful too, but not too important)
<infinity> estan: Except that it segfaults on ARM, so won't migrate.
<slangasek> tjaalton: we seem to still be no closer to a resolution on freeipa.  What are our options for un-sticking it for 18.04?  Are the autopkgtest failures in 4.6.3-1 something that need resolving, vs. skipping?  Is the resolution of those failures blocked on the nss stuff whose name I've forgotten?
<slangasek> jbicha: did you want Debian bug #866659 (zekr removal) actioned in Ubuntu to unblock swt-gtk?
<ubot5`> Debian bug 866659 in src:zekr "zekr: depends on libwebkitgtk-3.0-0 which is deprecated" [Serious,Open] http://bugs.debian.org/866659
<jbicha> slangasek: yes I filed Debian bug 892650 too
<ubot5`> Debian bug 892650 in src:zekr "zekr: Intent to request removal from Debian" [Serious,Open] http://bugs.debian.org/892650
<slangasek> removed
<jbicha> I assume we won't be trying to remove libgnomeui from Ubuntu this cycle -- it would kill shutter for instance (admittedly unmaintained but stillâ¦)
<jbicha> oh and sugar too
<slangasek> I wonder if there's anything in sugar that should still be kept in Ubuntu; last time it had a reason to be on my radar it was because of packages removed from Debian several years ago that we're still keeping in Ubuntu because there was an Ubuntu delta, but the Ubuntu delta is by now quite stale
<jbicha> sugar-toolkit doesn't look very important so removing gnome-python and gnome-python-desktop looks ok to me
#ubuntu-release 2018-03-14
-queuebot:#ubuntu-release- New binary: cross-toolchain-base-ports [amd64] (bionic-proposed/main) [18ubuntu1] (ubuntu-desktop)
<tjaalton> slangasek: yes, it needs nss-pem which needs some static nss libs packaged to build
<tjaalton> glandium refuses to package them, so i was thinking of taking it to the tech-ctte
<tjaalton> but if the tests are blocking stuff, just ignore them for now..
<slangasek> tjaalton: so nss-pem is only needed for the tests?
<tjaalton> slangasek: no, it's needed for server install to pass
<tjaalton> and useful on the client too, since certmonger needs it
<tjaalton> when renewing certificates
<slangasek> well, then I'm not sure there's a point in ignoring the test failures to get the package into release... since these are the test failures
<tjaalton> not freeipa itself, I thought it's blocking other things
-queuebot:#ubuntu-release- New: accepted cross-toolchain-base-ports [amd64] (bionic-proposed) [18ubuntu1]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [source] (bionic-proposed) [3:14]
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [amd64] (bionic-proposed/none) [3:14] (no packageset)
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [arm64] (bionic-proposed/none) [3:14] (no packageset)
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [i386] (bionic-proposed/none) [3:14] (no packageset)
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [armhf] (bionic-proposed/none) [3:14] (no packageset)
<slangasek> tjaalton: not anymore, no
<tjaalton> okay
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [ppc64el] (bionic-proposed/none) [3:14] (no packageset)
<tjaalton> cyphermox: any update on the review of pysmi/pycryptodome? bug 1748572
<ubot5`> bug 1748572 in pysmi (Ubuntu) "[MIR] pysmi, pycryptodome" [High,New] https://launchpad.net/bugs/1748572
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [amd64] (bionic-proposed) [3:14]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [armhf] (bionic-proposed) [3:14]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [ppc64el] (bionic-proposed) [3:14]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [arm64] (bionic-proposed) [3:14]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [i386] (bionic-proposed) [3:14]
<estan> infinity: ah, bugger.
<estan> infinity: i'll have a go at those crashes when i'm at work, and i've alerted upstream (https://github.com/Blosc/c-blosc/issues/223)
<estan> it's strange that the armhf debian build succeeded fine though.
<infinity> estan: If Debian's works and ours doesn't, there's a fair chance the issues are alignment-related.
<infinity> estan: Debian runs on ARMv7 hardware with alignment fixups at runtime.  We run on ARMv8 hardware that falls over on unaligned access with ARMv7 code.
<infinity> estan: 9 times out of 10, that'll be a SIGBUS, not a SIGSEGV, but when you do it just wrong, segfaults occur, so my bet's on that.
<tjaalton> is LP selective with it's debian mirror? some packages seem to not have "been picked up by LP yet", while newer ones have
<infinity> estan: Upshot of caring about unaligned access is that it'll be a (very minor) performance increase on even x86 for upstream to fix it. :P
<infinity> tjaalton: You want wgrant or cjwatson.
<infinity> tjaalton: (and probably #launchpad, not here, but meh)
<tjaalton> ok
<estan> infinity: ah ok. thanks for the input. i'm sure it's that then. the upstream author has also been sloppy with endianness in the past, so i wouldn't put alignment issues past him :) i see the failures are in the tests related to the shuffling that blosc does, where i think he twiddles around with bytes/bits.
<cjwatson> infinity: are you still working on that dpkg SRU for .asc files in format 1.0?  IIRC that's what tjaalton's problem is about
<tjaalton> filed FFE bug 1755717 for xcb-proto/libxcb
<ubot5`> bug 1755717 in xcb-proto (Ubuntu) "FFE: xcb-proto/libxcb 1.13" [Undecided,New] https://launchpad.net/bugs/1755717
<LocutusOfBorg> sil2100, good morning, seems that in less than 12h we got already a lot of happy people wrt vbox stack, and zero new bug founds
<LocutusOfBorg> (except for one reporting the issue fixed in -proposed, marked as duplicate)
<LocutusOfBorg> I'll redo all the tests today
<sil2100> LocutusOfBorg: \o/ thanks!
<rbalint> juliank: re: zstd for initramfs: sure, let's measure boot speed with it and lz4 and add support for the best
<rbalint> juliank: imo decompression time is way more important than size in initramfs case
<juliank> rbalint: there's no kernel support yet, we were a bit optimistic yesterday :(
<rbasak> It's great that you're working on this.
<rbasak> But I think it's premature for Bionic.
<rbalint> juliank: :-)
<rbasak> If we hit a zstd edge case in initramfs unpack that causes failure, we'll have broken users with no automatic way for them to recover.
<juliank> _I_ never said anything about doing that this cycle :D
<juliank> the kernel patches from october or november have not been reviewed yet AFAICT
<juliank> probably the submitter should resend them
<juliank> If we want to do something _now_, it would be adding support for lz4 I guess.
<apw> juliank, as in mainline has not yet taken them ?
<juliank> no maintainer has responded to them
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-117.141] (core, kernel)
<juliank> https://patchwork.kernel.org/patch/10003007/
<juliank> https://patchwork.kernel.org/patch/10003011/
<juliank> 2017-10-12	 these are the latest oners
<juliank> *ones I could find
<juliank> I guess I'll ping him and ask for a status update
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-117.141]
<infinity> cjwatson: Oh.  Yes.  Yes I am.  By which I mean I wasn't, but I will today.
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (xenial-proposed/main) [14.04+16.04.20171116-0ubuntu1 => 14.04+16.04.20180307-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<xnox> AAs old binaries left on amd64: kernel-signed-image-4.15.0-11-generic-di, linux-signed-image-4.15.0-11-generic, linux-signed-image-4.15.0-11-lowlatency (from 4.15.0-11.12)
<xnox> please clean up bionic-proposed, from un-migrated kernel udebs
<apw> xnox, looking
<apw> xnox, wacked
<apw> jamespage, percona-extradb-cluster-5.7 ... what is happening with that, is it replacing -5.6 ?
<jamespage> apw: yep - raised a bug for the RM somewhere
<jamespage> ubuntu-archive subbed
<jamespage> https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.6/+bug/1752373
<ubot5`> Ubuntu bug 1752373 in percona-xtradb-cluster-5.6 (Ubuntu) "[RM] replaced by percona-xtradb-cluster-5.7 package" [Undecided,New]
<apw> jamespage, ahh ok, thanks
<xnox> jamespage, what about https://launchpad.net/ubuntu/+source/percona-server-5.7 ? is that coming?
<xnox> and ditto percona-server-5.6
<apw> jamespage, and there is no issue with version skew with that and percona-server
<jamespage> xnox: nope and I actually think we should drop ps-5.6
<jamespage> apw: there should not be - have a missed something?
<apw> jamespage, no information here, just asking
<jamespage> ack no should be fine
<xnox> apw, i think cluster & server are standalone things; and do not depend on each other.
<xnox> jamespage, please file RM for ps-5.6 then. Old / unmaintained / not-desired.
<xnox> request of maintainer; or some such
<apw> jamespage, ok, cleared out
<jamespage> xnox: ack will do
<jamespage> apw: ta
 * jamespage feels fresher already
<slangasek> jbicha: gnome-calculator is showing up on component-mismatches, I see that's because you seeded it with "upgrades" as a rationale; but we don't normally retain packages in main with "upgrade" as a rationale.  And the metapackage won't depend on them anymore.  Was this discussed somewhere?
<slangasek> jbicha: btw your bzr committer setting is missing a closing >
<xnox> slangasek, i believe the package needs to be there, to perform deb -> snap migration no?
 * xnox hopes there is no deb->snap complexities for gnome-calculator....
<jbicha> bzr config fixed. I wonder how long that's been broken
<slangasek> the commit doesn't mention migration, but lack thereof
<jbicha> it was discussed briefly in #ubuntu-desktop today
<jbicha> seb128: do you want to weigh in on gnome-calculator and friends? ^
<xnox> promoting it back in, is contrary to the existing practice. so yeah, it is interesting to know what's different about gnome-calculator.
<jbicha> well there are 4 total apps, gnome-calculator was just the first one and the only one that had been fully demoted yet
<jbicha> Laney: or you? ^
<Laney> yes we wanted to keep "officially" supporting those for upgraders
<Laney> I think they won't be marked for autoremoval, and I'm not sure of a way to keep them installed via a metapackage but if there is one we could do that
<Laney> supporting as deb -> snap isn't something we are doing for 18.04
 * Laney is going, hopefully Seb can give you more information if you want it
-queuebot:#ubuntu-release- Unapproved: dpkg (xenial-proposed/main) [1.18.4ubuntu1.3 => 1.18.4ubuntu1.4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (xenial-proposed) [1.18.4ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: pciutils (xenial-proposed/main) [1:3.3.1-1.1ubuntu1.1 => 1:3.3.1-1.1ubuntu1.2] (core)
<doko> tempted to remove make-dfsg from proposed ...
-queuebot:#ubuntu-release- New sync: beets (bionic-proposed/primary) [1.4.6-2]
#ubuntu-release 2018-03-15
<acheronuk> is the armhf test queue stalled?
-queuebot:#ubuntu-release- New: accepted beets [sync] (bionic-proposed) [1.4.6-2]
<acheronuk> yup. looks like armhf test runners are not doing much as far as I can see.
<slangasek> acheronuk: thanks for flagging it. I'm not sure what's going on, the runners claim to be running; digging in
<slangasek> acheronuk: currently they are working and taking tests from the queue.  Progress was flatlined before that for a couple of hours, for whatever reason
<slangasek> but they're running now
<estan> infinity: me and the upstream c-blosc author are struggling a bit in trying to reproduce that armhf failure. i've been trying with a recent version of QEMU while he's tried on a real ARM hw. just so i'm clear: you said the ubuntu packages are built on ARMv8 hw?
<estan> infinity: i'm asking because i see now that the package build log indicates cmake detected the platform as armv7l (-- Building for system processor armv7l).
<estan> are the builds running on ARMv8 hw, but in an ARMv7 VM?
<mwhudson> estan: yes
<slangasek> ttbomk no; they build in armhf chroots on ARMv8 VMs but lie about the cpu because otherwise lots of software makes bad assumptions at build time
<estan> slangasek: hm okay. that's a good piece of info. i'll see if i can get something like that going. problem is i don't have any ARM hw :/
<estan> trying to help an upstream author debug this failure: https://launchpadlibrarian.net/360527843/buildlog_ubuntu-bionic-armhf.c-blosc_1.14.0+ds1-1_BUILDING.txt.gz , we suspect it's due to misaligned memory accesses, because the debian build of the same package succeeded, and that's apparently on ARMv7 hw.
<estan> (and the alignment requirements are stricter on ARMv8).
<estan> but so far i've had no luck in reproducing it on an ARMv8 machine in QEMU, eventhough from what i can tell of the QEMU code, it should do ARMv8 alignment checks.
<estan> slangasek: i found https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap now, so is the package building infrastructure using the approach described under "USING SYSCALL EMULATION" for the second stage debootstrap of the chroot?
<estan> or is it using QEMU machine emulation?
 * estan shudders at the thought of having to do nested full machine emulation to reproduce this.
<mwhudson> oh are they only chrrots?
<mwhudson> estan: i can try to build it on a porter box and then pastebin bits of syslog at you if that's helpful?
<estan> mwhudson: anything would be helpful at this point, and much appriciated. it's the recent upload of c-blosc 1.14.0 to the bionic proposed pocket. i'm not sure where i can get the source package actually.
<mwhudson> estan: i built it but accidentally in an arm64 chroot :)
<mwhudson> building in armhf now
<estan> thanks a lot.
<mwhudson> estan: how do the tests run? is there a test binary i can simply run under gdb somehow?
<estan> mwhudson: indeed there is. one of the tests that are failing are run with `./bench/bench blosclz` in the build directory.
<mwhudson> estan: https://paste.ubuntu.com/p/Wd6sjMxqPG/
<mwhudson> estan: er, that's ./blosc/fastcopy.c:452
<estan> mwhudson: many thanks! could you paste output of `bt` as well?
<mwhudson> estan: one sec
<mwhudson> i just deleted the whoe "case 8" bit and am re-running the tests
<mwhudson> *whole
<estan> ah yes, must be an alignment issue. something around there should probably be protected by an if !defined(BLOSC_STRICT_ALIGN).
<estan> mwhudson: i gotto run to the bus, back in ~30 minutes, but it would be great if you could post your findings to https://github.com/Blosc/c-blosc/issues/223
<mwhudson> estan: ok
<estan> that's the upstream report, @FrancescAlted is the upstream author (i was just trying to help out).
<mwhudson> estan: posted
<mwhudson> hope that helps
<mwhudson> (looks like it should!)
<infinity> estan: To be clear, alignment isn't stricter on ARMv8, it's that ARMv7 kernels, by default, trap alignment errors and do fixups.  ARMv8 ones don't.
<infinity> estan: That behaviour can be turned off on pure ARMv7 systems with a sysctl.
<infinity> estan: But I'm guessing from backscroll that mwhudson's experiment helped you find the bug?
-queuebot:#ubuntu-release- New source: openjdk-11 (bionic-proposed/primary) [11~4-1]
-queuebot:#ubuntu-release- New: accepted openjdk-11 [source] (bionic-proposed) [11~4-1]
<estan> infinity: ah thanks for clearing that up. yes indeed, mwhudson was very helpful. the upstream author has already made a fix based on the info (https://github.com/Blosc/c-blosc/issues/223#issuecomment-373314909).
<estan> infinity: what do you think, should i nudge the debian package maintainer to make a patched debian package that you can sync again, or should there be made a patched ubuntu package?
<mwhudson> how responsive is the debian maintainer to nudges?
<mwhudson> that was would be better i think :)
<infinity> estan: The bug is entirely valid for Debian too (those alignment traps are *expensive*), but probably sane to get mwhudson to test the patch first, if he still has his built tree.
<infinity> s/built/build/
<mwhudson> uh yes i do
<estan> mwhudson: he was very responsive when i asked him to do the 1.14.0 release in the first place, so i'll go with that then :)
<infinity> estan: Since the turnaround time of "get it in Debian, sync, find out it's still broken, repeat" isn't ideal.
<estan> indeed.
<infinity> estan: But yes, if mwhudson can confirm it's fixed, doing it through Debian is best.
<infinity> mwhudson: Sorry to volunteer you, I can do it too, if you prefer. :P
<infinity> mwhudson: I assume you did this in the bionic-armhf chroot on porter-arm64?
<mwhudson> infinity: i did
<mwhudson> building now
<infinity> Ta.
<mwhudson> assuming i drove quilt correctly which is not always a very good assumption
<estan> when i asked for an update, i did so by making MRs to https://salsa.debian.org/debian/c-blosc , but i'm not sure that's the way to contribute to the package, because the debian packager quickly closed my MRs and did the update himself :)
<infinity> estan: Just filing bugs in the Debian BTS with debdiffs attached is the general preferred method.
<estan> but i'll make an MR there again if the patch turns out good, and he can decide if he rather do the patching himself instead of accepting MRs.
<estan> aha.
<infinity> estan: I'm sure as salsa becomes more popular, PRs might become more common, but that's certainly not the current Debian Way.
<estan> alright. i'll dust off my debdiff making skills then.
<mwhudson> estan: thanks for finding a problem with a package that takes 6 minutes, not 6 hours to build :)
<infinity> Hahaha.
<estan> mwhudson: heh, i was thinking the same thing. especially when i was trying to reproduce in QEMU :)
<mwhudson> estan: built ok
<estan> *starts drumroll*
<mwhudson> fwiw this is what i did:
<mwhudson> (bionic-armhf)mwh@rugby:~/c-blosc-1.14.0+ds1$ wget https://github.com/Blosc/c-blosc/commit/8a84d51487eed81431b0fa488805a62c2d8f0163.patch
<mwhudson> (bionic-armhf)mwh@rugby:~/c-blosc-1.14.0+ds1$ quilt import 8a84d51487eed81431b0fa488805a62c2d8f0163.patch
<mwhudson> (bionic-armhf)mwh@rugby:~/c-blosc-1.14.0+ds1$ rm 8a84d51487eed81431b0fa488805a62c2d8f0163.patch
<mwhudson> (bionic-armhf)mwh@rugby:~/c-blosc-1.14.0+ds1$ dpkg-buildpackage
<mwhudson> and now i'm going to bed
<estan> many thanks mwhudson, sleep tight.
<infinity> estan: FWIW, if you need to try to reproduce this in the future, the magic on an ARMv7 kernel to stop doing the traps is "cat 1 > /proc/cpu/alignment"
<estan> if you have time to confirm the fix works on the GH issue that would be great, otherwise @FrancescAlted will just have to take my word for it :p
<infinity> s/cat/echo/
<infinity> I can't brain at 4am.
<mwhudson> oh yes
<estan> infinity: ah, good to know, thanks. when i was trying to reproduce it i was actually directly on an aarch64 QEMU VM, so i had misunderstood.
<infinity> estan: Oh, an aarch64 VM with an armhf chroot would have reproduced it fine.
<infinity> Albeit quite slowly, probably.
<estan> ah, so i was close then, or well, getting the chroot set up would have taken some time.
<infinity> debootstrap --variant=buildd --arch=armhf bionic directory/
<infinity> That bit doesn't take long. :)
<estan> :)
<infinity> Well, this is also assuming the default qemu aarch64 machine supports armv7 (which is an optional add-on for armv8), but I imagine it does.
<infinity> It might not.
<infinity> Not sure I've ever checked.
<estan> yea, i had that worry. i don't know either. i know it's uncommon among hw to not support it.
<infinity> Not that uncommon.
<infinity> Several server-oriented SoCs don't bother with the armv7 bit.
<infinity> And likely more in the future.
<infinity> I suspect a future Apple A-series SoC will also drop armv7 on whatever flag day they decide that olds apps don't matter anymore.
<infinity> s/olds/old/
<estan> alright, "know" was the wrong word. i may have based that off an old answer on askubuntu.com, which may even be wrong (https://askubuntu.com/questions/928249/how-to-run-armhf-executables-on-an-arm64-system).
<infinity> (I suspect maybe phone-oriented SoCs will move in that direction, but I'd put money on Apple doing it first, cause they love to draw those lines in the sand and say "we supported your migration path for 2 years, now suck it.")
<infinity> s/maybe/many/ ... I can't type.  It's time to not be here. :P
<infinity> Actually, Apple may have already done it.  I remember a conversation with my brother recently about newer iOS versions dropping 32-bit support.
<infinity> Which only really makes sense if they're also dropping the silicon bits.
<infinity> estan: But yeah, the server SoC bit has put us in an irritating position, since our armhf infra is based on the theory that we can get armv8 servers that support armv7.  And in the very first generation of armv8 servers (which we run currently) that was true.  And now, it's not. :P
<estan> ah yes.
<infinity> I imagine we can get by for a good long while if we make the current armv8 kit armv7-only and buy new armv8-only kit for the future, but eventually, we need to just have the "32-bit is dead" discussion, and consider dropping it on the floor.
<infinity> (along with i386, because ick)
<estan> yea.
<infinity> I intend to propose dropping both for 18.10, making 18.04 the last LTS with 32-bit support, but I also expect a bunch of push-back on one or both. :P
<estan> heh. i won't cry any rivers, so you have my support.
-queuebot:#ubuntu-release- New binary: openjdk-11 [s390x] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openjdk-11 [ppc64el] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-38.43] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (artful-proposed/multiverse) [5.1.34-0ubuntu1.17.10.1 => 5.1.34-0ubuntu1.17.10.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.1.34-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.2] (no packageset)
<LocutusOfBorg> sil2100, pleeeeeease ^^
<LocutusOfBorg> sigh, you were right, you just pointed at rules, and postinst was bad :/
<LocutusOfBorg> (techically not a big problem, that package works as expected anyway, just it is better to have them all at the same version)
<sil2100> LocutusOfBorg: actually I did point out both ;)
<sil2100> 12:28 < sil2100> LocutusOfBorg: in debian/postinst there's version=5.1.32 while the version of the package is 5.1.34 - is that ok?
<sil2100> 12:28 < sil2100> LocutusOfBorg: same for debian/rules
<sil2100> Anyway, looking!
<apw> that really should be being fixed by the packaging ...
<sil2100> LocutusOfBorg: eh, could you re-upload with -v ?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-38.43]
 * sil2100 AFK for a bit to get lunch
-queuebot:#ubuntu-release- New binary: openjdk-11 [amd64] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted openjdk-11 [amd64] (bionic-proposed) [11~4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-11 [s390x] (bionic-proposed) [11~4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-11 [ppc64el] (bionic-proposed) [11~4-1ubuntu1]
<LocutusOfBorg> sorry sil2100 I really didn't get that ping :/
<LocutusOfBorg> reuploaded with -v
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (artful-proposed/multiverse) [5.1.34-0ubuntu1.17.10.1 => 5.1.34-0ubuntu1.17.10.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.1.34-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: openjdk-11 [arm64] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted openjdk-11 [arm64] (bionic-proposed) [11~4-1ubuntu1]
<estan> infinity1: i submitted a debdiff adding the alignment fix patch to the debian package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893000 , let's hope it'll be a quick affair.
<ubot5`> Debian bug 893000 in src:c-blosc "c-blosc: Add upstream patch for unaligned access" [Important,Open]
-queuebot:#ubuntu-release- New binary: openjdk-11 [i386] (bionic-proposed/universe) [11~4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted openjdk-11 [i386] (bionic-proposed) [11~4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: murano-dashboard (artful-proposed/universe) [1:4.0.0-0ubuntu1.1 => 1:4.0.0-0ubuntu1.2] (openstack)
-queuebot:#ubuntu-release- Unapproved: designate-dashboard (artful-proposed/universe) [5.0.1-0ubuntu1 => 5.0.1-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sahara-dashboard (artful-proposed/universe) [6.0.0-0ubuntu1 => 6.0.0-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: trove-dashboard (artful-proposed/universe) [9.0.0-0ubuntu1 => 9.0.0-0ubuntu1.1] (no packageset)
<xnox> apw, as per http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html linux-kvm and linux-meta-kvm should be promoted, but it needs bug subscriber. Can you subscribe the right kernel team to those packages?
<ginggs> what needs to be done for this bug? LP: #1754843
<ubot5`> Launchpad bug 1754843 in gdk-pixbuf (Ubuntu) " gdk-pixbuf version in artful > version in bionic" [Undecided,New] https://launchpad.net/bugs/1754843
<cjwatson> that seems like a trivial copy-forward
<infinity1> Yup.  Doing.
<cjwatson> I just did
<infinity1> Well, then.  Not doing.
<cjwatson> :)
<cjwatson> somebody should do a full scan for that sort of thing though.
<ginggs> cjwatson, infinity1: thanks both of you
<Guest65850> hello - I'd like to get a release team ack for uploading apparmor 2.12 (merged from Debian's 2.12-3) to bionic
<tyhicks> lets try that again :)
<tyhicks> I'd like to get a release team ack for uploading apparmor 2.12 (merged from Debian's 2.12-3) to bionic
<Guest1006> argh... let me sort out irc problems and I'll be back
<apw> xnox, ok subscribed ...
-queuebot:#ubuntu-release- Unapproved: strongswan (trusty-proposed/main) [5.1.2-0ubuntu2.7 => 5.1.2-0ubuntu2.8] (no packageset)
<tyhicks> ok, back to the apparmor-2.12 upload...
<tyhicks> here are the upstream release notes: https://gitlab.com/apparmor/apparmor/wikis/Release_Notes_2.12#highlighted-new-features
<tyhicks> well, the features mentioned in the upstream release notes
<tyhicks> the last two bullets there are bug fixes to bugs that affect Ubuntu
<tyhicks> the first bullet is a new feature but only applies to suse systems as it is yast-specific
<tyhicks> I think I'm fine uploading apparmor 2.12 without a FFe but that yast-specific feature is the slight gray area that I wanted release team approval for
<tyhicks> the yast-specific feature is only in the python utils (apparmor-utils binary package) which are not seeded
<apw> i don't think i would count a feature we do not and can not use as a new feature
<apw> also i see that is bringing python 3.6 support, did we not just bump to that
<tyhicks> that's how I felt about the yast feature, as well, but I had a conflict of interest since I'm involved in apparmor upstream
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (artful-proposed) [5.1.34-0ubuntu1.17.10.2]
<tyhicks> oh, did we?
<tyhicks> apparmor 2.12 includes additional policy rules that allow for python 3.6 paths
<tyhicks> so, that'll be pretty important
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (artful-proposed) [5.1.34-0ubuntu1.17.10.2]
<tyhicks> I'll also mention that I ran through the entire test plan here: https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
<tyhicks> this upload is very well tested
<apw> the second of those pulled out ones, i seem to reember is something that snapd was tickling too
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.2]
<apw> tyhicks, from my niave reading of the changelog in full i don't see anything that sounds dangerous
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (xenial-proposed) [5.1.34-0ubuntu1.16.04.2]
<apw> tyhicks, or anything which would tip you over the bar to needing an FFe, so i think you are good
<tyhicks> apw: I feel the same way but wanted a +1 - thanks for taking a look!
<apw> tyhicks, +1
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-38.43~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (artful-proposed) [1:20180313.1-0ubuntu0.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20180313.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20180313.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-38.43~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.2-0ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu7.1]
<nacc> xnox: ok with removing ruby-filepath? (i'll file bug) it seems to hang, and upstream only indicates ruby2.3 compat.
<nacc> xnox: leaf package
<nacc> xnox: i've got the fix for ruby-grape as well
<Laney> stgraber: I'm going to deploy some more arm64 instances in a minute - any chance you could review that MP quickly so they get the new goodness?
<xnox> nacc, yes, i was considering removing ruby-filepath too, go ahead
<nacc> xnox: ack, thanks
<xnox> nacc, if only armhf would finish soon.....
<stgraber> Laney: link?
<Laney> stgraber: https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/341329
<xnox> nacc, there are a couple things that are regressions w.r.t. openssl1.1
<xnox> e.g. ruby-net-ssh is a suspect and the http-pipeline
<xnox> rpdf is weird
<xnox> and yard is fixed
<nacc> xnox: good to know on yard
<nacc> xnox: i'll trawl through the list today
<xnox> nacc, ruby-html-pipeline uploaded; ruby-net-ssh uploaded
<xnox> so there is very little left
<xnox> nacc, i think we can simply wait for all the results today
<xnox> from armhf, and revisit tomorrow
<stgraber> Laney: +1ed
<Laney> stgraber: thanks
<Laney> stgraber: I'll grab you at some point to help me migrate the existing ones if that's OK
<Laney> can't exactly remember what we did before
<stgraber> Laney: ok. I thought we ended up just deploying a new one, didn't we? But converting an existing one should definitely be possible.
<Laney> stgraber: I think we initially played on an existing instance, then tested a modified userdata
<stgraber> ah, yeah, that rings a bell
 * Laney does the split screen thing
<Laney> hoepfully armhf will go down a bit faster
<Laney> that or we kill another cloud
<Laney> slangasek: ^-- lxd-armhf{11..13} provisioning
<Laney> these ones with the new LXD stuff
<nacc> xnox: ack
<stgraber> tsimonq2: did it join your channel now?
<tsimonq2> stgraber: Ah, yes it did.
<tsimonq2> stgraber: Thanks!
<stgraber> np
<slangasek> Laney: cool.  Does this mean a (temporary) increase in the number of runners?
<Laney> slangasek: 3x3 more, yeah
<Laney> live now
-queuebot:#ubuntu-release- Unapproved: accepted pciutils [source] (xenial-proposed) [1:3.3.1-1.1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted python-pylxd [source] (xenial-proposed) [2.0.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (trusty-proposed) [5.1.2-0ubuntu2.8]
<tsimonq2> Any chance I could get an SRU team member to release https://bugs.launchpad.net/bugs/1739955 so it doesn't wait until Monday?
<ubot5`> Ubuntu bug 1739955 in qttools-opensource-src (Ubuntu Xenial) "Qt5UiTools.pc Requires: non-existent Qt5UiPlugin" [Medium,Fix committed]
<tsimonq2> bdmurray: Seems like you're the person to poke today.
<bdmurray> tsimonq2: looking
<tsimonq2> bdmurray: Thank you!
<slangasek> infinity, sil2100: FFe request LP: #1756177
<ubot5`> Launchpad bug 1756177 in e2fsprogs (Ubuntu) "FFe: e2fsprogs 1.44, support for largedir and ea_inode" [Undecided,New] https://launchpad.net/bugs/1756177
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1022.24] (kernel)
-queuebot:#ubuntu-release- Unapproved: trove-dashboard (xenial-proposed/universe) [6.0.0-1 => 6.0.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: murano-dashboard (xenial-proposed/universe) [1:2.0.0-1 => 1:2.0.0-1ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: sahara-dashboard (xenial-proposed/universe) [4.0.0-1ubuntu1 => 4.0.0-1ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: horizon (trusty-proposed/main) [1:2014.1.5-0ubuntu2.1 => 1:2014.1.5-0ubuntu2.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu4 => 2:9.1.2-0ubuntu5] (openstack, ubuntu-server)
<acheronuk> slangasek or infinity: would you have time to take a look at? https://bugs.launchpad.net/ubuntu/+source/amarok/+bug/1756066
<ubot5`> Ubuntu bug 1756066 in amarok (Ubuntu Bionic) "[FFe] Amarok 2.9.0 for Bionic" [Undecided,Confirmed]
<tsimonq2> +1, it's the last KDE 4 release of Amarok and it'd be really good to get it in for the LTS.
<nacc> xnox: fyi, ruby-grape is updated in debian and passes, i'll sync it
<sil2100> slangasek: I can take a look at that in some minutes if infinity isn't around
-queuebot:#ubuntu-release- Unapproved: accepted trove-dashboard [source] (artful-proposed) [9.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [source] (artful-proposed) [5.0.1-0ubuntu1.1]
<nacc> xnox: and i think ruby-grape-entity n eeds a uupdate (they are 2.5 compat upstream)
-queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (artful-proposed) [1:4.0.0-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted trove-dashboard [source] (xenial-proposed) [6.0.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (xenial-proposed) [1:2.0.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (xenial-proposed) [4.0.0-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (xenial-proposed) [2:9.1.2-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (trusty-proposed) [1:2014.1.5-0ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (trusty-proposed) [1:2014.1.5-0ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: sahara-dashboard (artful-proposed/universe) [6.0.0-0ubuntu1 => 6.0.0-0ubuntu1.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected sahara-dashboard [source] (artful-proposed) [6.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (artful-proposed) [6.0.0-0ubuntu1.2]
<slangasek> xnox: util-linux stole the rfkill binary package from the rfkill source; do you know if the Ubuntu delta from rfkill 0.5-1ubuntu2 is merged?
<slangasek> xnox: n/m, "This upgrade fix needs to be kept until after Ubuntu 16.04 LTS", which we are after ;)
<xnox> slangasek, my util-linux merging was a bit "i hope not to break anything" type of merge
<slangasek> xnox: though we do have some orphaned upstart conffiles now - let me take care of those
#ubuntu-release 2018-03-16
<slangasek> stgraber: wrt LP: #1750013: my understanding (having gotten this wrong before myself and been corrected) is that new dependencies are fine for safe-upgrade, it's only removals-by-conflict that are a problem
<ubot5`> Launchpad bug 1750013 in systemd (Ubuntu Trusty) "systemd-logind: memory leaks on session's connections (trusty-only)" [Medium,Fix committed] https://launchpad.net/bugs/1750013
<stgraber> slangasek: hmm, odd. mvo specifically mentioned that apt logic when pushing against making squashfuse a recommends of snapd through SRU
<infinity> slangasek: I don't know what safe-upgrade is, or even if humans use it, but upgrade won't allow any changes to install/remove status.  Which means no new deps.
<infinity> slangasek: This was exactly the thing that led to the mess of silly snap-confine-related SRUs.
<infinity> And also why I've argued for changing the behaviour of upgrade.
<infinity> slangasek: Unless you're confusing "apt" and "apt-get" (where "apt upgrade" allows new deps, while "apt-get upgrade" doesn't)
<infinity> But also, I find that argument spurious for rejecting an SRU.
<infinity> Since we're saying "we care deeply about you getting systemd updates, but the fact that you use apt incorrectly and never get a kernel upgrade doesn't bug me".
<infinity> stgraber: ^
<stgraber> infinity: so IIRC we special-case the kernel in update-manager, but anything else which introduces a new deps makes it skip or print a bad warning (then again, I've not used the thing in a long time, so not sure of exact current behavior)
<infinity> stgraber: No, that's flat out wrong.
<infinity> stgraber: update-manager always allows new deps.
<infinity> stgraber: This paranoia about new deps came about because some user failed to upgrade snapd with "apt-get upgrade".  That user also wasn't getting kernel updates.
<infinity> stgraber: That user should have been told they were wrong, and that's all.
<stgraber> oh, okay, I remembered it being force than that for some reason. If the only concern is someone running "apt-get upgrade", then yeah, that's definitely not a valid one.
<stgraber> how does unattended-upgrade behave?
<rbasak> AFAIK it works for kernels, because every so often some of my server VMs and containers end up with a full disk and I have to clear out a gazillion kernels.
<rbasak> I'm not aware of any special casing of kernels in apt except for the autoremove blocking stuff.
<infinity> stgraber: unattended-upgrades is new-ok-removal-not.
<infinity> stgraber: So, same as 'apt upgrade'
<infinity> stgraber: Literally the only thing that won't allow new deps is "apt-get upgrade", and while I contend that behaviour is a bug, it's also literally been like that since 1998.
<infinity> stgraber: (And again, like I said, saying "we care if you get random-app updates, but not if you get kernel updates" is lolz)
<infinity> stgraber: The special-casing in update-manager you might be thinking of is for removals.
<infinity> stgraber: Where it doesn't allow removals, EXCEPT in a one-way Conflict/Replace pair.
<infinity> stgraber: Which, while policy agrees update-manager is correct, it seems no other dpkg frontends do, and that's a unique feature. :P
<nacc> tjaalton: do you plan on picking up this for mesa? https://patchwork.freedesktop.org/patch/201547/, fixes https://bugs.freedesktop.org/show_bug.cgi?id=104777 which i am hitting with wine on bionic
<ubot5`> Freedesktop bug 104777 in Mesa core "Attaching multiple shader objects for the same stage to a GLSL program triggers a linker error" [Normal,Resolved: fixed]
<nacc> tjaalton: sorry, probably this is a better ref: https://cgit.freedesktop.org/mesa/mesa/commit/?id=4195eed961ccfe404ae81b9112189fc93a254ded
<tjaalton> nacc: it's already marked for 18.0
<tjaalton> upstream, meaning it should get in the next rc
<tjaalton> whenever that happens
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1022.24]
<tjaalton> slangasek: I've got nss-pem built with src:nss merged in and built first.. dunno which is less ugly, getting changes in src:nss or this
<smb> while trying to clear up the last dependency problems preventing iproute2 leaving proposed in bionic, I found tunneldigger which seems to be the same version since at least precise and does not (or no longer) exist in Debian. Event though the version number of 0.10 suggests its a package that was synced at some point. I wonder whether that should go away, I mean the tunneldigger package
<cascardo> smb: is that a reverse dependency?
<smb> cascardo, for iproute2, yes. tunneldigger-utils does a depend on iproute
<smb> and iproute2 latest dropped the iproute transitional package
<apw> for what it is worth tunneldigger was uploaded first in hoary and never uploaded again, so it is going to supprise me if it works
<apw> smb, and it definatly sync'd from debian and is not longer there
<smb> Yeah, that is what https://tracker.debian.org/search?package_name=tunneldigger tells me
-queuebot:#ubuntu-release- New source: nss-pem (bionic-proposed/primary) [1.0.3-0ubuntu1]
<tjaalton> slangasek: oh well, uploaded nss-pem ^
<nacc> tjaalton: and that is planned for 18.04 still?
<xnox> slangasek, i think if you remove ruby-filepath, and my uploads are retried, ruby-defaults will migrate
<xnox> https://bugs.launchpad.net/ubuntu/+source/ruby-filepath/+bug/1754464
<ubot5`> Ubuntu bug 1754464 in ruby-filepath (Ubuntu) "remove broken ruby srcpkgs due to ruby-defaults stuck in bionic-proposed" [Undecided,Confirmed]
<xnox> nacc, fixed up puppet, should fix ruby-puppet-syntax, rbpdf, http.
<xnox> nacc, so we should be done with this now.
<nacc> xnox: excellent, nice work!
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-144.193] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-144.193]
<ahasenack> hi, can someone please click on the ppc64el retry button for the gvfs test failure in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#samba
<ahasenack> I checked the history and that test is flaky, and when it fails it's about ftp access, not samba
<ahasenack> (samba triggered that test)
<ahasenack> there is a bug about that gvfs test also
<ahasenack> nacc: hi, could you perhaps do that for me please? ^ :)
-queuebot:#ubuntu-release- New binary: firefox [ppc64el] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
<tjaalton> nacc: yes
<nacc> tjaalton: thanks
<nacc> ahasenack: one moment
<nacc> ahasenack: done
<ahasenack> nacc: thanks
<xnox> infinity, if you are around, it would be really nice to remove ruby-filepath, the only thing outstanding to migrate ruby-defaults (sans a few outstanding autopkgtest triggers with things in proposed)
-queuebot:#ubuntu-release- New sync: mailman3 (bionic-proposed/primary) [3.1.1-6]
<xnox> https://bugs.launchpad.net/ubuntu/+source/ruby-filepath/+bug/1754464
<ubot5`> Ubuntu bug 1754464 in ruby-filepath (Ubuntu) "remove broken ruby srcpkgs due to ruby-defaults stuck in bionic-proposed" [Undecided,Confirmed]
<Odd_Bloke> dpb1: ^
<dpb1> nacc: ^
<nacc> dpb1: yes, i know? :)
<dpb1> not sure why Odd_Bloke did that
<dpb1> he's trolling me
<chrisccoulson> hi, can someone please approve the flash uploads that have been sat in partner for a few days?
<nacc> dpb1: :)
<Odd_Bloke> nacc: I wasn't trolling him, he'd asked me what the status was earlier.
<Odd_Bloke> dpb1: ^
<nacc> Odd_Bloke: :) yeah, i've been keeping him up to date
<dpb1> Odd_Bloke: I asked you if you have been involved, just to clear my good name.
<nacc> lol
-queuebot:#ubuntu-release- New binary: firefox [amd64] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: firefox [i386] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
<tsimonq2> infinity: Mind if I take care of bug 1750203?
<ubot5`> bug 1750203 in base-files (Ubuntu) "Please merge 10.1 from Debian" [Undecided,New] https://launchpad.net/bugs/1750203
<tsimonq2> infinity: I'm happy to do it unless you would like to.
<tsimonq2> infinity, slangasek: It would also be good to get an ACK/NACK on bug 1756195.
<ubot5`> bug 1756195 in sbuild (Ubuntu) "[FFe] Please merge sbuild 0.74.0-1 from Debian Sid" [Medium,New] https://launchpad.net/bugs/1756195
-queuebot:#ubuntu-release- New binary: firefox [armhf] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
 * xnox thinks i can fake ruby-filepath results
<nacc> xnox: it just got removed :)
<xnox> hahahha
<xnox> i'm sorry
<xnox> slangasek, nuke it from bionic-proposed too....
<xnox> https://launchpad.net/ubuntu/+source/ruby-filepath/0.6-3ubuntu1
<nacc> xnox: lol
<tsimonq2> jbicha: fyi I can take bug 1756372
<ubot5`> bug 1756372 in gtk+2.0 (Ubuntu) "Merge 2.24.32-1 from Debian" [Undecided,In progress] https://launchpad.net/bugs/1756372
<slangasek> xnox: :P done
-queuebot:#ubuntu-release- New binary: firefox [arm64] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
<nacc> xnox: slangasek: so i think we're just waiting for the ruby-filepath deletion to be noticed and ruby-defaults should switch to valid candidate?
<xnox> si
<nacc> slangasek: do you need to delete the NBS ruby-filepath?
<nacc> slangasek: i see the source gone, but the binaries are still listed per rmadison
<slangasek> nacc: race condition, grr.  Yes, deleting now, thanks
<nacc> slangasek: thanks!
<slangasek> (though it likely wouldn't have impacted anything wrt ruby-defaults, I think, since that was only in -proposed)
<nacc> slangasek: yeah, agreed
<infinity> tsimonq2: Leave base-files to me.
<tsimonq2> infinity: Then please do. ;)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-117.141~14.04.1] (kernel)
<slangasek> tsimonq2: your falkon upload is broken, it has a transitional qupzilla binary that depends on a package that conflicts with it
<tsimonq2> slangasek: I'm aware, and I was going to get to that tonight...
<slangasek> k
<slangasek> LocutusOfBorg: what's the rationale for syncing a new git-annex post-FF without the new version of datalad that satisfies the changed Breaks: ?
<slangasek> smb: iproute2 isn't going anywhere because the new Debian version drops the 'iproute' transitional package which still has revdeps in the archive, if you want to fix those up...
#ubuntu-release 2018-03-17
<infinity> slangasek: IIRC, most of those are ORed deps, but I'll give that a look later tonight after some me time.
<slangasek> infinity: well, update_output.txt shows the ones that aren't ORed
<infinity> slangasek: Yep.  tunneldigger is, AFAIK, a removal we missed.
<infinity>  -- Kai Henningsen <kai@khms.westfalen.de>  Sun,  4 Apr 2004 10:10:24 +0200
<infinity> It's been removed from Debian so long that the PTS doesn't even know about it.
<infinity> Nor does madison.
 * infinity thwacks.
<infinity> And, not shockingly, the other two (grml-btnet and grml-shlib) are Ubuntu-specific.
<slangasek> infinity: hah, nice
<infinity> slangasek: a2mp3 and grml-* are 13yo packages with a dead upstream in debian/copyright.  Kinda tempted to just punt them too.
<infinity> But I guess I could just fix the deps and punt that down the road too.  Don't care deeply either way.
<infinity> Votes?
<slangasek> abstain
<jbicha> infinity: please kill ancient unmaintained stuff that no one cares about that isn't in Debian
<slangasek> generally: yes.  but in terms of whether that's the right solution for unblocking iproute2: abstain :)
<infinity> Well, it *will* unblock it. :)
<infinity> So, two birds, one deletion.
<jbicha> slangasek: I try not to look too deeply in such cases :)
 * infinity looks for other bits from the same era/source.
<infinity> Looks like zsh-lovers too.
<infinity> So, Ima just thwack that lot.
<infinity> And thwacked.
<jbicha> infinity: I have lists of packages if you are looking for more stuff to remove :)
<infinity> jbicha: I think cleaning this sort of stuff pre-LTS is a good plan.  But I'm also AFK for the next 3 or 4 hours starting now. :P
<jbicha> just look through the ubuntu-archive subscribed bugs when you have time
<infinity> jbicha: Will do.
<tsimonq2> Oh cool, in that case, I might do some analysis (analyses? idk :) ) of KDE 4 junk before Adam comes back.
<tsimonq2> Right after I fix Falkon...
<tsimonq2> slangasek: falkon> Oh boy, that was a stupid mistake. :P  Fixed.
<tsimonq2> infinity: Yo dawg, I heard you're doing removals; bug 1745741 is a kool one.
<ubot5`> bug 1745741 in update-manager (Ubuntu Bionic) "RM: removed in Debian, working towards Qt 4 removal goal" [Medium,In progress] https://launchpad.net/bugs/1745741
<tsimonq2> Aww what? I thought kdesudo was removed already.
<tsimonq2> Ugh.
<tsimonq2> Oh, fun, actual porting needed. Cool.
<tsimonq2> It seems to me that when someone ported ubuntu-release-upgrader (the GTK frontend) to pkexec, they decided to forget all about the redundant call to kdesudo. Removing the conditional calling kdesudo should Just Fix It, but I'll try my code out in a VM first.
<tsimonq2> If this works, bug 1745741 needs to be processed first, then ubuntu-release-upgrader can be uploaded, and after that, we can kill kdesudo with fire.
<ubot5`> bug 1745741 in update-manager (Ubuntu Bionic) "RM: removed in Debian, working towards Qt 4 removal goal" [Medium,In progress] https://launchpad.net/bugs/1745741
<tsimonq2> Oh, I should probably just get this merged into the Bazaar branch.
<tsimonq2> I guess I'll poke again when that's merged...
<tsimonq2> Oh, yay. Falkon was accepted.
<tsimonq2> slangasek: It seems you never re-reviewed latte-dock after the discussions we had about tangerine.ttf. Could you please do that?
<tsimonq2> It would also be good to get a review on ukwm, because there's a couple other UKWM packages which are depwait on that before they can be uploaded.
<tsimonq2> Ah, there we go, LP's letting me file the bug... :)  bug 1756492
<ubot5`> bug 1756492 in qupzilla (Ubuntu Bionic) "RM: obsoleted by src:falkon" [High,New] https://launchpad.net/bugs/1756492
<slangasek> doko: I don't understand the freebayes build failure; why does ld complain about an "undefined reference to symbol 'gzerror'" in a .so which is already linked against libz?
<infinity> slangasek: 'pkg-config --libs libseqlib' seems to be full of lies compared to ldd.
<slangasek> infinity: perhaps; but I still don't see why that matters
<infinity> slangasek: libseqlib being underlinked is perhaps unrelated (but also broken), but -lz coming on the commandline before -lseqlib will certainly make --as-needed poop.  Which it wouldn't if pkg-config included -lz
<slangasek> infinity: except it's not underlinked; objdump -p /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libseqlib.so | grep libz -->   NEEDED               libz.so.1
<infinity> slangasek: No, it's underlinked for other deps.  Like I said, unrelated.
<slangasek> ah
<infinity> Bizarrely, underlinked for almost the exact inverse of what pkg-config --libs says. :P
<slangasek> I, er
<slangasek> libbwa is only available as a static lib?
<infinity> pkg-config knows nothing of -lz and -lm, while pkg-config's list aren't linked (and dpkg-shlibdeps screams loudly)
<infinity> bwa and fml both seem to be static only.  But it's also not linked to them.  Or dpkg-shlibdeps is having an aneurysm.
<slangasek> yes, it's not linked to them.  all very blech
<infinity> Any linker line that starts like 'g++  -fPIC -DPIC -shared -nostdlib' and isn't glibc makes me scared.
<slangasek> -fomit-sanity
<infinity> slangasek: Hrm, I guess one could assume that the -lfml -lbwa implies that everything that links -lseqlib is meant to bring in the static libs in its own build, in which case, it's not "underlinked" for that purpose.
<infinity> slangasek: Then the only bug here (other than piss-poor design, IMO) is '-lz -lm' missing from the pkg-config file.
<infinity> slangasek: Make that just -lz, the libm dep is transitive.
<infinity> slangasek: Oh, and for the lolz, the pkg-config file is a Debian patch.
<infinity> slangasek: And yeah, that fixes freebayes.  Uploaded that seqlib fix, will forward.
<slangasek> infinity: heh, ok
-queuebot:#ubuntu-release- New: accepted latte-dock [source] (bionic-proposed) [0.7.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: latte-dock [s390x] (bionic-proposed/none) [0.7.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: latte-dock [amd64] (bionic-proposed/none) [0.7.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: latte-dock [ppc64el] (bionic-proposed/none) [0.7.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: latte-dock [i386] (bionic-proposed/none) [0.7.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: latte-dock [arm64] (bionic-proposed/none) [0.7.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: latte-dock [armhf] (bionic-proposed/none) [0.7.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted latte-dock [amd64] (bionic-proposed) [0.7.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted latte-dock [armhf] (bionic-proposed) [0.7.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted latte-dock [ppc64el] (bionic-proposed) [0.7.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted latte-dock [arm64] (bionic-proposed) [0.7.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted latte-dock [s390x] (bionic-proposed) [0.7.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted latte-dock [i386] (bionic-proposed) [0.7.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: sbuild [amd64] (bionic-proposed/main) [0.74.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted firefox [amd64] (bionic-proposed) [59.0.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [armhf] (bionic-proposed) [59.0.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [ppc64el] (bionic-proposed) [59.0.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sbuild [amd64] (bionic-proposed) [0.74.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [arm64] (bionic-proposed) [59.0.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mailman3 [sync] (bionic-proposed) [3.1.1-6]
-queuebot:#ubuntu-release- New: accepted firefox [i386] (bionic-proposed) [59.0.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: mailman3 [amd64] (bionic-proposed/none) [3.1.1-6] (no packageset)
-queuebot:#ubuntu-release- New binary: linux [s390x] (bionic-proposed/main) [4.15.0-13.14] (core, kernel)
<ginggs> would someone please 'force-badtest octave-symbolic/2.6.0-3/s390x' ?  it seems to have passed by fluke on this architecture. previous version in vorlon's hints
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-13.14] (core, kernel)
<tumbleweed> ginggs: done
-queuebot:#ubuntu-release- New: accepted mailman3 [amd64] (bionic-proposed) [3.1.1-6]
<ginggs> tumbleweed: thanks
-queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (bionic-proposed/main) [3.28.0-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-117.141~14.04.1]
-queuebot:#ubuntu-release- New binary: mailman-suite [amd64] (bionic-proposed/universe) [0+20170523-12] (no packageset)
<LocutusOfBorg> archive admins, release team
<LocutusOfBorg> sbuild is blocked by +         apt-cacher-ng | apt-cacher,
<LocutusOfBorg>  not being in main
<LocutusOfBorg> but they are part of a new sbuild-debian-developer-setup binary package, why is it in main? I think it can be in universe
<LocutusOfBorg> (me is not remembering correctly if this can be done or not, wrt lp systems)
<cjwatson> Yes, it's listed on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html.  Moving to universe.
<tsimonq2> I was gonna say, that's a weird failure...
<tsimonq2> Thanks cjwatson
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-13.14] (core, kernel)
<tsimonq2> It'd be good to get botan processed fairly quickly.
-queuebot:#ubuntu-release- New sync: botan (bionic-proposed/primary) [2.4.0-3]
<tsimonq2> It was removed in Debian (well, 1.0 was) in 2009ish
<tsimonq2> They released a 2.0 and now qtcreator is depwait on it.
<tsimonq2> It's just a sync so it's already gone through Debian NEW, etc.
<tsimonq2> Cool, so pyqt4 is now a candidate for removal: 1745741
<tsimonq2> Er... bug 1745741
<ubot5`> bug 1745741 in pykde4 (Ubuntu Bionic) "RM: removed in Debian, working towards Qt 4 removal goal" [Medium,New] https://launchpad.net/bugs/1745741
-queuebot:#ubuntu-release- New binary: linux [armhf] (bionic-proposed/main) [4.15.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted botan [sync] (bionic-proposed) [2.4.0-3]
-queuebot:#ubuntu-release- New: accepted mailman-suite [amd64] (bionic-proposed) [0+20170523-12]
-queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (bionic-proposed) [3.28.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: botan [s390x] (bionic-proposed/universe) [2.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: botan [ppc64el] (bionic-proposed/universe) [2.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: botan [amd64] (bionic-proposed/universe) [2.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: botan [i386] (bionic-proposed/universe) [2.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: botan [arm64] (bionic-proposed/universe) [2.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: botan [armhf] (bionic-proposed/universe) [2.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted botan [amd64] (bionic-proposed) [2.4.0-3]
-queuebot:#ubuntu-release- New: accepted botan [armhf] (bionic-proposed) [2.4.0-3]
-queuebot:#ubuntu-release- New: accepted botan [ppc64el] (bionic-proposed) [2.4.0-3]
-queuebot:#ubuntu-release- New: accepted botan [arm64] (bionic-proposed) [2.4.0-3]
-queuebot:#ubuntu-release- New: accepted botan [s390x] (bionic-proposed) [2.4.0-3]
-queuebot:#ubuntu-release- New: accepted botan [i386] (bionic-proposed) [2.4.0-3]
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux [amd64] (bionic-proposed) [4.15.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [armhf] (bionic-proposed) [4.15.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [ppc64el] (bionic-proposed) [4.15.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [arm64] (bionic-proposed) [4.15.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [s390x] (bionic-proposed) [4.15.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux [i386] (bionic-proposed) [4.15.0-13.14]
#ubuntu-release 2018-03-18
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New sync: fluidr3mono-gm-soundfont (bionic-proposed/primary) [2.315-2]
-queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [162-1~ubuntu17.10.1 => 163-1~ubuntu17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [162-1~ubuntu16.04.1 => 163-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [163-1~ubuntu17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [163-1~ubuntu16.04.1]
<LocutusOfBorg> slangasek, can you please update xandikos hint to also take care of ppc64el regressed in release? thanks!
<tsimonq2> slangasek: FYI, I plan on resyncing civicrm when LP picks it up, because it seems to fix compatibility with the new symfony.
<tsimonq2> A new version was uploaded to Debian just now fixing the RC bug.
<slangasek> LocutusOfBorg: xandikos> done
<slangasek> tsimonq2: ok
<tsimonq2> slangasek: Ah, except, it still needs a delta. So sometime tonight I'll reupload it.
<tsimonq2> slangasek: (My point in pinging is that it can probably be fasttracked irt the usual checks given that it's been in Ubuntu already and not a lot has changed.)
<tsimonq2> slangasek: Also, the Debian maintainer doesn't want to do the qupzilla -> falkon rename. I'll try and convince them, but for now (so it isn't forgotten about for next cycle), please add it to the sync blacklist.
<tsimonq2> ("it" being src:qupzilla)
#ubuntu-release 2019-03-11
<infinity> tsimonq2, wxl: Fixed.
<infinity> (Or, will be on the next build)
<infinity> And no, it had nothing to do with participation in .6
<infinity> It had to do with someone archiving .5 ISOs and not removing them from the manifest, that's all.
<infinity> Timing would have been the deciding factor in some failing and others now.
<infinity> s/now/not/
<infinity> fossfreedom: ^
<tsimonq2> Thanks.
<acheronuk> logs say kubuntu iso succeeded 2 hrs ago, but no sign @ http://cdimage.ubuntu.com/kubuntu/daily-live/
<acheronuk> sil2100: morning. logs say kubuntu iso succeeded 2 hrs ago, but no sign @ http://cdimage.ubuntu.com/kubuntu/daily-live/
<acheronuk> qa tracker link is 'not found'
<acheronuk> today's ubuntu-mate iso is the same
<acheronuk> oh. mate was pre infinity's fix
<sil2100> acheronuk: hey! Looking
<acheronuk> sil2100: ty
 * acheronuk notes ubuntu job is now running
<sil2100> acheronuk: ok, everything seems to look correct on nusakan, I manually forced a mirror sync
<sil2100> Maybe now it'll be visible
<sil2100> Let's give it some time
<sil2100> 20190310  20190311  current  pending
<sil2100> That's on nusakan itself
<acheronuk> sil2100: yeah. ok I have to go for 30 mins anyway, so will re-check in a bit. thanks :)
<acheronuk> sil2100: how long does this normally take to show up?
<sil2100> acheronuk: hm, usually it's 'almost' instant, this is weird
-queuebot:#ubuntu-release- Unapproved: apt (cosmic-proposed/main) [1.7.3 => 1.7.4] (core)
<juliank> sil2100: ^ can you reject that, I messed up the changelog a bit
<juliank> I'd like to reupload it
<juliank> I gotta change gbp dch at some point
-queuebot:#ubuntu-release- Unapproved: apt (cosmic-proposed/main) [1.7.3 => 1.7.4] (core)
<juliank> And here's the fixed one
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6.9 => 1.6.10] (core)
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (cosmic-proposed) [1.7.4]
<apw> juliank, ^
<juliank> thanks apw
<acheronuk> sil2100: indeed. still no sign my end
<acheronuk> ubuntu images are likewise missing
<sil2100> Let me poke is about that
<acheronuk> ok. ty
<LocutusOfBorg> hello, can anybody please update debci hint to 2.0 too?
<sil2100> acheronuk: should be fixed, do you see the images now?
<acheronuk> sil2100: nope
<sil2100> acheronuk: did you try to hard-refresh? Or check in a different browser/tool (like even curl)
<sil2100> e.g. curl http://cdimage.ubuntu.com/kubuntu/daily-live/ just to see if it's not the browser cache
<acheronuk> 1st 2 of thsoe
<acheronuk> sil2100: now just appeared
<acheronuk> looks like we are good. thanks
<acheronuk> what? on another refresh they are gone.
<acheronuk> partial mirroring?
<acheronuk> and they are back again. fun!
 * acheronuk zsyncs quickly...
<acheronuk> sil2100: must be only partially mirrored, as sometime I get a stale one on refresh on the same browser tab, where a min before I had the latest
<LocutusOfBorg> doko, ^^ can you please ask to accept them?
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.18-dfsg-3~ubuntu18.04.2 => 5.2.18-dfsg-3~ubuntu18.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.18-dfsg-2~ubuntu18.04.3 => 5.2.18-dfsg-2~ubuntu18.04.4] (ubuntu-cloud)
<LocutusOfBorg> please accept them ^^ to unblock java
<LocutusOfBorg> sil2100, https://launchpad.net/ubuntu/+source/virtualbox-hwe/5.2.18-dfsg-3~ubuntu18.04.2
<LocutusOfBorg> you won't find bug numbers, they are build fixes because the previous version didn't build correctly due to new java
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.18-dfsg-3~ubuntu18.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (bionic-proposed) [5.2.18-dfsg-2~ubuntu18.04.4]
<doko> LocutusOfBorg: no, has to be built with security only. will upload to a ppa
<ddstreet> sil2100 good morning/afternoon!  wondering if you have a chance today, can you release systemd for x/b/c, and resolvconf for b/c?
<doko> LocutusOfBorg: https://launchpad.net/~openjdk-11-transition/+archive/ubuntu/stage5/+build/16483297  Missing build dependencies: xserver-xorg-dev-hwe-18.04
<LocutusOfBorg> doko, you need proposed too
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox-hwe/+bug/1816386
<ubot5> Ubuntu bug 1816386 in virtualbox-hwe (Ubuntu) "[SRU] Unable to install virtualbox-guest-x11-hwe on 18.04.2 LTS with HWE" [Undecided,Confirmed]
<LocutusOfBorg> doko, https://launchpad.net/ubuntu/+source/xorg-server-hwe-18.04
<LocutusOfBorg> you need to enable bionic-updates
<doko> LocutusOfBorg: I'll see what we will do. is this dependency absolutely required?
<halves> sil2100 hey there! could you please approve upload in X for qemu (LP: #1818880)? (cc'ing slashd)
<ubot5> Launchpad bug 1818880 in qemu (Ubuntu Xenial) "Deadlock when detaching network interface" [Undecided,Confirmed] https://launchpad.net/bugs/1818880
<LocutusOfBorg> doko, yes, it is, otherwise the -hwe stack won't be used, and virtualbox-hwe exists only for that reason :)
<doko> will ask security how they want to handle that
<sil2100> halves: hey! Will try o/
<sil2100> ddstreet: ok o/
<halves> sil2100 thanks man o/
<LocutusOfBorg> doko, the reason for that package is only for people with -updates pocket enabled, so if you enable that one for vbox-hwe there would be no issue wrt archive consistency
<slashd> sil2100, hope I'm saying it right "dziÄki" ;)
 * sil2100 starts his SRU shift just now
<vorlon> Eickmeyer, cyphermox: 'lintian -I' has a lot to say about carla's debian/copyright
<cyphermox> Eickmeyer: do you want to fix that please? ^
<Eickmeyer> cyphermox, vorlon: I'll get on that after 1) the current meeting in progress, and 2) getting my son to school (which is already late).
<Eickmeyer> Timinig on the meeting was going to lead to that, so I was prepared.
<cyphermox> Eickmeyer: the meeting is not even close to done though
-queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.5 => 4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.2 => 4.3.36-dfsg-1+deb8u1ubuntu1.14.04.3] (ubuntu-cloud)
<LocutusOfBorg> sil2100, ^^ please accept them, klebers needs to do testing for the kernel in proposed
<LocutusOfBorg> I syncd the security update on lts-xenial, now they are back in sync
 * sil2100 still in a very heated meeting
<LocutusOfBorg> (also bionic when you can please!)
 * LocutusOfBorg quits
<klebers> LocutusOfBorg, were there new uploads for these packages? At least virtualbox-lts-xenial currently in trusty-proposed already had the build fix.
<Eickmeyer> vorlon, cyphermox: Workng on Carla now.
<cyphermox> Eickmeyer: thanks. ping me when you need sponsoring
<Eickmeyer> cyphermox: I have a question. It looks like lintian is calling-out some issues in the copyright file for files that are only used when building for Windows or Mac (it's a cross-platform utility). Should those be a lintian-overrides or completely removed since packaging for Debian would never use those files?
<Eickmeyer> vorlon: If you can speak to this as well. ^
<vorlon> Eickmeyer: the lintian call-out is because static analysis of the source package shows no files exist that match the glob
<Eickmeyer> vorlon: Okay, if that's the case I'll remove those paragraphs.
<vorlon> (and if they are platform-specific tools that are pulled in from somewhere other than the source tarball on other platforms, there's no reason to list them in debian/copyright)
<Eickmeyer> As they are.
-queuebot:#ubuntu-release- Unapproved: libpdfbox-java (bionic-proposed/universe) [1:1.8.13-2 => 1:1.8.16-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.18-dfsg-2~ubuntu18.04.3 => 5.2.18-dfsg-2~ubuntu18.04.5] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: mongo-java-driver (bionic-proposed/universe) [3.6.2-1 => 3.6.3-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openhft-chronicle-threads (bionic-proposed/universe) [1.1.6-1 => 1.1.6-2~18.04.1] (no packageset) (sync)
<vorlon> LocutusOfBorg: hi, chatting w/ doko about virtualbox-hwe, we discussed its prior reject from -proposed and concur that it should be uploaded to -proposed and built there; however it seems there is no bug linked from the changelog which is a problem for the SRU process, could you please correct this and reupload?
<sil2100> halves: accepted (sorry it took so long)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.35]
<Eickmeyer> vorlon, cyphermox: Latest commit fixes copyright errors.
<Eickmeyer> (to carla)
<halves> sil2100 no worries man, thank you for the help!
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.18-dfsg-2~ubuntu18.04.5]
<Eickmeyer> I was unclear as to if it should have a new version number since it never made it out of the queue.
-queuebot:#ubuntu-release- Unapproved: accepted libpdfbox-java [sync] (bionic-proposed) [1:1.8.16-2~18.04]
<cyphermox> Eickmeyer: same version number is okay; so you'd want to git push --force or whatnot
-queuebot:#ubuntu-release- Unapproved: accepted mongo-java-driver [sync] (bionic-proposed) [3.6.3-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted openhft-chronicle-threads [sync] (bionic-proposed) [1.1.6-2~18.04.1]
<cyphermox> Eickmeyer: (if you had previously committed a release and tagged and all)
<Eickmeyer> cyphermox: Not seeing it. :/
 * Eickmeyer forgot to tag it
<cyphermox> I was speaking generally
<cyphermox> I'm finishing up with something and then I'll review what's in your git tree
<Eickmeyer> Okay, sounds good. I just pushed the tag.
-queuebot:#ubuntu-release- Unapproved: cloud-init (cosmic-proposed/main) [18.5-21-g8ee294d5-0ubuntu1~18.10.1 => 18.5-45-g3554ffe8-0ubuntu1~18.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.5-21-g8ee294d5-0ubuntu1~18.04.1 => 18.5-45-g3554ffe8-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.5-21-g8ee294d5-0ubuntu1~16.04.1 => 18.5-45-g3554ffe8-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<Odd_Bloke> infinity: If you have time to put your SRU hat on and look at those cloud-init uploads, it would be much appreciated; we have a couple of hot items in there and would like to get our validation process started ASAP. :)
-queuebot:#ubuntu-release- New source: carla (disco-proposed/primary) [1.9.13-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-12ubuntu2 => 2.02+dfsg1-12ubuntu2] (core)
<Eickmeyer> cyphermox: I'm guessing it looked much better? ^
<acheronuk> ooooh \o/
-queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-12ubuntu2 => 2.02+dfsg1-12ubuntu2] (core)
-queuebot:#ubuntu-release- New: rejected carla [source] (disco-proposed) [1.9.13-0ubuntu1]
<Eickmeyer> :(
<vorlon> that's the previous upload ;)
<Eickmeyer> Ohhhh....
 * Eickmeyer is mobile and can't tell
-queuebot:#ubuntu-release- Packageset: 109 entries have been added or removed
#ubuntu-release 2019-03-12
<rnpalmer> Please unblock statsmodels: bug1819227 isn't actually new, just newly tested for
<LocutusOfBorg> klebers, vbox-lts-xenial only builds guest stuff, not host packages
<LocutusOfBorg> vorlon, this is a fixup of the previous build failure in -proposed pocket, so the main bug is the one I'm trying to fix... do we really need a new one?
<LocutusOfBorg> the buildability is not a bug itself, the fix is to have it installable (    - No change rebuild package for bionic new hwe stack (LP: #1816386))
<ubot5> Launchpad bug 1816386 in virtualbox-hwe (Ubuntu) "[SRU] Unable to install virtualbox-guest-x11-hwe on 18.04.2 LTS with HWE" [Undecided,Confirmed] https://launchpad.net/bugs/1816386
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.2-0ubuntu0.18.04.3 => 1:3.32.0.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-control-center [source] (bionic-proposed) [1:3.32.0.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libjgoodies-looks-java (bionic-proposed/universe) [2.7.0-2 => 2.7.0-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libjgoodies-looks-java [sync] (bionic-proposed) [2.7.0-3~18.04]
-queuebot:#ubuntu-release- Unapproved: autofs (bionic-proposed/main) [5.1.2-1ubuntu3 => 5.1.2-1ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: autofs (cosmic-proposed/main) [5.1.2-4ubuntu1 => 5.1.2-4ubuntu1.1] (core)
<Odd_Bloke> bdmurray: Your review of the cloud-inits waiting in {xenial,bionic,cosmic}-proposed today would be much appreciated.
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.30 => 1.2.31] (core)
-queuebot:#ubuntu-release- Unapproved: apt (trusty-proposed/main) [1.0.1ubuntu2.21 => 1.0.1ubuntu2.22] (core)
<LocutusOfBorg> sil2100, you copied vbox from java security pocket, can you please also accept virtualbox-hwe that couldn't be built on the very same ppa? (because it relies on updates pocket)
<LocutusOfBorg> if you can copy from rejected it would be awesome! (vorlon told there was no bug number, but I don't think we need one!) please see above backlog
<vorlon> we do need one.
<vorlon> oh, fix-up of the previous upload, ok
<vorlon> let me look at that
<vorlon> LocutusOfBorg, sil2100: right, accepted now, sorry for failing to see that it was a continuation of the current SRU
-queuebot:#ubuntu-release- Unapproved: knockd (cosmic-proposed/universe) [0.7-1ubuntu1 => 0.7-1ubuntu1.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: knockd (bionic-proposed/universe) [0.7-1ubuntu1 => 0.7-1ubuntu1.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (cosmic-proposed) [18.5-45-g3554ffe8-0ubuntu1~18.10.1]
<cyphermox> hi, could someone please review grub2 EFI binaries (amd64 & arm64) in disco?
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.5-45-g3554ffe8-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [18.5-45-g3554ffe8-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [3.0.3-0ubuntu1~16.04.1 => 2.0.11-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: android-framework-23 (bionic-proposed/universe) [6.0.1+r72-4 => 6.0.1+r72-5~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-dalvik (bionic-proposed/universe) [7.0.0+r33-1 => 8.1.0+r23-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-build (bionic-proposed/universe) [1:7.0.0+r33-1 => 1:8.1.0+r23-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: android-platform-art (bionic-proposed/primary) [8.1.0+r23-3~18.04]
-queuebot:#ubuntu-release- New sync: android-platform-external-boringssl (bionic-proposed/primary) [8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- Unapproved: android-platform-development (bionic-proposed/universe) [7.0.0+r33-1 => 8.1.0+r23-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-external-libunwind (bionic-proposed/universe) [7.0.0+r1-4 => 8.1.0+r23-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-external-libselinux (bionic-proposed/universe) [7.0.0+r1-2 => 8.1.0+r23-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-frameworks-base (bionic-proposed/universe) [1:7.0.0+r33-1 => 1:8.1.0+r23-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-frameworks-native (bionic-proposed/universe) [1:7.0.0+r33-1 => 1:8.1.0+r23-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-libnativehelper (bionic-proposed/universe) [7.0.0+r33-1 => 8.1.0+r23-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-frameworks-data-binding (bionic-proposed/universe) [2.2.2-2 => 2.2.2-3~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-system-core (bionic-proposed/universe) [1:7.0.0+r33-2 => 1:8.1.0+r23-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-libcore (bionic-proposed/universe) [7.0.0+r33-1 => 8.1.0+r23-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-system-extras (bionic-proposed/universe) [7.0.0+r33-1 => 8.1.0+r23-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-tools-apksig (bionic-proposed/universe) [0.8-1 => 0.8-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: apktool (bionic-proposed/universe) [2.3.1+dfsg-1 => 2.3.4-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-system-tools-aidl (bionic-proposed/universe) [1:7.0.0+r33-1 => 1:8.1.0+r23-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: cava (bionic-proposed/primary) [0.6.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: android-sdk-meta (bionic-proposed/universe) [25.0.0+8 => 25.0.0+10~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: dummydroid (bionic-proposed/primary) [1.2-2~18.04]
-queuebot:#ubuntu-release- Unapproved: enjarify (bionic-proposed/universe) [1:1.0.3-3 => 1:1.0.3-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libscout (bionic-proposed/universe) [0.0~git20161124~dcd2a9e-1 => 2.3.2-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: f2fs-tools (bionic-proposed/universe) [1.10.0-1 => 1.11.0-1.1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libsmali-java (bionic-proposed/universe) [2.2.2-1 => 2.2.6-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: wala (bionic-proposed/universe) [1.3.9-2 => 1.5.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted android-framework-23 [sync] (bionic-proposed) [6.0.1+r72-5~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-build [sync] (bionic-proposed) [1:8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-dalvik [sync] (bionic-proposed) [8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-development [sync] (bionic-proposed) [8.1.0+r23-1~18.04]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190212.1-0ubuntu0.18.04.1 => 1:20190312.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20190212.1-0ubuntu0.14.04.1 => 1:20190312.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20190212.1-0ubuntu0.18.10.1 => 1:20190312.1-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190212.1-0ubuntu0.16.04.1 => 1:20190312.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-external-libselinux [sync] (bionic-proposed) [8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-external-libunwind [sync] (bionic-proposed) [8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-frameworks-base [sync] (bionic-proposed) [1:8.1.0+r23-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-lts-xenial [source] (trusty-proposed) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.6]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-frameworks-data-binding [sync] (bionic-proposed) [2.2.2-3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.38-2ubuntu1~18.04 => 8.5.38-2ubuntu1~18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-frameworks-native [sync] (bionic-proposed) [1:8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-libcore [sync] (bionic-proposed) [8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-libnativehelper [sync] (bionic-proposed) [8.1.0+r23-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (bionic-proposed) [8.5.38-2ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-system-core [sync] (bionic-proposed) [1:8.1.0+r23-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-system-extras [sync] (bionic-proposed) [8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-system-tools-aidl [sync] (bionic-proposed) [1:8.1.0+r23-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-tools-apksig [sync] (bionic-proposed) [0.8-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (bionic-proposed) [25.0.0+10~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted apktool [sync] (bionic-proposed) [2.3.4-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted enjarify [sync] (bionic-proposed) [1:1.0.3-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted f2fs-tools [sync] (bionic-proposed) [1.11.0-1.1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libscout [sync] (bionic-proposed) [2.3.2-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libsmali-java [sync] (bionic-proposed) [2.2.6-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted wala [sync] (bionic-proposed) [1.5.1-1~18.04]
-queuebot:#ubuntu-release- New: accepted android-platform-art [sync] (bionic-proposed) [8.1.0+r23-3~18.04]
-queuebot:#ubuntu-release- New: accepted android-platform-external-boringssl [sync] (bionic-proposed) [8.1.0+r23-2~18.04]
-queuebot:#ubuntu-release- New: accepted cava [sync] (bionic-proposed) [0.6.0-1~18.04]
-queuebot:#ubuntu-release- New: accepted dummydroid [sync] (bionic-proposed) [1.2-2~18.04]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2.2 => 1:0.5.2.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (disco-proposed) [2.02+dfsg1-12ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (disco-proposed) [2.02+dfsg1-12ubuntu2]
<LocutusOfBorg> thanks vorlon for fixing it up! I probably missed to explicit say that, and sorry for taking that long to upload a fix, it has been not trivial to craft it up (even if it is just some lines of code :) )
-queuebot:#ubuntu-release- Unapproved: gvfs (cosmic-proposed/main) [1.38.1-0ubuntu1.2 => 1.38.1-0ubuntu1.3] (desktop-core)
#ubuntu-release 2019-03-13
-queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.33-0ubuntu0.16.04.2 => 7.0.33-0ubuntu0.16.04.3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: leaflet-markercluster [amd64] (disco-proposed/universe) [1.4.1~dfsg-6] (no packageset)
<apw> anyone know anything about the set of android tools (android-platform-development) which have managed to get into cosmic-proposed with a lower version than cosmic-release ?
<apw> likely binary copy forwards from bionic done in error ?
<LocutusOfBorg> apw, I think this has been done by vorlon in effort to backport https://bugs.launchpad.net/ubuntu/+source/android-platform-libcore/+bug/1819448 to bionic (and also cosmic) to ensure smooth upgrades path?
<ubot5> Ubuntu bug 1819448 in wala (Ubuntu) "update to openjdk 11 in 18.04 LTS (android-tools packages)" [Undecided,New]
<LocutusOfBorg> but of course some of them already have higher version in release, so they should be just removed from the proposed pocket?
<apw> yeah that is what my reports are telling me to do :)
<LocutusOfBorg> hello, can anybody please update debci hint to 2.0 too?
<LocutusOfBorg> please also hint octave-image/2.10.0-2 on ppc64el, regressed in release
<LocutusOfBorg> (its already ignored on amd64 and i386, same OOM)
<LocutusOfBorg> apw, ^^
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.15 => 237-3ubuntu10.16] (core)
-queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.6 => 4.3.40-dfsg-0ubuntu1.14.04.1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.2 => 4.3.40-dfsg-0ubuntu14.04.1] (ubuntu-cloud)
<LocutusOfBorg> can anybody please reject from trusty queue the below?
<LocutusOfBorg>  	
<LocutusOfBorg> [Source] virtualbox (source)
<LocutusOfBorg> 4.3.36-dfsg-1+deb8u1ubuntu1.14.04.3	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-03-11
<LocutusOfBorg>  	
<LocutusOfBorg> [Source] virtualbox (source)
<LocutusOfBorg> 4.3.40-dfsg-0ubuntu14.04.1	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-03-01
<LocutusOfBorg>  	
<LocutusOfBorg> [Source] virtualbox (source)
<LocutusOfBorg> 4.3.40-0ubuntu14.04.1	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-01-21
<LocutusOfBorg> I rebased the upload on top of the proposed version
<doko> apw: please could you look at the linux autopkg test failure triggered by binutils?
<doko> vorlon: where did you copy these packages from: android-platform-development android-platform-external-boringssl android-platform-external-libunwind  android-platform-frameworks-native android-platform-system-tools-aidl
<doko> these are *not* in the ppa:android-tools for cosmic
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418 (disco-proposed/primary) [418.43-0ubuntu1]
<doko> vorlon: now removed
<doko> apw: ^^^
<apw> doko, will get it checked
-queuebot:#ubuntu-release- Unapproved: openjfx (cosmic-proposed/universe) [11.0.2+1-1~18.04.2 => 11.0.2+1-1~18.10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: scilab (cosmic-proposed/universe) [6.0.1-7~18.04.1 => 6.0.1-7~18.10] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: equinox-bundles (bionic-proposed/primary) [4.9-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted openjfx [sync] (cosmic-proposed) [11.0.2+1-1~18.10]
-queuebot:#ubuntu-release- New sync: equinox-framework (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: equinox-p2 (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted equinox-bundles [sync] (bionic-proposed) [4.9-2~18.04]
-queuebot:#ubuntu-release- New: accepted equinox-p2 [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted equinox-framework [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (cosmic-proposed) [6.0.1-7~18.10]
<doko> vorlon: also removed apktool and enjarify
-queuebot:#ubuntu-release- Unapproved: android-sdk-meta (bionic-proposed/universe) [25.0.0+8 => 25.0.0+10~18.04.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-sdk-meta (cosmic-proposed/universe) [25.0.0+8 => 25.0.0+10~18.04.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (cosmic-proposed) [25.0.0+10~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (bionic-proposed) [25.0.0+10~18.04.2]
<tjaalton> fwupdate is in bionic NEW, could someone ack the packages
<seb128> tjaalton, https://launchpad.net/ubuntu/bionic/+queue?queue_state=0&queue_text= is empty?
<tjaalton> hmm
<tjaalton> binaries
<tjaalton> not src
<seb128> ah
<tjaalton> https://launchpad.net/ubuntu/+source/fwupdate/12-3bionic2
<tjaalton> unapproved?
<seb128> indeed
<seb128> I let it though, I think fwupdate is somewhat special and vorlon had issues with the previous upload
<tjaalton> yes, those issues got fixed
<apw> bionic2 .... didnt we stop with the names years back
-queuebot:#ubuntu-release- New sync: wlroots (disco-proposed/primary) [0.3-1]
<vorlon> doko: when yesterday you listed android-tools ppa as one of the ppas to copy from for cosmic, I pointed out that ppa had no packages in cosmic at the time so I would copy forward directly from bionic
<doko> hmm, I'm pretty sure I copied everything there, and then removed the ones which were not needed
-queuebot:#ubuntu-release- New: accepted wlroots [sync] (disco-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: wlroots [amd64] (disco-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [s390x] (disco-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [ppc64el] (disco-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [arm64] (disco-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [i386] (disco-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [armhf] (disco-proposed/none) [0.3-1] (no packageset)
<Eickmeyer> Anybody up for looking at carla again now that I fixed its copyright issues? (vorlon, cyphermox)?
<mdeslaur> how to I retrigger the ghostscript autopkgtest now that there's a new ocrmypdf version in disco?
-queuebot:#ubuntu-release- New: accepted wlroots [amd64] (disco-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted wlroots [armhf] (disco-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted wlroots [ppc64el] (disco-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted wlroots [arm64] (disco-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted wlroots [s390x] (disco-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted wlroots [i386] (disco-proposed) [0.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (bionic-proposed) [12-3bionic2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (bionic-proposed) [12-3bionic2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (bionic-proposed) [12-3bionic2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (bionic-proposed) [12-3bionic2]
<vorlon> Eickmeyer: it needs an archive admin now to review it as it's been reuploaded to the NEW queue (so not cyphermox).  I am not looking at it currently, but it's on my list to come back to; I was currently prioritizing trying to get the image builds working again, since my os-prober fix was ineffective
<Eickmeyer> vorlon: Okay, let me know if I need to reinstate that update-grub exists check.
<vorlon> Eickmeyer: that won't help.  update-grub DOES exist, and is failing in the livecd-rootfs build environment.
<Eickmeyer> vorlon: ack
<cyphermox> that would need some livecd-rootfs change (os-prober)
<vorlon> cyphermox: that's what I changed and it apparently isn't os-prober that was failing
<cyphermox> vorlon: need more eyes?
<vorlon> I /assumed/ it was but it's actually failing due to grub-probe
<vorlon> (which, granted, was in the error message in the build log)
<cyphermox> is it a similar issue to what we've seen in cloud images?
<vorlon> so I really don't understand how this has wound up an ubuntustudio-specific problem, I would have expected more things to be calling update-grub before now, and we have no diversions
<vorlon> which issue?
<cyphermox> some time ago, livecd-rootfs hooks were confusing grub / grub-probe a bit re: UUIDs and whatnot
<cyphermox> I haven't looked at the build logs yet
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.17 => 229-4ubuntu21.18] (core)
-queuebot:#ubuntu-release- Unapproved: gvfs (bionic-proposed/main) [1.36.1-0ubuntu1.3 => 1.36.1-0ubuntu1.3.1] (desktop-core)
<Eickmeyer> vorlon: If there's anything I can do to help, let me know.
<Trevinho> sil2100: hey, maybe you can review this https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193 ?
<sil2100> Trevinho: hey! I can, yes! But not sure if we actually want this feature ;p
<Trevinho> sil2100: well, people is complaining about not being able to review the SRUs quickly... so...
<Trevinho> I should have done it probably 3 years ago, but...
<sil2100> Well, it's not that we couldn't do it, it's mostly because no one wanted to
-queuebot:#ubuntu-release- Unapproved: unity (xenial-proposed/main) [7.4.5+16.04.20180221-0ubuntu1 => 7.4.5+16.04.20190312-0ubuntu1] (ubuntu-desktop) (sync)
<sil2100> Thanks for the branch, let me take a look at it and at least do a code-review
<Laney> IMO you might as well have it while bileto is still alive, to make the SRU review experience easier - currently those reviews seem to be quite painful
<Trevinho> also dont' kill bileto! :)
<Trevinho> at least not everything, you can get rid of autopkg stuff, but it makes many things less annoying. So, get rid of what is broken and even a simple way to have a PPA setup and publishing is enough.
<Laney> doing that is work in itself, and why would you hate on the testing integration?
 * Laney sulks
<Trevinho> Laney: I was mentioend that was the part causing troubles.
<cjwatson> Landing mvo's command-not-found publisher integration for the primary archive (only >= disco)
<cjwatson> I'm just watching a couple of publisher runs to make sure it doesn't break
<cjwatson> Hm, not quite right, fixing
-queuebot:#ubuntu-release- Unapproved: python-ldappool (cosmic-proposed/universe) [2.2.0-3ubuntu1 => 2.2.0-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- New source: intel-mediasdk (disco-proposed/primary) [18.4.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (cosmic-proposed) [5.1.2-4ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted knockd [source] (cosmic-proposed) [0.7-1ubuntu1.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted knockd [source] (bionic-proposed) [0.7-1ubuntu1.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (bionic-proposed) [5.1.2-1ubuntu3.1]
<vorlon> ddstreet: for awareness: LP: #1819625
<ubot5> Launchpad bug 1819625 in resolvconf (Ubuntu) "Package resolvconf=1.79ubuntu10.18.04.1 broken" [Undecided,Confirmed] https://launchpad.net/bugs/1819625
<vorlon> I've seen a problem myself with DNS on cosmic after upgrade, which I'm working to reproduce under controlled circumstances that don't involve me being locked out of my desktop
<ddstreet> vorlon you use resolvconf on cosmic?
<vorlon> ddstreet: yes, because I upgrade and dogfood
<ddstreet> and it doesn't work?
<vorlon> ddstreet: post SRU, it stopped working because all of the upstream DNS servers got blatted into /run/resolvconf/resolv.conf instead of the system pointing at systemd-resolved which dtrt
<ddstreet> vorlon to be clear - you use resolvconf but not ifupdown?
<vorlon> resolvconf plus NM - this is on my laptop locally
<ddstreet> and you can't directly access your upstream ns?  only thru resolved?
<ddstreet> anyway, do put more info into the bug when you have time
<vorlon> ddstreet: I was on the corporate VPN and the VPN dropped and resolvconf didn't notice
<vorlon> yeah I'm going to chase this shortly
<ddstreet> ah ok
-queuebot:#ubuntu-release- Unapproved: resolvconf (cosmic-proposed/universe) [1.79ubuntu10.18.10.1 => 1.79ubuntu10.18.10.2] (no packageset)
<ddstreet> vorlon if you simply revert it then you place things back into edns0-to-upstream-dns server land, which isn't good either
<ddstreet> but of course, your call ;-)
<ddstreet> depends on whose dns resolution you want to break
<ddstreet> personally, i'd recommend rejecting your revert upload so we can try to figure out what the problem is and fix it
<vorlon> ddstreet: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1819625/comments/6
<ubot5> Ubuntu bug 1819625 in resolvconf (Ubuntu) "Package resolvconf=1.79ubuntu10.18.04.1 broken" [Undecided,Confirmed]
<vorlon> as far as I'm concerned, the root cause is that we failed to kick resolvconf to the curb prior to 18.04 release
<vorlon> and my /run/resolvconf/resolv.conf prior to the SRU did not have the configuration described in 2) of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1817903 - I have the local stub resolver and not the upstream name servers, which is what we should be aiming for
<ubot5> Ubuntu bug 1817903 in resolvconf (Ubuntu Disco) "systemd-resolve appends "options edns0" to resolv.conf" [Critical,Fix released]
<ddstreet> vorlon well, this is how things worked pre-bionic, with resolvconf you don't get per-interface dns resolution
<vorlon> yes, and we switched to resolved in bionic because it was the pre-bionic behavior was broken
<ddstreet> it seems, based on my (time-)limited testing, that the problem is resolved doesn't remove nameservers once routes go away
<vorlon> that is also a problem
<ddstreet> e.g. i connectd to vpn, /run/systemd/resolve/resolv.conf added the vpn nameserver, i disconnected, but it's still there
<vorlon> but round-robining the VPN dns servers by exposing them in /etc/resolv.conf is also a problem, and a regression introduced by this SRU
<ddstreet> maybe resolved magically knows not to talk to it, but it has to remove it for resolvconf to knwo that and update /etc/resolv.conf
<ddstreet> ok...well if you're rejecting the pre-bionic behavior of resolvconf, then we'll have to figure out a better way to have it use resolved than pull the stub-resolver
<ddstreet> because in that case, with ifupdown/resolvconf and systemd now including edns0, dns will definitely break unless all nameservers in the world start supporting edns0
<ddstreet> we could revert systemd including edns0 but that breaks from upstream, and we would then need to backport systemd resolved tcp pipelining from upstream, which is significantly more headache
<ddstreet> anyway, it's complex
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (cosmic-proposed) [1.79ubuntu10.18.10.2]
<ddstreet> go for the revert if you think that's best - once it's changed, i'll figure out how to best fix the entire situation (since it's still broken, but now just for other people)
<ddstreet> vorlon you may want to note in lp #1817903 that everyone affected will see breakage again with your reversion
<ubot5> Launchpad bug 1817903 in resolvconf (Ubuntu Disco) "systemd-resolve appends "options edns0" to resolv.conf" [Critical,Fix released] https://launchpad.net/bugs/1817903
<vorlon> ddstreet: xnox has some ideas about a proper fix
<xnox> ddstreet, hey
<xnox> ddstreet, let's use this channel.
<xnox> ddstreet, switching from stub-resolv.conf to resolv.conf is broken and should not have been ever done. As we have created stub-resolv.conf to specifically address integration on ubuntu, we want to use resolved's resolver all the time, as that's the only way to get correct split dns resolution.
<xnox> ddstreet, i do understand that options ends0 (with the systemd's sru) started to leak into /etc/resolv.conf with unintended consequences.
<xnox> ddstreet, the answer to that is to filter that option out as in:
<xnox> i was expecting to diff be:
<xnox> -ExecStart=+-/bin/sh -c 'cat /run/systemd/resolve/stub-resolv.conf | /sbin/resolvconf -a systemd-resolved'
<xnox> +ExecStart=+-/bin/sh -c 'cat /run/systemd/resolve/stub-resolv.conf | grep -v edns0 | /sbin/resolvconf -a systemd-resolved'
<ddstreet> xnox er, without edns0, the bug *that* fixed isn't fixed at all
<ddstreet> so people iwth resolvconf installed shouldn't get that fix?
<xnox> ddstreet, now that is sort of a majority fix, as we do kind of need ends0 when talking to resolved, but that's life for those that upgrade to bionic.
<xnox> ddstreet, yes.
<ddstreet> er...
<ddstreet> ok...
-queuebot:#ubuntu-release- Unapproved: resolvconf (bionic-proposed/universe) [1.79ubuntu10.18.04.1 => 1.79ubuntu10.18.04.2] (no packageset)
<xnox> ddstreet, now to fix this further, for everyone. we would need to reverse the flow of nameservers.
<xnox> ddstreet, instead of adding resolved' to resolvconf, we'd need to feed all the resolvconf entries into resolved.
<ddstreet> xnox so systems with resolvconf should definitely *not* be able to successfuly resolve dns if the reply is > 512 bytes?
<xnox> ddstreet, they will over TCP, won't they?
<xnox> ddstreet, you did SRU back listing on TCP, in addition to UDP?
<ddstreet> hopefully!  that was the entire problem tho
<xnox> *listening
<ddstreet> no i didn't backport tcp pipelining
<xnox> ddstreet, i just don't understand how you tested http://launchpadlibrarian.net/413182599/resolvconf_1.79ubuntu10_1.79ubuntu10.18.04.1.diff.gz this
<xnox> ddstreet, and why did you think that switching to raw nameservers would ever work, when ubuntu has never used those, in any of the releases.
<xnox> ddstreet, that's not a cherrypick from any release, is it?
<ddstreet> xnox that's how things were x and earlier
<ddstreet> with ifupdown/resolvconf
<xnox> ddstreet, which didn't have resolved by default.
<ddstreet> right...
<xnox> ddstreet, and also broken.
<xnox> (differently)
<ddstreet> what, x and earlier were broken?
<vorlon> yes
<xnox> it leaked dns, failed at split-dns, etc.
<ddstreet> ok :)
<xnox> all the things that were fixed in bionic.
<vorlon> we introduced systemd-resolved by design to fix architecture issues
<xnox> and now regressed.
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (bionic-proposed) [1.79ubuntu10.18.04.2]
<xnox> not just systemd-resolved, but stub-resolv.conf usage of systemd-resolved.
 * vorlon nods
<ddstreet> got it.  so b+ should *always* use resolved under all circumstances, period.
<xnox> ddstreet, note that people who have resolvconf installed on bionic; are upgrade peopel; and i'm ok with keeping them not as good as default install of bionic with resolved.
<ddstreet> well, except with ifupdown
<xnox> or upgraders
<xnox> (from ifupdown)
<ddstreet> xnox note that default installers of bionic don't get resolvconf
<ddstreet> ;-)
<vorlon> right
<xnox> hence it's ok to keep them without options ends0
<vorlon> and without resolvconf, things work better
<ddstreet> i will say that upgraders from xenial are likely a large number of users
<ddstreet> and that's *future* upgraders too - lots still on t/x
<xnox> ddstreet, that's subjective of the users you are exposed to ;-)
<vorlon> yeah; and I think xnox's | grep -v edns0 helps there
<ddstreet> yep, we can do that
<ddstreet> hopefully upstream nameservers will behave better than resolved-stub
<xnox> ddstreet, long term solution is to remove resolvconf from the archive, and make systemd provide /sbin/resolvconf that feeds into resolved (most things)
<ddstreet> (probably they will, i think dnsmasq and bind handle tcp pipelining ok, but i haven't specificalyl checked)
<xnox> ddstreet, then we can finally put all of the mess behind us.
<ddstreet> xnox yep i look forward to that day in 2050 xD
<xnox> ddstreet, it's usually the crappy home router between machine and the real internet that is shit.
<ddstreet> so xnox you want to update resolvconf with grep -v edns0, or should i?  or vorlon?
<xnox> ddstreet, vast majority of our users are fresh launches of cloud-images/containers btw ;-)
<xnox> irrespective of the bug volumes that we see.
<ddstreet> also one additional thought for vorlon - x upgraders who still use ifupdown with dhcp (and resolvconf), will have upstream nameservers in /etc/resolv.conf
<xnox> ddstreet, no.
<xnox> ddstreet, dhcp from ifupdown feeds into resolved via my resolved hook to isc-dhcp
<xnox> ddstreet, and feeds nothing into resolvconf
<ddstreet> ah right, resolved is lexically after resolvconf
<ddstreet> i'm thinking of ifupdown static ip/dns
<xnox> static bits feed into resolv.conf
<ddstreet> that is what gets into /etc/resolv.conf via the /etc/network/if-up.d/resolvconf script
<vorlon> yes; this is still broken
<vorlon> but we need to fix that local bug locally, not revert the architecture
<ddstreet> ok, as long as you're aware it's broken :)
<xnox> oh yes we are.
<ddstreet> well remove/fix the if-up script, shoudl be easy.
<ddstreet> xnox re: majority of our users, that's probably true, tho not with UA, but that's not really imporant
<ddstreet> xnox so should i update and reupload resolvconf with the grep -v?
<ddstreet> not sure if you or vorlon are doing it now
<vorlon> not me
<vorlon> I'm doing a straight revert which is under my SRU team purview
<ddstreet> xnox also while i have you, there's a bug where dhcp doesn't work for bionic+ guests inside libguestfs because dhcp calls the systemd hook, and systemd isn't init in the libguestfs appliance :(  not sure if you have any quick thoughts on that
<ddstreet> vorlon ack i'll do a follow up to add grep per xnox's comment above
<xnox> vorlon, ddstreet - we can do more heuristics, like if there are no nameservers apart from the stub-resolver in the end, we can append the ends0 option back in safely.
<ddstreet> vorlon do you want me to wait for your revert to get to -updates or just upload when i have it ready
<vorlon> ddstreet: feel free to upload when ready
<vorlon> I'll make sure the revert gets published first regardless
<ddstreet> thnx will do (probably tomrorow, it's late here)
<xnox> vorlon, ddstreet - cause that should be another common case with ifupdown+dhcp+resolvconf+resolved
<Ukikie> I hear in order for other things to get past -proposed golang-golang-x-sys needs hinting.
#ubuntu-release 2019-03-14
-queuebot:#ubuntu-release- New source: python-os-resource-classes (disco-proposed/primary) [0.3.0-0ubuntu1]
<jamespage> if there is an archive admin around ^^ is a split out from the nova project that came in since our last set of snapshots
<jamespage> its a pretty minimal package so hopefully not to onerous to review - I'll also need to raise a MIR for it
-queuebot:#ubuntu-release- New: accepted python-os-resource-classes [source] (disco-proposed) [0.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-os-resource-classes [amd64] (disco-proposed/universe) [0.3.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-os-resource-classes [amd64] (disco-proposed) [0.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted leaflet-markercluster [amd64] (disco-proposed) [1.4.1~dfsg-6]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-167.217] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-167.217]
-queuebot:#ubuntu-release- Unapproved: ggcov (bionic-proposed/universe) [0.9-20 => 0.9+20190314-0ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ggcov (cosmic-proposed/universe) [0.9-21 => 0.9+20190314-0ubuntu0.3] (no packageset)
<tjaalton> disco-proposed seems to have synced nvidia-graphics-drivers-legacy-390xx, that should be added to sync blacklist
<juliank> Riddell: Hey, could you perhaps transfer https://launchpad.net/software-properties to ubuntu-core-dev?
<juliank> rbalint: (reg ^) I think I want to convert software-properties to git before working on it
<juliank> but let's discuss that in #u-d if you have any pointers
<ddstreet> juliank are you planning to update apt-add-repository?  i was going to update that soon to work with private ppa's
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-47.50] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-17.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-17.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-47.50] (core, kernel)
<juliank> ddstreet: no, just porting software-properties to PackageKit
<juliank> ddstreet: But I've been thinking about the same thing
<juliank> ddstreet: So, if you want us to exchange our thoughts, let's do that on #ubuntu-devel :-)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (cosmic-proposed) [1.7.4]
<slashd> o/ sil2100, could you please approve the upload in X of pacemaker (LP: #1819046) when you have a moment ?
<ubot5> Launchpad bug 1819046 in pacemaker (Ubuntu Xenial) "Systemd unit file reads settings from wrong path" [Medium,In progress] https://launchpad.net/bugs/1819046
<sil2100> slashd: sure! But I guess it'll have to wait until after lunch, since I'm doing apt and systemd now ;)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (bionic-proposed) [1.6.10]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.31]
<Riddell> Probably, give me a few mins
<slashd> sil2100, no rush ;)
<slashd> sil2100, tks
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (trusty-proposed) [1.0.1ubuntu2.22]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.16]
<doko> apw: build-essential is now blocked for 12 days by linux autopkg test failures. please could you have a look?
<apw> doko, that is kind of a lie, this morning that wasn't on there, that has appeared because i got rid of the 4.19 hint because it no longer exists
<apw> doko, so i've reinstated the existing hint, we shall see what that does
<apw> doko, (a lie by the tooling)
<doko> ok, ta. but that failed since the build-essential upload, so it was there for 12 days, maybe with different version for the linux package
<apw> doko, it wasn't on the list this morning is all i know
<ginggs> apw, if you can, please: 'force-badtest statsmodels/0.8.0-9/armhf' LP: #1819227
<ubot5> Launchpad bug 1819227 in statsmodels (Ubuntu) "KalmanFilter gives wrong results on armhf" [Undecided,New] https://launchpad.net/bugs/1819227
<apw> doko, as i look at it every morning, so i fixed the binutils one
<apw> doko, though that is likely a previous binutils by now
<ginggs> also, please 'force-badtest octave-image/2.10.0-2/ppc64el' ?  it has regressed in release (as did amd64 and i386, which are already hinted)
<apw> ginggs, looks fine, done and done
<ginggs> apw: thanks!
<rbalint> juliank, ok, let's make s-p the next converted repo, i take a look
<juliank> :)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.18]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-8.9]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-8.9]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-8.9]
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (xenial-proposed) [1.1.14-2ubuntu1.5]
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (cosmic-proposed/main) [11.0.2+9-3ubuntu1~18.04.1 => 11.0.2+9-3ubuntu1~18.10.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (cosmic-proposed) [11.0.2+9-3ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (cosmic-proposed) [1.38.1-0ubuntu1.3]
<tjaalton> Laney: ffe for mesa good now? tested it on intel & amd
<tjaalton> upstream released 19.0.0 yesterday
<Laney> tjaalton: I guess so... what could possibly go wrong? :>
<tjaalton> exactly :)
<teward> *watches everything explode*  :P  (just kidding!)
<tjaalton> there will be point-releases every two weeks..
 * Laney sends teward in in a hazmat suit
<teward> heh
<teward> Laney: you're coming with.  *drags Laney in with him*
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190312.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: libnfs (cosmic-proposed/universe) [2.0.0-1~exp1 => 2.0.0-1~exp1ubuntu1] (kubuntu)
<doko> trying: icedtea-web
<doko> skipped: icedtea-web (10, 1, 0)
<doko>     got: 35+0: a-7:a-5:a-5:i-6:p-4:s-8
<doko>     * i386: sagemath
<doko> why?
<rbasak> doko: sagemath -> jmol -> libjmol-java -> icedtea-netx-common
<doko> ahh
<rbasak> icedtea-netx (from icedtea-web) Breaks icedtea-netx-common (< 1.7.1-1~)
<rbasak> I used chdist with apt-get install -s
<rbasak> In fact, more trivially, it looks like icedtea-netx and icedtea-netx-common aren't coinstallable?
<doko> yep, just didn't see any java deps in sagemath, missing jmol
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.19 => 2.525.20] (desktop-core)
<Eickmeyer> vorlon: Looks like the build worked.
<Eickmeyer> Now all we need is for Carla to be looked at.
 * Eickmeyer realizes vorlon is very busy and hates bugging him
<ddstreet> cyphermox i see you did the last no-change rebuild for d-i to update mini.iso; for lp #1755863 i also need to update the mini.iso in the archive; is the proper thing to do for me to upload a no-change rebuild of d-i and the netboot contents are automatically generated into the archive?  i know the manual process to build the netboot stuff has nothing to do with actually building d-i, but i don't know what the official process is to update
<ddstreet>  the archive netboot files
<ubot5> Launchpad bug 1755863 in systemd (Ubuntu Disco) "netbooting the bionic live CD over NFS goes straight to maintenance mode :" [Medium,Fix released] https://launchpad.net/bugs/1755863
<cyphermox> ddstreet: sorry, I don't understand; you say there was already a no-change rebuild of d-i?
<cyphermox> sounds like it would already be fixed in that case (looking)
<ddstreet> no i was just asking you because you're at the top of the changelog
<ddstreet> well, the top no-change rebuild in the changelog ;-)
<cyphermox> which release?
<ddstreet> b and c
<cyphermox> basically as long as whatever you needed of d-i was in the archive before the last build of d-i you'd be good
<cyphermox> so it depends when whatever other fix landed
<ddstreet> and if it wasn't, and i want to rebuild e.g. http://archive.ubuntu.com/ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/
<ddstreet> all i need to do is no-change rebuild update the d-i changelog and upload?
<cyphermox> yes
<ddstreet> cool thnx
<cyphermox> I'm very curious though, because I get a systemd bug there.
<ddstreet> yes
<ddstreet> systemd bug preventing installer from working
<cyphermox> you don't have systemd in d-i images where the installer runs AFAIK, so that would be quite odd
<ddstreet> hmm ok maybe it's for subiquity then...i'll check with the bug owner (i took it while he was out)
<leftyfb> https://bugs.launchpad.net/subiquity/+bug/1820096
<ubot5> Ubuntu bug 1820096 in subiquity "/etc/hosts not populated, preventing dns registration with dhcp" [Undecided,New]
<leftyfb> That's 1 of 4 bugs I have found with the live installer vs the classic installer
<leftyfb> another bug about cloud-init reverting the hostname after reboot was already filed
<leftyfb> another bug/difference is the fact that the live installer uses cloud-init to configure netplan so the config file in /etc/netplan/ is named differently than the classic installer. Is this worth filing a bug?
<leftyfb> another difference is the live installer installs the .46 kernel a opposed to the classic still installing the .45
<leftyfb> these issues are enough to trip up automated deployment (ansible in my case)
<leftyfb> issues/differences
<mwhudson> thanks for filing 1820096
<mwhudson> i don't think the netplan file name is part of the contract
<mwhudson> and i'm not going to apologise for the fact that you get the latest kernel from the archive by default either i think
<leftyfb> mwhudson: I'm just pointing out there are clear differences in the resulting installs between the live and classic installers
<leftyfb> mwhudson: what does "part of the contract" mean exactly?
<leftyfb> contract to ensure than the resulting installs are identical?
<mwhudson> leftyfb: you are right that there are differences
<mwhudson> and i guess i would argue that this is not a problem
<leftyfb> it is for automation tools like ansible when you make some assumptions
<mwhudson> the goal of the live installer is to install a server system, not one that is exactly the same as the older installer
<mwhudson> this might require changing some assumptions indeed
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.44 => 2.408.45] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.18 => 229-4ubuntu21.19] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-ldappool [source] (cosmic-proposed) [2.2.0-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (cosmic-proposed) [2:14.0.1-0ubuntu2]
<rbalint> tjaalton, vorlon, sil2100, could you please drop my systemd 229-4ubuntu21.19 upload? it is too early for it
-queuebot:#ubuntu-release- Unapproved: openconnect (cosmic-proposed/universe) [7.08-3 => 7.08-3ubuntu0.18.04.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: openconnect (cosmic-proposed/universe) [7.08-3 => 7.08-3ubuntu0.18.10.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected openconnect [source] (cosmic-proposed) [7.08-3ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: openconnect (bionic-proposed/universe) [7.08-3 => 7.08-3ubuntu0.18.04.1] (kubuntu)
<vorlon> rbalint: done
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (xenial-proposed) [229-4ubuntu21.19]
-queuebot:#ubuntu-release- Unapproved: grilo-plugins (cosmic-proposed/main) [0.3.8-2ubuntu1 => 0.3.8-2ubuntu1.1] (ubuntu-desktop)
#ubuntu-release 2019-03-15
<tjaalton> LocutusOfBorg: the trusty queue has four versions of virtualbox?
<tjaalton> tseliot: ubuntu-drivers-common seems to drop old changes? http://launchpadlibrarian.net/414857336/ubuntu-drivers-common_1%3A0.5.2.2_1%3A0.5.2.3.diff.gz
<mvo> tjaalton: hey, can you please remove the systemd xenial update in -proposed? I'm reviewing the ADT logs right now and I see some postinst issue that call for a closer investigation
<sil2100> mvo: can you mark the xenial bug as verification-failed-xenial?
<mvo> sil2100: yes
<mvo> bionic (so far) looks much better but I'm only half through the logs
<sil2100> mvo: will pull it in a moment
<mvo> sil2100: thank you, I will comment in the bug as well
<tjaalton> mvo: it was dropper last night
<mvo> tjaalton: good, thank you
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (xenial-proposed) [1.45-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (trusty-proposed) [4.3.40-0ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (trusty-proposed) [4.3.40-dfsg-0ubuntu14.04.1]
<tseliot> tjaalton: let me check
<tseliot> tjaalton: can you reject it, please? I'll re-upload
<tjaalton> tseliot: done
<tseliot> thanks
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.3]
-queuebot:#ubuntu-release- Unapproved: accepted gnutls26 [source] (trusty-proposed) [2.12.23-12ubuntu2.10]
<tjaalton> chrisccoulson: adobe-flashplugin update has no sru bug, and I don't see an upload for bionic
<tseliot> tjaalton: ok, re-uploaded. I think my git branch was out of sync. It should be fine now.
<tjaalton> thx
<sil2100> mvo: are you sure those failures you mentioned with the xenial systemd are reproducible and introduced by the new systemd?
<sil2100> mvo: I'll restart one of the tests to see if it wasn't some one time  timeout
<mvo> sil2100: well, I'm not sure at all, I'm just cautious
<mvo> sil2100: (sorry for the delay)
<mvo> sil2100: it might be just bad luck, i.e. the cloud being very slow and that lead to timeouts
<sil2100> mvo: let's see how the i386 goes, maybe it's not as bad
<sil2100> But the test was passing usually straight away
<mvo> sil2100: fingers crossed
<mvo> sil2100: exactly, the python-systemd ones had a long stretch of greens and then this failure, this made me nervous
 * mvo also tries to run this locally
<mvo> sil2100: I can reproduce it with a local autopkgtest run, lets make sure this becomes unavailable
<mvo> sil2100: but things are strange, trying to reproduce in a non-adt vm are not successful so far :/
-queuebot:#ubuntu-release- New binary: ipset [ppc64el] (disco-proposed/main) [7.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ipset [s390x] (disco-proposed/main) [7.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ipset [i386] (disco-proposed/main) [7.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ipset [arm64] (disco-proposed/main) [7.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ipset [armhf] (disco-proposed/main) [7.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ipset [amd64] (disco-proposed/main) [7.1-0ubuntu1] (ubuntu-server)
<Riddell> software-properties project now owned by ubuntu-core-dev
<seb128> Riddell, can we get it moved to git as well? ;)
-queuebot:#ubuntu-release- New: accepted ipset [amd64] (disco-proposed) [7.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipset [armhf] (disco-proposed) [7.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipset [ppc64el] (disco-proposed) [7.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipset [arm64] (disco-proposed) [7.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipset [s390x] (disco-proposed) [7.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipset [i386] (disco-proposed) [7.1-0ubuntu1]
<Riddell> I think that's why I was asked to change the team ownership
<Riddell> I've never done that before, you can tell me how but I fear I'd mess it up
<seb128> Riddell, oh ok, I don't know who is maintaining it, good if someone is looking at moving to git :)
<seb128> is that xnox?
<sil2100> I guess most bzr->git changes are coordinated by rbalint
<Riddell> it was juliank who asked me
<juliank> Yes
<juliank> seb128: it's on rbalint's todo list
<juliank> Riddell: Thanks!
<LocutusOfBorg> tjaalton, virtualbox 4.3.36-dfsg-1+deb8u1ubuntu1.14.04.3 this one should be deleted
<seb128> juliank, good, thx
<juliank> seb128: He's got the fancy tooling and experience for it :)
<seb128> Riddell, thx as well, sorry if my question confused you :)
<tjaalton> LocutusOfBorg: so full backport instead of just the dkms fix?
<tjaalton> actually both were backports but up to a different version
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (trusty-proposed) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (trusty-proposed) [4.3.40-0ubuntu1.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (trusty-proposed) [4.3.40-dfsg-0ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-lts-xenial [source] (trusty-proposed) [4.3.40-dfsg-0ubuntu1.14.04.1~14.04.1]
<LocutusOfBorg> tjaalton, meh, it was already in proposed the fixed version...
<LocutusOfBorg> anyway, this one contains the fix too
<LocutusOfBorg> we had one in proposed with dkms fix and this one has also a lot of cve fixes
<tjaalton> LocutusOfBorg: the queue was full of uploads.. and when I looked proposed had nothing
<LocutusOfBorg> 	2019-03-15 13:33:18 CET	Published	Trusty	proposed	multiverse	misc	4.3.40-dfsg-0ubuntu1.14.04.1~14.04.1
<LocutusOfBorg>  	2019-03-15 13:08:13 CET	Published	Trusty	updates	multiverse	misc	4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.6
<LocutusOfBorg> sure, it migrated some minutes before :)
<LocutusOfBorg> thanks!
<LocutusOfBorg> I thought it was needed a week of minimum time
<LocutusOfBorg> nice, thanks sil2100 :)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20190312.1-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20190312.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190312.1-0ubuntu0.16.04.1]
<tjaalton> security updates can be pushed quicker
<tjaalton> someone accepted adobe-flashplugin?
<ahasenack> hi release team, while preparing a MIR for zeromq3, it came to our attention that disco-proposed has a zeromq3 upload (from a debian sync) stuck for over 40 days due to an FTBFS (which I filed as #1820232). Question
<ahasenack> should that ftbfs be fixed now, after feature freeze, to let that package migrate? It was uploaded before FF
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2.2 => 1:0.5.2.3] (desktop-core, ubuntu-server)
<tjaalton> ahasenack: what would be the alternative? :)
<ahasenack> leave it there until after the release, I guess
<ahasenack> I'm well aware of the #topic :)
<tjaalton> ff doesn't mean packages can't be fixed to build
<tjaalton> oh
<tjaalton> disco has some version of zeromq3 now?
<tjaalton> which did build?
<tjaalton> right, I assumed it was a new pkg
<tjaalton> how silly
<ahasenack> I think the current one in disco will also fail
<ahasenack> so that's another option: kick the one in proposed out, and fix the build in the current one
<tjaalton> or file a FFE
-queuebot:#ubuntu-release- Unapproved: resolvconf (cosmic-proposed/universe) [1.79ubuntu10.18.10.2 => 1.79ubuntu10.18.10.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: resolvconf (bionic-proposed/universe) [1.79ubuntu10.18.04.2 => 1.79ubuntu10.18.04.3] (no packageset)
<Laney> tjaalton: looks like ubuntu image builds are failing now because of libvulkan1 not being in main...
<Laney> was the xorg upload premature? https://bugs.launchpad.net/ubuntu/+source/vulkan-loader/+bug/1742711 doesn't look approved yet?
<ubot5> Ubuntu bug 1742711 in vulkan-loader (Ubuntu) "MIR: vulkan-loader" [Undecided,Confirmed]
<tjaalton> Laney: I'd have thought it to not migrate because of the split
<tjaalton> and the vulkan mir was supposed to be handled this week anyway
<Laney> guess: mesa-vulkan-drivers was promoted to main after it migrated
<Laney> and proposed-migration isn't going to look deeply
<tjaalton> oh, it's in main now..
<tjaalton> ok then
<tjaalton> anyway, that MIR should be clear now, just needs the final ack and didrocks is gone
<Laney> so we don't get images until tuesday then?
<tjaalton> unless someone else acks it
<tjaalton> or the change is reverted
<tjaalton> cpaelzer, doko, cyphermox: ^ do you have time to check the vulkan-loader MIR? it should be all good now so would only take a minute :)
<cyphermox> ack
<Laney> cool, thanks
<tjaalton> great, thanks
<Eickmeyer> Still looking for someone to look at Carla. We'd like to get it into the Ubuntu Studio seed ASAP.
<ginggs> vorlon: what do you think of hinting python-scipy/1.2.1-0ubuntu1 ?  all tests pass locally except for one, which upstream think is an issue in matplotlib  (i think the same regression we see in 1.1.0-2)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-144.170] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-144.170]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-168.218] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (cosmic-proposed/main) [3.24.4-0ubuntu1 => 3.24.4-0ubuntu1.1] (ubuntu-desktop)
<tjaalton> Laney: images should build again, reverted the change since it seems now there's going to be a security review of vulkan-loader..
-queuebot:#ubuntu-release- Unapproved: ant (bionic-proposed/universe) [1.10.5-2~18.04 => 1.10.5-2ubuntu1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ant (cosmic-proposed/universe) [1.10.5-2 => 1.10.5-2ubuntu1~18.10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jameica (cosmic-proposed/universe) [2.8.1+dfsg-2 => 2.8.4+dfsg-1~18.10] (no packageset) (sync)
<jbicha> ruby-pkg-config went missing when it was promoted from disco-proposed today ð¢
-queuebot:#ubuntu-release- Unapproved: gradle (bionic-proposed/universe) [4.4.1-3~18.04.1 => 4.4.1-5~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gradle (cosmic-proposed/universe) [4.4.1-3~18.04.1 => 4.4.1-5~18.10] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-168.218]
-queuebot:#ubuntu-release- Unapproved: accepted ant [sync] (bionic-proposed) [1.10.5-2ubuntu1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (bionic-proposed) [4.4.1-5~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted ant [sync] (cosmic-proposed) [1.10.5-2ubuntu1~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted jameica [sync] (cosmic-proposed) [2.8.4+dfsg-1~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (cosmic-proposed) [4.4.1-5~18.10]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-47.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-17.18]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-47.50]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-17.18]
#ubuntu-release 2019-03-16
-queuebot:#ubuntu-release- New sync: prospector (disco-proposed/primary) [0.12.7-2.1]
-queuebot:#ubuntu-release- New: accepted prospector [sync] (disco-proposed) [0.12.7-2.1]
<bluesabre> Release team, care to ack https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1820388 ? We're late on our wallpaper upload (as we often are) :)
<ubot5> Ubuntu bug 1820388 in xubuntu-artwork (Ubuntu) " [UIFe] New wallpaper for Xubuntu 19.04" [Undecided,New]
<LocutusOfBorg> anybody with an s390x or a bigger knowledge can help understanding why thunderbird is sad on s390x? (I see update output complaining wrt testsuite), new binary there
<LocutusOfBorg> trying: thunderbird
<LocutusOfBorg> skipped: thunderbird (6, 3, 2)
<LocutusOfBorg>     got: 35+0: a-7:a-5:a-5:i-5:p-4:s-9
<LocutusOfBorg>     * s390x: thunderbird-testsuite
<jbicha> LocutusOfBorg: thunderbird-testsuite depends on gnome-session which depends on gnome-shell which isn't available on s390x
<jbicha> maybe we shouldn't build thunderbird-testsuite on s390xâ¦
-queuebot:#ubuntu-release- Unapproved: parted (bionic-proposed/main) [3.2-20ubuntu0.1 => 3.2-20ubuntu0.2] (core)
<LocutusOfBorg> mmmm ok thanks
#ubuntu-release 2019-03-17
<jbicha> I see at least epiphany-browser and ruby-pkg-config went missing when they were promoted from disco-proposed
<jbicha> simple-scan too
-queuebot:#ubuntu-release- New source: openjdk-13 (disco-proposed/primary) [13~12-1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418 [source] (disco-proposed) [418.43-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openjdk-13 [source] (disco-proposed) [13~12-1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-418 [i386] (disco-proposed/multiverse) [418.43-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-418 [amd64] (disco-proposed/multiverse) [418.43-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418 [amd64] (disco-proposed) [418.43-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418 [i386] (disco-proposed) [418.43-0ubuntu1]
<Eickmeyer> Upstream Carla has just released version 2.0 final. I need it reviewed to out of the NEW queue ASAP so I can upload new patches bringing it to 2.0 final.
<Eickmeyer> I do have a question about that process too that I'm sure cyphermox, vorlon, or anybody else can answer. Since Carla will be eventually in upstream Debian, when I upload the new patches, should I change it from 1.9.13-0ubuntu1 to 1.9.13-1ubuntu1 or some other method?
<Eickmeyer> tsimonq2, you could probably answer as well. ^
<teward> Eickmeyer: if the package is -1 in Debian, then -1ubuntu1 is the first Ubuntu revision
<teward> Eickmeyer: refer to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<teward> for how version strings behave.
<Eickmeyer> teward: It's not upstream yet, though.
<teward> i know it suggests -Xubuntu0.1, but I've typically seen it as -Xubuntu1 :P
<teward> Eickmeyer: then don't change it until it's in upstream
<teward> if it's not in Debian then it's -0ubuntuX.Y
<teward> so 0ubuntu1
<teward> you can take a look at any of my NGINX version bumps where the software version wasn't in Debian yet as examples ;P
<Eickmeyer> Okay, then it'll have to be 0ubuntu1.1?
<teward> I think i need more background on what you're after... :P
<teward> (I came in late)
<teward> AIUI, the 'version' change is based on the current package in Ubuntu
<teward> so if the current one is -0ubuntu1 and you're adding new pathces to that version, then it'd either be -0ubuntu1 or -0ubuntu2 - typically I've seen the *second* of those two versions
<teward> (but I've seen both before...)
<Eickmeyer> Okay, Carla is in the NEW queue, which means it still needs an admin to look at it to migrate to proposed. Upstream has just released it's 2.0 final (what's in the NEW is 1.9.13, aka 2.0-RC3 patched to 2.0-RC4), so I have patches to bring it to 2.0.
<Eickmeyer> And, since the eventualallity is that it will be in upstream Debian (but can't now due to the buster freeze), it has the Xubuntu1.
<Eickmeyer> teward: ^
<Eickmeyer> Going with 1.9.13-0ubuntu2
-queuebot:#ubuntu-release- New binary: openjdk-13 [s390x] (disco-proposed/universe) [13~12-1] (no packageset)
<jbicha> Eickmeyer: new packages can still be uploaded to Debian, they just won't be in Buster
<jbicha> and you can open a sponsoring bug for carla 2.0, you don't need to wait for it to be approved in the new queue first
<Eickmeyer> jbicha: I don't need a sponsor for Carla anymore, I was approved as uploader and the ACLs were already applied.
<Eickmeyer> It hasn't been moved out of new yet.
<jbicha> you still need a sponsor until it's actually in Ubuntu
<Eickmeyer> It's sitting in the new queue now, waiting for review.
<Eickmeyer> cyphermox already sponsored it.
<Eickmeyer> jbicha: Unless I'm confused?
<jbicha> you started by saying you needed to wait until it made out of the new queue to update it to 2.0 and I replied that you didn't need to wait :)
<Eickmeyer> jbicha: Well, it's already 2.0-RC3 (1.9.13) patched to 2.0-RC4 (1.9.14) and I have the patches ready to go once it's in Ubuntu, and since I have PPU for that package, I should just be able to update it directly, right?
<jbicha> yes, once it's approved, you won't need a sponsor
-queuebot:#ubuntu-release- New: accepted openjdk-13 [s390x] (disco-proposed) [13~12-1]
#ubuntu-release 2020-03-09
<mwhudson> um all glibc triggered autopkgtests failing isn't good?
<vorlon> doko: why are you rebuilding perl for libcrypt1?  It's not viable to have to rebuild every package which links against libcrypt to add a new dependency on libcrypt1
<vorlon> doko: and the plan that was discussed earlier on irc didn't mention perl, only base-files + libc + libxcrypt
<mwhudson> vorlon: is there any pump turning i can do to help with glibc?
<lotuspsychje> good morning to all
<lotuspsychje> we have a user reporting the same symptons of bug #1860622 in #ubuntu anyone knows whats the status on that?
<ubot5> bug 1860622 in pulseaudio (Ubuntu) "Dependency error installing pulseaudio-esound-compat" [Undecided,Fix committed] https://launchpad.net/bugs/1860622
<vorlon> mwhudson: I don't know, really; per above I'm not clear on why what's being uploaded is being uploaded
-queuebot:#ubuntu-release- New binary: ubuntustudio-look [amd64] (focal-proposed/universe) [0.69] (ubuntustudio)
<Eickmeyer> ^ Separated out a metadata file. Probably just needs a rubber stamp.
-queuebot:#ubuntu-release- New binary: heimdall-flash [amd64] (focal-proposed/none) [1.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: heimdall-flash [s390x] (focal-proposed/none) [1.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: heimdall-flash [ppc64el] (focal-proposed/universe) [1.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: heimdall-flash [arm64] (focal-proposed/universe) [1.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: heimdall-flash [armhf] (focal-proposed/universe) [1.4.2+dfsg-1] (no packageset)
<vorlon> I'm not sure what was going on with the autopkgtest queues being stuck, but it seems to be resolved now, (coincidentally?) after I reset the workers
-queuebot:#ubuntu-release- New: accepted heimdall-flash [arm64] (focal-proposed) [1.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted heimdall-flash [armhf] (focal-proposed) [1.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted heimdall-flash [amd64] (focal-proposed) [1.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted heimdall-flash [s390x] (focal-proposed) [1.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (focal-proposed) [3.10.3+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (focal-proposed) [3.10.3+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: accepted heimdall-flash [ppc64el] (focal-proposed) [1.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (focal-proposed) [3.10.3+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (focal-proposed) [3.10.3+dfsg-1~exp2]
<mwhudson> vorlon: hm ok i guess i'll see what doko says when he's around
<xnox> vorlon:  we had all autopkgtest fail, with perl failing to find libcrypt whilst upgrading the autopkgtest workers.
<xnox> he did say he will look more into that
<xnox> you can read up backscrol either here or on #ubuntu-devel
<xnox> let me find a sample log
<xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/3/389-ds-base/20200306_162651_f9385@/log.gz
<xnox> Setting up libc6:amd64 (2.31-0ubuntu1) ...
<xnox> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
<xnox> that was all of glibc triggered autopkgtests, with all of them failing as "unknown"
<xnox> due to above
<mwhudson> so everything needs retriggering with perl&glibc from proposed?
<mwhudson> i notice deboostrap succeeds today
<xnox> i am assuming somebody already retriggered
<xnox> because glibc results are half green already
<xnox> hm yet the queues are empty
<xnox> and there is lots of red
<xnox> i'll speak to doko
<doko> vorlon: perl-base and login are the only packages that pre-depend on libcrypt1, not base-files. and I didn't want to re-introduce another pre dependency
<doko> no, I didn't retrigger
-queuebot:#ubuntu-release- Unapproved: accepted alsa-lib [source] (eoan-proposed) [1.1.9-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted alsa-lib [source] (bionic-proposed) [1.1.3-5ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (eoan-proposed) [1.56-0ubuntu0.19.10.0]
<xnox> retriggering things triggered by glibc, on amd64 i386 ppc64el s390x, with extra trigger added for perl
<xnox> 8k of tests
<xnox> submission in progress
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-dev-tools [source] (bionic-proposed) [0.175ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1076.86] (kernel)
<doko> vorlon: please could you add llvm-toolchain-10 to the i386 whitelist?
<doko> xnox: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/c/cross-toolchain-base/20200309_104230_89307@/log.gz
<doko> Calculating upgrade...
<doko> The following packages will be upgraded:
<doko>   base-files libc-bin libc6 libcrypt1 libperl5.30 locales login passwd perl
<doko>   perl-base perl-modules-5.30
<doko> libcrypt1 is already installed (at least it says it's getting upgraded)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1076.86]
<doko> but the crypto library is removed because of the bad breaks/replaces in the old libcrypt1 on the image
<xnox> doko:  thus trigger should include libxcrypt?!
<xnox> doko:  i am wondering if libcrypt1 in shlibs should generate a dep on "libc6 (>= 2.31), libcrypt1 (>= 1:4....)
<xnox> doko:  because really, using libcrypt1 adds an extra requirement on a higher libc6
<doko> maybe, but this doesn't help with the current situation
<xnox> argh
<xnox> doko:  libc6 in it's postinst is using perl. but it is not guaranteed that the new libcrypt1/perl are _configured_ at that point, only unpacked.
<xnox> doko:  i wonder if libc6 maintainer scripts must LD_PRELOAD libcrypt1 or like actually predepend on it.
<xnox> doko:  because debconf
<doko> no, libcrypt1 is installed before
<doko> it get's removed by removing libc6 2.30 and installing 2.31
<xnox> doko:  it really didn't....
<xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/c/cross-toolchain-base/20200309_104230_89307@/log.gz
<xnox> says that it will be upgraded
<xnox> does the VM image have the old libcrypt1 without fixed up breaks?
<doko> yes
<xnox> in that case we need a new libc6 upload which conflicts with broken libcrypt1 versions
<xnox> (those without ubuntu-specific breaks/replaces)
<xnox> or like rebuild our VM images without libcrypt1
<xnox> Laney:  we have removed libcrypt1 from focal-release; yet our VM images appear to have it. Can we please rebuild autopkgtest VMs without libcrypt1?
<xnox> or maybe juliank ^^^^
 * xnox looks at VM images
<doko> xnox: can you confirm the libcrypt1 version on the images?
<xnox> good point
<xnox> if only i remembered which machines i need to ssh into
<doko> ahh, libxcrypt is entirely removed from the release pocket
<doko> yes, then rebuilding of the autopkg images should solve that issue
<juliank> xnox: it iss wendigo
<juliank> and I guess we can do that?
<xnox> juliank:  yeap, ssh-ed in
<xnox> based on admin docs
-queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.25-1ubuntu6 => 0.09.25-1ubuntu8] (no packageset)
<doko> and probably it's better to rebuild the buildd images as well
<doko> cjwatson: ^^^ is this something you could help with?
<juliank> xnox: So shall I do RELEASE=focal autopkgtest-cloud/tools/build-adt-image-all-clouds autopkgtest/setup-commands/setup-testbed ?
<xnox> juliank:  i want to check that the current images are bad. I am inside the worker, looking up nova creds to download the image
<xnox> juliank:  but then yes something like that.
<xnox> will need to be done
<xnox> downloading image, it is taking forever
<doko> to fix an upgrade from a bad libcrypt1, maybe move libcrypt.so.1 from /lib/<multiarch> in libc6's preinst, run ldconfig, and then remove it in the postinst?
<xnox> doko:  scary, as it is using perl in preinst
<doko> maybe cp instead of mv
<xnox> doko:  juliank: ii  libcrypt1:ppc64el                    1:4.4.10-10ubuntu1 is installed in the images
<xnox> which is bad
<juliank> ack
<xnox> we must rebuild images without it
<juliank> i can start that
<xnox> juliank:  i'm loging out of everything, as i have never rebuild the images from scratch
<xnox> hm
<xnox> i  should have killed my instance first!
<xnox> and did that now
<xnox> doko:  so i guess all of my test submissions will still be broken
<xnox> doko:  and tests should just pass, with glibc trigger alone.
<xnox> after we rebuild our images
<juliank> xnox: should I remove your test submissions
<juliank> ?
<xnox> juliank:  i think so, yes please.
<xnox> everything from xnox submitter
<juliank> doing so
<xnox> make it so!
<doko> yes
 * xnox giggles
<juliank> hmm
<juliank> I'm hitting a bug somewhere
<juliank> xnox: also to rebuild the images from scratch, we must hack around a bit, as otherwise, it upgrades the old ones, sigh
<xnox> juliank:  i thought there is a parameter to that script to start off from i.e. eoan stable
<juliank> xnox: ah really bootstrap from eoan
<juliank> yes
<xnox> juliank:  yes, use eoan as base image, or the prestine import of focal (the CPC cloud images, which are good)
<doko> libc6: conficts libcrypt1 (<< 1:4.4.10-10ubuntu3), libcrypt1: breaks libc6 (<< 2.31)
<doko> juliank: ^^^ how should apt resolve that?
<xnox> doko:  ok great, we just need to eradicate the broken ubuntu1 from the image then.
<xnox> doko:  assuming the breaks libc6 <<2.31 is in ubuntu3, yes.
<doko> I think the conflct adds an impossible solution to make the upgrade
<doko> s/solution/requirement/
<xnox> doko: let's rebuild autopkgtest VM images; then run tests, I think we will be fine then.
<xnox> doko:  without any extra libxcrypt nor glibc uploads.
<juliank> I'm investigating
<xnox> juliank:  from bash_history, i see that cpc stock image is often uploaded by hand with glance image-create
<xnox> however i see that was last done with cosmic
<xnox> juliank:  ./create-nova-image-new-release focal ubuntu/ubuntu-eoan-daily-amd64-server-20191122-disk1.img testbed-`hostname` autopkgtest/setup-commands/setup-testbed
<juliank> xnox: I want to check if we have older focal images, how many, etc
<xnox> was run before
<xnox> juliank:  so i see only adt customized images and no stock imports of focal at all.
<xnox> juliank:  https://paste.ubuntu.com/p/TY62S4Fgtj/
<xnox> 08/09 adt builds of arm64, ppc64el, s390x without any stock focal images
<xnox> and those contain broken libxcrypt1
<juliank> xnox: i see ubuntu/ubuntu-focal-daily-s390x-server-20200305-disk1.img
<xnox> juliank:  yet there are autosync images of eoan https://paste.ubuntu.com/p/B26J3r8dDY/
<juliank> on bos01-s390x
<xnox> juliank:  i'm connected to bos02-ppc64el env
<juliank> ack
<xnox> do you have the 0307 eoan daily builds?
<xnox> i.e.  auto-sync/ubuntu-eoan-daily-s390x-server-20200307-disk1.img
<xnox> i guess we need a common base image that exists in all regions for consistency
<xnox> or upload a new one
<juliank> ubuntu/ubuntu-eoan-daily-s390x-server-20200307-disk1.img
<juliank> yes
<juliank> xnox: it does not matter much where we start i guess
<xnox> juliank:  i don't see that one in bos02 =(
<xnox> unless  the prefix doesn't matter?
<xnox> auto-sync/ vs ubuntu/
<doko> I'm removing the build-essential upload from -proposed again, it's not needed, because libc6-dev depends on libcrypt-dev
<juliank> xnox: prefix does nto matter
<xnox> then rebuild everything against that? but i somehow confused how it will be extrapolated per arch =) cause it should be -$ARCH- right? hopefully the scripts know how to do that
<xnox> product_name      | com.ubuntu.cloud.daily:server:19.10:ppc64el
<xnox> anyway, i logout! best of luck to you =)
<juliank> xnox: so it will automatically rebuild with the latest focal base image next round, when was the last save image?
<juliank> I feel like making sure it was built before March 4 should work
<xnox> march 4 cpc upstream image is good
<xnox> adt/* images from 5/6/7/8/9 march are all bad
-queuebot:#ubuntu-release- Unapproved: accepted collectd [source] (bionic-proposed) [5.7.2-2ubuntu1.2]
<xnox> juliank:  or you can modify the rebuild script to temproarly do " apt remove libcrypt1"
<xnox> juliank:  because it is unreferenced in the image today.
<juliank> xnox: hmm
<xnox> (release pocket)
<doko> but remember to remove that line later ...
<juliank> I just ignore grep -v 20200306 | grep -v 20200307 | grep -v 20200308 | grep -v 20200309
<xnox> it used to be, but not anymore. I.e. bad base-files & bad libcrypt1 migrated, which ended up on the image (and persist), but now have been removed from focal-release
<juliank> Then we start from 2020-03-06 base images or earlier
<xnox> juliank:  more.
<xnox> juliank:  because bad libcrypt1 migrated on the 3rd of march?
<xnox> https://launchpad.net/ubuntu/+source/libxcrypt/+publishinghistory
<xnox> 	2020-03-03 09:08:17 GMT	Superseded	Focal	release	universe	libs	1:4.4.10-10
<juliank> ubuntu2 is the one we are worried about
<xnox> is when the very bad ubuntu1 landed in the image
<juliank> ubuntu1 did not have breaks/replaces?
<xnox> juliank:  no, ubuntu2 is the first good one
<juliank> it was just a no-change rebuild
<xnox> juliank:  but ubuntu2 is not installable with libc6 from release pocket.
<xnox> juliank:  ubuntu1 is installable with libc6 in the release pocket, which is bad.
<juliank> OK, let's just apt purge libcrypt1
<doko> xnox: no, the Debian imports are already broken
<xnox> doko:  right, ubuntu1 is the last bad one =)
<doko> ahh, ok
<xnox> ubuntu2 is the first good one
<doko> yes
<xnox> juliank:  but apt purge libcrypt1 might not work, if base-files is too new in the image. because it depends on libcrypt1. So maybe you need to purge libcrypt1 and downgrade base-files, which hopefully apt will figure out....
<doko> if it helps, remove base-files from -proposed
<xnox> juliank:  i still feel somehow rebootstrapping adt images from eoan might be better.
<juliank> xnox: ah
<juliank> xnox: hmm, it's running now
<xnox> juliank:  ack
<xnox> let's see if it works
<juliank> I see E: Unable to locate package libcrypt1
<juliank>  glib-networking : Depends: gsettings-desktop-schemas but it is not going to be installed
<juliank> ppc64el
<juliank> yikes
<juliank> probably need to really start from eoan again
<juliank> in any case, it will either produce new images without libcrypt1 or fail
<juliank> probably should have deleted other 20200309 images so I can know if I finished a new one
<juliank> some images are good already, and some fail to build
<juliank> xnox: Rebootstrapping from eoan
<juliank> xnox: I added a safety check to setup-testbed so it cant't build new images that end up with libcrypt1 installed
<xnox> juliank:  ok
<xnox> juliank:  we will need to remove that safety check after we have good images; because it will become safe after glibc migrates in focal
<juliank> xnox: yup
<xnox> (or if images with -proposed are built)
<juliank> ok I have a syntax error somewhere
<juliank> take #3
<juliank> Apologies for the inconvenience
<doko> juliank: are the images now updated?
<juliank> let's check
<juliank> doko: I don't think so
<juliank> bos02-arm64 succeeded
<juliank> but the rest got confused
<juliank> and spawned multiple instances with the same id
<juliank> gotta try that again
<juliank> First gotta delete all the images
<juliank> s/images/servers/
<juliank> doko: this is going to take a few more ages
<juliank> I'm deleting all servers now
<juliank> it's slow
<juliank> I'll also delete the images afterwards, then it should be easy to see
<juliank> doko: Also, we might be running out of resources on arm, so I'm not super confident it will work
<juliank> Anyway, deleted all adt-prepare servers and deleting images right now
<juliank> and then we still need to do the same thing on lxd
<juliank> this is only arm64+ppc64l+s390x+amd64+i386
<juliank> not armhf
<seb128> someone there should perhaps send an email to ubuntu-devel@ letting people know that the autopkgtest are out of order on focal and being work on but it's taking a bit
<juliank> I don't think that's necessary, what are they going to do differently?
<seb128> you are arguing that service outage is not worth communicating about?
<xnox> juliank:  i didn't see lxd images to be impacted, but maybe i am wrong
<juliank> xnox: I think they rebuild from cloud image today
<juliank> xnox: I'm launcing on
<juliank> * launching one
<juliank> lgtm
<juliank> this is slow
<juliank> ugh
<juliank> seb128: i think it's fairly self-evident
<juliank> seb128: but meh
<juliank> seb128: sent one
<seb128> juliank, it's also self-evident when e.g gmail is down, wonder why google bother communicating about outdates :p
<seb128> juliank, thanks
<juliank> meh
<juliank> reddit is down all the time and does not tell people about it
<juliank> autopkgtest is not down per se, just tests fail
<seb128> juliank, even when ti's self evident that a piece of infra is down is not evident that it has been reported to the right people so if only that an announce has as effect to don't have 15 different people spending time looking at who to ping and bothering all #is or whatever
<juliank> seb128: but it's been broken for a week, so fairly diminishing returns by now
<juliank> :D
<seb128> since friday no?
<seb128> which means a w.e with a good part of the active contributors out because they don't work on w.e/were travelling back from a sprint
<juliank> people say the libcrypt1 on march 03 4? was broken too
<juliank> i don't have followed this closely
<seb128> anyway, thanks for sending an email
<juliank> cloud-init has broken depends, so lcy01 and lgw01 are not building afaict
<juliank> not sure if the other ones work
<juliank> they're still doing stuff
<juliank> but it's possible we're not getting images for everything
<juliank> hmm
<juliank> it was trying to build i386 images
<juliank> I don't know why
<juliank> ppc64el and s390x are done
<juliank> should I just completely purge the queue?
<juliank> I think britney will rerequest stuff if needed?
<juliank> but not sure
<juliank> xnox: I only purged your stuff from one queue and forgot the others...
<juliank> ok, so how do I get amd64 images now?
<juliank> vorlon: Do we actually still use i386 images? I don't think so, and they fail to build now that we don't upgrade the last one
<juliank> xnox, doko arm64, ppc64el, s390x are done; building amd64 noew
<juliank> *now
<juliank> it's running in a tmux
<juliank> it's still running
<juliank> doko, xnox we should be live again
<juliank> Laney: We might get terrible error messages tomorrow
<juliank> Laney: I published new images upgraded from eoan that work (have no libcrypt1), but nightly will try to rebuild with latest focal daily - if that ends up containing libcrypt1, setup-testbed will fail its safety check i added
<juliank> JFYI
<xnox> juliank:  coool
<xnox> juliank:  let me retry just a couple of packages to see if they work fine
<vorlon> locutus_: was there an FFe bug for this qgis sync starting a transition?
<vorlon> doko: perl-base and login pre-depending on libcrypt1 doesn't appear to solve the problem of the library previously provided by libc6 moving to a different package.  Why did you decide it was not correct to have libc6 pre-depend on libcrypt1?
<vorlon> juliank: the i386 images are used in launchpad.
<juliank> vorlon: the i386 adt/ images is what I'm talking about
<vorlon> juliank: ok.  those we aren't using on focal, no
<juliank> right we should stop building them
<juliank> gotta add a test for that
<juliank> aka if [ $arch = i366 -a $RELEASE = focal ]; then continue; fi
-queuebot:#ubuntu-release- Packageset: Removed libmng from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed qt4-x11 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-10 to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added setuptools to i386-whitelist in focal
<locutus_> vorlon, no transition...
<locutus_> I don't remember the rationale for syncing it, let me check
<vorlon> locutus_: libqgis-server3.4.15 -> libqgis-server3.10.3 is this not a transition?
<locutus_> but no reverse-deps...
<vorlon> et al
<vorlon> ok
<locutus_> its somewhat an internal library I would say
<locutus_> unfortunately the diff is huge, but I remember some bugfixes we needed, such as compatibility with proj 6.3.1 and something else
<cjwatson> doko: I'm off today, but ask me tomorrow.  buildd images get built automatically, I just need to push them to LP once builds are available
<doko> vorlon: I didn't decide ... just questioning why the pre-depends wasn't done in unstable
<vorlon> doko: didn't decide? you were doing the uploads
-queuebot:#ubuntu-release- New sync: pdfchain (focal-proposed/primary) [1:0.4.4.2-1]
-queuebot:#ubuntu-release- New: rejected pdfchain [sync] (focal-proposed) [1:0.4.4.2-1]
-queuebot:#ubuntu-release- New source: pdfchain (focal-proposed/primary) [1:0.4.4.2-1build1]
-queuebot:#ubuntu-release- New: rejected pdfchain [source] (focal-proposed) [1:0.4.4.2-1build1]
-queuebot:#ubuntu-release- New binary: pdfchain [amd64] (focal-proposed/universe) [1:0.4.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdfchain [s390x] (focal-proposed/universe) [1:0.4.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdfchain [ppc64el] (focal-proposed/universe) [1:0.4.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdfchain [armhf] (focal-proposed/universe) [1:0.4.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: pdfchain [arm64] (focal-proposed/universe) [1:0.4.4.2-1build1] (no packageset)
<Eickmeyer> Is there any chance I can get ubuntustudio-look moved out of NEW? I moved a .xml file into its own package to fix an installation bug, so it's super trivial.
<Eickmeyer> Besides that, we have our new default wallpaper ready to go, so I want to make sure bug 1866584 gets fixed before I upload more changes.
<ubot5> bug 1866584 in ubuntustudio-look (Ubuntu) "ubuntustudio-wallpapers duplicates file in ubuntustudio-wallpapers-focal" [Undecided,Fix committed] https://launchpad.net/bugs/1866584
<ahasenack> vorlon: hi, I see debian-installer now is blocked on this new src:libxcrypt
<ahasenack> vorlon: I also saw juliank's email about the autopkgtest images being broken because of it. Is that the reason for the block?
<vorlon> ahasenack: no, the reason for the block is in scrollback over the weekend, libxcrypt somehow made it into the release pocket without a corresponding libc6 that pre-depends on it, which broke the world
<vorlon> Eickmeyer: ubuntustudio-wallpapers depends on ubuntustudio-wallpapers-focal; it does not look like a reasonable solution to me to deal with a file conflict between these two packages by introducing yet another binary package for a single data file
<ahasenack> vorlon: ok, thanks. What's the event that will unbkreak the world and release the lock
<ahasenack> ?
<vorlon> ahasenack: I don't know, doko has been laconic in his responses to me about what he's doing and the uploads I've seen don't match what was discussed.
<vorlon> I *expected* to see a pre-depends from libc6 to libcrypt1, possibly with some manual ldconfig handling in a preinst, and to unblock all of this once glibc is a candidate
<vorlon> but then I see no-change perl uploads that look to me like they're treating the symptom instead of fixing the bug
<ahasenack> vorlon: this glibc predates the breakage? https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu2
<ahasenack> it says "2 days old"
<vorlon> ahasenack: it appears to include all of the changes that were discussed. but it needs to be a candidate per p-m, and I also want to know why this change wasn't sufficient without there also being a perl upload
<ahasenack> I see all its reds point at libcrypt.so.1
<vorlon> xnox: you've triggered tests with perl+glibc and these passed on amd64 but not other archs, do you know why?
<juliank> oh I should send an email that the issue is sorted out i supposer
<vorlon> ah
<vorlon> so here's the problem
<vorlon> libc6 preinst is trying to load debconf before it does the ldconfig
<vorlon> I think we should just move the ldconfig handling to the front of the maintainer script instead.
<vorlon> glibc 2.31-0ubuntu3 uploaded
<vorlon> Eickmeyer: I've looked further and I see where usr/share/gnome-background-properties/ubuntustudio-wallpapers.xml is also shipped in e.g. ubuntustudio-wallpapers-disco, so it makes sense why there is a file conflict.  However, the actual contents of this file don't make much sense to me in a common data package, because the xml file /references/ the wallpapers from the various per-series binary
<vorlon> packages, which are not going to be installed.  So what do you expect the behavior to be here if someone installs ubuntustudio-wallpapers, then tries to select the disco wallpaper which is not actually installed?
-queuebot:#ubuntu-release- New: rejected ubuntustudio-look [amd64] (focal-proposed) [0.69]
<Eickmeyer[m]> vorlon: We
<Eickmeyer[m]> vorlon: We've been including that file in the packages for YEARS. It's the only way to get gnome to see our wallpapers. I don't appreciate the rejection without explanation.
<Eickmeyer[m]> But, I guess I'll fix the disco wallpapers, if it's showing up there too.
<vorlon> Eickmeyer[m]: er, I've given you an explanation for the reject.
<vorlon> you should have per-series .xml files, with no file conflict, unless you can provide an explanation why this is wrong
<vorlon> because right now, your all-in-one xml file is going to present impossible options to users in the gui by default
<Eickmeyer> It causes no issues. If the files aren't there, it simply skips over them.
<vorlon> (unless gnome happens to filter them out, but even then, this is not a good reason to create a separate -data package)
<Eickmeyer> Gnome filters them out if they're not there.
<vorlon> ok
<vorlon> but even so, having ubuntustudio-wallpapers-focal ship ./usr/share/gnome-background-properties/ubuntustudio-wallpapers-focal.xml with correct contents
<vorlon> and ubuntustudio-wallpapers-eoan ship ./usr/share/gnome-background-properties/ubuntustudio-wallpapers-eoan.xml with correct contents
<vorlon> is more correct
<Eickmeyer> I agree, but you are giving a VOLUNTEER that is sick a ton more work to do, even if it's "correct".
<vorlon> it is the responsibility of the archive admins to manage the namespace of binary packages in Ubuntu
<Eickmeyer> We've been shipping that all-in-one file for years, but this is the first time you've raised an issue.
<vorlon> because this is the first time you've asked me to approve a binary package for a single file
-queuebot:#ubuntu-release- New: accepted pdfchain [amd64] (focal-proposed) [1:0.4.4.2-1build1]
-queuebot:#ubuntu-release- New: accepted pdfchain [armhf] (focal-proposed) [1:0.4.4.2-1build1]
-queuebot:#ubuntu-release- New: accepted pdfchain [s390x] (focal-proposed) [1:0.4.4.2-1build1]
-queuebot:#ubuntu-release- New: accepted pdfchain [arm64] (focal-proposed) [1:0.4.4.2-1build1]
-queuebot:#ubuntu-release- New: accepted pdfchain [ppc64el] (focal-proposed) [1:0.4.4.2-1build1]
<vorlon> I understand that you are a volunteer, but that does not give you a free pass on binary packages that the archive admins disagree with
<Eickmeyer> Only overly pedantic ones that like to cause issues with Ubuntu Studio over the past years.
<Eickmeyer> Sorry, I'm gettin out-of-line.
<Eickmeyer> Just super frustrated.
<Eickmeyer> And ill.
-queuebot:#ubuntu-release- New: accepted python-tinyalign [amd64] (focal-proposed) [0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-tinyalign [armhf] (focal-proposed) [0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-tinyalign [s390x] (focal-proposed) [0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-tinyalign [arm64] (focal-proposed) [0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-tinyalign [ppc64el] (focal-proposed) [0.2-1ubuntu1]
<tjaalton> I've got a question about how to handle an upgrade issue with a dkms package which was first put in the OEM archive with '-ubuntuN' version, and then backported to bionic with '-0ubuntuN'. This essentially disables upgrades to the bionic archive version
<tjaalton> so the options are to bump the epoch (yuck), fake the upstream version somehow, or use '-ubuntuN' in the archive version too..
<tjaalton> or something else?
<tjaalton> I'm leaning towards just using NNNN+1-0ubuntuN
<tjaalton> so appending +1 to the upstream part
<tjaalton> the package is backport-iwlwifi-dkms, current version in bionic is 7906-0ubuntu4~18.04.1
<vorlon> tjaalton: bumping the upstream version seems reasonable to me
<vorlon> xnox: the answer for why the perl+glibc triggers were failing, btw, is because the perl no-change rebuild is not a correct fix for the problem and does not guarantee correct ordering on upgrade, so it's a crapshoot whether libcrypt.so.1 is actually available by the time perl starts.  Correct fix for glibc preinst uploaded.
<vorlon> xnox: so debian-installer 20101020ubuntu604, you rolled it back to the release pocket version of the kernel? because the kernel team isn't planning to migrate linux anytime soon?
<RikMills> vorlon: btw, thanks for Qt4 removal!
<vorlon> RikMills: my pleasure
<vorlon> and the fact that it waited until heimdall-flash had a new upstream version available in Debian (with a new maintainer) is surely just coincidence
<RikMills> of course ;)
<xnox> vorlon:  i agree with moving ldconfig to the top; also we had broken libxcrypt (libcrypt1) in autopkgtest VM base imaged => the one that migrated into release pocket, ended up in the autopkgtest base VM images.
<xnox> vorlon:  yes, and i further rolled back -proposed in 606
<xnox> vorlon:  thus 606 is build against src:linux-5.4 with bind9 without libcrypt1
<xnox> vorlon:  the reason being is that debian-installer is completely broken in the release pocket it is 9 abi matching src:linux, whereas the latest linux-generic abi is 14 from src:linux-5.4
<xnox> vorlon:  because the src:linux => src:linux-5.4 migrated without d-i =(
<mwhudson> xnox: is this why the d-i server CI is busted?
<mwhudson> or is that something else
<xnox> mwhudson:  yes, it boots -9 abi, tries to install -14 abi modules, which do not work.
<mwhudson> xnox: ok good
<xnox> mwhudson:  couldn't be bothered to figure out why it didn't try to install -9 abi modules, but i think this is due to provides.
<xnox> also it was making our server isos really big with two sets of udebs
<xnox> vorlon:  partially it is a problem that src:linux/release is still published in the archive, despite being "superseeded" by src:linux-5.4/release and NBS not catching that.
<vorlon> xnox: 606> oh. without 604 migrating?
<vorlon> ok
<xnox> vorlon:  yes because 606 is built in a bileto ppa, against release pocket only, with bind9/bind9-libs copied in from focal-proposed
<xnox> vorlon:  and i fucked up 605 build =)
 * xnox points at experiment 636
<xnox> vorlon:  once 606 migrates, i will upload a clean rebuild of d-i again which will hold up on both kernel being ready and libxcrypt/glibc being ready
<vorlon> k
<xnox> vorlon:  however i do wonder if i will need a frankenstein build if either kernel or libxcrypt complete first
<vorlon> why would you?
<xnox> cause i don't want to tie up linux & libxcrypt transitions together =)
<vorlon> it shouldn't tie
<xnox> 14 is quite an old kernel by now.
<xnox> a rebuild of d-i picks up libcrypt1-udeb dep
<vorlon> glibc and libxcrypt should be ready to go "soon"
<xnox> ok
 * xnox fingerscrossed
<vorlon> only one more britney cycle until glibc is built on armh
<vorlon> f
<vorlon> and then the autopkgtests should be virtually instantaneous, with no failures
 * xnox giggles
<xnox> so i do hope that d-i & bind9 migrate in two britney runs
 * xnox sleeps
#ubuntu-release 2020-03-10
<vorlon> http://autopkgtest.ubuntu.com/running#queue-huge-focal-amd64 looks good
<vorlon> interesting, I didn't realize that britney schedules autopkgtests alphabetically by architecture.  Maybe we should consider reordering that so that it schedules tests for the slowest arch first; or orders by (packagename,arch) instead of (arch,packagename).
<vorlon> otoh at this rate it should only take maybe 20 minutes to schedule all the glibc tests on amd64, so perhaps a pointless microoptimization
<mwhudson> vorlon: does it make sense to remove that perl from -proposed if it's pointless? or is it too late for that
<vorlon> mwhudson: it's burned the version number, so if there were another reason later to do a no-change rebuild of perl (between now and focal release, basically), it would cause annoying rejects for people following the normal process
<vorlon> but I've dumped the autopkgtests because I don't want the queues clogged with them right now
<vorlon> and I don't care if they get rescheduled / if this package migrates
<mwhudson> vorlon: oh right
<vorlon> so anyway, it's out of the way and we might clean it up later
<mwhudson> vorlon: yeah i was mainly thinking of the autopkgtest load
<mwhudson> but if you have other ways of getting rid of that, yay!
-queuebot:#ubuntu-release- Unapproved: sg3-utils (eoan-proposed/main) [1.44-1ubuntu1 => 1.44-1ubuntu1.1] (core)
<Eickmeyer> vorlon: I'd like to apolotize for my earlier actions. I ended up doing what you said and split that file up into separate files for each group of wallpapers. Upload is building.
<Eickmeyer> *apologize
<vorlon> Eickmeyer: glad we found a solution that worked!  I understand your frustration, and hope you feel better soon
<vorlon> bdmurray: is the apport/amd64 autopkgtest failure with glibc 2.31 familiar to you? looks like it could be a real regression but I don't know why without digging https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/a/apport/20200310_002651_7e8b1@/log.gz
<vorlon> cpaelzer: chrony autopkgtests regress with new upstream glibc because the testsuite tarball it downloads at test time from an external github url has incompatible prototyping of gettimeofday(); I'm going to badtest this rather than block glibc on it given the externality
<vorlon> tjaalton: you synced xkeyboard-config 2.29 dropping the delta for xkb-data-i18n to be a separate package, but ubiquity still build-depends on it; what's the correct solution there?
<tjaalton> vorlon: ouch.. i'll check how it's used and revive it if necessary
<vorlon> cheers
<tjaalton> and thanks for the suggestion, we'll go with bumping the upstream version on the dkms
<tjaalton> sounds like the build-dep could be dropped, it's only to make sure the translations are there so kbdnames-maker works
<vorlon> doko: why do you say that libc6 can't use a pre-depends on libcrypt1?
<vorlon> doko: glibc autopkgtests show failures on ppc64el and s390x that aren't caused by bad triggers
<cpaelzer> vorlon: thanks for the ping
<cpaelzer> vorlon: there is https://github.com/mlichvar/clknetsim/commit/6e4714b8b1730e865bf0066b898a7787e148eac9
<cpaelzer> but there were other reasons to not go forward
<cpaelzer> I'll pre-check the tests across arches and if the newer version will work I can give chrony a bump to have the tests work again
<cpaelzer> I also had https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1863590 open
<ubot5> Ubuntu bug 1863590 in chrony (Ubuntu) "Chrony test hangs with libpcap2 1:2.31-1" [Undecided,Confirmed]
<cpaelzer> need to check if bubblewrap and libcap2 migrated in the meantime
<cpaelzer> as that was what it was waiting on
<cpaelzer> ok, the old stuff is resovled - going for a test build with a fix for the chrony test ...
<cpaelzer> Hiho, it might be just a follow on to https://lists.ubuntu.com/archives/ubuntu-devel/2020-March/040939.html but plenty of builders are either "disabled" or seem stuck in "cleaning"
<cpaelzer> if someone is around who could give that a look that would be great
<cpaelzer> thanks wgrant for redirecting me here
 * cpaelzer keeps on wrongly asking in #launchpad for this, maybe because of the URL https://launchpad.net/builders ?
<cpaelzer> thanks for your patience with me wgrant
<wgrant> Hold on
<wgrant> That's not what I said :)
<wgrant> The Launchpad build farm is an Ubuntu service.
<wgrant> er
<wgrant> is a Launchpad service
<wgrant> But you linked to a thing about autopkgtest issues. Ubuntu's autopkgtest is an Ubuntu service.
<cpaelzer> too-many-moving-pieces-exception ... ok, thanks wgrant :-)
<wgrant> I'm addressing the Launchpad build farm.
<wgrant> But any Ubuntu autopkgtest issue is a) probably unrelated, and b) out of my hands.
<cpaelzer> now I see what you meant, yes that part of it is fine
<cpaelzer> build queue started to drop fast now - thanks wgrant
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.0 [amd64] (bionic-proposed/main) [5.0.0-1013.18] (no packageset)
<Mirv> archive team: could you check component mismatches, promote libenchant-2-voikko binary to main and demote enchant source+binaries to universe? it seems my seed change was enough also for the latter to pop up.
<doko> vorlon: I'm not saying it can't use it, but it will create a pre-dependency loop
<doko> vorlon: did you white list llvm-toolchain-10/i386?
<Laney> juliank: what's the tl;dr / current status on whatever happened yesterday?
<juliank> Laney: I don't think there were errors in the build for todays images, so we're good so far?
<Laney> don't plan on reading scrollback if it's all fixed
<Laney> I dunno, you were on it, just checking in :-)
<juliank> Laney: We need to remove the check in setup-testbed that prevents building images with libgcrypt1 installed once this is all working
<juliank> Laney: I'm looking at today's images now, they seem to be created
<juliank> they also do not have libcrypt1 installed
<juliank> so I'm happy
<doko> vorlon: these tests also fail on amd64. apparently not architecture specific
<Laney> juliank: good. now then, could we have stopped this bad thing from migrating?
<juliank> Laney: There seems to be a bug in britney somewhere that makes it ignore the Breaks+Replaces libcrypt1 has on libc6
<doko> Laney: the real problem was the libxcrypt imported from unstable not having tightened breaks/replaces
<Laney> doko: ok, I was wondering if something was missed
<Laney> like, no autopkgtests caught this?
<juliank> there are two problems
<doko> Laney: how? libxcrypt didn't even have autopkg tests
<juliank> libxcrypt -ubuntu1 was broken
<juliank> missing breaks/replaces
<juliank> then libxcrypt ubuntu3 made it in, despite having breaks/replaces in place that should have prevented migration; breaking debootstrap (and keeping back packages on upgrade)
<juliank> though libcrypt1 ubuntu1 was fine if you had a separate /usr
<juliank> I have it installed, and everything is fine
<doko> it was already the debian version which was broken
<juliank> because libcrypt1 installs to /usr/lib, and libc6 to /lib
<juliank> doko: but only for systems with merged user, so e.g. the buildd images don't care
<juliank> because now you had to libcrypt1, but like who cares
<doko> are you saying that the location changed?
<doko> for libcrypt.so.1?
<juliank> doko: yes
<doko> ahh
<juliank> libc6:amd64: /lib/x86_64-linux-gnu/libcrypt.so.1
<juliank> libcrypt1:amd64: /usr/lib/x86_64-linux-gnu/libcrypt.so.1
<Laney> ok, and that is the case for autopkgtest images too?
<doko> apparently not? libcrypt.so.1 was removed when libc6 was updated to 2.31
<doko> we use the merged usr as default since eoan
<Laney> hmmmmmmmmmmmmmmmmmmmmmmmmmmm
<Laney> no indeed, it's not that
<Laney> doesn't look like glibc's autopkgtests cause libcrypt1 to be installed
<Laney> libxcrypt's new tests did fail, but then I guess that wouldn't have been a regression
<doko> I added those long after it migrated
<Laney> seems like there were two migration incidents
<doko> juliank: please update the status of the testers on u-d (ML)
<Laney> or it was ubuntu3 that caused problems
<juliank> doko: oh
<Laney> meh
<Laney> none of the tests it triggered caused libcrypt1 to be installed
<Laney> don't really have a suggestion apart from figure out why it was allowed to be migrated
<LocutusOfBorg> tjaalton, can you please accept hedgewars/bionic again? https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1857363
<ubot5> Ubuntu bug 1857363 in hedgewars (Ubuntu Bionic) "update hw to 1.0" [Undecided,In progress]
<LocutusOfBorg> my ppa had backports enabled :/
<LocutusOfBorg> and debhelper12 is backports only
-queuebot:#ubuntu-release- Unapproved: hedgewars (bionic-proposed/universe) [1.0.0-4~ubuntu1.18.04.1 => 1.0.0-4~ubuntu1.18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-18.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-18.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-18.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1005.5] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-18.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1005.5] (core, kernel)
<xnox> juliank:  are our VMs broken? sudo: /tmp/autopkgtest-run-wrapper: command not found
<juliank> xnox: idk
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1build1] (core)
<ahasenack> why is debian-installer-udebs ubuntu606 depending on the 5.4.0-14 kernel instead of 5.4.0-18? It was built 14h ago
<ahasenack> focal release has 5.4.0.14.17
<ahasenack> focal proposed has 5.4.0.18.22
<ahasenack> it just missed it?
<ahasenack>   * Rebuild against release pocket only + bind9-libs.
<ahasenack>  -- Dimitri John Ledkov <xnox@ubuntu.com>  Mon, 09 Mar 2020 17:21:32 +0000
<ahasenack> xnox: ^  do you know why it's stuck now? autohinter complains about debian-installer-udebs
<ahasenack> I'd guess the old kernel
<xnox> ahasenack:  because there were more udebs missing from -proposed that were needed. hence i have rebuild 607 this morning
<xnox> so hoping 607 will migrate.....
<ahasenack> yay for 607
<xnox> doko:  do we need to rebuild gdb for glibc, or update apport gdb/glibc/abort test cases?
<doko> xnox: I don't think we did in the past. the only thing I was aware of was valgrind
<xnox> test_add_gdb_info_abort (__main__.T)
<xnox> add_gdb_info() with SIGABRT/assert() ... WARNING: Please install gdb-multiarch for processing reports from foreign architectures. Results with "gdb" will be very poor.
<xnox> WARNING: Please install gdb-multiarch for processing reports from foreign architectures. Results with "gdb" will be very poor.
<xnox> FAIL
<xnox> hm ok
<xnox> doko:  somebody will need to dig into apport test failures then
<tjaalton> LocutusOfBorg: done
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [source] (bionic-proposed) [1.0.0-4~ubuntu1.18.04.2]
<doko> bdmurray: could you have a look at the apport test failures?
<bdmurray> doko: to be clear the apport / glibc ones for Focal?
<doko> bdmurray: yes
<LocutusOfBorg> thanks
<vorlon> doko: yes, llvm-toolchain-10 is in the whitelist
<vorlon> doko: pre-dependency loop: I don't see a pre-dep loop, libcrypt1 only Depends libc6, and a pre-depends + depends is allowed (dpkg knows how to resolve this in the correct order).  Did you try this and run into problems?  Because I'm concerned that upgrade ordering could in some cases cause libc6 to still be unpacked before libcrypt1 and therefore cause libcrypt.so.1 to be missing from the system at
<vorlon> critical times
<vorlon> doko: we haven't run into this in focal yet because the set of packages we're upgrading is quite small within the devel series, but this could become a problem in dist-upgrades from bionic when apt has to calculate something more significant
<vorlon> juliank: ^^ ?
 * juliank in meeting
<doko> vorlon: see #debian-glibc. afaiu the perl (debconf) usage is optional. so maybe check if the ubuntu delta re-introduces this dependency
<vorlon> I don't see how that's relevant to any of the current problems
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-1build1]
<vorlon> doko: the Debian workaround for perl being broken at preinst time, per bug #946599, is to test whether 'perl -e ""' succeeds and if not to skip debconf.  I guess that's ok in that it makes libc6 more resilient, but it still doesn't address problems caused by unpack ordering of packages that are pre-dependencies of virtual packages
<ubot5> bug 946599 in inkscape (Ubuntu) "lindenmayer.py crashed with IOError in lxml.etree._FilelikeWriter.write (src/lxml/lxml.etree.c:92532)(): [Errno 32] Broken pipe" [Medium,Invalid] https://launchpad.net/bugs/946599
<vorlon> I think the Debian glibc package has gotten this completely wrong
<vorlon> doko: in the current implementation, there is nothing that prevents apt+dpkg from unpacking new libc6 first before libcrypt1, thus removing libcrypt.so.1 from disk; then trying to unpack and configure some other essential package which also needs upgraded; then unpacking libcrypt1.  There are some rules in apt now that make this less *likely*, but a later change in some other essential package
<vorlon> could cause this to all fall over, because the libc6+libcrypt1 relationships are not per se correct
<vorlon> juliank: ^^ if you want to sanity check me on any of this
<xnox> juliank:  vorlon: i think that libcrypt1 should conflict with older libc6 because of the undeclared file conflict between libc6 & libcrypt1. dpkg does not notice that /lib/ conflicts with /usr/lib thus old libc6 must be removed, before new libcrypt1 is unpacked.
<xnox> juergh:  vorlon: otherwise removal of old libc6 may remove the new libcrypt1's libcrypt.so.1 from disk
<juliank> hmm
<xnox> juergh:  unping
<xnox> juliank:  vorlon: i was thinking to open an RC bug against libcrypt1 in debian, if there are no conflicts there.
<juliank> So if libc6 Pre-Depends libcrypt1, doesn't that solve the issue as well?
<juliank> I prefer positive solutions over negative ones
<vorlon> xnox: but then the difficulty is that Conflicts means that libc6 MUST be unpacked before the new libcrypt1, which is the opposite of what we hope to accomplish with pre-depends
<vorlon> xnox: wouldn't it be better to change libcrypt1 to use the same path as libc6 in the package so we can rely on dpkg for this
<xnox> vorlon:  i think using the same path is better.
<juliank> libc6 Pre-Depends libcrypt1, libcrypt1 Breaks/Replaces old libc6 and change path ?
<xnox> juliank:  vorlon: the predepends & conflicts are for different libc6 versions. We conflict with old libc6, whilst only the new one predepends. imho we need both.
<juliank> New libc6 needs to p-d on libcrypt1
<juliank> libcrypt1 needs to break/replace old libc6
<xnox> breaks/replaces means that it is ok to unpack new libcrypt1 whilst the old libc6 is unpacked on disk, and I am arguing that is not true.
<juliank> it cannot conflict with old libc6
<juliank> because it does need the old libc6 unpacked
<juliank> if it conflicted, we need to unpack the new libc6 first
<vorlon> juliank: so you agree with my analysis that we should not rely, the way Debian currently does, on a depends being sufficient to ensure ordering during upgrade?
<juliank> which is a loop
<xnox> but then removal of old libc6 will remove libcrypt1's library and one is left _without_ any libcrypt.so.1 on disk?
<vorlon> and that it should be a pre-depends
<vorlon> xnox: no, because pre-depends + breaks means: deconfigure libc6; unpack libcrypt1 which takes over the files; configure libcrypt1; unpack libc6
<juliank> xnox: oh dear, that should be solved by changing the path in libcrypt1
<xnox> vorlon:  ok
<juliank> vorlon: Yes, we do want a pre-depends I think
<xnox> vorlon:  juliank: 1) change path in libcrypt1 2) have breaks+replaces in libcrypt1 (already done) 3) add predepends in the new libc6
<juliank> vorlon: I'm not 100% sure, but it seems reasonable
<xnox> agreed plan of record?
<juliank> ack
<juliank> +1
<vorlon> ok
<xnox> do we need bugs in debian about this?
<juliank> it would be nice to tell them they're wrong
<vorlon> doko: ^^ I am happy to drive the packaging changes for this; are you going to be looking into the glibc autopkgtest regressions?
<vorlon> juliank: do you want to join #debian-glibc to talk about this?  It might have more authority coming from the apt maintainer ;){
<juliank> I'm not super confident about the pre-depends thing that I could argue why it's the right thing to do
<juliank> It just feels like the right thing to do
<xnox> juliank:  predepends is the right thing, because libc6 preinst uses libcrypt.so.1 via perl/debconf
<juliank> ack
<xnox> juliank:  thus preinst expects to have a working perl / libcrypt / libc6
<juliank> I concur
<vorlon> right, but Debian has worked around that specific thing by making a perl failure non-fatal
<vorlon> my concern is unpack ordering of other packages within the Essential closure
<juliank> right
<vorlon> like, what else could require perl-base, between the time libc6 is unpacked and libcrypt1 is unpacked
<juliank> If you have an essential package that needs libcrypt, what happens?
<vorlon> yes, perl-base is such an essential package
<vorlon> which, the no-change rebuild of perl has added a pre-depends, but that doesn't change the fact that something might try to use perl before the new version has been unpacked
<vorlon> doko: https://wiki.ubuntu.com/DebianMaintainerField :P
<xnox> vorlon:  i wonder if we should have done switch to libxcrypt separate from upgrade to 2.31
<xnox> too late now
<vorlon> xnox: if you mean switching to libxcrypt /before/ upgrading to 2.31, that sounds like it might've been useful, but yeah obviously didn't happen
<vorlon> AIUI we can't defer it /beyond/ 2.31
<xnox> vorlon:  yeah that. cause we could have done the libxcrypt migration whilst 2.31 was not available yet.
<xnox> anyway, next time.
<vorlon> seb128: seems the Ubuntu focal daily ISO is over the new size limit again
<bdmurray> doko: I uploaded a new version of apport a bit ago
<seb128> vorlon, can you remind me where is the limit defined? also that's a discussion we are having with Wimpress this week in the context of langpacks to include so hopefully we have a decision then and can put a limit without having to keep revisiting
<vorlon> seb128: buried in the ubuntu-cdimage tree.py code
<seb128> k :)
<vorlon> size_limit()
<seb128> thanks for the pointer
<vorlon> Laney: the DNS failure rate on the armhf container runners is still non-zero and annoying.  did you have any more ideas on where to go with that?
<vorlon>         for so in $(DD)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so; do \
<vorlon>                 ln -sf /lib/$(DEB_HOST_MULTIARCH)/$$(basename $$(readlink -f $$s
<vorlon> o)) \
<vorlon> xnox: ^^ you're welcome
<vorlon>                         $$so; \
<Laney> vorlon: not really, perhaps we want to loop in someone from the lxd team?
<vorlon>         done
<vorlon> I thought we had already implemented their recommendations
<vorlon> but yeah, probably so
<Laney> yes
<Laney> but kind of abstractly / remotely
<Laney> rather than here's access, go have a good time with it
<Laney> I see that one person from this team already has the requisite access :>
<vorlon> what the heck, why was http://autopkgtest.ubuntu.com/packages/l/linuxinfo/focal/amd64 triggered with all-proposed=1
<Laney> lol
<Laney> I can guess
<vorlon> ?
<vorlon> because it matches the 'linux' regexp?
<vorlon> :/
<Laney> https://git.launchpad.net/autopkgtest-cloud/tree/worker/worker#n427
<Laney> linuxyolo
<vorlon> doko, xnox: libxcrypt 1:4.4.10-10ubuntu4 uploaded, this moves the library from /usr/lib to /lib from dpkg's perspective which will cause Replaces: to actually DTRT in the dpkg database
<vorlon> doko: I'm happy to finagle the pre-depends from glibc, but I don't want to reupload until we have a plan for the regressed autopkgtests
<vorlon> autopkgtest [14:32:18]: test run-unit-test: [-----------------------
<vorlon> Your machine does not support AVX2.
<vorlon> Please compile with SSE4.1 cmake -DHAVE_SSE4_1=1
<vorlon> autopkgtest [14:32:18]: test run-unit-test: -----------------------]
<vorlon> ....
<vorlon> how did this pass once
<xnox> vorlon:  we happened to run the test before on a Nova host node that did have avx2
<vorlon> I thought there was no avx2 in scalingstack for the foreseeable future
<vorlon> :/
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.0 [amd64] (bionic-proposed) [5.0.0-1013.18]
<cjwatson> vorlon: more no guaranteed avx2, I think
<vorlon> k
<cjwatson> We still have some Sandy Bridge in service for instance, which lacks AVX2; but we also have some things like Epycs
<wgrant> Right. Scalingstack isn't designed to support live migration, and the available hardware changes, so the available instruction set extensions varies
<apw> wgrant, do we not lie to the instances with a common possible subset?
<wgrant> apw: we could, but the CPUs range in age by eight years so it would be a bit unfortunate
<LocutusOfBorg> vorlon, would you mind kicking the can on gnupg2/i386 hint=
<LocutusOfBorg> please?
<LocutusOfBorg> also gpgme1.0
<doko> vorlon: I'll look at these tomorrow, they are common across all archs
<vorlon> xnox: you retried the rtags test with a non-obvious trigger and it passed once and failed once.  Do you have any insight or is this just a flaky test that needs the button to be hammered?
<vorlon> LocutusOfBorg: the expectation is that people who upload packages that have had one-time hints added for i386 will deal with these regressions as part of their upload, not kick the can
<vorlon> LocutusOfBorg: so unless you tell me that these autopkgtests can never work on i386, please fix them instead
<vorlon> E: Essential packages were removed and -y was used without --allow-remove-essential.
<vorlon> LocutusOfBorg: ^^ so that's the answer for gnupg, certainly that should be made an unversioned hint for i386
<vorlon> oh, or should that be diffutils:any
<vorlon> or, you know, should we just not be pointlessly declaring a test dep on an essential package
<vorlon> gnupg2 uploaded
<LocutusOfBorg> thanks vorlon I tried to fix before asking
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1035.39] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1035.39]
-queuebot:#ubuntu-release- Unapproved: sg3-utils (bionic-proposed/main) [1.42-2ubuntu1.18.04.1 => 1.42-2ubuntu1.18.04.2] (core)
#ubuntu-release 2020-03-11
<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
<ubot5> sourceware.org bug 25652 in build "testroot.pristine misses /lib64/ld-linux-x86-64.so.2" [Normal,Unconfirmed]
<mwhudson> (i think this one gets filed under "shell is bad")
<sarnold> so bad
<mwhudson> i assume https://sourceware.org/git/?p=glibc.git;a=commit;h=7db1fe38de21831d53ceab9ae83493d8d1aec601 is to blame without any particular evidence
<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?
<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')
<vorlon> doko, xnox: soooo libxcrypt doesn't build multilib variants
<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 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/d/dbus-glib/20200310_223456_7d94d@/log.gz
<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
<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
<mvo> rbasak: hey, do you think you could have a look at the SRU of snapd in unapproved?
<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?
<doko> I've been working on the regressions triggered by glibc yesterday. will continue today
<doko> vorlon, xnox: multilib, are you worried that we don't drop the glibc crypt code for the multilib variants?
<doko> given back dbus-glib with the glibc trigger
<doko> vorlon: please ignore the gcc-arm-none-eabi/i386 test failure
<doko> and the force-reset-test binutils-arm-none-eabi/13 hint can be removed, fixed
<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
<tjaalton> also spirv-tools should be removed
<tjaalton> from s390x..
<seb128> tjaalton,
<seb128> $ reverse-depends -b glslang-dev
<seb128> Reverse-Build-Depends
<seb128> =====================
<seb128> * libplacebo
<seb128> * renderdoc
<seb128> * vulkan-validationlayers
<seb128> tjaalton, the first and third build on s390x
<seb128> tjaalton, also https://paste.ubuntu.com/p/62n3D4vPDQ/ for tools
<tjaalton> seb128: remove those too
<tjaalton> I'll fix mesa
<tjaalton> vulkan-* are in proposed
<tjaalton> meh
<tjaalton> or just ignore that it's broken are restore the build.. dunno
<seb128> I would rather do that...
<seb128> in any case for removal I think a bug would be best since it's not trivial
<tjaalton> right
-queuebot:#ubuntu-release- Unapproved: xf86-input-wacom (bionic-proposed/main) [1:0.36.1-0ubuntu1 => 1:0.36.1-0ubuntu1.1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (eoan-proposed/main) [0.8.1-1ubuntu14.3 => 0.8.1-1ubuntu14.4] (core)
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.24]
-queuebot:#ubuntu-release- Unapproved: rejected lz4 [source] (xenial-proposed) [0.0~r131-2ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: rejected lz4 [source] (bionic-proposed) [0.0~r131-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (xenial-proposed) [9.5.21-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted quassel [source] (xenial-proposed) [0.12.2-0ubuntu1.16.04.1]
<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
<ubot5> Debian bug 953408 in ftp.debian.org "RM: coq [armel armhf i386 mipsel mips64el s390x] -- ROM; FTBFS (mostly on 32bit architectures, or where ocaml has only a bytecode compiler)" [Normal,Open]
<LocutusOfBorg> the list and reverse-deps is on that bug, basically coq armhf i386 s390x, with also prooftree why3 and libaac-tactics-ocaml
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1035.38~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1035.38~16.04.1]
-queuebot:#ubuntu-release- Unapproved: drbd-utils (bionic-proposed/main) [8.9.10-2 => 8.9.10-2ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.30]
-queuebot:#ubuntu-release- Unapproved: accepted sg3-utils [source] (bionic-proposed) [1.42-2ubuntu1.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted sg3-utils [source] (eoan-proposed) [1.44-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20200211.1-0ubuntu0.18.04.1 => 1:20200311.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20200211.1-0ubuntu0.16.04.1 => 1:20200311.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20200211.1-0ubuntu0.19.10.1 => 1:20200311.1-0ubuntu0.19.10.1] (no packageset)
<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
<vorlon> doko: gcc-arm-none-eabi, I'll have a look
<vorlon> doko: gcc-arm-none-eabi/i386 hinted, thanks
<doko> vorlon: before you upload glibc, I'm testing a fix for 1861353
<vorlon> doko: ok
-queuebot:#ubuntu-release- Packageset: Added wpebackend-fdo to i386-whitelist in focal
<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
<doko> no, I gave back now gnudatalanguage with empty test queues. let see if that helps
<doko> yes, but the only tests ignored for arm were the soft-float tests
-queuebot:#ubuntu-release- Packageset: Added mozjs68 to i386-whitelist in focal
<doko> vorlon, xnox: LP: #1861353 has a patch
<ubot5> Launchpad bug 1861353 in glibc (Ubuntu Focal) "libc6-dev:amd64 is not co-installable with libc6-dev:s390x" [Undecided,New] https://launchpad.net/bugs/1861353
<xnox> doko:  looks good, i'm not sure if we want current glibc to migrate or upload again?!
<doko> steve wants to upload afaik
<vorlon> xnox: upload again, getting the pre-depends, the autopkgtest fix, and the multiarch fix
<vorlon> xnox: but I am still looking to bottom out on the remaining revdep autopkgtest regressions
<vorlon> xnox: and when I upload -0ubuntu4 I will flush the irrelevant re-tests
<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
<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
<xnox> any idea why build-logs are not getting updated?
<vorlon> no idea, but looking
<vorlon> xnox: because someone landed a move from python2 to python3 and mirror-image-build-logs is not python3-clean
<vorlon> ;)
<vorlon> (and not covered by unit tests)
<vorlon> xnox: doing a one-off run under python2 now
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu22 => 2.04-1ubuntu22] (core)
<vorlon> xnox: and fixed
<cjwatson> universal_newlines=True and str would be better style, but OK :)
<cjwatson> (IMO anyway, not that it matters much)
<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
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu22 => 2.04-1ubuntu22] (core)
-queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.6-1ubuntu0.16.04.4 => 3.9-1ubuntu0.16.04.1] (ubuntu-desktop, ubuntu-server)
<vorlon> glibc uploaded
<vorlon> (a half hour ago)
<vorlon> if we can figure out what's up with those remaining arm failures and let this in, great
<vorlon> if not and we have to reupload, not much time wasted
<vorlon> (after jettisoning the autopkgtest queues)
<doko> if it's build, please retrigger libseccomp with the one from -proposed
<doko> built even
<doko> vorlon: the arm64 autopkg tests triggered by perl don't seem to make any progress
<vorlon> doko: why do you expect a different result for a libseccomp retrigger?
<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.
<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
<kanashiro> hi, I am investigating the gem2deb/1.0.5 autopkgtest failure on armhf and it is complaining (reprotest actually) about the kernel version: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/g/gem2deb/20200311_020802_c6e4e@/log.gz
<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
<kanashiro> is linux 4.15.0 expected in an ubuntu focal testbed?
<mwhudson> is glibc/yt/arm64 ooming?
<mwhudson> would it make sense for autopkgtest artifacts to include syslog
<vorlon> kanashiro: yes, because the armhf autopkgtest runners are containers, running on an LTS host
<vorlon> complaining about the kernel version: that sounds like a wrong test
<vorlon> no userspace packages in focal should fail with the bionic kernel
<vorlon> so a wrong test or a right test exposing wrong code
<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
<vorlon> but we could try adding it to the 'huge' config and see if that fixes it?
<mwhudson> vorlon: seems worth a shot
<mwhudson> vorlon: er i think yt _does_ oom on other arches
<mwhudson> is it badtested?
<mwhudson> eg https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/y/yt/20200310_112622_9fadd@/log.gz
<mwhudson> ubuntu-release:force-reset-test yt/3.5.1-3/amd64
<mwhudson> that version has passed though, so i don't know why it's marked "always failed" in excuses
<mwhudson> ANYWAY i need to get on the bus
<kanashiro> vorlon, ack, I'll see what I can do about it
<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 :)
<vorlon> LocutusOfBorg: ok
<vorlon> mwhudson: yt passed on armhf and on s390x; armhf would not have the memory limit, but s390x would
-queuebot:#ubuntu-release- Unapproved: util-linux (bionic-proposed/main) [2.31.1-0.4ubuntu3.5 => 2.31.1-0.4ubuntu3.6] (core)
-queuebot:#ubuntu-release- Unapproved: util-linux (eoan-proposed/main) [2.34-0.1ubuntu2.3 => 2.34-0.1ubuntu2.4] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.14 => 2.02-2ubuntu8.15] (core)
<LocutusOfBorg> vorlon, any idea? https://launchpad.net/ubuntu/+source/puma/3.12.4-1ubuntu2/+build/18828540
<LocutusOfBorg> chroot problem due to glibc?
<LocutusOfBorg> same arm64 ppc64el s390x
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.15 => 1.93.15ubuntu1] (core)
<xnox> Fetched 69.0 MB in 1s (81.4 MB/s)
<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.
<xnox> E: Internal Error, Could not early remove libc6:ppc64el (2)
<xnox> doko:  vorlon: juliank: ^
<mwhudson> vorlon: yeah, not saying it makes sense
<juliank> xnox: weeeeeeeeeee
<juliank> xnox: Did we add libc6 pre-depends libcrypt1?
<juliank> and is that the result?
<mwhudson> y
<mwhudson> at least that's what the .changes said
<juliank> ok I guess we gotta revert
<mwhudson> yay another glibc upload?
<juliank> wondering why that happens
<juliank> exactly, another glibc upload
<juliank> Or figuring out the other side of the loop and removing that if possible
<juliank> but meh
<juliank> idk
<juliank> I suggested removing the libc6 depends from libcrypt1
<mwhudson> it's going to take an aa to remove glibc from proposed before anything can build now isn't it?
<mwhudson> ubuntu-archive: halp
<LocutusOfBorg> yes ^^ doko
<xnox> wgrant:  are you up already?
<xnox> wgrant:  rm glibc from focal-proposed
<xnox> wgrant:  and copy in the previous one?
<vorlon> xnox: context?
<xnox> vorlon:  see highlight above
<xnox> vorlon:  cannot install libc6
<vorlon> xnox: yes, where is that quoted from? an autopkgtest log, a build log?
<juliank> Build log
<mwhudson> https://launchpad.net/ubuntu/+source/puma/3.12.4-1ubuntu2/+build/18828540
<vorlon> also why does it say conflicts when there are not
<vorlon> ah
<juliank> Meh who says messages are accurate anyway
<vorlon> >_<
<mwhudson> https://launchpad.net/ubuntu/+builds?build_text=&build_state=all
 * wgrant isn't quite awake yet
<mwhudson> (from which we can see the order the various architectures got published in)
<vorlon> ok, removing
<vorlon> xnox, juliank: is the Breaks: strictly required?  should it be only Replaces: instead? then there would be no loop
<juliank> we don't know
<juliank> I guess
<juliank> you probably need it for partial upgrades, but we don't support those
<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
<vorlon> however that seems unlikely here
<vorlon> and I don't see any other reason to need it
<juliank> you just can't have libcrypt1 migrated before libc6
<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
<vorlon> m
<vorlon> or if we would prefer dropping the Pre-Depends: and leaving open the possibility of wrong ordering on upgrade
<xnox> vorlon:  libcrypt1 is priority required, thus i don't think one can "simply" remove it?
<juliank> apt doesnt care
<juliank> apt only cares about essential / xb-important
<xnox> i thought apt wants one to type "Do as i say"
<xnox> hm
<xnox> is libcrypt1 essential yet?
<vorlon> no, and runtime libraries never are
<mwhudson> presumably removing a dependency of essential: yes is non-trivial?
<vorlon> they're only "virtually essential"
<juliank> well from apt's side it is essential once libc6 depends on it
<vorlon> mwhudson: correct, but that only helps you /after/ you've upgraded libc
<juliank> apt's understanding of essential is transitive
<juliank> :D
<vorlon> if you shoot yourself in the foot by installing and removing libcrypt without upgrading libc, it doesn't protect you
<xnox> yeah, cause i don't see essential set on libc6 itself
<juliank> heh just mark it xb-important: yes :D
<mwhudson> vorlon: if the libc on disk doesn't depend on libcrypt1 how does that matter? or is this about what happens during upgrades?
<vorlon> mwhudson: it's the fact that it's taking over files that previously belonged to libc
<juliank> then remove the bit in focal+1
<vorlon> that's why we want the pre-depends in the first place
<mwhudson> ah
<xnox> mwhudson:  we are splitting libc6 into libc6 & libcrypt1, with libcrypt1 taking over file from libc6
<xnox> on upgrade
<xnox> we got it a bit wrong 3 times now =)
<mwhudson> xnox: i think i had missed the fact that libcrypt1.so was already on disk
<xnox> mwhudson:  right, it used to be provided by glibc (they had their own implementation) but libxcrypt implementation is better
<mwhudson> yeah i get all that, but i didn't realize the soname was the same
<xnox> vorlon:  juliank: can we just use tarball component of libxcrypt and build it as part of glibc source build and avoid this mess? =)
<juliank> should have just added libxcrypt to glibc source package as extra tarball and called it ad ay
<xnox> or like Built-Using, and make libc6 copy-in and ship libxcrypt's libcrypt1 =)
<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
<xnox> riht
<juliank> I'd kind of prefer us to have the same issues debian has over making up our own ones
<xnox> and we thought we needed predepends, whilst autopkgtest VMs, had wrong version strings in breaks/replaces which were incorrect for ubuntu
<xnox> and it migrated by accident
<juliank> hence I was slightly surprised that we did the pre-depends upload after all
<juliank> but then I don't have a straight view of the timeline
<juliank> and I'm not exactly fully conscious at the moment
<mwhudson> vorlon: so without breaks the failure mode is something like:
<mwhudson> person running eoan updates apt sources to focal
<mwhudson> they upgrade libcrypt1 only from focal
<mwhudson> then apt remove libcrypt1 will not complain but also will break their system
<juliank> right, or focal to focal more likely
<juliank> we'vce got a ton of people on there now
<mwhudson> making the version of libcrypt1 in focal un-removable would be a bit of a hack but close this hole
<vorlon> right
<mwhudson> i.e. essential: yes or whatever xb-important is :)
<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
<mwhudson> juliank: does debian have an actual plan here?
<juliank> mwhudson: debian thinks they're approach is fine
<mwhudson> because i was wondering if debian is watching our flailing here
<mwhudson> juliank: which is?
<juliank> mwhudson: oh we told them
<juliank> mwhudson: libcrypt1 breaks/replaces old libc6, libc6 depends on libcrypt1, perl preinst gets changed to ignore libcrypt1 loading error IIRC
<juliank> i.e. sdome debconf questions were made optional
<mwhudson> uh huh ok
<juliank> The assumption is that it's highly unlikely that they'll end up in a broken situation
<juliank> because you know, apt will configure libc6 immediately anyway
<juliank> there's no real difference to a pre-depends _in practice_
<juliank> but it avoids having to break the loop which apt barfso n
<juliank> but anyway I'm too tired to think much
<mwhudson> i am conscious that i've never really understood this end of things
<juliank> I might understand it if I was actually awake
<xnox> i am confused why libcrypt1 doesn't have Depends libc6 >= 2.31
<xnox> Depends: libc6 (>= 2.25)
<xnox> Breaks: libc6 (<< 2.31)
<xnox> Replaces: libc6 (<< 2.31)
<xnox> is bogus
<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?
<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
<juliank> AFAIUI
<juliank> don't trust a sleepy juliank
<vorlon> hmm
<juliank> xnox: makes no difference
<vorlon> does immediately-configured imply one at a time?
<juliank> i think so
 * xnox goes to watch the latest episode of "keeping up with coronavirus"
<juliank> xnox: Depends and Breaks both other the same thing in practice
<xnox> hm i wonder if predepends is impossible
<xnox> because we cannot configure libcrypt1, only unpack it?!
<juliank> that is correct, there is a loop with Pre-Depends
<vorlon> dpkg will break a pre-depends/depends cycle
<vorlon> it will configure it despite the dep being unsatisfied
<juliank> dpkg's loop breaking might be irrelevant in essential
<juliank> because apt will break the loop itself, or try to and fail
<juliank> because the whole immediate configure thing
<juliank> E: This installation run will require temporarily removing the essential package libc6:ppc64el due to a Conflicts/Pre-Depends loop
<juliank> I think that's the reason it says that
<juliank> A {Pre-,}Depends-Unpacked would solve such issues and simplify a lot of stuff
<vorlon> juliank: does apt not implement the same loop-breaking logic as dpkg then, regarding pre-depends+depends loops?
<juliank> vorlon: i don't know
<vorlon> so I could test this
<vorlon> by uploading libxcrypt, dropping the Breaks
<vorlon> and reviving glibc
<vorlon> and seeing what happens
<juliank> sure
<juliank> in any case, I'll try to get some sleep, maybe I get lucky
<juliank> a good night's sleep is about the same level of difficulty as this library split
<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. ?
<mwhudson> ahasenack: yes
 * doko hates debugging broken autopkg tests
<vorlon> juliank, xnox, mwhudson: libxcrypt without Breaks: unblocks us, so I'd like to proceed from here
<mwhudson> vorlon: yay
<mwhudson> vorlon: is britney going to try to schedule <austin-powers>1 million</austin-powers> autopkgtests again?
<vorlon> yes
<vorlon> and then I'm going to murder them all
<vorlon> and manually reschedule the ones we want
<mwhudson> vorlon: and did you think at all about ways to cheat and make libcrypt1 unremovable?
<mwhudson> (seems low priority though)
<vorlon> mwhudson: no; I think that particular corner case is unlikely
<mwhudson> https://launchpad.net/ubuntu/+builds?build_text=&build_state=chrootwait <- i guess i'll retry the ones of these from today
<mwhudson> unless chroot problems get autoretried somehow?
<vorlon> mwhudson: they don't afaik
<mwhudson> hm wait someone already did this?
<mwhudson> https://launchpad.net/ubuntu/+source/puma/3.12.4-1ubuntu2/+build/18828540 is successful now
<vorlon> yeah it was really only puma that landed in the window afaik
<mwhudson> vorlon: or did you retry some to test things were ok?
<vorlon> and I retried them thinking it would be a test case
<vorlon> and they built with glibc 2.30 instead
<vorlon> so that was a fail :P
<mwhudson> ha
 * mwhudson retries the others
<tumbleweed>  /32
<tumbleweed> grr
<mwhudson> ok they all built now
<mwhudson> well bar one but that'll be fine i'm sure
-queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (bionic-proposed/universe) [0.164 => 0.175~18.04.1] (no packageset)
#ubuntu-release 2020-03-12
<foka> Hello!  I would like to request FFe to sync some packages from Debian, the first set being libsass from 3.5.5-4 to 3.6.3-1 and subsequently sassc, ruby-sassc, libsass-python and node-node-sass.
<foka> My question is: should I file one single Launchpad [FFe] bug for libsass and friends, or should I file one bug for each single package?  Many thanks!
-queuebot:#ubuntu-release- Packageset: Added libwpe to i386-whitelist in focal
<vorlon> doko: libseccomp in -proposed still fails on armhf with glibc 2.31
<sforshee> doko: bug 1866882 is causing problems for our linux autopkgtests on s390
<ubot5> bug 1866882 in llvm-toolchain-10 (Ubuntu) "segfault in libllvm-10 when building kernel bpf selftests on s390" [Undecided,New] https://launchpad.net/bugs/1866882
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu22]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu22]
<vorlon> juliank: hey, so it seems all the i386 autopkgtests fail because apt refuses to install the /cross/ libcrypt1:i386 on a system where libc6 is not yet unpacked and therefore bails.  I guess that means we do after all need a glibc without pre-depends, and can keep the libcrypt1 with Breaks
-queuebot:#ubuntu-release- New sync: pg-fact-loader (focal-proposed/primary) [1.5.2-2]
-queuebot:#ubuntu-release- New sync: pglogical (focal-proposed/primary) [2.3.0-1]
<vorlon> so, glibc 2.31-0ubuntu5 uploaded; I will not be around to flush the autopkgtest queues
<vorlon> Laney, juliank: once these glibc-triggered autopkgtests start getting scheduled, could you please dump them from the queue?
-queuebot:#ubuntu-release- New sync: libxcrypt (focal-proposed/primary) [1:4.4.10-10ubuntu4]
-queuebot:#ubuntu-release- New: accepted libxcrypt [sync] (focal-proposed) [1:4.4.10-10ubuntu4]
<vorlon> the libseccomp failures are because glibc is starting to use clock_gettime64() on armhf
<doko> Fetched 60.9 MB in 2s (30.9 MB/s)
<doko> E: This installation run will require temporarily removing the essential package libc6:arm64 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.
<doko> E: Internal Error, Could not early remove libc6:arm64 (2)
<vorlon> doko: source?
<doko> https://launchpadlibrarian.net/468751924/buildlog_ubuntu-focal-arm64.postgresql-12_12.2-1ubuntu1_BUILDING.txt.gz
<doko> just trying to give back a failed build
<vorlon> doko: oh. it's because I republished libxcrypt with the Breaks: readded, but glibc is still building.  this will resolve itself once https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu5 is built and published everywhere.
<doko> ahh, ok
<vorlon> and clock_gettime64 isn't enough to get libseccomp passing, bah
<vorlon> (fixes some tests but not all)
<vorlon> oh, it does fix it, I just didn't correctly add it everywhere
<cpaelzer> Hi,
<cpaelzer> oh - premature enter :-/
<cpaelzer> Hi, I'm about to bring back some packages that got removed by bug 1862601 that have since then grown compatibility for postgresql-12
<ubot5> bug 1862601 in postgresql-11 (Ubuntu) "[Remove] Please remove postgresql-11 from Focal" [High,Fix released] https://launchpad.net/bugs/1862601
<cpaelzer> since that alway means they add -12- in the name they have hit new queue
<cpaelzer> I'd appreaciate is someone could accept pglogical and pg-fact-loader from the new queue
<cpaelzer> once pglogical is in propsoed there will be another (dependent one) coming as well
<doko> sforshee: could you point me to a test case?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/borgbackup/1.1.11-1/+build/18830373
<LocutusOfBorg> looks like armhf is still chroot sad?
<LocutusOfBorg> also somewhere else https://launchpad.net/ubuntu/+source/libpam-alreadyloggedin/0.3-8 https://launchpad.net/ubuntu/+source/libseccomp/2.4.3-0ubuntu2 https://launchpad.net/ubuntu/+source/postgresql-12/12.2-1ubuntu1
<doko> see backlog
-queuebot:#ubuntu-release- Unapproved: quassel (xenial-proposed/universe) [0.12.2-0ubuntu1.16.04.1 => 0.12.2-0ubuntu1.16.04.2] (no packageset)
<LocutusOfBorg> rbasak, you there? I did reupload quassel, with two upstream patches to fix a build failure ^^ can you please accept this one?
 * rbasak looks
-queuebot:#ubuntu-release- New: accepted kipi-plugins [sync] (focal-proposed) [4:19.12.3-1]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [sync] (focal-proposed) [1.5.2-2]
-queuebot:#ubuntu-release- New: accepted ruby-factory-bot-rails [sync] (focal-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New: accepted morris [sync] (focal-proposed) [0.2-6]
-queuebot:#ubuntu-release- New: accepted pglogical [sync] (focal-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New binary: pg-fact-loader [amd64] (focal-proposed/universe) [1.5.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [s390x] (focal-proposed/universe) [1.5.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-factory-bot-rails [amd64] (focal-proposed/universe) [5.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [ppc64el] (focal-proposed/universe) [1.5.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [s390x] (focal-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morris [ppc64el] (focal-proposed/universe) [0.2-6] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [amd64] (focal-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morris [s390x] (focal-proposed/universe) [0.2-6] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [ppc64el] (focal-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kipi-plugins [s390x] (focal-proposed/universe) [4:19.12.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [arm64] (focal-proposed/universe) [1.5.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [armhf] (focal-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morris [amd64] (focal-proposed/universe) [0.2-6] (no packageset)
-queuebot:#ubuntu-release- New binary: pg-fact-loader [armhf] (focal-proposed/universe) [1.5.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: morris [armhf] (focal-proposed/universe) [0.2-6] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical [arm64] (focal-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kipi-plugins [amd64] (focal-proposed/universe) [4:19.12.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: morris [arm64] (focal-proposed/universe) [0.2-6] (no packageset)
-queuebot:#ubuntu-release- New binary: kipi-plugins [ppc64el] (focal-proposed/universe) [4:19.12.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted morris [amd64] (focal-proposed) [0.2-6]
-queuebot:#ubuntu-release- New: accepted morris [armhf] (focal-proposed) [0.2-6]
-queuebot:#ubuntu-release- New: accepted morris [s390x] (focal-proposed) [0.2-6]
-queuebot:#ubuntu-release- New: accepted morris [arm64] (focal-proposed) [0.2-6]
-queuebot:#ubuntu-release- New: accepted morris [ppc64el] (focal-proposed) [0.2-6]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [amd64] (focal-proposed) [1.5.2-2]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [armhf] (focal-proposed) [1.5.2-2]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [s390x] (focal-proposed) [1.5.2-2]
-queuebot:#ubuntu-release- New: accepted pglogical [arm64] (focal-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical [ppc64el] (focal-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-factory-bot-rails [amd64] (focal-proposed) [5.1.1-2]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [arm64] (focal-proposed) [1.5.2-2]
-queuebot:#ubuntu-release- New: accepted pglogical [amd64] (focal-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted pglogical [s390x] (focal-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted pg-fact-loader [ppc64el] (focal-proposed) [1.5.2-2]
-queuebot:#ubuntu-release- New: accepted pglogical [armhf] (focal-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New binary: kipi-plugins [arm64] (focal-proposed/universe) [4:19.12.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kipi-plugins [armhf] (focal-proposed/universe) [4:19.12.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted kipi-plugins [amd64] (focal-proposed) [4:19.12.3-1]
-queuebot:#ubuntu-release- New: accepted kipi-plugins [armhf] (focal-proposed) [4:19.12.3-1]
-queuebot:#ubuntu-release- New: accepted kipi-plugins [s390x] (focal-proposed) [4:19.12.3-1]
-queuebot:#ubuntu-release- New: accepted kipi-plugins [arm64] (focal-proposed) [4:19.12.3-1]
-queuebot:#ubuntu-release- New: accepted kipi-plugins [ppc64el] (focal-proposed) [4:19.12.3-1]
-queuebot:#ubuntu-release- New binary: foxtrotgps [s390x] (focal-proposed/universe) [1.2.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: foxtrotgps [amd64] (focal-proposed/universe) [1.2.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: foxtrotgps [ppc64el] (focal-proposed/universe) [1.2.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: foxtrotgps [arm64] (focal-proposed/universe) [1.2.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: foxtrotgps [armhf] (focal-proposed/universe) [1.2.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted quassel [source] (xenial-proposed) [0.12.2-0ubuntu1.16.04.2]
<LocutusOfBorg> vorlon, can we please get an hint on 32bit gpgme1.0 architectures? there is a new test "checky2106" that fails if long is 32bit...
<LocutusOfBorg> it is related to signatures not being valid after 2106 https://dev.gnupg.org/T4766 and honestly, I don't plan to be around on that date
-queuebot:#ubuntu-release- New sync: pglogical-ticker (focal-proposed/primary) [1.4.0-2]
<Laney> looks like those glibc tests are scheduled there, guess I should kill them off ?
<Laney> I'm not sure what the plan / idea was there but I'll do it ...
<juliank> Laney: oh yes, they weren't last time I looked
 * Laney is zapping
<Laney> this is just going to get hinted through or what?
<juliank> Laney: vorlon wants to start the interesting ones or something
<mfo> sil2100, hey o/  if you have a chance, could you please review util-linux in e/b upload queue?  just fyi, this is _not_ urgent afaik, so it can wait if timing is not good today. :)  thanks!
<sforshee> doko: added instructions to reproduce to the bug
<bluca> hello release team - any chance https://bugs.launchpad.net/ubuntu/+source/azure-cli/+bug/1866612 could be considered for Focal, please? It just needs 2 syncs from sid - thanks!
<ubot5> Ubuntu bug 1866612 in azure-cli (Ubuntu) "Wrong dependency javaproperties -> pyjavaproperties" [Undecided,New]
<sil2100> mfo: hey! I'll see about that, will put it on my TODO list for today :)
<mfo> sil2100, alright, thank you!
<cpaelzer> hiho ubuntu-archive people, could someone accept pglogical-ticker from the new queue
<cpaelzer> this is another one beign removed for https://bugs.launchpad.net/ubuntu/+source/pglogical/+bug/1862601
<ubot5> Ubuntu bug 1862601 in postgresql-11 (Ubuntu) "[Remove] Please remove postgresql-11 from Focal" [High,Fix released]
<cpaelzer> but now with PG-12 support coming back
<cpaelzer> This overall effort will also eventually need someone from the release Team to ack and merge https://code.launchpad.net/~paelzer/britney/hints-ubuntu-focal-pglogical-back/+merge/380613
<cpaelzer> if someone is around that would be great
<cpaelzer> ahasenack: ^^ FYI this is ongoing all day, you might have seen the trello updates already
<ahasenack> cpaelzer: I saw you synced, but don't know yet what happened to the tests in the bileto ticket, given the chroot breakage from last night
<cpaelzer> that is fine, all that were expected to run were good
<cpaelzer> some others were "always failed" anyway
<cpaelzer> and the MP above for pglogical will reset for that one
<cpaelzer> it effectively also is an always failed, I'm just bringing back the old rule that was cleaned up
<sil2100> cpaelzer: hey! I will try to get to it today, but I wouldn't mind if someone gets to it before me ;)
-queuebot:#ubuntu-release- New: accepted foxtrotgps [amd64] (focal-proposed) [1.2.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted foxtrotgps [armhf] (focal-proposed) [1.2.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted foxtrotgps [s390x] (focal-proposed) [1.2.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted foxtrotgps [arm64] (focal-proposed) [1.2.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [sync] (focal-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted foxtrotgps [ppc64el] (focal-proposed) [1.2.2-2ubuntu1]
-queuebot:#ubuntu-release- New binary: pglogical-ticker [arm64] (focal-proposed/none) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical-ticker [ppc64el] (focal-proposed/none) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical-ticker [armhf] (focal-proposed/none) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pglogical-ticker [s390x] (focal-proposed/none) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.9-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New sync: javaproperties (focal-proposed/primary) [0.6.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20200311.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20200311.1-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20200311.1-0ubuntu0.16.04.1]
<cpaelzer> thanks sil2100
<cpaelzer> also still looking for an ubuntu-archive person to accept pglogical-ticker
<cpaelzer> and in the meantime the new queue also has javaproperties for bug 1866612
<ubot5> bug 1866612 in azure-cli (Ubuntu) "Wrong dependency javaproperties -> pyjavaproperties" [Undecided,In progress] https://launchpad.net/bugs/1866612
<cpaelzer> which needs ubuntu-archive attention as well to pass
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [arm64] (focal-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [ppc64el] (focal-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [armhf] (focal-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [s390x] (focal-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New binary: pglogical-ticker [amd64] (focal-proposed/universe) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (eoan-proposed) [2.34-0.1ubuntu2.4]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (bionic-proposed) [2.31.1-0.4ubuntu3.6]
<vorlon> LocutusOfBorg: gpgme1.0 hint - no, a regression in proposed of the autopkgtests for a package in main needs to be fixed, not hinted
<vorlon> LocutusOfBorg: the test should obviously be skipped on archs with 32-bit time_t
<LocutusOfBorg> vorlon, do you have an idea for i386 build failure? there is some usual uninstallability, I would like to fix it if possible
-queuebot:#ubuntu-release- New: accepted pglogical-ticker [amd64] (focal-proposed) [1.4.0-2]
<vorlon> LocutusOfBorg: sorry, are you talking about a build failure now or a test failure? (gpgme1.0?)
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/g/gpgme1.0/20200310_150943_6e3c7@/log.gz
<LocutusOfBorg> this one
<LocutusOfBorg> looks like even python3 is not cross-installable
<vorlon> LocutusOfBorg: replace gcc+libc6-dev with build-essential in the test deps
<vorlon> ah but yes, python3 is definitely not cross-installable
<vorlon> so badtesting i386 is appropriate here
<vorlon> armhf should still be sorted however
<LocutusOfBorg> ok, what is the appropriate keyword here? DEB_BUILD_ARCH_BITS DEB_HOST_ARCH_BITS or DEB_TARGET_ARCH_BITS?
<Laney> mozjs68 needs promoting please, and then mozjs60 should drop into c-m
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu12.1 => 2.04-1ubuntu12.2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.128.1 => 1.128.2] (core)
<vorlon> LocutusOfBorg: DEB_HOST_ARCH_BITS (if you forget which is which, you can always run 'dpkg-architecture -amips' and look at the output for a refresher)
<LocutusOfBorg> I fail to parse sometimes, e.g. if the armhf test is run on arm64 kernel, isn't DEB_HOST_ARCH_BITS=64 and DEB_TARGET_ARCH_BITS=32? in this case, which one is appropriate?
<LocutusOfBorg> oh probably host because the time struct is a kernel stuff...
<vorlon> LocutusOfBorg: HOST_ARCH_BITS really refers to the userspace word size, not the kernel
<vorlon> (and even at the kernel level, armhf is using a different set of syscalls which are all 32-bit)
<cpaelzer> This is waiting for an FFe ack https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361
<ubot5> Ubuntu bug 1847361 in qemu (Ubuntu) "Upgrade of qemu binaries causes running instances not able to dynamically load modules" [Wishlist,In progress]
<cpaelzer> I have this ready now and another qmeu bug as well
<cpaelzer> would love to be able to upload before the weekend
<cpaelzer> so if soemone has time to FFe-Ack this that would be great
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu12.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.128.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.15]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu12.2 => 2.04-1ubuntu12.2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.15 => 2.02-2ubuntu8.15] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.15 => 1.93.16] (core)
-queuebot:#ubuntu-release- Unapproved: kmod (eoan-proposed/main) [26-1ubuntu1 => 26-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (bionic-proposed) [1.93.15ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.16]
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu12.2 => 2.04-1ubuntu12.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.15]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu12.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu12.2]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1043.48] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.15 => 2.02-2ubuntu8.15] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.15]
<mwhudson> vorlon: does the autopkgtest queue need savaging again?
<mwhudson> oh no, you've done that
<vorlon> mwhudson: yeah, we're ok there; what I need now is to know why gnudatalanguage is finding memory corruption only with glibc 2.31 on armhf
<vorlon> and why does gdb take so long to resolve symbol names for gnudatalanguage...
<vorlon> mwhudson: alright, I've gotten to the point now where trying to set a watchpoint with gdb is causing gdb itself to error out; and valgrind gives me nothing; so if you were to want to dig into gnudatalanguage further to see what's up you are welcome to and I can dump some state to you, but in the meantime I'm letting glibc through
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1043.48]
<mwhudson> hm that was strange, where did my irc client go
<mwhudson> vorlon: hmm debugging in that armhf environment where all our debugging tools work SO WELL, tempting
<mwhudson> vorlon: do you have a canonistack vm you can add my ssh keys to?
<mwhudson> i suppose i could test on the pi too
<mwhudson> % TEST_XDR_READ: Succesfully read of : /tmp/autopkgtest.XuifkF/build.aBF/src/testsuite/idl.xdr
<mwhudson> corrupted size vs. prev_size
<mwhudson> Magick: abort due to signal 6 (SIGABRT) "Abort"...
<mwhudson> Aborted (core dumped)
<mwhudson> vorlon: is that ^ the failure?
<mwhudson> vorlon: it's fairly hard to tell from the log...
<vorlon> mwhudson: yes that's the failure
<mwhudson> vorlon: it's happened at least a few times before glibc 2.31 it seems
<vorlon> mwhudson: reproducible with GDL_PATH=+/usr/share/gnudatalanguage:/tmp/gnudatalanguage-0.9.9/testsuite /usr/bin/gdl -quiet -e test_xdr
<vorlon> ah, even better
<mwhudson> vorlon: and in general http://autopkgtest.ubuntu.com/packages/g/gnudatalanguage is ... a thing
<mwhudson> although some of those are different
<mwhudson> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/g/gnudatalanguage/20200310_021853_92c62@/log.gz <- that looks completely broken
 * mwhudson afk for a bit
<vorlon> mwhudson: ISTR it broke on ppc64el due to a gfortran? update
<vorlon> doko: python3-defaults, those were all test progressions caused by new django, so --all-proposed sorted it
<vorlon> oh /now/ britney wants to not promote libxcrypt because it's uninstallable
#ubuntu-release 2020-03-13
<vorlon> doko: don't know if you were aware, but gcc-9 has to be migratable at the same time as glibc because libgphobos has a versioned dep on libc6 on s390x
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2 => 1.3.9-2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2 => 1.3.9-2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2 => 1.3.9-2] (core)
<vorlon> doko: so how long should this gcc-9 build on amd64 take?  since it's been going for 14 hours
<cpaelzer> hi, can I aske ubuntu-archive to consider accepting javaproperties in focal-new for bug 1866612?
<ubot5> bug 1866612 in azure-cli (Ubuntu) "Wrong dependency javaproperties -> pyjavaproperties" [Undecided,In progress] https://launchpad.net/bugs/1866612
<vorlon> done
-queuebot:#ubuntu-release- New: accepted javaproperties [sync] (focal-proposed) [0.6.0-2]
<cpaelzer> Thank you vorlon
<cpaelzer> I'll try to help this community member to get the further moving bits of this synced so that things will work properly in 20.04
-queuebot:#ubuntu-release- New binary: javaproperties [amd64] (focal-proposed/universe) [0.6.0-2] (no packageset)
<cpaelzer> vorlon: you accepted the source in NEW, now the build is complete and as one would expect now the binary is in NEW
<cpaelzer> would you mind accepting that as well?
<cpaelzer> in case vorlon is EOD now ubuntu-archive ^^
<doko> vorlon: I can find builds talking up to 18h, but also ones getting built in about six. so it should probably finish soonish
-queuebot:#ubuntu-release- New: accepted javaproperties [amd64] (focal-proposed) [0.6.0-2]
<cpaelzer> doko: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1867316
<ubot5> Ubuntu bug 1867316 in chrony (Ubuntu) "FTFBS in Focal armhf/ppc64/s390x" [Undecided,New]
<cpaelzer> does that mean anything including sys/param.h is FTBFS now?
<cpaelzer> actually limits.h
<cpaelzer> doko: to my naive view it seems libgcc-9-dev 9.3.0-1ubuntu2 will break everyone :-/
<cpaelzer> oh I see, only because of that long build time vorlon mentioned amd64 still works
<cpaelzer> as soon as that is built and published it most likely breaks as well
<cpaelzer> => https://launchpad.net/ubuntu/+source/gcc-9/9.3.0-1ubuntu2
<doko> yes, better I'm removing that one from -proposed. amd64 is working because it's not yet built
<cpaelzer> I might be misjudging the situation, but I'm tempted to ask to abourt that build and use ubuntu-archive powers to remove that new version from proposed
<cpaelzer> that might avoid a near global FTFBS until we have another gcc-9 pushed and built
<cpaelzer> ok, found a 5h old dup, which matches when s390x completed
<RikMills> yes, test building a few things I see the same, except obviously on amd64
<cpaelzer> even this will do
<cpaelzer> echo "#include <limits.h>" | gcc -E -Wp,-v -
<cpaelzer> breaks on all but amd64
<cpaelzer> and once built and published there as well
<cpaelzer> thanks RikMills for confirming - I was starting to feel I might be the outlier and on a totally crazy island here
<cpaelzer> I also a few minutes ago found https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1867303
<ubot5> Ubuntu bug 1867316 in gcc-9 (Ubuntu) "duplicate for #1867303 FTFBS in Focal armhf/ppc64/s390x" [Critical,Confirmed]
<RikMills> yeah, I was just test buildings a few things I wanted to sync for bugfixes, and 'bang'
<cpaelzer> I know ubuntu-archive should highlight all of you already, but I'm panicing (a bit) sorry, but apw seb128 doko vorlon infinity ^^
<RikMills> and seb128's sync did the same https://launchpad.net/ubuntu/+source/gnome-photos/3.34.1-1
<seb128> cpaelzer, hey, sorry I just joined and lack the backlog/context, what do you need exactly?
<cpaelzer> I think mostly we'd need doko, but for now read https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1867303
<RikMills> ggc-9 in proposed is ftbfs the world
<ubot5> Ubuntu bug 1867316 in gcc-9 (Ubuntu) "duplicate for #1867303 Almost global FTFBS due to dropping include-fixed dir in 9.3.0-1" [Critical,Confirmed]
<doko> <doko> yes, better I'm removing that one from -proposed. amd64 is working because it's not yet built
<cpaelzer> oh you are here
<cpaelzer> \o/
<doko> and I replied
<cpaelzer> yes that was my triage of the situation as well doko
<seb128> why do we get through such disruptive changes and transitions after ff? :(
<cpaelzer> lol
<cpaelzer> I was rading from too many channels at once
<cpaelzer> thanks doko, now that I realized you have seen it I'll leave it to your capable hands
 * cpaelzer stops panic mode
<doko> it was supposed to be a fix for an glibc issue
<cpaelzer> doko: if you could give a ping here once it is aborted and removed from proposed (for now) that would be great
<doko> cpaelzer: copy is now done, need to wait for the next publisher run
<cpaelzer> thank you
<doko> cpaelzer: now restored, and given back failed builds, afaics those in update_excuses
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-2]
-queuebot:#ubuntu-release- New source: nv-codec-headers (focal-proposed/primary) [9.1.23.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nv-codec-headers [source] (focal-proposed) [9.1.23.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted hud [source] (focal-proposed) [14.10+17.10.20170619-0ubuntu3]
<cpaelzer> thank you doko
<bluca> seb128: hi - the GP patch for network-manager-openconnect has moved from debian experimental to unstable now - I also imported all the patches you added downstream in 19.10 and 20.04
<bluca> https://tracker.debian.org/pkg/network-manager-openconnect
<bluca> any chance https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1857624 could be reconsidered for focal?
<ubot5> Ubuntu bug 1857624 in network-manager-openconnect (Ubuntu) "Option Protocol gp (Palo Alto GlobalProtect) missing on nmcli" [Undecided,Confirmed]
<bluca> unstable now is at the focal state + the 2 GP patches, so a sync would be enough
<cpaelzer> seb128: ^^ is that a package usually maintained by the desktop team?
-queuebot:#ubuntu-release- New binary: nv-codec-headers [amd64] (focal-proposed/universe) [9.1.23.1-0ubuntu1] (no packageset)
<seb128> cpaelzer, not really, but it's not maintained by anyone afaik so we do best effort to keep up with the n-m updates and fixes
<seb128> cpaelzer, do you want to do at if it's ok to sync or should I?
<seb128> bluca, thx for the fixes & ping
<cpaelzer> I can take a look and would sync if it is ok in terms of not needing an FFe
<bluca> thanks! debdiff: http://paste.debian.net/1134759/
<cpaelzer> bluca: BTW azure-cli is in -proposed now
<bluca> thanks!
<bluca> in the near future (so for 20.10 in Ubuntu terms) I will do the openconnect + network-manager-openconnect updates to the latest upstream versions as well
<seb128> cpaelzer, thanks
<kanashiro> hi, I've been investigating an autopkgtest regression on puppet/5.5.10-4ubuntu1 with the Debian maintainer and we can't reproduce the error locally: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/p/puppet/20200310_054016_1a91c@/log.gz
<kanashiro> is there any known issue with 'hostname --fqdn' inside a testbed? in a local container all the tests pass
<ahasenack> hi ubuntu-release, if someone could take a look at this nginx FFe bug please, thanks! https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1867150
<ubot5> Ubuntu bug 1867150 in nginx (Ubuntu) "FFe: nginx: demote bin:libnginx-mod-http-geoip" [Undecided,New]
<Laney>  kanashiro: Here's an example from a running instance
<Laney> ubuntu@autopkgtest:~$ hostname --fqdn
<Laney> adt-focal-amd64-systemd-20200313-113041.novalocal
<Laney> If you're expecting it to be the same as /etc/hostname, I guess that's an assumption that doesn't hold
<kanashiro> Laney, thanks for the info
<Laney> kanashiro: np, seems like the tests could be a bit more verbose on failure I would say
<Laney> like, what was the hostname you supplied and which certs did puppet know about
<Laney> that kind of thing
-queuebot:#ubuntu-release- Unapproved: kmod (bionic-proposed/main) [24-1ubuntu3.2 => 24-1ubuntu3.3] (core)
-queuebot:#ubuntu-release- Unapproved: vala (bionic-proposed/universe) [0.40.17-0ubuntu1 => 0.40.19-0ubuntu1] (ubuntu-desktop)
<vorlon> hmm re-queuing the glibc autopkgtests and getting results back would actually speed up the britney runs right now :P>
<vorlon> ah but queues aren't empty, so no point
<Laney> After the britney rebaseâ¢, we should optimise test submission / retrieval
<Laney> We could build up the list of tests to submit and then do them all in one go, and try to retrieve all pending test results at once too
<cjwatson> autopkgtests may suffer from the issues we're seeing in London scalingstacks at the moment FWIW.  See #is
<Laney> Ah, that'll probably explain why I got All The CD Build Failure Mails
<cjwatson> Dunno exactly what it is but something networky is Very Sad
<Laney> hmm
<Laney> perhaps not
<Laney> https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/focal/daily-live-20200313.3.log <- no livefs build requested
<Laney> ER no that's me being stupid and forgetting --live
<Laney> xnox: take it you saw the arm64 failure :-)
<xnox> Laney:  yes. Will work on the weekend to fix it.
<Laney> â
<vorlon> Laney: xnox raised a question of why britney can't get its test results by just downloading the sqlite db and parsing
<xnox> oooh yes
<Laney> backchannels eh
<xnox> Laney:  and my other question was how does debian's britney download tests, and do we need to change our autopkgtests, to yeah cherrypick what debian does?
<Laney> well, currently that is often subject to latency which we don't have when fetching directly from swift
<xnox> cause debian's britney invalidates out of date results, and re-requests them, and our britney doesn't.
<Laney> We need to rebase on the upstream version of britney2, and then we can have nice things
<xnox> my problem was that today we have only 13 britney runs per 24h. I don't care if britney fetches a 15minute stale sqlite db of results; as long as we can have britney complete 30+ runs per 24h.
<Laney> but the specific question of requesting and fetching tests in the way that Debian does (whatever that is) is not going to be one of them, since we don't use debci
<xnox> right
<xnox> cause i think swift latency gain is now killing us due to number of requests we need to make (thousands, when we have glibc & boost & icu & python stuck in proposed)
<xnox> versus using a stale sqlite3 db and just querieng that, a thousand times, but very quickly.
<Laney> Well, I don't know about killing, but it could be improved yes
<xnox> Laney:  i can run britney, locally, against the production autopkgtest.ubuntu.com results, right?
<xnox> to like attempt to profile it / speed a run up?
<Laney> Sure
<Laney> But I don't really suggest doing much work on top of our current britney2-ubuntu fork
<xnox> but it needs swift creds, or are those like public?
<Laney> No
 * xnox realises i asked two questions, which a single answer doesn't map to =)
 * xnox assumes it needs no creds
<Laney> It's public, anyone can use the swift API
<xnox> ah, cool.
<xnox> i guess i should look into the rebase then first
<xnox> even moving a little bit forward / merging a bit will help.
<xnox> to reduce the delta.
<Laney> That is a whole task of work on its own which I'm going to get on the roadmap
<xnox> ooooh
<Laney> well, try to
<Laney> but hopefully with success :-)
<vorlon> ahasenack: why do we have i386-specific bind NBS on https://people.canonical.com/~ubuntu-archive/nbs.html ?
<ahasenack> vorlon: these come from the old bind9-9.11.x perhaps?
<vorlon> Laney: latency> who cares?  if it takes 1h+ to even poll all the swift URLs
<ahasenack> src:bind9-9.11.x
<ahasenack> let me check the sonames
<vorlon> ahasenack: so specifically, they can't be removed because e.g. libbind-dev is listed as having a dep on them only on i386
<Laney> vorlon: ok
<Laney> so I thought I was clear that polling all of the URLs one by one is dumb, sorry if that wasn't true
<vorlon> Laney: I think the autopkgtest db updates at a much higher frequency than britney itself does at the moment; and I also don't care if a given britney run has all the latest results when it runs, if we will be able to iterate britney runs more quickly
<vorlon> right :-)
<Laney> I wouldn't go as far as specifying what the solution should be right off the bat
<vorlon> but I also don't think that polling them all should be in the main loop
<ahasenack> libbind-dev also existed only in src:bind9-9.11.x
<vorlon> because the results will come $eventually and when they're there they're there and britney will DTRT with them
<vorlon> ahasenack: but libbind-dev itself is not listed as NBS
<ahasenack> ah, bind9-libs builds it
<ahasenack> src_bind9-libs
<vorlon> so bind9-libs is missing from the i386 whitelist?
<ahasenack> yep
<vorlon> or
<vorlon> do we actually need bind9-libs on i386 or should I manually remove these binaries
<ahasenack> we had old bind9 9.11.x building for i386
<ahasenack> that was libs + server
<vorlon> it doesn't look like any of the revdeps of bind9-libs in the archive exist on i386 (which makes sense, else this wouldn't have migrated)
<vorlon> so I'll hand-remove the binaries
<vorlon> ahasenack: thanks
<ahasenack> sounds good
<ahasenack> vorlon: I'm gonna need libmaxminddb on i386 going forward, because bind9 has i386 builds
<ahasenack>  Missing build dependencies: libmaxminddb-dev (>= 1.3.0)  (in a ppa)
<vorlon> ahasenack: done
-queuebot:#ubuntu-release- Packageset: Added libmaxminddb to i386-whitelist in focal
<xnox> vorlon:  Laney: deffo _my_ changes in focal livecd-rootfs regressed the arm64 builds, lolz.
<ahasenack> thanks vorlon
-queuebot:#ubuntu-release- New sync: node-debbundle-es-to-primitive (focal-proposed/primary) [1.2.0+~1.1.4+~1.1.0+~1.1.0+~1.0.1+~1.0.2+~1.0.0+~1.0.1-2]
<vorlon> doko: gcc-snapshot also has a versioned glibc dep on s390x, which is precisely the architecture where it ftbfs; retrying now in case the ICE was transient, but if not I'll just remove the s390x binaries from the release pocket
<vorlon> doko: actually I'll just remove the binary now and we'll go from there
<Laney> xnox: ah man that reminds me about the hateful 20.04 hardcoded there
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1006.6] (core, kernel)
#ubuntu-release 2020-03-14
<vorlon> glibc finally migrated
<xnox> congrats!
<vorlon> mitya57: icu is in a middle of a transition, please don't sync packages right now that are part of that transition (qtwebkit-opensource-src)
<xnox> yeah, i was going to say, why did icu not migrate
<vorlon> there are other revdeps that still needed work, last I looked
<vorlon> webkit2gtk
<vorlon> but we don't need to be resetting things all the time
<vorlon> ruby-charlock-holmes entangles ruby + icu
<vorlon> at least
<OldManWi1ter> http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html so Debian seems to consider openssl (and gcc, cups) as system libraries, thus allowing GPL-2 applications to link.  I presume Ubuntu will too?
<foka> Dear all, could you please consider LilyPond 2.20.0 (stable release) for Ubuntu 20.04 LTS (focal)?  https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/1867129
<ubot5> Ubuntu bug 1867129 in lilypond (Ubuntu) "[FFe] Please sync lilypond 2.20.0-1 from Debian" [Undecided,New]
<xnox> OldManWi1ter:  it's only action for them to write something up. did they? and published it?
<OldManWi1ter> xnox: I have yet to see that.
<foka> And https://bugs.launchpad.net/ubuntu/+source/libsass/+bug/1867116
<ubot5> Ubuntu bug 1867116 in libsass (Ubuntu) "[FFe] Please sync libsass 3.6.3-1 from Debian" [Undecided,New]
<foka> Oops, sorry for cutting into your conversation.  I should have picked another time to post those URLs.  :-)
<xnox> OldManWi1ter:  well, i'd want to see that, rather than just irc logs of their private meeting where they discuss what to do =)
<OldManWi1ter> foka: Nah that's fine, it's nothing really.
<OldManWi1ter> xnox: Yeah, that'd be interesting to see the final write-up, rather than "Like Fedora"
<vorlon> hmm did someone just beat me to fixing libcrypt1's priority in the archive?
<vorlon> xnox: that's a rather odd changelog entry for a 0.57-2build1 package
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [213-1~ubuntu19.04.1 => 214.1-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (eoan-backports/universe) [213-1~ubuntu19.10.1 => 214.1-1~ubuntu19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [214.1-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [213-1~ubuntu18.04.1 => 214.1-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (eoan-backports) [214.1-1~ubuntu19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [214.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1006.6]
<mitya57> Oh, icu againâ¦
<mitya57> I wish we had warnings like in tracker.debian.org: this package is part of transition, please avoid unrelated uploads, etc.
<RikMills> doko * vorlon : LP: #1866844
<ubot5> Launchpad bug 1866844 in glibc (Ubuntu) "package libc6:amd64 2.31-0ubuntu3 failed to install/upgrade: installed libc6:amd64 package post-installation script subprocess returned error exit status 127" [Undecided,Confirmed] https://launchpad.net/bugs/1866844
<RikMills> for some, seems there is still an issue
-queuebot:#ubuntu-release- Unapproved: python-keyring (eoan-proposed/main) [18.0.1-1 => 18.0.1-1ubuntu1] (core)
<RikMills> vorlon: lintian is not installable on i386
<RikMills> which breaks building extra-cmake-tools and kconfig from the i386 whitelist
<RikMills> E: Package 'libdevel-size-perl' has no installation candidate
<RikMills> E: Package 'libsereal-decoder-perl' has no installation candidate
<RikMills> E: Package 'libsereal-encoder-perl' has no installation candidate
<vorlon> mitya57: well, I think it's important to know whether there's a version of a package in -proposed before uploading, and knowing why it hasn't moved
<vorlon> RikMills: thanks, I got subscribed to the bug and am coming in to check now.  Unfortunately the bug doesn't have good info but I'm going to see if I can reproduce this
<RikMills> vorlon: thanks. I quickly tied a couple of VM upgrades, but they went without error :/
<RikMills> *tried
<vorlon> RikMills: right, and see the comment I just added, this bug was filed by somebody upgrading with focal-proposed enabled and is therefore an invalid description of the problem
<vorlon> "Solution was to remove libc6-amd64 as Debian upstream suggests" lolwut https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1867423/comments/10
<ubot5> Ubuntu bug 1866844 in glibc (Ubuntu Focal) "duplicate for #1867423 package libc6:amd64 2.31-0ubuntu3 failed to install/upgrade: installed libc6:amd64 package post-installation script subprocess returned error exit status 127" [Critical,Confirmed]
<RikMills> o_O
<RikMills> I really wish software properties had a better description for the -proposed updates checkbox :(
<RikMills> people read it as just an early way to get new goodies!
<vorlon> ah
<vorlon> I bet the affected users all had the bad libcrypt1 installed, from the day that it incorrectly migrated to the release pocket
<RikMills> makes sense
<Logan> welp, I just got hit by this
<Logan> vorlon: let me know if I can help provide any useful data
#ubuntu-release 2020-03-15
<vorlon> Logan: just requires britney to catch up so I can hint the new glibc upload through
<Kamilion> I just encountered it too, `ln -s /lib/x86_64-linux-gnu/libcrypt.so.1.1.0 libcrypt.so.1` in another root terminal was enough to get apt to finish installing the rest of the packages. Proposed was not enabled.
<Kamilion> tossed my wajig log at https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1867423/comments/11
<ubot5> Ubuntu bug 1867431 in glibc (Ubuntu) "duplicate for #1867423 ERROR got an error from dpkg for pkg: 'libc6'" [Critical,Fix committed]
<Kamilion> https://launchpadlibrarian.net/469110017/terminal.log  has the terminal session where I ran into it.
<vorlon> Kamilion: yes, if you were upgrading libcrypt1 instead of it being a new install, then that's exactly what you've hit
<Kamilion> symlink's harmless to leave?
<vorlon> well on upgrade it will be replaced with the one from the package
<mitya57> Can someone please reject sip4 in xenial SRU queue?
<rbasak> mitya57: ^ done
-queuebot:#ubuntu-release- Unapproved: rejected sip4 [source] (xenial-proposed) [4.17+dfsg-1ubuntu0.1]
<mitya57> thanks!
-queuebot:#ubuntu-release- Unapproved: sip4 (xenial-proposed/universe) [4.17+dfsg-1build1 => 4.17+dfsg-1ubuntu0.1] (kubuntu)
<mitya57> rbasak: this is the new version that fixes your comments :)
<rbasak> Sorry, I was just driving past :)
<rbasak> I'll try to remember to look when I'm back on Monday
<mitya57> No hurry, Xenial was with this bug for a few years anyway
<rbasak> Thanks.
<rbasak> BTW, you can upload without needing a reject for the old upload first, if that helps with waiting for round trips
<RikMills> vorlon: can we get linian installable on i386 in proposed? if not, pkg-kde-tools will not be installable on i386, and so very core kde packages extra-cmake-modules and kconfig will not build in focal any more
<RikMills> i.e. add the dep packages without i386 builds to the whitelist
<RikMills> alternatively remove extra-cmake-modules and kconfig from the i386 whitelist, as they have no good reason to be there
