=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== didrocks1 is now known as didrocks
[07:31] <mlankhorst> morning
=== clayfreeman_ is now known as clayfreeman
=== doko_ is now known as doko
[08:23] <mlankhorst> oh yeah getting the complaint about the no kernel modules with the alternate cd :(
[08:52] <xnox> Wubi sent for signing in RT #73935
[09:07] <jibel> mlankhorst, if it's to debug the lts-trusty installation failure, use http://cdimage.ubuntu.com/precise/daily/20140805.1/
[09:07] <jibel> it should work
[09:08] <mlankhorst> ok thanks
[09:09] <jibel> mlankhorst, you can also probably reproduce in the chroot or minimal vm by installing the task ubuntu-desktop^
[09:10] <mlankhorst> jibel: yeah that's going to be problematic
[09:11] <mlankhorst> jibel: it mentions 12.04.4 though, or was that description not updated?
[09:18] <jibel> mlankhorst, no idea if it failed with lts-saucy in 12.04.4.
[09:19] <jibel> mlankhorst, with http://cdimage.ubuntu.com/precise/daily/20140805/precise-alternate-amd64.iso I confirm that you can reproduce the lts-trusty failure
[09:19] <jibel> mlankhorst, download this image then you start it with something like: qemu-img create /tmp/disk.img 8G && /usr/bin/qemu-system-x86_64 -m 1024 -display sdl -vga std -enable-kvm -drive file=/tmp/disk.img -cdrom ~/iso/ubuntu/precise-alternate-amd64.iso
[09:20] <jibel> proceed with the installation and it'll fail
[09:20] <mlankhorst> ok
[09:22] <mlankhorst> it's installing base system now
[09:26] <mlankhorst> oh indeed
[09:27] <mlankhorst> jibel: I'm getting a different failure though, about python-couchdb and some other python packages
[09:28] <mlankhorst> http://paste.debian.net/113906/
[09:29] <mlankhorst> oh, that's probably from the preseed I was using
[09:31] <jibel> mlankhorst, don't use any preseed, just what's on the image. These packages are installed by automated tests
[09:33] <mlankhorst> ah
[09:43] <mlankhorst> jibel: libgl1-mesa-dri is part of task ubuntu-desktop
[09:43] <mlankhorst> jibel: so what's happening simply seems to be that it's trying to install libgl1-mesa-dri and libgl1-mesa-dri-lts-trusty simultaneously, no deeper causes afaict
[09:44] <jibel> mlankhorst, ah good to know.
[09:47] <mlankhorst> is there anything else you oneed, or do you think you can fix it from here?
=== ricmm_ is now known as ricmm
[10:54] <shadeslayer> can I ask for a Kubuntu Plasma 5 ISO spin in ~30 minutes?
[11:12] <shadeslayer> infinity: stgraber ^^ ?
[11:13] <shadeslayer> oh, parted would still be broken though
[11:13] <cjwatson> it is, though I think I have a handle on it
[11:14] <shadeslayer> \o/
[11:32] <doko> infinity, cjwatson: did you promote ruby-hiera without promoting the source? and without a MIR?
[11:32] <rbasak> doko: it got renamed from "hiera". Or something like that.
[11:33] <doko> rbasak, is there a bug report for this?
[11:33] <rbasak> doko: no, but I did post https://lists.ubuntu.com/archives/ubuntu-release/2014-July/002966.html
[11:34] <rbasak> doko: what else is needed? I thought it'd be a no-brainer.
[11:34] <doko> rbasak, I'm not subscribed to -release
[11:35] <doko> ok, promoted
[11:35] <rbasak> Thanks!
[11:37] <rbasak> doko: while you're looking, there was also https://lists.ubuntu.com/archives/ubuntu-release/2014-July/002967.html
[11:37] <rbasak> New dependencies on haproxy-doc, pulling in nodejs of all things.
[11:38] <rbasak> I suggest demoting just the haproxy-doc binary to universe, if that's acceptable?
[11:38] <doko> rbasak, sure, https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1353421 is your's then =)
[11:38] <ubot93> Launchpad bug 1353421 in haproxy "haproxy: component mismatch (depends on twitter-bootstrap and friends)" [Critical,Confirmed]
[11:40] <rbasak> doko: commented
[11:40] <doko> rbasak, no, fix it!
[11:41] <rbasak> doko: please can you elaborate?
[11:42] <doko> ahh, let me try an exclude in the seeds
[11:48] <jibel> mlankhorst, actually I've no idea where this must be fixed. if it's a seed issue I don't know how it works.
[11:48] <mlankhorst> jibel: neither do I to be honest, I think the default cd's explicitly had a step to remove libgl1-mesa-dri etc from the seeds
[11:54]  * mlankhorst checks again
[11:57] <doko> rbasak, here are more server related component mismatches: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg =)
[12:02] <mlankhorst> cjwatson: hey do you know how we fixed the libgl1-mesa-dri/libgl1-mesa-dri-lts conflicts in the normal cd?
[12:04] <cjwatson> mlankhorst: all I know was the thing you remembered about glamor
[12:05] <cjwatson> have no other brain cycles just now due to parted
[12:05] <mlankhorst> jibel: why does the alternate cd contain libgl1-mesa-dri/glx and libglapi-mesa ?
[12:06] <jibel> mlankhorst, I really don't know how this part works
[12:08] <mlankhorst> presumably the same reason why it's trying to install
[12:10] <mlankhorst> can I see the build logs for the cd somewhere?
[12:14] <cjwatson> mlankhorst: http://people.canonical.com/~ubuntu-archive/cd-build-logs/
[12:15] <cjwatson> link at the top of each log to the livefs build log on Launchpad
[12:15] <cjwatson> (in cases where the image contains a livefs)
[12:15] <mlankhorst> ok
[12:18] <mlankhorst> * Chose libgl1-mesa-glx to satisfy xserver-xorg-core-lts-trusty
[12:19] <mlankhorst> hm..
[12:19] <cjwatson> might just need a preferred alternative there then
[12:20] <mlankhorst> yeah but first one that shows up from the log seems to be mesa-common-dev
[12:22] <Riddell> anyone able to debug why kde4libs and all its friends in kde sc 4.13.97 doesn't want to transition to -release ?
[12:22] <Riddell> the nepomuk packages have gone away
[12:23] <Riddell> I wonder if I've still got some to delete
[12:23] <mlankhorst> cjwatson: looks like you ma be right
[12:29] <mlankhorst> cjwatson: where is  /srv/cdimage.ubuntu.com/scratch/ubuntu/precise/daily/tmp/precise-amd64/list ?
[12:34] <cjwatson> on nusakan
[12:34] <cjwatson> but it's autogenerated every build
[12:36] <rbasak> doko: probably best leave jamespage to sort out the tomcat8 mismatches. I think zul is looking after the Openstack-related ones.
[12:37] <zul> rbasak:  i am
[12:38] <rbasak> doko: FYI, I've also got an upcoming mysql-5.5 to mysql-5.6 switch
[12:41] <mlankhorst> cjwatson: ah, is there any documentation on how to build the official image myself?
[12:42] <cjwatson> not really
[12:42] <cjwatson> sorry I can't help right now
[12:42] <cjwatson> maybe this evening ...
[12:43] <mlankhorst> ok
[13:03] <doko> rbasak, please don't build using gcc-4.4 ;-P
[13:06] <rbasak> doko: :)
[13:46] <shadeslayer> cjwatson: any ETA on parted?
=== mbarnett` is now known as mbarnett
[13:49] <cjwatson> shadeslayer: found the problem, but the obvious revert breaks a test, so trying to figure out a way to deal with it without breaking ABI
[13:49] <shadeslayer> okay :)
[14:10] <doko> xnox, pitti: is it safe to accept systemd & upstart?
[14:10] <jibel> stgraber, for info, ubiquity crashes on ubuntu desktop 12.04.5 and oem mode
[14:10] <jibel> stgraber, I'll file a bug
[14:11] <pitti> doko: yes, from my POV
[14:11] <pitti> doko: it's just a new python3-systemd package, and I dropped the Python 2 one
[14:11] <pitti> (no rdepends)
[14:11] <xnox> jibel: =((((( please shoot me a number, i'll look into it asap.
[14:12] <doko> pitti, and systemd-sysv?
[14:12] <pitti> doko: ah right; requested by slangasek and jhunt; that shoudl go to universe for now
[14:13] <pitti> doko: it's not installable yet, but will soon be with my pending sysvinit merge
[14:13] <xnox> pitti: doko: does systemd-sysv correctly replace only pot-split upstart?
[14:13] <xnox> s/pot/post/
[14:13] <xnox> or does it even matter?
[14:13] <pitti> xnox: it doesn't replace it at all?
[14:13] <pitti> xnox: it conflicts: to upstart (but not to -bin)
[14:13] <xnox> pitti: ack, yeah conflicts should be enough.
[14:14] <jibel> xnox, syslog http://paste.ubuntu.com/7970723/ to reproduce press F4/OEM in syslinux, then 'Install Ubuntu'. wait until it crashes
[14:15] <mlankhorst> can I get xserver-xorg-video-s3 and xserver-xorg-video-sis removed? they're no longer in debian sid
[14:15] <mlankhorst> https://launchpad.net/debian/+source/xserver-xorg-video-s3 https://launchpad.net/debian/+source/xserver-xorg-video-sis
[14:26] <jibel> xnox, stgraber bug 1353531
[14:26] <ubot93> bug 1353531 in ubiquity "[12.04.5] ubiquity crashes in OEM mode in info_loop in in ubi-usersetup.py, line 394 with : TypeError: sequence item 0: expected string, NoneType found" [Undecided,New] https://launchpad.net/bugs/1353531
[14:28] <cjwatson> shadeslayer: building a Debian upload now - can I just let it autosync in some hours, or do you need it faster?
[14:28] <shadeslayer> autosync is fine
[14:28] <cjwatson> great, sorry about the delay
[14:29] <cjwatson> http://anonscm.debian.org/cgit/parted/debian/parted.git/commit/?id=11ccc7136ada703a3dcf932609023392c5bbf95f was the fix FWIW
[14:29] <cjwatson> it's a bit hacky, so I'll need to sort it out better with upstream, but it seems to do the job for now
[14:35] <Riddell> stgraber: you're on 12.04.5 duty?
[14:35] <Riddell> it says no kernal modules were found
[14:35] <Riddell> I don't miss the alternate installer
[14:36] <stgraber> Riddell: yep
[14:37] <Riddell> stgraber: do I need to update a seed somewhere?
[14:38] <stgraber> hmm, I see a whole lot of lts-saucy stuff on that media, so yeah, something looks a bit off
[14:39] <Riddell> oh it needs "Move precise from lts-saucy to lts-trusty"
[14:39] <stgraber> what does?
[14:40] <Riddell> dunno I just read that in the ubuntu.precise seed bzr changelog
[14:40] <stgraber> ok, so first question is does kubuntu actually do the enablement kernel and X stuff?
[14:41] <Riddell> gosh I don't remember, maybe we don't for precise
[14:42]  * stgraber goes to look at kubuntu 12.04.4 alternate
[14:44] <stgraber> so that's confusing, the only kernel you've got on the 12.04.4 image is the original 3.2 but then you also had a bunch of 3.11 kernel modules for whatever reason. So it looks like the installer was using 3.11 but the installed system was on 3.2
[14:44] <Riddell> I think we may have tried to use lts enablement but didn't quite manage it properly
[14:46] <xnox> jibel: looks very corrupt, from code "errors" list may only ever have strings.... And I cannot reproduce in my VM instance. Is there something fishy going on with network  / vm hostname? is there internet connectivity to the VM?
[14:47] <jibel> xnox, this is how I start the iso. qemu-img create /tmp/disk.img 10G && /usr/bin/qemu-system-x86_64 -m 1024 -display sdl -vga std -enable-kvm -drive file=/tmp/disk.img -cdrom ~/iso/ubuntu/precise-desktop-amd64.iso
[14:47] <jibel> xnox, I'll check network connectivity
[14:47] <jibel> xnox, but I guess it's okay, the release notes link is displayed on other tests
[14:47] <jibel> xnox, I'm on utopic if that matters
[14:48] <stgraber> Riddell: ok, I think I know what needs to happen, doing that now
[14:48]  * Riddell looks appreciative
[14:48] <xnox> jibel: host utopic here as well. Your image checksum please?
[14:49] <jibel> xnox, 968441ac29b8cb088f24aa5851451881e0efbe5afff31e3c137850b7e9804209  /home/j-lallement/iso/ubuntu/precise-desktop-amd64.iso
[14:49] <jibel> same as http://cdimage.ubuntu.com/precise/daily-live/20140805.3/SHA256SUMS
[14:49] <stgraber> Riddell: updated your seeds, rebuilding alternate now
[14:51] <Riddell> great thanks stgraber
[14:53] <jibel> xnox, there is network connectivity. the hostname is ubuntu, does ubiquity build another hostname from a serial/model/brand anything specific to the machine?
[14:55] <xnox> jibel: it tries to, yes. e.g. for me i end up with "dima-virtual-machine" name based on dhcp and the fact that it's a virtual machine.
[14:56] <jibel> xnox, ah it might be it. For me in the last step it pre-fills computer name with: ubuntu-SMBIOS-implementations-newer-than-version-2-7-are-not-fully-supported-by-this-version-of-dmidecode-Standard-PC-i440FX-PIIX-1996
[14:57] <xnox> lolz =)
[14:57] <xnox> jibel: clearly dmidecode is failing =)))))))))))
[14:57] <xnox> jibel: do you have some custom qemu / kvm  / smbios installed?
[14:57]  * xnox upgrades my machine
[14:58] <xnox> jibel: submitted succes OEM test, for ubuntu amd64 precise
[14:58] <xnox> on the iso tracker
[14:59] <jibel> xnox, okay, I've only standard components
[14:59] <xnox> (that string looks like a complete error message from dmidecode)
[15:00] <shadeslayer> cjwatson: thx for the patch btw :)
[15:00] <cjwatson> phew
[15:01] <shadeslayer> why the phew? :D
[15:01] <xnox> jibel: i'm running older qemu, upgrading now, hopefully that's the bug.
[15:02] <doko> xnox, the uninstallability is because libscalapack-openmpi1 depends on libblacs-mpi1, and not libblacs-openmpi1 as it should. no trying to figure out why
[15:03] <cjwatson> shadeslayer: because it took a day and a half :)
[15:03] <xnox> doko: i did switch from one implementation to another on various arches in the past. they should all match within a given stack, and ideally match the default mpi for the arch.
[15:06] <jibel> xnox, likely. It works on vbox where the name is ubuntu-Virtualbox. I'll mark the test as passed and update the report. ubiquity shouldn't crash if dmidecode returns unexpected strings. But not critical for the release
[15:07] <xnox> true.
[15:08] <xnox> jibel: well, if we respin, i'll prepare a fix for it....
[15:18] <Riddell> what's the status of meta-release-lts being updated for trusty?
[15:19] <stgraber> Riddell: let me know if that still doesn't boot for you ^
[15:22] <stgraber> Riddell: I still see a bunch of packages that really shouldn't be on your media but those that should be are there, so it doesn't look any worse than 12.04.4 so far :)
[15:23] <shadeslayer> cjwatson: hah :D
[15:23] <shadeslayer> cjwatson: {{hugs}}
[15:37] <stgraber> Riddell: just gave that new image a quick try and I get all the way to partitioning so hopefully that means it now works
[15:38] <Riddell> stgraber: lovely, thanks
[15:44] <stgraber> xnox, jibel: so did you make any progress on that OEM bug? is that an actual regression from 14.04 or just something which changed in the test setup and made it show up?
[15:44] <xnox> stgraber: oem mode fails on qemu 2.1 (utopic) as reported by jibel.
[15:45] <xnox> stgraber: no idea if trusty/utopic also fails.
[15:45] <jibel> stgraber, it's dmidecode that returns loooong strings with qemu 2.1
[15:45]  * jibel tries with utopic
[15:45] <stgraber> do you have a plan on how to fix that?
[15:46] <jibel> xnox, there is no OEM mode in utopic desktop ?
[15:46] <stgraber> (a last minute ubiquity change means respinning a whole bunch of things, all desktops and alternates...)
[15:46]  * jibel tries with trusty :)
[15:46] <xnox> jibel: there is... but one must manually type out kernel cmd arg.
[15:47] <xnox> stgraber: well, we can release note that 12.04.5 does not work on qemu 2.1 (or newer smb-bios) or let me come up with a minimal fix to work-around it.
[15:47] <cjwatson> stgraber: but respins are really fast now ;-)
[15:47] <cjwatson> (yes, I know, QA not so much so, but ...)
[15:47] <xnox> and we don't have new signed wubi yet.
[15:47] <stgraber> yeah, at least we don't have to sit and wait for 5 hours anymore :)
[15:48] <stgraber> hmm, looks like we need more seed changes, there are reports of kernel mismatch on server too... let's look into that
[15:48] <jibel> xnox, stgraber works with trusty, trying with 12.04.4
[15:49] <stgraber> jibel: is that because dmidecode returns something more reasonable on trusty or because ubiquity deals with it somehow?
[15:50] <xnox> stgraber: it returns two line comment "SMBIOS implementations newer than version ...." and then what ubiquity expects/wants "QEMU"
[15:50] <xnox> =(
[15:51] <jibel> stgraber, because dmidecode doesn't return a warning on trusty while on Precise ubiquity tries to convert this warning to an hostname
[15:51] <jibel> BTW 12.04.4 is also affected, so not a regression
[15:51] <xnox> imho dmidecode is broken and should be spewing the comment into stderr, and not into stdout....
[15:52] <xnox> but that's dmidecode sru into precise + respin. =/
[15:52] <stgraber> well, in any case, if we want this fixed, it's sru + respin
[15:55] <stgraber> so there's a patch against our current dmidecode which bumps SUPPORTED_SMBIOS_VER to 0x0208
[15:55] <stgraber> I wonder if just cherry-picking that into precise's will do the trick
[15:55] <stgraber> jibel: do you still have an affected VM around you could run a test dmidecode for me on?
[15:55] <xnox> yes, that would help.
[15:56] <jibel> stgraber, sure
[15:57] <stgraber> jibel: what's the bug number again?
[15:58] <xnox> hm, actually ubiquity cod emakes no sense..... errors has "hostname_error_length" and it fails to handle that error condition. Thus we have been so far lucky, and it's just the first time hitting any error =/
[15:59] <stgraber> jibel: nevermind, found it in backlog
[16:05] <xnox> jibel: stgraber: http://paste.ubuntu.com/7971511/
[16:06] <xnox> hostname returns a list of errors for which it is suppose to fetch strings, but for some reason hostname_error_length string is not returned and instead None is returns, which bombs out ubiquity.
[16:06] <stgraber> jibel: packaged are available at: https://launchpad.net/~stgraber/+archive/ubuntu/experimental/+packages
[16:06] <xnox> what should be happnening, is correct warning string fetched / added....
[16:06] <stgraber> jibel: *packages
[16:08] <stgraber> xnox: ok, please push that to ubiquity trunk. I think I'd rather not touch ubiquity for precise if we can avoid it. It's the last point release so if fixing dmidecode works, let's just do that.
[16:08] <xnox> ack.
[16:08]  * stgraber gets back to being confused as to where the kernel mismatch is for server
[16:08] <stgraber> mlankhorst: oh, and any progress on the alternate X HWE stack mess?
[16:08]  * xnox reviews your dmidecode fix.
[16:09] <stgraber> xnox: it's a simple copy of the patch we carry in current dmidecode so hopefully that does the trick
[16:10] <Saviq> guys, any idea about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
[16:10] <Saviq> is sysvinit being synced from debian or something?
[16:10] <cjwatson> Of course it isn't :)
[16:11] <stgraber> hmm, how old is that d-i on the server image... running kernel is -30 instead of -32, I wonder how that happened
[16:11] <cjwatson> This is easy to check: https://launchpad.net/ubuntu/+source/sysvinit
[16:11] <Saviq> cjwatson, yeah, that I know
[16:11] <Saviq> cjwatson, but will it be?
[16:11] <Saviq> cjwatson, systemd in proposed requires it to be...
[16:11] <xnox> Saviq: just pitti needs pocking. There is a pending sysv merge to get it up to high enough version.
[16:11] <cjwatson> pitti: ^- do you have a plan to resolve that?
[16:11] <cjwatson> Saviq: sync != merge
[16:12] <cjwatson> Saviq: when we say sync around here we mean a verbatim copy
[16:12] <Saviq> cjwatson, yeah sure, that I know, didn't know this was a merge
[16:12] <xnox> stgraber: dmidecode from your ppa fixes everything as well.
[16:12] <stgraber> yay
[16:12] <xnox> stgraber: +1 from me....
[16:12] <infinity> stgraber: Did you not rebuild after we promoted d-i?
[16:12]  * xnox the non-release team person.
[16:12]  * xnox should fix that.
[16:13] <stgraber> infinity: 21:38 UTC, that's almost certainly after we promoted d-i
[16:13] <stgraber> infinity: but yeah, the build log shows it picked up the old d-i, so I'll rebuild now
[16:14] <stgraber> xnox: ok, thanks for confirming, I'll upload to the queue now
[16:15] <xnox> stgraber: and it would all work, if errors were printed to stderr.... ubiquity would get proper QEMU string and live would be wonderful and we wouldn't need to upload dmidecode.
[16:15]  * xnox files a bug against dmidecode.
[16:15] <stgraber> xnox: yeah, agreed, errors on stdout is stupid...
[16:16] <stgraber> infinity: can I get you to review that one? ^
[16:16] <xnox> and ubiquity specifically diverts stderr when calling dmidecode.
=== chorrell is now known as chorrell-away
=== chorrell-away is now known as chorrell
[16:16] <ara> stgraber, quick question if I may
[16:16] <stgraber> ara: sure
[16:16] <ara> stgraber, when are point releases moved to old-releases? as soon as the new point release is released?
[16:17] <ara> stgraber, i.e. when 12.04.5 gets released, 12.04.4 will move to old-releases?
[16:17] <ara> stgraber, or is it other criteria?
[16:17] <stgraber> ara: yes, unless we forget to do it (it's a manual action)
[16:17] <stgraber> ara: but usually we only keep the original release (12.04) and the last point release (12.04.5) on releases.u.c
[16:19] <stgraber> infinity: LP seems to be unhappy with dmidecode, not producing a diff... here's my local one: http://paste.ubuntu.com/7971624/
[16:20]  * stgraber -> out for a few minutes
[16:21] <jibel> stgraber, dmidecode 2.11-4ubuntu0.1 doesn't make ubiquity crash
[16:22] <infinity> jibel: That was quick testing for a package still in the queue...
[16:22] <jibel> and it identify an SMBIOS 2.8 instead of returning a warning
[16:22] <stgraber> infinity: I uploaded it to a PPA first :)
[16:22] <infinity> Ahh.
[16:23] <ara> stgraber, thanks for the quick reply!
[16:23] <jibel> infinity, I got the build from https://launchpad.net/~stgraber/+archive/ubuntu/experimental/+build/6246998
[16:24] <stgraber> ok, so once that one is accepted, built and copied to -updates we can rebuild all images with ubiquity on them. The new server images will hopefully work too. So we'll then be left with that alternate X HWE stack weirdness to figure out, then hopefully we'll be good for the point release...
[16:24] <jibel> infinity, it is just to make cjwatson lie when he said QA was no fast :)
[16:24]  * stgraber disappears again for a bit longer this time.
[16:25] <infinity> stgraber: server has dmidecode on it too.
[16:25] <infinity> stgraber: I think dmidecode is a rebuild world event.
[16:27] <ara> stgraber, what about 14.04 and 14.04.1 images? both are in releases.ubuntu.com
[16:27] <ara> stgraber, (we are trying to fix the links in the certification site)
[16:30] <cjwatson> jibel: my bad :)
[16:31] <xnox> infinity: point release images become out of date with respect to updates pocket. so one doesn't have to rebuild server image with updated dmidecode. And that ubiquity/oem codepath is not used on server.
[16:32] <infinity> xnox: But the source ISOs won't match.
[16:44] <stgraber> arges: the rule is "original release + last point release" so it makes sense to have 14.04 and 14.04.1
[16:44] <stgraber> arges: sorry, was meant for ara but she left :)
[16:44] <xnox> infinity: =/ doh.
[16:44] <arges> stgraber: i was wondering what i did : )
[16:45] <stgraber> infinity: rebuild the world it is then
[16:46] <stgraber> xnox: any idea what bug 1353568 is about?
[16:46] <ubot93> bug 1353568 in ubiquity "ubiquity never gets to partitioning page in 12.04.5 live or ubiquity sessions" [Undecided,New] https://launchpad.net/bugs/1353568
[16:46] <infinity> stgraber: Actually, releases.u.c should only carry the latest point release.  14.04 still being there is because I didn't archive it while the website links were still broken.
[16:46] <infinity> stgraber: If you check 12.04, it only has .4
[16:47] <stgraber> infinity: hmm, ok.
[16:47] <xnox> stgraber: no idea, and incomplete information. commented.
[16:47] <stgraber> davmor2: ^
[16:48] <davmor2> stgraber: yeap when I have five minutes I will improve the bug it was just something quick to act as a marker
[16:50] <davmor2> xnox: It might actually be the 3rd party drivers for the wifi, but I really need to pull out the logs to know for sure I'll be doing that after tea when I have a few minute free though
[16:50] <ScottK> infinity: Given the non-LTS nature of some of the HWE components shipped on the point release media, might not leaving the original make sense?
[16:52] <infinity> ScottK: The website links to old-releases for people who want .1 without HWE.  I'm not sure if it'd be more or less confusing to have double the images on releases.u.c
[16:52] <xnox> davmor2: oh, was the crash after clicking next on the page "you have internets, you have disk space, etc." ?
[16:52] <infinity> ScottK: (I've asked the same question myself, just not sure the best way to represent the whole mess)
[16:52] <xnox> davmor2: could be well about the drivers.
[16:52] <davmor2> xnox: yeap sorry I forgot you have the select timezone next
[16:52] <davmor2> not partitioning
[16:53] <davmor2> d'oh
[16:53] <davmor2> long day
[16:54] <pitti> cjwatson, xnox: argh, sorry about that; I locally have my sysvinit merge installed, so I didn't notice
[16:55] <pitti> slangasek: would it be ok to upload my sysvinit merge to -proposed as well and set a block-proposed bug until you review? or revert the systemd upload?
[16:58] <ScottK> infinity: I'm not either.  I think ideally you'd have the choice of HWE or non-HWE on the point release install media, but that's suboptimal for other reasons.
[16:58] <stgraber> jibel, xnox: when one of you has a minute, can you try https://launchpad.net/ubuntu/+source/dmidecode/2.11-4ubuntu0.1 and make sure that works too?
[17:02] <infinity> ScottK: Aye.  It's an easy option to offer for d-i/netboot types (and we do), which I expect covers most of the people who deeply care, but it's harder for ISOs.
[17:06] <davmor2> xnox: added syslog and installer debug.  I don't see a partman log
[17:13] <davmor2> xnox: anything useful there?
[17:23] <davmor2> xnox: apport-collected on the bug too
[17:26] <davmor2> stgraber: ^
[17:28] <doko> xnox, same for mumps ... uploaded
[17:43] <stgraber> dmidecode copied to precise-updates, will begin the mass rebuild once that's published
[17:45] <jibel> stgraber, verification done!
[17:45] <jibel> :)
[17:46] <pitti> cjwatson, xnox, Saviq: I lowered the initscripts dep of systemd; will push back up (it's technically correct) when we finally land the sysvinit merge
[17:46] <jibel> davmor2, bah, looks like a kernel oops
[18:08] <davmor2> jibel: sadtrombone.com
[18:34] <Saviq> pitti, thanks
[19:54] <stgraber> took a while for dmidecode to get to precise-updates, finally starting the mass respin now
[20:27] <cjwatson> ScottK: I recently heard that the kernel team would like to go back to having both ("back" because it's what we did in lucid, well actually we just had all the available stacks as options there)
[20:28] <cjwatson> So would consider doing that in trusty
[20:28] <cjwatson> Both on the .N install media, I mean
[21:32] <stgraber> zequence: are you guys participating in 12.04.5?
[21:34] <slangasek> pitti: why does the systemd upload need reverting wrt sysvinit?
[21:35] <slangasek> pitti: again, I really do not think anything should be uploaded to -proposed that is not expected to go into the release pocket almost immediately; for sysvinit, I am planning to review but can't commit to getting it done before next week
[22:06] <ScottK> cjwatson: That would definitely help.