#ubuntu-release 2011-01-31
<pitti> jdstrand_: e-d-s had a manual dependency on libgdata7, I fixed that over the weekend; CDs built again
<lamont> rolling new natty tarballs, btw
<jibel> cjwatson, is there a rebuild of xubuntu desktop amd64 scheduled today? X segfaults on amd64 with the current image.
<cjwatson> dunno
<cjwatson> is there a reason to believe that a rebuild would fare any better?
<jibel> cjwatson, bug 709977 has been fixed yesterday. other images are fine now and I wanted to verify that xubuntu was ok too.
<ubot4> Launchpad bug 709977 in xserver-xorg-input-evdev (Ubuntu Natty) (and 1 other project) "Xorg crashed with SIGSEGV in RemoveDevice() - segfault at 1010 error 4 in evdev_drv.so (affects: 37) (dups: 15) (heat: 214)" [Critical,Fix released] https://launchpad.net/bugs/709977
<cjwatson> jibel: well, xubuntu desktop amd64 was already built this morning
<cjwatson> and it contains that version
<cjwatson> so I'm not sure why a rebuild would help, again :)
<jibel> cjwatson, the images are syncing now, I tried earlier and there was no xubuntu desktop iso for today. weird.
<jdstrand_> pitti: re libgdata7. oh? I checked the build logs for e-d-s on all archs and it pulled in libgdata11. I am almost certain I did checkrdepends too, but it is possible I forgot the -b flag...
<jdstrand_> pitti: sorry about that. btw, where do you see that CD images are failing to build?
<pitti> jdstrand_: right, it linked against libgdata11 (through shlibs:Depens), but had an obsolete additional libgdata7 dependency
<pitti> jdstrand_: the release team gets the failed logs emailed
<pitti> jdstrand_: don't worry, it was easy to fix, and a real bug anyway
<seb128> pitti, speaking of which there was a merge request with the fix waiting on launchpad
<pitti> seb128: dropping the dependency?
<seb128> yes
 * pitti closes
<jdstrand> pitti: ok. I'll take a look at the last package to see what it did so I can try to not make the same mistake in the future
<pitti> seb128: updated, thanks
<seb128> thanks
<jdstrand> pitti: should I get those u-r emails? are they to a list or just an alias/exploder?
<pitti> jdstrand: I'm not sure, cjwatson would know more
<cjwatson> manually maintained list
<cjwatson> I can add you if you like
<cjwatson> preferred address?
<jdstrand> cjwatson: I took this to be a long term responsibility. as such, it seems like it would make sense so I can at least be more proactive in me reacting :)
<jdstrand> cjwatson: jamie@canonical.com would be great
<jdstrand> s/me/my/
<cjwatson> ok, thanks, done
<jdstrand> cjwatson: thank you
<ara> pitti, cjwatson: sorry about being that picky about testing from -proposed before eglibc and d-i go into -updates. We want to find regressions if there are any, but it is a very expensive testing, so we wouldn't like to start testing, then validation failures are found on those packages, and we have to start all over again
<pitti> ara: that's fine; that's why we have these meetings, to figure out what will work for everyone :)
 * skaet nods
 * pitti -> dinner
<ara> good night all
<charlie-tca> do we have any daily/daily-live images of Xubuntu lucid 10.04.2?
<cjwatson> probably not at the moment, I can do some if they're going to be tested
<ScottK> Looks like Kubuntu live i386 on Lucid managed to get oversized.
<ScottK> Riddell: ^^^ thoughts on this?
<Riddell> remove a language pack I guess
<pitti> there are none left on Kubuntu live :/
<pitti> except -en
<pitti> you could drop language-support-en
<pitti> Riddell: so the gvfs removal didn't help enough?
<Riddell> pitti: "lucid"
<Riddell> natty is fine
<pitti> ah
<ScottK> Riddell: Did you kick off the powerpc rebuild in Natty?  Curious how it's going.
<Riddell> still ongoing..
<ScottK> Thanks.
<charlie-tca> cjwatson: I can wait for the iso testing, if you prefer
<charlie-tca> I asked because I couldn't find them, but if they are not there, it is okay today
<stgraber> just FYI, I'm currently fixing LTSP in Ubuntu. I'll be uploading a new ldm now which should fix the biggest issue (non-working gnome).
<stgraber> I haven't tested installing LTSP from alternate yet but if it's broken, it'll likely be in ltsp itself and not ldm. Will test it tomorrow morning.
#ubuntu-release 2011-02-01
<jibel> skaet, I verified sru bug 607657 on both amd64 and i386, also verified that the following packages upgrade correctly and that the system reboots after the upgrade: base-files, consolekit,  eglibc, grub2, unattended-upgrades, upstart, xserver-xorg-video-geode
<ubot4> Launchpad bug 607657 in debian-installer (Ubuntu Lucid) (and 3 other projects) "Lucid point release installer must support LTS backported Kernels (affects: 2) (heat: 28)" [High,Fix committed] https://launchpad.net/bugs/607657
<jibel> I've verified that lsb_release returns the right version too. I'll add a comment on the bug report tomorrow morning (mine), good night all
<skaet> jibel,  thank you!  :)
<jibel> ara, pitti, I verified sru bug 607657 on both amd64 and i386, also verified that the following packages upgrade correctly and that the system reboots after the upgrade: base-files, consolekit,  eglibc, grub2, unattended-upgrades, upstart, xserver-xorg-video-geode
<ubot4> Launchpad bug 607657 in debian-installer (Ubuntu Lucid) (and 3 other projects) "Lucid point release installer must support LTS backported Kernels (affects: 2) (heat: 28)" [High,Fix committed] https://launchpad.net/bugs/607657
<ara> thanks a lot jibel
<jibel> I've verified that lsb_release returns the right version too. Anything other thing to check for sanity ?
<jibel> I'll update the reports.
<cjwatson> skaet: the morning's CD builds have mostly been hamstrung by the new X packages, which aren't coinstallable yet.  I'll try to push things uphill until jdstrand is around ...
<skaet> cjwatson, thanks.  We
<skaet> are having storms here, and I don't have power to the house, so jdstrand may be affected as well.
<skaet> internet is on UPS - so I guess we'll see how long its battery lasts ;)
<ara> pitti, cjwatson: are eglibc and d-i now ready to be moved to -updates?
<pitti> they are; I already did eglibc
<pitti> (and a few others)
<pitti> d-i needs special treatment, I'll do that today
<pitti> I asked about testing tbird-locales, should happen today (from Chris)
 * ara hugs pitti
<ara> thanks!
<jibel> pitti, you can publish base-files too, there is no bug report for it.
<pitti> then casper is the only thing which is still in -proposed
<pitti> jibel: right, that's just the "I'm 10.04.2" bump
<pitti> jibel: many thanks for all these verifications
<jibel> pitti, correct. and I've verified that lsb_release displays 10.04.2 :-)
<jibel> pitti, for x-x-v-geode, I verified that it installs but I don't have this hw so it really proves nothing. only q-funk could do a valid verification.
<pitti> jibel: right, I already prodded him to give it a test
<pitti> ah, and grub2 still needs testing
<pitti> ara: so what was the plan now? do cert on the proposed images, or wait until everything is verified?
<ara> pitti, we will start with the -proposed images
<jibel> pitti, and for grub, strangely this morning usb-creator crashes on me when I want to create create a bootable memory stick.
<ara> pitti, the only need of waiting on those packages to move to -updates was to be able to know that validation was fine :)
<ara> pitti, we will start as soon as possible testing on a broad range of hardware, to test if everything is still OK
<pitti> cool
<ara> Hopefully there won't be any regressions
<ara> fingers crossed
<ara> we will be posting results in a report as we go, we will let you know where it is
<Riddell> new package doesn't contain the full licence text but a URL to the licence, reject?  (http://paste.kde.org/3879/)
<cjwatson> is that in debian/copyright or in an upstream file?
<Riddell> both
<cjwatson> the upstream file does not need to change
<cjwatson> (as Steve and I have been saying for ages)
<cjwatson> debian/copyright needs to comply with policy, though
<cjwatson> should be as simple as inserting a reference to /usr/share/common-licenses/Apache-2.0
<pitti> I object
<pitti> well, GPL requires it
<pitti> and this one kind of does
<pitti> "You must give any other recipients of the Work or Derivative Works a copy of this License"
<cjwatson> that's why it's in common-license
<cjwatson> s
<cjwatson> the upstream file does not need to change because (a) upstream is the licensor not a licensee and can do what it likes (b) we shouldn't encourage people to change upstream files when it isn't necessary.  a reference to the common-licenses file in debian/copyright satisfies our licensing obligations
<pitti> right, but I still consider it an upstream pacakging error to not ship the license
<cjwatson> it might be a justification for a polite mail to upstream asking if they can ship it
<pitti> *nod*
<cjwatson> it is absolutely not a justification for a reject
<pitti> I agree
<cjwatson> (although the debian/copyright error is)
<Riddell> I'll reject, thanks
<pitti> I do reject GPL packages which don't ship a copy, though, as the GPL wording is quite strong in that regard
<cjwatson> we meet our obligations there by shipping it with the system
<cjwatson> that's the whole point of common-licenses
<cjwatson> suppose it depends what you think "along with" means
<pitti> to me it means "is the orig.tar.gz redistributable"
<pitti> which it wouldn't be if it wouldn't have a GPL copy
<pitti> we made some concessions for that in the past
<cjwatson> I'm concerned that this policy encourages people to modify orig.tar.gz files
<pitti> such as "I told upstream, and they'll ship it in the  next release"
<cjwatson> it is IMO clearly sufficient to put it in the diff.gz/debian.tar.gz
<pitti> at which point I  accepted them
<Riddell> three rejects today, I'm on a roll :)
<Riddell> the benevolent dictator has confirmed bug 709980, does that mean I don't need to wait for ubuntu-sru to confirm it?
<ubot4> Launchpad bug 709980 in ubuntu-font-family-sources (Ubuntu Karmic) (and 5 other projects) "SRU ubuntu-font-family 0.70.1 for * (affects: 2) (heat: 16)" [Undecided,New] https://launchpad.net/bugs/709980
<jibel> cjwatson, pitti, can we start testing alternate images ? there's nothing for a2 on the tracker.
<cjwatson> jibel: no, needs X fixed
<cjwatson> I'll post to the tracker when stuff is ready
<cjwatson> Riddell: in general you don't need to wait for ubuntu-sru to confirm something before upload anyway; we review from the queue
<jibel> cjwatson, okay, thanks
<cjwatson> it's only if you want some kind of design review
<Riddell> cjwatson: it is in the queue, I'm asking if I can accept it
<cjwatson> not for lucid (10.04.2 freeze); it's OK for other releases if it passes your review
<cjwatson> (IMO)
<jibel> pitti, I verified casper, grub2 and srtp in lucid,
<pitti> wow, thanks!
<jibel> I've never been able to reproduce the eclipse bug
<pitti> for that a "package stilll works" is probably sufficient at this point IMHO
<jibel> okay, you need moon as well ?
<pitti> no, it's not on any CD
<pitti> eclipse isn't either, I think
<pitti> (no Task: header)
<cjwatson> FWIW, to whoever did main syncs, I was deliberately avoiding main syncs due to the soft freeze
<cjwatson> universe syncs are fine
<jdstrand> I have power
<jdstrand> and am here now
 * jdstrand is reveiwing backscroll and email
<cjwatson> jdstrand: status: waiting for pile of X uploads to build so that http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html looks like less of a disaster area and we can actually have CD builds that work
<cjwatson> xserver-xorg-input-mouse still needs a non-trivial upload
<pitti> cjwatson: FYI, d-i copied to lucid-updates, according to the wiki procedure
<pitti> (plus sru-release lucid d-i)
<jdstrand> cjwatson: ok, thanks. is there anything you need me to do right now to help? I was planning at looking at the various reports (nincluding that one) and reviewing the antimony emails for things to work on
 * jdstrand notes armel seems particularly cranky
<jdstrand> I'm guessing that is a secondary priority though
<cjwatson> jdstrand: most of the X crankiness on armel should be fixed soon
<cjwatson> pitti: thanks
<cjwatson> pitti: did you stop the publisher for it, or run it when the publisher was quiet anyway?
<cjwatson> jdstrand: the libreoffice stuff can/has-to be ignored on armel for the time being, AIUI
<pitti> cjwatson: I did that in dists.new, as the wiki page says (and confirmed that it was still present afterwards)
<pitti> I'll check on http://archive.u.c./ after the next publisher run, though
<cjwatson> and KDE seems busted on armel for one reason or another
<cjwatson> pitti: ok, thank
<cjwatson> s
<cjwatson> jdstrand: I think once this X hairball lands I'll try another full batch of CD builds, and then let you wrestle with whatever falls out of that
<jdstrand> cjwatson: ok
<jdstrand> cjwatson: I was looking at kde on friday. as of then, it is a snowball effect of kdebase not building
<jdstrand> Riddell: fyi ^
<jdstrand> I didn't look beyond that yet
<Riddell> jdstrand: well it's kdebindings that's the blocker on arm
<jdstrand> Riddell: ok, so you are aware of it. cool. is that going to be fixed for alpha2?
<Riddell> jdstrand: doesn't seem like it, I can't work out why it's failing :(
<jdstrand> Riddell: perhaps that is something doko look at if it is a tool chain issue?
<jdstrand> s/look at/provide guidance, etc/
<cjwatson> doko's on holiday for the next two weeks
<jdstrand> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/build/buildd/gtk+2.0-2.23.90/gtk -I.. -DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/usr/lib\" -DGTK_DATADIR=\"/usr/share\" -DGTK_DATA_PREFIX=\"/usr\" -DGTK_SYSCONFDIR=\"/etc\" -DGTK_VERSION=\"2.23.90\" -DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"arm-unknown-linux-gnueabi\" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"file,cups\" "-DGTK_PRINT_PREVIEW_COMMAND=\"evince --unlink-tempfile --preview --print-sett
<jdstrand> sip: KPlotAxis::majorTickMarks() unsupported function return type - provide %MethodCode and a C++ signature
<jdstrand> holy cow that line was way longer than I thought
<jdstrand> sorry about that!
<jdstrand> heheh
<Riddell> -x PyQt_qreal_double should set double to be qreal and get round the qreal != double issue
<Riddell> I can't see anything which has changed in the pykde source
<Riddell> it's a new sip4 and py-qt4 version but upstream says nothing has changed there
<Riddell> and indeed /usr/share/sip/PyQt4/QtCore/qglobal.sip still has the typedef in it
<jdstrand> I've not looked at this or the kdebindings build issue before
<jdstrand> what does -x PyQt_qreal_double do to affect the compile?
<Riddell> NCommander has worked on it before but he doesn't seem to be interested in it now
<jdstrand> ah, ok
<Riddell> it should do typedef double qreal;
<Riddell> from qglobal.sip
<jdstrand> maybe we should poke him
<Riddell> or bribe him
<cjwatson> so I *think* we should be good to go for images other than Kubuntu armel in a bit over an hour and a half
<cjwatson> by that point the remaining X stuff should have landed, along with new ubiquity
<cjwatson> maybe not powerpc
<charlie-tca> cjwatson: don't spin the xubuntu powerpc
<cjwatson> ok, what's wrong with it?
<charlie-tca> it don't work and I don't have a tester
 * cjwatson makes yet another mental note to get that mac mini set up
<jdstrand> filed bug #711293 (apache2)
<ubot4> Launchpad bug 711293 in apache2 (Ubuntu Natty) (and 1 other project) "[natty] apache2 FTBFS on amd64 (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/711293
<jdstrand> looks like axis2c won't be fixed for alpha2 (bug #600174)
<ubot4> Launchpad bug 600174 in axis2c (Ubuntu Natty) (and 2 other projects) "axis2c fails to build from source on maverick/i386 (affects: 4) (dups: 2) (heat: 41)" [High,Confirmed] https://launchpad.net/bugs/600174
<jdstrand> (followed up with server team)
<jdstrand> also kdebindings probably won't be fixed for alpha-2
<jdstrand> (followed up with arm team)
<Daviey> jdstrand, I am going to take another sniff of axis2c today.
<jdstrand> Daviey: cool, thanks :)
<Daviey> I hate it, i hate it! :)
 * jdstrand is sorry to bring it up
<Daviey> heh
 * skaet is glad jdstrand brought it up
<jdstrand> skaet: hi! do you have power back on?
<skaet> yup,  got it back now.
<jdstrand> nice. crazy winds
<skaet> have half a tree in my backyard to deal with now at some point
<jdstrand> :(
<pitti> hey skaet, good morning
<highvoltage> hectic
<skaet> hey pitti, good afternoon.
 * skaet working through the irc log now - but parts not updated yet.
<jdstrand> skaet: oh, been meaning to ask you. dapper server is going eol in june and hardy desktop in april-- are you planning to send a pre-eol announcement? I think slangasek would do it 3 months before... if this is in a wiki, feel free to point me at it
<skaet> jdstrand: just a sec, and I'll get the link and double check as well.
<skaet> whew... its just 30 days before, so we're fine. :) https://wiki.ubuntu.com/EndOfLifeProcess
<skaet> and yup, I'll send it out and work through the checklist, do the negotiations with OEM, etc.
<jdstrand> skaet: thanks for the link. I wonder if it should be sooner for LTS? maybe not, but my thinking is that the types of people who stay on LTS may need more time to test upgrades, etc. of course, they are probably aware of the EOL
<jdstrand> skaet: just a thought...
<skaet> jdstrand,  its a good thought
<skaet> I was planning on pinging marketing to see if they wanted to do something public about dapper server (first ever LTS release EOL'd)
<skaet> jdstrand:  will dig into the implications of sending out an EOL pre-announce for the LTS (2 months prior?, then repeat at 30 days) next week, after A2 is out.  ;)
<jdstrand> skaet: cool, thanks. it looks like I misremembered. All I could find was https://lists.ubuntu.com/archives/ubuntu-announce/2009-July/000123.html which was a month (or so) before
<jdstrand> (dapper eol)
<skaet> jdstrand:  thanks for the link to dapper's eol.   It will be appropriately cribbed in due time, ;)
<cjwatson> sigh, kde4libs update meant that amd64 exploded
<cjwatson> publisher on manual, I don't have all day
<Riddell> yeah sorry about that, I shouldn't have uploaded that
<JamieBennett> Hi cjwatson, can you give me an update on the x uploads? Wondering when i can respin images for Linaro again.
<smoser> does anyone know of reasons that I would not be able to start UEC / EC2 image testing on last nights build ?
<smoser> or would there be something important missing from them.
<cjwatson> JamieBennett: X is done, just sorting out kde4libs
<JamieBennett> Ok, thanks
<smoser> the only update that I see from current 20100102 images and what the archive has is libdb4.8
<smoser> the changelog doesn't mention anything seemingly relevant for me
<smoser> so, i would guess unless there are objections, that I'm asking someone to populate the iso tracker from http://uec-images.ubuntu.com/server/natty/20110201/ (http://uec-images.ubuntu.com/server/natty/20110201/published-ec2-daily.txt)
<smoser> but i guess iso tracker hasn't even started alpha-2 testing yet.. .so maybe im'just too early
 * cjwatson thinks
<cjwatson> server's probably OK
<cjwatson> smoser: remind me what file I'm supposed to use as input to post-amis-to-iso-tracker.py?
 * smoser searches
<cjwatson> I'm sure I used to know
<cjwatson> it's supposed to be parseable like this:
<cjwatson>                 zone,ami,arch,store = line.split()[0:4]
<cjwatson>                 if not ami.startswith('ami-'):
<cjwatson>                         continue
<smoser> lp:~ubuntu-archive/ubuntu-archive-tools/trunk/post-amis-to-iso-tracker.py
<cjwatson> yes
<smoser> 'hvm' in store is possibly going to break you
<smoser> which is a new deliverable.
<cjwatson> I can't find the file to supply as input to that script, though
<cjwatson> I'm happy to try to fix up the script ...
<smoser> the second link in above
<smoser> http://uec-images.ubuntu.com/server/natty/20110201/published-ec2-daily.txt
<cjwatson> oh, bah, sorry, missed that
<skaet> jdstrand, pitti, cjwatson - have cleaned up iso.qa.ubuntu.com.   Its ready for the images to go up, when they come off the builds.
<cjwatson> ok, so what should I do with the hvm deliverable?
<cjwatson> I wonder how flexible the testcase naming is
<cjwatson> if it'll just accept us-east-1-amd64-hvm, we may be OK
<cjwatson> oh, right, there's a numerical map
<smoser> yeah, so right now there isn't a test case for it, and i'm not going to test it like i have the others
<smoser> so i guess, if you can add a test group for it, that would be good.
<cjwatson> test group?
<cjwatson> I can add a test case id for it in the tracker, but have no idea how to make that have useful backend data
<smoser> hm... well, i guess do the first step.
<smoser> i have no idea either.
<cjwatson> just call it "Ubuntu Server EC2 HVM (US-East) amd64"?
<smoser> yeah
<cjwatson> bah, it's supposed to have a URL
<cjwatson> I can't even find the list of existing testcase URLs
<cjwatson> http://testcases.qa.ubuntu.com/Install doesn't include anything for EC2 AFAICS
<cjwatson> stgraber,jibel: do you have any idea what I should use as a testcase URL for a new EC2 deliverable?
 * stgraber looks at the DB for similar testcases
<cjwatson> is there anything private in the ISO tracker DB?  password hashes I guess ...
<stgraber> we could probably export part of the DB at least, it's a Drupal instance so exporting just the data of the qatracker module should be fine
<stgraber> looks like I no longer have ssh access to the box hosting the QA tracker ...
<stgraber> used to be on quandong.canonical.com but got moved to something else and I don't know the name of the new server ...
 * cjwatson looks at powering up the mac mini persia gave him and discovers it has a deeply alarming power plug which I don't want to plug into anything here
<cjwatson> I think I'll get a native end for the power brick tomorrow instead ...
<cjwatson> it has an earth wire which apparently you're supposed to do this with: http://www.binchoutan.com/alfa-genius/images/fielder/img1_13.jpg
<highvoltage> isn't that a normal american plug?
<cjwatson> never seen a US plug with the additional spadeclip earth wire
<cjwatson> which you're meant to screw onto a post attached to your socket
<skaet> sweet!  just finished looking at the A1 release note bugs, and all those with numbers are actually fix released/resolved. :)
<highvoltage> heh, weird
<ScottK> Riddell: It looks like I asked for that powerpc respin yesterday too soon as it came in the same size.  Could we respin it again?
<cjwatson> stgraber: do you think I might be able to just use a blank URL?
<davmor2> latest x drivers update seem to of broken unity I get just the background and white mouse cursor and nothing else :(  It was working fine-ish yesterday
<Riddell> ScottK: I think now we need to wait for the alpha 2 candidates to appear
<ScottK> Riddell: OK.  That'll be fine.  I wasn't sure if we'd got that far yet or not.
<ScottK> (I'm offline most of today and tomorrow)
<stgraber> cjwatson: IIRC an external testcase isn't even a requirement (in the code, might be in the process), so you should be able to add one without an URL, then whenever we find someone with DB access we can change it
<jibel> cjwatson, there are 3 testcases for uec http://testcases.qa.ubuntu.com/Install/ServerUECTopology[1-3]
<cjwatson> jibel: this is EC2 rather than UEC
<jibel> cjwatson, oh right. I think you can go with a blank, I'll update it later.
<jibel> cjwatson, the testcase url for ec2 is http://testcases.qa.ubuntu.com/System/EC2CloudImages
<cjwatson> jibel: I tried both that URL and a blank URL, but it just ignores me (doesn't show the new testcase in the list, and doesn't show an error)
<cjwatson> jibel: can you try, if you have admin access?
<cjwatson> server and Kubuntu images building, pending that
<cjwatson> Ubuntu server posted
<jibel> cjwatson, for which product and what is the testcase title ?
<cjwatson> jibel: "Ubuntu Server EC2 HVM (US-East) amd64"
<cjwatson> (for Ubuntu, of course)
<jibel> cjwatson, I've added it to the list of products, now you should see it in the testcase management page. Do I add the 2 testcases "EC2 User Data" and "EC2 Multiple Instances Run" ?
<cjwatson> ah, I see, I was working on the wrong page
<cjwatson> can you make it match whatever the other EC2 products say?
<jibel> cjwatson, done. the menu "Manage Testcases" is misleading because it lists products and there is no way to list the test cases in the tracker. This tool definitely needs some love.
<cjwatson> yeah
<cjwatson> thanks!
<jibel> yw
<cjwatson> smoser: posted now
<smoser> thank you cjwatson
<cjwatson> Kubuntu alternate/desktop posted
<cjwatson> not sure how much more we can do until unity's fixed
<cjwatson> can somebody else take over whatever CD builds are needed and possible, and post them to the tracker?  see #ubuntu-devel (Amaranth etc.) for general state of unity, and keep an eye on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html for what images it's possible to build
<cjwatson> it's probably possible for somebody to do Xubuntu
<cjwatson> but I want to finish for the day now
<skaet> cjwatson,  I'll go in and start off Xubuntu then.
<skaet> jdstrand,  can you keep an eye on the natty_probs?
<jdstrand> skaet: sure
<jdstrand> fyi, probs is in pretty good shape except for libreoffice/oo.o (excluding armel, which, as stated before, is cranky)
 * jdstrand continues to keep an eye on it
<apw> is unity core dumping and dropping you into classic known with the archive as of half hour ago?
 * apw waves at skaet 
 * skaet refocuses back on this
<skaet> apw, yes,  we're treating this as a blocking issue for A2 right now for the release
<apw> skaet, sounds like you are goiong to be having fun
<skaet> apw, indeed.  :(
<apw> skaet, is there a bug number do you know, as i have an affected system it can be used to test
<skaet> apw, I've been snagging the bug numbers as I see them into the release notes,  see under desktop section.
 * skaet notes them now, and will work with desktop team to make them pretty tomorrow
<apw> skaet, where are the release notes :)
<skaet> ara,  https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<smoser> ok. i found a bug (bug 711480) in ec2 images testing
<ubot4> Launchpad bug 711480 in cloud-init (Ubuntu) "user-data scripts do not run (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/711480
<smoser> and would like to re-spin for it.
<smoser> so someone can take down the posted AMIs that cjwatson scrambled for me for.
 * apw_ switches to a test box which is at least working ...
<skaet> smoser, will do
<jdstrand> filed bug #711512
<ubot4> Launchpad bug 711512 in libreoffice (Ubuntu Natty) (and 1 other project) "[natty] libreoffice uninstallable: depends on ttf-sil-gentium-basic from universe (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/711512
<jdstrand> skaet: that ^ will affect DVD builds, but CDs should otherwise be ok
<jdstrand> at least, afaics
 * skaet looking
<jdstrand> ah yes
<jdstrand> well, it might be a recommends
 * jdstrand still looks
<skaet> jdstrand,  do we document, or will kicking off a new build pick it up?
<jdstrand> I haven't uploaded anything, I just discovered the issue. I am not sure it will prevent the DVD from building. it seems to be related to various spell checkers
<jdstrand> the dependencies are a bit swirly, let me keep looking
<pitti> jdstrand: these are recommends only, should be fine
<pitti> see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> ah, sorry
<pitti> ttf-sil-gentium is a recommends
<pitti> -basic isn't
<pitti> so that will cause trouble
<jdstrand> right
<jdstrand> I'm just trying to see what is pulling that in on natty_probs.html
<jdstrand> my crappy germinate grepper tells me:
<jdstrand>  ubuntu.natty/dvd: * myspell-de-de-oldspell # non-default alternative for language-support-de ubuntu.natty/dvd: * myspell-fr # myspell-fr-gut preferred
<jdstrand> meh
<jdstrand>  ubuntu.natty/dvd: * myspell-de-de-oldspell # non-default alternative for language-support-de
<jdstrand>  ubuntu.natty/dvd: * myspell-fr # myspell-fr-gut preferred
<jdstrand> so mysqll-fr has:
<jdstrand> dictionaries-common (>= 0.10) | openoffice.org-updatedicts
<jdstrand> oh, meh, openoffice.org-updatedicts isn't anywhere anyway
<jdstrand> and dictionaries-common seems ok
<ogra> did anyone trigger armel builds yet ?
<jdstrand> myspell-de-de-oldspell suggests openoffice.org
<jdstrand> it seems maybe it won't keep the DVD from building, if that is the only issue
<ogra> hmpf seems we have a problem with the armel builders and empathy ftbfs without producing a log
<ogra> lamont, any idea ?
<ogra> lamont, seems it always ends up on one of the new builders
 * ogra gives back again 
<lamont> ogra: yeah -give it back one more time now that the builders are happy again, and  I'll watch it
<ogra> k
<ogra> its on buttercup this time
<lamont> sorry about all the fail on that page, fwiw
<ogra> i dont care, the missing log was bothering
<ogra> the page is just icons :)
<lamont> heh
<ogra> lamont, still filed without log
<ogra> *failed
<lamont> ogra: yeah... smack it one more time
<ogra> done
<ogra> wohoo
<ogra> logs
<ogra> that looks better
<lamont> root cause identified and fixed then. :(
<ogra> k
<ogra> thanks for the quick fix
<ogra> pitti, are you driving antimony tonight ?
<skaet> xubuntu is now pushed out
<ogra> skaet, for arm we will have to wait until https://launchpad.net/ubuntu/+source/empathy/2.32.2-0ubuntu8/+buildjob/2237015 is finished and published
<skaet> ogra,  let me know when it publishes, and I'll kick off the builds.
<ogra> GrueMaster, can you watch it and tell skaet ? i actually planned to sleep at some point tonight
<GrueMaster> Can do.
<ogra> (or delegate to NCommander ;) )
<ogra> after he returned
<ogra> i hope thats the only package that slipped through
<skaet> thanks ogra, GrueMaster
<ogra> (would be really helpful if an uploader who uploads during a freeze could notify us about failed arm builds, i wouldnt have noticed it if GrueMaster hadnt just stumpled over it)
<ogra> i#m pretty sure ken got a mail for the buildfailure
<lamont> ogra: fwiw, I retried 14 builds from earlier today, some of those were natty/release
<lamont> 2236478 2236483 2236979 2236989 2237017 2237048 2237049 2237051 2237110 2237125 2237129 2237147 2237196 2237208 <-- to be specific
<lamont> http://launchpad.net/builders/+buildjob/$id
<lamont> those were all builds that retry-timed-out today, so they should all have been post-freeze uploads in any case
<lamont> and presumably are the ones you'd have been wondering about sometime between now and alpha2
<GrueMaster> skaet: Build finished successfully.  Awaiting publication.
<skaet> Thanks GrueMaster,  let me know when you see it published, and I'll add it in to the image build list.
<GrueMaster> ok.  I am monitoring from an earlier image to make sure dist-upgrade doesn't break on anything else.
#ubuntu-release 2011-02-02
<skaet> ubuntu desktop and alternate is up on the iso tracker now
<jdstrand> skaet: I'm past eod atm. is there anything you need from me now? do you need me to check in later?
<skaet> jdstrand,  if you could check in later that would be appreciated.
<skaet> right now, just flavor building images,  and waiting for the arm ones to be ready.
 * skaet -> dinner,  biab
<jdstrand> kdebindings/kde on armel update: depends on working qt4-x11, which is being worked on first
<jdstrand> (actively being worked on that is)
<jdstrand> skaet: ack
 * jdstrand -> dinner, etc
<ogra> jdstrand, if qt4-x11 is broken now it wont make a2 on armel
<ogra> (takes to long to build)
<jdstrand> ogra: I'm just passing along info from NCommander
<ogra> ah
<jdstrand> he is aware of both issues and is actively working on fixing qt4-x11
<ogra> we are expecting a new qt upstream any day now (according to riddell)
<jdstrand> once that is done, he'll start on kdebindings
<ogra> yes, i know i just talked to him about it ;)
<jdstrand> hehe
<jdstrand> well, there you go :)
<jdstrand> nice that we all understand each other
<ogra> heh
<jdstrand> ok, biab myself
<jdstrand> skaet: fyi, the dvd build issues should be fixed. seems they tried to snag empathy-common (= 2.32.2-0ubuntu7). empathy 2.32.2-0ubuntu8 on powerpc only finished building 45 minutes ago and the publisher hadn't copied them yet
<jdstrand> ok, biab for reals
<ogra> skaet, go !
 * ogra is off to bed
<skaet> ogra, okie.   sleep well.
<GrueMaster> skaet: I agree.  Everything looks good on this end.
<skaet> Thanks GrueMaster.   Am waiting for the ubuntu dvd build to come to an end, then will be kicking it off.
<GrueMaster> np.  I'll look for it in a few hours.
<skaet> :)  will post here when I publish to iso tracker.
<jdstrand> skaet: I am around again
<skaet> thanks jdstrand.
<jdstrand> skaet: it seems that things are going ok, but I am only getting failure reports so not sure what the actual status is
<skaet> we still had the daily builds enabled it appears.
<jdstrand> (the two I mentioned (powerpc) are the only feedback I've seen)
<skaet> they're off now,  and the ubuntu DVD just finished building.
<jdstrand> \o/
<jdstrand> so I was right about libreoffice. always nice :)
<jdstrand> well
<skaet> I'm about to kick off the netbook builds
<jdstrand> I was intially wrong, but then ended right
<skaet> and expect that if there is any trouble, that's where we'll see it.
<jdstrand> I score that as +1 for jdstrand
<skaet> :)
<jdstrand> skaet: how long do they typically take?
<skaet> suggest you check back in an hour or so
<skaet> I'm not sure on the arm side, depends on the builders.
<jdstrand> there are a lot of natty_probs for arm. mostly kde, but still a lot
 * skaet nods
<skaet> I'm not building kubuntu mobile this time round, based on earlier feedback.  Its already documented in the release notes.
<jdstrand> cool
<skaet> ubuntu dvd's are up on the iso tracker now, for those interested.
<GrueMaster> Sigh.  Latest X has issues on armel.  namely it segfaults on start.
<GrueMaster> Tracing it now.
<skaet> GrueMaster, ack. :(
<GrueMaster> yep.
<skaet> edubuntu dvd's are up on the iso tracker now.
<slangasek> skaet: bug #711614, if it doesn't break all hardware that uses the framebuffer driver, at least breaks X on all common ARM hardware.  Working on a fix now; do you want me to upload when I have it?
<ubot4> Launchpad bug 711614 in xserver-xorg-video-fbdev (Ubuntu) "X crashes on OMAP BeagleBoard C4 (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/711614
<skaet> slangasek, yes please.
<slangasek> ok
<slangasek> (it's possible it really is ARM-specific, but AFAICS the same segfault would happen in the PCI codepath)
 * skaet crosses fingers crossed its ARM-specific.
<slangasek> well, it doesn't affect anything using the common video drivers (nouveau/intel/radeon)
<slangasek> but I think it does affect anything using framebuffer
<GrueMaster> That could mean VM's I would think.
<slangasek> k, X working here again
<slangasek> xserver-xorg-video-fbdev 0.4.2-3ubuntu4 uploaded
<skaet> ubuntu-netbook preinstalled finished building,  20110202 is there, but I'm kicking off a fresh one, to pick up xserver-xorg-video-fbdev upload.
<GrueMaster> skaet: I don't think the new package has published yet.  May want to wait an hour.  Let me see.
<GrueMaster> Yea, need to wait for the next publisher run to complete before respinning the images.
<skaet> GrueMaster,  ack.  ok will kill it off.
<skaet> GrueMaster, please let me know when you see it published so it will pick up.
<GrueMaster> I think it will show up in the next hour.  I was told that the publisher starts at :03 and takes ~40 minutes.
<jdstrand> skaet: so, seems like things are in general still ok (except the xserver-xorg-video-fbdev you are waiting on)
<jdstrand> skaet: GrueMaster was right though. usually by :40 it is ready
<skaet> jdstrand, couple of weirdnesses with the builds
<skaet> jdstrand, I'll get you to show me how I can check directly next time :)
<jdstrand> GrueMaster: in the future, it is possible for me (or cjwatson, or pitti, et al) to reschedule the publisher run if it is required
<jdstrand> err
<jdstrand> skaet: ^
<jdstrand> GrueMaster: nm
<jdstrand> skaet: where did you see the weirdness? I don't have the emails
<skaet> in terms of the weirdnesses,  for flavors mythbuntu and ubuntu studio,  only i386 versions were produced.  Not sure why no amd64 came out.
<skaet> does that trigger any prior conversations?
<jdstrand> no... there are some myth nbs on powerpc..
<jdstrand> ah
<jdstrand> skaet: it looks like the amd64 ubuntustudio got a sigint
<jdstrand> KeyboardInterrupt
<jdstrand> ^ from germinate
<skaet> hmm,  user error on my part?  or something else....
<jdstrand> skaet: that was an email from antimony. I initially assumed it was intentional
<skaet> heh, was cutting and pasting, so ....
<jdstrand> skaet: was the mythtv run part of a longer command that included that?
<skaet> jdstrand, yea, I was trying to get all the flavors queued up
<jdstrand> that seems to explain it then
<skaet> ok, will kick them off again, and see if that fixes it.   doing it manually this time... :/
<skaet> have marked them in iso tracker as being rebuilt as well.
<jdstrand> cool
<jdstrand> skaet: at this point do you need more for anything? thinking I may head to bed. will be available at 7am or so
<jdstrand> s/more/me/
<skaet> thanks jdstrand.
<skaet> sleep well
<jdstrand> ok cool
<skaet> am expecting cjwatson will be online soon, and sort out what's left at this point.  :)
<jdstrand> skaet: try to get some sleep yourself. I'll check the logs first thing and see if I can do anything (assuming cjwatson and pitti don't get to it first)
<jdstrand> alrighty
<jdstrand> good night!
<skaet> :)
<jdstrand> skaet: oh, sorry. I just remembered that the 04:03 UTC publication run is pre-empted bye another job :\
<jdstrand> skaet: that means that the fbdev driver won't be ready until for another hour
<skaet> ok
<jdstrand> s/bye/by/
<GrueMaster> jdstrand: Thanks for the update.
<GrueMaster> Unfortunately, it doesn't appear to have hit the pool yet.
<jdstrand> GrueMaster: no, a little bit later I mentioned that the publisher is preempted at 04:03 UTC
<GrueMaster> Ah.  Missed that.
 * jdstrand forgot about that too
<jdstrand> anyhoo, heading off
<slangasek> -fbdev installed (at last)
<skaet> yup,  armel builds kicked off again.   Will leave it to cjwatson/pitti to move them into the iso tracker when they're ready.
<skaet> have rebuilt the ubuntu studio, and mythbuntu - and still only i386 images.
<skaet> have uploaded the i386 images to the tracker.
<skaet> pitti, see slangasek's comments about framebuffer ^^.    Should an image rebuild be triggered to pick up his fix beyond armel, or do we just document?
 * skaet --> bed
<pitti> Good morning
<pitti> ogra: sorry, went offline shortly before your ping
<pitti> skaet_afk, cjwatson: I don't think we need to respin non-armel for this if it doesn't hurt i386/amd64; having an out-of-date package isn't that important for a2 IMHO
<pitti> ogra, GrueMaster: I'm adding http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20110202/ as "Ubuntu ARM Preinstalled omap{3,4}"; are there any other armel images to add to the tracker?
<pitti> there's an "Ubuntu desktop armel", but I don't think we build images for that?
<apw> pitti, are we waiting for more fixes or is whats in the archive 'done' ... ie are any bugs in it something i have to live with
<pitti> apw: I guess we are "done", unless we have a real showstopper? what bug are you talking about in particular?
<apw> i suspect its one of the stacking in unity isues.  i think i have a modal dialog open which i can't see or interact with
<pitti> I think that's the kind of bug we need to release-note
<apw> plus for me non-working scroll bars in both places thingies
<apw> ok
<apw> i'll go moan on ayatana
<pitti> confirmed the scrollbar problem
<pitti> but at this point we should only respin for install failures or major startup failures
<pitti> everything else can be fixed post-install with an update
<persia> cjwatson, The power here is 10A/100V, and most stuff is unearthed (or only rarely and optionally earthed).  Perhaps it's a bit less odd when there's a special earthing clip for the wire at the base of the socket.  Sorry for the confusion.
<ogra> pitti, you will have to respin everything that uses the framebuffer driver, do VMs use vesa on intel ?
<ogra> pitti, and we would need 02.1, not 02 on the tracker
<pitti> does it matter which graphics card the VM host uses?
<pitti> ogra: oh, I thought skate already triggered new images, and 0202 is the latest we have
<ogra> its the X framebuffer driver thats broken
<ogra> no, she built 02.1
<pitti> anyway, current images work fine in kvm
<ogra> 02 has the broken X
<ogra> 02.1 is the respin after slangasek's fix
<pitti> ah, they appeared now, will update tracker; thanks!
<ogra> thanks too :)
<pitti> done
<pitti> ogra: so "Ubuntu desktop armel" doesn't exist any more, right?
<ogra> right
<ogra> we only have netbook-preinstalled
<ogra> there is a preinstalled headless (name still in discussion) coming for FF
<ogra> but not yet
 * ogra wonders where you see that desktop image
<pitti> ogra: it's an option in the "add image" in the tracker, from older releases
<ogra> ah, k
<ogra> i was digging on cdimage
<ogra> :)
<cjwatson> persia: heh, no problem
<cjwatson> pitti: catching up and I have a batch of notes from skaet.  What's the summary from your end at the moment?
<pitti> cjwatson: good morning
<cjwatson> psusi sent me a parted fix for dmraid, but I assume we've missed the boat?
<pitti> cjwatson: current armel images are on the tracker, rest should work
<cjwatson> ev is producing a new ubiquity upload for bug 702898
<ubot4> Launchpad bug 702898 in ubiquity (Ubuntu) "ubiquity crashed with TypeError in changed(): value is of wrong type for this column (affects: 21) (dups: 8) (heat: 110)" [High,Confirmed] https://launchpad.net/bugs/702898
<pitti> it was an open question whether to respin i386/amd64 for the fbdev fix
<pitti> but as it doesn't seem to break kvm etc., I don't think we should respin just for that
<pitti> cjwatson: ah, that sounds like a better reason for respinning then
<cjwatson> affects all users whose IP addresses are unknown to the geoip database, apparently
<cjwatson> the fix is a pair of str() casts
<pitti> I haven't done a real-iron test install myself yet with today's image (just with earlier ones), that's still on my agenda for today
<ev> slightly correction: it affects all users who cannot reach geoip-lookup.ubuntu.com
<cjwatson> whee, even better
<ev> or whatever the address is
<cjwatson> so any non-networked install for example
<ev> need more coffee
<ev> exactly
<cjwatson> any opinions on the parted change?  bug 711616
<ubot4> Launchpad bug 711616 in parted (Ubuntu) "[PATCH] Fix dmraid install regression (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/711616
<cjwatson> technically affects all images but I don't know that we have to care about them all being in sync
<pitti> the patch looks sane enough; does that get folded into the ubiquity source, or is it a separate package?
<cjwatson> separate
<pitti> I don't mind having out-of-sync packages for A2, so I'm fine with having it on every image we need to respin anyway, and document the rest
<pitti> e. g. I don't think we should respin armels for this
<ogra> only if it fixes an oem-config issue ;)
<ogra> we dont use plain ubiquity nor doe we use dmraid on preinstalled
<ogra> *do
<cjwatson> I wouldn't expect to see dmraid on armel, no
<ogra> i would
<cjwatson> blink
<ogra> but not by default
<cjwatson> on what kind of platform?
<ogra> people do weird things to run a NAS with USB disks ;)
<cjwatson> uploaded, anyway
<cjwatson> bizarre
 * ogra wonders how to download the images with the constantly segfaulting NM on his laptop
<cjwatson> mythbuntu desktop amd64 and ubuntustudio alternate amd64 posted
<cjwatson> pitti: ok, so which images do we need to respin for the new ubiquity+parted?
<cjwatson> pitti: * desktop {amd64,i386}?
<pitti> edubuntu DVD as well, I suppose?
<pitti> ubuntu and edubuntu DVDs didn't get testing yet anyway
<cjwatson> yeah, DVDs too
<pitti> I can't see anything else
<cjwatson> OK, I'll get started on those
<pitti> ok, thanks
<cjwatson> ev: does oem-config use the geoip selector?
<cjwatson> I'm not desperately inclined to respin alternates, maybe we can just release-note
<pitti> the workaround would be to disable the network during oem-setup?
<cjwatson> enable, I think
 * cjwatson queues up giant build set
<cjwatson> echo ubuntu desktop; buildlive ubuntu daily-live && for-project ubuntu cron.daily-live && build-chinese-edition /srv/cdimage.ubuntu.com/www/full/daily-live/current/natty-desktop-i386.iso; echo kubuntu desktop; buildlive kubuntu daily-live && for-project kubuntu cron.daily-live; echo xubuntu desktop; buildlive xubuntu daily-live && for-project xubuntu cron.daily-live; echo mythbuntu desktop; buildlive mythbuntu daily-live ...
<cjwatson> ... && for-project mythbuntu cron.daily-live; echo kubuntu-mobile; buildlive kubuntu-mobile daily-live && for-project kubuntu-mobile cron.daily-live; echo ubuntu dvd; buildlive ubuntu-dvd dvd && for-project ubuntu cron.dvd; echo edubuntu dvd; buildlive edubuntu-dvd dvd && for-project edubuntu cron.dvd; echo kubuntu dvd; buildlive kubuntu-dvd dvd && for-project kubuntu cron.dvd
<cjwatson> I'm archiving jaunty off cdimage and releases to save space
<ev> cjwatson: yes
<cjwatson> ev: would you be OK with release-noting that problem for oem-config?
<ev> sure
<ev> after lunch, if that's okay
<cjwatson> oh, yeah, I just mean OK with not respinning for it
<ev> ah, indeed
<ev> done
<ev> feel free to reword that if its not to your liking
<Riddell> where are the release notes?
<ev> https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<didrocks> hey
<didrocks> so, I have a fix for a compiz crash at start some people seem to get
<didrocks> (bug #708812)
<ubot4> Launchpad bug 708812 in compiz (Ubuntu) "compiz crashed with SIGSEGV in CompOption::value() (affects: 4) (dups: 2) (heat: 28)" [High,Triaged] https://launchpad.net/bugs/708812
<didrocks> is there a respin schedulded?
<cjwatson> there's one in progress
<cjwatson> there is not currently another scheduled
<cjwatson> certainly looks like you should upload that anyway and we'll see what happens
<didrocks> ok
<cjwatson> oh, hmm
<cjwatson> compiz has fairly tight versioned dependencies and is an arch all/any mix
<cjwatson> so buildd skew could break one of the respins in progress
<cjwatson> let's see, how long does it take to build?
<didrocks> cjwatson: ok, so I can wait for the respins to be finished
<didrocks> cjwatson: where should I monitor that? iso.qa ?
<cjwatson> mm, takes over an hour on armel, so no way to reliably squeeze it in
<cjwatson> there's no good monitoring really, I'll have to just tell you
<didrocks> ok, just ping me please then when you think it's safe
<cjwatson> actually, mind you, I'm not doing any armel respins at the moment, and everything else takes <30 minutes
<cjwatson> didrocks: if you go ahead right now I believe it should be safe
<didrocks> cjwatson: excellent, doing it now then. Thanks :)
<cjwatson> (because all of amd64/i386/powerpc will build before the next publisher run)
<cjwatson> and all the distro buildds are currently idle
<stgraber> cjwatson: what's part of that respin ?
<didrocks> ok, nice to get that fix soon :)
<cjwatson> stgraber: ubiquity fix upon failure to contact geoip; parted fix for broken dmraid installations; um, whatever else was in the archive
<stgraber> cjwatson: ok, so that's going to affect all desktop builds ? shouldn't they be disabled on the tracker ?
<cjwatson> it's such a hassle to go around clicking all the buttons
<cjwatson> done now
 * pitti disables ubuntu desktops as well
<pitti> ah, actually, are they current already?
<pitti> 13:33 UTC
<pitti> checking manifest..
<stgraber> marjo: Speaking of the tracker ;) Could you check on which machine it's running now and see if I can get my ssh access restored ?
<pitti> they are, sorry; reenabling
<stgraber> marjo: I lost access to it on Lucid's release week when it was moved to another box. I used to have ssh access with sudo rights to the "db" user to access the postgresql DB and run some scripts.
<marjo> stgraber: ok, will do
<cjwatson> pitti: yes, they were current
<cjwatson> Kubuntu desktops posted now too
<Riddell> thanks
<pitti> uh -- "ubiquity[2970]: segfault at bbadbeef ... in libwebkitgtk-1.0.so.0.5.2
<cjwatson> that came up before
<pitti> not only is this unfortunate, it's also a really snarky address to crash at
<cjwatson> bug 710852
<cjwatson> err
<cjwatson> bug 710582
<ubot4> Launchpad bug 710582 in yelp (Ubuntu Natty) (and 5 other projects) "webkit does not implement "assert" sanely (ubiquity crashes after step 'Who are you', yelp segfaults) (affects: 4) (dups: 2) (heat: 30)" [Undecided,New] https://launchpad.net/bugs/710582
<pitti> ah, thanks
<pitti> I guess I'll release-note that then
<cjwatson> ev: is there a way to disable the slideshow at run-time or boot-time?
<ev> you can always uninstall the package
<cjwatson> mm, I was hoping for something release-notable
<smoser> cjwatson, can you populate tracker from http://uec-images.ubuntu.com/server/natty/20110202/published-ec2-daily.txt please
<cjwatson> smoser: done
<jibel> pitti, whats your cpu ? I can reproduce the crash on anthenticAMD but not on Intel.
<smoser> cjwatson, or someone...
<smoser> so i click on one of those amis
<smoser> http://iso.qa.ubuntu.com/qatracker/test/4959
<smoser> then click on one of the tests
<smoser> and there is no where to record anything
<smoser> ie: http://iso.qa.ubuntu.com/qatracker/result/4959/549 is blank
<smoser> stupid user
<smoser> login, smoser.
<smoser> (sorry for the wasted bytes)
<skaet> smoser, np
<stgraber> skaet: what page do I update to release note something ? I'd like to release note LTSP as non-working for Edubuntu and Ubuntu Alternate
<pitti> cjwatson: that should be possible in the live system, though; apt-get purge ubiquity-slideshow-ubuntu actually works, ubiquity just looks rather funny then (small window)
<skaet> stgraber: https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<apw> stgraber, whats the blocker on that?
<pitti> skaet: good morning
<stgraber> - the new nbd-client that somebody merged last week gets stuck on I/O wait when connecting for the second time to the same server (blocking login)
<stgraber> - calling /etc/X11/Xsession fails as gnome-session needs a parameter now
<stgraber> (calling only "/etc/X11/Xsession" should start the "default" session and not just say "No valid session found")
<skaet> pitti, good afternoon,  from the logs looks like the fun has continued since last night...
<stgraber> didrocks: ^ (as you're around ;))
<didrocks> stgraber: on a call, will look at it then :)
<cjwatson> pitti: yeah, though it's not really a graceful workaround
<pitti> cjwatson: right, but at least it gets you further; test install still running, if it succeeds, want me to release note it?
<cjwatson> yep - if it only happens on amd64, that's interesting too
<pitti> my i386 test install went fine, but that was without internet (broadcom wifi on the dell mini)
<pitti> this amd64 run is in kvm
<pitti> but as the slideshow shouldn't access the network, that's hopefully not a factor
<cjwatson> you hope.  who knows what webkit does :)
<pitti>  well, webkit might try to fetch something
<cjwatson> but yeah
<pitti> extra CSS or whatnot
<cjwatson> xml schema
<pitti> I'll test i386 in kvm afterwards to check
<pitti> and amd64 without network as well
<pitti> jibel: cpu> crash was in kvm
<pitti> jibel: intel atom (netbook) i386 worked
<stgraber> skaet, didrocks: bug 707232 (initially reported by linaro, added ubuntu task and set gnome-session as the package for now)
<ubot4> Launchpad bug 707232 in gnome-session (Ubuntu) (and 1 other project) "Netbook image - no valid session found (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/707232
<skaet> stgraber,  thanks!
<stgraber> skaet: nbd issue is bug 711951
<ubot4> Launchpad bug 711951 in nbd (Ubuntu) "New nbd-client hangs when connecting a second time to a server (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/711951
<pitti> cjwatson: I confirmed that it's unrelated to the network and amd64 specific, and that purging slideshow works; documenting..
<cjwatson> thanks
<didrocks> stgraber: hey
<stgraber> didrocks: hi
<didrocks> stgraber: so, it doesns't need a parameterâ¦ the default should still be called without one, isn't it?
<stgraber> didrocks: currently some systems including LTSP start: "/etc/X11/Xsession" without any parameter an expect the default session to open
<stgraber> didrocks: calling that basically starts "gnome-session" still without parameter
<stgraber> didrocks: which currently fails
<didrocks> stgraber: interesting, let me have a look
<didrocks> one sec
<stgraber> I'd expect "gnome-session" without any parameter to start whatever should be the default, so probably unity and falling back to classic if unity doesn't work on the hardware (quite likely with LTSP)
<pitti> didrocks, seb128: I brushed up https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview a bit now; do you have suggestions what to add to the "desktop" section or notable known bugs in compiz/unity which should be documented?
<didrocks> stgraber: oh you're right
<didrocks> pitti: yeah, I'll add some crashes and issues with unity
<didrocks> pitti: will do it before EOD
<pitti> didrocks: merci
<didrocks> pitti: yw :)
<didrocks> stgraber: so, ok for ubuntu.session for being the default when calling it with nothing?
<didrocks> stgraber: I'll add a patch, can you file a bug, please?
<didrocks> (I'll report the handing to upstream as well)
<stgraber> didrocks: bug 707232
<ubot4> Launchpad bug 707232 in gnome-session (Ubuntu) (and 1 other project) "Netbook image - no valid session found (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/707232
<seb128> didrocks, thanks
<apw> stgraber, ok if its in D there may be a kernel interaction ... i've requested some debugging in your bug (ndb one)
<didrocks> stgraber: thanks :)
<seb128> pitti, I will let didrocks list those, no need to duplicate the work, not sure the jockey issues are worth mentioning
<pitti> seb128: I don't think so; nvidia/fglrx are now disabled anyway, and broadcom can be installed from the installer
<stgraber> apw: ok, I saw a recent upload of nbd-client so thought it might be that, but nbd.ko can also be the problem (or the interaction between nbd-client and nbd.ko)
<pitti> seb128: but then again I didn't see the crash; if it's prominent, I'm happy to add it
<apw> stgraber, indeed, either could be at fault, knowing what the client is trying to do when it locks may help, which is what i am asking for :)
<didrocks> cjwatson: pitti: btw, no respin scheduled for now? (just to know if I need to report the crash at startup or not in the TechnicalOverview)
<cjwatson> didrocks: I don't at present but am willing to be overruled ...
<cjwatson> since skaet's up now I reckon it's her call
<pitti> didrocks: not scheduled for other reasons, anyway
<seb128> pitti, ok, I was not sure if that was a "crash for everybody after install" or not
<didrocks> ok, I'll mention it for now
 * skaet emerging back from release note... and scanning log
<seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/711225 I mean
<ubot4> Launchpad bug 711225 in jockey (Ubuntu) "jockey-gtk crashed with TypeError in _cleanup(): an integer is required (affects: 1) (heat: 10)" [Undecided,New]
<pitti> seb128: it looks like a corner case to me; I thought you meant bug 706193
<ubot4> Launchpad bug 706193 in jockey (Ubuntu Natty) (and 1 other project) "jockey-gtk crashed with AttributeError in __getattr__(): 'gi.repository.Gtk' object has no attribute 'ICON_LOOKUP_USE_BUILTIN' (affects: 22) (dups: 21) (heat: 180)" [High,In progress] https://launchpad.net/bugs/706193
<seb128> pitti, ok, I've no clue about the crash, just that jockey doesn't start on my alpha2 test install
<seb128> pitti, if that's a corner case great
<pitti> bah, compiz focus issues are driving me mad
<stgraber> apw: ok, updated bug report with some more info
<stgraber> apw: I'm rebooting my VM now and will try the old nbd-client to see if that fixes/workaround the problem
<apw> didrocks, i think i just got your new compiz ... had a working compiz on login 5/5, as against about 1/4 before
<didrocks> apw: nice, that was the goal TBH :)
<apw> didrocks, :)  thought you should know
<didrocks> apw: thanks for the feedback, nice to have some good news in this crashing time ;)
<apw> didrocks, i now am seeing huge delays starting indicators about 1/4 ..
<apw> stgraber, good thanks
<didrocks> apw: if you try to killall unity-panel-service? does it fix it? (no hurry though)
<apw> didrocks, they come eventually I'd say between 30s and 60s (not measured it) just not 'immediate' like normal
<didrocks> apw: yeah, try kill this service (it will respawn) in that case, juste to ensure it's the unity or the indicator side
<apw> didrocks, will do that next time it occurs
<didrocks> sure :)
<apw> stgraber, could i get the whole dmesg please
<stgraber> apw: going to boot a livecd to reproduce it instead, I just trashed my VM by force rebooting it too much (last initrd is probably half-synced to the disk so it won't boot)
<apw> stgraber, ok thanks, i suspect this is a kernel locking issue from the dump you have in there
<stgraber> using the old client didn't help, haven't tried the old server yet but I don't think it'd change anything
<apw> stgraber, want to know if there is anything before that .... feel free to move this discussion over to #ubuntu-kernel as we are likely spamming release here
 * cjwatson posts xubuntu desktop and mythbuntu desktop.  sorry for being tardy on those
<cjwatson> ubuntu dvd, edubuntu dvd, and kubuntu dvd are still in the pipeline; please could somebody post those when they're done?  I need to go out
<stgraber> I'll do it
<cjwatson> thanks
 * Daviey wonders if the release team would slap Daviey with a wet trout if he suggested a Eucalyptus upload for A2.
 * skaet has hands full with unity foo. 
<skaet> Daviey,  what's it fixing?
<Daviey> skaet, FTBFS, ability to start instances and a security fix.
 * apw hands skaet the biggest trout in his lake
<Daviey> skaet, The current UEC experience is weak, making A2 somewhat pointless benchmark for it.
 * skaet accepts trout from apw - contemplating roasting it rather than throwing it around though...
<skaet> Daviey,  ok, lets add it into the queue for rebuilds, and call off QA on those images.
<skaet> don't think they've gotten too far.
<Daviey> skaet, great!  thanks
 * Daviey munches on trout.
<skaet> let me know when the uploads are done, and we're ready to kick off the rebuilds (ie, package has landed and available)
<Daviey> skaet, wilco, thanks
<seb128> skaet, https://bugs.launchpad.net/ubuntu/+source/ubuntu-sso-client/+bug/708018
<ubot4> Launchpad bug 708018 in ubuntu-sso-client (Ubuntu) (and 1 other project) "ubuntu-sso-login crashed with IndexError in prompt_handle(): list index out of range (affects: 2) (dups: 1) (heat: 18)" [High,Triaged]
<seb128> skaet, you might want to add this one to the notes
<seb128> pitti, ^
<seb128> it's basically ubuntu-sso-client crashing on autologin accounts (or livecd)
<seb128> the u1 guys are working on it now
<skaet> pitti, could you see if you can nudge getting unity available for the iso builds?  https://launchpad.net/ubuntu/+source/unity/3.4.0-0ubuntu2
<seb128> skaet, it failed to build
<seb128> didrocks, ^
<pitti> re
<seb128> http://launchpadlibrarian.net/63367725/buildlog_ubuntu-natty-i386.unity_3.4.0-0ubuntu2_FAILEDTOBUILD.txt.gz
<didrocks> oh? didn't get email this time :/
<seb128> didrocks, guess that needs the fix you commited earlier today
<didrocks> argh, the glu one with the new glew :/
<didrocks> ok, let's forget about unity then, needs a glew upload for proper fixâ¦
<skaet> didrocks, ok can you please add the comments to the release notes about this?
<didrocks> skaet: about the migration tool crash at start? sure
<skaet> didrocks, yup.  thanks!
<pitti> seb128: ah, because it doesn't unlock the keyring?
<pitti> seb128: happy to add that to the RNs
<seb128> pitti, because they use the login keyring but there is none of those in an autologin session
<pitti> right
<Daviey> pitti, Do you have LP foo to make a package build higher priority?
<pitti> seb128: I wonder why it doesn't crash on the live session? do we have a casper script to disable this?
<pitti> Daviey: yes
<pitti> "fu" anyway :)
<pitti> Daviey: which one do you need bumped?
<pitti> seb128: ah, will add after didrocks is done editing
<Daviey> Pici, would you might bumping https://launchpad.net/~davewalker/+archive/uec-testing/+buildjob/2238876 , it would make it easier for hggdh to test before it's uploaded to the archive.
<Daviey> err, pitti
<didrocks> pitti: will tell you once finished
<pitti> done
<seb128> pitti, it does crash on the livecd
<Daviey> pitti, thanks!
<seb128> pitti, did you try to authentificate on the live session?
<pitti> seb128: not to U1
<Daviey> dammit... okay skaet - it's still failing to build, i thought we had this fixed and it is not.
<didrocks> pitti: done, I'll complete on the desktop part a little later
<Daviey> perhaps it would be better to ship A2 with a known broken version, taking the pressure off to get a fix in apt-get upgrade away... What are your thoughts?
<pitti> didrocks: hm, I still get a "locked" message
<didrocks> pitti: hum? I'm on the preview page
<didrocks> (the one after saving)
<pitti> ah, works now
<didrocks> maybe I pong you before wikimoinsmoins finishes its saving
<stgraber> Ubuntu DVD is ready for testing
<skaet> Daviey,  its an A2, so just document it *really* well, so folks don't waste time.
<skaet> stgraber,  sweet.  thanks.
<Daviey> skaet, ok, thanks.
<ogra> Daviey, as long as it works on arm we wont complain :)
<Daviey> ogra, good luck with that... let us know when we have kvm on arm :)
<skaet> ogra, how are the images from last night looking?
<ogra> ogra@ac100:~$ apt-cache show eucalyptus-cloud|grep Architecture:
<ogra> Architecture: armel
<ogra> Daviey, you mean that wouldnt work !?!
<ogra> skaet, all fine
<Daviey> ogra, Ohhh, sure eucalyptus works.... but you can't start instances :)
<ogra> you really need to fix that !!!
<ogra> *g*
<Daviey> ogra, Okay, i'll port kvm to arm before i go to bed tonight :)
<ogra> thanks, i'll ping you tomorrow :)
<skaet> ogra, cool.   Could you go to the release notes, and add the features you want highlighted for this release then.  :)
 * ogra will go to bed early today :)
<ogra> skaet, i went over them already, we dont have anything to highlight until unity-2d is on the images
<ogra> they currently dont differ from maverick
<Daviey> ogra, nn :)
<ogra> heh
<skaet> ogra,  thanks.
<ogra> A3 will be our big one :)
<ogra> with lots of blogging and screenshots
 * skaet hopes that all testing will be done *early* in the cycle. 
<ogra> and indeed with the eucalyptus port from Daviey included by default ;)
<ogra> skaet, fully agreed and i was hoping we could get it on the A2 images, but a Qt bug prevents us from it ... there is no way we ship a desktop where half the apps segfault
<skaet> ogra, *agree*
<ogra> unity-2d itself is ready :(
 * ogra is really sad that we cant ship it yet
<Riddell> are kubuntu DVDs going to appear at some point?
<stgraber> they should. I'm monitoring cdimage to check when edubuntu and kubuntu appears
<stgraber> edubuntu seems to be building at the moment, kubuntu should be next
<GrueMaster> skaet: Unless there is a dire need to respin, omap/omap4 image testing is done.  No critical/high/medium issues.
 * ogra lols about Bug 711968
<ubot4> Launchpad bug 711968 in ubiquity (Ubuntu) "[natty] Installer suggests "Not-Available" as computer name (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/711968
<ogra> did nobody tell marc about the new empathy integration of the installer ?
<GrueMaster> I don't think he's available for comment.
<skaet> GrueMaster,  thanks!  there are reasons to respin, but its unlikely we'll be getting the fixes in time.  So we'll be going with these images.
<GrueMaster> Oh?  What issues?
<GrueMaster> Other than the ubiquity fixes (which I have tested).
<skaet> GrueMaster,  unity changes and eucalyptus ones,  shouldn't be impacting you.
 * skaet was using images in context beyond arm ;)
<GrueMaster> Nope, neither one does.  Unity is in the images but won't run w/o 3D acceleration and eucalyptus isn't in the image.
<skaet> stgraber, any update on the edubuntu dvds?  you posting?
<stgraber> skaet: oops, Edubuntu meeting ;) I guess they just showed up, weren't there 10mins ago. Adding them now.
<skaet> stgraber, sweet.  Thanks!
<highvoltage> anyone else available to look at Edubuntu amd64?
<highvoltage> The installer window just completely dissappears for me after I enter the user details and click next
<highvoltage> seems to be fine on i386 though. it's under kvm so it could perhaps just have something to do with that
<skaet> highvoltage, we've got some real nastiness going on with amd64 (see: https://launchpad.net/bugs/710582).  Is yours possibly related?
<ubot4> Launchpad bug 710582 in yelp (Ubuntu Natty) (and 5 other projects) "webkit does not implement "assert" sanely (ubiquity crashes after step 'Who are you', yelp segfaults) (affects: 5) (dups: 3) (heat: 40)" [Undecided,New]
<charlie-tca> skaet: updated release notes
<skaet> charlie-tca, thank you! :)
<highvoltage> skaet: yep, that's it
<skaet> thanks highvoltage,  can you add your info to the log of the bug then.
<highvoltage> skaet: ok, will do
<skaet> :)
<charlie-tca> skaet: I need to add wording to the workaround for the ubiquity bug. In Xubuntu, you open a terminal (shortcut does not work), then purge "ubiquity-slideshow-xubuntu"
<skaet> charlie-tca, go ahead.  (and thank you)
<charlie-tca> Thanks
<smoser> skaet, EC2 images are tested
<smoser> pre-publishing is in progress
<smoser> images still need to be tested on UEC, but would really be surprised to see a failure there.
<skaet> smoser,  cool.  Thanks!
<slangasek> lamont: gourd runs out of memory trying to build qemu-linaro for armel :(
<slangasek> lamont: should we build qemu under qemu?
#ubuntu-release 2011-02-03
<cjwatson> I think we'd best release-note that btrfs installations are busted :-/
<cjwatson> bug 712029, plus it turns out that systems don't work very well when / is mode 0700
<ubot4> Launchpad bug 712029 in ubiquity (Ubuntu) "ubiquity btrfs install fails to boot (grub rescue> prompt) (affects: 1) (heat: 6)" [Undecided,Triaged] https://launchpad.net/bugs/712029
<cjwatson> fixed the latter, not quite sure what's going on with the former yet
<lamont> slangasek: if 30.5GB is insufficient to build it, I'm going to assert that there's a bug...
<lamont> (all of the armel buildds have 512MB RAM and 30GB swap
<lamont> )
<slangasek> lamont: hmmmm
<skaet> cjwatson, pitti, (and anyone else who's interested) can you please take a pass through https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview, and add any key bugs I may have overlooked.
<pitti> Good morning
<pitti> skaet: yep, will do; already had some passes yesterday, but will beautify and add more bugs from the iso tracker
<Riddell> do we have an ETA on release?  I still have DVDs to test and notes to write
<pitti> Riddell: I guess we won't release before skaet wakes up again
<pitti> so still plenty of time
<pitti> skaet: I went through the current "serious" bugs on the tracker, they are now all on TechnicalOverview; the "what's new in desktop" part is now signed off, too
<jibel> Riddell, I'm syncing kubuntu amd64 dvd, but I can not guarantee that I'll be able to test i386 as well, can you or some else take care of it ?
<Riddell> jibel: yes I'm onto it, thanks
<pitti> victorp, ara, cjwatson: good news! I just moved the last lucid package which affects media builds to -updates (i. e. all main packages except the new ubuntu font)
<pitti> so I wonder whether we should switch the lucid daily builds to -updates now?
<pitti> would be better for testing what we will actually release
<pitti> and in theory we could also unfreeze lucid-proposed then (but freeze -updates instead)
<ara> \o/
<ara> it sounds good to me, we are always testing the latest build anyway
<pitti> actually the lucid daily builds were disabled anyway; perhaps as an unintended side effect of disabling daily natty builds, perhaps because of something else; I'll wait for cjwatson/skaet before I re-eneable them and drop the PROPOSED=1
<cjwatson> I suspect that was unintended
<cjwatson> I'll deal with dropping -proposed, there are a few places where it needs to be tweaked
<pitti> ah, thanks
<pitti> where else, OOI?
<cjwatson> cdimage run-germinate, debian-cd CONF.sh, the crontab
<cjwatson> stgraber: (or whoever did it) thanks for posting the DVDs
<cjwatson> pitti,ara: lucid daily builds re-enabled from -updates
<pitti> ah, thanks
<cjwatson> next build will be tomorrow
<ara> cjwatson, thanks!
<highvoltage> is there any verdict on the amd64 isos yet? is there going to be a respin or will it pass with a workaround note?
<pitti> highvoltage: a respin would only be an option if we had a real solution, but we don't
<pitti> highvoltage: we currently documented the workaround on the tech overview
<highvoltage> pitti: ok
<ogra> are we there yet ?
<ogra> :)
<mvo> is a xserver-xorg-video-intel_2.14.0-1ubuntu6_source.changes upload ok at this point? fixes a anoying UI corruption
<mvo> (I guess it is, just want to double check)
<cjwatson> yes, I think that is OK - it won't be picked up unless we have another reason to respin
<mvo> thanks
<highvoltage> I passed the edubuntu amd64 iso with a note explaining that the ubiquity-slideshow-edubuntu package needs to be removed before installation and that that will have to go into the release notes since there's no current fix available for the webkit problem
<ScottK> The Kubuntu upgrade tests are missing off the ISO tracker.
<ScottK> I don't think it should affect this milestone, but it'd be good to get it fixed for Alpha 3.
<pitti> ScottK: they are present in the "add build set" options
<pitti> ScottK: do you still want them added for a2?
<ScottK> pitti: It wouldn't hurt, but I wouldn't delay anything based on if they get done or not.
<pitti> ScottK: added
<pitti> I agree
<ScottK> pitti: Thanks.
<pitti> "Known issues" in https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview has become quite long this time, smells like a new record
<pitti> cjwatson, skaet: it seems that despite those ^ we aren't going to respin, I figure? can we lift the freeze now? (#u-desktop folks are getting eager..)
<cjwatson> pitti: I'd like to have skaet's ack - I'm just a flunky here
<skaet> good morning all
 * skaet scanning back
<skaet> pitti, cjwatson,  don't see any reason not to lift the freeze now.   Its pretty clear that the images we have now are the one's we'll be going out with.
<pitti> hey skaet, good morning
<pitti> skaet: ok, thanks
<pitti> skaet: want me to update #u-devel topic?
<skaet> pitti, yes please.  :)   we need to work through the rest of today's checklist as well.
<pitti> skaet: who is doing the publishing of the images?
<pitti> cjwatson: ^ are you, or should I start now?
<skaet> pitti,  you're down for this release in the task sheet, so go ahead.   unless cjwatson *wants* to. ;) ?
<pitti> ack, turning the crank then
<cjwatson> I don't want to :)
<pitti> skaet, ogra: https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview doesn't currently link to http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-2/ for armel; is that deliberate because they don't work, or want me to add it?
<skaet> pitti,  please add, its an oversite.
<skaet> no images were available for A1, and this was a cut paste from that.    good catch.
<pitti> skaet: well, actually we do have http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-1/
<pitti> skaet: they might have been broken and thus not announced, of course, I don't remember any more
<ogra> pitti, please add
<ogra> arm images are good
<skaet> pitti,  they weren't available when the announce came out last time
<skaet> showed up later.
<pitti> https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview -> done; looks ok?
<skaet> still gathering a few more tweaks, but pretty close at this point.
<pitti> smoser: "Publish the milestone UEC images on uec-images.ubuntu.com" -> can you please do that?
<smoser> pitti, make them public, right ?
<pitti> smoser: yes
<pitti> smoser: I'm currently publishing all other images; they are as good as they are going to be for a2
<smoser> in progress... its ~ a 10 minute operation.
<stgraber> skaet: I just noticed that my two LTSP entries were at the wrong place on TehcnicalOverview, moved them to the Known issues now
<ogra> are we there yet ?
<ogra> :)
<skaet> stgraber,  thanks!
 * pitti feeds the rsync hamsters to pedal faster
<smoser> uec-images published: http://uec-images.ubuntu.com/releases/natty/alpha-2/
<pitti> smoser: cheers
<skaet> cjwatson,  with the perm changes, I don't seem to be able to update the alpha-2 milestone to make it inactive,  can you handle?
<pitti> hm, I can't either; is that actually necessary? the due date is already past
<pitti> ah, but I can still target buts to that, it is still active then
<skaet> yeah, don't want folks assigning bugs to it
<skaet> :)
<pitti> ah, it's not on /ubuntu/, you need to click on the milestone page
<pitti> skaet, cjwatson: a2 milestone set to inactive
<skaet> pitti, thanks!
<bdmurray> Are there any release for Alpha 2?  I was looking at bug 655950 and thinking about having it in there.
<ubot4> Launchpad bug 655950 in ubiquity (Ubuntu Natty) (and 3 other projects) "Maverick ubiquity confusion w/ auto-resize option results in OS and data loss (affects: 18) (dups: 2) (heat: 105)" [High,Confirmed] https://launchpad.net/bugs/655950
<cjwatson> https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<skaet> bdmurray, ^^  feel free to add
<highvoltage> skaet: I updated http://edubuntu.org/2011-02-02/edubuntu-1104-alpha-2-released (that's not linked to from anywhere yet) to indlude the amd64 bugs, just in case you copy and pasted that to anywhere
<highvoltage> skaet: ah, I see the technical overview page links to it, I'll just update the link since the date will change
<skaet> highvoltage, thanks!
<bdmurray> skaet: done
<skaet> bdmurray,  thanks!
<cjwatson> I've added skaet to ~ubuntu-release, FWIW
<cjwatson> it seems silly not to at this point
<pitti> rsyncing is a little on the slow side today, I guess it will still take some 15 mins
<skaet> Riddell,  changes for Kubuntu look good.   Thanks!
<pitti> skaet: FYI, we seem to have a problem with some of the cdimage mirrors, IS is investigating
<pitti> can anyone else see the images in http://cdimage.ubuntu.com/ubuntustudio/releases/natty/alpha-2/ ?
<pitti> they flip between "empty page" and "works" for me
<charlie-tca> looks like a complete page to me
<pitti> seems to stabilize now
<pitti> it's rsyncing the last folder now, xubuntu
<pitti> http://cdimage.ubuntu.com/xubuntu/releases/natty/alpha-2/
<pitti> amd64 is there
<pitti> skaet: do you know if http://www.ubuntu.com/testing/download still needs to be updated? It currently leads me to a German mirror with a rather ugly page of the cdimage root fs (not to alpha-2 images)
<skaet> pitti,  yes, I believe newz2000 is waiting for the signal from us.
<skaet> will go ahead and ask him now.
<pitti> skaet: ok, steps 1, 2, 3, and 5 done now (in "Release day" section)
<skaet> :)
<pitti> skaet: with "verify" all but above link
<pitti> I also tried 6 (check torrents), but all I get is a "Requested download is not authorized for use with this tracker"
<pitti> but then again I never really used torrents
 * pitti fixes a formatting error on the RN
<cjwatson> pitti: IS often need to restart the torrent tracker to make it stop sucking
<pitti> I'll ask
<skaet> pitti, asked newz2000 to get step 7 going (/testing/download),  waiting to hear back.
<highvoltage> I'm just going to make a quick change to the wiki page (will be out of it quick again)
 * skaet added mythbuntu link, was missing from announce
<skaet> highvoltage, let me know when you're out,  couple more bugs to add.
<pitti> skaet: do you need me for anything urgent? if not, I'd like to make some dinner
<highvoltage> skaet: fire away
<skaet> pitti, enjoy your dinner.   Look in your inbox for draft of the announce when you finish dinner,  would like your eyes on it before I hit send.  :)
<pitti> skaet: ack, will do
<pitti> skaet: or just pastebin it and put the URL here
<skaet> pitti, ack
 * skaet -> lunch, biab
 * skaet back
<skaet> pitti, cjwatson - http://paste.ubuntu.com/562153/  any changes you recommend?
<pitti> food is in the oven, looking
<pitti> skaet: the verbatiim paragraph for XFCE at http://www.ubuntu.com/testing/natty/alpha2  looks bad
<pitti> I suggest to remove the ``` and just make it a normal paragraph
<pitti> http://paste.ubuntu.com/562153/ looks fine to me
<skaet> pitti,  yeah, there are some other formating issues I've hightlighted to Matt.   Will go in and edit it.   He'll be refreshing later.   I'm still trying to figure out if we can get the /download/testing working - most of the mirrors haven't picked up Natty yet.
<pitti> skaet: I don't think they are supposed to
<pitti> alphas are traditionally downloaded from cdimage.u.c.
<skaet> ahhh... that would explain it.
<skaet> in the announce I switched it over,  will do so in the TechOver as well then.
<pitti> skaet: right, that works better
<pitti> skaet: perhaps put them into the same paragraph then?
<pitti> http://cdimage.ubuntu.com/releases/natty/alpha-2/ together with the others?
 * skaet nods
<skaet> it will be better that way if its not a separate site this time.
<skaet> done on announce,  will do on TechOver next.
<highvoltage> skaet: Can we release Edubuntu Natty Alpha 2 yet?
<skaet> highvoltage,  web page needs an update before I send out announce.
<lamont> just fyi - ppa builder maintenance is going to look like a rolling blackout
<highvoltage> skaet: ok
<skaet> highvoltage, if I don't hear from newz2000 in next hour, I'll send out announce, and let him update the web page with the details later.  Some bad formating on page right now.
<highvoltage> skaet: I'm correct in correcting Amber that the alpha isn't released, right? http://www.ubuntu-user.com/Online/Blogs/Amber-Graner-You-in-Ubuntu/Ubuntu-Natty-Narwhal-Alpha-2-Released-Today
<skaet> highvoltage, you're correct.   It will be though.
<charlie-tca> OMG! Ubuntu announced is hours ago
<charlie-tca> s/is/it
<skaet> heh, fun of open development.
<highvoltage> charlie-tca: yeah, they always jump the gun, at least no one takes OMG Ubuntu seriously anymore :)
<skaet> ok, will send out the announce, and let newz2000 do the update later
<pitti> good night
<charlie-tca> true
<skaet> thanks pitti for all your help today.
<charlie-tca> I gave up on OMG a while back
<skaet> highvoltage, ok, I've sent off the email.
<highvoltage> ok great, I'll publish the edubuntu one too then...
<highvoltage> skaet: thanks!
<charlie-tca> ops is going to start hating me, now
<skaet> web site will get cleaned up as soon as it can... be.
<highvoltage> great
<highvoltage> skaet: were you release manager yet for the first alpha?
<skaet> highvoltage,  yes, was feeling my way in still a bit though.
 * skaet still is feeling her way :p   suspect she will be for a while.   lol
<highvoltage> imho you did great. this was a rocky alpha and you didn't panic!
<highvoltage> I think that's very, very important :)
<charlie-tca> I thought skaet did great on this one. It was a short testing period, lot of bugs, and a rough alpha to get out on schedule
<skaet> thanks - its an awesome release team to work with.
<skaet> :)
<highvoltage> charlie-tca: +1!
<nhandler> cjwatson: When you get a chance, could you push the email through the queue on ubuntu-devel-announce@ ? I know a few people wanting to link to the official announcement email there
<skaet> charlie-tca, highvoltage - it was jdstrand first time bit-wrangling the archive for a release.   kudos to him as well as the excellent pitti, cjwatson, slangasek.   The QA, Hardware Cert teams and the community testers are amazing at how quickly they can go through the images and let us know what the images looking like!!!  The leads of each of the flavors are great to work with as well for those announces.  ;)
<skaet> Its a team that is a delight to work with.
<jdstrand> skaet: thanks for the kind words :)
<jdstrand> skaet: nice job to you too :)
<skaet> also - http://www.ubuntu.com/testing/natty/alpha2 is now updated.  :)
<skaet> Release done!
<skaet> now on to 10.04.2 and Alpha 3 ... lol
<charlie-tca> We keep trying... :-)
<skaet> :)
 * skaet -> heading to dinner 
<highvoltage> skaet: indeed!
<cjwatson> nhandler: looks like somebody did it
#ubuntu-release 2011-02-04
<slangasek> lamont: are you sure gourd has that 30GB of swap enabled?  cross-compiling that same failing qemu object using gcc-4.5-arm-linux-gnueabi takes "only" 3.2GB of RAM, and the previous build got well past this point in the compile running on hubbard
<slangasek> (I'm currently trying to confirm how much memory used to build on ARM, but as I have much less than 30GB swap hooked up at the moment, it's taking some time to do so)
<pitti> skaet: congratulations for alpha-2!
<pitti> jdstrand: thnaks for your great help as well; got the hang of untangling the archive now? :-)
<pitti> dpm: hello
<dpm> pitti, so we were discussing that if we request a full export of Lucid language packs today, they should be available on the PPA on Monday,
<dpm> the 7th
<pitti> cjwatson, skaet, ara: currently discussing updated langpacks for lucid -- do we still want them?
<pitti> or is it too late?
<ara> I don't see much trouble on it, but I guess is skaet who should be deciding :)
<pitti> either way, we build the CDs from -updates now, so I think we can safely have them in -proposed
<pitti> and then see if we can get them into -updates quick enough?
<ara> pitti, indeed
<pitti> dpm: so, I think you should request the full export anyway, and we'll get it into -proposed ASAP
<pitti> it won't happen before Monday anyway
<pitti> so we can still discuss that in today's release meeting
<dpm> pitti, that sounds good, full langpack request done. When is today's release meeting? I'd like to announce this as early as possible today to translators, so that they still have some time to do any fixes or new translations before the time of the export at 22:00 UTC
<pitti> dpm: it's at 1600 UTC
<dpm> pitti, ok, thanks. Shall I attend, or will you bring up the subject at the meeting?
<pitti> dpm: I'll bring it up
 * dpm hugs pitti
<pitti> you can still attend if you want to, of course, but I don't think it's required
 * pitti hugs you back
<dpm> ok, sounds good, I'll be idling here and read the log
<apw> pitti, did we release, want to upload a new kernel if we are un-frozed
<pitti> apw: sure, go ahead
<apw> pitti, thanks, will do when these final tests are done
<cjwatson> pitti: updated langpacks seem worth it
<pitti> we aren't oversized ATM, so at least we aren't pressed to take them if anything should go wrong
<lamont>  cat /proc/swaps
<lamont> Filename                                Type            Size    Used    Priority
<lamont> /dev/sda2                               partition       30708236        16524  -1
<lamont> slangasek: ^^
<ScottK> skaet and cjwatson: I've gotten positive test results for the Kubuntu live powerpc image for Alpha 2.  Would it still be possible to release that as well?
<cjwatson> don't see why not
<cjwatson> pitti: do you have the publish-release command line you used to hand?  I don't know if you had to do anything non-trivial
<pitti> cjwatson: actually not, I just took the publish-image-set.py output
<pitti> I went through it, and it seemed to be just fine
<cjwatson> oh, powerpc wouldn't have been on iso.qa
<cjwatson> I'll figure out how to publish the Kubuntu image, then
<persia> With luck, that ought be fixed for Alpha 3 (unless priorities change between then and now)
<cjwatson> ScottK: published (modulo mirror syncing)
<ScottK> cjwatson: Thanks.
<jdstrand> pitti: hehe, thanks! I'm not sure I could untangle just anything, but yeah I feel pretty good about it overall :)
<skaet> pitti,  ara,  if we can get the langpacks in that would be good.  :)
<pitti> skaet: ok, so we are all in agreement; we'll kick them in ASAP
<skaet> :)
<skaet> ScottK,  great to hear that the Kubuntu live PowerPC image is looking good.   Thank you cjwatson for making it available :)
<ara> skaet, how was LCA? did you have a good time? How was your talk?
<skaet> ara, LCA was great.  The quality of the talks there is great, and there are always multiple things I want to see simultaneously.
<ara> great :)
<skaet> ara,  was really inspiring how well the team in Brisbane managed to make it happen with so few glitches after having to move it the week before due to the original venu being flooded.
<skaet> 700 person conference shifting venues, and having wifi and infrastructure working, as well as room logistics, etc.
<skaet> Open Day at the end was fun too.   Got to meet some of the Australian loco team members and help out at the booth.   Good trip, but glad to be home  (and A2 out the door!!!)
<seb128> skaet, not going to fosdem today? ;-)
<skaet> seb128, with the roads in Austin having ice on them, and snow on the ground - very glad not to have to travel!!  :)
<seb128> ;-)
 * skaet heading over to #ubuntu-meeting for release team meeting in 5 mintues...
<slangasek> lamont: ok, so it's something that's not even reproducible with a cross-compiler :/  I'll keep poking at it then
<lamont> I heard rumblings of a gcc-bug accusation rumor.  those generally tend to be people throwing straws though
<lamont> how far into the build does it die?
<lamont> because if you kick it off, I can go peek at it while it's running
<lamont> though I'm about to afk to do the townward transition and grab breakfast
<slangasek> lamont: well, the most recent build got 1h17min in; the one before that got much farther
<lamont> could be hitting a corner case in the vm subsystem during the swapwars, too
<slangasek> do you want me to kick one off now?
<lamont> I don't suppose it's somewhere convenient, like a test suite we could disable?
<slangasek> or should I wait until after breakfast?
<slangasek> no, it's when building the core of the emulator
<lamont> kick it in about 30 min?
<slangasek> can do
<lamont> how... inconvenient.
<slangasek> it's using memory at exactly the place it should use memory
<slangasek> just not 30GB of memory :)
<lamont> right
<lamont> poke me when you kick it to remind me, if you would
<slangasek> will do, thanks
<lamont> forecasted high/low: 46, 25.  current temp: 14
<lamont> this is fail
 * lamont grabs his coat, afks
<charlie-tca> hm, warm there, too
<nogo> ram disk is awesome
<slangasek> lamont: qemu-linaro retry scheduled; estimated start in 4h
<dpm> hi pitti, what was the output on the discussion re: the lucid langpacks in the release meeting? I had to disconnect for a while, and I couldn't follow it
<dpm> s/output/outcome/
<pitti> dpm: already discussed before with skaet and cjwatson, we all agree
<pitti> dpm: so let's get them into -proposed on Monday, and test them fast
<dpm> pitti, sounds great. Any suggestions on the day testing should be finished and we upload them to -updates? I'll then inform translators/testers
<pitti> dpm: ideally end of next week, as it's getting tight with final image validation
<pitti> dpm: Monday the week after (14.) might just barely make it still
<pitti> would one week be enough for the ~ 10 langs we ship on the CDs?
<pitti> dpm: I guess we could at least install them and check if they boot into a non-crashing desktop and can run update-manager
<pitti> dpm: that won't catch "bad looking" strings, but at least "ill-formatted" ones
<dpm> pitti, do we really ship that many on the CD?
<pitti> dpm: I didn't actually count; but it's different for each architecture and flavour
<dpm> but yeah, I think the ones we ship are from active teams
<dpm> brb, on a call
<skaet> dpm, earlier next week the better for the testing results.  possibly let us know as they come in, rather than batch at the end.
<dpm> skaet, I can definitely do that, and tell translators as well that they should provide the feedback as soon as possible, but in addition to that, it works better if they know a deadline, as in e.g.: "you've got until Thursday to test these packages"
<skaet> dpm,  sounds good.  Thursday would be a good point to pick.  But feel free to let them know earlier is better ;)
<dpm> yeah, I'll do that, thanks skaet!
#ubuntu-release 2011-02-05
<cjwatson> I noticed daily CD builds were still disabled following alpha-2; I re-enabled them
#ubuntu-release 2012-01-30
<doko> seb128, pitti, Riddell, ScottK: are any major changes planned before alpha2 during the soft-freeze?
<seb128> doko, nothing "major" from the GNOME side
<doko> seb128, and no upload which lead to temporary non-installability?
<seb128> doko, that I don't know
<seb128> we might have a gtk upload
<seb128> which usually leads to few hours installability issues
<doko> seb128, please could you make sure that things stay installable? we have a test rebuild scheduled during the release according the release schedule
<seb128> doko, I've little control on arch all,any delays, but I will make sure to not create issues if that can be avoided yes
<doko> thanks
<Riddell> doko: no changes, I'd like to see if anything needs done to calligra but that's not on CDs, I'd like to see if I should be worried about oversizing but I won't be able to solve that in time even if I should, I'd like to double check the pyqt binary compatibility issue is fixed and I'm hearing lots of things about X crashing when videos are played
<cjwatson> pitti: Would you care to review release-upgrader-{apt,python-apt} in lucid-proposed (I think they landed in NEW, but they're in lucid-updates)?
<pitti> cjwatson: sure, doing now
<cjwatson> I'm putting together similar apt changes for lucid-proposed and oneiric-proposed too
<pitti> cjwatson: accepted
<cjwatson> Thanks!  What did we do last time about the aging period for release-upgrader-*?  It doesn't get ordinary testing in -proposed, and update-manager doesn't currently have a way to opt into it
<cjwatson> The way you test it is to install the packages before starting update-manager / do-release-upgrade / whatever
<mvo> cjwatson: last time (because it was the first time) I moved the upgrade to use -propesed directly but before I ran the entire auto-upgrade-tester suite using the upgrader package (by modifiying the local bzr)
<cjwatson> jibel: would it be possible to adjust jenkins to do this temporarily, once these builds land in -proposed?
<cjwatson> that might be the most effective way to test this
<cjwatson> I could change update-manager but then that affects all users
<pitti> yes, I agree; once it's through a successful lts-upgrade autotest, I'm fine with moving them to -updates
<jibel> cjwatson, yes, it is possible. I can do that today when the new builds are available.
<cjwatson> excellent.  maybe it'll be in time for alpha 2 after all.
<stgraber> skaet: good morning!
<skaet> stgraber,  good morning!  :)
<stgraber> skaet, jibel: So I was wondering what we wanted to do for Alpha 2 on the tracker. Should we hide the Daily milestone during Alpha 2 testing and redirect the automated upgrade testing to the milestone?
<skaet> stgraber,  hiding the daily, and redirecting the automated upgrade testing seems reasonable to me.
 * skaet curious about jibel's opinion though
<jibel> stgraber, I agree with skaet. and displaying daily and a2 would be confusing.
<stgraber> jibel: cool, so they'll see Alpha 1 as released and Alpha 2 as testing on the frontpage (want to get them used to seeing more than one thing there) and daily will re-appear post-alpha2.
<skaet> stgraber,  sounds good.   Tomorrow's dailies will be the first A2 images.
<jibel> stgraber, yes, sounds good.
<stgraber> which reminds me, I need to start poking some people, mythbuntu and xubuntu all failed to upgrade yesterday and edubuntu i386 failed too
<stgraber> mythbuntu and xubuntu because of unity-greeter crashing. Edubuntu i386 because of gnome-settings-daemon crashing
<cjwatson> pitti: would you mind NEWing release-upgrader-apt in lucid-proposed?  I probably ought not to do it myself
<Riddell> cjwatson: looking
<cjwatson> PS should go to main
<Riddell> cjwatson: PS?
<cjwatson> postscript
<Riddell> I see libapt-inst1.4 and libapt-pkg4.12
<cjwatson> in the sense of "an addition to my previous message"
<cjwatson> all of libapt-inst1.4, libapt-pkg4.12, and release-upgrader-libapt-pkg-dev should be overridden to main, to roughly match lucid-updates
<Riddell> yes, doing
<pitti> thanks Riddell
<cjwatson> pitti,Riddell: release-upgrader-python-apt now needs binary NEWing in lucid-proposed as well
<cjwatson> I've preemptively overridden it to main
<slangasek> \o/
<jibel> cjwatson, I installed the new packages manually and upgraded lucid desktop i386 and it passes.
<slangasek> progress
<cjwatson> excellent
<cjwatson> jibel: did you pick release-upgrader-python-apt out of LP?
<jibel> cjwatson, I did
<cjwatson> right, cool
<cjwatson> we can probably move that straight to updates once it's in the archive, then
<cjwatson> although I guess it might be good to run the whole suite
<cjwatson> I'd definitely like to know whether universe passes
<cjwatson> or gets further
<jibel> cjwatson, the upgrade failed but for another reason: "dpkg: error processing dpkg (--configure): package dpkg is already installed and configured" :(
<cjwatson> that's some kind of trigger failure; it's apt's fault, but I'm not convinced it could be related to that resolver change
<cjwatson> mvo may be able to work it out?
<cjwatson> well, it's *probably* apt's fault
<cjwatson> IMO if it gets past the resolver it's a progression
 * cjwatson has another go at building lucid DVDs
<cjwatson> this time with -proposed switched on
<jibel> I'll try again and see if it reproduces
<cjwatson> skaet: I've done steps 2-6 from "Release minus 1 month" on https://wiki.ubuntu.com/PointReleaseProcess
<cjwatson> skaet: only just asked Evan for the updated build so I expect he might not get back to me until tomorrow
<skaet> cjwatson, thanks
<cjwatson> (updated build> wubi that is)
<skaet> in terms of the A2 release,  slangasek,  I've done steps 2 and 5 from release minus 6 days.  (steveedwards will be the contact, and have put the request in to mvo).
<Riddell> cjwatson: is this binary New?  why does it not have a capital N to mark it? http://paste.kde.org/196940/
<skaet> https://launchpad.net/ubuntu/r-series and https://launchpad.net/ubuntu/s-series have now been created as future series in launchpad.
<skaet> cjwatson, slangasek, Riddell, pitti, and others interested... ^^
<Riddell> those are boring codenames :)
<skaet> :)  indeed,  however I'm sure they will be made more interesting at the appropriate time,  lol
<cjwatson> Riddell: Soyuz gets a bit confused by packages that don't currently exist in the pocket they were uploaded to (or in its ancestry; basically lucid in this case) but that do exist somewhere else in the archive
<cjwatson> Riddell: in the new republic^W^W^W^Wwhen I get round to reimplementing this in the API it will look more sensible :-)
<Riddell> cjwatson: I see that explains it, I accepted it
<cjwatson> thanks
<micahg> skaet: I might miss the freeze by a few minutes for some Ubuntu Studio specific packages I'm sponsoring (no impact on anything else)
<skaet> micahg,  thanks.  images will be generated by the cron job tonight.
<astraljava> skaet: micahg: Thanks guys!
<micahg> astraljava: I"m going to do the -meta later tonight, I don't believe your images get spun until 18:00 UTC tomorrow anyways
<micahg> skaet: ^^ is that ok, I'm uploading the other packages now for Ubuntu Studio
<skaet> micahg, prefer it be done earlier rather than waiting until the wire.   Don't want to have to be special casing it if it misses deadline.
 * skaet goes to look at the crontab...   thought it was earlier...
<micahg> ok, let me see if I can finish it now then
<skaet> micahg, thanks!
<astraljava> skaet: Different time than dailies?
<cjwatson> we have to spread builds out through the day otherwise they collide too much
<astraljava> Yeah I understand. I just didn't know, that's all. :)
<micahg> ok, meta uploaded
<micahg> for ubuntustudio that is :)
<skaet> thanks!
 * ScottK just uploaded meta for Kubuntu too.
#ubuntu-release 2012-01-31
<cjwatson> * Chose apturl to satisfy xul-ext-ubufox
<cjwatson> dear cdimage, what are you on, I'd like some
<cjwatson> oh, never mind, that actually makes sense doesn't it
<cjwatson> in that case I'm confused about why xul-ext-ubufox isn't on the lucid DVD
<cjwatson> unless it's having trouble with the dependency changes between lucid and lucid-updates ...
<cjwatson> oh, wow, germinate bug
 * cjwatson tries to construct a unit test
<cjwatson> Any chance of somebody on the MIR team looking at bug 922631?  I think it would clear precise_probs.
<ubot4`> Launchpad bug 922631 in apache-pom (Ubuntu) "[MIR] apache-pom (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/922631
<jibel> server images do not install this morning: no kernel module found
<jibel> no kernels found sorry
<pitti> hm, same for alternates
<pitti> strange, d-i was rebuilt against -12
<jibel> pitti, bug 924182
<ubot4> Launchpad bug 924182 in debian-installer (Ubuntu Precise) (and 1 other project) "d-i images (server, alternate) failed to install: no kernels found (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/924182
<jibel> it is not a problem with the version of the kernel
<jibel> pitti, lines 15078 to 15116 in syslog
<pitti> fallout from new apt?
<pitti> jibel: on the bright side, nice to see that test_lts_upgrade_system.py succeeds now, and 3/4 _user.py
<jibel> pitti, indeed. I must fix the upgrade tester to report unittest results correctly though.
<cjwatson> jibel: looking
<cjwatson> jibel: Where is your preseed file coming from?  You appear to be trying to use the amd64 preseed file on an i386 image.
<cjwatson> jibel: They differ, in particular, on which kernel to use. :-)
<cjwatson> That said I see that amd64 is failing too.
<cjwatson> reproduced
<cjwatson> Ah.  pitti is correct that it's fallout from the new apt.
<Riddell> installing today's kubuntu ISO from USB disk it errors that it "could not set up local CD sources" or similar
<Riddell> why is my debug log so short? http://starsky.19inch.net/~jr/tmp/installer/
 * Riddell runs again with --debug
<cjwatson> Riddell: look at syslog instead
<cjwatson> (/var/log/syslog)
<cjwatson> Riddell: I strongly suspect it's bug 924182 though
<ubot4> Launchpad bug 924182 in apt (Ubuntu Precise) (and 1 other project) "d-i images (server, alternate) failed to install: no kernels found (affects: 1) (heat: 6)" [Critical,In progress] https://launchpad.net/bugs/924182
<cjwatson> That's better.
<Riddell> cjwatson: I don't think it is "an attempt to configure apt to install additional packages from the cd failed" http://starsky.19inch.net/~jr/tmp/installer/syslog
<Riddell> E: Could not open file /cdrom/dists/precise/main/binary-i386/Packages - open (2: No such file or directory)
<pitti> ^ sounds like that very bug, though
<Riddell> pitti: really?  less scary error than "no kernel found"
<Riddell> maybe this is USB vs CD install
<pitti> Riddell: above but is apt falling over on a missing "Packages" file (as intended, it's Packages.gz)
<pitti> s/but/bug/
<cjwatson> Riddell: it's the same bug.
<cjwatson> just different manifestation in d-i vs. ubiquity.
<Riddell> pitti: yes, Packages.gz exists you're right
<Riddell> cjwatson: ok thanks
<cjwatson> I have a fix - just writing it up for the BTS.
<Riddell> cool
<cjwatson> uploaded - will rebuild all images once it's built and published, I guess
<cjwatson> kicked off a number of rebuilds
<cjwatson> not the full set, but the crontab is still enabled so I didn't think that was desperately important
<cjwatson> jibel: could you try running the full set of upgrade tests on jenkins with release-upgrader-{apt,python-apt} from lucid-proposed?  ideally I'd like to see results from that published to jenkins
<mvo> is a python-apt upload ok at this point or should I wait for after a2?
<jibel> cjwatson, upgrade test with release-upgrader from -proposed seems to work, now the resolver resolves
<jibel> but there is now this error "package dpkg is already installed and configured" on both arch while previous test on amd64 was ok.
<jibel> I'm reverting to -updates and see if it pass
<apw> are we aware the screen saver is not engaging on suspend/resume ... see rtg on #ubuntu-devel
<cjwatson> mvo: what would it do?
<cjwatson> jibel: hm, I suppose I did do a general update of release-upgrader-apt from precise so it could be something else in there ... sigh
<mvo> cjwatson: some additional api (access to PkgPolicy.get_priority(), drops the need for python-debian and fixes .xz support for apt.debfile.DebFile()) (and another crash fix for multiarch debfiles)
<stgraber> cjwatson: can you have nusakan push to the "Precise Alpha 2" milestone instead of "Precise Daily" (if not already done)?
<cjwatson> stgraber: oops, yes, done no
<cjwatson> w
<cjwatson> mvo: do you think any of it is a2-critical?  I don't know how important the crash is, or what needs the new API
<stgraber> cjwatson: thanks
<mvo> cjwatson: not critical, no
<mvo> I will wait for after a2 then, thanks
<cjwatson> mm, I think that's probably best, thanks
<cjwatson> enough stuff going wrong already and it's only Tuesday :)
<pitti> precise is becoming much greener again, thanks cjwatson
<pitti> (in jenkins)
<cjwatson> phew
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html language pack badness again ...
<pitti> yeah, just looking at this
<pitti> I wonder what happened to language-pack-kde-ru
<pitti> it's built, not in NEW, but also not in teh archive any more, WTH
<pitti> cjwatson: kde-wae was built an hour ago, and is on cocoplum, that should resolve itself
<pitti> cjwatson: I hope kde-ru is just somewhere in limbo in the publisher
<cjwatson> 2012-01-31 11:35:32 ERROR   PoolFileOverwriteError: 92c921c793d4f95ec628f28ecb98cfdac50b61c7 != f6dd336dab9bd75d34ceefcb8bdfaf0348b51f2d for /srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/l/language-pack-kde-ru/language-pack-kde-ru_12.04+20120130_all.deb, skipping. (OOPS-5a54afb4f69ef3bb6d25194cabc1af86)
<ubot4> https://lp-oops.canonical.com/oops.py/?oopsid=5a54afb4f69ef3bb6d25194cabc1af86
<cjwatson> hm, there's also a corrupted file in /srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/l/language-pack-kde-ru/language-pack-kde-ru_12.04+20120130_all.deb
<cjwatson> that's non-trivially confusing
<cjwatson> I've removed it from the pool since the publisher is clearly still trying and failing to publish it; hopefully the next run will wowrk
<cjwatson> *wrk
<cjwatson> damnit, YKWIM
<cjwatson> it was 15668 bytes rather than the expected 899940
<pitti> urgh, how could that happen? some bug in the langpack-o-matic upload script?
<pitti> although that just calls dput, although 200 times in a row
<cjwatson> no, it's clearly not on your side, it's fine in LP
<cjwatson> there was a librarian deployment about that time ... I can only guess though
<cjwatson> 2012-01-31 15:04:44 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/l/language-pack-kde-ru/language-pack-kde-ru_12.04+20120130_all.deb from library
<cjwatson> looks better
<cjwatson> pitti: what do you think of http://paste.ubuntu.com/823931/ ?  https://bugs.launchpad.net/ubuntu/+source/ruby-sinatra/+bug/843734 shows it working
<ubot4> Launchpad bug 843734 in ruby-sinatra (Ubuntu Oneiric) (and 1 other project) "ruby-sinatra : Depends: ruby-rack but it is not installable (affects: 5) (dups: 2) (heat: 43)" [Undecided,Fix released]
<cjwatson> it's a little cumbersome that you have to go to the queue web interface
<pitti> cjwatson: I just hope approving them from the web ui is not subject to the very same timeouts
<cjwatson> OTOH it's also cumbersome when you have to ssh to cocoplum and run copy-package.py
<pitti> yes, it is
<cjwatson> I shouldn't have thought so, it'll have done a bunch of the work by then
<cjwatson> I can wait until there's an opportunity to copy something huge if you prefer, and we can stress-test that
<pitti> and at least it can then also be done by the whole SRU team
<pitti> cjwatson: I'm sure the next kernel update isn't that far out; we just copied unity yesterday, that was also a good one
<pitti> cjwatson: but anyway, I'd say go ahead with it
<pitti> and we'll see how it goes
<pitti> bzr is good at remembering the old code, if we have to :)
 * cjwatson tidies the output slightly
<cjwatson> yeah :)
* skaet changed the topic of #ubuntu-release to: Alpha 2 testing in progress: Archive:Soft Freeze  | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate covered ants | melior malum quod cognoscis
<ogasawara> skaet: bug 923512, we're still trying to isolate the regression.  I would like to upload a fix if we are able to find it in time.  If the window to upload has passed, I'll release note it.
<ubot4> Launchpad bug 923512 in linux (Ubuntu) "ath9k wireless stopped working after kernel upgrade to 3.2.0-12 (affects: 2) (dups: 1) (heat: 18)" [High,Confirmed] https://launchpad.net/bugs/923512
<skaet> ogasawara, ping when you find the regression and we'll see where we are with the other issues.
<cjwatson> pitti: done
<ogasawara> skaet: a test kernel which reverts what we believe is the offending patch is being built right now, then we're gating on feedback from reporters.
<ogasawara> skaet: am trying to find someone with hw that uses ath9k to see if we might be able to speed up the testing process.
<skaet> ogasawara, thanks
<stgraber> ogasawara: I have a USB ath9k device if that helps
<ogasawara> stgraber: I just found out serge can reproduce.  I'm assuming we can get a quick test confirmation from him, if not I'll come find you.
<ogasawara> stgraber: thanks
<skaet> slangasek, could you update #uubntu-devel to indicate we're soft frozen now?   I lack ability to be op in that channel.
<cjwatson> You do?  I thought we fixed that ages ago.
<cjwatson> 15:48 -ChanServ(ChanServ@services.)- 7     skaet                  +tA [modified 1 year, 16 weeks, 3 days, 03:40:52 ago]
<skaet> cjwatson,  it appears not.  I just tried to get operator status to update the header, like I did for ubuntu-release, and got back: * #ubuntu-devel :You're not a channel operator
<skaet> PBKAC?
 * skaet doesn't rule it out anyway... ;)
<cjwatson> Yes, but you can use the topic command to chanserv.
<cjwatson> /msg chanserv topic #ubuntu-devel new topic blah blah blah
<cjwatson> (Which should work here too.)
 * skaet trying
<Riddell> http://iso.qa.ubuntu.com/qatracker/milestones/206/builds lists 20120131 when it should be 20120131.2 n'est pas?
<cjwatson> Possibly I didn't change .isotracker.conf in time.
<cjwatson> If you want to get me a list of new builds to post then I can post them
<skaet> cjwatson,  chanserv new topic worked. \o/
<cjwatson> good, except the "new topic" bit was meant to be a placeholder :)
<skaet> thank you.
<cjwatson> 15:54 -!- Irssi: Topic: -: Archive: open
<cjwatson> 15:54 -!- Irssi: Topic: +: new topic Archive: soft freeze for Alpha 2
<skaet> lol
<skaet> fixing now
<skaet> done.
 * skaet goes to get more coffee,  it appears needed today.
<jibel> skaet, stgraber all builds published to the tracker excepted ubuntu-studio
<jibel> for ubuntu-studio there's no alternate since last week, DVD is available but not listed on the releaseimagecontacts page
<jibel> does DVD replaces alternate ?
<cjwatson> yes
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/other-p-ubuntustudio-livedvd
<jibel> thanks
<skaet> thanks fro updating the manifest jibel. :)
<skaet> (or rather the image contacts ;) )
<Riddell> yay kubuntu ISO installs good
<skaet> :)
<jibel> cjwatson, I built a fresh lucid desktop amd64. without proposed, upgrade succeeds. with -proposed enabled it fails.
<pitti> cjwatson: could you perhaps apply your magic trick for language-pack-kde-wae again?
<pitti> cjwatson: -ru is gone from precise_probs, -wae is still there
<pitti> the others are just armel buildd skew
<cjwatson> I'm not seeing a similar problem there
 * pitti checks again
<pitti> oh crud, I know; sorry, cjwatson
 * pitti makes a mental note to actually update the branch on macquarie when pushing fixes to bzr
<doko> with the soft freeze in place ... I'm starting the test rebuild now ...
<skaet> doko, we scheduled it for tomorrow...   I'm expecting we'll be doing some rebuilds of the images later today (mdeslaur's change, possible kernel update)
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<doko> skaet: you're over-optmistic that it will be done in one day ;-)
<doko> it was meant to use the empty buildds during the freeze
<skaet> doko,  slangasek is wrestling the bits this time around.   I leave the decision to him.  :)
<pitti> hm, universe stuff is usually not covered by the freeze
<micahg> pitti: some stuff is, anything shipped on an image
<micahg> skaet: did the freeze start late for alpha2 or at the normal time?
<pitti> I meant for expecting empty buildds
<skaet> micahg,  it started late.   slangasek announced it for tuesday last week in release meeting,  so I held to that.
<micahg> ah, yeah, and there are always security uploads, but usually the buildds are emptier during the freeze
<micahg> skaet: ah, ok, so I won't go around slapping people with a fish then :)
<pitti> wow, even powerpc got down to 14 minutes
<skaet> pitti - really?   cool!
<skaet> micahg,  you and doko probably should coordinate a bit to use the buildds - he has intentions there too. ;)
<micahg> skaet: most of mine are surprisingly done, what's left is short and shouldn't impact anything, if I end up respinning for any reason, I'll let him know
<skaet> micahg, great.  Thanks. :)
<astraljava> Hey guys, Ubuntu Studio doesn't have test cases for Alpha-2. Anyone able to help us with that?
<astraljava> Nevermind, jibel on -testing is taking care of this. Thanks!
<mvo> cjwatson: I just merged your fix for apt back, sorry that its currently such a bumpy ride
<mvo> skaet: I only just now uploaded the updated app-install-data, sorry, there was a bug in .xz code that I had to find/fix first
<hallyn> i'd like to push a fix for lxc for bug 924281.  Any objections?
<ubot4> Launchpad bug 924281 in cgroup-lite (Ubuntu) "cgroup-lite not installable inside 'lxc create -t ubuntu' container (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/924281
<skaet> hallyn,  go ahead,  we're waiting for some other things to land before rebuilds occur.
<skaet> slangasek, ^
<slangasek> ack
<slangasek> doko: feel free to go ahead with the test rebuild if you haven't already
<slangasek> doko: provided you've reserved us a builder for each arch for emergencies
<infinity> doko: Which arches are you test-rebuilding on?
<slangasek> ScottK: I notice that there are kubuntu-mobile images still in the cdimage crontab, but they're not in the release manifest; should those be dropped?
<ogasawara> slangasek, skaet: Fix for bug 923512 has been confirmed.  I'd like to upload if I may?
<ubot4> Launchpad bug 923512 in linux (Ubuntu) "ath9k wireless stopped working after kernel upgrade to 3.2.0-12 (affects: 3) (dups: 2) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/923512
<ogasawara> slangasek, skaet: the regression was introduced in upstream stable v3.2.2 so I've just reverted the offending patch.  it's already been reported upstream, so we'll follow up there.
<skaet> ogasawara,  go ahead.
<ogasawara> skaet: thanks
<doko> slangasek, infinity, armhf, i386, amd64. herb did want to look for additional machines once the rebuild is started. reserving would be setting a buildd on manual ... I'll score down the big packages instead, so that wait times are short
<doko> afk for diner now
<infinity> doko: Kay, was mostly interested in which arm you were doing (armhf was my preference, so yay), and I'll re-balance the buildds a bit to compensate.
<slangasek> doko: the plan out of the rally was that we *would* have a buildd set on manual
<infinity> slangasek: Would it be good enough to reserve one of each of the old/first-gen buildds (crested, yellow, vernadsky, rothera)?
<infinity> slangasek: If so, I can't see that hurting a rebuild much, since faster mashines like allspice and roseapple will tear through the process anyway.
<infinity> machines, too.  Typing hard.
<slangasek> infinity: yes; I don't expect any huge builds needed for respins (and if they are we can shoot builds in the head manually to free up resources)
<utlemming> stgraber: can I have you add http://cloud-images.ubuntu.com/precise/20120131/ to the iso tracker?
<stgraber> utlemming: pushed a bunch but the script then failed, looking at it now
<utlemming> stgraber: thank you kindly
<stgraber> utlemming: ok, added all these that exist on the tracker. We're apparently missing sa-east-* and us-west-*
<stgraber> well, sa-east-1-* and us-west-2-* actually
<utlemming> stgraber: missing them from the tracker or from the url?
<doko> slangasek, ok, will do that. infinity: which one is the slowest i386?
<stgraber> utlemming: either missing on the tracker or missing in our mapping table in the script. Everything looks good on your side AFAICT
<stgraber> jibel: do you have a few minutes to add sa-east-1-amd64-ebs, sa-east-1-amd64-instance, sa-east-1-i386-ebs, sa-east-1-i386-instance, us-west-2-amd64-ebs, us-west-2-amd64-instance, us-west-2-i386-ebs and us-west-2-i386-instance to the tracker?
<utlemming> stgraber: intersting...yeah, I see in the tracker it is scrapping off the -#, so US-West-2 and US-West-1 are mangled.
<stgraber> jibel: (as in, adding the products and test cases for these, I'll update the script to push them once done)
<utlemming> stgraber: also, I'm working on a query2 format that will deliver this information in JSON format...is that interesting for you guys?
<stgraber> utlemming: published-ec2-daily.txt seems easy enough to parse for now, but json would work too indeed
<stgraber> utlemming: we probably should look into running our script everytime the new AMIs are published so they automatically appear either as part of daily testing or as part of the current milestone testing
<utlemming> stgraber: jamespage is looking integrating the test results automagically into isotracker. The problem that I see with running your script is on a schedule is that we promote a daily to a release-candidate. Since we don't want the released AMI's public till the release date, and we publish new AMI's for the current dev cycle daily, tracking them automatically could be bad.
<utlemming> what I could do, is to work out something so that I can flag release-candidates so that you know if the tracker needs to be updated and then you could check that instead
<stgraber> utlemming: what do you mean by "Since we don't want the released AMI's public till the release date"? does that mean you don't want daily testing of the AMIs? (in case that wasn't clear yet, I know close to nothing about EC2 ;))
<utlemming> erm....we do want daily testing
<utlemming> but the problem with EC2 is that there is a new AMI ID every time you build
<utlemming> when we promote a daily to a release, alpha, whatever, it is re-registered
<utlemming> so the AMI IDs that are on the tracker are the daily images that we've chosen as the candidate
<utlemming> once we release the images, those AMI ID's are invalid
<utlemming> basically, the easiest way to think of it is that we don't know the AMI ID's of the released images until after they are made public
<stgraber> utlemming: ok, but there wouldn't be any problem with publishing all your dailies as part of the "Precise Daily" milestone on the tracker as we do for ISO images, have them published as "Precise Alpha 2" when doing milestone testing. What you're saying only seems to impact what goes in the release announcement (where the final IDs need to be put I guess)
<utlemming> okay, I think I'm on the same page now
<utlemming> yes, publishing all the dailies is fine, as long as they are flagged as dailies
<stgraber> cool, might look into that when I have some time. Trying to get as much as possible to show up on the daily testing page :)
<cjwatson> sigh, my germinate sync failed to build - I wish we would get mailed about that case
<cjwatson> (I know, known bug)
<GrueMaster> stgraber: Can you change Netboot armel+omap to Netboot armhf+omap (or add  Netboot armhf+omap).  We care more about armhf than armel.
<GrueMaster> On iso.qa.ubuntu.com
<stgraber> GrueMaster: oops, seems like we're missing Netboot armhf+omap in the DB indeed. Fixing that now
<GrueMaster> thx
<GrueMaster> Although I am not sure how long before I get to it.  8 images to test on omap and only 1 board.
<slangasek> GrueMaster: "We care more about armhf than armel" - does that mean the armel/armhf decision has been made?
<slangasek> last I heard it was still up in the air
<stgraber> GrueMaster: done
<infinity> doko: rothera, vernadsky, yellow, and crested are all basically the same vintage.
<GrueMaster> No, not until before FF.
 * slangasek nods
<GrueMaster> However, we are leaning towards armhf.
<infinity> slangasek: It's still up in the air, but we're trying to focus on armhf to influence the decision in the direction we all want it to go. :P
<slangasek> ack
<infinity> slangasek: The other reasonably fair point is that, other than archive skew, anything that works on armhf should work on armel, while the inverse isn't necessarily true.
<slangasek> I don't follow that at all
<infinity> slangasek: Since anything I do for armhf, I also do for armel, but there could be plenty of armel-specific hacks still kicking around causing armhf problems.  So, testing armhf seems the saner route to catch problems with both, if you're time-constrained and can't do both.
<slangasek> unless we're talking about latent bugs due to the newness of armhf itself?
<slangasek> oh, no, I'm upside down
<infinity> Newness of the armhf toolchain, plus packages that might have armel hacks that haven't been duplicated on armhf.
<infinity> Where can I find a lintian lab to do an rgrep of armel in debian/* BTW? :P
<infinity> Sifting through that will suck, but I think it needs to be done.
 * GrueMaster sees new desktop armel images finally showed up for today, sighs after testing most of the previous ones.
<GrueMaster> s/armel/arm
<slangasek> GrueMaster: in fact, there will be further builds today since there were several package uploads landing; the current daily images would certainly be fine for smoke testing in any case
<GrueMaster> slangasek: Problem is I have limited resources (me) and a lot of images.
<GrueMaster> I really don't want to be testing at 10pm again.
<skaet> slangasek, have to step away for a bit - will be back on later.
<slangasek> skaet: ack
<jibel> stgraber, will do. test cases are the same than other instances ?
<stgraber> jibel: yep
<GrueMaster> slangasek: What packages have changed?
<stgraber> jibel: I have the script updated here ready to post the new builds
<stgraber> jibel: I went with "(South America)" and "(US-West-2)" in the script but feel free to use whatever you want on the tracker
<slangasek> GrueMaster: nautilus, app-install-data, lxc, sudo; also the kernel, for an x86-specific fix
<jibel> stgraber, I'll use the same naming convention.
<slangasek> GrueMaster: a smattering of other packages - I don't have an exact list because the weather report doesn't have the preinstall images on it
<GrueMaster> So essentially I am done for the day as far as real milestone testing goes.
<jibel> stgraber, ec2 will need a dedicated tracker soon
<slangasek> GrueMaster: I don't know what you mean by "real" milestone testing
<GrueMaster> Since it will take several hours to build new images, and a few hours to pull them down locally.
<GrueMaster> I.e. reporting into qa.iso.ubuntu.com.  Anything I test and report there will need to be retested/posted with the new images.
<slangasek> yes, which is how this always works
<GrueMaster> Well, last cycle I didn't have 2x the number of images (armel only).
<GrueMaster> And I can't automate any of the preinstalled image tests.
<slangasek> Riddell, ScottK: do you want libqapt1 rebuilt against current libapt for a2?
<Riddell> slangasek: hmm not unless it needs to be
<Riddell> do we know of any problems with old libapt?
<slangasek> there are a number of bugs
<slangasek> nothing that's going to be milestone-critical in that context however
<slangasek> Riddell: probably the biggest win is it means you don't have to have two copies of libapt on the CD? :)
<jibel> stgraber, http://paste.ubuntu.com/824402/
<Riddell> slangasek: ach we're well oversized anyway, it won't help
<stgraber> jibel: looks good, I'll push the builds now
<jibel> stgraber, k
<stgraber> yay, no error message this time!
<stgraber> jibel, utlemming: should all be on the tracker now
<astraljava> stgraber: skaet: What's the ETA for Ubuntu Studio image?
<slangasek> astraljava: no eta yet, still waiting for an updated kernel package
<astraljava> slangasek: Thanks!
<slangasek> astraljava: you can assume it'll be at least 4h out
<astraljava> That's fine. Thanks again!
<slangasek> skaet: step 3 on -2days isn't anything I've seen / done before, is this mail something I should be sending?  (Or is this inherited from somewhere?)
<stgraber> jibel: no testcase for Ubuntu Server EC2 instance (US-West-2) i386
<jibel> stgraber, it's true
<jibel> stgraber, fixed
<Riddell> what is the capital X for in new queue info? http://paste.kde.org/197528/
<slangasek> interesting question; I don't think I've ever seen that before
<slangasek> I thought the allowed values were 'S-' for source, and '-B' for binary
<Riddell> random bug? http://paste.kde.org/197534/
<Riddell> fetch fails
<slangasek> bug of some kind; whether it's random or not I don't know :)
<Riddell> slangasek: sladen filed bug 924537 and wgrant says it's not a priority because new packages can be waved through
<ubot4> Launchpad bug 924537 in launchpad ""queue fetch" requires a changes file which copies sometimes lack (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/924537
<wgrant> It should be trivial, though.
<wgrant> slangasek, Riddell: X is copy/sync
<slangasek> ah
<slangasek> "waved through" - we do want to make sure syncs are landing in the right component (universe vs. multiverse)
<slangasek> hmm, apparently the typical time for a kernel build is a bit higher than I remembered.  I think I shall be pushing builds out without waiting, for smoketesting purposes
<infinity> slangasek: For the record, the flash-kernel upload I just did only affects a subarch we don't ship, so shouldn't trigger rebuild mania.  But harmless if we do more respins later and incidentally pick itup.
<slangasek> ack
<slangasek> heh, new linux published on armhf, still waiting for the other archs
<infinity> *flex*
<infinity> (It sort of helps that armhf only builds one flavour...)
<cjwatson> slangasek: syncs do land appropriately in universe/multiverse IME
<cjwatson> slangasek: do I need to rebuild d-i for the new kernel?
<slangasek> cjwatson: oh, then perhaps waving them through is the correct answer after all :)
<slangasek> cjwatson: it's a non-ABI-changing upload
<cjwatson> Riddell,wgrant: I thought about fixing that queue fetch bug, but TBH I hadn't been bothering because I was intending to supersede it soon enough :-)
<cjwatson> slangasek: yeah, but do we need the changes to be reflected in the d-i initrds?
<wgrant> cjwatson: Yep
<wgrant> cjwatson: It's pretty trivial if someone does want to fix it, though.
<cjwatson> Aye
<slangasek> cjwatson: well, it contains a single fix for a wifi driver; any reason to rev the initrds for that?
<cjwatson> Depends if it's in the initrds ... which driver?
<slangasek> ath9k
<cjwatson> well, it is in the netboot initrd, at least
<cjwatson> not cdrom, so it's not critical path
<cjwatson> ideally I'll be heading to bed unless there are any emergencies, so maybe somebody could do an upload there :)
<infinity> I have ath9k on several of my systems here.
<infinity> Not sure if that's an argument for rebuilding d-i, but yeah.  It's not uncommon, at any rate.
#ubuntu-release 2012-02-01
<infinity> slangasek: I need to do a new d-i upload for omap anyway, apparently, so we'll get the new kernel with that.
<slangasek> ok
<infinity> slangasek: Uploaded.
<slangasek> cheers
<infinity> Oh wait... Bah.
<infinity> Were the new kernels still pending?
<infinity> Silly trigger-happy me.
<slangasek> evidently
<slangasek> only armhf has published
<infinity> There, removed from the upload queue.
<infinity> I'll re-upload later.
<infinity> La la la.  Pay no attention to the shell account behind the curtain.
<infinity> slangasek: If history is anything to go by, those kernels will be done in 6-7 hours, so I'll do my d-i upload just before bed tonight.
<slangasek> alright
<infinity> cjwatson: Don't worry about d-i respins, I'm doing an upload to fix omap after all the kernels are built.
<skaet> slangasek, re: step 3 on day-2 - I did it earlier (and just added it).  Basically want to make sure the cloud images stay in synch with our rebuilds (or its an explicit decision to not rebuild)
<slangasek> skaet: oh, I meant step 4, apparently you added a new 3 when I wasn't looking ;)
<skaet> :)  step 4 was an artifact from before,  and given the iso tester mails out to those subscribed to tests, am wondering if its worth doing.   Didn't do it earlier since we knew the images were bad - does the current set look like possible keepers?
<slangasek> no, the current set are still only smoke-testers
<slangasek> the kernel is still building
<skaet> still building... urk
<skaet> ok, maybe cjwatson and pitti can do the mail out once the next set get posted then.
<skaet> s/and/or/
<skaet> slangasek, when did they actually start building?
<skaet> slangasek, any updates to the pad.ubuntu.com?
<slangasek> skaet: the kernels started building as soon as uploaded, 6-ish hours ago; all archs are built now except for armel.  As for pad.ubuntu.com, infinity has updated it to allow outputting arm images faster so that we don't have to wait for all subarchs before testing can be done
<skaet> slangasek,  re: kernel - ok,  seems a bit longer than before though, but I'll check my records before commenting further.
<skaet> re. pad.ubuntu.com - you comment doesn't quite make sense to me,  pad is just to record what's happening.  Comments there were the ones I put up before I had to go to the meeting (indicating things building, etc.  not current status).   I see adam's changes on the arm images - but the status at the top isn't accurate at the moment.
<skaet> hence my questions on IRC :)
<slangasek> skaet: oh, sorry - I mean that there was a tweak to the build pipeline, my comment didn't make sense because I misunderstood the question :)
<slangasek> skaet: I hadn't looked at the top there.  What's the "LTSP" item?
<slangasek> skaet: in any event, no new issues have been raised since those
<TheYsNoi> hi there..1st time boot here...finally..
<pitti> skaet: mail out> sorry, what mail?
<pitti> (and good morning)
 * infinity glares at the armel kernel build to see if that will make it finish faster.
<infinity> Kernel finally published; new debian-installer uploaded.
<TheYsNoi_> hi there...new boot here..
<TheYsNoi_> anybody?
 * cjwatson uploads casper to fix the autotests (bug 924535)
<ubot4> Launchpad bug 924535 in casper (Ubuntu Precise) (and 1 other project) "desktop preseeded installation stops at user setup since build 20120131 (affects: 2) (dups: 1) (heat: 14)" [High,In progress] https://launchpad.net/bugs/924535
<cjwatson> added to the pad
<Riddell> "Preseeded installation stops at user setup" remind me again what that is?
<cjwatson> bug 924535
<ubot4> Launchpad bug 924535 in casper (Ubuntu Precise) (and 1 other project) "desktop preseeded installation stops at user setup since build 20120131 (affects: 2) (dups: 1) (heat: 14)" [High,Fix released] https://launchpad.net/bugs/924535
<cjwatson> unless I'm misunderstanding your question
<Riddell> needs a preseed file pointed too at the start of the install
<cjwatson> sure, the automatic tests do that
<Riddell> that'll be it, that's why I haven't come across it
<cjwatson> if you aren't preseeding then that bug doesn't show up, indeed
<cjwatson> but it makes a pretty big difference for qa/hwcert
<Riddell> that makes sense
<Riddell> do they care about kubuntu?  if not it doesn't seem to be alpha critical for us
<cjwatson> do you have jenkins tests?
<Riddell> nope
<cjwatson> well, it's possible for other folks to do preseeding as well, but true, probably not milestone-critical for Kubuntu in itself
<Riddell> I am coming cross network-manager not successfully telling plymouth that it has started which causes plymouth to wait for ages on first boot
<Riddell> I don't see that in the iso tracker yet
<jibel> Riddell, I got this issue, but not enough information to file a bug. there's a 2 minutes timeout on first boot.
<Riddell> I filed bug 924836
<ubot4> Launchpad bug 924836 in network-manager (Ubuntu) "network-manager does not tell plymouth it has started (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/924836
 * ogra_ wonders why the ac100.bootimg files on cdimage have the wrong md5 
<cjwatson> URL?
<ogra_> http://cdimage.ubuntu.com/daily-preinstalled/20120201.1/precise-preinstalled-desktop-armel+ac100.bootimg
<cjwatson> hm
<ogra_> 552f7b49d76bf0df93a71223dec9ff06 is what i get locally
<ogra_> 47dcdb59b8dbacc2c0462135c38b864c is what it says it should be in the MD5SUM file
<ogra_> aha, which is the MD5 of the last build
<cjwatson> looking into it
<ogra_> seems the publisher doesnt properly replace that file or so
<cjwatson> looking into it :)
<ogra_> yep
<cjwatson> combination of problems I think
<ogra_> hmm
<ogra_> armhf seems to have the same issue, sad
<cjwatson> fixed the core problems (pending deployment) but this really isn't helped by there being an entirely different preinstalled output directory from debian-cd for no obvious reason
<ogra_> "different preinstalled output directory " ?
<cjwatson> ./CONF.sh:244:export PREINSTALLEDIMAGES=$CDIMAGE_ROOT/scratch/$PROJECT/$IMAGE_TYPE/preinstalled
<ogra_> all preinstalleds go into the same target dir, no ?
<ogra_> oh, the scratch dir
<cjwatson> which is unhelpful, it should just use OUT
<cjwatson> then this would have worked
<cjwatson> (then again we'd never have noticed the underlying bugs, but)
 * ogra_ wonders where that line comes from, i cant remember adding that
<ogra_> (and i wouldnt know why i would mangle the default dir)
<cjwatson> should be fixed on cdimage now at least
<ogra_> thanks
<cjwatson> oh, I suppose PREINSTALLEDIMAGES might be more like LIVEIMAGES, that makes sense
<cjwatson> so the bug is just that ac100 bootimg files are written to PREINSTALLEDIMAGES (which is meant to be an intermediate directory) rather than OUT (which is meant to have all the output files)
<ogra_> aha
 * cjwatson goes to fix that
<cjwatson> actually I'm still very confused.  maybe I don't need to deal with this right now.
<cjwatson> for future reference, I think my statement above is wrong - maybe it's a problem with the imagesums target not checksumming .bootimg files
<ogra_> cjwatson, ugh, that bashism is in all arm boot scripts btw
<cjwatson> anyway, it shouldn't cause a practical problem no
<cjwatson> w
<cjwatson> ogra_: that was just drive-by nitpicking, not a real problem, seeing as it's #!/bin/bash :)
 * ogra_ will fix that after milestone, since its ugly
<ogra_> sure, still ugly :)
<ogra_> thats what you get basing all scripts on the same initial version :)
<ogra_> hmm, is it normal that i get a wlan network dialog in ubiquity but the password field is greyed out ?
<ogra_> i get a separate popup to input the WEP key, but it seems that should already be possible from the main dialog
<ogra_> hmm, and shouldnt i see a slideshow ? or isnt that ready yet
<ogra_> gah, i'm stuck with english kbd ... and i cant remember having a kbd selection dialog .... do i get an english keyboard based on the language selection nowadays ?
<ogra_> bah, and dpkg-reconfigure keyboard-configuration only regenerates my initrd, how do i tell debconf to use a different keyboard ?
<cjwatson> you should get console selection
<ogra_> i dont
<cjwatson> setxkbmap may help for the time being
<ogra_> reconfiguring console-setup gets me keymap selection etc
<cjwatson> sorry, I'm deep in the innards of apt, no attention to spare
<ogra_> but keyboard-configuration doesnt get me any debconf prompts
<ogra_> well, editing /etc/default/keyboard helps for the moment
<cjwatson> it's possible the keyboard configuration bit is after wireless selection
 * ogra_ tries a german install this time, lets see
<cjwatson> we can't really fix the ordering there until we can move keyboard handling to an indicator
<ogra_> k
<cjwatson> which is bug 800561
<ubot4> Launchpad bug 800561 in ubiquity (Ubuntu Precise) (and 5 other projects) "No way to add other keymap than english on Live CD (affects: 4) (dups: 1) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/800561
<ogra_> ah, ok, if its filed i wont dig deeper
<cjwatson> also bug 653057 sounds like what you're describing
<ubot4> Launchpad bug 653057 in ubiquity (Ubuntu) "[Maverick] can't connect to wi-fi during installation because keyboard isn't set up yep (affects: 1)" [Undecided,New] https://launchpad.net/bugs/653057
<ogra_> well, i had no prob connecting to wifi, its just that in the ubiquity dialog there is a password field thats greyed out
<ogra_> clicking the wlan i want gets me the std network manager WEP dialog though
<ogra_> (i dont htink the kbd stuff and the wlan issue are related at all)
<ogra_> hmm, intresting, so if i dont select the network in this dialog but the device the pw field isnt greyed out
<ogra_> and i definitely dont get any kbd seletion at all ...
<ogra_> (in ubiquity that is)
<ogra_> hmpf and even in a german install i end up with us kbd
<ogra_> beyond that keyboard issue all looks fine on armhf and armel ac100
<ogra_> :)
 * ogra_ moves on to omap4
<lamont> who's the victim of the day?
<lamont> I'm going to nuke the oneiric x86 livecd rootfs images on cardamom, for disk space, figured I'd check first
<lamont> cjwatson: ??
<cjwatson> I think that's OK although is there anything else that could be nuked first?
<lamont> 13722   public_html/LiveCD/lucid
<lamont> 10763   public_html/LiveCD/oneiric
<lamont> 66511   public_html/LiveCD/precise
<lamont> that's du -smx
<lamont> the precise number is a *boggle* I'll discuss with infinity later
<lamont> cjwatson: and I assume you'd prefer nuking oneiric to nuking lucid ?
<lamont> all it really means is that you'd need to regen before you could respin, but you're highly likely to need to do so anyway
<cjwatson> nuking lucid would be bad
<cjwatson> we're about to do a point release
<cjwatson> nuking oneiric is OK given that it's not too horrible to regenerate
<lamont> that was my thinking, with out the "about to do" part
<cjwatson> but yeah, clean up precise :)
<cjwatson> er in the reduce rather than remove sense
<lamont> right
<lamont> base edubuntu-dvd kubuntu kubuntu-dvd kubuntu-mobile lubuntu mythbuntu ubuntu ubuntu-core ubuntu-dvd ubuntustudio-dvd ubuntu-wubi ubuntu-zh_CN xubuntu
<lamont> edubuntu-dvd is the clear winner at 10700MB, everyone else is 2-6GB, or base/ubuntu-core at 200-700 MB
<lamont> y'all keep adding images
<stgraber> skaet: bug 924897 is caused by the switch to PAE on the i386 images. LTSP explicitly depends on the non-PAE kernel as a good part of the existing thin clients don't support PAE.
<ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/924897
<stgraber> skaet: I realise asking to have a second kernel on the CD just for LTSP is a bit too much to ask, so I'll probably relax the dependecy to "linux-image-generic | linux-image-generic-pae" keeping non-pae as the default (for these manually running ltsp-build-client post-install) while using the PAE kernel for these installing from alternate
<stgraber> I'll need to release note it though as people will need manual action post-installs to switch to the non-pae kernel if they have any thin clients requiring that (mostly thinking of VIA and Pentium M)
<stgraber> skaet: ok, I have a fix for bug 924897. Should I upload that? (it's not tested in the exact environment as it's not really easy to do for something running in the middle of d-i. I tested the change manually on another Precise machine)
<ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/924897
<skaet> stgraber, looking into it.
<cjwatson> of the set listed at the top of the pad, the only one that isn't built is cgroup-lite
<cjwatson> the pad claims that it was uploaded, but I see no evidence of that
<cjwatson> Riddell: Kubuntu supports Wubi, doesn't it?  Bug 924899 points out that (I think) bug 924535 breaks Wubi
<ubot4> Launchpad bug 924899 in wubi "Had to enter new account name and password both in wubi.exe and in the second phase Xubuntu installer (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/924899
<ubot4> Launchpad bug 924535 in casper (Ubuntu Precise) (and 1 other project) "desktop preseeded installation stops at user setup since build 20120131 (affects: 2) (dups: 1) (heat: 14)" [High,Fix released] https://launchpad.net/bugs/924535
<cjwatson> well, FSVO "breaks", I suppose it's release-notable if we must
<skaet> stgraber,  looks like we'll need to rebuild all the alternates (including server), edubuntu dvd, kubuntu dvd - have I missed some?
<astraljava> skaet: What about Studio? What's the reason for this?
<astraljava> Ahh... wubi, I presume.
<stgraber> skaet: the LTSP fix would only required alternate to be rebuilt, well, technically only i386 but well...
<stgraber> skaet: the bug is in ltsp-build-client running in d-i when we don't have linux-image-generic on the media
<skaet> astraljava, ubuntustudio switching to dvd has me unsure of the implications on it.  But if that was the trigger,  then  yup,  guess so.
<skaet> stgraber,  I'm seeing reference to ltsp-client in the kubuntu dvd
<Riddell> cjwatson: more like Wubi supports Kubuntu, I think I'm happy not having wubi working for alpha 2
<cjwatson> Riddell: *nod*
<cjwatson> astraljava: not sure Wubi supports Ubuntu Studio
<astraljava> cjwatson: I am not familiar with wubi support at all, so I'll trust your word on the matter.
<cjwatson> but the ath9k fix perhaps?
<jibel> wubi doesn't support ubuntu studio
<stgraber> skaet: do they have linux-image-generic on the media (on i386)? if not, it'll need a rebuild indeed
<Riddell> skaet: are you testing kubuntu dvds?
<skaet> Riddell,  no - was looking through manifests to scope implications of the fix and spotted that the ltsp-client was on it.
<Riddell> oh right
<Riddell> skaet: I'd also be fine having broken ltsp on our dvds
<jibel> stgraber, linux-image-generic is on kubuntu i386 DVD.
<Riddell> for alpha 2
<skaet> stgraber,  linux-generic-pae	3.2.0.12.12
<skaet> linux-image-3.2.0-12-generic-pae	3.2.0-12.20
<skaet> linux-image-generic-pae	3.2.0.12.12
<skaet> is on the kubuntu DVD
<skaet> hmm... what Riddell said
<skaet> :)
<stgraber> ok, so not affected then
<stgraber> skaet: so looks like it's just alternate then. Should I upload the fix?
<skaet> stgraber,  yes go ahead and upload
<skaet> cjwatson,  so the casper fix is going to require all the live cd/dvds to be rebuilt?
 * GrueMaster hears "rebuild", twitches.
 * charlie-tca thinks "time" when he sees "rebuild"
 * ScottK LOLs at GrueMaster when he hears rebuild.
<cjwatson> skaet: anything that cares about (a) automatic testing (b) wubi
<cjwatson> other images can probably get away without; Riddell has already decided that Kubuntu can skip it
<ogra_> GrueMaster, we dont use casper luckily ... :)
<ogra_> no need to rebuild any of arm for this ...
<skaet> thanks ogra_
<stgraber> skaet: uploaded
<stgraber> skaet: I'll run the test myself on i386 as soon as it's built so we know if the fix worked ASAP
<skaet> thanks stgraber,   I'll do that one first then.
<skaet> or slangasek will ;)
<doko_> set the i386 and amd64 to manual to get a build on a fast buildd. please ping me if you need something urgent
<skaet> doko_,  don't know the runes for that,  so looks like someone else will need to step in and help out here.
<cjwatson> I think he's saying he already did it
<doko_> good to have interpreters on this channel ;-)
<skaet> ahh... s/set/have set/
<skaet> thanks cjwatson, doko_  :)
<cjwatson> set is set in the simple past tense too ;-)
<GrueMaster> iso.qa needs to be updated with the latest netboot (20101020ubuntu103).
<skaet> stgraber, jibel - ^ can one of you help with getting netboot updated on the tracker.
<skaet> ?
<jibel> skaet, GrueMaster done
<GrueMaster> Thanks.
<skaet> stgraber,  do you want respins of Edubuntu for the casper fix?
<stgraber> skaet: it's not critical for us but might as well do it yes, I haven't tested Edubuntu yet and was planning on testing later this afternoon anyway
<skaet> stgraber, ack
<skaet> cjwatson,  can you do a review of the pad.ubuntu.com and confirm I've got the state captured accurately of what needs to be rebuilt and why?
<cjwatson> skaet: I think Xubuntu desktop may want [8]
<cjwatson> not sure about Mythbuntu and Lubuntu; may be less of an issue there, but I did get a bug report from a user trying to install Xubuntu using Wubi who was bitten by that
<skaet> cjwatson,  ok,  will plan on Xubuntu desktop then, unless one of the Xubuntu crowd says otherwise.   Not seeing gilir or superm1 in the channel to ask - will see if I can hunt them down later (will leave it as ? then for those)
<skaet> Thanks!
<charlie-tca> I will go with cjwatson's recommendations for Xubuntu
 * charlie-tca highly respects cjwatson when he makes a suggestion
<skaet> :)
<slangasek> cjwatson: the most recent builds I did should already have the ath9k fix landed on any livefses, if I didn't screw it up - so perhaps that means ubuntustudio doesn't care about respinning?
<cjwatson> ah, could be
<slangasek> ogasawara: are you still maintaining the code behind http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html?  (Is that going to remain the url for this, and should we be talking to QA about getting someone else to maintain it?)
<cjwatson> the pad didn't capture that in a way I understood :)
<astraljava> slangasek: I was sort of waiting for ScottL to tell us whether he wants the lightdm-greeter fix in before it or not, but it's still not settled.
<ogasawara> slangasek: technically I still look after it, although I haven't really touched it aside from s/oneiric/precise/
<slangasek> cjwatson: right, sorry, I haven't usefully updated the pad, I don't really have the feel for how that works
<ogasawara> slangasek: I don't mind maintaining it for now as it's not much work involved and I'm happy to make tweaks.  Any major re-work I'd probably rather hand over to QA.
<skaet> slangasek, astraljava - ltsp-client - https://launchpad.net/bugs/924897 needed for Ubuntu Studio ?
<ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,Fix released]
<skaet> slangasek,  want to get on the phone and I'll walk you through how we've been using the pad?
<slangasek> ogasawara: so the main thing right now is that we should probably have manifest tracking for the arm preinstall images
<cjwatson> skaet: ltsp> no
<astraljava> skaet: It's not needed for us, but we would be interested in the ath9k fix, as some of the milestone testers have hw that need that driver.
<astraljava> s/need/use/
<slangasek> skaet: well, I did get the briefing earlier when you started using it, I just don't have the *feel* for it yet :)
<skaet> I'm not seeing the ath9k fix on the pad - so it probably should be added explicitly.
<cjwatson> astraljava: you've got it already - sorry for being confusing
<slangasek> skaet: that's [3]
<cjwatson> skaet: no need
<skaet> slangasek, cjwatson - ok.  :)
<ogasawara> slangasek: that should be easy enough to add, I'll ping you when it's available
<slangasek> ogasawara: thanks :)
<slangasek> strange smattering of package uploads overnight that hit the alternates, I see... libraw? http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport/iso_pkg_diffs/ubuntu-i386-alt.html
<astraljava> cjwatson: Ok, thanks!
<skaet> slangasek,  to confirm [2],[3],[4],[5] - are now in the images we've got up on the tracker and in testing?
<slangasek> skaet: 2 definitely, 3 may be missing yet from some of the arm images (that's why I'd like the weather report updated to be able to tell me), 4 and 5 are definitely both done
<skaet> slangasek, gotcha. :)
<GrueMaster> slangasek: I don't think we care about 3 so much.  None of our "supported" image systems use ath9k (only AC100 and it has a community kernel).
<hallyn> libvirt fix being queued up - shall I wait to push it?  (it's not urgent)
<slangasek> GrueMaster: ok, thanks
<slangasek> skaet: so according to the weather report, kubuntu alternate is actually still missing the ath9k fix in its d-i builds
<slangasek> that's a quick'n'easy respin that I can do right now
<slangasek> Riddell: ^^
<skaet> slangasek, should bug 924752 be on the pad for triggering rebuilds?   just the wubi affected?
<ubot4> Launchpad bug 924752 in wubi "wubi r255 - Ubuntu Desktop failed to install from disk image - wrong download url (affects: 1) (heat: 6)" [Critical,Fix released] https://launchpad.net/bugs/924752
<slangasek> btw, in light of the discussions above about disk space, I've also nuked the stale ubuntustudio daily/ directory in favor of the new dvds
<GrueMaster> slangasek: Looking at the bug, I assume only the main kernel was fixed?  That only covers omap3, which none of the supported systems have wifi built in.  Could possibly affect usb wifi, but I think the affected user base will be extremely low.
<skaet> slangasek,  wait on that alternate rebuild until [9] is built I think,  its marked down for rebuilds when that's done as well.
<cjwatson> cdimage doesn't have especially meaningful disk space constraints these days
<slangasek> cjwatson, jibel: does bug #924752 need fixed on the CDs, or just in the standalone wubi?
<ubot4> Launchpad bug 924752 in wubi "wubi r255 - Ubuntu Desktop failed to install from disk image - wrong download url (affects: 1) (heat: 6)" [Critical,Fix released] https://launchpad.net/bugs/924752
<cjwatson> lamont was talking about the livefs builders
<slangasek> cjwatson: ah, ok
<cjwatson> still, nuking that directory probably made sense
<cjwatson> slangasek: it *should* be able to copy from the CD rather than downloading
<cjwatson> I think
<slangasek> cjwatson: well, it also leads to the weather report claiming that 682 packages are out of date on an image we no longer care about ;)
<cjwatson> slangasek: any rebuild will pick it up anyway ...
<cjwatson> slangasek: heh, yeah
<slangasek> skaet: so no, we don't need to track 924752 for respins
<slangasek> GrueMaster: yes, it's the main kernel
<slangasek> skaet: ack, holding off on respin
<ogra_> ac100 doesnt have ath9k anyway
<ogasawara> slangasek: hrm, is there an arm specific Packages.gz file so that I can compare what's in the archive to what's in the manifest?
<ogra_> so no issues here
<skaet> slangasek, re; 924752 ok, have updated pad to reflect its not a respin trigger (so I don't end up asking again)
<ogasawara> slangasek: nm, found it
<skaet> slangasek,  looks like ltsp-client is published now,  so go ahead with those rebuilds.
<skaet> https://launchpad.net/ubuntu/+source/ltsp/5.2.16-0ubuntu13
<highvoltage> ltsp-client? rebuilds? does that affect edubuntu too?
<slangasek> highvoltage: it wasn't marked as such; the bug impacts LTSP client installs from an image that doesn't include linux-image-generic
<slangasek> highvoltage: which seems not to apply to edubuntu, so no need for a respin unless you want it to give the other code path testing
<skaet> highvoltage - edubuntu has linux-image-generic in its manifest, so its not affected.
<skaet> however edubuntu needs respin for [8]
<stgraber> highvoltage: Edubuntu won't get rebuilt for this but will for some other packages (casper being one). I'll do the testing this afternoon with the new build.
 * skaet notes [8] is casper fix.... 
<slangasek> alternate respins going
<stgraber> slangasek: cool. Will test for the LTSP fix when I'm back with something to eat (should be right around the time where they'll be ready)
<charlie-tca> What is the cutoff for getting the images tested now for alpha2?
<slangasek> infinity: we're building both daily and daily-preinstalled for ubuntu-server on armel?
<skaet> charlie-tca 1400 GMT on Feb 2.
<highvoltage> stgraber: ok
<skaet> slangasek,  any reason not to start the casper rebuilds as well?
<charlie-tca> Ok, upgrade testing may have to be skipped for Xubuntu
<ogra_> slangasek, hmm, we shouldnt build daily (only netinst)
<slangasek> stgraber: iso tracker bug: if I try to disable all alternates at once, I get an error about an invalid selection
<slangasek> stgraber: not sure I can reproduce it however
<stgraber> slangasek: could it be something published since you last refreshed the page?
<ogra_> slangasek, daily will happen once we have the marvell kernel which isnt the case yet
<cjwatson> slangasek: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview?action=diff&rev2=36&rev1=35 - can you review?
<slangasek> ogra_: er, considering the daily-preinstalled (which is not a netinst) has a crontab entry all its own, I'm not inclined to disable that.  I'm only asking about the duplication between daily and daily-preinstalled
<ogra_> slangasek, yes, i was referring to that, we should not build daily yet
 * GrueMaster didn't even know a daily existed.
<cjwatson> there's no such thing as a netinst for Ubuntu to the best of my knowledge - do you mean netboot?
<ogra_> only daily-preinst
<GrueMaster> cjwatson: yes, netboot.
<ogra_> cjwatson, well, a mangled netboot image that pretends to be a mini iso :)
<cjwatson> netinst is a term of art related to Debian installer images
<slangasek> skaet: looks good to me for the casper respinning; I'll launch that here shortly
<stgraber> slangasek: hmm, actually got a trace in the logs, so indeed a bug. Will investigate.
<slangasek> stgraber: shouldn't have been due to anything being published, I had refreshed the page this morning
<cjwatson> it refers specifically to an image which contains all the installer udebs plus the base system but is configured to install everything else from the network
<cjwatson> we don't have those
<ogra_> right
<slangasek> ogra_: so you don't need server daily *now*, but you *will* soon?
<slangasek> for a disjoint set of subarchs?
<cjwatson> so I'm picky about the terms in case somebody invents one for Ubuntu and then I get confused :)
<ogra_> slangasek, yes, as soon as the marvell kernel exists we will roll normal d-i daily server images with it
<ogra_> cjwatson, we just call it (falsely) like that because the install pulls all packages from the network, no debian relation at all :)
<slangasek> cjwatson: release note LGTM
<cjwatson> thanks
<slangasek> skaet: bug #924281 was fixed with an upload of lxc, not of cgroup-lite; fixing the bug state & pad
<ubot4> Launchpad bug 924281 in cgroup-lite (Ubuntu) "cgroup-lite not installable inside 'lxc create -t ubuntu' container (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/924281
<skaet> slangasek,  :)  thanks for solving that mystery.
<slangasek> stgraber: no really, bug #924836 has nothing to do with network-manager - /etc/init/failsafe.conf doesn't care about network devices that aren't listed in /e/n/i
<ubot4> Launchpad bug 924836 in network-manager (Ubuntu Precise) (and 3 other projects) "network-manager does not tell plymouth it has started (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/924836
<ogasawara> slangasek: arm manifests added, all showing to be up to date
<slangasek> ogasawara: sweet, thanks!
<stgraber> slangasek: oh, right, misread the script ... I'll eventually get a clear picture of all that in my head :) right. when lo is brought up, the ifupdown hook should emit static-network-up as all the interfaces are ready
<stgraber> slangasek: so the question is why it didn't happen or what make the script think there was something else to bring up
<slangasek> yep
<stgraber> slangasek: asked for details. My guess is that one of the other if-up hooks failed making ifupdown stop there and never called the upstart one. That's easy to check with upstart job logging.
<slangasek> right
<GrueMaster> ogasawara: Not all arm images are listed.  Missing Kubuntu-desktop (omap, omap4), and Ubuntu-Server (omap, omap4).  Both are daily-preinstalled.
<ogasawara> GrueMaster: ah thanks, will add those
<GrueMaster> Also, Ubuntu Netbook Remix and Kubuntu Netbook are no longer built.
<GrueMaster> (both were rolled into desktop).
<stgraber> skaet: same LTSP issue says jibel ... apparently my fix didn't work. I'm grabbing the image here to investigate, ETA around 30min till I have an idea of what's broken (and that wasn't fixed by my fix)
<skaet> stgraber, ack.
<slangasek> skaet: do the question marks mean we're waiting for feedback on mythbuntu and lubuntu before deciding te respin?
<hallyn> skaet: is now a good time to push a new libvirt with bugfix?
<skaet> slangasek,  yes - default is probably going to be release note, but want them to have the option.
<skaet> hallyn,   is it a blocker for A2 or can it be release noted?
<hallyn> skaet: it blocks pxeboot of vms, but can be worked around - release noted is probably fine
<hallyn> Daviey here?
<skaet> hallyn,  if it can be worked around, then lets just release note it for now.
<Daviey> hallyn: always
<hallyn> skaet: ok, will do.  no idea where to release not it, btw
<hallyn> release note, that is
<stgraber> skaet: just noticed my auto upgrade tester just pushed the results for today (flavours). Edubuntu and Kubuntu are all good (better than yesterday) but Xubuntu and Mythbuntu both fail because of a unity-greeter crash (affects i386 and amd64)
<hallyn> Daviey: just wanted your assessment of the bug importance - i don't know if there are projects blocked by it (bc of automated installs breaking)
<Daviey> hallyn: Can you quote the bug number, and reference a patch?
<charlie-tca> I wonder if that is because we don't use unity-greeter?
<Daviey> hallyn: i think we are too early in the cycle to be blocked on something not working :)
<stgraber> charlie-tca: well, if it crashes, that's because it's installed for some reason :)
<hallyn> iDaviey: cool, thx
<skaet> stgraber,  re: unity-greeter - is it a known issue already or a new one?  (bug number?)
<stgraber> skaet: no idea, all I see is a .crash in the upgrade tester and apport won't let me use the .crash files from the auto upgrade...
<stgraber> skaet: someone would need to manually run the upgrade to figure out exactly what's happening and be able to report the crash with apport
<skaet> stgraber,  ack.
<slangasek> skaet: are we not worrying about oversizedness right now?
<skaet> charlie-tca, not sure.   Can you see if you can help figure it out?
<skaet> slangasek,  yes, we'll document our oversizedness as part of the release notes for A2
<slangasek> ok
<charlie-tca> Yes, I can try an upgrade, but it will take about 4-6 hours here
<charlie-tca> wait, which one am I haelping with?
<charlie-tca> the oversized for xubuntu doesn't matter yet. We adjust it around beta1
<skaet> charlie-tca, the upgrade crash is the one I'm wondering about.   However if you're comfortable release noting it (ie. don't do it), that might be an option.
<Daviey> hallyn: have the bug and patch?
<charlie-tca> I don't see much of an option but to release note it. It will take me at least 12 hours to run both upgrades
<charlie-tca> if I don't do anything else while they are running
<charlie-tca> I ran them for alpha1, and they worked, but the new tracker has always shown them failing
<charlie-tca> skaet: my choice is to run all tests except upgrades, or run the upgrade tests
<stgraber> charlie-tca: I'm trying to boot one of the auto upgrade images manually, see if I can extract something
<stgraber> charlie-tca: hmm, you don't seem to have a login screen at this stage, all I see is a black screen with a white bar at the top
<charlie-tca> How can that be?
<charlie-tca> because it installed unity-greeter
<stgraber> charlie-tca: well, AFAICT it's using unity-greeter. greeter-session=unity-greeter in /etc/lightdm/lightdm.conf
<charlie-tca> that has to be removed, and xubuntu-greeter installed
<charlie-tca> Xubuntu willl not work with unity greeter
<stgraber> charlie-tca: right, no xubuntu-greeter installed
<stgraber> charlie-tca: unity-greeter is getting installed because lightdm recommends it
<charlie-tca> but it won't work
<stgraber> charlie-tca: and sets itself as the default in its postinst
<charlie-tca> which makes xubuntu fail because it won't login
<charlie-tca> so, the user must then manually switch to a tty, install xubuntu-greeter, remove unity-greeter, and do what ever else he needs to be able to login
<charlie-tca> We had that fixed in 11.10, but apparently it will take fixing for each release
<stgraber> charlie-tca: what's the actual name for xubuntu-greeter? there isn't a xubuntu-greeter package in the archive
<skaet> charlie-tca,  release note it is.
<micahg> umm, the resolver shouldn't be adding unity-greeter to xubuntu as both lightdm and lightdm-gtk-greeter are recommends
<micahg> s/recommends/depends/
<charlie-tca> micahg: what's the name we use?
<micahg> we're using lightdm-gtk-greeter which provides lightdm-greeter
<stgraber> micahg: well, there's nothing wrong (at least for apt) with installing lightdm-gtk-greeter and unity-greeter
<micahg> stgraber: yes, there is when it's seeded like that :)
<micahg> unity-greeter is not on the xubuntu live image
<stgraber> micahg: hmm, indeed, that's weird (just looked at the exact recommends/provides)
<charlie-tca> Thanks, micahg
<micahg> at least amd64 from 2 days ago
<charlie-tca> and won't allow the login to work, for whatever reason
<stgraber> micahg: when was that introduced?
<micahg> stgraber: which?
<stgraber> micahg: lightdm-gtk-greeter providing lightdm-greeter and lightdm recommending unity-greeter | lightdm-greeter
<micahg> oneiric IIRC
<micahg> lightdm (0.9.3-0ubuntu3) oneiric; urgency=low
<stgraber> k, so it's not a case where lightdm would be upgraded before lightdm-gtk-greeter pulling unity-greeter as the provides isn't part of lightdm-gtk-greeter yet, then
<stgraber> micahg: oh, hmm, wait, are you telling me you actually depend on unity-greeter not being on the media for your stuff to work?
<micahg> stgraber: idk about depend, but I think so, it certainly shouldn't be on the xubuntu media
<stgraber> if so, that's the problem, because auto-upgrade-tester doesn't use a media, it uses the archive and so unity-greeter is available
<stgraber> just like it'd be if you did a Netboot install (which very well may be failing for you at the moment)
<micahg> the two greeters will overwrite the configuration for each other depending on which is configured last
<ScottK> That sounds like a clear bug.
<micahg> not really, you can only have one greeter working at a time
<micahg> although, idk why unity-greeter wouldn't work with xubuntu
<charlie-tca> I think because it doesn't start the right file, it tries to run the wrong session
<stgraber> the fix here is that some xubuntu package should probably depend on lightdm-gtk-greeter explicitly and conflict with unity-greeter
<micahg> I'm certainly using it with xubuntu on one machine, but idk about the live media
<stgraber> otherwise you depend on what's on the media and that's just wrong
<micahg> I think we have a hack somewhere that specifies the lightdm-gtk-greeter for xubuntu
<charlie-tca> It's the way lightdm is coded to use unity and unity session
<micahg> stgraber: well, xubuntu-desktop depends on lightdm-gtk-greeter, but it shouldn't conflict with unity-greeter
<stgraber> micahg: well "something" should ensure you can't get two greeters are once and that the default is lightdm-gtk-greeter in your case (even if unity-greeter is available for installation)
<micahg> oh wait, I don't have unity-greeter on that other machine anymore
<micahg> stgraber: that's what the seed is supposed to do
<micahg> xubuntu-desktop depending on lightdm and lightdm-gtk-greeter should insure that
<micahg> do we have apt debug output for this use case?
<micahg> 2 greeters at once isn't an issue on an installed system
<stgraber> micahg: what I see is the release upgrader installing "xubuntu-desktop" on a minimal ubuntu system and both lightdm-gtk-greeter and unity-greeter in the list
 * micahg tries in a chroot
<micahg> yeah, I see that too which is wrong, let's see what's pulling it in
<stgraber> charlie-tca: good news, only a very limited subset of people will get the issue, actually these would likely have a broken Oneiric system too, bad news, auto upgrade testing is kind of pointless for you until that's solved (and will need solving as an SRU in Oneiric for it to work)
<ScottK> micahg: One package overwriting the configuration for another is a bug.  It doesn't matter if only one can run at a time (think about sendmail overwriting postfix config files).
<micahg> gah, no debug output
<charlie-tca> stgraber: thanks for pushing through to this point on it.
<micahg> ScottK: it's not overwriting the configuration, just setting itself as the current greeter akin to setting the dm before like gdm, kdm, xdm
<stgraber> ScottK: they both use some lightdm command to set themselves as default, AFAIK they never touch the config directly.
<stgraber> micahg was faster ;)
<ScottK> Oh.  I see.
<ScottK> thanks.
<stgraber> skaet: found the bug in my fix, should have thought of it ... my check (apt-cache show) is running outside the LTSP chroot which isn't guaranteed to have the same apt sources as the chroot (and in this case, doesn't)
<stgraber> skaet: I'll have a fix ready for upload in a few minutes (just checking out another LTSP weirdness on Edubuntu first)
<skaet> stgraber, goodness.   :)
<micahg> stgraber: I still think it's a resolver issue, but I can't get any debug output
<stgraber> skaet: too many levels of chroot going on ;) installer => target => ltsp chroot each with potentially different apt sources ...
<Riddell> skaet: I need to go out for a few hours
<Riddell> skaet: when is release expected?
<slangasek> tomorrow? :)
<skaet> Riddell,  we'll be doing the release tomorrow - once we've gotten the test results and release notes updated.
<Riddell> I need to test the new kubuntu alternates slangasek has made, otherwise I'm happy with the kubuntu images for an alpha
<Riddell> I can do more tests if the release is not early tomorrow
<Riddell> virtualbox actually works on precise which is a big help
<slangasek> ubuntu desktop respin posted
<slangasek> only xubuntu, edubuntu, ubuntu-dvd outstanding
<Riddell> I can't do arm tests yet, I need a power supply for my pandaboard so those won't be in kubuntu alpha 2 I expect
<ScottK> Unless GrueMaster has some time for them ...
<GrueMaster> Sigh....
<GrueMaster> I'll add them to my list, but they will be last.
<GrueMaster> Riddell: You can always power it from the microusb to your PC if you have a USB Y cable (like for external drives).
<skaet> Riddell,  ok.   I'll have the draft of the techoverview ready for review later today.
<Riddell> GrueMaster: so a phone charger should do it?
<skaet> Riddell,  please add any Kubuntu notes when you're back.
<Riddell> will do
<GrueMaster> Build versions of arm desktop need to be bumped on iso.qa.  (20120201.1)
<slangasek> infinity: ^^ are those from your respin?
<stgraber> skaet: I have fixes for both the Edubuntu issues (caused by the "inotify doesn't quite work with overlayfs" kernel bug) and the Ubuntu Alternate issue. Testing both now
<stgraber> skaet: if you want these fixes, Ubuntu Alternate and Edubuntu will need rebuilding
<slangasek> GrueMaster: updated
<skaet> thanks stgraber,  ok,  will mark them for rebuild.
<infinity> slangasek: I did no respin.
<slangasek> infinity: didn't you do a build last night after d-i rebuilt?
<infinity> slangasek: No, I just uploaded d-i and went to sleep. :P
<slangasek> hmm
<slangasek> infinity: oh, that's because we built in two batches so they had different serial numbers
<infinity> Ahh, yes, that makes more sense.
<infinity> And an irksome side effect of that change.
<infinity> Oh well.
<stgraber> skaet: uploaded
<slangasek> infinity: yeah, not a big deal, we just have to remember that :)
<gilir> skaet, is it possible to respin lubuntu desktop images when the last lubuntu-meta upload will be built ?
<skaet> gilir,  should be possible.   when has lubuntu-meta been uploaded?
<gilir> skaet, just a minute ago :)
<stgraber> skaet: Edubuntu would like bug 882147 to be released targeted and its importance bumped. It's the ultimate cause of all these ltsp-live bugs and the reason why I had to add a bunch of upstart and NM hacks in ltsp-live (as in, force them to rescan/restart their config to workaround inotify not working)
<ubot4> Launchpad bug 882147 in linux (Ubuntu) "overlayfs does not implement inotify interfaces correctly (affects: 4) (dups: 3) (heat: 42)" [Medium,Triaged] https://launchpad.net/bugs/882147
<stgraber> *release targeted
<skaet> gilir, okie,  please post an explicit warning in the channel during soft freeze  :)   which bug number?
<stgraber> skaet: this is also annoying when doing things like "tail -f /var/log/syslog" in a livecd and it just doesn't work because of that bug
<slangasek> hah, right, tail supports inotify these days
<skaet> stgraber,  I've up'd the priority and marked it targetted to precise.
<gilir> skaet, ok, will do it next time, there is no specific bug number, the seed was very outdated
<skaet> gilir,  thanks.  ok,  putting it on the pad as such.
<gilir> skaet, but it's not risky for lubuntu desktpop iso, there are currently badly broken, and I'm not even sure this upload will improve the situation :/
<stgraber> skaet: thanks
<slangasek> gilir: so you want desktop respin only, not alternates?
<stgraber> slangasek: yeah, we discovered that at the release sprint when doing tail -f /var/log/syslog and wondering why syslog wasn't working in the live environment ;) when in fact it was "simply" inotify not working with overlayfs
 * slangasek nods
<gilir> slangasek, I'm checking the alternate right now, to see if it's necessary also
<slangasek> stgraber: what was the upload just now to work around this?
<stgraber> slangasek: ltsp for ltsp-live. A super-ugly hack ... after installing the packages needed for LTSP, I run "initctl reload-configuration" to have upstart manually scan /etc/init and for Network Manager, well ... I restart it completely ...
<skaet> gilir,  ack.  The rebuild will be picking up [8] by the way.   Hopefully that will help to.o
<gilir> skaet, thanks
<skaet> stgraber,  can you confirm ltsp .2.16-0ubuntu14 should also fix bug 924897.  (I think so, but double checking...)
<ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/924897
<stgraber> skaet: yes, the second changelog entry is for that one. I looked at the bug list on LP and couldn't find it (as it was fix released) so didn't put the LP: # entry in changelog
<skaet> slangasek, ^ This was [9] on the tracker.
<skaet> stgraber,  probably should have the status changed back to Fix Committed - since it isn't really fixed.
<skaet> yet. :)
<stgraber> :)
<skaet> slangasek, ^ same set we did for [9] will need to be redone for [12]  - at least these are nice and speedy.  ;)
<slangasek> skaet: well, if it's ltsp-live, isn't it only edubuntu that's actually affected by the bug?
<slangasek> we can respin to ensure the images are up to date of course, but it doesn't seem to impact on the releasability
 * skaet going to check the backscroll - but thought it was wider impact... 
 * skaet could be wrong though :)
<slangasek> bug #924897 was already fixed in a previous upload and alternates already respun for it
<ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/924897
<slangasek> stgraber: was the fix in -0ubuntu13 incomplete?
<stgraber> slangasek: yes
<skaet> slangasek, yes.  bug is in ltsp-build-client running in d-i when we don't have linux-image-generic on the media.
 * skaet found what she wanted in the back scroll
<slangasek> ok
<slangasek> skaet: right, I hadn't seen that you'd stuck another bug # on [12] :)
<stgraber> slangasek: the new LTSP requires Ubuntu Alternate and Edubuntu to be respin (nothing else as ltsp-live is Edubuntu specific and the non-PAE issue only affects Ubuntu Alternate, everything else has the kernel on the media)
<slangasek> stgraber: does server have -generic on it?
<stgraber> slangasek: I don't think so, but they don't have LTSP (LTSP requires a full desktop install)
<skaet> slangasek,  :)  you'd removed [9] so seemed easier to add it there, since the fix for [12] referenced it.
 * skaet wants time machine option on this pad... 
<slangasek> stgraber: so the ltsp-client-builder package on the ubuntu-server CDs is... unrelated?  superfluous?
<slangasek> stgraber: none of [kxl]ubuntu alternate have linux-image-generic on the i386 CD, and they do all have at least ltsp-client-builder
<slangasek> are they not affected because they do the LTSP install via the network only?
<skaet> slangasek,  issue is recovering from the fact that they don't have linux-image-generic on the image.  :)
<skaet> those images that have it don't need the fix
<skaet> (ie. dvd's were ok)
<stgraber> slangasek: hmm, server having ltsp-client-builder sounds like a bug, there's no way that'd work (ltsp-client-builder forces ltsp-build-client to use the install media as source)
<slangasek> yes, I understand
<slangasek> stgraber: ok, so scratching ubuntu-server off the rebuild list.  How about the other?
<slangasek> others
<stgraber> slangasek: [kxl]ubuntu might be affected, I didn't know they actually had LTSP on them (I only test Ubuntu and Edubuntu). Would be worth checking if the LTSP option is visible in gfxboot for these, if not, the presence of ltsp-client-builder is a bug
<slangasek> stgraber: I'll exclude them from the respins for now, then
<stgraber> slangasek: ok. I have a local copy of all of them, I'll have a quick look in gfxboot to see which actually offer ltsp as an option
<charlie-tca> Xubuntu can release note that the fix will be available in the daily image tomorrow
<slangasek> charlie-tca: does an ltsp install work at all from Xubuntu CDs?
<charlie-tca> not sure, I thought it was only desktop images
<slangasek> I suspect then that there's no need to release something you're not QAing anyway
<charlie-tca> slangasek: it is not something we actually test, but every once in a while a user does an ltsp install. That's when we find out if it is broken
<stgraber> slangasek: kubuntu => not in gfxboot, xubuntu => in gfxboot, lubuntu => not in gfxboot
<stgraber> slangasek: I also confirmed that it's not in gfxboot for ubuntu server
<slangasek> stgraber: ok, thanks
<slangasek> charlie-tca: so I won't respin xubuntu alternate for ltsp unless you insist :)
<charlie-tca> Thank you. I would prefer we do NOT do it
<stgraber> slangasek: so it looks like only Ubuntu and Xubuntu offer LTSP in their alternate install and Edubuntu is the only one offering it in a live install (it costs an extra 400MB so we're the only one who can afford it space wise ;))
<slangasek> oh wait
<slangasek> I misparsed!
<slangasek> charlie-tca: so xubuntu *is* affected, but it's still release-notable if you prefer
<charlie-tca> I think I told the last person trying that to go to server and ask how
<charlie-tca> slangasek: we will release note it. Thanks
<charlie-tca> If everything else works, we will be happy
<stgraber> charlie-tca: Xubuntu should have someone who actively wants LTSP to work and can test/fix it and coordinate with upstream (#ltsp) or it should be dropped, I don't really have time to spend on testing/fixing it in Xubuntu and I doubt someone else in LTSP upstream does.
<charlie-tca> I will bring that up to the powers that be, then. I don't care either way about LTSP, myself.
<stgraber> charlie-tca: thanks
<charlie-tca> stgraber: thank you for bringing it to my attention
<stgraber> skaet: just so you know, I'm looking at bug 924836 which seems to affect any current system during first boot, making first boot time 90s slower, potential reason for a mass respin (I tested on Ubuntu but Kubuntu at least is also affected).
<ubot4> Launchpad bug 924836 in network-manager (Ubuntu Precise) (and 3 other projects) "network-manager does not tell plymouth it has started (affects: 1) (heat: 8)" [High,Invalid] https://launchpad.net/bugs/924836
<stgraber> slangasek: confirmed, it's /etc/network/if-up.d/000resolvconf failing to find /run/resolvconf/interface and blocking the other if-up.d scripts
<slangasek> oh good, if it's only resolvconf then :P
<slangasek> stgraber: will you follow through?
<slangasek> hmm, why would that be only on first boot?
<stgraber> slangasek: yeah, I'm continuing to investigate the exact source, /run/resolvconf doesn't exist at all on first boot ...
<slangasek> hmm
<stgraber> slangasek: and /var/lib/resolvconf/convert exists, so that means the upstart job never started (or failed pretty early)
 * slangasek nods
<stgraber> slangasek: right, resolvconf is "stop/waiting" and I don't have any log for it in /var/log/upstart
<slangasek> odd
<slangasek> is there something on first-boot that prevents mountall from running normally?
<stgraber> slangasek: I don't get why it didn't start though, it's "start on mounted MOUNTPOINT=/run" that should definitely work
 * slangasek nods
<stgraber> slangasek: apparently yes "mountall: Event failed"
<stgraber> slangasek: in /var/log/boot.log
<slangasek> fun
<stgraber> slangasek: I can also confirm that the second boot works fine
<stgraber> actually, fine-ish, I still have the mountall "Event failed" in boot.log, but the boot no longer hangs
<cjwatson> interaction with ureadahead profiling somehow, maybe?
<stgraber> cjwatson: oh, good idea, yeah, it's "start on starting mountall", so a failure would be pretty bad. I'll try to flush the profile and see what happens
<stgraber> hmm, doesn't seem to be it. I certainly regret not making a snapshot of the VM post install. Re-installing now to have that snapshot ...
<stgraber> running a full diff of post-install / post-first-boot should explain what's going on
<skaet> stgraber,  slangasek,  since the fallback mode (while slower) still works,  am thinking it might be best to look at this one opportunistically - ie. go ahead and upload, but we won't mandate a massive rebuild for A2, since thing seem to work in recovery mode.     Document it in release notes, and know the dailies will have it.
<stgraber> skaet: well, apparently it's not just a matter of taking 90s to boot instead of 5s, a bunch of upstart jobs don't start, including resolvconf, so I'm not too sure you'd be able to resolv anything post-boot
<stgraber> will know more once I found the source of the issue though
<stgraber> (we could still release note that it'll take 90s to boot and you'll then need to reboot to have it working though)
<skaet> stgraber,  ok,  standing by
<slangasek> ubuntu alternate, edubuntu respin for ltsp going
 * stgraber wonders why Ubiquity is "Importing documents and settings" and "Restoring previously installed packages" on a perfectly blank disk image ;)
<slangasek> and lubuntu also going
<jibel> verification failed for bug 924535
<ubot4> Launchpad bug 924535 in casper (Ubuntu Precise) (and 1 other project) "desktop preseeded installation stops at user setup since build 20120131 (affects: 2) (dups: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/924535
<slangasek> :/
<slangasek> cjwatson: ^^ bug #924535 is still an issue, if you're still around
<stgraber> doh, that boot hanging issue seems to be a racy ...
<stgraber> ok, at least it showed up on the second boot try ;)
<stgraber> Can someone with access to nusakan fix Ubuntu Studio mapping with the tracker?
<stgraber> No iso.qa.ubuntu.com product found for ubuntustudio/dvd/precise-dvd-amd64; skipping.
<stgraber> No iso.qa.ubuntu.com product found for ubuntustudio/dvd/precise-dvd-i386; skipping.
<slangasek> stgraber: where is the mapping?
<stgraber> slangasek: no idea, I don't have access to that part of the magic. It's whatever ends up calling post-images-to-iso-tracker.py
<jibel> verification of bug 924752 failed
<ubot4> Launchpad bug 924752 in wubi "wubi r255 - Ubuntu Desktop failed to install from disk image - wrong download url (affects: 1) (heat: 6)" [Critical,Fix released] https://launchpad.net/bugs/924752
<slangasek> jibel: same error as before or not?
<stgraber> slangasek: hmm, nothing interesting that I can find in the diff ... only difference in /etc are resolv.conf (simple change in content as NM starte), mtab and udev's 70-persistent-cd.rules...
<slangasek> stgraber: why would you expect it to be a diff in /etc, though?\
<jibel> slangasek, double-checking, the downloader returns a 403 but the url is correct and the file exists on the server
<stgraber> slangasek: well, I was expecting "something" to show up in the diff between post-install and after the first boot... /var isn't particularly more interesting. A new entry in /var/cache/cups, the dbus UUID, a dhcp lease, NM's interface status, update-manager and update-notifier info on release and updates and the lightdm session files
<slangasek> jibel: which url is it using?
<slangasek> jibel: it's possibly a case of bad timing, since the wubi tarball was just updated on cdimage
<slangasek> stgraber: well, but there would be /var/cache changes for ureadahead, too
<slangasek> stgraber: but what about logs?
<jibel> slangasek, false alarm. I used the wrong version of wubi. removing all wubi.exe from the drive and trying again.
<jibel> 12.04 is downloading
<slangasek> jibel: ok :)
<stgraber> slangasek: definitely is a race ... got 10 good boots in a row (every time going back to the post-install disk), then started stressing my SSD with some I/Os (copying disk images around) and got the hang
<slangasek> stgraber: that's 10 good first-boots from the snapshot?
<stgraber> slangasek: yeah
 * slangasek nods
<slangasek> fwiw, I've just done a precise install test here... on the first boot I hit the "waiting for network" problem, and then on the second boot I see that NM has taken over /etc/resolv.conf.
<slangasek> ah, no
<slangasek> it's that /var/lib/resolvconf/convert is still present
<slangasek> interesting
<stgraber> oh, so resolvconf still hasn't started for you on the second boot ...
<slangasek> correct
<stgraber> slangasek: can you confirm the "mountall: Event failed" in /var/log/boot.log?
<slangasek> yes
<stgraber> I confirmed that manually doing "initctl emit mounted MOUNTPOINT=/run" works and fixes /etc/resolv.conf, now to understand why it doesn't do it at boot time...
<stgraber> hmm, actually, stupid question, are we supposed to get that event when mountall itself doesn't actually mount it?
<slangasek> oh, I really hope so :P
<stgraber> ok, time for mountall --debug I guess
<cjwatson> slangasek: argh, I tested that :(
<stgraber> slangasek: if it doesn't emit mounted MOUNTPOINT for already mounted mount points, that "may" be my fault (with the code to ensure mountall doesn't hide an existing mount point)
<cjwatson> slangasek: I'll be around in a bit to have a look
<slangasek> cjwatson: ok, thanks
<cjwatson> jibel: if you're still here, it would be helpful to know what debconf question you're using to preseed the password
<cjwatson> jibel: I thought you were using passwd/user-password-crypted or however it's spelled, but it's just occurred to me that you might be using the non-crypted version
<cjwatson> which is overwritten as a side-effect of user-setup-apply ...
<jibel> cjwatson, d-i passwd/user-password and d-i passwd/user-password-again
<cjwatson> damn, I should have asked
<slangasek> stgraber: mountall definitely emits events for all filesystems, even those it didn't mount
<slangasek> (all filesystems listed in /etc/fstab or /lib/init/fstab, that is)
<cjwatson> ok, that's an easy fix in casper, just add those to the debconf_backup and debconf_restore calls
<stgraber> slangasek: good, so I didn't break it, still doesn't explain what's going on ... resolvconf should start or fail but either way I should have a log file for it ...
<slangasek> stgraber: oh blast
<slangasek> stgraber: /run is always mounted BEFORE / IS WRITABLE
 * slangasek facepalms
<stgraber> slangasek: oh, yeah, that would be a problem indeed ;)
<jibel> cjwatson, I can change to -crypted and release note it for a2
<jibel> I asked the cert team to verify it works with their tests
<stgraber> slangasek: so just changing resolvconf to "start on mounted MOUNTPOINT=/ and mounted MOUNTPOINT=/run" should do the trick
<slangasek> no
<slangasek> not at all
<stgraber> oh right, because mountall will emit mounted for / even though it's ro ...
<slangasek> the whole idea of using a stamp file for /etc/resolv.conf linking needs to be scrapped
<slangasek> no
<cjwatson> jibel: I guess that depends - if we're going to have to rebuild for this resolvconf thing anyway (which I've only peripherally been following so may be talking out my hat) then casper is an easy ride-along
<slangasek> the problem is that we need to *block the boot* while getting /etc/resolv.conf in place
<cjwatson> backing up / restoring a couple extra questions isn't going to make it worse
<slangasek> so since we can't do that reliably if we have to write to /, we instead need to ensure /etc/resolv.conf linkage is done at package install time, not at boot time
<stgraber> which gets us back to how to do that without breaking chroots
<stgraber> oh, actually there's a way I didn't consider that should fix chroots ... simply move /etc/resolv.conf to /run/resolvconf/resolv.conf, then make the symlink
<stgraber> on a regular system, it'll be wiped (as it's on tmpfs) and generated by resolvconf, but for chroots, /run is just a directory like any other, so it'll stay there and work just like a regular /etc/resolv.conf
<stgraber> slangasek: does that make sense or did I forget something (sounds too easy)?
<slangasek> stgraber: were chroots the justification for this change?  I was just working on understanding that
<slangasek> bug #922578
<ubot4> Launchpad bug 922578 in resolvconf (Ubuntu) "please remove 'resolvconf' from ubuntu-minimal Depends (affects: 1) (heat: 6)" [High,Opinion] https://launchpad.net/bugs/922578
<slangasek> oh, with the descriptive bug title, right :P
<stgraber> slangasek: right, that was the reason for the change, that bug and report from apw and tgardner that schroot was no longer working for a similar reason
<slangasek> stgraber: I thought the chroot problems were that, if /etc/resolv.conf was a symlink at all inside the chroot, things fail because they want to do a cp
<stgraber> slangasek: hmm, the bit with the cp is schroot and indeed it'll fail if we make it a symlink ... unless we make it a relative symlink
<slangasek> heh
<stgraber> otherwise schroot's cp will try to override the /run/resolvconf/resolv.conf outside of the container
<stgraber> which will work in some cases (but not do what we want) and fail in others
<slangasek> technically a policy violation, but if either /etc or /run is itself a symlink, thbbt
<slangasek> stgraber: I want to think on this some more; I don't think this is anything we should try to change for alpha-2, the risk is too high
<slangasek> but a relative symlink might be ok
<stgraber> having postinst, copy /etc/resolv.conf to /run/resolvconf/resolv.conf and make /etc/resolv.conf a relative symlink to ../run/resolvconf/resolv.conf sounds like it'd do what we want (except for respecting policy)
<stgraber> slangasek: yeah, I agree it's risky. How would we release note it? "run 'sudo start resolvconf' after first boot, then reboot"?
<slangasek> that sounds good to me
<cjwatson> so should I hold off on the casper change too?
<cjwatson> if I'm not going to get to ride along with something else
<slangasek> cjwatson: I thought the casper change was a blocker for actually doing the milestone validation?
<cjwatson> there exists a workaround by using the keys that contain pre-crypted passwords
<cjwatson> which is unnecessary in an insecure environment like this, but would work around this bug
<cjwatson> the fix is almost certainly http://paste.ubuntu.com/825741/ FWIW
<slangasek> ah, right, got that from scrollback now
<slangasek> cjwatson: I think I'd like to have the casper upload anyway, so that any other respins that come up benefit from it
<cjwatson> OK, I'm just testing it
<cjwatson> ... and once again I'm tempted to shove nano in the initramfs
<cjwatson> cp -a /scripts/casper-bottom/25adduser /root/tmp/ && chroot /root vi /tmp/25adduser && cp -a /root/tmp/25adduser /scripts/casper-bottom/ # sigh
<stgraber> slangasek: actually resolvconf's postinst already does the cp to /run/resolvconf/resolv.conf. So the only problem was that the symlink wasn't relative.
<slangasek> stgraber: well, that and the problem that the symlinking has been moved out of the postinst to a bit of upstart job that never runs ;)
<stgraber> cjwatson: IIRC you can call /root/usr/bin/vim.tiny without a chroot call, so without doing the cp magic (it complains but still mostly works)
<cjwatson> stgraber: mm, yeah, sometimes I remember that
<cjwatson> but still it's annoying :)
<cjwatson> I think it might need LD_LIBRARY_PATH ...
<cjwatson> (at least in principle)
<stgraber> slangasek: yeah, the new postinst needs to check for /var/lib/resolvconf/convert, remove it and reset the debconf key
<slangasek> yes to the first two parts; are we already resetting the debconf key right now?
<slangasek> stgraber: btw, I don't find any mention of post-images-to-iso-tracker.py in cdimage
<cjwatson> slangasek: debconf key> is that directed to me or stgraber?
<slangasek> cjwatson: stgraber
<cjwatson> slangasek: bin/post-qa - might only be in the deployment branch
<cjwatson> also s/images/image/
<slangasek> aha
<cjwatson> you wanted an ubuntustudio thing fixed?  I can do that now
<slangasek> hence my grep fail :)
<slangasek> cjwatson: yes please
<cjwatson> it was my oversight anyway
<cjwatson> what's the product name?
<cjwatson> "Ubuntu Studio DVD {amd64,i386}"?
<stgraber> slangasek: http://paste.ubuntu.com/825747/
<stgraber> cjwatson: yes
<cjwatson> stgraber,slangasek: post-qa fixed - I haven't posted anything current though, not up to date on the state of the tracker
<slangasek> cjwatson: I think stgraber already updated the tracker
<cjwatson> slangasek: casper 1.304 uploaded
<slangasek> ta
<cjwatson> ok
<slangasek> stgraber: I would've just done if [ "$RET" = "true" ] || [ -e /var/lib/resolvconf/convert ]; then
<stgraber> slangasek: http://paste.ubuntu.com/825753/ is the delta from ubuntu4 (last version with the link being created in the postinst)
<slangasek> stgraber: then there's no additional messing with debconf, and we just need to rm -f /var/lib/resolvconf/convert
<slangasek> but either way works
<stgraber> slangasek: indeed, then wipe the directory (as it no longer exists in the new package)
<slangasek> yes, that looks sane
 * slangasek nods
<slangasek> rm -rf /var/lib/resolvconf, in that case
<stgraber> slangasek: http://paste.ubuntu.com/825759/ (still from ubuntu4)
<slangasek> stgraber: lgtm - possibly also add a note that this transitional code can be dropped after, say, beta-2?
<slangasek> or maybe just after precise release
<slangasek> stgraber: also, please double-check that /etc/resolvconf/update.d/libc's readlink works with the new target
<stgraber> slangasek: http://paste.ubuntu.com/825766/
<stgraber> (went with readlink -m)
<GrueMaster> Can someone verify the md5sums at  http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20120201
<slangasek> stgraber: right, lgtm then
<slangasek> 2f73545a5bc65f3d2fd5cbf1c9ba4444  kubuntu/daily-preinstalled/20120201/precise-preinstalled-desktop-armel+omap4.img.gz
<slangasek> 0911bead4e5721a04d59cddb4bab3e50  kubuntu/daily-preinstalled/20120201/precise-preinstalled-desktop-armel+omap.img.gz
<slangasek> GrueMaster: ^^
<stgraber> slangasek: good, I'll keep it around and upload tomorrow then
<GrueMaster> Yea, I get the same when running md5sum on the images.  the MD5SUMS file must be old.
<slangasek> GrueMaster: yeah, I think cjwatson was addressing this earlier, but the scripts haven't been run since
<slangasek> stgraber: can you push that change to bzr today?  I might wind up poking at a few other things
<slangasek> and I'd rather this be committed first
<GrueMaster> ok.  I won't worry then and will test these images when I return (have to step out for a bit).  Almost all other images have now been tested on arm.
<GrueMaster> barring an arm respin (shudder).
<stgraber> slangasek: sure
<cjwatson> I didn't notice a problem with .img.gz files
<cjwatson> let me check
<stgraber> slangasek: pushed
<slangasek> cjwatson: ah, that as just bootimg before, right
<cjwatson> yeah
<slangasek> stgraber: tah
<slangasek> ta
<GrueMaster> cjwatson: The images seem ok, just no way to ensure they are the right images.
<cjwatson> sure
<cjwatson> I understand the need for checksums :-)
<cjwatson> GrueMaster: I think that's fixed now.  Thanks for the report.  If this recurs I definitely want to know about it because that means my previous fix was busted.
<cjwatson> (Or incomplete.)
<GrueMaster> Ok.  I can't make any promises, as I don't normally check the kubuntu images.
<GrueMaster> But I'll check next week when the dailies are turned back on.
<cjwatson> Yeah, I won't hold you to auditing our checksums ...
<cjwatson> stgraber: why doesn't isotracker_xmlrpc understand the "Precise Alpha 2" milestone?
<cjwatson> I've tried fiddling around with various parameters to isotracker.drupal.qatracker.milestones.get_list and can't make it return it
<cjwatson> >>> [m["title"] for m in isotracker.drupal.qatracker.milestones.get_list(range(1000)) if "Precise" in m["title"]]
<cjwatson> ['Precise Alpha 1', 'Precise Daily']
<cjwatson> stgraber: ah, never mind, ~/.isotracker.conf on my laptop is still configured to your old testing tracker :)
<stgraber> cjwatson: I was just about to suggest that ;)
<cjwatson> much better now
#ubuntu-release 2012-02-02
<Riddell> what does "Run Once" mean for test cases on iso.qa.u.c?
<slangasek> Riddell: that the test case needs to be done once for all images, instead of once per image
<cjwatson> [5~/wg 44
<cjwatson> sigh
<GrueMaster> One more image to test and I can hit the pub.
<micahg> slangasek: I assume disabling the publisher for hours at a time before alpha2 is released would be a bad thing?
<pitti> micahg: is "hours" more like two or 12?
<pitti> micahg: two hours sohuld be bearable if it's urgent
<pitti> but not much more
<micahg> pitti: 2-3 per release (this is for the Firefox migration to -security)
<micahg> releases == lucid,maverick
<pitti> wow, copying packages takes that long?
<micahg> yeah, I think it took 3 hrs per release from -proposed to -updates
<pitti> I think that mostly was because jdstrand used copy-package.py for the gazillion langpacks, wasn't it?
<micahg> is that not the right way?
<pitti> it works, but is utterly slow
<pitti> using our sru-release --pattern lucid --security language-pack script, it's a matter of 15 minutes or so
<micahg> pitti: ah, could you please document that on the archive admin page, that's what we were trying to use
<micahg> https://wiki.ubuntu.com/ArchiveAdministration#langpack_SRUs
 * micahg probably won't be ready until after release in any event though
<pitti> urgh yes, that is a bit obsolete
<pitti> also https://wiki.ubuntu.com/ArchiveAdministration#Standard_case
<pitti> will update
<micahg> thanks
<micahg> ok, so, it should be <30 minutes per release then, perfect, if I'm ready before alpha2, I'll come ask in here
<pitti> micahg: ArchiveAdmin page updated
<micahg> pitti: thanks
<mvo> is vmware-view-client waiting for approval in the precise-partner queue ? and if so, could someone have a look please :)
<pitti> mvo: I don't see it in new or unapproved
<mvo> odd, I reupload
<mvo> thanks
 * cjwatson investigates lubuntu having ended up with unity-greeter
<ogra_> wasnt there a bug about that that was fixed ?
<cjwatson> not so you'd notice in the current images.
<cjwatson> bug 918401 and bug 925358
<ubot4> Launchpad bug 918401 in unity-greeter (Ubuntu) (and 1 other project) "Unity-greeter installed by default on Lubuntu, crashing on start (affects: 8) (dups: 1) (heat: 50)" [Undecided,Confirmed] https://launchpad.net/bugs/918401
<ubot4> Launchpad bug 925358 in casper (Ubuntu) "Lubuntu Precise live CD boots to a Unity-like DE (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/925358
<cjwatson> but germinate output looks right; trying a local livecd-rootfs build
<ogra_> jibel, hey, when you get Bug 924993, do you actually get a keyboard selection dialog ? i wonder if these two issues i see are related (and if its probably only an oem-config vs ubiquity thing)
<ubot4> Launchpad bug 924993 in ubiquity (Ubuntu) "wireless password field disabled when user selects a protected network (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/924993
<ogra_> i use oem-config here, see the same behavior but somehow the keyboard selection is supressed in that scenario ... while on systems without wlan the kbd selection shows up
<jibel> ogra_, I do, everything works as expected apart from this password field that should be enabled.
<ogra_> ok
<ogra_> then it might be arm or oem-config specific
<ogra_> though arm is unlikel else kbd selection wouldnt be shown on the pandaboards
 * ogra_ wonders wh his Y ke onl works ever 5th press
<jdstrand> pitti: re sru-release> the name implies it can only be used for -proposed to -updates. I see now there is a --security arg to go to -security. looking at the --help, I wonder about -updates to -security for the times that things might already be out of -proposed
<pitti> jdstrand: I could add a --security-only for this occasion, it's easy to do
<pitti> jdstrand: the packages are still in -proposed, so copying from -proposed to -security will be fine
<pitti> jdstrand: you could use -s as-is, then it would copy to -updates again, plus -security
<pitti> it's just a waste of half the time
<pitti> but it might eventually come in handy for other occasions like firefox
<jdstrand> well, since we run copy-report automatically, I don't really see why we would want --security-only at this time
<jdstrand> it was more just the case of 'if the packages were deleted from -proposed already, but still in -updates'
<jdstrand> I admit I don't know when things get deleted from -proposed
<cjwatson> whenever we c/p the lines from the pending-sru page
<cjwatson> which appear once they're in -updates
<pitti> right, the report just doesn't cover langpacks, as it filters them out except for -en as a representative
<pitti> as the validation process is different, and it would clutter up the page too uch
<pitti> so in practice they stay in -proposed all the time
<jdstrand> well, language-pack-en shows it is no longer in -proposed, but language-pack-es is
<jdstrand> this was more curiosity anyway. I don't know if we will have another new set of langpacks for firefox 10
<pitti> jdstrand: right, -en might have been cleaned up already, so we need to copy that manually
<pitti> but all the other n-hundred can be done with the script
<pitti> jdstrand: no, we won't
<pitti> jdstrand: this was an one-time change for 3.6->9
<jdstrand> pitti: ah great! thanks for your time :)
<pitti> jdstrand: so, for this one time I'd just locally comment out the copying to -updates, that's easiest :)
 * jdstrand makes a note
<pitti> wrt. alpha-2, I suppose there's still a potential  lubuntu rebuild?
<pitti> (as for freeze lifting)
<Riddell> slangasek: for Kubuntu these images should be included in alpha 2: i386 and amd64 alternate, desktop and dvd
<cjwatson> I think I've figured out the Lubuntu problem
<cjwatson> it'll be a livecd-rootfs upload, build/publisher cycle, rebuild images
<superm1> skaet wanted me to mention we are planning a2 for mythbuntu
<cjwatson> how are your tests looking?
<superm1> last tests were a week ago, so i'm going to try to drum up the team to test candidates today
<cjwatson> right, this looks a few orders of magnitude more sensible.
<skaet> cjwatson,  go ahead and start on the upload and build for Lubuntu please.   We'll wait until gilir's online to decide to retest/not.
<skaet> Last I hear from him, was that he was ok with alternates going out, but not the livecd's.
<cjwatson> the current desktop images are definitely unreleaseable by any reasonable metric.
<cjwatson> (lubuntu I mean)
<cjwatson> they simply aren't as specified
<cjwatson> this should cut their size down a fair bit too ...
 * skaet nods
 * skaet figures its time for all images to go on a bit of a diet as well... after A2 ;)
<cjwatson> feel free to make suggestions ;)
<pitti> we have some overhead due to non-empty langpack updates
<pitti> and ubuntuone bits need to be fixed to stop using gtk 2 and webkit (underway, AFAIUI)
<pitti> then we can drop the old webkit gtk2 bits, some 8 MB
<pitti> I did a size analysis recently, the biggest offenders were firefox/thunderbird (+2.6 MB each), new LibO (~ 1.5 MB), and of course python3 (~ +6 MB)
<stgraber> skaet: I prepended the resolvconf issue to the list of known issues as I'm expecting quite a lot of users to hit that one
<stgraber> skaet: looking at Edubuntu now
<skaet> thanks pitti.   :)
<skaet> stgraber,  thanks!   Yes,  anyone who knows of issues that are likely to be hit,  please review the TechnicalOverview and add them.
<cjwatson> hmm, but isn't the resulting Lubuntu system going to need to have recommends disabled too ...
<cjwatson> grah, this is annoyingly complex
<seb128> pitti, webkit-gtk2 ... isn't that still used by ubuntuone-control-panel?
<seb128> pitti, and gwibber
<pitti> seb128: yes, but I thought ubuntuone stuff would be moved to GTK3 (sso-client) and PyQt (control-panel)
<pitti> seb128: ah, gwibber, too, I thought ken was working on it
<seb128> pitti, I'm not sure the pyqt stuff is going to happen this cycle
<pitti> now that we have gnome-keyring GIR bindings
<seb128> but let's see
<seb128> pitti, he is, that didn't land yet either though ;-)
 * slangasek waves morning-like
<pitti> anyway, it's the best thing we have right now wrt. size reduction
<seb128> slangasek, hey
<pitti> slangasek: good morning
<skaet> slangasek,  good morning.   grab the coffee.  ;)
<slangasek> Riddell: so you specifically don't want the amd64+mac and powerpc images published with the alpha?
<cjwatson> I think the Lubuntu alternate CDs should be respun.  Explanation in bug 918401 comment 32.
<ubot4> Launchpad bug 918401 in unity-greeter (Ubuntu) (and 2 other projects) "Unity-greeter installed by default on Lubuntu, crashing on start (affects: 9) (dups: 2) (heat: 58)" [Undecided,Confirmed] https://launchpad.net/bugs/918401
<stgraber> skaet: the Edubuntu technical overview is a bit long, unfortunately it looks like most of our changes happened between alpha-1 and alpha-2 ;) (alpha-1 was roughly identical to Oneiric)
<stgraber> skaet: I'm now just waiting for highvoltage to do a final review so it may still grow or shrink a bit :)
<cjwatson> I am fairly sure we'll need a new ubiquity if we want Lubuntu desktop to be suitable for Alpha 2.
<skaet> stgraber,  that's fine.   Thanks!
<Riddell> slangasek: they are untested, you can if users are clear of that
<cjwatson> At which point I might as well include last night's marathon NTFS installation fix there as well.
<skaet> slangasek,  Riddell,  if they are untested,  they shouldn't go out.
<Riddell> right
<cjwatson> Any opinions on a new ubiquity just for Lubuntu?
<cjwatson> I'm preparing it now anyway
<cjwatson> IWBNI a Lubuntu developer were around here ...
<skaet> cjwatson,  given the complexity I suspect its unlikely we'll get a home run and it all work,  however they're changes that are needed, so if they don't end up in A2, getting them in the dailies tomorrow is good.
<cjwatson> Are all the other images golden at this point?
<cjwatson> I agree it will be a slight fluke if they all work; however if everything else is good (at least for desktop) then going ahead with a ubiquity upload probably wouldn't hurt
<skaet> cjwatson,  I haven't heard any other show stoppers - so all the ones that are tested are likelies at this point.
<cjwatson> The partman-auto change technically affects non-desktops although I seriously doubt anyone would notice
<cjwatson> OK, so how about I go ahead and if it fails we just drop Lubuntu desktop from A2 (or attempt to release it tomorrow or something)
<skaet> cjwatson,  sounds good.
<cjwatson> I don't see obvious drawbacks
<cjwatson> OK
<highvoltage> stgraber: looks good!
<slangasek> ok, can someone tell me what ~/.isotracker.conf should look like? :)
<cjwatson> you could grab nusakan's
<cjwatson> though that'll have you pretending to be ubuntu-cdimage
<slangasek> what password is it wanting?  Hopefully not the SSO password?
<slangasek> anyway, this is for publish-image-set, so pretending is probably fine
<cjwatson> it's its own API key
<slangasek> hum, getting an error:
<slangasek> ERROR: Cannot handle product Ubuntu Server EC2 EBS (Asia-Pacific-NorthEast) amd64
<slangasek> ... but that should match the 'ignore' regexp that I see in here
<slangasek> ignore_product_re = re.compile('Netboot |Upgrade |Server EC2|line-through')
<cjwatson> looks like a space, quacks like a space, isn't actually a space, maybe?
<cjwatson> ok, new ubiquity on its way
<cjwatson> oh, it's using .match not .search
<cjwatson> slangasek: update and try again
<cjwatson> heh, now it dislikes uwbi
<cjwatson> *wubi
<slangasek> well, progress :)
<cjwatson> which to be fair it probably can't actually handle - I don't know that there's any non-manual release handling for wubi yet
 * slangasek nods
<cjwatson> I've added that to the ignore regex for now
<slangasek> thanks
<cjwatson> it produces sensible output now
<cjwatson> well, output
<slangasek> :-)
<cjwatson> sense is your problem
<cjwatson> surprising that I'm not seeing amd64+mac anywhere in the output
<slangasek> possibly a missing $ on the amd64 variant
<slangasek> testing
<slangasek> yep
<slangasek> fix pushed
<cjwatson> yeah, I was just getting there :)
<cjwatson> ta
<slangasek> so to mark things as not-for-publishing, do we have a better mechanism than disabling them on the tracker?
<cjwatson> ah yes, broken since r320
 * cjwatson satisfies curiosity
<cjwatson> r330 fixed it for armel+* but not amd64+*
<cjwatson> slangasek: not AFAIK; I think I've just manually filtered them out of the publish-image-set output when I've done this
<cjwatson> oh, we should do a source build
 * cjwatson goes to poke that
<skaet> slangasek,   I'm not seeing any of the amd64+mac images with testing on them,  so they shouldn't be going out with A2.
<skaet> (nor the powerpc ones)
<cjwatson> I've been making some progress on scaring up powerpc testers and reminding them that they actually need to do it, but it was only a couple of days ago so they may not have got organised in time
<skaet> do you want me to just go in and disable the definite "no go"s?
<skaet> cjwatson,  thanks.  :)   I've also been talking to IBM (Linux manager at LCA and he was receptive to the notion of getting some of his folks lined up to help)  but it needs to be followed up on too.
<slangasek> skaet: does disabling them prevent people from posting tests of them?
<slangasek> I think disabling them on the tracker is probably still best if we're pretty sure we're not publishing them, but it does mean it'd be nice to have a better way for the tool to decide what to publish
<skaet> slangasek,  yes,  but if there are no tests posted at this point,  its unlikely we'll be getting any before we release.
<skaet> slangasek,  yes that would be good.   Maybe we can brainstorm with stgraber about it after A2 is out.   (publish ticky box?)
<slangasek> or the tool could embed the policy directly about what's publishable or not based on testedness
<stgraber> skaet: we could indeed create an extra build status for "ready" (trying to find a term that works for hardware testing and package testing too ;))
<stgraber> slangasek: the data actually is available in the API, so I could give a script using our criteria and returning the list
<skaet> embedding the policy would be nice, but it needs to be transparent on the ship/not - maybe a color change when the testing results are satisfied to indicate its now possible to ship?
<slangasek> well, that implies embedding the policy in *two* places, one of which the release engineer can't edit ;)
<stgraber> right, if we want it visible on the website, we'd need a few extra tricks. Otherwise I'd simply make a python script using the API and put it in ubuntu-archive-tools (well, likely just update publish-image-set.py)
<stgraber> so if someone wants to change the policy, it's just a matter of changing the script
<stgraber> what I could do though is have the "ready" status visible on the website, have publish-image-set.py first apply the policy to the tracker and then show the list of what's ready to be published
<skaet> just having the ready status visible on the website was what I was looking for.  :)
<stgraber> that'd allow for manual overrides on the tracker by manuall marking stuff as ready and still have the script apply the policy automatically for the rest
<stgraber> then show the final list
 * skaet nods
<skaet> slangasek,   what are the key bugs right now preventing upgrading from 10.04 to 12.04?  I'd like to add them to the release notes.
<stgraber> skaet: so what's the current policy exactly? we clearly don't publish anything that wasn't tested at all but do we care about the actual test results? (like not publish anything that's not fully tested or not publish something that has all its results marked as failed, ...)
<skaet> stgraber,  we need to refine the policies and make them visible - some parts are grey right now,  and it would be good to get the expectations nice and uniform.
<cjwatson> skaet: bug 917173 and bug 922485 come to mind (fixed in precise but not yet successfully backported)
<ubot4> Launchpad bug 917173 in apt (Debian) (and 12 other projects) "lucid -> precise upgrade failed: Resolver failed to calculate the upgrade - dpkg-dev held back (affects: 1) (heat: 10)" [Unknown,New] https://launchpad.net/bugs/917173
<ubot4> Launchpad bug 922485 in apt (Debian) (and 12 other projects) "Lucid Desktop i386 failed to calculate the upgrade to Precise (affects: 1) (dups: 1) (heat: 16)" [Unknown,New] https://launchpad.net/bugs/922485
<skaet> thanks cjwatson
 * skaet adding them now.
<cjwatson> skaet: the bugs at this point are IMO sufficiently early in the process that we do not have a good overview of problems
<cjwatson> I was trying to figure out why the backports failed to verify but was derailed by a2 stuff
<skaet> cjwatson,  fair enough.  :)   expect we'll be figuring out a lot of this over next month.
<slangasek> skaet: right, the ones cjwatson listed.  Although, does listing LTS upgrade bugs set an unreasonable expectation for people that a 10.04->12.04 upgrade is a reasonable thing for mortals to do? :)
<skaet> slangasek,  "Upgrading from 10.04 to 12.04 still has some known issues and is not recommended at this time." - just wanted to provide some examples  ;)
<slangasek> right-o :)
<slangasek> skaet: as for policy on publishing... I guess I would say anything that's untested, or anything that's been tested but had only failures, should not be published, and anything else is a question of human judgement?
<slangasek> i.e., if there's a reason we're choosing not to publish an image that *has* been successfully tested, we could still indicate that manually
<skaet> slangasek,  yes it does seem to boil down to that.   How about I start a wiki page off after we get A2 out, and we'll get the rest of the release team's input.
<skaet> then we can all have the same expectations on release day ;)
<slangasek> sounds good
<cjwatson> the good bit about testing upgrades is that you have plenty of opportunities for coffee breaks.
<cjwatson> rebuilding Lubuntu desktop with fingers crossed
 * skaet crosses fingers
<stgraber> skaet, slangasek: Using http://paste.ubuntu.com/826568/ gives me http://paste.ubuntu.com/826569/ (though iterating through everything takes almost a minute ... so custom status would be nice to avoid that, then just products.get_list and builds.get_list would be required)
<stgraber> so that's everything that's currently active on the tracker (status = 0) and with at least one mandatory testcase marked as passed
<skaet> stgraber,  it should actually be all mandatory testcases marked as passed.... else they shouldn't be mandatory.
<skaet> but its a judgement thing, depending where in the release cycle we are.
<skaet> stgraber, http://paste.ubuntu.com/826569/ looks good though.  :)
<stgraber> skaet: indeed, we definitely want all the mandatory passed at least once for final, all the run-once also passed at least once and we can probably ignore the optionals (or only consider failures?)
<stgraber> skaet: anyway, writting down the policy will help quite a bit ;)
<slangasek> skaet: but late in the cycle, those also typically gate whether we're ready to publish, rather than just whether a particular image should be published
<slangasek> so I think having the tool just block untested and completely-failed images gets us to the right place as far as automation
<skaet> slangasek, stgraber - fair enough.  Will work on writing it up tomorrow, and see if we can get it discussed next week.   I'll try to add a dimension for Alpha, Beta, Final criteria - so we're clearer.
<slangasek> hmm, are Ubuntu Studio considered publish-ready?
<slangasek> apparently there are no successful ubiquity installs, just a bunch of failures
<slangasek> skaet: ^^ I'm holding off on ubuntustudio for now given the above
<skaet> slangasek,  ack
<skaet> scott-work, ^ any data that isn't in the tracker?
<seb128> slangasek, skaet: is there any plan to unfreeze today?
<slangasek> I think we should be unfreezing at this point; skaet?
<seb128> just trying to schedule my end or day and friday
<seb128> or->of
<scott-work> slangasek: skaet:  i believe there were successful installs - there were cases of ubiquity failing but also lightdm not properly configured which may have been construed as "ubiquity failuers"
<slangasek> scott-work: well, the only people who've posted test results on the tracker marked their tests as failed
<cjwatson> Lubuntu desktop looks better to me now
<cjwatson> at least gives me a working desktop, haven't tried an install
<scott-work> slangasek:  it may be better to not publish for A2 then
<slangasek> scott-work: ok
<skaet> thanks cjwatson,   was wanting to hear how it looked before unfreezing.   No results in from any of the lubuntu folk though yet,  but at this point,  not seeing much upside in keeping it frozen.
<skaet> scott-work,  I'll comment out the ubuntu-studio comments from the technical overview then as well.
<slangasek> cjwatson: evidently the rules on #ubuntu-devel /topic handling have changed since last I needed to set one; can't set it directly, chanserv won't set it for me?
<cjwatson> you have +t, you should be able to use /msg chanserv topic
 * cjwatson tries to find what the channel mode used to be
<slangasek> yeah, chanserv didn't like me
<slangasek> man
<slangasek> can't set the channel here either
* slangasek changed the topic of #ubuntu-release to: Alpha 2 testing in progress: Archive:open  | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate covered ants | melior malum quod cognoscis
<davmor2> slangasek: you just weren't hitting it hard enough :)
<cjwatson> hm, you know, sod it, +t isn't mlocked on -devel afaics
<scott-work> slangasek: skaet:  sorry for dropping the ball on A2, i will be more prepared in the future
<stgraber> slangasek: do we want to wait a bit longer for the resolvconf upload or should I go ahead and upload it nowish? (thanks for the postrm fix btw)
<slangasek> scott-work: no skin off my nose... :)
<slangasek> stgraber: I'm fine with you uploading it now
<stgraber> slangasek: good. Will do a couple more tests on it and then upload, should definitely be in the archive in time for the Edubuntu daily (assuming they've been switched back on)
<slangasek> they haven't been just yet
<slangasek> who usually handles the cloud image publishing?
<utlemming> slangesek: that's me
<slangasek> utlemming: ah, hi :)
<slangasek> utlemming: is there anything else pending from your POV before those can be published?
<slangasek> looks like the testing is done
<slangasek> and we're pushing out the ISOs, so I guess it's time for the cloud images to go out also?
<utlemming> slangesek: no, we're good to go, just waiting for the go-ahead to publish them
<Riddell> slangasek: announcing the release sometime soon?
<slangasek> utlemming: go ahead then :)
<utlemming> slangasek: publishing now
<slangasek> Riddell: well, skaet will be
<Riddell> I'm away for a few hours, I'll tell my kubuntu people to watch and put on the website when they see it
<skaet> Riddell,  sounds good.   want me to post in the #kubuntu-devel channel,  or will someone monitor here?
<Riddell> skaet: that would be good yes
<utlemming> cloud-images for Alpha2 are now public
<skaet> utlemming,  yup,  able to see them now. :)
* skaet changed the topic of #ubuntu-release to: Alpha 2 released!  Archive:open  | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate covered ants | melior malum quod cognoscis
<skaet> Looks like we're all nicely released now for A2.    Thanks slangasek!
<highvoltage> :)
<balloons> gratz everyone!
#ubuntu-release 2012-02-03
<TheYsNoi> hello there...
<TheYsNoi> has someone tested the alpha2 release here?
<brendand> TheYsNoi - lot's of people have. any problem?
<cjwatson> brendand: he/she isn't here any more,
<cjwatson> anyhow I suspect it's confusion between this channel and #ubuntu-testing, or something
<skaet> hmm... rls-mgr-p-tracking seems to be missing some bugs that should be there.   Wonder what glitched up now?
<jibel> skaet, the glitch is "Friday, 20. January 2012 02:01 UTC "
<jibel> last refresh is 2 weeks behind
<skaet> *sigh*
<skaet> thanks jibel
<skaet> missed that
 * skaet was focused on A2 since returning from vacation.
<cjwatson> I complained about it in a release meeting or two.
<cjwatson> So far I seem to have been ignored.
<skaet> cjwatson,  bjf is the person to ping directly when it stops working.   Sorry I thought it had been taken care of,  but didn't check for myself until this morning.
<cjwatson> Somebody (Steve, I think) said they had already done so.
<cjwatson> I've given up on that whole system as honestly it's just broken too often.  At least LP is consistent.
<cjwatson> Even if it's less well-categorised.
<skaet> I wanted it in LP,  but there were roadblocks put up for getting the categorization in there.
<jdstrand> fyi, I need to take the publisher offline
<jdstrand> we have an important firefox update that has to go out today, and I need to make sure everything that went to -updates with the rapid release migration makes it to -security
<jdstrand> now that I know about sru-release, this should not be as painful as last time
<jdstrand> (not nearly-- it should be off for less than an hour)
<jdstrand> sorry, this should be the last of these
<jdstrand> cron job disabled
<cjwatson> jdstrand: I'd like to know how long it took
<jdstrand> cjwatson: well, it is for two releases, maverick and lucid
<jdstrand> lucid is done, maverick is still going
<jdstrand> I didn't start sru-release right away though, cause there were a number of things I needed to copy-package
<jdstrand> I think it was in the neighborhood of 25 minutes
<jdstrand> and by they, I mean lucid
<jdstrand> or it
<jdstrand> meh
<jdstrand> lucid I think took 25 minutes
<jdstrand> which is *much* better than the 2.5+ hours it took for copy-package
<cjwatson> OK.  Archive.copyPackages might be faster yet, but that doesn't send mail so I want to think about whether it makes sense for sru-release to use that
<cjwatson> How many packages was this?
 * micahg was wondering about recent mail sent for -updates
<cjwatson> Yeah, side-effect
<cjwatson> But copyPackages might be a sensible solution actually
<cjwatson> I forget what the typical overhead of an API request is
<cjwatson> I'd like to get to the point where - at least - this sort of thing only requires good timing rather than stopping the publisher, and ideally is transactional so you always get either all or none
<jdstrand> cjwatson: looks like 736, based on what q accept tells me I had to do with unapproved in lucid-security for language-pack-
<cjwatson> (IIRC copyPackages isn't transactional though)
<micahg> cjwatson: stuff was also coming from 2 different sources (-proposed and -updates)
<jdstrand> fwiw, I commented out temporarily the copy to -updates in sru-release since they are already there
<cjwatson> jdstrand: wow.  one API request versus 736 might well make a serious difference then.
<cjwatson> micahg: ok, two requests then :)
<jdstrand> yeah, I was pretty surprised by that number before, and was resurprised today :)
<jdstrand> I have to do it twice too
<cjwatson> that might well just amount to good timing
<jdstrand> ok maverick done
<micahg> but both needed to be atomic, I guess the -proposed stuff could've been copied to -updates first, then copy everything to -security
<cjwatson> strictly you only need to be confident of it completing before the next publisher run starts
<cjwatson> if it takes five minutes or something, that's just timing
<jdstrand> maverick had 770
<jdstrand> ok, almost done with my bits
<cjwatson> of course it's a bit awkward that you have to accept from the queue as well
<jdstrand> it is
<jdstrand> ok, cron job re-enabled
<cjwatson> if copyPackages were restricted to the archive owner (I don't *think* it is ...) or if we had an alternative privileged interface, then we could arrange for that to bypass the queue
<cjwatson> it goes through the queue right now because we're using an interface that only requires ordinary uploader privilegeq
<cjwatson> s/q$//
<jdstrand> interestingly, it seems there might be some logic there
<jdstrand> the langpacks like I said I didn't copy to -updates (commented out those lines in sru-release)
<jdstrand> those needed to be approved
<jdstrand> but when bzr reverted sru-release and used it for firefox and mozvoikko for lucid-oneiric, I was told to look in the q, but they weren't there
 * jdstrand checks again
<jdstrand> oh, there they are
<jdstrand> must have been another cron job
<jdstrand> ok, all accepted
<cjwatson> yes, PackageCopyJobs are processed by a cron job
<cjwatson> it's every minute or two I think
#ubuntu-release 2012-02-05
<micahg> for any AA reviewing shimmer-themes, I did a review of the package before mr_pouit uploaded
#ubuntu-release 2013-01-28
<bdmurray> cjohnston: ^
<cjohnston> I'm guessing the other cj, bdmurray ?
<bdmurray> yes the one with a w - cjwatson
<cjohnston> heh
<cjwatson> ta
<cjwatson> bdmurray: you didn't need to correct precise to precise-proposed :)
<cjwatson> Laney: rejecting your software-center upload, but only in favour of bdmurray's which includes it
<Laney> aye aye
<Laney> I don't really know anything about udebs - how would I go about finding out why gtk+3.0 doesn't want to migrate?
<Laney>     * i386: libgtk-3-0-udeb, libvte-2.90-9-udeb
<cjwatson> Probably because the udeb is built with wayland support and the rest of wayland isn't udebificated
<Laney> this upload was to disable that
<Laney> and the wayland one did migrate
<cjwatson> well, they have dependencies like any other package
<cjwatson> those dependencies are only allowed to be satisfied by other udebs (i.e. */debian-installer/binary-*/Packages.gz)
<infinity> Nah, it's because the udeb depends on libc6-udeb (>= 2.17)
<infinity> It'll migrate shortly.
<infinity> Why the udeb dependencies don't seem to use .symbols, I don't know.
<cjwatson> Ah yes, it's made clear(ish) by _excuses
<cjwatson> "Depends: gtk+3.0 eglibc"
<Laney> ah, yeah, didn't look there
<infinity> Are udeb deps not generated by dpkg-shlibdeps?
<infinity> Cause the non-udeb packages depend on, like, libc6 (>= 2.4) or something.
<cjwatson> They are, or should be
<infinity> Seems silly that the udebs are much stricter.
<cjwatson> But there's special udeb support in shlibdeps, and maybe glibc doesn't set it up quite right
<infinity> Anyhow, mostly a non-issue, it'll migrate soon enough.
<infinity> It's possible glibc has no idea how to do that correctly, yes. :P
<Laney> Policy 8.6 says "Libraries with a corresponding udeb must also provide a shlibs file, since the udeb infrastructure does not use symbols files."
<infinity> s/glibc has/I have/
<cjwatson> Ah, heh
<infinity> Right.  No symbols.  Check.
<cjwatson> Probably nobody cares much
<infinity> Hence the strict dep.
<infinity> Not world-ending.
<cjwatson> Since we don't need partial upgrade handling for udebs or anything
<infinity> Laney: Anyhow, should migrate in this cycle, dante/armhf just lagged a tag.
<Laney> Aye, ta.
<smagoun> Hi, can we sneak a new gnome-settings-daemon into precise-updates? The package has been sitting in precise-proposed for >1 month. There is 1 bug listed in the SRU; I verified it today. Bug 1034090
<ubot2> Launchpad bug 1034090 in gnome-settings-daemon (Ubuntu Precise) "Hotkeys not functional after upgrade to quantal's xorg (new xinput version)" [High,Fix committed] https://launchpad.net/bugs/1034090
<infinity> smagoun: We're not past letting things into updates, don't worry.
<smagoun> infinity: oh, I know. I will break out the big guns when I get really desperate: a free XPS 13 for each bug resolved :P
<infinity> smagoun: Don't want one.
<infinity> smagoun: Entice me with something with a Lenovo logo.
<smagoun> infinity: X1 carbon?
<infinity> smagoun: T430s, or a Carbon X1, maybe?
<vanhoof> infinity: T40p
<vanhoof> =P
<micahg> infinity: I see my two SRUs never were accepted, I'm guessing it's too late, I guess I don't mind too much
<infinity> micahg: Not too late, but if they're not installation/media/first-impression critical, it's not a big deal either way.
<micahg> yeah, not needed for 12.04.2, I'll remove the milestones I added
<davmor2> infinity: you want ideapad y580 you know you do
<infinity> davmor2: Pretty sure I don't.
<infinity> There aren't many laptops that are an upgrade to my T420s.
<infinity> The T430s being one of the few. :P
#ubuntu-release 2013-01-29
<phillw> Hi guys, now please don't laugh... but what is the difference between the mini-iso and ubuntu-core?
<ogra_> infinity, FYI, still no cadejo (IS is pinged again though)
<infinity> ogra_: Pinging's about the best I can do too, so if you're keeping on them about it, at least you're in the right timezone to do so. :/
<ogra_> yeah
<ogra_> i really wonder why such outages always happen when we actually need the machines for sprints etc ... while they are happy all the rest of the time where they only do daily operation
<ogra_> must be a builtin panda-murphy or so
<infinity> We lose several Pandas a week to random things.  It's less about Murphy and more about using glorified cell phones as production servers.
<infinity> This horrible misery should all be past us in a year or three, but it's going to feel like a decade.
 * ogra_ is more in the "three" camp
<infinity> Well, it depends.  We could get armv7 (A9 or A15) server kit this year, and it may even be stable and awesome.  It certainly can't be worse than dev boards.
<infinity> But the "three" would be around what one might expect for decent armv8 kit.
<infinity> Which is, ultimately, where we want to be.  Building armhf on arm64 machines (just as we build powerpc on ppc64, i386 on amd64, etc)
<ogra_> i highly doubt the "this year" part here
<infinity> It already exists in the wild.
<infinity> It's just scarce.
<ogra_> i know you will likely have to pre-order a year in advance though
<ogra_> amnd get a hand soldered machine signed by the engineer or so
<infinity> :P
<jamespage> any SRU team members around? bug 1085255 has been fixed commited for a while now and openstack upstream are about to release a new point release for folsom so it would be great if the packages could be pushed through to -updates
<ubot2> Launchpad bug 1085255 in quantum (Ubuntu Quantal) "Meta bug for tracking Openstack 2012.2.1 Stable Update" [Undecided,Fix committed] https://launchpad.net/bugs/1085255
<infinity> jamespage: Did no one bother to verify any of the other bugs?
<infinity> jamespage: Oh, I see, this is part of some provisional MRE with fancy CI testing strategy.
<jamespage> infinity, indeed it is :-)
 * jamespage nearly had a heart attack then
<jamespage> infinity, adam_g has put it through the CI testing; we test a few deployment configurations
<infinity> To be clear, I'm still not happy about not having specific bugs verified.  Why reference them in the changelog if no one's willing to test?
<infinity> (The kernel has an MRE too, but they verify every single bug they fix, or revert the patch)
<cjwatson> Yeah, I'm not happy about it either.  If nothing else, if all the bugs in the changelog were verified (one way or another), then you'd find that the update would be pushed to -updates without you having to ask.
<cjwatson> Which should clearly be better from your point of view.
<infinity> jamespage: Anyhow.  Releasing it this time, but I really do think we need to revisit this.  It's lovely you have rigorous QA (hey, so does the kernel), but if you're claiming to fix specific bugs, it shouldn't be too much to ask that someone verifies they're actually fixed.
<jamespage> infinity, OK - I've kinda picked up on the back of this SRU; once we have this lot through I happy to revisit and figure out what fits best for SRU + Ubuntu Server team
<infinity> jamespage: Different people have different workflows, and I'm entirely prepared to acknowledge that, but the bottom line, really, is that if you say you've fixed a bug, you should be prepared to test and back that up.
<infinity> jamespage: And hey, if that means adding a new test for every bug to your automated CI machine of doom, verifying the results, and then marking v-done on each bug after looking at the logs, that's cool.  Just something other than "well, we tested all the bits together and none of our computers are on fire, so it probably also fixed all these other bugs".
<infinity> jamespage: Well, you should be prepared to test, or prepared to revert.  The latter being the stance the kernel team took.  If bug reporters outside their team refuse to verify bugs, they just revert the patches and say "nyah nyah".
<infinity> jamespage: (You'd be amazed at how effective that's been at getting people to test)
<jamespage> infinity, so I'm busy reading through the TB list around this MRE
<jamespage> infinity, I expect this has been discussed prior to now (but it did not involve me :-))
<jamespage> infinity, cjwatson: is the objection from you guys that the specific bugs are referenced at-all in the changelog?
<infinity> jamespage: No.  If the uploads fix bugs, referencing them is good and right.
<infinity> jamespage: But if you claim it fixes bugs, someone should test that the bugs are fixed.
<jamespage> infinity, so reading this https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<jamespage> "For MRE packages only, it can generally be assumed that bugs claimed to be fixed have actually been fixed upstream, and it is not necessary to manually independently verify them. (Some bugs may deserve specific verification if for example they are hard to reproduce upstream.) "
<infinity> jamespage: I'll use the kernel team as a stellar example here again.  They do a ton of regression testing (not unlike your CI infrastructure), but if they also fix specific bugs, they verify those.
<infinity> jamespage: It's possible I disagree with the wiki on this point.  But it does seem you're more or less doing as told in this case.
<cjwatson> jamespage: My objection is the mismatch between listing bugs in the changelog and tagging them
<infinity> jamespage: There's also the part where provisional MREs aren't quite MREs.
<infinity> cjwatson: To be fair, they're doing exactly what the MRE instructions say to do.
<cjwatson> jamespage: That note in the MRE page is more intended to be about random bugs cited in the upstream changelog, rather than ones that you've gone to the effort of listing explicitly in debian/changelog
<infinity> "When the preceding steps have been done, the headline bug (only) should be marked verification-done"
<jamespage> cjwatson, well gone to effort is actually 'generated the changelog from git' in this case
<cjwatson> A bletcherous practice, but it still counts as effort :)
<cjwatson> The uploader still takes responsibility for the output of automated tools
<cjwatson> Anyway, the point of the MRE thing should - IMO - be that you don't have to manually verify them, not that the bugs don't have to be tagged
<jamespage> cjwatson, indeed - ftr its also peer reviewed
<cjwatson> I don't know where that thing about only tagging the headline bug came from - it's clearly wildly out of step with the process
<cjwatson> Feel free to bring that up on the TB list for correction
<cjwatson> The whole process would, in any case, work much more smoothly if all bugs mentioned in the changelog were tagged.  Whichever way you want to resolve that.
<Daviey> Hello o/ :)
<jamespage> cjwatson, OK - I'll give that some sort; we actually raise tasks for Ubuntu during the SRU update process if they are missing; maybe we should stop doing that
<cjwatson> As in, this update would have been released over three weeks ago.
<Daviey> cjwatson: Can you clarify what tag you want?
<cjwatson> verification-done
<cjwatson> jamespage: Yeah, sounds pretty pointless
<jamespage> sort/thought
<cjwatson> If there's already one, listing it is useful so that it gets closed
<cjwatson> But creating it just for the sake of independent verification you don't plan to do is pretty pointless
<infinity> jamespage: If all parties involved agree that the MRE+CI is enough, then you could easily script or otherwise automate adding the v-done tag to all the bugs.
<Daviey> jamespage: We did do some semi-automation for handling the verification of each bug task last cycle.
<jamespage> infinity, indeed - if the SRU team are happy with that then we can do that
<infinity> Well, it would get your SRUs released in a timely fashion, as Colin points out.
<infinity> The only other option is to track your SRUs separately, as we do for the kernel, but that doesn't scale well if we have too many unique snowflakes.
<Daviey> jamespage: There is tooling to change tag state, already in the tools branch.. no?
<cjwatson> The SRU team is looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html and in general isn't going to have read all the bug histories; the best way to get something released is to make sure it all looks nice and green there.
<Daviey> infinity: well the openstack suite is getting larger per cycle.. so yeah
<cjwatson> (I do still tend to eyeball each bug to catch abuse, and so would appreciate it if there weren't a wild excess of automatically-created bugs there)
<Daviey> if we release early and often avoids the wild excess :)
<infinity> Speaking of old SRUs, I need to do something about my initramfs-tools in precise for dot-two.  Grr.
<cjwatson> Daviey: Helps, but even so it's a lot quicker to eyeball (say) two bugs than five :)
<Daviey> cjwatson: I think that was the initial reason for the master tracking bug TBH
<jamespage> infinity, cjwatson: well we could not auto-generate missing bug tasks and links in the changelog; so we only see 'Ubuntu reported' bugs
<cjwatson> Daviey: Right, the master bug is not the problem here, it's all the other ones that as far as pending-sru.html is concerned appear to be blocking the release
<jamespage> which would limit the SRU list
<cjwatson> jamespage: Sounds entirely rationale
<cjwatson> *rational
<cjwatson> That seems like a decision to not do work with no value :-)
<jamespage> cjwatson, I'd be happier automating the verification-done stuff on that basis; as its against actual ubuntu bugs rather than upstream
<infinity> jamespage: I don't actually have issues with the tasks being created and then tagged, though Colin's eyeballing point stands too.
<cjwatson> jamespage: Or, you could write the bug references that don't have Ubuntu tasks in such a way that dpkg-genchanges doesn't see them as bug closures
<Daviey> cjwatson: I did disucss with SpamapS about the potential to NOT tag and comment on each bug, as part of the SRU process.
<cjwatson> e.g. "see LP #nnnnnn"
<Daviey> cjwatson: It seems quite rude to hijack an 'upstream' bug with verbose ubuntu process.
<cjwatson> That way, they're available as cross-references for humans, but don't jam up the process
<jamespage> cjwatson, that would still let end-users reference back to LP
<cjwatson> Daviey: Indeed
<jamespage> cjwatson, which gets a +1 from me
<infinity> cjwatson: The only sadness with intentionally avoiding closure syntax is you miss out on auto-linking in web UIs and such.
<Daviey> "Hi $someone-that-doesn't-care-about Ubuntu, please test our Ubuntu packages"
<cjwatson> infinity: Yeah, but that's fairly minor ...
<cjwatson> (And some UIs will manage to guesstimate it anyway)
<cjwatson> So this sounds like we're all in agreement and we just need to correct the lies in the MRE process
<jamespage> cjwatson, lol
<Daviey> erm, the LP UI is still fine.. It was more the sru-accept.py content that i found uncomfortable
<jamespage> so to summarize
<Daviey> marking them with LP janitor closing logs is reasonable IMO
<jamespage> 1) don't generate bug tasks and closes entries for upstream bugs with no ubuntu task
<cjwatson> If they aren't in a form that dpkg-genchanges recognises, the LP janitor won't close them
<cjwatson> Which IMO is fine here
<jamespage> 2) still reference the bug in the changelog but without the closure
<Daviey> Hmm, i don't see the problem with a Ubuntu bugtask?
<cjwatson> If you have an Ubuntu bug task, you should close it
<Daviey> and why not close them?
<cjwatson> Otherwise you'll end up with cruft in the bug database
<jamespage> 3) automate the verification-done step once all is good
<cjwatson> If you close them, they'll show up on sru-report / sru-accept etc. and you MUST tag them when happy to release
<cjwatson> I don't care which way round you do things, but it needs to match
<Daviey> Right.. I mean.. Have a bug task, and have the changelogs reference them.. but don't add sru tracking tags to the bugs?
<cjwatson> That ain't happening because the tools can't tell
<jamespage> Daviey, this is why
<jamespage> "     - [1c99b24] Jenkins jobs fail because of incompatibility between sqlalchemy-
<jamespage>        migrate and the newest sqlalchemy-0.8.0b1 (LP: #1073569)"
<ubot2> Launchpad bug 1073569 in nova (Ubuntu) "Jenkins jobs fail because of incompatibility between sqlalchemy-migrate and the newest sqlalchemy-0.8.0b1" [Undecided,Fix committed] https://launchpad.net/bugs/1073569
<jamespage> raising the task and marking verification-done is farcical
<cjwatson> You have to either (a) both have Ubuntu (appropriate stable release) bug tasks and set appropriate verification tags, or (b) neither
<Daviey> cjwatson: pending-sru.htmk can't be fixed to ignore bugs without tags?
<cjwatson> Daviey: sru-accept can't be fixed to automatically not create them, and it is very bad to require even more manual work in that process
<cjwatson> Daviey: One of the reasons the SRU queue gets so backed up is that the tools for accepting SRUs require so much tedious manual work
<cjwatson> Daviey: (Which is on somebody's WI list to fix this cycle)
<Daviey> cjwatson: ./sru-accept $@ --no-tags, wouldn't be reasonable?
<cjwatson> Daviey: No, because it still needs tags for some bugs
<cjwatson> Daviey: And, in any case, the goal is not to require manual invocation of sru-accept at all
<cjwatson> It should be done automatically from a frontend SRU review tool
<cjwatson> I don't think it's necessary for openstack packages to be special snowflakes here
<Daviey> cjwatson: Okay.. I will be saddened if we lose the ability to have presence for each suitable bugtask
<cjwatson> You have two perfectly good options to choose from for any given bug, both of which will work fine
<Daviey> So.. If there is a ubuntu task ALREADY.. we tag it.. but don'tcreate superfluous ones?
<pitti> infinity, cjwatson: FYI, langpacks built, debdiffed and tested, uploading now (for precise)
<cjwatson> Daviey: Nobody is saying you need to lose that ability
<cjwatson> Daviey: You simply need to tag the bug verification-done if you do it
<cjwatson> Daviey: Otherwise your update sits in a queue for weeks
<cjwatson> Or rather, in -proposed
<infinity> pitti: Huzzah.
<cjwatson> Daviey: This is a simple matter of appropriate communication ...
<Daviey> right
<cjwatson> And if a bug task is unsuitable for having an Ubuntu bug task and the bug log noise that goes along with it, just don't give it one and don't use the LP: #nnnnnn syntax for it in the changelog
<cjwatson> (After all, most upstream commits in most projects never have an associated bug task and it's fine)
<Daviey> jamespage: the too for git->dch changelogs already polls for LP bug... we should make it check if there is already a task.. and use proper LP #syntax if there is, and inproper LP syntax if it doesn't.  Sound reasonable, everyone?
<Daviey> cjwatson: these should all MOSTLY have LP bug tasks fwiw
<Daviey> (upstream)
<cjwatson> I mean Ubuntu bug tasks
<Daviey> ah, yes
<cjwatson> changelog tool> that will be fine so long as all the ones that do have Ubuntu bug tasks then get tagged v-done when the MRE upload is ready to go
<cjwatson> Then the whole thing will light up green in pending-sru and we'll know what to do
<pitti> infinity: do we still have a way to mass-accept them from -proposed?
<jamespage> cjwatson, OK _ I think I have it now
<pitti> infinity: from unapproved I mean
<infinity> pitti: Yep.
<infinity> pitti: I'll get to them shortlyish.
<Daviey> jamespage / cjwatson: We will also track pending-sru's closer :)
<pitti> infinity: ok, thanks; please let me know if you still need anything from me langpack-wise
<infinity> pitti: Assuming these are complete and all work, I'm fine with 'em.
<Daviey> pitti: do you not use the queue tool?
<infinity> pitti: Thanks for the silly workaround to appease people's missing hash phobias.
<pitti> Daviey: ah right, that; TBH, I've become a bit rusty with archive admin stuff
<infinity> Daviey: pitti probably still lives in the past where we used to do everything on ftpmaster.
<pitti> infinity: no worries; at some point I'll need to get the built sources to macquarie, but that's not a biggie
<pitti> infinity: actually, most of what I did was by-package review and clicking accept on the +queue page :)
<cjwatson> For this purpose queue is basically equivalent to the old ftpmaster queue with additional network latency per accept but lower startup cost
<Daviey> pitti: the queue tool can match by regex.. but wise to use --dry-run first :)
<cjwatson> Oh, and it no longer does substring match by default
<Daviey> err, yeah substring.. not regex.
<pitti> yeah, I remember now
<infinity> pitti: How many of these are there, BTW?
<pitti> infinity: stil uploading; 500ish
<infinity> Need fewer languages.
<Daviey> crikey, i had better free up some inodes on my mail server, for the noise on *-changes
<pitti> infinity: oh, 824
<infinity> Can't we just roughly divide the world into "English America", "Spanish America", "German Europe", "Russian Europe/Asia", and "Chinese everywhereelse"?
<pitti> infinity: well, there are 6 packages per language
<infinity> I'm sure that wouldn't annoy anyone at all.
<xnox> infinity: and about half of those packages are empty and have not translations at all =)
<xnox> infinity: my solution is that when we start publishing packagesets data on the mirrors, we can publish translations packagesets (e.g. such that all gnomy apps that have translations in l18n-gnome-pack-CC declare a packageset l18n-gnome-pack)
<xnox> and then we can use magic from ubuntu-drivers-common to query: oooh I have languages AA, BB, CC enabled & I have packages from l18n-gnome-pack set installed, hence my language support is incomplete until I install l18n-gnome-pack-[AA|BB|CC]
<xnox> cause currently we have, -base|-updates gnome-base|gnome-updates mozilla chromium and kde language pack packages which a lot of them are empty
<xnox> simply because we have no clear way to figure out on the client side which once are needed.
<xnox> (well empty - meta-packages)
<xnox> but this cunning little plan, relies on either auto-generating packageset headers or manually declaring "Translation-Pack" (in approx. similar fasion to Modaliases:*)
<cjwatson> We'll be autogenerating package set headers as soon as I figure out the necessary pile of SQL
<cjwatson> I need that for other reasons anyway
<infinity> pitti: Clearly too late, since I've accepted half of these, but this has always bugged me.  Could the automagic changelog for langpacks be switched from "Initial release" to something like "Updated translation export from $date".
<infinity> pitti: Cause "Initial release" is so clearly a lie for most languages. :P
<pitti> infinity: it actually does that if lp-o-matic updates a langpack
<pitti> infinity: but for a fresh base rebuild I just rm -rf ../precise and rebuild them from scratch
<pitti> infinity: so indeed, it's a wart
<infinity> pitti: language-pack-hpv?
<pitti> infinity: please feel free to reject the NEW ones
<pitti> infinity: need to run out for some 2 hours or so, bbl
<infinity> pitti: Why do we not love the NEW ones?
<pitti> infinity: I thought it was a kind of principle to not introduce new packages in SRUs
<pitti> infinity: I have no strong opinion either way
<infinity> pitti: I have no issues with supporting new languages.
<xnox> pitti: ubuntu should be usable by everyone no matter what language they speak ;-)
<infinity> xnox: As long as that language is English.
<pitti> infinity: as long as you accept -tlh :)
<xnox> infinity: Ð´Ð° Ð»Ð°Ð´Ð½Ð¾ =)
<infinity> xnox: I feel like you may have perhaps just cursed at me, but I'm not going to ask Google Translate.
<xnox> it's not a curse, but i bet this phrase will loose it's meaning in translation.
<xnox> (and the second it's should be its)
<pitti> I understand "yes" at least; no idea about Ð»Ð°Ð´Ð½Ð¾
<cjwatson> google translate says "oh well"
<pitti> Ð¯ Ð³Ð¾Ð²Ð¾ÑÑ Ð¿Ð¾-ÑÑÑÑÐºÐ¸ Ð¾ÑÐµÐ½Ñ Ð¿Ð»Ð¾ÑÐ¾
<xnox> cjwatson: very good. =)
<xnox> pitti: =))))
<infinity> xnox: Yes, his copy and paste skills know no bounds.
<phillw> hi huys, raring-core is in iso tracker as a tar.gz and not as an iso. Who's best to ask about that?
<infinity> phillw: It's not an ISO.
<infinity> phillw: I'm not sure what there is to discuss. :)
<phillw> infinity: which does beg the question of it being on the iso tracker, as I can't test it :)
<infinity> It's just a minimal root filesystem tarball.
<infinity> I think it has a linked testcase, doesn't it?
<infinity> Something like "download, untar, cp /etc/resolv.conf chroot/etc/resolv.conf, chroot in, run apt-get update, profit"
<phillw> infinity: yeah.. drat... I was hoping to use it instead of mini-iso... So much for that carefully laid plan :P
<infinity> phillw: It's not an installer, so that would end poorly.
<infinity> What's wrong with the mini.iso?  It works well.
<phillw> infinity: server is currently over size as an install iso. test-drive doesn't work with mini-iso, I was looking for an alternative.
<cjwatson> It's not a substitute for a mini.iso, and won't be.
<phillw> although I am puzzled as to why server would be over size, with no GUI?
<cjwatson> server being oversized has zero effect on testdrive
<cjwatson> (or should do, anyway)
<cjwatson> It's essentially an academic issue
<phillw> cjwatson: okies, I'll go with server, it has the advantage of being to use the tasksel window to install a choice of GUI to it. Thanks guys, I'll leave you in peace :)
<cjwatson> It turns out there's loads of other stuff people want to shove in *shrug*
<cjwatson> Think cloud, for instance
<infinity> The whole cloud.
<infinity> All of it.
<infinity> And only 15MB over a CD.
<phillw> he he
<infinity> Not too shabby.
<infinity> cjwatson: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1040393 verified for you, if you want to push that before I spin a new d-i with only ABI changes.
<ubot2> Ubuntu bug 1040393 in debian-installer (Ubuntu Precise) "omap netboot partition too small for flash-kernel backup procedure" [Undecided,Fix committed]
<ogasawara> anyone have a clue how often teams are refreshed for our burn down charts?
<ogasawara> for ex, I just punted pgraner from canonical-kernel-distro-team to get a more accurate view of the work assigned to my team, but it has yet to update and I made the change over 2hrs ago
<infinity> I have no clue how or when any of that is generated.  Was that helpful?
<ogasawara> infinity: slightly
<xnox> ogasawara: from personal experience it is ~4h
<ogasawara> xnox: ah thanks, I'll be more patient and check it later then
<stgraber> ^ done at cyphermox's request
<vanhoof> ogasawara: looks like an update just happened ~5m ago
<ogasawara> vanhoof: hrm, I expected more things to fall off, you sure it's happened?
<ogasawara> vanhoof: I do see timestamps of "Last updated: Tue 29 January 2013, 20:13 UTC" but I don't think the team actually refreshed
<vanhoof> ogasawara: hmm not sure, i know all of this is stored in a db, i wonder if removing someone from a team is enough since the work items were already registered?
<vanhoof> ogasawara: from when i ran my own instance of this, it updated everything each time, but might take a bit longer in this case?
<vanhoof> ogasawara: i was going off of the same timestamps myself
<ogasawara> vanhoof: which reminds me, call today?
<vanhoof> ogasawara: sure
<vanhoof> ogasawara: whenever is good for you, im call free for a few hours :)
<ogasawara> vanhoof: sweet, how bout now
<vanhoof> ogasawara: sure
<vanhoof> we've validated both bug 1080588 and bug 1091068 ... can we get these promoted to -updates for 12.04.2 (believe those are the last two big ones on our radar for the point release)
<ubot2> Launchpad bug 1080588 in jockey (Ubuntu) "jockey suggests not installable packages on renamed stack" [High,In progress] https://launchpad.net/bugs/1080588
<ubot2> Launchpad bug 1091068 in linux (Ubuntu Quantal) "No support for Ivybridge Server GPUs in 12.04" [High,Triaged] https://launchpad.net/bugs/1091068
<infinity> vanhoof: Patience. :)
<infinity> vanhoof: They'll both get in if they're validated, no worries.
<vanhoof> infinity: ... is a virtue ;)
<infinity> Also the name of a Firefly character.
<vanhoof> infinity: ack, wfm ... just dont want any to fall off :)
<vanhoof> infinity: thanks
<infinity> That IveBridge bug appears to have 'linux' tasks that are still in Triaged.
<infinity> Did the kernel get fixed without a bug reference at some point?
<infinity> Or did the kernel not actually need fixing?
<infinity> Oh, I see, it got broken out into another bug and fixed.  Should twiddle those tasks, then.
<vanhoof> infinity: think thats been sorted in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087302
<ubot2> Ubuntu bug 1087302 in linux (Ubuntu Quantal) "Add support for Ivy Bridge GT2 Servers" [Medium,Fix released]
<vanhoof> infinity: just task/bug-galore
<vanhoof> infinity: you're too fast I was just about to do that :)
<infinity> :P
<infinity> I've come to the conclusion that my changelogs are too long.
<infinity> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/613662/comments/11 <-- That's, like, half the bug log.
<ubot2> Ubuntu bug 613662 in eglibc (Ubuntu Quantal) "nscd doesn't cache host entries" [Undecided,Fix committed]
<vanhoof> infinity: nice :)
<infinity> vanhoof: Speaking of.  I had several people from several teams asking for things in the latest eglibc SRUs.  I don't recall if any of those were you.  But if so, feel free to peruse the bugs and verify one or two. :P
<infinity> https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu10.4
<vanhoof> infinity: nothing off-hand I know of but let me look
<infinity> Kay.  I need to hunt down the people who cared deeply about the malloc deadlock and the ARM futex thing.
<infinity> The rest, a monkey on valium could validate.
<vanhoof> infinity: nothing sounds familiar, have any names handy, i can go help chase em down
<infinity> I'll remember after I've slept, I'm sure.
<infinity> It's been one of those weeks already.
<vanhoof> infinity: :)
<infinity> (Is it Friday yet?)
<stgraber> infinity: almost
<infinity> Are you lying to make me feel better?
<vanhoof> infinity: in 35m it will be
<infinity> You don't have to do that, we're not dating.
<vanhoof> roflz
<vanhoof> infinity: i like long walks on the beach, drag racing, and hockey
<infinity> I also enjoy racing in dresses.
<infinity> We have so much in common.
<vanhoof> :D
 * xnox goes back to knitting scarf
<vanhoof> xnox: orange please
<xnox> vanhoof: sure, next one will be orange.
<infinity> vanhoof: Flyers orange or Ubuntu orange?
<infinity> vanhoof: Answer carefully.
<vanhoof> infinity: ubuntu ;)
<vanhoof> I dont like that traitor of a coach the Flyers have ;)
<vanhoof> xnox: http://ubuntuone.com/45rb67F6TBowKJJm3Fb283 ... -ENEEDSCARF
<xnox> vanhoof: is that actually your dog?
<infinity> I refuse to believe a dog can use onboard.
<infinity> Most humans can't.
<vanhoof> yeah she's blessing me with her presence as we speak :)
<xnox> me can do a small one for her ;-)
<infinity> balloons: Hey dude.  You filed a bug a bazillion years ago and never followed up for SRU verification.
<infinity> balloons: y u no love us?
<infinity> balloons: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1018504
<ubot2> Ubuntu bug 1018504 in empathy (Fedora) "Empathy doesn't display buddy list" [Undecided,New]
<vanhoof> xnox: :D
<vanhoof> xnox: she's 50lb so not too small :)
<balloons> infinity, ooo
<balloons> that got fixed
<balloons> I check it out
<balloons> what's up with it?
<infinity> balloons: It got fixed 125 days ago, apparently, but you never verified on precise.  Sadness.
<balloons> wha? I thought it got verified :-(
<balloons> it worked for me
<infinity> balloons: I'd love to release that SRU instead of pulling it, if you can verify.
<balloons> I'm not on precise anymore
<xnox> infinity: /me is doing libnih verification. It's ~approx. from that timeframe.
<balloons> ahh.. looks like it never made it to precise perhaps
<balloons> ?
<infinity> balloons: Your only comment was about it being fixed in Q, which was less than helpful. :/
<infinity> balloons: It's been in precise-proposed for 125 days due to lack of verification.
<balloons> well, I can reload precise and do a verify
<balloons> i thought it was released :-(
<balloons> hmm
<infinity> xnox: Someone should SRU libnih to whack that glibc private symbol usage too, to help apt's tiny brain cope better with upgrades.
<infinity> xnox: Though, would require an apport SRU for completeness too.
<infinity> xnox: https://bugs.launchpad.net/libnih/+bug/997359
<ubot2> Ubuntu bug 997359 in libnih "nih uses eglibc private symbol __abort_msg" [Undecided,Confirmed]
<xnox> infinity: yeah, somehow coverity source code analyser says that __abort_msg is never reached in the code (or something like always evaluating to a const value). I'd like to check that first.
<infinity> xnox: Why check that when it should be removed? :P
<xnox> as in the other _nih__abort_msg symbol that got introduced to replace the glibc one is not reached, that is.
<xnox> =D
<ogra_> infinity, fyi, while cadejo is reachable via http, it doesnt seem to do anything when triggering a build
<ogra_> buildlive just silently hangs forever
<infinity> ogra_: Oh, that probably means you have a few dozen BuildLiveCDs all sitting there waiting on locks.
<ogra_> nothing in nusakans processlist
<ogra_> i had started a manual build right after it came up again, but killed it now since nothing happened
<infinity> nusakan has nothing to do with it.
<infinity> killing the ssh session doesn't kill the remote.
<infinity> Anyhow, looking into it.
<ogra_> i know
<ogra_> i dont think there was a remote session
<ogra_> or if there was one it was just sitting there
<ogra_> none of the logs moved
<infinity> You missed the part where I said "waiting on locks", right?
<infinity> Probably had a stale lock when it came up.
<ogra_> i didnt, thats what i was agreeing to :)
<ogra_> "sitting there"
<ogra_> hmpf, so why does my upstart job not work ...
<ogra_> i can run it manually but it never runs automatically
<stgraber> ogra_: never starts or fails once started?
<infinity> Does it specify when it should start?
<stgraber> ogra_: (do you have /var/log/upstart/<job>.log?)
<infinity> Does it double-fork itself into oblivion and upstart loses it?
<ogra_> http://paste.ubuntu.com/1587278/
<ogra_> pretty trivial
<cjwatson> vanhoof: yeah, the routine for 12.04.2 is going to be that we manually check everything that *doesn't* seem to be going in
<ogra_> oh, i didnt know about that log stuff !!!
<ogra_> gah
<cjwatson> maybe it objects to your pointless use of /bin/echo? :)
<ogra_> cannot create /sys/devices/system/cpu/cpufreq/interactive/boost_factor: Directory nonexistent
<vanhoof> cjwatson: cool, feel free to yell^Wping if you see anything on our end but outside of a few that are already verified, we look to be good
<stgraber> ogra_: hehe, and upstart runs with -e, so any error is critical and the script stops there
<ogra_> i guess i need to bind that to a udev rule and wait for the governor to be initialized
<cjwatson> vanhoof: wouldn't hurt to have a list of things to pay attention to, but it's not vital
<stgraber> ogra_: well, we have a udev bridge you know ;)
<ogra_> right
<vanhoof> cjwatson: noted, i'll have a pass at the queue this evening to be sure
<infinity> ogra_: Or just do it from ondemand, where the governor gets set.
<stgraber> ogra_: so you can do a "start on <device-type>-added" assuming you know what device type you're looking at
<ogra_> infinity, ondemand is off on the nexus
<stgraber> though in this case, it'd be "cpu" which you should have before anything runs :)
<infinity> ogra_: Eh?
<cjwatson> and yeah, I'm checking pending-sru for verified stuff more than once a day; I expect I'm not the only one
<ogra_> we use interactive like android
<infinity> ogra_: I meant the script.
<infinity> ogra_: I know we use interactive, I'm the one who patched it. :P
<ogra_> ondemand has proven to be pretty  wasteful
<ogra_> oh
<ogra_> that one
 * ogra_ tries to stay away from sysvinit for new stuff usually ... i didnt even think about it
<ogra_> though that wont help much if the governor is slow to initalize
<ogra_> i tested the upstart job with "start on started lightdm" i desparation ... seems the dir wasnt even there by then
<ogra_> s/i/in/
<infinity> ogra_: That's inentional.  Read /etc/init.d/ondemand
<infinity> ogra_: The script sleeps so the machine can tear through boot in performance, before dropping you to a friendlier scheduler.
<ogra_> heh
<slangasek> infinity: I think he means the kernel side is slow to appear, not referring to the delay in the init script?
<ogra_> lol
<ogra_> yeah
<ogra_> slangasek, right, i did
<infinity> slangasek: The delay in the init script is why the kernel side isn't there, I imagine.
<slangasek> ogra_: why not do it as a udev rule?
<ogra_> but the sleep will help i guess
<infinity> As in, without enabling the governor, you can't twiddle it.
<ogra_> slangasek, that was what i said above before infinity came up with the ondemand script
<slangasek> infinity: the init script only pokes at /sys, which I think is what ogra is doing too
<ogra_> right
<infinity> slangasek: Yes, but the init script and Oli are doing two different things.
<infinity> slangasek: And one might find that he can't do his thing without first doing what the script does.
<slangasek> right, sure
<infinity> ogra_: cadejo might give you love now.
<ogra_> k
<slangasek> does the 'interactive' governor also adversely impact startup speed?
<infinity> Not sure by how much, but it would do so, yes.
<slangasek> but yeah, I see now; the init script is already where we handle 'interactive', so further tuning should probably go there as well
<infinity> Possibly less than ondemand.
<slangasek> no real sense in splitting the logic between an init script and an upstart job/udev rule that depends on that init script
<ogra_> well, all that stuff should move to upstart/udev eventually
<ogra_> imho
<slangasek> yes, but that's a long "eventually" and we shouldn't leave bits of the logic scattered in multiple different places in the meantime
<ogra_> right
<Noskcaj> the iso tracker has frozen for 12.04, kubuntu alternate
#ubuntu-release 2013-01-30
<cjwatson> infinity: d-i pushed to -updates
<doko> cjwatson, infinity: online?
<doko> hm, promoted libcloog-ppl1 for now
<ogra_> there is a brcm-patchram-plus  in raring source NEW, it makes (or is supposed to make) BT work on the nexus7, would be great if that could be reviewed soon
<seb128> ogra_, seems ok, but shouldn't the source contain the license's text? e.g have a COPYING with the apache license?
<ogra_> seb128, debian/copyright points to "/usr/share/common-licenses/Apache-2.0"
<ogra_> i think thats enough, iirc we only need to ship the full license if there is nothing in /usr/share/common-licenses/
<ogra_> cjwatson, (or anyone else familiar with sysvinit ) .... i'd like a quick glance over http://paste.ubuntu.com/1589449/ before i upload
<ogra_> (it is tested and works on the nx7)
<cjwatson> what if /sys/module/cpu_tegra3 doesn't exist?
<cjwatson> this script's architecture-independent
<ogra_> so i should add tests for every line ?
 * ogra_ does so
<ogra_> hmpf, that gets bulky
<cjwatson> I think it's OK to assume that the interactive governor entries exist
<cjwatson> I don't know about cpuidle
<cjwatson> "if [ -d /sys/module/cpu_tegra3 ]; then ...; fi" around the two cpu_tegra3 entries seems to make sense to me?
<ogra_> yup
<cjwatson> You could sort the entries while you're at it
<seb128> cjwatson, brcm-patchram-plus in NEW is a simple debian-native style package with one .c file under apache license ... does the source needs to contain the apache license text?
<ogra_> debian/copyright points to "/usr/share/common-licenses/Apache-2.0" ...
<seb128> ogra_, well, my understanding (and what I've applied to far for NEWing) is that the license needs to be distributed with the source
<ogra_> right, mine always was that this only applies to licenses not in /usr/share/common-licenses
<cjwatson> If it's in common-licenses, and the situation is clear, it's normally fine for it to be referenced in debian/copyright
<cjwatson> We don't need to police upstream's licence distribution practices; we only need to ensure that we're meeting our obligations ourselves
<seb128> ogra_, I got uploaded rejected in Debian because the LGPL was not included in the upstream tarball IIRC (and it's in common-licenses)
<cjwatson> And distribution in common-licenses is enough
<seb128> uploads*
<xnox> seb128: source upstream tarball typically should have a full license text, debian binary packages can simply have a pointer to /usr/share/common-licenses.
<seb128> well, anyway, I just wanted to check
<cjwatson> xnox: it is not our job to police the contents of upstream tarballs
<seb128> ogra_, NEWed
<seb128> cjwatson, thanks
<ogra_> seb128, well, debian ...
<ogra_> :)
<cjwatson> seb128: I can't speak for every Debian ftp-master, but that doesn't fall under the various things in REJECT-FAQ
<seb128> cjwatson, maybe I remember wrongly or maybe some ftpmaster are picky about that ... anyway, thanks for the clarification!
<cjwatson> seb128: There has to be either an indication in the upstream tarball of the licence that the copyright holder(s) intended, or a description of how we figured out what the licence was
<cjwatson> ("License II" in REJECT-FAQ)
<cjwatson> Of course, it might still be a good idea to contact upstream and get them to spell out the licensing more clearly in their tarball
<cjwatson> I just don't think it's cause for rejection
<seb128> noted, thanks
<ogra_> hmm, how do i pull that into the image now
<ogra_> i guess a dep from ubuntu-defaults-nexus7 will do
<seb128> ogra_, binNEWed as well
<ogra_> cjwatson, http://paste.ubuntu.com/1589513/
<cjwatson> ogra_: LGTM
<ogra_> great, uploading
<tjaalton> I've done a clean install of 12.10, then ran dist-upgrade and rebooted. after that I enabled fglrx and rebooted again, noticing that unity didn't run because the fglrx module wasn't built
<tjaalton> the reason for that was that while linux-headers-generic got upgraded, it didn't pull the new headers package
<tjaalton> so I did 'apt-get --fix-policy install', which did pull the new headers and a bunch of others, like ecryptfs-utils
<tjaalton> also, linux-generic isn't installed on the system, although dpkg.log shows it being installed during image build
<tjaalton> same for the ecryptfs stuff
<tjaalton> so the question is, is it normal?
<cjwatson> tjaalton: there's a known bug in the quantal installer that some of the kernel metapackages were mistakenly uninstalled - bug 1070427
<ubot2> Launchpad bug 1070427 in ubiquity (Ubuntu Quantal) "Ubiquity removes kernel headers, fails to build nonfree drivers" [High,Triaged] https://launchpad.net/bugs/1070427
<cjwatson> We'll probably have to quirk it in upgrades from quantal, or something
<tjaalton> cjwatson: oh..
<tjaalton> thanks
<tjaalton> apw: ^
<apw> tjaalton, ahhh erp, ok that would expalin things
<balloons> infinity, so I went to verify this bug -- i don't see a package in -proposed for it. https://bugs.launchpad.net/ubuntu/precise/+source/empathy/+bug/1018504
<ubot2> Ubuntu bug 1018504 in empathy (Fedora) "Empathy doesn't display buddy list" [Undecided,New]
<balloons> som the changelog doesn't show that it went in.. however the fix was backported from upstream: http://changelogs.ubuntu.com/changelogs/pool/main/e/empathy/empathy_3.4.2.3-0ubuntu1/changelog
<balloons> d'oh.. wrong changelog
<balloons> hmm.. ok, so telepathy-glib0 never saw an update -- ahh, that's the upgrade
<infinity> balloons: It wasn't empathy, it was telepathy.  The bug's mistargeted.
<balloons> infinity, yes I think it's sorted now
<infinity> balloons: Ugh, and if people had just done the right bug paperwork, I wouldn't have had to bug you.  There was another bug (without a precise task) that someone has verified months ago.  Grr.
<balloons> it's ok.. like I said, I thought it had gotten in and everything was taken care of
<balloons> I actually looked at that last year again in Nov when it was pinged again
<balloons> anyways.. let me know if I can do anything else to help
<infinity> balloons: I'm releasing it now, so not much more you can do for that bug. :P
<balloons> hehe
<balloons> good
<infinity> balloons: But we're driving toward 12.04.2, if you want to get together hordes of testers to throw at dailies.
<infinity> balloons: Between the new kernel/X enablement stacks and SecureBoot, there's something there to break for everyone.
<balloons> I know.. I was thinking about asking.. it's only going to be the dailies then -- no milestone at all?
<balloons> I believe slangesk answered me on it a few weeks ago when I asked saying so
<cjwatson> 12.04.2 will be the milestone
<cjwatson> I posted a note to ubuntu-devel-announce a few days ago with the rough schedule for candidate images and such
<infinity> balloons: Yeah, the milestone will appear soon enough.  But early testing never hurts.  Especially in the face of massive changes that we may need last-minute fixes for.
<balloons> cjwatson, ahh, ok good
<balloons> that's saner, I missed your annouce then
 * balloons goes to look
<infinity> Dear Soyuz, the source isn't NEW when the package is already in -updates, kthx.
<cjwatson> infinity: Ancestry again :-/
<infinity> cjwatson: Yeahp.  And well-known.
<infinity> cjwatson: Just annoys me occasionally. :)
<cjwatson> Yeah
<antarus> anyone know where arges hangs out?
<infinity> Dear Soyuz.  Oh.  Wait.  We've had this conversation.
<infinity> antarus: #ubuntu-kernel is a fair bet.
<antarus> do you know what TZ he is in?
<infinity> Something vaguely Americanish.
<infinity> He's in Austin.
<antarus> ahh yes
<antarus> SpamapS: ping
<SpamapS> antarus: pong, sup?
<antarus> SpamapS: hi
<antarus> SpamapS: looking for a sponsor for eslayer   ] [ yofel     ]
<antarus> ugh
<antarus> chromeos screws me again
<antarus> eslayer   ] [ yofel     ]
<antarus> sigh
<antarus> I give up
<yofel> ^^
<antarus> bug 806248
<ubot2> Launchpad bug 806248 in unity (Ubuntu Precise) "unity::TimeUtil::TimeDelta returns an int value which overflows after 24 days of uptime" [High,In progress] https://launchpad.net/bugs/806248
<antarus> yofel: sorry :/
<antarus> chromeos + chromoting == crappy copy and paste :/
<yofel> happens ;)
<antarus> could be worse, I didn't paste confidential information ;p
<infinity> tjaalton: ^
#ubuntu-release 2013-01-31
<tjaalton> infinity: excellent, thanks!
<Mirv> could someone remove bamf 0.2.126-0ubuntu1 from the precise queue and 0.3.6-0ubuntu1 from the quantal queue? nothing wrong with them, but we have an additional commit that fixes the bug in a more cases so that'd be better
<cjwatson> Mirv: done
<Mirv> cjwatson: thank you
<cjwatson> Mirv: (can you explain the quantal reject to Åukasz, if he doesn't already know?  he'll have got a fairly mysterious message)
<Mirv> cjwatson: I agreed upon this with him
<cjwatson> OK
<plars> on upgrading (dist-upgrade) from 12.04.1, lsb_release -a still says 12.04.1 rather than 12.04.2. Is that intentional due to pinning the kernel to the precise 3.2 series unless you installed with 12.04.2 or manually requested the new kernel? or should it still say 12.04.2?
<cjwatson> plars: it's already fixed in -proposed
<cjwatson> base-files
<plars> cjwatson: ok, thanks
<hggdh> cjwatson: so it will say 12.04.2, correct?
<cjwatson> yes
<cjwatson> feel free to upgrade base-files and confirm :)
<hggdh> thank you dear sir :-)
<bdmurray> I skipped the precise one as it doesn't seem that important
#ubuntu-release 2013-02-01
<phillw> cjwatson: infinity do the flavors that do not 'subscribe' to 12.04.1 / 12.04.02 get the 'core' updates as part of normal updating?
<cjwatson> phillw: yes
<cjwatson> it would be pretty hard to stop them
 * cjwatson eyes an image build failure on amd64
<cjwatson> (before psivaa notices :-) )
<cjwatson> good grief, is it February already
<psivaa> :), but there is an amd64
<psivaa> image i mean
<cjwatson> psivaa: mm, with a stale livefs though
<psivaa> cjwatson: ok, i dont know the impact of this, but the image has passed the default smoke tests including a manual installation
<cjwatson> if it's not broken for you yet, don't worry then :)
<cjwatson> but I'll fix it anyway, since it'll go wrong eventually
<cjwatson> impact: the image doesn't actually have new software
<psivaa> cjwatson: ok yes just noticed amd64 images have 3.8.0-2-generic whilst the i386 have 3.8.0-3-generic :)
<cjwatson> I think it's just bad luck with upload timing, actually
<cjwatson> I'll poke a respin
<cjwatson> linux-meta was uploaded in the right kind of time period, and there's probably a window where the live task is wrong in the archive
<cjwatson> ok, that respin seems to have worked, or at any rate hasn't complained at me
<psivaa> cjwatson: ok, will use the latest. thanks
<cjwatson> Wait.  What?  libxkbcommon generates shlibs with *exact version* dependencies?
<Laney> grim, eh?
<cjwatson> Huh, it's in 0.1.0~0-1's changelog
<Laney> We were just discussing that in #-desktop - I pinged tjaalton for comment
<cjwatson> "Since users are likely to be only XServer and Wayland, that shouldn't be too much of a hassle."
<Laney> I believe that's a hangover from when it was really expereimental
<cjwatson> So, uh, yeah, I guess somebody's going to reupload gtk+3.0 ...
<Laney> We'll take care of it, but I'd like it to be after fixing the shlibs
<cjwatson> Depends how long the latter takes, I guess
<Laney> sure
<Laney> Surprised this didn't get caught at MIR time though
<infinity> Laney: It was totally caught at MIR time as a feature. :P
<infinity> Laney: "Looks fine. The packaging is great. No symbols file, but it specifies a strict -V arg for dh_makeshlibs. Builds fine. Even has a bug subscriber!"
<Laney> Hah :P
<infinity> (Were it a -V of just the upstream version or something, that wouldn't bug me terribly, though symbols files are much saner to guard against regressions and such)
<Laney> that's what we have in u3 now
<infinity> Laney: The symbols file in -0ubuntu3 is surely a lie...
<infinity> Laney: Not that I guess partial upgrades are a big concern, but I assume most of those symbols should be tagged 0.1.0, not 0.2.0
<Laney> I didn't look at it. What's the problem?
<Laney> Maybe. I'm not sure I care all that much for the two rdeps that are already broken.
<infinity> Yeah, it's not really a big deal, I suppose.  I'm just the sort of anal retentive perfectionist who would have gone back in time and generate my symbols file on 0.1.0, then updated it for 0.2.0.
<infinity> With absolutely zero benefit.
<Laney> I'm sure tjaalton would love a patch. :P
<tjaalton> well, there never was a 0.1.0
<tjaalton> 0.2.0 is the first release
<tjaalton> that doesn't mean 0.1.0~ didn't have any symbols..
<tjaalton> so I could fix that, but it's probably not urgent?-)
<infinity> tjaalton: Not only is it not urgent, it's pointless.
<tjaalton> :)
<infinity> tjaalton: Since the only reason to have a symbols file that lists 0.1.0's symbols is to allow people to install 0.1.0 to satisfy the dep.  Which we probably don't want anyway.
<tjaalton> right
<infinity> tjaalton: I was just being mildly anal about the documentation of symbol history, I guess. :P
<tjaalton> hehe
<infinity> I do find that, with a few rare examples like glibc, Debian symbols file are often one of the better references for "this symbol was added in version $foo".
<Laney> http://upstream-tracker.org/ is quite neat
<infinity> Laney: Ooo, neat, I've never seen that before.
<phillw> ScottK: from the OP --> Devon Tourond :Â ThanksÂ 
<ScottK> phillw: You're welcome.
<phillw> well, we don't often get a 'thank you' back from OP's, So I wanted to share that one with you :)
#ubuntu-release 2013-02-02
<slangasek> infinity: ^^ 1 of 2 :)
 * infinity raises an eyebrow at the name in the changelog...
#ubuntu-release 2014-01-27
<infinity> gccgo-go?  That's not redundant-redundant..
<jamespage> infinity, its the go tool built using gccgo instead of golang gc - for proposed main inclusion
<zul> can someone promote python-networkx (#1271609), python-taskflow (#1271617), python-oslo.rootwrap (#1259985) so we can get openstack built in the archive please
#ubuntu-release 2014-01-28
<xnox> zul: hm networkx interesting that it needs such a scientific package =)
<doko> please can somebody overwriting the failing cherrypy and python-misaka tests?
<doko> infinity, ^^^
<doko> never did succeed
<infinity> doko: Done.
<infinity> bdmurray: You around?
<bdmurray> infinity: in a meeting
<infinity> bdmurray: That's okay.  Can I get you to set raring to unsupported in meta-release when you're bored of your meeting? :P
<ogra_> *sniff* ... there goes the ringtail
<Laney> it had a good life
<bdmurray> infinity: yeah, I'll take care of it
<ogra_> Laney, it had my favorite T-Shirt :)
<Laney> it's the last one I have a t-shirt for I think
<Laney> :(
<ogra_> same here
<bdmurray> infinity: done
<infinity> bdmurray: Danke.
<infinity> bdmurray: Oh, and I think ReleaseNotes should be moved to http://changelogs.ubuntu.com/EOLReleaseAnnouncement ?
<infinity> bdmurray: History in older releases seems to imply that.
<infinity> bdmurray: And remove ReleaseNotesHtml.
<bdmurray> infinity: right, thanks
<xnox> doko: please remove python-central from the archive: obsolete - superseded by dh-python
<mlankhorst> can someone accept glamor-egl?
<tiheum> =====================================================================================================================
<mlankhorst> ty
<seb128> mlankhorst, https://lists.ubuntu.com/archives/ubuntu-archive/2014-January/047281.html btw in case you didn't see it
<mlankhorst> I don't think that can be fixed
<mlankhorst> oh m-a same, oops
<mlankhorst> ok I've pushed a fix to the glamor-egl repo, should be part of the next upload
<seb128> mlankhorst, thanks
#ubuntu-release 2014-01-29
<cjwatson> pepo (archive master) and alphecca (buildd-manager) are being upgraded to precise; there'll be no builds or publications for an hour or so
<cjwatson> (well, modulo whenever it starts ...)
<rsalveti> infinity: mind checking linux-flo and linux-meta-flo (binary new atm)?
<rsalveti> useful to create the new nexus 7 image
<infinity> rsalveti: Done.
<rsalveti> infinity: awesome, thanks
<lool> cyphermox: http://paste.ubuntu.com/6839249/
<lool> ups ECHAN
#ubuntu-release 2014-01-30
<ogra_> wheee ! congrats to whoever unscrewed the publisher
<cjwatson> yeah, it looks like it's done now, though band-aided
<cjwatson> (only slightly)
#ubuntu-release 2014-01-31
<matttbe> Hello bdmurray
<matttbe> I see that you accept an SRU for Cairo-Dock (core) => LP: #1250221
<ubot2`> Launchpad bug 1250221 in cairo-dock (Ubuntu Trusty) "[SRU] Please update Cairo-Dock and its plugins to the version 3.3.2 (bug-fix version)" [High,Fix released] https://launchpad.net/bugs/1250221
<matttbe> Thank you for your help!
<matttbe> Is it maybe possible to also accept the SRU for the plugins too? :-)
<matttbe> (because the user will have a lot of warnings in the terminal if the core version is newer than the plugins :-) )
<matttbe> The new version of the plugins should fix these bugs: LP: #1244997 - LP: #1243608 - LP: #1089052
<ubot2`> Launchpad bug 1244997 in cairo-dock-plug-ins (Ubuntu Saucy) "cairo doesn't run, only settings window appears" [Undecided,Fix committed] https://launchpad.net/bugs/1244997
<ubot2`> Launchpad bug 1243608 in cairo-dock-plug-ins (Ubuntu Saucy) "composite manager applett has typo in its russian description localisatoin" [Undecided,Fix committed] https://launchpad.net/bugs/1243608
<ubot2`> Launchpad bug 1089052 in cairo-dock-plug-ins (Ubuntu Saucy) "Panel mode can't be positioned to the right" [Low,Fix committed] https://launchpad.net/bugs/1089052
<bdmurray> matttbe: I'll have a look
<matttbe> bdmurray, thank you :-)
<matttbe> bdmurray, thank you for your help! :-)
#ubuntu-release 2014-02-01
<slangasek> cjwatson: so I figured out how I overlooked mir as a protobuf revdep before staging this; I had an out-of-date checkrdepends on lillypilly looking at an out-of-date mirror of dists (trusty is entirely missing).  should lillypilly:/home/ubuntu-archive/mirror/ubuntu/ be getting updates?
#ubuntu-release 2014-02-02
<xnox> slangasek: use up-to-date $ reverse-depends & reverse-depends -b ?! (well it's timed with SA archive pulse/mirroring but typically seems to be enough for calculating transitions)
<slangasek> xnox: checkrdepends figures out the binary packages for a given source; while reverse-depends seems adequate for transitions like this, checkrdepends also covers other cases so I'd like to have it working again somewhere :)
<infinity> slangasek: reverse-depends also does source to binary mapping, if you use the "src:<package>" syntax.
<infinity> slangasek: My only complaint about reverse-depends is that it's on third-party infrastructure.  If we moved it to snakefruit (and updated the tool appropriately), I think I'd prefer improving it to fill gaps, if there are any.
<infinity> Since no one can use checkrdepends without access to a machine with a dists tree, which is a bit limiting for recommending it to others.
<cjwatson> slangasek: I wouldn't expect it to; we should probably nuke that for clarity and have people use snakefruit
<cjwatson> (though that only works for AAs)
<Laney> a mirror on lillypilly would still be useful
<slangasek> infinity: so are you proposing we expose the reverse-depends service on snakefruit?
<xnox> slangasek: yeah, reverse-depends already accepts --service-url=URL so we simply need to generate and expose compatible cache
#ubuntu-release 2015-01-26
<cyphermox> could someone please look at the libndp MIR; I've just uploaded a fix for the network-manager test regression, and now that's in depwait because libndp isn't in main yet
<cyphermox> incidently, the previous upload didn't block on that, but it was coming from a citrain silo
<cyphermox> fwiw, it's MIR bug #1392385
<ubot93> bug 1392385 in libndp (Ubuntu) "[MIR] libndp" [Undecided,Fix committed] https://launchpad.net/bugs/1392385
<mlankhorst> can I get a sru admin to accept the remaining packages for utopic's xorg in trusty?
<sil2100> stgraber: hey! Do you know if it's possible to build Ubuntu-RTM images through the isotracker right now?
<sil2100> I don't seem to see the possibility there, but maybe I'm blind
<sil2100> I remember we couldn't in the past
<ogra_> i dont think that was ever added
<cyphermox> slangasek: would you have time to kick libndp into main, as per my request above?
<cyphermox> (please)
<ari-tczew> +1 ^
<apw> infinity, i think we have a linux NBS situation in vivid-proposed, as -10 never worked and was replaced by -11
<infinity> apw: Probably, yes.  I just uploaded d-i, will sort out the NBS now.
<apw> infinity, thanks
#ubuntu-release 2015-01-27
<mlankhorst> can those binaries be accepted? ^
<infinity> mlankhorst: I'll sort out llvm in the morning, it'll need some overrides and I don't feel like thinking at 2am.
<mlankhorst> oke
<Riddell> Laney: does you magic migration knowledge have any thoughts on getting muon/libqapt/debconf-kde into the archive?
<Laney> Riddell: looks like a transition?
<Riddell> Laney: yep, moving to qt5/kf5
<Riddell> but all the rdepends should be with it now
<Laney> Riddell: I don't see, for example, kde-runtime uploaded for it (Depends: libqapt2-runtime)
<Riddell> Laney: you're a genius, how did you find that?
<Laney> Riddell: I looked in update_output near the bottom where it lists a big load of packages and drilled one of them down to kde-runtime which itself has these out of date Depends
<Laney> Riddell: you might find the transition tracker helpful, btw
<LocutusOfBorg1> hi folks, why virtualbox/precise-proposed didn't migrate yet? it is in proposed since  2015-01-16
<rbasak> ^^ that's the last of the php5 binaries. Can someone review please? After this is accepted, I'll need to rebuild php-json and then all the reverse deps.
<cjwatson> That's just adding php5-phpdbg?
<rbasak> I'm not sure - I didn't see exactly what changed. This is a 5.5->5.6 bump with some major packaging changes in Debian.
<cjwatson> php5-phpdbg is the only new binary.
<rbasak> OK
<cjwatson> Which seems fine, so accepted.
<rbasak> Thanks!
<brainwash> can someone please move xfdesktop4 from trusty-proposed to -updates? bug 1365965
<ubot93> bug 1365965 in xfdesktop4 (Ubuntu Trusty) "[MRE] Please update xfdesktop4 to 4.11.8 in Trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1365965
#ubuntu-release 2015-01-28
<rbasak> [3.4.0-3ubuntu1 => 3.4.0-3ubuntu2.1]
<rbasak> Oops. Never mind.
<rbasak> It'd be nice to be able to automate SRU version number generation.
 * rbasak wonders what the security team doess
<jdstrand> rbasak: we use a tool called 'umt': http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/build-tools/umt
<jdstrand> rbasak: it does a quite good job, but it doesn't know about some corner cases
<jdstrand> (eg, two releases with the same version that need an update)
<mlankhorst> uh weird.. thought libepoxy was in trusty?
<mlankhorst> oh damn, not in main..
<didrocks> cjwatson: sorry to bother you for that one, but I'm unsure how this can work on the archive/launchpad side. Of course, trusty is frozen, so I can't promote it from the release pocket, and there has been no SRU for libepoxy. Consequence is that it can't find it in trusty-updates for instance? how would you deal with this? ^
<mlankhorst> worst case we could SRU libepoxy from utopic, I don't think anything depends on it right now in trusty
<mlankhorst> $ reverse-depends -b libepoxy-dev -r trusty
<mlankhorst> No reverse dependencies found
<didrocks> mlankhorst: I would think rather that we can do a non change rebuild
<didrocks> "just" to get a new binary
<mlankhorst> yeah probably
<cjwatson> didrocks: copy it to trusty-proposed (or maybe trusty-updates) and promote the copy
<cjwatson> didrocks: no need for a no-change rebuild
<mlankhorst> ah
<mlankhorst> didn't we have this in precise before? can't remember the package though
<didrocks> cjwatson: gotcha, doing! thanks
<mlankhorst> needs approval :P
<cjwatson> lies
<didrocks> mlankhorst: should pe published soon in main ^
<mlankhorst> goodie
<rbasak> jdstrand: neat. Thanks!
<mlankhorst> \o/
<mlankhorst> accept and the drivers should start building. :P
<LocutusOfBorg1> hi folks, why virtualbox/precise is still in proposed since 12 days?  4.1.12-dfsg-2ubuntu0.8
<LocutusOfBorg1> also virtualbox/trusty should have migrated today
<LocutusOfBorg1> I would like to address the 6 CVES
<LocutusOfBorg1> arges, can you please also push virtualbox-trusty?
<LocutusOfBorg1> (thanks for the precise virtualbox move)
<arges> LocutusOfBorg1: sure, going through the list slowly
<LocutusOfBorg1> sorry for bothering, just there is bug 1413603 waiting for it ;)
<LocutusOfBorg1> I just don't like having CVEs around my packages :)
<arges> LocutusOfBorg1: ok done
<LocutusOfBorg1> thanks!!!
<bdmurray> arges: are you doing SRU work today?
<bdmurray> arges: if so could you stop as I'll be training tjaalton later today.
<arges> bdmurray: sure. thought today was my day?
<bdmurray> arges: It is I just need training material. ;-)
<arges> bdmurray: ah, no problemo. happy SRUing
<infinity> Trying easy from adconrad: libcapi20-3/1:3.27-1 network-manager/0.9.10.0-4ubuntu2 network-manager-applet/0.9.10.1-0ubuntu1 gnome-control-center/1:3.14.2-2ubuntu2 ppp/2.4.6-3ubuntu1 isdnutils/1:3.25+dfsg1-3.5ubuntu1 network-manager-pptp/0.9.10.0-1ubuntu1 network-manager-iodine/0.0.5-1ubuntu1
<infinity> leading: libcapi20-3,network-manager,network-manager-applet,gnome-control-center,ppp,isdnutils,network-manager-pptp,network-manager-iodine
<infinity> failed: libcapi20-3
<infinity> THANKS FOR YOUR EXTREME VERBOSITY, BRITNEY.
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/vivid/2015-01-28/17:16:30.log you got it on the previous run
<infinity> Laney: Oh, hah.  Check.
<infinity> Laney: So, yeah.  "failed" is an entirely silly message.  Oh well.
<infinity> I have no urge to fix it because I don't want a pointless delta with Debian.
<infinity> And even less urge to fix it in Debian.
<Laney> Maybe you can reward my powers of observation by moderating u-d-a. :)
<Laney> I won't know if you do or don't though, because CTRL-A D BYEEEE
<infinity> Laney: Done.
<tjaalton> stgraber: was lxc 1.1.0~rc3-0ubuntu1 supposed to go to vivid instead?
<stgraber> tjaalton: hmm, yeah, where did it end up? trusty? :)
<stgraber> yeah, looks like it did... /me re-uploads to vivid
<tjaalton> stgraber: hehe, cool
<stgraber> looks like you beat me at rejecting it :)
#ubuntu-release 2015-01-29
<infinity> bdmurray: Since you've been accepting SRUs of mine today, want to look at those two as well?  ^^
<bdmurray> infinity: can it wait 'til tomorrow? I've been working with timo and he's gone now.
<infinity> bdmurray: Oh.  Sure.
<infinity> bdmurray: No rush, just thought you might be in a zone. :P
<bdmurray> infinity: the burned out zone now ;-)
<bluesabre> SRU team, please accept  xubuntu-default-settings (trusty-proposed/universe) [14.04.7 => 14.04.8] into proposed
<bluesabre> let me know if you have any questions :)
<lefteris> hi there, can i ask something about making an sru or this is not the right channel;
<mlankhorst> lefteris: #ubuntu-devel and the wiki pages :)
<lefteris> mlankhorst: thank you
<brainwash> bdmurray: I've commented on the xubuntu-default-settings report (trusty-proposed)
#ubuntu-release 2016-02-01
<rtg> infinity_, please reject the linux-snapdragon package. looks like we might take a different direction.
<jderose> cyphermox: you have a chance to look at this yet? https://code.launchpad.net/~jderose/ubiquity/fix-1539266/+merge/284364
<cyphermox> jderose: looks fine, I'll merge it
<jderose> cyphermox: much thanks!
<jderose> cyphermox: how long to you think it will take for this to land in a 14.04.4 daily ISO? I'll test this as soon  as the ISO is available, will report back with the results.
<cyphermox> I don't know, it will also be up to the SRU team to review it, and then the usual SRU time.
<cyphermox> (provided it's tested quickly enough)
<jderose> cyphermox: ah gotcha, so this change will go through the normal SRU process? makes sense considering how late in the game it is. thanks!
<cyphermox> well, things have to go through the normal SRU process anyway
<infinity> jderose: Accepted.  Should be in the next daily.
<jderose> infinity: awesome, thanks!
<infinity> jderose: Please give it a spin on old and new hardware and verify it ASAP once you can, we're getting close to the point release.
<jderose> infinity: will do. i already checked it (by copying my changed file over the installed file) on hardware that uses SMBIOS newer than 2.8
<jderose> infinity: as soon as i can, i'll also double check it on older hardware to make sure there are no regressions because of this change, and will double check it on newer hardware that needed this fix
<cyphermox> infinity: could you please also review multipath-tools and parted?
<infinity> cyphermox: In a bit, yeah.  Breakfasting. :)
<cyphermox> yikes
<cyphermox> breakfasting actual breakfast, or shawarma? ;)
<infinity> cyphermox: Oatmeal Crisp!
<cyphermox> nummy
#ubuntu-release 2016-02-02
<rbasak> stgraber: ^ please
<cyphermox> rbasak: ^ thanks!
<xnox> could an AA please weight in on: https://bugs.launchpad.net/ubuntu/+source/sysconfig/+bug/1528658 infinity slangasek seb128 cjwatson ?! =) I guess it would be a "no", as that's only something required on bare-metal installs (non-kvm)
<ubot5`> Launchpad bug 1528658 in sysconfig (Ubuntu) "sysconfig-hardware is missing from s390x server livecd squashfs builds" [Undecided,Confirmed]
<slangasek> xnox: is that an AA question?  The seeds are not AA-managed
<slangasek> xnox: since it affects the server image I would say smoser or rbasak should weigh in, maybe
<xnox> slangasek, well, it affects the s390x debootstrap =) which is used for squashfs on s390x. only on s390x.
<xnox> but yeah, i'm not sure about the procedure here.
<ogra_> seeds can be changed by any core-dev
<ogra_> (so technically you shoudl be able to do it yourself ... parctically you should talk to a server person first indeeD)
<xnox> ogra_, slangasek, is it about seeds? i'm asking about a priority override standard -> important
<ogra_> xnox, ah, i didnt read the bug ... what you can do for a quick solution is to tell livecd-rootfs/live-build to install that package in an arch specific way ...
<xnox> ogra_, ah.
<ogra_> we do that in several places for different bootloader setups
<rbasak> xnox: what's this /etc/sysconfig/ stuff about?
<rbasak> No objection to seeding it, but that path seems completely wrong to me for a Debian-based system.
<rbasak> In this room we think the minimal seed is appropriate I think.
<cjwatson> xnox: Priorities are synced periodically with the seeds.
<xnox> rbasak, it's a mainframe thing, to activate hard-drives and ethernet devices on mainframes, based on hex CCWGROUP addresses.
<cjwatson> xnox: So ultimately, yes, it's a seeds matter.
<rbasak> xnox: that's fine, but why that path?
<ogra_> xnox, take a look at  lp:livecd-rootfs ... in live-build/auto/config line 495 and the next 100-200 lines or so
<xnox> cjwatson, ah. and which seeds become important?
<cjwatson> xnox: minimal
<xnox> ack.
<cjwatson> (and the required seed -> Priority: required)
<xnox> i do wonder, i probably don't want that package in minimal. but I do want it preinstalled in the server.iso squashfs.
<ogra_> cjwatson, but that will add it for all arches, no ? i thought the package is s390 specific
<flexiondotorg_> infinity, Have you had the chance to review the "base" merge proposals for Xubuntu and Ubuntu MATE?
<cjwatson> ogra_: not if it only exists on one architecture, which is the case
<ogra_> ah, k
<cjwatson> xnox: that seems like an odd pairing of things to want
<cjwatson> xnox: is it harmful to have installed on non-bare-metal installs?
<rbasak> xnox: I filed bug 1541007
<ubot5`> bug 1541007 in sysconfig (Ubuntu) "Package ships files in incorrect paths" [Undecided,New] https://launchpad.net/bugs/1541007
<cjwatson> I mean, it's 8KB
<cjwatson> I would think shoving it into minimal is a better use of everyone's time than inventing a new method just for it :)
<rbasak> cjwatson: "is it harmful to have installed on non-bare-metal"...I'm told it's required everywhere.
<rbasak> (also that "bare-metal" doesn't make sense for s390x apparently)
<cjwatson> rbasak: Well, bare-metal as in not inside KVM
<xnox> cjwatson, mostly harmless on non-bare-metal machines =)
<cpaelzer> cjwatson: hi this is the way debian configures channel devices
<cpaelzer> that applies to z/VM/LPAR/KVM
<cpaelzer> all of them
<cjwatson> OK, so why are we discussing it then?  Just shove it into minimal :)
<xnox> ok.
<cjwatson> There's a "hardware and architecture support" section at the top of minimal, it probably belongs there
<jderose> infinity: no new 14.04.4 daily yet it seems? will there be one today?
<tsimonq2> I could be wrong, but I thought that was delayed...
<infinity> jderose: Curious.  Lemme poke.
<infinity> jderose: Evidently, the livefses failed.
 * infinity goes to see why.
<infinity> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/Release.gpg  Unable to connect to archive.ubuntu.com:http:
<infinity> Network blip?
<infinity> jderose: I'll give them a retry.
<jderose> infinity: thanks!
<jderose> cyphermox: i noticed last night that this bug seems to have made it's way into the trusty branch - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1508865
<ubot5`> Launchpad bug 1508865 in ubiquity (Ubuntu) "oem-config: networking not enabled during user config" [High,Confirmed]
<jderose> seems something is different in how the oem session is setup vs the normal install session... any suggestions where i should go digging for this?
<cyphermox> hum, wha?
<cyphermox> when one runs prepare for shipping, NM gets its OEM connections removed (since those are the connections for the OEM network, presumably), it will create new ones when end users uses the system
<cyphermox> also, that bug only lists 15.10, are you saying it also happens on 14.04?
<jderose> cyphermox: i originally filed it for 15.10 the day before it's release... but seems that code made it into the trusty branch since then
<cyphermox> what code do you mean? that you see a bug?
<jderose> cyphermox: networking used to work correctly when doing the first run user config after an oem install; sometime during 15.10 development it broke, and now also seems broken in trusty; i'm not sure where the bug is, haven't dug into it yet
<cyphermox> ok
<cyphermox> could it be that trusty got installed with proposed enabled?
<cyphermox> (just curious, since there is one libnl3 update in proposed that broke things)
<jderose> cyphermox: well, i have noticed that the current 14.04.4 daily ISOs have proposed enabled (i assume to get the lts-wily X and mesa bits ).. so yeah, could be because of libnl, i didn't think about that
<cyphermox> a fixed n-m landed 2 hours ago or so
<infinity> cyphermox: trusty is building with proposed, yes.
<cyphermox> jderose: syslog would tell you for sure.
<jderose> cyphermox: okay, i'll check it out when i test the next 14.04.4 daily. thanks!
<infinity> jderose: New daily up.
<jderose> infinity: awesome, thanks! will report back with my results shortly
<tsimonq2> So I have learned how packages are built recently, but what about the ISOs? what tools are used? how is it automated?
<xnox> done. and it looks like it's similar to what is done for power platforms.
<jderose> infinity: so far so good... tested on newer hardware that uses this code path, plus on older hardware that doesn't. everything is shiny. will be testing oem first user run shortly using our imaging system
<cyphermox_> infinity: if you're reviewing parted, multipath-tools; I just uploaded a fixed multipath-tools for the same kpartx issue that was reported for xenial.
<jderose> infinity: finished testing, everything is shiny - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1539266
<ubot5`> Launchpad bug 1539266 in ubiquity (Ubuntu) "14.04.4: work-around "SMBIOS-implementations-newer-than-version-2-8..." junk from dmidecode" [Medium,New]
<cyphermox_> jderose: NM too?
<jderose> cyphermox_: ah, forgot the check ... NM worked fine during initial install, not sure about first-run user setup... double checking that now
<cyphermox_> k
<jderose> cyphermox: NM seems to be working fine (tested both Ethernet and WiFi)... so the problem I hit last night must have been because of the libnl version in proposed
<cyphermox> ok
<tumbleweed> I've been seeing these in my seeded-in-ubuntu backend cron mail. anyone know why we have vivid images building?
<tumbleweed> WARNING:update.py:Unexpected path: manifests/ubuntu-pd/vivid/daily-preinstalled/20160202
<tumbleweed> WARNING:update.py:Unexpected path: manifests/ubuntu-core/vivid/daily-preinstalled/20160201.1
<tumbleweed> WARNING:update.py:Unexpected path: manifests/ubuntu-touch/vivid/daily-preinstalled/20160202
<infinity> tumbleweed: Because some products (phone and snappy) are still vivid-based for now.
#ubuntu-release 2016-02-03
<slangasek> infinity, cjwatson: is there any reason at this point that we shouldn't drop the BuildLiveCD script from the livecd-rootfs package, and point people at launchpad-buildd instead?
<slangasek> (from the package and the branch)
#ubuntu-release 2016-02-04
<LocutusOfBorg> hi, can anybody pretty-please look at virtualbox-lts-vivid?
<LocutusOfBorg> I  would be happy to answer to any question you might have :)
<apw> LocutusOfBorg, (not that i can approve it, but) is there a reason it has to be a seaparate package, that the support for the vivid kernels cannot be folded into the original ?
<LocutusOfBorg> apw, https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1424769
<ubot5`> Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [High,Triaged]
<LocutusOfBorg>   virtualbox-guest-x11 : Depends: xorg-video-abi-15
<LocutusOfBorg>                         Depends: xserver-xorg-core (>= 2:1.14.99.902)
<LocutusOfBorg> so I had to add a new package specially built against the -lts-vivid package
<LocutusOfBorg> because it changed ABI, so it isn't installable
<LocutusOfBorg> and I'm talking about the guest- package
<LocutusOfBorg> not the host, this is why I'm building only virtualbox-guest-*, and so on
<apw> LocutusOfBorg, ahh against xorg-lts-vivid ... then that makes perfect sense, thank you
 * LocutusOfBorg was hoping about and answer like "hey dumb maintainer, there is this bit that fixes all the mess for you" :)
<LocutusOfBorg> I spent months in debugging this issue, and for sure I would like to avoid having to maintain a new package :(
<apw> we have an initramfs-tools siting in New, which it might be prudent to leave there until (say) Monday as there is also a kernel in flight
<cjwatson> slangasek: launchpad-buildd isn't entirely trivial to set up, but it's indeed perhaps better to not have a script getting gradually staler.
<rbasak> Is it possible to have one architecture binary package in main, but the others in universe?
<rbasak> We're wondering in relation to DPDK and what commitment we want to make for support in main for ppc64el.
<cjwatson> rbasak: It is technically possible in Launchpad, but makes various reports get upset and I think it's a bad idea.
<cjwatson> rbasak: As general advice I would suggest not relying solely on the main/universe distinction to express supportedness.
<rbasak> cjwatson: OK. Any advice on this one please? ppc64el support isn't upstream but there is a patch. We definitely want dpdk in main for amd64 for ovs, but also don't want to block anyone from having ppc64el working in dpdk but aren't sure we (Canonical) want to commit to support that (considering options).
<cjwatson> AIUI Canonical is perfectly capable of having its support guarantees be out-of-band with the archive
<cjwatson> Perhaps talk to STS?
<rbasak> OK, thanks!
<cjwatson> I think the security team still want everything in main to be supportable, but it seems quite unlikely to end up with an architecture-specific vulnerability.
<bdmurray> slangasek: I'm not seeing Supported info for packages any more in Xenial.
<slangasek> cjwatson, infinity: ^^ so Supported seems to have disappeared from the xenial packages files, about the time I merged the change to make xenial == trusty... where does the output of this get logged?
<cjwatson> I didn't deploy it until yesterday, FWIW
<cjwatson> anyway, try pepo:/srv/launchpad.net/production-logs/lp_publish/publish-ftpmaster.log
<cjwatson> Laney: speaking of which, rsync appstream.ubuntu.com::appstream/ -> "@ERROR: Unknown module 'appstream'" - looks like your rsync fragment has somehow ended up not in /etc/rsyncd.conf
<cjwatson> Running maintenance-check for xenial...  done
<cjwatson> slangasek: ^- that's all it says I'm afraid
<Laney> cjwatson: ah FFS
<Laney> cjwatson: I just deployed the nrpe thing which exposes things over rsync, bet that clobbered it
<cjwatson> slangasek: ah, in fact /srv/launchpad.net/ubuntu-archive/ubuntu-germinate/_maintenance-check.xenial.stderr
<cjwatson> oh god this is a fractal of wrong
<teward> with regards to snappy core, how is that affected by the 15.04 EOL?
<teward> s/core//
<cjwatson> slangasek: I think I have bodged this to not be entirely wrong.  lp:ubuntu-archive-publishing r77
<cjwatson> bdmurray: ^-
<cjwatson> deployed, hopefully will recover in a bit
<cjwatson> slangasek: (the wrongness wasn't of your origin, you just tickled it by adding ppc64el/s390x)
<slangasek> heh ok
<slangasek> cjwatson: thanks :)
<slangasek> fractal of wrong> I didn't *think* I was writing python...
<slangasek> er, I mean, php
<bdmurray> cjwatson: okay, thanks
<Laney> cjwatson: should be back
 * cjwatson fixes lp:ubuntu-archive-publishing harder
<cjwatson> Laney: thanks
<Laney> I should document the right place to get that charm from so the next person doesn't have to feel around in the dark
<slangasek> infinity, cjwatson: should our d-i stop build-depending on cramfsprogs? (obsolete, removed in Debian)
<slangasek> and the build-dep is powerpc only, which is why I ask you two
<infinity> slangasek: I'd have to look at why it thinks it needs the build-dep, but I'm willing to believe it's not being used.
<slangasek> infinity: ./build/config/powerpc/powerpc/floppy/net-drivers.cfg, ./build/config/powerpc/powerpc/floppy/cd-drivers.cfg seems to use it, are you building powerpc floppies? :)
<infinity> slangasek: Hrm.  Or maybe it does, indeed, think it's being used.  But it certainly shouldn't need it.
<infinity> slangasek: We're not building floppies, but I'm not convinced that "floppy" means "floppy" in that context, given the filenames.  Will have to trace through a little bit.
<xnox> slangasek, common, we still use punchcards too, and tape =)
<xnox> floppy is so advanced!
<cjwatson> slangasek: fine by me if we track down any associated debris
<cjwatson> bdmurray,slangasek: I've checked and there are in fact Supported fields for xenial now, and I think correct for the recent changes
<cjwatson> (only checked very lightly though)
<slangasek> cjwatson: great, thanks!
#ubuntu-release 2016-02-05
<tjaalton> vivid is EOL, so can all the remaining uploads on SRU queue be rejected?
<ogra_> tjaalton, it isnt EOL for phone and snappy ... perhaps people want to chrry pick stuf from proposed to their build PPAs first
<tjaalton> ok, I won't touch it
 * flexiondotorg_ tickles infinity to inquire about Xubuntu Base and Ubuntu MATE Base.
<slangasek> utlemming: hi, still working on the raspi2 images and I have some questions about intent of some of the binary hooks that I'm hoping you can shed light on
<slangasek> utlemming: specifically, 030-root-tarball.binary - this is doing kernel and bootloader removal... this is because it's creating a separate root tarball artifact, I guess?
<slangasek> well, I guess I've answered that particular question by reading on in the code
<slangasek> but now I need to see what we should do here... AFAICS when building for a subarch we should simply never build the rootfs bits
<xnox> slangasek, rootfs.tar.gz has kernel/bootloader bits removed, and the result becomes lxc image and lxd image (after a metadata tarball is built elsewhere)
 * slangasek nods
<xnox> slangasek, the generated /boot/grub from ec2 emul remains inside it.
<xnox> grub ec2 emul thing
<slangasek> so for a subarch build, we should just skip the rootfs generation
 * slangasek wonders why cloud image livefs builds only list the manifests as artifacts
<xnox> slangasek, i wonder why SHA512SUMS file is not generated.
<slangasek> xnox: maybe it is, but is hidden somewhere?
<xnox> slangasek, =)))))))) youd't think that, right.
<slangasek> but quite specifically, the actual images are not shown as output artifacts
<xnox> slangasek, btw they have to be collected pretty fast, as launchpad agreesively expires / deletes them.
<xnox> slangasek, this is why cpc builds in jenkins, poll, download and store artifacts in swift.
<slangasek> erm ok
<xnox> slangasek, oh the irony, if the same swift is used by both.
<slangasek> pretty sure it is :)
<xnox> slangasek, please RM unity-scope-snappy, defunct, unusable, ftbfs (multiple reasons), not supported upstream, change of api & directly.
<xnox> https://bugs.launchpad.net/ubuntu/+source/unity-scope-snappy/+bug/1542451
<ubot5`> Launchpad bug 1542451 in unity-scope-snappy (Ubuntu) "RM: unity-scope-snappy" [Critical,Triaged]
<xnox> slangasek, canonical upstream approved removal.
<xnox> not seeded.
<xnox> and it has invalid Built-Using tags =)
<slangasek> xnox: Task: ubuntu-desktop-next ?
<xnox> slangasek, i wonder where you get that idea from
<slangasek> from the Packages file
<xnox> which is not authoritative, is it?
<slangasek> xnox: it's not the source, it is authoritative. Are you cheekily suggesting to me that you've already removed it from the seed?
<xnox> slangasek, no, i'm suggesting that desktop team has dropped "ubuntu-desktop-next" a few cycles back.
<slangasek> um
<slangasek> sounds like they didn't communicate that to the archive admins, then :)
<xnox> Laney, is ubuntu-desktop-next a thing?
<xnox> slangasek, if I were an AA...
<slangasek> ya ba dibba dibba dibba dibba dibba dibba dum?
<xnox> slangasek, well, meta pacakge did disappear. so an AA was involved.
<xnox> $ rmadison ubuntu-desktop-next
<xnox>  ubuntu-desktop-next | 1.221 | vivid/universe | amd64, armhf, i386
<xnox> ..
<xnox> one time, and one time only, vivid special.
<slangasek> removing the metapackage might well be independent of removing the task
<xnox> https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/1.250
<slangasek> and the task still exists in ubuntu-touch.xenial
<slangasek> so, lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.xenial please
<xnox> Â¯\_(ã)_/Â¯
<xnox> done
<slangasek> hmm ok
<slangasek> well, I assigned the bug to the desktop team, so we can still grab their review to confirm before removing the package
<teward> when is featurefreeze again?
<infinity> In two weeks.
<teward> thanks.  i would check but the wiki and my tablet here aren't behaving :/
#ubuntu-release 2016-02-06
<tumbleweed> xnox: your ubuntu-touch seeds change broke germinate, because STRUCTURE still references desktop
<xnox> tumbleweed, bah!
<xnox> tumbleweed, should be better now, or whenever structure runs next on that.
<ginggs> hi xnox, do you know the situation with cmake? it seems we reverted from 3.3.2 to 3.2.2 last year. debian are now on 3.4.1 and we need a rebuild for the libjsoncpp transition
<xnox> ginggs, so rebuild it for the transition =)
<doko> ginggs, xnox: well, check if 3.4.1 works ... it still has some proprietary cross patches :-/
<tumbleweed> xnox: thanks. hopefully cron will stop assaulting me by e-mail :)
<infinity> tumbleweed: Should be fixed after my commit.
<xnox> lol, thanks.
<Laney> xnox: We kept that on purpose
<Laney> You should probably check before just doing whatever you want
<Laney> (I would guess that it would be okay to drop it now though, but the call isn't mine)
<xnox> Laney, so unity-scope-snappy ftbfs, uses old snappy api, and is generally not usable. However slangasek didn't want to remove it, as it was still in the desktop-next task.
<xnox> Laney, however the meta packages, and the cdroms were removed in wily. But not the tasks.
<xnox> Laney, slangasek wanted to wait for desktop team to respond about that. and I kind of took the removal of meta packages and images (even historic) as product deprecation.
<xnox> Laney, the seeds can be easily reverted back in place, it's in bzr history. But can we start removing unsupported packages from the archive?
<xnox> Laney, upstream said that unity snappy scope is dead.
#ubuntu-release 2017-01-30
<slangasek> flocculant: cron fixed
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Zesty Alpha 2] has been updated (20170130)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Zesty Alpha 2] has been updated (20170130)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Zesty Alpha 2] (20170130) has been added
<jbicha> slangasek: I guess Zesty Alpha 2 needs to be marked as Released in the iso tracker to quiet the queuebot ^
<acheronuk> Hi. Could someone please take a look at the new sources in the queue for KDE applications 16.12.1? thank you
<ginggs> how does one mark a package so that its autopkgtests run on a 'big' host? Iirc,  p.itti may have done something like that for the julia package
<apw> ginggs, that is a server side configuration, so you need to "ask" here
<ginggs> apw: what is it called, and does it work for all architectures?
<apw> ginggs, its part of the primary configuration for the autopkgtest builder hosts
<ginggs> apw: so what do i need to ask for, and will it help on ppc64el, for example?
<apw> i don't think it affects anything other than the virtual machine architectures
<apw> but i would defer to Laney for more knowledge
<flocculant> slangasek: ty :)
<ginggs> apw: I think it was setting '--flavor m1.large' and I think it would have been for amd64, because julia's tests don't succeed anywhere else. Anyway, could we do this for python-hypothesis please?
<apw> ginggs, that is the effect for scaling stack yes,but it is a mark of "huge" for the package as a whole
<ginggs> apw: so can we mark python-hypothesis "huge" please?
<apw> ginggs, will see what i can do
<ginggs> apw: thanks!
<fossfreedom_> jbicha: quick question - I saw you have a v0.22 in zesty proposed - in debian sid shotwell is v0.25 - I thought for zesty we should be syncing against sid/testing - why are we still at the rather elderly v0.22 series?
<jbicha> fossfreedom_: see bug 1581180 particularly comment 2
<ubot5> bug 1581180 in shotwell (Ubuntu) "Update to Shotwell 0.24.x" [Wishlist,Triaged] https://launchpad.net/bugs/1581180
<jbicha> odd numbers are unstable releases so Debian should have stayed with 0.24 since Debian is freezing for release now
<fossfreedom_> k - thanks for the feedback.  agreed - very much a blocker :(
<fossfreedom_> the reason for the question - for Ubuntu Budgie we were going to drop GNOME Photos in favour for the new shotwell.  Guess we can't.
<jbicha> the bug is available for anyone to work on; the important thing is to not regress Ubuntu Online Accounts support (or anything else)
<jbicha> it was too challenging for me 6 months ago but I haven't looked at it recently
<cpaelzer> FYI  I've seen multiple reverse dependencies tests breaking on the synced Debian DPDK - I'm working to get a fix to Debian and sync a newer one then
<apw> ginggs, ok that should be in production (if i have done it right)
<ginggs> apw: thanks, let me try kicking off a test - should know in about 45 minutes
-queuebot:#ubuntu-release- New binary: libixion [ppc64el] (zesty-proposed/main) [0.12.2-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libixion [i386] (zesty-proposed/main) [0.12.2-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libixion [s390x] (zesty-proposed/main) [0.12.2-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libixion [amd64] (zesty-proposed/main) [0.12.2-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libixion [arm64] (zesty-proposed/main) [0.12.2-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libixion [powerpc] (zesty-proposed/main) [0.12.2-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libixion [armhf] (zesty-proposed/main) [0.12.2-1] (kubuntu, ubuntu-desktop)
<elopio> join #ubuntu-devel
-queuebot:#ubuntu-release- New: accepted libixion [amd64] (zesty-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted libixion [armhf] (zesty-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted libixion [powerpc] (zesty-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted libixion [s390x] (zesty-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted libixion [arm64] (zesty-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted libixion [ppc64el] (zesty-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted libixion [i386] (zesty-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted u-boot-menu [amd64] (zesty-proposed) [1]
<flocculant> do I have to?
<LocutusOfBorg> apw, please remove the block proposed to ocaml stuff? it shouldn't be needed anymore, and maybe Debian will fix them
<apw> LocutusOfBorg, gone
<LocutusOfBorg> <3 ta!
-queuebot:#ubuntu-release- New binary: liborcus [i386] (zesty-proposed/main) [0.12.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: liborcus [ppc64el] (zesty-proposed/main) [0.12.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: liborcus [amd64] (zesty-proposed/main) [0.12.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: liborcus [s390x] (zesty-proposed/main) [0.12.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: liborcus [powerpc] (zesty-proposed/main) [0.12.1-1] (kubuntu, ubuntu-desktop)
<ginggs> apw: \o/ that worked, thanks!
-queuebot:#ubuntu-release- New binary: liborcus [arm64] (zesty-proposed/main) [0.12.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: liborcus [armhf] (zesty-proposed/main) [0.12.1-1] (kubuntu, ubuntu-desktop)
<apw> ginggs, good!
-queuebot:#ubuntu-release- New: accepted liborcus [amd64] (zesty-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted liborcus [armhf] (zesty-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted liborcus [powerpc] (zesty-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted liborcus [s390x] (zesty-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted liborcus [arm64] (zesty-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted liborcus [ppc64el] (zesty-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted liborcus [i386] (zesty-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New source: python-murano-pkg-check (zesty-proposed/primary) [0.2.0-0ubuntu1]
<ogra_> infinity, http://cdimage.ubuntu.com/ubuntu-core/16/current/current/ misses .htacces it seems (i see FOOTER and HEASDER as files there)
-queuebot:#ubuntu-release- New binary: gpgme1.0 [ppc64el] (zesty-proposed/main) [1.8.0-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gpgme1.0 [amd64] (zesty-proposed/main) [1.8.0-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gpgme1.0 [i386] (zesty-proposed/main) [1.8.0-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gpgme1.0 [s390x] (zesty-proposed/main) [1.8.0-3ubuntu1] (core)
<smoser> hi, can i get someone to release the cloud-init yakkety SRU ?
<smoser> josvaz, ^
<apw> smoser, looking
<apw> smoser, done
<smoser> apw, thank you.
<infinity> ogra_: Who set that up?
<ogra_> infinity, i thought that was you
<ogra_> "foundations" :)
<infinity> Certainly not me, maybe "us".
<ogra_> slangasek, who set up http://cdimage.ubuntu.com/ubuntu-core/16/current/current/ ?
 * ogra_ would also liek to know if there are any builds for the edge channel 
<ogra_> *like
<infinity> Anyhow, if it's published by the cdimage code, .htaccess is meant to be written automatically.  If that was slapped together by hand, or is an in-progress thing, patience?
<ogra_> yeah, no hurry
<slangasek> ogra_: current/current?  Do you mean stable/current?
<slangasek> I set that up
<ogra_> slangasek, just a copy/paste from my browser
<slangasek> there are no edge channel builds currently; those will happen when automation is completed
<ogra_> ah, k
<ogra_> i dont really care about stable :)
<slangasek> I... have no idea what has been done here
<ogra_> (apart from release day)
<slangasek> oh I see, stable was a symlink and I though it was a directory. fixing.
<ogra_> well, all the dirs miss the hataccess in fact
<ogra_> *htaccess
<infinity> I prefer hat access.
<ogra_> heh :)
<slangasek> ogra_: 'current' is missing .htaccess because /that/ one was done by hand, back in November
<slangasek> 'pending' has it
<ogra_> well, looks all better now
<ogra_> thx
<acheronuk> Could someone please take a look at the new sources in the queue for KDE applications 16.12.1? thanks
<acheronuk> can someone please also accept gpgme binaries please? these are now required for new KDE frameworks and applications, and without them we are sort of stuck!
#ubuntu-release 2017-01-31
-queuebot:#ubuntu-release- New source: python-os-xenapi (zesty-proposed/primary) [0.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.8-0ubuntu1~ubuntu16.04.1 => 2.0.9-0ubuntu1~16.04.1] (edubuntu, ubuntu-server)
<cpaelzer> rbasak: Hi, I wanted to kick off a discussion if uploaders on multipath-tools should be changed
<cpaelzer> rbasak: I start here  as I'd expect -release to be the right channel, but please feel free to redirect wherever is more appropriate
<cpaelzer> rbasak: current uploaders are hallyn + ubuntu-core-dev; given that our Team was tasked to do the merge this cycle I wanted to ask if it would be correct to add ubuntu-server-dev to that list?
<LocutusOfBorg> hello release and archive admins, the haskell migration needs a kick of haskell-secret-sharing out of release please
<LocutusOfBorg> reason is: the new ghc-8.0.2 can't build haskell-secret-sharing's documentation with haddock
<LocutusOfBorg> we can A: remove the doc package, B: kick it out until the upstream bug is fixed
<LocutusOfBorg> (leaf package)
<LocutusOfBorg> apw, ^^ :=
<rbasak> cpaelzer: I think it may be appropriate to add multipath-tools to the server packageset. Are there any non-server uses of multipath-tools?
<rbasak> Only servers have multipath, right? :-)
<cpaelzer> Only servers have real multipath
<apw> rbasak, things can be in more than one packageset can't they ?
<cpaelzer> rbasak: and crazy-geek-machines
<apw> LocutusOfBorg, do we have a near-term expectation of that fix arriving soon ?
<LocutusOfBorg> in my opinion for a new leaf package, B is preferred (and both me and the Debian Maintainer, are monitoring upstream issue: https://github.com/haskell/haddock/issues/574 )
<rbasak> apw: they can. But AIUI a "relevant to this flavor but not relevant to any other flavor" is pretty much a slam dunk reason to add to a flavor-based packageset.
<apw> rbasak, and yes i would say it is a server-class machine feature in general
<LocutusOfBorg> apw, sorry, don't know
<LocutusOfBorg> I can always remove the doc package if we want it to go in again
<LocutusOfBorg> but for haskell going out of sync from Debian is risky
<acheronuk> apw: sorry to bother you, but any news on getting the old and obsolete kdeconnect-plasma-dbg removed?
 * locutus_ leaves
<apw> acheronuk, i think that is fine, am trying to get a second oppinion
<acheronuk> apw: ok. np. I'm aware the release team is a bit short handed ATM
<apw> acheronuk, will try and get that sorted asap
<apw> LocutusOfBorg, done
<acheronuk> apw: we have KDE applications 16.12.1 sources and gpgme in the 'new' queue as well
<acheronuk> gpgme is needed for some new applications
<acheronuk> apw: but I know you are busy. so whatever can be done is great
<apw> acheronuk, the gpgme1.0 has ftbfs on three arches it used to build on
<acheronuk> apw: yes, I know. which is better than the complete fail it has been having for the last month and 1/2
<apw> acheronuk, so it will not be migrating either way right ?
<acheronuk> apw: That I don't know. The launchpad builders have had issues running the buildtime tests, and it had been difficult to get even this far with it.
<acheronuk> it is something we can't do without if we want to do the KDE PIM suite for zesty, and not leave people with buggy out of date email/addressbook/ etc applications
<acheronuk> https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1647204
<ubot5> Ubuntu bug 1647204 in gpgme1.0 (Ubuntu) "1.8.0-2 FTBFS in zesty 17.04" [Undecided,Confirmed]
<acheronuk> apw: I'm not sure what happens there if we unable to get gpgme building on arm architectures, but for KDE and things like claw-mail it is needed. at least on the architectures it builds on
<apw> acheronuk, indeed ... hmmm
<acheronuk> apw: yep. I have 50+ packages in the KDE PIM suite that can't be uploaded as they are waiting on a working gpgme build, for at least amd64 and i386
<acheronuk> apw: thank you. that seems to have unstuck migrated kdeconnect :)
<acheronuk> & migrated
<apw> acheronuk, so i think we need some commitment to getting that building on those arches if we let it in as it is in the meantime
<apw> acheronuk, good stuff
<acheronuk> apw: well, I certainly would not like it to stay ftbfs on those other architectures if it can be helped, even if on the kubuntu side it not actually required as because of other dependences our PIM packages that need it are not buildable on arm and powerpc anyway
<acheronuk> I think barry is preety keen to see it build on all, and so presumably is the gpg dev who was assisting in that bug report
<apw> acheronuk, ok i'll look at it
<apw> on that basis
<acheronuk> apw: thanks. I am very aware it's not ideal, but at one point I was seriously looking at back up plans for it not building on anything!
-queuebot:#ubuntu-release- New: accepted gpgme1.0 [amd64] (zesty-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted gpgme1.0 [ppc64el] (zesty-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted gpgme1.0 [i386] (zesty-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted gpgme1.0 [s390x] (zesty-proposed) [1.8.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: console-setup (xenial-proposed/main) [1.108ubuntu15.2 => 1.108ubuntu15.3] (core)
<xnox> i do not see a 16.04.2 testing milestone on the iso tracker.
<xnox> the console-setup fix is not essential for a respin.
<xnox> are we releasing 16.04.2 this week?
<jbicha> the HWE stuff is still in xenial-proposed
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.25 => 2.26+17.04.1] (no packageset)
<ogra_> infinity, hmm, is there any particular reason why we do not publish manifest files for server images on releases.u.c ? i see them in the daily builds on cdimage
<ogra_> or slangasek ^^^
<barry> acheronuk: i can't say i have any more bright ideas about the arm failures tho :/
<acheronuk> barry: One is a Qt issue, so I can have ask around the KDE/Qt people on that. Andre Heinecke thought the the others might be helped by some commits in gpgme master branch which don't apply cleanly to 1.8-3
<acheronuk> I may try a git snapshot in a ppa to test the 2nd of those ^^^
<barry> acheronuk: please do let me know how it goes.  it's kind of background for me right now, but i'm interested because it's holding up the claws-mail promotion
<jgrimm> RAOF, SRU duty today?   if so, Xenial Unapproved queue: cloud-init, docker.io, runc, containerd could use some help
<jgrimm> mdeslaur, your zesty memcached upload stuck in update_excuses, just mentioning in case you'd not seen (60 days old)
<mdeslaur> jgrimm: thanks, I'll take a look
<jgrimm> thanks sir
<flexiondotorg> infinity There is a verification done SRU we'd really like to see landed in Xenial in time for 16.04.2
<flexiondotorg> It is humanity-icon-theme (0.6.10.1) xenial;
<flexiondotorg> System 76 were encouraged to do some work to resolve some issues.
<flexiondotorg> They've stepped up and we'd really like to see this included in the 16.04.2 image.
<flexiondotorg> These are the relevant bugs LP: #1657863 and LP: #1622686
<ubot5> Launchpad bug 1657863 in humanity-icon-theme (Ubuntu Yakkety) "Icons are too big or the wrong icon is shown on hidpi screens" [Low,Fix committed] https://launchpad.net/bugs/1657863
<ubot5> Launchpad bug 1622686 in ubiquity (Ubuntu Yakkety) "double header in 16.10" [Low,New] https://launchpad.net/bugs/1622686
<flexiondotorg> slangasek Please also see the above regarding landing humanity-icon-theme (0.6.10.1) xenial; for 16.04.2
<infinity> flexiondotorg: Looking.
<flexiondotorg> Cheers. I'll start chalking up beers.
<infinity> flexiondotorg: There's a ubiquity task there, too.  Is that invalid?  Does the icon theme fix alone fix it?
<flexiondotorg> It does.
<infinity> So we can close the installer tasks?
<flexiondotorg> There is a separate patch for Ubiquity as well.
<flexiondotorg> Which isn't absolutely required to fixed the double header.
<flexiondotorg> So that has landed in z already.
<infinity> But the ubiquity fix is still desirable?  I should keep those tasks open? :P
<infinity> flexiondotorg: Anyhow, icon theme released.
<flexiondotorg> But the icon scaling fixes alone ensure the a11y indicator in ubiquity-dm doesn't oversize the header.
<flexiondotorg> Cheers.
<flexiondotorg> Much appreciated.
<flexiondotorg> infinity When will the 16.04 archive freeze for building?
<infinity> flexiondotorg: Later.  There's another 1wk delay for $reasons being announced this morning, if my meetings last night are any indication.
<flexiondotorg> OK, thanks.
<flexiondotorg> That is actually a relief.
<sergiusens> infinity or slangasek can you please reject 'snapcraft (2.26+17.04.1) xenial' ?
-queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (xenial-proposed) [2.26+17.04.1]
-queuebot:#ubuntu-release- Packageset: Added multipath-tools to ubuntu-server in zesty
-queuebot:#ubuntu-release- New binary: key-chord-el [amd64] (zesty-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: leaflet-geometryutil [amd64] (zesty-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbio-eutilities-perl [amd64] (zesty-proposed/none) [1.75-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golden-ratio-el [amd64] (zesty-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdist-zilla-plugin-autometaresources-perl [amd64] (zesty-proposed/none) [1.21-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu (xenial-proposed/main) [1.1.0-1 => 1.1.2-0ubuntu0.16.04.1] (desktop-core)
-queuebot:#ubuntu-release- New: accepted golden-ratio-el [amd64] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted leaflet-geometryutil [amd64] (zesty-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libdist-zilla-plugin-autometaresources-perl [amd64] (zesty-proposed) [1.21-1]
-queuebot:#ubuntu-release- New: accepted key-chord-el [amd64] (zesty-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted libbio-eutilities-perl [amd64] (zesty-proposed) [1.75-1]
-queuebot:#ubuntu-release- New source: python-tinyrpc (zesty-proposed/primary) [0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.25 => 2.26] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.25+16.10 => 2.26+16.10] (no packageset)
<sergiusens> slangasek: so finally made it and all green ^ (adt tests pre dput can be seen here https://github.com/snapcore/snapcraft/pull/1088)
<slangasek> sergiusens: \o/ \o/
<slangasek> sergiusens: your changelog reuses the already-closed SRU bug for 2.25
<sergiusens> slangasek: :-( Can you reject and I'll fix?
<sergiusens> I checked this many times
<sergiusens> oh well
<slangasek> sergiusens: done
-queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (xenial-proposed) [2.26]
-queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (yakkety-proposed) [2.26+16.10]
<sergiusens> slangasek: do I need to do a new push for zesty as well? I guess so
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.25+16.10 => 2.26+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.25 => 2.26] (no packageset)
<slangasek> sergiusens: no
<sergiusens> slangasek: thanks, re-uploaded for the yak and xerus
-queuebot:#ubuntu-release- New source: neutron-lbaas-dashboard (zesty-proposed/primary) [1.0.0-0ubuntu1]
<RAOF> jgrimm: Sure, looking.
<jgrimm> RAOF, great!! thanks!
<mwhudson> hope they're installable this time...
<lamont> who is my favorite sru team member today?  (can I have freeipmi reviewed and accepted for xenial and yakkety?)
<lamont> (package finally verified in zesty)
<RAOF> lamont: Hello!
<RAOF> I got to actually release some fixes today. Yay!
<lamont> yay!
<lamont> it's a *cough* sizeable addition of some new stuff
<RAOF> *sigh*
-queuebot:#ubuntu-release- Unapproved: im-config (yakkety-proposed/main) [0.29-1ubuntu16.1 => 0.29-1ubuntu16.2] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
<RAOF> jgrimm: cloud-init is quite a large change, and does not seem to be a bugfix-only change.
<RAOF> jgrimm: I notice that the cloud-init in yakkety has been updated by cherry-picking fixes rather than a new upstream version.
<RAOF> jgrimm: Also, your upload would make the version of cloud-init xenial-proposed greater than the version in yakkety. Are you additionally planning to upload this to yakkety?
<jgrimm> RAOF ^^ smoser
<seyeongkim> I'm stuck in verifying 1587039,1640382(same one)  since reproduction steps on description is not working for me. could you please get it out of proposed? I heard there is another commit waiting for my verification. but I think mine seems take long time.
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.12.6-0ubuntu1~16.04.1]
<lamont> RAOF: fwiw, all discussed and in-process with upstream, but figured you didn't want 1.6~aanotevenalpha1 backported... :D
<RAOF> :)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (yakkety-proposed) [1.12.6-0ubuntu1~16.10.1]
<lamont> which reminds me, I need to chunk up the PR that is the patch
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (xenial-proposed) [1.0.0~rc2-0ubuntu2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [2.0.6-0ubuntu1~ubuntu16.04.2 => 2.0.7-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxc (yakkety-proposed/main) [2.0.6-0ubuntu1~ubuntu16.10.2 => 2.0.7-0ubuntu1~16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxcfs (xenial-proposed/main) [2.0.5-0ubuntu1~ubuntu16.04.1 => 2.0.6-0ubuntu1~16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxcfs (yakkety-proposed/main) [2.0.5-0ubuntu1~ubuntu16.10.1 => 2.0.6-0ubuntu1~16.10.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (yakkety-proposed) [1.0.0~rc2-0ubuntu2~16.10.1]
#ubuntu-release 2017-02-01
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (xenial-proposed) [0.2.5-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (yakkety-proposed) [0.2.5-0ubuntu1~16.10.1]
 * RAOF *again* thinks freeipmi should be called freeimpi, pronounced free-imp-me
-queuebot:#ubuntu-release- Unapproved: accepted freeipmi [source] (xenial-proposed) [1.4.11-1.1ubuntu3~0.16.04]
<mwhudson> RAOF: thanks for doing all the docker bits
-queuebot:#ubuntu-release- Unapproved: accepted freeipmi [source] (yakkety-proposed) [1.4.11-1.1ubuntu3~0.16.10]
<jgrimm> RAOF, ditto
<RAOF1> no problem
<elopio> RAOF1: do you know if there's something missing to get snapcraft into proposed?
<elopio> or maybe slangasek, not sure if you are around.
<slangasek> elopio: just the formulaic review
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.26+16.10]
<elopio> thanks slangasek :) It seems I'll get to test yakkety and xenial tonight.
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.26]
<smoser> RAOF1, eventually...
<smoser> RAOF1, on its way
<smoser> Uploading cloud-init_0.7.9-0ubuntu1~16.10.1.dsc
 * smoser out
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-68-gca3ae67-0ubuntu1~16.10.1 => 0.7.9-0ubuntu1~16.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<RAOF> smoser: There's still the other question - 0.7.9 is not obviously a bugfix-only release over what's currently in xenial; why are we updating to 0.7.9 rather than cherry-picking fixes as has been done in the past?
<jgrimm> RAOF, cloud-init tends to get full updates rather than cherry-picking unless there is an immeditate hot fix to push through quickly.. and even then will usually do a follow-up SRU that brings it to a new version update. As we have a need to continue to push forward with new cloud requirements or maas requirements (which also SRUs full versions forward)
<jgrimm> RAOF, we are in the middle of documenting that formally.. since we have that same quesiton come up with each SRU reviewer (i've promised steve we'll have that in place this cycle)
<RAOF> :)
<jgrimm> its a perfectly fair question!!
 * RAOF goes to get a coffee and something sweet.
<tsimonq2> RAOF: Coffee this late? You must be in Australia or something! ;)
<tsimonq2> (oic, your Launchpad profile says Australia, got it...)
<flocculant> cyphermox: just saw fix released on os-prober, sorry to be the bearer of bad news ... not working here
-queuebot:#ubuntu-release- Unapproved: xorg-hwe-16.04 (xenial-proposed/main) [1:7.7+13ubuntu4~16.04.1 => 1:7.7+13ubuntu4~16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.22~14.04]
<mvo> hey xnox - is anything holding back xorg-server-lts-xenial in the trusty SRU? it seems like its already in proposed for 18days and it would be nice to get it as it unblocks the systemd install on desktop images in trusty. thank you!
<mvo> xnox: oh, nevermind, it looks like there are still some bugs in "verification-needed" state
<xnox> mvo, correct the top sru is a piggy back on the previous one which is a huge SRU.
-queuebot:#ubuntu-release- Unapproved: accepted xorg-hwe-16.04 [source] (xenial-proposed) [1:7.7+13ubuntu4~16.04.2]
<ginggs> cjwatson, infinity: have you seen my mail about ubuntu-archive?
-queuebot:#ubuntu-release- Unapproved: systemd (trusty-proposed/main) [204-5ubuntu20.22 => 204-5ubuntu20.23] (core)
<fossfreedom_> cyphermox: Hi - next time you are in the ubiquity space (hopefully soon) - please can you consider our (Ubuntu Budgie) merge proposal?  TIA - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1659280
<ubot5> Ubuntu bug 1659280 in ubiquity (Ubuntu) "ubuntu budgie does not display a background wallpaper nor window decorations" [Undecided,In progress]
-queuebot:#ubuntu-release- Unapproved: appstream (yakkety-backports/main) [0.10.1-1 => 0.10.6-1~ubuntu16.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: appstream (xenial-backports/main) [0.10.1-1~ubuntu16.04.1 => 0.10.6-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted appstream [source] (yakkety-backports) [0.10.6-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted appstream [source] (xenial-backports) [0.10.6-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: appstream [amd64] (yakkety-backports/main) [0.10.6-1~ubuntu16.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [ppc64el] (yakkety-backports/main) [0.10.6-1~ubuntu16.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [arm64] (yakkety-backports/main) [0.10.6-1~ubuntu16.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [i386] (yakkety-backports/main) [0.10.6-1~ubuntu16.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [armhf] (yakkety-backports/main) [0.10.6-1~ubuntu16.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [s390x] (yakkety-backports/main) [0.10.6-1~ubuntu16.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [amd64] (xenial-backports/main) [0.10.6-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [i386] (xenial-backports/main) [0.10.6-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [powerpc] (yakkety-backports/main) [0.10.6-1~ubuntu16.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [arm64] (xenial-backports/main) [0.10.6-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [ppc64el] (xenial-backports/main) [0.10.6-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [armhf] (xenial-backports/main) [0.10.6-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [powerpc] (xenial-backports/main) [0.10.6-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [s390x] (xenial-backports/main) [0.10.6-1~ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted appstream [amd64] (xenial-backports) [0.10.6-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted appstream [armhf] (xenial-backports) [0.10.6-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted appstream [powerpc] (xenial-backports) [0.10.6-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted appstream [s390x] (xenial-backports) [0.10.6-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted appstream [arm64] (yakkety-backports) [0.10.6-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted appstream [i386] (yakkety-backports) [0.10.6-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted appstream [ppc64el] (yakkety-backports) [0.10.6-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted appstream [arm64] (xenial-backports) [0.10.6-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted appstream [ppc64el] (xenial-backports) [0.10.6-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted appstream [armhf] (yakkety-backports) [0.10.6-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted appstream [s390x] (yakkety-backports) [0.10.6-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted appstream [i386] (xenial-backports) [0.10.6-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted appstream [powerpc] (yakkety-backports) [0.10.6-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted appstream [amd64] (yakkety-backports) [0.10.6-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: libscrypt (trusty-proposed/universe) [1-2ubuntu2 => 1-2ubuntu2.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (xenial-proposed) [1.108ubuntu15.3]
-queuebot:#ubuntu-release- New: accepted qm-dsp [amd64] (zesty-proposed) [1.7.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qm-dsp [armhf] (zesty-proposed) [1.7.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qm-dsp [powerpc] (zesty-proposed) [1.7.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qm-dsp [s390x] (zesty-proposed) [1.7.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qm-dsp [arm64] (zesty-proposed) [1.7.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qm-dsp [ppc64el] (zesty-proposed) [1.7.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qm-dsp [i386] (zesty-proposed) [1.7.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-golang-leveldb [sync] (zesty-proposed) [0.0~git20161231.0.3435554-1]
-queuebot:#ubuntu-release- New: accepted libopenshot [sync] (zesty-proposed) [0.1.2+ds1-1]
-queuebot:#ubuntu-release- New: accepted rekall [sync] (zesty-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [sync] (zesty-proposed) [0.1.2+ds1-1]
-queuebot:#ubuntu-release- New: accepted skysentials [sync] (zesty-proposed) [1.0.1-5]
-queuebot:#ubuntu-release- New: accepted libstaroffice [sync] (zesty-proposed) [0.0.2-3]
-queuebot:#ubuntu-release- New: accepted panko [amd64] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected python-os-xenapi [source] (zesty-proposed) [0.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-github-golang-leveldb [amd64] (zesty-proposed/none) [0.0~git20161231.0.3435554-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skysentials [amd64] (zesty-proposed/none) [1.0.1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rekall [amd64] (zesty-proposed/none) [1.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libstaroffice [ppc64el] (zesty-proposed/none) [0.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libstaroffice [s390x] (zesty-proposed/none) [0.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libstaroffice [i386] (zesty-proposed/none) [0.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libstaroffice [powerpc] (zesty-proposed/none) [0.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libstaroffice [arm64] (zesty-proposed/none) [0.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libstaroffice [armhf] (zesty-proposed/none) [0.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-marathon [source] (zesty-proposed) [0.8.10-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-golang-leveldb [amd64] (zesty-proposed) [0.0~git20161231.0.3435554-1]
-queuebot:#ubuntu-release- New: accepted skysentials [amd64] (zesty-proposed) [1.0.1-5]
-queuebot:#ubuntu-release- New: accepted rekall [amd64] (zesty-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: libstaroffice [amd64] (zesty-proposed/none) [0.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-marathon [amd64] (zesty-proposed/none) [0.8.10-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libstaroffice [amd64] (zesty-proposed) [0.0.2-3]
-queuebot:#ubuntu-release- New: accepted libstaroffice [armhf] (zesty-proposed) [0.0.2-3]
-queuebot:#ubuntu-release- New: accepted libstaroffice [powerpc] (zesty-proposed) [0.0.2-3]
-queuebot:#ubuntu-release- New: accepted libstaroffice [s390x] (zesty-proposed) [0.0.2-3]
-queuebot:#ubuntu-release- New: accepted python-tinyrpc [source] (zesty-proposed) [0.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libstaroffice [arm64] (zesty-proposed) [0.0.2-3]
-queuebot:#ubuntu-release- New: accepted libstaroffice [ppc64el] (zesty-proposed) [0.0.2-3]
-queuebot:#ubuntu-release- New: accepted libstaroffice [i386] (zesty-proposed) [0.0.2-3]
-queuebot:#ubuntu-release- New: accepted python-marathon [amd64] (zesty-proposed) [0.8.10-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-tinyrpc [amd64] (zesty-proposed/none) [0.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-os-xenapi [source] (zesty-proposed) [0.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-tinyrpc [amd64] (zesty-proposed) [0.5-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-os-xenapi [amd64] (zesty-proposed/universe) [0.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-os-xenapi [amd64] (zesty-proposed) [0.1.1-0ubuntu1]
<rbasak> RAOF or RAOF1: are you working on the docker and/or cloud-init SRUs?
-queuebot:#ubuntu-release- New: accepted neutron-lbaas-dashboard [source] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: neutron-lbaas-dashboard [amd64] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: gce-compute-image-packages (trusty-proposed/primary) [20160930-0ubuntu3~14.04]
-queuebot:#ubuntu-release- New binary: pldebugger [ppc64el] (zesty-proposed/none) [9.5.0-10-gd663a19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cycle-quotes [amd64] (zesty-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-openwith [amd64] (zesty-proposed/none) [0.8g-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-world-time-mode [amd64] (zesty-proposed/none) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pldebugger [armhf] (zesty-proposed/none) [9.5.0-10-gd663a19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-bind-map [amd64] (zesty-proposed/none) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pldebugger [arm64] (zesty-proposed/none) [9.5.0-10-gd663a19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-smeargle [amd64] (zesty-proposed/none) [0.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnsdiag [amd64] (zesty-proposed/none) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hungry-delete-el [amd64] (zesty-proposed/none) [1.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pldebugger [i386] (zesty-proposed/none) [9.5.0-10-gd663a19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pldebugger [s390x] (zesty-proposed/none) [9.5.0-10-gd663a19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-signet [amd64] (zesty-proposed/none) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-nebulouslabs-go-upnp [amd64] (zesty-proposed/none) [0.0~git20160920.0.73e8530-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pldebugger [powerpc] (zesty-proposed/none) [9.5.0-10-gd663a19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tendermint-go-autofile [amd64] (zesty-proposed/none) [0.0~20170129~0git48b17de-1] (no packageset)
-queuebot:#ubuntu-release- New binary: paredit-everywhere [amd64] (zesty-proposed/none) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pointback [amd64] (zesty-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdist-zilla-plugin-readmefrompod-perl [amd64] (zesty-proposed/none) [0.35-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pldebugger [amd64] (zesty-proposed/none) [9.5.0-10-gd663a19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: visual-regexp-el [amd64] (zesty-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: parent-mode-el [amd64] (zesty-proposed/none) [2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rainbow-identifiers-el [amd64] (zesty-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod-weaver-plugin-ensureuniquesections-perl [amd64] (zesty-proposed/none) [0.163250-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-testfixtures [amd64] (zesty-proposed/none) [4.13.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod-weaver-section-contributors-perl [amd64] (zesty-proposed/none) [0.009-1] (no packageset)
<philroche> Hi, would anyone be able to do accept gce-compute-image-packages in to trusty-proposed? This is a new package and exists in zesty, yakkety and xenial already. lp bug - https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1643585 Package in upload queue - https://launchpad.net/ubuntu/trusty/+queue?queue_state=0&queue_text=gce-compute-image-packages.
<ubot5> Ubuntu bug 1643585 in gce-compute-image-packages (Ubuntu Trusty) "Backporting gce-compute-image-packages " [Undecided,New]
-queuebot:#ubuntu-release- New binary: highlight-numbers-el [amd64] (zesty-proposed/none) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdist-zilla-plugin-mojibaketests-perl [amd64] (zesty-proposed/none) [0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: stenographer [amd64] (zesty-proposed/universe) [0.0~git20161206.0.66a8e7e-4] (no packageset)
-queuebot:#ubuntu-release- New binary: stenographer [ppc64el] (zesty-proposed/universe) [0.0~git20161206.0.66a8e7e-4] (no packageset)
-queuebot:#ubuntu-release- New binary: stenographer [i386] (zesty-proposed/universe) [0.0~git20161206.0.66a8e7e-4] (no packageset)
-queuebot:#ubuntu-release- New binary: stenographer [s390x] (zesty-proposed/universe) [0.0~git20161206.0.66a8e7e-4] (no packageset)
-queuebot:#ubuntu-release- New binary: stenographer [powerpc] (zesty-proposed/universe) [0.0~git20161206.0.66a8e7e-4] (no packageset)
-queuebot:#ubuntu-release- New binary: stenographer [arm64] (zesty-proposed/universe) [0.0~git20161206.0.66a8e7e-4] (no packageset)
-queuebot:#ubuntu-release- New binary: stenographer [armhf] (zesty-proposed/universe) [0.0~git20161206.0.66a8e7e-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.22 => 2.22.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.22+16.10 => 2.22.1+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.22~14.04 => 2.22.1~14.04] (no packageset)
<acheronuk> Could someone please take a look at the new sources in the queue for KDE applications 16.12.1? uploaded just over a week ago. thanks
<camako> Hello, any core devs around who can publish ticket #2369 for me?
<flocculant> cyphermox: had time to track back on that os-prober - lp version definitely fails, went to grab the debian one - that's now at 1.74 - grabbed that and it works
<cyphermox> lp version 1.73ubuntu3?
<flocculant> cyphermox: yea - that doesn't work
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.22.1+16.10]
<flocculant> you probably missed the ping from ~11 hours ago
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.22.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.22.1~14.04]
<cyphermox> flocculant: ack. well, in that case I still have no clue what might be wrong
<cyphermox> cjwatson: halp, if you have time, would be good to have a second set of eyes to make sure
<cyphermox> in 1.73ubuntu3 I see nothing relevant that would cause bug 1660159
<ubot5> bug 1660159 in os-prober (Ubuntu Zesty) "os-prober fails to see other installed systems" [Undecided,Fix released] https://launchpad.net/bugs/1660159
<flocculant> cyphermox: ok  - confirmed here that 1.74 works as did 1.73 from Debian yesterday
<cyphermox> yeah, no surprises there
<flocculant> :)
<clivejo> cyphermox: can you please run the Kubuntu seed script?
<cyphermox> clivejo: I will get to it soon
<clivejo> also is there any chance those new KDE packages can be looked at by an AA please?
<clivejo> they are just NEW packages which have been split upstream from kde-baseapps
<mwhudson> jgrimm, xnox: so er should we test the docker from x-proposed on s390x this time?
<jgrimm> mwhudson, hmmm... seems reasonable
<mwhudson> also arm64 i guess
<mwhudson> jgrimm: i did test the zesty packages on s390x so i'd be surprised by it breaking but even so
<mwhudson> jgrimm: i don't think i have access to any s390x xenial instances
<infinity> mwhudson: Unless you're concerned about kernel interactions, xenial is just a debootstrap away.
<mwhudson> infinity: docker works in a chroot?
<infinity> Why wouldn't it?
<mwhudson> well let's find out
<jgrimm> howdy, would anyone be able to release curtin from xenial-proposed
<jgrimm> rbasak, just in case still on SRU duty^^ :)
<mwhudson> hm no can't make it work
<rbasak> jgrimm: done
<jgrimm> rbasak thanks!!
<slangasek> camako: done
<camako> slangasek, thanks
<RAOF> rbasak: I believe I did all the docker SRU bits; I did not do cloud-init.
-queuebot:#ubuntu-release- New binary: breeze-icons [amd64] (zesty-proposed/universe) [4:5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: ksyntax-highlighting [amd64] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
<rbasak> RAOF: thanks. I'm not really sure how to review cloud-init fwiw.
<rbasak> I feel that we should have a single documentation page for anything that isn't a traditional-style SRU.
<RAOF> rbasak: Neither was I :)
<rbasak> So we can coordinate our expectations, what test plans have been approved, etc.
<RAOF> They apparently don't actually *have* an approved test plan.
<rbasak> slangasek, infinity: ^ opinions? In addition to cloud-init specifically, I'd like some guidance on how to determine what is OK under the new "new feature" exception. Do we need a process for ~ubuntu-sru to review and document "exceptions" now that they don't need the TB
<rbasak> ?
#ubuntu-release 2017-02-02
<tsimonq2> Someone needs to fix this: bad-distribution-in-changes-file zesty
<tsimonq2> I know Colin put it in upstream Lintian
<tsimonq2> But if someone could cherry pick, that would be wonderful
<cyphermox> tsimonq2: I have some related changes in progress
<cyphermox> should upload tomorrow
<tsimonq2> cyphermox: Thanks. :)
<cyphermox> fwiw it's not Colin's lintian changes, but instead devscripts which insists on setting "yakkety" when you dch -r still.
<cyphermox> I can look at lintian tomorrow too though :)
<tsimonq2> Ohhhh ok
<tsimonq2> cyphermox: Wait really?
<tsimonq2> But I don't dch -r, I manually pop open changelogs :P
<cyphermox> not the first time I hear that; I'm mostly scratching my own itch after it bug me for a while
<cyphermox> and caught some gpg issue in the process
<tsimonq2> How could GPG be caught in this? O__o
-queuebot:#ubuntu-release- Packageset: 134 entries have been added or removed
<ginggs> apw: would you please add 'force-badtest ocrmypdf/4.3.5-2/s390x' to your hints?
<ginggs> and 'force-badtest freecad/0.16+dfsg2-3/ppc64el freecad/0.16+dfsg2-3/s390x' in p.itti's hints
<mapreri> ocrmypdf is still broken on s390x?
 * mapreri points its maintainer to it
<ginggs> mapreri: i think its actually liblept5
<mapreri> yeah, but I remember clearly helping him with some s390x issue, so I was surprised.  And I'm confident he will fix it
<ginggs> mapreri: and there's debian bug #849094
<ubot5> Debian bug 849094 in liblept5 "liblept5: Broken on s390x (+ other big endian archs)" [Normal,Open] http://bugs.debian.org/849094
<mapreri> right, which is open by Sean
<mapreri> oh, it's that very one thing, ok
<mapreri> somehow I believed that was long fixed, but it has been just a bit more than one month
<acheronuk> Hi. Can someone please review and accept our sources in the NEW queue please? they are needed before we can our packageset refresh done.
<acheronuk> namely minuet, konqueror, kommander, klinkstatus, kimagemapeditor,kfind, kfilereplace, keditbookmarks, kdialog
<acheronuk> thanks
<acheronuk> most of those are actually OLD packages, but KDE have now split the sources
<acheronuk> .
<acheronuk> minuet is part of the full KDE applications 16.04.0 release that we were unable to get into yakkety, due to not have some build depends for it in the archive
<acheronuk> see: https://www.kde.org/announcements/announce-applications-16.04.0.php
<acheronuk> in 16.12 KDE app we are now doing...
<acheronuk> kde-baseapps (split into kdialog, keditbookmarks, kfind, konqueror)
<acheronuk> kdewebdev (split into kfilereplace, kimagemapeditor, klinkstatus, kommander)
<acheronuk> hence these are nothing new per se. just split and some ported to KF5
<acheronuk> see: https://community.kde.org/Applications/16.12_Release_Notes#Tarballs_that_we_have_split
<acheronuk> .
<acheronuk> also ref Lukasz Zemczak needing those sources accept before he can do our refresh
<acheronuk> see: https://lists.ubuntu.com/archives/devel-permissions/2017-February/001026.html
<acheronuk> apw: maybe ^^
<acheronuk> I hate to nag you, as you've helped a lot recently :/
<acheronuk> but we are a bit stuck with some of the stuff the lack of this refresh is holding back
<acheronuk> or anyone else really :)
-queuebot:#ubuntu-release- Unapproved: systemd (trusty-proposed/main) [204-5ubuntu20.22 => 204-5ubuntu20.24] (core)
<acheronuk> sil2100: as you requested in your email in reply to us ^^^^
-queuebot:#ubuntu-release- New: accepted stenographer [arm64] (zesty-proposed) [0.0~git20161206.0.66a8e7e-4]
-queuebot:#ubuntu-release- New: accepted stenographer [i386] (zesty-proposed) [0.0~git20161206.0.66a8e7e-4]
-queuebot:#ubuntu-release- New: accepted stenographer [s390x] (zesty-proposed) [0.0~git20161206.0.66a8e7e-4]
-queuebot:#ubuntu-release- New: accepted stenographer [armhf] (zesty-proposed) [0.0~git20161206.0.66a8e7e-4]
-queuebot:#ubuntu-release- New: accepted stenographer [powerpc] (zesty-proposed) [0.0~git20161206.0.66a8e7e-4]
-queuebot:#ubuntu-release- New: accepted cycle-quotes [amd64] (zesty-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted emacs-bind-map [amd64] (zesty-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted emacs-smeargle [amd64] (zesty-proposed) [0.03-1]
-queuebot:#ubuntu-release- New: accepted golang-github-nebulouslabs-go-upnp [amd64] (zesty-proposed) [0.0~git20160920.0.73e8530-1]
-queuebot:#ubuntu-release- New: accepted hungry-delete-el [amd64] (zesty-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted libdist-zilla-plugin-readmefrompod-perl [amd64] (zesty-proposed) [0.35-1]
-queuebot:#ubuntu-release- New: accepted libpod-weaver-section-contributors-perl [amd64] (zesty-proposed) [0.009-1]
-queuebot:#ubuntu-release- New: accepted parent-mode-el [amd64] (zesty-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted pldebugger [arm64] (zesty-proposed) [9.5.0-10-gd663a19-1]
-queuebot:#ubuntu-release- New: accepted pldebugger [i386] (zesty-proposed) [9.5.0-10-gd663a19-1]
-queuebot:#ubuntu-release- New: accepted dnsdiag [amd64] (zesty-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted emacs-world-time-mode [amd64] (zesty-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted libdist-zilla-plugin-mojibaketests-perl [amd64] (zesty-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted paredit-everywhere [amd64] (zesty-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted pldebugger [armhf] (zesty-proposed) [9.5.0-10-gd663a19-1]
-queuebot:#ubuntu-release- New: accepted pldebugger [ppc64el] (zesty-proposed) [9.5.0-10-gd663a19-1]
-queuebot:#ubuntu-release- New: accepted pointback [amd64] (zesty-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted rainbow-identifiers-el [amd64] (zesty-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted stenographer [amd64] (zesty-proposed) [0.0~git20161206.0.66a8e7e-4]
-queuebot:#ubuntu-release- New: accepted tendermint-go-autofile [amd64] (zesty-proposed) [0.0~20170129~0git48b17de-1]
-queuebot:#ubuntu-release- New: accepted emacs-openwith [amd64] (zesty-proposed) [0.8g-1]
-queuebot:#ubuntu-release- New: accepted libpod-weaver-plugin-ensureuniquesections-perl [amd64] (zesty-proposed) [0.163250-1]
-queuebot:#ubuntu-release- New: accepted pldebugger [powerpc] (zesty-proposed) [9.5.0-10-gd663a19-1]
-queuebot:#ubuntu-release- New: accepted python-testfixtures [amd64] (zesty-proposed) [4.13.3-1]
-queuebot:#ubuntu-release- New: accepted stenographer [ppc64el] (zesty-proposed) [0.0~git20161206.0.66a8e7e-4]
-queuebot:#ubuntu-release- New: accepted highlight-numbers-el [amd64] (zesty-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted pldebugger [s390x] (zesty-proposed) [9.5.0-10-gd663a19-1]
-queuebot:#ubuntu-release- New: accepted visual-regexp-el [amd64] (zesty-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted pldebugger [amd64] (zesty-proposed) [9.5.0-10-gd663a19-1]
-queuebot:#ubuntu-release- New: accepted ruby-signet [amd64] (zesty-proposed) [0.7.3-1]
<luna_> 16.4.2 today ?
<xnox> luna_, nope.
<xnox> see emails about another one week extension
<sil2100> seb128, cjwatson, slangasek: hey! Anyone of you could maybe take a look at the kubuntu packages in the zesty NEW queue as mentioned above? ^
<acheronuk> ksyntax-highlighting is also needed, as that blocks any new plasma-desktop/workspace release or uploas
<acheronuk> thx :)
<rbasak> clivejo: IMHO, you should send that email to ubuntu-devel@. There are archive admins and other sponsors on there who may be able to help, who probably don't watch devel-permissions@
<rbasak> clivejo: also, you should go there if you don't get anywhere on IRC when you're blocked by any team really, again IMHO, before you get frustrated. Requests on IRC tend to scroll past.
<clivejo> rbasak: I don't know who to send it to.  I was lead to believe that this was the place to ask
<rbasak> clivejo: to ubuntu-devel@lists.ubuntu.com.
<rbasak> This is certainly the right place to ask in the first instance for realtime requests.
<rbasak> But do fall back to the mailing list. IRC is too ephemeral to expect things to happen if people miss the window where it would be visible on their screens.
<clivejo> I have trouble expressing myself in emails, what do I ask?
<clivejo> from my POV, our packages are added to a "queue" which would suggest they would be processed in order of when added, but I see newer packages jumping the queue and our sitting there for ages
<clivejo> both acheronuk and I have asked here on several occasions, at different times of the day and never get a reply
<clivejo> are we missing something, not following a process?
<rbasak> clivejo: we have no rule that says that the queues have to be processed in order. Just as we don't get to tell you what to do first either.
<sil2100> No, I guess you're following the process right
<rbasak> clivejo: just point out that you've been asking on IRC, that your stuff has been stuck in queue X for Y days, and please could an archive admin take a look.
<xnox> clivejo, things that "jump" the queues are usually urgent (security issues) or simple (trivial soname renames / package resplits)
<xnox> it's not a straight forward first in first one, since items are not of the same complexity.
<clivejo> xnox, most of ours are simple package splits
<sil2100> It's just that there's not too many archive admins around, so sometimes they don't have time to handle packages in the queue if not requested explicitly
<sil2100> Let's have a bit more patience, maybe slangasek or infinity can help
<clivejo> is the seed refresh script resource intensive?
<rbasak> clivejo: consider an email to ubuntu-devel@ as the escalation part of the process if you can't find someone on IRC and if your items have been languishing in the queue.
<clivejo> basically, by running it now it would remove the barrier to uploading a few packages
<rbasak> clivejo: there are people who may be able to make things happen, but right now they don't even know this.
<acheronuk> hi. sorry to moan or seem ungrateful. just trying to avoid situations like we had with yakkety (not Queue/permission issues) where we had to groups of several hundred packages through on FFE's etc
<acheronuk> for zesty in terms of getting things ready, we are better placed (KDE PIM aside). but are a bit blocked on this other stuff.
<clivejo> acheronuk: would you email ubuntu-devel@, I'm afraid I don't have the time, energy or patiences at the moment
-queuebot:#ubuntu-release- Unapproved: linux-signed-lts-xenial (trusty-proposed/main) [4.4.0-62.83~14.04.1 => 4.4.0-63.84~14.04.1] (kernel)
<flocculant> cyphermox: would ubiquity not recognising that a disk has an installed system when live boots be part of the os-prober issue?
-queuebot:#ubuntu-release- New binary: libopenshot-audio [ppc64el] (zesty-proposed/universe) [0.1.2+ds1-1ubuntu1] (no packageset)
 * flocculant hopes it is - or there is an issue with that ...
<cyphermox> probably not, but I suppose that depends on what you mean by that
<flocculant> I mean this http://i.imgur.com/7gXtWLf.png
<flocculant> I just installed xubuntu to that drive - rebooted to test alongside - and it doesn't see the installed system
<xnox> flocculant, is the disk big enough for two installations?
-queuebot:#ubuntu-release- New binary: libopenshot-audio [armhf] (zesty-proposed/universe) [0.1.2+ds1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [i386] (zesty-proposed/universe) [0.1.2+ds1-1ubuntu1] (no packageset)
<xnox> flocculant, can you extract logs from that live sessions to look into things?
<flocculant> xnox: 20Gb should be more than enough for 2 xubuntu's
<xnox> (e.g. use try session, start installer, then do ubuntu-bug ubiquity whilst ubiquity is at that step)
<xnox> i don't think so.
<flocculant> doing something else currently - can do that of course
-queuebot:#ubuntu-release- New binary: libopenshot-audio [arm64] (zesty-proposed/universe) [0.1.2+ds1-1ubuntu1] (no packageset)
<xnox> we have static sizing, with room for user data, which I thought was more than 10GB and thus 20GB is not enough for side by side installations.
<flocculant> oh
<xnox> it's pointless to install a system, which then has zero disk space left for user data & media =)
<flocculant> xnox: yea - xubuntu installs to ~6.5Gb at the moment
<flocculant> and yea of course
-queuebot:#ubuntu-release- New binary: libopenshot-audio [s390x] (zesty-proposed/universe) [0.1.2+ds1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [powerpc] (zesty-proposed/universe) [0.1.2+ds1-1ubuntu1] (no packageset)
 * flocculant will return 
-queuebot:#ubuntu-release- New binary: bedops [ppc64el] (zesty-proposed/universe) [2.4.20+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [amd64] (zesty-proposed/universe) [0.1.2+ds1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bedops [amd64] (zesty-proposed/universe) [2.4.20+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bedops [i386] (zesty-proposed/universe) [2.4.20+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bedops [s390x] (zesty-proposed/universe) [2.4.20+dfsg-1ubuntu1] (no packageset)
<smb> Could someone (AA) reject linux-signed-lts-xenial (4.4.0-63.84~14.04.1) from the accept queue of trusty please
-queuebot:#ubuntu-release- New binary: bedops [arm64] (zesty-proposed/universe) [2.4.20+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bedops [powerpc] (zesty-proposed/universe) [2.4.20+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bedops [armhf] (zesty-proposed/universe) [2.4.20+dfsg-1ubuntu1] (no packageset)
<smb> cyphermox, ^ can you reject?
<cyphermox> smb: sorry, not archive admin.
<smb> cyphermox, ah darn. but thanks
<cyphermox> infinity: slangasek: apw: ^
<smb> cyphermox, Andy unlikely (today)
<flocculant> xnox: bug 1661278
<ubot5> bug 1661278 in ubiquity (Ubuntu) "Install 17.04 alongside unavailable on 25Gb drive" [Undecided,New] https://launchpad.net/bugs/1661278
<cyphermox> flocculant: ta
<flocculant> cyphermox: welcome asl always
<flocculant> btw I did on the same hdd try with 16.10 which let me do what I wanted to
<smb> sil2100, Could you reject linux-signed-lts-xenial (4.4.0-63.84~14.04.1) from the accept queue of trusty please
<flocculant> xnox: so that does tend to suggest it'll be ok when os-prober is?
<sil2100> smb: you mean from the Unapproved queue, right?
<infinity> smb: Gone.
<smb> sil2100, I probably meant, yes.
<smb> sil2100, infinity ok thanks
<sil2100> ...aaand infinity just did it ;)
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed-lts-xenial [source] (trusty-proposed) [4.4.0-63.84~14.04.1]
<smb> sil2100, yes sorry did not realize he was already on it
<acheronuk> sil2100: our packageset apparently got partially refreshed (still needs the ones in the new queue), but the source 'prison-kf5' somehow escaped the update
<flocculant> xnox: ignore me - I proved it to myself by installing a different os-prober ...
<sil2100> acheronuk: oh, it did?
<sil2100> acheronuk: didn't know someone else was on it as well, my scripts are still running in the background
<sil2100> rbasak: did you update the packageset for kubuntu?
<acheronuk> sil2100: from our devel channel [14:40] <cyphermox> clivejo: packageset is updated.
<sil2100> Ah, ok
<cyphermox> sil2100: sorry, you were running the packageset magic in the background?
<rbasak> sil2100: no, I didn't touch it.
<cyphermox> it's terrible that it takes so long to run
<rbasak> It's germinate that takes the time.
<acheronuk> sil2100: but missed 'prison-kf5' source name, and obviously the NEW queue ones
<rbasak> I wonder if there's a more central one we could use instead, like from the main germinate run or something
<sil2100> cyphermox: yeah, I mentioned it briefly on the dmb channel, but I actually started the script like 30 minutes ago
<cyphermox> yeah
<sil2100> Anyway, no big deal here, didn't waste any time actually
<clivejo> ah sil2100, you are Lukasz !
<sil2100> clivejo: yes!
<clivejo> didn't realise
<cyphermox> acheronuk: this is because prison-kf5 doesn't exist in your seed.
<cyphermox> (and neither do the new sources, but that's expected)
<clivejo> cyphermox: http://bazaar.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu.zesty/view/head:/supported#L258
<acheronuk> cyphermox: it's libkf5prison-dev is there
<acheronuk> so the source that belongs to should have been added
<cyphermox> ah, I see now
<cyphermox> yeah, but the timing may be a little wrong, I ran the script a little before that addition happened
<cyphermox> (or maybe a little after, but before the seeds were updated on p.u.c)
<cyphermox> assuming that's where we get the seeds for that script, I haven't checked.
<clivejo> that would explain why prison is in our package and prison-kf5 isn't
<clivejo> https://launchpad.net/ubuntu/+source/prison is the old KDE4 version I believe
<acheronuk> clivejo: but you updated our seed in one revision did you not?
<clivejo> I did
<acheronuk> so if the others went in ok, so should prison-kf5
<acheronuk> prison-kf5 wasn't added later
<cyphermox> acheronuk: there's some more process involved in updating the seed when dealing with packagesets; germinate by default goes to see a webpage which is not updated instantly.
<acheronuk> these things are rarely as simple as they seem.
<acheronuk> prison-kf5 is now part of the official KDE frameworks, and is needed for QR code etc support in out plasma desktop
<acheronuk> an old version with the same source and library names exists, but is not new enough
<cyphermox> I'll re-run this later as I try to automate it, so it's good if there are some changes that wil lshow up
<acheronuk> cyphermox: yeah, there are  few more missing as I look at it, but see if the re-run catches them :)
<acheronuk> I shall go and make even more new stuff to add ;)
 * acheronuk runs
-queuebot:#ubuntu-release- New: accepted bedops [amd64] (zesty-proposed) [2.4.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bedops [armhf] (zesty-proposed) [2.4.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bedops [powerpc] (zesty-proposed) [2.4.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bedops [s390x] (zesty-proposed) [2.4.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bedops [arm64] (zesty-proposed) [2.4.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bedops [ppc64el] (zesty-proposed) [2.4.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bedops [i386] (zesty-proposed) [2.4.20+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [amd64] (zesty-proposed) [0.1.2+ds1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [armhf] (zesty-proposed) [0.1.2+ds1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [powerpc] (zesty-proposed) [0.1.2+ds1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [s390x] (zesty-proposed) [0.1.2+ds1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [arm64] (zesty-proposed) [0.1.2+ds1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [ppc64el] (zesty-proposed) [0.1.2+ds1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [i386] (zesty-proposed) [0.1.2+ds1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted breeze-icons [amd64] (zesty-proposed) [4:5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted neutron-lbaas-dashboard [amd64] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ksyntax-highlighting [amd64] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-murano-pkg-check [source] (zesty-proposed) [0.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-murano-pkg-check [amd64] (zesty-proposed/none) [0.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-murano-pkg-check [amd64] (zesty-proposed) [0.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kdeclarative [ppc64el] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: knewstuff [ppc64el] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdeclarative [amd64] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: knewstuff [amd64] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: knewstuff [arm64] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdeclarative [armhf] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdeclarative [i386] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: knewstuff [i386] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdeclarative [powerpc] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdeclarative [s390x] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: knewstuff [powerpc] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: knewstuff [s390x] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: knewstuff [armhf] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdeclarative [arm64] (zesty-proposed/universe) [5.30.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [7.11.90.20161005-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (yakkety-proposed) [0.29-1ubuntu16.2]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.22.1~14.04 => 2.22.2~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.22.1 => 2.22.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.22.1+16.10 => 2.22.2+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libopenshot [i386] (zesty-proposed/universe) [0.1.2+ds1-1] (no packageset)
<sergiusens> bdmurray: (or backup slangasek) mind letting snapcraft into xenial-updates and yakkety-updates?
<clivejo> is there any way to retry regressions with all-proposed=1 en masse?
<slangasek> it could be scripted, but please don't.
<slangasek> unless you mean for a specific subset of related packages.
<clivejo> KDE have a batch of packages which all get uploaded together and many need retried with &all-proposed=1 appended to the URL
<slangasek> right, so you could do some scripting around retry-autopkgtest-regressions --all-proposed to only trigger those that belong to the set
<clivejo> for example Frameworks 5.30 are in proposed at the moment
<clivejo> I'm poking them on as best I can, but its a very boring job!
-queuebot:#ubuntu-release- New binary: libopenshot [i386] (zesty-proposed/universe) [0.1.2+ds1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot [amd64] (zesty-proposed/universe) [0.1.2+ds1-3] (no packageset)
<mightyiam> Hey, release team. Maybe consider fixing bug #1656620 prior to 16.04. Terrible discoloration on open source radeon driver. Not sure scope of hardware.
<ubot5> bug 1656620 in Mesa "Discoloration in some XFCE icons and window borders" [Medium,Confirmed] https://launchpad.net/bugs/1656620
-queuebot:#ubuntu-release- Unapproved: rejected gnome-calculator [source] (yakkety-proposed) [1:3.22.2-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted sudo [source] (yakkety-proposed) [1.8.16-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: rejected ddtp-translations [source] (yakkety-proposed) [20170127.1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-application [sync] (yakkety-proposed) [12.10.1+16.10.20170120-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-application [sync] (xenial-proposed) [12.10.1+16.04.20170120-0ubuntu1]
<sergiusens> slangasek, falling back to you, mind letting snapcraft into xenial-updates and yakkety-updates?
<slangasek> sergiusens: looking
<sergiusens> thanks
-queuebot:#ubuntu-release- Unapproved: accepted netcfg [source] (xenial-proposed) [1.135ubuntu4.2]
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (xenial-proposed) [1:2.0.0-0ubuntu1.1]
#ubuntu-release 2017-02-03
-queuebot:#ubuntu-release- Unapproved: xorg-server-lts-xenial (trusty-proposed/main) [2:1.18.3-1ubuntu2.2~trusty3 => 2:1.18.3-1ubuntu2.3~trusty1] (no packageset)
-queuebot:#ubuntu-release- New: accepted graphene [source] (zesty-proposed) [1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-os-brick (xenial-proposed/main) [1.2.0-2ubuntu0.1 => 1.2.0-2ubuntu0.2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: graphene [ppc64el] (zesty-proposed/universe) [1.5.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [amd64] (zesty-proposed/universe) [1.5.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [s390x] (zesty-proposed/universe) [1.5.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-lts-xenial [source] (trusty-proposed) [2:1.18.3-1ubuntu2.3~trusty1]
-queuebot:#ubuntu-release- New binary: graphene [arm64] (zesty-proposed/universe) [1.5.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [powerpc] (zesty-proposed/universe) [1.5.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-os-brick (yakkety-proposed/main) [1.6.1-0ubuntu1 => 1.6.1-0ubuntu1.1] (openstack, ubuntu-server)
<tjaalton> slangasek: what happened to xorg-server-lts-xenial? 1.18.4 was already pretty much verified but it got replaced with an older version?
<slangasek> tjaalton: there were a significant number of bugs linked from the changelog which had not been verified; I was discussing it with bdmurray because this was blocking fixing snapd installability on the desktop, and as we couldn't see any immediate path to getting this one verified to his satisfaction, we decided to swap in just the packaging fixes and reupload 1.18.4 afterwards
<tjaalton> ok
<tjaalton> well
<tjaalton> I don't see anyone actually verifying all those bugs
<tjaalton> on trusty
<slangasek> then it didn't really seem to be following the SRU process?
<tjaalton> aren't these backports special?
<slangasek> tjaalton: bdmurray expressed concern about the test case in bug #1619142
<ubot5> bug 1619142 in xorg-server-lts-xenial (Ubuntu Trusty) "[MRE] Update to 1.18.4" [Undecided,Fix committed] https://launchpad.net/bugs/1619142
<slangasek> I didn't review the SRU bugs myself in any detail, I'm just the messenger here
<tjaalton> sure
<slangasek> tjaalton: anyway, the SRU had certainly stalled out already by having a bunch of other, non-verified bugs linked from the changelog / .changes file... hwe backports aren't special for that
<tjaalton> should've uploaded with just the mre/snapd bugs?
<tjaalton> in .changes
<tjaalton> that'd take care of the process ;)
<bdmurray> It wouldn't improve the test case / results in bug 1619142 though
<ubot5> bug 1619142 in xorg-server-lts-xenial (Ubuntu Trusty) "[MRE] Update to 1.18.4" [Undecided,Fix committed] https://launchpad.net/bugs/1619142
<tjaalton> that bug didn't actually have any test case when the upload was acked ;)
<tjaalton> then someone requested it yesterday and I put something
<tjaalton> added some
<philroche> Hi, would anyone be able to do accept gce-compute-image-packages in to trusty-proposed? This is a new package and exists in zesty, yakkety and xenial already. lp bug - https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1643585 Package in upload queue - https://launchpad.net/ubuntu/trusty/+queue?queue_state=0&queue_text=gce-compute-image-packages.
<ubot5> Ubuntu bug 1643585 in gce-compute-image-packages (Ubuntu Trusty) "Backporting gce-compute-image-packages " [Undecided,New]
<apw> philroche, other than the version number being inconistent with those in the other backports it looks ok
<ginggs> apw: would you please add 'force-badtest ocrmypdf/4.3.5-2/s390x' to your hints?
<ginggs> and 'force-badtest freecad/0.16+dfsg2-3/ppc64el freecad/0.16+dfsg2-3/s390x' in p.itti's hints
<philroche> apw. Updating version number now
<ginggs> apw: and lastly, please 'force-badtest python-pysam/0.10.0+ds-1ubuntu1/armhf python-pysam/0.10.0+ds-1ubuntu1/i386' - it doesn't actually build on those, not sure why its trying to run tests there
-queuebot:#ubuntu-release- New: rejected gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu3~14.04]
<apw> ^ rejecting to get a new version number
-queuebot:#ubuntu-release- New source: gce-compute-image-packages (trusty-proposed/primary) [20160930-0ubuntu3~14.04.0]
<philroche> apw: Version number for gce-compute-image-packages updated and reuploaded https://launchpad.net/ubuntu/trusty/+queue?queue_state=0&queue_text=gce-compute-image-packages
<apw> philroche, it just told me above :)
<philroche> :)
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu3~14.04.0]
<apw> philroche, ^
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [i386] (trusty-proposed/universe) [20160930-0ubuntu3~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Packageset: 160 entries have been added or removed
-queuebot:#ubuntu-release- Packageset: 111 entries have been added or removed
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.22.2+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.22.2]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.22.2~14.04]
<apw> Laney, have you seen cases where britney run tests for packages which are in depwait ?
<Laney> apw: no, but I've never looked for such a thing - you can check th elogs to see what it did
<Laney> also that's the kind of thing you could write a testcase for and then fix ;-)
<apw> Laney, :-p
<apw> ginggs, look sensible, done.
<Laney> Although I suppose it might be valid to run testsuites in the case of arch:all binaries
 * apw thinks about that ... maybe
<Laney> Maybe
<apw> it really feels if we have builds in a faliure state that we cannot know if we have what we need to run tests
<apw> we may have, but we do not know
-queuebot:#ubuntu-release- New: accepted libopenshot [i386] (zesty-proposed) [0.1.2+ds1-1]
-queuebot:#ubuntu-release- New: accepted libopenshot [i386] (zesty-proposed) [0.1.2+ds1-3]
-queuebot:#ubuntu-release- New: accepted libopenshot [amd64] (zesty-proposed) [0.1.2+ds1-3]
<Laney> Looks like in this case it used to work on those arches and then stopped with an update
<Laney> otherwise it wouldn't be a regression
<Laney> And the source does build an arch:all binary package which could be tested
-queuebot:#ubuntu-release- Packageset: Removed myspell-ku from personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Removed mythes-it from personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Removed mythes-sv from personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-adf to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-atarismall to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-ddc-uchen to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-firacode to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-go to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-liberation2 to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-ocr-b to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-oradano-mincho-gsrr to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-sambhota-tsugring to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added fonts-tiresias to personal-gunnarhj in zesty
-queuebot:#ubuntu-release- Packageset: Added hunspell-bo to personal-gunnarhj in zesty
<ginggs> apw: many thanks!
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [i386] (trusty-proposed) [20160930-0ubuntu3~14.04.0]
<acheronuk> Hi. Can someone please review and accept our sources in the NEW queue please? they are needed before we can our packageset refresh done.
<acheronuk> namely minuet, konqueror, kommander, klinkstatus, kimagemapeditor,kfind, kfilereplace, keditbookmarks, kdialog
<acheronuk> thanks
<acheronuk> most of those are actually OLD packages, but KDE have now split the sources
<acheronuk> .
<acheronuk> minuet is part of the full KDE applications 16.04.0 release that we were unable to get into yakkety, due to not have some build depends for it in the archive
<acheronuk> see: https://www.kde.org/announcements/announce-applications-16.04.0.php
<acheronuk> in 16.12 KDE app we are now doing...
<acheronuk> kde-baseapps (split into kdialog, keditbookmarks, kfind, konqueror)
<acheronuk> kdewebdev (split into kfilereplace, kimagemapeditor, klinkstatus, kommander)
<acheronuk> hence these are nothing new per se. just split and some ported to KF5
<acheronuk> see: https://community.kde.org/Applications/16.12_Release_Notes#Tarballs_that_we_have_split
<acheronuk> thanks :)
-queuebot:#ubuntu-release- Unapproved: im-config (xenial-proposed/main) [0.29-1ubuntu12.3 => 0.29-1ubuntu12.4] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.9.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.9.0-16.17]
-queuebot:#ubuntu-release- New: accepted kdeclarative [amd64] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdeclarative [armhf] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdeclarative [powerpc] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdeclarative [s390x] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdeclarative [arm64] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdeclarative [ppc64el] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdeclarative [i386] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted knewstuff [amd64] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted knewstuff [armhf] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted knewstuff [powerpc] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted knewstuff [s390x] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted knewstuff [arm64] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted knewstuff [ppc64el] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted knewstuff [i386] (zesty-proposed) [5.30.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: landscape-client (trusty-proposed/main) [14.12-0ubuntu0.14.04 => 14.12-0ubuntu4.14.04] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: graphene [ppc64el] (zesty-proposed/universe) [1.5.4-0ubuntu2] (no packageset)
<apw> acheronuk, as these new binaries are not yet in debian, do we have confirmation that debian will use the same epoch ?  we do not want to be epoching ahead of them
-queuebot:#ubuntu-release- New binary: graphene [amd64] (zesty-proposed/universe) [1.5.4-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [i386] (zesty-proposed/universe) [1.5.4-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [arm64] (zesty-proposed/universe) [1.5.4-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: im-config (xenial-proposed/main) [0.29-1ubuntu12.3 => 0.29-1ubuntu12.4] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: graphene [s390x] (zesty-proposed/universe) [1.5.4-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [powerpc] (zesty-proposed/universe) [1.5.4-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: rejected graphene [amd64] (zesty-proposed) [1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected graphene [powerpc] (zesty-proposed) [1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected graphene [s390x] (zesty-proposed) [1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected graphene [arm64] (zesty-proposed) [1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected graphene [ppc64el] (zesty-proposed) [1.5.4-0ubuntu1]
<acheronuk> apw: keditbookmarks, kdialog are genuinely not yet in debian so the epoch was dropped.
<acheronuk> the others ARE in debian, with an epoch, so we cannot drop it for those debs
<acheronuk> https://packages.debian.org/sid/konqueror
<acheronuk> https://packages.debian.org/sid/klinkstatus
<acheronuk> https://packages.debian.org/sid/kimagemapeditor
<acheronuk> https://packages.debian.org/sid/kfind
<acheronuk> https://packages.debian.org/sid/kfilereplace
<apw> acheronuk, bah why do they not show up in rmadison
<apw> oh ... there are already binary packages of those names ... right
<acheronuk> yes, so where there were not, we dropped epoch. where there was, we could not for now
<apw> i guess they cannot do anything other than what you have done
-queuebot:#ubuntu-release- Unapproved: rejected im-config [source] (xenial-proposed) [0.29-1ubuntu12.4]
-queuebot:#ubuntu-release- Unapproved: accepted im-config [source] (xenial-proposed) [0.29-1ubuntu12.4]
-queuebot:#ubuntu-release- New binary: graphene [ppc64el] (zesty-proposed/universe) [1.5.4-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.9-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: graphene [arm64] (zesty-proposed/universe) [1.5.4-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [armhf] (zesty-proposed/universe) [1.5.4-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [amd64] (zesty-proposed/universe) [1.5.4-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [s390x] (zesty-proposed/universe) [1.5.4-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [i386] (zesty-proposed/universe) [1.5.4-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [powerpc] (zesty-proposed/universe) [1.5.4-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (yakkety-proposed) [2.0.7-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (yakkety-proposed) [2.0.6-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (xenial-proposed) [2.0.6-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-proposed) [2.0.7-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted os-prober [source] (xenial-proposed) [1.70ubuntu3.3]
<apw> jbicha, are you going to fix that graphene armhf ftbfs ?
<apw> jbicha, that is intended as a query, as it is stuck in New on all other arches
<jbicha> apw: it's fixed now :) https://launchpad.net/ubuntu/+source/graphene/1.5.4-0ubuntu3
<apw> jbicha, heh
-queuebot:#ubuntu-release- New: rejected graphene [amd64] (zesty-proposed) [1.5.4-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected graphene [i386] (zesty-proposed) [1.5.4-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected graphene [ppc64el] (zesty-proposed) [1.5.4-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected graphene [arm64] (zesty-proposed) [1.5.4-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected graphene [s390x] (zesty-proposed) [1.5.4-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected graphene [powerpc] (zesty-proposed) [1.5.4-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted graphene [amd64] (zesty-proposed) [1.5.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted graphene [armhf] (zesty-proposed) [1.5.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted graphene [powerpc] (zesty-proposed) [1.5.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted graphene [s390x] (zesty-proposed) [1.5.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted graphene [arm64] (zesty-proposed) [1.5.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted graphene [ppc64el] (zesty-proposed) [1.5.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted graphene [i386] (zesty-proposed) [1.5.4-0ubuntu3]
<jbicha> thanks
<acheronuk> apw: exactly, debian will have to do the same if they want to keep those apps
<santa_> I have a question which is slightly offtopic here but I need to ask
<santa_> we got recently a new testcase added to the kio testsuite which apparently needs to access the network
<santa_> so it's failing on the official autopkgtest ubuntu infra
<apw> santa_, i believe the lxc and docker.io tests do do that kind of thing
<santa_> doing it by the book the correct solution would be adding the isolation-container restriction to the testsuite
<nacc> santa_: i believe you can specify the isolation-container restriction ... yeah :)
<santa_> however I'm concerned that this would result in the testsuite being skipped on the official infra
<santa_> so I'm wondering if it would be better to just disable the test case which access the network
<santa_> so we would get the tests running even if the official infra doesn't provide the stuff needed for isolation-container
<santa_> so the million dollar question is: does the official infra provide support for that?
<santa_> any other toughts?
<santa_> apw: thanks for the info btw
<nacc> santa_: could you break up the tests in d/t/control to have the tests that don't need network in one stanza and the one that does in another?
<nacc> santa_: not sure if that's possible or not
<apw> that indeed
<apw> though all are at least containers
<santa_> well I think i could break up the tests
<santa_> calling the cmake thing to execute the one needing network, and another one to call the remaining tests
<santa_> I would need to dig into that
<nacc> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/d/docker.io/20170201_211202_f4e3c@/log.gz seems to imply docker.io is going to the network for something ("Pulling from library/hello-world")?
<santa_> I have the impression it would be possible with enough time
<santa_> nacc: indeed
<apw> i suspect those have complex proxy management in them to make it work
<apw> as i believe all arches are network capable but needing proxy
<nacc> apw: ah good point
<nacc> santa_: yeah, i'd look at what docker.io actually has to do to make it work
<santa_> ok, I will try to dig into this if I have time
<santa_> apw, nacc: thank you very much for the info :)
-queuebot:#ubuntu-release- New: rejected snapd-glib [amd64] (zesty-proposed) [1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected snapd-glib [s390x] (zesty-proposed) [1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected snapd-glib [arm64] (zesty-proposed) [1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [amd64] (zesty-proposed) [1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [armhf] (zesty-proposed) [1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [powerpc] (zesty-proposed) [1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [s390x] (zesty-proposed) [1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [arm64] (zesty-proposed) [1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [ppc64el] (zesty-proposed) [1.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [i386] (zesty-proposed) [1.6-0ubuntu1]
<cyphermox> fossfreedom_: why does budgie-wm need to be run with --replace for ubiquity-dm? Seems wrong and likely to look bad (ie. you need this if some other WM starts, and in that case, you'll see some flickering as the first wm dies and budgie-wm starts; it looks clunky)
-queuebot:#ubuntu-release- Unapproved: flash-kernel (xenial-proposed/main) [3.0~rc.4ubuntu62.1.1 => 3.0~rc.4ubuntu62.2] (core)
-queuebot:#ubuntu-release- New sync: linux-hwe (xenial-proposed/primary) [4.8.0-35.40~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-hwe [sync] (xenial-proposed) [4.8.0-35.40~16.04.1]
-queuebot:#ubuntu-release- New sync: linux-signed-hwe (xenial-proposed/primary) [4.8.0-35.40~16.04.1]
<apw> infinity, the meta is in unstable
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [sync] (xenial-proposed) [4.8.0-35.40~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-35.40~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New sync: linux-meta-hwe (xenial-proposed/primary) [4.8.0.35.7]
-queuebot:#ubuntu-release- New: accepted linux-meta-hwe [sync] (xenial-proposed) [4.8.0.35.7]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-35.40~16.04.1]
-queuebot:#ubuntu-release- Unapproved: bind9 (trusty-proposed/main) [1:9.9.5.dfsg-3ubuntu0.11 => 1:9.9.5.dfsg-3ubuntu0.12] (core)
<lamont> tbf, ^^ the bind9 SRU was targeted at trusty-updates 4 march 2016.  /me is slow sometimes.
<infinity> lamont: Well, to be fair, you are really, really, really old, so we expect things to sometimes slip your mind.
<infinity> (Did I miss a "really"?)
<lamont> I'm not old yet.  old is totally in the mind.  and I had other things on my mind that month.
<lamont> :p
<infinity> s/month/year/
<lamont> infinity: does that mean you'll let it into proposed to percolate. :p
<lamont> I'd offer to hug you, but I'm not sure which behavior that would incent.
<lamont> doko: ever feel like you walked into the middle of a very awkward conversation?
<infinity> You can hug doko, it's cool.
<lamont> lol
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (trusty-proposed) [1:9.9.5.dfsg-3ubuntu0.12]
<lamont> ta
#ubuntu-release 2017-02-04
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-63.84] (core, kernel)
-queuebot:#ubuntu-release- New binary: kwin [ppc64el] (zesty-proposed/universe) [4:5.9.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [amd64] (zesty-proposed/universe) [4:5.9.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kwin [i386] (zesty-proposed/universe) [4:5.9.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kwin [amd64] (zesty-proposed) [4:5.9.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [ppc64el] (zesty-proposed) [4:5.9.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwin [i386] (zesty-proposed) [4:5.9.0-0ubuntu1]
<fossfreedom_> cyphermos: yeah - you are correct - budgie-wm doesnt need --replace to start.  I've done some more testing and all is well with the removal of --replace.  I've updated my ubiquity branch and merged in the latest changes in the parent - https://code.launchpad.net/~fossfreedom/ubiquity/lp1659280
<fossfreedom_> cyphermox: ^^^ would be helpful if I can actually type!
-queuebot:#ubuntu-release- New binary: python-neovim [amd64] (zesty-proposed/none) [0.1.13-1] (no packageset)
#ubuntu-release 2017-02-05
<jbicha> archive admins, please add linux-signed to the sync blacklist, Debian now has a newer version in experimental, bug 1621217
<ubot5> bug 1621217 in linux-signed (Ubuntu) "Please add linux-signed to sync blacklist" [Undecided,New] https://launchpad.net/bugs/1621217
<slangasek> jbicha: done
-queuebot:#ubuntu-release- Unapproved: appstream (xenial-backports/main) [0.10.6-1~ubuntu16.04.1 => 0.10.6-1~ubuntu16.04.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted appstream [source] (xenial-backports) [0.10.6-1~ubuntu16.04.2]
-queuebot:#ubuntu-release- Unapproved: appstream (yakkety-backports/main) [0.10.6-1~ubuntu16.10.1 => 0.10.6-1~ubuntu16.10.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted appstream [source] (yakkety-backports) [0.10.6-1~ubuntu16.10.2]
-queuebot:#ubuntu-release- New: accepted python-neovim [amd64] (zesty-proposed) [0.1.13-1]
-queuebot:#ubuntu-release- New binary: selectors34 [amd64] (zesty-proposed/universe) [1.1.0-1] (no packageset)
#ubuntu-release 2018-01-29
<tsimonq2> slangasek: ukui-menus is incoming to Bionic source NEW and should have the copyright changes you requested, could you please take a look?
-queuebot:#ubuntu-release- New source: ukui-menus (bionic-proposed/primary) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: vdr-plugin-osdteletext [s390x] (bionic-proposed/none) [0.9.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vdr-plugin-osdteletext [arm64] (bionic-proposed/universe) [0.9.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vdr-plugin-osdteletext [armhf] (bionic-proposed/universe) [0.9.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vdr-plugin-osdteletext [ppc64el] (bionic-proposed/universe) [0.9.6-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: menu-cache (xenial-proposed/universe) [1.0.1-1ubuntu0.1 => 1.0.1-1ubuntu0.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lxpanel (xenial-proposed/universe) [0.8.2-1ubuntu2 => 0.8.2-1ubuntu2.1] (lubuntu)
-queuebot:#ubuntu-release- New binary: vdr-plugin-osdteletext [amd64] (bionic-proposed/universe) [0.9.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vdr-plugin-osdteletext [i386] (bionic-proposed/universe) [0.9.6-1] (no packageset)
<flocculant> wgrant: awesome - thanks for lettimg me know
-queuebot:#ubuntu-release- Unapproved: qttools-opensource-src (xenial-proposed/universe) [5.5.1-3build1 => 5.5.1-3ubuntu0.1] (kubuntu, qt5)
<juliank> Apparently we either need to MIR sanlock or demote lvm2-lockd to universe.
<juliank> otherwise lvm2 is stuck
<jibel> sil2100, hi, alpha 2 is still planned this week?
<sil2100> jibel: hey! I think you need to ask tsimonq2 ;)
<sil2100> I didn't hear anything from him yet, I'm just the image engineer for this milestone
<acheronuk> sil2100: see yesterdays log from here
<acheronuk> https://irclogs.ubuntu.com/2018/01/28/%23ubuntu-release.html#t07:13
<acheronuk> sil2100: and that fulfils my promise from 07:19 in that log ;)
<sil2100> ooo!
<sil2100> acheronuk: thanks for the info then ;)
-queuebot:#ubuntu-release- New binary: cysignals [s390x] (bionic-proposed/universe) [1.6.6+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: cysignals [ppc64el] (bionic-proposed/universe) [1.6.6+ds-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu-hwe-16.04 (xenial-proposed/main) [1.3.0-0ubuntu1~16.04.1 => 1.4.0-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati-hwe-16.04 (xenial-proposed/main) [1:7.9.0-0ubuntu1~16.04.1 => 1:7.10.0-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cysignals [arm64] (bionic-proposed/universe) [1.6.6+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: cysignals [i386] (bionic-proposed/universe) [1.6.6+ds-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-nouveau-hwe-16.04 (xenial-proposed/main) [1:1.0.14-0ubuntu1~16.04.1 => 1:1.0.15-2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cysignals [armhf] (bionic-proposed/universe) [1.6.6+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: cysignals [amd64] (bionic-proposed/universe) [1.6.6+ds-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (artful-proposed/main) [0.12.8~17.10.1 => 0.12.9~17.10.1] (no packageset)
<handsome_feng> Hi, I'm the member of Ubuntu Kylin, we know that Ubuntu 18.04 LTS Will Likely Ship With Linux 4.15, but is it possible to choose kernel 4.14 for ubuntukylin 18.04? If it's possible, how to archive that?
<jbicha> handsome_feng: why?
<handsome_feng> jbicha:emmm, it's just a idea that not decide yet, and we just want to know is that possible, :)
<jbicha> handsome_feng: I am not a Kernel Team member or Release Team but the short answer is "no"
<jbicha> Canonical will support 4.15 for the normal life of Ubuntu 18.04 LTS
<handsome_feng> jbicha: Fine, Got it, thanks!
-queuebot:#ubuntu-release- New: accepted cysignals [amd64] (bionic-proposed) [1.6.6+ds-3]
-queuebot:#ubuntu-release- New: accepted cysignals [armhf] (bionic-proposed) [1.6.6+ds-3]
-queuebot:#ubuntu-release- New: accepted cysignals [ppc64el] (bionic-proposed) [1.6.6+ds-3]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-osdteletext [amd64] (bionic-proposed) [0.9.6-1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-osdteletext [armhf] (bionic-proposed) [0.9.6-1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-osdteletext [ppc64el] (bionic-proposed) [0.9.6-1]
-queuebot:#ubuntu-release- New: accepted cysignals [arm64] (bionic-proposed) [1.6.6+ds-3]
-queuebot:#ubuntu-release- New: accepted cysignals [s390x] (bionic-proposed) [1.6.6+ds-3]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-osdteletext [i386] (bionic-proposed) [0.9.6-1]
-queuebot:#ubuntu-release- New: accepted cysignals [i386] (bionic-proposed) [1.6.6+ds-3]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-osdteletext [s390x] (bionic-proposed) [0.9.6-1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-osdteletext [arm64] (bionic-proposed) [0.9.6-1]
<jbicha> if you're thinking that 4.14 is better because it's LTS, note that it's not scheduled to be an extended LTS like 4.4 is
<jbicha> https://www.kernel.org/releases.html
-queuebot:#ubuntu-release- New: accepted freefem [amd64] (bionic-proposed) [3.5.8-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted freefem [armhf] (bionic-proposed) [3.5.8-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted freefem [ppc64el] (bionic-proposed) [3.5.8-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-skinenigmang [amd64] (bionic-proposed) [0.1.2+git20180128-1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-skinenigmang [armhf] (bionic-proposed) [0.1.2+git20180128-1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-skinenigmang [ppc64el] (bionic-proposed) [0.1.2+git20180128-1]
-queuebot:#ubuntu-release- New: accepted freefem [arm64] (bionic-proposed) [3.5.8-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted freefem [s390x] (bionic-proposed) [3.5.8-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-skinenigmang [i386] (bionic-proposed) [0.1.2+git20180128-1]
-queuebot:#ubuntu-release- New: accepted freefem [i386] (bionic-proposed) [3.5.8-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-skinenigmang [s390x] (bionic-proposed) [0.1.2+git20180128-1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-skinenigmang [arm64] (bionic-proposed) [0.1.2+git20180128-1]
-queuebot:#ubuntu-release- New: accepted qca2 [amd64] (bionic-proposed) [2.1.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-epgsync [arm64] (bionic-proposed) [1.0.1-3]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-epgsync [i386] (bionic-proposed) [1.0.1-3]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-epgsync [s390x] (bionic-proposed) [1.0.1-3]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-epgsync [amd64] (bionic-proposed) [1.0.1-3]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-epgsync [ppc64el] (bionic-proposed) [1.0.1-3]
-queuebot:#ubuntu-release- New: accepted vdr-plugin-epgsync [armhf] (bionic-proposed) [1.0.1-3]
<handsome_feng> jbicha: Thank you for your information!
<jbicha> handsome_feng: there was talk about skipping Bionic Alpha 2
<jbicha> https://irclogs.ubuntu.com/2018/01/28/%23ubuntu-release.html#t07:13
<handsome_feng> jbicha: Thanks, after a discuss with other members, kylin will join in alpha2.
<jbicha> handsome_feng: did you read the discussion link I just posted?
<handsome_feng> emm, part of them, Did I miss something?
<jbicha> it sounds like it might only be you and Budgie in Alpha2
<jbicha> I don't think it makes sense to do an Alpha for only one flavor IMO (but I'm not in charge of that)
<jbicha> will you handle the release work, sending out the announcements and other coordination?
<handsome_feng> emm, Do you mean the release note and iso testing for ubuntu kylin?
<jbicha> I mean are you going to send out the ubuntu-devel-announce email for all participating flavors
<jbicha> are you going to stay in this channel at least during release week?
<jbicha> are you going to coordinate with other participating flavors so that rebuilds and the release happen smoothly?
<handsome_feng> sorry, I don't think I am good enough for the job...
<jbicha> if I remember correctly, I don't think Ubuntu Budgie has done that job either
<jbicha> there are people here that can teach you and help you with that if you want to commit to doing it for Alpha 2
<jbicha> but it needs to be either you or Ubuntu Budgie (fossfreedom probably) to do that work for there to be an Alpha 2
<handsome_feng> Does this have a wiki page? I'm worried about my bad English and I have no experience.
<handsome_feng> jbicha: Considering that I'm not good enough and the time different, We decide skipping alpha2 too, sorry.
<jbicha> handsome_feng: I recommend you follow up with Ubuntu Budgie
<handsome_feng> Fine, We will follow up with Budgie, if they do the release job, we will join in(and learning how to do the release job), and if not, we will skipping too.
<jbicha> thanks
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (artful-proposed) [17.2.8-0ubuntu0~17.10.1]
-queuebot:#ubuntu-release- Unapproved: mesa (artful-proposed/main) [17.2.4-0ubuntu1~17.10.2 => 17.2.8-0ubuntu0~17.10.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (xenial-proposed) [17.2.8-0ubuntu0~16.04.1]
-queuebot:#ubuntu-release- Unapproved: mesa (xenial-proposed/main) [17.2.4-0ubuntu1~16.04.4 => 17.2.8-0ubuntu0~16.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: sosreport (artful-proposed/main) [3.5-1~ubuntu17.10.1 => 3.5-1~ubuntu17.10.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.5-1~ubuntu16.04.1 => 3.5-1~ubuntu16.04.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (trusty-proposed/main) [3.5-1~ubuntu14.04.1 => 3.5-1~ubuntu14.04.2] (ubuntu-desktop)
<slangasek> Laney: all of the autopkgtest queues seem to be draining faster today; did you do anything?
<Laney> slangasek: cleaned up ports on bos02, but otherwise nothing in particular
<slangasek> hmm
<Laney> that might have been why bos02 was slower
<slangasek> Laney: when I checked in over the weekend (but had no time to follow through), I was seeing s390x test runners consistently failing
<Laney> right
<slangasek> which wouldn't be the port thing, since that would be architecture-agnostic
<Laney> I started a test instance and it failed to allocate a neutron port
-queuebot:#ubuntu-release- Unapproved: apparmor (artful-proposed/main) [2.11.0-2ubuntu17 => 2.11.0-2ubuntu17.1] (core)
-queuebot:#ubuntu-release- Unapproved: apparmor (xenial-proposed/main) [2.10.95-0ubuntu2.7 => 2.10.95-0ubuntu2.8] (core)
-queuebot:#ubuntu-release- Unapproved: apparmor (trusty-proposed/main) [2.10.95-0ubuntu2.6~14.04.1 => 2.10.95-0ubuntu2.6~14.04.2] (core)
<tsimonq2> slangasek: Can kde-baseapps please get an RM from bionic-proposed? I miscalculated things...
<tsimonq2> (tl;dr it should be removed from bionic once all rdeps are ported, or they should go with it, KDE 4...)
<slangasek> tsimonq2: sorry, what was the miscalculation?
<tsimonq2> slangasek: autopkgtests are rightfully broken because of version mismatches. I could go and monkey patch the incompatibilities but it seems to be better to just RM
<slangasek> tsimonq2: this appears to have been a sync of a package still present in Debian; do you expect it to be removed there?
<tsimonq2> slangasek: Eventually it will be removed in Debian because of the KDE 4 deprecation but not at the moment.
<slangasek> tsimonq2: ok
<tsimonq2> slangasek: So I'm just suggesting to remove from -proposed and keep with the 16.04.3 version already in Bionic.
<slangasek> done
<tsimonq2> slangasek: Because it's not worth the effort to fix it if it's deprecated upstream and will be RMed anyways
<tsimonq2> Thanks
<tsimonq2> slangasek: btw, did you get a chance to look at ukui-menus? It should be good now.
<slangasek> and I see someone is spiking the autopkgtest queue again... I assume that's more KDE
<tsimonq2> Not likely
<slangasek> tsimonq2: not yet; I'm a bit under the weather and working at half capacity today, which basically means I'm keeping up with meetings and little else
<tsimonq2> KDE Frameworks was uploaded days ago...
<tsimonq2> slangasek: ah ok, it's going around I think (I have it too :/), get well soon
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (artful-proposed) [2.8.1-0ubuntu0.17.10.2]
<slangasek> looks like it's nodejs to blame for the queues
<tjaalton> could someone mark bdfproxy autopkgtest triggered by pyasn1 as ignored, it's blocking python-ldap
<tjaalton> and also mark freeipa ignored on python-ldap triggered tests
<tjaalton> not permanently, should be a one-off thing to unblock 389-ds-base
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu-hwe-16.04 [source] (xenial-proposed) [1.4.0-1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati-hwe-16.04 [source] (xenial-proposed) [1:7.10.0-1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-nouveau-hwe-16.04 [source] (xenial-proposed) [1:1.0.15-2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (artful-proposed) [17.2.8-0ubuntu0~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (xenial-proposed) [17.2.8-0ubuntu0~16.04.1]
-queuebot:#ubuntu-release- Packageset: Added budgie-extras to personal-fossfreedom in artful
-queuebot:#ubuntu-release- Packageset: Added budgie-extras to personal-fossfreedom in bionic
<wolsen> any chance to release https://bugs.launchpad.net/ubuntu/+source/networking-l2gw/+bug/1737040 into artful?
<ubot5> Ubuntu bug 1737040 in networking-l2gw (Ubuntu Artful) "[SRU] Update to networking-l2gw 11.0.0 for Pike" [Medium,Fix committed]
<slangasek> cpaelzer: you appear to be proposing a hint for the wrong version of 389-ds-base; 1.3.7.8-4 is the version in -proposed that has working autopkgtests
<tjaalton> slangasek: that's why I asked to ignore some tests to let pyasn1 & python-ldap to migrate, which would unblock 389-ds-base
<slangasek> tjaalton: indeed; though I'm going to need a rationale on why it's correct to ignore those failures, especially for ignoring a freeipa/4.4.4-4 failure on python-ldap when 4.4.4-4 is the version that's supposed to have fixed tests
<tjaalton> well, maybe I overlooked something in the new python-ldap, it fails to install test dependencies
<tjaalton> hang on
<tjaalton> maybe it's the dep on newer pyasn1?
<tjaalton> so touch that first, ignore bdfproxy on amd64
<tjaalton> heck, I'll send a merge proposal for that
<tjaalton> there
-queuebot:#ubuntu-release- New binary: hoel [amd64] (bionic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [i386] (bionic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: multitime [i386] (bionic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (xenial-proposed/main) [0.7.0-0ubuntu4.3 => 0.8.3-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: multitime [amd64] (bionic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [s390x] (bionic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: multitime [s390x] (bionic-proposed/universe) [1.3-1] (no packageset)
#ubuntu-release 2018-01-30
-queuebot:#ubuntu-release- New binary: hoel [arm64] (bionic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: multitime [arm64] (bionic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [armhf] (bionic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: multitime [armhf] (bionic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hoel [ppc64el] (bionic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: multitime [ppc64el] (bionic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted hoel [amd64] (bionic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted hoel [armhf] (bionic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted hoel [ppc64el] (bionic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted hoel [arm64] (bionic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted hoel [s390x] (bionic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted hoel [i386] (bionic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted multitime [amd64] (bionic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted multitime [armhf] (bionic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted multitime [ppc64el] (bionic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted multitime [arm64] (bionic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted multitime [s390x] (bionic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted multitime [i386] (bionic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted gnome-tweaks [source] (bionic-proposed) [3.27.4-1ubuntu1]
-queuebot:#ubuntu-release- New binary: gnome-tweaks [amd64] (bionic-proposed/none) [3.27.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-tweaks [amd64] (bionic-proposed) [3.27.4-1ubuntu1]
<cpaelzer> slangasek: yes I found that as well - since 1.3.7.8-2 it is good
<cpaelzer> I'm abandoning the MP
<tjaalton> it's already merged
<tjaalton> or to be exact, changed so that it only affected the bad version
<doko> tjaalton: freepa needs a bind9 merge
<doko> freeipa even
<tjaalton> doko: I know, the server team is on it
<tjaalton> merging https://code.launchpad.net/~tjaalton/britney/hints-ubuntu/+merge/336803 would unblock python-ldap and then 389-ds-base
<apw> tjaalton, what on earth is is attempting to merge that into ?
<tjaalton> apw: huh, something silly
<apw> are you merging it into the code perhaps
<tjaalton> same mistake that cpaelzer did, apparently
<tjaalton> I pulled hints-ubuntu, modified it and then pushed it to lp:tjaalton
<cpaelzer> thanks that I'm not alone tjaalton :-)
<tjaalton> :)
<cpaelzer> this is the default that is selected, which is wrong :-/
<apw> tjaalton, can you change what it is trying to merge it into, that isn't an editable for me
<tjaalton> I'll try
<tjaalton> No RSA host key is known for bazaar.launchpad.net and you have requested strict checking.
<tjaalton> huh
<apw> tjaalton, hmmm going to be one of those days is it
<tjaalton> looks like it
<apw> tjaalton, anyhow the diff looks fine when its not mad, merged and pushed
<tjaalton> cool
<apw> tjaalton, https://code.launchpad.net/~tjaalton/britney/hints-ubuntu/+merge/336815
<apw> ok i found a button to resubmit it against the right thing i think
<tjaalton> good, I couldn't
-queuebot:#ubuntu-release- New source: ipxe-qemu-256k-compat (bionic-proposed/primary) [1.0.0+git-20150424.a25a16d-0ubuntu1]
<cpaelzer> the above is for bug 1713490
<ubot5> bug 1713490 in qemu (Ubuntu Bionic) "error migrating blocked on virtio-net-pci.rom" [High,In progress] https://launchpad.net/bugs/1713490
<cpaelzer> TL;DR a copy of xenial src:ipxe stripped of most but a few roms we need as compat
<cpaelzer> I also need a MIR on this which I think I can only open once through new (to have the src on LP)
<cpaelzer> so if one could take a look that would be great
<cpaelzer> let me know if there is anything I still need to do to pass the new queue on this
-queuebot:#ubuntu-release- New binary: libvirt [s390x] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
<cpaelzer> and that is libvirt splitting a few submodules (in Debian) for storage support
-queuebot:#ubuntu-release- New binary: libvirt [ppc64el] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: libvirt [arm64] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: libvirt [armhf] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: libvirt [amd64] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: libvirt [i386] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
<smb> Can someone drop the artful upload of ubuntu-fan from the sru queue, please? (would like to replace it with minor packaging changes)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-fan [source] (artful-proposed) [0.12.9~17.10.1]
-queuebot:#ubuntu-release- New: accepted libvirt [amd64] (bionic-proposed) [4.0.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [armhf] (bionic-proposed) [4.0.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [ppc64el] (bionic-proposed) [4.0.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [arm64] (bionic-proposed) [4.0.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [s390x] (bionic-proposed) [4.0.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [i386] (bionic-proposed) [4.0.0-1ubuntu1]
<cpaelzer> thanks for those accepts
<cpaelzer> I'd be happy about an accept or discussion on New source: ipxe-qemu-256k-compat as well
<doko> component-mismatches are not updated ...
<cpaelzer> If one would accept src:ipxe-qemu-256k-compat I'd know one component-mismatch more than before :-P
-queuebot:#ubuntu-release- New binary: bind9 [s390x] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [ppc64el] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [amd64] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
<ahasenack> \o/
<ahasenack> heads up: the bind9 upload above needs python3-ply to be pulled back into main. The source and python-ply (py2 version) are in main already
-queuebot:#ubuntu-release- New binary: bind9 [arm64] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [armhf] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [i386] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (artful-proposed/main) [0.12.8~17.10.1 => 0.12.9~17.10.1] (no packageset)
<smb> ^so its back and waiting to be accepted
<cpaelzer> hehe
<cpaelzer> one more ping on ipxe-qemu-256k-compat (source) btw
<cpaelzer> this really is a rename+strip of src:ipxe from former releases
<cpaelzer> and I just realized it has to pass new queue to be able to file the MIR for it
<cpaelzer> bug 1746255
<ubot5> bug 1746255 in Launchpad itself "packages in new queue have a per-package page, but some actions trigger an oops" [Undecided,New] https://launchpad.net/bugs/1746255
<cpaelzer> also libvirt in proposed migration puzzles me
<cpaelzer> maybe one can help me to track why it is complaining about unsatisfieable Depends
<cpaelzer> glusterfs-common is universe
<cpaelzer> libvirt (most components) are in main
<cpaelzer> but the link to gluster is a suggests (intentionally)
<cpaelzer> libvirt-daemon => Suggests: libvirt-daemon-driver-storage-gluster
<cpaelzer> libvirt-daemon-driver-storage-gluster_4.0.0-1ubuntu1_amd64.deb => Depends: glusterfs-common
<cpaelzer> Seeded is only libvirt-daemon-system/libvirt-bin
<cpaelzer> But proposed migration complains:
<cpaelzer> libvirt-daemon-driver-storage-gluster/amd64 unsatisfiable Depends: glusterfs-common
<cpaelzer> maybe it is not about main/universe after all and I miss something
<cpaelzer> but on a system with the ppa of the same source all is installable with/without gluster as I thought it should be
<cpaelzer> any hint is welcome
<tjaalton> I'm weeding through all the python madness in bionic-proposed, and was wondering why pyasn1/-modules still hasn't migrated and update_output.txt shows that some packages should be uninstallable. well, turns out I can install python-construct but python-dfvfs complains that -construct can't be installed..
<tjaalton> and I have a newer version installed already?!
<tjaalton>  python-dfvfs : Depends: python-construct (>= 2.5.2) but it is not going to be installed
<tjaalton> ahah
<tjaalton> there's a braks
<tjaalton> *breaks
<tjaalton> newer dfvfs is in -proposed
<tjaalton> just ftbfs while fine on debian
-queuebot:#ubuntu-release- New: accepted bind9 [amd64] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [armhf] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [ppc64el] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [arm64] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [s390x] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [i386] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
<rbasak> cpaelzer: libvirt-daemon-driver-storage-gluster_4.0.0-1ubuntu1_amd64.deb does depend on glusterfs-common.
<rbasak> cpaelzer: if it doesn't in the source, perhaps the build added it?
<cpaelzer> rbasak: it does, but that is fine
<cpaelzer> as libvirt-daemon-driver-storage-gluster_4.0.0-1ubuntu1_amd64.deb itself is only suggested
<cpaelzer> so it should not be a component mismatch
<cpaelzer> and also glusterfs-common is available in general (I can install it)
<cpaelzer> oh well
<cpaelzer> maybe it depends on a specific new version of glusterfs-common that is itself blocked by something
<cpaelzer> I need to look in that
<cjwatson> component-mismatches-proposed is out of date and I suspect that once it comes up to date it'll show -gluster for demotion to universe
<rbasak>  Depends: glusterfs-common, libc6 (>= 2.4), libvirt-daemon (= 4.0.0-1ubuntu1)
<cjwatson> I might have managed to unstick it earlier; we'll see
<cpaelzer> ok, I'll just let it be and consider it a false positive that will be resolved
<cpaelzer> because atm that is how it looks to me
<cpaelzer> libvirt-daemon-driver-storage-gluster is new and should be only in universe
<rbasak> Oh, I see. Now I think I understand the problem. Never mind, sorry.
<cjwatson> it probably just went into main by default due to being from a source in main
<cjwatson> don't worry about it for now
<cpaelzer> yeah
<cpaelzer> thanks cjwatson
<cpaelzer> all I wanted to hear
<cjwatson> cpaelzer: as I thought.  demoting now
<flocculant> cpaelzer: re mouse integration - just posted to bug, but as you're here ... success with ppa and tablet - thanks very much :)
<flocculant> nvm ...
<slangasek> has anyone analyzed why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says 'freeipa-server-dns/amd64 unsatisfiable Depends: bind9-dyndb-ldap (>= 11)' when bind9-dyndb-ldap 11.1-1 is now in bionic-proposed?
<nacc> ahasenack: --^
<ahasenack> slangasek: bind9 9.11 can't migrate because I missed a universe dependency (lmdb)
<ahasenack> slangasek: I have https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1746296 and a branch for it, currently building in a ppa
<ubot5> Ubuntu bug 1746296 in bind9 (Ubuntu) "Drop lmdb dependency as it's in universe" [High,In progress]
<ahasenack> slangasek: the other universe dependency we need a component-mismatch for, it's python3-ply. The source package (ply) is in main, as is the python-ply (py2) package it produces
<slangasek> ahasenack: yes, but that shouldn't translate to "unsatisfiable dependency", it should only translate to "depends on bind9", which is also listed
<nacc> yeah that's weird
<nacc> they are both in universe
<ahasenack> slangasek: that I haven't analyzed, i zeroed in in the lmdb dependency I missed
<ahasenack> slangasek: >= 11 seems wrong, shouldn't it be >= 9.11?
<ahasenack> oh, it's from another source package
<ahasenack> n/m
<ahasenack> excuses says "missing build": missing build on amd64: bind9-dyndb-ldap (from 10.1-2)
<ahasenack> but 11.1-1 built: https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.1-1/
<nacc> ahasenack: nice catch, that's presumably why
<ahasenack> excuses is just not seeing the builds for some reason?
<nacc> ahasenack: it might be lagging
<ahasenack> it's built since december
<nacc> ahasenack: then i don't know ;)
<ahasenack> https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.1-1/ also says "no changes file available"
<oSoMoN> hey, can the libreoffice i386 autopkgtest failure be ignored to allow 1:5.4.4-0ubuntu2 to migrate? it's the same failure that was ignored for the past few updates, because of bug #1699772 (java/kernel stack clash)
<ubot5> bug 1699772 in linux (Ubuntu Bionic) "linux-image-4.13.0-12-generic, linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic | Regression: many user-space apps crashing" [Critical,In progress] https://launchpad.net/bugs/1699772
<oSoMoN> (the good news is that someone from the kernel team is looking into it so hopefully a future kernel update will have a fix)
<doko> oSoMoN: lo won't mirgrate until poppler, mpclib, mpfr4, gnustep-* tinyxml2, binutils gcc-* glibc migrate ... and probably other affected transitions
<oSoMoN> okay, I'd better be patient thenâ¦
<doko> oSoMoN: or help identifying stuff which still needs fixing?
<oSoMoN> doko, sure, where do I start?
<jbicha> doko: does LO 6 need to wait for all those transitions?
<doko> oSoMoN: update_excuses and update_output, looking for library packages which won't migrate, i.e. transitions imported from debian and not done in Ubuntu
<doko> jbicha: it needs poppler
<jbicha> doko: yes, I mean does oSoMoN need to wait to upload LO 6 until after the poppler transition is done?
<doko> so fixing autopkg tests which prevent migration of poppler helps
<doko> ahh, maybe not
<seb128> doko, oSoMoN, it was built before poppler was uploaded so it should be able to migrate no?
<seb128> well before poppler at least
<doko> no
<LocutusOfBorg> apw, merge my patch please? (hints bzr repo)
<oSoMoN> the poppler transition happened between I test-built LO in a PPA and I uploaded it, so I had to re-upload with a patch for the new poppler
<slangasek> ahasenack, nacc: hmm, then it should still only translate into "depends on bind-dyndb-ldap", which appears to be the source package still building that binary in both bionic and bionic-proposed.
<ahasenack> slangasek: for a moment I thought this dyndb-ldap package came from the bind9 source, specially because of the similar version (11.1 vs 9.11) that tricked my eye
<nacc> slangasek: yeah, i agree; it feels like 'something' is in the wrong state
<nacc> slangasek: rmadison reports the binaries are available, e.g., but excuses doesn't see them?
 * slangasek nods
<slangasek> so, launchpad says it's there, let's see if it's missing from the packages files
<slangasek> it is present in the packages files
<slangasek> so that's going to take some rooting around in britney state, sigh
<nacc> doko: should i change the state of the libsodium bug task so it's back on the MIR list to modify for bionic?
 * slangasek considers manually copying bind-dyndb-ldap to the release pocket to try to unblock
<slangasek> ahahaha can't copy bind-dyndb-ldap because it depends on new bind9 sonames <facepalm>
<slangasek> ah, but behold, now bind-dyndb-ldap is happy :P
<slangasek> ahasenack, nacc: what's the current thinking wrt lmdb?  Is this getting dropped or MIRed?
<ahasenack> slangasek: I'm dropping it at the moment, it's for a new tool to convert zone files
<slangasek> ok
<ahasenack> slangasek: https://launchpad.net/~ahasenack/+archive/ubuntu/bind9-drop-lmdb-1746296/+packages has packages I will test tomorrow
<slangasek> ahasenack: test tomorrow> why, vs. me uploading them today?
<ahasenack> I just want to be sure the only thing we will not have is that tool to convert the zone files
<ahasenack> slangasek: would you like to review my branch perhaps?
<ahasenack> slangasek: https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+ref/bind9-drop-lmdb-1746296
<slangasek> ahasenack: that seems like something I could manage to test with debdiff before pushing, if necessary :) but also, it seems like that shouldn't block the long and messy proposed-migration dep chain right now
<slangasek> sure, I'll look
<slangasek> I guess it's still the case that I don't have access to land this branch anywhere?
<ahasenack> slangasek: ok, let me do a quick install then. I moved to another task while the packages in the ppa were building
<ahasenack> slangasek: probably, me neither. You can take over it with a debdiff if you are happy with it, I don't mind
<slangasek> ahasenack: wow, so for some reason, I can't do a clean checkout of this repo; all of the win32 *vcxproj*.in files in the tree show up as modified
<slangasek> ahasenack: seems to be some line feed issue, git knows that the files in the working dir don't match but refuses to fix them :P
<ahasenack> slangasek: I just did a quick test with a feature that the CHANGES file say would be affected by using the new lmdb library, using the packages from that ppa, seems to have worked fine: https://pastebin.ubuntu.com/26491290/
<slangasek> also, was I wrong to expect pristine-tar data on these branches?
<ahasenack> created this file: https://pastebin.ubuntu.com/26491297/
<ahasenack> slangasek: reading
<slangasek> ahasenack: uploaded, thanks
<ahasenack> slangasek: I don't know about pristine-tar. I cloned bind (using git ubuntu clone bind9), then created a new branch from ubuntu/devel, and that's what I pushed to lp
 * slangasek nods
<slangasek> right, so it was more a question of whether I should expect pristine-tar on the usd branches
<slangasek> it's possible I was told before that I shouldn't, but I still do, because I'm difficult that way
<ahasenack> nacc: ^ :)
<ahasenack> slangasek: there will still be one component-mismatch on python3-ply, can you fix that?
<ahasenack> python-ply, which comes from the same source ("ply"), is in main
<slangasek> ahasenack: already done; will be fixed in next publisher run
<ahasenack> great
-queuebot:#ubuntu-release- New binary: rsyslog [s390x] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [ppc64el] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [arm64] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [armhf] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [i386] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: rsyslog [amd64] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
<slangasek> tsimonq2: so I caught in scrollback you were discussing skipping alpha2.  I haven't seen anything to the contrary, and it's Tuesday of the milestone week, so I guess this is the plan of record?
<nacc> ahasenack: slangasek: we have per-distro pristine-tar branches
<nacc> slangasek: let me know if that does not answer your question
<slangasek> nacc: so why did git-buildpackage not find them?
<slangasek> nacc: was it because I was building from ahasenack's branch instead of from one of the usd branches?
<nacc> slangasek: gbp ivoekd directly?
<nacc> *invoked
<slangasek> yeah
<nacc> slangasek: gbp can't find them
<nacc> gbp doesn't have any concept of multiple pristine-tar
<nacc> we wrap all that with git-ubuntu build :)
<nacc> it's possible that's now fixed in the latest gbp, but I think it's not still -- i'll need to look
<nacc> basically our wrapper uses a context to checkout the "right" pristine-tar branches to 'pristine-tar' and then calls gbp
<nacc> there is a export-orig subcommand now that makes that more accessible
<tsimonq2> slangasek: I guess it is, yes.
<slangasek> nacc: ah ok
<nacc> slangasek: seeing as you did it before, would it be possible for you to promote libsodium again? LP: #1621386? it's pulled up by php7.2-cli now (which is in turn going to get promoted via the seeds)
<ubot5> Launchpad bug 1621386 in libsodium (Ubuntu) "[MIR] libsodium" [Undecided,Confirmed] https://launchpad.net/bugs/1621386
<slangasek> nacc: needs a new team subscriber, unity-api-team should not be considered an owner for new MIRs
<nacc> slangasek: it does already
<nacc> slangasek: ubuntu-server subscribed to the package
<slangasek> nacc: <refresh> oh, so they did
<nacc> slangasek: :)
<nacc> i also thought i had put a comment to that effect in the MIR bug
<slangasek> nacc: you want me to read *both* sentences of the comment?
<nacc> slangasek: it is a lot to ask :)
<tsimonq2> "Therefore, we will need to include it in main to support Unity 8." woah we're putting Unity 8 BACK in the archive?
 * tsimonq2 runs
<slangasek> it's actually just a pork barrel MIR
<slangasek> "the Server Team will formally support unity8, in exchange for you shipping nodejs in main"
<tsimonq2> hah :)
<nacc> lol
<nacc> slangasek: thanks
<juliank> oh, rsyslog landed in NEW.
<juliank> Kind of makes sense, I guess
<juliank> We do have new binaries after all
<juliank> I wonder why that did not happen when lvm2-lockd was introduced, though. that was odd.
<juliank> or maybe it did and I did not notice
<nacc> juliank: it did, and probably was auto-accepted
<juliank> ah
<juliank> well, I don't care much as long as it works :)
<nacc> (not 100%, but just a guess)
<nacc> auto = reviewed by an AA and accepted, i mean
<juliank> yeah
-queuebot:#ubuntu-release- New binary: rkt [amd64] (bionic-proposed/universe) [1.29.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: otb [s390x] (bionic-proposed/universe) [6.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted otb [s390x] (bionic-proposed) [6.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rkt [amd64] (bionic-proposed) [1.29.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: otb [ppc64el] (bionic-proposed/universe) [6.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted otb [ppc64el] (bionic-proposed) [6.4.0+dfsg-1]
#ubuntu-release 2018-01-31
-queuebot:#ubuntu-release- New binary: otb [amd64] (bionic-proposed/universe) [6.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (artful-proposed/main) [7.2.0-8ubuntu3 => 7.2.0-8ubuntu3.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-5 (xenial-proposed/main) [5.4.0-6ubuntu1~16.04.6 => 5.4.0-6ubuntu1~16.04.8] (core) (sync)
<slangasek> Laney: do you know if there's a particular reason for using ssmtp (from universe) in the autopkgtest hooks?  It may simply not be smart enough to send mail to multiple recipients, and it certainly doesn't do any useful logging
-queuebot:#ubuntu-release- New: accepted otb [amd64] (bionic-proposed) [6.4.0+dfsg-1]
<slangasek> Laney: hmm no, it's not that
<slangasek> Laney: i.e. strace shows it dtrt at the smtp level
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [sync] (artful-proposed) [7.2.0-8ubuntu3.1]
-queuebot:#ubuntu-release- New: accepted rsyslog [amd64] (bionic-proposed) [8.32.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsyslog [armhf] (bionic-proposed) [8.32.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsyslog [ppc64el] (bionic-proposed) [8.32.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsyslog [arm64] (bionic-proposed) [8.32.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsyslog [s390x] (bionic-proposed) [8.32.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rsyslog [i386] (bionic-proposed) [8.32.0-1ubuntu1]
<cpaelzer> flocculant: that is great, glad I could help
-queuebot:#ubuntu-release- New binary: dino-im [ppc64el] (bionic-proposed/none) [0.0.git20180130-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dino-im [s390x] (bionic-proposed/none) [0.0.git20180130-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dino-im [arm64] (bionic-proposed/none) [0.0.git20180130-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dino-im [i386] (bionic-proposed/none) [0.0.git20180130-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dino-im [armhf] (bionic-proposed/none) [0.0.git20180130-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-josepy [amd64] (bionic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dino-im [amd64] (bionic-proposed/none) [0.0.git20180130-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-josepy [amd64] (bionic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted dino-im [amd64] (bionic-proposed) [0.0.git20180130-1]
-queuebot:#ubuntu-release- New: accepted dino-im [armhf] (bionic-proposed) [0.0.git20180130-1]
-queuebot:#ubuntu-release- New: accepted dino-im [ppc64el] (bionic-proposed) [0.0.git20180130-1]
-queuebot:#ubuntu-release- New: accepted dino-im [arm64] (bionic-proposed) [0.0.git20180130-1]
-queuebot:#ubuntu-release- New: accepted dino-im [s390x] (bionic-proposed) [0.0.git20180130-1]
-queuebot:#ubuntu-release- New: accepted dino-im [i386] (bionic-proposed) [0.0.git20180130-1]
<doko> what is wrong with http://people.canonical.com/~ubuntu-archive/component-mismatches.txt golang-1.8?
<doko> why is it pulled into main?
<doko> Laney: autopkgtest for lintian/unknown: amd64: Regression â» , armhf: Regression â» , i386: Regression â» any idea why that fails? already gave it back
<doko> Laney: nm, lintian was not yet built :-/
<infinity> doko: Possibly snapd Built-Using: golang-1.8
<cpaelzer> Hi, I wanted to ask again for src:ipxe-qemu-256k-compat on bionic new queue to be considered
<cpaelzer> I even have a security ack in a mail thread for a MIR right afterwards, but I can't file the MIR before the accept on new is done
<cpaelzer> also it blocks qemu proposed-migration
<cpaelzer> I'm here for discussions on src:ipxe-qemu-256k-compat if needed
<infinity> cpaelzer: I'll have a look.
<cpaelzer> thanks in advance
<doko> infinity: ahh, and ftbfs in proposed
<doko> given back
<doko> and giving back all failed builds in -proposed
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (bionic-proposed) [10-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (bionic-proposed) [10-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (bionic-proposed) [10-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (bionic-proposed) [10-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (bionic-proposed) [10-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (bionic-proposed) [10-2]
-queuebot:#ubuntu-release- New binary: openttd [s390x] (bionic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openttd [amd64] (bionic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openttd [i386] (bionic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openttd [armhf] (bionic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openttd [arm64] (bionic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (artful-proposed) [0.12.9~17.10.1]
-queuebot:#ubuntu-release- New binary: fmtlib [s390x] (bionic-proposed/universe) [4.0.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openttd [ppc64el] (bionic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qoauth [s390x] (bionic-proposed/universe) [2.0.1~1-3] (no packageset)
<juliank> sil2100: Can we ignore the ruby2.3 failure on arm64 blocking readline? It happened before, it's not readline specific.
-queuebot:#ubuntu-release- New binary: qoauth [armhf] (bionic-proposed/universe) [2.0.1~1-3] (no packageset)
<juliank> It's some weird path thing
<juliank> -"/var/lib/gems/2.3.0"
<juliank> +"/tmp/test_rubygems_895/default"
-queuebot:#ubuntu-release- New binary: qoauth [arm64] (bionic-proposed/universe) [2.0.1~1-3] (no packageset)
<juliank> oh, there are more
<juliank> hmm some obscure time zone failures
<juliank> Failure: count is the same as for openssl, though, so I guess both are fine :)
<juliank> don't ask me why it works in 50% of the cases - I  don't know
-queuebot:#ubuntu-release- New: accepted openttd [amd64] (bionic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted openttd [armhf] (bionic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted openttd [ppc64el] (bionic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted openttd [arm64] (bionic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted openttd [s390x] (bionic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted openttd [i386] (bionic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New binary: fmtlib [arm64] (bionic-proposed/universe) [4.0.0+ds-2] (no packageset)
<doko> juliank, sil2100: I would support ignoring all ruby2.3 related failures now. ruby2.5 will be in bionic, and ruby2.3 will go away
<juliank> +1
-queuebot:#ubuntu-release- New binary: fmtlib [armhf] (bionic-proposed/universe) [4.0.0+ds-2] (no packageset)
<juliank> doko: I assume you wanted to sync readline (since you merged the changes into Debian and put out two bugfixes after that), but forgot it, hence I did last week.
<sil2100> hm, ok
-queuebot:#ubuntu-release- New binary: fmtlib [i386] (bionic-proposed/universe) [4.0.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fmtlib [amd64] (bionic-proposed/universe) [4.0.0+ds-2] (no packageset)
<sil2100> juliank: done
<juliank> sil2100: thanks
-queuebot:#ubuntu-release- New binary: qoauth [amd64] (bionic-proposed/universe) [2.0.1~1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qoauth [i386] (bionic-proposed/universe) [2.0.1~1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: fmtlib [ppc64el] (bionic-proposed/universe) [4.0.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qoauth [ppc64el] (bionic-proposed/universe) [2.0.1~1-3] (no packageset)
<xnox> Please remove libssl1.0.0-dbg binaries from bionic, migrated to dbgsyms packages.
-queuebot:#ubuntu-release- New: accepted qoauth [amd64] (bionic-proposed) [2.0.1~1-3]
-queuebot:#ubuntu-release- New: accepted qoauth [armhf] (bionic-proposed) [2.0.1~1-3]
-queuebot:#ubuntu-release- New: accepted qoauth [ppc64el] (bionic-proposed) [2.0.1~1-3]
-queuebot:#ubuntu-release- New: accepted qoauth [arm64] (bionic-proposed) [2.0.1~1-3]
-queuebot:#ubuntu-release- New: accepted qoauth [s390x] (bionic-proposed) [2.0.1~1-3]
-queuebot:#ubuntu-release- New: accepted qoauth [i386] (bionic-proposed) [2.0.1~1-3]
<xnox> juliank, doko, does not help that ruby2.5 does not pass its tests either.
-queuebot:#ubuntu-release- New: accepted fmtlib [amd64] (bionic-proposed) [4.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted fmtlib [armhf] (bionic-proposed) [4.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted fmtlib [ppc64el] (bionic-proposed) [4.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted fmtlib [arm64] (bionic-proposed) [4.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted fmtlib [s390x] (bionic-proposed) [4.0.0+ds-2]
-queuebot:#ubuntu-release- New: accepted fmtlib [i386] (bionic-proposed) [4.0.0+ds-2]
<juliank> xnox: it does not?
<juliank> seemed fine for readline
<juliank> xnox: um, ok, it's allways failed
<juliank> xnox: but always failed does help :D
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [sync] (xenial-proposed) [5.4.0-6ubuntu1~16.04.8]
<infinity> xnox: It's not bionic that's causing that error, it's bionic-proposed.
<infinity> xnox: If NBS in the release pocket needed manual intervention every time, nothing would ever migrate. :P
<xnox> infinity, ah
<infinity> xnox: Fixed in proposed.
<infinity> Err, by someone else before me, apparently. :P
-queuebot:#ubuntu-release- New binary: libixion [s390x] (bionic-proposed/main) [0.13.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libixion [ppc64el] (bionic-proposed/main) [0.13.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libixion [i386] (bionic-proposed/main) [0.13.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libixion [amd64] (bionic-proposed/main) [0.13.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libixion [armhf] (bionic-proposed/main) [0.13.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libixion [arm64] (bionic-proposed/main) [0.13.0-2] (kubuntu)
-queuebot:#ubuntu-release- New: accepted libixion [amd64] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted libixion [armhf] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted libixion [ppc64el] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted libixion [arm64] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted libixion [s390x] (bionic-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted libixion [i386] (bionic-proposed) [0.13.0-2]
<xnox> infinity, could you please RM qesteidutil 0.3.1-0ubuntu3 from bionic-proposed? no longer needed, as the libp11-3 soname bump is reverted for now (we do not have the new ssl yet, derp)
<xnox> plus it FTBFS anyway
<oSoMoN> doko, is there anything blocking the promotion of poppler now?
<ahasenack> hi, is bind9 stuck in migration? It's been like this (everything green or ignored) for about 12h now: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#bind9
<doko> oSoMoN: same as yesterday: mpfr4, binutils, and all the depending stuff, including net-snmp and perl
<doko> oSoMoN: and see the new libixion. not sure what rebuilds are needed
-queuebot:#ubuntu-release- New binary: liborcus [s390x] (bionic-proposed/main) [0.13.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liborcus [ppc64el] (bionic-proposed/main) [0.13.2-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liborcus [i386] (bionic-proposed/main) [0.13.2-1] (kubuntu)
<infinity> ahasenack: bind9 is a transition, it can't migrate until all its rdeps are rebuilt and ready.
<ahasenack> I see
<ahasenack> do I need to do anything about it, or are these other builds kicked off automatically?
<infinity> ahasenack: They are not.
<ahasenack> so I need to hunt them down?
<infinity> ahasenack: I'll set up a transition tracker to find them for us.
<ahasenack> ok
<infinity> ahasenack: Actually, it may be a short enough list to not bother with that.
-queuebot:#ubuntu-release- New binary: liborcus [amd64] (bionic-proposed/main) [0.13.2-1] (kubuntu)
<ahasenack> bind9 has an annoyingly large number of library packages
<infinity> ahasenack: Yeah, but almost nothing uses them.
-queuebot:#ubuntu-release- New binary: liborcus [arm64] (bionic-proposed/main) [0.13.2-1] (kubuntu)
<infinity> ahasenack: isc-dhcp, bind9-dyndb-ldap, libnss-lwres... Looks like the whole list.
<infinity> ahasenack: And bind9-dyndb-ldap was already uploaded.
<infinity> ahasenack: So, just isc-dhcp and libnss-lwres need rebuilding, AFAICT.
<ahasenack> libnss-lwres will be dropped, as we are not shipping lwresd anymore
<ahasenack> it might build, but won't be installable
<infinity> ahasenack: Define "not shipping"... Looks like it's in the archive.
<ahasenack> for bind9 9.10, not this 9.11 one
<ahasenack> I sent an email to ubuntu-server@ and ubuntu-devel@ about it
<ahasenack> debian dropped it
-queuebot:#ubuntu-release- New binary: liborcus [armhf] (bionic-proposed/main) [0.13.2-1] (kubuntu)
<infinity> ahasenack: lwresd is dropped, yes, but not liblwres, which is what libnss-lwres depends on.
<ahasenack> right
<ahasenack> but libnss-lwres depends on lwresd (runtimE)
<infinity> ahasenack: But it doesn't.
<ahasenack> really?
<infinity> It recommends it, but doesn't depend on it.  Which would imply that either it can work without the daemon, or it's packaged incorrectly. :P
<ahasenack> ah, I hadn't noticed that it's a recommends
<ahasenack> it can work by not breaking, without the server bit (lwresd)
<ahasenack> but won't do anything useful I think
<ahasenack> anyway
<ahasenack> we can kick a rebuild I suppose
<ahasenack> maybe it can point at a different ip instead of localhost
<ahasenack> there was no manpage for its config file, nor a sample one
<ahasenack> ok then
<infinity> ahasenack: Well, I think lwresd in bind9 was actually just some symlinks to the named binary. :P
<ahasenack> it is
<ahasenack> I was just looking up my mp where I summarized it
<ahasenack> infinity: https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+merge/336719/comments/882890
<ahasenack> there
<ahasenack> tl;dr:
<ahasenack> root@bionic-bind9-merge:~# md5sum /usr/sbin/lwresd /usr/sbin/named
<ahasenack> 5d1fbcc8583f732b50c2b8a4c3946223 /usr/sbin/lwresd
<ahasenack> 5d1fbcc8583f732b50c2b8a4c3946223 /usr/sbin/named
<ahasenack> that's why liblwres is still packaged, as the /usr/sbin/named will still behave as lwresd (and need the lib) if it's called like that
<infinity> ahasenack: So, does the new package ship lwresd as a symlink/hardlink?
<ahasenack> no
<ahasenack> it's really gone
<infinity> ahasenack: If not, that seems like a regression.
<ahasenack> no lwresd package, no /usr/sbin/lwresd blob
<ahasenack> that's what was dropped by debian, and we followed
<infinity> And a pointless one.
<ahasenack> upstream dropped the lwres code entirely in 9.12
<infinity> Ahh, if it's gone in 9.12, fair enough.
<ahasenack> yes, see my email to ubuntu-devel: https://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/msg08445.html
<infinity> ahasenack: In that case, I'm all for removing libnss-lwres entirely.
<ahasenack> \o/
<infinity> ahasenack: isc-dhcp, on the other hand, can you test and make sure it works with a straight rebuild (and, if not, find a way forward)?
<ahasenack> I will
<ahasenack> get bionic-proposed, make sure bind is 9.11, rebuild isc-dhcp
<ahasenack> that it?
<ahasenack> and that it works, of course
<infinity> ahasenack: Yeah.  Or toss it at a PPA with proposed enabled, if you're lazy.
<ahasenack> ok, thx
<ahasenack> will ping back with results
<infinity> ahasenack: libnss-lwres removed.
<ahasenack> thanks
-queuebot:#ubuntu-release- New: accepted liborcus [amd64] (bionic-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted liborcus [armhf] (bionic-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted liborcus [ppc64el] (bionic-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted liborcus [arm64] (bionic-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted liborcus [s390x] (bionic-proposed) [0.13.2-1]
-queuebot:#ubuntu-release- New: accepted liborcus [i386] (bionic-proposed) [0.13.2-1]
<doko> oSoMoN: ^^^ once that is build, we need a LO no-change upload. or do you want to upload a new package?
<doko> LocutusOfBorg: could you summarize the status of the current ghc transition?
<oSoMoN> doko, I don't have new changes to push, so a no-change upload is fine
<LocutusOfBorg> doko, ready to go, as soon as hoogle fixes the test on arm64
<LocutusOfBorg> I did a no change rebuild half an hour ago
<LocutusOfBorg> to see what changes
-queuebot:#ubuntu-release- Unapproved: preseed (artful-proposed/main) [1.71ubuntu5 => 1.71ubuntu5.1] (core)
-queuebot:#ubuntu-release- Unapproved: preseed (trusty-proposed/main) [1.62ubuntu1.1 => 1.62ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: preseed (xenial-proposed/main) [1.71ubuntu1.1 => 1.71ubuntu1.2] (core)
<doko> LocutusOfBorg: looks like it's entangled with perl / mpfr4
<LocutusOfBorg> doko, I don't agree, sorry!
<LocutusOfBorg> Trying easy from autohinter: gitit/0.12.2.1+dfsg-2build1 haskell-aeson-qq/0.8.2-1build4 haskell-asn1-encoding/0.9.5-1build7
<LocutusOfBorg> look for this hint
<LocutusOfBorg> it is blocked only by a single autopkgtest failure
-queuebot:#ubuntu-release- Unapproved: debian-installer (artful-proposed/main) [20101020ubuntu523.1 => 20101020ubuntu523.2] (core)
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.18 => 20101020ubuntu451.19] (core)
-queuebot:#ubuntu-release- Unapproved: debian-installer (trusty-proposed/main) [20101020ubuntu318.42 => 20101020ubuntu318.43] (core)
-queuebot:#ubuntu-release- Unapproved: accepted lxpanel [source] (xenial-proposed) [0.8.2-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted menu-cache [source] (xenial-proposed) [1.0.1-1ubuntu0.2]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1020.21] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (xenial-proposed) [0.27-0ubuntu25]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1020.21]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [source] (xenial-proposed) [2.2.0.316-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [source] (trusty-proposed) [2.2.0.316-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- New binary: uvp-monitor [armhf] (xenial-proposed/none) [2.2.0.316-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [arm64] (trusty-proposed/none) [2.2.0.316-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [armhf] (trusty-proposed/none) [2.2.0.316-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [arm64] (xenial-proposed/none) [2.2.0.316-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [i386] (xenial-proposed/none) [2.2.0.316-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [amd64] (trusty-proposed/none) [2.2.0.316-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [amd64] (xenial-proposed/none) [2.2.0.316-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: uvp-monitor [i386] (trusty-proposed/none) [2.2.0.316-0ubuntu1~14.04.1] (no packageset)
<ahasenack> infinity: hi, my test with isc-dhcp-server built with bind 9.11.2: https://pastebin.ubuntu.com/26496073/
<ahasenack> took a while because I wanted to use maas for this test, but turns out maas in bionic is broken, and the snap is useless for this test since it ships its own isc-dhcp-server
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu5 => 2.02-2ubuntu5] (core)
<nacc_> slangasek: I think phpunit and phpunit-mock-object may need a bootstrap
<nacc_> slangasek: would you be able to do that or would you rather I upload packages that will build without test and then replace them with the test versions?
<slangasek> nacc_: I'm a bit strapped for time currently, the fast path is probably for you to do it in-archive
<nacc_> slangasek: ok, thanks
<nacc_> slangasek: np
-queuebot:#ubuntu-release- New source: heat-dashboard (bionic-proposed/primary) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [158-1~ubuntu17.10.1 => 160-1~ubuntu17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [158-1~ubuntu16.04.1 => 160-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [160-1~ubuntu17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [160-1~ubuntu16.04.1]
<nacc_> if an AA could demote the php binaries mentioned at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed I think that will allow the eventual removall of php7.1 and clear upt he current unsatisfiable depends in excuses for 7.2
<juliank> oh I did not know there was a html page too
-queuebot:#ubuntu-release- New binary: firefox [amd64] (bionic-proposed/main) [58.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
<nacc_> juliank: yeah it's a bit easier to read sometimes :)
-queuebot:#ubuntu-release- New: accepted uvp-monitor [amd64] (trusty-proposed) [2.2.0.316-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [armhf] (trusty-proposed) [2.2.0.316-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [amd64] (xenial-proposed) [2.2.0.316-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [armhf] (xenial-proposed) [2.2.0.316-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [arm64] (trusty-proposed) [2.2.0.316-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [arm64] (xenial-proposed) [2.2.0.316-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [i386] (trusty-proposed) [2.2.0.316-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- New: accepted uvp-monitor [i386] (xenial-proposed) [2.2.0.316-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: lubuntu-artwork [amd64] (bionic-proposed/universe) [0.70] (no packageset)
<tsimonq2> I would appreciate it if lubuntu-artwork could get a Binary NEW review as soon as possible.
-queuebot:#ubuntu-release- New binary: node-fn-name [amd64] (bionic-proposed/none) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: firefox [i386] (bionic-proposed/main) [58.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
<slangasek> Laney: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/ubuntu/+build/122424 we need to revert this livecd-rootfs change; it breaks all builds because people.c.c is not reachable from LP.
<cjwatson> you could just http://people.canonical.com/~ubuntu-archive -> http://archive-team.internal
<cjwatson> I mean by all means revert for process reasons if you'd rather but that'd be the obvious fix
<cjwatson> oh heh, that last change basically did the opposite of that.  never mind me :-)
<cjwatson> hmm, does it?  there's a *.buildd -> SEEDMIRROR=http://archive-team.internal/seeds/ in there
<cjwatson> I bet that just needs to be *.buildd|*.ppa|*.scalingstack
<slangasek> cjwatson: a revert lets me fix the release pocket a lot more quickly in the face of current autopkgtest queues, at least in theory
#ubuntu-release 2018-02-01
<cjwatson> sure
-queuebot:#ubuntu-release- New binary: firefox [arm64] (bionic-proposed/main) [58.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: livecd-rootfs (bionic-release/primary) [2.490]
-queuebot:#ubuntu-release- New: accepted livecd-rootfs [sync] (bionic-release) [2.490]
<slangasek> cjwatson: is it certain that .scalingstack matches the hostname?  the log only ever shows the local part in output
<cjwatson> *.buildd is legacy but harmless; *.ppa|*.scalingstack I think matches all our current hosts, though I can't be completely certain - I'm going from what LP believes their hostnames to be
<cjwatson> there are unfortunately a couple of different naming schemes, but I'm not aware of anything that wouldn't match
<slangasek> cjwatson: ok; since the autopkgtests also don't catch this, and since *.ppa suggests the hostnames might be different if I triggered a livefs build in a ppa for testing (?), it'd be nice to know with certainty before uploading and potentially having to revert again
<slangasek> I guess I could upload, block in -proposed, and do a PROPOSED=1 test
<cjwatson> "in a ppa" no, not that
<cjwatson> the differences are per-region
<slangasek> ok
<cjwatson> AFAICT due to either prevailing documentation or personal sysadmin preference at the time the region in question was deployed
<cjwatson> PROPOSED=1 has a decent (not 100%) chance of catching any errors though
 * cjwatson sleeps
-queuebot:#ubuntu-release- New: accepted lubuntu-artwork [amd64] (bionic-proposed) [0.70]
-queuebot:#ubuntu-release- New: accepted node-fn-name [amd64] (bionic-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted firefox [amd64] (bionic-proposed) [58.0.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [i386] (bionic-proposed) [58.0.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [arm64] (bionic-proposed) [58.0.1+build1-0ubuntu1]
<tsimonq2> Interesting proposal: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2018-February/017875.html
-queuebot:#ubuntu-release- New binary: togl [amd64] (bionic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: togl [ppc64el] (bionic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: togl [i386] (bionic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: togl [s390x] (bionic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: togl [armhf] (bionic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: togl [arm64] (bionic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted togl [amd64] (bionic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted togl [armhf] (bionic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted togl [ppc64el] (bionic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted togl [arm64] (bionic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted togl [s390x] (bionic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted togl [i386] (bionic-proposed) [2.0-1]
<infinity> tsimonq2: Not particularly, no.
<tsimonq2> infinity: Depends on your opinion of it. It could work well if implemented properly.
<infinity> tsimonq2: "If implemented properly" implies a lot more work.  Curious who plans to staff that.
<tsimonq2> infinity: I'm curious about that as well.
-queuebot:#ubuntu-release- New binary: gdbm [ppc64el] (bionic-proposed/main) [1.14.1-2] (core)
-queuebot:#ubuntu-release- New binary: gdbm [s390x] (bionic-proposed/main) [1.14.1-2] (core)
-queuebot:#ubuntu-release- New binary: gdbm [arm64] (bionic-proposed/main) [1.14.1-2] (core)
-queuebot:#ubuntu-release- New binary: gdbm [i386] (bionic-proposed/main) [1.14.1-2] (core)
-queuebot:#ubuntu-release- New binary: gdbm [armhf] (bionic-proposed/main) [1.14.1-2] (core)
-queuebot:#ubuntu-release- New binary: gdbm [amd64] (bionic-proposed/main) [1.14.1-2] (core)
<ginggs> morning! octave-symbol's autokpgtests have regressed in release on amd64 and ppc64el. octave-ltfat's autopkgtests are now timing out on arm64.  can these be force-badtest'd please?
-queuebot:#ubuntu-release- New: accepted gdbm [amd64] (bionic-proposed) [1.14.1-2]
-queuebot:#ubuntu-release- New: accepted gdbm [armhf] (bionic-proposed) [1.14.1-2]
-queuebot:#ubuntu-release- New: accepted gdbm [ppc64el] (bionic-proposed) [1.14.1-2]
-queuebot:#ubuntu-release- New: accepted gdbm [arm64] (bionic-proposed) [1.14.1-2]
-queuebot:#ubuntu-release- New: accepted gdbm [s390x] (bionic-proposed) [1.14.1-2]
-queuebot:#ubuntu-release- New: accepted gdbm [i386] (bionic-proposed) [1.14.1-2]
<cpaelzer> infinity: you already had a vagrant-libvirt rule so I set you as reviewer of https://code.launchpad.net/~paelzer/britney/hints-ubuntu-libvirt-blocked-s390x-vagrant/+merge/336955
<cpaelzer> but essentially I think the case is clear, so anyone else acking on it would be fine as well
<cpaelzer> also ipxe-qemu-256k-compat is still in bionic's new queue
<cpaelzer> infinity: you mentioned you wanted to take a look, but I assume high prio interrupts stopped you
<infinity> cpaelzer: Yeah, didn't quite get to it yet.
<infinity> cpaelzer: britney hint LGTM, merging.
<cpaelzer> thanks
<cpaelzer> knowing that ipxe-qemu-256k-compa still on your list is fine enough for now
<LocutusOfBorg> can anybody please ignore haskell-hoogle/arm64 test so we can finally see haskell migrate? the test is flaky, I don't see a point in clicking retry until it passes
<LocutusOfBorg> apw, Laney ^^
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/h/haskell-hoogle/bionic/arm64 see the history
<doko> nfs for main? joy ...
<LocutusOfBorg> (and I smell the problem to be around the container stuff, not a flaky package in real environment?)
<infinity> LocutusOfBorg: arm64 autopkgtests aren't in containers.
<infinity> LocutusOfBorg: Probably more to do with arm64 ghc being sketchy.
<LocutusOfBorg> maybe, but at this point I don't care too much honestly
<LocutusOfBorg> it has been that way for years probably
<rbasak> doko: so in Debian they've uploaded mariadb-10.2 to unstable as well, and are preparing mariadb-10.3. They moved some binaries from mariadb-10.1 to mariadb-10.2, leaving mariadb-10.1 somewhat broken in terms of dep8 (one of the tests can no longer run).
<rbasak> I'm not sure how imminent the removal of mariadb-10.1 is.
<doko> <rbasak> doko: if you need mariadb-10.1 through, I think it's appropriate to force-badtest it.
<LocutusOfBorg> infinity, this one is also mostly trivial and will make something migrate https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/335626
<LocutusOfBorg> <3
<LocutusOfBorg> please cleanup consolekit, it is now built only on kfreebsd so we can NBS/remove it?
<infinity> LocutusOfBorg: It has rdeps.
<LocutusOfBorg> nice way to do a transition :)
<infinity> (IOW: I'm not deleting it from -release until that's fixed)
<LocutusOfBorg> sure, it makes a lot of sense :)
<LocutusOfBorg> do you think we can do some systemd ignore on amd64 so we can move forward with perl and bind9 transitions? the new systemd is not building on arm64 probably due to https://bugs.debian.org/888789
<ubot5> Debian bug 888789 in binutils "ld: /usr/lib/crt0-efi-aarch64.o: relocation R_AARCH64_ABS16 against `EFI_SUBSYSTEM' can not be used when making a shared object" [Grave,Open]
<LocutusOfBorg> doko, there is an upstream merged patch, any reason for not having uploaded it?
<doko> I haven't seen any patch yet
<LocutusOfBorg> you might be right, I'm pretty sure I saw it with a link from the debian bug, but I can't find it anymroe
<LocutusOfBorg> will look after coffee
<LocutusOfBorg> infinity, question: I made openmw build on arm64, but this will likely not work anymore because it works only with gl and not with gles
<LocutusOfBorg> can you please remove that package? https://launchpad.net/ubuntu/+source/openmw/0.43.0-3 on arm64? so we can force-sync next time?
<LocutusOfBorg> I don't see a point in making it build if it will not work
<LocutusOfBorg> mitya57, ^^
<doko> LocutusOfBorg: yes, discussed yesterday with ginggs. did you look for rdeps?
<LocutusOfBorg> I can't find any rdep
<LocutusOfBorg> please make perl migrate, seriously
<LocutusOfBorg> gdbm transition is ongoing, and a perl rebuild will make it entangle even more
<ginggs> LocutusOfBorg: do ko did remove it, and tinyxml2 migrated, but then you uploaded 0.43.0-3ubuntu1
<doko> LocutusOfBorg: did you look at the systemd failure triggered by perl?
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (artful-proposed) [3.5-1~ubuntu17.10.2]
<LocutusOfBorg> doko, cryptofoo timeout while starting?
<LocutusOfBorg> varcrypt, whatever it means
<LocutusOfBorg> ginggs, I think the ubuntu1 is the one who did make it migrate... did we do it at the exact same time? (upload+removal)
<LocutusOfBorg> hurray for haskell migration
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.5-1~ubuntu16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (trusty-proposed) [3.5-1~ubuntu14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted php-sabre-vobject-3 [source] (artful-proposed) [3.5.2-1ubuntu0.1]
<ginggs> LocutusOfBorg: from emails, i think tinyxml2 migrated at 2018-01-30 20:54 GMT
<LocutusOfBorg> and openmw 2018-01-30 23:03:50 CET
<LocutusOfBorg> damn, I uploaded because stuff was not migrating, I missed it for one hour
-queuebot:#ubuntu-release- Unapproved: accepted intltool [source] (artful-proposed) [0.51.0-4ubuntu1.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted intltool [source] (xenial-proposed) [0.51.0-2ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (artful-proposed) [2.11.0-2ubuntu17.1]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (xenial-proposed) [2.10.95-0ubuntu2.8]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (trusty-proposed) [2.10.95-0ubuntu2.6~14.04.2]
<doko> ginggs: https://launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/9.0.176-2 isn't migrating
<jbicha> any volunteers to put out a "non-announcement" on the ubuntu-devel-announce list today to let people know that there won't be an Alpha 2 release?
 * rbasak considers copying and pasting that
<ginggs> doko: nvidia-cuda-toolkit not installable due to: libgl1-mesa-glx conflicts libgl1
<ginggs> doko: so the problem lies with mesa?
<ginggs> doko: eztrace-contrib, hwloc-contrib and pycuda are all affected
<doko> tjaalton: ^^^
<tjaalton> huh?
<tjaalton> tseliot: ^?
<doko> mesa?
<tseliot> I'm pretty sure I didn't change anything there
<tjaalton> libgl1-mesa-glx has conflicted with libgl1 for a long time
<tseliot> not yet, at least
<tjaalton> it's C/R/P: libgl1
<doko> see also:
<doko> libglvnd (0.2.999+git20170802-2 to 1.0.0-2)
<doko> Maintainer: Debian X Strike Force
<doko> Section: universe/misc
<doko> 5 days old
<doko> libegl1/amd64 unsatisfiable Depends: libegl-mesa0 | libegl-vendor
<doko> libglx0/amd64 unsatisfiable Depends: libglx-mesa0 | libglx-vendor
<tseliot> tjaalton: it looks like fun ^ ;)
<tjaalton> libglvnd has been there since august
<tjaalton> it'
<tjaalton> it shouldn't be causing issues
<ginggs> tjaalton tseliot: this has been like this for a while - at least end December, nvidia-cuda-toolkit 9.0.176-1 did not migrate either
<tjaalton> synced from debian?
<tjaalton> not going to work then
<tjaalton> most likely
<tjaalton> debian migrated to libglvnd already, we will in a week or two
<rbasak> Could someone force-badtest dovecot/1:2.2.33.2-1ubuntu1/armhf please? It's the same racy pattern with the dovecot tests as ever.
<LocutusOfBorg> cjwatson, please block haskell autosync again, now the switch to 8.2 might be imminent in some days :)
<ginggs> tjaalton: <tjaalton> synced from debian? - is what synced from debian?
<tjaalton> nvidia-cuda-toolkit 9.0.176-2
<tjaalton> if it depends on the debian nvidia driver model, it's not going to work on ubuntu
<ginggs> tjaalton: ok, yes it is
<tjaalton> tseliot: don't we have cuda too?
<tjaalton> so this should be blacklisted, I think
<ginggs> tjaalton: anbe, tseliot and i made it work with the ubuntu driver model too
<tjaalton> something is missing then
<cjwatson> LocutusOfBorg: Done.  It's a fairly simple sync-blacklist change FWIW, any AA should be able to look at the blacklist history and dig out what's necessary
<tjaalton> ginggs: if you are not able to install on a chroot with bionic-proposed enabled, then try with ppa:canonical-x/testing
<tjaalton> ginggs: if that works, then either change the package or wait until glvnd has landed
<LocutusOfBorg> oh nice thanks! I was wondering if it was something that was under your only control
<cjwatson> LocutusOfBorg: it used to be a slightly more involved change to auto-sync, but I fixed that ages ago
<LocutusOfBorg> ack thanks
<LocutusOfBorg> BTW I won't give up for ghc 8.2/bionic, but only if it settles down in Debian before
<tjaalton> ginggs: I don't see anything in the package blocking it's install
<ginggs> tjaalton: i was able to install libgl1 and libglx0 from ppa:canonical-x/testing
<tjaalton> ginggs: on a clean chroot, install libgl1-mesa-glx, then install nvidia-cuda-toolkit. no problems
<ginggs> but not sure what that tells us
<tjaalton> this was with pure bionic-proposed
<tjaalton> no ppa
<tjaalton> so whatever says there are conflicts is wrong
<ginggs> chdist aptitude bionic build-dep pycuda
<ginggs> libgl1-mesa-glx: Conflicts: libgl1 but 1.0.0-2 is to be installed
<tjaalton> with just proposed?
<tjaalton> not here
<ginggs> <tjaalton> with just proposed? - not sure what you mean here
<tjaalton> use a clean chroot
<tjaalton> don't enable the ppa
<tjaalton> enable proposed
<tjaalton> you didn't test the first case I asked?
<tjaalton> 16:29 < tjaalton> ginggs: if you are not able to install on a chroot with bionic-proposed enabled, then
<tjaalton>                   try with ppa:canonical-x/testing
<tjaalton> just using -proposed works fine here
<ginggs> the output i showed is from 'chdist aptitude bionic build-dep pycuda'
<ginggs> with bionic-proposed enable in .chdist/etc/apt/sources.list
<tjaalton> I have no problem running 'apt build-dep pycuda'
<tjaalton> works fine
<tjaalton> aha
<tjaalton> works fine if libgl1-mesa-glx is already installed
<tjaalton> so, remove libglvnd from proposed
<tjaalton> it'll be fixed later anyway
<ginggs> <tjaalton> so, remove libglvnd from proposed <- doko
<ginggs> thanks tjaalton
<tjaalton> the current version won't work on ubuntu as-is because it refers to mesa version where debian migrated
<tseliot> yes, we'll be moving to glvnd soon
<tjaalton> clean chroot, enable the testing ppa; apt build-dep pycuda works
<tjaalton> anyway, we'll get there before FF
<tjaalton> libglvnd can be removed from -proposed for now
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20171129+dfsg1-0ubuntu1~14.04.0 => 20180129+dfsg1-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20171129+dfsg1-0ubuntu1~16.04.0 => 20180129+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (artful-proposed/universe) [20171129+dfsg1-0ubuntu1~17.10.0 => 20180129+dfsg1-0ubuntu1~17.10.0] (ubuntu-cloud)
<slangasek> doko: fwiw I noticed that you had demoted packages that only Recommends: python-imaging rather than Depends:; I'm going to readd these since these are allowed per proposed-migration
<doko> slangasek: hmm, .... I had removed the packages now. not sure, which ones will migrate
<slangasek> doko: it's fine, I'm re-adding, just wanted to give you a heads-up
<doko> python-aalib python-trml2pdf streamtuner2 trac-diavisview trac-odtexport trac-wikiprint twms utopia-documents weboob cfv comix fofix-dfsg griffith htmlgen ibid impressive impressive-display mcomix oboinus phatch photon pisa psychopy
<doko> these were removed
<slangasek> cfv, pisa I'm readding
<doko> ta
-queuebot:#ubuntu-release- Unapproved: accepted preseed [source] (artful-proposed) [1.71ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (artful-proposed) [20101020ubuntu523.2]
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (artful-proposed) [1:10.0-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.8]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (xenial-proposed) [0.8.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: budgie-extras [amd64] (bionic-proposed/universe) [0.4.1-0ubuntu1] (personal-fossfreedom)
<slangasek> Laney: did you find anything that explained arm64 autopkgtest queue flatlining last weekend? because it seems to be doing it again
-queuebot:#ubuntu-release- Unapproved: accepted qttools-opensource-src [source] (xenial-proposed) [5.5.1-3ubuntu0.1]
-queuebot:#ubuntu-release- New binary: budgie-artwork [amd64] (bionic-proposed/universe) [0.9.0] (personal-fossfreedom)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (bionic-proposed/universe) [1.23.0+dfsg1+llvm-0ubuntu1] (no packageset)
<nacc> slangasek: did you figure out what is going on the with arm builders
<slangasek> nacc: I wasn't aware anything was going on with arm builders; context?
<nacc> slangasek: or maybe i'm just missing their queues being rather long?
<nacc> slangasek: i saw you mentioned it above for the dep8 queues
<nacc> but perhaps those are separate?
<slangasek> nacc: dep8 queues != builders
<nacc> ah ok
<nacc> i assumed they were the same population of machines
<slangasek> they both run on scalingstack, so there can be problems affecting both; but so far I've only noticed a symptom on autopkgtest
<slangasek> and maybe I should highlight wgrant so we can compare notes
<nacc> i think i'm just hitting the builders while ruby is too
<slangasek> GOOD NEWS EVERYONE, autosynced ruby transition
<tsimonq2> SO AMAZINGLY WONDERFUL.
<tsimonq2> Now, quick, someone upload Perl!
<slangasek> it's already there, if somebody uploads it again before it transitions I will tele-murderize
<tsimonq2> slangasek: ...why in the hell isn't something huge like this blacklisted from autosync?!?
<Laney> slangasek: Not really here but things seem to be progressing albeit very slowly
<Laney> It's possible I tipped the cloud over the edge when moving the armhf workers over there --- IS might be able to tell you more (and maybe hurry up adding some of the bos01 capacity there)
<slangasek> tsimonq2: because that just moves the pain around
<tsimonq2> slangasek: It delays the pain until sane times when our infra isn't crippled :P
<tsimonq2> Or am I wrong here?
<slangasek> tsimonq2: "delays the pain" has the risk of causing us to miss it completely for a release cycle and ship out-of-date stuff instead
<slangasek> anyway, changing ruby-defaults is not automatically a huge transition right away
<tsimonq2> slangasek: ah ok
-queuebot:#ubuntu-release- New binary: liblivemedia [ppc64el] (bionic-proposed/universe) [2018.01.29-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [ppc64el] (bionic-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblivemedia [s390x] (bionic-proposed/universe) [2018.01.29-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [s390x] (bionic-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: salt (artful-proposed/universe) [2016.11.5+ds-1 => 2017.7.2+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [armhf] (bionic-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblivemedia [arm64] (bionic-proposed/universe) [2018.01.29-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [arm64] (bionic-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblivemedia [armhf] (bionic-proposed/universe) [2018.01.29-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [amd64] (bionic-proposed/universe) [2018.01.29-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [amd64] (bionic-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [i386] (bionic-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblivemedia [i386] (bionic-proposed/universe) [2018.01.29-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: node-buf-compare [amd64] (bionic-proposed/universe) [1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: streamtuner2 [amd64] (bionic-proposed/universe) [2.2.0+dfsg-1] (no packageset)
#ubuntu-release 2018-02-02
<slangasek> trying: perl
<slangasek> skipped: perl (50, 176, 3)
<slangasek>     got: 19+0: a-4:a-3:a-3:i-3:p-3:s-3
<slangasek>     * amd64: libencode-perl
<slangasek> stab
<tsimonq2> (hah, and I was joking!)
<slangasek> a minor delay, just needs britney stabbing
-queuebot:#ubuntu-release- New binary: nanopass-framework-scheme [amd64] (bionic-proposed/universe) [1.9+git20160429.g1f7e80b-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (xenial-proposed) [1.78ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (trusty-proposed) [1.69ubuntu1.4]
<slangasek> there we are, perl is in
<cjwatson> libsodium too, good good
<wgrant> slangasek: What's the ARM scalingstack trouble you were seeing?
-queuebot:#ubuntu-release- New: accepted budgie-artwork [amd64] (bionic-proposed) [0.9.0]
-queuebot:#ubuntu-release- New: accepted budgie-extras [amd64] (bionic-proposed) [0.4.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libplacebo [amd64] (bionic-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [armhf] (bionic-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [ppc64el] (bionic-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted nanopass-framework-scheme [amd64] (bionic-proposed) [1.9+git20160429.g1f7e80b-1build1]
-queuebot:#ubuntu-release- New: accepted streamtuner2 [amd64] (bionic-proposed) [2.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libplacebo [arm64] (bionic-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [s390x] (bionic-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [i386] (bionic-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted node-buf-compare [amd64] (bionic-proposed) [1.0.1-2]
-queuebot:#ubuntu-release- New: accepted liblivemedia [amd64] (bionic-proposed) [2018.01.29-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [armhf] (bionic-proposed) [2018.01.29-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [ppc64el] (bionic-proposed) [2018.01.29-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [arm64] (bionic-proposed) [2018.01.29-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [s390x] (bionic-proposed) [2018.01.29-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [i386] (bionic-proposed) [2018.01.29-1]
<slangasek> wgrant: arm64 runners are not keeping up with other archs, where they were previously.  I haven't had a chance to dig into it, and we don't exactly have good metrics to show if this is API slowness vs failed attempts vs the arch just having longer-running jobs currently at the top of the queue (which might be the case currently, looks like we're into the KDE packages)
<cpaelzer> infinity: (or anyone else who can take the time and ahs the powers) - ping on status of src:ipxe-qemu-256k-compat in new queue?
<cpaelzer> it blocks qemu (obviously) and that in turn starts to collect a trail of things blocked by qemu in turn
-queuebot:#ubuntu-release- New binary: bitseq [s390x] (bionic-proposed/universe) [0.7.5+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitseq [amd64] (bionic-proposed/universe) [0.7.5+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitseq [ppc64el] (bionic-proposed/universe) [0.7.5+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitseq [i386] (bionic-proposed/universe) [0.7.5+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitseq [arm64] (bionic-proposed/universe) [0.7.5+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitseq [armhf] (bionic-proposed/universe) [0.7.5+dfsg-3ubuntu1] (no packageset)
<acheronuk> hi, if any archive admins are able to, could this be looked at please? https://bugs.launchpad.net/ubuntu/+source/kdevplatform/+bug/1746959
<ubot5> Ubuntu bug 1746959 in kdevplatform (Ubuntu Bionic) "Please remove kdevplatform from bionic" [Undecided,New]
<acheronuk> thanks :0
<acheronuk> ummm :)
<LocutusOfBorg> gdbm transition in some minutes
<LocutusOfBorg> maybe better wait for ruby
<acheronuk> LocutusOfBorg: some vlc stuff uninstallable in tests? that is ruby?
<LocutusOfBorg> who knows? probably
<LocutusOfBorg> even perl/gdbm needs rebuilds, but I don't know if I can entangle it (probably I should, because it is already entangled with ruby
<acheronuk> gah. maybe I should just hide for the weekend, and just build nice things in ppas for artful backports!
<LocutusOfBorg> xnox, can I do a ubuntu-core-meta no change rebuild against new gdbm=
<LocutusOfBorg> ?
-queuebot:#ubuntu-release- New: accepted bitseq [amd64] (bionic-proposed) [0.7.5+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bitseq [armhf] (bionic-proposed) [0.7.5+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bitseq [ppc64el] (bionic-proposed) [0.7.5+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bitseq [arm64] (bionic-proposed) [0.7.5+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bitseq [s390x] (bionic-proposed) [0.7.5+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bitseq [i386] (bionic-proposed) [0.7.5+dfsg-3ubuntu1]
<LocutusOfBorg> xnox, can I upload this? https://launchpadlibrarian.net/355519874/buildlog_ubuntu-bionic-amd64.ubuntu-core-meta_0.6.18_BUILDING.txt.gz
<infinity> Is it not generated from seeds, like every other meta?
<infinity> It sure is.
<infinity> LocutusOfBorg: What are you proposing uploading? :P
 * infinity does the update sanely.
<doko> LocutusOfBorg: where are perl & ruby entangled?
<acheronuk> infinity: hi. are you able to do that kdevplaform removal? if not, no worries, I'll catch someone else later
<infinity> acheronuk: Looking.
<infinity> acheronuk: Looks sane to me.
<LocutusOfBorg> doko, perl and ruby -> gdbm
<LocutusOfBorg> problem is no-change ruby rebuild fails
<LocutusOfBorg> (due to tzdata or whatever
<LocutusOfBorg> sorry infinity I was trying to copypaste the debdiff, not the log -.-'
<LocutusOfBorg> https://launchpadlibrarian.net/355519854/ubuntu-core-meta_0.6.17_0.6.18.diff.gz
<LocutusOfBorg> sed s/libgdbm3/libgdbm5/g
<infinity> LocutusOfBorg: Yeah, like I said, I'm doing the update correctly.
<LocutusOfBorg> thanks :) I didn't upload because I remember I have to prod people for that
<LocutusOfBorg> and moreover I'm not sure if we can start gdbm rebuilds or not
<infinity> LocutusOfBorg: Updating a meta by directly updating its data files is always wrong.
<ahasenack> infinity: hi, good morning/afternoon, not sure if you saw my ping the day before yesterday about my isc-dhcp testing with new bind9 9.11
<ahasenack> I had the day off yesterday
<LocutusOfBorg> sure, you have to regenerate them, but since I don't (want to) know, I prefer people doing that, I don't want to mess with your pet seeds :p
<infinity> ahasenack: I saw, and uploaded a rebuild.
<ahasenack> infinity: oh, thanks a bunch
<infinity> ahasenack: It's just stuck on some autopkgtests sucking.
<ahasenack> systemd, hm
<infinity> LocutusOfBorg: Okay, let me put it differently, if the meta and the seeds are desynced, you did something wrong.
<infinity> LocutusOfBorg: So, "can I upload this hack" was the wrong question.
<LocutusOfBorg> oh I got it now, for sure I did use the wrong words :)
<LocutusOfBorg> I usually don't touch native packages for no-change rebuilds, the golden rule should apply :)
<LocutusOfBorg> I'm afraid we will need a no change perl rebuild :/
<infinity> How is that a problem?
<acheronuk> infinity: thanks for removing :)
<apw> presumably because it kills adt for a year
<infinity> It's not actually that bad.
<infinity> It's lots of tests, but they're mostly tiny.
<infinity> glibc is much worse.
<LocutusOfBorg> it is the worse package I usually touch :p
<infinity> And people keep uploading that when I prefer to wait. :P
<LocutusOfBorg> one day Laney will come to my home and knock the door :p
<infinity> apw: Speaking of britney things, we should migrate your kernel.
<LocutusOfBorg> now that I have some release team folks, since 16.04 is completely virtualbox broken
<LocutusOfBorg> and vbox 5.2 in xenial is a no-go, is it possible to request an update from 5.0 to 5.1?
<LocutusOfBorg> spectre foo messed completely up the virtualization, and we don't have a fix for 5.0, and I receive 10-15 emails everyday of people complaining
<LocutusOfBorg> (new kernel in hwe is incompatible with vboxdrv from 5.0 too)
<LocutusOfBorg> 5.2 can't build because of qtbase oldness
<LocutusOfBorg> 5.1 has been released some days ago, is the best/only candidate
-queuebot:#ubuntu-release- Unapproved: uvp-monitor (trusty-proposed/universe) [2.2.0.316-0ubuntu1~14.04.1 => 2.2.0.316-0ubuntu1~14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected uvp-monitor [source] (trusty-proposed) [2.2.0.316-0ubuntu1~14.04.2]
-queuebot:#ubuntu-release- Unapproved: uvp-monitor (trusty-proposed/universe) [2.2.0.316-0ubuntu1~14.04.1 => 2.2.0.316-0ubuntu1~14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted uvp-monitor [source] (trusty-proposed) [2.2.0.316-0ubuntu1~14.04.2]
<doko> LocutusOfBorg: no, they are not. the very same versions are already in the release pocket
<LocutusOfBorg> doko, context sorry?
<doko> "<LocutusOfBorg> doko, perl and ruby -> gdbm"
<LocutusOfBorg> we still have to issue the rebuilds
 * LocutusOfBorg goes ahead and triggers them
<doko> LocutusOfBorg: and ruby2.3 has gdbm test failures too
<LocutusOfBorg> yes we know
<LocutusOfBorg> but 2.3 should die with the current ruby transition AFAIK
<LocutusOfBorg> in case it is blocked, I'll try to fix the failures, should be relatively easy according to the git log
-queuebot:#ubuntu-release- Unapproved: update-manager (artful-proposed/main) [1:17.10.12 => 1:17.10.13] (core)
<LocutusOfBorg> nacc, stealing freeradius
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.10 => 1:16.04.11] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (trusty-proposed/main) [1:0.196.24 => 1:0.196.25] (core)
<doko> LocutusOfBorg: thanks so many times for the perl rebuild
<LocutusOfBorg> I waited 4 months to do gdbm transition, there is no good time to rebuild perl, never
<LocutusOfBorg> (we discussed this some lines above)
<LocutusOfBorg> and we need to get rid to the old gdbm3 on next chroot generation, so sooner is better, otherwise we will have a lot of autopkgtest failures due to the mix
<nacc> LocutusOfBorg: ok
<LocutusOfBorg> nacc, this was for gdbm transition, feel free to steal it again lol :)
<LocutusOfBorg> any AA, can you please remove/kick to proposed gnu-smalltalk? Updating gnu-smalltalk introduces new bugs: #868545, #871077. <-- needs a sourceful upload anyway, out from buster
<ubot5> bug 871077 in Odoo Addons (MOVED TO GITHUB) "[TRUNK] With multi_currency enviroment in vouchers, wrong lines on voucher" [Medium,Invalid] https://launchpad.net/bugs/871077
<ubot5> bug 868545 in flashplugin-nonfree (Ubuntu Oneiric) "[UPDATE] Adobe flash 11 is out" [Undecided,Fix released] https://launchpad.net/bugs/868545
<nacc> LocutusOfBorg: heh, i'm pretty well buried in PHP :)
<infinity> LocutusOfBorg: Or, fix the build, with the patches in said bug.
<infinity> LocutusOfBorg: Testing patches here.
 * LocutusOfBorg tries
<LocutusOfBorg> oh thanks!
<LocutusOfBorg> can you please NMU to debian too?
<infinity> They already removed it from testing.  I'm sure the maintainer will fix it if he cares.
<LocutusOfBorg> I already fixed avahi, and I'll play the ruby mess probably
<infinity> Or Adrian will.
<LocutusOfBorg> ok I'll do it then
<LocutusOfBorg> I don't want another delta
<LocutusOfBorg> configure: error: Synchronization primitives not found, please use a newer compiler.
<infinity> LocutusOfBorg: As Adrian explains, that's just the compiler erroring out because of how it was called.
<LocutusOfBorg> I was doing pbuilder to the unpatched version, it has been a long week :/
<infinity> LocutusOfBorg: Welp, fixed version uploaded to Ubuntu, if you just want to steal that. :P
<LocutusOfBorg> already done, I was just using the wrong one to test loool
<infinity> LocutusOfBorg: The other reason I'm not doing the Debian NMU is that I don't feel the urge to fix the OTHER RC bug (overlapping files in dbgsym packages).
<infinity> And I couldn't care less about that bug in Ubuntu (well, not enough to deem it RC).
<LocutusOfBorg> I don't care too, but honestly, having it buildable is nice to remove the old cruft, even if one RC is still there
<elopio> hey Laney, the github retry autopkgtest script is failing to verify a certificate: https://paste.ubuntu.com/26506845/
<elopio> do you know anything about this?
<tsimonq2> slangasek: Was there any ever progress about arm64 running slowly?
<slangasek> tsimonq2: currently my educated guess is that arm64 is slower to churn through the queue because there are currently a bunch of long-running tests at the front of the queue (kde)
<acheronuk> elopio: I was getting with the archive tools retry script:  WARNING: cannot verify autopkgtest.ubuntu.com's certificate, issued by âCN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=USâ
<tsimonq2> slangasek: thanks for reminding me I need to look into making that not be a thimg
<tsimonq2> s/thimg/thing/
 * tsimonq2 puts on todolist
<elopio> acheronuk: not just me then :)
<acheronuk> elopio: looks like certificate started with a new one on '1 February 2018', so scripts don't recognise it's validity
<tsimonq2> slangasek: So it's the KDE stuff that was uploaded at least a week ago? wtf, how did it take that long to get to it?
<slangasek> tsimonq2: because nothing at all was being processed until we had security updates for arm64
<tsimonq2> slangasek: How long ago was that?
<slangasek> tsimonq2: whenever scrollback says it happened :)
<tsimonq2> slangasek: It's been more than a few days, right?
<slangasek> yes
<slangasek> and there's been much more than a few days backlog
-queuebot:#ubuntu-release- Unapproved: apparmor (trusty-proposed/main) [2.10.95-0ubuntu2.6~14.04.2 => 2.10.95-0ubuntu2.6~14.04.3] (core)
<slashd> sil2100, ^ fyi
<tsimonq2> Right so I guess my question is, was arm64 enabled last or is it just slow?
<tsimonq2> slangasek: ^
<slangasek> it is slower than ppc64el and s390x
<slangasek> there were also some infrastructure issues last weekend that were affecting one arch or another
-queuebot:#ubuntu-release- New binary: node-acorn-object-spread [amd64] (bionic-proposed/universe) [3.1.0-2] (no packageset)
<tsimonq2> ok
<slangasek> note that s390x has also not zeroed its queue in the last week, it just gets less attention for this fact because it's 3-4k smaller than the arm64 queue
<infinity> arm64 is also at half capacity right now.
<infinity> slangasek: ^
<slangasek> not to my understanding
<infinity> slangasek: Unless that was fixed in the last few hours, it's still true.
<slangasek> there's a rolling migration of compute, which I'm looped in on wrt autopkgtest
<infinity> slangasek: bos01 was being redeployed, and the compute wasn't moved to bos02.
<infinity> slangasek: Unless it was moved very recently.
<infinity> slangasek: So, maybe more appropriately, it was running at below full capacity, and may still be? :P
<slangasek> infinity: bos01 hasn't been redeployed yet, the compute is being moved first
<slangasek> yes, we're at less than full capacity
<slangasek> however, that doesn't appear to be preventing autopkgtest from using its quota
<infinity> Fair enough.
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (trusty-proposed) [2.10.95-0ubuntu2.6~14.04.3]
<slangasek> W: ipxe-qemu-256k-compat source: missing-field-in-dep5-copyright copyright (paragraph at line 5)
<slangasek> I: ipxe-qemu-256k-compat source: wildcard-matches-nothing-in-dep5-copyright src/drivers/net/e1000/* (paragraph at line 8)
<slangasek> I: ipxe-qemu-256k-compat source: wildcard-matches-nothing-in-dep5-copyright src/drivers/net/e1000e/* (paragraph at line 8)
<slangasek> I: ipxe-qemu-256k-compat source: wildcard-matches-nothing-in-dep5-copyright src/drivers/net/igb/* (paragraph at line 8)
<slangasek> I: ipxe-qemu-256k-compat source: wildcard-matches-nothing-in-dep5-copyright ... use --no-tag-display-limit to see all (or pipe to a file/program)
<slangasek> cpaelzer: ^^
<slangasek> cpaelzer: debian/copyright is definitely going to need cleanup
<tsimonq2> infinity, slangasek: Is there a process I can follow to request that some custom cdimage CSS be applied for Lubuntu in the same way Kubuntu does?
<tsimonq2> I know there's a part on the tooling
<slangasek> tsimonq2: give us a file to install as http://releases.ubuntu.com/include/lubuntu.css , and a patch against lp:ubuntu-cdimage to use it
-queuebot:#ubuntu-release- New: accepted ipxe-qemu-256k-compat [source] (bionic-proposed) [1.0.0+git-20150424.a25a16d-0ubuntu1]
<tsimonq2> slangasek: ok, my artwork guy put it under a Git repo, it's available at lp:~lubuntu-art/+git/cdimage-css
-queuebot:#ubuntu-release- New binary: ipxe-qemu-256k-compat [amd64] (bionic-proposed/universe) [1.0.0+git-20150424.a25a16d-0ubuntu1] (no packageset)
<slangasek> tsimonq2: I don't think it's a good idea for the CSS to reference images from another site that's separately administered; I think we should do something like the kubuntu-img directory as seen in kubuntu.css
<slangasek> gdbm ugh
<tsimonq2> slangasek: I'll ask him to put the file in the Git repo if that's OK? (Maybe the whole repo can be deployed.)
<slangasek> tsimonq2: the css file itself will also need modified
<slangasek> for relative urls instead
<tsimonq2> slangasek: OK
<tsimonq2> slangasek: better?
<slangasek> tsimonq2: yes; I think unlike kubuntu we should deploy this only to cdimage.ubuntu.com (since lubuntu itself has never been on releases).  Are you happy with http://cdimage.ubuntu.com/include/lubuntu as a path for this repo?
<tsimonq2> slangasek: Works for me.
<tsimonq2> slangasek: Let's say we want to make CSS changes down the road. Can it be set up (using cron or whatever) to pull any changes, or would you prefer to do that manually?
<slangasek> tsimonq2: we would not automate the rollout (we don't for any of the rest of it), but it would just be a ping to the cdimage team to have it updated
<tsimonq2> slangasek: ok, awesome
<tsimonq2> slangasek: MP proposed for when it's deployed
<slangasek> tsimonq2: syntax tuning suggestion on mp
<tsimonq2> slangasek: done
<slangasek> tsimonq2: so run-tests passed for you? you didn't get linting errors about over-long lines in test_tree.py?
<slangasek> tsimonq2: (fixed and pushed)
<tsimonq2> slangasek: to be fair I only checked the first iteration
<tsimonq2> slangasek: but thanks
<slangasek> tsimonq2: the over-long lines were in the test cases, which didn't change AFAIK
<slangasek> tsimonq2: and manually running a lubuntu build now
<tsimonq2> slangasek: hm ok
<tsimonq2> slangasek: alright, is this something you'll be able to deploy on all of Lubuntu's file indexes (for lack of a better term) or just anything from here on out?
<tsimonq2> (consistency is nice :) )
<slangasek> tsimonq2: for manual changes to existing indices, please file a bug against ubuntu-cdimage
-queuebot:#ubuntu-release- Unapproved: horizon (artful-proposed/main) [3:12.0.1-0ubuntu1 => 3:12.0.2-0ubuntu1] (openstack, ubuntu-server)
<tsimonq2> slangasek: ack, thanks
<tsimonq2> slangasek: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1747083
<ubot5> Ubuntu bug 1747083 in Ubuntu CD Images "Lubuntu's cdimage indexes should be updated with new CSS" [Undecided,New]
<tsimonq2> (indexes or indices?)
<tsimonq2> (aha, indices)
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.1-46-g7acc9e68-0ubuntu1~17.10.1 => 17.2-30-gf7deaf15-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<tsimonq2> slangasek: Also, why is http://cdimage.ubuntu.com/lubuntu/artful/ still present?
<slangasek> tsimonq2: because those are the daily builds that became 17.10.1, they don't automatically get cleaned up
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.1-46-g7acc9e68-0ubuntu1~16.04.1 => 17.2-30-gf7deaf15-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<tsimonq2> slangasek: ah ok
-queuebot:#ubuntu-release- New: accepted ipxe-qemu-256k-compat [amd64] (bionic-proposed) [1.0.0+git-20150424.a25a16d-0ubuntu1]
<nacc> cpaelzer: --^
<slangasek> tsimonq2: looks like the lubuntu daily test build failed
<slangasek> looks like it's a bind9 package priority issue, lessee
<slangasek> ah, NBS
<slangasek> anyway, removing etc
<nacc> slangasek: hrm, i woder about the autodep8 dep8 failure (i'm just trawllig while i wait for rebuilds to go through). Timeout o armhf with dpkg-buildpackage. Would something like that be possibly transient?
<slangasek> nacc: what package are you talking about?
<LocutusOfBorg> infinity, is it possible to do a debhelper merge please? apr-utils is failing because of it
<slangasek> nacc: http://autopkgtest.ubuntu.com/packages/a/autodep8/bionic/armhf shows an 'error' that should be retried, is that what you mean?
<slangasek> and somebody actually beat me to the NBS
<nacc> slangasek: i did mean src:autodep8 and i see a 'fail' only on armhf in excuses
<slangasek> nacc: yes, clicking through shows it's an error that should be retried
<nacc> slangasek: right, just confirming; did you already retrigger?
<slangasek> I did not
<slangasek> and I have not checked if someone else did
<nacc> slangasek: also, is there a good way for me to entangel the phpunit packages that are all in proposed? they all need to migrate together and probably all need to be tested together
<nacc> slangasek: ok
<nacc> slangasek: i'll check the queus
<slangasek> tested together> you can set them all as triggers when retrying through request.cgi
<nacc> slangasek: http://autopkgtest.ubuntu.com/packages/a/autodep8/bionic/armhf looks good there
<nacc> slangasek: yeah, i guess that's easiest (i'll need to iterate all sources and all the combinations of which srcpkg i care about, right?)
<slangasek> nacc: by checking if someone retriggered, I meant checking if there's a pending request currently in the queue at http://autopkgtest.ubuntu.com/running
<slangasek> (since we still don't consolidate duplicate requests)
<nacc> slangasek: ah ok
 * tsimonq2 wonders if duplication prevention could be easily implementrd
<slangasek> tsimonq2: not "easily" because of the nature of rabbitmq
<tsimonq2> slangasek: (I have not looked at the code at all but...) it has to add to the queue, why can't it read the queue?
<slangasek> tsimonq2: it can. it's just not as "easy" as if you had dedupe on insert
<slangasek> it's absolutely possible
<tsimonq2> slangasek: think I'd be duping work if I gave it a go?
<slangasek> tsimonq2: LP: #1686929, have at it
<ubot5> Launchpad bug 1686929 in Auto Package Testing "Duplicate tests can be queued" [Undecided,New] https://launchpad.net/bugs/1686929
<tsimonq2> slangasek: thanks
<nacc> doko: fyi, down to only 8 packages to transitionn for 7.2 now (although there is some serious breakage from phpunit i'll need to patch in na few places, i thinkn)
-queuebot:#ubuntu-release- New binary: chezscheme [i386] (bionic-proposed/universe) [9.5+dfsg-2] (no packageset)
<slangasek> tsimonq2: http://cdimage.ubuntu.com/lubuntu/daily-live/current/ ?
<tsimonq2> slangasek: yes :D
<doko> nacc: ta, appreciated. however we now have the mess about everything entangled with everything
#ubuntu-release 2018-02-03
<nacc> doko: yes, i konw :)
<nacc> i needed to get the rebuilds in so that php7.1 stops getting installed automatically as a dep
<nacc> a lot of the failures are mixed envs
<nacc> php7.2 should migrate soon(ish) once arm64 catches up
<nacc> that will clear a lot of them, and then i'll work on the phpunit stuff meanwhile
<tsimonq2> slangasek: please git pull the repo on cdimage, Raf (artwork guy) found a bug
<slangasek> tsimonq2: done
<tsimonq2> slangasek: thanks
<tsimonq2> slangasek: You sure? I'm not seeing the changes from https://git.launchpad.net/~lubuntu-art/+git/cdimage-css/commit/?id=8b15240d7fb57304a64f1dcec564923bcb02424f deployed...
<slangasek> tsimonq2: I pulled but didn't push to mirrors; one sec
<slangasek> tsimonq2: more done
<tsimonq2> slangasek: aha, there we go, thanks again :)
<tsimonq2> slangasek: So were those issues solved with the Lubuntu ISO?
<slangasek> tsimonq2: they should be; I didn't retrigger a build
<tsimonq2> slangasek: ok
<tsimonq2> slangasek: ack
<tsimonq2> (grr didn't see I replied twice)
<tsimonq2> slangasek: so about the earlier bug, filter-amqp seems to do a lot of the same things... iterating on the queue given a search phrase and deleting items. Am I wrong there?
<slangasek> tsimonq2: it does
<tsimonq2> slangasek: aha :)
<tsimonq2> slangasek: I'll look on it after I get some sleep; have a good night.
<tsimonq2> s/on/at/ bahh
-queuebot:#ubuntu-release- New binary: symfony [amd64] (bionic-proposed/universe) [3.4.3+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-acorn-object-spread [amd64] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted symfony [amd64] (bionic-proposed) [3.4.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted chezscheme [i386] (bionic-proposed) [9.5+dfsg-2]
<xnox> slangasek, please undelete trust-store
<xnox> slangasek, your RM comments are incomplete, in light of future snapd/pulseaudio/upstream work =/
<xnox> slangasek, and i hope your pulseaudio upload did not remove/drop snapd & apparmor patches
 * xnox should double check
 * xnox was about to seed trust-store back in on thrusday, because of comments from the security team.....
<redwolf> infinity, can you please pull the changes I've made to the Lubuntu cdimage includes and push to mirrors?
<redwolf> thanks in advance
<tsimonq2> slangasek: ^
<tsimonq2> infinity, cyphermox: This bug is pretty peculiar: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1746807
<ubot5> Ubuntu bug 1746807 in debian-installer (Ubuntu) "18.04 daily installer fails missing kernel" [Undecided,Confirmed]
<tsimonq2> Doesn't happen with Ubuntu Server.
<infinity> tsimonq2: Tell your testers to inlcude logs when submitting installer bugs, please.
<tsimonq2> infinity: Will do.
<slangasek> xnox: nack on undeleting; if there is an upstream as you say, they can upload it with a fix for the FTBFS and I am happy to fast-track it back into the archive
<slangasek> xnox: and no patches were dropped, only the build-dep
<slangasek> redwolf, tsimonq2, infinity: css updated
<tsimonq2> slangasek: thanks
<tsimonq2> slangasek: Mind taking a look when you can? It should be the last of the customizations for now: https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/add-lubuntu-css/+merge/337123
<slangasek> tsimonq2: yep, in my queue
<tsimonq2> slangasek: kthx
-queuebot:#ubuntu-release- New binary: pytest-doctestplus [s390x] (bionic-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-openfiles [s390x] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-doctestplus [ppc64el] (bionic-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-openfiles [ppc64el] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ci-info [amd64] (bionic-proposed/none) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-doctestplus [i386] (bionic-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: impressive [amd64] (bionic-proposed/none) [0.11.2-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-doctestplus [armhf] (bionic-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-doctestplus [arm64] (bionic-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jboss-threads [amd64] (bionic-proposed/none) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-openfiles [amd64] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-openfiles [armhf] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-doctestplus [amd64] (bionic-proposed/none) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-openfiles [i386] (bionic-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-openfiles [arm64] (bionic-proposed/none) [0.2.0-1] (no packageset)
#ubuntu-release 2018-02-04
-queuebot:#ubuntu-release- New binary: open-adventure [amd64] (bionic-proposed/universe) [1.4+git20170917.0.d512384-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-adventure [ppc64el] (bionic-proposed/universe) [1.4+git20170917.0.d512384-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-adventure [i386] (bionic-proposed/universe) [1.4+git20170917.0.d512384-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-adventure [s390x] (bionic-proposed/universe) [1.4+git20170917.0.d512384-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-adventure [armhf] (bionic-proposed/universe) [1.4+git20170917.0.d512384-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-adventure [arm64] (bionic-proposed/universe) [1.4+git20170917.0.d512384-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-grpc [amd64] (bionic-proposed/universe) [1.3.2+debian-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-grpc [i386] (bionic-proposed/universe) [1.3.2+debian-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-grpc [ppc64el] (bionic-proposed/universe) [1.3.2+debian-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pytest-doctestplus [amd64] (bionic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-grpc [amd64] (bionic-proposed) [1.3.2+debian-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-grpc [ppc64el] (bionic-proposed) [1.3.2+debian-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted pytest-openfiles [i386] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-grpc [i386] (bionic-proposed) [1.3.2+debian-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted impressive [amd64] (bionic-proposed) [0.11.2-1.1]
-queuebot:#ubuntu-release- New: accepted node-ci-info [amd64] (bionic-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted pytest-doctestplus [armhf] (bionic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted pytest-doctestplus [ppc64el] (bionic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted pytest-openfiles [amd64] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted pytest-openfiles [armhf] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted pytest-openfiles [s390x] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted jboss-threads [amd64] (bionic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted pytest-doctestplus [i386] (bionic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted pytest-openfiles [arm64] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted pytest-doctestplus [arm64] (bionic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted pytest-openfiles [ppc64el] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted pytest-doctestplus [s390x] (bionic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted open-adventure [amd64] (bionic-proposed) [1.4+git20170917.0.d512384-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted open-adventure [s390x] (bionic-proposed) [1.4+git20170917.0.d512384-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted open-adventure [i386] (bionic-proposed) [1.4+git20170917.0.d512384-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted open-adventure [arm64] (bionic-proposed) [1.4+git20170917.0.d512384-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted open-adventure [ppc64el] (bionic-proposed) [1.4+git20170917.0.d512384-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted open-adventure [armhf] (bionic-proposed) [1.4+git20170917.0.d512384-1ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-gitaly-proto [amd64] (bionic-proposed/universe) [0.26.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-gitaly-proto [amd64] (bionic-proposed) [0.26.0+dfsg-2]
-queuebot:#ubuntu-release- New binary: plasma-discover [s390x] (bionic-proposed/universe) [5.12.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [amd64] (bionic-proposed/universe) [5.12.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [i386] (bionic-proposed/universe) [5.12.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [ppc64el] (bionic-proposed/universe) [5.12.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [arm64] (bionic-proposed/universe) [5.12.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [armhf] (bionic-proposed/universe) [5.12.0-0ubuntu2] (kubuntu)
<cpaelzer> thanks for ipxe compat, the copyright is as it was in the orig package
<cpaelzer> but I'll take a look for both on Mondy
<cpaelzer> both = new compat as well as actual full ipxe package
-queuebot:#ubuntu-release- New binary: chezscheme [amd64] (bionic-proposed/universe) [9.5+dfsg-2build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted chezscheme [amd64] (bionic-proposed) [9.5+dfsg-2build1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [amd64] (bionic-proposed) [5.12.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted plasma-discover [armhf] (bionic-proposed) [5.12.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted plasma-discover [ppc64el] (bionic-proposed) [5.12.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted plasma-discover [arm64] (bionic-proposed) [5.12.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted plasma-discover [s390x] (bionic-proposed) [5.12.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted plasma-discover [i386] (bionic-proposed) [5.12.0-0ubuntu2]
-queuebot:#ubuntu-release- New binary: chezscheme [amd64] (bionic-proposed/universe) [9.5+dfsg-2build2] (no packageset)
-queuebot:#ubuntu-release- New: accepted chezscheme [amd64] (bionic-proposed) [9.5+dfsg-2build2]
<fossfreedom_> Anyone around.  I'm trying to figure out why our meta package binary "ubuntu-budgie-desktop" is missing from our ubuntu budgie daily iso.  Any ideas where to look to find that out?
<tsimonq2> fossfreedom_: Is it in your seed?
<fossfreedom_> ...looking ...
<tsimonq2> Otherwise http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-budgie/bionic/daily-live-20180204.log (and the livefses that are linked at the top of that) might be helpful to you.
<tsimonq2> Yeah, my guess is that it's not in the seed, looking at these.
<tsimonq2> I can confirm that by looking at your seed.
<tsimonq2> fossfreedom_: Line 18 for example is how Lubuntu does it: https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/tree/desktop
<fossfreedom_> tsimonq2, odd - it isn't in our artful seeds - nor in our bionic seeds
<fossfreedom_> ok - in both artful and bionic "ubuntu-budgie-desktop" is in a file called "metapackage-map"
<tsimonq2> Right, it's in the metapackage map, but not pulled in by the seed itseld.
<tsimonq2> *itself
<fossfreedom_> correct - what's more odd - most of the packages that are in the seed are actually in the iso - what is missing are the packages I added to the seed a couple of days ago + ubuntu-budgie-desktop itself
-queuebot:#ubuntu-release- New binary: meta-kde [amd64] (bionic-proposed/universe) [5:99] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [s390x] (bionic-proposed/universe) [5:99] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [ppc64el] (bionic-proposed/universe) [5:99] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [arm64] (bionic-proposed/universe) [5:99] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [i386] (bionic-proposed/universe) [5:99] (kubuntu)
-queuebot:#ubuntu-release- New binary: meta-kde [armhf] (bionic-proposed/universe) [5:99] (kubuntu)
<krytarik> I'll mention that I don't see an update to  http://people.canonical.com/~ubuntu-archive/seeds/ubuntu-budgie.bionic/  since rev 2219 to the Budgie seed.
-queuebot:#ubuntu-release- New binary: ibm-3270 [amd64] (bionic-proposed/universe) [3.6ga4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-aiomeasures [amd64] (bionic-proposed/universe) [0.5.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qpack [amd64] (bionic-proposed/universe) [0.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qpack [i386] (bionic-proposed/universe) [0.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-3.3 [amd64] (bionic-proposed/universe) [1:3.3.6ds1-30] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-3.3 [i386] (bionic-proposed/universe) [1:3.3.6ds1-30] (no packageset)
-queuebot:#ubuntu-release- New binary: qpack [ppc64el] (bionic-proposed/universe) [0.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qpack [arm64] (bionic-proposed/universe) [0.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qpack [armhf] (bionic-proposed/universe) [0.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qpack [s390x] (bionic-proposed/universe) [0.0.17-1] (no packageset)
#ubuntu-release 2019-01-28
-queuebot:#ubuntu-release- New binary: gatb-core [arm64] (disco-proposed/universe) [1.4.1+git20181225.44d5a44+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gatb-core [arm64] (disco-proposed) [1.4.1+git20181225.44d5a44+dfsg-1]
-queuebot:#ubuntu-release- New: accepted igor [ppc64el] (disco-proposed) [1.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [amd64] (disco-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [s390x] (disco-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [ppc64el] (disco-proposed) [3.19.1-2]
-queuebot:#ubuntu-release- New: accepted igor [s390x] (disco-proposed) [1.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (disco-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [ppc64el] (disco-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [s390x] (disco-proposed) [3.19.1-2]
-queuebot:#ubuntu-release- New: accepted gatb-core [i386] (disco-proposed) [1.4.1+git20181225.44d5a44+dfsg-1]
-queuebot:#ubuntu-release- New: accepted igor [amd64] (disco-proposed) [1.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted orthanc-wsi [i386] (disco-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted salmid [amd64] (disco-proposed) [0.1.23-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [i386] (disco-proposed) [3.19.1-2]
-queuebot:#ubuntu-release- New: accepted gatb-core [ppc64el] (disco-proposed) [1.4.1+git20181225.44d5a44+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (disco-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted igor [i386] (disco-proposed) [1.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [amd64] (disco-proposed) [3.19.1-2]
-queuebot:#ubuntu-release- New: accepted gatb-core [amd64] (disco-proposed) [1.4.1+git20181225.44d5a44+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (disco-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted xmlmarshaller [amd64] (disco-proposed) [1.0.1-2]
-queuebot:#ubuntu-release- New: accepted gatb-core [s390x] (disco-proposed) [1.4.1+git20181225.44d5a44+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [i386] (disco-proposed) [3.2.1+dfsg-2]
-queuebot:#ubuntu-release- New binary: keysync [amd64] (disco-proposed/none) [0.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted keysync [amd64] (disco-proposed) [0.2.2-2]
<acheronuk> The membership of Kubuntu Council (kubuntu-council) in the Ubuntu
<acheronuk> Testcase Admins (ubuntu-testcase) team has expired.
<acheronuk> does this matter?
<acheronuk> valorie: ?
-queuebot:#ubuntu-release- New source: coyote (disco-proposed/primary) [2018.01.25-1build1]
-queuebot:#ubuntu-release- New source: idlastro (disco-proposed/primary) [2018.08.10+dfsg-1build1]
-queuebot:#ubuntu-release- New: accepted coyote [source] (disco-proposed) [2018.01.25-1build1]
-queuebot:#ubuntu-release- New: accepted idlastro [source] (disco-proposed) [2018.08.10+dfsg-1build1]
-queuebot:#ubuntu-release- New binary: coyote [amd64] (disco-proposed/universe) [2018.01.25-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: idlastro [amd64] (disco-proposed/universe) [2018.08.10+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted coyote [amd64] (disco-proposed) [2018.01.25-1build1]
-queuebot:#ubuntu-release- New: accepted idlastro [amd64] (disco-proposed) [2018.08.10+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (bionic-proposed/multiverse) [1.20180919-0ubuntu0.18.04.1 => 1.20180919-0ubuntu0.18.04.2] (no packageset)
<juliank> Laney, sil2100 add salt to long tests on arm* so it stops timing out 90% of the time: https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/362292
<LocutusOfBorg> hello, should we just sync mariadb-10.3? it is not auto-syncd because of libmariadb-dev shared with mariadb-10.1
 * LocutusOfBorg does sync it
-queuebot:#ubuntu-release- New sync: mariadb-10.3 (disco-proposed/primary) [1:10.3.12-2]
<sil2100> juliank: ok, seeing all the salt's successful runs, it does seem like a long test indeed
<LocutusOfBorg> vorlon, coreycb os-faults is now python-os-faults in debian... can we just sync it?
-queuebot:#ubuntu-release- New sync: matplotlib2 (disco-proposed/primary) [2.2.3-5]
-queuebot:#ubuntu-release- Unapproved: rejected ufw [source] (cosmic-proposed) [0.36-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (cosmic-proposed) [2:1.20.3-0ubuntu0.18.10.1]
<juliank> sil2100: thanks for the approve, but since I can't push, can you merge it too? :)
<sil2100> juliank: ah! Forgot about that, sure ;)
<sil2100> juliank: (just need a moment)
-queuebot:#ubuntu-release- Unapproved: iscsitarget (trusty-proposed/universe) [1.4.20.3+svn499-0ubuntu2.5 => 1.4.20.3+svn499-0ubuntu2.6] (no packageset)
<xnox> cking, stress-ng is failing on armhf autopkgtests (the weird runs inside lxd containder, on arm64 kernel mind you....) http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html you can see it blocking zlib migration
<xnox> cking, would you be able to take a look?
<cking> xnox, ok, i'll do that right now
-queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (trusty-proposed) [1.4.20.3+svn499-0ubuntu2.6]
<xnox> doko, please RM git-remote-hg https://bugs.launchpad.net/debian/+source/git-remote-hg/+bug/1699087
<ubot5> Ubuntu bug 1699087 in git-remote-hg (Ubuntu) "RM git-remote-hg hg-git" [Wishlist,Triaged]
-queuebot:#ubuntu-release- New binary: plplot [s390x] (disco-proposed/universe) [5.14.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [ppc64el] (disco-proposed/universe) [5.14.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [i386] (disco-proposed/universe) [5.14.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [arm64] (disco-proposed/universe) [5.14.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [armhf] (disco-proposed/universe) [5.14.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [amd64] (disco-proposed/universe) [5.14.0+dfsg-3] (no packageset)
<LocutusOfBorg> vorlon, did you do anything to fix nodejs?
<LocutusOfBorg> I see it is now passing
<doko> xnox: done
-queuebot:#ubuntu-release- New: accepted mariadb-10.3 [sync] (disco-proposed) [1:10.3.12-2]
-queuebot:#ubuntu-release- New: accepted plplot [amd64] (disco-proposed) [5.14.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted plplot [armhf] (disco-proposed) [5.14.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted plplot [ppc64el] (disco-proposed) [5.14.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted matplotlib2 [sync] (disco-proposed) [2.2.3-5]
-queuebot:#ubuntu-release- New: accepted plplot [i386] (disco-proposed) [5.14.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted plplot [arm64] (disco-proposed) [5.14.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted plplot [s390x] (disco-proposed) [5.14.0+dfsg-3]
-queuebot:#ubuntu-release- New binary: mariadb-10.3 [s390x] (disco-proposed/universe) [1:10.3.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.3 [amd64] (disco-proposed/universe) [1:10.3.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.3 [ppc64el] (disco-proposed/universe) [1:10.3.12-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kdeconnect [source] (cosmic-proposed) [1.3.3-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New binary: mariadb-10.3 [i386] (disco-proposed/universe) [1:10.3.12-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted mariadb-10.3 [amd64] (disco-proposed) [1:10.3.12-2]
-queuebot:#ubuntu-release- New: accepted mariadb-10.3 [ppc64el] (disco-proposed) [1:10.3.12-2]
-queuebot:#ubuntu-release- New: accepted mariadb-10.3 [i386] (disco-proposed) [1:10.3.12-2]
-queuebot:#ubuntu-release- New: accepted mariadb-10.3 [s390x] (disco-proposed) [1:10.3.12-2]
-queuebot:#ubuntu-release- Unapproved: accepted kdeconnect [source] (bionic-proposed) [1.3.3-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected ufw [source] (bionic-proposed) [0.36-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (bionic-proposed) [1.0.6-0ubuntu0.1]
<coreycb> LocutusOfBorg: yes i think a sync should be fine
<coreycb> LocutusOfBorg: i'll do that
<cking> xnox, I've added a fix to stress-ng, tested it and uploaded to disco
<xnox> cking, awesome!
<coreycb> LocutusOfBorg: that's failing to build and we have no reverse depends on it
<cking> xnox, it takes a while to verify it works, the regression tests are a bit too thorough
<xnox> cking, hopefully it will migrate; and pass again with whatever it is blocking.
<cking> fingers crossed
<LocutusOfBorg> coreycb, yes, strange thing
<LocutusOfBorg> will you have a look?
<coreycb> LocutusOfBorg: i don't know if it's worth it. can we just drop the package?
<LocutusOfBorg> btw ansible was requiring it too
<LocutusOfBorg> I can have a look coreycb maybe
<coreycb> LocutusOfBorg: i have so many higher priority things and openstack doesn't need it
<coreycb> LocutusOfBorg: well thanks but i really don't think it's needed
<LocutusOfBorg> oh you are right coreycb ! can you please file a bug or ask to drop it?
<coreycb> LocutusOfBorg: yes i can
<coreycb> LocutusOfBorg: https://bugs.launchpad.net/ubuntu/+source/os-faults/+bug/1813600
<ubot5> Ubuntu bug 1813600 in os-faults (Ubuntu) "[RM] os-faults" [Undecided,New]
<slashd> o/ sil2100 could you please approve the upload of libmemcached for C/B/X/T (LP: #1573594) ?
<ubot5> Launchpad bug 1573594 in libmemcached (Ubuntu Cosmic) "Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling" [Medium,In progress] https://launchpad.net/bugs/1573594
<vorlon> LocutusOfBorg: fix nodejs> yes, I changed it to run on the bigger instances.  I would still like to know why it doesn't need bigger instances for any of the other archs, though
-queuebot:#ubuntu-release- Unapproved: dkms (xenial-proposed/main) [2.2.0.3-2ubuntu11.5 => 2.2.0.3-2ubuntu11.6] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.3 => 1.33.1~16.04.4] (core)
<LocutusOfBorg> vorlon, I'm already happy that it wasn't a bug on the package :)
<blackboxsw> infinity:  If you are on call for SRUs cloud-init has an sru in the queue for xenial, bionic and cosmic per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1813346 for to release 18.5.17
<ubot5> Ubuntu bug 1813346 in cloud-init (Ubuntu) "sru cloud-init (18.4.0 update to 18.5-17-gd1a2fe73) Xenial, Bionic, Cosmic" [Undecided,New]
<LocutusOfBorg> vorlon, the number of tests is 2181 on amd64 and arm64, so maybe the container configuration is different?
<vorlon> there are no containers, these are VMs
<LocutusOfBorg> ah ok
<LocutusOfBorg> but also arm64? isn't some lxc/lxd stuff?
<vorlon> no, that's on armhf
<LocutusOfBorg> oh ok can it be some different VM configuration on amd64?
<LocutusOfBorg> maybe the address space on 64 bit is less optimized
-queuebot:#ubuntu-release- Unapproved: shim-signed (trusty-proposed/main) [1.33.1~14.04.3 => 1.33.1~14.04.4] (core)
<vorlon> I don't know of any reason that a VM on amd64 would consistently have more available memory for tests than on any of the other archs
<LocutusOfBorg> specially compared with s390x or ppc64el, both with 64 bit address space...
<vorlon> sorry, I guess that's "less available memory" on amd64
<vorlon> but either way
<juliank> Laney, vorlon, sil2100 Is there a safe (as in, not aborting running tests) way to restart the bos02-arm64 workers so they pick up the worker.conf changes
<Laney> HUP them
<juliank> ah right
<Laney> https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Worker_administration
-queuebot:#ubuntu-release- Unapproved: dkms (trusty-proposed/main) [2.2.0.3-1.1ubuntu5.14.04.9 => 2.2.0.3-1.1ubuntu5.14.04.10] (kubuntu, ubuntu-desktop)
<juliank> Laney: I bookmarked that now
<juliank> Laney: I was searching for restart in the history, and obviously did not find anything
<juliank> I think we can make the unit implement reload, then we can systemctl reload services
<juliank> might be even nicer, idk
<Laney> probably that could even just be /bin/kill -HUP $MAINPID
<juliank> yes
<juliank> Laney: bos01-arm64 is down
<juliank> or well, I saw quite a lot of errors
<juliank> it seems we did not properly cleanup security groups or something
<juliank> 1 out of 3 workers are running
<juliank> either some manual tests are running in the security groups of workers 1 or 3, or something is fishy
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (cosmic-proposed) [1.7.2]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (bionic-proposed) [1.6.8]
<juliank> found them
<juliank> adt-disco-arm64-mariadb-10.1-20190128-154301
<juliank> adt-disco-arm64-kopanocore-20190128-153946
<juliank> they are still running but have no processes
<juliank> all workers seem to be running again
<juliank> Well, it seems some other instances are broken and can't be deleted
<juliank> causing some worker services to be blocked
<juliank> because they cannot delete the security group and create it again, because the existing one is in use
<juliank> looks ok now
<Laney> the maintenance script cleared it up presumably?
<juliank> possibly
<juliank> I wonder whether it makes sense to fail if we can't delete the secgroup because it's used
<juliank> maybe we should just ignore the failure and reuse it
<juliank> then we do not hit restart limits and stuff and lose workers over an hour
<Laney> sounds like the workers are aborting and leaving stray instances and secgroups around - at least the first of those is a waste of resources, would be good to fix that
<Laney> it's not supposed to happen like that
<juliank> adt-disco-ppc64el-python-oslo.service-20190120-101922 is in state deleting since ages
<juliank> this test is from 8 days ago afaict
<juliank> (on bos01)
<Laney> there's a ticket about that
<juliank> and it keeps blocking the -4.service
<juliank> so I think I should just make failure to delete a no-op
<Laney> so *that* one is an openstack bug
<Laney> what about those other two?
<juliank> the other ones were cleaned up
<Laney> what made them break?
<juliank> Laney: I cowboyed in a change to just reuse the existing secgroup
<juliank> to see what that does
<Laney> seems a bit...
<Laney> zealous
<Laney> given that we were in the middle of discussing it
<juliank> Laney: yes, I took it out again, but I restarted autopkgtest@bos01-ppc64el-4.service with that change to evaluate it
<juliank> Laney: I think the failure to delete instances is Jan 28 00:01:09 juju-prod-ues-proposed-migration-machine-11 sh[1650]: No UUID given. Instance won't be deleted!
<juliank> So, after "Creating nova instance", it says "Timed out waiting for ssh. "
<Laney> it should still know the UUID at that point
<Laney> /o\
-queuebot:#ubuntu-release- New binary: agg [s390x] (disco-proposed/universe) [1:2.6.0-r132+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: agg [amd64] (disco-proposed/universe) [1:2.6.0-r132+dfsg1-1] (no packageset)
 * Laney sent IS a nag mail to please delete that instance for us
<juliank> it's odd
-queuebot:#ubuntu-release- New binary: libjs-rtcpeerconnection-shim [amd64] (disco-proposed/none) [1.2.14-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pkg-js-tools [amd64] (disco-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcatmandu-filestore-perl [amd64] (disco-proposed/none) [1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: looking-glass [amd64] (disco-proposed/none) [0+a12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-yarnpkg [amd64] (disco-proposed/none) [1.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjs-sdp [amd64] (disco-proposed/none) [2.9.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: popper.js [amd64] (disco-proposed/none) [1.14.6+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netdata [amd64] (disco-proposed/universe) [1.11.1+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: nextcloud-desktop [i386] (disco-proposed/universe) [2.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libcatmandu-filestore-perl [amd64] (disco-proposed) [1.13-1]
-queuebot:#ubuntu-release- New: accepted nextcloud-desktop [i386] (disco-proposed) [2.5.1-1]
-queuebot:#ubuntu-release- New: accepted netdata [amd64] (disco-proposed) [1.11.1+dfsg-5]
-queuebot:#ubuntu-release- New: accepted node-yarnpkg [amd64] (disco-proposed) [1.13.0-1]
-queuebot:#ubuntu-release- New: accepted agg [amd64] (disco-proposed) [1:2.6.0-r132+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libjs-rtcpeerconnection-shim [amd64] (disco-proposed) [1.2.14-3]
-queuebot:#ubuntu-release- New: accepted looking-glass [amd64] (disco-proposed) [0+a12-1]
-queuebot:#ubuntu-release- New: accepted popper.js [amd64] (disco-proposed) [1.14.6+ds-1]
-queuebot:#ubuntu-release- New: accepted agg [s390x] (disco-proposed) [1:2.6.0-r132+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted pkg-js-tools [amd64] (disco-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted libjs-sdp [amd64] (disco-proposed) [2.9.0-4]
-queuebot:#ubuntu-release- New binary: nextcloud-desktop [amd64] (disco-proposed/universe) [2.5.1-1] (no packageset)
<blackboxsw> sil2100: I'm not sure infinity is around for SRU on call, is there anyone that might be able to help with cloud-init xenial. bionic and cosmic queued SRU?per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1813346 for to release 18.5.17
<ubot5> Ubuntu bug 1813346 in cloud-init (Ubuntu) "sru cloud-init (18.4.0 update to 18.5-17-gd1a2fe73) Xenial, Bionic, Cosmic" [Undecided,New]
<blackboxsw> just wanted to get that -proposed timer started sometime today (and start our verification process)
<sil2100> blackboxsw: hey!
<sil2100> Let me looks
<sil2100> *look
<blackboxsw> excellents  *excellent
<sil2100> ;)
<sil2100> blackboxsw: whoops, I can't accept it right now, did you see that 18.5-17-gd1a2fe73 in disco FTBFS?
<blackboxsw> ohh sil2100 nice, thanks I hadn't seen. and will remedy thank you
<sil2100> Let's re-visit this once the package builds fine (and possibly migrates) in disco
<sil2100> yw o/
<blackboxsw> sil2100 thanks again.  I had fixed one issue I saw on disco locally this weekend and didn't realize there were two issue (timing related). Will have a  18.5.18 upload to remedy this.
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (bionic-proposed) [1.20180919-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New: accepted nextcloud-desktop [amd64] (disco-proposed) [2.5.1-1]
-queuebot:#ubuntu-release- Unapproved: ceilometer (cosmic-proposed/main) [1:11.0.1-0ubuntu1 => 1:11.0.1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (bionic-proposed/main) [1:10.0.1-0ubuntu0.18.04.1 => 1:10.0.1-0ubuntu0.18.04.2] (openstack, ubuntu-server)
<valorie> oh dear, I'll look into that acheronuk
#ubuntu-release 2019-01-29
<vorlon> Laney, juliank: was there a known issue that was causing arm64 autopkgtests to take longer?  I can't see anything now that would cause them to be slow
<ginggs> would someone please kick the can along?  '+force-badtest r-cran-rnexml/2.3.0-1/arm64 r-cran-rnexml/2.3.0-1/s390x' in ubuntu-release - indirect test dep on r-cran-v8, not available on these archs
<apw> ginggs, done
<Laney> vorlon: not known by me
<ginggs> apw: thanks!
-queuebot:#ubuntu-release- Unapproved: duplicity (bionic-proposed/main) [0.7.17-0ubuntu1 => 0.7.17-0ubuntu1.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.8-0ubuntu0.18.04.1 => 12.2.8-0ubuntu0.18.04.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cogl (bionic-proposed/main) [1.22.2-3 => 1.22.2-3ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu26 => 0.6.5.6-0ubuntu27] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu27]
-queuebot:#ubuntu-release- Unapproved: libdbusmenu (bionic-proposed/main) [16.04.1+18.04.20171206-0ubuntu1 => 16.04.1+18.04.20171206-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: pygobject (bionic-proposed/main) [3.26.1-2 => 3.26.1-2ubuntu1] (core)
<ginggs> someone please 'force-badtest xtensor/0.10.11-1/i386' - FP precision errors, regressed in release
<LocutusOfBorg> dear AA, is it possible to remove src:mariadb-10.1 from the archive?
<LocutusOfBorg> it should be, but I prefer to ask in case my reverse-depends failed
<LocutusOfBorg> vorlon, doko ^^
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [4.19.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [4.19.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: ceph (cosmic-proposed/main) [13.2.1+dfsg1-0ubuntu2.18.10.1 => 13.2.4+dfsg1-0ubuntu0.18.10.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [4.19.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [4.19.0-12.13]
-queuebot:#ubuntu-release- New: accepted unity-scope-gnote [source] (disco-proposed) [0.1+13.10.20130723-0ubuntu2]
-queuebot:#ubuntu-release- New binary: unity-scope-gnote [amd64] (disco-proposed/universe) [0.1+13.10.20130723-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: unity-control-center (cosmic-proposed/universe) [15.04.0+18.04.20180216-0ubuntu1 => 15.04.0+18.10.20190107-0ubuntu1] (mythbuntu, ubuntukylin) (sync)
-queuebot:#ubuntu-release- New: accepted unity-scope-gnote [amd64] (disco-proposed) [0.1+13.10.20130723-0ubuntu2]
<vorlon> LocutusOfBorg: well, reverse-depends is being unhelpful on account of old versions of arch: all packages being kept around in the archive.   But the one thing I do see is tcl8.6-tdbc-mysql depends libmariadbclient18 and for some reason prefers it over libmysqlclient20 (the one in main), maybe that should get a sourceful fix to the ordering
<rbasak> I noticed tcl8.6-tdbc-mysql for other reasons the other day (upcoming transition). I didn't notice the ordering.
<rbasak> I assume it's using dlopen or similar.
<rbasak> Agree with the ordering. We'll have to maintain an Ubuntu delta on it. Unless we can get a dpkg-vendor based thing in Debian landed.
<rbasak> (which would be ugly due to needing to hack the control file)
<rbasak> Another way might be to have src:mysql-defaults provide a new default- package (if there isn't one already) and have tcl8.6-tdbc-mysql use that.
<LocutusOfBorg> rbasak, can I leave it to you?
<LocutusOfBorg> I mean, removing old mariadb
<rbasak> LocutusOfBorg: could you just file a removal bug for AAs?
<rbasak> That's the normal process.
<rbasak> I was leaving mariadb-10.3 alone.
<rbasak> Because I didn't want to commit to the work of finishing it off right now.
<rbasak> If you synced it, then please finish it :)
<LocutusOfBorg> sure
<LocutusOfBorg> but I don't understand what is the tdbc problem
<LocutusOfBorg> I'm happy to fix it
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/mariadb-10.1/+bug/1813803
<ubot5> Ubuntu bug 1813803 in mariadb-10.1 (Ubuntu) "Remove mariadb-10.1 from disco" [Undecided,New]
<rbasak> My understanding of the tdbc problem is that it's (mostly) unrelated to MariaDB 10.1->10.3.
<rbasak> So don't worry about that part, unless I'm wrong.
<LocutusOfBorg> so, wrt my removal bug there is nothing preventing it from disappearing?
<rbasak> Depends: libc6 (>= 2.14), tcl8.6, tcl8.6-tdbc (>= 1.0.5), libmariadbclient18 | libmysqlclient18 | libmysqlclient20
<rbasak> libmysqlclient20 is in the archive right now.
<LocutusOfBorg> ack
<rbasak> And I'll take care of adding libmysqlclient21 to that list as needed.
<rbasak> So I don't think it blocks removal.
<LocutusOfBorg> damn it was already removed :/ good AA is good
<rbasak> :)
<LocutusOfBorg> and #1711949 is fixed now
<roaksoax> win 2
-queuebot:#ubuntu-release- Unapproved: libunistring (bionic-proposed/main) [0.9.9-0ubuntu1 => 0.9.10-1ubuntu0.1] (core)
<LocutusOfBorg> apw, ^^ you usually help me with vbox
<LocutusOfBorg> please remove virtualbox-qt and virtualbox from disco/i386 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920801 thanks!
<ubot5> Debian bug 920801 in ftp.debian.org "RM: virtualbox, virtualbox-qt [i386] -- ROM; NBS" [Normal,Open]
<LocutusOfBorg> I don't know if the ext-pack testsuite will need an hint or not... meh
<apw> LocutusOfBorg, ack
-queuebot:#ubuntu-release- Unapproved: cloud-init (cosmic-proposed/main) [18.4-7-g4652b196-0ubuntu1 => 18.5-21-g8ee294d5-0ubuntu1~18.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.4-0ubuntu1~18.04.1 => 18.5-21-g8ee294d5-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.4-0ubuntu1~16.04.2 => 18.5-21-g8ee294d5-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.6 => 239-7ubuntu10.7] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.11 => 237-3ubuntu10.12] (core)
<ddstreet> bdmurray if you're sru point person today, and you have a chance, would be great to get those systemd uploads for b/c approved today, they are rather urgent
<doko> why do we have so many /unknown test failures on arm64?
<vorlon> I don't know; but the bigger issue is that britney is mis-collecting the test results and treating "unknown" as a later version than any real version
-queuebot:#ubuntu-release- Unapproved: golang-1.6 (trusty-security/universe) [1.6-0ubuntu1~14.04 => 1.6-0ubuntu1~14.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.6 [sync] (trusty-security) [1.6-0ubuntu1~14.04]
#ubuntu-release 2019-01-30
<RAOF> ddstreet: Hm, that systemd upload appears to drop a bunch of changes from the existing cosmic-proposed package?
<RAOF> ddstreet: Specifically, the fixes for bug #1799364, LP: #1804584, LP: #1804603, LP: #1804864, LP: #1805358
<ubot5> bug 1799364 in systemd (Ubuntu Bionic) "The wlan/bt hotkey doesn't work for all Dell Latitude and Precision computers" [Medium,New] https://launchpad.net/bugs/1799364
<ubot5> Launchpad bug 1804584 in systemd (Ubuntu Bionic) "LG screen reported as being a Goldstar one" [Undecided,New] https://launchpad.net/bugs/1804584
<ubot5> Launchpad bug 1804603 in systemd (Ubuntu Disco) "systemd-tmpfiles-setup.service fails on btrfs" [Undecided,Fix released] https://launchpad.net/bugs/1804603
<ubot5> Launchpad bug 1804864 in systemd (Ubuntu Cosmic) "autopkgtest regression TEST-22-TMPFILES are not executable" [Undecided,Fix released] https://launchpad.net/bugs/1804864
<ubot5> Launchpad bug 1805358 in systemd (Ubuntu Bionic) "autopkgtest boot-and-services fails on many architectures very often since systemd/239-7ubuntu12" [Undecided,New] https://launchpad.net/bugs/1805358
<RAOF> ddstreet: Likewise, the bionic upload appears to drop a bunch of changes?
<LocutusOfBorg> apw, yes I need an hint too :/ force-badtest virtualbox-ext-pack/all/i386 #relies on non-existing virtualbox binary on i386
<LocutusOfBorg> good morning btw :)
<ypwong> infinity, will 18.04.2 use hwe package? The daily image is still using 4.15 kernel
<ypwong> I mean the desktop one
<apw> ypwong, the 18.04.2 point release desktop images would be expected to be using the hwe kernel
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-45.48] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-45.48] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-45.48]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-45.48]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.37 => 2.37.1] (desktop-core, ubuntu-server)
<Laney> there's a lot of /unknown results atm, I think one of the cloud regions is woeful so I've disabled it
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.37+18.04 => 2.37.1+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.37+18.10 => 2.37.1+18.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.37~14.04 => 2.37.1~14.04] (no packageset)
<Laney> and I'm too lazy to click all those buttons so I'll just retry all failed arm64 :>
 * apw looks at snapd ^
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (cosmic-proposed) [2.37.1+18.10]
<ddstreet> RAOF you're comparing against the last pre-security systemd release; I didn't drop the changes, the last (security) systemd release did
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.37.1+18.04]
<ddstreet> if you compare against the current systemd in -updates you should see the correct diff, with just my changes added
<ddstreet> RAOF that is not unusual when security releases supercede something in -proposed
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.37.1]
<ddstreet> RAOF let me know if you have any other q about the uploads
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.37.1~14.04]
<ddstreet> rbasak if you're sru approver today, can you approve the b/c systemd uploads, please, when you get a chance
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-45.48~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-45.48~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-45.48~16.04.1]
-queuebot:#ubuntu-release- New binary: erlang-erlware-commons [amd64] (disco-proposed/universe) [1.3.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-erlware-commons [ppc64el] (disco-proposed/universe) [1.3.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-45.48~16.04.1]
-queuebot:#ubuntu-release- New binary: erlang-erlware-commons [s390x] (disco-proposed/universe) [1.3.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-erlware-commons [i386] (disco-proposed/universe) [1.3.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: progress-linux [amd64] (disco-proposed/universe) [20181201-3] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-erlware-commons [arm64] (disco-proposed/universe) [1.3.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-erlware-commons [armhf] (disco-proposed/universe) [1.3.1+dfsg-2] (no packageset)
<joalif> rbasak, if you're sru approver today, could you please approve the upload of libmemcached for C/B/X/T (LP: #1573594)
<ubot5> Launchpad bug 1573594 in libmemcached (Ubuntu Cosmic) "Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling" [Medium,In progress] https://launchpad.net/bugs/1573594
<rbasak> ddstreet, joalif: added to my list. I'll see how far I get today.
<joalif> rbasak, thanks!
-queuebot:#ubuntu-release- Unapproved: libidn (bionic-proposed/main) [1.33-2.1ubuntu1 => 1.33-2.1ubuntu1.1] (core)
<ginggs> sil2100: thanks! (xtensor hint)
<LocutusOfBorg> hello AA I need an hint too :/ force-badtest virtualbox-ext-pack/all/i386 #relies on non-existing virtualbox binary on i386
<LocutusOfBorg> plllllllllllllllllease ^^
<sil2100> ginggs: yw!
<sil2100> LocutusOfBorg: looking o/
<LocutusOfBorg> ta
<LocutusOfBorg> sil2100, basically, there is no vbox anymore on i386, so the testsuite needs a permanent hint
<LocutusOfBorg> upstream stopped supporting it with 6.0 release
<juliank> good for them
<sil2100> ugh
<LocutusOfBorg> wait, I don't mean guest
<LocutusOfBorg> I mean vbox as *host*
<LocutusOfBorg> in fact, the ext-pack regression was the reason for me discovering that :D
<LocutusOfBorg> so, for the first time a regression has been useful :)
<jamespage> would a member of the sru team be able to look at https://bugs.launchpad.net/ubuntu/bionic/+source/ceph/+bug/1813582 please - that bug is impacting on bionic openstack deploys (for a subset of services)
<ubot5> Ubuntu bug 1813582 in ceph (Ubuntu Bionic) "Update to 12.2.8 leads to SIGSEGV Segmentation fault in python3-rados" [High,In progress]
<Trevinho> hey rbasak, do you have some time to review the stuff we have as desktop-team in SRU queue, mostly shell relateded stuff though (mutter, g-s, g-c-c, g-s-d and related upower)
<tjaalton> anyone know why bionic dailies still don't use HWE packages (kernel + xorg stack)?
<rbasak> Trevinho: adding to my list, but it seems unlikely I'll get to it, sorry.
<seb128> could someone binNEW review the bionic/fwupdate SRU, it's going to miss .2 otherwise (https://launchpad.net/ubuntu/bionic/+queue?queue_state=0&queue_text=)
-queuebot:#ubuntu-release- New: accepted erlang-erlware-commons [amd64] (disco-proposed) [1.3.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted erlang-erlware-commons [armhf] (disco-proposed) [1.3.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted erlang-erlware-commons [ppc64el] (disco-proposed) [1.3.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted progress-linux [amd64] (disco-proposed) [20181201-3]
-queuebot:#ubuntu-release- New: accepted erlang-erlware-commons [arm64] (disco-proposed) [1.3.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted erlang-erlware-commons [s390x] (disco-proposed) [1.3.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted erlang-erlware-commons [i386] (disco-proposed) [1.3.1+dfsg-2]
<Trevinho> rbasak: ok, that's fine... In case please pass the wort to others in the SRU team please
<rbasak> Trevinho: sure but that happens automatically...there's a queue :-)
<rbasak> (though unfortunately lately every item in the queue seems to be a mega-feature-review)
<Trevinho> yeah, indeed, I see the point our stuff isn't the smallest either :-P
<Laney> bos01's supposed to be fixed
<Laney> will start up 1Ã instance to see if it works
<Laney> it's aliiiivvvveeeee
-queuebot:#ubuntu-release- New: accepted fwupdate [amd64] (bionic-proposed) [12-3bionic1]
-queuebot:#ubuntu-release- New: accepted fwupdate [armhf] (bionic-proposed) [12-3bionic1]
-queuebot:#ubuntu-release- New: accepted fwupdate [arm64] (bionic-proposed) [12-3bionic1]
-queuebot:#ubuntu-release- New: accepted fwupdate [i386] (bionic-proposed) [12-3bionic1]
<blackboxsw> Hi sil2100, looks like it's that time again, we sorted the cloud-init disco intermittent build failure per ftbs and have queued 	cloud-init 18.5-21-g8ee294d5 for Xenial Bionic and Cosmic per SRU process bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1813346.
<ubot5> Ubuntu bug 1813346 in cloud-init (Ubuntu) "sru cloud-init (18.4.0 update to 18.5-21-g8ee294d5) Xenial, Bionic, Cosmic" [Undecided,New]
<blackboxsw> if there is time today, we'd like to  reject the queued cloud-init 18.5-17 upload requests, in favor of 18.5-21 I that would be great.
<apw> seb128, i assume you know that those signing templates won't do anything
<sil2100> blackboxsw: hey! Thanks, I'll reject the old ones but not sure if I'll have the cycles to do the review today (I'll try) - if not, I'll do them first thing tomorrow morning as I have my SRU shift then
<blackboxsw> sil2100: excellent. thanks much!
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (cosmic-proposed) [18.5-17-gd1a2fe73-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [18.5-17-gd1a2fe73-0ubuntu1~18.04.1]
<cpaelzer> Hi, it would be great if a release team member could consider https://code.launchpad.net/~paelzer/britney/hints-ubuntu-mask-livecd-rootfs-disco/+merge/362475 to unblock a few things blocked by livecd-rootfs
<vorlon> doko: python-numpy showing some autopkgtest regressions from the usual suspects, any thoughts?
<doko> vorlon: not my biggest priority for now, however I was trying to give back all the astro stuff for now
<vorlon> there was some entanglement with scikit and a ftbfs matplotlib2 which is now resolved in -proposed, so the remaining astro stuff should now build
<LocutusOfBorg> vorlon, thanks for kicking it out
<LocutusOfBorg> I spent two full days trying to fix it
<LocutusOfBorg> and *nothing* :/ even with upstream patches
<LocutusOfBorg> I hope they will have a new release out soon, and I pinged today to backport the patch to 2.3.x branch
<vorlon> LocutusOfBorg: for kicking which out?
<vorlon> cpaelzer: done
<LocutusOfBorg> vorlon, for kicking matplotlib2 :)
<LocutusOfBorg> I would have kicked sphinx too, to let matplotlib2 migrate :p
<seb128> apw, the fwupdate bionic SRU? I don't know much about that SRU, just that Mario pinged to get it unblocked
<vorlon> LocutusOfBorg: ah, sure thing
<sil2100> LocutusOfBorg: (I added that vbox hint if anything)
<LocutusOfBorg> sil2100, â¤
<LocutusOfBorg> apw, sorry, I forgot we have a boinc-virtualbox on i386... I uploaded boinc to stop providing it... can you please do the magic? (remove boinc-virtualbox on i386)
<LocutusOfBorg> I also opened a debian bug
<LocutusOfBorg>  https://bugs.debian.org/920944
<ubot5> Error: debian bug 920944 not found
<vorlon> Laney, juliank: were either of you involved in the rollout of the new ssl certificate on autopkgtest.ubuntu.com?
<juliank> vorlon: not me
<vorlon> k
<vorlon> timestamps on the files coincide with a login from Laney on wendigo
<vorlon> and the new ssl certificate was missing its certificate chain so I had to do surgery
<vorlon> Laney: I think 'juju set autopkgtest-web ssl-cert="$(cat autopkgtest.ubuntu.com.crt autopkgtest.ubuntu.com_chain.crt)" ssl-key="$(cat *.key)"' is the right modification and matches the impementation in autopkgtest-cloud/deployment/deploy.sh (namely, cat *.crt).  Should this be documented on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Production_deployment_from_wendigo ?
<doko> python-defaults (2.7.15-3 to 2.7.15-4) in proposed for 11 days
<doko> Waiting
<doko> dds/2.9.0-6: arm64, armhf
<doko> django-maintenancemode/0.11.2-3: amd64, arm64, i386
<doko> openslide-python/1.1.1-4: amd64, arm64, s390x
<doko> python-lzma/0.5.3-4: amd64, arm64, armhf, i386, s390x
<doko> sphinxcontrib-restbuilder/0.2-2: amd64, arm64, i386, s390x
<doko> svgwrite/1.2.1-1.1: arm64
<doko> vorlon, Laney: are you giving all these tests back which are marked as running, but are not?
<vorlon> doko: no (it doesn't require admin privs to do so; if someone had done it you would see them in the queue again)
<vorlon> although
<vorlon> I did give ack openslide-python
<vorlon> back
<vorlon> but only with a python3-defaults trigger, not python-defaults
<doko> well, just trying to address the ones I didn't mention above
<doko> anyway, EOD
<cpaelzer> thanks vorlon
<cpaelzer> actually, I thought you merged https://code.launchpad.net/~paelzer/britney/hints-ubuntu-mask-livecd-rootfs-disco/+merge/362475 but it is still waiting
<cpaelzer> vorlon: might I ask what is "done" ?
<vorlon> cpaelzer: hmm oops, there was a push conflict; fixing
<vorlon> cpaelzer: now done
<cpaelzer> thanks again
<cpaelzer> I'm going to be dreaming of migrating packages ...
<cpaelzer> cu
-queuebot:#ubuntu-release- Unapproved: accepted libidn [source] (bionic-proposed) [1.33-2.1ubuntu1.1]
<Laney> vorlon: ah, thx
<Laney> I tested with openssl s_cert and firefox, both worked for me, sorry for missing that (please document)
<Laney> doko: all of which ones? it's not expected to happen, so it's not a case of randomly retrying them imho, but something to be investigated
<Laney> s/s_cert/s_client/
<Laney> doko: unless you mean those ones that I think were missed when the surgery was done. if so, feel free to retry those yourself, yes.
#ubuntu-release 2019-01-31
<RAOF> ddstreet: Perhaps I should rephrase: is there a particular reason why you didn't you fold in the superceded SRU's changes? As far as I can tell they'd all been verified and were just waiting to be aged enough for acceptance into -updates.
<RAOF> ddstreet: Those bugs are still there, still have patches to fix them, and have the SRU paperwork filled out, so it should be low effort to fold the changes in and upload one systemd SRU. As it is, accepting just your changes into -proposed will mean waiting 7 days for it to get accepted into -updates, and then immediately uploading another systemd SRU to -proposed to fix those other bugs.
<RAOF> Unless I'm missing something, which I may be.
-queuebot:#ubuntu-release- New binary: ptunnel-ng [s390x] (disco-proposed/none) [1.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [s390x] (disco-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ptunnel-ng [ppc64el] (disco-proposed/none) [1.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ptunnel-ng [i386] (disco-proposed/none) [1.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [ppc64el] (disco-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [i386] (disco-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [amd64] (disco-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ptunnel-ng [amd64] (disco-proposed/none) [1.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [armhf] (disco-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [arm64] (disco-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ptunnel-ng [arm64] (disco-proposed/universe) [1.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ptunnel-ng [armhf] (disco-proposed/universe) [1.32-1] (no packageset)
<acheronuk> Todays Kubuntu bionic live cd failed
<acheronuk> The following packages have unmet dependencies:
<acheronuk>  fwupdate-signed : Depends: fwupdate (= 10-3) but 12-3bionic1 is to be installed
<acheronuk> *failed to build
<acheronuk> main ubuntu bionic iso also failed to build
-queuebot:#ubuntu-release- New: accepted libjwt [amd64] (disco-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted libjwt [armhf] (disco-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted libjwt [ppc64el] (disco-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted ptunnel-ng [amd64] (disco-proposed) [1.32-1]
-queuebot:#ubuntu-release- New: accepted ptunnel-ng [armhf] (disco-proposed) [1.32-1]
-queuebot:#ubuntu-release- New: accepted ptunnel-ng [ppc64el] (disco-proposed) [1.32-1]
-queuebot:#ubuntu-release- New: accepted libjwt [arm64] (disco-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted libjwt [s390x] (disco-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted ptunnel-ng [i386] (disco-proposed) [1.32-1]
-queuebot:#ubuntu-release- New: accepted libjwt [i386] (disco-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted ptunnel-ng [s390x] (disco-proposed) [1.32-1]
-queuebot:#ubuntu-release- New: accepted ptunnel-ng [arm64] (disco-proposed) [1.32-1]
<cpaelzer> hiho, I'd need some archive-powers to get DPDK fixed in Disco
<cpaelzer> currently update_excuses lists it as "unsatisfiable Depends: libipsec ..."
<cpaelzer> which is correct, libipsec isn't in main and some DPDK packages depends on it
<cpaelzer> but, we made efforts to be able to drop parts of DPDK to universe
<cpaelzer> and DPDK is only seeded in main through openvswitch-switch-dpdk which pulls dpdk and some librte-*
<cpaelzer> but none should reach libipsec, so I wanted to ask if one could check for the demotion of the DPDK libraries
<cpaelzer> or at least get in touch with me why they are not demotable
<cpaelzer> actually let me file a bug for all of that ...
<cpaelzer> hmm, I guess we need the rebuild of OVS by jamespage anyway
<jamespage> cpaelzer: new DPDK in disco now? I'll get on the upload asap
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (trusty-proposed/universe) [1.0.0-0ubuntu1~14.04.0 => 1.0.0-0ubuntu1~14.04.1] (no packageset)
<cpaelzer> jamespage: yes it is there, you should have a ping of yesterday around 10 o'clock pm
<cpaelzer> but I know ping floods are lost
<cpaelzer> also I'll need to no change-rebuild collectd and virtio-forwarder which I'll start as well
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (cosmic-proposed) [18.5-21-g8ee294d5-0ubuntu1~18.10.1]
<cpaelzer> jamespage: I subscribed your to bug 1814060 as FYI which is about the demotion I asked above
<ubot5> bug 1814060 in dpdk (Ubuntu) "Disco: Please demote some binaries of src:dpdk to universe" [Undecided,New] https://launchpad.net/bugs/1814060
<cpaelzer> taking a look at the no change rebuilds now
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (trusty-proposed) [1.0.0-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: hddemux (cosmic-proposed/universe) [0.4-7 => 0.4-7ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.5-21-g8ee294d5-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted upower [source] (cosmic-proposed) [0.99.8-2ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (cosmic-proposed) [3.30.2-0ubuntu1.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (cosmic-proposed) [1:3.30.2-1ubuntu0.18.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.8-0ubuntu0.18.04.2]
<LocutusOfBorg> vorlon, node-source-map will be fixed today or tomorrow, but I'm scared about node-yarnpkg "regression" on i386... I can't reproduce the segfault locally, maybe some network issue on the VM?
<LocutusOfBorg> its a new package, maybe we can hint?
-queuebot:#ubuntu-release- Unapproved: haproxy (cosmic-proposed/main) [1.8.13-2ubuntu0.1 => 1.8.13-2ubuntu0.2] (ubuntu-server)
<LocutusOfBorg> I tried an autopkgtest against itself, lets see if it is broken in release
-queuebot:#ubuntu-release- Unapproved: haproxy (bionic-proposed/main) [1.8.8-1ubuntu0.3 => 1.8.8-1ubuntu0.4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: network-manager-fortisslvpn (bionic-proposed/universe) [1.2.8-1build1 => 1.2.8-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (cosmic-proposed) [13.2.4+dfsg1-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New binary: golang-github-influxdata-tail [amd64] (disco-proposed/universe) [1.0.0+git20180327.c434825-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrokey [i386] (disco-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrokey [amd64] (disco-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-factory-bot-rails [amd64] (disco-proposed/universe) [4.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrokey-test [s390x] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrokey-test [i386] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrokey [s390x] (disco-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bzip2 [amd64] (disco-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrokey [ppc64el] (disco-proposed/universe) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrokey-test [amd64] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bzip2 [i386] (disco-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-coresimd [i386] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrokey-test [ppc64el] (disco-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-coresimd [amd64] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-goblin [amd64] (disco-proposed/universe) [0.0.19-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bzip2 [s390x] (disco-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bzip2 [ppc64el] (disco-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vim-youcompleteme [amd64] (disco-proposed/universe) [0+20181101+gitfaa019a-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-coresimd [s390x] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-influxdata-tail [amd64] (disco-proposed) [1.0.0+git20180327.c434825-1]
-queuebot:#ubuntu-release- New: accepted vim-youcompleteme [amd64] (disco-proposed) [0+20181101+gitfaa019a-0.1]
-queuebot:#ubuntu-release- New: accepted ruby-factory-bot-rails [amd64] (disco-proposed) [4.11.1-1]
-queuebot:#ubuntu-release- New: accepted rust-bzip2 [amd64] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bzip2 [ppc64el] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrokey [amd64] (disco-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrokey [ppc64el] (disco-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New binary: rust-coresimd [ppc64el] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-bzip2 [i386] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrokey [i386] (disco-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-bzip2 [s390x] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrokey [s390x] (disco-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-coresimd [amd64] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-coresimd [ppc64el] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrokey-test [amd64] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrokey-test [ppc64el] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-coresimd [i386] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrokey-test [i386] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-coresimd [s390x] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrokey-test [s390x] (disco-proposed) [0.2.0-1]
<doko> vorlon, ginggs: pandas needs fixes for numpy 1.6, probably a new upstream. didn't check for python-scipy yet. pysparse: "new" upstream available from 2013, could be removed with sfepy, satpy could be removed as well.
<doko> python-scipy/i386: new upstream available in experimental. the python2 tests are getting killed
-queuebot:#ubuntu-release- New: accepted rust-goblin [amd64] (disco-proposed) [0.0.19-1]
-queuebot:#ubuntu-release- New binary: cp2k [i386] (disco-proposed/universe) [6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cp2k [amd64] (disco-proposed/universe) [6.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted cp2k [amd64] (disco-proposed) [6.1-2]
-queuebot:#ubuntu-release- New binary: cp2k [s390x] (disco-proposed/universe) [6.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted cp2k [i386] (disco-proposed) [6.1-2]
-queuebot:#ubuntu-release- New: accepted cp2k [s390x] (disco-proposed) [6.1-2]
-queuebot:#ubuntu-release- New binary: cp2k [ppc64el] (disco-proposed/universe) [6.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted cp2k [ppc64el] (disco-proposed) [6.1-2]
-queuebot:#ubuntu-release- Unapproved: s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8.8 => 1.34.0-0ubuntu8.9] (no packageset)
-queuebot:#ubuntu-release- New source: mysql-8.0 (disco-proposed/primary) [8.0.14-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10.7]
<joalif> sil2100, could you please approve the upload of libmemcached for C/B/X/T (LP: #1573594) ?
<ubot5> Launchpad bug 1573594 in libmemcached (Ubuntu Cosmic) "Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling" [Medium,In progress] https://launchpad.net/bugs/1573594
<sil2100> joalif: hey! Let me try getting to that after I'm done with systemd
<joalif> sure sil2100 thanks!
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [source] (disco-proposed) [8.0.14-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.12]
<rbasak> mysql-8.0> that was quick. Thanks!
<teward> heh
<ahasenack> something going on with the arm builders? The queue is huge
<cjwatson> A good chunk of it is https://launchpad.net/ubuntu/+archive/test-rebuild-20181222-test/+builds?build_state=pending
<cjwatson> So they should mostly be scored down low
<cjwatson> New builds should jump the queue
<ahasenack> cjwatson: but not new ppa builds, right?
<ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/apache2-merge-2.4.38/+packages is stuck it seems
<cjwatson> ahasenack: Yes new PPA builds
<ahasenack> ok, I'll wait
<cjwatson> ahasenack: That's probably mostly large builds in progress then, rather than the length of the queue as such
<ahasenack> ok, because that ppa was published 2h ago
<cjwatson> Sure, but there's a lot in progress :)
<cjwatson> Most of the builders are building stuff and nothing seems stuck
<cjwatson> And there are a bunch of builds in the Ubuntu primary archive which will normally win
<cjwatson> I can rescore builds if they're urgent for a specific reason
-queuebot:#ubuntu-release- New binary: mysql-8.0 [s390x] (disco-proposed/universe) [8.0.14-0ubuntu1] (no packageset)
<sil2100> joalif: looking at the change - it looks good and I'm ready to approve it, just was wondering if anyone managed to reach out to the security team about this?
<sil2100> joalif: this looks like something that could potentially go to -security as well
<joalif> thanks sil2100, I haven't talked with security team about this, should I?
<sil2100> Let's poke them about it
-queuebot:#ubuntu-release- New binary: mysql-8.0 [ppc64el] (disco-proposed/universe) [8.0.14-0ubuntu1] (no packageset)
<sil2100> joalif: ok, I'm not getting any response from the security team so far
<joalif> sil2100, yup I can see
<teward> sil2100: they could be busy :P
<joalif> sil2100, so what happens now?
<sil2100> joalif: since I'll be finishing my shift soon, I guess let me just accept those and leave a query for the security team - we can always re-build the package in the security PPA and/or override the -proposed upload with a security upload
<joalif> ack sil2100, thanks!
<sil2100> yw!
-queuebot:#ubuntu-release- Unapproved: accepted libmemcached [source] (cosmic-proposed) [1.0.18-4.2ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libmemcached [source] (bionic-proposed) [1.0.18-4.2ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: mysql-8.0 [amd64] (disco-proposed/universe) [8.0.14-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libmemcached [source] (xenial-proposed) [1.0.18-4.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libmemcached [source] (trusty-proposed) [1.0.8-1ubuntu2.1]
-queuebot:#ubuntu-release- New binary: mysql-8.0 [i386] (disco-proposed/universe) [8.0.14-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lizzie [amd64] (disco-proposed/universe) [0.6+dfsg1-4] (no packageset)
<vorlon> https://launchpad.net/ubuntu/+source/fwupdate-signed/1.19bionic1/+build/16282395/+files/buildlog_ubuntu-bionic-amd64.fwupdate-signed_1.19bionic1_BUILDING.txt.gz shows fwupdate-signed 1.19bionic1 built with the right version of fwupdate, and ending up with the wrong Built-Using and version field.
<vorlon> http://ftpmaster.internal/ubuntu/dists/bionic-proposed/main/uefi/fwupdate-amd64 has none of the its.
<vorlon> bits
<infinity> http://us.archive.ubuntu.com/ubuntu/dists/bionic-proposed/main/uefi/fwupdate-amd64/current/ is 10-3
<infinity> ...
<infinity> If this is a straight backport of 12-3 (which it seems to be), that would be why it doesn't work.
<infinity> We have an Ubuntu delta for a reason.
<vorlon> infinity: ok. I'm going to v-failed and throw both of these out of -proposed to unblock image builds
<vorlon> (though, today is PROPOSED=0 day according to the schedule, are we on track for that?)
<infinity> We're going to be ready for that by late tonight, I think.
<infinity> I mean, modulo people trying to jam things like this in last minute. ;)
<vorlon> seb128: ^^ and this is why I was in no particular hurry to do new processing of fwupdate in -proposed, fwiw
<infinity> I see no reason this update needs to be on or near media, though.
<infinity> If your firmware works well enough to boot Ubuntu and run fwupdate, it works well enough to update fwupdate.
<vorlon> because I knew things had changed radically post-bionic, and was wary of what might be in the queue being correct for bionic
<joelkraehemann> hi all
<joelkraehemann> https://tracker.debian.org/news/1026125/accepted-gsequencer-2141-1-source-into-unstable/
<joelkraehemann> ^^ do I need to create a sync-request?
<joelkraehemann>  https://bugs.launchpad.net/bugs/1813456
<ubot5> Ubuntu bug 1813456 in gsequencer (Ubuntu) "gsequencer fails autopkg tests on anything except amd64" [Undecided,New]
<joelkraehemann> ^^ regarding this issue the functional tests have now restrictions: flaky
<joelkraehemann> https://salsa.debian.org/multimedia-team/gsequencer/blob/master/debian/tests/control
* vorlon changed the topic of #ubuntu-release to: Released: Bionic 18.04.1, Cosmic 18.10 | Archive: Open | Disco Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<vorlon> joelkraehemann: autosyncs are enabled (and /topic now fixed to match), so there should be no need to request a sync
<joelkraehemann> thank vorlon
<joelkraehemann> do you recognize the flaky restrictions?
<vorlon> I believe so
<vorlon> I'm certainly unclear why the test in question needs to allocate && !free so much memory
<vorlon> or why its memory usage is somehow consistently different on amd64 vs not
<joelkraehemann> I think amd64 is faster by freeing memory
<joelkraehemann> ^^ may be it is accelerated
<joelkraehemann> the other architectures delayed free memory
<joelkraehemann> but yes the test wastes 1.2 GB of RAM
<joelkraehemann> I didn't take care of it because the test should exit and the system releases the resources
<joelkraehemann> there many threads involved some allocate, some free and the test runner wastes
<joelkraehemann> I think it is a race for available resources
-queuebot:#ubuntu-release- New: accepted lizzie [amd64] (disco-proposed) [0.6+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [amd64] (disco-proposed) [8.0.14-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [ppc64el] (disco-proposed) [8.0.14-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [i386] (disco-proposed) [8.0.14-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [s390x] (disco-proposed) [8.0.14-0ubuntu1]
<vorlon> doko: ah, enigmail/ppc64el was also a progression rather than a regression, I've retried those tests also with all-proposed
<seb128> vorlon, I forced no-one to NEW those, it would have been fine to comment on the bug saying why they were stucked in the queue, it just felt wrong to not let Mario know what was going on nor reply to his ping on the SRU bug
<vorlon> seb128: a ping on the SRU bug is not guaranteed to get to the right people, if he were here on IRC I would've poked him about it before now
<seb128> vorlon, well, it feels wrong the source accept a SRU and then block the binaries, especially that the process doesn't handle that and that whoever accepted the source added the comments on the bugs saying that the update was accepted in proposed and needed to be tested now
<seb128> to source*
<vorlon> yes, I didn't accept the source either
<seb128> anyway, sorry if it caused trouble, I just tried to get the situation clarified because it confused some people
<vorlon> seb128: sure, and it's clarified now; if you talk to superm1 and can persuade him to be here on IRC again, it can be clarified more quickly in the future :)
<seb128> thx :)
<vorlon> Laney: hey, so regarding the certificate rotation, what do you think about us having a standing procedure to ping others here when one of us meddles directly on the servers?  I might have spent less time debugging the certificates issue if I had known it was changing
<vorlon> doko: where did you identify a new upstream version for pysparse?  the debian/watch is dead and https://sourceforge.net/projects/pysparse/files/ doesn't show anything newer
<vorlon> doko: I see https://pypi.org/project/pysparse/1.3-dev/#files ; that looks like a whole lot of not-fun, support for non-bundled superlu seems dropped upstream
-queuebot:#ubuntu-release- Unapproved: accepted hddemux [source] (cosmic-proposed) [0.4-7ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (cosmic-proposed) [1.8.13-2ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (bionic-proposed) [1.8.8-1ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (cosmic-proposed) [3.30.1.2-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal [source] (cosmic-proposed) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (cosmic-proposed) [18.09.00-0ubuntu2]
-queuebot:#ubuntu-release- New binary: nautilus-image-manipulator [amd64] (disco-proposed/none) [1.3-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: fasttracker2 [ppc64el] (disco-proposed/none) [0.1+b132-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [s390x] (disco-proposed/none) [2.1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [amd64] (disco-proposed/none) [2.1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (bionic-proposed) [18.03.00-0ubuntu4]
-queuebot:#ubuntu-release- New binary: pymssql [i386] (disco-proposed/none) [2.1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [ppc64el] (disco-proposed/none) [2.1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fasttracker2 [s390x] (disco-proposed/multiverse) [0.1+b132-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (xenial-proposed) [16.03.00-0ubuntu1.3]
-queuebot:#ubuntu-release- New binary: fasttracker2 [amd64] (disco-proposed/multiverse) [0.1+b132-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (cosmic-proposed) [1:11.0.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (bionic-proposed) [1:10.0.1-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (cosmic-proposed) [2.6.0-0ubuntu7.1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (cosmic-proposed) [3.30.2-1~ubuntu18.10.3]
-queuebot:#ubuntu-release- New binary: pymssql [arm64] (disco-proposed/universe) [2.1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [armhf] (disco-proposed/universe) [2.1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (bionic-proposed) [3.28.1-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted duplicity [source] (bionic-proposed) [0.7.17-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted cogl [source] (bionic-proposed) [1.22.2-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libdbusmenu [source] (bionic-proposed) [16.04.1+18.04.20171206-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pygobject [source] (bionic-proposed) [3.26.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-control-center [source] (bionic-proposed) [1:3.28.2-0ubuntu0.18.04.3]
#ubuntu-release 2019-02-01
-queuebot:#ubuntu-release- New binary: pypy3 [s390x] (disco-proposed/universe) [6.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fasttracker2 [armhf] (disco-proposed/multiverse) [0.1+b132-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fasttracker2 [arm64] (disco-proposed/multiverse) [0.1+b132-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pypy3 [amd64] (disco-proposed/universe) [6.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pypy3 [i386] (disco-proposed/universe) [6.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pypy3 [ppc64el] (disco-proposed/universe) [6.0.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (xenial-proposed/main) [1.33-0ubuntu0.16.04.1 => 1.45-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.3 => 1.6.3ubuntu1] (core)
<Trevinho> any reason why https://launchpadlibrarian.net/408268783/gnome-control-center_3.28.2-0ubuntu0.18.04.3_source.changes was not accepted ?
<Trevinho> bdmurray: was you? ^
<bdmurray> Trevinho: Because it had no Launchpad-Bugs-Fixed - it should say in the rejection email.
<Trevinho> mh, I didn't get that email it seems, ok... but isn't stating bug #1745032 in changelog?
<ubot5> bug 1745032 in gnome-control-center (Ubuntu Bionic) "AC adapter status not detected on Asus ZenBook UX410UAK" [Medium,In progress] https://launchpad.net/bugs/1745032
<bdmurray> I think if you build on debian then Launchpad-Bugs-Fixed doesn't get generated instead you get what ever thing debian uses.
<Trevinho> ah, ok... well I guess L_aney has to fix that then
-queuebot:#ubuntu-release- New: accepted fasttracker2 [arm64] (disco-proposed) [0.1+b132-1]
-queuebot:#ubuntu-release- New: accepted pymssql [arm64] (disco-proposed) [2.1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pypy3 [amd64] (disco-proposed) [6.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted pypy3 [ppc64el] (disco-proposed) [6.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted fasttracker2 [armhf] (disco-proposed) [0.1+b132-1]
-queuebot:#ubuntu-release- New: accepted pypy3 [i386] (disco-proposed) [6.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted pymssql [armhf] (disco-proposed) [2.1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pypy3 [s390x] (disco-proposed) [6.0.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted fasttracker2 [amd64] (disco-proposed) [0.1+b132-1]
-queuebot:#ubuntu-release- New: accepted fasttracker2 [s390x] (disco-proposed) [0.1+b132-1]
-queuebot:#ubuntu-release- New: accepted pymssql [i386] (disco-proposed) [2.1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pymssql [s390x] (disco-proposed) [2.1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fasttracker2 [ppc64el] (disco-proposed) [0.1+b132-1]
-queuebot:#ubuntu-release- New: accepted pymssql [ppc64el] (disco-proposed) [2.1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pymssql [amd64] (disco-proposed) [2.1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted nautilus-image-manipulator [amd64] (disco-proposed) [1.3-2.1]
-queuebot:#ubuntu-release- New binary: pbbam [ppc64el] (disco-proposed/universe) [0.19.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pbbam [ppc64el] (disco-proposed) [0.19.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New binary: pbbam [amd64] (disco-proposed/universe) [0.19.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pbbam [amd64] (disco-proposed) [0.19.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New binary: pbbam [arm64] (disco-proposed/universe) [0.19.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: flxmlrpc [i386] (disco-proposed/universe) [0.1.4-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: flxmlrpc [s390x] (disco-proposed/universe) [0.1.4-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: flxmlrpc [ppc64el] (disco-proposed/universe) [0.1.4-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: flxmlrpc [amd64] (disco-proposed/universe) [0.1.4-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pbbam [arm64] (disco-proposed) [0.19.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New binary: flxmlrpc [arm64] (disco-proposed/universe) [0.1.4-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: flxmlrpc [armhf] (disco-proposed/universe) [0.1.4-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freedict [amd64] (disco-proposed/universe) [2018.10.21-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted flxmlrpc [amd64] (disco-proposed) [0.1.4-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted flxmlrpc [armhf] (disco-proposed) [0.1.4-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted flxmlrpc [ppc64el] (disco-proposed) [0.1.4-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted flxmlrpc [arm64] (disco-proposed) [0.1.4-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted flxmlrpc [s390x] (disco-proposed) [0.1.4-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted flxmlrpc [i386] (disco-proposed) [0.1.4-4ubuntu1]
-queuebot:#ubuntu-release- New binary: blasr [ppc64el] (disco-proposed/universe) [5.3.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted blasr [ppc64el] (disco-proposed) [5.3.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted freedict [amd64] (disco-proposed) [2018.10.21-3]
-queuebot:#ubuntu-release- New binary: blasr [amd64] (disco-proposed/universe) [5.3.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted blasr [amd64] (disco-proposed) [5.3.2+dfsg-1]
-queuebot:#ubuntu-release- New binary: unanimity [amd64] (disco-proposed/universe) [3.3.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted unanimity [amd64] (disco-proposed) [3.3.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New binary: unanimity [ppc64el] (disco-proposed/universe) [3.3.0+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: unanimity [amd64] (disco-proposed/universe) [3.3.0+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted unanimity [amd64] (disco-proposed) [3.3.0+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted unanimity [ppc64el] (disco-proposed) [3.3.0+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- New binary: pbgenomicconsensus [amd64] (disco-proposed/universe) [2.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: atlas-cpp [s390x] (disco-proposed/universe) [0.6.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: atlas-cpp [ppc64el] (disco-proposed/universe) [0.6.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: atlas-cpp [i386] (disco-proposed/universe) [0.6.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: atlas-cpp [arm64] (disco-proposed/universe) [0.6.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: atlas-cpp [amd64] (disco-proposed/universe) [0.6.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: atlas-cpp [armhf] (disco-proposed/universe) [0.6.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: python-os-ken (disco-proposed/primary) [0.3.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vulkan (bionic-proposed/universe) [1.1.70+dfsg1-1 => 1.1.70+dfsg1-1ubuntu0.18.04.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.2-0ubuntu0.18.04.2 => 1:3.28.2-0ubuntu0.18.04.3] (ubuntu-desktop)
<Laney> bdmurray: ^- that's fixed now, thanks for noticing
 * Laney should make dput-ng detect that
-queuebot:#ubuntu-release- New binary: gromacs [s390x] (disco-proposed/universe) [2019-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gromacs [ppc64el] (disco-proposed/universe) [2019-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gromacs [i386] (disco-proposed/universe) [2019-1] (no packageset)
 * Laney has in fact just written such a check
<Laney> running required-fields: check whether a field is present and non-empty in the changes file
<Laney> The field 'Launchpad-Bugs-Fixed' is required for uplaods to 'cosmic' but it is missing
-queuebot:#ubuntu-release- New binary: gromacs [amd64] (disco-proposed/universe) [2019-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gromacs [armhf] (disco-proposed/universe) [2019-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gromacs [arm64] (disco-proposed/universe) [2019-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted atlas-cpp [amd64] (disco-proposed) [0.6.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted atlas-cpp [armhf] (disco-proposed) [0.6.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted atlas-cpp [ppc64el] (disco-proposed) [0.6.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted atlas-cpp [arm64] (disco-proposed) [0.6.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted atlas-cpp [s390x] (disco-proposed) [0.6.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted atlas-cpp [i386] (disco-proposed) [0.6.4-2ubuntu1]
<vorlon> Laney: I see that despite us still having the same number of armhf runners, armhf is now trailing behind on the queue; and it doesn't look like the stuff in the queue is obviously armhf-unfriendly.  Do you know anything more?  Are we having runner failures again/still?
<vorlon> rebuilding for the libmysqlclient21 transition; checks out in -proposed as not currently entangled
<vorlon> and it appears there are some api changes that are going to break some revdeps (no more my_bool?)
<rbasak> I had assumed it'd be down to me to sort these.
<rbasak> We have a bunch of rdep patches already prepared and tested in https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mysql-8.0/+packages
<rbasak> But there are a bunch of true positive dep8 failures in excuses currently
<rbasak> Skuggen (in #ubuntu-devel) is working on them.
<vorlon> rbasak: excellent; now would be a good time to upload them for the rebuilds, since those packages are all ftbfs until sorted
<vorlon> there's certainly no reason to wait for the dep8 fixes to mysql-8.0 before rebuilding the revdeps, afaics
<rbasak> No I'm just trying to juggle a few other unrelated tasks as well.
<rbasak> I didn't accept AA acceptance of the new source package so soon!
<vorlon> ah :)
<rbasak> Uh, s/accept/expect/
-queuebot:#ubuntu-release- New binary: libappimage [s390x] (disco-proposed/none) [0.1.8+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libappimage [ppc64el] (disco-proposed/none) [0.1.8+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: partman-efi (bionic-proposed/main) [71ubuntu2.1 => 71ubuntu2.2] (core)
-queuebot:#ubuntu-release- New binary: libappimage [arm64] (disco-proposed/universe) [0.1.8+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libappimage [armhf] (disco-proposed/universe) [0.1.8+dfsg-1] (no packageset)
<vorlon> Laney: looks like one source of armhf test failures is dns degradation again D:   Could not connect to ftpmaster.internal:80 (91.189.89.99), connection timed out
<infinity> vorlon: If it resolved the address, but failed to connect, how are you diagnosing that as DNS degradation?
<vorlon> infinity: poorly
<vorlon> infinity: because I didn't read half the line
<infinity> vorlon: Bold strategy.
<vorlon> rbasak: I get the impression that pretty much all revdeps ftbfs due to this mysql api change, which makes me wonder what upstream was thinking there
<infinity> vorlon: If it's hosts on one machine that continually see network blips, while I'd love to blame the kernel or containers, have we ever had anyone just... Reboot the switch?
<vorlon> infinity: "have we ever" - I'm only just seeing this pattern
<infinity> vorlon: Oh, really?  We've seen network timeouts kill armhf tests for ages, I thought.
<infinity> (whether in DNS or elsewise)
<rbasak> vorlon: which change exactly? Do you have an example build failure for me please?
<vorlon> infinity: the DNS problem got sorted with a lxd upgrade
<vorlon> rbasak: https://launchpad.net/ubuntu/+source/emboss/6.6.0+dfsg-7build1/+build/16342404
<vorlon> bool handling / namespacing seems to be very different
<vorlon> rbasak: another: https://launchpad.net/ubuntu/+source/gearmand/1.1.18+ds-3build2/+build/16342452
<rbasak> There was something to do with the type of my_bool.
<rbasak> Skuggen (not here) knows the details. I don't want to repeat it wrong.
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (cosmic-proposed/main) [0.131ubuntu15 => 0.131ubuntu15.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (bionic-proposed) [1.6.3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted partman-efi [source] (bionic-proposed) [71ubuntu2.2]
<vorlon> cpaelzer: I see dpdk is holding things up in -proposed due to missing intel-ipsec-mb MIR, is that anything for you?
-queuebot:#ubuntu-release- New: accepted libappimage [arm64] (disco-proposed) [0.1.8+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libappimage [armhf] (disco-proposed) [0.1.8+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gromacs [amd64] (disco-proposed) [2019-1]
-queuebot:#ubuntu-release- New: accepted gromacs [armhf] (disco-proposed) [2019-1]
-queuebot:#ubuntu-release- New: accepted gromacs [ppc64el] (disco-proposed) [2019-1]
-queuebot:#ubuntu-release- New: accepted libappimage [ppc64el] (disco-proposed) [0.1.8+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pbgenomicconsensus [amd64] (disco-proposed) [2.3.2-1]
-queuebot:#ubuntu-release- New: accepted gromacs [arm64] (disco-proposed) [2019-1]
-queuebot:#ubuntu-release- New: accepted gromacs [s390x] (disco-proposed) [2019-1]
-queuebot:#ubuntu-release- New: accepted gromacs [i386] (disco-proposed) [2019-1]
-queuebot:#ubuntu-release- New: accepted libappimage [s390x] (disco-proposed) [0.1.8+dfsg-1]
-queuebot:#ubuntu-release- New source: jhdf (disco-proposed/primary) [2.11.0+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted jhdf [source] (disco-proposed) [2.11.0+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New binary: puppet-module-panko [amd64] (disco-proposed/universe) [13.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted puppet-module-panko [amd64] (disco-proposed) [13.3.1-1]
-queuebot:#ubuntu-release- New binary: jhdf [ppc64el] (disco-proposed/universe) [2.11.0+dfsg-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: jhdf [s390x] (disco-proposed/universe) [2.11.0+dfsg-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted jhdf [ppc64el] (disco-proposed) [2.11.0+dfsg-3ubuntu2]
-queuebot:#ubuntu-release- New: accepted jhdf [s390x] (disco-proposed) [2.11.0+dfsg-3ubuntu2]
-queuebot:#ubuntu-release- New binary: jhdf [amd64] (disco-proposed/universe) [2.11.0+dfsg-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New source: xserver-xorg-video-intel-hwe-18.04 (bionic-proposed/primary) [2:2.99.917+git20171229-1~18.04.1]
<infinity> tjaalton: ^-- That's the bionic version, not cosmic.
<tjaalton> huh..
<tjaalton> oh right, the host is bionic
<infinity> tjaalton: Well, try again? :)
-queuebot:#ubuntu-release- New: rejected xserver-xorg-video-intel-hwe-18.04 [source] (bionic-proposed) [2:2.99.917+git20171229-1~18.04.1]
<tjaalton> yes
-queuebot:#ubuntu-release- New source: xserver-xorg-video-intel-hwe-18.04 (bionic-proposed/primary) [2:2.99.917+git20171229-1ubuntu1~18.04.1]
<tjaalton> there
<vorlon> hrm why does http://autopkgtest.ubuntu.com/packages/p/pbbam/disco/amd64 show 'build not needed' and the package not being built after I've explicitly added 'build-needed' in this upload? :P
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-intel-hwe-18.04 [source] (bionic-proposed) [2:2.99.917+git20171229-1ubuntu1~18.04.1]
<infinity> tjaalton: \o/
<infinity> tjaalton: And can we update the meta to resurrect the recommends too?
<tjaalton> infinity: done
-queuebot:#ubuntu-release- Unapproved: xorg-hwe-18.04 (bionic-proposed/main) [1:7.7+19ubuntu8~18.04.1 => 1:7.7+19ubuntu8~18.04.2] (no packageset)
<infinity> tjaalton: My hero.
-queuebot:#ubuntu-release- New binary: xserver-xorg-video-intel-hwe-18.04 [amd64] (bionic-proposed/main) [2:2.99.917+git20171229-1ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-video-intel-hwe-18.04 [i386] (bionic-proposed/main) [2:2.99.917+git20171229-1ubuntu1~18.04.1] (no packageset)
<tjaalton> well, if it happened two months ago ;)
-queuebot:#ubuntu-release- Unapproved: accepted xorg-hwe-18.04 [source] (bionic-proposed) [1:7.7+19ubuntu8~18.04.2]
<infinity> The best laid plans of mice and men...
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-intel-hwe-18.04 [amd64] (bionic-proposed) [2:2.99.917+git20171229-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-intel-hwe-18.04 [i386] (bionic-proposed) [2:2.99.917+git20171229-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [18.2.2-0ubuntu1~18.04.1 => 18.2.8-0ubuntu0~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- New binary: libsystem-sub-perl [amd64] (disco-proposed/none) [0.162800-2] (no packageset)
#ubuntu-release 2019-02-02
-queuebot:#ubuntu-release- New binary: rust-rand [s390x] (disco-proposed/universe) [0.6.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand [amd64] (disco-proposed/universe) [0.6.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand [ppc64el] (disco-proposed/universe) [0.6.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand [i386] (disco-proposed/universe) [0.6.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand [armhf] (disco-proposed/universe) [0.6.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand [arm64] (disco-proposed/universe) [0.6.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libsystem-sub-perl [amd64] (disco-proposed) [0.162800-2]
-queuebot:#ubuntu-release- New: accepted rust-rand [arm64] (disco-proposed) [0.6.4-1]
-queuebot:#ubuntu-release- New: accepted rust-rand [i386] (disco-proposed) [0.6.4-1]
-queuebot:#ubuntu-release- New: accepted rust-rand [s390x] (disco-proposed) [0.6.4-1]
-queuebot:#ubuntu-release- New: accepted rust-rand [amd64] (disco-proposed) [0.6.4-1]
-queuebot:#ubuntu-release- New: accepted rust-rand [ppc64el] (disco-proposed) [0.6.4-1]
-queuebot:#ubuntu-release- New: accepted rust-rand [armhf] (disco-proposed) [0.6.4-1]
-queuebot:#ubuntu-release- New binary: rust-euclid [amd64] (disco-proposed/universe) [0.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid [ppc64el] (disco-proposed/universe) [0.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid [i386] (disco-proposed/universe) [0.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid [s390x] (disco-proposed/universe) [0.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid [arm64] (disco-proposed/universe) [0.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid [armhf] (disco-proposed/universe) [0.19.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-euclid [amd64] (disco-proposed) [0.19.5-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid [armhf] (disco-proposed) [0.19.5-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid [ppc64el] (disco-proposed) [0.19.5-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid [arm64] (disco-proposed) [0.19.5-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid [s390x] (disco-proposed) [0.19.5-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid [i386] (disco-proposed) [0.19.5-1]
-queuebot:#ubuntu-release- New binary: rust-backtrace [amd64] (disco-proposed/universe) [0.3.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [ppc64el] (disco-proposed/universe) [0.3.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [i386] (disco-proposed/universe) [0.3.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [s390x] (disco-proposed/universe) [0.3.13-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-backtrace [amd64] (disco-proposed) [0.3.13-1]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [ppc64el] (disco-proposed) [0.3.13-1]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [i386] (disco-proposed) [0.3.13-1]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [s390x] (disco-proposed) [0.3.13-1]
-queuebot:#ubuntu-release- New binary: rust-backtrace [arm64] (disco-proposed/universe) [0.3.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [armhf] (disco-proposed/universe) [0.3.13-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-backtrace [arm64] (disco-proposed) [0.3.13-1]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [armhf] (disco-proposed) [0.3.13-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (cosmic-proposed/main) [1:18.10.11.4 => 1:18.10.11.5] (core)
-queuebot:#ubuntu-release- New binary: rust-lyon-geom [amd64] (disco-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-geom [ppc64el] (disco-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-geom [i386] (disco-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-geom [s390x] (disco-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-geom [armhf] (disco-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-geom [arm64] (disco-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgit-sub-perl [amd64] (disco-proposed/universe) [0.163320-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgit-sub-perl [amd64] (disco-proposed) [0.163320-2]
-queuebot:#ubuntu-release- New: accepted rust-lyon-geom [armhf] (disco-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted rust-lyon-geom [ppc64el] (disco-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted rust-lyon-geom [arm64] (disco-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted rust-lyon-geom [s390x] (disco-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted rust-lyon-geom [i386] (disco-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted rust-lyon-geom [amd64] (disco-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New binary: rust-bindgen [s390x] (disco-proposed/universe) [0.47.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bindgen [ppc64el] (disco-proposed/universe) [0.47.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bindgen [amd64] (disco-proposed/universe) [0.47.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-debcargo [s390x] (disco-proposed/universe) [2.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-debcargo [i386] (disco-proposed/universe) [2.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-debcargo [ppc64el] (disco-proposed/universe) [2.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bindgen [arm64] (disco-proposed/universe) [0.47.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bindgen [armhf] (disco-proposed/universe) [0.47.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bindgen [i386] (disco-proposed/universe) [0.47.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-bindgen [armhf] (disco-proposed) [0.47.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bindgen [i386] (disco-proposed) [0.47.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bindgen [amd64] (disco-proposed) [0.47.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bindgen [ppc64el] (disco-proposed) [0.47.0-1]
-queuebot:#ubuntu-release- New: accepted rust-debcargo [i386] (disco-proposed) [2.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-debcargo [s390x] (disco-proposed) [2.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-bindgen [arm64] (disco-proposed) [0.47.0-1]
-queuebot:#ubuntu-release- New: accepted rust-debcargo [ppc64el] (disco-proposed) [2.2.10-1]
-queuebot:#ubuntu-release- New: accepted rust-bindgen [s390x] (disco-proposed) [0.47.0-1]
-queuebot:#ubuntu-release- New binary: rust-pangocairo [ppc64el] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgtypes [ppc64el] (disco-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo [s390x] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgtypes [s390x] (disco-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo [i386] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgtypes [i386] (disco-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgtypes [amd64] (disco-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgtypes [arm64] (disco-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pangocairo [amd64] (disco-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgtypes [armhf] (disco-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libdist-inkt-role-git-perl [amd64] (disco-proposed/universe) [0.001-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fuzzylite [s390x] (disco-proposed/universe) [6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [s390x] (disco-proposed/universe) [0.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [s390x] (disco-proposed/universe) [7.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: backports.functools-lru-cache [amd64] (disco-proposed/universe) [1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ianlancetaylor-demangle [amd64] (disco-proposed/none) [0.0~git20181102.5e5cf60-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [ppc64el] (disco-proposed/universe) [7.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [ppc64el] (disco-proposed/universe) [0.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-danverbraganza-varcaser [amd64] (disco-proposed/none) [0.0~git20151108.ce61ec4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [i386] (disco-proposed/universe) [0.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-remeh-sizedwaitgroup [amd64] (disco-proposed/none) [0.0~git20180822.5e7302b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [amd64] (disco-proposed/universe) [1.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zsnapd [amd64] (disco-proposed/universe) [0.8.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fuzzylite [ppc64el] (disco-proposed/universe) [6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-intel-tfortools [amd64] (disco-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-proglottis-gpgme [amd64] (disco-proposed/none) [0.0~git20181127.3b0be09-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pytools [amd64] (disco-proposed/universe) [2019.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gosuri-uilive [amd64] (disco-proposed/none) [0.0~git20170323.ac356e6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [amd64] (disco-proposed/universe) [0.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-openzipkin-zipkin-go [amd64] (disco-proposed/none) [0.1.5+git20190103.2fd7f4a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [arm64] (disco-proposed/universe) [0.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtoxcore [armhf] (disco-proposed/universe) [0.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fuzzylite [amd64] (disco-proposed/universe) [6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [arm64] (disco-proposed/universe) [7.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pysurfer [amd64] (disco-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [armhf] (disco-proposed/universe) [7.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fuzzylite [arm64] (disco-proposed/universe) [6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [amd64] (disco-proposed/universe) [7.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fuzzylite [armhf] (disco-proposed/universe) [6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [i386] (disco-proposed/universe) [7.2.9-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fuzzylite [arm64] (disco-proposed) [6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ipe [amd64] (disco-proposed) [7.2.9-1]
-queuebot:#ubuntu-release- New: accepted fuzzylite [armhf] (disco-proposed) [6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ipe [i386] (disco-proposed) [7.2.9-1]
-queuebot:#ubuntu-release- New: accepted fuzzylite [amd64] (disco-proposed) [6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-intel-tfortools [amd64] (disco-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-proglottis-gpgme [amd64] (disco-proposed) [0.0~git20181127.3b0be09-2]
-queuebot:#ubuntu-release- New: accepted ipe [armhf] (disco-proposed) [7.2.9-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [armhf] (disco-proposed) [0.2.9-1]
-queuebot:#ubuntu-release- New: accepted pytools [amd64] (disco-proposed) [2019.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gosuri-uilive [amd64] (disco-proposed) [0.0~git20170323.ac356e6-1]
-queuebot:#ubuntu-release- New: accepted ipe [arm64] (disco-proposed) [7.2.9-1]
-queuebot:#ubuntu-release- New: accepted pysurfer [amd64] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-openzipkin-zipkin-go [amd64] (disco-proposed) [0.1.5+git20190103.2fd7f4a-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [arm64] (disco-proposed) [0.2.9-1]
-queuebot:#ubuntu-release- New: accepted backports.functools-lru-cache [amd64] (disco-proposed) [1.5-2]
-queuebot:#ubuntu-release- New: accepted golang-github-danverbraganza-varcaser [amd64] (disco-proposed) [0.0~git20151108.ce61ec4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-remeh-sizedwaitgroup [amd64] (disco-proposed) [0.0~git20180822.5e7302b-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [amd64] (disco-proposed) [0.2.9-1]
-queuebot:#ubuntu-release- New: accepted spoa [amd64] (disco-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted fuzzylite [ppc64el] (disco-proposed) [6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ipe [ppc64el] (disco-proposed) [7.2.9-1]
-queuebot:#ubuntu-release- New: accepted zsnapd [amd64] (disco-proposed) [0.8.5-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ianlancetaylor-demangle [amd64] (disco-proposed) [0.0~git20181102.5e5cf60-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [i386] (disco-proposed) [0.2.9-1]
-queuebot:#ubuntu-release- New: accepted fuzzylite [s390x] (disco-proposed) [6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libdist-inkt-role-git-perl [amd64] (disco-proposed) [0.001-1]
-queuebot:#ubuntu-release- New: accepted libtoxcore [s390x] (disco-proposed) [0.2.9-1]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo [i386] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-svgtypes [armhf] (disco-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted ipe [s390x] (disco-proposed) [7.2.9-1]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo [amd64] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-svgtypes [i386] (disco-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted libtoxcore [ppc64el] (disco-proposed) [0.2.9-1]
-queuebot:#ubuntu-release- New: accepted rust-svgtypes [arm64] (disco-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo [ppc64el] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-svgtypes [amd64] (disco-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted rust-svgtypes [s390x] (disco-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted rust-pangocairo [s390x] (disco-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-svgtypes [ppc64el] (disco-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New binary: rust-findshlibs [s390x] (disco-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-findshlibs [amd64] (disco-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sleef-sys [s390x] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-findshlibs [ppc64el] (disco-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-findshlibs [i386] (disco-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sleef-sys [ppc64el] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sleef-sys [amd64] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-findshlibs [armhf] (disco-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sleef-sys [i386] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sleef-sys [arm64] (disco-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-findshlibs [amd64] (disco-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-findshlibs [i386] (disco-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-findshlibs [s390x] (disco-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-sleef-sys [arm64] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-sleef-sys [ppc64el] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-findshlibs [armhf] (disco-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-sleef-sys [amd64] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-sleef-sys [s390x] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-findshlibs [ppc64el] (disco-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-sleef-sys [i386] (disco-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New binary: rust-findshlibs [arm64] (disco-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-object [amd64] (disco-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgdom [ppc64el] (disco-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgdom [amd64] (disco-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgdom [s390x] (disco-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-svgdom [i386] (disco-proposed/universe) [0.16.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-svgdom [i386] (disco-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New: accepted rust-svgdom [ppc64el] (disco-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New: accepted rust-findshlibs [arm64] (disco-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-svgdom [amd64] (disco-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New: accepted rust-object [amd64] (disco-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-svgdom [s390x] (disco-proposed) [0.16.0-1]
-queuebot:#ubuntu-release- New binary: rust-zip [ppc64el] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-zip [s390x] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-zip [amd64] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-zip [arm64] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-zip [i386] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-zip [armhf] (disco-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-zip [amd64] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-zip [armhf] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-zip [ppc64el] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-zip [arm64] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-zip [s390x] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-zip [i386] (disco-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New binary: golang-github-gosuri-uiprogress [amd64] (disco-proposed/universe) [0.0~git20170224.d0567a9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-keltia-archive [amd64] (disco-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-addr2line [amd64] (disco-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrocli [s390x] (disco-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrocli [ppc64el] (disco-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-gosuri-uiprogress [amd64] (disco-proposed) [0.0~git20170224.d0567a9-1]
-queuebot:#ubuntu-release- New: accepted rust-addr2line [amd64] (disco-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrocli [s390x] (disco-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-keltia-archive [amd64] (disco-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrocli [ppc64el] (disco-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New binary: rust-grcov [s390x] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grcov [ppc64el] (disco-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrocli [armhf] (disco-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrocli [amd64] (disco-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nitrocli [arm64] (disco-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-grcov [ppc64el] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrocli [amd64] (disco-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrocli [armhf] (disco-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-grcov [s390x] (disco-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-nitrocli [arm64] (disco-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New binary: rust-cargo-vendor [s390x] (disco-proposed/universe) [0.1.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cargo-vendor [amd64] (disco-proposed/universe) [0.1.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cargo-vendor [i386] (disco-proposed/universe) [0.1.22-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-cargo-vendor [amd64] (disco-proposed) [0.1.22-1]
-queuebot:#ubuntu-release- New: accepted rust-cargo-vendor [s390x] (disco-proposed) [0.1.22-1]
-queuebot:#ubuntu-release- New: accepted rust-cargo-vendor [i386] (disco-proposed) [0.1.22-1]
-queuebot:#ubuntu-release- New binary: rust-cargo-vendor [ppc64el] (disco-proposed/universe) [0.1.22-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-cargo-vendor [ppc64el] (disco-proposed) [0.1.22-1]
<LocutusOfBorg> sigh nodejs
-queuebot:#ubuntu-release- New binary: speech-dispatcher [s390x] (disco-proposed/main) [0.9.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: speech-dispatcher [i386] (disco-proposed/main) [0.9.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: speech-dispatcher [ppc64el] (disco-proposed/main) [0.9.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: speech-dispatcher [amd64] (disco-proposed/main) [0.9.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted jhdf [amd64] (disco-proposed) [2.11.0+dfsg-3ubuntu2]
-queuebot:#ubuntu-release- New binary: speech-dispatcher [armhf] (disco-proposed/main) [0.9.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: speech-dispatcher [arm64] (disco-proposed/main) [0.9.0-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted speech-dispatcher [amd64] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher [armhf] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher [ppc64el] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher [arm64] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher [s390x] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher [i386] (disco-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: rust-tokio [s390x] (disco-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-tokio [s390x] (disco-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New binary: rust-tokio [i386] (disco-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio [amd64] (disco-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio [ppc64el] (disco-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-tokio [amd64] (disco-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio [ppc64el] (disco-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio [i386] (disco-proposed) [0.1.14-1]
<LocutusOfBorg> vorlon, we might be good to go with nodejs, once autopkgtests finish, if we a) ignore yarn, new package, failing only on i386, who cares b) kick it out
<LocutusOfBorg> btw, upstream nodejs doesn't support anymore i386
-queuebot:#ubuntu-release- New binary: golang-github-xorpaul-uiprogress [amd64] (disco-proposed/universe) [0.0~git20170224.d0567a9-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.14 => 2.525.15] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.15]
-queuebot:#ubuntu-release- New binary: python-asttokens [amd64] (disco-proposed/none) [1.1.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-flor [amd64] (disco-proposed/none) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ontospy [amd64] (disco-proposed/none) [0~20190107~dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sqt [ppc64el] (disco-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sqt [amd64] (disco-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sqt [arm64] (disco-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-xorpaul-uiprogress [amd64] (disco-proposed) [0.0~git20170224.d0567a9-1]
-queuebot:#ubuntu-release- New: accepted python-asttokens [amd64] (disco-proposed) [1.1.13-1]
-queuebot:#ubuntu-release- New: accepted ontospy [amd64] (disco-proposed) [0~20190107~dfsg1-2]
-queuebot:#ubuntu-release- New: accepted python-flor [amd64] (disco-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted python-sqt [arm64] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted python-sqt [amd64] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted python-sqt [ppc64el] (disco-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New binary: gcc-9 [s390x] (disco-proposed/universe) [9-20190202-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qmath3d [ppc64el] (disco-proposed/none) [0~1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qmath3d [s390x] (disco-proposed/none) [0~1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qmath3d [amd64] (disco-proposed/universe) [0~1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qmath3d [i386] (disco-proposed/universe) [0~1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-9 [ppc64el] (disco-proposed/universe) [9-20190202-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qmath3d [arm64] (disco-proposed/universe) [0~1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qmath3d [armhf] (disco-proposed/universe) [0~1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-9 [i386] (disco-proposed/universe) [9-20190202-1ubuntu1] (no packageset)
<vorlon> LocutusOfBorg: yeah, I saw node-marked-man come through \o/
-queuebot:#ubuntu-release- New binary: gcc-9 [amd64] (disco-proposed/universe) [9-20190202-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-infrastructure-storage-tools [amd64] (disco-proposed/universe) [20180915-2] (no packageset)
#ubuntu-release 2019-02-03
-queuebot:#ubuntu-release- New: accepted open-infrastructure-storage-tools [amd64] (disco-proposed) [20180915-2]
-queuebot:#ubuntu-release- New: accepted qmath3d [amd64] (disco-proposed) [0~1.0-1]
-queuebot:#ubuntu-release- New: accepted qmath3d [armhf] (disco-proposed) [0~1.0-1]
-queuebot:#ubuntu-release- New: accepted qmath3d [ppc64el] (disco-proposed) [0~1.0-1]
-queuebot:#ubuntu-release- New: accepted qmath3d [arm64] (disco-proposed) [0~1.0-1]
-queuebot:#ubuntu-release- New: accepted qmath3d [s390x] (disco-proposed) [0~1.0-1]
-queuebot:#ubuntu-release- New: accepted qmath3d [i386] (disco-proposed) [0~1.0-1]
-queuebot:#ubuntu-release- New binary: gcc-9 [armhf] (disco-proposed/universe) [9-20190202-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-9 [arm64] (disco-proposed/universe) [9-20190202-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: soupsieve (disco-proposed/primary) [1.7.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9 [amd64] (disco-proposed) [9-20190202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9 [armhf] (disco-proposed) [9-20190202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9 [ppc64el] (disco-proposed) [9-20190202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9 [arm64] (disco-proposed) [9-20190202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9 [s390x] (disco-proposed) [9-20190202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9 [i386] (disco-proposed) [9-20190202-1ubuntu1]
<sil2100> o/
 * tumbleweed self-rejects soupsieve to try a bileto bootstrap
-queuebot:#ubuntu-release- New: rejected soupsieve [source] (disco-proposed) [1.7.3+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-updates/main) [2.32.5+18.04 => 2.34.2+18.04] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [sync] (bionic-updates) [2.34.2+18.04]
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.34.2+18.04 => 2.37.1.1+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.37.1.1+18.04]
-queuebot:#ubuntu-release- New binary: eye [amd64] (disco-proposed/universe) [19.0116.1239~ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-infrastructure-service-tools [amd64] (disco-proposed/universe) [20170701-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libusrsctp [amd64] (disco-proposed/universe) [0.9.3.0+20190127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netdata [i386] (disco-proposed/universe) [1.11.1+dfsg-6] (no packageset)
-queuebot:#ubuntu-release- New binary: libusrsctp [i386] (disco-proposed/universe) [0.9.3.0+20190127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusrsctp [s390x] (disco-proposed/universe) [0.9.3.0+20190127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusrsctp [ppc64el] (disco-proposed/universe) [0.9.3.0+20190127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusrsctp [arm64] (disco-proposed/universe) [0.9.3.0+20190127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusrsctp [armhf] (disco-proposed/universe) [0.9.3.0+20190127-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted eye [amd64] (disco-proposed) [19.0116.1239~ds-1]
-queuebot:#ubuntu-release- New: accepted libusrsctp [arm64] (disco-proposed) [0.9.3.0+20190127-1]
-queuebot:#ubuntu-release- New: accepted libusrsctp [i386] (disco-proposed) [0.9.3.0+20190127-1]
-queuebot:#ubuntu-release- New: accepted libusrsctp [s390x] (disco-proposed) [0.9.3.0+20190127-1]
-queuebot:#ubuntu-release- New: accepted open-infrastructure-service-tools [amd64] (disco-proposed) [20170701-3]
-queuebot:#ubuntu-release- New: accepted libusrsctp [amd64] (disco-proposed) [0.9.3.0+20190127-1]
-queuebot:#ubuntu-release- New: accepted libusrsctp [ppc64el] (disco-proposed) [0.9.3.0+20190127-1]
-queuebot:#ubuntu-release- New: accepted libusrsctp [armhf] (disco-proposed) [0.9.3.0+20190127-1]
-queuebot:#ubuntu-release- New: accepted netdata [i386] (disco-proposed) [1.11.1+dfsg-6]
-queuebot:#ubuntu-release- New binary: spf-engine [amd64] (disco-proposed/universe) [2.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2gobroker [i386] (disco-proposed/none) [0.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyrandom2 [amd64] (disco-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: social-auth-app-django [amd64] (disco-proposed/none) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: x2gobroker [s390x] (disco-proposed/none) [0.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2gobroker [amd64] (disco-proposed/none) [0.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2gobroker [ppc64el] (disco-proposed/none) [0.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2gobroker [arm64] (disco-proposed/universe) [0.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2gobroker [armhf] (disco-proposed/universe) [0.0.4.0-1] (no packageset)
#ubuntu-release 2020-01-27
-queuebot:#ubuntu-release- New binary: swami [s390x] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: swami [amd64] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: swami [ppc64el] (focal-proposed/universe) [2.2.0-2] (no packageset)
<mwhudson> infinity: so fwiw, my "trailing space in d/changelog" is a vs A not i vs A fwiw :)
-queuebot:#ubuntu-release- New binary: swami [arm64] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: swami [armhf] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted swami [amd64] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted swami [armhf] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted swami [s390x] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted swami [arm64] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted swami [ppc64el] (focal-proposed) [2.2.0-2]
<infinity> mwhudson: A-ha.  (a-ha?)
<Eickmeyer[m]> infinity: *80s music intensifies*
-queuebot:#ubuntu-release- New binary: v-sim [s390x] (focal-proposed/universe) [3.7.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: v-sim [amd64] (focal-proposed/universe) [3.7.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: v-sim [ppc64el] (focal-proposed/universe) [3.7.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: v-sim [arm64] (focal-proposed/universe) [3.7.2-8] (no packageset)
-queuebot:#ubuntu-release- New binary: v-sim [armhf] (focal-proposed/universe) [3.7.2-8] (no packageset)
<ddstreet> hi sil2100, i know you're busy with point release work, but any chance you might have time to review the systemd uploads for b/e?  And also util-linux in x/b/e if possible...and we also have qemu in b/e...
<ddstreet> the systemd upload is actually a re-upload to address some of vor-lon's comments, and to add more bugfixes...it was originally uploaded a week or two ago
<LocutusOfBorg> please somebody remove sfcgal on armhf
<LocutusOfBorg> missing build on armhf: libsfcgal-dev, libsfcgal1 (from 1.3.7-2ubuntu1)
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946261
<ubot5> Debian bug 946261 in ftp.debian.org "RM: sfcgal [armhf] -- ROM; Architecture specific issue" [Normal,Open]
<jibel> xnox, re bug 1860559 could you add the dependency on finalrd to casper on bionic?
<ubot5> bug 1860559 in linux (Ubuntu Bionic) "[18.04.4] System fails to reboot after installation" [Critical,Confirmed] https://launchpad.net/bugs/1860559
<jibel> finalrd has been promoted to main last friday
<sil2100> ddstreet: util-linux is on my TODO list, I'll try also looking at systemd though o/
<ddstreet> much thanks!
<ddstreet> and qemu should be a really easy one, very small patch, if you have time
<ddstreet> however qemu is still waiting on the focal merge so it can wait
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (eoan-proposed) [2.34-0.1ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (bionic-proposed) [2.31.1-0.4ubuntu3.5]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.10]
<mfo> sil2100, thanks ^
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (eoan-proposed) [1:4.0+dfsg-0ubuntu9.3]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.22]
<sforshee> doko: we're seeing cross-toolchain-base test failures with the focal-proposed kernel. They don't look kernel related though, can you confirm? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/c/cross-toolchain-base/20200122_153118_a4418@/log.gz
<bdmurray> sil2100: What sort of verification should I do for u-r-u in bionic-proposed?
<sil2100> bdmurray: we usually don't do any verification, but guess checking if one can successfully run u-r-u would be enough I'd say
<sil2100> (any verification for mirror-bumps on point-release SRUs that is)
<bdmurray> sil2100: Okay, I'll do an X to B upgrade just in case
<sil2100> bdmurray: thank you!
<bdmurray> jibel: Are we doing any automatic upgrade testing to 18.04?
<gQuigs> was just going to ping to have SRU of python-ldap for disco removed, but could all the SRUs just be dropped for disco (and trusty..)
-queuebot:#ubuntu-release- New binary: dbus-cpp [amd64] (focal-proposed/universe) [5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dbus-cpp [arm64] (focal-proposed/universe) [5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wordpress (eoan-proposed/universe) [5.2.2+dfsg1-1 => 5.2.2+dfsg1-1ubuntu0.1] (no packageset)
<infinity> gQuigs: I'll be tidying up and closing disco today.  trusty's a weirder case.
<gQuigs> infinity: thanks!  why is trusty so weird?
-queuebot:#ubuntu-release- Unapproved: dmidecode (eoan-proposed/main) [3.2-2 => 3.2-2ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: dmidecode (bionic-proposed/main) [3.1-1 => 3.1-1ubuntu0.1] (core)
<doko> sforshee: please give it back
-queuebot:#ubuntu-release- Unapproved: dmidecode (xenial-proposed/main) [3.0-2ubuntu0.1 => 3.0-2ubuntu0.2] (core)
<sforshee> doko: come again?
<doko> sforshee: ?
<sforshee> doko: I don't understand what you meant by "please give it back"
<doko> sforshee: you're testing against 2.33.1-6ubuntu3, which isn't in the archive anymore
<sforshee> doko: ok I'll retry, thanks
<bdmurray> sil2100: The release upgrade went well.
-queuebot:#ubuntu-release- Packageset: Removed x11-utils from i386-whitelist in focal
<infinity> sforshee: "give-back" is a command in the Debian buildd/wanna-build stack that amounts to a buildd releasing a build back to the queue, so when old farts like doko say "give it back", they mean "hit the retry button".
<cjwatson> I was about to say that it never made sense in Ubuntu because Launchpad's builders don't work that way, but I guess it actually did in 2004/2005 when we ran dak
<cjwatson> Language is really sticky though
<cjwatson> Trying to explain why rmadison is called that to new Launchpad developers recently involved several layers of backing up and explaining another layer
<doko> sforshee: btw, what are these "No change, rebuild to use new binutils" kernel uploads?
#ubuntu-release 2020-01-28
-queuebot:#ubuntu-release- Unapproved: libclc (bionic-proposed/universe) [0.2.0+git20190827-1~ubuntu18.04.1 => 0.2.0+git20190827-1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libclc (eoan-proposed/universe) [0.2.0+git20190827-1 => 0.2.0+git20190827-1ubuntu0.19.10.1] (no packageset)
<tjaalton> sil2100: hi, these ^ fix a regression with opencl
-queuebot:#ubuntu-release- New binary: pynag [amd64] (focal-proposed/universe) [1.1.2+dfsg-1ubuntu1] (no packageset)
<sil2100> tjaalton: oh no, ok! Looking
<sil2100> tjaalton: did you push this revert to focal as well?
<tjaalton> sil2100: it'll sync from debian
<sil2100> Awesome
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (eoan-proposed) [0.2.0+git20190827-1ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (bionic-proposed) [0.2.0+git20190827-1ubuntu0.18.04.1]
<tjaalton> thanks1
<tjaalton> !
<juliank> We should force-badtest aptdaemon/arm64/all I think
<juliank> It did pass _once_
<juliank> once in eoan, once in focal so far
<juliank> there's a race condition somewhere that's been there forever
<juliank> Then we can have aptdaemon migrate to release
<juliank> which will partially unblock python-apt 1.9.5 I just pushed to proposed
<xnox> sil2100:  casper is verified in bionic, can it please be released early such that i can upload it again?
<sil2100> xnox: yeah, on it! In the meantime, just upload it to the queue and I'll pick it up in a moment
<sil2100> Thanks!
-queuebot:#ubuntu-release- Unapproved: casper (bionic-proposed/main) [1.394.2 => 1.394.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: node-node-sass [amd64] (focal-proposed/universe) [4.13.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-quantities [amd64] (focal-proposed/none) [0.12.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-node-sass [amd64] (focal-proposed) [4.13.1-1]
-queuebot:#ubuntu-release- New: accepted v-sim [arm64] (focal-proposed) [3.7.2-8]
-queuebot:#ubuntu-release- New: accepted python-quantities [amd64] (focal-proposed) [0.12.4-1]
-queuebot:#ubuntu-release- New: accepted v-sim [armhf] (focal-proposed) [3.7.2-8]
-queuebot:#ubuntu-release- New: accepted v-sim [amd64] (focal-proposed) [3.7.2-8]
-queuebot:#ubuntu-release- New: accepted v-sim [s390x] (focal-proposed) [3.7.2-8]
-queuebot:#ubuntu-release- New: accepted v-sim [ppc64el] (focal-proposed) [3.7.2-8]
<xnox> apw:  infinity: sil2100: seeding oem kernels in focal properly https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/patch/?id=c287b1923d23ac9ef72d08dbc56f32757f7168df they appear to have landed into universe pocket for now.
<apw> xnox, ta
-queuebot:#ubuntu-release- New: accepted pynag [amd64] (focal-proposed) [1.1.2+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted dbus-cpp [amd64] (focal-proposed) [5.0.1-1]
-queuebot:#ubuntu-release- New: accepted dbus-cpp [arm64] (focal-proposed) [5.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (bionic-proposed) [1.394.3]
<ahasenack> hi release team, if someone could please merge https://code.launchpad.net/~ahasenack/britney/samba-i386-bump/+merge/378163
-queuebot:#ubuntu-release- New binary: neo [amd64] (focal-proposed/universe) [0.7.2-2] (no packageset)
<tumbleweed> ahasenack: let's move that to a * then
<ahasenack> I tend to be conservative with *, and i386 issues
<tumbleweed> if we don't expect it to ever pass, it should be a *
<ahasenack> at the same time, it seems to be under a section called "needs investigation", and it's possible I missed something
<tumbleweed> half the other packages in the archive are
<tumbleweed> it sounds like you investigated :P
<ahasenack>  the dropping of samba/i386 (the bin package) was a request from vorlon, and he reviewed that, so I'm not sure why he didn't use * already
<ahasenack> that's all
<ahasenack> tumbleweed: can  you merge that? Or are you just commenting?
-queuebot:#ubuntu-release- New: accepted neo [amd64] (focal-proposed) [0.7.2-2]
<tumbleweed> I can merge that
<ahasenack> do you want me to change it to *?
<tumbleweed> naah, I can post-merge
<sforshee> doko: yes they are
<ahasenack> tumbleweed: thanks!
<doko> sforshee: I'm asking "what are they?", and you reply with "yes they are"?
<sforshee> doko: sorry, misread. The previous arm64 kernels wouldn't boot, and xnox told us there had been a binutils problem with arm64 which was fixed. Rebuilding the kernel fixed the arm64 boot issue
<doko> sforshee: yes, just wondering that I see these changelog entries now a lot
<sforshee> doko: we haven't done many of these type of uploads at all for devel series kernels that I can recall, if you are talking about SRU kernels I'm not so much in the loop on those
<doko> vorlon: please could you add a python3-defaults hints like the one we had for python-defaults?
<ahasenack> hi release team, another i386 bump for your consideration please: https://code.launchpad.net/~ahasenack/britney/bump-tdb-i386/+merge/378167
<ahasenack> ops, wrong merge target
<ahasenack> fixed^
<apw> ahasenack, not looking any different, showing 8k lines of change
<ahasenack> the url probably changed
<ahasenack> let me paste
<ahasenack> apw: https://code.launchpad.net/~ahasenack/britney/bump-tdb-i386/+merge/378168
<ahasenack> sorry
<ahasenack> thanks apw
<xnox> apw:  components missmatches has now caught up, please promote oem stuff to main in focal as per https://lists.ubuntu.com/archives/ubuntu-release/2020-January/004890.html
<xnox> once that publishes, we can re-add livecd-rootfs change to install oem kernel flavour
<apw> xnox, wiggled
<xnox> apw:  Ok google, play "Wiggle" feat. Snoop Dogg by Jason Derulo
<vorlon> doko: python3-defaults> done
-queuebot:#ubuntu-release- New binary: zeitgeist [amd64] (focal-proposed/universe) [1.0.2-3ubuntu1] (ubuntu-budgie, ubuntukylin)
-queuebot:#ubuntu-release- New: accepted zeitgeist [amd64] (focal-proposed) [1.0.2-3ubuntu1]
<vorlon> doko: looks like python3.* are holding up the libffi transition currently
 * vorlon kicks some test retries with all-proposed
<doko> vorlon: it looks like i386 removals hold up the python3.8 transition
<vorlon> doko: ?
<vorlon> doko: is that rdma-core, or something else?
<doko> ceph
<vorlon> right
<vorlon> rdma-core+ceph, I've been working on, but there was another revdep after samba removed its dep
<vorlon> so I had to get openmpi to migrate, now I'm checking the results right now
<doko> I'm not yet looking at autopkg test failures, still doing the transition tracker
<vorlon> so ceph is now out of the picture but hwloc still wants rdma-core :P
-queuebot:#ubuntu-release- Packageset: Removed libfabric from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed pep8 from i386-whitelist in focal
<vorlon> doko: ceph binaries cleaned up from -proposed, but it looks like the ceph in -proposed also has other installability issues
<bdmurray> sil2100: I'm not sure if you saw my ping but I upgraded from X to B with -proposed and u-r-u is good to go.
<sil2100> bdmurray: awesome, thank you o/
<infinity> xnox: Why are we adding the oem kernel to the desktop ISO, and is this meant to be backed out before release, or...?
<xnox> infinity:  it's meant to be backed into focal release.....
<xnox> as the second flavour
<xnox> there is now a real 5.4 oem flavour
<xnox> which is different from generic
<infinity> ... why?
<doko> make it 5.5
<infinity> The whole point of OEM was to exit post-release and carry patches to agressive for stable kernels, but ultimately converge on the next generic.
<xnox> infinity:  because there will be certified laptops on release day that will not work with generic, but will work with oem flavour. also it is likely that oem flavour will be 5.5 based at focal release time.
<infinity> s/exit/exist/
<xnox> infinity:  whilst your statement is true, it will not be so at 20.04.0 release day
<infinity> xnox: Okay, and those certified laptop would have their own images/media, no?
<xnox> infinity:  or maybe even v5.6 based oem flavour, with v5.4 based generic flavour at 20.04.0 time.
<infinity> Complicating our "simple" installer with two kernels we can't adequately explain to the end user is not great.
<infinity> And if one if 5.4 and one is 5.5, everyone will pick the 5.5 kernel.
<infinity> So we may as well ditch generic.
<xnox> infinity:  .... there is UX work, and installer work, to offer certified installer all-in-one......
<xnox> which desktop team are working on.
<infinity> Sunk cost doesn't imply it was a good idea.
<xnox> there will not be an linux-hwe v5.6 based at release time.
<xnox> and v5.6-oem will not be as usable as generic one is.
 * xnox should finish the draft email to techboard.....
<infinity> And literally no "dumb end user" will understand that.
<xnox> infinity: non-certified machines will only boot -generic, and will not see any of the certified ux, or even the oem kernel.
<infinity> This is why we don't ship both GA and HWE on desktop images today.
<infinity> Giving people choice between kernel versions is not "simple" or "intuitive".
<xnox> certified ones will boot to the oem kernel by default
<infinity> Oh, gross.
<xnox> meaning by default there is no choice.
<xnox> unless one tries hard
<infinity> You're doing this with ACPI model queries in grub?
<xnox> (i.e. squint at grub meny on hi-dpi)
<xnox> infinity:  yes. vendor, sku, product id.
<infinity> re: squinting at grub menu, the non-default kernel shouldn't even be in the menu.
<xnox> see smbios module that is in grub2 that can query all the things that are in $ sudo dmidecode => and match verbantim the vendor metapackages modaliases matches by sku
<infinity> But okay, if you can hide it so it appears as though there's only one kernel per machine, I'll retract most of my "ew", except for the part where it's still kinda gross. ;)
<xnox> infinity: add duplicate linux-restricted-modules and duplicate nvidia stuff too, to that ew to make it "ew supreme" .....
<infinity> And I still bet you'll see blogs and forum posts telling people to run out and install linux-oem over linux-generic in one of those "first things to tweak after installing focal!" articles because the version's higher.
<xnox> infinity:  i expect that for tigerlake / flagship laptops => yes.
<xnox> infinity:  given that one can edit grub menu entry from 'vmlinuz' 'vmlinuz-oem' i think it's ok. Also, I was hoping to allow expert users to opt-into vanilla experience only, despite oem certified machine, because paranoia.
<infinity> xnox: Letting OEM opt into GA is fine, letting GA opt into OEM is more sketchy.
<xnox> "it's ok" to have like "Advanced Options" grub submenu with vanilla / oem entries.
<vorlon> infinity: the reason we don't ship both GA and HWE on desktop today is that we can't guarantee they'll both work with the same squashfs due to userspace entanglement (drm, mesa).  But I've been given a committment going forward that there isn't going to be any more hwe skew for the graphics stack
<infinity> xnox: And by "letting", I mean "having a visible menu item".
<xnox> infinity:  oh yes, i mean oem opt into ga.
<vorlon> like, we do present both ga and hwe kernels on server; the above is the blocking reason from my perspective why we never did the same on desktop
<infinity> vorlon: Now more HWE skew for the graphics stack?  In what sense?
<infinity> I'm curious about how this commitment was made in good faith. :P
<vorlon> infinity: something something precise something libdrm-hwe
<infinity> vorlon: But anyhow, I reject your assertion.  We toyed with shipping both, and opted not to because confusing.
<vorlon> infinity: if the kernel team is signing up to maintain compatibility, then
<xnox> infinity:  so i think apw said that graphics stack will follow the new kernel naming with version indirection, to roll people forward as much as possible; and use metapackages to create whatever is called "stable" vs "edge"(hwe) graphics stack.
<vorlon> xnox: that is very different than what I was told
<xnox> infinity:  i.e. most things need not to be divergent anymore; and it's only partial amouns of stack that needs to diverge.
<vorlon> having any amount of the stack have to diverge means you can't use the same root squashfs for desktop
<xnox> vorlon:  well, i am relaying what i understood apw said at the weekly OEM desktop calls
<vorlon> xnox: apw and tjaalton need to get on the same page then
<infinity> Yeah, the only way to have One True Livefs is for the kernel interfaces to be backported.
<xnox> vorlon:  true, but i thought they will package things "normal" "edge" and roll edge->normal on continious basis.
<infinity> Which they generally are for OEM, but not for GA.
<infinity> Of course, that's enough if .1 has OEM/GA compat and .2 has OEM/HWE compat.
<infinity> Which, really, is how it's been for years anyway.
<infinity> (The bionic X stack depends on hwe/oem)
<infinity> So maybe they're promising no changes because it's already being done right? :P
<infinity> (Ignoring GA, of course)
<xnox> that was the open question if we will seed ga/hwe/oem at .2 time, or if we stick to hwe/oem only for .2 onwards
<xnox> however, we will potentially have equivalent of X stack needs to work on ga/oem at .0 time where ga is v5.4 and oem is v5.6
<xnox> which is closer to ga/hwe compat from graphics point of view
<ahasenack> hi release team, another /i386 hint bump for your consideration, talloc this time: https://code.launchpad.net/~ahasenack/britney/bump-talloc-i386/+merge/378196
<blackboxsw> RAOF:  Is there an ubuntu-sru vanguard available to review the cloud-init -proposed SRU into xenial, bionic and eoan today? https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1859725
<ubot5> Ubuntu bug 1859725 in cloud-init (Ubuntu) "sru cloud-init (19.3.41 to 19.4.33) Xenial, Bionic and Eoan" [Undecided,New]
<tjaalton> xnox, vorlon: hum, what I recall saying last time in paris was that GA kernel works with HWE gfx stack, as it has already done for a couple of lts releases
<tjaalton> so there's no reason why generic/oem kernel can't use the same userspace
<tjaalton> if userspace is newer, but kernel is lacking a feature that userspace supports, then it's not getting enabled
<tjaalton> if it's the other way around, same thing essentially
<xnox> infinity:  ^^^^
-queuebot:#ubuntu-release- Packageset: Added nvidia-settings to i386-whitelist in focal
<infinity> tjaalton: Okay, so it's not that any effort is being made by us to make the interfaces compatible, it's just that upstream got smarter about bilateral backward compatibility on both sides of said interfaces?
<infinity> (Maybe more technically forward compatibility in this case, but...)
<tjaalton> infinity: well, new stuff might get added, but I don't recall old stuff removed breaking userspace
<infinity> tjaalton: Sure, but there's a difference between "it's been working like this because no one removed old interfaces" and "it's working like this because people committed to not removing old interfaces".
<infinity> tjaalton: One is an interesting anecdote, the other is something we can count on. :P
<tjaalton> "New functionality in the kernel DRM drivers typically requires a new libdrm,
<tjaalton> but a new libdrm will always work with an older kernel.
<tjaalton> "
<tjaalton> that's from libdrm readme
<tjaalton> so I think we can count on that ;)
<tjaalton> we wouldn't be the only ones to yell if something broke
-queuebot:#ubuntu-release- Unapproved: pandas (eoan-proposed/universe) [0.23.3+dfsg-4ubuntu1 => 0.23.3+dfsg-4ubuntu1.1] (no packageset)
<vorlon> ahasenack: bumped talloc to talloc/all/i386, because python
<ahasenack> vorlon: great, thanks
<Eickmeyer[m]> xnox: Question: Is the lowlatency flavor of the kernel going to be affected in any way?
<infinity> Eickmeyer[m]: Don't see why it would be.
<infinity> Eickmeyer[m]: This is just about which kernel(s) we inclue on the Ubuntu desktop image, nothing else really changes for anyone.
<Eickmeyer[m]> infinity: Perfect. Thanks.
<vorlon> infinity: are you driving https://wiki.ubuntu.com/EndOfLifeProcess for disco? I just told tdaitx not to add new disco blacklist entries for autopkgtest because it's EOL, then I notice we haven't done the rest of the cleanup yet
<infinity> vorlon: Yeah, I'm doing some archive tidying right now and then whacking it.
<vorlon> ok
<vorlon> juliank, Laney: fyi I'm taking care of the disco EOL autopkgtest task
<bdmurray> I just happened to notice that disco is still listed as supported.
<bdmurray> In LP
<xnox> Eickmeyer[m]:  affected... in respect to what? lowlatency today is a subflavour enabled on certain kernels. I.e. there is generic and generic-lowlatency
<xnox> just like it was before, and is now.
-queuebot:#ubuntu-release- Unapproved: walinuxagent (eoan-proposed/main) [2.2.40-0ubuntu1 => 2.2.45-0ubuntu1~19.10.1] (core, ubuntu-cloud)
<Eickmeyer[m]> xnox: Thanks for the clarification.
-queuebot:#ubuntu-release- Unapproved: walinuxagent (bionic-proposed/main) [2.2.40-0ubuntu1~18.04.1 => 2.2.45-0ubuntu1~18.04.1] (ubuntu-cloud)
<juliank> vorlon: ack
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.40-0ubuntu1~16.04.1 => 2.2.45-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
<xnox> lowlatency is the default on some flavour, but can't remember which
<wxl> probably studio
<wxl> which would be relevant given that's home for Eickmeyer[m] :)
<Eickmeyer[m]> xnox: It's seeded by Ubuntu Studio.
<xnox> yeah, that one installs lowlatency, and only uses lowlatency, and nothing else.
<xnox> no changes there.
<Eickmeyer[m]> xnox: Not sure if you know, but I lead Ubuntu Studio, so anything that affects Studio greatly interests me. Hence my question.
#ubuntu-release 2020-01-29
<blackboxsw> bdmurray: I don't think I was able to get RAOF today for ubuntu-sru. Do you think there is time today for an SRU verification for cloud-init for xenial, bionic and eoan per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1859725
<ubot5> Ubuntu bug 1859725 in cloud-init (Ubuntu) "sru cloud-init (19.3.41 to 19.4.33) Xenial, Bionic and Eoan" [Undecided,In progress]
<RAOF> blackboxsw: Heh. I'm currently looking at that :)
<bdmurray> well then my work here is done
<powersj> \o/
<RAOF> Is there a reason why the oracle tests are only run on xenial and bionic?
<powersj> blackboxsw, ^ I think it has to do with image availability but will let him confirm
<blackboxsw> RAOF awesome: and yes oracle only has LTS images
<RAOF> That was my guess :)
<blackboxsw> so eaon isn't available publicly (at least I can't launch those type of instances on my account type)(
<blackboxsw> account type == grunt :)
<RAOF> If normal people can't launch them then normal people can't run into any regressions with the SRU ð
<blackboxsw> heh.   RAOF: note only unique thing we ran into during testing was in maas-sru and curtin-proposed-sru attached logs. I annotated the top of those files with info about why the exceptions are known (haven't SRU'd yet for both maas and curtin)
<RAOF> Yeah, thanks for that. It makes!
<blackboxsw> I think we'll follow that general process if we happen to have any logs showing SRU verification failures test failures if they are known exceptions
<blackboxsw> for future SRUs too
<blackboxsw> good deal
<RAOF> Bah! That's right! Focal's dropped python2-launchpadlib.
-queuebot:#ubuntu-release- Unapproved: lz4 (bionic-proposed/main) [0.0~r131-2ubuntu3 => 0.0~r131-2ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: lz4 (xenial-proposed/main) [0.0~r131-2ubuntu2 => 0.0~r131-2ubuntu2.1] (core)
-queuebot:#ubuntu-release- New binary: pyside2 [s390x] (focal-proposed/universe) [5.14.0-1~exp1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyside2 [amd64] (focal-proposed/universe) [5.14.0-1~exp1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pyside2 [amd64] (focal-proposed) [5.14.0-1~exp1build1]
-queuebot:#ubuntu-release- New: accepted pyside2 [s390x] (focal-proposed) [5.14.0-1~exp1build1]
-queuebot:#ubuntu-release- New binary: pyside2 [ppc64el] (focal-proposed/universe) [5.14.0-1~exp1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pyside2 [ppc64el] (focal-proposed) [5.14.0-1~exp1build1]
-queuebot:#ubuntu-release- New binary: vala [s390x] (focal-proposed/universe) [0.47.3-1~ubuntu1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [amd64] (focal-proposed/universe) [0.47.3-1~ubuntu1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [i386] (focal-proposed/universe) [0.47.3-1~ubuntu1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [ppc64el] (focal-proposed/universe) [0.47.3-1~ubuntu1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [armhf] (focal-proposed/universe) [0.47.3-1~ubuntu1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [arm64] (focal-proposed/universe) [0.47.3-1~ubuntu1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted vala [amd64] (focal-proposed) [0.47.3-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [armhf] (focal-proposed) [0.47.3-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [ppc64el] (focal-proposed) [0.47.3-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [arm64] (focal-proposed) [0.47.3-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [s390x] (focal-proposed) [0.47.3-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [i386] (focal-proposed) [0.47.3-1~ubuntu1]
<LocutusOfBorg> hello, is it possible to NBS-proposed cleanup python-mpi4py and python-mpi4py-dbg? thanks
<apw> locutus__, looking
<doko> locutus__: you looked at pyside2 before. any idea why freecad can't find it?
<RikMills> doko: this? https://tracker.freecadweb.org/view.php?id=4229
<RikMills> I see /bin/sh: 1: PYSIDE2RCCBINARY-NOTFOUND: not found in the buildlog
<doko> RikMills: yes
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440 (eoan-proposed/primary) [440.44-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (eoan-proposed/restricted) [390.129-0ubuntu2 => 390.132-0ubuntu0.19.10.1] (core)
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440 (bionic-proposed/primary) [440.44-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (bionic-proposed/restricted) [340.107-0ubuntu0.18.04.4 => 340.108-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (eoan-proposed/restricted) [340.107-0ubuntu7 => 340.108-0ubuntu0.19.10.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.116-0ubuntu0.18.04.3 => 390.132-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-settings (bionic-proposed/main) [390.77-0ubuntu0.18.04.1 => 440.44-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-settings (eoan-proposed/main) [435.21-0ubuntu2 => 440.44-0ubuntu0.19.10.1] (ubuntu-desktop)
<tseliot> hey sil2100, can you have a look at these ^ uploads, please? (some of them are in NEW). This is for LP: #1854485
<ubot5> Launchpad bug 1854485 in nvidia-settings (Ubuntu Eoan) "Introduce the new NVIDIA 440 series, and add 5.4 Linux compatibility to the 340 and 390 series" [Medium,In progress] https://launchpad.net/bugs/1854485
<sil2100> tseliot: hey! Looking in a moment
<tseliot> thanks :)
<sil2100> tseliot: ok, will try to go through some of them today, but if I won't be able to do all I'll pick the rest up tomorrow during my SRU shift ;)
<sil2100> (if that's fine with you)
<locutus__> doko, yes
<locutus__> and I don't think syncing from experimental was a good idea...
<tseliot> sil2100, that would be great, thanks :)
<cpaelzer> need to do some pings ...
<cpaelzer> first https://code.launchpad.net/~paelzer/britney/hints-ubuntu-focal-pgsql-i386-universe/+merge/378234 for a release Team member
<cpaelzer> to get some more tests affected by i386 out of excuses
-queuebot:#ubuntu-release- Unapproved: pandas (bionic-proposed/universe) [0.22.0-4 => 0.22.0-4ubuntu1] (no packageset)
<coreycb> rbasak: hello, I have new pandas uploads in the eoan and bionic unapproved queues. If you have some time today could you take a look? the bionic pandas update is blocking some of our openstack ussuri cloud archive backports.
<rbasak> Sure, looking
<locutus__> is it possible to blacklist also openjdk-13 on armhf?
<locutus__> # timeouts on armhf
<locutus__> force-badtest openjdk-lts/all/armhf
<locutus__> timeout... same reason as the lts one (also 14 has probably to be blacklisted?)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (eoan-proposed) [340.108-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted pandas [source] (eoan-proposed) [0.23.3+dfsg-4ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted pandas [source] (bionic-proposed) [0.22.0-4ubuntu1]
<rbasak> coreycb: accepted, but just one thing - Eoan looks successfully built for armhf. So do we need to release the SRU to Eoan users after verification, or is it OK to hold that in proposed indefinitely?
<seb128> locutus__, see #ubuntu-devel backlog from the past hour about openjdk
<coreycb> rbasak: thank you. eoan should be ok to hold in proposed.
<locutus__> seb128, so they are going to be blacklisted? thanks!
<seb128> locutus__, np!
<locutus__> I mean hinted :)
<rbasak> coreycb: great, thanks!
-queuebot:#ubuntu-release- New binary: pep8 [amd64] (focal-proposed/main) [1.7.1-9ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted pep8 [amd64] (focal-proposed) [1.7.1-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (bionic-proposed) [340.108-0ubuntu0.18.04.1]
<doko> locutus__: freecad built on arm64, but just on arm64. puzzled
<locutus__> doko, I already have a patch
<locutus__> + - [PYSIDE-1098] Replace pyside2-uic/pyside2-rcc by
<locutus__> +                 uic/rcc which now have an option to generate Python
<locutus__> reason is that the arm64 build picked up: Setting up shiboken2 (5.13.2-2.2) ...
<locutus__> I will upload a fixed freecad after coffee, I leave to you fixing autopkgtest regressions
<chiluk> mdeslaur https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1861304
<ubot5> Ubuntu bug 1861304 in mysql-5.7 (Ubuntu Bionic) "libmysqlclient-dev will not install with libssl1.0-dev" [High,New]
<mdeslaur> chiluk: yep, sucks
<chiluk> looks like the correct course of action is simply break people and force an upgrade to libssl1.1?  it really feels like there should have been a libssl meta package that updated to the new version.
<chiluk> is there a reason that doesn't exist?
<chiluk> and that libssl1.0 and libssl1.1 are explicitly versioned?
<xnox> chiluk:  both 1.0.2 and 1.1.1 dev packages ship /usr/include/openssl/ssl.h and changing that path would break all software trying to build against both versions.
<xnox> chiluk:  and mysql is a client binding library which must ensure that clients against that link against mysql library, also link and build against matching libssl, as one is not allowed to link and load both libssl's in a single binary
<xnox> closed as invalid
-queuebot:#ubuntu-release- New binary: fonts-arundina [amd64] (focal-proposed/universe) [0.3.1-1] (no packageset)
<chiluk> xnox, I understand why there are separte versioned libssl1.x packages, what I don't get is why there's not a meta-package to assist with updates.
<xnox> chiluk:  what sort of metapackages? the libssl-dev is a metapackage that points to latest, and each binary app must be rebuild and relinked against the new libssl-dev which autogenerates the dependency on libssl1.0 or libssl1.1 binary packages through abi / symbol dependencies.
<xnox> chiluk:  one cannot magically install a different libssl and expect all binaries to change abi, they need to be rebuilt.
<cjwatson> Right, a metapackage for the runtime libraries would be anti-helpful
<xnox> chiluk: it is highly unusual to install libssl1.0-dev and very few people ever do that. My question to you is why did installing "libssl1.0-dev" made it into your scripts on bionic in the first place.
<xnox> as that package only exists on bionic, and doesn't exist on any other releases.
<chiluk> I suspect that was done explicitly because the libraries were needed for development of applications here when we were on 16.04, and the scripts were not upgraded to libssl1.1 when upgraed to 18.04
<chiluk> which was probably done to maintain stability of environment between 16.04 and 18.04
<chiluk> it might have also been a dependency of some out-of-archive package.... which was from before my time.
<xnox> some packages did declare "Build-Depends: libssl-dev (< 1.1.0) | libssl1.0-dev" to be buildable on 16.04 and 18.04 against openssl1.0.
<chiluk> either way I think we have a solution... thanks guys, and I think I learned something as well.
<xnox> chiluk:  by default, one must use matching series to build the binaries for..... i.e. the abis change significantly between releases, with required minimum versions, even if package name stays the same.
<xnox> i.e. glibc generates higher version requirements in focal, than in bionic, which in turn is higher than xenial.....
<xnox> chiluk:  please use libssl-dev everywhere, and please use libssl1.1 in bionic and up; and libssl1.0 in xenial and down.
<chiluk> right.. that's the problem.
<infinity> Well, or you build everything on the oldest release you have and hope for the best. :P
<cjwatson> I'm not sure where this meme comes from that there ought to have been a libssl runtime library metapackage.  It's not something we do elsewhere.
<chiluk> the developer environment at indeed explicitly installed libssl1.0 to be compatible accross 16.04 and 18.04...
<chiluk> which was a poor decision made by those before me.
<xnox> chiluk:  if we only had openssh ported in time for bionic release, we would not have shipped libssl1.0 there at all. but alas timing didn't work out.
<xnox> chiluk:  libssl1.0 is dead and has been removed from ubuntu, focal will only have 1.1
<chiluk> yep..
<xnox> and by default it will require TLSv1.2, DTLSv1.2, 2k RSA keys, SHA256 signatures on certificates, etc.....
<xnox> thus one has to ensure TLSv1.2 is up and running on those 16.04 software, cause anything lower than that is useless on the public internet today.
<infinity> bdmurray: These walinuxagent backports don't have the dh-python build-dep fix.  Did you want to re-backport with that?
<infinity> bdmurray: Oh, but python3-all depends on it in earlier releases, so it's probably fine.
<infinity> bdmurray: Oh, and one that needs to be fixed...
<infinity> bdmurray: python3-distro was addeed to build-deps in focal "for python3.8 support".  There's probably no harm in that being backported to eoan.  And you correctly removed it for xenial.  But you left it for bionic, where it will generate a runtime dep on python3-distro, which is in universe there.
<infinity> bdmurray: So bionic needs re-uploading with the same revert as xenial.
<xnox> vorlon:  bump livecd-rootfs again? livecd-rootfs:i386:any in the log
<xnox> badtest livecd-rootfs on i386?
<vorlon> xnox: Laney already did
<xnox> awesome!
<vorlon> xnox: bumped it.  We haven't made it an all-version hint, that's a decision still to be taken
-queuebot:#ubuntu-release- Unapproved: rejected walinuxagent [source] (bionic-proposed) [2.2.45-0ubuntu1~18.04.1]
<infinity> bdmurray: If you want to retain the ability to do straight backports without deltas, you might want to change that to something tricksy like "python3 (<< 3.8.0) || python3-distro (>> 1.3.0)"
<infinity> bdmurray: Also, I'm reminded by my own fuzzy brain that you're off today, so I might JFDI and reupload myself.
<doko> s/||/|/
-queuebot:#ubuntu-release- New binary: rdkit [s390x] (focal-proposed/universe) [201909.1-2ubuntu1] (no packageset)
<infinity> doko: Yeah, brain's not in the right language yet. :)
<doko> I'm happy seeing you preparing the glibc update ;p
<ahasenack> wait, wat
<ahasenack> is there a glibc update coming up? :)
<infinity> 2.31 releases early feb, so yes.
<infinity> If only this happened every 6 months, so people would stop being surprised.
-queuebot:#ubuntu-release- New binary: rdkit [amd64] (focal-proposed/universe) [201909.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fonts-arundina [amd64] (focal-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rdkit [s390x] (focal-proposed) [201909.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rdkit [amd64] (focal-proposed) [201909.1-2ubuntu1]
<doko> ahasenack: sssd, and it even builds \o/
<ahasenack> doko: yeah, fixed it
<ahasenack> once it lands fully in proposed (missing arm* I think), I can rebuild autofs (which also broke)
<ahasenack> and that should be the last piece of the samba stack
<ahasenack> ok, autofs now builds as well
 * ahasenack lets the magic happen
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.14 => 1.173.15] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (eoan-proposed/main) [1.183.3 => 1.183.4] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: s390-tools (focal-proposed/main) [2.11.0-0ubuntu2 => 2.12.0-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: liblnk [amd64] (focal-proposed/none) [20181227-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblnk [s390x] (focal-proposed/none) [20181227-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblnk [arm64] (focal-proposed/none) [20181227-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblnk [armhf] (focal-proposed/none) [20181227-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblnk [ppc64el] (focal-proposed/none) [20181227-1.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted liblnk [amd64] (focal-proposed) [20181227-1.1]
-queuebot:#ubuntu-release- New: accepted liblnk [armhf] (focal-proposed) [20181227-1.1]
-queuebot:#ubuntu-release- New: accepted liblnk [s390x] (focal-proposed) [20181227-1.1]
-queuebot:#ubuntu-release- New: accepted liblnk [arm64] (focal-proposed) [20181227-1.1]
-queuebot:#ubuntu-release- New: accepted liblnk [ppc64el] (focal-proposed) [20181227-1.1]
#ubuntu-release 2020-01-30
-queuebot:#ubuntu-release- New binary: qclib [s390x] (focal-proposed/universe) [2.0.1-0ubuntu1] (no packageset)
<sarnold> hello; disco is still promoted in the header on http://releases.ubuntu.com/releases/ -- should it be removed? is there a better place to suggest its removal?
-queuebot:#ubuntu-release- Unapproved: walinuxagent (bionic-proposed/main) [2.2.40-0ubuntu1~18.04.1 => 2.2.45-0ubuntu1~18.04.1] (ubuntu-cloud)
<vorlon> infinity: ^^ what progress on the EOL checklist?
<vorlon> temporarily removing haskell-hledger and haskell-hledger-lib from -proposed, to allow a rebuild of old haskell-hledger against new libffi without blocking on haskell-hledger-lib/s390x
<infinity> sarnold, vorlon: I'll clean up cdimage/release first thing tomorrow, sorry, got sidetracked a bit.
<infinity> I guess I can remove it from the header now and clean up images when I'm more alive.
-queuebot:#ubuntu-release- New: accepted qclib [s390x] (focal-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-cachecontrol [amd64] (focal-proposed/universe) [0.11.7-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-cachecontrol [amd64] (focal-proposed) [0.11.7-2ubuntu1]
<sil2100> tseliot: hey! Looking at nvidia-graphics-drivers-390 right now - you missed a # in front of the bug number and now the .changes file has no bugs mentioned
<sil2100> tseliot: could you re-upload?
<tseliot> sil2100, oh, the one for eoan. Sure, please reject that and I'll re-upload
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-390 [source] (eoan-proposed) [390.132-0ubuntu0.19.10.1]
<sil2100> tseliot: done, thanks o/
<tseliot> sil2100, re-uploaded, thanks!
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (eoan-proposed/restricted) [390.129-0ubuntu2 => 390.132-0ubuntu0.19.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (eoan-proposed) [390.132-0ubuntu0.19.10.1]
<ddstreet> sil2100 hi, any chance you could review network-manager in e upload queue?
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (bionic-proposed/main) [1.3.4-0ubuntu2 => 1.3.4-0ubuntu2+ppa2.3] (core)
<juliank> sil2100: ^ if you have a second, could you reject that
<juliank> ?
-queuebot:#ubuntu-release- Unapproved: rejected powerpc-utils [source] (bionic-proposed) [1.3.4-0ubuntu2+ppa2.3]
-queuebot:#ubuntu-release- New binary: securefs [ppc64el] (focal-proposed/none) [0.9.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: securefs [s390x] (focal-proposed/none) [0.9.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: securefs [amd64] (focal-proposed/none) [0.9.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: securefs [armhf] (focal-proposed/none) [0.9.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: securefs [arm64] (focal-proposed/none) [0.9.0+ds-1] (no packageset)
<RikMills> could an AA please action? LP: #1861390
<ubot5> Launchpad bug 1861390 in scribus-ng (Ubuntu) "Please remove scribus-ng from focal" [Undecided,New] https://launchpad.net/bugs/1861390
<RikMills> thanks
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.132-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-settings [source] (eoan-proposed) [440.44-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- New binary: setuptools-scm [amd64] (focal-proposed/universe) [3.4.3-1ubuntu1] (i386-whitelist)
<sil2100> tseliot: looking at nvidia-settings on bionic and I see that libxnvctrl0 dropped two symbols - just wanted to make sure this won't potentially break any existing users
-queuebot:#ubuntu-release- New: accepted securefs [amd64] (focal-proposed) [0.9.0+ds-1]
-queuebot:#ubuntu-release- New: accepted securefs [armhf] (focal-proposed) [0.9.0+ds-1]
-queuebot:#ubuntu-release- New: accepted securefs [s390x] (focal-proposed) [0.9.0+ds-1]
-queuebot:#ubuntu-release- New: accepted securefs [arm64] (focal-proposed) [0.9.0+ds-1]
-queuebot:#ubuntu-release- New: accepted setuptools-scm [amd64] (focal-proposed) [3.4.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted securefs [ppc64el] (focal-proposed) [0.9.0+ds-1]
<sil2100> ddstreet: hey! Will try!
<ddstreet> thanks!
<sil2100> ddstreet: hm, could you (just for tidiness) re-upload it with -v, so that the previous 2 ADT bugs are also mentioned in the .changes?
<sil2100> ddstreet: it's good as it is now as those are only ADT changes, but I guess it would be nice if we would auto-close them
<ddstreet> ah ok sure, sorry i didn't realize that was needed since the previous was in -proposed, i'll remember that next time
<sil2100> tjaalton: hey! Do you think you could get libclc and the new mesa validated for bionic today?
<ddstreet> sil2100 reuploaded n-m
-queuebot:#ubuntu-release- Unapproved: network-manager (eoan-proposed/main) [1.20.4-2ubuntu2.1 => 1.20.4-2ubuntu2.2] (desktop-core)
<sil2100> ddstreet: thanks! On it in a moment :)
-queuebot:#ubuntu-release- Unapproved: flash-kernel (bionic-proposed/main) [3.98ubuntu10~18.04.1 => 3.98ubuntu11~18.04.1] (core)
<sil2100> .4 is eating most of my time still, so much fiddling to do
<tjaalton> sil2100: I don't have a radeon to test the libclc regression with, but since eoan is fine..
<tjaalton> the guy who reported it on bionic upgraded to eoan already
<sil2100> Darn
<tjaalton> my thinking logic says that it can't be worse than what's in bionic now :)
<sil2100> Hard decision, normally I wouldn't do this but yeah, I might jus accept it basing on the fact that it works in eoan
<sil2100> Yeah
<sil2100> tjaalton: ok, thanks! And what about mesa? Since I guess it would be good to have the latest shiny in -updates for .4
<sil2100> I see someone verified it for eoan
<sil2100> But not for bionic yet
<sil2100> (verified as in used and was happy)
<tjaalton> sil2100: right, I'll test that on intel
<tjaalton> already running on eoan
-queuebot:#ubuntu-release- Unapproved: rejected network-manager [source] (eoan-proposed) [1.20.4-2ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (eoan-proposed) [1.20.4-2ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (bionic-proposed) [3.98ubuntu11~18.04.1]
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.7 => 10.1ubuntu2.8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.8]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-174.204] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-174.204]
<ginggs> vorlon: what's a bfsg? :p
<tumbleweed> ginggs: typo fixed
<ginggs> tumbleweed: thanks, but version needs to be 1.14.0+dfsg-2
<ginggs> tumbleweed: ta!
<tseliot> sil2100, I don't think the lack of NV_ID symbol should really break anything
<doko> mwhudson: https://qa.debian.org/developer.php?email=team%2Btryton-team%40tracker.debian.org   almost all of tryton is marked for autoremoval in debian, I think we should do the same for focal
<sil2100> tseliot: ok, I'll accept it, but let's keep an eye out for its rdeps - I'll list them in the bug
<tseliot> sil2100, sounds good to me, thanks
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-settings [source] (bionic-proposed) [440.44-0ubuntu0.18.04.1]
<tjaalton> sil2100: mesa verified on bionic
<ddstreet> sil2100 not sure if you're still around, but if so, any change you could review the systemd uploads for b/e?  vorlon took a look a week-ish ago and i re-uploaded based on his comments, but also included more bugfixes
<sil2100> ddstreet: I would love to, but not sure if I'll manage - I'm afraid this one might require a bit more time, while today and tomorrow I might still be busy with getting all the .4 things staged and set-up - it's all the time on my TODO list though!
<sil2100> Sorry about that o/
<sil2100> tjaalton: thanks!
<ddstreet> ack, no problem, thanks :)
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.45-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (bionic-proposed) [2.2.45-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (eoan-proposed) [2.2.45-0ubuntu1~19.10.1]
<vorlon> doko: you uploaded gobject-introspection, resetting the libffi transition progress?
<doko> vorlon: yes, because pygobject was auto-synced
<vorlon> k
<Laney> why was it auto-synced when it had a delta?
<vorlon> pygobject didn't have a delta
<Laney> oh sorry I misread
<Laney> the new g-i seems bad though
<Laney> ubuntu@autopkgtest:~$ g-ir-scanner
<Laney> Traceback (most recent call last):
<Laney> only built for 3.8 I guess
<doko> Laney: looks like the package is missing a b-d on dh-python?
<doko> ahh, no, it has dh-sequence-python3
<doko> but the generated dependency python3:any seems to be wrong, when you have the extension only for 3.8
<sarnold> infinity: thanks :) (re removing disco from header)
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (focal-proposed) [2.12.0-0ubuntu1]
<vorlon> libglib-object-introspection-perl autosync because of course it is
<vorlon> I'm going to shut off autosyncs until I have a chance to get libffi through
<vorlon> (which would've been done within an hour of my start of day, if not for these newer syncs)
<doko> please communicate that on the ML
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [19.1-7-g37a7a0f4-0ubuntu1~16.04.1 => 19.3-17-g50ffca46-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [19.1-7-g37a7a0f4-0ubuntu1~18.04.1 => 19.3-17-g50ffca46-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (eoan-proposed/main) [19.2-9-g38ce22b0-0ubuntu1 => 19.3-17-g50ffca46-0ubuntu1~19.10.1] (ubuntu-desktop, ubuntu-server)
<blackboxsw> wwot!
#ubuntu-release 2020-01-31
<xnox> vorlon:  i think if in the output of r$ everse-depends libebook-contacts-1.2-3
<xnox> all packages are excluded on i386
<xnox> then boost can be removed from i386, unless i got my analysis wrong
<xnox> i.e. not build the libphonenumber sutff / ebook-contacts
<xnox> $ reverse-depends libebook-contacts-1.2-3
<xnox> also note https://launchpad.net/ubuntu/+source/libsdl2/2.0.10+dfsg1-1ubuntu8
<xnox> hm i see a few build-deps for header only libs however
<xnox> so maybe not
<xnox> seeding boost1.71 into i386
<vorlon> xnox: i386+build-depends lists firebird3.0, mir, libftdi1 as reverse-build-deps of libboost-*dev; I don't even see that libebook-contacts is implicated
-queuebot:#ubuntu-release- Packageset: Added munkres to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added pep8 to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added python-cffi to i386-whitelist in focal
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.12-0ubuntu0.18.04.4 => 12.2.12-0ubuntu0.18.04.5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1030.31] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1030.31]
<xnox> vorlon: ok. How does one add boost1.71 to the i386 whitelist? Without it there, I can't really start boost transition.
<apw> xnox, i think i can add it ...
<apw> xnox, added as far as i can tell
-queuebot:#ubuntu-release- Packageset: Added boost1.71 to i386-whitelist in focal
<juliank> where do the britney hints go again?
 * juliank lost his checkout
<ginggs> juliank: https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu ?
<juliank> thanks ginggs
<juliank> hmm I do have hints-ubuntu locally, odd
<juliank> how'd I not find it?
<ddstreet> tjaalton if you're doing sru review today, are you able to review systemd uploads for b/e?
<juliank> don't push branches on WIFIonICE
<juliank> please merge: https://code.launchpad.net/~juliank/britney/hints-ubuntu/+merge/378392
<juliank> this will unblock aptdaemon
<juliank> I need to figure out why update-manager is broken, but after that is done as well, python-apt should be ubnlocked too
<juliank> Python 3.8 removed platform.dist() function
<juliank> nice
<juliank> I'll just retry without python-defaults change for python-apt
<cjwatson> The distro module is often a good replacement
<juliank> probably
<juliank> So it's the codename it's looking at I guess
<juliank> cjwatson: heh, update-manager has its own utils.get_dist() even
<juliank> this silly thing was using two different ways to get to the codename
<tjaalton> ddstreet: wondering if I should be making the final judgement call on that one
<ddstreet> up to you i guess
<juliank> baasically pushing code over Edge
<juliank> it's so slow
<tjaalton> vorlon: since you had some concerns about the systemd sru, could you have a look if you have time?
<juliank> #DeutscheBahn #WIFIonICE
<juliank> Well at least the upload made it to the server
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (eoan-proposed) [1.183.4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.15]
-queuebot:#ubuntu-release- New binary: linux-signed-5.4 [amd64] (focal-proposed/main) [5.4.0-13.16] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-5.4 [s390x] (focal-proposed/main) [5.4.0-13.16] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-5.4 [ppc64el] (focal-proposed/main) [5.4.0-13.16] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-5.4 [arm64] (focal-proposed/main) [5.4.0-13.16] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [amd64] (focal-proposed) [5.4.0-13.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [ppc64el] (focal-proposed) [5.4.0-13.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [arm64] (focal-proposed) [5.4.0-13.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [s390x] (focal-proposed) [5.4.0-13.16]
-queuebot:#ubuntu-release- New sync: waybar (focal-proposed/primary) [0.9.0-1]
<vorlon> apw: when adding stuff to i386-whitelist, please do so via the update-i386-whitelist script in lp:ubuntu-archive-tools so that future refreshes don't clobber
<vorlon> tjaalton: sorry, I'm off today
<LocutusOfBorg> <LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946261
<LocutusOfBorg> <ubot5> Debian bug 946261 in ftp.debian.org "RM: sfcgal [armhf] -- ROM; Architecture specific issue" [Normal,Open]
<ubot5> Debian bug 946261 in ftp.debian.org "RM: sfcgal [armhf] -- ROM; Architecture specific issue" [Normal,Open]
<LocutusOfBorg> <LocutusOfBorg> please somebody remove sfcgal on armhf
<LocutusOfBorg> <LocutusOfBorg> missing build on armhf: libsfcgal-dev, libsfcgal1 (from 1.3.7-2ubuntu1)
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.39 => 2.525.40] (desktop-core)
<sil2100> bdmurray: livecd-rootfs in the queue! ^
<sil2100> With some juicy .4 stuff
<apw> vorlon, ooops, ack
<bdmurray> sil2100: don't you want all the bugs in Launchpad-Bugs-Fixed?
<sil2100> bdmurray: what bugs? I released the previous livecd-rootfs
<sil2100> I guess it's just a leftover in -proposed
<bdmurray> sil2100: ah, okay that's why sru-review complained
<sil2100> Yeah, I guess I forgot to clear out all the proposed leftovers yesterday
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.40]
<vorlon> autosyncs reenabled
-queuebot:#ubuntu-release- Packageset: Removed capnproto from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed egl-wayland from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed eglexternalplatform from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed gflags from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed glm from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed google-glog from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libimagequant from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed mir from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed olefile from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed pep8 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed pillow from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed python-cffi from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed python-dbusmock from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed raqm from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed ust from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed wlcs from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed yaml-cpp from i386-whitelist in focal
<vorlon> doko: lexicon had python3-certbot-foo as revdeps
-queuebot:#ubuntu-release- New binary: libm4rie [amd64] (focal-proposed/universe) [20200125-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cl-ppcre [amd64] (focal-proposed/universe) [20190407.git1ca0cd9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gparted [amd64] (focal-proposed/main) [1.0.0-0.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: bigint [amd64] (focal-proposed/none) [2010.04.30-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [amd64] (focal-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-parsexp [amd64] (focal-proposed/none) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: remaster-iso [amd64] (focal-proposed/none) [0.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: doxypypy [amd64] (focal-proposed/none) [0.8.8.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sentineldl [amd64] (focal-proposed/none) [20200127-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zookeeper [amd64] (focal-proposed/universe) [3.4.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libm4rie [s390x] (focal-proposed/universe) [20200125-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [amd64] (focal-proposed/universe) [20.01.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libm4rie [arm64] (focal-proposed/universe) [20200125-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [s390x] (focal-proposed/universe) [20.01.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libm4rie [armhf] (focal-proposed/universe) [20200125-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted doxypypy [amd64] (focal-proposed) [0.8.8.6-1]
-queuebot:#ubuntu-release- New: accepted libm4rie [armhf] (focal-proposed) [20200125-1]
-queuebot:#ubuntu-release- New: accepted limesuite [amd64] (focal-proposed) [20.01.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-parsexp [amd64] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted sentineldl [amd64] (focal-proposed) [20200127-1]
-queuebot:#ubuntu-release- New: accepted libm4rie [arm64] (focal-proposed) [20200125-1]
-queuebot:#ubuntu-release- New: accepted limesuite [s390x] (focal-proposed) [20.01.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted zookeeper [amd64] (focal-proposed) [3.4.13-4]
-queuebot:#ubuntu-release- New: accepted libm4rie [s390x] (focal-proposed) [20200125-1]
-queuebot:#ubuntu-release- New: accepted remaster-iso [amd64] (focal-proposed) [0.9.2-1]
-queuebot:#ubuntu-release- New: accepted bigint [amd64] (focal-proposed) [2010.04.30-2]
-queuebot:#ubuntu-release- New: accepted gparted [amd64] (focal-proposed) [1.0.0-0.1]
-queuebot:#ubuntu-release- New: accepted wlroots [amd64] (focal-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted cl-ppcre [amd64] (focal-proposed) [20190407.git1ca0cd9-1]
-queuebot:#ubuntu-release- New: accepted libm4rie [amd64] (focal-proposed) [20200125-1]
-queuebot:#ubuntu-release- New binary: limesuite [armhf] (focal-proposed/universe) [20.01.0+dfsg-1] (no packageset)
#ubuntu-release 2020-02-01
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-1 => 1.3.7-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-1 => 1.3.7-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-1 => 1.3.7-1] (core)
-queuebot:#ubuntu-release- New binary: libreoffice [s390x] (focal-proposed/main) [1:6.4.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [ppc64el] (focal-proposed/main) [1:6.4.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted libreoffice [ppc64el] (focal-proposed) [1:6.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted limesuite [armhf] (focal-proposed) [20.01.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libreoffice [s390x] (focal-proposed) [1:6.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted waybar [sync] (focal-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: waybar [s390x] (focal-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: waybar [ppc64el] (focal-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: waybar [amd64] (focal-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: waybar [armhf] (focal-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: waybar [arm64] (focal-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted waybar [amd64] (focal-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted waybar [armhf] (focal-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted waybar [s390x] (focal-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted waybar [arm64] (focal-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted waybar [ppc64el] (focal-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: puppet-module-voxpupuli-alternatives [amd64] (focal-proposed/none) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nifti2dicom [amd64] (focal-proposed/none) [0.4.11-1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- New: accepted nifti2dicom [amd64] (focal-proposed) [0.4.11-1.1]
-queuebot:#ubuntu-release- New: accepted puppet-module-voxpupuli-alternatives [amd64] (focal-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (focal-proposed/main) [1:6.4.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: pcl [s390x] (focal-proposed/universe) [1.10.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pcl [ppc64el] (focal-proposed/universe) [1.10.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pcl [amd64] (focal-proposed/universe) [1.10.0+dfsg-4] (no packageset)
<xnox> apw: thank you!
-queuebot:#ubuntu-release- New binary: libvirt [s390x] (focal-proposed/main) [6.0.0-0ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: libvirt [amd64] (focal-proposed/main) [6.0.0-0ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: libvirt [ppc64el] (focal-proposed/main) [6.0.0-0ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: libvirt [arm64] (focal-proposed/main) [6.0.0-0ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: libvirt [armhf] (focal-proposed/main) [6.0.0-0ubuntu1] (ubuntu-server, virt)
<xnox> ooooh, shiny libvirt
<cpaelzer> xnox: no swtpm yet :-/
<cpaelzer> I want to get the new version first without too many bonus things (already enough)
<cpaelzer> xnox: but testing was long enough and is good now
<xnox> cpaelzer: i know, but at least this one has the right apparmor stuff. Such that i don't need to hack off apparmor locally with locally packaged/built swtpm.
<cpaelzer> qemu is coming as well
<xnox> nice
<cpaelzer> yeah that is true
<cpaelzer> anyway it will hit new queue and component mismatches
<cpaelzer> slowest possible migration :-)
<xnox> that's what you get for releasing on weekend ;-)
-queuebot:#ubuntu-release- New binary: qemu [amd64] (focal-proposed/main) [1:4.2-1ubuntu1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: pcl [arm64] (focal-proposed/universe) [1.10.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (focal-proposed) [1:6.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: retry [amd64] (focal-proposed/none) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: retry [s390x] (focal-proposed/none) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: retry [ppc64el] (focal-proposed/none) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: retry [arm64] (focal-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: retry [armhf] (focal-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opencv [s390x] (focal-proposed/universe) [4.2.0+dfsg-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: pcl [armhf] (focal-proposed/universe) [1.10.0+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: opencv [ppc64el] (focal-proposed/universe) [4.2.0+dfsg-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: opencv [amd64] (focal-proposed/universe) [4.2.0+dfsg-3] (kubuntu)
<xnox> apw:  vorlon: nice, used copy-package to create i386 build record
-queuebot:#ubuntu-release- New binary: opencv [armhf] (focal-proposed/universe) [4.2.0+dfsg-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: opencv [arm64] (focal-proposed/universe) [4.2.0+dfsg-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: coq-float [amd64] (focal-proposed/universe) [1:8.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted coq-float [amd64] (focal-proposed) [1:8.9.0-1]
-queuebot:#ubuntu-release- New: accepted libvirt [amd64] (focal-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [armhf] (focal-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [s390x] (focal-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [arm64] (focal-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qemu [amd64] (focal-proposed) [1:4.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvirt [ppc64el] (focal-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pcl [amd64] (focal-proposed) [1.10.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted pcl [armhf] (focal-proposed) [1.10.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted pcl [s390x] (focal-proposed) [1.10.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted pcl [arm64] (focal-proposed) [1.10.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted pcl [ppc64el] (focal-proposed) [1.10.0+dfsg-4]
-queuebot:#ubuntu-release- New: accepted opencv [amd64] (focal-proposed) [4.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted opencv [armhf] (focal-proposed) [4.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted opencv [s390x] (focal-proposed) [4.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted retry [arm64] (focal-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted retry [ppc64el] (focal-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted opencv [arm64] (focal-proposed) [4.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted retry [amd64] (focal-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted retry [s390x] (focal-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted opencv [ppc64el] (focal-proposed) [4.2.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted retry [armhf] (focal-proposed) [1.0.3-1]
<vorlon> xnox: mm? I'm sure copy-package wasn't creating build records when I used it
<xnox> vorlon: well, boost1.71 has i386 build record after I copied it from focal-proposed to focal-proposed with binaries and skipping the check of same orig/destination.
<xnox> boost1.71 failed autopkgtest twice on amd64 due to clock skew with makefiles / source files modified in the future confusing make
<xnox> did something change in the cloud / instances to like not store precise timestamps on the filesystem? or like the cloud clocks are not synced? cpu overcommit?
<xnox> make[2]: Warning: File 'CMakeFiles/demo2.dir/flags.make' has modification time 0.019 s in the future
<xnox> Scanning dependencies of target demo2
<xnox> make[2]: warning:  Clock skew detected.  Your build may be incomplete.
<xnox> make[2]: Warning: File 'CMakeFiles/demo2.dir/flags.make' has modification time 0.009 s in the future
<xnox> [ 75%] Building CXX object CMakeFiles/demo2.dir/demo2.cpp.o
<xnox> [100%] Linking CXX executable demo2
<xnox> make[2]: warning:  Clock skew detected.  Your build may be incomplete.
#ubuntu-release 2020-02-02
<LocutusOfBorg> hello vorlon, rationale for pcl upload? the sync was building fine everywhere...
<LocutusOfBorg> I'm uploading a new version
<vorlon> LocutusOfBorg: I'm going through TIL merges and didn't see that the delta could be dropped
<vorlon> I'm happy to no longer be TIL on it ;)
-queuebot:#ubuntu-release- New binary: glktermw [amd64] (focal-proposed/none) [1.0.4+git20200122-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mtbl [amd64] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glktermw [s390x] (focal-proposed/none) [1.0.4+git20200122-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mtbl [s390x] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glktermw [armhf] (focal-proposed/none) [1.0.4+git20200122-2] (no packageset)
-queuebot:#ubuntu-release- New binary: glktermw [arm64] (focal-proposed/none) [1.0.4+git20200122-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mtbl [ppc64el] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mtbl [arm64] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mtbl [armhf] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glktermw [ppc64el] (focal-proposed/universe) [1.0.4+git20200122-2] (no packageset)
<LocutusOfBorg> hello seriously, perl transition finished months ago... isn't it time for chroot upgrades? :)
-queuebot:#ubuntu-release- New: accepted glktermw [amd64] (focal-proposed) [1.0.4+git20200122-2]
-queuebot:#ubuntu-release- New: accepted glktermw [armhf] (focal-proposed) [1.0.4+git20200122-2]
-queuebot:#ubuntu-release- New: accepted glktermw [s390x] (focal-proposed) [1.0.4+git20200122-2]
-queuebot:#ubuntu-release- New: accepted mtbl [arm64] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted mtbl [ppc64el] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted glktermw [arm64] (focal-proposed) [1.0.4+git20200122-2]
-queuebot:#ubuntu-release- New: accepted mtbl [amd64] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted mtbl [s390x] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted glktermw [ppc64el] (focal-proposed) [1.0.4+git20200122-2]
-queuebot:#ubuntu-release- New: accepted mtbl [armhf] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New binary: glulxe [amd64] (focal-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glulxe [armhf] (focal-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glulxe [s390x] (focal-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glulxe [arm64] (focal-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glulxe [ppc64el] (focal-proposed/universe) [0.5.4-1] (no packageset)
<LocutusOfBorg> <LocutusOfBorg> <LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946261
<LocutusOfBorg> <LocutusOfBorg> <ubot5> Debian bug 946261 in ftp.debian.org "RM: sfcgal [armhf] -- ROM; Architecture specific issue" [Normal,Open]
<LocutusOfBorg> <ubot5> Debian bug 946261 in ftp.debian.org "RM: sfcgal [armhf] -- ROM; Architecture specific issue" [Normal,Open]
<LocutusOfBorg> <LocutusOfBorg> <LocutusOfBorg> please somebody remove sfcgal on armhf
<ubot5> Debian bug 946261 in ftp.debian.org "RM: sfcgal [armhf] -- ROM; Architecture specific issue" [Normal,Open]
<LocutusOfBorg> <LocutusOfBorg> <LocutusOfBorg> missing build on armhf: libsfcgal-dev, libsfcgal1 (from 1.3.7-2ubuntu1)
<LocutusOfBorg> <LocutusOfBorg> ta
<LocutusOfBorg> please please please ^^
<LocutusOfBorg> I patched postgis to not fail anymore sfcgal tests on armhf
<LocutusOfBorg> gdal is mostly ready now, if you remove sfcgal!
<LocutusOfBorg> vorlon, ^^ pleeeeeeeeease?
-queuebot:#ubuntu-release- New: accepted glulxe [amd64] (focal-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted glulxe [armhf] (focal-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted glulxe [s390x] (focal-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted glulxe [arm64] (focal-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted glulxe [ppc64el] (focal-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New binary: gcc-10 [s390x] (focal-proposed/main) [10-20200202-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-10 [ppc64el] (focal-proposed/main) [10-20200202-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-10 [i386] (focal-proposed/main) [10-20200202-1ubuntu1] (i386-whitelist)
<cpaelzer> ahasenack: fro pmdk / ndctl we need some Extra-excludes in the seeds
<cpaelzer> ude to auto-promoting -dev and -doc and maybe even -debug it pulls in way too much atm
<cpaelzer> Rescued from pmdk (Uploader: ahasenack), libpmemblk-dev, libpmemblk1-debug, libpmemlog-dev, libpmemobj-dev, libpmempool-dev, librpmem-dev, libvmem-dev, libvmmalloc-dev
-queuebot:#ubuntu-release- New binary: gcc-10 [amd64] (focal-proposed/main) [10-20200202-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-10 [arm64] (focal-proposed/main) [10-20200202-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-10 [armhf] (focal-proposed/main) [10-20200202-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted gcc-10 [amd64] (focal-proposed) [10-20200202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10 [armhf] (focal-proposed) [10-20200202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10 [ppc64el] (focal-proposed) [10-20200202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10 [arm64] (focal-proposed) [10-20200202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10 [s390x] (focal-proposed) [10-20200202-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10 [i386] (focal-proposed) [10-20200202-1ubuntu1]
<RikMills> vorlon: could you please action this? LP: #1861616
<ubot5> Launchpad bug 1861616 in pcsx2 (Ubuntu) "Please remove from focal archive" [Undecided,New] https://launchpad.net/bugs/1861616
<vorlon> RikMills: the Debian bug points to a simple build-dep change to fix this package; and as an i386-only package, deleting it now will make it annoying to re-add if it's fixed upstream.  Did you try the proposed one-liner fix?
<RikMills> vorlon: yes, I tried switching the build deps. just tried a tweak to that, and still fails. I note that the upstream daily build ppa still uses gtk2 wxWidgets, and that is a source 15 months on from the snapshot source we have
-queuebot:#ubuntu-release- New binary: libm4ri [amd64] (focal-proposed/universe) [20200115-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libm4ri [armhf] (focal-proposed/universe) [20200115-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libm4ri [ppc64el] (focal-proposed/universe) [20200115-1] (no packageset)
-queuebot:#ubuntu-release- New binary: syrthes [amd64] (focal-proposed/universe) [4.3.0-dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: syrthes [ppc64el] (focal-proposed/universe) [4.3.0-dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: syrthes [armhf] (focal-proposed/universe) [4.3.0-dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.4 [ppc64el] (focal-proposed/universe) [7.4.1-1] (no packageset)
