[05:09] <nickSwe> Is it possible in some way to have the top unity panel 100% transparent? I have tried all (compiz, unity tweak tool etc).. All is set to 0 opacity but it is still slightly shaded. I think it is a bug in unity. But is there a workaround? For example a png file somewhere that I can modify to 100% transparency?
[05:09] <nickSwe> This is Ubuntu 14.10
[06:29] <pitti> Good morning
[06:29] <pitti> flexiondotorg: you're welcome!
[06:33] <Unit193> Howdy.
[06:37] <pitti> meh, syntax error in /usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeViewKDE.py breaks the world
[06:39] <pitti> ah, that was from https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:15.04.6 which has been removed since
[06:39]  * pitti restarts a gazillion tests then
[06:39] <Unit193> Heh, I have a merge for that package pending.
[06:39] <kenvandine> pitti, thanks!
[06:39] <kenvandine> i was just looking at the excuses page :)
[06:40] <pitti> kenvandine: yeah, my ubuntu mailbox greeted me this morning with tons of jenkins failures
[06:40] <kenvandine> good morning seb128!
[06:40] <seb128> kenvandine, hey! you gave up on sleeping? ;-)
[06:40] <kenvandine> seb128's up... i should really go to bed
[06:40] <kenvandine> :-p
[06:40] <seb128> hehe
[06:41]  * kenvandine goes to get some sleep
[06:41] <pitti> bonjour seb128
[06:41] <pitti> seb128: you're up early, too!
[06:41] <seb128> pitti, salut, same as every day (maybe started IRC some 15 minutes earlier)
[07:08] <dholbach> good morning
[07:16] <dholbach> @pilot in
[08:36] <dholbach> bdmurray, can you take a look at https://code.launchpad.net/~unit193/ubuntu-release-upgrader/core-upgrades/+merge/250224?
[08:38] <dholbach> slangasek, do you know who could take a look at https://code.launchpad.net/~tj/grub-installer/lp1354730/+merge/250100?
[08:53] <dholbach> smoser, can you take a look at https://code.launchpad.net/~niedbalski/ubuntu/vivid/curtin/fix-1263181/+merge/250163 please?
[09:13] <dholbach> seb128, can somebody take a look at https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1340067?
[09:14] <seb128> dholbach, don't ask me? no idea about vte or g-t, maybe larsu or Laney know
[09:14] <dholbach> seb128, sorry, I thought you could ping somebody on the desktop team to look at it
[09:15] <darkxst> dholbach, it should already be dropped
[09:15] <seb128> dholbach, you can just join #ubuntu-desktop and ask there :-)
[09:15] <dholbach> darkxst, can the bug be closed then?
[09:15] <seb128> dholbach, that's a good way to ping the desktop team on IRC ;-)
[09:15] <dholbach> seb128, I'm looking at lots of open sponsorship bugs right now :-(
[09:15] <Laney> it's asking for a SRU
[09:15] <darkxst> dholbach, no, I don't thinks its been dropped though you are correct it does nothing
[09:15] <Laney> I don't think there's much point bothering
[09:15] <Laney> pretty sure it is gone
[09:15] <seb128> dholbach, yeah, just saying that pinging channels works better than asking individuals
[09:21] <dholbach> Laney, darkxst: so what do you want me to do now? close the bug and say we won't SRU?
[09:22] <Laney> dholbach: There's some UI which doesn't work due to it, so it might be worth uploading on that basis
[09:22] <Laney> should be "Fix Released" for vivid and confirmed for trusty & utopic afaics
[09:56] <dholbach> GunnarHj, happyaron: do you know if anyone is looking into getting 1377370 merged?
[09:57] <Mirv> would an archive admin ack compiz that has a new compiz-mate binary package? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021 + https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diff - I also asked on Tue + Wed, but today would be FF so it'd be useful to get it in
[10:05] <dholbach> LocutusOfBorg1, I'll fake a new changelog entry for bug 1416651
[10:05] <LocutusOfBorg1> oops dholbach hold on
[10:05] <LocutusOfBorg1> debian has the -3 upload now
[10:06] <LocutusOfBorg1> let me update it
[10:06] <dholbach> yes, I know
[10:06] <Laney> Mirv: why don't you upload it and get them to ack in the queue as would be normal?
[10:06] <dholbach> LocutusOfBorg1, I did it already
[10:06] <LocutusOfBorg1> you rock man! ;)
[10:06] <Laney> (or don't you have upload rights to compiz?)
[10:06] <Mirv> Laney: because CI Train goes past it ...
[10:06] <Laney> huh
[10:07] <Laney> I remember that it used to, but copies certainly work for UNAPPROVED - why not NEW?
[10:08] <Mirv> sil2100: can you confirm what's the current behavior ^ I'm working on the assumption that the text at the top of the diff is still right
[10:08] <dholbach> LocutusOfBorg1, is http://paste.ubuntu.com/10305574/ what you would have done?
[10:08] <dholbach> LocutusOfBorg1, what about debian/patches/0006_add_unity_quicklist_support.patch?
[10:10] <sil2100> Mirv: from what I remember binary packages get pass NEW and go straight to -proposed
[10:10] <sil2100> Mirv: new source packages only get stuck in NEW
[10:10] <dholbach> Laney, could it be that debian/patches/0006_add_unity_quicklist_support.patch was just mentioned in inkscape (0.48.5-3ubuntu1) but never added?
[10:11] <Laney> anything could be
[10:11] <LocutusOfBorg1> dholbach, they seem already applied to the source
[10:11] <LocutusOfBorg1> https://sources.debian.net/src/inkscape/0.91-3/inkscape.desktop.in/
[10:11] <Laney> dholbach: am I to blame? :P
[10:11] <dholbach> Laney, you uploaded that version, but the patch file is not in the source package :)
[10:11] <Mirv> Laney: ^ what sil2100 said, so we need that preNEW acceptance from archive admin instead.
[10:11] <LocutusOfBorg1> dholbach, not a problem, the patch is not needed anymore
[10:11] <LocutusOfBorg1> :)
[10:12] <dholbach> LocutusOfBorg1, ok
[10:12] <highvoltage> .wub 47
[10:12] <Laney> dubstep wub wub wub
[10:12] <LocutusOfBorg1> if you look the source it is already included
[10:12] <dholbach> LocutusOfBorg1, I was just confused and thought, if we drop a patch we should probably mention it
[10:12] <highvoltage> (oh dear)
[10:12] <LocutusOfBorg1> dholbach, if we didn't apply it how can we mention the drop? :D (just joking)
[10:13] <dholbach> LocutusOfBorg1, move along, nothing to see here
[10:13] <dholbach> ok, nevermind then :)
[10:13] <dholbach> I'll do a test-build and upload it later on
[10:13] <dholbach> thanks Laney, thanks LocutusOfBorg1
[10:14] <LocutusOfBorg1> :) you are welcome
[10:14] <LocutusOfBorg1> I already did the test rebuilds on my ppa IIRC
[10:14] <LocutusOfBorg1> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
[10:14] <LocutusOfBorg1> just armhf has failed I guess because of a qemu stack problem (as usual)
[10:15] <Laney> wait what
[10:17] <Laney> dholbach: LocutusOfBorg1: laney@iota> GET https://launchpad.net/ubuntu/+archive/primary/+files/inkscape_0.48.5-3ubuntu2.debian.tar.xz | tar tJ --wildcards debian/patches/0006_add\*
[10:17] <Laney> debian/patches/0006_add_unity_quicklist_support.patch
[10:17] <Laney> ?
[10:18] <dholbach> sorry, I found the mistake
[10:18] <dholbach> I had the unstable version unpacked locally
[10:18] <dholbach> LocutusOfBorg1, ^ I'll add something to the changelog entry explaining the patch is upstream now
[10:19] <Riddell> bdmurray: thanks for fixing ubuntu-release-upgrader, I'll do another upload now
[10:22] <Riddell> pitti: ubuntu-release-upgrader_15.04.7 up ↑
[10:25] <seb128> dpm, pitti, wgrant, how often are we supposed to have vivid langpack updates?
[10:27] <dpm> seb128, exports are set up weekly (although it seems 2 weeks ago it wasn't generated) -> https://translations.launchpad.net/ubuntu/vivid/+language-packs I think pitti has langpack-o-matic for vivid to follow that
[10:27] <pitti> seb128: the cronjob is running every Tuesday
[10:27] <wgrant> Yeah, they're triggered weekly.
[10:28] <wgrant> But the Launchpad side of it is very fragile. Should be a bit happier now that we have SSDs, though.
[10:28] <pitti> https://launchpad.net/ubuntu/+source/language-pack-de/+publishinghistory
[10:28] <seb128> why is the current one from 0202 then?
[10:28] <pitti> indeed that's usually weekly, but we missed the two recent ones
[10:28] <pitti> https://translations.launchpad.net/ubuntu/vivid/+language-packs
[10:28] <pitti> so ther was no export on Feb 09
[10:29] <dpm> yeah, but there was one on the 16th
[10:29] <LocutusOfBorg1> thanks dholbach :)
[10:29] <pitti> seb128: ah, and Tuesday I indeed got a cron failure from langpacks as it tripped over a still running utopic import
[10:29] <pitti> so, two rare conditions hit within a week
[10:29]  * pitti restarts the one from this week
[10:30] <seb128> pitti, danke
[10:30] <pitti> apw, ogasawara: nice to see the kernel autopkgtests landing now! note that there's one failure, see https://jenkins.qa.ubuntu.com/job/vivid-adt-linux/
[10:31] <pitti> https://jenkins.qa.ubuntu.com/job/vivid-adt-linux/60/ARCH=i386,label=adt/artifact/results/ubuntu-regression-suite-stdout is probably the smallest/most useful log to look at
[10:31] <pitti> (the complete log is 4.5 MB due to also having the package build output)
[10:32] <apw> 09:58:33 INFO | END GOOD--------timestamp=1424339913localtime=Feb 19 09:58:33
[10:32] <apw> pitti, doesn't that say "i worked just fine?"
[10:33] <pitti> apw: the last test succeeds, yes; but scroll up :)
[10:33] <pitti> 09:29:26 INFO |         END ERROR       ubuntu_seccomp.seccomp  ubuntu_seccomp.seccomp  timestamp=1424338166    localtime=Feb 19 0
[10:33] <apw> oh i see that is just bile as normal ... can you say "i hate test suites which have GOOD at the bottom of logs"
[10:33] <pitti> 9:29:26
[10:33] <apw> pitti, yeah that is UTTERLY USELESS :)
[10:34] <pitti> grep FAIL /tmp/ubuntu-regression-suite-stdout
[10:34] <pitti> that's more useful
[10:34] <pitti> apw: let's just say this is a test that britney actually holds back a kernel with regresssion :)
[10:34] <apw> pitti, yeah, the damn test suite should grep that out for sure into a summary log ... sigh
[10:34] <apw> pitti, but yes indeed
[10:35]  * pitti wants to look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux but people.c.c seems down?
[10:35] <apw> pitti, scheduled maintenance apparently
[10:36] <apw> pitti, as so do i :)  so i can see what it looks like, to detect and report it
[10:37] <apw> pitti, and rmadison is gone ... ugg, my world just become a spew of urllib.urlopen failures
[10:37] <pitti> apw: there's also the "Jenkins failed" mail that the uploader gets -- in this case, ogasawara
[10:37] <pitti> which gives you the notification and the public+private jenkins links
[10:38] <apw> pitti, yeah but frankly that is too specific a person as they might be sleeping etc
[10:38] <pitti> apw, ogasawara: so, if landing that kernel is urgent, it's ok to mark that as "skip bad test", as it's just a new test and not really a regression
[10:38] <pitti> apw: yes, we can surely fine-tune that
[10:38] <apw> pitti, there is a .yaml for this kind of thing, so i assume it is usable to find this issue
[10:39] <pitti> seb128: bah -- langpack build failed for the same reason as people.u.c. etc. being down
[10:39] <Laney> oh noes, can't syncpackage either
[10:39] <Laney> terrible!
[10:39] <seb128> pitti, k, I guess to retry later :-/
[10:40] <apw> pitti, i think we are about to replace this kernel with a 3.19 so there is no rush at all, and it being in this mess should be investigated, and it serves to allow tooling to detect it to be written
[10:40] <apw> ONCE people.c.c comes back of course
[10:42] <pitti> apw: the jenkins logs work, it's just the britney output that's currently AWOL
[10:42] <apw> pitti, yeah i am pretty sure i was looking yesterday and tehre is a nice parsable output we cna use to find the list of tests and see if any say Regression
[10:43] <apw> pitti, we should consider pumping those into #ubuntu-devel :)
[10:43] <pitti> uh, you don't want that :)
[10:43] <pitti> not with the gazillion failures that I get every day
[10:44] <apw> :) no i am sure i don't
[10:44] <pitti> last week it was the jenkins hiccup which broke hundreds of tests
[10:44] <pitti> last night the python-dist-upgrader one, etc. (although this one might have actually been useful)
[10:44] <Odd_Bloke> dholbach: I'd love it if you could have a look at https://bugs.launchpad.net/ubuntu/+source/irssi/+bug/1423499 :)
[10:45] <dholbach> Odd_Bloke, ok
[10:50] <dholbach> Odd_Bloke, responded
[10:56] <Odd_Bloke> dholbach: Thanks; taking a look.
[11:02] <Odd_Bloke> dholbach: Concern addressed; I've removed those files.
[11:02] <dholbach> ok cool
[11:06] <pitti> apw: people is back
[11:07] <apw> pitti, thanks
[11:18] <Laney> tyhicks: ooh, I see apparmor stuff is landing in dbus upstream now!
[11:39] <dholbach> @pilot out
[12:38] <xnox> pitti: address the ubuntu-drivers-common review -> will you merge and cut a release, or shall i cherry-pick into the ubuntu package?
[12:38] <xnox> https://github.com/tseliot/ubuntu-drivers-common/pull/11/files
[12:38] <xnox> well.
[12:38] <xnox> https://github.com/tseliot/ubuntu-drivers-common/pull/11
[13:43] <GunnarHj> dholbach, happyaron: As regards bug #1377370 we are simply waiting for a core dev to get it in, I suppose.
[13:46] <pitti> xnox: ack, thanks for fixing! I'll merge/upload
[13:46] <xnox> pitti: thanks.
[13:47] <xnox> seb128: yo, the unity-settings-daemon patch is not enough to get highdpi ubiquity.
[13:47] <xnox> seb128: however, booting unity7 desktop on vivid (livecd) does not do highdpi right either out of the box.
[13:47] <seb128> xnox, hey, hum, ok, does it make any visible difference?
[13:47] <xnox> seb128: upping the scale factor in the unity-control-settings-panel make things look right
[13:48] <dholbach> GunnarHj, ok
[13:48] <xnox> seb128: everything is same size.
[13:49] <seb128> xnox, can you gdb/printf debug the code added to unity-settings-daemon to set what dpi it gets and what factor it computes?
[13:52] <dholbach> GunnarHj, uploaded
[13:53] <pitti> xnox: done, thanks!
[13:53] <GunnarHj> dholbach: Tnx
[13:59] <xnox> seb128: well, not now/today. gave the hardware up. However, ubiquity does rescale itself correctly when the scaling-factor is bumped. So i'm happy with that.
[13:59] <seb128> xnox, yeah, and the u-s-d patch should set the factor, maybe it didn't think your screen was hi-dpi enough to do that though?
[13:59] <seb128> xnox, can you check next time you have access to the hwd?
[14:00] <xnox> yeah, i will.
[14:00] <seb128> thanks
[14:01] <xnox> seb128: you don't have hidpi hw do you?
[14:01] <xnox> bregma: help us =)
[14:03] <bregma> I can queue that up for later, what's the bug number?
[14:04] <xnox> bregma: vivid livecd looks crap with highdpi -> both ubiquity & live desktop sessions.
[14:04] <seb128> xnox, no, I don't
[14:04] <seb128> xnox, that statement is weird, live session runs unity and should have working hidpi
[14:04] <seb128> xnox, maybe your screen is not what we flag/consider as hidpi?
[14:05] <xnox> bregma: there is a patch to unity-settings-daemon from seb128 at https://code.launchpad.net/~seb128/unity-settings-daemon/non-unity-sessions-need-scaling/+merge/250153 which suppose to fix ubiquity
[14:05] <xnox> seb128: well it's a laptop, and it clearly is highdpi. i'll poke the values that are being checked.
[14:05] <xnox> bregma: a confirmation that unity live desktop in vivid looks good in highdpi would be a good start =)
[14:06] <cyphermox> good morning!
[14:06] <xnox> bregma: and whether the seb's patch above fixes it for ubiquity as well would be good. -> boot on kernel cmdline with "maybe-ubiquity debug-ubiquity" -> get into live session / tty install the updated packages, and on tty1 do $ service lightdm restart -> to get a new ubiquity session up, but running patched unity-settings-daemon.
[14:36] <Odd_Bloke> mvo: https://code.launchpad.net/~ubuntu-on-ec2/livecd-rootfs/cpc/+merge/250313 is the livecd-rootfs MP we discussed a little while ago.
[14:47] <flexiondotorg> cyphermox, Hi 😃
[14:47] <flexiondotorg> cyphermox, Are you up for some sponsoring?
[14:48] <cyphermox> sure
[14:48] <flexiondotorg> cyphermox, Thanks!
[14:48] <flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu/+bug/1423581
[14:57] <tyhicks> Laney: yes! it landed yesterday :)
[14:57] <tyhicks> Laney: I plan on backporting the patches that landed to our vivid package and uploading today
[15:01] <didrocks> cyphermox: hey, it seems that network-manager only enable now (with dhcp) to provide additional DNS, not replacing the primary one?
[15:01] <didrocks> "nmcli device show wlan0" shows that I have 2 DNS (the one configured by the dhcp provider and then mine)
[15:02] <cyphermox> didrocks: I don't quite follow? it should be working as it was before
[15:02] <cyphermox> ah
[15:02] <didrocks> cyphermox: see the nmcli comment, the string changed as well it's "additional DNS"
[15:02] <cyphermox> maybe?
[15:02] <cyphermox> I think it's already how it was
[15:02] <didrocks> cyphermox: hum, so you can't override the primary with nm?
[15:02] <cyphermox> but it's worth checking
[15:03] <Laney> tyhicks: are they planning a release?
[15:03] <cyphermox> didrocks: I don't know, don't think you could, but I'll ask on #nm
[15:03] <didrocks> cyphermox: thanks :)
[15:03] <cyphermox> didrocks: together with dnsmasq it shouldn't be that much of a problem?
[15:04] <didrocks> cyphermox: I guess I should configure dnsmasq, right
[15:04] <cyphermox> didrocks: you had deconfigured it?
[15:05] <cyphermox> if you tell me what precisely you're trying to achieve with the DNS servers I can offer some tricks maybe :)
[15:06] <didrocks> cyphermox: just want to replace the DNS servers from the ISP provider by other ones as primary (they have some technical issues right now and so, quite slow…)
[15:06] <cyphermox> ah, yeah
[15:07] <tyhicks> Laney: not quite sure - they did a 1.9.12 release, which includes AppArmor support, but we'd need to wait for 1.10 for it to have security support
[15:07] <cyphermox> dnsmasq is probably going to help you there.
[15:09] <cyphermox> flexiondotorg: any other ubuntu developer checked it out to review it?
[15:10] <flexiondotorg> cyphermox, Not Ubuntu. But it was checked by a Debian developer.
[15:10] <cyphermox> didrocks: would you happen to have time to review the package in bug 1423581?
[15:10] <cyphermox> I'm doing a review right now and will upload
[15:11] <mvo> Odd_Bloke: sure, I have a look
[15:11] <didrocks> cyphermox: can do the new review after yours, yeah
[15:11] <didrocks> cyphermox: just ping me
[15:11] <cyphermox> ah, so do you think I should just ignore the part about two ubuntu devs reviewing before upload?
[15:11] <cyphermox> I'm sponsoring, it's not my own package ;)
[15:11] <bdmurray> Riddell: thanks, there are some pep8 errors found when using bzr-buildpackage too.
[15:11] <Odd_Bloke> mvo: Thanks. :)
[15:12] <didrocks> cyphermox: well, it will go to the NEW queue, so that will be the second review and I can ack directly :)
[15:12] <cyphermox> fair enough :)
[15:13] <cyphermox> flexiondotorg: ah, mate-menu doesn't work yet with python3?
[15:14] <flexiondotorg> cyphermox, It does not. python2 only.
[15:14] <flexiondotorg> I will consider a python3 port in the next cycle.
[15:14] <cyphermox> ok
[15:14] <cyphermox> what provides git clone libmatedesktop and libmatepanelapplet?
[15:15] <flexiondotorg> cyphermox, ?
[15:15] <cyphermox> it's in the build-depends for mate-menu
[15:15] <flexiondotorg> libmatedesktop comes from mate-desktop, already in the 15.04 archive.
[15:15] <cyphermox> ah
[15:16] <flexiondotorg> libmatepanelapplet comes from mate-panel, already in the 15.04 archive.
[15:16] <cyphermox> hmm, weird, they weren't coming up
[15:17] <cyphermox> ah, the name may be wrong there
[15:20] <cyphermox> flexiondotorg: also, you're missing a debian/watch file so I can't download the source tarball
[15:23] <flexiondotorg> cyphermox, I'll fix the watch file shortly.
[15:36] <Trevinho> Mirv: hey, for some reason yesterday I missed your pings on pyotherside here... No notification at all... Btw... new pyotherside has been released http://thp.io/2011/pyotherside/
[15:36] <Trevinho> so, if we want to sync that from debian instead...
[15:38] <flexiondotorg> cyphermox, mate-menu has been updated.
[15:38] <cyphermox> flexiondotorg: ok
[15:39] <flexiondotorg> cyphermox, Also 😉
[15:39] <flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu/+bug/1423597
[15:39] <Mirv> Trevinho: yep, so to clear any confusion what I uploaded was the real git snapshot, not your branch, so it should be pretty up-to-date. I'm EOD, but if you can get someone to a) upload 1.4.0 to Debian, b) sync it from there to Ubuntu during the next 5 hours and 20 minutes, it's still possible to make the version number neater :)
[15:40] <Trevinho> Mirv: yes I saw you fixed my mistake (sorry)...
[15:40] <Trevinho> Mirv: so ubuntu version includes now latest git, a part from one missing commit fixing a crash... But well,  we can live without...
[15:40] <LocutusOfBorg1> dholbach, what about syncing tomcat8 from debian experimental?
[15:41] <Trevinho> Mirv: so, no worries... Enjoy your evening and thanks... Do you know anyone here that could do that?
[15:41] <LocutusOfBorg1> also tomcat7 would be nice to see updated :)
[15:41] <dholbach> LocutusOfBorg1, I have no idea about tomcat
[15:49] <cyphermox> flexiondotorg: can you please add (LP: #xxxx) to the changelog for mate-tweak to close the needs-packaging bug as the upload gets done?
[15:49] <flexiondotorg> cyphermox, Sure.
[15:55] <flexiondotorg> cyphermox, (LP: #xxxx) added to mate-menu and mate-tweak.
[15:55] <cyphermox> thanks. It's a little late for mate-menu though
[15:55] <cyphermox> I uploaded it without (oops)
[15:56] <cyphermox> we'll see if didrocks feels forgiving :)
[15:56] <flexiondotorg> cyphermox, I won't tell if you don't 😉
[15:57] <Mirv> Trevinho: it's not lowNMU so your best luck would be Zygmunt himself (the maintainer) or anyone on the Debian Python team
[15:57] <didrocks> it won't close them anyway
[15:57] <didrocks> as there is no mate-tweak or any other task
[15:57] <cyphermox> oh, true
[15:58] <cyphermox> well, I'll upload mate-tweak soonish
[15:58] <flexiondotorg> cyphermox, You're a star thanks.
[15:58] <cyphermox> ah crap, I forgot about what I told you of libmatedesktop too
[15:58] <cyphermox> I'm trying to do too many things at once without coffee
[15:59] <flexiondotorg> cyphermox, Get coffee 😃
[15:59] <flexiondotorg> cyphermox, I know this place by the central station ;)
[15:59] <cyphermox> my coffee is already brewed and has been waiting for me in the machine for the past >30 minutes
[16:01] <ScottK> tkamppeter: I have an HP Officejet 6700 that is giving me really weird print results (sometimes offset and generally rotated to varying degrees) to the point it's pretty useless.  This is with 12.04.  Is this something you've heard of?  Suggestions on how to troubleshoot?
[16:05] <bdmurray> dholbach: I will
[16:05] <dholbach> thanks bdmurray
[16:07] <didrocks> flexiondotorg: cyphermox: doesn't make sense for me to NEW it before libmatedesktop and such are sponsoring though, so waiting (but on urgent debugging right now)
[16:07] <cyphermox> didrocks: I was about to tell you to reject it, since that piece is wrong
[16:08] <cyphermox> AIUI it should be libmate-desktop-dev and libmate-panel-dev, the names as they are are most likely remnants of previous naming
[16:08] <cyphermox> er,, not -dev but ykwim
[16:08] <didrocks> cyphermox: ok, flushing
[16:08] <cyphermox> sorry
[16:09] <didrocks> no worry, it's a click away :)
[16:09] <didrocks> done
[16:10] <cyphermox> hmm.. the big deal is that libmatedesktop is a Provide from libmate-desktop-2-17 (and any other), coming from mate-desktop
[16:10] <cyphermox> didrocks: ^ as flexiondotorg pointed out earlier with fewer details
[16:11] <didrocks> oh ok, yeah, sounds like this shouldn't be a Provide but dep on the soname
[16:14] <dholbach> can somebody help fix bug 1368801?
[16:14] <Unit193> dholbach: Thanks for the upload!
[16:15] <dholbach> Unit193, anytime
[16:22] <slangasek> dholbach: https://code.launchpad.net/~tj/grub-installer/lp1354730/+merge/250100 -- cyphermox :)
[16:22] <cyphermox> yes, going to merge this
[16:22] <slangasek> pitti: why do you say that systemd is blocked on updating juju and maas?  I thought those could be dealt with out-of-band?
[16:23] <pitti> slangasek: juju potentially yes; I don't know how we would deal with maas? (but I'm not familiar with it at all)
[16:23] <dannf> infinity: any comments on https://code.launchpad.net/~dannf/debian-installer/arm64-cleanup/+merge/249738 ? i've posted an MP for lp:maas-images for smoser so that side of things should be good
[16:23] <pitti> slangasek: and there's NFS too?
[16:24] <slangasek> pitti: nfs is critical path, yes, and I'm going to get that sorted out today
[16:24] <infinity> dannf: Not until after today's point release happens, I'm in multitasking hell.
[16:24] <dholbach> thanks cyphermox, slangasek
[16:24] <slangasek> pitti: I don't remember what the issue is with maas?
[16:24] <dannf> infinity: ack
[16:25] <slangasek> hum. what the heck is grilo-plugins and why is it being pulled into main?
[16:25] <slangasek> gnome-music?  is that used on the Ubuntu desktop?
[16:25] <pitti> slangasek: I figure primarily the fact that it has three upstart jobs, but no systemd units or sysv init scripts; I don't know whether it dynamically creates upstart jobs
[16:26] <slangasek> ok
[16:26] <infinity> slangasek: According to the MIR, it's totem.
[16:27] <slangasek> pitti: I don't see maas broken out as a work item on https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration... have you spoken with anyone on the maas team about this?
[16:27] <pitti> I thought we had a representative from the maas team on the last meeting, but indeed I don't see a bug
[16:28] <slangasek> roaksoax: ping - is someone working on making maas work with systemd?
[16:28]  * pitti creates one
[16:29] <slangasek> rbasak: hey, so re: bug #1417328, I see that mariadb-10.0 is failing to migrate to trusty because several of the binaries that it builds are showing as uninstallable; do you know what's happening there or should I investigate?
[16:30] <infinity> slangasek: It needs a smooth transition of mysql-5.6 with it, IIRC.
[16:31]  * pitti files bug 1423613
[16:31] <rbasak> slangasek: I'm on top of it, with infinity's help. percona-xtradb-cluster-5.6 needs accepting first ideally. Then we can delete all the 5.5 packages, remove the old binaries, and everything should work.
[16:31] <rbasak> In theory. There will inevitably be something I've missed.
[16:32] <rbasak> slangasek: oh, for your specific question - yes - new mariadb binaries need the new mysql-common from src:mysql-5.6.
[16:33] <slangasek> ok
[16:35] <slangasek> rbasak, infinity: right, checked and confirmed that these packages are installable within vivid-proposed, so looks like percona-xtradb-cluster-5.6 will do the trick
[16:36] <rbasak> BTW, percona-xtradb-cluster-5.6 depends on percona-galera-3, but the latter is relatively trivial.
[16:39] <tkamppeter> ScottK, this behavior is not known to me. You should report a bug to HPLIP upstream (https://launchpad.net/hplip/). When reporting the bug follow the instructions on https://wiki.ubuntu.com/DebuggingPrintingProblems.
[16:39] <ScottK> tkamppeter: Thanks.
[16:40] <flexiondotorg> cyphermox, Is there anything additional I need to do with mate-menu or mate-tweak?
[16:40] <ScottK> tkamppeter: Maybe I should try and backport hplip from vivid first and see if that fixes it.
[16:40] <cyphermox> flexiondotorg: hold on, I'm on something else for a minute
[16:40] <flexiondotorg> cyphermox, Sure
[16:40] <cyphermox> flexiondotorg: I haven't reviewed mate-tweak yet
[16:45] <infinity> rbasak: Speaking of the mysql-5.6 transition, php5 in vivid-proposed is failing to install build-deps with:
[16:45] <infinity> The following packages have unmet dependencies:
[16:45] <infinity>  mysql-server : Depends: mysql-server-5.6 but it is not installable
[16:45] <infinity> E: Unable to correct problems, you have held broken packages.
[16:46] <infinity> rbasak: Is that the same old "5.6 can't install while 5.5 still exists" bug that really needs to be understood and fixed, or something worse?
[16:46] <rbasak> infinity: yeah. I'm a bit confused about that. AFAICT, it is installable in vivid-proposed, and my local sbuild succeeds on it
[16:46] <rbasak> So I was going to retry after mysql-5.6 migrates.
[16:46] <rbasak> It might have been something temporary while stuff was changing round or something.
[16:47] <rbasak> (I've done so many uploads of mysql-5.6 and mariadb-10.0 and the deps are complicated enough that I can't contemplate the appropriate dependency history in my head right now)
[16:48] <rbasak> I wonder. Is it a main vs. universe thing?
[16:48]  * infinity wonders why and when php5 got a build-dep on mysql-*server* anyway.
[16:48] <rbasak> mysql-server-core-5.6 binary for example is in universe.
[16:48] <rbasak> msyql-server virtual package is in main.
[16:48] <rbasak> Maybe that's it.
[16:49] <infinity> rbasak: Oh, hrm.  I don't see that on component-mismatches-proposed.
[16:49] <rbasak> I'm only guessing.
[16:49] <infinity> Oh, yes I do.
[16:49] <infinity> I'm blind.
[16:49] <infinity> The whole mysql-5.6 source is in universe, that's why.
[16:49] <infinity> I was looking at the binary-only section.
[16:49] <infinity> So, yes, that needs fixing. :P
[16:49] <rbasak> Ah. I was expecting to ask someone to fix that after things had migrated and settled.
[16:50] <rbasak> I presume no MIR is needed for this one.
[16:50] <infinity> rbasak: No MIR needed.  post-migration is the wrong time to ask for the fixing.
[16:50] <Bluefoxicy> okay so
[16:50] <rbasak> Oh. OK.
[16:50] <rbasak> infinity: please could you fix? :-P
[16:50] <infinity> rbasak: Doing so. :P
[16:50] <Bluefoxicy> installing Ubuntu 14.04.1 LTS creates a dangling link /initrd.img -> /boot/initrd-3.13.0-32-generic
[16:51] <Bluefoxicy> causing linux-image-3.13.0-32-generic to fail to install
[16:51] <Bluefoxicy> causing linux-extra-blahblahblah to fail dependencies
[16:51] <Bluefoxicy> causing install to halt.
[16:51] <infinity> Bluefoxicy: Good thing we're just hours away from releasing 14.04.2 then.
[16:51] <Bluefoxicy> ... this is from the 14.04.1-LTS server install on AMD64
[16:51] <Bluefoxicy> infinity, oh good.
[16:52] <Bluefoxicy> infinity, point me at the latest release plz.  I'll tell you if it's broken in like 10 minutes.
[16:52] <tkamppeter> ScottK, yes, I think ths would be a good idea. 12.04 is rather old.
[16:52] <ScottK> Actually I meant 14.04, but it's still older.
[16:52] <Bluefoxicy> http://cdimage.ubuntu.com/trusty/daily-live/current/ is this it?
[16:53] <Bluefoxicy> ... need server amd64
[16:53] <infinity> Bluefoxicy: Should do.
[16:53] <infinity> Bluefoxicy: Err, server.  You want /ubuntu-server/ in there.
[16:53] <infinity> http://cdimage.ubuntu.com/ubuntu-server/trusty/daily/20150218.1/
[16:53] <Bluefoxicy> aha, thanks.
[16:54] <infinity> Bluefoxicy: Though that dangling link thing sounds like something more people would have noticed.  I'm curious how it's just you.
[16:55] <Bluefoxicy> infinity, I'm using a 2GB ext2 /boot, LVM for the rest of that disk, with a separate /log and /var/spool/mail.  /boot is noatime,nodiratime,sync,nodev,noexec,nosuid,user_xattr
[16:55] <Bluefoxicy> I don't think any of that would affect the ability to create the initrd file
[16:57] <Bluefoxicy> k sec, my download is slow, currently coming at 28MB/s, give me a minute
[17:01] <roaksoax> slangasek: as in the init jobs? no we have not looked at that.
[17:02] <roaksoax> slangasek: is there some kind of spec?
[17:07] <Bluefoxicy> still fails
[17:08] <alexbligh1> how long in general does it take for a new release to appear on http://cdimage.ubuntu.com/releases/ ? 14.04.2 has been in the repo several hours, but the CD image isn't up. I'm guessing there is some kind of automated test process. I know I could use the daily build, but presumably that has *not* been through the test process yet.
[17:09] <Bluefoxicy> infinity, http://i.imgur.com/b0BzWmZ.png
[17:09] <Bluefoxicy> I get that out of console 4 ando ut of a chroot /target dpkg --configure -a
[17:10] <infinity> alexbligh1: 14.04.2 doesn't exist until I say it does, essentially. :P
[17:10] <Bluefoxicy> infinity, does console 4 log go anywhere I can extract full log from?
[17:11] <infinity> Bluefoxicy: So, (a) this isn't a regression (obviously), and (b) it's pretty specific to you.  So, I'd love to debug it, but I won't be blocking 14.04.2 on it. :/
[17:11] <alexbligh1> infinity, ah, the manual process of administering divine blessing :-)
[17:11] <infinity> Bluefoxicy: /var/log/syslog should have the whole installation.
[17:13] <Bluefoxicy> infinity, it looks like it fails to mount things
[17:15] <Bluefoxicy> oh I see
[17:15] <slangasek> roaksoax: spec is https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration
[17:15] <Bluefoxicy> it tries to mount every partition to see what it is; it can't mount LVM physical volumes to /tmp/AnonTW or whatever
[17:15] <slangasek> roaksoax: I'm trying to remember now what was discussed during the systemd sprint - did blake come to that?  Maybe it had been proposed that maas set a boot arg to continue booting upstart, until this is supported?
[17:17] <Bluefoxicy> infinity, do you get a lot of getfattr Operation Not Permitted errors on syslog?
[17:17] <Bluefoxicy> Operation Not Supported rather
[17:17] <infinity> Bluefoxicy: If you feel your setup is sane and should be supported, please do file a bug on whatever's perpetrating the evil.
[17:18] <Bluefoxicy> infinity,  I'm actually about to try a default install for a baseline.  It's just vmware esx
[17:19] <jamespage> pitti, are we enabling the biosdevname equiv feature in systemd (as in http://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames) for vivid?
[17:19] <pitti> jamespage: no, we don't
[17:20] <jamespage> pitti, so we'll still rely on biosdevname?
[17:20] <pitti> we haven't enabled it yet in ubuntu, stgraber has some reservations about this
[17:20] <pitti> jamespage: no, I thought we don't want the fancy names at all?
[17:21] <pitti> the problem wasn't biosdevname or the udev equivalent itself, but too much software expecting the names to be "eth0" or "wlan0"
[17:21] <Bluefoxicy> okay, the getfattr thing is normal; breakage is not.  I'll track it down and see what I can find out.
[17:22] <Bluefoxicy> infinity, thanks
[17:24] <jamespage> pitti, hrm - I think a stock server install on 14.04 installs biosdevname
[17:25] <jamespage> pitti, did we take it out again post 14.04?
[17:25]  * rbasak thought the same as jamespage
[17:25] <pitti> oh, I don't know
[17:25] <pitti> last time I discussed that with stgraber he said "we don't want this"
[17:25] <jamespage> pitti, I'm pretty sure it does
[17:25] <pitti> if we do, we can certainly enable that
[17:26] <slangasek> I think the last time it was discussed was when we were being pushed to enable it via SRU
[17:26] <pitti> we definitively don't install it on a desktop
[17:26] <jamespage> pitti, there is some debate as to whether we do want to enable this
[17:26] <jamespage> or disable it
[17:26] <jamespage> pitti, agreed on desktop installs
[17:26] <rbasak> https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/891258
[17:26] <rbasak> Dells only?
[17:27] <cjwatson> no I'm pretty sure I refused to make that hw-specific
[17:27] <rbasak> https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/891258/comments/18
[17:27] <rbasak> That was when it was enabled by default. You're right - no reference to hw-specific there.
[17:27] <pitti> ah, we got stuff like bug 1293633
[17:27] <cjwatson> but I enabled it on firm instruction and under protest
[17:28] <pitti> so it's not desktop vs. server, it's ubiquity vs. alternates?
[17:28] <rbasak> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1347859 exists
[17:28] <cjwatson> so I am not advocating for it :)
[17:29] <infinity> Maybe the systemd equivalent fixed all of this, but biosdevname was racy as heck and would leave interfaces in weird half-done "rename" states.
[17:29] <infinity> It was not a pleasant solution to what, for most people, is a non-problem.
[17:29] <slangasek> infinity: you're thinking of the precursor to biosdevname
[17:29] <slangasek> or the precursor to its proper integration
[17:30] <infinity> slangasek: I'm definitely thinking of biosdevname.
[17:30] <infinity> slangasek: Yeah, I know the udev persistent rules also had that issue, but that was fixed.
[17:34] <roaksoax>  slangasek nope, he didn't go to the systemd sprint
[17:34] <slangasek> roaksoax: didn't he?  it was a virtual sprint and I thought he was there part of the time, but ok
[17:34] <roaksoax> slangasek: i'll review the spec and probably have this looked at this week
[17:35] <roaksoax> slangasek: we are sprinting now, so it probably makes sense for us to look at it
[17:35] <roaksoax> now
[17:35] <stgraber> jamespage, pitti: server has biosdevname, everything else doesn't
[17:35] <slangasek> roaksoax: perfect, thanks
[17:37] <bdmurray> shadeslayer: could you update bug 1375786?
[17:37] <Bluefoxicy> Methinks it simply does not like having that many file systems mounted during install
[17:39] <alexbligh1> in a Depends file, what is the correct way of depending on the version of Ubuntu? I want a package that will install on both P and T but the dependencies are different
[17:39] <Bluefoxicy> infinity, Potential cause:  tar complains it can't remove /var/spool/mail.  I mounted something on /var/spool/mail.  Files can't be found in /var to build the initrd.  Perhaps the installer dislikes having a separate partition for mail.
[17:39] <alexbligh1> s/Depends/control/
[17:41] <Bluefoxicy> It's a decent enough use case for servers, because something as simple as a crontab * * * * * /bin/do_something_that_emits_output could make gigabytes of crap in /var/spool/mail/root which, by design, can't be rotated with logrotate.
[17:43] <infinity> Bluefoxicy: Pretty please file a bug with syslog attached and your thoughts/debugging of the matter.  I'm far too busy today with the point release to give it proper attention.
[17:45] <Bluefoxicy> infinity, nod.  Just fishing for info.  I'll add a bug later when I've done more testing.
[17:48] <aeoril> darkxst I contacted cphe via e-mail and he thinks the bug is not in vte or gnome-terminal, but somewhere else in Ubuntu.  Unless someone else has any really helpful ideas, I am thinking of admitting defeat at this point
[17:52] <happyaron> dholbach: thanks for merging 1377370, I'm on spring festival holidays, :)
[17:52] <dholbach> happyaron, of course you are - enjoy the break! and happy new year!
[17:53] <happyaron> xD
[18:01] <zyga> pitti: hey, what's the best way to get pyotherside 1.4 into ubuntu today?
[18:01] <pitti> zyga: hah, just talking to Trevinho :)
[18:01] <zyga> yeah, we work together on this
[18:01] <pitti> zyga: I'm currently sponsoring it to exp and I was wondering if that was agreed with you
[18:02] <zyga> pitti: the updated version is in debian svn, I'm trying to get it moved to collab-maint
[18:02] <zyga> pitti: yes though I did make changes since his version was pushed
[18:02] <pitti> https://ftp-master.debian.org/dinstall.html
[18:02] <zyga> Trevinho: ^^
[18:02] <pitti> zyga, Trevinho ^
[18:02] <pitti> so it should hit launchpad in maybe 4 hours, then someone can sync
[18:02] <pitti> I'm quite sure that if we sync it tomorrow (Europe) morning, the world won't crumble either
[18:03] <zyga> pitti: ok, but how do we get it into debian :)
[18:03] <zyga> pitti: I cannot push it there
[18:03] <pitti> pitti | zyga: I'm currently sponsoring it to exp [...]
[18:03] <zyga> pitti: ah, ok, which version did you get?
[18:03] <pitti> 1.4.0-1 from http://debomatic-amd64.debian.net/debomatic/experimental/pool/pyotherside_1.4.0-1/
[18:03] <Trevinho> pitti: http://anonscm.debian.org/viewvc/python-modules/packages/pyotherside/trunk/ would be better
[18:03] <zyga> pitti: and if possible, could you get the last one from dpmt svn (on it's way out of dpmt) please?
[18:03] <Trevinho> if it's not too late
[18:03] <zyga> pitti: there were some minor changes later:
[18:04] <pitti> no, I just built, I didn't uplaod yet
[18:04] <Trevinho> or... zyga in case prepare a -2
[18:04] <pitti> someone please toss me a .dsc
[18:04] <zyga> http://anonscm.debian.org/viewvc/python-modules/packages/pyotherside/trunk/debian/control?view=log
[18:04] <pitti> (multiplexing/overloaded/late already, sorry0
[18:04] <zyga> sorry, ok
[18:04] <Trevinho> zyga: you handle that, right?
[18:05] <zyga> Trevinho: I think, I never worked that way before
[18:05] <pitti> bdmurray: bug 1420544> I'm afraid that's something the reporter or utlemming has to test themselves, as this requires being on a google cloud instance
[18:06] <utlemming> bdmurray, pitti: I'll confirm that today
[18:11] <pitti> utlemming: do you need that for precise, too, BTW?
[18:11] <pitti> utlemming: and before that can go to -updates, we need some plan what to do for vivid onwards; i. e. fix this properly in the driver (the SRUed rule is more like a hack really), or whatnot
[18:11] <utlemming> pitti: eventually, yes
[18:12] <pitti> Trevinho, zyga: I need some dinner; ping me once you have a dsc to be sponsored, then I can uplaod to Debin experimental
[18:12] <zyga> pitti: ok
[18:12] <pitti> Trevinho, zyga: ideally before https://ftp-master.debian.org/dinstall.html :)
[18:13] <flexiondotorg> cyphermox, I see new "stuff" in the upload queue 😃 Thanks for your help!
[18:17] <zyga> Trevinho: can you help me build that somewhere?
[18:19] <zyga> Trevinho: I've copied all of that to pi.zygoon.pl/~zyga/
[18:19] <zyga> Trevinho: can you test-build it using deb-o-matic
[18:19] <Trevinho> yes
[18:22] <cyphermox> flexiondotorg: oh, yes
[18:23] <cyphermox> flexiondotorg: just make sure to update-maintainer in each of these branches, it's the only change I did
[18:24] <Trevinho> zyga: the build in amhrf failed in deb-o-matic due to a segfault on testing, but maybe it's just there
[18:24] <zyga> Trevinho: hmmm
[18:24] <zyga> Trevinho: that's not good
[18:25] <zyga> Trevinho: what was in the segvfault?
[18:25]  * zyga tries on arm locally
[18:25] <Trevinho> zyga: http://debomatic-armhf.debian.net/distribution#experimental/pyotherside/1.4.0-1/buildlog
[18:26] <Trevinho> zyga: libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
[18:26] <Trevinho> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[18:26] <zyga> yeah
[18:26] <zyga> hmm
[18:26] <Trevinho> not sure in experimental, but it was doing it fine in vivid
[18:26] <Trevinho> last time I built that
[18:27] <zyga> I think I saw that earlier
[18:29] <Trevinho> zyga: building at http://debomatic-amd64.debian.net/distribution#experimental/pyotherside/1.4.0-1/buildlog
[18:30] <zyga> Trevinho: did you change anything?
[18:31] <Trevinho> zyga: no, but I had to resign the dsc with my key in order to get that built
[18:32] <zyga> ah, right
[18:50] <zyga> Trevinho: building locally, we'll see
[19:00] <zyga> Trevinho: builds and tests on x86 are ok
[19:00] <Trevinho> zyga: I've just made sure that you're getting an account on deb-o-matic btw
[19:00] <pitti> slangasek: so if we still want to push for the switch in vivid, and assume that maas/juju land in time (or get a workaround), and assume that NFS lands soon: the actual flip would mostly be a seed change, right? or do you see anythign else there?
[19:01] <zyga> Trevinho: thanks!
[19:01] <pitti> slangasek: I guess I could stuff an updated ubuntu-meta into a PPA and test dist-upgrade from utopic and trusty with that, to ensure apt gets along with the removals etc.?
[19:01] <slangasek> pitti: I don't recall whether we discussed the mechanics of the change.  Probably a seed change - maybe xnox has looked at it?
[19:01] <zyga> pitti: we have a deb but it failed testing on deb-o-matic armhf (DRI related), still, its our best bet
[19:01] <slangasek> pitti: sounds like a good test
[19:01] <pitti> slangasek: no, I don't think we discussed it in depth; it should mostly just be a seed change indeed
[19:01] <pitti> slangasek: ack, I'll do that then
[19:02] <zyga> pitti: otherwise it builds and tests fine on sid-amd64
[19:02] <zyga> pitti: dget http://pi.lan/~zyga/pyotherside_1.4.0-1.dsc
[19:03] <pitti> curl: (6) Could not resolve host: pi.lan
[19:03] <pitti> zyga: .lan sounds like something local? :-)
[19:03] <zyga> d'oh
[19:03] <zyga> pitti: pi.zygoon.pl
[19:03] <zyga> :D
[19:03] <zyga> yes
[19:04]  * zyga needs to get that hisilicon board instead
[19:04] <zyga> as all the arm boards around have just a gig of ram tops
[19:05] <pitti> wow, it needs that much RAM to build?
[19:05] <zyga> pitti: it's lintian clean, the upstream hash checks out and packaging changes are minimal
[19:05] <pitti> yes, debdiff looks good
[19:05] <zyga> pitti: no, it's not that, just having so little ram is annoying
[19:08] <zyga> pitti: adt tests just finished, passing
[19:09] <pitti> zyga: ah good, I just started them with teh sbuilt binaries two mins ago
[19:09] <pitti> but I guess I can just as well let them finish, still 40 mins to go
[19:09] <zyga> pitti: do you run adt on arm as well?
[19:10] <pitti> done
[19:10] <pitti> no, just amd64
[19:10] <zyga> pitti: yeah, same here
[19:11] <zyga> pitti: I should setup something running ubuntu as armhf is (especially in our team now) almost front and center
[19:12] <pitti> zyga, Trevinho: uploaded
[19:12] <zyga> pitti: thanks a lot!
[19:12] <zyga> Trevinho: what else remains to sync it to ubuntu?
[19:13] <zyga> next sync in 38 minutes
[19:14] <pitti> well, that's the debian dinstall run; after that it takes a couple of hours to hit the Debian mirrors and get imported into LP
[19:14] <pitti> zyga, Trevinho: if it's urgent, I could upload it as ~fakesync to vivid, and "properly" sync again tomorrow
[19:15] <zyga> Trevinho: what do you think?
[19:15] <Trevinho> pitti: well, not that urgent
[19:15] <Trevinho> pitti: it depends if we can do it tomorrow as well... :)
[19:15] <Trevinho> pitti: the thing is that vivid has already basically the same version minus a commit that fixes a crash, so pushing there is mostly a bug fix
[19:16] <pitti> oh, indeed!
[19:16] <pitti> Trevinho: no urgency at all then
[19:17] <pitti> Trevinho: so there are no other ubuntu changes to keep, we can sync tomorrow?
[19:17] <pitti> (bug fixes and syncs which only bring in bug fixes are possible any time)
[19:18] <Trevinho> pitti: yes, no worries
[19:18] <Trevinho> pitti: thanks
[19:30] <zyga> thanks to both of you!
[19:30]  * zyga EODs
[19:30] <zyga> see you
[19:33] <pitti> mvo: hm, it seems merely changing ubuntu-minimal to drop upstart and ureadahead and adding systemd-sysv doesn't convince apt enough to replace the packages
[19:34] <xevious> Is the 14.04.2 release still on track for today?
[19:34] <pitti> mvo: i. e. uninstall upstart+ureadahead and install systemd-sysv
[19:34] <pitti> mvo: a Replaces/Provides: upstart would be clearly wrong, is there some other way we could do this?
[19:36] <Unit193> bdmurray: Added hopefully enough info to give you some background.
[19:37] <pitti> slangasek: ^ FYI (not that simple for updates); I guess we don't need to figure this out today, and for people who don't have ubuntu-minimal installed we need some fallback solution anyway; but it's still too early to more forcefully drop the upstart package IMHO
[19:40] <slangasek> pitti: drop ureadahead> so has that still not been addressed?  I heard there was confusion about ureadahead being "obsolete", which it's not
[19:40] <slangasek> AIUI systemd does not embed equivalent functionality
[19:41] <pitti> slangasek: it used to up to 215, but as nobody maintained it it was dropped, yes
[19:41] <slangasek> mm
[19:41] <pitti> slangasek: we have a WI to investigate if it's still necessary/useful, and revive it to work with systemd too
[19:41] <pitti> or bring back systemd-readahead
[19:42] <pitti> (mostly for the phone)
[19:42] <pitti> ATM it mostly gets uninstalled because it Depends: upstart, and only has upstart jobs
[19:48] <pitti> actually, fixing ureadahead could already help enough, I'll look at that
[19:52] <ogra_> yeah, please dont drop it ... it helps a lot on slow I/O devices
[19:53] <ogra_> (gained me ~5sec of the phone boot to read all files at once)
[19:54] <pitti> mterry: any chance you could have a look at the two python libs in bug 1407695? these have blocked keystone in -proposed for over a month
[19:54] <pitti> sarnold: ^ that one also has xmlsec1 which is assigned to you; any chance you could have a look at it?
[19:54] <pitti> ogra_: *nod*
[19:54] <sarnold> pitti: hey, I think they're blocked on security team
[19:55] <sarnold> pitti: I'm going to work on them soon, thanks for the ping
[19:55] <mterry> pitti, will look at the non-security ones today or tomorrow
[19:55] <pitti> mterry: cheers
[19:56] <mterry> pitti, they fell off my radar after passing off the security one, thanks
[19:58] <bdmurray> Unit193: how does the desktop manifest file show the the xubuntu-core package uses ubuntu-release-upgrader-core? I installed xubuntu-core and ubuntu-release-upgrader-core was not installed. I'd expect people installing from the mini iso to upgrade via apt-get after changing soruces.list
[20:03] <Unit193> bdmurray: Aha, sorry.  I seem to have misunderstood.  For Lubuntu, I've seen this problem pop up a few times on IRC, mailing list, and I believe a bug though I don't know where.  Generally speaking Ubuntu support channels tell you not to upgrade that way as well.  So, did you install the xubunt-core metapackage, or the task?  From all tests done by our team, when you install the task (like we're
[20:03] <Unit193> recommending, it works out far better than the meta), ubuntu-release-upgrader-core does end up getting pulled in anyway, and since that's what all the documentation tells you to use, users get an unexpected result.
[20:05] <bdmurray> Unit193: How do you have people install the xubuntu-core task?
[20:05] <Unit193> bdmurray: The mini.iso generally uses tasksel, which is one very common way to do it.  Another option of course is  apt-get install xubuntu-core^
[20:16] <pitti> mvo, slangasek: ah nice, fixing ureadahead actually makes the dist-upgrade work
[20:17] <pitti> replacing one package with another is apparenlty ok, replacing two with one another isn't :)
[20:17] <pitti> s/one another/another/
[20:17] <pitti> well "an other", too late for grammar
[20:30] <Unit193> bdmurray: You still with me?
[20:30] <bdmurray> Unit193: I'm installing from the mini.iso now
[20:31] <Unit193> Aha.
[20:50] <infinity> pitti: Isn't the solution to "people don't have ubuntu-minimal installed" to promote "init" to Essential, and have it flip the dep?
[20:51] <infinity> Though, that would have gone better if we'd had it in trusty...
[20:53] <infinity> Actually, apt always tries to install new Essential packages, I think, so that would still work.
[21:02] <utlemming> bdmurray: SRU'ified bug #1420544...sorry about that
[21:52] <flexiondotorg> cyphermox, Ping?
[22:02] <cyphermox> flexiondotorg: what's up?
[22:03] <flexiondotorg> cyphermox, Was wondering when we can start killing some kittens?
[22:03] <flexiondotorg> cyphermox, I mean, try some builds 😉
[22:04] <cyphermox> flexiondotorg: I think that's up to infinity at this point, whether he reverted the ubuntu-cdimage changes and whether he can spare a minute to poke the right buttons, but I know he's busy with Trusty right now
[22:05] <infinity> cyphermox: I didn't revert anything, but I'm in the middle of publishing 14.04.2 right now, so I'd appreciate others not mucking around on cdimage.
[22:05] <cyphermox> infinity: totally understand
[22:05] <flexiondotorg> cyphermox, OK. I seen that Trusty .2 has dominated peoples attention. Fair enough 😃
[22:06] <cyphermox> fwiw, *I* have no access to touch any of this
[23:35] <tyhicks> Laney: fyi - I've attached a dbus debdiff of the backported-from-dbus-upstream apparmor patches to https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1362469/comments/9