[00:11] <burner> anyone familiar with what ubuntu is going to do about nautilus and gio in hardy?  gio isn't going to support smb:// or ftp:// according to the gnome folks.  can gnome-vfs going to be backported or are we just going to have regressions when going from dapper to hardy?
[00:11]  * Fujitsu can use SMB in Hardy's Nautilus, and it seems to use GIO...
[00:12] <burner> oh?
[00:12] <Fujitsu> It's not exavrtly reliable, but...
[00:12] <burner> well wtf was all that chatter on planet gnome?
[00:12] <Fujitsu> There was something about it not supporting network:/// or similar a while ago.
[00:13] <burner> aww
[00:13] <burner> that's right
[00:13] <burner> http://live.gnome.org/GioToDo says there is no Network:  ftp: http/https/webdav: obexftp: burn: or fonts:
[00:14] <burner> ftp is going to kill me when doing web dev :\
[00:14] <soren> Aw, no fonts:/// ?
[00:15] <Fujitsu> I have a burn:/// too.
[00:15]  * burner shrugs
[00:17] <ion_> You aren’t using FTP with authentication but without encryption, are you?
[00:18]  * burner is
[00:18]  * burner does
[00:18]  * burner has a host that doesn't support sftp
[00:18] <thotypous> hi :)
[00:19]  * Fujitsu would have hoped that such hosts ceased to exist a while ago.
[00:19] <ion_> You aren’t paying anything for the service, are you?
[00:19] <thotypous> hi caetano
[00:20] <caetano> hi
[00:20] <thotypous> hey, is there someone here responsible for ubuntu's kernel stuff?
[00:20] <mjg59> thotypous: #ubuntu-kernel
[00:21] <thotypous> thanks
[00:21] <thotypous> hey maskd, #ubuntu-kernel
[00:27] <Pimentel-ES> thotypous: burro
[00:27] <Pimentel-ES> nao vai falar do oss?
[00:31] <xivulon> heno: I have uploaded umenu code to https://code.launchpad.net/umenu
[00:31] <xivulon> make prerequisites && make && make test
[01:02] <ogra> aclocal: macro `AM_PROG_MKDIR_P' required but not defined
[01:02]  * ogra sighs loudly
[01:31] <lamont> ogra: automake does tend to make one sigh, doesn't it./
[01:32] <ogra> yeah
[01:33] <ogra> especially if someone "fixed" your code to use a newer version instead of being compatible with the most common one ....
[01:40] <jdong> any ubuntu-main-sponsors want a quickie?
[01:40] <jdong> (upload, that is)
[01:44] <lamont> ogra: but newer is always better, no?
[01:45] <TheMuso> jdong: In a few months I might. :p
[01:45] <TheMuso> but not just yet
[01:45] <jdong> TheMuso: :) that's no help for a feature freeze ;-)
[01:45]  * jdong thinks transmission should stay in universe until FF!
[01:46] <TheMuso> jdong: Its called, just got the keys to the world, and don't want to break anything.
[01:46] <jdong> TheMuso: haha well you have my word that it won't break anything :)
[01:46] <jdong> if that means anything :D
[01:46] <TheMuso> No, I'm not even on the main sponsors team yet
[01:47] <jdong> oh well I'll keep /pounce-ums active then
[01:48] <ogra> lamont, yeah, but some people use changelogs to let other devs know it changed ... ;)
[02:01] <superm1> ogra, i missed the discussion with you and laga on the patches that he had for mythbuntu-diskless against ltsp, what came of that?
[02:02] <ogra> superm1, the plugin is included in ltsp since today, his initramfs changes have to be merged into the mythbuntu-diskless-client package
[02:03] <ogra> there are some changes i''d like to see in the code before final but all in all it looks fine
[02:03] <superm1> ogra, okay so everything should be fine on it then for this cycle?
[02:03] <ogra> yup
[02:03] <superm1> ogra, great, thanks :)
[02:16] <lamont> sigh.  jdong did you get taken care of while I was translocating?
[02:16] <jdong> lamont: you mean my call for sponsorship? not yet
[02:16] <lamont> what is it you need sponsored?
[02:16] <jdong> bug 190614
[02:16] <ubotu> Launchpad bug 190614 in transmission "New upstream version: 1.05" [Undecided,New] https://launchpad.net/bugs/190614
[02:16] <lamont> if it's not too complex, I suppose I could be talked into it...
[02:16] <lamont> hrm...
[02:16] <jdong> it's a trivial and routine one
[02:17] <jdong> I've been the one who's done like the past 4 or 5
[02:18] <lamont> where does $UPSTREAM_VERSION get used?
[02:18] <lamont> or rather, where should I grab bts from to look at them?
[02:18] <jdong> lamont: it's used in Debian's get-orig-source rule
[02:18] <jdong> lamont: which is redundant and there for historical purposes, as right now a watchfile is used
[02:19] <jdong> (before DFSG needed to do some repacking)
[02:19] <lamont> ah
[02:20]  * lamont fetches
[02:20]  * lamont wants to know how to get gutsy's network managler to automatically notice that and switch ssids without me doing "manual config"
[02:22] <jdong> lamont: it doesn't detect your teleportation?
[02:24] <lamont> something like that
[02:24] <jdong> lamont: are you sleeping to and from your destination?
[02:30] <lamont> I removed network mangler and reinstalled it (long story_)
[02:30] <lamont> and right now all i have is 'manual config'
[02:33]  * lamont dist-upgrades his hardy chroot so he can test build
[02:35] <ogra> does anyone know why libexecdir defaults to /usr/libexec, even that dir usually doesnt exists in debian/ubuntu and is usually pointed to /usr/lib ?
[02:35] <ogra> i would expect it to use a default that actually works with my system
[02:36] <lamont> ogra: historical linux?
[02:37] <ogra> silly ... i would expect tools that have "auto" in their name to set the best defaults for the current system i'm on :)
[02:38] <lamont> ogra: bug keybuk, I guess...
[02:38] <ogra> well, likely asleep :)
[02:39] <lamont> and your excuse?
[02:39] <ogra> freeze tomorrow, and insanely early meeting :)
[02:39] <lamont> oh. meh
[02:40] <ogra> (well, insanely early for my biorhythm ... others like to be up at 8am :) )
[02:42] <lamont> feature freeze or so?
[02:42] <ogra> yep
[02:42] <ogra> which goes hand in hand with UVF nowadays
[02:42] <lamont> ok.  /me has an upload pending for bind9 - but it's more of a bug fix, IMO
[02:43] <lamont> otoh, we're two revs back
[02:43] <ogra> well, it wouldnt be a freeze if theer werent exceptions
[02:44]  * lamont files a sync request,  having noticed that it's out of date
[02:57] <lamont> jdong: you didn't say it build-depends: $WORLD
[02:58] <jdong> lamont: sorry :)
[02:58] <jdong> lamont: you could take my word that it builds fine in a hardy pbuilder
[02:58] <ScottK> !jdong
 jdong: yes, but you're FULL OF CRACK!
[02:58] <ScottK> ;-)
[02:59] <ScottK> If it's transmission though, I'd be inclined to believe him.
[03:00] <lamont> heh
[03:00] <lamont> Get:91 http://us.archive.ubuntu.com hardy/main gettext 0.17-2ubuntu1 [1978kB]
[03:24] <lamont> jdong: transmission_1.05-0ubuntu1 uploaded
[03:24] <jdong> lamont: thanks!
[03:24] <jdong> lamont: now it'll hurt less the next time you do it for me :D
[03:24] <lamont> lol
[03:25] <jdong> (luckily for you there's FF)
[03:25] <lamont> yeah - my build chroots hadn't been set up yet on the laptop
[03:25] <lamont> what's FF? :-)
[03:25] <lamont> I will _not_ upload firefox for you
[03:25]  * lamont ducks
[03:25] <StevenK> Hah
[03:26] <LaserJock> lol
[03:26] <emgent> :)
[03:26] <StevenK> Is jdong wanting to crackport firefox? :-P
[03:26] <lamont> I  wonder if anyone has ever done stats on who's sig is most common on new upstream versions in the archive post-feature freeze...
[03:26] <lamont> StevenK: what else could FF possibly mean? :-)
[03:27] <StevenK> lamont: "Feature Freeze"
[03:27] <lamont> StevenK: you do spoil trolling, you know...
[03:27] <LaserJock> lamont: seb128 perhaps?
[03:27] <StevenK> lamont: :-)
[03:27] <lamont> LaserJock: almost certainly
[03:27] <jdong> StevenK: ff-3 crackports already done btw ;-)
[03:27] <StevenK> jdong: Argh
[03:28]  * lamont notes that is  "just do the right thing, dammit' build-package script is now 250 lines of shell
[03:28] <jdong> StevenK: it was done responsibly and safely though ;-)
[03:28] <lamont> I should really consider rewriting that in something else.
[03:29] <StevenK> lamont: Blink?
[03:29] <StevenK> 250 lines to do what?
[03:31] <superm1> could one of you many core-devs around sponsor a small patch to acpi-support?  bug 123104
[03:31] <ubotu> Launchpad bug 123104 in acpi-support "Suspend using nvidia driver and NVIDIA 8400M GS doesn't work" [Undecided,In progress] https://launchpad.net/bugs/123104
[03:32]  * ScottK is pretty certain that's not where I'm going to start doing Main uploads....
[03:32] <lamont> ScottK: _I_ won't touch an acpi upload
[03:33] <StevenK> ScottK: Did you get core-dev?
[03:33] <lamont> StevenK: mostly magic sed commands to smash build-deps around
[03:33] <ScottK> StevenK: I did
[03:33] <lamont> StevenK: he's a real person now
[03:33] <StevenK> ScottK: Nice! Congrats
[03:33] <jdong> superm1: we still use acpi-support?
[03:33] <ScottK> lamont: Heh
[03:33] <superm1> congrats ScottK, i wasnt aware of this either
[03:33] <StevenK> lamont: ... Why?
[03:33] <ScottK> StevenK: Thanks.
[03:33] <ScottK> superm1: Thanks.
[03:33] <lamont> StevenK: he's a real person because he's cool.
[03:34] <jdong> ScottK: congrats!
[03:34] <lamont> acpi?  scary - too easy to break random crap elsewhere with what seems like a simple fix.
[03:34] <StevenK> lamont: Sorry, that "... Why?" was due to "mostly magic sed commands to smash build-deps around
[03:34] <superm1> jdong, I was under the impression that part of it was still used
[03:34] <lamont> because sometimes I backport things from hardy to dapper.
[03:34] <superm1> to build the modules that need to be taken out
[03:34] <StevenK> Crazy
[03:34] <jdong> superm1: that may be. Sounds a bit silly though
[03:34] <lamont> jdong: acpi-support is on my freshly-installed gutsy box
[03:34] <StevenK> superm1: I'd talk to mjg59 first.
[03:35] <jdong> superm1: and pm-utils's taking out modules routine actually does absolutely crap
[03:35] <ScottK> jdong: THanks
[03:35] <jdong> lamont: hardy's using pm-utils though :)
[03:35] <lamont> ah, ok
[03:35] <superm1> thanks StevenK i'll check with him
[03:35] <jdong> superm1: I filed a bug and a debdiff on that ;-)
[03:35] <lamont> one of these days I should do more playing with hardy...
[03:35] <jdong> lamont: it looks very promising as a solid release :)
[03:36] <lamont> mostly ScottK just tells me to upload stuff, and I do....
[03:36] <lamont> no one wants a solid hardy release more than me
[03:36] <lamont> backporting from hardy to dapper, um, sometimes really really sucks
[03:36] <jdong> lol
[03:38] <lamont> only 10 sed commands (admittedly, it could be 2, since all but one just tweak debian/control
[03:38] <lamont> I think my favorite has to be:
[03:38] <lamont>                         sed -ri "$(grep-dctrl -P -sPackage -n python- ${CTL} |
[03:38] <lamont>                                   sed 's/\(python\)\(-.*\)/\/^[^ ]*(Pac|Dep|Sug|Pro|Con|Rep)\/s\/\0\/\12.4\2\/g;/')" ${CTL}
[03:38] <StevenK> Please. I just ate.
[03:39] <LaserJock> yikes
[03:40] <jdong> wow
[03:40] <lamont> what's wrong with having sed generate a sed program?
[03:40] <lamont> have I mentioned that I love python, and I _HATE_ python-packaging changes?
[03:40] <StevenK> lamont: A few things. Mostly readability and maintainability?
[03:41] <lamont> StevenK: piffle
[03:42] <lamont>                         sed -i '/^Build-Dep/s/libdb-dev (>=4.6.19-1)/libdb4.4-dev/g' ${CTL}
[03:42] <lamont> that one is nicer.
[03:43] <lamont> see, this way I just say 'build-package -bfeisty postfix_4.7.1-1' and it does the right thing, and generates binaries for testing, so that I can sign and upload the source.
[03:43] <lamont> admittedly, the dapper backports I'm doing have a very targeted uh, target.
[03:43] <jdong> lamont: why don't you just write a pbuilder-satisfydepends that's more lenient? :)
[03:43] <jdong> lamont: then I can steal parts of that for backports usage too
[03:44] <lamont> jdong: because I'm uploading these to a pedantic archive
[03:44] <StevenK> lamont: Is the meat of build-package calling sbuild or pbuilder?
[03:44] <jdong> lamont: lovely :)
[03:44] <lamont> sbuild.
[03:44] <lamont> what's pbuilder?
[03:44] <lamont> :-)
[03:44] <StevenK> Haha
[03:44]  * lamont has only been using sbuild for most of a decade...
[03:44] <lamont> I keep saying that I should really take time and learn pbuilder... it never makes it above the cutline though...
[03:45] <StevenK> Depends how long your machine takes to untar a 80Mb base tarball
[03:45] <lifeless> lamont: pdebuild FTW
[03:45] <lifeless> lamont: combined with bzr builddeb, its fun
[03:46] <lamont> a major improvement in the script came recently when I taught it to notice that I'd forgotten the epoch in the version, and just rip that from changelog
[03:46] <StevenK> I'm going to stand up for sbuild, and say that keescook is my hero and that mk-sbuild-lv rocks
[03:46] <lamont> lifeless: I've used bzr far more in the last five weeks than ever before.
[03:46] <lifeless> lamont: thumbs up or down
[03:46] <lamont> I'm building a list... have filed a bug or 3
[03:47] <lamont> well, _a_ bug, iirc.
[03:47] <lamont> I think that I have more
[03:47] <lamont> lifeless: I did make my life a bit simpler by making sure that I'm using bzr 1.1-1 everywhere, instead of 0.8.$mumble
[03:48] <lamont> 0.8.2-1ubuntu3 to be specific
[03:48] <lamont> and myriad versions in between...
[03:49] <lamont> bzr uncommit? +1
[03:49] <lamont> any bzr command that generates copious output not doing the right thing (piping to $PAGER)? -1
[03:50] <lamont> mostly thumbs up
[03:50] <LaserJock> lifeless: you guys got a "bzr for git users" doc somewhere?
[03:51] <lifeless> LaserJock: the wiki, possibly the user manual now
[03:51] <lamont> lifeless: give me an easy way to bzr import from active git repo, and push commits both ways
[03:52] <lamont> LaserJock: I'
[03:52] <lamont> ve mostly been getting the crash-hands-on course
[03:52] <StevenK> I wish there was a "git for bzr users" -- I really like bzr, but can't get my head around git
[03:52] <lamont> see the tech talks
[03:52] <lamont> most notably randalls
[03:53] <LaserJock> StevenK: I think I might be the opposite
[03:53] <LaserJock> I don't think I got much out of bzr
[03:53] <LaserJock> but I find git quite nice
[03:53] <StevenK> bzr just works like cvs and svn, so I just clicked.
[03:53] <StevenK> git just looks oddball
[03:53] <Fujitsu> StevenK: bzr doesn't work like CVS. CVS doesn't work.
[03:54] <lamont> StevenK: that's what happens when someone designs the plumbing and doesn't care about the porcelain
[03:54] <StevenK> Fujitsu: Sure it works, it just doesn't do some things well
[03:54] <lamont> git prior to 1.5?  sucky UI that is not recommendable for anyone other than kernel gods
[03:54] <StevenK> Heh
[03:54] <StevenK> Well, even Rusty can't work out git
[03:55] <lamont> rusty?
[03:55] <LaserJock> I really like git-cvs
[03:55] <lamont> LaserJock: parsecvs for the win
[03:56] <lamont> although you need sane ,v files for that
[03:56] <StevenK> lamont: Rusty Russell
[03:56] <lamont> lifeless: yes, postfix broke parsecvs too
[03:57] <lamont> merge speed in git is rather incredible, I must say
[03:57] <LaserJock> I think the part of bzr that's gives me problems, and perhaps what I like about git, is the "branch as dir" concept
[03:57] <lamont> ??
[03:58] <LaserJock> I just don't like having directories all over so I tend to not branch very much in bzr
[03:58] <LaserJock> whereas in git my dir structure stays clean even if I have branches all over
[03:58]  * ogra was proposing a branch as pizza function since ages, but noone heard
[03:58]  * lamont tends to bounce between branches in one working directory... if I really really need more than one dir, I can clone the branch I want into a sisiter dir
[03:59] <RAOF> LaserJock: Where as I'm completely the opposite.  git's hidden branch approach smacks of code-simplicity over interface tradeoffs to me.
[03:59] <lifeless> StevenK: you dont want to get your head around git
[03:59]  * lamont isn't sure about this "branch as dir" thing...  maybe I need to actually read the users manual...
[03:59] <lamont> RAOF: hidden branch?  it's a file.
[03:59] <lamont> you want it in a separate dir, you clone
[03:59] <lifeless> lamont: problem is, plumbing sets constraints on porcelain
[04:00] <RAOF> lamont: And then checkout.  Using strange and arcane syntax.
[04:00] <lamont> yeah... that's why it wants to be pretty static from the beginning
[04:01] <lamont> RAOF: of course.  clone is well, clone
[04:02] <emgent> debian #464876
[04:02] <ubotu> Debian bug 464876 in drupal5 "drupal5: New upstream version 5.7 available, fixes several bugs" [Normal,Fixed] http://bugs.debian.org/464876
[04:03] <lamont>  git clone postfix test; cd test; git rebase origin/stable/v2.4
[04:03] <lamont> it's not _so_ arcane...
[04:04] <lamont> of course the downside is that 'master' in test is then stable/v2.4 in the original (postfix) tree
[04:04] <lamont> just remember: source management systems all suck.  differently.
[04:05] <lifeless> lamont: branches in a file in .git -> not discoverable; complex rules to edit, can't use standard shell commands to manage branches, urls are tricky to define well and usefully.
[04:07] <lamont> actually, .git/refs/head/$branchname is a file... containing the sha1 of the head of that branch
[04:08] <lamont> and git-branch -a will show all of them
[04:08] <lamont> hrm.. does dapper dpkg have anything like source:Upstream-Version?
[04:13] <lamont> nope.
[04:13] <lamont> sigh
[04:15] <StevenK> lifeless: moblin are using git, so I have to at least learn a bit
[04:15] <lamont> StevenK: seriously, watch randall's tech talk
[04:16] <lamont> once you understand git's "index" (which every source management system has, and almost none export to the user's view), then it all falls into place.
[04:16] <lamont> until then, it's confusion
[04:17] <lamont> randall does a good job of giving a tech overview of git.
[04:17] <StevenK> lamont: Google for "randall tech git talk" or so?
[04:17] <lamont> lifeless: bzr bisect would be cool to have.
[04:17] <lamont> StevenK: yep
[04:17] <lamont> google for "git tech talk" (with quotes) and (last time i did it) there were two results: linus and randal
[04:17] <lamont> randall
[04:17] <lamont> even
[04:18] <lifeless> lamont: https://launchpad.net/bzr-rebase
[04:19] <lifeless> lamont: exposing the index is not done by most systems for a reason
[04:19] <lifeless> lamont: its like exposing inodes to the user (and I don't mean C programs) on a file system.
[04:21] <lamont> lifeless: yeah
[04:22] <RAOF> lifeless: You know, it seems like all the features I want in bzr are already plugin projects on LP.  Are they going to get an actual release sometime soon?  Please? :)
[04:22] <lifeless> RAOF: what do you mean
[04:23] <lamont> lifeless: yeah... the index does tend to confuse the hell out of people without providing them the benefit that understanding it would given them.
[04:23] <lamont> s/given/give/
[04:23] <RAOF> Well, there seem to be a lot of useful bzr plugins on LP; things like bzr-git, bzr-rebase, bzr-bisect, etc.  But none of them seem to have released a tarball.
[04:24] <RAOF> Or been packaged in some other form useful to me.
[04:24] <lifeless> lamont: s/would/might/
[04:24] <lifeless> lamont: most users won't get any benefit from the index
[04:26] <lamont> yeah
[04:26] <lifeless> they don't /want/ a current state that differs from the working tree in any wa.
[04:26] <lamont> the index being exposed is one of those things you get when a kernel jock designs an SCM.
[04:26]  * lamont uses it as a 1/2 commit :0)
[04:29] <lifeless> RAOF: so package and upload them
[04:29] <lifeless> RAOF: join the bzr-packaging team
[04:29] <lifeless> RAOF: tarballs are so 1980's
[04:29] <LaserJock> lifeless: is there such a team?
[04:30] <RAOF> Oh, but that's *work*.  Worse, it's work that I have to do! :P  Ok, added to my TODO.
[04:30] <lifeless> LaserJock: its on alioth
[04:30] <StevenK> lamont: Googling only shows Linus' talk
[04:30] <LaserJock> StevenK: the first one is the one you want
[04:30] <LaserJock> StevenK: it just says "git"
[04:31] <LaserJock> http://www.youtube.com/watch?v=8dhZ9BXQgc4
[04:31] <lamont> gah
[04:31] <lamont> gimme a second
[04:32] <lamont> http://video.google.com/videoplay?docid=-3999952944619245780
[04:33]  * StevenK clicks the yummy download link
[04:33] <lifeless> RAOF: basically, with a vcs every push is a release; folk really stop bothering with tarballs in smaller projects. too much overhead, and too slow.
[04:33] <lamont> StevenK: any of the october versions are Randall.  Linus was a few months earlier
[04:34] <lamont> lifeless: overall, I'm very impressed with bzr
[04:34] <LaserJock> lifeless: except it's hard to distribute and is much harder to find a "stable" release
[04:34] <RAOF> lifeless: Fair enough.  Bzr builddeb should make packaging from bzr more enjoyable.
[04:34] <lamont>   * backport to dapper
[04:34] <lamont>   * source:Upstream-Version expanded inline
[04:34] <lamont> there. now build-package deals with packages that use source:Upstream-Version
[04:34] <lifeless> lamont: good :)
[04:35] <lamont> wc /home/lamont/bin/build-package
[04:35] <lamont>  254  802 7371 /home/lamont/bin/build-package
[04:35] <lifeless> LaserJock: uhhh, its trivial to distribute, and tarballs have no magic equality with stability.
[04:37] <LaserJock> lifeless: it's not trivial to distribute until we get rid of source packages, and no, there is no "magic", but it's more "conventional"
[04:41] <lamont> lifeless: for anything that's going into a debian/ubuntu/whatever release, trivial packaging of tar+diff is kinda a requirement
[04:41] <lamont> or at least a tarball
[04:41] <lifeless> lamont: 'bzr export'
[04:41] <lamont> yeah - it's trivial for us'ns
[04:42] <lamont> I was aluding back to the bzr builddeb
[04:42] <lamont> which I freely admit to never having used
[04:42] <TheMuso> bzr-builddeb is great.
[04:44] <jdong> "which I freely admit to never having used"
[04:44] <jdong> that's coolest sentence construct of the day!
[04:45] <lamont> jdong: cool sentence construction is just one of my more flashy skills
[04:45] <lamont> I haz gud wordspeak
[04:45] <lifeless> in ur channelz hacking ur brainz
[04:46] <lamont> 'zactly
[04:46] <lamont> lifeless: so when are we all switching to RCS? :-)
[04:46] <lamont> my kids go to RCS.
[04:46] <lamont> hrm.
[04:46] <lamont> I think that's different

[04:47] <jdong> lamont: you you have to pick them up and drop them off individually?
[04:47] <jdong> :)
[04:47] <StevenK> And woe betide if your children change names!
[04:47] <lamont> actually, their start/stop times _are_ staggered 15 min... so the one just gets dropped off early and picked up late
[04:48] <lamont> www.ridgeviewclassical.com
[04:48] <StevenK> A classical school.
[04:48] <lamont> StevenK: _very_.
[04:48] <StevenK> Damn, I was going somewhere with that, and then my thought train derailed
[04:49] <StevenK> Oh yes.
[04:49] <StevenK> A classical school, as opposed to you know, *regular* boring school.
[04:50] <jdong> to make everyone feel better....
[04:51] <jdong> at the MIT software engineering course, I am being FORCED to write JAVA CODE in a PAPER NOTEBOOK.
[04:51] <jdong> of course, 0.5 pages of code later, it turned into a 3 page argument why this is nonsensical :)
[04:51] <StevenK> I hate doing that in exams.
[04:52] <regulate> take a different course
[04:52] <lamont> StevenK: it's more around changes in the modern education ideas
[04:52] <lamont> which the school kinda, uh, rejects.
[04:52] <StevenK> lamont: Like computers?
[04:53] <lamont> like student-desire-drivin curriculum.
[04:53] <lamont> actually, the school teaches openoffice to everyone
[04:53] <StevenK> Pah, we never had that when I went to school
[04:53] <lamont> it's a mindset, not specific curriculum.
[04:53] <lamont> curricula?
[04:54] <regulate> curriculae
[04:54] <regulate> curriculum
[04:54] <lamont> tardy?  no problem.  sit right there on the bench until the period is over.  you will not interrupt the class and waste 1+ student-hours (30 students, 2 min or so disturbance)
[04:55] <lamont> little things like that.  very teacher-centered education
[04:55] <lifeless> lamont: do they get their drugs from CVS?
[04:55] <lamont> we actually don't have any CVS stores here.  iz very sad.
[04:55] <StevenK> I nearly fell over when I saw the CVS store in Boston
[04:56] <StevenK> And then on Friday, pitti and I saw a CVS import
[04:57] <lamont> StevenK: that just hurts
[04:57] <lamont> hrm...  closing time... I guess I should start wrapping up
[04:58] <lamont> dear kde.  70 MB is not a deb.  it's several.
[04:58] <lamont> kthx
[04:58] <genii> OK, not sure if this is some dev issue, but here's a weird problem. In 2.6.22-14-generic my usb based rtl8187 works fine but kernel of course can't see my full 8Gb. In 2.6.22-14-server the RAM gets seen but the nic is no good. Even tried compiling from svn from rtl-wifi but getting indecipherable compiler errors on all svn versions 61 thru 67.The exact same code compiles without a groan under -generic
[04:59] <genii> Some weird PAE thing perhaps?
[05:01]  * genii hands SNuxoll a coffee
[05:02] <SNuxoll> yay caffiene
[05:10]  * lamont relocates homeward
[05:35] <talcite> hey guys, does anyone know if the sqlite3 in the gutsy repos is compiled with the --threadsafe option?
[05:38] <beuno> talcite, it would seem from the build log that yes: http://launchpadlibrarian.net/9193582/buildlog_ubuntu-gutsy-i386.sqlite_2.8.17-2.1build1_FULLYBUILT.txt.gz
[05:39] <LucidFox> Any core-devs involved with Mono here?
[05:39] <beuno> it has the "-DTHREADSAFE=1" bit in it
[05:41] <talcite> beuno: thanks
[06:10] <warp10> Good morning
[06:22]  * lamont gets home, sleeps.  night all
[06:23] <Fujitsu> Night lamont.
[06:27] <LucidFox> Fujitsu, did you check PM?
[06:45] <thegodfather> superm1: ping?
[06:45] <superm1> yo
[06:46] <thegodfather> superm1: hey.. i think you should plan to change the Depends: mysql-server to Predepends
[06:46] <superm1> on which?
[06:46] <superm1> er which package particularly at least
[06:46] <thegodfather> superm1: problem on upgrade is simple.. mythtv wants to backup and update the db, but if mysql is upgraded too, it's not running.. failing to backup and update
[06:46] <thegodfather> superm1: dunno.. you can figure that out yourself :)
[06:47] <superm1> ah for folks going from dapper->hardy or gutsy->hardy
[06:47] <thegodfather> at the moment i am just doing hardy->hardy regular updates
[06:47] <superm1> and running into that particular issue i suppose?
[06:47] <thegodfather> problem occours when there is a major myth db update and mysql update at the same time
[06:47] <thegodfather> so that will be the case also on upgrades from release to release
[06:47] <thegodfather> or anything that upgrades to hardy
[06:48] <thegodfather> superm1: yes.. right now
[06:48] <superm1> thegodfather, okay i'll see what i can do, you should see it in the next hardy update.  let me know if that works out better for you then
[06:49] <thegodfather> superm1: well it can be simulated if you need to
[06:49] <thegodfather> superm1: just prepare a fake mysql update in your local repo and a mythtv update at the same time
[06:50] <superm1> yeah good point
[06:50] <thegodfather> superm1: make sure that the mythtv update simulate a mysql DB update and zack
[06:50] <superm1> well i'm fairly confident that you're right on this too, pre-depends should solve it.
[07:48]  * Mithrandir grumbles at his /dev/sda being renamed to /dev/hda
[07:49] <ogra> lol, really ?
[07:50]  * ogra has never seen it this way around
[07:51] <Mithrandir> happened between -5 and -7 in hardy.
[07:51] <Mithrandir> unsurprising, this breaks libpam-mount
[08:01] <dholbach> good morning
[08:10] <stgraber> moin
[08:12] <TomJaeger> Stefan Bader is not hanging around here, is he?
[08:17] <TomJaeger> are there any formal critera to get a patch into the ubuntu kernal?
[08:18] <TomJaeger> anybody?
[08:20] <TomJaeger> alright, I'll just post to launchpad
[08:20] <TomJaeger> quit
[09:06] <TheMuso> Do MIRs need to be done by FF?
[09:07] <ionstorm> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.24/+bug/190587 whats up with this security risk
[09:07] <ubotu> Launchpad bug 190587 in linux "Local root exploit in kernel 2.6.17 - 2.6.24 (vmsplice)" [High,Fix committed]
[09:08] <panthera> hi,
[09:08] <panthera> for the sake of 'history', i'd like to have all ubuntu revisions ever of my packages in debian.
[09:09] <panthera> is there something like snapshot.d.n for ubuntu?
[09:15] <cjwatson> panthera: you should be able to fish them out of links in Launchpad, at least from dapper onwards
[09:16] <cjwatson> start from https://launchpad.net/ubuntu/+source/PACKAGENAME
[09:18] <cjwatson> ionstorm: seems to be in pretty good progress
[09:24] <panthera> cjwatson: nice, thanks.
[09:32] <\sh> soren, thx
[09:32] <Riddell> pitti: could you give back digikam
[09:33]  * Mithrandir stabs gecko with a very sharp spoon
[09:34] <Mithrandir> actually, cairo.
[09:34] <simira> Mithrandir: didn't I tell you to stop stabbing people with spoons?
[09:34] <Mithrandir> epiphany-browser: /build/buildd/cairo-1.5.8/src/cairo-pdf-surface.c:4461: _cairo_pdf_surface_fill: Assertion `_cairo_pdf_surface_operation_supported (surface, op, source)' failed.
[09:34] <Mithrandir> (when trying to print to PDF)
[09:35] <soren> Unless there's any particular reason not to, could an archive admin please release the new kernel from NEW?
[09:35] <Mithrandir> not that postscript fares any better.  *sigh*.
[09:49] <tjaalton> any hal experts available? I can't get hal-set-property to work from a script ("Could not initialise connection to hald."), when it works if run by hand
[09:50] <cjwatson> soren: done (amd64 i386 lpia sparc)
[09:52] <soren> cjwatson: Cool. Thanks.
[09:52] <soren> cjwatson: Any chance we could get a new debian-installer once the new kernel is published?
[09:53] <soren> cjwatson: ...and perhaps a respin of the server cd when the new debian-installer is published? Pretty please? :)
[09:54] <TheMuso> soren: We need new metas I think.
[09:54] <soren> TheMuso: Not exactly "need".
[09:55] <soren> TheMuso: d-i specifies which version it wants.
[09:55] <soren> TheMuso: explicitly.
[09:55] <TheMuso> soren: Fair enough
[09:55] <soren> TheMuso: It wouldn't be very nice to have the installer and linux-meta out of sync, though.
[09:55] <soren> TheMuso: To sum up: Good point!
[09:55] <soren> :)
[09:57]  * TheMuso now feels nervous... About to upload packages to implement initramfs error handling... :)
[10:10] <cjwatson> soren: linux-meta should go in at around the same time, so I'd prefer kernel team coordination
[10:11] <geser> good morning
[10:11] <soren> cjwatson: Alright then.
[10:12] <pitti> Riddell: given back
[10:15] <pitti> soren: so pkg-create-dbgsym should use a temporary file instead of stdin? hmkay
[10:15] <pitti> ScottK: argh, sorry about not being at the meeting; I was at dancing school; how did it go?
[10:15] <\sh> if someone has some time checking licensing stuff: please review this license and tell me if it's usable for universe/multiverse? zend-framework http://framework.zend.com/license
[10:16] <soren> pitti: Either that or find another way of reading it from stdin.
[10:18] <ScottK> pitti: It went quite well.  I'm in.
[10:18] <ScottK> pitti: Thanks for asking.
[10:20] <Riddell> pitti: did you see that mhb had extra exams so won't make feature freeze for jockey qt
[10:21] <geser> \sh: what problem do you see with this license? it has a caption of "New BSD License" and also looks very similar to /usr/share/common-licenses/BSD
[10:22] <\sh> geser, this point: * Neither the name of Zend Technologies USA, Inc. nor the names of its
[10:22] <\sh>       contributors may be used to endorse or promote products derived from this
[10:22] <\sh>       software without specific prior written permission.
[10:22] <geser> \sh: "3. Neither the name of the University nor the names of its contributors
[10:22] <geser>    may be used to endorse or promote products derived from this software
[10:23] <geser>    without specific prior written permission." from /usr/share/common-licenses/BSD
[10:23] <geser> so it doesn't look like a problem
[10:23] <\sh> geser, so naming the package "zend-framework"  is not covered by this?
[10:24] <MacSlow> mvo, do you happen to be in a mode of grabbing a newer version of libcompizconfig from upstream atm?
[10:25] <pitti> ScottK: congratulations! *hug*
[10:25] <geser> \sh: at this point I'm not sure
[10:25] <pitti> Riddell: ergh, not given back; my script fails with a HTTP Error 500: Internal Server Error
[10:25] <pitti> Riddell: yay ever-changing LP
[10:25] <MacSlow> mvo, I ask because I just happen to run into a bug, which I talked about on #compiz-fusion... Danny fixed it right away... and it is important for the profile-spec
[10:25] <ScottK> pitti: Thanks.
[10:25] <\sh> geser, see, that's what was bugging me :)
[10:25] <pitti> Riddell: mhb> I didn't see it, I just talked to him yesterday and he seemed quite busy
[10:25] <pitti> with hacking on jockey
[10:26] <\sh> elmo, you as ftpmaster, any thoughts about this?
[10:26] <MacSlow> mvo, if you're busy elsewhere I can do it myself and just hand over the .diff.gz/.dsc for upload-sponsorship
[10:27] <cjwatson> \sh: a package name isn't normally counted as "endors[ing] or promot[ing]"
[10:27] <cjwatson> \sh: we have plenty of other examples of the same thing in the archive
[10:27] <mvo> MacSlow: I can do it in a bit, just use your local fixed version for developing in the meantime. it will be uploaded before lunch
[10:27] <MacSlow> mvo, okyday
[10:27] <MacSlow> argx
[10:28] <cjwatson> \sh: p.s. elmo hasn't done active Ubuntu ftpmaster work other than related system administration for a couple of years now. launchpad.net/~ubuntu-archive
[10:28] <MacSlow> mvo, thanks
[10:30] <\sh> cjwatson, so it's ok to name the package "zend-framework" without violating the new BSD lic...(and elmo came into my mind because of his duties as debian ftpmaster)
[10:30] <Riddell> pitti: ok, that was last week, maybe he's back onto it now
[10:31] <TheMuso> Ok, so I'm assuming that silence means that MIRs can be written, and can be accepted after FF...
[10:31] <cjwatson> \sh: if this were a problem, little things like python would be in violation. It's fine.
[10:31] <cjwatson> TheMuso: err
[10:32] <cjwatson> TheMuso: the incorporation of dmraid into the installer is a feature, and is subject to feature freeze
[10:32] <TheMuso> Oh ok.
[10:32] <\sh> cjwatson, thx for the headsup :)
[10:32] <cjwatson> TheMuso: we treat things on that kind of level rather than the mechanics of "is it an MIR or something else"
[10:33] <TheMuso> ugh of course
[10:47] <Mithrandir> siretart: is revu down?
[10:47] <ScottK> Yes
[10:48] <Mithrandir> hm, any idea when it'll be fixed?
[10:48] <ScottK> No.  It had a full hard drive yesterday, but sistypoty isn't around now and he was the one looking into it.
[10:50] <Mithrandir> ah, ok
[10:54] <Keybuk> ogra: long running argument, that one
[11:00] <TheMuso> cjwatson: Are you able to change the status of the initramfs error handling spec? Since I wasn't involved with it, I can't, but have edited the whiteboard and left notes.
[11:06] <dramen> hello
[11:08] <dramen> i built my own apt-repository. now when i want to install a programme using "apt-get install ...." i get a warning about authentification of the package
[11:10] <soren> pochu: gtk-vnc uploaded. Thanks.
[11:10] <TheMuso> dramen: You need to sign the Release file with a GPG key, and then ad the public key to apt's keyring, so it knows about it.
[11:10] <soren> pochu: Sorry for the delay.
[11:10] <pochu> soren: yohoo :)
[11:10] <dramen> i generated a Release.gpg in the repository and added the key to apt (apt-key add <file>)
[11:10] <pochu> soren: I was blocked with that for vinagre, so thanks a lot!
[11:11] <pochu> soren: was the patch update ok?
[11:11] <TheMuso> dramen: Hrm wel I'm out of ideas.
[11:11] <cjwatson> TheMuso: I've assigned it to you, so you should be able to change its status now
[11:11] <TheMuso> cjwatson: Thanks.
[11:12] <dramen> "apt-key list " shows me the correct data about my keys
[11:12] <dramen> and "gpg --list-keys" as well
[11:12] <soren> pochu: Almost :) One line missing, but it was easy to miss.
[11:13] <cjwatson> dramen: this may be obvious, but you need to 'apt-get update' *after* setting up a proper Release.gpg
[11:14] <dramen> i did it
[11:15] <dramen> and everything seems to be all right
[11:55] <Lure> who is the right person to approve blacklisting specific kernel modules, like suggested in bug 114565
[11:56]  * persia suspects someone in #ubuntu-kernel, but doesn't actually know
[12:15] <TheMuso> pitti: If you're around and have a minute, I'd like to have a chat with you about dmraid.
[12:40] <pitti> TheMuso: I'm 120% busy today anyway due to FF, so please just ask me, and I'll answer (maybe with some lag)
[12:41] <TheMuso> pitti: Ok. There was talk of adding dmraid to the installer as a feature for hardy, but nothing has been done till now. I happened to have hardware that supported it, and have managed to perform an install using dmraid, which is almost 100% working.
[12:42] <TheMuso> pitti: Do you think its worth trying to get in, and if so, should I go about writing an MIR for it, assuming that all is well with code etc?
[12:42] <TheMuso> pitti: Or do you think it shoudl wait for hardy+1?
[12:43] <pitti> TheMuso: what is dmraid? d-i already has support for setting up RAID?
[12:43] <pitti> TheMuso: is there a spec for it?
[12:44] <TheMuso> pitti: Afaik there is no spec. Dmraid is used to use the kernel's devmapper layer to make use of configurations that are saved to hard disks that are configured in a fakeraid/bios raid setup.
[12:44] <TheMuso> pitti: This is common on a lot of newer motherboards, well since 2002 at least.
[12:47] <cjwatson> pitti: the existing RAID support doesn't help with dmraid; there's no spec because this is work done upstream by Debain
[12:47] <cjwatson> Debian
[12:49] <pitti> TheMuso: MIR wise you can go ahead for my sake, but I don't feel qualified about feasibility of d-i/ubiquity integration; I defer to cjwatson and evand for that
[12:49] <pitti> (and keep in mind that we are currently DoSed with dozens of MIRs and can hardly keep up, so it'll take a while)
[12:50] <TheMuso> Understandable.
[12:50] <TheMuso> pitti: Part of the integration with d-i is already done through partman-dmraid.
[12:57] <geser> pitti: have you time to give-back ftphs?
[12:58] <pitti> geser: if my script wouldn't fail with 500: Internal Server Error *sigh*
[12:58] <Mithrandir> geser: given-back
[12:58] <pitti> geser: nothing to give back
[12:58] <pitti> ah, Mithrandir beat me to it apparently
[12:58] <Mithrandir> yeah, my greasemonkey script doesn't take 500 for an answer.
[12:59] <StevenK> Hah
[13:00] <geser> Mithrandir, pitti: thanks
[13:17] <Riddell> pitti: could you move the dapper packages in bug 184149 to -updates at some point, they're been checked by sru-verification
[13:17] <ubotu> Launchpad bug 184149 in kdelibs "[hardy]xembed and flash support patches doesn't work for konqueror" [Undecided,Fix committed] https://launchpad.net/bugs/184149
[13:19] <pitti> Riddell: ok (although the flashplugin isn't updated in dapper yet)
[13:19] <Riddell> pitti: no but there's one in backports, and it won't do any harm for those with older flash
[13:19] <pitti> Riddell: bdmurray had to update the one in -backports AFAIR
[13:20] <Riddell> yes
[13:20] <pitti> anyway, will move
[13:20] <pitti> Riddell: btw, the bug mentions 'still broken in hardy', although it's marked as fixed?
[13:21] <Riddell> pitti: I suspect his konqueror just hasn't found the flash plugin
[13:26] <pitti> Riddell: copied
[13:26] <Riddell> thanks pitti
[13:36] <pranith> hello
[13:36] <pranith> is there any good decompiler which i can use to decompile binaries to source code. i need this for a project im doing...
[13:39] <pitti> pranith: if you are talking about decompiling machine code (ELF files), there can't be something like a 'good' decompiler
[13:39] <pranith> pitti, any decompiler, not necessarily good...?
[13:39] <pitti> pranith: I don't know any either
[13:40] <Mithrandir> pranith: gdb can disassemble for you
[13:41] <pranith> Mithrandir, dissambling is ok. i want a decompiler which can give me C source code. working with assembly is too complex
[13:42] <Riddell> pitti: so you're unable to give back digikam?
[13:42] <pitti> Riddell: doing now (just more work)
[13:42] <frafu> Hello, could anybody please review the main inclusion request for mousetweaks: https://bugs.edge.launchpad.net/ubuntu/+source/mousetweaks/+bug/190208
[13:42] <ubotu> Launchpad bug 190208 in mousetweaks "Main Inclusion Report for mousetweaks" [Undecided,New]
[13:43] <pitti> Riddell: done
[13:43] <Riddell> thanks pitti
[13:43] <TheMuso> frafu: Is ubuntu-mir subscribed? If so, theres nothing you can do but wait.
[13:43] <pitti> frafu: we have a huge backlog of MIRs; we'll get to it
[13:44] <TheMuso> frafu: The main inclusion queue is quite long atm.
[13:44] <frafu> TheMuso:  yes subscribed
[13:44] <TheMuso> frafu: Good.
[13:44] <frafu> But does feature freeze not apply?
[13:54] <zul> pitti: how convient for the drbd MIR should it be upgraded as well?
[13:59] <frafu> TheMuso: What about feature freeze? Once feature freeze has passed, will it have to wait ubuntu 8.10? Moreover, once it is in main, will the upgrades (upstream is GNOME) be done similarly as for universe: I prepare the diff.gz .of the new package, file an upgrade bug and subscribe ubuntu-main-sponsors to it?
[14:00] <seb128> frafu: GNOME desktop has a freeze exception for new versions
[14:08] <frafu> seb128: thanks for the reply; so I assume that it will make it into hardy. And what about the upgrade procedure? Will the core-dev do everything or is there also a procedure similar to upgrades in universe with sponsoring?
[14:08] <seb128> frafu: what upgrade?
[14:09] <frafu> for example when there is a new upstream release?
[14:09] <seb128> ah, you mean update
[14:09] <seb128> well, whoever does the updates usually should do those
[14:10] <seb128> when the package is promoted open sponsorship requests
[14:19] <frafu> seb128: thanks
[14:19] <seb128> you are welcome
[15:03] <saispo> any know if it's possible to resume a broken dpkg-buildpackage -rfakeroot or you must relaunch it from start ?
[15:03] <persia> saispo: You can resume, but the results may not be what you expect.  Restarting is preferred to ensure reliable behaviour.
[15:03] <saispo> persia: ok, it's an error about some info missing in control file :/
[15:04] <saispo> persia: how can i relaunch for test ? :)
[15:04] <persia> saispo: For something missing in the control file, you really want to run it all over again.
[15:04] <saispo> ok :/ kernel building take a lot of times :)
[15:17] <pitti> zul: "how convient for the drbd MIR should it be upgraded" -> parse error
[15:17] <zul> pitti: i was just wondering about the drbd MIR, i was talking to ivoks and we believe that it should be upgraded
[15:18] <pitti> ok
[15:18] <zul> so Im in the process of doing that right now
[15:18] <pitti> just FYI, my plan is to catch up on emails and some bugs now, and get to the MIR queue tomorrow
[15:19] <pitti> anything that qualifies for main in principle, but needs some bugs fixed first, can still be promoted later
[15:19] <zul> pitti: thats fine with me
[15:19] <pitti> (we need to settle on features now, not components)
[15:19] <zul> ive been going through the server-team related packages and trying to resolve the issues brought up in the MIR
[15:21] <pitti> hm, let me do a quick re-review now, so that you guys have some more time
[15:26] <geser> pitti: do you know when you will find time to fix pkg-create-dbgsym to respect -X from dh_strip calls?
[15:28] <pitti> geser: this week people will keep me busy with MIRs, sponsoring, reviews, etc., I'm afraid
[15:29] <pitti> geser: I'll switch to full bug fixing mode next week, and this is on the top of my list
[15:29] <pitti> if anyone is interested in fixing this, feel free to preempt me, of course :)
[15:29] <pitti> (even writing a test case for it would save me a lot of time already)
[15:30] <geser> pitti: no hurry, I'm just curious if it didn't get lost somewhere
[15:30] <pitti> geser: no, it's definitively not lost; just stalled until after FF
[15:38] <dholbach> keescook: you said something about syncing imagemagick: the newest response on bug 110178 says that it's in sid now and that 2 packages will ftbfs (dx and vips)
[15:38] <ubotu> Launchpad bug 110178 in imagemagick "Please sync imagemagick 7:6.3.7.9.dfsg1-1 from debian unstable" [Medium,Confirmed] https://launchpad.net/bugs/110178
[15:46] <cjwatson> mjg59: did you get a chance to look at the kernel font restoration work for hardy-console
[15:46] <cjwatson> ?
[15:46] <mjg59> cjwatson: Afraid not
[15:46] <cjwatson> are you likely to?
[15:47] <mjg59> Probably can do this evening
[15:47] <cjwatson> cool, thanks
[15:52]  * mvo wonders what the magic switch for git diff is to make it show newly added files as well
[15:52] <cjwatson> git diff --cached
[15:53] <cjwatson> if you 'git update-index' everything you've edited, then that will show everything that's due to be committed
[15:54] <mvo> cjwatson: thanks! that was what I was looking for :)
[15:55]  * mvo wants to go back to bzr
[15:55] <cjwatson> I have few words for whomever thought that --cached shouldn't be the default
[15:56] <mvo> funny, git diff gives me now the changes to the existing files, git diff --cache the diff of the new file. but none shows both
[15:56] <mvo> joy!
[15:56] <cjwatson> mvo: see my comment about update-index
[15:57] <cjwatson> in git you have to explicitly tell it about files you're changing, sort of like in quilt
[15:57] <cjwatson> although you can do so after editing rather than before, unlike quilt
[15:58] <mvo> I'm reading the man page for git update-index now, it seems like a simple "git update-index" is not enough (nor --add my-file)
[15:59] <Mithrandir> mvo: doesn't git add $new_file $file_you_changed and then git diff --cached DTRT?
[16:00] <mvo> Mithrandir: yes! misunderstood cjwatson earlier. that are indeed the magic words :)
[16:00] <mvo> thanks
[16:00] <Mithrandir> no need for git update-index nowadays, just use git add and git rm
[16:01] <Kano> hi, how about updateing ntfs-3g?
[16:01]  * mvo nods
[16:02] <Kano> 1.1120 is pretty old comparted to 1.2129 and also has built-in fuse lite (which uses debian)
[16:02] <cjwatson> Mithrandir: somebody said on a kernel channel the other day that one should continue to use git update-index because add may stop DoingTRT there
[16:03] <Mithrandir> cjwatson: yes, that was BenC and I corrected him about 20 lines further along; add is the right way to do it now.
[16:04] <Mithrandir> (see what git status outputs, for instance.)
[16:04] <cjwatson> Mithrandir: oh, ok
[16:05] <cjwatson> I stand corrected
[16:05] <tkamppeter> hi pitti
[16:08] <lool> cjwatson: Are you working on #127985?  Now that I'm core-dev, I can actually upload it  :-P
[16:09] <xivulon> heno: re umenu, you need "touch po/umenu.pot" before running make, forgot to include that file yesterday
[16:09] <cjwatson> lool: I'm not - please go ahead
[16:09] <lool> Thanks!
[16:36] <CarlFK> cjwatson: what should I be reading to get my "partman-auto/choose_recipe All in one partition"  settings right?  (install currently asks for recipe and disk.)
[16:37] <cjwatson> CarlFK: please ask me again after feature freeze
[16:37] <CarlFK> oke
[16:50] <Mez> any xen experts here?
[16:53] <mathiaz> Mez: you'd better ask zul
[16:54] <ArM-eye> amon-ra everyone
[16:54]  * pitti grumbles about someone uploading partman-target without checking it into bzr; this caused a rejected upload for me
[16:54] <ArM-eye> Do you want to read the reveal?
[16:55] <ArM-eye> It involves biblical figures
[16:55] <pitti> evand: can you please commit your partman-target changes to bzr? I already committed/pushed my own ubuntu4, so that needs to be merged
[16:55] <ArM-eye> yes or no?
[16:56] <ArM-eye> it must not be given against will
[17:07] <bazhang> ArM-eye: you got kicked from #ubuntu for that
[17:12] <evand> dear glade-3, stop renaming my widgets.  No love, Evan.
[17:14] <tkamppeter> pitti, ping
[17:17] <jpatrick> cjwatson: prehaps we should ban him? (just in case)
[17:27] <cjwatson> jpatrick: *shrug* he hasn't come back yet, if he does then I will
[17:27] <pochu> he was kicked by mdz on -meeting too
[17:32] <neftune> he seems to be all over freenode
[17:33] <jpatrick> neftune: network troll, then, anyone problems in #ubuntu channels, give us a call with !ops
[17:46] <pitti> hi tkamppeter
[17:52] <keescook> dang, missed dholbach
[17:52] <pitti> hi keescook
[17:52] <pitti> keescook: for the imagemagick sync?
[17:52] <keescook> hiya pitti
[17:52] <keescook> yeah
[17:53] <keescook> I was looking at the API changes and was worried
[17:53] <keescook> but if it's just two ftbfs, that's easy
[17:53] <keescook> I'm still a bit worried about the ABI changes -- there might be issues no one has noticed yet
[17:54] <tkamppeter> hi pitti, have you seen the HPLIP packages? Can you upload them before UVF?
[17:54] <keescook> however, I'd really like to get the updated imagemagick into hardy for the LTS
[17:54] <pitti> tkamppeter: yes, I will
[17:54] <pitti> keescook: no problem, I can sync it right now if you want me to
[17:56] <tkamppeter> pitti, when is the freeze exactly? At midnight UTC today or at midnight UTC at the end of tomorrow?
[17:56] <pitti> tkamppeter: tomorrow evening, see slangasek's mail
[17:56] <pitti> well, we deliberately don't specify it up to the second :)
[17:59] <keescook> pitti: it needs a merge, unfortunately (small change for g++ 4.3 compilation)
[17:59] <keescook> pitti: I've got it merged locally but was shy to upload it.  :)
[18:00] <keescook> should I just do it?
[18:00] <pitti> sure
[18:00] <pitti> if it doesn't horribly break main
[18:00] <pitti> keescook: is the gcc 4.3 fix upstream/in Debian's BTS, BTW?
[18:00] <keescook> well, that's what I mean -- I'm unsure if the ABI changes are going to eat the world or not.
[18:01] <keescook> pitti: not sure, doko did the ubuntu one, I will check for it.
[18:01] <pitti> oh, btw
[18:01] <pitti> I remember seeing an MIR for graphicsmagick
[18:01] <keescook> eeek
[18:01] <pitti> which was supposed to supersede and replace imagemagick
[18:01] <pitti> but I haven't heard anything about this any more from the reporter
[18:03] <keescook> I think graphicsmagick got attention because Debian hadn't moved imagemagick since 2005.  :P
[18:03] <pitti> -- hardy/main i386 deps on libmagick9:
[18:03] <pitti> imagemagick
[18:04] <pitti> inkscape
[18:04] <pitti> libmagick++9c2a
[18:04] <pitti> libmagick9-dev
[18:04] <pitti> libxine1-misc-plugins
[18:04] <pitti> rss-glx
[18:04] <pitti> keescook: ^ not too bad
[18:04] <pitti> i. e. screensavers, inkscape, and xine
[18:04] <keescook> I can make sure inkscape works.  ;)
[18:04] <pitti> oh, and some build deps: human-icon-theme tangerine-icon-theme tango-icon-theme tango-icon-theme-common
[18:05] <pitti> but I guess the CLI interface didn't change, just the internal library API?
[18:05] <keescook> okay, I'm going to shove it in -- the list looks small enough that we can sort out problems if they come up.
[18:05] <keescook> right, just the so bump
[18:05] <keescook> though I have to wonder if people have lots of work-arounds built up due to bugs in the CLI behavior -- but that's no reason not to upgrade either.
[18:05] <keescook> (yay alpha masking!)
[18:10] <webwolf_27> tkamppeter, do those *.dsc files need to be IN the source packages? or accompanied?
[18:11] <geser> webwolf_27: .dsc is part of the Debian source package (the others are the .diff.gz and .orig.tar.gz)
[18:11] <webwolf_27> geser, thanks
[18:18] <webwolf_27> does the *_source.changes belong in the archive as well?
[18:19] <pitti> webwolf_27: source.changes are an upload vehicle, they aren't kept permanently
[18:19] <webwolf_27> thanks pitti
[18:21] <jdstrand> pitti, slangasek, et al: I am adding a profile that exists in apparmor-profiles to a package.  the profile is a conffile in both packages.  I know that Conflicts is not enough-- is there a standard way (ie docs) on how to move a conffile from one package to another?
[18:21] <tkamppeter> webwolf_27, you do not need to make a tarball, you can put the 4 files .dsc, .diff.gz orig.tar.gz, and _source.changes simply into the same directory on the server. Then the whole kit can be directly passed over into the distro repos.
[18:22] <webwolf_27> tkamppeter, thanks for the info
[18:23] <tkamppeter> webwolf_27, but as I have to download the kit anyway to sign it you can also put the four files into one tarball.
[18:24] <ionstorm> update manager should have a update history
[18:24] <ionstorm> or does it already?
[18:24] <webwolf_27> ok I'll tar em
[18:25] <slangasek> jdstrand: these days, I think all you need is "Replaces"?
[18:25] <jdstrand> slangasek: mathiaz and I were talking about Replaces
[18:26] <jdstrand> slangasek: I was reading 7.5.1 of the policy and trying to make sure it did the right thing
[18:26] <mathiaz> don't you need to conflicts also ?
[18:27] <pitti> jdstrand: oh, for conffiles that's indeed quite some wizardry
[18:27]  * jdstrand nods
[18:27] <pitti> jdstrand: especially if you want to avoid dpkg conffile questions for modified ones
[18:27] <slangasek> mathiaz: no, conflicts means "remove the named package before installing this other", and I think all you want here is to change the ownership of the conffile
[18:27] <slangasek> I'm pretty sure that Replaces: now DTRT in dpkg
[18:28] <jdstrand> I was thinking I needed to do a variation on http://wiki.debian.org/DpkgConffileHandling
[18:28] <pitti> jdstrand: look at the udev preinst for an example
[18:28] <jdstrand> but would be very pleased with Replaces
[18:28] <pitti> jdstrand: yes, that has the recipes, too
[18:28] <slangasek> yeah, that wiki page is for moving a conffile around, not for changing its ownership
[18:28] <jdstrand> (hence the variation)
[18:28] <pitti> for normal files it's Conflicts:/Replaces: package (<< version_that_moved_the_file)
[18:28] <pitti> but conffiles are special
[18:29] <slangasek> probably wouldn't hurt to /document/ on that page how to change ownership of a conffile
[18:29] <pitti> tkamppeter: hplip uploaded
[18:29]  * jdstrand goes to look at udev...
[18:30] <slangasek> pitti: udev is moving conffiles around and removing them, which is again not what's happening here
[18:31] <slangasek> fwiw, libldap-2.4-2 took over a conffile from libldap2 in the recent migration using nothing more than a Replaces:, and there've been no bug reporst
[18:32] <pitti> it also has prep_mv_conffile() etc.
[18:32] <mathiaz> jdstrand: apparmor profiles are not conffiles IIRC.
[18:32] <jdstrand> !
[18:32] <pitti> as long as it's a conffile which users won't likely change (like an init script), a simple replaces: will probably do
[18:33] <jdstrand> mathiaz: let me check that
[18:33] <pitti> mathiaz: erm, they should
[18:33] <slangasek> pitti: but prep_mv_conffile() is also about moving the conffile to a different *location* on disk, not to a different package
[18:33]  * jdstrand admits he *thought* they should be too, and therefore assumed
[18:34] <tkamppeter> pitti, thank you.
[18:35] <jdstrand> mathiaz: some are, some aren't
[18:35] <jdstrand> the ones in question are
[18:36] <jdstrand> well, it installs some conffiles.  others are in doc/ as examples-- nothing is installed as a configuration file
[18:39] <mathiaz> jdstrand: right.
[18:39] <jdstrand> slangasek: is libldap-2.3-0 completely gone?
[18:39] <slangasek> jdstrand: long gone
[18:40] <jdstrand> slangasek: that was part of my question-- apparmor-profiles should still stick around.  I wasn't sure Replaces wasn't too heavy-handed
[18:40] <slangasek> jdstrand: oh, but libldap-2.3-0 isn't the package that owned the conffile, it was libldap2
[18:41] <slangasek> which is not completely gone yet; it /should/ go, but the Replaces: in any case is IMHO correct for your use case
[18:41] <slangasek> if apparmor-profiles is sticking around, though, it should be a versioned Replaces:
[18:41] <jdstrand> slangasek: I will give it a shot
[18:41] <jdstrand> slangasek: agreed
[18:42]  * jdstrand really would not like to create another recipe for DpkgConffileHandling
[18:42] <jdstrand> :)
[18:42] <slangasek> take heart in the fact that if it hasn't been written before now, it's pretty likely that it's not needed. :)
[18:48] <webwolf_27> tkamppeter, I'm uploading
[18:48] <webwolf_27> tkamppeter, I'll let you know when they are up
[18:49] <cody-somerville> Riddell: Hey.
[18:49] <cody-somerville> Riddell: for bug 191322, I simply packaged it before debian did so I feel it can be synced.
[18:49] <ubotu> Launchpad bug 191322 in libfile-basedir-perl "Sync libfile-basedir-perl 0.03-0.1from debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/191322
[18:52] <webwolf_27> tkamppeter, The3 tarball should be on http://www.fam-schoenhaar.de/jeremy/packages/ in about 12 Mins.
[18:54] <Riddell> cody-somerville: you misunderstand.  it would be nice to have it synced but that is impossible because the orig.tar.gz file is different (run md5sum on them)
[18:55] <Riddell> cody-somerville: it can be synced next time there is a new upstream .orig file in debian
[19:04] <webwolf_27> tkamppeter, did you get those tarballs?
[19:05] <bddebian> Riddell: All of those sync requests were pre-emptive.  New uploads just went in to Debian today. :-(
[19:08] <mathiaz> slangasek: are you planning to merge php5 before FF ?
[19:08] <tkamppeter> pitti, I have prepared bug 25966 for the package upload into NEW
[19:08] <ubotu> Launchpad bug 25966 in ubuntu "NEW PACKAGE: Printer drivers for Brother needed" [High,In progress] https://launchpad.net/bugs/25966
[19:09] <tkamppeter> pitti, should I upload all the packages to REVU? They will make one REVU entry for each (10 entries).
[19:11] <tkamppeter> Is it OK for the freeze when the packages are in REVU in time?
[19:12] <slangasek> mathiaz: had no plans for it, no; I only touched the package to rebuild against libldap-2.4-2
[19:12] <mathiaz> slangasek: ok. I'll work on the merge then.
[19:12] <slangasek> mathiaz: enjoy :)
[19:13] <cody-somerville> Riddell: Okay
[19:16] <tkamppeter> webwolf_27, a small fix is still needed in your source packages: You need to delete all editor backup files (*~).
[19:17] <Riddell> bddebian: that's pretty confusing then.  give me a ping when they're actually ready to process
[19:20] <bigon> will the new queue processed before FF?
[19:23] <bddebian> Riddell: OK, sorry, I just didn't want to miss the cut-off for Hardy.  BTW, there's one for lordsawar out there too that probably hasn't propigated in Debian either.
[19:23] <ScottK> Riddell: If you have a moment, would you please accept clamav 0.91.2-3ubuntu2.3~feisty1 in feisty-backports (it's got two CVE fixes in it).
[19:26] <Riddell> ScottK: done
[19:26] <ScottK> Riddell: Thanks (my first 'core-dev' type upload BTW).
[19:27] <pochu> ScottK: oh are you core-dev now? I didn't see any announcement. Congratulations :)
[19:27] <ScottK> pochu: Thanks (just happened yesterday).
[19:28] <bddebian> Whoa ScottK, congrats!
[19:28] <ScottK> bddebian: Thanks.
[19:29] <ScottK> bddebian: There were 4 others too (including TheMuso).
[19:29] <bddebian> Dang
[19:40] <geser> bddebian: when it's your turn? :)
[19:41] <cody-somerville> Can someone please review http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin?
[19:41] <cody-somerville> It requires one more advocation :)
[19:48] <cody-somerville> mischan
[19:52] <bddebian> geser: I'll never be worthy :-)
[19:57] <cjwatson> keescook: openssh with selinux fix on its way into the archive now
[19:58] <cjwatson> ogra: ^-- the above also includes consolekit support
[19:59] <keescook> cjwatson: nice, I was _just_ looking at that.  :)  which archive do you mean, btw?  I see it just landed in Debian.  Did you do a sync in ubuntu too?
[20:00] <cjwatson> keescook: I needed to branch the Ubuntu package for the consolekit support anyway so I just did an upload with that based on the Debian change
[20:00] <cjwatson> so I meant both archives
[20:06] <siretart> Mithrandir: yes, I'm tomorrow in the office again (finally!) and will look after sparky via serial console
[20:06] <pochu> TheMuso: \o/
[20:41] <gnash> anybody
[20:42] <ion_> nobody
[20:42] <gnash> okay
[20:42] <gnash> i ws askin if anybody can listen to me
[20:43] <ScottK> !ask | gnash (but not /topic and be on topic)
[20:43] <ubotu> gnash (but not /topic and be on topic): Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
[20:43] <ScottK> not/note
[20:45] <gnash> actually i m a very new user ..i even dont know if i m on right thread...here it goes i installed ubuntu gutsy yesterday and the sonund is not working at all..laptop is lenovo y series ...sound card is being detected....checked by lspci....sound not available to root even
[20:45] <gnash> any suggestions
[20:45] <ScottK> gnash: Then you should be asking on #ubuntu.  That's the channel for help.
[20:45] <gnash> okay
[20:46] <gnash> thank u
[20:46] <gnash> join #ubuntu
[20:46] <gnash> i think that is the command
[20:46] <gnash> ?
[20:46] <ScottK> gnash: Preceed the command with '/'
[21:10] <keescook> seb128: do you have details about the pcre3 7.6 incompat issues?  I'm surprised that upstream broke -- they're usually very careful.
[21:47] <jjesse> question in hardy which will be default firefox 2.0 or firefox 3.0?
[21:48] <pochu> jjesse: 3
[21:48] <jjesse> pochu: thanks
[22:08] <lifeless> why does pulse hate me :(
[22:14] <cjwatson>         modes.tmp.key 6 add dup length 1 add string /modes.tmp.str exch def
[22:14] <cjwatson> sigh, RPN makes my head hurt
[22:14] <lifeless> BenC: new kernel spam in hardy: [163017.896131] wlan0: switched to short barker preamble (BSSID=00:0c:41:f9:3f:12)
[22:14] <lifeless> BenC: want a bug ?
[22:15] <mjg59> cjwatson: I think I've got font restoration sorted, but the kernel does some weird things when switching from X. I'll want to look at that a little further.
[22:15] <mjg59> cjwatson: Amusingly, there's already a font structure in the vt structure
[22:15] <mjg59> It's just unused
[22:15] <cjwatson> I think I remember noticing that and swearing
[22:15] <cjwatson> thanks
[22:15] <mjg59> Oh, and I need to spend a while looking at the locking
[22:15] <mjg59> The VT layer is made of fail
[22:19] <lifeless> yay, pkill pulseaudio restores my music.
[22:28] <mario_limonciell> cjwatson, wading through debian/changelog from gfxboot, it looks like you brought it in from kanotix some time back.  what was the issue with bringing in grub-gfxboot at the same time (or was there one, or just not a priority)?
[22:38] <cjwatson> mario_limonciell: not a priority, and would have required care in gfxboot-theme-ubuntu which I didn't have time to give it
[22:38] <cjwatson> mario_limonciell: plus general consensus was that we didn't want to display a grub menu by default anyway
[22:38] <mario_limonciell> cjwatson, ah i understand
[22:38] <cjwatson> and the risk of things going wrong in grub is IMO greater than the risk of things going wrong at CD time
[22:38] <cjwatson> because at that point you're talking about people's previously working systems
[22:38] <cjwatson> so for all those reasons I steered clear
[22:53] <mario_limonciell> cjwatson, would there be an opposition to my bringing it into universe (and letting it live there for now)?
[22:54] <keescook> can someone familiar with grub and/or dpkg triggers look at 189173 with a +1/-1 ?
[22:54] <mario_limonciell> at least in the sense of using the normal grub package (that's in main) with the gfxboot patch added on to it
[22:54] <keescook> I believe it to be sane, but I wanted a second opinion
[22:55] <cjwatson> mario_limonciell: IMO that should only be done if somebody commits to updating gfxboot-theme-ubuntu to work with it
[22:55] <cjwatson> mario_limonciell: otherwise all it does is lead people down a wild goose chase
[22:55] <cjwatson> keescook: looks fine to me
[22:55] <mario_limonciell> cjwatson, do you know how much is involved with updating it?
[22:55] <cjwatson> mario_limonciell: I don't think it should be done unless it's actually worthwhile. We shouldn't have useless packages in universe and large complex patches applied to our default boot loader.
[22:56] <cjwatson> mario_limonciell: probably moderate amounts of work; bear in mind that gfxboot "themes" would in fact be better described as programmed boot loader menus
[22:56] <mario_limonciell> cjwatson, well we have a use case that is going to be needing it, so it would be preferable that it lives in apt rather than has to go into the factory only
[22:56] <cjwatson> you can't use gfxboot without a theme, and I doubt you want to use the SuSE one
[22:57] <cjwatson> you really should investigate this part of it before pulling grub-gfxboot into the archive
[22:57] <mario_limonciell> understood
[22:57] <mario_limonciell> well with the impending feature freeze, that's little time to explore it, so I was thinking "get it in" and then sort out the dust right afterward
[22:58] <cjwatson> the theme is a large part of the feature
[22:58] <cjwatson> seriously, the name is quite badly misleading
[22:58] <cjwatson> you are asking to get in a package that just will not work in any reasonable way
[22:58] <cjwatson> it's a bit more than dust
[22:58] <slangasek> keescook: the patch in 189173 looks sane enough to me, I'm more concerned about what goes on the other end of it :)
[22:59] <cjwatson> I've not deliberately broken it for non-syslinux boot loaders, but I'm fairly sure it won't work as is
[22:59] <cjwatson> and you absolutely need to know what's involved before committing to it
[22:59] <keescook> slangasek: yes, me too.  I'm trying to find the part of the selinux packages that touches menu.lst.  :P
[23:00] <slangasek> keescook: also, I'm not sure why this case warrants the complexity of a trigger, as opposed to having those other packages just call update-grub
[23:00] <michaelfavia> bluez-utils most recent update 3.26-0ubuntu2 is suspiciously missing binary named hidd is this intentional?
[23:01] <slangasek> the benefit of triggers is to defer all invocations until the end of a dpkg run, but there's no mention of getting the kernel packages to use this and those are the main consumers of update-grub today
[23:01] <keescook> slangasek: well, it'd be nice if everyone who needed to run an update-grub would trigger it instead of running it each time separately, so I'm for it.
[23:01] <keescook> true
[23:01] <slangasek> fair enough
[23:02] <michaelfavia> it isnt in the changelog and there is an existing question: https://answers.launchpad.net/ubuntu/+source/bluez-utils/+question/24516 would like to update ubuntu documentation to reflect chnages if change is known and intentional.
[23:02] <michaelfavia> already had 2 support requests.
[23:02] <mario_limonciell> cjwatson, okay thanks i'll double check with some folks on my team about it
[23:03] <_MMA_> mario_limonciell: Skype?
[23:03] <LaserJock> how many times is update-grub run generally for an average apt-get run? I wouldn't think it'd be that many
[23:03] <soren> keescook, slangasek: libc6 has done this quite cleverly w.r.t. ldconfig. We don't need to touch the kernel packages at all, afaics.
[23:03] <mario_limonciell> _MMA_, I won't be able to from here
[23:03] <_MMA_> np. Hit me up later.
[23:04] <_MMA_> (whenever)
[23:04] <mario_limonciell> ok
[23:04] <cjwatson> mario_limonciell: what's the use case here?
[23:04]  * LaserJock hits _MMA_ 
[23:04] <mario_limonciell> cjwatson, a localized grub menu is necessary
[23:04] <_MMA_> :P
[23:04] <mario_limonciell> cjwatson, and the only way that it seems to be possible to do (or at least has been done) was via the grub-gfxboot
[23:04] <cjwatson> mario_limonciell: rather than a hidden grub menu, which is the Ubuntu default if at all possible?
[23:05] <cjwatson> mario_limonciell: it's faintly possible that grub2 might be a saner approach here; there have been recent Planet Debian posts about its localisation support
[23:05] <soren> keescook, slangasek: Short version: ldconfig has been replaced by a wrapper that checks if it's being called as part of a postinst running. If so, it triggers. If not, it just calls the real ldconfig.
[23:05] <soren> We could do the same to grub quite easily.
[23:05] <mario_limonciell> cjwatson, yeah we need to be able to provide locale specific options rather than a hidden grub menu
[23:06] <soren> And by "we" I of course mean "someone who isn't me".
[23:06] <soren> :)
[23:06] <cjwatson> mario_limonciell: try grub2? with a bit of integration work, it might work better, and is already in the archive
[23:06] <cjwatson> we're probably going to have to migrate to it eventually anyway, and it would be nice to have somebody trying it out
[23:06] <cjwatson> grub-gfxboot will totally break with grub2 anyway
[23:06] <mario_limonciell> cjwatson, okay will do, and with it  being in the archive that gives time for the integration work still then
[23:07] <slangasek> soren: meh :)
[23:07] <cjwatson> mario_limonciell: http://oskuro.net/blog/freesoftware/time-for-grub2-2008-02-09-17-53
[23:08] <mario_limonciell> cjwatson, ah very good.  this does seem like a much more feasible route then as you say
[23:08] <keescook> soren: :)
[23:09] <cjwatson> mario_limonciell: on the flip side, grub2 is a new boot loader base and is untested in the Ubuntu context (though more people are beginning to try it out in Debian)
[23:09] <cjwatson> mario_limonciell: but I think it's probably the same order of magnitude of work as grub-gfxboot, and less horrifically painful in the medium to long term
[23:10] <mario_limonciell> cjwatson, indeed the additional testing that it would see from our usage would probably be beneficial to Ubuntu come the time to switch then
[23:11] <cjwatson> right, rather than having to throw it away in a year's time or whatever
[23:12] <mario_limonciell> okay thanks cjwatson
[23:56] <soren> Wow... Singing and piano lesson spam.. That's a first.
[23:56] <michaelfavia> hah
[23:56] <soren> I hope they teach singing and piano better than they spell.
[23:57] <ion_> I wouldn’t mind spam that teaches me to play piano better.
[23:57] <soren> ion_: I'm not complaining. :) Just saying.
[23:57] <TheMuso> soren: lol
[23:58] <soren> Oh, it's Argentinian. Some of it might just be dialect.
[23:58] <persia> Riddell: wildmidi was both rejected and accepted.  Am I missing something?