[13:51] <rbasak> stgraber: ^ please
[14:56] <cyphermox> rbasak: ^ thanks!
[16:03] <xnox> could an AA please weight in on: https://bugs.launchpad.net/ubuntu/+source/sysconfig/+bug/1528658 infinity slangasek seb128 cjwatson ?! =) I guess it would be a "no", as that's only something required on bare-metal installs (non-kvm)
[16:03] <ubot5`> Launchpad bug 1528658 in sysconfig (Ubuntu) "sysconfig-hardware is missing from s390x server livecd squashfs builds" [Undecided,Confirmed]
[16:24] <slangasek> xnox: is that an AA question?  The seeds are not AA-managed
[16:25] <slangasek> xnox: since it affects the server image I would say smoser or rbasak should weigh in, maybe
[16:26] <xnox> slangasek, well, it affects the s390x debootstrap =) which is used for squashfs on s390x. only on s390x.
[16:27] <xnox> but yeah, i'm not sure about the procedure here.
[16:28] <ogra_> seeds can be changed by any core-dev
[16:28] <ogra_> (so technically you shoudl be able to do it yourself ... parctically you should talk to a server person first indeeD)
[16:30] <xnox> ogra_, slangasek, is it about seeds? i'm asking about a priority override standard -> important
[16:33] <ogra_> xnox, ah, i didnt read the bug ... what you can do for a quick solution is to tell livecd-rootfs/live-build to install that package in an arch specific way ...
[16:33] <xnox> ogra_, ah.
[16:33] <ogra_> we do that in several places for different bootloader setups
[16:33] <rbasak> xnox: what's this /etc/sysconfig/ stuff about?
[16:33] <rbasak> No objection to seeding it, but that path seems completely wrong to me for a Debian-based system.
[16:34] <rbasak> In this room we think the minimal seed is appropriate I think.
[16:34] <cjwatson> xnox: Priorities are synced periodically with the seeds.
[16:34] <xnox> rbasak, it's a mainframe thing, to activate hard-drives and ethernet devices on mainframes, based on hex CCWGROUP addresses.
[16:34] <cjwatson> xnox: So ultimately, yes, it's a seeds matter.
[16:34] <rbasak> xnox: that's fine, but why that path?
[16:34] <ogra_> xnox, take a look at  lp:livecd-rootfs ... in live-build/auto/config line 495 and the next 100-200 lines or so
[16:34] <xnox> cjwatson, ah. and which seeds become important?
[16:35] <cjwatson> xnox: minimal
[16:35] <xnox> ack.
[16:35] <cjwatson> (and the required seed -> Priority: required)
[16:35] <xnox> i do wonder, i probably don't want that package in minimal. but I do want it preinstalled in the server.iso squashfs.
[16:35] <ogra_> cjwatson, but that will add it for all arches, no ? i thought the package is s390 specific
[16:36] <flexiondotorg_> infinity, Have you had the chance to review the "base" merge proposals for Xubuntu and Ubuntu MATE?
[16:36] <cjwatson> ogra_: not if it only exists on one architecture, which is the case
[16:36] <ogra_> ah, k
[16:36] <cjwatson> xnox: that seems like an odd pairing of things to want
[16:37] <cjwatson> xnox: is it harmful to have installed on non-bare-metal installs?
[16:37] <rbasak> xnox: I filed bug 1541007
[16:37] <ubot5`> bug 1541007 in sysconfig (Ubuntu) "Package ships files in incorrect paths" [Undecided,New] https://launchpad.net/bugs/1541007
[16:37] <cjwatson> I mean, it's 8KB
[16:38] <cjwatson> I would think shoving it into minimal is a better use of everyone's time than inventing a new method just for it :)
[16:40] <rbasak> cjwatson: "is it harmful to have installed on non-bare-metal"...I'm told it's required everywhere.
[16:40] <rbasak> (also that "bare-metal" doesn't make sense for s390x apparently)
[16:42] <cjwatson> rbasak: Well, bare-metal as in not inside KVM
[16:43] <xnox> cjwatson, mostly harmless on non-bare-metal machines =)
[16:43] <cpaelzer> cjwatson: hi this is the way debian configures channel devices
[16:43] <cpaelzer> that applies to z/VM/LPAR/KVM
[16:43] <cpaelzer> all of them
[16:44] <cjwatson> OK, so why are we discussing it then?  Just shove it into minimal :)
[16:45] <xnox> ok.
[16:46] <cjwatson> There's a "hardware and architecture support" section at the top of minimal, it probably belongs there
[17:03] <jderose> infinity: no new 14.04.4 daily yet it seems? will there be one today?
[17:03] <tsimonq2> I could be wrong, but I thought that was delayed...
[17:05] <infinity> jderose: Curious.  Lemme poke.
[17:06] <infinity> jderose: Evidently, the livefses failed.
[17:06]  * infinity goes to see why.
[17:07] <infinity> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/Release.gpg  Unable to connect to archive.ubuntu.com:http:
[17:07] <infinity> Network blip?
[17:07] <infinity> jderose: I'll give them a retry.
[17:07] <jderose> infinity: thanks!
[17:08] <jderose> cyphermox: i noticed last night that this bug seems to have made it's way into the trusty branch - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1508865
[17:08] <ubot5`> Launchpad bug 1508865 in ubiquity (Ubuntu) "oem-config: networking not enabled during user config" [High,Confirmed]
[17:09] <jderose> seems something is different in how the oem session is setup vs the normal install session... any suggestions where i should go digging for this?
[17:09] <cyphermox> hum, wha?
[17:11] <cyphermox> when one runs prepare for shipping, NM gets its OEM connections removed (since those are the connections for the OEM network, presumably), it will create new ones when end users uses the system
[17:11] <cyphermox> also, that bug only lists 15.10, are you saying it also happens on 14.04?
[17:32] <jderose> cyphermox: i originally filed it for 15.10 the day before it's release... but seems that code made it into the trusty branch since then
[17:33] <cyphermox> what code do you mean? that you see a bug?
[17:34] <jderose> cyphermox: networking used to work correctly when doing the first run user config after an oem install; sometime during 15.10 development it broke, and now also seems broken in trusty; i'm not sure where the bug is, haven't dug into it yet
[17:34] <cyphermox> ok
[17:34] <cyphermox> could it be that trusty got installed with proposed enabled?
[17:36] <cyphermox> (just curious, since there is one libnl3 update in proposed that broke things)
[17:38] <jderose> cyphermox: well, i have noticed that the current 14.04.4 daily ISOs have proposed enabled (i assume to get the lts-wily X and mesa bits ).. so yeah, could be because of libnl, i didn't think about that
[17:39] <cyphermox> a fixed n-m landed 2 hours ago or so
[17:39] <infinity> cyphermox: trusty is building with proposed, yes.
[17:40] <cyphermox> jderose: syslog would tell you for sure.
[17:40] <jderose> cyphermox: okay, i'll check it out when i test the next 14.04.4 daily. thanks!
[17:45] <infinity> jderose: New daily up.
[17:46] <jderose> infinity: awesome, thanks! will report back with my results shortly
[18:04] <tsimonq2> So I have learned how packages are built recently, but what about the ISOs? what tools are used? how is it automated?
[18:13] <xnox> done. and it looks like it's similar to what is done for power platforms.
[18:49] <jderose> infinity: so far so good... tested on newer hardware that uses this code path, plus on older hardware that doesn't. everything is shiny. will be testing oem first user run shortly using our imaging system
[20:36] <cyphermox_> infinity: if you're reviewing parted, multipath-tools; I just uploaded a fixed multipath-tools for the same kpartx issue that was reported for xenial.
[20:41] <jderose> infinity: finished testing, everything is shiny - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1539266
[20:41] <ubot5`> Launchpad bug 1539266 in ubiquity (Ubuntu) "14.04.4: work-around "SMBIOS-implementations-newer-than-version-2-8..." junk from dmidecode" [Medium,New]
[20:43] <cyphermox_> jderose: NM too?
[20:44] <jderose> cyphermox_: ah, forgot the check ... NM worked fine during initial install, not sure about first-run user setup... double checking that now
[20:44] <cyphermox_> k
[20:51] <jderose> cyphermox: NM seems to be working fine (tested both Ethernet and WiFi)... so the problem I hit last night must have been because of the libnl version in proposed
[20:51] <cyphermox> ok
[23:22] <tumbleweed> I've been seeing these in my seeded-in-ubuntu backend cron mail. anyone know why we have vivid images building?
[23:22] <tumbleweed> WARNING:update.py:Unexpected path: manifests/ubuntu-pd/vivid/daily-preinstalled/20160202
[23:22] <tumbleweed> WARNING:update.py:Unexpected path: manifests/ubuntu-core/vivid/daily-preinstalled/20160201.1
[23:22] <tumbleweed> WARNING:update.py:Unexpected path: manifests/ubuntu-touch/vivid/daily-preinstalled/20160202
[23:23] <infinity> tumbleweed: Because some products (phone and snappy) are still vivid-based for now.