[00:00] <slangasek> tsimonq2: you're looking for yakkety daily images, not xenial daily images?
[00:00] <tsimonq2> slangasek: correct
[00:00] <wxl> wait
[00:00] <wxl> uh
[00:00] <wxl> why?
[00:00] <slangasek> Missing debootstrap-required makedev
[00:00] <slangasek> CD1 missing some packages needed by debootstrap
[00:00] <slangasek> make: *** [/srv/cdimage.ubuntu.com/scratch/lubuntu/yakkety/daily/tmp/yakkety-pow
[00:00] <slangasek> erpc/packages-stamp] Error 1
[00:00] <slangasek> ERROR WHILE BUILDING OFFICIAL IMAGES !!
[00:00] <tsimonq2> slangasek: wait, relating to this problem?
[00:00] <wxl> we're testing xenial for .1
[00:00] <tsimonq2> yes
[00:00] <tsimonq2> sorry
[00:00] <tsimonq2> oghhhhh I'm stupid :(
[00:01] <slangasek> checking if the errors are similar for the other lubuntu dailies
[00:01] <wxl> it happens to all of us
[00:01] <slangasek> they are
[00:01] <slangasek> anyway, yeah, that dir is for the yakkety dailies, not the 16.04.1 candidates
[00:01] <wxl> i asked adam earlier if we had a timeline for the TRUSTY respin XD
[00:01] <slangasek> wxl: we do! "next week"
[00:01] <tsimonq2> welp, Xenial is good to go
[00:01] <tsimonq2> slangasek: but a good time to look at Yakkety XD
[00:02] <wxl> heheh
[00:02] <tsimonq2> sorry all :P
[00:02] <wxl> no worries
[00:02] <wxl> looks like you caught something at least
[00:02] <wxl> it's just not as urgent :)
[00:02] <tsimonq2> yep :)
[00:02] <tsimonq2> sorry for the pings infinity :)
[00:03] <wxl> just keep on pinging him while you tell him sorry for pinging him
[00:03] <wxl> sheesh, the nerve of some people :)
[00:03] <tsimonq2> yep, that's how that works ;)
[00:03] <tsimonq2> anyways, I'm testing for that libfm fix
[00:04] <wxl> in yakkety or xenial?
[00:04] <tsimonq2> Xenial
[00:04] <wxl> oh well get that thing zsync'd then :)
[00:04] <tsimonq2> I'm grabbing the Xenial image to test and see if the libfm fix is good to go for 16.04.1
[00:05] <tsimonq2> wxl: that's what I'm doing ;)
[00:05] <slangasek> tsimonq2: so regarding the oversizedness, who is going to fit this back down to CD size and when?  This is listed on a daily basis as an error in my email, it's tagged as a warning on the index of every daily image, yet it hasn't gotten attention for the past two releases.  An error message that no one pays attention to isn't useful
[00:06] <tsimonq2> slangasek: I see - how do I get this error message? XD
[00:06] <tsimonq2> slangasek: but in all serious, Julien
[00:06] <tsimonq2> *seriousness
[00:06] <slangasek> we can sign you up to receive the daily emails ;P
[00:07] <tsimonq2> slangasek: he's our development head and does the metapackage manipulation
[00:07] <slangasek> (and it's also in red on http://cdimage.ubuntu.com/lubuntu/xenial/daily/current/)
[00:08] <tsimonq2> wxl: can we sign lubuntu-devel or lubuntu-admins up? :)
[00:09] <tsimonq2> slangasek: I'll address it at our Lubuntu meeting tomorrow
[00:09] <slangasek> tsimonq2: cheers
[00:09] <tsimonq2> slangasek: anyways, where did you find those errors?
[00:10] <slangasek> tsimonq2: the ones about the image builds?
[00:10] <slangasek> I found them on nusakan... let me remember where the public mirror is
[00:10] <tsimonq2> slangasek: are these part of the emails that get sent out?
[00:10] <slangasek> tsimonq2: build failure mails also get sent out, yes
[00:11] <tsimonq2> I mean, with the logs?
[00:11] <slangasek> yes
[00:11] <tsimonq2> slangasek: could you just forward me today's email<EMAIL_ADDRESS>[00:12] <slangasek> and http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ doesn't have anything newer than utopic, and I think those are only the logs for the old livefs builders... not sure if the cdimage logs are published anywhere
[00:12] <slangasek> tsimonq2: it's quite possible that the failure emails also only cover livefs builds, now that I look at my mail history
[00:13] <slangasek> but I can dig a log out and post it for you
[00:13] <tsimonq2> :/
[00:13] <tsimonq2> that would be awesome, thank you
[00:16] <slangasek> tzimonq: https://people.canonical.com/~vorlon/lubuntu-daily-20160719.log
[00:16] <slangasek> eh
[00:16] <slangasek> tsimonq2: ^^
[00:17] <tsimonq2> thanks slangasek
[00:18] <tsimonq2> slangasek: is the nusakan code public?
[00:19] <tjaalton> infinity: who are 'the friends'? :)
[00:19] <tjaalton> infinity: i've been on vacation and sprinting this week, I can test the image at some point today/tomorrow
[00:20] <slangasek> tsimonq2: yes, lp:ubuntu-cdimage
[00:21] <tsimonq2> slangasek: I thought that was only the scripts that called it? where are the actual build scripts (in lp:ubuntu-cdimage)
[00:26] <slangasek> tsimonq2: ah, then you mean lp:~ubuntu-cdimage/debian-cd/ubuntu
[00:27] <tsimonq2> that might be it :)
[00:28] <tsimonq2> thanks :)
[00:46] <tsimonq2> slangasek: hey, you still around?
[00:54] <xnox> slangasek, http://people.canonical.com/~ubuntu-archive/cd-build-logs/
[00:54] <tsimonq2> OH! thanks xnox :)
[00:55] <xnox> for some things you would want to see the livebuild info from launchpad, and the start of the log it will have urls to requested livebuilds
[00:55] <xnox> and follow that to see that part of the build log
[00:56] <xnox> e.g. http://people.canonical.com/~ubuntu-archive/cd-build-logs/livecd-base/xenial/?C=M;O=A ->
[00:56] <xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/livecd-base/xenial/livecd-base-20160420.log ->
[00:56] <xnox> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-base/+build/69643
[00:56] <xnox> https://launchpadlibrarian.net/273991911/buildlog_ubuntu_xenial_s390x_ubuntu-base_BUILDING.txt.gz
[00:56] <xnox> depending which part of build-process one is after
[00:56] <slangasek> xnox: oh right, those :)
[00:57] <xnox> good night.... however it is still too hot to sleep =/
[05:09] <slangasek> Trevinho: hi, please see bug #1604657
[05:44] <tjaalton> infinity: I don't see the trusty daily image using lts-xenial stack
[05:44] <tjaalton> just did an install
[05:44] <tjaalton> or, at least it doesn't install it, maybe the installer ran it
[05:46] <tjaalton> nope
[05:51] <pitti> infinity: urgh, sorry, misunderstanding -- I thought you just asked for confirmation, not doing it
[05:53] <pitti> infinity: trusty langpacks> I requested a full export on https://translations.launchpad.net/ubuntu/trusty/+language-packs ; not sure if I still caught today's export (possible), otherwise I'll get one next Wed; if you need them earlier, I can ping wgrant about running it manually
[05:54] <pitti> infinity: sprint weeks are notoriously bad for paying attention to IRC, sorry
[06:30] <infinity> pitti: Yeah, I'm sprinting too, I can relate.
[06:30] <infinity> tjaalton: Err, wat?  trusty dailies should have switched.
[06:31] <infinity> Sonofa...
[06:31] <tjaalton> infinity: I downloaded from http://cdimage.ubuntu.com/trusty/daily-live/current/
[06:31] <infinity> tjaalton: Maybe I only did that in a PPA, and I'm braindead?
[06:31] <tjaalton> you tell me ;)
[06:32] <infinity> tjaalton: Yeah, I think I neglected to actually upload.  Derp.  I'll find some time to test my PPA upload a bit, and then push it to the archive.
[06:33] <tjaalton> ok, cool
[06:33] <infinity> tjaalton: I'll give you a poke when dailies have flipped.
[06:33] <tjaalton> thx
[06:33] <infinity> pitti: Next wed should be fine, if that gives you enough time to validate and promote.
[06:40] <tjaalton> infinity: actually, proposed is enabled
[06:40] <tjaalton> in /etc/apt/sources.list.d/proposed.list. but I can't see xserver-xorg-lts-xenial
[06:41] <infinity> tjaalton: Sure, proposed is enabled, but I didn't make the livecd-rootfs change to switch to lts-xenial.  That's sitting in a PPA right now.
[06:41] <tjaalton> and xorg-lts-xenial is not in new anymore?
[06:42] <tjaalton> surely I should be able to see the pkg with apt
[06:42] <infinity> tjaalton: Try an apt-get update?
[06:43] <tjaalton> ah there it is
[06:44] <tjaalton> ooh, and upgrae seems to work too
[06:47] <infinity> tjaalton: You're not supposed to sound surprised by that. ;)
[06:47] <tjaalton> right, spoke too soon :)
[06:48] <tjaalton> the image will build fine, but there's still something with the upgrade, it won't pull everything that's needed
[06:48] <tsimonq2> infinity: could you please upload my fix in bug 1574544 to xenial-proposed?
[06:52] <infinity> tsimonq2: Are you going to retest all lubuntu ISOs if we push that through and respin, or are you wanting it as a post-point-release SRU?
[06:54] <infinity> tsimonq2: Also, the version in your debdiff is wrong.  Can't use the same version as yakkety.
[06:54] <tjaalton> infinity: won't pull libwayland-egl1-mesa-lts-xenial, i'll look into that
[06:55] <infinity> tjaalton: I thought the previous one had that issue too.  I think my wiki instructions explicitly put that on that apt-get install line.
[06:55] <tjaalton> then it'll complain about deps
[06:55] <tjaalton> probably a scripted typo somewhere
[07:01] <tjaalton> huh, works on the installed machine
[07:01] <tjaalton> so maybe it's all fine afterall
[07:01] <tjaalton> I'll check the wiki
[07:06] <tjaalton> infinity: for ubuntu at least it seems to be enough  to just do 'apt install xserver-xorg-lts-xenial libwayland-egl1-mesa-lts-xenial' and it'll pull the kernel and all. --install-recommends is probaly for flavors that don't install recommends by default? (if there are any)
[07:11] <tsimonq2> infinity: let's land in 16.04.1, I'll test the fix, then could you respin once it's in -updates?
[07:11] <tsimonq2> that will be the final respin then
[07:13] <flexiondotorg> infinity, Yo
[07:13] <infinity> flexiondotorg: 'Sup?
[07:13] <flexiondotorg> Where are you hiding?
[07:13] <infinity> flexiondotorg: Germany.
[07:14] <flexiondotorg> :-D
[07:14] <flexiondotorg> I've tried chasing round.
[07:19] <jbicha> infinity: good morning, I'm checking on whether the gnome image will still have gnome-maps
[07:20] <tsimonq2> flocculant: ping
[07:20] <infinity> jbicha: I need to fix that today.
[07:21] <jbicha> infinity: I appreciate it :)
[07:21] <flocculant> tsimonq2: quickly - off out the door very shortly
[07:22] <tsimonq2> flocculant: the fix to light-locker-settings is landing soon, it affects Xubuntu, if the bug report is correct it makes light-locker-settings completely unusable - Lubuntu is doing a respin
[07:22] <tsimonq2> flocculant: I thought I would let you know just in case you wanted to consider doing the same
[07:22] <tsimonq2> (for 16.04.1)
[07:23] <flocculant> what bug is that?
[07:23] <tsimonq2> bug 1574544
[07:25] <flocculant> mmm not seen that one before
[07:28] <flocculant> tsimonq2: we don't install that package
[07:29] <tsimonq2> oh really?
[07:29] <tsimonq2> huh
[07:29] <tsimonq2> alright, problem solved :)
[07:30] <flocculant> too many things too early - we dob't in yak at least, don't think we do in xenial
[07:32] <flocculant> and we don't there either - didn't think so
[07:43] <tsimonq2> infinity: how long does it take for a package to be published in proposed after the upload?
[07:55] <infinity> tsimonq2: It takes until it's done.
[07:55] <tsimonq2> oh okay infinity
[07:59] <infinity> tsimonq2: Should be pushing to mirrors over the next 10-15m.
[08:00] <tsimonq2> thanks, not being impatient, I was just generally curious how long it takes infinity :)
[08:00] <infinity> tsimonq2: The time varies.  Build time, then the publisher can be anywhwere from 5m to 30+, depending on what's pending and in how many series'.
[08:01] <infinity> tsimonq2: Then pushing to public mirrors.
[08:02] <tsimonq2> alright
[08:10] <tsimonq2> infinity: verification-done on bug 1574544
[08:11] <infinity> tsimonq2: Ta.
[08:49] <flexiondotorg> infinity, Obviously no powerpc with me.
[08:50] <flexiondotorg> One community member reports the PowerPC image boots.
[08:50] <flexiondotorg> They've not done and install.
[08:50] <flexiondotorg> That is good enough for me. You're thoughts?
[08:50] <infinity> flexiondotorg: Boots and installs would be ideal.
[08:50] <infinity> flexiondotorg: Well, boot, install, reboot.
[08:50] <flexiondotorg> I'm not going to get an install test :-(
[08:50] <infinity> flexiondotorg: That's the minimal smoketest I require before releasing something to end users.
[08:51] <infinity> flexiondotorg: Can be done in qmeu, though it's sloooow on x86.
[08:51] <flexiondotorg> infinity, Have you seen my laptop ;-)
[08:51] <tjaalton> infinity: when is 14.04.5 supposed to ship?
[08:51] <infinity> tjaalton: 2 weeks and 2 days.
[08:51] <tjaalton> alright
[08:52] <flexiondotorg> infinity, Can you give me 5 mins in a break to teach me the qemu dance?
[08:52] <infinity> flexiondotorg: Yeah.  I might also be able to do it remotely on a PPC machine, though poking a hole and forwarding VNC will take some doing.
[08:53] <infinity> jbicha: Testing livecd-rootfs fix here https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-gnome/+build/69728
[08:53] <tsimonq2> infinity: seems it's landed in -proposed! \o/
[08:53] <infinity> jbicha: If that comes out identical to the current daily, minus gnome-maps, I'll push it to the archive and respoin.
[08:54] <infinity> respin, too.
[08:54] <tsimonq2> whoops, -updates
[08:54] <infinity> tsimonq2: Not entirely, but yes, I'm watching.
[08:54] <tsimonq2> cool, thanks for watching :)
[08:54] <tjaalton> infinity: will the previous stacks be upgraded to .5?
[08:55] <tjaalton> automatically
[08:55] <infinity> tjaalton: Automatically?  No.  We'll resurrect the bits we used in 12.04.5 to inform people they need to upgrade, and teach update-manager to do so, etc.
[08:55] <infinity> tjaalton: Thankfully, this is the last LTS with that broken thing, since we roll in Xenial.
[08:55] <infinity> (yay)
[08:56] <tjaalton> infinity: ok, because the thing is that fglrx users might see regressions because amd hasn't made a non-beta hybrid driver yet
[08:56] <infinity> Joy.
[08:57] <davmor2> infinity: just refreshing all my images I assume the d-i fix is in the latest image right?
[08:57] <infinity> davmor2: Yup.
[08:57] <tjaalton> but if it's enough to mention it in relnotes and maybe warn somewhere (update-manager?) then that's fine
[08:57] <davmor2> infinity: awesome thanks for the fix
[08:57] <infinity> davmor2: Only respins pending now are lubuntu for light-locker-settings and ubuntu-gnome for the livecd-rootfs fix, everything else is stable (and hopefully final)
[08:58] <infinity> davmor2: Pretty please bug any flavours who aren't testing.
[08:58] <infinity> I'd help test for people, but bandwidth at this sprint is awful.
[08:59] <infinity> Plus, ignoring Mark is a CLM.
[08:59] <davmor2> infinity: oh your at the snappy sprint didn't know dude :)
[09:00] <infinity> Yeah.
[09:08]  * mwhudson was thinking this was late for infinity to be awake even by his standards
[09:44] <xnox> infinity, is base the new name for the old core?
[09:44]  * xnox is confused
[09:51] <davmor2> infinity: good news netboot is working \o/
[09:52] <infinity> davmor2: I would be shocked if it wasn't.
[09:52] <infinity> xnox: Yes.  We were forced to rename it do it didn't conflict with the other Core.
[09:52] <infinity> s/do it/so it/
[09:53] <davmor2> infinity: indeed but it's nice to know it now there is a real image right :D
[09:53] <infinity> davmor2: Indeed.  I committed the same to Debian, since they'll hit the same bug in a couple of months.
[10:22] <xnox> infinity, shouldn't "ports" .iso images have /ubuntu-ports directory?
[10:22] <xnox> or at least a symlink from /ubuntu-ports -> /ubuntu?
[10:23] <xnox> cause at the moment, one can network install off that iso mount, but one needs to specify three things on ports: country manual; hostname; directory /ubuntu
[10:23] <xnox> instead of just two on the special snowflake "i386" and "amd64"
[10:23]  * xnox marks offline installation as pass
[10:35] <infinity> xnox: Probably.  File a bug.  Won't fix it for .1
[10:36] <infinity> xnox: It's never been an issue for people installing with the ISO, so I guess we've never noticed.
[10:40] <xnox> bug #1604765
[10:49] <xnox> also console-setup has a minor regression on s390x -> unit fails and causes install to be "degraded"
[10:49] <xnox> bug #1604737
[11:03] <tsimonq2> infinity: what's the status of the rebuild?
[11:09] <infinity> tsimonq2: Kicking off lubuntu* nowish.  Had a lunch break. :P
[11:10] <xnox> i should do lunch too i guess, this encrypted install will take forever
[11:12] <tsimonq2> ok infinity :)
[11:15]  * tsimonq2 sleeps
[11:46] <flexiondotorg> infinity, I'm doing the qemu powerpc dance.
[11:46] <flexiondotorg> Slowly. Very, v-e-r-y, s-l-o-w-l-y....
[11:49] <Odd_Bloke> flexiondotorg: You're slow-dancing with powerpc?
[11:49] <Odd_Bloke> infinity will be jealous.
[11:51] <infinity> flexiondotorg: 64-bit, I hope
[11:51] <infinity> flexiondotorg: The 32-bit emu is even slower and buggier.
[11:51] <flexiondotorg> Not what I wanted to hear infinity ;-)
[11:52] <infinity> flexiondotorg: I'm in an empty slot right now, if you wanted me to come hand-hold.
[11:52] <flexiondotorg> Testing Ubuntu MATE 16.04.1 candidate for PowerPC emulating G4 CPU.
[11:52] <flexiondotorg> infinity, Thanks for the offer. Making good, but slow progress.
[11:52] <infinity> Yeah, emulating a pSeries machine would be less vile.
[11:53] <infinity> qemu-system-ppc64 -M pseries
[11:53] <flexiondotorg> In actual fact, not that much slow than my real iBook G4.
[11:53] <flexiondotorg> infinity, Thanks. Added to my notes.
[11:53] <flexiondotorg> Is that a valid emulation to sign off on the image?
[11:53] <infinity> Sure.
[11:53] <flexiondotorg> OK
[11:54] <infinity> If you have a pseries machine with a video card and it installs MATE, I'd call it good.
[11:54] <infinity> And less likely to explode than old machines from last decade. :P
[11:56] <infinity> Uh oh.  I'm down to three more pseudoephedrine.  This cold needs to die in the next 16 hours.
[12:11] <apw> infinity, that sounds fatal ... need to ask a local what they are called
[12:13] <infinity> apw: Yeah, I might get someone to go buy drugs for me.
[12:15] <xnox> infinity, i think you are after sudafed
[12:15] <infinity> xnox: That'd be the most common brand, yes.
[12:15] <xnox> infinity, but take your existing stuff with you, and say "yo i am sick candadian give me more pills"
[12:16] <xnox> as i think it's prescription only in germany, as it's controlled recreational substitute.....
[12:16] <infinity> That would be lame.
[12:16] <cjwatson> Is it one of those countries where it's easier to buy meth and synthesise pseudoephedrine from it?
[12:16] <xnox> cjwatson, =))) yes
[12:17] <infinity> I didn't know you could go that direction.
[12:17] <infinity> In North America, we buy pseudo to make meth. :P
[12:17] <cjwatson> infinity: http://heterodoxy.cc/meowdocs/pseudo/pseudosynth.pdf
[12:18] <infinity> cjwatson: Why do you have that link handy? :)
[12:18] <xnox> that's what i was pondering too.
[12:18] <cjwatson> I didn't, I just have search-fu :)
[12:18] <xnox> the look up speed is fast with this one
[12:18] <infinity> Uh huh.
[12:19] <infinity> Right.  Well, I'll go find myself a meth dealer and a kids' chemistry set.
[12:20] <cjwatson> (I have nowhere near enough chemistry to be able to tell whether the actual synthesis is feasible or chain-jerking ...)
[12:30] <infinity> cjwatson: Only one way to find out!
[12:30] <infinity> cjwatson: Next up, making coca leaves from cocaine.
[12:30] <infinity> Cause that's good chewin'.
[12:31] <infinity> jbicha: What timezone are you in?
[12:32] <infinity> Oh, EST5EDT.
[13:09] <apw> infinity, ^ this is something which got pushed out by the incoming shim/dkms stuff for secure boot, it is applied to wily/xenial already; but ... is trusty-proposed still open
[13:13] <infinity> apw: Yeah.
[13:13] <infinity> apw: For userspace stuff, trusty's still got time.
[13:13] <sil2100> Hello release team! We just recently pushed out a new address-book-app version to our 3 series (yakkety, xenial-overlay and vivid-overlay)
[13:13] <sil2100> We're working currently on the whole touch xenial-arm64 enablement initiative
[13:14] <sil2100> The new address-book-app basically enables building the arm64 binaries - the thing is, since we had to triple-land address-book-app, now the package will be stuck in -proposed for a longer while due to unity8 not available for arm64
[13:15] <sil2100> Which is a dependency of address-book-app
[13:15] <sil2100> So britney is sad
[13:15] <sil2100> We can't make unity8 buildable because we need oxide-qt 1.17 for that, which is planned to be released in ~a month
[13:16] <sil2100> It is buildable in our xenial-overlay because we (*cough*) hacked in a arm64-only oxide-qt-arm64 1.17 based package there to make things moving, as we can't wait a month for getting our first testable images
[13:16] <infinity> sil2100: So, don't upload packages that depend on packages that don't exist?
[13:16] <sil2100> infinity: I would love to, but address-book-app is a triple-landed CI Train package, it's either all or nothing
[13:17] <sil2100> infinity: if we only pushed that to xenial, with every new address-book-app our changes would be reverted
[13:17] <sil2100> My question now is, how can we proceed? Should we drop the address-book-app part, leave it only for xenial-overlay and rebuild everytime someone triple-lands it?
[13:18] <infinity> sil2100: Or make unity8 build in yakkety?  Where is this mysterious "oxide-qt-arm64 1.17" from, and why can't we just upload oxide-qt 1.17 for all arches instead?
[13:18] <infinity> (If it's a pre-release, fine, upload 1.17~pre1)
[13:18] <sil2100> infinity: it's some oxide release cycle that they follow, we currently have 1.15, in the nearest time there will be a 1.16 released
[13:18] <sil2100> So we can't just skip to 1.17
[13:19] <sil2100> The oxide-qt-arm64 is an overlay-only package we pushed to the PPA that provides oxide-qt binaries only for arm64 that's based on 1.17
[13:19] <infinity> sil2100: Well, what you're asking me to do is let you have uninstallable packages, which is exactly the opposite direction of where we should be heading to.
[13:19] <sil2100> It's a hack we did to speed things up for our testing
[13:20] <sil2100> Well, yeah, but arm64 will be installable once we have all the bits in place, right now we didn't even have any arm64 binaries for address-book-app
[13:20] <sil2100> Currently we simply cannot (or I can't think of an easy way)
[13:20] <infinity> sil2100: If oxide-qt 1.17 is to be final in ~1mo, I don't see why a pre-release can't land now.
[13:21] <sil2100> chrisccoulson: ping
[13:21] <sil2100> infinity: chrisccoulson would have to give us some input here, since if we land a pre-release now, they won't be able to land their 1.16 which they have planned right now and in the works
[13:22] <infinity> sil2100: If the goal is 1.17 for yakkety, we should just work on that.
[13:22] <infinity> sil2100: If the goal isn't 1.17 for yakkety, then your bits will remain uninsallable, and you shouldn't upload them.
[13:22] <infinity> sil2100: I don't see a whole bunch of grey area here.
[13:22] <sil2100> Yes, it is the goal
[13:23] <sil2100> But a goal that will be achieved in a month or so
[13:23] <sil2100> With a few other sub-goals mid-way
[13:23] <sil2100> ;)
[13:23] <infinity> But it clearly sort of exists already, or that oxide-qt 1.17 package you have in your PPA would be vapourware. :P
[13:24] <sil2100> I guess there are some branches out there yes, but 1.17 we have was tailored just for us, with love etc.
[13:24] <sil2100> I need chrisccoulson to back me up on this one
[13:24] <sil2100> Or dbarth
[13:30] <xnox> sil2100, why can you not upload oxide-qt 1.17 for arm64 only into yakkety, they way it is done in the ppa?
[13:30] <xnox> or why triple-landing packaging cannot do special things in xenial-overlay only
[13:31] <xnox> (i.e. have arm64 only in xenial and not other series...)
[13:31] <sil2100> xnox: well, would the archive admins be happy about a oxide-qt package only for arm64?
[13:32] <sil2100> If yes, we can do that no problem
[13:32] <infinity> sil2100: For release?  Absolutely not.  For now, maaaaybe?
[13:32] <sil2100> ;)
[13:32] <sil2100> hm hm hm
[13:34] <chrisccoulson> you can upload whatever version of oxide you like to yakkety. I don't care ;)
[13:34] <sil2100> Ok, let's leave the address-book-app in -proposed for a bit, I'll try to somehow re-check our options
[13:34] <chrisccoulson> the -arm64 hack was because we didn't want to ship a bleeding edge build in an OTA just in order to enable arm64
[13:34] <infinity> chrisccoulson: Right, then I'd rather see that pre-release 1.17 be all arches, not some arm64 hack.
[13:34] <infinity> chrisccoulson: Assuming >= 1.17 will be the final shipping version.
[13:35] <sil2100> Oooh
[13:35] <sil2100> That would be nice
[13:35] <infinity> (in yakkety, I mean, not the overlay)
[13:35] <sil2100> Of course
[13:36] <sil2100> chrisccoulson: do you have any pre-release binaries of oxide-qt 1.17 for yakkety anywhere?
[13:36] <infinity> sil2100: I'm assuming you can take the oxide-qt-arm64 package, rename it, and Bob's your uncle.
[13:36] <infinity> (And enable it on all arches, if it's arm64-specific right now)
[13:37]  * sil2100 shrugs
[13:37] <xnox> infinity, so apart from console-setup degraded bug all looks good. needs ConditionArchitecture=!s390x on the setvtrgb.service
[13:37] <xnox> however, i'm slightly confused why it fails on s390x even in KVM
[13:37] <sil2100> Last time I was re-packaging the source package of oxide-qt it was thrashing my whole laptop for 2 hours
[13:37] <infinity> xnox: Ugh.
[13:37] <infinity> xnox: Is that critically broken?
[13:38] <sil2100> That's why I always tend to ask if we have some version ready somewhere already ;)
[13:38] <infinity> xnox: I don't really want to respin the world. :P
[13:38] <xnox> infinity, nothing is broken, apart from $ systemctl is-system-running claims "degraded" which imho is cosmetic
[13:38] <xnox> so i don't want to respin because of that
[13:38] <infinity> xnox: Ahh, so that can be fixed in a 0-day SRU on Friday or whatever.
[13:38] <xnox> i'll SRU it post .1
[13:38] <infinity> Though, I'm always annoyed by systemd telling me I'm degraded.
[13:39] <xnox> yeah, but if you do happen to respin, squeezing this in might be fun.
[13:39] <xnox> lolz
[13:39] <infinity> xnox: Well, if you're sure disabling it on s390x is the right answer, upload.
[13:39] <xnox> cd /tm
[13:39] <xnox> argh.
[13:39] <infinity> xnox: But if it's more fundamentally "doesn't work on non-vga consoles" or something, we might have a more generic bug to fix.
[13:39] <xnox> focus follow eyesight stopped working again
[13:40] <chrisccoulson> sil2100, I don't have any builds for yakkety. And the version in the overlay PPA is quite out of date now
[13:40] <xnox> infinity, it's all really weird, on kvm i get pretty nice full vt capable console on serial, yet i don't get pretty colors at all.
[13:41] <xnox> e.g. dpkg-reconfigure debconf -> is just black & white rather than aubergine like it is on x86_64 kvm
[13:41] <sil2100> chrisccoulson: but we can use the 1.17 from the overlay for an upload to yakkety, right? Or would you prefer not?
[13:41] <chrisccoulson> sil2100, I'd prefer not. it contains known regressions on other architectures (eg, bug 1599236)
[13:42] <xnox> "Couldn't get a file descriptor referring to the console"
[13:42] <infinity> xnox: Is the console actually a vc, or a different type of tty?
[13:43] <infinity> xnox: The right fix might just be to ignore failure.
[13:43] <xnox> how to correctly query the actual console?
[13:43] <xnox> w says i am on ttysclp0
[13:44] <sil2100> chrisccoulson: hmm, so which version of 1.17 should we use for the pre-release for yakkety?
[13:44] <infinity> Yeah, that's not a vc.
[13:44] <infinity> I wonder if this thing works on serial at all.
[13:44] <infinity> Probably not, given the name.
[13:45] <chrisccoulson> sil2100, the latest revision https://git.launchpad.net/oxide/commit/?id=57e72d85310e5a3b45c56a5ae9f5c98540b8d878
[13:45] <infinity> xnox: I'd suspect the right behaviour is just to ignore failure, rather than try to guess which consoles may or may not work.
[13:45] <infinity> xnox: Or, perhaps, for /sbin/setvtrgb to learn to behave better when asked to mangle a console it can't.
[13:45] <chrisccoulson> Although you'll probably need me to create a tarball
[13:46] <infinity> xnox: Maybe the latter, since it's poor form to have || true in init jobs.
[13:46] <xnox> it does have an array of things it tries
[13:47] <xnox>  /proc/self/fd/0, /dev/tty, /dev/tty0, /dev/vc/0, /dev/systty, /dev/console
[13:47]  * xnox ponders if adding ttyslcp0 to that will make things "work"
[13:47] <sil2100> Ok, so I think I'll just look into making address-book-app temporarily using the bileto hooks
[13:47] <infinity> xnox: Really doubt it.
[13:48] <infinity> xnox: Given that /proc/self/fd/0 is already going to be ttyslcp0 in your case, and it failed to love it.
[13:50] <xnox> yeap.
[13:51] <infinity> xnox: Pretty sure it's doing things the linux vc driver itself can handle, and serial consoles can't.
[13:51] <infinity> xnox: So, yeah.  Might want to test the type of console before it acts, or something.
[13:53] <xnox> trying to find on fedora if and where they call setvtrgb
[13:59] <infinity> xnox: Is stvtrgb using GIO_CMAP/PIO_CMAP?
[14:01] <xnox> infinity, https://sources.debian.net/src/kbd/2.0.3-2/src/getfd.c/
[14:01] <xnox> iterates conspaths, and open_a_console must succeed, wtih is_a_consoole
[14:01] <xnox> 	return (isatty (fd)
[14:01] <xnox> 		&& ioctl(fd, KDGKBTYPE, &arg) == 0
[14:01] <xnox> 		&& ((arg == KB_101) || (arg == KB_84)));
[14:01] <xnox> no idea what GIO_CMAP and PIO_CMAP are
[14:01] <infinity> xnox: I meant to do the color setting.
[14:02] <infinity> xnox: But yes, that confirms my suspicion that they probably are, as they're testing explicitly if a Linux VC IOCTL works.
[14:03] <infinity> xnox: So, the only error, IMO, is that they exit non-zero if none of the scanned victims are Linux VCs.
[14:03] <infinity> xnox: Which would fail on any completely headless system.
[14:03] <infinity> ie: I could reproduce this on PPC just as easily.
[14:05] <infinity> I would suggest that if all is_a_console() attempts fail, you'd want to exit 0, and then later, if setting colours on something we thought should work fails, exit non-zero.
[14:08] <xnox> right
[14:08] <infinity> Ahh, and getfd exits 1 when is_a_console asplodes, so setvtrgb:main() just needs to test for that and either exit 0 or attempt to apply colors.
[14:09] <infinity> Just missing that one branch there, IMO.  It never tests the return of getfd(), it just assumes it got a useful result.
[14:10] <xnox> updated https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/1604737
[14:10] <xnox> with above irc chatter
[14:13] <infinity> xnox: Arguably, the error string from getfd() should be less opaque too, and maybe something more pleasant like "Console isn't a Linux Virtual Console", but meh.
[14:13] <xnox> oh
[14:13] <xnox> getfd does "exit(1)" total failure
[14:13] <infinity> "Couldn't get a file descriptor referring to the console" is about as useful as a kick in the head.  And also a lie.
[14:13] <infinity> Oh, it exits, not returns?
[14:13] <infinity> Derp.
[14:14] <xnox> ...
[14:14] <infinity> So, yeah, that needs to be a return, not exit.
[14:14] <infinity> Then main() needs to look for it and act.
[14:14] <xnox> it's not lieing when it says "total failure" either
[14:14] <infinity> My brain read the exit as return, assuming they wouldn't be so silly, I guess.
[14:15] <infinity> I guess, alternately, it could just exit 0 there.
[14:15] <infinity> Which results in the same behaviour I was suggesting above.
[14:16] <infinity> Just doesn't seem like "Your console isn't a Linux VC" should fail non-zero to me.
[14:16]  * infinity shrugs.
[14:18] <xnox> infinity, set normal exit to 1 in the systemd unit?
[14:18] <xnox> =)
[14:20] <davmor2> infinity: should 16.04.1 have the upgrade from 14.04.4 enabled or is that coming in 14.04.5
[14:23] <xnox> davmor2, after we release 16.04.1 that would make sense to enable..... usually bdmurray does it.
[14:23] <xnox> davmor2, we haven't released 16.04.1 yet
[14:23] <davmor2> xnox: yes I know but I'm just checking for timings
[14:24] <flocculant> cos I was being lazy ...
[14:26] <infinity> davmor2: It'll be early next week, probably.
[14:35] <infinity> Daviey: Yo, is anyone testing mythbuntu?
[14:40] <infinity> davmor2: How's desktop looking?  I don't see any test results on the tracker.
[14:41] <davmor2> infinity: there are some refresh
[14:41] <infinity> davmor2: s/any/many/ ;)
[14:41] <davmor2> infinity: no issues so far
[14:42] <davmor2> infinity: that's cause netboot takes so long but that was good for desktop and server
[14:42] <xnox> infinity, i thought i used to have permissions to mark ubuntu server s390x as ready
[14:43] <davmor2> infinity: I should have amd64 finished today and start looking at i386
[14:43] <infinity> xnox: Doesn't matter, I always mark the Canonical products myself based on the testing state.
[14:43] <xnox> looks like i don't, it's all good across all platforms, variety of disks, etc. with offline/preseed/eltorito/.ins loading
[14:43] <xnox> infinity, the degraded setvtrgb thing is the only "borked" thing
[14:44] <infinity> xnox: Kay.
[14:44] <xnox> i think i might just upload exit(0) to yakkety =)
[14:45] <xnox> however exit 1 is kind of right, it's just that systemd job shouldn't fail and make the boot look degraded
[14:55] <infinity> xnox: Yeah, I'm on the fence about what's "right" there.
[14:55] <infinity> xnox: Maybe a --no-fail-if-not-vc switch, specifically for use in init jobs.
[14:55] <infinity> xnox: Cause init jobs shouldn't hack around failures with || true, but maybe the tool itself is doing the right thing when run manually.  I dunno.
[14:56] <xnox> infinity, maybe setvtrgb.service should not be wantedby sisinit.target
[14:57] <xnox> but instead be wantedby<EMAIL_ADDRESS>[14:57] <xnox> that way when we have "vt" it gets pulled in
[14:57] <xnox> when we don't, it will not be pulled into boot at all.
[14:57] <infinity> xnox: Isn't getty run on all ttys, not just VCs?
[14:57] <xnox> on s390x i only have serial-getty@* and no<EMAIL_ADDRESS>[14:57] <infinity> xnox: I mean, if it's not, you wouldn't get a prompt on serial. :P
[14:58] <infinity> Oh.  They're different?  Weird.
[14:58] <infinity> Thanks, systemd.
[14:58] <xnox> there is getty.target which consists of getty@ (graphical vgas) and serial-getty@ (for serial thingies)
[14:58] <xnox> getty.target is "catch 'em all"
[14:59] <xnox> let me try that
[15:10] <xnox> infinity, systemd is silly. wantedby<EMAIL_ADDRESS>does not work, because there is always<EMAIL_ADDRESS>units generated by the generator.... with conditionpathexists=/dev/tty0 which means
[15:10] <xnox> pretend we will start these, but then we won't.
[15:10] <xnox> meaning my setrgbvga still gets pulled in
[15:10] <slangasek> ubuntu-server/xenial/powerpc still oversized; infinity were you going to drop the 32-bit kernel from there?
[15:11] <xnox> so i am pondering conditionpathexists=/dev/tty0 to the setvtvga.service
[15:11] <infinity> xnox: FWIW, I'm degraded on a headless PPC install too, unsurprisingly.
[15:11] <infinity> xnox: That might be reasonable.
[15:11] <infinity> xnox: Err, but I have a /dev/tty0 here.
[15:13] <xnox> infinity, and what is $ systemct list-units --all getty*
[15:13] <infinity> slangasek: I'm not sure how I feel about dropping it in a stable series, but time's sort of running out there too.
[15:13] <xnox> infinity, and what is $ systemctl list-units --all getty*
[15:14] <infinity> getty-static.service loaded inactive dead    getty on tty2-tty6 if dbus and logi
[15:14] <infinity><EMAIL_ADDRESS> loaded active   running Getty on tty1
[15:14] <infinity> ● keyboard-setup.service                                                    loaded failed failed    Set console keymap
[15:14] <infinity> getty.target         loaded active   active  Login Prompts
[15:14] <infinity> Oh, so I have a different failure here.
[15:14] <infinity> Hah.
[15:14] <infinity> Thanks, systemd.
[15:14] <xnox> yes
[15:14] <xnox> so colors did load correctly for you =)
[15:14] <xnox> so all is good
[15:14] <infinity> xnox: Though, it's the same code dying. :P
[15:14] <infinity> Jul 20 11:10:17 ubuntu loadkeys[2092]: Couldn't get a file descriptor referring
[15:15] <infinity> SPECIAL.
[15:20] <bdmurray> slangasek: Could you fully phase php7.0 in xenial for nacc?
[15:21] <infinity> xnox: Do you not get loadkeys dying?
[15:21] <infinity> xnox: There might be some weird race where one or the other dies. :)
[15:21] <infinity> xnox: Based on the error message, it looks like it's the same getfd() failure.
[15:21] <xnox> hm?
[15:22] <slangasek> bdmurray: as opposed to overriding the phasing and letting it pick back up automatically?
[15:22] <xnox> i'm complaining about setvtvga.service unit failing
[15:22] <infinity> xnox: Yes, I know.
[15:22] <xnox> which unit you want me to check now? keyboard-setup?
[15:22] <infinity> xnox: But keyboard-setup.service appears to invoke the same codepath.
[15:23] <bdmurray> slangasek: oh, yeah that.  I'll find some more coffee.
[15:23] <xnox> it's not enabled on my machine....
[15:23] <slangasek> bdmurray: ok, ^C'ing the change-override :)
[15:23] <infinity> xnox: Huh.  Kay.
[15:23] <xnox> and on s390x it loads fine
[15:24] <xnox> We are not on the console, the console is left unconfigured.
[15:24] <xnox> ...done
[15:24] <xnox> with exit 0
[15:24] <xnox> also probably should not run
[15:24] <infinity> Oh, FFS.
[15:24] <infinity> I switch from ppc64el to powerpc (EXACT SAME VM), and systemd-modules-load.service fails, while keyboard works.
[15:25] <infinity> I love deterministic boot systems.
[15:25] <xnox> infinity, note the $<EMAIL_ADDRESS>-> so we always try to start tty1, even on headless systems....
[15:26] <infinity> xnox: Yeah.  I'm done talking about this today.  It's making me angry. ;)
[15:26] <infinity> xnox: Let's revisit after the point release is out and see if we can make a variety of hardware all boot green.
[15:26] <infinity> And if not, replace systemd with upstart over the weekend.
[15:26]  * rbasak can see the headlines now
[15:28] <infinity> Daviey: If I'm asking the wrong person about Myth testing, can you pass along the message ASAP? :P
[15:30] <infinity> tgm4883: Oh, it's you I'm meant to be bugging.
[15:30] <xnox> infinity, it's getting too hot in britain again.
[15:30] <xnox> i already have all windows open, turned the hot water boiler off
[15:30] <infinity> xnox: Pretty annoyingly hot in Heidelberg too.
[15:31] <rbasak> xnox: nah, this is nice. Much preferable to the usual.
[15:31] <xnox> and now i'm off to get an ice cream
[15:31] <xnox> hmmm sorbet
[15:31] <infinity> Sorbet isn't ice cream.
[15:31] <infinity> It's a travesty.
[15:32] <tgm4883> infinity: I'm downloading the ISO now
[15:32] <infinity> tgm4883: Yay.
[15:32] <infinity> tgm4883: I assume that's ISOs, plural. ;)
[15:33] <infinity> tgm4883: Based on everyone else's testing so far, I don't expect you to find much to complain about, but at the very least, I need confirmation of boot/install/reboot smoketesting before I'll let you release it. :P
[15:34] <tgm4883> yep, it's a slow download currently :/
[15:38]  * xnox BRAINFREEZE
[16:12] <Daviey> infinity: hey.. superm1 is the project lead.. i'm only loosely involved still
[16:12] <Daviey> infinity: i'll talk with him
[16:14] <infinity> Daviey: tgm4883 is on the case.
[16:15] <Daviey> infinity: hah, i just pinged him aswell
[16:15] <tgm4883> Daviey: I'm the best one to talk to, unless he's changed his mind superm1 is stepping down
[16:17] <Daviey> tgm4883: sad4us
[16:17] <tgm4883> Daviey: true, but hopefully snap packages will work for us and we can drop the ISO
[16:17]  * tgm4883 's goal
[16:18] <infinity> tgm4883: Well, if packages of any sort on top of a base OS "worked for you", you could just give your users a metapackage to install on top of, say, Xubuntu.
[16:18] <infinity> tgm4883: Not sure how snaps change that equation really.
[16:18] <tgm4883> infinity: one way or another, the 16.04.X releases are our last ISOs
[16:18] <infinity> tgm4883: You were LTS-only, right?
[16:19] <infinity> tgm4883: So, yeah, you have 21 months to figure out the next step.
[16:21] <infinity> tgm4883: But if/when you're positive you don't intend to release anything post-16.04.x, lemme know, and we can turn off your dailies and free up some disk space and machine time.
[16:21] <infinity> (your >= yakkety dailies, that is)
[16:23] <tgm4883> infinity: yep, LTS only
[16:23] <tgm4883> infinity: I'm like 99.9% positive. We already have a tool (MCC) that can install what's necessary
[16:24] <tgm4883> infinity: and if our snappy packaging works out, my official stance is "install core, add snap package"
[16:24] <infinity> tgm4883: Speaking of yakkety, you're aware that mythtv is uninstallable in yakkety, right?  (not to detract from your xenial testing)
[16:25] <tgm4883> infinity: no idea. I've not seen any bug reports on that
[16:25] <infinity> tgm4883: It depends on a package that's been removed due to bugginess and lack of porting.
[16:25]  * infinity refreshes his memory.
[16:26] <tgm4883> I'll take a look
[16:27] <jbicha> infinity: the ubuntu-gnome iso build you linked me to adds notification-daemon and libreoffice-style-elementary :(
[16:27] <tgm4883> Can someone refresh my memory on the QA page for marking ISOs as good?
[16:27] <infinity> jbicha: Yeah, I'm still playing.
[16:27] <infinity> tgm4883: The package you depend on is transcode ... https://packages.qa.debian.org/t/transcode/news/20160331T095610Z.html
[16:28] <infinity> tgm4883: And http://iso.qa.ubuntu.com/qatracker/milestones/363/builds for your other question.
[16:28] <infinity> jbicha: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-gnome/+build/69761 might go better.  We'll see.
[16:32] <infinity> jbicha: If this build is good, I can turn around a livecd-rootfs SRU and image rebuild in a couple of hours.  Is that still good enough for you to finish testing, or should we give up the fight?
[16:35] <tgm4883> infinity: done, ISOslooks good
[16:35] <infinity> tgm4883: Shiny, thanks.
[16:35] <infinity> tgm4883: Feel free to help any flavours (other than Canonical ones) that appear to be slacking, if you're feeling helpful.
[16:36] <jbicha> infinity: I think we'll still be able to test in time, let me email our main tester
[16:36] <infinity> jbicha: Well, you have very few results right now on the current images, so either people aren't testing, or they're saving up their results to surprise us. ;)
[16:37] <pitti> infinity: apparently I caught it early enough, https://translations.launchpad.net/ubuntu/trusty/+language-packs has a new trusty export; so I'll build those in the next days; 14.04.x coming up?
[16:37]  * infinity isn't a huge fan of surprises.
[16:37] <sil2100> infinity: as for the address-book-app yakkety blockage - I have a branch ready that will disable the arm64 package builds for anything non-xenial for now
[16:37] <infinity> pitti: Shiny.  14.04.x is in 2wk, so that sounds fresh enough to me.
[16:38] <infinity> 14.04.5, even.
[16:38] <sil2100> infinity: (until we get oxide-qt, webbrowser and then unity8 building properly for arm64)
[16:38] <infinity> sil2100: *nod*
[16:39] <infinity> sil2100: If I find some "spare time" this cycle, I really want to drive the uninstall count to zero on all arches, hence my getting annoyed with people asking to drive it up.
[16:39] <infinity> (Plus, britney has a "feature" where it'll trade uninstallables to create a better overall situation, so every time you add one, you create the possibilty of breaking something else)
[16:40] <infinity> jbicha: Bingo.  That build looks good.
[16:40] <sil2100> infinity: no worries, I noticed the problem when britney in the silo was not happy with it and I was like "oh crap", but published anyway since I'm really desperate to get our xenial arm64 touch builds working
[16:40] <infinity> jbicha: http://paste.ubuntu.com/20196029/
[16:40] <sil2100> Like, really desperate
[16:40] <sil2100> Desperate enough to fix the aftermath later, like, now for instance ;)
[16:40] <infinity> jbicha: So, give me a +1, and I'll SRU that and get the ball rolling.
[16:41] <jbicha> infinity: great, yes I'd prefer a re-spin with that change
[16:42] <infinity> pitti: Quick review on livecd-rootfs, please.
[16:42] <infinity> pitti: Ideally without reading it, because ew.
[16:42] <infinity> pitti: So, y'know, "review".
[16:42] <pitti> ERROR: queue does not have a debdiff
[16:42] <infinity> pitti: This is already tested in a PPA to DTR.
[16:42] <pitti> :)
[16:42] <infinity> T
[16:49] <pitti> infinity: meh, still no diff -- so LOOK BEHIND -- A three headed monkey!
[16:50] <infinity> pitti: YAY MONKEY.
[16:50] <pitti> huh, who did that..
[16:51] <infinity> pitti: I need to do some sprint thing.  If that builds and publishes and you're still around, can you sru-release it for me too?
[16:51] <infinity> pitti: Then I can build jbicha new ISOs when I'm back.
[16:51] <infinity> pitti: Or, if you'll be out, hand the babysitting off to Mr Manager.
[16:51]  * infinity points at slangasek.
[16:52] <pitti> infinity: we are still listening to the town hall, probably still here for 30 mins or so
[16:52] <pitti> infinity: i. e. should be able to copy
[16:52] <infinity> pitti: Ta.
[16:52] <infinity> jbicha: You should have images in probably about 2h.
[16:52] <infinity> jbicha: Roughly.
[16:52] <pitti> set up a build trigger?
[16:53] <infinity> I suppose I could wait-for-package it.
[16:53] <infinity> But that puts undue stress on ftpmaster with the rsync-in-a-loop.
[16:53] <infinity> I'll just come back to my laptop and look in. :P
[16:54] <pitti> already built, so will copy in ~ 20 mins or so when it published
[17:08] <pitti> infinity: done
[17:09] <davmor2> infinity: all the mandatory, all the secondary and 3 of the run once are covered on amd 64 moving onto i386 now
[17:10] <davmor2> no massive issues hit which is good news :)
[17:10] <bzoltan> pitti: sorry to bug you,  have heard that you were pinged about the ppc64el failures of the ubuntu-system-settings-online-accounts<EMAIL_ADDRESS>Could you figure out something?
[17:11] <pitti> bzoltan: no, not yet; on a sprint this week, sorry
[17:11] <davmor2> pitti: give jibel a hug I think he needs it :)
[17:12] <pitti> davmor2: I would love to, but he's not here in Delft :)
[17:12] <davmor2> oh not the snappy sprint then
[17:13] <pitti> no, desktop startup upstart->systemd sprint
[17:15] <pitti> nacc: is bug 1604630 something that needs to be squeezed into 16.04.1? ('cause that sounds pretty much "too late" now)
[17:16] <nacc> pitti: i'm not sure ... it's an annoyance, with a clear workaround
[17:16] <nacc> pitti: it's also unclear to me if it's been broken for some time or not :/
[17:17] <pitti> nacc: I updated the xenial seed and wanted to update the metapackage, but it's in universe; promoting...
[17:17] <pitti> fortunately we have a version in xenial-updates which we can promote :)
[17:17] <bzoltan> pitti:  no worries, do you know anybody who I could turn to?
[17:17] <nacc> pitti: ah yes, sorry, i didn't see that until just now
[17:20] <pitti> bzoltan: I seriously doubt anyone cares about this package on ppc64el, I'd suggest to just ignore the test for now?
[17:21] <bzoltan> pitti: I am in. Who can override or change the tests?
[17:21] <pitti> http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/yakkety/ppc64el/
[17:21] <pitti> it started failing between July 11 and 18, no idea why
[17:22] <pitti> bzoltan: I don't want to force-badtest it, just land the thing; not sure how CI train's overrides work, does the train enforce no regressions?
[17:22] <bzoltan> pitti:  yes, it does.
[17:25] <pitti> bzoltan: I added a hint; let me know if it works (not sure which hints the CI train uses)
[17:25] <pitti> i. e. on next britney run for the silo
[17:31] <bzoltan> pitti:  thanks
[17:57] <camako> The (unrelated) failure we saw during britney run (and was overridden) is preventing my silo from migrating out of proposed (http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#mir)
[17:57] <camako> Can someone help move it along?
[18:00] <camako> robru, ^^ is there a specific person I should ask this to?
[18:01] <robru> camako: whoever is around. Maybe pitti is still here
[18:02] <camako> Oh I see in the scrollback pitti was talking about it ^^
[18:07] <robru> camako: if pitti doesn't respond then slangasek is more timezone appropriate
[18:07] <robru> Brb
[18:07] <camako> thanks robru...
[18:07] <robru> camako: you're welcome
[18:08] <camako> I see this is plaguing a bunch of us, so I guess I'll sit tight
[18:09] <slangasek> robru: so bileto's p-m runs use the main release team hints branch?
[18:10] <slangasek> if so, the hint's been added and should clear on the next p-m run
[18:11] <slangasek> oh, we're talking about yakkety itself here
[18:11] <slangasek> yeah, that will clear on the next run
[18:30] <infinity> slangasek: When jbicha comes back, let him know his images are building. :P
[18:30]  * infinity goes back to drinking all the wine.
[18:30] <tsimonq2> infinity: Lubuntu images are done right?
[18:31]  * tsimonq2 just woke up
[18:31] <infinity> tsimonq2: Built ages ago, not very well tested yet, though.  Please get people on that.
[18:31] <tsimonq2> working on it :)
[18:31] <robru> slangasek: I think so
[18:32] <robru> slangasek: bileto pulls hints from lp:~ubuntu-release/britney/hints-ubuntu
[18:33] <tsimonq2> infinity: wait a minute... not tested?!?!?!? http://pix.toile-libre.org/upload/original/1469039594.png
[18:34] <tsimonq2> infinity: I mean, it's not FULLY tested, but we're working on it :)
[19:15] <infinity> tsimonq2: Last I looked, it wasn't like that.  My apologies. :)
[19:15] <tsimonq2> it's fine :)
[19:15] <davmor2> infinity: i386 first run things are looking okay will finish it up tomorrow
[19:18] <infinity> wxl: Is no one doing Lubuntu PPC testing for 16.04.1?
[19:18] <infinity> wxl: If not, we can just not release those.
[19:18] <wxl> infinity: i try, i try. and yes, i agree.
[19:19] <infinity> jbicha: Your new images are building.  Should be done shortly.
[19:26] <infinity> arges: Erk.  I guess you missed the memo that we're in an RC freeze for xenial, and promoting things to updates is bad. :P
[19:29] <arges> infinity: oh shit
[19:29] <arges> infinity: sorry
[19:31] <jderose> infinity: just catching up on the conversation above, but are you expecting to respin desktop images due to the samba-server/winbind issue?
[19:34] <infinity> jderose: The what?
[19:34]  * infinity scrolls back.
[19:36] <infinity> jderose: Nope, not respinning for that.
[19:37] <jderose> infinity: cool, thanks!
[19:37] <infinity> People installing that task from the server ISO will be SOL, but oh well. :/
[19:39] <infinity> nacc: Should libnss-winbind be included in samba-server as well?
[19:40] <infinity> nacc: Adding libpam-winbind only solves half that bug.
[19:40] <infinity> pitti: ^
[19:42] <nacc> infinity: that's an open question, I tried to clarify that in my SRU bug. the user in question is going to test if libnss-winbind is needed or not, but it's goign to take some time
[19:42] <nacc> infinity: and libnss-winbind has always been in universe, so it'd need a MIR etc.
[19:42] <infinity> nacc: Well, it's needed for one of his usecases (getent passwd foo)
[19:43] <nacc> infinity: ah good point
[19:43] <infinity> nacc: Doesn't need an MIR, it's from the samba source.
[19:43] <infinity> jbicha: ^-- Go sic an army of testers on that.
[19:44] <infinity> arges: I'm going to delete that fuse from updates on the off chance I have to do an emergency respin.
[19:44] <infinity> arges: So don't delete the proposed one. :)
[19:44] <nacc> infinity: ah! ... so in this case, I genuinely don't know if libnss-winbind is "needed" for "samba file server" or not. Is it better to be proactive (given one user's report that it did help them)
[19:44] <arges> infinity: ack
[19:45] <infinity> nacc: Yeah, it's more needed for samba clients, probably.  But that's arguably true of libpam-samba too, which we've always included (under the other name).
[19:45] <infinity> nacc: So... Meh.
[19:45] <infinity> I guess libpam-smbpass also allowed you to change passwords, but do does smbpasswd.
[19:46] <infinity> s/do does/so does/
[19:46] <jbicha> infinity: thanks!
[19:46] <infinity> jbicha: If you get get me quick smoketests ASAP, so I know if we need to respin again, then you can get people on deeper testing.
[19:46] <nacc> infinity: ok, i can send new MRs for yakkety & xenial
[19:47] <infinity> nacc: Also worth noting that we don't have a "samba domain client" task, so "samba server" perhaps covers both halves of "pretend I'm WinNT".
[19:47] <infinity> Though poorly named, if it's that.
[19:48] <nacc> infinity: yeah, i'm realizing that myself as I try to figure this out :)
[20:20] <nacc> infinity: fwiw, updated MRs pushed out (MR: #300661 and MR: #300660)
[20:25] <nacc> pitti: --^
[20:25] <nacc> infinity: thanks for the poke on that
[20:34] <bdmurray> infinity, tjaalton:The reason I'd asked about the xorg lts-xenial packages for trusty is that I'm working on adding HWE support to Trusty and having an xenial kernel w/o x packages didn't go to well for me.
[20:34] <tjaalton> infinity: are you the only one processing NEW?
[20:35] <tjaalton> bdmurray: support for what?
[20:36] <jbicha> infinity: boot/basic install/reboot for UG i386 and amd64 on VBox works
[20:37] <tjaalton> (just curious)
[20:37] <slangasek> tjaalton: the 'hwe-support-status' tool, actually - for tracking info about HWE support
[20:37] <bdmurray> tjaalton: installing a HWE stack that is supported for a longer period of time e.g. installing the xenial stack instead of vivid.
[20:37] <slangasek> (and facilitating upgrades)
[20:38] <tjaalton> ah, ok
[20:39] <tjaalton> well, proposed has then and my testing shows they upgrade fine, now the image needs to be tested when it's available
[20:39] <bdmurray> tjaalton: when I mentioned it yesterday infinity didn't seem to know that they upgrade fine
[20:40] <tjaalton> bdmurray: he also didn'tknow the daily image didn't have them :)
[20:41] <infinity> Yeah.  Derp.
[20:41] <infinity> I'll fix that ASAP when 16.04.1's out.
[20:41] <infinity> Or tomorrow, while I'm waiting on mirrors, if the sprint isn't all-consuming.
[20:45] <tjaalton> it involves more than just pulling a trigger?
[20:46] <slangasek> getting the lts stack into the image requires changes to a couple of the infra packages, so that they look for the right package names
[20:48] <tjaalton> ok, well i should have two hours on friday to test it while waiting for my connecting flight. if the image is available by then
[20:49] <tjaalton> or i'll ask Sarvatt to test :)
[21:01] <infinity> The changes to livecd-rootfs for the package names are trivial, it's the subsequent testing of how that perturbed the install set that takes a tiny bit of time.
[21:01] <infinity> And then fixing bugs that arise from that can take longer (but hopefully there are none)
[21:01] <infinity> But I'll spin up a ton of test livefses in my PPA tomorrow, where the livecd-rootfs change has been sitting. :/
[21:01] <infinity> And checn results.
[21:01] <infinity> check, too.
[21:01] <infinity> tjaalton, slangasek ^
[21:02]  * slangasek nods
[21:04] <tjaalton> ok, cool
[22:22] <balloons> so I used to know where to check and see what's broken in the archive, but it's lost on me now. Can anyone give help or insight into fixing yakkety for these golang-* depends? the powerpc build completed, but the rest claim the golang-* depends can't be installed: https://launchpad.net/ubuntu/+source/juju-core/2.0~beta12-0ubuntu<IP_ADDRESS>/
[22:23] <balloons> I can build against yakkety, so it must be something in proposed. I'll have to get a local build using it to see
[22:32] <slangasek> balloons: you can use porter-powerpc.canonical.com to try to figure it out; but in general it's going to be a problem caused by powerpc being our lone gccgo-only architecture
[22:33] <balloons> slangasek, in this case powerpc built fine -- everything else did not. It was able to grab the dependencies the other builds are complaining are uninstallable.
[22:33] <slangasek> balloons: it also appears that powerpc is the only architecture having a *newer* version of juju-2.0 in yakkety-proposed, so... wat?
[22:33] <slangasek>  juju-2.0       | 2.0~beta12-0ubuntu<IP_ADDRESS> | yakkety-proposed        | amd64, arm64, armhf, i386, ppc64el, s390x
[22:33] <slangasek>  juju-2.0       | 2.0~beta12-0ubuntu<IP_ADDRESS> | yakkety-proposed        | powerpc
[22:34] <balloons> slangasek, right.. the rest failed to build the new version.
[22:34] <balloons> I want 2.0~beta12-0ubuntu<IP_ADDRESS> to build, as the previous upload has an adt failure. 2.0~beta12-0ubuntu<IP_ADDRESS> should land properly
[22:35] <balloons> see for example "The following packages have unmet dependencies:" in https://launchpadlibrarian.net/274157286/buildlog_ubuntu-yakkety-amd64.juju-core_2.0~beta12-0ubuntu<IP_ADDRESS>_BUILDING.txt.gz
[22:35] <slangasek> oh, I see, powerpc was the *only* one that built
[22:36] <slangasek> I thought that was the one that wanted debugging, sorry
[22:37] <mwhudson> uh oh is this my fault
[22:37] <mwhudson> ah yes
[22:38] <slangasek> balloons: so anyway, you'll definitely need to check with -proposed enabled... in general.  or you can just blame mwhudson ;
[22:38] <slangasek> )
[22:38] <mwhudson> oh duuuh go 1.6.3 will have broken abi
[22:39] <mwhudson> (because the version number ends up being part of the abi, i really need to Do Something about that)
[22:39] <mwhudson> some no-change rebuilds coming up
[22:40] <balloons> mwhudson, I saw the new go version, but I honestly assumed you wouldn't upload something broken ;-)
[22:40] <mwhudson> it's not broken but the rdeps need rebuilding
[22:42] <balloons> and yea, slangasek, lol, given the fact ONLY ppc built I knew something was up :-)
[22:47] <mwhudson> uh so transitions
[23:30] <xnox> mwhudson, having URLs as ABI is bad enough, but they have version numbers too... how un-go to have any sort of ABI versioning =)
[23:31] <mwhudson> xnox: well it's all my fault


[08:51] <rbasak> apw, cking: I'm confused. https://launchpad.net/ubuntu/+source/zfs-linux/<IP_ADDRESS>-5ubuntu5 doesn't appear in https://launchpad.net/~colin-king/+uploaded-packages and doesn't appear to have needed sponsorship. What am I missing?
[08:59] <apw> rbasak, could it have been a sync into -proposed from cking's ppa and then when its been copied again that is lost ?
[09:00] <apw> rbasak, as to why its not on his +uploaded-packages ...
[09:01] <apw> rbasak, i wonder if those are the first ones since the buildinfo
[09:02] <apw> rbasak, or indeed if artful is missing from that list
[09:02] <apw> (+uploaded-packages)
[09:05] <apw> rbasak, ok that artful zfs is listed under _my_ sync's.  iirc that was the first upload he did which had .buildinfo included
[09:05] <rbasak> apw: ah, yes, thanks. https://launchpad.net/ubuntu/+source/zfs-linux/<IP_ADDRESS>-5ubuntu5/+publishinghistory
[09:05] <apw> rbasak, and that meant i could not sponsor it as an upload (he test builds them in a PPA) so i copied it out of the PPA
[09:06] <apw> there begin a bug in that pull-lp-source does not get .buildinfo
[09:07] <rbasak> Not relevant to my reason for asking, but I'm curious as to why buildinfo gets in the way here. Why could you not sponsor it as an upload?
[09:15] <dupondje_> I got some gzip issues in Tomcat. But after downgrading zlib1g it works again. Is there somebody with some experience in this? :D
[11:38] <dupondje_> xnox: happen to be around?
[11:38] <xnox> dupondje_, sure
[11:39] <dupondje_> I upgraded my system recently to 17.04. And was having an issue with my 'UniFi' controller. Seems like gzip compression in the build-in tomcat was broken. "curl: (23) Error while processing content unencoding: invalid code lengths set"
[11:39] <dupondje_> Now I was able to pinpoint it, and the following commit fixes my issue: https://github.com/madler/zlib/commit/f9694097dd69354b03cb8af959094c7f260db0a1.patch
[11:40] <dupondje_> I don't see any other bugreports, so it must be some edge case I guess. But would an SRU be possible for this you think?
[11:41] <xnox> dupondje_, yes, please open a bug report.
[11:41] <dupondje_> the SRU style kinda bug report? :)
[11:49] <dupondje_> xnox: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1692870
[11:52] <xnox> dupondje_, if you could update the bug description to follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template that would be awesome
[11:52] <xnox> dupondje_, specifically how to reproduce the problem/bug would be very useful. As I am not familiar with tomcat.
[11:57] <dupondje_> adjusted
[12:00] <dupondje_> Thing is I didn't had time to test if tomcat is affected somehow. But as the UniFi guest portal is using tomcat in the background, and relies on java (which uses the zlib). I guess it will (in some cases)
[15:45] <mdeslaur> kees, infinity, stgraber, slangasek: tech board meeting in 15 minutes
[15:45]  * slangasek nods
[15:57] <ddstreet> stgraber sorry to bug you, but i noticed you've done a few sponsor uploads for the ifupdown and vlan pkgs, could you review and/or sponsor bug 1573272 if you have a chance?
[16:17] <slangasek> kees: now why are bindnow numbers still so low?
[16:27] <kees> slangasek: those aren't benefited from the generous PIE logic. i.e. bindnow is only detected on executables with it set
[16:28] <kees> slangasek: so, 50% of source packages have a PIE executable (with bindnow), and 80% of source packages lack an ET_EXEC (i.e. not not PIE)
[16:29] <kees> (does that make sense?)
[16:33] <slangasek> kees: so you're saying the heuristic is lowballing?
[16:35] <slangasek> rbalint: hi, so when PIE was turned on in Debian, did you do anything systematically with static linking?
[16:36] <slangasek> rbalint: thinking about how we might do this more cleanly this time around, since when we turned it on for amd64 we spent a long time chasing opaque build failures.
[16:39] <rbalint> slangasek: i tracked down every issue, and finally the solution was recompiling the static libs with PIE
[16:39] <rbalint> they don't need to be PIC, PIE is enough
[16:39] <slangasek> rbalint: so what I'm wondering is if we shouldn't analyze the archive for "-dev build-deps that don't produce shared lib runtime deps", do build tests of those packages, confirm they FTBFS, rebuild the build deps, rebuild the dependent packages, confirm it fixes the FTBFS
[16:41] <rbalint> yes, this would be the way to go archive-wide IMO
[16:41] <slangasek> rbalint: ok.  would you like to drive this? :)
[16:41] <slangasek> rbalint: I'm interested in making sure that we fix these build failures early so that developers don't trip on them
[16:42] <rbalint> slangasek: sure :-)
[16:46] <slangasek> cool
[16:46] <slangasek> rbalint: to be clear, we would want this analysis across all of main and universe
[16:48] <rbalint> slangasek: sure, it was my understanding, too
[17:35] <nacc> cyphermox: would you happen to have any insight into LP: #1688018 or LP: #1682227 ?
[17:37] <cyphermox> not sure the second is accurate, would need to dig in more about the first...
[17:51] <cyphermox> nacc: too many people with unrelated issues touching these bugs, some are about VPN and network interfaces, other about suspend/resume behavior, and others about $somethingelse
[17:51] <nacc> cyphermox: yeah, me neither yet
[17:52] <nacc> cyphermox: right, so there are (i think) two classes of bugs, as you noted
[17:52] <nacc> s/r is supposedly fixed (or is confirmed fixed for many users)
[17:52] <nacc> the dns 'leak' is a separate bug
[17:52] <nacc> *class
[17:52] <cyphermox> yes, suspend resume is probably fixed.
[17:52] <nacc> i agree they are all really noisy :)
[17:53] <nacc> rbasak: LP: #1573624, not sure if you've seen that last comment?
[17:53] <cyphermox> yeah... well it's a "common problem" and people don't usually have the esoteric knowledge of DNS in the context of VPNs
[17:53] <nacc> cyphermox: right
[17:54] <cyphermox> I have no idea why some of these have been marked as duplicate when they pretty obviously look like not
[17:55] <rbasak> nacc: that comment sounds like bug 1592669
[17:55] <rbasak> nacc: I'll comment
[17:55] <nacc> cyphermox: yeah, the s/r bug that is fix-released had a crazy number of dupes, i'm not sure where they all came from
[17:55] <nacc> rbasak: yep, thanks!
[17:56] <cyphermox> nacc: so first step would be to make sure dnsmasq indeed has the requisite fixes, so at least we know we don't need to look at suspend/resume too much
[17:56] <cyphermox> (I'm doing this, just including the running commentary)
[17:57] <cyphermox> err, why is this done without patches?
[17:59] <nacc> cyphermox: dnsmasq is a 1.0 source format pkg
[17:59] <nacc> iirc
[17:59] <cyphermox> doesn't matter, we still do patches for that?
[17:59] <cyphermox> (usually anyway)
[18:00] <cyphermox> it doesn't matter, it's just yucky
[18:01] <nacc> cyphermox: maybe i am misunderstanding, but i thought a 1.0 source package was an orig tarball plus a diff tarball (a single patch to apply aiui)
[18:04] <nacc> cpaelzer: would you be able to respond to LP: #1540692 from a qemu perspective?
[18:04] <nacc> cpaelzer: i'm guessing we're just following debian's lead, but would like confirmation
[18:06] <cyphermox> nacc, you can still use a patching tool like quilt for 1.0 format packages; it only needs a bit of configuration
[18:07] <nacc> cyphermox: ah ok, i guess maybe it's not available by default and the tool i usually use (e.g., `dpkg-source --commit`) just says "no" :)
[18:07] <nacc> *not configured by default
[18:09] <cyphermox> nacc: in any case, looks like dnsmasq is up to par (at least AFAICT), so focusing on the VPN situation...
[18:10] <nacc> cyphermox: ok
[18:37] <nacc> cyphermox: here is another possibly related (with a specific missing connection between NM and openvpn being claimed): LP: #1686252
[18:37] <nacc> the 'repeatedly tell OpenVPN to connect' seems similar
[18:41] <cyphermox> no, that's something different
[18:45] <nacc> cyphermox: ok :)
[18:49] <nacc> rbasak: it appears that perhaps this is a real bug: LP: #1688068 ?
[18:51] <nacc> sarnold: for something like LP: #1687930 which is really just a report of https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-8779.html, what does the security team usually do with such bugs?
[18:52] <sarnold> nacc: we normally mark it confimred, public security, and add the bug to the UCT entry so we stand a chance of closing the bug when updates are issued
[18:53] <nacc> sarnold: ok, are you able to do that for this bug? i can do the first part, not sure if i have permissions to do the second
[18:53] <sarnold> nacc: of course if it's in universe we add the usual "this package is community-supported, please provide debdiffs" etc etc
[18:54] <nacc> sarnold: right
[18:54] <sarnold> nacc: heh yeah, it's not worth figuring out how to do merges in bzr to add one line to the file :) hehe
[18:55] <nacc> sarnold: thanks!
[19:09] <cpaelzer> nacc: done on the qemu bug
[19:10] <cpaelzer> nacc: it is not only debians lead, but also component mismatch and full of CVEs recently
[19:10] <cpaelzer> nacc: I wrote it in the bug to be clear with the reporter
[20:07] <nacc> cpaelzer: thanks!
[20:59] <bdmurray> What would I use on Lubuntu and Xubuntu that is equivalent to gnome-session-quit?
[21:00] <wxl> it's via lxsession if memory serves correctly
[21:00] <wxl> (for lubuntu)
[21:06] <nacc> cpaelzer: fwiw, re: c#2.6 in LP: #1686679, the Author should be the patch's author, not the backporter's.
[21:11] <bdmurray> wxl: Is there anyway you could confirm that for me so I can fix a software-properties bug?
[21:12] <Unit193> What precisely does gnome-session-quit do?
[21:14] <bdmurray> gnome-session-quit - End the current GNOME session
[21:14] <bdmurray> There's a reboot button in software-properties-gtk that I'm guessing doesn't do anything on Lubuntu or Xubuntu.
[21:15] <Unit193> xfce4-session-logout --reboot
[21:15] <bdmurray> Unit193: will there be a prompt too?
[21:15] <Unit193> If you want that, drop '--reboot'
[21:16] <wxl> i'm on kubuntu right now and plasma ain't behaving for me. once i get it going again i'll open a vm for you, bdmurray
[21:17] <bdmurray> wxl: cool, thanks
[21:17] <bdmurray> Unit193: Thanks
[21:20] <wxl> lxsession-logout
[21:21] <Unit193> bdmurray: Sure thing!
[21:21] <bdmurray> wxl: I've put this issue in bug 1693038 since it might be worth SRU'ing.
[21:22] <wxl> bdmurray: if you subscribe lubuntu packages team, we'll notice :)
[21:30] <nacc> rbasak: https://launchpadlibrarian.net/318686604/HookError_source_mysql_5.7.txt from LP: #1689015 appears to be a bug in the mysql apport hook?
[21:32] <bdmurray> nacc: For sure with the 2nd traceback
[21:33] <nacc> bdmurray: yep
[21:35] <bdmurray> nacc: At least in zesty there is try except for the other one
[21:35] <nacc> bdmurray: ah ok, good to know
[21:43] <rbasak> nacc, bdmurray: I suspect the user has replaced /usr/bin/python with python 3.
[21:43] <rbasak> We should have apport pick up on that and have a bug pattern on it.
[21:45] <bdmurray> rbasak: Why do you suspect that in that bug? Also re apport bug 1681528.
[21:45] <rbasak> bdmurray: I'd need to check, but https://launchpadlibrarian.net/318686604/HookError_source_mysql_5.7.txt and I don't think that the hook has been converted to Python 3. So I wouldn't expect that error. Also I've seen users do this before, IIRC wrt. mysql.
[21:46] <rbasak> I could be wrong. Just a hunch.
[21:53] <nacc> rbasak: yeah there was another bug that i triaged today with  that issue (they eventually get a backtrace about ConfigParser, which is now configparser in python3)
[21:56] <bdmurray> rbasak: running python3 /usr/share/apport/package-hooks/source_mysql-5.7.py or python  /usr/share/apport/package-hooks/source_mysql-5.7.py works for me on a xenial system
[21:56] <rbasak> bdmurray: could it be an edge case?
[21:56] <rbasak> bdmurray: what does the shebang say?
[21:56] <bdmurray> rbasak: there is no shebang in it
[21:58] <rbasak> bdmurray: http://paste.ubuntu.com/24637495/
[21:58] <rbasak> This is why I think it's a 2 vs 3 thing.
[22:00] <rbasak> bdmurray: so I don't know how he's got things running under Python 3, but I'm pretty sure the hook was not written to target 3.
[22:01] <rbasak> We can fix it of course.
[22:01] <rbasak> We should update it to work on both at a minimum. And perhaps there's a dependency that's not being declared.
[22:01] <rbasak> Or, perhaps it's an edge case code path that we haven't noticed and is always buggy since something in apport was deliberately switched to use 3.
[22:02]  * rbasak EODs
[22:03] <bdmurray> python3-apport is seeded and apport just uses all the stuff in /usr/share/apport/package-hooks/
[22:03] <bdmurray> The point being I don't think the user did anything wrong but that the hook needs updating.


[00:00]  * paultag o.O
[00:00] <skellat> The thing to ponder as we continue June is reaching out to others who may be out of reach or who we might not have heard from recently such as jandrusk
[00:01] <skellat> Folks who have cut all electronic communications ties should still be made welcome and should be encouraged to re-engage
[00:02] <skellat> Though I do seem to trigger plenty of deactivations every time I send a "Contact Team" e-mail :-\
[00:02] <Unit193> Yeah, that one is a bit more annoying than something on the mailing list.
[00:02] <skellat> Yeah
[00:03] <skellat> Somehow we have 420+ members and that's the only way to reach all of them
[00:03] <skellat> From my end in Ashtabula all I can do is cajole, suggest, prod, and ask to welcome others around the state and ask why they've disengaged
[00:04] <skellat> I'm not prepared to go as far as Jono Bacon and post my cell phone number openly for people to call to talk to
[00:04] <skellat> But
[00:04] <skellat> I am fairly reachable
[00:04] <skellat> And if you need second-tier/back-end help reaching out to others I'll do what I can
[00:05] <skellat> Do we have any other discussion for Item #3
[00:05] <skellat> ?
[00:06] <skellat> Nothing being heard, we move on to Item #4 -- Any Other Business where we start off with that phone call I had with Jono Bacon earlier today
[00:06] <skellat> Jono and I talked about the Ars Technica article I linked at the beginning of the meeting where the Carrier Advisory Group was announced for the Ubuntu Phone project
[00:07] <skellat> Some folks noted on Google Plus that US carriers were conspicuously absent
[00:07] <skellat> For the time being, nothing is blocking them from joining if they choose on their own initiative
[00:08] <skellat> At this stage in the development of Ubuntu Phone, it looks like what will be ready by October will class more as a "Feature Phone" instead of a "Smartphone" in terms of what will ship.  This is akin to having something ship with Symbian S40 instead of iOS.
[00:09] <skellat> The approach being taken is to pursue "emerging markets" in lieu of trying to start in the United States.
[00:09] <skellat> From a business perspective, it makes far more sense to pursue markets other than the United States and Canada first.
[00:09] <skellat> Essentially, based upon my experience selling wireless devices, it should be remembered that nobody else on this planet we share sells cell phones the way we do in the United States and Canada
[00:10] <skellat> The way we do it is a distinctly minority business model compared to the planet at-large.  Heck, GSM is the dominant global standard while CDMA is something peculiar to the US & Canada as well as 31 smaller jurisdictions.
[00:11] <skellat> So, at the macro level...the time has not come yet for us to see consumer-level roll out of Ubuntu Phone in the US
[00:11] <skellat> It is coming
[00:11] <skellat> But it isn't our time yet
[00:11] <skellat> Okay, that sums up my discussion with Jono.  What do you all think?
[00:13] <skellat> Going once...
[00:13] <drkokandy> not surprising that it's not coming to the US first
[00:15] <jrgifford> skellat: unrelated note going back to the previous item: if you want a SIP line that acts like a phone, I can get you one easily enough.
[00:15] <skellat> jrgifford: Not yet
[00:15] <jrgifford> skellat: its like, $5/month. Just let me know. :)
[00:16] <skellat> As I said to Mr. Bacon when we talked earlier, I'm willing to wait to pay for a phone.  If a GSM version is ready for the US market I may just bypass a subsidy contract and try to buy one outright.
[00:17] <skellat> Okay.  Is there any other discussion on the Ubuntu Phone item?  Is there any other business to come before the meeting tonight?
[00:17] <Unit193> I'm not interested in it at all, I don't have an electric slave driver right now, but Android or Mozilla look more interesting right now anyway.
[00:17] <jrgifford> I've played with the phone preview on my nexus 7.
[00:18] <jrgifford> Haven't tried on the phone, I rely on it too much.
[00:18] <jrgifford> Overall, it needs work, but its not bad.
[00:18] <jrgifford> Battery life is much better, at least on the tablet
[00:19] <skellat> I had an HTC Thunderbolt for 30 days and dumped Android plus the phone as I just got annoyed with it.  The touch screen really annoyed me.  My aunt's iPhone has an easier touch screen to use.
[00:19] <jrgifford> Probably because it doesn't have push notifications yet.
[00:20] <skellat> Perhaps
[00:20] <skellat> Is there any other business to come before the meeting tonight?
[00:20] <jrgifford> Anyway, that's what I've got on the subject.
[00:21] <jrgifford> None here
[00:21] <skellat> Item #5 -- Fix The Date For The Next Meeting.  What is our pleasure for a date in July to hold our next meeting?
[00:23] <skellat> My calendar remains clear since I remain unemployed and one layer or another of the Department of Job & Family Services has blocked my attempt at going back to school.  I could have started in a master's program with Ashland but that is blocked at this time.
[00:24] <skellat> Four weeks from today will put us at July 16th
[00:24] <jrgifford> I've got the third week of July booked period, but other than that I can do what ever
[00:24] <jrgifford> The 16th looks good
[00:24] <skellat> Unit193, drkokandy: How say you?
[00:25] <drkokandy> I might be a little distracted, but I can be here
[00:25] <skellat> Okay
[00:25] <Unit193> We'll see.
[00:26] <skellat> I'll mark it as tentative and send out a Doodle poll when we get closer.
[00:26] <skellat> Item #6 -- Potpourri
[00:26] <skellat> Bad weather happens at this time of year
[00:26] <skellat> Cleveland-area television went wall-to-wall with tornado coverage not that long ago
[00:27] <skellat> If you're interested in watching Ohio weather warnings and alerts you can join ##weather-us-oh to see such on IRC
[00:27] <skellat> NOAA Weather Radio is a nice non-Internet way to keep track of such too: http://www.nws.noaa.gov/nwr/
[00:27] <jenni> [ NOAA Weather Radio ] - http://j.mp/12TYwfw
[00:27] <skellat> And there is a FAQ about that taxpayer-paid service: http://www.nws.noaa.gov/nwr/faq.htm
[00:27] <jenni> [ NOAA Weather Radio ] - http://j.mp/12TYxjD
[00:28] <skellat> FEMA has a guide up with disaster assistance materials specifically for Ohio: http://www.fema.gov/states/ohio
[00:28] <jenni> [ Ohio | FEMA.gov ] - http://j.mp/12TYB2O
[00:28] <skellat> There is the citizen's awareness to disaster assistance course that you can pursue at your own pace: http://training.fema.gov/EMIWeb/IS/courseOverview.aspx?code=IS-7
[00:28] <jenni> [ IS-7: A Citizen's Guide to Disaster Assistance | FEMA - Emergency Management Institute (EMI) Course ] - http://j.mp/12TYCUl
[00:29] <skellat> And we're looking at Lightning Awareness Week coming up next week here in the state of Ohio: http://www.nws.noaa.gov/om/severeweather/severewxcal.shtml
[00:29] <jenni> [ Severe Weather Events Calendar ] - http://j.mp/12TYEf4
[00:29] <skellat> Ars Technica had a recent story about one of their editors being struck by lightning
[00:29] <skellat> It did bad things to him
[00:29] <skellat> Imagine what it can do to your computer
[00:29] <skellat> And remember, lightning damage is OS-agnostic
[00:29] <Unit193> That's why I took mine off the roof!
[00:29] <skellat> :-)
[00:30] <paultag> skellat: twice, actually!
[00:30] <skellat> Thank you for attending the June 2013 Business Meeting.  The log will be posted later tonight to the wiki and announced not only on the mailing list but also Planet Ubuntu.
[00:30] <skellat> Thank you guys!
[00:31]  * skellat realizes he blew way past his original time estimate but kept it within an hour
[00:32] <Unit193> drkokandy: Have you been wanting to do something locally?
[00:34] <drkokandy> hmm, we could if you're interested in trying to put something together
[00:34] <drkokandy> would you be thinking about another Ubuntu Hour type event or something different?
[00:34] <Unit193> Well, was wondering if you were itching for one, I was and am the least social of us. :P
[00:36] <drkokandy> so if it ends up being just the two of us it would be a pretty quiet event I guess. I don't know that I'd say I'm itching for one - I've been busier than usual this summer
[00:37] <drkokandy> But if you
[00:39] <drkokandy> * you're itching for something like that, just let me know what nights work for you and I should be able to reorganize things to swing down to Mansfield/Ontario for an Ubuntu Hour thing
[00:41] <Unit193> Heh, fun.  Yep, would be nice and awkwardly silent. :D
[02:25] <Unit193> srandby: Hello!
[02:26] <srandby> Hello


 @jubo2, Mailspring us best! I just tried Kube again. Accounts will not set up. I will be giving kmail another shot this weekend as integration with the pim suit would be welcomed.
 I'm using kde and installed ffmpegthumbnailer or something similar package.  In dolphin i click the preview button and I still have no joy of video previews
 any idea why?
 I heard there were improvements for nvidia in 18.10, so I switched from intel to nvidia and rebooted. No. Still graphical glitches. 😫
[03:25] <valorie> hmmm, I found it improved in 18.10
[03:26] <valorie> I also use nvidia
[03:26] <valorie> illuminated: I'll try that and see
 Well, maybe I am doing something wrong, but my Dell Precision 5520 (which came with Linux) does not like nvidia! 🙁
[03:29] <valorie> how did you install it?
[03:29] <valorie> I used what systemsettings advised
 Yes, I used the settings Driver Manager.
[03:31] <illuminated> valorie: I got it.. ctrl-m to open up menu bar:  settings -> configure dolphin -> General -> Previews -> video files (ffmpegthumbs)
[03:33] <valorie> oh cool
[03:33] <valorie> well, my vid folder was empty so I'm repopulating it
[03:33] <valorie> yay for backups!
[03:46] <valorie> illuminated: yup, works for me too!
[03:57] <illuminated> awesome
[03:57] <illuminated> I've only been using linux about 3 weeks
[04:06] <illuminated> i've used some form of posix for years, but only in a server environment.  Not used to linux on the desktop yet, but not unfamiliar with linux generally
[04:18] <illuminated> https://raymii.org/s/articles/The_awesomely_epic_guide_to_KDE.html
[04:19] <illuminated> not exactly comprehensive but has some great info
[05:17] <valorie> that is rather old!
[05:41] <illuminated> well, maybe so, but for a person that's only been using plasma for a few weeks, it's kinda helpful
[11:45] <BluesKaj> Hi folks
[11:50] <Alexfrench> hi
[12:32] <Mrokii> Hello. With kPartition manager, can I resize a partition without losing its data? Or will the data be lost with resizing a partition?
[12:33] <Mrokii> I mean kde partition manager
[12:34] <BluesKaj> Mrokii, as long as you don't make the partition smaller than the amount of space the data uses, and mounted partitions like the one you're using can't be resized of course.
[12:36] <BluesKaj> unless you use a live media partition manager like gparted
[12:37] <Mrokii> BluesKaj: thanks.
[12:38] <BluesKaj> Mrokii, yw
[12:38] <Mrokii> BluesKaj: Did I understand that correctly, that gparted allows resizing of mounted partitions? That sounds dangerous.
[12:39] <BluesKaj> no, it means gparted on a cd or usb can resize any hdd or ssd partitions not in use, you just need to unmount them first
[12:40] <Mrokii> BluesKaj: Ah yes, okay. That's what I thought. Thanks again. :)
[12:40] <BluesKaj> your welcome , Mrokii :-)
 Hi
 i installed kubuntu 18.04
 And i cant install new themes
 did you have the same problem?
 WiFi doesn't work for me on Macbook Air Early 2015, I installed additional driver from Driver management
 (Photo, 656x212) https://irc-attachments.kde.org/Jug5ue05/file_10594.jpg
 nvm, this fixed the issue
 Fwd from M1kaela: and to your WLAN problem, my quick investigation (without being in front of the device or having direct feeling/experience, with being sleep deprived etc. so with your own responsibility) … 1. `sudo apt-get remove bcmwl-kernel-source` … 2. `sudo apt-get install broadcom-sta-dkms` … Sources that would make me to do this in your place: … 1. Googling for your drivers and DKMS
 1. sudo apt-get remove bcmwl-kernel-source … 2. sudo apt-get install broadcom-sta-dkms … Sources that would make me to do this in your place: … 1. Googling for your drivers and DKMS https://packages.ubuntu.com/bionic/bcmwl-kernel-source … 2. Ending up to https://askubuntu.com/a/978626 … 3. And there getting linked to https://wiki.debian.org/wl
[20:21] <JMichaelX> are there any known issues with in 18.04 with finding network printers?
[20:23] <valorie> JMichaelX: I never had any..... on cosmic now so can't test
[20:34] <JMichaelX> valorie: ty. just attempted to install an HP printer on an Ubuntu 16.04 server, and cannot connect to it from Kubuntu 18.04
[20:34] <valorie> does it not see the printer, or what?
[20:35] <valorie> !printer
[20:35] <JMichaelX> neither printer setting utility, nor cups accessed via browser is seeing it
[20:35] <valorie> might be something in those links ^
[20:35] <valorie> oh, that sucks
[20:35] <valorie> not all printers will play well with linux
[20:36] <valorie> I guess you could google about your particular printer and see?
[20:36] <JMichaelX> this one had played sort of decently in the past. had been using it connected to a 1st gen rspberry pi
[20:36] <valorie> huh
[20:36] <JMichaelX> i may have to go back to th at
[20:36] <JMichaelX> that*
[20:37] <valorie> I"m not aware of anything changing but .... dunno


[01:03] <smoser> tych0: \o/
[04:53] <cpaelzer> good morning
[06:27] <lordievader> Good morning
[15:02] <jrwren> using this filter: 'google us-east1 20180920' on https://cloud-images.ubuntu.com/locator/daily/ I can see that I should use daily-ubuntu-1804-bionic-v20180920 as my image name in GCE, but what is the name of the ubuntu image-project in GCE?
[19:19] <fdelgado> Hi people!
[19:23] <fdelgado> Some of you knows where to download a good manual for linux?
[19:25] <sarnold> fdelgado: the server guides have downloadable PDFs https://help.ubuntu.com/
[19:55] <genii> For general linux knowledge, the Linux Documentation Project is also a good resource. https://www.tldp.org/
[20:04] <Futurian> The server guides are exceptional in my opinion..
[20:07] <jrwren> i agree. Ubuntu Server Guide is a treasure.
[20:32] <guardian> hello, I'm surprised I install ubuntu server but it didn't ask nor configure the timezone
[20:32] <guardian> is it expected?
[20:39] <guardian> can this be caused by having no DHCP on the VLAN from which I intalled ubuntu server?
[20:40] <jrwren> most servers run configured to UTC, so I would guess that it is by design.
[20:45] <guardian> k
[20:45] <guardian> then I've things to learn
[20:45] <guardian> why are they configured to UTC?
[20:47] <maxh> Does anyone know if OpenSSL 1.1.1 will be in Cosmic? (Or, more specifically, if TLS 1.3 will be supported?)
[20:56] <sdeziel> maxh: it will as it's in -proposed already
[20:57] <sdeziel> maxh: I've also heard that it would eventually be backported to Bionic for TLS 1.3 enablement :)
[21:03] <maxh> Excellent! :D
[22:08] <sarnold> ahasenack: congratulations :)
[23:24] <ahasenack> sarnold: thanks! :)


[09:55] <Stralytic> where can i find out what the mid img installer installs?
[10:00] <persia> Stralytic, It's basically the same as the ubuntu-mid metapackage.  `apt-cache show ubuntu-mid` provides a basic outline.  There's also a manifest on cdimage that has the details.
[10:02] <Stralytic> great, thankyou
[10:04] <Stralytic> this might sound like a dumb question, but is there a way to change the architecture of an existing i386 system to lpia?
[17:14] <johan> hi, I'd like to setup a lpia chroot on my workstation (i386), is there an easy way to do so using pre-built cd images or debootstrap?
[18:11] <tunk_> I installed Ubuntu and the UNR packages!
[18:12] <tunk_> However, when I run the launcher and maximus, some of the icons which were in the top and bottom icon bars flicker when they change state (e.g. a signal strength meter for the wifi). Has anyone else seen this?
[18:14] <tunk_> oh, its compiz.
[18:17] <ogra> compiz and UNR dont work together, you need to use metacity
[18:23] <tunk_> thanks ogra
[18:33] <tunk_> it looks really nice
[18:33] <tunk_> i just showed it off to a mate at work
[18:33] <tunk_> :)
[18:37] <tunk_> THIS IS SO SWEET
[18:37] <tunk_> I LOVE YOU GUYS
[18:38] <ogra> :)
[18:39] <tunk> do you work on this UNR ogra
[18:39] <tunk> its so much better than linpus i almost want to cry
[18:39] <ogra> only very remotely ... StevenK included it into the main distro for jaunty and many other people in here did the work on the apps
[18:40] <ogra> tunk, tell that to bfiller, he will love to hear that (he leads the team working on it and surely likes getting flowers ;) )
[18:41] <tunk> which country does he live in?
[18:41] <ogra> US
[18:51] <bfiller> ogra, tunk : thank you :)
[20:11] <tunk> i think i love UNR
[20:11] <tunk> this is pretty much how i've always wanted my computer to look
[20:11] <bow^znc> it does work pretty well
[20:12] <tunk> it feels so much more natural
[20:12] <tunk> and it sticks the icons at the top, very small, so you still have complete control
[20:12] <tunk> it doesnt make sense to use a netbook like a laptop, but this is great
[20:13] <bow^znc> agreed
[20:13] <bow^znc> conventional desktops on netbooks partly defeats the purpose
[20:14] <tunk> yeah
[20:14] <tunk> when ubuntu came up i felt comfortable
[20:14] <tunk> but this is just very natural
[20:14] <tunk> tabbed interface means you can have nice big fonts, or whatever
[20:14] <tunk> i'm gushing a bit atm arent i ?
[20:14] <tunk> ;)
[20:15] <bow^znc> I've used it since the eee 900 came out
[20:16] <bow^znc> no real problems
[21:42] <tunk> Guys do you know how to switch between tabs (each 'tab' being an app) in ubuntu netbook remix? Checked a few obvious places and its not there