[05:11] <pitti> Good morning
[05:55] <didrocks> good morning
[06:01] <pitti> bonjour didrocks
[06:03] <didrocks> hey pitti, how are you?
[06:07] <pitti> didrocks: quite well, thanks! juggling systemd, langpacks, and urgent apport features :)
[06:07] <didrocks> good luck!
[06:07] <pitti> et toi ?
[06:08] <didrocks> I'm fine, thanks
[06:24] <larsu> morning :)
[07:11] <pitti> hey larsu, wie gehts?
[07:12] <seb128> hey pitti & desktopers
[07:12] <seb128> pitti, wie gehts?
[07:12]  * pitti ^5s seb128, gut danke! und dir?
[07:12] <seb128> pitti, larsu is off for the morning, he's have spanish classes this week (and shifted hours)
[07:12]  * seb128 ^5s pitti back, good, danke!
[07:12] <pitti> seb128: ah, I missed his "good morning" earlier
[07:54] <seb128> hum
[07:54] <seb128> so that iso doesn't boot in kvm :-/
[07:54] <seb128> "systemd: Started udev Coldplug all Devices."
[07:54] <seb128> it just sits there
[07:55] <seb128> 13s in the boot
[08:06] <Laney> hello!
[08:07] <didrocks> morning Laney
[08:08] <seb128> hey Laney
[08:11] <seb128> pitti, is boot blocking on "systemd: Started udev Coldplug all Devices." symptomatic of some known class of system misconfiguration/bug?
[08:13] <Laney> hey didrocks & seb128
[08:13] <seb128> Laney, how is u.k today?
[08:15] <Laney> cloudy, rain later
[08:15] <Laney> and nl?
[08:18] <seb128> sunny today!
[08:18] <seb128> and not too windy, which is nice
[08:22] <pitti> seb128: not really -- that sounds like a kernel driver issue usually, but hard to tell without more logs
[08:22] <pitti> seb128: drop "quiet splash" and boot with "debug systemd.debug-shell"?
[08:23] <seb128> pitti, k
[09:18] <seb128> pitti, it hangs on http://imagebin.ca/v/25WyUYshyvpy ... no way to go to vt8 or something
[09:28] <pitti> seb128: hm, is that with a new kernel or something? since when did that happened?
[09:30] <Laney> bet a thousand euros it's the personal image
[09:30] <Laney> :)
[09:30] <seb128> Laney, you won!
[09:31] <seb128> pitti, it's a candidate of snappy personnal image I'm trying to build in kvm
[09:31] <seb128> it's the first image build that worked so can't compare to "previous versions/since"
[09:32] <pitti> seb128: ah, ok; and no VT switching? seems that something is breaking stuff really hard then :/ could you try moving /etc/sysctl.d/ away for testing if it's one of the knobs there which trigger a kernel fault or so?
[09:47] <seb128> pitti, how do you I move things away without a command line? can I do that from grub?
[09:47] <seb128> booting with upstart it hits cloud-init expection errors and seem to bug on that
[09:47] <pitti> seb128: you can't boot rescue either?
[09:47] <seb128> some mkdir failing
[09:47] <pitti> seb128: you could boot with init=/bin/bash
[09:48] <pitti> then mount -o remount,rw /
[09:48] <pitti> and h4ck stuff there
[09:48] <seb128> let me try recovery
[09:48] <pitti> I can help you in a bit, I'm just rather swamped ATM
[09:49] <seb128> don't worry, thanks for the hints
[09:49] <pitti> and Laney's "fix udisks" club is becoming a real threat too
[09:49] <pitti> seb128: in the mean time, feel free to scp it to people.c.c.?
[09:49] <seb128> pitti, it's a 10G image, going to take a while on my dsl line, going to do that over lunch
[09:50] <pitti> seb128: convert it to qcow2?
[09:50] <pitti> seb128: please don't upload a raw image :)
[09:50] <seb128> k
[09:50]  * seb128 googles
[09:51] <seb128> qemu-img convert -f raw -O qcow2
[09:51] <pitti> seb128: qemu-img convert -O qcow2 xx.raw xx.img
[09:51] <pitti> seb128: you can then also use -snapshot
[09:51] <pitti> when running the VM, to avoid modifying it
[09:52]  * didrocks has some easy-to-use scripts for this if interested
[09:52] <seb128> didrocks, converting?
[09:52] <seb128> shoot! :-)
[09:52] <didrocks> seb128: not converting, but starting with/without snapshot, using hw accel…
[09:53]  * Laney hugs pitti
[09:53] <Laney> feel free to punt that if you have some hints about where to look
[09:53] <didrocks> seb128: http://people.canonical.com/~didrocks/vms/vmcommon
[09:53] <seb128> didrocks, I'm interested!
[09:53] <didrocks> seb128: http://people.canonical.com/~didrocks/vms/ rather
[09:53] <seb128> didrocks, 'ci
[09:53] <pitti> fun how everyone has their own :)
[09:53] <didrocks> seb128: make them all executable, but vmcommon
[09:54] <seb128> k
[09:54] <pitti> http://people.canonical.com/~pitti/scripts/vm and http://people.canonical.com/~pitti/scripts/vmbr here
[09:54] <didrocks> Usage: /home/didrocks/bin/vm [--master] <image> [vm options...]
[09:54] <pitti> so that I can do "vm /my/ubuntu.img -snapshot"
[09:54] <pitti> and vmbr is with using the lxcbr0 bridge for "proper" networking
[09:54] <Laney> you crazy people
[09:54] <didrocks> interesting, mine are -snapshot by default, unless you specify --master to modify base image
[09:54] <Laney> I just load it up in virt-manager :P
[09:55] <didrocks> (as I'm using snapshot way more)
[09:55] <pitti> didrocks: yeah, I tend to do that too, good idea
[09:55] <didrocks> the vm-net is inspired by the commands you gave me some times ago, seems similar to vmbr :)
[09:55] <pitti> yeah, "vm" just searches a free port and uses that for ssh redirection, vmbr does the bridge thing
[09:57] <didrocks> Laney: remember that you are the one liking tiling wm :)
[10:57] <larsu> hi pitti :)
[10:57] <larsu> man it's nice out
[11:00] <ogra_> in berlin too ?
[11:04] <pitti> c'était gris en Bavière d'hier :(
[11:11] <larsu> ogra_: ya. Perfect.
[11:12] <ogra_> kassel too :)
[11:12] <larsu> nice :)
[11:24] <pitti> Laney: udisks is an actual regression; investigating now
[11:24] <pitti> perhaps related to newer kernel/util-linux/udev, as udisks2 itself hasn't changed in a while
[14:28] <seb128> pitti, ok, so I managed to get a debug console, tons of jobs fail to start :-/
[14:28] <seb128> journalctl has a lot of "failed dependencies", is there a way to tell which one?
[14:29] <seb128> also trying to start e.g getty@tty7 returns a job for ... canceled"
[14:29] <larsu> it is configured to only allow 6 gettys
[14:29] <larsu> this is on touch?
[14:30] <pitti> seb128: can you pastebin a journalctl output?
[14:30]  * pitti needs to run for some errands, back in 20
[14:31] <seb128> larsu, ignore getty, I can list any other job in the same situation, rc-local.service if you prefer
[14:31] <seb128> pitti, not easy, I'm in a debug console of a kvm without much access to outside
[14:31] <pitti> seb128: systemctl --failed
[14:31] <seb128> larsu, and no, it's not touch, it's snappy personnal try
[14:31] <seb128> pitti, that lists 38 failed jobs
[14:32] <seb128> but mostly mount ones
[14:32] <seb128> which I know why they fail, but that shouldn't block the system to start, should it?
[14:32] <larsu> depends on which ones fail I guess
[14:33] <seb128> larsu, /writable touch rw overwrites
[14:33] <seb128> not system partitions
[14:33] <larsu> hm?
[14:33] <seb128> hum?
[14:33] <larsu> huum?
[14:33] <seb128> what do you "hm?" about?
[14:33] <larsu> not sure what you mean by "/writable touch rw overwrites"
[14:33] <seb128> the fstab includes bindmounts for touch
[14:33] <seb128> which don't work on snappy
[14:34] <seb128> but I don't really care if those locales stay ro
[14:34] <seb128> so those jobs failing is fine to me (if that doesn't block other things)
[14:34] <larsu> ah, that makes sense
[14:34] <larsu> haven't dug that deep into systemd yet
[14:34] <larsu> but probably it's configured to not boot when mounts fail
[14:35] <seb128> is there a "retry all failing jobs?" ;-)
[14:35] <larsu> I don't think so, no :)
[14:36] <larsu> there's probably some mount target that you can activate though
[14:36]  * larsu looks
[14:38] <larsu> seb128: what does `systemctl list-units --type=targets --all` say?
[14:38] <larsu> especially for the local-fs.target
[14:39] <seb128> "unknown unit type or load state 'targets'"
[14:39] <larsu> sorry, it's --type=target
[14:40] <seb128> all is not-found
[14:40] <larsu> not good :/
[14:40] <seb128> syslog as well
[14:40] <seb128> everything else is loaded
[14:40] <seb128> local-fs is loaded inactive dead
[14:40] <seb128> which I guess is not good
[14:41] <larsu> indeed
[14:41] <larsu> should be active :)
[14:41] <larsu> you can try reactivating it, but I'm not sure why that would work now
[14:42] <seb128> yeah, a dependency job failed
[14:42] <seb128> but it doesn't say which one
[14:42] <larsu> not even in the jounral?
[14:43] <larsu> journalctl -f in a separate terminal is really handy btw
[14:44] <seb128> yeah, just too much content in there
[14:44] <seb128> like it lists 50 jobs that fail
[14:46] <seb128> k, that's ridiculous, I guess I need to clear out the fstab/writable issue first and see what remains
[14:46] <pitti> seb128: if fstab mounts fail that aren't marked with "nofail", they will fail local-fs.target and with it pretty much everything else
[14:46] <seb128> pitti, yeah, I guess it's the issue there
[14:47] <seb128> pitti, can I edit fstab and tell "retry all the jobs"? ;-)
[14:47] <seb128> or retry start local-fs ?
[14:47] <pitti> seb128: (untested) "systemctl default"
[14:47] <pitti> seb128: but might be easier to just reboot :)
[14:48] <pitti> seb128: systemctl status local-fs.target doesn't say which dependency failed? it shold
[14:51] <seb128> pitti, hum, are changed to qcow2 images stored/persistent?
[14:51] <pitti> seb128: normally yes, unless you start qemu with -snapshot
[14:52] <pitti> usually better to start with -snapshot, as you can hack away without destroying the image
[14:52] <seb128> k
[14:52] <seb128> pitti, http://picpaste.com/qemu-7fiqV7Bv.png
[14:53] <didrocks> or if you use my script… :)
[14:53]  * seb128 tries reboot
[14:54] <pitti> seb128: ok; then "systemctl --failed --type=mount" should list the failed ones
[14:54] <seb128> pitti, yeah, there is like 38 of those
[14:55] <seb128> ok, boots now to what looks like a display server fail, progress!
[14:57] <seb128> didrocks, do you remember why you didn't include http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/20-extra-files.chroot in the ubuntu-desktop-next dir?
[14:57] <seb128> that seems the issue
[14:57] <seb128> the /writable dir is missing so all the mount job fail
[14:57] <seb128> jobs*
[14:58] <pitti> seb128: ah, nice!
[14:58] <pitti> ln -sf /proc/mounts /etc/mtab
[14:59] <pitti> oh for $DEITY's sake, can we just completely eradicate /etc/mtab?
[14:59] <pitti> it seems snappy is the one thing that doesn't need to be concerned about 30 year old tools for disks/mounts administration?
[14:59] <didrocks> seb128: once sec, looking (sorry, finishing up opening a BTS issue on licensecheck)
[14:59] <seb128> didrocks, thanks
[15:00] <seb128> pitti, yeah, I just want the "mkdir -p /writable"
[15:00] <seb128> mvo_, ogra_, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/20-extra-files.chroot ... see pitti's comment about mtab
[15:00] <didrocks> seb128: maybe a mistake. I remember to have deleted one file on purpose, but I don't think it was that one
[15:01] <pitti> mvo_, ogra_: specifically, did you just add /etc/mtab "because we always did", or does something on snappy actually need it? if the latter, can we fix that?
[15:01] <ogra_> seb128, yes, and ? i'm fully with him
[15:01] <ogra_> pitti, no, i had to add it else mountall tries to set it up
[15:01] <pitti> (I'm volunteering for fixing it, FTR)
[15:01] <ogra_> we discussed that, remember
[15:01] <pitti> ogra_: aah, ok
[15:01] <seb128> ogra_, so it's needed?
[15:01] <pitti> ogra_: so that was just to quiesce mountall
[15:01] <ogra_> it needs to be a sym,link
[15:01] <pitti> but that doesn't affect snappy, just touuch?
[15:01] <ogra_> we used to do that on the s-i server when re-packing
[15:02] <ogra_> does systemd have anything handling mtab ?
[15:02] <ogra_> i think you said no
[15:02] <pitti> ogra_: our package has a "fixup" job to replace a file with a symlink
[15:02] <pitti> upstream, no
[15:02] <ogra_> then snappy wont need it
[15:02] <pitti> the last bit of util-linux was fix in 2.25 I believe (but we only turned on that option in wily)
[15:03] <pitti> ogra_: ah, I just see that we do need to adjust /lib/systemd/debian-fixup
[15:04] <pitti> we don't need /lib/systemd/system/debian-fixup.service in snappy at all, so if we are looking for some 0.01 s optimization somewhere.. :)
[15:04] <seb128> ogra_, pitti, so should I keep it or delete it?
[15:05] <pitti> seb128: delete it, and I'll fix debian-fixup.service
[15:05] <ogra_> pitti, btw, i discussed mtab with slangasek when i added that ... (we are trying to get rid of it since at least 5 years) and i think he said it would probably time to re-visit that ... iirc there are still some debs that rely on it and iots format he said
[15:05] <pitti> it'll fail on a r/o image until then, but that's harmless
[15:05] <seb128> pitti, k, what happens without your fix?
[15:06] <ogra_> seb128, /etc isnt writable ...
[15:06] <pitti> seb128: debian-fixup.service will likely fail as it can't create the /etc/mtab link
[15:06] <ogra_> so whatever would try to create it would fail
[15:06] <seb128> k, but that doesn't block the boot?
[15:06] <pitti> seb128: no, should be fine; it's just a wants
[15:06] <seb128> great
[15:07] <ochosi> Laney: pressed the power button on my new xps13 for the first time one minute ago
[15:07] <seb128> ogra_, mvo_, do you want it out of ubuntu-core as well?
[15:07] <seb128> ochosi, oh, you received it? great :-)
[15:07] <ochosi> yep! :)
[15:07] <ogra_> seb128, i dont reallyy care, just leave it in touch
[15:07] <ochosi> first time i see ubuntu OEM
[15:07] <Laney> ochosi: nice, good luck ;-)
[15:08] <ochosi> Laney: well i've already downloaded a 15.04 iso, but i still wanted to see what the ootb experience was
[15:08] <ogra_> the point of this hook is to make it possible to use plain cdimage rootfses without them being re-packaged on the s-i server
[15:08] <ogra_> i thinnk it will make mountall fall over or at least unhappy on the phone
[15:11] <ochosi> Laney: is it just Dell or do you ship chrome by default these days?
[15:11] <Laney> haha of course not
[15:11] <seb128> ochosi, just oem images
[15:11] <Laney> that's them
[15:11] <ochosi> thought so, just wanted to be sure
[15:12] <seb128> we have discussions every now and then about chromium by default but it never managed to make it default
[15:12] <ochosi> yeah, basically it'd mean replacing tb as well, no?
[15:12] <ochosi> at least to get the full benefit of dropping XUL
[15:12] <seb128> no
[15:13] <seb128> yeah, well that's not the main driver motivation to change
[15:13] <seb128> the people who want chromium default just think that it has more users/is more popular
[15:14] <ogra_> well, it will soon have less ads :)
[15:14] <ogra_> (given the new firefox ad model)
[15:16] <ochosi> Laney: whoa, who made BIOS look like Windows 95??
[15:33] <seb128> pitti, ok, next problem, the vm boots to what looks like x failing to start, but it loops on that and no way to go to a vt or anything, any clue how to debug?
[15:33] <seb128> recovery does the same
[15:34] <seb128> tried to boot with init=/bin/bash but that hangs boot and doesn't give me a shell
[15:34] <pitti> seb128: can you boot with console=ttyS0, and with qemu option "-serial stdout"
[15:34] <pitti> sorry, "-serial stdio"
[15:34] <pitti> seb128: then you will get a serial console and the boot messages there
[15:35] <pitti> and don't need to rely on the internal VTs
[15:36] <seb128> pitti, great, danke
[15:38] <seb128> arg
[15:38] <seb128> don't ctrl-C on that std :p
[15:38] <seb128> it stops the qemu
[15:40] <pitti> seb128: yeah :/
[15:40] <pitti> seb128: do you get some useful output and a getty there?
[15:41] <seb128> pitti, yes, basically xorg fails to start as expected
[15:41] <seb128> it just do it in loops for ever
[15:41] <seb128> and in recovery mode as well? (that feels wrong)
[15:41] <pitti> so lightdm keeps restarting? or the autologin does?
[15:41] <pitti> yes, recovery shouldn't start lightdm and default.target and all that
[15:42] <seb128> lightdm keeps restarting as far as I can tell
[15:43] <ogra_> seb128, hmm you dont create the firmware and modules mountpoints ?
[15:43] <ogra_> (why ?)
[15:43] <seb128> ogra_, is that needed and why?
[15:43] <seb128> because I don't understand why that's here
[15:43] <seb128> and it's undocumented
[15:43] <ogra_> to give your system access to modules and firmware files :)
[15:43] <seb128> so I try without and if it's needed I'm going to know why and document it
[15:43] <ogra_> that is where the initrd mounts them
[15:43] <ogra_> s/mounts/bind mounts/
[15:44] <seb128> so it's needed?
[15:44] <ogra_> if you plan to use any modules or firmware ... yes
[15:44] <ogra_> well, if you always only use system-image re-packed rootfses it will currently still work because the s-i server re-packs the whole rootfs just to add these three dirs
[15:45] <ogra_> but we are planning to drop that code from there
[15:45] <ogra_> this hook was in preparation of the droppage
[15:45] <seb128> oh ok
[15:45] <ogra_> so if you want it future proof, better create these two dirs too
[15:46] <seb128> I was going to say, livecd-rootfs copy things to those dirs
[15:46] <seb128> k
[15:46] <seb128> noted for the next upload, thanks
[15:46] <ogra_> no, it doesnt ... they are just nodes for mountpoints
[15:46] <ogra_> (firmware and modules come from the device tarball, separate from the rootfs)
[15:47] <seb128> ogra_, well, on the booted image those dirs exist and have content from the kernel image deb
[15:47] <ogra_> http://bazaar.launchpad.net/~ubuntu-system-image/ubuntu-system-image/server/view/head:/lib/systemimage/generators.py#L525
[15:47] <ogra_> thats the code in system-image the hook replaces
[15:47] <ogra_> (and which we will drop)
[15:48] <seb128> pitti, yeah, according to the journal lightdm does "Failed with result 'exit-code'" and it keeps retrying
[15:48] <seb128> ogra_, k, thanks
[15:51] <mvo_> seb128: could you do me a favour and reject my accidental golang-gettext from vivid-proposed. that was a mistake
[15:52] <seb128> mvo_, done
[15:52] <mvo_> ta
[15:53] <seb128> yw
[15:56] <ochosi> Laney: oh wow, installing 15.04 cleanly doesn't seem like much fun... (uefi and no wifi)
[15:56] <ochosi> and sry, i'll stop spamming you with this now
[15:56] <Laney> ochosi: I just got bcmwl on there manually
[15:57] <Laney> and it is installed in efi mode
[15:57] <ogra_> 15.04 isnt even usable on the old XPS13
[15:57]  * ogra_ will actually do a reinstall of trusty on the weekend
[15:58] <ochosi> Laney: switching to legacy left me with: floppy, cd/dvd, usb and mini-sd as boot options...
[16:58] <seb128> Laney, can you retry desktop-next iso build?.
[16:58] <Laney> try using your powers?
[17:00] <seb128> Laney, where is the button?
[17:00] <seb128> I don't see any control on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next
[17:01] <ogra_> ssh nusakan :)
[17:01] <Laney> wrong and wrong
[17:01] <Laney> go to http://iso.qa.ubuntu.com and log in
[17:01] <Laney> then go to "Wily daily"
[17:01] <Laney> tick the boxes next to the things you want to rebuild
[17:01] <ogra_> pfft
[17:02] <seb128> shrug
[17:02] <seb128> login fails "The name seb128 is already taken."
 points to http://iso.qa.ubuntu.com/user/password
[17:02] <seb128> which is "The resource you tried to access doesn't exist. This can happen because of an invalid link or because of a bug."
[17:02] <seb128> great
[17:02] <seb128> quality website
[17:03] <Laney> be charitable please
[17:03] <seb128> sorry ;-)
[17:03] <Laney> probably go ask stgraber, that is his product
[17:03] <seb128> can you click for me then? ;-)
[17:04] <Laney> fine, if you go ping him so that I don't have to keep doing this forever
[17:04] <Laney> probably good to see if doing it via this button works first anyway ...
[17:04]  * Laney always did it over ssh before
[17:04] <seb128> Laney, done on -devel
[17:05] <Laney> thx
[17:05] <seb128> thank for pointing me to the website
[17:07] <Laney> didn't work anyway
[17:07] <Laney> #FAIL
[17:09] <seb128> :-/
[17:09] <seb128> stgraber is looking at my issue
[17:09] <seb128> it's better I'm older than the sso
[17:09]  * seb128 dinosaur
[17:32] <Laney> :)
[17:32] <Laney> I retried it the old way for now
[17:34] <seb128> Laney, thanks


[06:41] <dholbach> good morning
[06:46] <mvo> elopio: hi, if you are still up, I wonder if I should top-approve sergios branches for snapcraft or if he prefers to do that himself
[06:46] <mvo> hey dholbach, good morning
[06:51] <dholbach> thanks mvo
[07:04] <fgimenez> good morning
[07:27] <zyga> good morning
[08:19] <Chipaca> goood morning!
[08:40] <ogra_> mvo, do we want to wait til there is any feedback on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791661 for the SRU of bug 1323732 ? seems a user has issues creating users in 15.04 (on the ML)
[08:41] <ogra_> or should we perhaps just push it to the PPA
[08:53] <mvo> ogra_: this is in wily, no?
[08:54] <mvo> ogra_: aha, you mean for 15.04? yeah, going the ppa route is fine here I think
[09:09] <Chipaca> mvo: o/
[09:09] <Chipaca> mvo: so, comapreDirs
[09:09] <mvo> hey Chipaca
[09:09] <Chipaca> mvo: compares the output of ls
[09:09] <mvo> Chipaca: no, compardirs is terrible
[09:09] <Chipaca> mvo: that's a huge red flag
[09:09] <Chipaca> but
[09:09] <Chipaca> BUT
[09:09] <mvo> Chipaca: I was wondering about https://code.launchpad.net/~mvo/snappy/snappy-lp1468831-race/+merge/269155
[09:09] <Chipaca> because it's a controlled test scenario
[09:09] <Chipaca> it wouldn't be too terrible
[09:09] <Chipaca> however
[09:09] <Chipaca> it's comparing the ctimes, which we don't care about
[09:09] <Chipaca> isntead of the mtimes or the atimes which we apparently do care about
[09:10] <mvo> oh, sorry, I get it now, its connected
[09:10] <Chipaca> also it
[09:10]  * mvo shuts up and listens
[09:10]  * Chipaca derails
[09:11] <Chipaca> i was going to say "also it compares the time format instead of asking ls to use something smarter", but i'm not sure that would be a win
[09:11] <Chipaca> I mean, you can tell ls to --time-style=+%s for example
[09:11]  * mvo nods
[09:11] <Chipaca> but if we're just comparing for equality that's fine
[09:12] <Chipaca> and, given the comment about atime/mtime in RSyncWithDelete, I think we *do* care about equality
[09:12] <Chipaca> so that means the test is wrong, and the fix is hiding it instead of fixing it :)
[09:12] <Chipaca> so
[09:12] <Chipaca> rant mode off
[09:12] <Chipaca> fix mode on
[09:12] <Chipaca> i guess what we want is to have ls print the atime and the mtime, if those are truly what we care about
[09:12] <mvo> yeah, absolutely agreed, I will reject the branch
[09:14] <Chipaca> hm, ls can't print both atime and mtime at the same time
[09:14] <elopio> fgimenez: ping. I made some good progress on the subunit repo. Can you please check the pull requests? https://github.com/elopio/subunit/pulls
[09:15] <elopio> I couldn't find how to do something like prerequisits in git, so if you don't start from the older it might be a mess.
[09:16] <fgimenez> elopio, ok np i'll take a look
[09:16] <Chipaca> mvo: default for ls is mtime (i thought it was ctime, for some reason), so we're not preserving it in RSyncWithDelete?
[09:17] <mvo> Chipaca: hm, its using cp -a
[09:18] <Chipaca> mvo: but for single files
[09:18] <Chipaca> mvo: directories it's making itself
[09:18]  * Chipaca wonders why that isn't a single cp call
[09:18] <Chipaca> ah, because of the filesareequal check
[09:18] <Chipaca> so
[09:18] <Chipaca> i know how to unbreak the test, now :)
[09:19] <mvo> yeah, the dirs are indeed missing
[09:19] <mvo> yay, thanks Chipaca
[09:19] <mvo> and sorry for the trouble :/
[09:19] <Chipaca> hah. no worries.
[09:19] <Chipaca> sorry for the rant
[09:20] <mvo> all good, terrible code there
[09:29] <Chipaca> yuss
[09:36] <Chipaca> mvo: how does http://pastebin.ubuntu.com/12244247/ look?
[09:38] <mvo> Chipaca: much nicer
[09:39] <Chipaca> mvo: OTOH i could move that to CopyFile
[09:39] <Chipaca> mvo: and just use CopyFile here
[09:39] <Chipaca> but maybe make it different branches
[09:39]  * Chipaca agrees with himself already
[09:40] <mvo> heh
[09:40] <mvo> cleanup++
[09:42] <Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/fix-1468831/+merge/269728 would be that then
[09:45] <mvo> \o/
[09:54] <Chipaca> mvo: not top-approving because integration tests
[09:56] <Chipaca> oooh, mp failed?
[09:58] <mvo> helpers/helpers.go:503: impossible type assertion:
[09:58] <mvo>  *syscall.Stat_t does not implement os.FileInfo (missing IsDir method)
[09:58] <mvo> looks like it
[10:00] <Chipaca> dah
[10:00] <Chipaca> mvo: forgot .Sys() :(
[10:01] <Chipaca> mvo: fixed
[10:04] <Chipaca> mvo: in https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176 you say elopio's comment is addressed, but .. you forgot to push it?
[10:04] <mvo> Chipaca: indeed, sorry again
[10:05]  * Chipaca takes a break
[10:13] <sergiusens> mvo: thanks for the reviews!
[10:17] <ogra_> sergiusens, wrt bug 1490741 ... shouldnt u-d-f bail out when using a RPi2 snap with a generic tarball ?
[10:18] <ogra_> or did i do something rong with the meta data in the pi2 snap ?
[10:18] <ogra_> *wrong
[10:21] <sergiusens> ogra_: it shouldn't fail, no; it will use the one from s-i
[10:21] <ogra_> thats bad
[10:21] <sergiusens> ogra_: that is the catch to --developer-mode, no hand holding
[10:22] <sergiusens> ogra_: yeah, you need to put this upstream ;-)
[10:22] <ogra_> ah
[10:22] <ogra_> yeah, i think we need a mechanism to define what device tarballs an oem snap can be used with
[10:22] <sergiusens> ogra_: how would you start enabling a board if not?
[10:23] <sergiusens> ogra_: well, with what mvo is doing right now and with what I did here http://blog.sergiusens.org/posts/Recovering-Ubuntu-Core/ that is no longer going to be necessary
[10:23] <ogra_> oh, it should all be open while developing ... but package.yaml should have an optional enttry that can bind us to a certain device tarball
[10:23] <sergiusens> ogra_: but the device tarbal is just a tar
[10:23] <ogra_> currently :)
[10:24] <sergiusens> ogra_: when it becomes a snap, I hope the gadget would define it
[10:24] <ogra_> yeah
[10:24] <sergiusens> ogra_: since it would be pulled from the store, so it needs the name
[10:27]  * ogra_ turns the u-d-f task on the bug invalid but keeps the snappy one open then
[10:37]  * Chipaca is trying to figure out https://code.launchpad.net/~fgimenez/snappy/setenv-closure-redefinition/+merge/269717
[10:41]  * ogra_ twiddles thumbs waiting for shadow to be published in the PPA
[10:41] <fgimenez> Chipaca, yes, it's a bit involved :)
[10:42] <fgimenez> Chipaca, in build_test we used var definitions for testing the dependency calls
[10:43] <Chipaca> mhmm
[10:43] <Chipaca> fgimenez: but here's the thing
[10:43] <Chipaca> fgimenez: a var is not a closure
[10:43] <Chipaca> there's nothing to "refresh"
[10:44] <fgimenez> Chipaca, well, maybe the wording is not correct, we first define the var here http://bazaar.launchpad.net/~fgimenez/snappy/setenv-closure-redefinition/view/head:/_integration-tests/testutils/build/build.go#L46
[10:45] <fgimenez> Chipaca, when we call this afterwards, it doesn't take the value of the environment variables if we don't redefine it
[10:45] <fgimenez> Chipaca, this used to work before 1.5
[10:46] <Chipaca> hmm
[10:46] <Chipaca> fgimenez: and you get the same error every time without this change?
[10:47] <fgimenez> Chipaca, yep
[10:47] <Chipaca> fgimenez: and if you do "export GOMAXPROCS=1" before running the test?
[10:47] <fgimenez> Chipaca, let me try..
[10:48] <Chipaca> fgimenez: because what changed was that in 1.5 GOMAXPROCS defaults to the number of cores; before it was 1
[10:48] <Chipaca> fgimenez: and getenv is per-process
[10:49]  * Chipaca writes a small testcase to check this just in case
[10:49] <fgimenez> Chipaca, ah! ok, shouldn't GOARCH be the same for all of them?
[10:55] <fgimenez> Chipaca, i'm getting this http://paste.ubuntu.com/12244578/ after removing the var redefinition line
[10:57] <Chipaca> fgimenez: i'll dig into it in a bit
[10:59] <fgimenez> Chipaca, ok thanks! :)
[11:11] <Chipaca> oooooh
[11:12] <Chipaca> fgimenez: shouldn't osGetenv return something?
[11:12] <Chipaca> i mean
[11:12] <Chipaca> fgimenez: in the tests
[11:12] <Chipaca> fgimenez: you're rewriting osGetenv
[11:12] <Chipaca> fgimenez: with fakeOsGetenv
[11:12] <Chipaca> fgimenez: that does not return anything
[11:12] <Chipaca> i.e. it always returns an empty string
[11:14] <Chipaca> fgimenez: may i suggest you keep an environ map[string]string in the test, and set things in it from fakeSetenv, and return things from it in fakeGetenv?
[11:15] <fgimenez> Chipaca, yes that makes a lot of sense, let me take a look
[11:15] <Chipaca> actually making it a map[string]struct{string, int, int} would be the way I'd do it, actually
[11:16] <Chipaca> fgimenez: i'll show you what i mean in a diff, give me a few
[11:40] <Chipaca> fgimenez: something like http://pastebin.ubuntu.com/12244793/ might work, but it would involve changing a number of tests appropriately
[11:41] <Chipaca> fgimenez: advantage of this is you have a single place where you track reads, writes and current value of the environment
[11:41] <Chipaca> fgimenez: disadvantage might be that it's a bigger change from where the code is right now
[11:43] <Chipaca> fgimenez: whereas the simpler change would be http://pastebin.ubuntu.com/12244813/
[11:43] <Chipaca> fgimenez: i feel it'll make things harder to follow in the long term, but not particularly strongly :)
[11:44] <Chipaca> fgimenez: also note you would have spotted this error earlier if you didn't use the "bare return" thing as much as you do
[11:45] <fgimenez> Chipaca, yep :) thanks for that, i was thinking in the latter option that you proposed, i'll put hands on it
[11:45] <Chipaca> fgimenez: in both cases note i haven't tested the code :)
[11:46] <fgimenez> Chipaca, np :)
[11:50]  * Chipaca is now on lunch break
[13:54] <Chipaca> pitti: i have the silliest systemd question, and sadly for you your name is soldered to systemd in my mind
[13:54] <pitti> hey Chipaca -- heh :)
[13:54] <pitti> Chipaca: you could ask anyone in the vast systemd maintenance team in Ubuntu!
[13:54] <Chipaca> pitti: if I do, e.g.,: sudo journalctl -u urfkill -o json-pretty
[13:55] <Chipaca> pitti: it returns a series of lines, with a json document per line
[13:55] <Chipaca> um
[13:55] <Chipaca> json, not json-pretty
[13:55] <Chipaca> :)
[13:55] <Chipaca> pitti: json-pretty to read it, json to parse it :)
[13:55] <Chipaca> pitti: anyway. you get that, a series of json objects
[13:55] <pitti> right
[13:55] <pitti> looking at it here, for systemd-udevd, as i don't have urfkill
[13:55] <Chipaca> pitti: in the first one, the systemd unit is in the "UNIT" key
[13:56] <Chipaca> pitti: in the following ones, it's in "_SYSTEMD_UNIT"
[13:56] <Chipaca> pitti: this feels like a bug
[13:56] <Chipaca> pitti: but I don't know
[13:56] <pitti> Chipaca: it for sure is
[13:56] <Chipaca> *gasp*
[13:56] <pitti> I mean, I don't see how this would be deliberate
[13:57] <Chipaca> well, it's certainly not what's documented :)
[13:57]  * Chipaca updates his system just in case
[13:57] <pitti> Chipaca: it's the same with -o verbose or export, i. e. not just a presentation problem; I guess it's actually wrong in the db
[13:58] <pitti> yep, should always be _SYSTEMD_UNIT as per systemd.journal-fields(7)
[13:58] <Chipaca> pitti: i wonder whether it's different on purpose, so you get the unit the first time and don't bother if it's not there because it's the same?
[13:58] <Chipaca> that sounds contrieved though
[13:58] <Chipaca> and aggregates poorly
[13:59] <pitti> yeah
[13:59] <pitti> Chipaca: do you mind filing it at https://github.com/systemd/systemd/issues or should I proxy it for you?
[13:59] <Chipaca> pitti: i wouldn't mind filing it
[14:00] <pitti> Chipaca: cool, thanks; if this is blocking you I'll see to fix it this week, but I suppose it's easy enough to work around for now?
[14:00] <Chipaca> it is
[14:01] <Chipaca> pitti: it's also only the first one for any service, for you?
[14:01] <pitti> Chipaca: yes, consistently (tried 3)
[14:02] <pitti> Chipaca: in a fresh VM I see two UNIT=, though
[14:02] <pitti> but either way, this is inconsistent and undocumented
[14:02] <Chipaca> pitti: I'll file the bug, you add that to it :)
[14:03] <pitti> ack
[14:05] <Chipaca> pitti: https://github.com/systemd/systemd/issues/1106
[14:07] <pitti> Chipaca: thanks, I'll watch what upstream says and if appropriate look into it
[14:09] <Chipaca> pitti: ta
[14:34] <Chipaca> pitti: there you go then
[14:35] <pitti> Chipaca: ah! so this is "message from pid 1 about unit foo" vs. "message from unit foo"
[14:36] <Chipaca> pitti: yep, so it might be a bug in documentation as opposed to implementation
[14:36] <Chipaca> as the docs don't mention UNIT nor any other mysterious "couple of other keys"
[14:36] <pitti> Chipaca: yeah, I just followed up wrt. that
[14:36] <Chipaca> heh. jinks.
[14:36] <Chipaca> jinx*
[14:37] <Chipaca> anyway, you know what time it is?
[14:37] <Chipaca> time for a cuppa tea
[14:37] <pitti> and again
[14:37] <pitti> Chipaca: good idea!
[14:37] <pitti> Chipaca: I was about to yell "Tool time!" :)
[14:57] <rickspencer3> is there a bug # for snappy-remote install doesn't work with webdm?
[14:57] <Chipaca> pitti: do you know what they mean wrt trusted/untrusted fields?
[14:57] <pitti> "Fields prefixed with an underscore are trusted fields, i.e. fields that are
[14:57] <pitti>        implicitly added by the journal and cannot be altered by client code."
[14:58] <Chipaca> pitti: where's that?
[14:58] <pitti> Chipaca: in man systemd.journal-fields
[14:58] <Chipaca> pitti: gotcha
[14:58] <ted> sergiusens, Do you have a snapcraft branch where you're removing the ubuntu plugin?
[14:58] <pitti> Chipaca: so, a client using libsystemd journal_* can set arbitrary fields, but not those prefixed with _
[14:59] <Chipaca> pitti: k :)
[14:59] <sergiusens> ted: not pushed yet
[14:59] <sergiusens> ted: still in the works (writing tests)
[14:59] <ted> sergiusens, Can you push so I can base off of that?
[15:02] <Chipaca> rickspencer3: how does it not work?
[15:02] <Chipaca> rickspencer3: http://pastebin.ubuntu.com/12246078/
[15:03] <rickspencer3> Chipaca, the last time I tried it, it didn't work, and I was told that it was a bug
[15:03] <rickspencer3> oh
[15:03] <Chipaca> rickspencer3: ah, maybe sergiusens knows more then
[15:04] <rickspencer3> Chipaca, I did $snappy-remote install --url=ssh://webdm.local or something
[15:04] <rickspencer3> Chipaca, oh
[15:04] <rickspencer3> no, you are installing webdm
[15:04] <rickspencer3> I meant installing a different snap using webdm
[15:04] <rickspencer3> instead of the ip address
[15:08] <ogra_> you mean using avahi ;)
[15:14] <ogra_> (webdm.local is an avahi address, perhaps the go implementation that the webdm package ships has issues)
[15:15] <Chipaca> I think it's snappy-remote doing something smart with --url that does not include avahi
[15:15] <Chipaca> it also does not hand it straight off to ssh, which means you can't use fake ssh hostnames
[15:15] <ogra_> also note that you can only have the same avahi address once in your network ... i.e. if you have a BBB on the same network running another webdm instance that calls for issues
[15:15] <Chipaca> *also* also note I don't think avahi will work to kvm
[15:18] <Chipaca> mvo: wrt bug 1491011, if your snappy doesn't have a service, you don't have the fix. If it does have service, and you're seeing this, then caca.
[15:19] <mvo> Chipaca: uh, I'm not sure I understand, thats webdm, it has a service
[15:19] <Chipaca> mvo: yes
[15:19] <Chipaca> mvo: what does "snappy service status webdm" print
[15:20]  * Chipaca forgot the 'status' verb
[15:20] <ogra_> i think i said before that i dont think it is wrong if webdm doesnt start when no network is available
[15:20] <mvo> Chipaca: its on 15.04, do we have snappy service there already?
[15:20] <ogra_> what *is* important though is that it starts as soon as you connect network
[15:20] <Chipaca> mvo: then you don't have the network brouhaha fix :)
[15:20] <mvo> Chipaca: aha!
[15:20] <mvo> Chipaca: now I understand
[15:20] <Chipaca> mvo: it's not backported, and landed in wily together with "service", hence that question
[15:21] <mvo> Chipaca: cool, do you happen to remember the bugnumber?
[15:21] <mvo> Chipaca: I can have a look in a bit then
[15:23] <Chipaca> bug 1466672
[15:24]  * Chipaca hugs --fixes
[15:24] <Chipaca> mvo: ^
[15:24] <mvo> ta
[15:24] <mvo> I will do a backport in a bit
[15:30] <ogra_> zyga, you had issues wirth missing firmware IIRC ... there is a http://people.canonical.com/~ogra/snappy/test/device-pi2-0.16.tar.xz that contains all of linux-firmware now
[15:30] <ogra_> (in case you feel like trying it)
[15:38] <Chipaca> zomg, next week school starts again
[15:41] <elopio> fgimenez: I'm not sure how to make an anonymous struct inside a for.
[15:41] <elopio> that sounds scary too.
[15:42] <elopio> fgimenez: I was copying the style from here: https://github.com/golang/go/wiki/TableDrivenTests
[15:44] <fgimenez> elopio, yes :) it's just to replace the flagtest var definition in that example with the struct itself, readability could suffer though
[15:45] <fgimenez> elopio, i've seen an example here http://talks.golang.org/2015/tricks.slide?utm_source=golangweekly&utm_medium=email#12
[15:46] <tedg> sergiuse1s: Not sure if it got lost in the various disconnects, can you push your branch so I can build on it?
[15:46] <elopio> fgimenez: yes, -1 for that. Maybe I'm too used to testscenarios.
[15:46] <tedg> sergiuse1s: Should be fine without tests for what I need.
[15:46] <elopio> what I think we should do is to add scenarios to go check.
[15:47] <fgimenez> elopio, that would be great
[15:49] <zyga> ogra_: thanks a lot, I'll check it out
[15:50] <ogra_> thanks
[15:51] <sergiuse1s> tedg: oh, I don't think I can share just yet, still not glued in
[15:53] <tedg> sergiuse1s: Hmm, okay. The problem I'm running into is needed a global package library. Putting things in python-project causes them to conflict with python the base one.
[15:55] <sergiuse1s> tedg: I think I understand, going to start the drive back home, we can continue then
[15:58] <tedg> sergiuse1s: K
[16:07] <tedg> barry: Reading through the pip docs and learning about wheels. Do you think we need to support those in Snapcraft?
[16:08] <tedg> Not sure how often they're used, or if everyone just uses the source versions.
[16:11] <barry> tedg: yes, i think so.  the python ecosystem is definitely transitioning to wheels, although for python modules which include extension modules (e.g. sharedlibs), it's problematic on linux.  there's ongoing discussions about how that will work.  pure python, np
[16:15] <tedg> barry: Okay. But as I'm reading more that seems separate from pip though, right? Pip can just build wheels?
[16:20] <fgimenez> nice evening everyone o/
[16:21] <barry> tedg: yes.  pip will build wheels, although our debuntu version of pip is in serious need of an update (it's on my todo)
[16:24] <tedg> barry: Is there any reason I'd want to have pip build wheels and install from those? Seems like a no-op for our purposes.
[16:46] <ogra_> mvo, hmm, did i hand you https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1490608 yet ? i know you asked for it
[16:46] <mvo> ogra_: yes, you mentioned it and I failed to look at it
[16:46] <ogra_> i guess thats foundations material anyway, no ?
[16:47] <mvo> well, yes, I would still guess if someone of us does it it will be faster
[16:47] <mvo> they are usually super busy
[16:47] <ogra_> nah, they just pretend to ... its all scripted :P
[17:34] <barry> tedg: it may not matter in practice.  i think pip wheelifying packages is mostly an implementation detail
[17:42] <ali1234> o/
[17:43] <ogra_> hey ali1234
[17:44] <ali1234> so my problem is essentially that i want all the read-only goodness of snappy, but my hardware is designed around the raspberry pi model a+, and the 2b simply won't fit
[17:45] <ali1234> debian jessie appears to have the same version of golang and ubuntu 15.04
[17:45] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/vivid-preinstalled-core-armhf.manifest ...
[17:45] <ogra_> thats the list of files ...
[17:45] <ali1234> i've seen those manifest files
[17:45] <ali1234> but no idea what to do with them
[17:46] <ali1234> like, what tkes the list and builds an image?
[17:46] <ogra_> you would want to build them on raspbian
[17:46] <ali1234> i'd expect most of them already exist
[17:46] <ali1234> raspbian has literally everything debian has afaik
[17:46] <ogra_> we use live-build to build the images ... with modifications and configs living in the livecd-rootfs package
[17:47] <ogra_> there is an old project of mine that i'm about to re-vivie for "building at home"
[17:47] <ogra_> https://launchpad.net/project-rootstock-ng
[17:47] <ali1234> hah, rootstock, i remember that
[17:47] <ogra_> that should allow you to build a rootfs
[17:48] <ogra_> beyond the rootfs you need a device tarball http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/ check the armhf one here ...
[17:48] <ali1234> what does that do?
[17:49] <ogra_> carry kernel, firmware blobs and modules
[17:49] <ali1234> rootfs just manages updates and things?
[17:49] <ogra_> no
[17:49] <ogra_> snappy manages the updates
[17:49] <ogra_> currently using the same mechanism the phones use (system-image)
[17:49] <ogra_> soon switching away from that ... (everything becomes a snap )
[17:50] <ogra_> beyond rootfs and device tarball you need an oem snap ... that has your bootloader setup
[17:51] <ogra_> once you have these three you can feed them into ubuntu-device-flash which generates an image for you
[17:51] <ogra_> out of these three files
[17:51] <ogra_> your prob will be that you cant really use the store, even if you get it up and running ...
[17:51] <ali1234> yeah... i've seen the ubuntu-device-flash stuff too
[17:51] <ali1234> i'm not concerned about using the store, i want to package my own software
[17:51] <ogra_> all binaries in the store are built for armhf indeed
[17:52] <ali1234> my only dependency is gstreamer
[17:52] <ali1234> which i assume i'd have to bundle anyway
[17:52] <ogra_> yeah
[17:54] <ali1234> so step 1 would be to check if debian has all the packages from the device image manifest and then port any that are missing?
[17:54] <ogra_> right
[17:55] <ogra_> a lot of the magic is in the initrd, in the snappy binary and in systemd units ...
[17:55] <ali1234> "system-image-snappy-common" - bet debian doesn't have that...
[17:55] <ogra_> (nad in the bootloader setup too)
[17:55] <ali1234> is that package the snappy tool itself?
[17:56] <ali1234> no, that's ubuntu-snappy
[17:56] <ogra_> i think the ubuntu-snappy package buulds it
[17:58] <sergiusens> tedg: oh, you are working on the pip plugin, no wonder your questions, I guess you missed the comment, but zyga was close to having a pip plugin in place
[17:59] <ali1234> okay well that's something to be going with, thanks
[18:00] <ogra_> ali1234, just come back if you have more questions (you surely will) ... i'm curious how that experiment turns out :)
[18:01] <tedg> sergiusens: Oh, okay. Perhaps I should look at a different one then. That was at the top of the backlog.
[18:02] <sergiusens> tedg: well no worries if you decide to tackle it, not sure zyga has the same agenda we do, but he said he was close
[18:03] <tedg> sergiusens: I can pause what I'm doing to talk to him tomorrow (I think he's EU timezone) and start on another plugin.
[18:04] <tedg> sergiusens: I think that we really want to have the shared root ubuntu package support for it, otherwise you have to play with the python plugin.
[18:04] <tedg> sergiusens: Which really doesn't make a lot of sense.
[18:09] <tedg> Haha, I lose. The ROS instructions depend on pip :-)
[18:24] <rickspencer3> does anyone know any tricks regarding getting wifi to work on the bbb?
[18:25] <ogra_> rickspencer3, plugging in a device we ship the deriver for and following https://wiki.debian.org/WiFi/HowToUse#Command_Line should be enough i think
[18:26] <ogra_> *driver
[18:26] <rickspencer3> hmmm, I think I did that
[18:27] <ogra_> is the device detected ? do you see an interface for it in /proc/net/dev after you plugged it in ?
[18:34] <pindonga> hi, I'm getting this from snapcraft when building a package using the ubuntu plugin... any idea what I'm missing? no repository found in /etc/apt/sources.list or sources.list.d at /usr/bin/dget line 355.
[18:34] <rickspencer3> ogra_
[18:34] <rickspencer3> $ ls /proc/net/dev
[18:34] <rickspencer3> /proc/net/dev
[18:34] <ogra_> cat
[18:35] <ogra_> (meow :) )
[18:35] <rickspencer3> just lo and eth0
[18:35] <ogra_> ah, smells like either the driver or some sirmware is missing
[18:35] <ogra_> *frimware
[18:35] <ogra_> bah !
[18:35] <ogra_> check syslog when plugging it in
[18:36] <rickspencer3> ogra_, http://pastebin.ubuntu.com/12247479/
[18:38] <ogra_> rickspencer3, ah, ralink ...
[18:38] <rickspencer3> ogra_, not supported?
[18:38]  * rickspencer3 sobs
[18:38] <rickspencer3> I bought it on a whim because it was specifically supported by bbb debian
[18:39] <ogra_> no, just a constant source of pain :)
[18:41] <rickspencer3> ogra_, sorry, I don't quite grock, are you saying I am out of luck with this particular dongle?
[18:41] <ogra_> seems to need the mt7601u module
[18:42] <rickspencer3> ogra_, ok, what should I do? buy a different dongle?
[18:43] <beuno> rickspencer3, some guy on the mailing list had the same problem
[18:43] <beuno> there might not be a dongle that has the module in our kernel
[18:43] <ogra_> rickspencer3, gimme a bit to read up about it :)
[18:44] <rickspencer3> well, I know that at least one person got at least one dongle working with rpi2 and snappy
[18:44] <beuno> rickspencer3, yeah, the rpi2 kernel comes with some modules
[18:44] <ogra_> hmm, so it should be supported by rt2800usb ...
[18:44] <ogra_> which we also ship in the device tarball
[18:44] <rickspencer3> ogra_, well, this image is oooold
[18:44] <ogra_> (on RPi2 the firmware is missing though )
[18:45] <ogra_> rickspencer3, uname -r ?
[18:45] <rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ uname -r
[18:45] <rickspencer3> 3.19.0-23-generic
[18:45] <ogra_> not that old then
[18:45] <rickspencer3> well, I run updates :)
[18:46] <ogra_> try sudo modprobe rt2800usb
[18:46] <ogra_> and see if that thinks it knows the device (re-plug if needed)
[18:46] <rickspencer3> lol
[18:46] <rickspencer3> $ try sudo modprobe rt2800usb
[18:46] <rickspencer3> -bash: try: command not found
[18:46] <ogra_> haha
[18:47] <rickspencer3> ogra_, I reran  cat /proc/net/dev
[18:47] <rickspencer3> still just lo and eth0
[18:47] <ogra_> and syslog
[18:47] <ogra_> (also after re-plugging with the module loaded)
[18:48] <rickspencer3> Sep  1 18:46:29 localhost kernel: [ 1300.551733] usbcore: registered new interface driver rt2800usb
[18:48] <ogra_> nothing else
[18:48] <ogra_> ?
[18:48] <ogra_> even when re-plugging the device ?
[18:49] <rickspencer3> ogra_, no, everything looks the same
[18:49] <ogra_> the musb-hdrc error in your paste actually indicates a deeper prob with USB i think
[18:49] <rickspencer3> /proc/net/dev, syslog, etc...
[18:49] <rickspencer3> awesome!
[18:49] <ogra_> i guess thats one for ppisati
[18:51] <ogra_> rickspencer3, if you want to try the same on the RPi, i have a device tarball in preparation that contains all wifi firmware we have at http://people.canonical.com/~ogra/snappy/test/device-pi2-0.16.tar.xz ... perhaps the Pi works better here
[18:52] <rickspencer3> ogra_, ok, rpi2 is coming up next
[18:52] <ogra_> the beagle musb issues are legendary :)
[18:52]  * rickspencer3 finishes transferring bbb to new case
[18:52] <ogra_> and as old as homers oddisey i think
[18:53] <rickspencer3> ogra_, not sure what you mean, is it something that we need to fix generally, is it just my specific dongle?
[18:53] <ogra_> rickspencer3, there are general issues with USB on BBB since forever
[18:54] <rickspencer3> ogra_, right, but are you saying we are out of luck on bbb, or that we need to hack around the issues?
[18:54] <ogra_> it got a lot better over the years but there are still issues
[18:54] <ogra_> well, forst of all you should file a bug and let ppisati know
[18:54] <ogra_> so he can take a look
[19:05] <rickspencer3> ogra_, anything else useful I can add to this?
[19:05] <rickspencer3> https://bugs.launchpad.net/snappy/+bug/1491094
[19:09] <ogra_> rickspencer3, i extended the subject line and will point paolo to it tomorrow
[19:10] <rickspencer3> thanks ogra_


[16:00] <coreycb> o/
[16:00] <gaughen> it's me!!!
[16:00] <smoser> horay!
[16:00] <caribou> \o
[16:00] <rharper> \o
[16:01] <beisner> o/
[16:01] <thedac> \o
[16:01] <gaughen> #startmeeting ubuntu-server-team
[16:01] <meetingology> Meeting started Tue Sep 29 16:01:36 2015 UTC.  The chair is gaughen. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:01] <gaughen> #topic Review ACTION points from previous meeting
[16:02] <gaughen> I don't see any action points from last time.
[16:02] <rharper> yay, we finally moved on from asking rharper about numad
[16:02] <gaughen> #topic Wily Development
[16:02] <gaughen> #link https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
[16:02] <gaughen> ha
[16:02] <gaughen> is thedac on the list to run this meeting?
[16:03] <coreycb> gaughen, no but he probably should be
[16:03] <thedac> so far I have hidden away
[16:03] <gaughen> final beta has passed
[16:03] <gaughen> thedac, I'm putting you on the list. I'm kind that way.
[16:03] <gaughen> I'll put you on the end... but before me ;-)
[16:03] <thedac> I am reconsidering our friendship :p
[16:03] <gaughen> final release is in less than a month - AAAAH!
[16:04] <gaughen> final freeze is Oct 15
[16:04] <gaughen> #subtopic Release Bugs
[16:04] <gaughen> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-w-tracking-bug-tasks.html#ubuntu-server
[16:05] <gaughen> don't think there's anything worth mentioning  on the list
[16:05] <gaughen> #topic Server & Cloud Bugs (caribou)
[16:05] <gaughen> caribou, you have anything to say?
[16:05] <gaughen> beuller
[16:05] <caribou> hi ?
[16:05] <gaughen> hello
[16:05] <gaughen> any bugs you want to mention
[16:05] <caribou> yes, bug #1496317 is up for review
[16:05] <smoser> oh nice.
[16:05] <caribou> apw is supposed to look at it soon
[16:06] <caribou> tl;dr create smaller initrd.img in /boot/kdump
[16:06] <arges> caribou: if it gets uploaded before tomorrow, I'll sru-review it : )
[16:06] <caribou> arges: then go & harrass apw about it :)
[16:06] <caribou> arges: I'd like a few eyes on it. Adding stuff to /boot can be seen as invasive
[16:07] <arges> yea
[16:07] <caribou> gaughen: other than that I'm good
[16:07] <gaughen> caribou, cool! thank you!
[16:07] <gaughen> #topic Weekly Updates & Questions for the QA Team (matsubara)
[16:07] <gaughen> matsubara, any QA topics?
[16:07] <matsubara> gaughen, hi, nothing new from me
[16:07] <caribou> smoser: debdiff is in the case if you want to have a look at it
[16:08] <gaughen> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
[16:08] <smb> Nothing to see here, move along... Please...
[16:09] <gaughen> #topic Upcoming Call For Papers
[16:09] <gaughen> any papers?
[16:09] <gaughen> topics?
[16:09] <gaughen> moving on
[16:09] <gaughen> #topic Ubuntu Server Team Events
[16:10] <gaughen> Openstack Summit in Tokyo is coming up
[16:10] <gaughen> there is also Linux Con EU next week
[16:10] <gaughen> several folks are presenting  on LXD and cloud-init
[16:10] <gaughen> anything else?
[16:10] <gaughen> #topic Open Discussion
[16:11] <gaughen> anything?
[16:11] <rharper> crickets
[16:11] <gaughen> #topic Announce next meeting date, time and chair
[16:11] <gaughen> next week, same time, same place
[16:11] <smoser> oh.
[16:11] <gaughen> chair will be
[16:11] <smoser> hold on.
[16:11] <smoser> lets go back to open discussion
[16:12] <gaughen> arosales
[16:12] <smoser> i want to float one thing
[16:12] <gaughen> okay, go back
[16:12] <gaughen> go for it
[16:12] <smoser> https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-networkd-vs-ifupdown
[16:12] <gaughen> do I need to switch topics officially?
[16:12] <smoser> nah
[16:12] <smoser> server has been asked what we think of a switch to networkd in 15.10
[16:12] <smoser> "by default"
[16:12] <rharper> how can we do that now ?
[16:12] <smoser> i wish rbasak was here, but interested in anyone's thoughts.
[16:13] <smoser> :)
[16:13] <gaughen> rcj, does this impact cloud-images?
[16:13] <smoser> that is the expected response.
[16:13] <rharper> maybe at the start of a cycle
[16:13] <gaughen> smoser, isn't it a wee bit late
[16:13] <smoser> well, the argument for it goes like this: i'd rather fail horribly now
[16:13] <gaughen> rcj, I expect the answer is yes
[16:13] <smoser> it does affect cloud images, yes.
[16:14] <smoser> not a *ton*, but it it would.
[16:14] <gaughen> smoser, would we have enough time to recover if we failed horribly now?
[16:14] <rharper> smoser: hopefully the argument is: networkd fixes the following issues we have with ifupdown
[16:14] <smoser> the bigger thing is anythign that writes (or reads) files in /etc/network/interfaces
[16:14] <rharper> if the size of that list is not large, it's hard to argue that it's worth the trouble in the first place
[16:14] <rcj> We have cloud image specifics around the interfaces files so we'll break clouds
[16:15] <smoser> a 1x1 static change is easy enough.
[16:15] <rcj> we have things that generate interfaces on the fly
[16:15] <smoser> honestly, i wouldnt expect the cloud images to be terribly effected.
[16:15] <smoser> oh?
[16:15] <smoser> rcj, where do you have such things ?
[16:15] <rcj> for cloud providers that have dynamic networking and multiple devices
[16:16] <rcj> Joyent is one
[16:16] <smoser> ok. so i'm very interested in that... can you give examples ?
[16:16] <gaughen> probably not here
[16:16] <smoser> (to be clear, i'm not advocating for this, but rather playing devils advocate).
[16:16] <rcj> But I don't know what tools like walinuxagent and gce tools are doing for certain either.
[16:16] <gaughen> what does non-devils advocate smoser think is the right thing to do here?
[16:17] <smoser> rcj, can you give a link to code that does "dynamic config" ?
[16:17] <rcj> smoser, I don't know that I'll find it quickly with Ben out
[16:18] <smoser> gaughen, the non-devils advocate thinks this is very late in a cycle.  and also even possibly very late in an LTS cycle (ie, as in now is late for *16.04*)
[16:18] <rharper> smoser: the most damning discussion I've seen is that networkd hasn't been (in the past at least) focused on server configuration, so things like parallel interface bringup or even ordered interface bring up (think bonds) have been addressed
[16:18] <rharper> the ifupdown + bonding threads brought up the issue and networkd folks, no we don't do that, lemme see if I can find the link
[16:18] <smoser> well, this would be a server install (and cloud image) config.
[16:18] <gaughen> smoser, can we do a test build with it and see what falls out?
[16:18] <rharper> but if we don't get equivalent function, and bug fixing, it's hard to argue that we should switch (and certainly harder late in the cycle)
[16:19] <smoser> rharper, i think that you're mistaken. in that networkd *is* server centric.
[16:20] <smoser> https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-networkd-vs-ifupdown is the blueprint, and /usr/share/doc/systemd/README.Debian.gz on your wily system describes how to change
[16:20] <smoser> pitti has done a good job of documenting that.
[16:20] <rharper> I'll track down the emails I read;
[16:21] <smoser> for easier reference, that README.Debian.gz is http://paste.ubuntu.com/12613789/
[16:21] <smoser> i agree, rharper that lack of bond is certainly a stop ship issue.
[16:21] <smoser> gaughen, so yeah, you could reasonably easily "see what falls out".
[16:22] <smoser> so the big fallout is in anything that is reading or writing /etc/network/interfaces{,.d/*}
[16:22] <smoser> which is curtin for one
[16:22] <smoser> and also juju
[16:22] <smoser> i'm interested i knowing anything else that people are aware of.
[16:22] <smoser> largely this is a fact finding expedition
[16:22] <smoser> also relevant is resolvconf -> systemd-resolvconf would be probably done
[16:23] <gaughen> smoser, if we're still in fact finding mode that means to me we're not ready to pull the trigger
[16:23] <gaughen> and thus too damn late for wily
[16:23] <gaughen> my 2 cents
[16:23] <smoser> the general reason for the interest in networkd is the same as that of systemd
[16:23] <smoser> its not something you generally *chose*
[16:24] <smoser> but something that is chosen for you. and you have to justify the cost of maintaining the other option (ifupdown-/etc/network/interfaces) indefinitely.
[16:25]  * caribou likes the fact that this discussion is under Announce next meeting date :)
[16:25] <gaughen> :-)
[16:25] <gaughen> so anything else to talk about on this topic. smoser what's the next step?
[16:26] <smoser> thus, if it is inevitable, then dropping ENI/ifupdown (which people love to hate also) by 16.04 , means we get to drop support for ifupdown 2 years sooner.
[16:26] <smoser> does anyone have other examples of readers or writers of /etc/network/interfaces ?
[16:27] <smoser> the other one that I know of is cloud-initramfs-dyn-netconf (which writes /etc/network/interfaces style file based on 'ip=' arguments on the cmdline).  And also open-iscsi is probably somehow affected (as it has to not bounce network interface of the root iscsi device).
[16:27] <smoser> anyone have anything else?
[16:27] <gaughen> smoser, should this one be emailed about on ubuntu-server?
[16:28] <gaughen> *crickets*
[16:28] <gaughen> okay I'm declaring this mtg done
[16:28] <smoser> done
[16:28] <smoser> thanks.
[16:28] <gaughen> until next week, same time, same place.
[16:29] <gaughen> thank you smoser for your little topic
[16:29] <caribou> thanks gaughen
[16:29] <gaughen> #endmeeting
[16:29] <meetingology> Meeting ended Tue Sep 29 16:29:12 2015 UTC.
[16:29] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-09-29-16.01.moin.txt
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <meetingology> Meeting started Tue Sep 29 17:00:02 2015 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: action commands idea info link nick
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Wily
[17:00] <cking> o/
[17:00] <smb> o/
[17:00] <henrix> o/
[17:00] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://kernel.ubuntu.com/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:01] <jsalisbury> [TOPIC] Status: Wily Development Kernel (ogasawara)
[17:01] <ogasawara> Our Wily kernel remains based on stable v4.2.1 and we will continue to
[17:01] <ogasawara> track 4.2 for the remainder of the 15.10 cycle.  As a reminder, we are
[17:01] <ogasawara> approaching Wily Kernel Freeze on Oct 8, ~1 week away.  If there are any patches which need to land for 15.10, please get them submitted soon.
[17:01] <ogasawara> Following the Kernel Freeze deadline, all patches are subject to our SRU policy.
[17:01] <ogasawara> -----
[17:01] <ogasawara> Important upcoming dates:
[17:01] <ogasawara> [LINK] https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
[17:01] <ogasawara> Thurs Oct  8 - Kernel Freeze (~1 weeks away)
[17:01] <ogasawara> Thurs Oct 15 - Final Freeze (~2 weeks away)
[17:01] <ogasawara> Thurs Oct 22 - 15.10 Release (~3 weeks away)
[17:01] <ogasawara> ..
[17:01] <chiluk> o/
[17:01] <chiluk> <-late
[17:01] <jsalisbury> [TOPIC] Status: CVE's
[17:01] <jsalisbury> The current CVE status can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://kernel.ubuntu.com/reports/kernel-cves.html
[17:01] <jsalisbury> ..
[17:02] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Precise/Trusty/lts-utopic/Vivid
[17:02] <jsalisbury> Status for the main kernels, until today:
[17:02] <jsalisbury>   *     Precise - Kernel Prep
[17:02] <jsalisbury>   *      Trusty - Kernel Prep
[17:02] <jsalisbury>   *  lts-Utopic - Kernel Prep
[17:02] <jsalisbury>   *      Vivid  - Kernel Prep
[17:02] <jsalisbury> Current opened tracking bugs details:
[17:02] <jsalisbury>   * http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
[17:02] <jsalisbury> For SRUs, SRU report is a good source of information:
[17:02] <jsalisbury>   * http://kernel.ubuntu.com/sru/sru-report.html
[17:02] <jsalisbury> Schedule:
[17:02] <jsalisbury> cycle: 27-Sep through 17-Oct
[17:02] <jsalisbury> [17:02] <jsalisbury>          25-Sep   Last day for kernel commits for this cycle
[17:02] <jsalisbury> 27-Sep - 03-Oct   Kernel prep week.
[17:02] <jsalisbury> 04-Oct - 10-Oct   Bug verification & Regression testing.
[17:02] <jsalisbury> 11-Oct - 17-Oct   Regression testing & Release to -updates.
[17:02] <jsalisbury> ..
[17:02] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:03] <jsalisbury> Thanks everyone
[17:03] <jsalisbury> #endmeeting
[17:03] <meetingology> Meeting ended Tue Sep 29 17:03:05 2015 UTC.
[17:03] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-09-29-17.00.moin.txt
[17:06] <Macbook_Oliver> Hi Team. Can anyone take a look at this: https://bugzilla.kernel.org/show_bug.cgi?id=99891
[17:06] <Macbook_Oliver> Basically the new macbook 12" is completely useless:(


[00:04]  * Ryan52 wonders if that should be low..
[00:06]  * duanedesign agrees
[00:07]  * Ryan52 sets it to wishlist
[00:07]  * duanedesign is appreciative
[00:07] <Ryan52> :)
[04:05] <pckchem> Umm... What should I do about bug 310431 and his illegally downloaded movie that won't open?
[04:05] <pckchem> :(
[04:08] <pckchem> Heh, illegal subtitles? Whatever.
[04:10] <duanedesign> bug #310353 I think should be set to 'wishlist' however this problem goes back to the default dpi settings in Gnome. So this 'bug' is entirely dependant on whether or not Gnome is ever going to default to the actual dpi or the default 96dpi
[04:37] <duanedesign> PrivateVoid: hello
[04:38] <PrivateVoid> hey duanedesign
[04:41] <duanedesign> PrivateVoid: I wanted your permission to post your ufw how to on my blog
[04:41] <PrivateVoid> Fine by me...
[04:41] <PrivateVoid> just link to the original
[04:42] <duanedesign> definetly, it was the easiest to understand, in my opinion
[04:43] <PrivateVoid> k
[04:48] <crimsun> pckchem: i've asked for an additional test
[04:50] <pckchem> crimsun: ?
[04:51] <crimsun> pckchem: you referenced bug 310431 about 46 minutes ago
[04:53] <pckchem> crimsun: Thats fine. Although I'm curious why you would choose to have him test it in 9.04 when so far nobody on 8.10 is able to reproduce?
[05:03] <crimsun> pckchem: question of detail, really. the current task is for the development version, not 8.10.
[05:04] <crimsun> pckchem: to be %100 precise, i'd need to open an intrepid task, too.
[05:07] <Ryan52> duanedesign: err, sorry you didn't get a response yet, give me a minute...
[05:08] <Ryan52> duanedesign, it should probably be set to wont fix also, because the default dpi bug is marked as wont fix...fixing this bug would just "break" stuff unless the other one is also fixed, which it won't..
[05:09] <Ryan52> or did I not read that well enough?
[05:12] <Ryan52> also, since it's configurable it's not really a "bug", so I agree about the wishlist setting.
[05:19] <Ryan52> duanedesign, set to wishlist, it'd probably be nice if you explain (it's configurable, usually only affected if you change some other default setting, etc etc) why in a comment.
[05:20] <duanedesign> Ryan52: I noticed that. Since I am fairly new to triage I wamt to make sure on certain things. Thank You
[05:24] <duanedesign> Ryan52: I think you read it correctly. I agree with your take on it. I will comment on it. If you changed the font size then everyone who accepts the default would have a font size too small.
[05:25] <duanedesign> and as it stands there are no plans, according to the default dpi bug, to change the 96dpi setting in Gnome
[05:31] <Ryan52> yup
[06:42] <marmuta> hi, I've tracked bug #309785 down to a recent xorg patch by Peter Hutterer. I know the buggy line, how do I go from there?
[06:42] <marmuta> Is he reading launchpad bugs at all?
[06:44] <RAOF> marmuta: If he's an upstream developer, probably not.
[06:44] <RAOF> Urgh.  EPARSE
[06:46] <marmuta> ok, is there an irc channel where the ubuntu X devs hang out?
[06:48] <RAOF> #ubuntu-x
[06:50] <RAOF> But it looks like he isn't actually directly involved in Ubuntu development, so he probably doesn't read Launchpad.
[06:51] <marmuta> ok, thank you, I guess I have to figure out how to get the bug upstream then
[06:51] <RAOF> marmuta: Which means the bug should probably go upstream to X's bugzilla.
[06:53] <marmuta> yep, I think I've found it: bugs.freedesktop.org
[07:09] <dholbach> good morning
[11:37] <Hew> We're about to hit 50,000 open Ubuntu bugs.. :-(
[11:39]  * Hew triages against the tide
[12:07] <Valsum> Hello, I have a question. Does one have to know how to program to help the Bug Squad?
[12:09] <MrKanister> Valsum: No, there are a lot of other things you can do. Have a lock at https://wiki.ubuntu.com/BugSquad/GettingInvolved for information about what you can do to help out with bugs
[12:09] <Valsum> yeah, I have already read that. So no programming skills needed for assigning packages and triaging bugs, right?
[12:12] <Hew> Valsum: That's right :-). Feel free to join the Launchpad team if you haven't already, and just start triaging!
[12:13] <MrKanister> Valsum: Yes, that's right. I think a good idea to start is to have a look at the new filed bug. Join #ubuntu-bugs-announce and you get notified about new bugs. With the help of https://wiki.ubuntu.com/Bugs/HowToTriage you can then make the bug report more informative until it is ready for being read by a developer
[12:13] <Hew> We're about to hit 50,000 open Ubuntu bugs, so the more help we get, the more bugs we can get to work on!
[12:15]  * Hobbsee randomly closes 10000 bugs
[12:15] <Hobbsee> that better?
[12:20] <Hobbsee> !ping
[12:20] <Hobbsee> hmmm
[12:20] <Valsum> MrKanister: Thanks.
[12:22] <MrKanister> Valsum: Thank you for helping us :)
[12:24] <Valsum> No prob. The more the merrier, hehe.
[12:25] <MrKanister> Valsum: That's right
[12:35] <Hew> Hobbsee: I wish it were that easy :P
[12:35] <Hobbsee> Hew: well, it can be.  you just have to get policy changed to say it's OK :P
[12:35] <Hew> hehe
[14:07] <bddebian> Boo
[14:10] <abraxxa> hello
[14:11] <abraxxa> the new libavahi packages from last week seem to break samba authentification, is this a known bug?
[14:21]  * BUGabundo_work opens 10001 to by pass Hobbsee doing!
[14:25]  * Hew has only closed about 10 :P
[15:28] <azimout> question: which tag should be applied to bug reports that need to be forwarded upstream?
[15:28] <azimout> according to this: https://wiki.ubuntu.com/Bugs/Tags, 'needs-upstream-report' is kubuntu-specific
[15:32] <Hew> azimout: Ideally you can forward it yourself and link the upstream bug, but if you are unable to do that, you can just open an upstream task with New status.
[15:36] <azimout> i know about upstream reporting, i want to choose a tag, for bugadays or the global bug jam in february
[15:37] <azimout> anyways, is there some reason why 'needs-upstream-report' should be kde-only?
[20:01] <ryanakca> What package does bug 309591 belong to?
[20:01] <Pici> Definitely not kubuntu-website
[20:01] <Pici> :)
[20:02] <ryanakca> Pici: *nod*, I'm trying to clear out the bugs filed against it...
[20:06] <ryanakca> Pici: should I just set it to Ubuntu?
[20:07] <Pici> ryanakca: I think its 'debian-installer' for the alternate CD.
[20:07] <ryanakca> Thanks
[20:15] <Ryan52> that's not even a bug. grub (legacy) doesn't work with raid 0.
[21:32] <kenkku> hi everyone, regarding bug 310723, the drivers don't support 16 bit (http://ati.amd.com/products/catalyst/linux.html#9), which naturally can't be fixed by ubuntu and is aknowledged by the AMD developers, what state should the bug be set to?
[21:32] <kenkku> https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/310723
[21:33] <kenkku> ah, hehe, ubottu was just a bit slow
[21:37] <charlie-tca> Will the ubuntu ati drivers ever have fglrx?
[21:38] <charlie-tca> We do have our own now, even though they don´t support it at the moment
[21:39] <charlie-tca> OTH, it is a question he asked! ... is this possible? a simple answer is ¨not at this time¨