[00:21] <slangasek> lamont: in bug #268996, there's a pointer to an update to take nmap up to 4.76 for Debian (http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=nmap) - are there concrete reasons for not updating nmap in Debian right now?
[00:37] <slangasek> cjwatson, mdz, pitti: seed archaeology says that powernowd has been part of the desktop seed since its creation; should this be revisited given the ondemand governor is the one we use by default (and, according to what mjg59 writes, it should stay that way)?
[00:41] <slangasek> ah, apparently the Ubuntu version of the package tries to avoid using powernowd at all costs ;)
[03:50] <StevenK> Argh, libdrm is still broken
[06:19] <dholbach> good morning
[07:26] <lamont> slangasek: (re: nmap) mostly just the usual testing vs sid madness and waiting for it to settle a bit more - I'll be uploading nmap this weekend
[07:26] <lamont> to debian, and requesting the sync
[08:19] <pitti> slangasek: ah, I remember that it was 'userspace' in the past?
[08:19] <pitti> slangasek: yes, if it's not needed, I'm all for throwing it out
[08:19] <pitti> Good morning
[08:21] <Hobbsee> morning pitti!
[08:21] <StevenK> Morning pitti
[08:21] <StevenK> pitti: So, I NEWed libdrm-intel1, and it's busticated.
[08:21] <tjaalton> StevenK: should work now
[08:21] <StevenK> tjaalton: Oh, you added Replaces?
[08:22] <tjaalton> crap, it needs that now?
[08:22] <StevenK> Look at what the .deb contains
[08:22] <StevenK> libdrm2 probably contains both .so's
[08:22] <tjaalton> the old one did, yes
[08:23] <StevenK> Right
[08:24] <StevenK> tjaalton: Did you test upgrades, as well as installability?
[08:24] <tjaalton> StevenK: take a wild guess
[08:26] <StevenK> tjaalton: I'm only asking
[08:26] <tjaalton> StevenK: ok :) no, I don't have jaunty yet
[08:26] <Hobbsee> chroots?
[08:26] <tjaalton> suck
[08:26]  * tjaalton runs
[08:26]  * Hobbsee attacks tjaalton with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ for attempting to upload crack.
[08:27] <StevenK> tjaalton: -0ubuntu3 didn't upgrade, which is why I asked.
[08:27] <tjaalton> Hobbsee: ouch!
[08:27] <Hobbsee> tjaalton: apart from that, there are even pbuilder hooks that deal with this.
[08:27] <tjaalton> StevenK: ok, but I put -0ubuntu5 there just to be safe
[08:27] <Hobbsee> tjaalton: so if you test built with pbuilder, you wouldn't have even had to set up a test chroot.
[08:28] <tjaalton> Hobbsee: you mean test the installability? sounds nice
[08:28] <Hobbsee> tjaalton: yeah.  I sent a mail out a while ago about it.  I'll find it again.
[08:28] <tjaalton> maybe I'm just too lazy and will upgrade to jaunty to be safe..
[08:29] <tjaalton> because the following changes might actually break something
[08:29] <Hobbsee> tjaalton: https://lists.ubuntu.com/archives/ubuntu-devel/2008-September/026607.html
[08:29] <StevenK> I wouldn't upgrade yet, since you broke X :-P
[08:29] <tjaalton> StevenK: oh? did this really do that much harm?
[08:29] <tjaalton> Hobbsee: thanks
[08:29] <Hobbsee> tjaalton: you're welcome
[08:30] <StevenK> tjaalton: Yes
[08:30] <StevenK> tjaalton: The new X didn't build because of it
[08:30] <tjaalton> StevenK: ah, but the installed one still runs right?-)
[08:30] <tjaalton> Hobbsee: bookmarked
[08:31] <StevenK> tjaalton: Actually, some drivers seem to want the new X, so it doesn't even install
[08:31]  * Hobbsee ponders resending the last part of the mail out, with a subject of "please actually read this.  This will help you" and see if more people read it.
[08:32] <tjaalton> StevenK: ok, that's weird.. I'll see what's wrong with that
[09:23] <directhex> hm. do i need a MIR to add a package to main which is already being built by a source package in main (but the binary itself currently goes to universe)?
[09:23] <Mithrandir> directhex: no.
[09:23] <directhex> Mithrandir, any formal process, or will it be auto-promoted?
[09:24] <tjaalton> Hobbsee: nice, B91dpkg-i hook works fine
[09:24] <Mithrandir> directhex: tends to be pulled in automagically, or you can just poke an archive admin
[09:24] <tkamppeter> pitti, bug 292690 got confirmed, you can move the SpliX package to the updates.
[09:24] <pitti> tkamppeter: 7 day maturing period isn't done yet
[09:24] <Hobbsee> tjaalton: excellent!
[09:25] <amitk> has 2.6.28-1.1 been NEW'ed?
[09:25] <pitti> amitk: you see the version on https://edge.launchpad.net/ubuntu/+source/linux, thus the source is in jaunty
[09:26] <pitti> amitk: if you click on the version, you get to https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-1.1
[09:26] <tkamppeter> pitti, should I put the tag back to verification-needed then?
[09:26] <pitti> amitk: this shows the failed builds, and the completed ones, which are NEW
[09:26] <pitti> tkamppeter: no, that's fine; it fixes the bug
[09:27] <amitk> pitti: aaah. Didn't know that "NEW" status was shown there too. Thanks.
[09:27]  * pitti processes it
[09:29] <tjaalton> is it just me or are the builders really quick nowadays?-)
[09:29] <ogra> tjaalton, well, after X was broken they ran out of packages to build :P
[09:29] <tjaalton> ogra: so that's why.. makes sense now :)
[09:30] <ogra> heh
[09:31]  * pitti arghs at the kernel-overrides script
[09:32] <directhex> ogra, yeah, but i sent calc an OOo patch he needs to apply, and that should keep the builders toasty for a good few hours
[09:33] <ogra> directhex, no trace of oo.o yet on https://launchpad.net/+builds though
[09:34] <directhex> well, it'll FTBFS without patching, so don't look at me :)
[09:34] <ogra> heh
[09:36] <lool> tjaalton: xorg-server was given back against the new libdrm which is now installable
[09:36] <tjaalton> lool: but not yet in the archive, so does it build?
[09:37] <lool> tjaalton: at least it installs
[09:37] <tjaalton> lool: ok, maybe 0ubuntu5 does install in the chroot, 0u6 only added the Replaces
[09:39] <ogra> the Replaces is only important for upgrades ... the buildds pull it freshly for building
[09:39] <tjaalton> right
[09:39] <lool> I guess the ones without xen could have it, but these packages are usually removed after a build
[09:50] <directhex> woo, another merge bug filed for the mono 2.0 transition
[09:53] <ogra> directhex, well, its still totally broken on hppa
[09:53] <ogra> :P
[09:53] <directhex> ogra, mono or OOo?
[09:54] <ogra> mono
[09:54] <ogra> err
[09:54] <ogra> both actually :)
[09:55] <directhex> ogra, there's some code in the source for hppa... but we ain't even trying to make packages from it
[09:55] <directhex> ogra, you volunteering? :p
[09:55] <ogra> not really :)
[09:56] <ogra> i'm rying to get armel in shape .... there OO.o built and runs fine :)
[09:57] <directhex> ogra, mono built & ran fine on armel, in 2.0.1-0ubuntu2
[09:57] <directhex> ogra, and 2.0.1-1 if anyone feels like syncing it (not really required, only one bugfix change)
[09:57] <ogra> apart from winforms mono seems good on arm
[09:58] <pitti> directhex: want me to?
[09:58] <directhex> pitti, honestly? i wouldn't bother until i see something worth syncing for from pkg-mono svn. it'd really just be making the buildds churn out CO2
[09:58] <pitti> directhex: that was my question :)
[09:58] <pitti> ok
[09:59] <directhex> pitti, i could do with my monodoc merge going in though :)
[09:59] <directhex> LP #302745
[09:59] <directhex> debian is pulling ahead on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO, so gotta get some mergesyncs done asap! ;)
[10:00] <ogra> hmm, libcanberra-gnome still holds back ubuntu-desktop
[10:00] <mdz> slangasek: re: powernowd, absolutely yes.  it was originally there because we used the daemon, then only because its init script loads the modules and sets the governor.  if the kernel/udev can do that on their own now, we should axe it
[10:01] <ogra> yay
[10:01] <pitti> directhex: will sponsor
[10:01] <directhex> cheers pitti
[10:03] <directhex> pitti, you can't sync mono-debugger 2.0-1 (LP #300156) while you're at it can you? my 0ubuntu1 package was a bust, but the sync is fine
[10:04] <directhex> i know it's universe, but you're awake! :p
[10:05] <pitti> directhex: component doesn't matter for syncs; doing
[10:05] <directhex> thanks!
[10:05] <pitti> E: mono-debugger: not found
[10:05] <pitti> meh?
[10:06] <directhex> pitti, meh? archive being slow or something? i spy http://ftp.debian.org/debian/pool/main/m/mono-debugger/mono-debugger_2.0-1.dsc
[10:06] <pitti> tel, bbl
[10:09] <pitti> directhex: no idea, sync-source is being mad at me
[10:09] <directhex> :(
[10:09] <directhex> let's just leave it a few hours
[10:09] <pitti> might be mirror being lagging or os
[10:09] <pitti> s/os/so/
[10:10] <Hobbsee> pitti: did you forget to feed it again?
[10:10] <pitti> tel again, argh
[10:11] <directhex> yeah, reckon it's mirror related. i see it on ftp.debian.org but not mirror.ox.ac.uk
[10:11] <directhex> stupid slow oxford people
[11:00] <Kanam> hey guys... maybe this is the place where I will find a answer to my question.
[11:02] <Kanam> We all know that Ubuntu plan to release a new version every 6 month. What happens if a the release date, some piece are not accomplished ?
[11:02] <Kanam> is the release rollouted ? or delayed ?
[11:05] <directhex> Kanam, yes, it can be delayed
[11:06] <directhex> Kanam, 6.04 was delayed until june, for example
[11:14] <Kanam> ok directhex. I suppose it just a mater of "is the problem critical"
[11:15] <Kanam> I looked for a place where i could find what kind of trouble should delay a release and what should be resolved post released by update
[11:15] <Kanam> but i did not find
[11:16] <soren> Kanam: It's not very easy to define, really.
[11:17] <Kanam> for exemple if the translation is not over for a locale... I suppose that it's not release-critical and that it could be solved by update
[11:18] <wgrant> Dapper wasn't delayed due to some problem, really.
[11:20] <Kanam> so why ?
[11:20] <cjwatson> Dapper's delay is pretty certain not to happen again; don't take it as a model
[11:21] <cjwatson> it was delayed because we needed to get a new installer in place but we realised it was going to be impossible to do so in the time available
[11:21] <Mithrandir> cjwatson: while I hope you're right.  Famous last words. :-)
[11:21] <Mithrandir> s/\./:/
[11:22] <cjwatson> sure, but I don't want to encourage people into believing that we might delay releases, because once people believe that it becomes the truth
[11:22] <ogra> Kanam, translations are updated constantly even after release, features that are not ready by feature freeze get thrown out, the typical thing that would delay a release would be "app X wipes your HDD if you close a window" or some such
[11:23] <cjwatson> even then, it would only be if we found out about this so close to release that we weren't able to resolve it in time; and I would only expect that to result in a day or two of delay at most
[11:23] <ogra> it has to be really critical to delay the whole thing, minor annoyances or missing feaures are not in the critical realm
[11:23] <ogra> right
[11:23] <ogra> it widnt delay by months :)
[11:23] <ogra> *wouldnt
[11:24] <directhex> even crap like the "no nvidia drivers for most people" thing
[11:24] <Mithrandir> for that to happen, it'd be something like "all the developers go sick for a month"
[11:24] <ogra> heh
[11:24] <Kanam> ho ho I'm not trying to make this change
[11:29] <Hobbsee> Mithrandir: the late-effecting UDS plague?
[11:30] <Hobbsee> er, delayed-reaction UDS plague?
[11:30] <directhex> you joke, but putting so many greasy computer people in close proximity can only mean one thing: biohazard warning
[11:31] <Hobbsee> directhex: the UDS plague is a known problem.
[11:31] <Hobbsee> directhex: at least most people shower regularly, and wear different tshirts each day.
[11:31] <directhex> Hobbsee, you get the same thing working for a university - freshers' flu. every single cold & sniffle from every corner of the earth, moved to one place, in spet/oct
[11:32] <Hobbsee> they don't tend to be *that* greasy - or at least, not that I noticed.
[11:32] <Hobbsee> heh
[11:32] <Mithrandir> I think we should make showering mandatory and use a fire hose on those that don't
[11:32] <Hobbsee> a normal hose.  I'm fairly sure it's illegal to use fire hoses for anyhting but fires.
[11:33] <directhex> Hobbsee, easily solved
[11:33] <directhex> set them on fire if they haven't showered!
[11:33]  * Hobbsee giggles
[11:34] <Hobbsee> perfect solution!
[11:34]  * directhex wonders when UDS will return to somewhere commutable, like oxford
[11:34] <Hobbsee> just get used to leaving the country.  Problem solved.
[11:35] <directhex> Hobbsee, yeah....... i have a mortgage to pay
[11:36] <Hobbsee> darn
[11:39] <Treenaks> directhex: so do I, and I'm going to the UDS ;)
[11:40] <directhex> Treenaks, at a cost of how much, excluding accommodation?
[11:41] <Treenaks> directhex: €a_lot
[11:41] <Treenaks> directhex: I prefer the european ones, they're a lot cheaper ;)
[11:41] <directhex> i don't have €a_lot
[11:42] <Treenaks> directhex: I don't have €a_lot anymore ;)
[11:42]  * Hobbsee suggests not attempting to get more money by blowing up ATMs
[11:43] <Treenaks> Hobbsee: so that's why I haven't seen you at a UDS since Seville! :P
[11:43] <Hobbsee> Treenaks: haha :)
[11:43]  * Hobbsee hasn't been for other reasons
[11:43]  * jussi01 just only saw Hobbsee's last comment on the chatview, and thought it was interesting....
[11:43] <Hobbsee> jussi01: <evil grin>
[11:44] <jussi01> :D
[12:03] <cjwatson> TheMuso: I've adjusted the desktop seeds to use gnome-session-canberra instead of libcanberra-gnome
[12:04] <cjwatson> (and processed that through NEW)
[12:16] <cjwatson> could somebody score up https://launchpad.net/ubuntu/+source/xorg-server/2:1.5.3-1ubuntu1/+build/797814 (xorg-server/armel), please?
[12:17] <cjwatson> I think it would be helpful for it to build a little earlier than December ...
[12:17] <Mithrandir> just a sec
[12:17] <pitti> cjwatson: done
[12:17] <seb128> cjwatson: hi
[12:18] <Mithrandir> dear LP, please stop logging me out.
[12:18] <Hobbsee> (done)
[12:18] <cjwatson> four at once! score
[12:18] <cjwatson> thanks all you enthusiastic buildd admins ;-)
[12:18] <Hobbsee> ;)
[12:18] <directhex> dear Mithrandir, you must log in to complete this request. love LP
[12:19] <seb128> cjwatson: not sure that the gtk directfb backend is really supposed to work in the current version, it's not maintained upstream and didn't build, I did some changes to get it build but I would not be surprised if there was other things required
[12:19] <Mithrandir> directhex: I logged in a couple of days ago
[12:19] <seb128> cjwatson: I didn't spend too much efforts on it because etoomuchtodo and it was not used in ubuntu
[12:19] <cjwatson> seb128: understood; it worked in 2.12
[12:20] <cjwatson> seb128: I was going to figure out how to patch it up if nobody else had
[12:20] <seb128> cjwatson: right and they rewrote some code for offscreen rendering which broke the backend and nobody bothered updating the directfb code
[12:20] <cjwatson> seb128: I'll be going on leave soon, so it'll probably have to wait until after that, though
[12:20] <seb128> cjwatson: I'm not convinced directfb is the way to go
[12:20] <pitti> directhex: argh, monodoc upload rejected, fixing
[12:21] <directhex> pitti, whyso?
[12:21] <pitti> directhex: forgot -sa
[12:21] <cjwatson> seb128: bit late
[12:21] <seb128> cjwatson: do we really need the graphical d-i? isn't ubiquity and the alternate installer enough?
[12:21] <directhex> pitti, ah, so not my cock-up then
[12:21] <cjwatson> seb128: I'm only going to do the d-i GTK frontend if it's easy, and that means following Debian
[12:21] <cjwatson> seb128: I've had requests for it
[12:21] <seb128> cjwatson: alright, the debian pkg-gnome had some discussion about that too
[12:22] <cjwatson> seb128: surely this should be with debian-boot ...
[12:22] <seb128> cjwatson: the thing is that nobody is the gtk land is interested by maintaining the directfb backend so debian will need to find somebody wanting to do that if the installer keep relying on it
[12:22] <cjwatson> that's reasonable, yes
[12:22] <cjwatson> mind you, there are outstanding patches in bugzilla to update the directfb backend
[12:22] <seb128> cjwatson: right, the discussion which happened on IRC was rather a "should it block the new version to go in experimental"
[12:23] <cjwatson> so it would be a matter of actually doing something with those, I'd have thought?
[12:23] <seb128> could be
[12:23] <seb128> it still requires somebody wanting to spend time reviewing those
[12:23] <seb128> if somebody is interested in doing that great
[12:23] <cjwatson> seb128: GTK d-i isn't a hugely high priority; I was just hoping that it would be a reasonably straightforward thing to pull in
[12:24] <seb128> I was just pointing that neither the ubuntu desktop team nor debian pkg-gnome has somebody interested in that right now
[12:24] <cjwatson> but it's not at the bottom of the list either
[12:24] <cjwatson> seb128: there's a history of debian-boot helping out to get that stuff to work already
[12:24] <seb128> ok good
[12:24] <cjwatson> I think there are two or three people who would be willing to get it fixed
[12:25] <seb128> I wanted to point that upstream didn't do the required changes to get the directfb backend working this cycle and that the patches we added are probably not totally correct
[12:25] <seb128> before you spent too much energy trying to figure why the d-i is not working
[12:25] <seb128> I guess debian will look at that after lenny
[12:25] <cjwatson> seb128: yeah, I'd already figured that out from looking at bugzilla :)
[12:25] <cjwatson> it was pretty clear that backend had fallen behind
[12:26] <cjwatson> thanks for letting me know
[12:26] <seb128> you're welcome
[12:27] <sebner> seb128: /me is wondering if we also will keep in (re-)sync with debian regarding gnome stuff O_o
[12:27] <seb128> sebner: why not?
[12:28] <sebner> seb128: because we haven't done it for years?
[12:28] <seb128> sebner: you are joking right?
[12:28] <sebner> seb128: well "no officially" because you know that -0ubuntu1 stuff
[12:29] <seb128> sebner: we do sync every cycle, look at the GNOME uploads on jaunty-change
[12:29] <seb128> sebner: we have some ubuntu specific changes, that doesn't mean we don't merge they change and sync the packages when we can
[12:29] <seb128> s/they/their
[12:30] <seb128> but launchpad integration changes are hard to get into debian for example
[12:30] <directhex> for some reason
[12:30] <sebner> seb128: sure, /me just noticed that we have now a 1ubuntu1 in jaunty but for example never in intrepid
[12:30] <seb128> sebner: right, debian is frozen using GNOME 2.22 for lenny and we have GNOME 2.24 in intrepid
[12:31] <sebner> seb128: ah true, sry =)
[12:32] <directhex> the lenny freeze is sucky.
[12:32] <sebner> directhex: the word "freeze" is sucky  :P
[13:43] <ogra> tjaalton, do you have any idea if there are plans to ship xorg 1.6 in jaunty ?
[13:43] <ogra> well, xserver
[13:48] <doko_> seb128: gnome-python did ftbfs on armel. could you tighten the b-d, or wait with uploads until the packages are built on all archs?
[13:50] <seb128> doko_: no and no
[13:50] <seb128> I can kick a rebuild later though
[13:51] <seb128> doko_: waiting on all arches means waiting hours between uploads because some arches are really slow which means breaking installability on all archs just to wait for slow ones which is a now win thing
[13:53] <tjaalton> ogra: yes there are
[13:53] <ogra> tjaalton, evdev 2.1 as well ?
[13:53] <tjaalton> ogra: evdev 2.1.0 is in already
[13:53] <ogra> perfect :)
[13:53] <ogra> that will make the touchscreen situation a lot easier :)
[13:54] <tjaalton> ye
[13:54] <tjaalton> +p
[13:58] <doko_> seb128: fine if you remember these rebuilds; didn't work well in intrepid (not only gnome)
[14:14] <ogra> cjwatson, is teher any useful reason for us to have libvte9-udeb ? (assuming we wont use directfb in d-i i wouldnt think so)
[14:15] <ogra> *there
[14:51] <directhex> hm. can i swap a pair of packages between main & universe please? ^_^
[14:54] <kirkland> slangasek: i agree with your proposal regarding bug #277517;  i have tested the lpia build via ppa, and persia confirms ia64;  that wasn't enough confidence for Intrepid at that point in the release, but for Jaunty, i think it should be fine now.
[14:56] <directhex> kirkland, next we need PPAs using kvm to make ia64 packages :)
[14:57] <kirkland> directhex: ;-)  agreed
[14:57] <kirkland> directhex: i kinda wish there were ppc builds for ppa too
[14:57] <kirkland> directhex: or at least for people who ask for them
[14:57] <directhex> kirkland, so do i. i had a request for ppc support on my mono backport repo
[14:58] <directhex> lpia support was "free", although i've had no users yet
[15:02]  * directhex wonders if pitti is still about
[15:02] <pitti> directhex: o/
[15:02] <directhex> that was fast o_O
[15:03] <cjwatson> ogra: let's please keep it; the assumption that we won't use directfb in d-i is *not* a safe one to make!
[15:03] <directhex> pitti, as part of the transition, monodoc has a slightly different build-dep which is causing dep-wait. (currently in universe) libmono-relaxng2.0-cil is used to build instead of the (currently in main) libmono-relaxng1.0-cil
[15:04] <ogra> cjwatson, ok
[15:04] <pitti> directhex: promoted libmono-relaxng2.0-cil to main
[15:04] <pitti> directhex: unfortunately just about 1 minute after the publisher started to run, so it'll take another two horus
[15:05] <pitti> "hours", no Aegyptian gods here
[15:05] <directhex> pitti, great, thanks. you can demote 1.0 if you like - its only rbd is monodoc, which obviously is no longer the case
[15:05] <pitti> directhex: component-mismatches will pick that up
[15:05] <directhex> pitti, handy! i suspect it'll geta  lot of work during this transition
[15:09] <directhex> reverse-build-depends ought to be an apt-cache function, not just a script from ubuntu-dev-tools
[15:47] <pitti> slangasek: did you have some time so far to test the new hal's rfkill patch in my PPA?
[16:09] <seb128> doko_, pitti: could you rescore the pygtk and gnome-python builds? they did fail on first try on some arches because there was not enough delay between the pygobject, pygtk, etc uploads
[16:10] <pitti> seb128: you mean score them down or up?
[16:11] <seb128> pitti: I did click on the retry button but they are schedule for next week now
[16:11] <pitti> so, 'up' :)
[16:11] <seb128> pitti: whatever makes those go faster, otherwise the python stack will be uninstallable during this week on those
[16:11] <pitti> seb128: pygtk> only on ia64 and sparc, others are built
[16:12] <pitti> (pygtk 2.13.0-2ubuntu1)
[16:12] <seb128> pitti: right, pygobject was reading on time for other arches
[16:12] <pitti> gnome-python 2.22.3-0ubuntu2 rescored on hppa, armel, sparc; ia64 FTBFS, others built
[16:12] <seb128> danke
[16:12] <pitti> seb128: shall I retry it on ia64?
[16:12] <pitti> well, you can do yourself
[16:14] <cjwatson> soren: would you mind doing a no-change upload of vm-builder to jaunty? The copy from intrepid-security/updates has meant that it's run into bug 299448 and the Architecture: all binaries are missing from armel's Packages files
[16:14] <cjwatson> soren: a no-change upload is the simplest fix
[16:14] <seb128> pitti: I did retry on arches where is was require but retries have a low score
[16:15] <seb128> pitti: danke
[16:31] <soren> cjwatson: I'm working on a new upload as we speak anyway..
[16:51] <cjwatson> soren: ok, cool
[17:09] <doko_> how am I supposed to make new libtool and old automake-1.7/autconf2.13 work together? e.g. in rpm
[17:09] <doko_> or fontforge
[17:30] <slangasek> mdz: right; I don't know that kernel/udev can set the governor on its own yet, I was coming at the question from looking at a sponsorship bug and being confused by the package's current description
[17:31] <mdz> slangasek: I'm pretty certain it's possible to set the default governor in the kernel config.  not sure about loading the right modules
[17:31] <slangasek> mdz: it seems there are some chipsets that can't handle ondemand, and currently 'userspace' is the fallback we're using
[18:05] <slangasek> pitti: hal rfkill> no, sorry, I had a stack overflow; looking at it now
[18:05] <pitti> slangasek: ah, hang on
[18:05] <pitti> slangasek: upstream just responded that the patch shouldn't be needed at all any more, due to restructuring of the addon
[18:06] <slangasek> pitti: not needed any more, effective when?
[18:06] <pitti> slangasek: so I'll update that package in my PPA in a bit (as soon as I fixed the FTBFS which occured on the jaunty buildds, but not on my local build)
[18:06] <slangasek> (I saw a bug follow-up from upstream that talked about a "new" plugin, which made it sound like it would sit alongside the existing one)
[18:06] <pitti> slangasek: effective with the 0.5.11+git shapshot I uploaded to jaunty a few days back
[18:07] <pitti> slangasek: so I think we should test 0.5.12rc1 first, and if that still gives problems, try my ported patch
[18:08] <pitti> meh, it *still* builds fine in an up-to-date jaunty chroot, WTH
[18:08] <pitti> oh, buildds are already using -libc-dev 2.6.28
[18:10] <pitti> tjaalton: do you still remember why hal needs 85_set_property_direct.patch? It's still not upstream
[18:13] <slangasek> pitti: so, this is fun; I upgraded hal to your ppa for kicks, and network-manager proceeded to give my default route to my openvpn tap0 device
[18:15] <pitti> bah
[18:16] <slangasek> the new version incorrectly believes tap0 is a wired ethernet, I guess?
[18:17] <pitti> slangasek: seems like it; could you do an lshal output of the old and new version and diff?
[18:17] <slangasek> yeah, I'll have a look at that this evening
[18:17] <slangasek> (right now I have Thanksgiving Day preparations I should be working on)
[18:17] <pitti> thanks
[18:17] <pitti> oh, it's a holiday in the US?
[18:17] <pitti> enjoy then!
[18:18] <tjaalton> pitti: yes, it's because otherwise the callout-script (debian-setup-keyboard) doesn't work
[18:52] <directhex> pitti, depending on which mirror gets pulled from, mono-debugger ought to be syncable. it's definitely on ftp.debian and ftp.de.debian
[18:58] <pitti> directhex: what was the bug again?
[18:58] <pitti> bug number, I mean
[18:58] <directhex> 300156
[18:59] <directhex> *cough*
[18:59] <directhex> LP #300156
[18:59] <pitti> yep, syncs now
[19:00] <pitti> slangasek: I uploaded 0.5.12~rc1-0ubuntu2~intrepid1 to my ppa, with the rfkill patch dropped; please let me know if it still works for you
[19:02] <directhex> mono-tools is trapped ni debian NEW. i'm looking at a 0ubuntu1
[19:06] <directhex> yeah, builds fine, another promotion needed like the last one (s/mozilla0.2/webbrowser0.5/)
[19:06] <directhex> i'll track down a verifiable orig since i can't pull it down from NEW
[19:20] <DktrKranz> cjwatson, is autosync running correctly? It seems aria2 source package has not been autosynced.
[19:20] <cjwatson> DktrKranz: "auto"
[19:21] <cjwatson> it's run by hand daily ;-)
[19:21] <cjwatson> DktrKranz: I'll run it now
[19:21] <DktrKranz> oh, I thought it was running automatically, thanks
[19:22] <cjwatson> it's automatic in the sense that the commands are trivial compared to the work that's done
[19:22] <cjwatson> but it isn't cronned
[19:22] <DktrKranz> I understand, thanks ;)
[19:23] <directhex> pitti, thanks for syncing that. only one package left for transition phase 1 to be complete!
[19:23] <directhex> and rene has committed my OOo changes to ooo-build, which means that one should transition soon
[19:24] <directhex> well, in debian. up to doko or calc after that
[19:34] <br1ck> gday, can somebody in here help me out with initrd creation
[19:34] <br1ck> i know it is not really a dev thing but #ubuntu-boot is not exactly crowded
[20:21] <HoppingWombat> hello
[20:21] <HoppingWombat> i am looking to join the development team
[20:21] <HoppingWombat> and i am a bit confused
[20:21] <HoppingWombat> if someone could tell me if i get this right, that would be great
[20:21] <HoppingWombat> first i become a ubuntero
[20:22] <HoppingWombat> right?
[20:22] <bryce> HoppingWombat: I think most people are gone on vacation right now
[20:22] <bryce> HoppingWombat: starting as ubuntero is probably a good idea
[20:22] <HoppingWombat> oh ...
[20:22] <bryce> HoppingWombat: then work your way towards getting MOTU
[20:23] <bryce> then after that you can go for core-dev if you like
[20:23] <Mithrandir> HoppingWombat: https://wiki.ubuntu.com/MOTU/GettingStarted might be a good starting point.
[20:23] <HoppingWombat> ok ... after a bit of being a ubentero i go to contributing developer, right?
[20:23] <HoppingWombat> then motu?
[20:24] <bryce> HoppingWombat: it's been some time since I went through the process and I know some bits have changed.
[20:26] <HoppingWombat> well, thanks guys ...
[20:26] <HoppingWombat> i think i have it
[20:26] <HoppingWombat> :-) hope to see you soon
[20:27] <Mithrandir> happy to help
[20:35] <pochu> HoppingWombat: feel free to join #ubuntu-motu and ask questions there
[20:36] <HoppingWombat> i think i will :-)
[20:36] <HoppingWombat> oops ... need to go
[20:36] <HoppingWombat> bye ... thanks for helping!
[21:41] <Laney> Can we sync packages from debian-multimedia?
[21:45] <RAOF> Laney: IIRC the answer is "we can sync packages from anything with a reasonable repository structure".  Whether or not you /should/ ask to sync packages from debian-multimedia is a slightly different question :)
[21:45] <cjwatson> what he said
[21:45] <Laney> Well I've been pointed to there for a package update I did myself
[21:46]  * directhex thirds the "AUDIT MARILLAT PACKAGES!" warning
[21:47] <Laney> :P
[21:47] <RAOF> Details are often useful :).  What package, what was the update, does it exist in debian proper, etc.
[21:49] <Laney> RAOF: Package is anyevent, new upstream version (not updated in Ubuntu since ever), not in Debian
[21:49] <Laney> I don't really care for it that much, just saw that it needed an update on UEHS
[21:50] <Laney> ...so I now feel obliged to follow through
[21:52] <RAOF> Ah, the old "you touched it you maintain it" urge.
[21:53]  * Laney nods
[21:54] <Laney> The packaging doesn't have any serious problems that I can see, and it's definitely not worse than what we currently have
[22:38] <directhex> so who wants to work some magic on LP #302955, and sign off phase 1 of the mono transition?
[22:39] <directhex> it'll require that libmono-webbrowser0.5-cil be promoted (replacing the old libmono-mozilla0.2-cil package in main used for pre-2.0 versions)
[22:41] <wgrant> pitti: How can apport use the LP API? That needs auth for everything!
[22:44] <directhex> if some sexy beast were to upload that mono-tools package, then I could send a big friendly mail to ubuntu-devel and ubuntu-motu announcing phase 2 open & awaiting help. i really could. i have the technology!
[22:49] <mathiaz> james_w: hi - I'm going through your wiki page on distributed development
[22:49] <james_w> hi mathiaz
[22:49] <mathiaz> james_w: in https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource
[22:49] <mathiaz> james_w: when you get the trunk branch why do you name the local branch after the name of the package?
[22:50] <mathiaz> james_w: ex: seccure
[22:50] <bryce> is anyone here running jaunty on an intel graphics system, and wouldn't mind testing out a new -intel driver build for me?
[22:50] <mathiaz> james_w: wouldn't it make more sense to call the branch ubuntu or jaunty?
[22:51] <james_w> mathiaz: it depends how you are storing them I guess
[22:51] <james_w> but yes, with the way I have suggested it would make sense
[22:53] <mathiaz> james_w: hm - in your example dropping the last option (package name) would create a directory named after the release
[22:53] <mathiaz> james_w: which makes the most sense given the use of init-repo package name
[22:53] <mathiaz> james_w: that's the way I've structured my source directories.
[22:53] <james_w> mathiaz: the example was originally the launchpad one, where it would name it after the package
[22:54] <james_w> mathiaz: so specifying it is generally needed
[22:54] <james_w> mathiaz: you're free to organise things however you like of course
[22:54] <mathiaz> james_w: hm-right
[22:54] <mathiaz> james_w: agreed that I can organize whatever I want
[22:55] <mathiaz> james_w: however from a newbie perspective having standard practive helps to get started
[22:55] <james_w> mathiaz: I entirely agree, so I picked a suggestion that would work. Feel free to edit the page
[22:55] <mathiaz> james_w: and choosing a directory structure is not really an important choice to get started.
[22:56] <mathiaz> james_w: is the naming schema for LP already aggreed upon? (ie: lp:ubuntu/+trunk/seccure )
[22:57] <james_w> I think they are pretty firm on it
[22:57] <wgrant> The spec says /ubuntu/+latest/openssh, but that it's still open for discussion.
[22:57] <james_w> the spelling of +latest is certainly an open question
[22:58] <mathiaz> james_w: ok - just thinking about way to simplify the workflow
[22:58] <james_w> either way round you get conflicts sometimes
[22:58] <james_w> but having the suite last probably gives you less
[22:58] <james_w> however +latest isn't a normal name for a directory
[22:58] <mathiaz> james_w: could a checkout of an ubuntu branch do the create-repo automatically?
[22:59] <james_w> I suggested we extend bzr to let directory services suggest a target directory if the user doesn't specify one
[22:59] <james_w> that would let us be creative
[22:59] <mathiaz> james_w: my point being: bzr co lp:~ubuntu/hardy/mysql-dfsg-5.0/ should get me started right away
[23:00] <james_w> mathiaz: it would have to be a higher level tool
[23:00] <mathiaz> james_w: it would create a bzr repo and do the upstream co there.
[23:01] <james_w> that command will get you started right away, just not in the optimum way if you are going to have more than one branch.
[23:01] <james_w> and if a checkout of an ubuntu branch should create a shared repository, why not a checkout of any other branch?
[23:02] <mathiaz> james_w: agreed - I almost always created a repo before co upstream
[23:02] <wgrant> Because bzr should do what I tell it, and not something else like creating a shared repository.
[23:04] <james_w> that's one argument
[23:04] <TheMuso> cjwatson: Thanks a lot, I was going to do that once gnome-session-canberra cleared binary new, but you beat me to it.
[23:04] <mathiaz> wgrant: right. as james_w it may belong to higher level tool then.
[23:05] <james_w> the higher level tool could be another bzr command of course
[23:05]  * mathiaz nods
[23:05] <james_w> it was suggested that having an "easy" tool and an "advanced" one (standard bzr) might not be the best idea
[23:57] <RAOF> popey: Aha!  The tools which build a binary package will automatically create a file named "$PACKAGENAME_$VERSION_$ARCH.deb".  Nothing actually cares about the filename of a .deb.
[23:58] <popey> thanks
[23:59] <popey> I'm glad the guy himself didn't venture into -motu to be honest
[23:59] <popey> being told he's doing it wrong isn't exactly friendly
[23:59] <azeem> I said he's doing /something/ wrong