[00:59] <meoblast001> hi
[03:41] <LaserJock> bryce: around?
[03:42] <bryce> indeed
[06:00] <pitti> Good morning
[07:20] <TheMuso> pitti: I see there are currently no studio alpha images on the tracker to test. Has the tracker even been updated for ubuntu/kubuntu etc images yet, or is it just studio that hasn't been updated?
[07:22] <pitti> TheMuso: I think I just missed it, hang on
[07:23] <pitti> TheMuso: http://cdimage.ubuntu.com/ubuntustudio/daily/20090722.1/ should hopefully work
[07:23] <pitti> TheMuso: added to tracker, thanks
[07:23] <TheMuso> pitti: np thanks.
[07:26] <superm1> pitti, i may have some livecd-rootfs changes that will fix one of serious bugs for mythbuntu ISOs. i'm verifying right now that it actually fixes things with a local run of livecd-rootfs
[07:33] <pitti> superm1: thanks; infinity, would a livecd-rootfs upload need any manual treatment for the buildds, or does it "just happen"?
[07:34] <StevenK> pitti: The buildds will upgrade once a day for livecd-rootfs, but it's at like 1:15am DC time
[07:34] <pitti> StevenK: ah, thanks
[07:43] <pitti> superm1: bug 403289, that wasn't due to gdm then? gdm was recently fixed to not pull in gnome-session any more
[07:44] <superm1> pitti, i think it's because somehow a recommends is pulling in a whole bunch of gnome because of the order of dependency resolution for live disk builds
[07:45] <superm1> because mythbuntu doesn't use the tasks for LIST and LIVELIST (some problems earlier this year with doing so)
[07:45] <pitti> superm1: you're using custom.conf in bug 403290 now?
[07:45] <pitti> superm1: (sorry, gdm.conf and gdm-cdd.conf have gone entirely)
[07:45] <superm1> as for bug 403290, yeah i've adjusted the code to use custom.conf
[07:45] <superm1> didn't realize gdm-cdd.conf was gone entirely, will be uploading to fix that bug shortly
[07:46] <superm1> with gdm-cdd.conf being gone, i'm not sure how to fix or even address bug 403291 though
[07:47] <StevenK> pitti: Autologin is completly broken for UNR too
[07:47] <StevenK> pitti: But I suspect you knew that already :-)
[07:48]  * ogra hugs pitti 
[07:48] <pitti> StevenK: just trawling through the bugs
[07:48] <ogra> pitti, thanks for moving udhcpc
[07:49] <StevenK> superm1: Hmm, perhaps your seeds need some clean up to stop metacity and co getting installed?
[07:49] <pitti> no prob, got approved recently
[07:50] <ogra> it will indeed bloat the alternate CD ... with 23k more :)
[07:51] <superm1> StevenK, any easy way to do such things?
[07:51] <StevenK> superm1: Easiest way is to check the germinate output, since it contains a "Why" column
[07:52] <StevenK> superm1: http://people.canonical.com/~ubuntu-archive//germinate-output/mythbuntu.karmic/all
[07:52] <pitti> StevenK: autologin> you mean bug 403309 ?
[07:52] <superm1> but since we install with metapackages rather than tasks, is that valid?
[07:52] <pitti> StevenK: (just asked for custom.conf there)
[07:52] <ogra> mvo, !
[07:52] <ogra> the man i wanted to talk to !
[07:52] <mvo> hey og
[07:53] <mvo> ra
[07:53] <superm1> StevenK, but i suppose if we can rid them from there we can switch to tasks for livecd-rootfs
[07:53] <ogra> mvo, i want to make it impossible to upgrade from jaunty to karmic for certain armel machines, can you point me to the right place to put a script that checks /proc/cpuinfo ?
[07:54] <superm1> StevenK, so in looking through that, it claims that metacity comes in from gnome-control-center which comes from gnome-panel, which comes from gnome-panel-dbg, but it doesn't go any further up the chain, so how do I rid that out of there?
[07:55] <StevenK> superm1: Yeah, I sort of fell over there too
[07:56] <mvo> ogra: upate-manager and there DistUpgrade/DistUpgradeQuirks.py - if you give me the details (what to look for in cpuinfo)  I can add it quickly for you if oyu want
[07:56] <superm1> StevenK, so perhaps is there a way I can just blacklist gnome-panel from the seed and hope for the best then?
[07:58] <ogra> mvo, i'll work out a patch for you, essentially it should block if the "Processor" line of /proc/cpuinfo contains anything thats smaller than ARMv6 or ARMv7, thanks for the pointer
[07:58] <mvo> ogra: ok, thanks
[08:00] <pitti> superm1: my feeling is that it's not worth re-rolling the isos just for bug 403290, since a mere upgrade will fix it as well; WDYT?
[08:00] <pitti> StevenK: UNR uses autologin by default, which would make bug 403309 kind of a showstopper?
[08:01] <superm1> pitti, agree, not just for bug 403290.  bug 403289 and bug 403291 however if a solution can be came up with would be worth a reroll
[08:01] <pitti> StevenK: I'm trying to understand where the autologin configuration happens (gdm itself works just fine with autologin, but behaves that way if you specify an invalid user)
[08:01] <StevenK> pitti: The livecd does, but doesn't desktop also do that?
[08:01] <pitti> superm1: right; bug 403291 might need gdm changes, let me check the code about the default session
[08:02] <pitti> StevenK: it works there (we don't default to it, too)
[08:02] <pitti> StevenK: I recently fixed that in user-setup (which wrote "AutomaticLogin=ubuntu" instead of $USER)
[08:02] <StevenK> Ahh
[08:02] <StevenK> pitti: Right, so it sounds good to get a re-roll for this
[08:03] <pitti> StevenK: might it be that this bug somehow crept into the UNR image builder as well?
[08:03] <pitti> StevenK: I don't really know how the .img is put together, I'm afraid; is that a standard live system with ubiquity?
[08:03] <pitti> StevenK: oh argh, http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/20090722/karmic-netbook-remix-i386.manifest
[08:03] <pitti> indeed, it has the old ubiquity
[08:04] <StevenK> pitti: Karmic UNR is now an .iso
[08:04] <pitti> StevenK: so, if I re-roll them now, can someone test the new images soon?
[08:04] <StevenK> pitti: Sure
[08:04] <pitti> started
[08:05] <pitti> I'll fiddle the bugs now
[08:05] <superm1> StevenK, is there a nice command I can run to generate that germinate output myself so I can tweak with adding packages to blacklist in mythbuntu.karmic and seeing if that improves things?
[08:06] <StevenK> superm1: That bit I'm not sure about, sorry
[08:16] <pitti> superm1: I followed up to bug 403291 with the gdm analysis, FYI
[08:16] <pitti> superm1: however, I don't think we'll manage to fix this in the next couple of hours, TBH
[08:17] <pitti> superm1: so perhaps mythbuntu A3 could/should be released later? or you just skip A3 entirely?
[08:17] <superm1> pitti, if 403289 can be sorted out, we can go out a little later, otherwise we'll have to skip A3
[08:18] <superm1> based on your analysis, i agree that bug 403291 would likely be a moot point if 403289 is solved
[08:18] <pitti> superm1: I'm just on holiday from tomorrow until Tuesday, so we'd have to defer it for a bit
[08:19] <superm1> pitti, ah i see.  well i'll spend a little more tonight playing more with germinate.  if no luck then we'll plan to evaluate options after the weekend then
[08:19] <superm1> and i'll discuss it with my team and see what they think is the best
[08:19] <pitti> superm1: I'm sorry for that :/
[08:31] <pitti> lol, I just got two spam mails from facebook which want to become friends with "Apport"
[08:32] <ttx> pitti: we should start a LP group first. 'Apport facebook friends'
[08:32] <pitti> neither Apport nor me personally have ever come close to Facebook, so I wonder why I get these now :/
[08:33] <ttx> beh
[08:35] <pitti> StevenK: http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/20090723/ (also added to tracker)
[08:36] <StevenK> pitti: Thanks!
[08:36] <pitti> would be cool if you could give them a quick test
[08:58] <pitti> TheMuso: hm, I don't see ubuntustudio in earlier alpha announcements, how is that usually handled? do you send our your own announcement?
[08:59] <pitti> TheMuso: then again, there's no karmic/ on http://cdimage.ubuntu.com/ubuntustudio/releases/
[09:10] <superm1> pitti, okay it appears that the livecd-rootfs change i made got rid of most of the gnome stuff and kept what mattered
[09:11] <pitti> superm1: nice
[09:11] <superm1> so if you can reroll with the newer livecd-rootfs, I can grab in the morning and verify
[09:11] <pitti> superm1: as StevenK said, the buildds will only upgrade in about 15 hours :/
[09:12] <pitti> so, plenty of time to get it tested and uploaded
[09:12] <pitti> superm1: but that way you could annouce mythbuntu alpha-3 on Monday or so
[09:12] <superm1> pitti, okay that should be fine.  gives extra time to mirror and what not too after testing
[09:12] <pitti> superm1: I won't be there, but I'm sure Riddell or someone else will push the publish-release button for you
[09:13] <StevenK> pitti: But it can be done manually
[09:13] <pitti> StevenK: right, but both lamont and infinity are asleep right now
[09:15] <TheMuso> pitti: we didn't release previous alphas due to problems that hadn't been addressed by the time those alphas came out
[09:15] <TheMuso> related to the realtime kernel
[09:15] <pitti> TheMuso: ah, so want me to release this one now?
[09:46] <tseliot> pitti: if I wanted to add the support for collecting data from touchpads to apport, what part of apport should I work on?
[09:46] <pitti> tseliot: package hook for xserver-xorg-input-synaptic?
[09:46] <tseliot> pitti: yes, exactly
[09:47] <pitti> tseliot: it probably should be added to the generic xorg package hook
[09:47] <pitti> /usr/share/apport/package-hooks/source_xorg.py
[09:47] <pitti> tseliot: all other X packages symlink to that
[09:47] <pitti> tseliot: it's in x11-common I think
[09:47] <pitti> (dpkg -S)
[09:48] <tseliot> pitti: also, could I add a small C program (with no external dependencies) that I wrote?
[09:49] <tseliot> it simply uses a system call to extract data from the touchpad
[09:49] <pitti> tseliot: you can't do that in Python?
[09:49] <pitti> tseliot: the package is currently arch:all
[09:49] <pitti> tseliot: but of course you could add that helper to the -synaptics package, and call it from the hook
[09:50] <tseliot> pitti: no, it can't be done from Python
[09:50] <tseliot> pitti: but yes, I can add it to -synaptics as you say
[09:51] <pitti> tseliot: what does it need to do?
[09:52] <tseliot> pitti: the C program lists input devices and extracts their ids, names, etc.
[09:53] <tseliot> this would be useful for quirks
[09:53] <tseliot> furthermore I would like to collect the output of xinput too
[09:53] <pitti> tseliot: isn't that pretty much what udevadm gives you arleady?
[09:54] <tseliot> pitti: it's what lsinputs does but I stripped it down and changed a few things
[10:02] <tseliot> pitti: I've just tried udevadm but it doesn't give me what I need
[10:08] <pitti> TheMuso: did anyone test the current studio images? iso tracker says 0/4
[10:20] <pitti> StevenK: does the current UNR image now do what it should?
[10:20]  * ccheney is so tired
[10:20] <ccheney> been up since Jul 22 13:00 UTC
[10:21] <StevenK> pitti: I'm still having a look
[10:21] <ccheney> another 9-10 hour before i can go to sleep too :-\
[10:22] <pitti> ccheney: jetlag?
[10:22] <ccheney> pitti: i can't sleep on planes and flew to madrid then have a 6 hour layover before the train to caceres
[10:24] <ccheney> really its more  i can't sleep sitting up
[10:24] <pitti> ccheney: ah, debconf?
[10:24] <ccheney> yea
[10:32] <ogra> ccheney, july 22 ? which year ?
[10:34] <ccheney> ogra: er yesterday ;-P
[10:34] <ccheney> so about 30 hour or so when i finally get to the hotel
[10:36] <StevenK> ccheney: Not even things like Melatonin help?
[10:37] <glatzor> servus mvo
[10:37] <pitti> hey glatzor
[10:38] <glatzor> mvo, I reimplemented the twisted deferreds using the gobject main loop
[10:38] <ccheney> StevenK: i didn't try it this time but in the past it didn't seem to
[10:39] <Keybuk> pitti: why is there a udev task on bug #403381 ?
[10:39] <pitti> udev? that's wrong
[10:39] <ccheney> StevenK: of course my flight wasn't that long just managed to lose the night in the process, the main flight started at the equivalent of ~ 4pm for me and was only 7-8 hr long
[10:39] <Keybuk> pitti: you added it ;-)
[10:39] <pitti> argh
[10:40] <pitti> Keybuk: accidentally clicked on a canned response, sorry
[10:40] <pitti> fixed
[10:40] <pitti> but I'm sure that we could have fixed it in udev as well :-P
[10:40] <mvo> hey glatzor
[10:40] <mvo> glatzor: you rock!
[10:40] <ccheney> StevenK: melatonin seems to help reset my internal clock though when i finally do go to bed after travelling
[10:40]  * mvo hugs g'magic'tzor
[10:40] <glatzor> servus pitti
[11:05] <dpm> morning pitti, I'm having a look at the translations imports queue for karmic, and I've noticed a few debian/po-up/patches.pot (for e.g. gnome-panel) and similar templates. Without having had a closer look at it before, I always assumed that patches were first applied and then a single template was produced (when the package had only one). Is this something new or am I missing the point?
[11:05] <dpm> what are those templates?
[11:07] <seb128> dpm, those are a debian thing to do translations for debian changes
[11:10] <dpm> seb128: is this a common practice? Could we somehow track the Ubuntu/Debian translation changes due to patches with those?
[11:10] <seb128> dpm, no it's marginal I think we should not bother and just use launchpad
[11:16] <dpm> seb128: ok, thanks. I was just wondering, because (without having thought oo much on the implementation) perhaps it could be used to mark in Rosetts those strings which are only specific to Ubuntu. But then again, it might also introduce a special case in Launchpad which would not be desirable.
[11:17] <seb128> dpm, all debian changes are not marked this way though
[11:19] <dpm> ok, but within a single package which produces a separate .pot for patches, are generally all changes which affect strings collected in a single separate template?
[11:22] <seb128> dpm, it seems so
[11:24] <StevenK> pitti: Autologin looks great with the new spin
[11:24] <pitti> \o/
[11:25] <dpm> seb128: is it trivial to produce those separate templates for patches? I'm just wondering whether it would be useful to try to generalise that practice
[11:26] <seb128> dpm, should be trivial, it's a one line cdbs rules
[11:27] <seb128> dpm, I've not been looking to much into that I don't want po in the source package since that means you need upload to change translations
[11:27] <seb128> dpm, debian do that because they have no language packs they can use
[11:31] <pitti> StevenK, lool: http://cdimage.ubuntu.com/releases/karmic/alpha-3/ currently talks about the UNR "CD"
[11:31] <pitti> given that it's way over 700 MB, what should it say instead? Are people expected to use usb-creator to write an image?
[11:32] <dpm> seb128: but this would just introduce a change in which we have the same situation as now (package produces a pot on build) plus a second template for the patches also generated on build, wouldn't it? Is it not how it is done in gnome-session? That's one of the packages where I first spotted this additional template.
[11:33] <seb128> dpm, I don't know the specific, I never used the system, it just add lot of cruft in the source package since it build template and po for all of those in the debian directory
[11:33] <seb128> dpm, look the gnome-session source for details
[11:34] <dpm> seb128: I'll do, thanks
[11:34] <seb128> dpm, in fact I was cleaning that cruft out in some packages when I resynced on debian, I think it doesn't bring us anything and is noisy
[11:35] <pitti> Riddell: is there an equivalent for usb-creator in Kubuntu?
[11:35] <pitti> i. e. something that people can use to put an .iso to an USB stick?
[11:36] <seb128> pitti, the bzr version of usb-creator has a kde variant now
[11:37] <seb128> pitti, I'm waiting for that to land in karmic for some weeks now to switch it to gtkbuilder dunno why they don't upload to karmic
[11:37] <seb128> evand, ^
[11:37] <pitti> so how do KDE folks test these images then?
[11:38] <dpm> seb128: by cleaning that cruft you mean getting the package to build one single pot as usual? I think this might be the best approach for now, as otherwise I don't know what to do with those extra templates in the import queue. I think it might be worth considering if they might be useful in the future as I was saying earlier, but for now it think it might be best to stick to the more general practice of building one single template
[11:38] <evand> seb128: I'll do it now.  I've been hoping to finish the devicekit backend first, but that's not going to happen quickly
[11:38] <pitti> StevenK, lool: please cross-check http://cdimage.ubuntu.com/releases/karmic/alpha-3/, I updated the desdcription
[11:39] <seb128> evand, thanks, will you port the gnomevfs code to gvfs? or patches are welcome for that? same for gtkbuilder
[11:39] <evand> patches are welcome, but if no one else steps up, I'll surely fix those problems before UI freeze
[11:39] <pitti> evand: you are actually using dk-disks, or libgdu? (the latter should be much nicer)
[11:39]  * Riddell just tests netbook images from DVDs currently
[11:39] <evand> pitti: dbus to devicekit
[11:40] <pitti> evand: devicekit-disks, I assume
[11:40] <evand> err devicekit-disks
[11:40] <pitti> ok
[11:40] <evand> yes
[11:40] <seb128> evand, ok, I will rank it low on my list, I would prefer to focus on things which will not get done otherwise ;-)
[11:40] <evand> seb128: sure thing :)
[11:40] <pitti> Riddell: ok, I'm fine with changing the text to "DVD", if that's fine with you for alpha-3?
[11:40] <ogra> pitti, does devicekit-power still have APM support or did it completely switch to ACPI only ?
[11:40] <seb128> evand, in fact I did the gtkbuilder conversion locally but you have a very weird hack which I blocked on
[11:40] <evand> oh?
[11:41] <seb128> evand, some
[11:41] <seb128>         for widget in self.builder.get_objects():
[11:41] <seb128>             if isinstance(widget, gtk.Label):
[11:41] <seb128>                 widget.set_property('can-focus', False)
[11:41] <seb128> evand, that's the non working gtkbuilder version
[11:41] <evand> ahh, that can probably go away
[11:41] <Riddell> pitti: have the UNR guys expressed an opinion?
[11:41] <pitti> ogra: well, neither really; it just uses /sysfs
[11:41] <evand> it was there to address a bug in ubiquity, if memory serves
[11:42] <evand> and it somehow got copied over
[11:42] <pitti> Riddell: I pinged them above, but no response yet; I changed it to usb-creator for now
[11:42] <seb128> evand, well it seems it's to make text not being selected when using tab
[11:42] <ogra> pitti, oh, i thought it inly looked in the acpi subpaths
[11:42] <seb128> evand, but if gtk does it that's for a reason, ie no need to try to change it by weird hacks in your software, better to be consistent with other applications
[11:42] <pitti> ogra: sysfs_get_string (native_path, "status") for battery status, etc.
[11:43] <evand> seb128: indeed
[11:43] <pitti> ogra: and pm-utils for the suspend/resume stuff
[11:43] <evand> I'll tear it out in trunk
[11:43] <pitti> (which also uses sysfs)
[11:43] <ogra> ah, ok so it doesnt restrict itself to /sys/bus/acpi/
[11:43] <ogra> (i'll likely need to look into APM support for armel)
[11:44] <pitti> i. e. whatever is behind (APM/ACPI) should export proper sysfs attributes, then it should just work
[11:44] <mat_t> Keybuk: hi
[11:44] <ogra> yep
[11:44] <ogra> so its a kernel thing then, thanks
[11:44] <Keybuk> mat_t: hi
[11:44] <mat_t> Keybuk: is there a maximum number of legacy OSs that can be installed at the time?
[11:44] <ogra> (or udev FWIW)
[11:44] <pitti> ogra: udev can't change /sys
[11:45] <ogra> ok
[11:45] <mat_t> Keybuk: I'm asking primarily in the context of the OS switcher
[11:49] <Keybuk> mat_t: is there a maximum length to a piece of string?
[11:49] <lool> pitti: Looks good
[11:50] <lool> pitti: "Choose this if you are at all unsure." in the only UNR image is a bit too much
[11:50] <Keybuk> mat_t: any limit I tell you today will almost certainly be wrong in a year's time ;-)
[11:50] <mat_t> Keybuk: I see
[11:50] <pitti> lool: heh, ok
[11:50] <Keybuk> mat_t: so design and code for no limit
[11:50] <lool> Otherwise ok
[11:50] <pitti> lool: removed
[11:50] <lool> (I wonder where the up to 10" comes from though)
[11:51] <mat_t> Keybuk: perfect, thanks :)
[11:51] <lool> I've seen people run UNR on regular laptops :)
[11:53] <StevenK> lool: It's probably hysterical raisins now
[11:54] <sebner> pitti: seems there is now also a workaround for me :) (regarding the external harddrive problem - you are debugging it with someone else again)
[11:55] <pitti> sebner: bug 387161? what is it?
[11:56] <sebner> pitti: yep, just discovered that my bug was marked as duplicated of this bug, /me is going to uninstall devicekit-disks later to see if this also fixes the issue for me
[11:57] <pitti> it's just a short-term workaround, though
[11:59] <sebner> pitti: of course but better than nothing. /me is just wondering why this is working because I thought devicekit-disks is *needed* to deal with hardware
[12:03] <pitti> sebner: right, gnome is using it now
[12:04] <sebner> pitti: why is a external drive then working when it is needed for hardware and gnome using it? ^^
[12:05] <pitti> sebner: that's a miracle
[12:06] <sebner> lol
[12:07] <sebner> pitti: the magic of open source? *cough*   might it have any negative effects if I remove it, besides that it might fix my external harddrive?
[12:07] <pitti> sebner: did you reboot after removal? or sudo killall devkit-disks-daemon?
[12:07] <pitti> gvfs doesn't build the hal monitor any more
[12:07] <sebner> pitti: didn't remove it yet
[12:07] <pitti> so it shouldn't be able to detect usb sticks and the like any more
[12:07] <pitti> oh
[12:11] <sebner> pitti: so downgrading gfvs as well?
[12:12] <pitti> sebner: you probably need to
[12:12] <sebner> pitti: argh, removing devicekit-disks will remove half of my system
[12:12] <pitti> sebner: well, you can't remove dk-disks without removing gvfs, it's a dependency
[12:12] <pitti> and GNOME depends on gvfs
[12:12] <pitti> anyway, food time
[12:12] <sebner> pitti: it seemed possible though ?!
[12:12] <sebner> hf
[12:21] <tseliot> pitti: my program requires root privileges. Can it still be used by an apport hook?
[13:28] <maxb> The postgresql-common upload to karmic today - why is that 100.1 instead of 100ubuntu1 ?
[13:29] <mok0> maxb, probably a nmu
[13:29] <maxb> mok0: I don't understand
[13:30] <maxb> It was a direct upload to Ubuntu, not a sync
[13:31] <mok0> maxb: merged nmu?
[13:32] <maxb> A merge would normally still have "ubuntu" in its version string
[13:32] <geser> maxb: probably a glitch from pitti as he's also the debian maintainer for it
[13:32] <mok0> maxb, it's an nmu synced from debian afacs
[13:33] <maxb> mok0: The changesfile lists the distribution as karmic, so I prefer geser's explanation
[13:34] <maxb> Also, "100.1" isn't a nmu version string
[13:34] <mok0> maxb. yeah
[13:34] <mok0> maxb: 100 is latest debian release
[13:35] <maxb> yup. A nmu would be labelled as 100+nmu1
[13:36] <mok0> maxb, I assumed you were quoting a version string before checking
[13:36] <maxb> I was quoting a version string?
[13:36] <mok0> maxb: no :-)
[13:37] <maxb> Sorry, I mean: I *was* quoting a version string, are you suggesting I wasn't?
[13:37] <mok0> maxb I thought you were quoting the release part of the version string
[13:38] <maxb> aha :-)
[13:38] <mok0> maxb, I was wondering about the huge number
[13:38] <maxb> mm, 100 debian revisions for a single upstream would be impressive
[13:39] <maxb> though sysvinit is more than half way there
[13:40] <geser> cron is at -106 already
[13:41] <mok0> implies very low upstream activity
[13:42] <mok0> the postgresql-common problem is discussed  in bug 403381
[13:43] <mok0> looks like it could be a temporary fix
[13:43] <mok0> and that pitti wants it to go away automatically at next sync
[13:43] <geser> very low activity indeed: -35 was uploaded in Dec 1996 (the Debian changelog doesn't reach further back)
[13:44] <mok0> geser: cron is a legacy package now, right?
[13:44] <hyperair> it is? why would it be?
[13:45] <mok0> Because anacron is being installed by default
[13:45] <mok0> And aren't there discussions about moving to Apple's launchd ?
[13:46] <hyperair> don't they do separate things?
[13:46] <mok0> hyperair: afaik launchd is a reimplementation of cron
[13:47] <hyperair> is it?
[13:47] <hyperair> hmm
[13:47] <hyperair> (i was referring to anacron vs cron)
[13:47] <mok0> but with better security and flexibility
[13:47] <ion> launchd is more than crond.
[13:47] <mok0> hyperair: ah
[13:47] <hyperair> what's wrong with crond?
[13:47] <hyperair> and we don't have a launchd package around, do we?
[13:48] <mok0> hyperair: I imagine it has something to do with the /etc/cron.d/ directories
[13:48] <hyperair> hmm
[13:48] <hyperair> oh yeah, that.
[13:48] <mok0> hyperair: so packages can drop files in there
[13:48] <hyperair> so how would you secure something of that sort?
[13:48] <hyperair> without losing the said functionality
[13:49]  * mok0 googles crond vs launchd
[13:49] <pitti> tseliot: no, I'm afraid not
[13:49] <ion> Upstart will implement the cron/at/anacron/whatever functionality in the future. Upstart’s design is better than launchd’s IMO.
[13:49] <pitti> geser:, maxb, mok0: it was a bzr head snapshot
[13:50] <pitti> no reason to upload to debian for just that
[13:50] <pitti> and the next time it will autosync, right
[13:50] <tseliot> pitti: ok, thanks
[13:50] <mok0> http://arstechnica.com/apple/reviews/2005/04/macosx-10-4.ars/5
[13:51] <ogra> mvo, mind to take a look at http://paste.ubuntu.com/227208/ ?
[13:52] <ion> mok0, hyperair: http://www.netsplit.com/2006/08/26/upstart-in-universe/ heading “How does it differ from launchd?”
[13:54] <glatzor> mvo,  You can take a look at the new code: lp:~aptdaemon-developers/aptdaemon/gdefer
[13:54] <glatzor> mvo, I've only converted the GetTrustedVendorKeys method to the new gobject based deferreds
[13:55] <glatzor> mvo, yet. I am away now for some days! See you.
[13:55] <mok0> ion, ah, so it's upstart rather than launchd
[13:56] <ttx> doko: about doublechecking if a MIR is really needed: I was thinking on reviewing package bug history, is there any better way, like some official list of MIR-ed packages ?
[13:56] <ion> http://upstart.ubuntu.com/faq.html#replace-cron
[13:58] <mok0> ion, oh crond (launchd) capability is _planned_ but not currently in upstart
[13:58] <doko> ttx: I would just look at Sources from jaunty if the package was in main
[13:59] <ion> crond is still not equal to launchd.
[13:59] <ion> In some areas, Upstart is far beyond launchd in functionality.
[13:59] <ttx> doko: ok, thx
[14:00] <mok0> ion, apple uses launchd to replace crond
[14:00] <ion> Yes
[14:01] <ion> As well as inetd and initd.
[14:01] <mok0> ion, didn't know that
[14:01] <mok0> ion, although I am typing this from my Powerbook G4 :-)
[14:07] <hyperair> hmm the article said that upstart was to have reached stage #6 by edgy+2, which was gutsy.
[14:07] <hyperair> that's so long ago, and we're not even there yet! =O
[14:07] <mok0> From upstart webpage "Events may be received from any other process on the system" -- I hope there's a decent authorization system in place
[14:10] <hyperair> what kind of events do you want to limit access to?
[14:12] <ion> The usual. If you have write access to init’s UNIX socket or the system bus, you can talk to init.
[14:13] <ion> /etc/dbus-1/system.d/Upstart.conf
[14:14] <mok0> If a single process controls almost everything, it also gives blackhats more options for making trouble
[14:15] <mok0> Just sayin'
[14:15]  * ogra wonders if mok0 is aware of the PID init had since it existed
[14:15] <hyperair> i wouldn't say that.
[14:16] <hyperair> i think it's more of giving blackhats something to focus on attacking.
[14:16] <hyperair> rather than giving them more options
[14:16] <mok0> ok
[14:16] <ion> Instead of D-Bus handling the access policy, so you have a single chunk of code to audit, every piece of software should NIH its own, so you have to audit all of them?
[14:16] <mvo> ogra: looks good, just commit
[14:16] <ogra> mvo, thanks :) not hard to understand the code :)
[14:18] <mok0> ion, good point
[14:19] <mok0> ion, but the fundamental design better be right
[14:19] <ion> Feel free to inspect the fundamental design.
[14:19] <hyperair> NIH = ?
[14:19] <mok0> ion, I'm not qualified for that
[14:20] <ogra> hyperair, Not Invented Here
[14:20] <Chipzz> ion: I think the fundamental design is broken
[14:20] <Chipzz> but that's just my opinion
[14:20] <hyperair> ah.
[14:20] <hyperair> broken how?
[14:21] <mok0> ion, just slightly concerned when several very well tested systems get replaced by a single piece of software
[14:21] <mok0> ion, NEW software
[14:21] <Chipzz> one central daemon that is needed and when breaks, would call huge amounts of havoc
[14:21] <mok0> Chipzz: exactly
[14:21] <hyperair> that's the entire purpose of init isn't it?
[14:22] <hyperair> if init breaks, you get huge amounts of havoc
[14:22] <mok0> hyperair: yes, but will it work?
[14:22] <Chipzz> hyperair: and the dbus developers have, IIRC, always had a "Distro's go fuck yourself, dbus isn't designed to be restarted" attitude
[14:22] <Chipzz> hyperair: init is a LOT less complex than dbus
[14:22] <mok0> hyperair: init has been tested on? hundreds of mililons of systems?
[14:22] <Chipzz> and now you need dbus and god knows what just to log in
[14:22] <hyperair> mok0: upstart has been ubuntu's init for some time already.
[14:23] <ion> Upstart runs just fine without D-Bus. Even handles D-Bus restarts. Also, Upstart has been running on – how many Ubuntu users are there again? – for many releases by now. Oh, and i bet Upstart has a more comprehensive test suite than sysvinit. :-P
[14:23] <Chipzz> sounds like looking for things to break
[14:23] <Chipzz> ion: I'm not criticizing upstart
[14:23] <mok0> neither am I
[14:23] <Chipzz> my critique is wrt dbus and the whole santa-boutique of *kits
[14:24] <hyperair> upstart isn't about to engulf dbus.
[14:24] <hyperair> i don't see the point of comparing upstart with dbug
[14:24] <hyperair> dbus*
[14:24] <ion> I’m not saying D-Bus doesn’t suck. I’m still quite confident D-Bus won’t let $randomuser get root access from Upstart, which seemed to be the original doubt.
[14:24] <mok0> hyperair: ok
[14:24] <Chipzz> I think yesterdays breakage cjwatsons, and who elses? don't recall desktop proved my point very nicely
[14:25] <hyperair> what breakage?
[14:25] <Chipzz> part of ecrypt breaks, and sudo/login get broken
[14:25] <Chipzz> bad
[14:25] <Chipzz> BAD
[14:25] <Chipzz> BAD DESIGN
[14:25] <hyperair> sudo got broken?
[14:25] <hyperair> and i have no interest in ecrypt, so i don't really bother with that
[14:25] <Chipzz> which is why I don't like the whole idea of dbus and the whole bunch of *kits
[14:26] <hyperair> i'm more interested to know what went wrong that caused sudo to break.
[14:26] <Chipzz> read the backlog or ask someone who can give more detail
[14:26] <hyperair> and break in what way
[14:26] <Chipzz> segfault
[14:26] <hyperair> O_o
[14:26] <Chipzz> no logins possible, sudo segfaults
[14:26] <hyperair> i had nothing of that sort.
[14:27] <hyperair> at least, my sudo never segfaulted, and i didn't log out for a very long time
[14:27]  * ogra wouldnt call that an encfs design flaw
[14:27] <ogra> rather a pam one
[14:27] <hyperair> oh it's pam eh.
[14:28] <hyperair> that reminds me. someone was complaining about kdesu breaking in #ubuntu-kernel, claiming it to be the fault of the kernel.
[14:28] <pitti> hyperair: well, a major point of ecryptfs is to hook into the login process, i. e. PAM
[14:28] <ogra> but if you can confuse the login process with a broken third party hook thats a flaw in the login system imho
[14:29] <Chipzz> pitti: reading the backlog pam wasn't involved in that?
[14:29] <pitti> Chipzz: sure, ecryptfs ships a pam module which segfaulted
[14:29]  * hyperair uses cryptsetup-on-lvm
[14:29] <pitti> it wasn't the pam package itself, of course
[14:29] <Chipzz> pitti: then I misunderstood the whole debacle
[14:58] <ttx> pitti: congrats !
[14:58] <pitti> thanks to all involved!
[15:01]  * ogra applauds
[15:03] <DktrKranz> pitti: now that Alpha 3 is out, mind giving a look at bug 401953 when you have some time?
[15:05] <pitti> DktrKranz: oh, that makes a lot of sense
[15:05] <pitti> dpkg apport | grep -- -packages
[15:07] <sebner> pitti: workaround is working now (after downgrading gvfs and uninstalling gvfs), I have mount the harddrive/usb-stick manuall and the sticks are only usable as root but at least it's working :D
[15:07] <pitti> ah
[15:07] <sebner> pitti: uninstalling devicekit-disks of course, sry
[15:08] <pitti> I figured :)
[15:09] <sebner> pitti: I'm curious how long this workaround will be working though
[15:10] <sebner> pitti: or even more when devicekit-disks is fixed :P
[15:11] <Laney> what is the problem?
[15:11] <sebner> Laney: external harddrive not usable. Downgrading gvfs and uninstalling devicekit-disks is the only workaround so far
[15:12] <Laney> interesting
[15:14] <sebner> Laney: annoying might be a better word :P
[15:16] <pitti> sebner: hm, for me it takes some 30 seconds until nautilus can open them, but otherwise they seem to work
[15:16] <pitti> it almost feels like the old gutsy bug where we had to set a special mount option to speed up vfat dir reading from 5 minutes to 2 seconds ("usefree" option)
[15:17] <sebner> pitti: I have to mount them manually so dunno
[15:17] <ion> I wan’t (wannot) getdeb.net indeed.
[15:18] <sebner> pitti: waha! just discovered that they are automounted now (reboot after uninstalling devicekit-disks)
[15:18] <pitti> sebner: sure, by hal
[15:18] <sebner> hal \o/
[15:18] <pitti> or, by gvfs/nautilus through hal
[15:19] <sebner> pitti: /media contains now usb (symlink) and usb0 - usb7 though. dunno why
[15:21] <pitti> sebner: just added some more requests for debug output to bug 387161; perhaps you can do that on a karmic live CD?
[15:22] <ogra> pitti, you mean its not because i'm remotely logged in to his desktop and mounted it ? :)
[15:22] <pitti> ogra: sorry, context?
 or, by gvfs/nautilus through hal
[15:23] <ogra> sorry, bad joke
[15:23] <pitti> ah
[15:23] <sebner> pitti: nah, posting instructions *before* I downgraded :P heh, but of course when I have time I'll try it with a karmic live cd
[15:24] <pitti> sebner: just downgrading gvfs shold be enough, you could leave dk-disks instlaled even
[15:24] <pitti> sebner: and try devkit-disks --mount /dev/sd...
[15:24] <pitti> gvfs/gnome will still use hal
[15:25] <sebner> sounds reasonable
[15:26] <dupondje> gvfs & samba also broken :(
[15:31] <pitti> DktrKranz: hm, after building apport with that patched cdbs, the apport package still has empty ./usr/lib/python2.6/dist-packages/ and ./usr/lib/python2.5/site-packages/ dirs..
[15:32] <pitti> aah, ?.?
[15:50] <cjwatson> apw: just in case any of you guys were thinking about it, please don't turn on CONFIG_X86_PAT :-)
[15:50] <cjwatson> apw: joeyh and I just spent several hours debugging why Debian's d-i wouldn't boot in qemu and Ubuntu's would, and it turned out to be because Debian had enabled CONFIG_X86_PAT
[15:52] <apw> cjwatson, heh thanks for the warning ... on my scarey list
[15:54] <DktrKranz> pitti: yeah, it creates /usr/lib/python?.?/site-packages
[15:54] <ogra> cjwatson, but its more modern than MTRR :P
[16:16] <superm1> pitti, once livecd-rootfs updates on the build machine, will doing the new mythbuntu iso with the updated livecd-rootfs need a manual prod, or is the cron still activated?
[16:22] <Riddell> 19 6 * * *      buildlive mythbuntu; for-project mythbuntu cron.daily-live
[16:23] <Riddell> superm1: so if you wait until 6 tomorrow morning it'll get made
[16:23] <Riddell> or you can just ask me
[16:24] <superm1> Riddell, well if livecd-rootfs updates on the build machine sooner than that, doing it sooner would be better so that we can get testing and mirroring done sooner
[16:25] <superm1> StevenK said it updated at 1:15am DC time
[16:27] <Riddell> superm1: do you want me to do anything?
[16:28] <superm1> Riddell, if you can update livecd-rootfs sooner and kick off a build, that would be good. if you can't update it, then after it updates, kicking a build then would be good
[16:29] <Riddell> after what updates?
[16:29] <superm1> i uploaded a newer livecd-rootfs that is needed to fix bug 403289
[16:29] <superm1> StevenK said that the process to update on the build machine is automatic, but it only happens once a day normally
[16:31] <Riddell> oh hmm, maybe
[16:32] <Riddell> superm1: sounds like a job for a sysadmin, try asking in #canonical-sysadmin ?
[16:32] <superm1> Riddell, okay.  will do
[16:33] <birthdaylogger> james_w: hey, can the gtk-module.so be moved out of the packagekit main package? kpackagekit deps packagkit and packagekit (due to the gtk-module) deps gtk, so gtk ends up in a Kubuntu installation while it should indeed not
[16:41] <rickspencer3> in terms of pythonic design ... is it proper to have a property that gets a different value than it sets
[16:42] <rickspencer3> in this case,  list_of_dicts = couchwidget.selected_rows
[16:42] <rickspencer3> but
[16:42] <rickspencer3> couchwidget.selected_rows = list_if_ints
[16:42] <rickspencer3> ?
[16:42] <rickspencer3> pitti: lool: ^ thoughts?
[16:43] <rickspencer3> oops, I said "value", but meant "type"
[16:51] <lool> rickspencer3: Hmm I think I'd need more context but that's probably ok as long as it's clear from the comments/inline doc
[16:53] <rickspencer3> perhaps selected_rows should be read only ... and select_rows(list_of_ints) would go with it?
[16:55] <dvestal> rickspencer3: The logic of doing that makes sense, but I would probably lean more toward using an "indexes" property to set the selection with a list of indexes. that way you have list_of_dicts = couchwidget.selected_rows and couchwidget.selected_row_indexes = list_of_ints. otherwise something like you just mentioned regarding the read-only property and a setter method.
[16:56] <rickspencer3> dvestal: hmm
[16:56] <dvestal> although, doing it with the indexes property would actually require a setter method anyway to be able to modify the other property.
[16:56] <rickspencer3> in fact, perhaps couchwidget.selected_indexes could be a read/write property?
[16:57] <dvestal> the read-only property and a setter method may be the best way to do it.
[16:57]  * rickspencer3 nods
[16:58] <rickspencer3> or perhaps the whole list_of_ints for indexes is too implementation specific
[16:58] <rickspencer3> the developer should rather provide a list of records to select ... the fact that they are displayed in a treeview with a listmodel shouldn't be exposed in the widget api?
[17:03] <dvestal> rickspencer3: i don't know that a list of indexes is too specific for a list of items, but that's more dependant on how it's being used. i come from more of a web application background; so i tend to lean toward an index + lightweight textual value for lists and that may not be the most appropriate in all circumstances.
[17:27] <kirkland> bryce: hi
[17:28] <kirkland> bryce: what should and shouldn't work, as i insert and remove my thinkpad x200 to/from the docking station with an external monitor
[17:28] <kirkland> (intel video, karmic)
[17:28]  * kirkland misses ctrl-alt-backspace for the first time in a while
[17:45] <maco> hey guys, im trying to do the thing with bzr & debian/changelog & debcommit and then pushing to lp and merge request...what do i put for the release in debian/changelog? "UNRELEASED" or -proposed?
[17:48] <tjaalton> kirkland: c-a-b should work just fine in your session, if you just enable it from the kbd capplet
[18:12] <ogra> jdstrand, why doesnt gufw have a simple "internet connection sharing" checkbox anywhere ? it already makes firewalling a breeze, but NAT seems to be missing
[18:12]  * kirkland is less productive when his sound is broken
[18:13]  * ogra sings a bit for kirkland 
[18:13] <kirkland> :-)
[18:13]  * kirkland hugs ogra 
[18:13] <ogra> :)
[18:14] <kirkland> anyone else having sound issues?
[18:14] <ogra> worked this morning when i watched the news in flashplayer
[18:15] <ogra> RB works
[18:15] <kirkland> ogra: yeah, that's funny, flash sound is working, but rhythmbox, xmms are not
[18:16] <ogra> just fired up RB
[18:16] <ogra> plays fine
[18:16] <ogra> kirkland, did you check the sound profile ?
[18:16] <ogra> probably these apps are muted
[18:16] <ogra> (we have per app settings now)
[18:17] <kirkland> ogra: where is this magik?
[18:17] <kirkland> sound preferences -> output ?
[18:17] <kirkland> i only have stereo audio
[18:17] <ogra> right click the new volume control
[18:17] <kirkland> right
[18:17] <kirkland> applications
[18:17] <kirkland> "No application is currently playing or recording audio"
[18:17] <ogra> last tab, "applications"
[18:17] <kirkland> which is wrong
[18:17] <ogra> oh
[18:17] <kirkland> firefox/pandora is playing music
[18:18] <ogra> i have firefox-3.5 and RB ... both with volume controls
[18:18]  * kirkland frowns
[18:18] <ogra> probably ask TheMuso
[18:19] <ogra> though its a very bad time for him
[18:23] <kirkland> ogra: okay, thanks
[18:24] <jdstrand> ogra: re gufw> a) I don't develop gufw and b) ufw doesn't support NAT via the cli command yet
[18:25] <ogra> oh, i thought it did
[18:25] <ogra> well, it would be a cool feature to have
[18:25] <jdstrand> ogra: it is planned, but only after all the host-based stuff is there
[18:25] <ogra> ok
[18:26] <ogra> its just something i have to deal often with in #ltsp ... so i was wondering
[18:26] <jdstrand> ogra: specifically filtering by interface (which will be in 0.28) and egress filtering (which will be sometime after that)
[18:26] <ogra> sweet
[18:27] <jdstrand> ogra: there is an example of doing NAT in /usr/share/doc/ufw/README.gz under 'Advanced Configuration', and I'm pretty sure help.ubuntu.com also has a recipe
[18:28] <jdstrand> ogra: ufw can do it (it can do anything iptables-restore can do), it just isn't exposed via the cli command yet
[18:28] <jdstrand> ogra: and therefore gufw doesn't support it yet
[18:29] <ogra> right, but after all users currently seem more comfortable with iptables-save and editing /e/n/i
[18:31] <jdstrand> ogra: whatever someone wants to use to get their work done is fine be me. :) the point I was trying to make is that if you want to use ufw generally, but just want a NAT rule, then you can do that
[18:32] <ogra> well, i would prefer to tell users to do "ufw enable nat" "ufw save" :)
[18:32] <ogra> or something along that
[18:32] <jdstrand> ogra: ack, but not this cycle :)
[18:33] <ogra> understood :)
[18:57] <mathiaz> does anyone has an example of a python package that uses cdbs+distutils?
[18:57] <mathiaz> *have*
[18:57] <pitti> mathiaz: apport, jockey
[18:57] <mathiaz> pitti: thank you :)
[19:02] <mathiaz> pitti: IIUC lp:apport/ is the upstream branch, while lp:~lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu is the packaging branch?
[19:03] <pitti> right
[19:15] <pitti> mbiebl: hm, CK 0.3.1 released, also with PK 1.0; seems we can't hold it back much longer in Debian ..
[19:16] <pitti> just uploaded to ubuntu, but can't commit it to pkg-utopia yet (no polkit-1)
[19:29] <maco> is it normal for changes to exist in -security that dont exist in -proposed
[19:30] <pitti> maco: rare, but happens
[19:30] <pitti> maco: if a package in -proposed doesn't get verified for a while, and a security update comes in between and "shadows" it
[19:30] <kees> maco: if by "changes" you mean non-security-changes, it's like pitti says.
[19:30] <kees> maco: what are you specifically examining?
[19:31] <maco> i just made a change to sudo for hardy-proposed and did a merge request for ubuntu/hardy/sudo/hardy-proposed and found that the diff between what i put and what's in hardy-proposed right now includes your last change in -security, kees
[19:32] <kees> maco: ah, then, yes, -security skips -proposed.  only very rarely will a security update go through -proposed.
[19:32] <maco> oh ok
[19:32] <kees> you need to always base uploads to -proposed on the most recent version in either -updates or -security.
[19:33] <maco> i did it against hardy-updates. its the same as hardy-security though
[19:34] <kees> maco: right, so a diff between the old -proposed version and the new -proposed version will contain the changes between old -proposed and -updates/-security and your new changes.
[19:35] <maco> ok
[19:35] <maco> just didnt expect that
[20:02] <CardinalFang> Hi all.  I have a packaging question.  I have package "foo".  I want to split it into "foo" and "foo-ui".  I want upgraders to get "foo-ui" (which depends on "foo"), but I don't want to require "foo-ui" to be installed for new users or after the upgrade.  What package relationships should I use?
[20:10] <geser> CardinalFang: that seems not to be possible. what might work is renaming "foo" to "foo-backend" (or whatever) and introducing a transitional package "foo" which depends on "foo-ui".
[20:14] <sebner> geser: sebner bot is now a sponsoring bot, already ACKed ~15 sync requests \o/
[20:18] <geser> \o/
[20:19] <geser> sebner: now you also need a sponsoring module for merges :)
[20:20] <sebner> geser: I'll leave soon so I just want to finish until I have 20 ACKs. merges are my victims for tomorrow \o/
[20:20] <kirkland> can someone point me to a step-by-step guide for i18n-ing a package?
[20:20] <geser> does something magical happen at 20 ACKs?
[20:21] <kirkland> i know there's a bunch of gettext calls to add to the shell, python and C
[20:21] <kirkland> there's some po work
[20:21] <kirkland> a fair amount of build and packaging
[20:21] <sebner> geser: well, 20 sounds so much nicer and cleaner than 17 does ;)
[20:21] <kirkland> as well as launchpad setup, etc.
[20:21] <kirkland> i'm hoping someone has written up a best practices guide on making this happen
[20:24] <dpm> kirkland: there's http://live.gnome.org/TranslationProject/DevGuidelines and http://developer.gnome.org/projects/gtp/l10n-guide/, although the latter is really outdated. I'd like to write such a guide for Ubuntu, but this hasn't happened yet.
[20:24] <kirkland> dpm: thanks for the pointers
[20:24] <kirkland> dpm: i'm going to email the list asking for such things; perhaps you can respond there?
[20:26] <dpm> kirkland: sure. We've also already started this with dholbach here -> https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation, but it is really crude at the moment, that's why we haven't announced it yet
[20:27] <kirkland> dpm: i'm happy to be a guinea pig in your development of that documentation
[20:28] <dpm> kirkland: ;) just feel free to ping me or ask anything as well, maybe this will be a good way to see which are the most important sections to cover there
[20:36] <wizztjh> hi , i am a python programmer , how can i help to develop ubuntu?
[20:47] <jjohansen> wizztjh: look around find a project that interests you and start fixing bugs/adding features
[20:47] <jjohansen> wizztjh: the best way really is just finding something interesting and jumping in
[20:48] <wizztjh> i now browsing MOTU , where can i join the project
[20:49] <jjohansen> which project?
[20:50] <jjohansen> if you mean MOTU https://wiki.ubuntu.com/MOTU/GettingStarted
[21:39] <bryce> anyone know if there is a test bugzilla up running anywhere?  I'm doing a script to upstream bugs from lp but don't want to irritate freedesktop.org with a bunch of test posts