[00:00] <smoser> right? and you can SRU that to stable releases.
[00:00] <bdrung> yes
[00:00] <bdrung> that's the plan
[00:00] <smoser> i added code to use it in cobbler, but then was pointed at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[00:01] <smoser> (i just dropped the Recommends in distro-info of cobbler to a Suggests)
[00:01] <smoser> as it was showing mismatch for build-depends on distro-info of haskel
[00:01] <smoser> so..
[00:01] <smoser> so...
[00:01] <smoser> to the question
[00:02] <smoser> are you insistent on haskell?
[00:02] <bdrung> i fail to see haskel in that diagram.
[00:02] <smoser> right. its gone now.
[00:03] <smoser> but there was a long line hanging off cobbler into some haskell libraries
[00:03] <bdrung> the haskell version is way faster than the python version and therefore i like to keep the haskell version
[00:03] <bdrung> there was a haskell transition
[00:04] <smoser> hm.. well, since its a build-depens, it doesn't really gain us to do separation (like you've done with the -data)
[00:04] <ScottK> bdrung: The problem is that haskell isn't and won't be in Main.
[00:04] <smoser> ie, we sitll get all the build-depends pulled into main of the source.
[00:06] <smoser> so, i guess my question is going forward would you be open to even splitting out source packages ? or something else that removed a dependency on haskell ?
[00:07] <smoser> i think its absolutely silly to have to SRU a package to get a string change.
[00:07] <Laney> you could feasibly have haskell bindings to a C lib
[00:07] <Laney> in a separate package
[00:08] <bdrung> smoser: what do you really want? distro-info in main?
[00:08] <Daviey> I think what smoser is getting at, would you be happy having two source packages.. a distro-info-data (containing csv's) and a distro-info tool?
[00:08] <smoser> well, i supose distro-info and distro-info-data.
[00:08] <Daviey> That would mean that A) you don't need to recompile for SRU
[00:08] <Daviey> and secondly, peope can cuse a shell or python version if they want. (in main)
[00:09] <smoser> i'd like distro-info in main
[00:09] <smoser> (or some shell usable utility, i dont really care about speed)
[00:09] <Daviey> bdrung: I must say, that a 1.5M binary + csv is pretty nuts.
[00:09] <bdrung> other user's care about speed
[00:09] <smoser> because if the shell utility is not in main, then i have to write the same thing in shell
[00:09] <smoser> (or python)
[00:09] <smoser> people dont care about speed that much.
[00:09] <smoser> and really, why would you call this program 1000s of times ?
[00:10] <smoser> it changes once per 6 months
[00:10] <bdrung> bash completion and bashrc
[00:10] <smoser> thats fair.
[00:10] <smoser> but i bet i can write native bash that are faster
[00:10] <smoser> :)
[00:10] <bdrung> Daviey: the binary size is due to haskell
[00:10] <smoser> or very close.
[00:12] <bdrung> smoser: i am willing to adopt a shell script if it can do the same as the haskell script and comes with a test suite
[00:12] <smoser> well.... that'd only get us part of the way.
[00:12] <bdrung> i can split distro-info-data into a separate package
[00:13] <smoser> ok.
[00:13] <smoser> yeah, so that'd work.
[00:13] <Daviey> bdrung: Do you agree or not that a tool for this function, is crazy being 1.5M ?
[00:14] <smoser> Daviey, i dont think we need to be rude :)
[00:14] <smoser> i'm really thankful for the utility.
[00:14] <bdrung> Daviey: yes, 1.5M is huge (but this is a restriction of Haskell)
[00:14] <Daviey> Oh i am aswell.. i think that came out wrong.. Sorry bdrung
[00:14] <bdrung> smoser: which interface do you use?
[00:14] <smoser> i just wish i would have realized it needed some help for main inclusion.
[00:14] <smoser> i'm using the shell interface.
[00:14]  * bdrung wasn't offended.
[00:14] <smoser> and i'd prefer that just because i dont care to do the date math.
[00:15] <smoser> (shell interface == command line == distro-info --supported)
[00:16] <bdrung> btw, the csv file shouldn't be used directly. so there are: command line, python, perl
[00:17] <smoser> right. i guess i hadn't thought of using python library.
[00:19] <bryceh> slangasek, hey in looking into a key mapping issue I notice our console-setup is quite diverged from debian's
[00:21] <bryceh> slangasek, there's been quite a bit of change.  I'm figuring I should just cherrypick out the specific fixes I need, but wanted to check with you if we should think about a larger import of some sort
[00:23] <bdrung> Daviey, smoser: which programming languages can be compiled in main?
[00:24] <bdrung> or should this tool be codified in shell?
[00:24] <smoser> i dont think there is a hard reason for shell.
[00:24] <smoser> if you wanted to write it in C, that'd be fine.
[00:25] <bdrung> i would prefer C over shell.
[00:25] <Daviey> bdrung: I was going to also mention vala, but it's been demoted this cycle..
[00:25] <smoser> that'd be fine. the only advantage of shell over C would be executable size.
[00:25] <bdrung> vala would be a nice tool to learn
[00:26] <Daviey> smoser: You don't think there is a slight speed advantage in C?
[00:26] <bdrung> smoser: really? shell would be smaller than C?
[00:26] <smoser> $ ls -l /bin/true
[00:26] <smoser> -rwxr-xr-x 1 root root 22896 Nov 20 12:42 /bin/true
[00:26] <Daviey> smoser: I imagine true is a compelx tool :)
[00:28] <bdrung> running u-d-t 100 times takes 0.330s and running the python version of it takes 3.045s
[00:29] <smoser> bdrung, where is "the python version" ?
[00:29] <bdrung> smoser: in the source in python/
[00:31] <bdrung> but it lacks some parameters
[00:35] <ScottK> jtaylor: Why does python-numpy recommend gcc, but python3-numpy does not?
[00:37] <infinity> bdrung: shell, C, C++, perl, python, there are a few options.
[00:38] <infinity> bdrung: As much as it's taboo to mention it, Perl would do this same job MUCH faster than Python. :P
[00:38] <smoser> infinity, FOR SHAME!
[00:38] <bdrung> infinity: nope
[00:38] <infinity> bdrung: (And it could be done entirely in perl-base, and have no deps outside Essential, I'm sure)
[00:38] <bdrung> infinity: the perl version was the slowest
[00:38] <infinity> bdrung: That's a pretty bold nope.
[00:39] <bdrung> infinity: you can either blame perl or tumbleweed for that slowness ;)
[00:39] <infinity> I'll go with the latter.
[00:40] <bdrung> i would ask you to write a faster one, but perl is not readable.
[00:40] <infinity> But other than the slightly larger disk footprint, C seems like a fair choice.  It's a simple enough thing to write bug-free on the first go.
[01:02] <cjwatson_> bryceh: it's a pain to merge and historically merges have introduced a lot of fragility, so I would be -1 on a merge at this point.  feel free to cherry-pick, though.
[01:02] <bryceh> cjwatson, sounds good, will do
[01:02] <cjwatson> that's why it tends to "fall behind" as some people see it
[01:03] <cjwatson> we'll deal at some point
[01:03] <bryceh> yeah I can tell; the patch I'm dealing with appears to be a whole bunch of different changes all mashed together.  picking out what I need will be interesting
[01:03] <cjwatson> hope you aren't trying to work with lp:{debian,ubuntu}/console-setup
[01:04] <bryceh> cjwatson, am I interpreting correctly that at least some of the keyboard mapping is duplicating code elsewhere?
[01:04] <cjwatson> almost certainly
[01:04] <bryceh> cjwatson, no, git checkout from debian
[01:04] <cjwatson> good
[01:04] <cjwatson> yeah, some of the committers aren't ... quite perfect at separating out logical changes
[01:26] <Sarvatt> ok so I want to file a bug about how apport hooks with questions present all questions twice if you click "show details" on the "Sorry, Ubuntu 12.04 has experienced an internal error." window to figure out what package the bug is for. Where would that go now?
[01:26] <Sarvatt> whoopsie or apport? :)
[01:28] <Sarvatt> xorg bugs are no fun when you have to click show details to figure out that its even the xorg bug you want to file now that it shows that generic info and walk through all of the questions to see what package its for, then again to actually file it
[01:31] <Sarvatt> i usually have at least 10 .crash files in /var/crash that i've already filed bugs for so clicking show details on each is required to see if i'm wasting my time filing the same one
[02:00] <smoser> bdrung, still around ?
[02:19] <bdrung> smoser: yes
[02:20] <smoser> i have a version of ubuntu-distro-info in shell that compares favorably in load times to the haskel
[02:20] <smoser> http://paste.ubuntu.com/891634/
[02:21] <smoser> i think the --date= needs some work.
[02:21] <smoser> but it shouldn't add too much
[02:22] <smoser> locally, 1000 runs shows http://paste.ubuntu.com/891636/
[02:23] <smoser> but i have to run now.
[02:24] <smoser> i'm willing to polish that some more.
[02:43] <bdrung> smoser: you are fast. it could use "set -e". some comments would be nice.
[02:50] <bdrung> smoser: --devel and --lts produce wrong output
[04:01] <slangasek> bryceh: console-setup isn't a safe package to be doing large imports of post-FF... I'd say cherry-pick what you need
[04:01] <ScottK> slangasek: He got the lecture from cjwatson already today.
[04:01] <slangasek> heh, ok
[04:04] <bryceh> slangasek, yeah picked out the bit I needed.  I gather all changes are direct applied rather than use a patch system?
[04:05] <slangasek> it's a native package maintained in a VCS - a patch system would be unhelpful :)
[04:05] <bryceh> er...
[04:18] <komputes> hi bryceh how are you?
[04:18] <bryceh> hi komputes I'm good
[04:19] <komputes> thats good to hear, long time no talk. are you strictly maintaining xorg these days?
[04:20] <bryceh> komputes, I would say more indulgently
[04:25] <komputes> it's in your blood :D
[08:04] <dholbach> good morning
[08:10] <ZeroKewl> hi
[08:11] <ZeroKewl> where did xbox controller started working out of box in ubuntu 12.04
[08:11] <ZeroKewl> when* -where
[08:32] <Riddell> janimo`: libva-cedarview-vaapi-driver for restricted?
[08:52] <apw> can anyone tell me what an package flagged 'un' in dpkg -l means ?
[08:52] <apw> un  linux-image-3.0
[08:53] <apw> and indeed how one gets rid of em
[08:56] <geser> apw: see the header of "dpkg -l" for an explanation (un: Desired=Unknown, Status=Not Installed)
[08:57] <apw> geser, hmm oh desired ... so once you install a packge its in your db forever even if its not longer installed
[08:57] <smb> That does not seem to be what happens when I uninstall things
[08:58] <smb> Those seem to either become rc (removed configured) or go away (purged)
[08:59] <geser> apw: I guess that's also true for any package dpkg knows about (because it's listed in Recommends, Suggests, Conflicts, etc)
[08:59] <apw> geser, hmmm, i'd expect them to be singletons as they are all test kernels once installed long ago
[09:01] <apw> un  linux-image-3.0-0-generic                             <none>                                                (no description available)
[09:01] <apw> so that one i literally just purged it and its gone to that state
[09:03] <geser> IIRC dpkg has a list of package names it has ever seen
[09:03] <geser> check if it's listed in /var/lib/dpkg/available
[09:05] <apw> geser, yep it is in there
[09:09] <geser> try "dpkg --forget-old-unavail" (or ask someone who knows dpkg better than me how to get rid of those old entries)
[09:12] <smb> So the difference is in how one uses dpkg -l: "dpkg -l|grep linux-image" won't show un, but "dpkg -l linux-image-*" will do
[09:12] <jhojho> has anyone actually tried out the openssl package on 64bit precise?
[09:13] <jhojho> i'm getting much slower speed timings for one and secondly, it seems to be dropping back to sslv3 vs tls1 for some reason
[09:13] <jhojho> even when i have what I think is a correct config.....
[10:04] <janimo`> Riddell, please purge that package, there will be a newer upload later, with fixed copyright
[10:06] <Riddell> janimo`: rejected!
[10:06] <janimo`> Riddell, thanks!
[11:06] <janimo`> pitti, the acpi-support deprecation wikipage is almost 3 years old. https://wiki.edubuntu.org/AcpiSupportDeprecation . What is the status of this package? I lookoed at the hotkey debugging pages that mantioned it is being phased out but no details
[11:17] <nailora> could someone un-private bug #930677 if possible? thanks!
[11:18] <nailora> it is referenced in Bug #952577
[11:25] <sladen> nailora: what is your Launchpad ID?
[11:28] <sladen> nailora: poke
[11:29] <brendand> sladen, i don't see anything private in there so it's un-privated
[11:33] <sladen> nailora: see brendand above ^^
[11:41] <nailora> https://launchpad.net/~nailor
[11:42] <nailora> brendand: thanks
[11:59] <MacSlow> mvo, ping
[12:22] <mvo> MacSlow: pong
[13:04] <slangasek> janimo`: acpi-support hasn't been phased out yet because there are some hotkeys that nothing else in the stack has handling for (antenna, touchpad toggling keys)
[13:06] <seb128> slangasek, the pad enable,disable is handled by gnome-settings-daemon (just for info) but maybe you need something not desktop specific for those ;-)
[13:07] <slangasek> seb128: when did it start handling them?
[13:08] <seb128> slangasek, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=1c8f64d1dc6beb7d27a6dce74fa29e27e8c34583
[13:08] <seb128> slangasek, so in the natty version it seems
[13:09] <seb128> slangasek, if that's the same keys we are talking about
[13:10] <slangasek> seb128: ah, I'm pretty sure X can't actually receive that keypress due to the core input limitation
[13:11] <janimo`> slangasek, Riddell the acpi-support changelog mentions dropping power.sh when kubuntu starts using upower, not sure if that is the case, it is an old comment
[13:11] <janimo`> slangasek, and are there better suited packages for the things acpi-support is still needed for or it is here as a catch-all for the forseeable future?
[13:11] <seb128> slangasek, well, it works for most people it seems
[13:12] <slangasek> janimo`: if there were better-suited packages, it wouldn't still be needed :)
[13:12] <seb128> slangasek, we got bugs about the notify-osd corresponding images being reversed previous cycle
[13:12] <slangasek> seb128: hmm, I'll have to test then
[13:12] <seb128> slangasek, which indicates the g-s-d action get triggered
[13:12] <seb128> slangasek, ok ;-)
[13:13] <slangasek> seb128: right, but we just recently (this cycle) got a report from someone else wanting touchpad toggle support in acpi-support for a new device
[13:13] <janimo`> slangasek, well what I meant was there may be other packages but migrating is ongoing and not terribly urgent
[13:13] <janimo`> as opposed to noweher to migrate yet :
[13:13] <janimo`> :)
[13:14] <slangasek> janimo`: power.sh should definitely go away if kubuntu is using upowerd now
[13:14] <seb128> slangasek, https://bugs.freedesktop.org/show_bug.cgi?id=31300#c2 might be interesting
[13:15] <seb128> slangasek, well not sure what happened since and if that works for laptop that have a physical action connected to the key or not
[13:15]  * slangasek nods
[13:16] <seb128> slangasek, seems it's the same issue than sound, some hardware require you to handle to action, some others don't
[13:16] <slangasek> well, seems like those should be represented as different types of events
[13:17] <slangasek> not sure why a button press that the software isn't expected to handle should ever show up as a key event
[13:18] <slangasek> anyway, I'll test with my T60 and see what I get
[13:18] <seb128> slangasek, because you still want the notify-osd bubble
[13:18] <slangasek> there's no reason to logically represent that as a *keypress* though
[13:18] <seb128> slangasek, what is doing the action doesn't matter much, but you want a consistent feedback mechanism
[13:18] <slangasek> it's a notification event
[13:18] <seb128> right
[13:18] <seb128> that's a good point ;-)
[13:19] <slangasek> so there should be a different channel for that from the kernel to g-s-d... and maybe that's the one that actually works now
[13:19] <slangasek> anyway, I know thinkpads *don't* handle it in hardware, so I'll check it out and report back :)
[13:21] <seb128> slangasek, thanks ;-)
[13:26] <stgraber> dpm: can you add me to the translation team mailing-list whitelist so I can reply to mails without having them go through moderation, yet don't need to subscribe?
[13:29] <dpm> stgraber, I can at least try :) IIRC there is a filter to accept any ubuntu.com address, but it seems not to be working. Let me have a look...
[13:31] <stgraber> dpm: I usually do it through the moderation queue, when you accept my next e-mail, you can tick a box saying any other e-mail from my address is accepted
[13:32] <dpm> stgraber, ah, I see. I never use the admin interface, I use listadmin, which is much quicker
[13:33] <dpm> in any case, you're now whitelisted
[13:34] <stgraber> dpm: thanks
[13:36] <cjwatson> it'd be awesome if listadmin could understand that bit of the moderation queue interface
[14:05] <cjwatson> popey: bug 960092 - can you tell me about your partition/filesystem layout?
[14:06] <soren> debconf is confusing me.
[14:06] <soren> When I add a template to a package  (which already used debconf)... How does its new templates get added to the debconf cache?
[14:07] <soren> dpkg and debconf are separate, so it's not dpkg itself.
[14:07] <cjwatson> the frontend loads templates from whatever it's operating on
[14:07] <cjwatson> dpkg-preconfigure does it too, via apt-extracttemplates
[14:07] <soren> Ah.
[14:08] <soren> It's a bit special. I'm building something very much like dbconfig-common, so my package ships the templates, but doesn't actually use debconf itself.
[14:08] <soren> ...so that's why they're not getting loaded (and why I can't reference them with db_register from another package).
[14:08] <cjwatson> there's debconf-loadtemplate if you really have t
[14:08] <cjwatson> o
[14:09] <cjwatson> or you could load the confmodule in your postinst, but do nothing else with debconf
[14:09] <soren> The latter sounds like a better idea.
[14:09] <cjwatson> likely, yes
[14:09] <soren> I guess I eventually will want to actually use debconf in this package too.
[14:09] <soren> I wonder how the first set of templates got added..
[14:10] <popey> cjwatson: left comment on the bug
[14:10] <soren> I guess I must have triggered debconf at some point. I can't imagine how or why, but meh.
[14:11] <cjwatson> popey: hm, so 1.99-17ubuntu1 worked but 1.99-18ubuntu1 failed?
[14:11] <cjwatson> (wtf?  I didn't touch partition handling.)
[14:11] <popey> cjwatson: well, it may have been a day or more between updates on that box. but it is my main desktop, and doesn't get rebooted that often, often suspended
[14:12] <cjwatson> popey: you said you reinstalled grub to get it back to a bootable state, so presumably you know what version you reinstalled?
[14:13] <popey> cjwatson: I just did grub-install
[14:13] <popey> cjwatson: sorry, "grub-install /dev/sdb"
[14:13] <cjwatson> oh, you were probably misconfigured to start with then.  I left a question in the bug ...
[14:14] <soren> cjwatson: Fantastic, that did the trick. Thanks!
[14:14] <popey> cjwatson: sorry, pasted, should have attached.
[14:15] <cjwatson> no matter
[14:39] <soren> cjwatson: What if I'm updating an existing template rather than adding a new one? The new ones are in /var/lib/dpkg/info/<my package>.templates, and I do include confmodule in my postinst, but /var/cache/debconf/templates.dat still has the old templates.
[14:42] <cjwatson> soren: that normally just works
[14:42] <cjwatson> sorry, not sure what the problem might be in your case
[14:43] <smb> cjwatson, Just to make sure I understand right: so the multipath udeb would only carry dm-multipath and dm-round-robin ? I am not sure abotu the scsi device handlers. They might be only used for multipath setups but on the other hand are grouped into the scsi subsystem.
[14:44] <soren> Perhaps it refrains from refreshing because there are multiple owners?
[14:45] <cjwatson> smb: {dm-multipath,dm-round-robin} -> multipath-modules, scsi device handlers -> scsi-modules sounds o
[14:45] <cjwatson> ok
[14:46] <cjwatson> smb: I'm just trying to claw things back into being slightly more in line with Debian because it means less unnecessary divergence in the userspace installer code
[14:47] <smb> cjwatson, ok thanks. will look to get it done. Less divergence is good and it should not be a really big change, so it makes much sense to get it done right now that there need to be changes anyway
[14:51] <cjwatson> smb: great, thank you
[14:51] <cjwatson> soren: I would have expected it to add an owner in the case of any shared templates, and just add any non-shared ones
[15:10] <soren> cjwatson: *blush*
[15:10] <soren> cjwatson: I had a copy of the templates file in another package.
[15:11] <soren> cjwatson: With all the same names.
[15:11] <soren> cjwatson: So each time I installed that, I'd get the old version.
[15:12] <soren> cjwatson: And my test-debug cycle included: Install the config-common package -> isntall a package that consumes it -> test.
[15:12] <soren> cjwatson: So it always overwrote the changed templates.
[15:12] <cjwatson> whoops
[15:13] <cjwatson> yeah, easy to make that kind of mistake with shared templates
[15:19] <soren> cjwatson: Ironically, I'm doing this to *avoid* sharing templates, and just ship them in a single package (and use db_register <common package>/$question <consumer package>/$question). I just copied the templates file over at some point by mistake.
[15:19] <soren> I never noticed because so far, I've only been *adding* new templates. Added templates got through just fine.
[15:19] <soren> *headdesk*
[15:19] <cjwatson> heh
[15:19] <cjwatson> ah well
[15:52] <tsdgeos> what's the best way to store a dictionary inside a gvalue?
[15:52] <tsdgeos> i went the way of gvalue being a variant and the variant being a dictionary
[15:52] <tsdgeos> sounds ok?
[16:05] <Riddell> janimo`: yes we use upower in KDE
[16:05] <slangasek> mvo: I'm not sure I understand the right way to pop up a notification about a package's download failing; from what I can see in the code, /var/lib/update-notifier/user.d/ is only processed when a new file is added there or when the applet starts, is that right?
[16:05] <slangasek> mvo: in which case it seems I want the script to add/remove a file to that directory, and not use DisplayIf?
[16:06] <mvo> slangasek: yeah, add it or touch it (to display the notification again)
[16:07] <slangasek> ok
[16:10] <smb> cjwatson, Oh, I just remembered something else. I think you at least sponsored some updates to dmraid user-space. I think I found some discrepancy in the initramfs-tools scripts/hooks. Unfortunately lost the bug reporter for now... bug 948291 (comments 37 and 38)...
[16:11] <smb> (afraid it is a bit in the middle of things... just the difference between output and input seemed like one thing more likely broken...)
[16:11] <cjwatson> smb: sponsored, but I don't feel confident to make changes on my own initiative
[16:12] <cjwatson> smb: if you can get hold of psusi, he tends to be useful on this
[16:12] <smb> cjwatson, Ok, I'll try... Saw his name too
[16:15] <ricotz> smoser, hi, could you have a look at qemu-kvm which installs /usr/etc/qemu/target-x86_64.conf, i guess this should go to /etc/qemu/target-x86_64.conf
[16:16] <smoser> ricotz, can you open a bug ?
[16:16] <ricotz> smoser, i was hoping pinging you might be enough
[16:17] <smoser> well, i was just going to ping hallyn
[16:17] <smoser> but ... a bug would still be helpful.
[16:17] <ricotz> ok
[16:19] <slangasek> mvo: do you know what creates /var/lib/update-notifier/user.d/firefox-restart-required nowadays?  The only thing I find in the firefox postinst is 'touch /var/run/firefox-restart-required'
[16:19] <slangasek> mvo: I'm trying to find this to see how they've handled localization so I can copy it
[16:19] <ricotz> smoser, https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/960359
[16:19] <mvo> slangasek: sorry, I don't know
[16:19] <mvo> slangasek: maybe the ubufox stuff?
[16:20] <mvo> slangasek: but chrisccoulson should know
[16:20] <slangasek> I'll look there, thanks
[16:20] <smoser> ricotz, gracias
[16:20] <chrisccoulson> mvo, slangasek, we haven't had that in firefox since lucid
[16:20] <slangasek> chrisccoulson: hah, ok
[16:21] <slangasek> chrisccoulson: why did it go away?
[16:21] <slangasek> (OOI)
[16:22] <chrisccoulson> slangasek, it was sort-of redundant. we already have the restart notification banner inside firefox, so we just use that rather than relying on update-notifier
[16:22] <slangasek> fair enough
[16:22] <slangasek> (though personally, the restart banner drives me crazy ;)
[16:23] <chrisccoulson> slangasek, it's meant to make you want to restart :)
[16:23] <chrisccoulson> although, i think i changed the timings this cycle so that it doesn't remind so often
[16:23] <slangasek> chrisccoulson: it doesn't make me want to do that, it makes me want to swear off web browsing! :)
[16:23] <chrisccoulson> lol
[16:24] <slangasek> ah, looks like the french translation is statically encoded here, ah well
[16:27] <chrisccoulson> slangasek, we might get rid of the restart banner at some point (and turn it in to a notification panel inside firefox instead, which doesn't shift the content down when it appears)
[16:44] <mdeslaur> slangasek: fyi: #952556
[16:47] <slangasek> mdeslaur: are you seeing this behavior?
[16:47] <mdeslaur> slangasek: I haven't checked personally, but it looks like something we should take a look at
[16:48] <mdeslaur> I'll try it on my test laptop, one sec
[16:50] <slangasek> mdeslaur: looks like I can reproduce it here
[16:50] <slangasek> which is strange, because I definitely *didn't* see this earlier in the cycle when making that change
[16:52] <slangasek> cking: why are you sure bug #952556 isn't a kernel bug?  I don't think this was the behavior in January at the time I changed the hdparm apm_battery setting, and hdparm hasn't changed at all since
[16:52] <slangasek> so I think something has changed in the kernel
[16:52] <mdeslaur> slangasek: well, some of the desktop power optimisations may have decreased regular disk activity
[16:53] <slangasek> yes, that was actually a precondition of me changing hdparm
[16:53] <mdeslaur> ah! i see
[16:53] <slangasek> before, the root problem wasn't the spin*down* time, it was the spin *up* frequency
[16:53] <cking> slangasek, well, it still happens when the user uses an oneiric kernel
[16:53] <slangasek> cking: ok
[16:53] <slangasek> that's pretty conclusive then
[16:54] <cking> and I checked it on an hpmini this afternoon
[16:54] <slangasek> let me see if something's regressed on the desktop to cause these spin-ups
[16:54] <cking> I also factored out the pm-utils changes just to sanity check things
[16:55] <slangasek> so, setting a higher spindown time by default is probably reasonable in any case
[16:55] <slangasek> and would guard against destroying disks
[16:55] <slangasek> so I think we'll go ahead with that
[16:56] <mdeslaur> fwiw, my count increased by 3 in 5 minutes
[16:57]  * slangasek breaks out fatrace \o/
[16:58]  * mdeslaur tries fat race too :)
[17:03] <slangasek> kinda looking like a firefox regression
[17:03] <slangasek> or possibly a google regression :P
[17:05] <cking> slangasek, yep I think a higher spindown time is a good solution
[17:09]  * micahg pops his head up
[17:10] <doko> is there a known issue with usb disks in the precise kernel? getting now I/O errors with the second usb disk. just do not want to believe that both external disks are damaged
[17:11] <mdeslaur> wow, fatrace is awesome
[18:09] <slangasek> mvo: I notice as I'm testing this u-n change that u-n only processes hooks when something touches /var/lib/update-notifier/dpkg-run-stamp.  It seems to me that the two should be somewhat independent?
[18:59] <ahasenack> SpamapS: ping, around?
[19:04] <psusi> ok, so multipath-tools has a binary package named multipath-tools-boot that contains the initramfs hook to add multipath-tools and kpartx to the initramfs... dmraid needs kpartx to be in the initramfs.. so, should I add a hook to dmraid to copy the kpartx binary, or split the multipath-tools hook in two, so there is on efor multipath-tools-boot, and one for kpartx?  hrm...
[19:08] <cjwatson> we generally put the hooks in the package that ships the binary because that means that the initramfs gets updated every time the package that actually ships the binary is updated, which is important
[19:09] <cjwatson> so maybe in kpartx itself but with something to arrange that it only actually goes in the initramfs when needed?
[19:10] <psusi> ahh.. hrm.. what would that something be?
[19:10] <cjwatson> not sure :-)
[19:11]  * cjwatson handwaves merrily
[19:11] <ahasenack> hi, quick (I hope) question about bzr merge-upstream, it seems it is bzr deleting all files and then bzr adding all the new files, that's not a merge
[19:12] <ahasenack> bzr st shows it removing and adding the same file, even though that file didn't change regarding the upstream version
[19:12] <ahasenack> like, the LICENSE file, it's exactly the same
[19:12] <psusi> what is it that makes the initramfs update when you upgrade the package anyhow?  does it need to call update-initramfs from its postinst?
[19:12] <cjwatson> psusi: right, and that ends up activating a trigger
[19:16] <psusi> hrm... this is odd... multipath-tools-boot has a postinst that runs update-initramfs to process the included hook... the hook checks for the existance of /sbin/multipath-tools and exits if it doesn't exist.  multipath-tools-boot does not depend on multipath-tools... so strangely, you can install it and it effectively does nothing unless you also install multipath-tools
[19:17] <psusi> I think I'll fix the existing hook so that it just skips the multipath-tools parts if it is not found, but if kpartx is found, will copy that in... then add multipath-tools-boot as a depend of dmraid
[19:20] <broder> psusi, cjwatson: you could use the initramfs-tools variable thing that plymouth uses to trigger
[19:21] <broder> so then i think anything that wanted kpartx would ship a file in, uh, /usr/share/initramfs-tools/conf-hooks.d/blah
[19:27] <cjwatson> broder: thank you for concretifying my handwaving
[19:29] <mvo> slangasek: sorry for the delay- that is correct, it was designed to not popup in the middle of a upgrade, originally this handled stuff like the reboot required. but indeed, its no longer a valid reason (as reboot-required is done differently these days)
[19:30] <slangasek> mvo: ok, I'll adjust the code then to process the hooks anyway, thanks
[19:32] <mvo> thanks
[19:32] <mvo> for a bit of background, I had hoped we could get rid of update-notifier in favor of upstart user session event scripts, but we are not there yet
[19:32] <mvo> (it seems at least)
[19:39] <slangasek> ah :)
[19:51] <SpamapS> ahasenack: howdy
[19:51] <ahasenack> SpamapS: \o/
[19:52] <ahasenack> SpamapS: so I tried a bit bzr merge-upstream, can I make some questions?
[19:53] <ahasenack> SpamapS: are you on the udd mailing list?
[19:54] <micahg> https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2012-March/001052.html
[19:54] <ahasenack> micahg: thanks! :)
[19:57] <SpamapS> ahasenack: I'm not
[19:57] <ahasenack> SpamapS: my question is above in the archive link that micahg pasted
[19:57] <ahasenack> SpamapS: basically, seems like bzr merge-upstream deletes and adds all files again
[19:57] <ahasenack> regardless if they had changes or not
[19:58] <SpamapS> ahasenack: hm
[19:58] <SpamapS> ahasenack: I would not expect it to do that.
[19:58] <ahasenack> SpamapS: good :)
[20:01] <SpamapS> ahasenack: I am trying it now.. I've never used the bzr branch with --revision and --version before.. it may work differently
[20:02] <ahasenack> SpamapS: I tried a few combinations, but got the same result
[20:03] <micahg> it might be treating it as a bzr branch instead of an upstream tarball, but I'm not sure how the upstream tarball behaviour works TBH
[20:04] <SpamapS> ahasenack: as micahg is eluding to.. try it that way
[20:04] <SpamapS> with bzr exported to a tarball
[20:04] <ahasenack> SpamapS: I think it's what merge-upstream ends up doing, because I saw a tarball in the parent directory
[20:04] <ahasenack> SpamapS: but let's try
[20:05] <ahasenack> SpamapS: yeah, now it worked as expected
[20:06] <ahasenack> SpamapS: http://pastebin.ubuntu.com/892732/
[20:07] <SpamapS> ahasenack: so, I would suspect that when doing a bzr branch, there is some extra magic being attempted..
[20:09] <ahasenack> SpamapS: what you did yesterday, was with a tarball?
[20:10] <ahasenack> SpamapS: and, did you just try with a branch? Did you get the same add/remove outcome as I?
[20:12] <SpamapS> ahasenack: what I did yesterday was upload a pure source package. The package importer pulled that into ubuntu:landscape-client
[20:13] <ahasenack> SpamapS: ok, and did you try merge-upstream with a branch just now, just to see if you get the same outcome as I?
[20:13] <SpamapS> ahasenack: I did, and got the same outcome.
[20:14] <ahasenack> ok
[20:14] <ahasenack> looks like we should avoid that for now
[20:14] <ahasenack> SpamapS: thanks!
[21:16] <bernie> anyone knows why there have been no new chromium snapshots in the ppa for a couple of months?
[21:17] <micahg> bernie: various reasons, I'm trying to get it sorted, hopefully by the time precise releases
[21:18] <bernie> micahg: cool thanks
[22:11] <rsalveti> ogra_: do you know why the installer slideshow is still broken on arm?
[22:12] <rsalveti> don't remember if it was simply something we decided to drop, or that wasn't enabled properly after that bug we had with webkit
[22:12] <rsalveti> I'd like to have it working again as then we can have a similar installer experience as we have for other archs
[22:12] <rsalveti> let me try to find a bug for it
[22:32] <rsalveti> ogra_: neither universe nor multiverse is enabled by default
[22:33] <rsalveti> it's also lacking the deb-src lines as well
[22:33] <rsalveti> guess a bug at livecd-rootfs
[23:15] <TheMuso> @pilot in
[23:34] <popey> cjwatson: just seen someone else with the same grub issue I had
[23:36] <popey> cjwatson: https://plus.google.com/u/0/115941496951821782702/posts/1vwCLcQtFY4
[23:37] <popey> pointed him at the bug report