[00:31] <Unit193> jbicha: Pinging with 1757574 as you did the aforementioned upload.
[00:31] <Unit193> LP 1757574
[00:32] <jbicha> Unit193: could you be more specific?
[00:33] <Unit193> jbicha: Eg libappindicator-dev should depend on libgtk2.0-dev, same for the gtk varient.
[00:36] <jbicha> do you want to submit a merge proposal? https://code.launchpad.net/~indicator-applet-developers/libappindicator/trunk.16.10
[00:36] <jbicha> lp:libappindicator
[00:39] <Unit193> Sure, I could do that if it gets it in.
[00:55] <Unit193> https://code.launchpad.net/~unit193/libappindicator/build-depends/+merge/341865
[00:59] <Unit193> (If you're wondering how one could have a build-depend on that but not libgtk2.0-dev, wxwidgets.)
[01:23] <Unit193> Thanks!
[09:28] <tseliot> doko: hi, any chance of getting the fix for gcc in 16.04 and 14.04? https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1750937
[09:44] <doko> tseliot: I'm not sure what you're asking
[09:45] <doko> if it's about the retpoline patches, then you should ask the security team
[09:45] <anon^_^> hello
[09:45] <anon^_^> doko?
[09:46] <anon^_^> i was the user that reported an issue with reptoline missing in gcc-4.8
[09:46] <anon^_^> in ubuntu-kernel yesterday
[09:47] <tseliot> doko: this ^
[09:47] <anon^_^> i had a functional system with nvidia 384, updated to 3.13.0-143-lowlatency
[09:48] <doko> looks good to me: https://launchpad.net/ubuntu/+source/gcc-4.8
[09:48] <anon^_^> then kern.log began throwing errors
[09:48] <anon^_^> Mar 21 02:11:55 ****** kernel: [   60.800613] nvidia: version magic '3.13.0-143-lowlatency SMP preempt mod_unload modversions ' should be '3.13.0-143-lowlatency SMP preempt mod_unload modversions retpoline '
[09:48] <anon^_^> the nvidia driver was unloaded
[09:49] <anon^_^> actually it was 4:4.8.2-1ubuntu6
[09:49] <anon^_^> gcc version
[09:50] <anon^_^> removed both the kernel and nvidia 384, re-installed and it was still broken
[09:50] <anon^_^> modinfo nvidia-384 -k 3.13.0-143-lowlatency
[09:50] <anon^_^> vermagic:       3.13.0-143-lowlatency SMP preempt mod_unload modversions
[09:51] <anon^_^> ^ no retpoline flag
[09:51] <anon^_^> to get the nvidia driver to load i have to manually edit
[09:51] <anon^_^> # /usr/src/linux-headers-3.13.0-143/include/linux/vermagic.h
[09:52] <anon^_^> following sven's workaround
[09:52] <anon^_^> https://devtalk.nvidia.com/default/topic/1030325/nvidia-driver-installation-v387-26-on-ubuntu-16-04/
[09:52] <anon^_^> then i removed the nvidia module from dkms, re-installed, rebooted
[09:53] <anon^_^> there probably aren't very many people using 14.04 with it being close to EOL
[09:54] <anon^_^> but i doubt that most ubuntu users are going to be able to figure out what broke nvidia drivers or go through all that to fix it
[09:56] <anon^_^> if i remove that workaround from vermagic.h the nvidia module will not load
[09:58] <anon^_^> the issue is persistent across reboots and re-install
[10:10] <anon^_^> doko?
[10:16] <doko> sbeattie: ^^^  I have no idea about that ...
[11:54] <coreycb> sil2100: it seems like the accepted into proposed script needs updating if only per-release verification-done tags are accepted
[11:59] <sil2100> coreycb: it is updated, not sure why Brian's response had the old comment - for instance right now it's like this: https://bugs.launchpad.net/ubuntu/+source/httmock/+bug/1735160/comments/21
[11:59] <coreycb> sil2100: ok cool
[11:59] <coreycb> sil2100: thanks :)
[12:00] <sil2100> I'll poke Brian later, maybe he's missing a bzr pull or something ;)
[12:00] <sil2100> (but that's a very old change)
[12:02] <sil2100> bdmurray: hey! As per coreycb's pointer, it seems like you have a greatly outdated sru-review script? Looks like you're leaving outdated verification comments, like for instance in https://bugs.launchpad.net/horizon/+bug/1582725/comments/19
[12:04] <sil2100> bdmurray: I changed that string ages ago when we switched to the verification-done-SERIES enforcement
[13:38] <bdmurray> sil2100: I might have been in an old branch... I'll clean that up.
[13:58] <sil2100> bdmurray: thanks ;)
[14:40] <rbasak> sil2100: reminder to review bug 1466926 please
[15:18] <sil2100> rbasak: ACK
[15:20] <rbasak> sil2100: thank you for the review
[17:13] <powersj> slangasek: LP: #1758113 is currently causing troubles with server ISO
[17:16] <powersj> ^ coreycb is this known?
[17:17] <slangasek> powersj: also reported as LP: #1758004; but I'm not sure what the actual bug is, python3-cffi-backend provides both virtual package names
[17:17] <coreycb> powersj: i don't know. my changes to that were no-ops.
[17:18] <slangasek> powersj: is python3-cffi-backend present on the ISO?
[17:18] <coreycb> powersj: Tristan might be a better contact
[17:18] <powersj> slangasek: it is not
[17:19] <slangasek> powersj: ok. does the error occur when trying to do an install of this task without a network apt source?
[17:20] <slangasek> powersj: my guess is that apt within the target is fine to do this installation, but our code to assemble the pool on the image fails to handle versioned provides
[17:21] <slangasek> in this case, we would've sidestepped the bug if the squashfs on the server ISO was the full server task
[17:21] <slangasek> xnox: ^^
[17:22] <xnox> slangasek, which server team rejected
[17:22] <xnox> slangasek, saying "oh no, people use server.iso, as a mini d-i.iso, and only install minimal by default"
[17:22] <xnox> slangasek, unless we ship multiple squashfs on the server.iso
[17:22] <slangasek> xnox: where/when was this reject?
[17:23] <xnox> slangasek, in an informal conversation.
[17:23] <xnox> slangasek, however that was in the context of disable tasksel /as well/. maybe they will be happy with a fatter squashfs. (and tasksel kept in tact)
[17:23] <xnox> i can re-raise that.
[17:24] <slangasek> xnox: yeah, I don't think that's a good rationale for this behavior anymore
[17:24] <slangasek> xnox: please re-raise it where I can participate in the discussion :)
[17:24] <xnox> slangasek, meet us in the pub, in cambridge, at 17:00 tomorrow
[17:24] <xnox> =)
[17:24]  * xnox giggles
[17:26] <slangasek> xnox: anyway, these days we are producing a "good" squashfs for the subiquity image, and it's a shame that we're not using it for the d-i image
[17:29] <slangasek> ? Unknown dependency python3-cffi-backend-api-min (<= 9729) by python3-cryptography
[17:29] <slangasek> ? Unknown dependency python3-cffi-backend-api-max (>= 9729) by python3-cryptography
[17:29] <slangasek> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/bionic/daily-20180322.log
[17:30] <slangasek> actually, this seems to be in germinate
[17:30] <slangasek> cjwatson: does germinate support versioned provides, in some version later than what we currently have on nusakan?
[17:31] <cjwatson> I don't think so.  Could I have a bug?
[17:31] <cjwatson> It shouldn't be too horribly difficult
[17:31] <slangasek> cjwatson: https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1758004
[17:31] <cjwatson> Thanks.  I'd be happy to take a look, though probably not today
[17:36] <cjwatson> I do at least have a failing test case in place
[19:24] <sergiusens> slangasek: since I see you are on it, just wanted to say that the new dh-python broken our snapcraft pkg builds https://launchpadlibrarian.net/361662873/buildlog_ubuntu-bionic-amd64.snapcraft_2.40+18.04.2_BUILDING.txt.gz
[19:25] <sergiusens> *broke
[19:27] <sergiusens> there seems to be new copy logic in there
[19:27] <slangasek> sergiusens: please refer this to doko who made this post-FF change
[19:28] <sergiusens> ack, I'll log a bug
[19:33] <sergiusens> doko: LP: #1758142
[19:59] <slangasek> powersj, cjwatson: as a short-term hack to unbreak server, I think I'm going to try to have germinate on nusakan ignore versions entirely for provides calculation; AFAIK we don't have any versioned dependencies currently that will be incorrectly resolved to non-version-matching virtual packages as a result of this, and even if we do, the outcome is no worse than currently
[20:00] <powersj> slangasek: ok I would need to wait for tomorrow's ISO to re-test?
[20:00] <slangasek> powersj: I would retrigger a build immediately for testing
[20:00] <powersj> even better
[20:02] <slangasek> powersj: (and running now)
[20:02] <mwhudson> morning
[20:05]  * slangasek waves
[20:05] <slangasek> powersj: we should diff the .list files for each architecture, to make sure it's done what we expect
[20:08]  * powersj downloads the 20180322.list
[20:27] <slangasek> powersj: 20180322.1 done
[20:27]  * powersj waits on http://cdimage.ubuntu.com/ubuntu-server/daily/20180322.1/
[20:29] <slangasek> unfortunately the dh-python dpkg-dev fix landed at the same time so the diff is large
[20:30] <powersj> diff http://paste.ubuntu.com/p/xXpyH96ntG/
[20:30] <powersj> yeah
[20:30] <slangasek> -/pool/main/p/perl/libperl5.26_5.26.1-5_amd64.deb
[20:30] <slangasek> that part doesn't look good though
[20:30] <slangasek> +/pool/main/p/python-cffi/python3-cffi-backend_1.11.5-1_amd64.deb
[20:30] <slangasek> whereas that part does
[20:32] <slangasek> actually, even the perl stuff is consistent with the priority-mismatches fixup
[20:33] <powersj> diff with only changes: http://paste.ubuntu.com/p/8VHTTf57ds/
[20:33] <powersj> all the gcc and gnupg2 changes are expected?
[20:33] <slangasek> yes
[20:33] <slangasek> python3 -> dh_python was incorrectly pulling in dpkg-dev -> build-essential
[20:33] <powersj> ok I'll launch tests
[20:34] <slangasek> so actually 20180321 might be a better basis for comparison
[20:34] <slangasek> hmmm no, gcc was already in the mix in 20180321
[20:34] <slangasek> so nevermind
[20:35] <slangasek> I could revert this change and do another build for comparison
[20:35] <slangasek> powersj: ^^?
[20:35] <powersj> that might be good to make sure we don't let something slip through
[20:35] <powersj> I'll still launch on 22.1
[20:35] <slangasek> k, running
[20:39] <slangasek> the libperl5.26 change *looks* super-odd, but when I dig I am surprised to find that perl-base (/usr/bin/perl) does not depend on libperl.  Sooooo even this is plausible
[20:41] <slangasek> cjwatson: you mentioned a failing test case, perhaps you also arrived at something like https://code.launchpad.net/~vorlon/germinate/+git/germinate/+ref/lp.1758004
[20:48] <powersj> slangasek: smoke test install just completed successfully
[20:50] <cjwatson> slangasek: Similar kind of thing; thanks
[20:52] <jbicha> cking: why did you reintroduce xchat-gnome to Ubuntu? LP: #1758163
[20:52] <cking> jbicha, it can be killed, it's too much hassle to maintain IMHO
[20:53] <jbicha> could you comment on the bug please then :)
[20:54] <cking> done
[20:55] <jbicha> apw: since you sponsored xchat-gnome back into Ubuntu, could you look into removing it now? ^
[20:57] <slangasek> jbicha, cking, apw: done
[20:57] <jbicha> cool, that was really fast :)
[20:58] <cking> thank
[20:58] <cking> s
[21:01] <slangasek> oh no, we removed his irc client from the archive and he fell offline
[21:02] <acheronuk> lol
[21:04] <slangasek> powersj: 22.2 is up, with a shorter (and still interesting) delta
[21:05] <powersj> slangasek: is this what you show? 22.1 diffed against 22.2 http://paste.ubuntu.com/p/2cTHwh7W3W/
[21:05] <powersj> so e2fslibs
[21:05] <slangasek> powersj: yes.  so, what does ef2slibs mean
[21:07] <powersj> ef2slibs was on the cd, but since changing germinate to ignore versions it is now not on there
[21:10] <anon^_^> doko, sbeattie, any update re: reptoline, gcc-4.8 issue with 14.04 that lead to persistent unloading of Nvidia driver?
[21:33] <slangasek> powersj: turns out libext2fs2 Provides: e2fslibs (= 1.44.0-1); so it's a bit strange that e2fslibs and libext2fs2 exist like this, but it's not wrong for the image build to drop e2fslibs from the image based on my germinate change
[21:34] <powersj> ok
[21:39] <sbeattie> anon^_^: I don't know what you're referencing. gcc-4.8 4.8.4-2ubuntu1~14.04.4 (available in both trusty-security and trusty-updates) is needed for the dkms build. I'm not sure why any of that would cause a module to unload, though.
[21:42] <jbicha> slangasek: can you explain the bash 4.4.18-1.1ubuntu1 removal?
[21:43] <jbicha> because I used sbuild-launchpad-chroot to create an armhf chroot but it is stuck trying to update bash with an error that looks like Debian bug 889869
[21:43] <slangasek> jbicha: PIE is a security feature, and shouldn't be disabled to work around a bug in qemu-user-static
[21:44] <jbicha> is there a LP bug for the issue I experienced then?
[21:44] <slangasek> jbicha: LP: #1751011
[21:44] <jbicha> bash being stuck half-installed is a bit of a problem…
[21:49] <jbicha> slangasek: I request that you reconsider. The PIE change was only in Debian one week before it was reverted
[21:50] <jbicha> meanwhile, I added it to the Release Notes…
[21:51] <slangasek> jbicha: considering.  I think at minimum, I would want it signed off by the Security Team that they're ok with non-PIE bash in 18.04
[21:56] <slangasek> jbicha: barring that signoff, although I understand it's inconvenient to have qemu-user completely unusable for cross-chroots as a result of this, there are also still large swaths of the archive that qemu-user can't cope with (last I checked: anything Qt-based, for armhf), so I think having it completely-broken vs 25% broken is not a persuasive reason to disable the hardening feature
[21:56] <slangasek> mdeslaur, sbeattie: ^^ would one of you want to weigh in on this?
[21:58] <sbeattie> slangasek: we previously had bash as no-pie because it hit a similar failure on older kernels. It's not ideal, but I can live with it.
[21:59] <jbicha> slangasek: comment 15 at Debian bug 865599 has another proposal…
[21:59] <jbicha> I don't know enough about bash to know what the proposal means
[22:00] <slangasek> sbeattie: you're not required to live with it, though... if you think this is important to our hardening story in 18.04, I think that takes precedence
[22:01] <slangasek> also it's one thing to have had PIE disabled for a package for 16.10-17.10, and another to have it disabled in 18.04 LTS
[22:01] <slangasek> jbicha: yes, that suggestion makes sense given what I saw of the description of the problem (internal use of sbrk instead of glibc malloc)
[22:02] <slangasek> jbicha: I think it's worth investigating as a path forward (but I'm probably not going to pursue this myself)
[22:03] <jbicha> ok
[22:29] <anon^_^> sbeattie, pm
[22:51] <tjaalton> could a member of the security team please review https://bugs.launchpad.net/ubuntu/+source/pysmi/+bug/1748572
[22:51] <tjaalton> I need to get 389-ds-base unblocked, finally
[22:52] <sarnold> tjaalton: it'll be next week before we can get to that
[22:52] <tjaalton> sarnold: as long as it's on the radar, thanks
[22:53] <sarnold> tjaalton: yup, not forgotten, it just got knocked back a bit on the list when encrypted devices stopped working the other day :/
[22:53] <tjaalton> fun times
[22:54] <sarnold> there's always a bit of a rush around FF time .. this one more than most, probably because it's an LTS..
[22:54] <tjaalton> I'm just as guilty :)
[22:55] <sarnold> it's probably just the way things are going to go when it's run on a cycle ;)
[22:56] <tjaalton> yup
[23:15] <slangasek> tjaalton: <cough> I accidentally got 389-ds-base in already without the MIR being handled
[23:15] <sarnold> heh
[23:16] <slangasek> MIR still needs doing of course
[23:33] <tjaalton> slangasek: oh, hehe.. thanks


[01:03] <skellat> CajunTechie: Which community team are you referring to?  You were previously in the #ubuntu-locoteams channel asking about teams and that is the correct place but didn't idle long enough until a council member could reply.  If you could head back over there, we may discuss things there.
[01:06] <CajunTechie> Thank you Skellat! I appreciate it. I'm headed back to the locoteams chan.
[07:01] <ochosi> morning
[07:02] <elfy> morning
[07:19] <ochosi> elfy, Unit193: any chance you could (in the future) do the core discussions in here?
[07:20] <Unit193> Sure, we did this afternoon.
[07:20] <ochosi> i know, which is why i thought i should call you out this time ;)
[07:20] <ochosi> so the problem is that with gb no kernel modules are found, but with us it'd work fine?
[07:20] <Unit193> Well, figured that bit was more offtopic, still do, but whatever works I suppose.
[07:21] <ochosi> well, it would be good to know what the status/progress of testing is
[07:21] <Unit193> All I can say: Worked for me™
[07:21] <ochosi> elfy: any chance you could test with another language than gb?
[07:21] <Unit193> s/language/repo/
[07:21] <elfy> what's the point
[07:21] <Unit193> And I don't think it offeres.
[07:22] <ochosi> elfy: well confirming that it generally works?
[07:22] <elfy> Unit193's confirmed that
[07:22] <ochosi> well, a single person doesn't confirm that much tbh
[07:23] <ochosi> if it's not working with other repos (for whatever reason) that sucks then
[07:23] <Unit193> Why not? :P
[07:23] <ochosi> ;)
[07:23] <elfy> we want other people to test this - at the moment then I have confirmed that it doesn't work
[07:23] <elfy> I don't see any point in confirming that it works 'somewhere'
[07:24] <ochosi> why not?
[07:25] <elfy> because it's confirmed that it doesn't work 'everywhere'
[07:25] <Unit193> Because he generally tests about 2 isos a day, and it's getting annoying?
[07:26] <ochosi> right, any plan to get others to test it?
[07:26] <Unit193> Once we know we won't get a ton of FP errors.
[07:26] <ochosi> but that you don't know atm, you only know it works with us and doesn't with gb, right?
[07:27] <Unit193> gb will give FPs, we know that.
[07:27] <elfy> ochosi: so it works for you?
[07:27] <ochosi> elfy: i haven't had time to test it yet
[07:27] <elfy> oh sorry - us =US - read that wrong :)
[07:27] <ochosi> ah hehe :)
[07:27] <Unit193> us = me. :D
[07:28] <ochosi> reminds me of that great quotation from the office: "there is no *i* in team. but there is *me*."
[07:28] <ochosi> (the gb office that is, not the us version)
[07:29] <ochosi> anyhoo, i realize i might be a bit of a pain in the ass here, but remember that that's currently in my job description...
[07:29] <ochosi> can't either of you test another repo?
[07:29] <elfy> trying now
[07:29] <Unit193> You'd have to spoof your geoip, only ever lets me select the one.
[07:30] <elfy> Unit193: I got to choose archive
[07:30] <Unit193> elfy: I get to choose too, but there's only ever one option, us.archive.ubuntu.com. :P
[07:31] <elfy> au fails
[07:31]  * Unit193 redacts a comment there...
[07:31] <elfy> trying us
[07:32] <elfy> which looks like it's going to fail for me as well
[07:33] <ochosi> weird
[07:33] <elfy> perhaps it's vbox
[07:33] <ochosi> would you say that's a question of the utopic cycle being so fresh?
[07:33] <ochosi> or what other reasons would there be for it to fail
[07:33] <elfy> anyway - work now - cya later
[07:33] <ochosi> sure, seeya elfy
[07:33] <elfy> point - Unit193 you doing this from trusty or utopic?
[07:33] <ochosi> and thanks for testing!
[07:34] <Unit193> utopic, isn't in trusty.  vbox too.
[07:34] <elfy> mmm odd
[07:34] <elfy> anyway - off now
[07:34] <ochosi> Unit193: maybe we can get someone else from the us to confirm that it works to begin with ;)
[07:35] <Unit193> ochosi: Might be a good idea to start using proper case. :P
[07:35] <ochosi> and then move to other regions
[07:35]  * ochosi likes the ambiguity
[07:36] <Unit193> Well, does it matter too much?  There's going to be a lot of failures, and this is before the Xubuntu part so that's not the cause.
[07:36] <ochosi> yeah, but it'd be good to know *why* it fails at least
[07:36] <ochosi> (at least to me that's not crystall clear)
[07:37] <Unit193> elfy: If you try a new install, grab a new iso too, if you would?
[07:40] <Unit193> Uhhh, are we still tracking systemd?  208 should land after B2.
[07:44] <ochosi> Unit193: not sure tbh, but best to bring it up with elfy or blue
[07:44] <ochosi> gotta go...
[10:16] <ochosi> bluesabre: i pushed updates to a few themes btw (greybird, orion, bluebird) for xfwm4.11.2
[10:17] <ochosi> gotta talk to satya how he wants numix to look
[10:18] <ochosi> albatross is fine-ish as is, i think we should drop that theme this cycle (unless knome or somebody else volunteers to maintain it)
[10:28] <ochosi> bluesabre: i'll do releases soon i guess, but if you're already running utopic and could take a look whether anything else is missing or looks broken, that'd be great!
[10:29] <ochosi> same goes for those icons in the classical appmenu that seemed too large
[10:34] <ochosi> (could then do releases for themes and icons)
[10:46] <bluesabre> ochosi: that would be cool
[13:15] <elfy> ochosi Unit193 - seems to be working if I get the iso again and not use whatever was on core.html yesterday
[13:36] <knome> olli, hhrgh
[13:36] <knome> hump, ochosi ^
[13:36] <olli> hhrgh?
[13:36] <knome> olli, keep it for one more cycle and i'll promise to update it? ;]
[13:36] <olli> ;)
[13:37] <knome> sorry, wrong target
[13:37] <knome> long day moving friends
[13:37] <olli>  /nick illo
[13:37] <knome> that would work! ;)
[13:37] <olli> anything I can do for you ;)
[13:37] <knome> hehe
[13:38]  * knome offers olli some cookies and coffee
[16:19] <elfy> ochosi: 64 bit failed debbootstrap
[16:40] <elfy> same in 32bit
[16:44] <elfy> mmm
[16:45] <elfy> so forced it past that, when I get to the tasksel window - xubuntu minimum is not there
[16:46] <knome> what about xubuntu minimal?
[16:46] <knome> ;>
[16:48] <elfy> that's as present as minimum
[16:48] <knome> damn ;)
[16:48] <elfy> waste of hours of my time
[16:48] <knome> :(
[16:48] <knome> sorry to hear that
[17:17] <elfy> bluesabre: am I supposed to be seeing Settings in the whiskermenu now?
[18:23] <elfy> Unit193: nor in the 64bit :|
[18:26] <ochosi> elfy: i guess that (settings) depends on your version of x-d-s and whether it's a clean install/new user
[18:26] <ochosi> i'm not sure an upgrade overwrites the old menufile
[18:27] <elfy> ok ochosi - thanks
[18:28] <ochosi> while the changelog has been updated, i don't read anything from a version bump or a release
[18:28] <ochosi> https://code.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk
[18:28] <ochosi> so you might have to wait a little longer (unless you wanna just pull in rev494 by hand
[18:32] <elfy> so - having to apt-get install xubuntu-core
[18:32] <ochosi> i thought core isn't working?
[18:32] <ochosi> or on top of what are you installing that now?
[19:43] <Unit193> This is turning out to be very inconsistant.
[19:50] <pleia2> ochosi: I've been thinking a lot about a donations page that points to things like the bounties, since folks on social media ask every few months how they can donate money and not even Xfce has a place anymore (they used to have a spot for donating to Thunar)
[19:50] <pleia2> ochosi: but catch up with me next week, still recovering here :)
[19:51] <SkippersBoss> evening
[20:58] <Unit193> ochosi: So tasksel needs refreshed before it'll show up in there it seems.  The only things of note: https://unit193.net/noxubuntucore.png  https://unit193.net/debootstrapwarn1.png  https://unit193.net/mirror-selection.png
[21:16] <ochosi> pleia2: sure, take your time to rest, we can talk whenever you're back on your feet
[21:17] <ochosi> Unit193: how does that work? (refresh tasksel)
[21:24] <Unit193> Don't know, so I asked.
[21:37] <Unit193> bluesabre: Except now we get a battery panel item for desktops. :P
[21:37] <ochosi> while that is true, it's still kinda useful
[21:38] <ochosi> it handles your wireless mice and all devices that draw power (mp3 players etc)
[21:38] <ochosi> and you get quick access to presentation mode and settings, so let's say it's at least not entirely useless
[21:39] <Unit193> Ah, not entirely then.
[21:39] <ochosi> at least it's easier to remove it from the panel ;)
[22:12] <Unit193> ochosi: So, what's the deal with the xubuntu-*.desktop files?
[22:13] <ochosi> which ones?
[22:14] <Unit193> Linking to the website and stuff.
[22:16] <ochosi> ah those ones
[22:16] <ochosi> well what do you mean what's the deal? i guess they were a convenient way to link people to the documentation in the appmenu
[22:17] <ochosi> (were and possibly still are)
[22:17] <Unit193> Thought there was a comment about them, but I could be remembering wrong.
[22:19]  * ochosi only read Unit193's comment from a few minutes ago...
[22:19] <Unit193> OK, thanks.
[22:20] <ochosi> np, if there's a deal with those .desktop files let me know!
[22:23] <Unit193> Uhhh, well I'll let others say.
[22:23] <ochosi> why?
[22:24] <Unit193> Because it's personal taste.
[22:25] <ochosi> you're still free to utter your opinion
[23:50] <pleia2> did the non-automatic social media things for the 14.04.1 post (twitter & g+)


[17:13] <infinity> xnox: Naughty.
[17:14] <xnox> infinity: =)
[17:15] <xnox> infinity: yeah, i think I'll move firmware install from post-base-install.d to pre-pkgsel.d/01* such that it's almost first thing after kernel is installed.
[17:16] <xnox> infinity: and most importantly before update-initramfs is done.
[17:16] <infinity> Indeed.  The timing is critical.
[17:17] <infinity> (Well, there's no reason you can't trigger another in-target update-initramfs -u)
[17:17] <infinity> SUcks to slow down the install with multiple calls, but it's not world-ending either.
[17:17] <xnox> infinity: i just think that some of drivers, might just be drivers with no other postinst scripts et al.
[17:18] <xnox> infinity: and as this bug shows, all other driver disks never used proper dependencies.
[17:18] <xnox> =/
[17:21] <xnox> infinity: should drivers generally depend on "linux-image-3.x.y-WW-generic" ?
[17:21] <infinity> Well, dkms driver disks don't need to depend on a kernel (would be wrong if they did), but still better to shuffle them all to this later spot.
[17:22] <infinity> This new and icky case is because they're shipping pre-compiled .ko files.
[17:22] <xnox> infinity: true. I wonder if moving this will break any existing driver disks, as I'll be pushing this to precise I'm guessing.
[17:22] <xnox> infinity: e.g. like Dell disks (which is where this feature originally came from)
[17:23] <infinity> I don't see why it would break a dkms disk, but shouldn't be too hard to test.
[17:23] <infinity> It just means the dkms trigger will have to happen from the driver install instead of from the kernel's postinst.
[17:23] <xnox> infinity: true.
[17:24] <infinity> Which should be true anyway, or their driver's don't work when you apt-get install them.
[17:24] <infinity> But worth checking.
[17:24] <infinity> s/driver's/drivers/
[17:24] <infinity> Wow, I'm typing in internet grammar.  I need to wake up.
[17:25] <xnox> infinity: try to install twice? or will we find bugs =)
[17:25] <xnox> i think it ignores errors at the moment.
[17:27] <xnox> superm1: are there any Dell Driver Injection Disks available publicly? e.g. for testing. I am working on a solution for bug #1216043
[17:27] <ubot2`> Launchpad bug 1216043 in hw-detect (Ubuntu Saucy) "driver-inject-disk: in target debs are installed before kernel has been" [High,Confirmed] https://launchpad.net/bugs/1216043
[17:27] <xnox> superm1: and well see discussion above ^
[17:28] <xnox> and I would not want to break existing driver disks.
[17:34] <superm1> xnox: AFAIK it hasn't actually been used yet.  it was added in anticipation of a factory preinstalled ubuntu server image, but thus far the machines have been certified but not preinstalled and there has been no other work put towards it
[17:35] <superm1> but to your discussion, i don't think it's appropriate that the debs included should depend on specific kernel versions
[17:35] <superm1> it's asking for breakage with every respin of an alternate ISO that includes an updated kernel
[17:36] <xnox> superm1: ok. thanks for the info.
[17:36] <superm1> kentb-out: was just discussing with me plans on how to get it into deployment though, so if you make changes make sure you tie off with him
[17:37] <xnox> ack.
[17:39] <infinity> superm1: dkms disks obviously shouldn't depend on kernel versions.  This other messed up use-case (pre-built .ko files) has to, but that shouldn't concern you guys, cause you're doing it right. :)
[17:40]  * arges reads
[17:42] <superm1> prebuilt ko's without a way to rebuild is asking for trouble for sure
[17:46] <infinity> superm1: We've told this partner the same thing, yes. :P
[17:46] <infinity> superm1: But providing them a mechanism to ask for said trouble is still helpful, even if we disagree with their method. :)
[17:47] <infinity> (And it should just be a matter of doing the driver install a tiny bit later (after a kernel is already installed in-target) and then making sure that doens't blow up dkms disks)
[17:47] <superm1> that's unfortunate that it probably will get used by another partner before we ever got to use it in production
[17:47] <infinity> superm1: And if you guys aren't yet using dkms disks in production, this is perfect, as we can just test new disks going forward, not worry about breaking old ones.
[17:47] <superm1> yep
[18:03] <xnox> arges: see proposed branch and check if that works for you https://bugs.launchpad.net/ubuntu/+source/hw-detect/+bug/1216043
[18:03] <ubot2`> Launchpad bug 1216043 in hw-detect (Ubuntu Saucy) "driver-inject-disk: in target debs are installed before kernel has been" [High,Confirmed]
[18:04] <xnox> arges: I'm off to gym and EOD/EOW, but will pop back on IRC later.
[18:07] <infinity> xnox: Your MP is full of >>><<< merge conflict markers. :P
[18:08] <xnox> infinity: excellent.
[18:09] <xnox> infinity: so you click search, find a branch, click on it, lp adds it to the target branch field, but does not move the radio button from default focus!
[18:10] <infinity> xnox: Oh, so the MP was a mistake? :)
[18:10] <infinity> That explains a lot.
[18:10] <xnox> infinity: well, target branch =)
[18:10] <xnox> infinity: https://code.launchpad.net/~xnox/hw-detect/fix-firmware-order/+merge/181886
[18:10] <xnox> fixed.
[18:14] <infinity> xnox: Ahh, that's much more readable.  Uselessly so, since I need the source to figure out what the file you moved is. :)
[18:14]  * infinity looks.
[18:15] <infinity> # copy any loose firmware files to /target (incl. subdirs)
[18:15] <infinity> SRSLY?
[18:15] <infinity> Who wrote this?
[18:17] <infinity> I really, really, really wish I hadn't read that script.
[18:20] <infinity> xnox: Hrm, after I've approved it, I now wonder if the above scary bit is a problem with reordering.
[18:20] <infinity> xnox: Since it could be overwriting firmware from linux-firmware (presumably, it ran before linux-firmware was installed before you moved it)
[18:21] <infinity> Honestly, I wonder who thought that was a good idea AT ALL.  Copying random firmware from the installer to the target system just seems scary.
[18:26] <superm1> 50-install-firmware wasn't written as part of the driver injection disk stuff, i thought that part came from debian from earlier
[18:26] <infinity> Indeed, you just leveraged it, since it already copies debs around and installs them.
[18:26] <infinity> In fact...
[18:26] <infinity> Hrm.
[18:27] <infinity> xnox: It might be better to put 50-install-firmware back where it came from.
[18:27] <infinity> xnox: And do a new XX-driver-disk in hw-detect.pre-pkgsel.d that uses a different /tmp directory.
[18:28] <infinity> xnox: And mangle driver-injection-disk.sh to use that instead of overloading /tmp/firmware
[18:30] <superm1> also the driver injection stuff did make it up to debian, so make sure that whatever you change you commit (or get someone to sponsor) up there too to be consistent
[18:30] <infinity> xnox and I both have commit to d-i in Debian.
[18:31] <superm1> great :)
[19:13] <xnox> infinity: I rarely question d-i =) colin will be back on monday and I can see if that bit can be improved.
[19:28] <infinity> xnox: Fundamentally, I think it's just wrong to leverage the firmware thing to install things that aren't firmware.  Using another tmpdir and a different hook for driver disks feels cleaner.
[19:28] <infinity> xnox: And should be generally non-contentious.  I'd commit that upstream today, if it looked clean.
[19:44] <xnox> I have tea to drink with cheesecake though =)
[19:44] <xnox> will do that, but not today.