| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| tsimonq2 | wxl: can we sign lubuntu-devel or lubuntu-admins up? :) | 00:08 |
| 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:09 |
| 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:10 |
| tsimonq2 | I mean, with the logs? | 00:11 |
| slangasek | yes | 00:11 |
| tsimonq2 | slangasek: could you just forward me today's email? tsimonq2@ubuntu.com | 00:11 |
| 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:12 |
| 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:13 |
| slangasek | tzimonq: https://people.canonical.com/~vorlon/lubuntu-daily-20160719.log | 00:16 |
| slangasek | eh | 00:16 |
| slangasek | tsimonq2: ^^ | 00:16 |
| tsimonq2 | thanks slangasek | 00:17 |
| tsimonq2 | slangasek: is the nusakan code public? | 00:18 |
| 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:19 |
| slangasek | tsimonq2: yes, lp:ubuntu-cdimage | 00:20 |
| tsimonq2 | slangasek: I thought that was only the scripts that called it? where are the actual build scripts (in lp:ubuntu-cdimage) | 00:21 |
| slangasek | tsimonq2: ah, then you mean lp:~ubuntu-cdimage/debian-cd/ubuntu | 00:26 |
| tsimonq2 | that might be it :) | 00:27 |
| tsimonq2 | thanks :) | 00:28 |
| tsimonq2 | slangasek: hey, you still around? | 00:46 |
| xnox | slangasek, http://people.canonical.com/~ubuntu-archive/cd-build-logs/ | 00:54 |
| tsimonq2 | OH! thanks xnox :) | 00:54 |
| 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:55 |
| 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:56 |
| xnox | good night.... however it is still too hot to sleep =/ | 00:57 |
| slangasek | Trevinho: hi, please see bug #1604657 | 05:09 |
| ubot5 | bug 1604657 in unity (Ubuntu) "[Regression] Unity shows blank desktop with software renderer" [Undecided,New] https://launchpad.net/bugs/1604657 | 05:09 |
| 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:44 |
| tjaalton | nope | 05:46 |
| pitti | infinity: urgh, sorry, misunderstanding -- I thought you just asked for confirmation, not doing it | 05:51 |
| 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:53 |
| pitti | infinity: sprint weeks are notoriously bad for paying attention to IRC, sorry | 05:54 |
| infinity | pitti: Yeah, I'm sprinting too, I can relate. | 06:30 |
| infinity | tjaalton: Err, wat? trusty dailies should have switched. | 06:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:40 |
| 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:41 |
| tjaalton | surely I should be able to see the pkg with apt | 06:42 |
| infinity | tjaalton: Try an apt-get update? | 06:42 |
| tjaalton | ah there it is | 06:43 |
| tjaalton | ooh, and upgrae seems to work too | 06:44 |
| infinity | tjaalton: You're not supposed to sound surprised by that. ;) | 06:47 |
| tjaalton | right, spoke too soon :) | 06:47 |
| 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:48 |
| ubot5 | bug 1574544 in light-locker-settings (Ubuntu Xenial) "[SRU] Light-locker-settings crash on startup" [High,In progress] https://launchpad.net/bugs/1574544 | 06:48 |
| 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:52 |
| 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:54 |
| 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 | 06:55 |
| 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:01 |
| 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:06 |
| 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:11 |
| flexiondotorg | infinity, Yo | 07:13 |
| infinity | flexiondotorg: 'Sup? | 07:13 |
| flexiondotorg | Where are you hiding? | 07:13 |
| infinity | flexiondotorg: Germany. | 07:13 |
| flexiondotorg | :-D | 07:14 |
| flexiondotorg | I've tried chasing round. | 07:14 |
| jbicha | infinity: good morning, I'm checking on whether the gnome image will still have gnome-maps | 07:19 |
| tsimonq2 | flocculant: ping | 07:20 |
| infinity | jbicha: I need to fix that today. | 07:20 |
| jbicha | infinity: I appreciate it :) | 07:21 |
| flocculant | tsimonq2: quickly - off out the door very shortly | 07:21 |
| 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:22 |
| flocculant | what bug is that? | 07:23 |
| tsimonq2 | bug 1574544 | 07:23 |
| ubot5 | bug 1574544 in light-locker-settings (Ubuntu Xenial) "[SRU] Light-locker-settings crash on startup" [High,Fix committed] https://launchpad.net/bugs/1574544 | 07:23 |
| flocculant | mmm not seen that one before | 07:25 |
| flocculant | tsimonq2: we don't install that package | 07:28 |
| tsimonq2 | oh really? | 07:29 |
| tsimonq2 | huh | 07:29 |
| tsimonq2 | alright, problem solved :) | 07:29 |
| flocculant | too many things too early - we dob't in yak at least, don't think we do in xenial | 07:30 |
| flocculant | and we don't there either - didn't think so | 07:32 |
| tsimonq2 | infinity: how long does it take for a package to be published in proposed after the upload? | 07:43 |
| infinity | tsimonq2: It takes until it's done. | 07:55 |
| tsimonq2 | oh okay infinity | 07:55 |
| infinity | tsimonq2: Should be pushing to mirrors over the next 10-15m. | 07:59 |
| 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:00 |
| infinity | tsimonq2: Then pushing to public mirrors. | 08:01 |
| tsimonq2 | alright | 08:02 |
| tsimonq2 | infinity: verification-done on bug 1574544 | 08:10 |
| ubot5 | bug 1574544 in light-locker-settings (Ubuntu Xenial) "[SRU] Light-locker-settings crash on startup" [High,Fix committed] https://launchpad.net/bugs/1574544 | 08:10 |
| infinity | tsimonq2: Ta. | 08:11 |
| flexiondotorg | infinity, Obviously no powerpc with me. | 08:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| infinity | Plus, ignoring Mark is a CLM. | 08:59 |
| davmor2 | infinity: oh your at the snappy sprint didn't know dude :) | 08:59 |
| infinity | Yeah. | 09:00 |
| * mwhudson was thinking this was late for infinity to be awake even by his standards | 09:08 | |
| === s8321414_ is now known as s8321414 | ||
| xnox | infinity, is base the new name for the old core? | 09:44 |
| * xnox is confused | 09:44 | |
| davmor2 | infinity: good news netboot is working \o/ | 09:51 |
| 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:52 |
| 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. | 09:53 |
| === rcj` is now known as rcj | ||
| xnox | infinity, shouldn't "ports" .iso images have /ubuntu-ports directory? | 10:22 |
| xnox | or at least a symlink from /ubuntu-ports -> /ubuntu? | 10:22 |
| 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:23 | |
| infinity | xnox: Probably. File a bug. Won't fix it for .1 | 10:35 |
| infinity | xnox: It's never been an issue for people installing with the ISO, so I guess we've never noticed. | 10:36 |
| xnox | bug #1604765 | 10:40 |
| ubot5 | bug 1604765 in Ubuntu CD Images "ports.iso should have /ubuntu-ports -> /ubuntu symlink" [Undecided,New] https://launchpad.net/bugs/1604765 | 10:40 |
| xnox | also console-setup has a minor regression on s390x -> unit fails and causes install to be "degraded" | 10:49 |
| xnox | bug #1604737 | 10:49 |
| ubot5 | bug 1604737 in console-setup (Ubuntu Xenial) "s390x installations are degraded due to failed setvtrgb.service" [Undecided,New] https://launchpad.net/bugs/1604737 | 10:49 |
| tsimonq2 | infinity: what's the status of the rebuild? | 11:03 |
| infinity | tsimonq2: Kicking off lubuntu* nowish. Had a lunch break. :P | 11:09 |
| xnox | i should do lunch too i guess, this encrypted install will take forever | 11:10 |
| tsimonq2 | ok infinity :) | 11:12 |
| * tsimonq2 sleeps | 11:15 | |
| 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:46 |
| Odd_Bloke | flexiondotorg: You're slow-dancing with powerpc? | 11:49 |
| Odd_Bloke | infinity will be jealous. | 11:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| infinity | Uh oh. I'm down to three more pseudoephedrine. This cold needs to die in the next 16 hours. | 11:56 |
| apw | infinity, that sounds fatal ... need to ask a local what they are called | 12:11 |
| infinity | apw: Yeah, I might get someone to go buy drugs for me. | 12:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| infinity | Right. Well, I'll go find myself a meth dealer and a kids' chemistry set. | 12:19 |
| cjwatson | (I have nowhere near enough chemistry to be able to tell whether the actual synthesis is feasible or chain-jerking ...) | 12:20 |
| 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:30 |
| infinity | jbicha: What timezone are you in? | 12:31 |
| infinity | Oh, EST5EDT. | 12:32 |
| 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:09 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:34 |
| 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:35 |
| 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:36 |
| * 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| ubot5 | bug 1599236 in Oxide "Tooltips in Flash content have stopped working" [High,Fix released] https://launchpad.net/bugs/1599236 | 13:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| infinity | xnox: Given that /proc/self/fd/0 is already going to be ttyslcp0 in your case, and it failed to love it. | 13:48 |
| xnox | yeap. | 13:50 |
| 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:51 |
| xnox | trying to find on fedora if and where they call setvtrgb | 13:53 |
| infinity | xnox: Is stvtrgb using GIO_CMAP/PIO_CMAP? | 13:59 |
| 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:01 |
| infinity | xnox: But yes, that confirms my suspicion that they probably are, as they're testing explicitly if a Linux VC IOCTL works. | 14:02 |
| 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:03 |
| 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:05 |
| 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:08 |
| infinity | Just missing that one branch there, IMO. It never tests the return of getfd(), it just assumes it got a useful result. | 14:09 |
| xnox | updated https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/1604737 | 14:10 |
| ubot5 | Launchpad bug 1604737 in kbd (Ubuntu Xenial) "headless installations are degraded due to failed setvtrgb.service" [Undecided,New] | 14:10 |
| xnox | with above irc chatter | 14:10 |
| 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:13 |
| 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:14 |
| infinity | I guess, alternately, it could just exit 0 there. | 14:15 |
| infinity | Which results in the same behaviour I was suggesting above. | 14:15 |
| infinity | Just doesn't seem like "Your console isn't a Linux VC" should fail non-zero to me. | 14:16 |
| * infinity shrugs. | 14:16 | |
| xnox | infinity, set normal exit to 1 in the systemd unit? | 14:18 |
| xnox | =) | 14:18 |
| davmor2 | infinity: should 16.04.1 have the upgrade from 14.04.4 enabled or is that coming in 14.04.5 | 14:20 |
| 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:23 |
| flocculant | cos I was being lazy ... | 14:24 |
| infinity | davmor2: It'll be early next week, probably. | 14:26 |
| infinity | Daviey: Yo, is anyone testing mythbuntu? | 14:35 |
| infinity | davmor2: How's desktop looking? I don't see any test results on the tracker. | 14:40 |
| davmor2 | infinity: there are some refresh | 14:41 |
| infinity | davmor2: s/any/many/ ;) | 14:41 |
| davmor2 | infinity: no issues so far | 14:41 |
| 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:42 |
| 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:43 |
| infinity | xnox: Kay. | 14:44 |
| xnox | i think i might just upload exit(0) to yakkety =) | 14:44 |
| xnox | however exit 1 is kind of right, it's just that systemd job shouldn't fail and make the boot look degraded | 14:45 |
| 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:55 |
| xnox | infinity, maybe setvtrgb.service should not be wantedby sisinit.target | 14:56 |
| xnox | but instead be wantedby getty@.service | 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 getty@.service | 14:57 |
| infinity | xnox: I mean, if it's not, you wouldn't get a prompt on serial. :P | 14:57 |
| 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:58 |
| xnox | let me try that | 14:59 |
| xnox | infinity, systemd is silly. wantedby getty@.service does not work, because there is always getty@tty1|7.service 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:10 |
| 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:11 |
| 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:13 |
| infinity | getty-static.service loaded inactive dead getty on tty2-tty6 if dbus and logi | 15:14 |
| infinity | getty@tty1.service 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:14 |
| infinity | SPECIAL. | 15:15 |
| bdmurray | slangasek: Could you fully phase php7.0 in xenial for nacc? | 15:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| infinity | I love deterministic boot systems. | 15:25 |
| xnox | infinity, note the $ /etc/systemd/system/getty.target.wants/getty@tty1.service -> so we always try to start tty1, even on headless systems.... | 15:25 |
| 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:26 | |
| infinity | Daviey: If I'm asking the wrong person about Myth testing, can you pass along the message ASAP? :P | 15:28 |
| 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:30 |
| 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:31 |
| tgm4883 | infinity: I'm downloading the ISO now | 15:32 |
| infinity | tgm4883: Yay. | 15:32 |
| infinity | tgm4883: I assume that's ISOs, plural. ;) | 15:32 |
| 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:33 |
| tgm4883 | yep, it's a slow download currently :/ | 15:34 |
| * xnox BRAINFREEZE | 15:38 | |
| Daviey | infinity: hey.. superm1 is the project lead.. i'm only loosely involved still | 16:12 |
| Daviey | infinity: i'll talk with him | 16:12 |
| infinity | Daviey: tgm4883 is on the case. | 16:14 |
| 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:15 |
| 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:17 | |
| 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:18 |
| infinity | tgm4883: So, yeah, you have 21 months to figure out the next step. | 16:19 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 | |
| tgm4883 | I'll take a look | 16:26 |
| 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:27 |
| 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:28 |
| 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:32 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| jbicha | infinity: great, yes I'd prefer a re-spin with that change | 16:41 |
| 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:42 |
| pitti | infinity: meh, still no diff -- so LOOK BEHIND -- A three headed monkey! | 16:49 |
| infinity | pitti: YAY MONKEY. | 16:50 |
| pitti | huh, who did that.. | 16:50 |
| 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:51 | |
| 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:52 |
| 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:53 |
| pitti | already built, so will copy in ~ 20 mins or so when it published | 16:54 |
| pitti | infinity: done | 17:08 |
| davmor2 | infinity: all the mandatory, all the secondary and 3 of the run once are covered on amd 64 moving onto i386 now | 17:09 |
| 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 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-019/xenial/ppc64el/u/ubuntu-system-settings-online-accounts/20160718_054019@/log.gz Could you figure out something? | 17:10 |
| 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:11 |
| pitti | davmor2: I would love to, but he's not here in Delft :) | 17:12 |
| davmor2 | oh not the snappy sprint then | 17:12 |
| pitti | no, desktop startup upstart->systemd sprint | 17:13 |
| pitti | nacc: is bug 1604630 something that needs to be squeezed into 16.04.1? ('cause that sounds pretty much "too late" now) | 17:15 |
| ubot5 | bug 1604630 in ubuntu-meta (Ubuntu Xenial) "[FFe] 16.04 SAMBA missing winbind packages during install" [Undecided,New] https://launchpad.net/bugs/1604630 | 17:15 |
| 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:16 |
| 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:17 |
| pitti | bzoltan: I seriously doubt anyone cares about this package on ppc64el, I'd suggest to just ignore the test for now? | 17:20 |
| 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:21 |
| 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:22 |
| 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:25 |
| bzoltan | pitti: thanks | 17:31 |
| 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? | 17:57 |
| camako | robru, ^^ is there a specific person I should ask this to? | 18:00 |
| robru | camako: whoever is around. Maybe pitti is still here | 18:01 |
| camako | Oh I see in the scrollback pitti was talking about it ^^ | 18:02 |
| 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:07 |
| camako | I see this is plaguing a bunch of us, so I guess I'll sit tight | 18:08 |
| slangasek | robru: so bileto's p-m runs use the main release team hints branch? | 18:09 |
| slangasek | if so, the hint's been added and should clear on the next p-m run | 18:10 |
| slangasek | oh, we're talking about yakkety itself here | 18:11 |
| slangasek | yeah, that will clear on the next run | 18:11 |
| 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:30 |
| * 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:31 |
| robru | slangasek: bileto pulls hints from lp:~ubuntu-release/britney/hints-ubuntu | 18:32 |
| tsimonq2 | infinity: wait a minute... not tested?!?!?!? http://pix.toile-libre.org/upload/original/1469039594.png | 18:33 |
| tsimonq2 | infinity: I mean, it's not FULLY tested, but we're working on it :) | 18:34 |
| 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:15 |
| 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:18 |
| infinity | jbicha: Your new images are building. Should be done shortly. | 19:19 |
| 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:26 |
| arges | infinity: oh shit | 19:29 |
| arges | infinity: sorry | 19:29 |
| 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:31 |
| infinity | jderose: The what? | 19:34 |
| * infinity scrolls back. | 19:34 | |
| infinity | jderose: Nope, not respinning for that. | 19:36 |
| jderose | infinity: cool, thanks! | 19:37 |
| infinity | People installing that task from the server ISO will be SOL, but oh well. :/ | 19:37 |
| infinity | nacc: Should libnss-winbind be included in samba-server as well? | 19:39 |
| infinity | nacc: Adding libpam-winbind only solves half that bug. | 19:40 |
| infinity | pitti: ^ | 19:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| nacc | infinity: yeah, i'm realizing that myself as I try to figure this out :) | 19:48 |
| nacc | infinity: fwiw, updated MRs pushed out (MR: #300661 and MR: #300660) | 20:20 |
| nacc | pitti: --^ | 20:25 |
| nacc | infinity: thanks for the poke on that | 20:25 |
| 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:34 |
| tjaalton | bdmurray: support for what? | 20:35 |
| jbicha | infinity: boot/basic install/reboot for UG i386 and amd64 on VBox works | 20:36 |
| 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:37 |
| tjaalton | ah, ok | 20:38 |
| 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:39 |
| tjaalton | bdmurray: he also didn'tknow the daily image didn't have them :) | 20:40 |
| 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:41 |
| tjaalton | it involves more than just pulling a trigger? | 20:45 |
| 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:46 |
| 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:48 |
| tjaalton | or i'll ask Sarvatt to test :) | 20:49 |
| 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:01 |
| * slangasek nods | 21:02 | |
| tjaalton | ok, cool | 21:04 |
| 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-0ubuntu2.16.10.1/ | 22:22 |
| 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:23 |
| 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:32 |
| 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-0ubuntu1.16.10.1 | yakkety-proposed | amd64, arm64, armhf, i386, ppc64el, s390x | 22:33 |
| slangasek | juju-2.0 | 2.0~beta12-0ubuntu2.16.10.1 | yakkety-proposed | powerpc | 22:33 |
| balloons | slangasek, right.. the rest failed to build the new version. | 22:34 |
| balloons | I want 2.0~beta12-0ubuntu2.16.10.1 to build, as the previous upload has an adt failure. 2.0~beta12-0ubuntu2.16.10.1 should land properly | 22:34 |
| balloons | see for example "The following packages have unmet dependencies:" in https://launchpadlibrarian.net/274157286/buildlog_ubuntu-yakkety-amd64.juju-core_2.0~beta12-0ubuntu2.16.10.1_BUILDING.txt.gz | 22:35 |
| slangasek | oh, I see, powerpc was the *only* one that built | 22:35 |
| slangasek | I thought that was the one that wanted debugging, sorry | 22:36 |
| mwhudson | uh oh is this my fault | 22:37 |
| mwhudson | ah yes | 22:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| balloons | and yea, slangasek, lol, given the fact ONLY ppc built I knew something was up :-) | 22:42 |
| mwhudson | uh so transitions | 22:47 |
| 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:30 |
| mwhudson | xnox: well it's all my fault | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
