[00:04] <Keybuk> lamont: ok
[00:04] <Keybuk> lamont: http://kernel.ubuntu.com/git?p=scott/util-linux.git;a=summary
[00:04] <Keybuk> lamont: that either includes the missing uploads which I've uploaded again
[00:05] <Keybuk> lamont: or it contains hard core porn
[00:05] <Keybuk> lamont: I'm not entirely sure which, but it says "master" so it could be either
[00:05] <Keybuk> lamont: if you pull from that into your ubuntu branch, things may work out
[00:05] <Keybuk> lamont: and if they do, I'll use that to push any further uploads
[00:05] <Keybuk> lamont: (until sabdfl notices, and makes you use bzr like a sane person <g>)
[00:06] <ion_> :-P
[00:07] <Keybuk> seriously, two hours to get a branch pushed
[00:07] <Keybuk> the next time someone tells me that git is easy to use, I'm going to bypass subtlety and go straight for the chainsaw to the face
[00:12] <ion_> Git is easy to use.
[00:12] <RAOF> FSVO easy.
[00:13] <Keybuk> ion_: you're only able to get away with that because you know we'll never meet :o)
[00:13] <ion_> Who knows. :-)
[00:19] <ogra> ion_, only for masochists though
[00:19] <cjwatson> Keybuk: every time I complain about git being hard to use, people tell me it got much easier in 1.5
[00:19] <cjwatson> Keybuk: then I point out I'm already using >=1.5, and they sort of shrug
[00:19] <TheMuso> Git is hard to use if you are not used to its workflow.
[00:20] <Keybuk> no
[00:20] <Keybuk> Git is hard to use
[00:20] <TheMuso> I am warming to it a lot more recently, since I've had to get used to its workflow.
[00:20] <cjwatson> ah, now that's code for "git fails to adapt to my workflow"
[00:20] <TheMuso> Whatever... I am at the point where I feel reasonably comfortable with it.
[00:20] <Keybuk> TheMuso: ok, you have a branch in your working directory
[00:20] <Keybuk> you've committed some patches to it
[00:21] <Keybuk> how do you make that public?
[00:21] <Keybuk> in 1,000 words or less, please
[00:21] <TheMuso> Keybuk: Depends on how many patches. If a lot, it may be worth creating a git branch on a host, and pushing to that via ssh.
[00:21] <TheMuso> Otherwise, use git format-patch to create mailable patches.
[00:22] <ion_> Do a couple of clicks at github and paste the command it gives to your terminal. :-P
[00:22] <TheMuso> ...this is assuming I am actually understanding what you are asking.
[00:22] <Keybuk> since git can't even process MIME, let's ignore the e-mail option
[00:22] <Keybuk> I want to publish a branch
[00:22] <cjwatson> TheMuso: he's asking for the direct equivalent of 'bzr push sftp://host/path/to/published/directory'
[00:23] <Keybuk> I know what it is now
[00:23] <Keybuk>   ssh host
[00:23] <Keybuk>   cd /path/to/published
[00:23] <Keybuk>   GIT_DIR=directory git init
[00:23] <Keybuk>   chmod +x directory/hooks/post-update
[00:23] <Keybuk>   ^D
[00:23] <Keybuk>   git remote add ssh://host/path/to/published/directory
[00:23] <TheMuso> Keybuk: I've never created a git branch on a host from scratch, so haven't had to go through those steps yet.
[00:23] <Keybuk> err
[00:23] <Keybuk>   git remote add wibble ssh://host/path/to/published/directory
[00:23] <Keybuk>   git push wibble mybranch
[00:23] <Keybuk>   ssh host
[00:24] <Keybuk>   cd /path/to/published/directory
[00:24]  * RAOF 's brain collapses.
[00:24] <TheMuso> Ok so you are saying bzr just does it, interesting. Again, I have never had to do that with git.
[00:24] <TheMuso> So can't comment.
[00:24] <Keybuk>   rm -f refs/HEAD
[00:24] <Keybuk> err
[00:24] <Keybuk>   rm -f HEAD
[00:25] <Keybuk>   ln -s refs/heads/mybranch HEAD
[00:25] <Keybuk>   git update-server-info
[00:25] <Keybuk>   ^D
[00:26] <doko> ubuntu-archive: some distraction: please accept python3-stdlib-extensions and python3-profiler in source NEW
[00:27] <ogra> doko, you are breaking the rant for an actual work request ... damn you :)
[00:27]  * ogra was actually pointed to the git gui tools today since you would understand the cmdline tools way easier through that :)
[00:39] <cjwatson> TheMuso: do you have any idea why the ia64 kernel seems to have suddenly bloated up from 5.something MB to 16 MB?
[00:39] <cjwatson> TheMuso: it made d-i fail to build; I can probably work around it but it seems perhaps accidental?
[00:41] <TheMuso> cjwatson: Probably a configure option that got enabled when it shouldn't have been, I'll have a dig tonight and see what I can find, and fix it along with other changes I need to make in another upload in the next day or so.
[00:45] <cjwatson> TheMuso: thanks
[00:52] <Keybuk> http://www.netsplit.com/2009/02/17/git-sucks/
[00:52] <Keybuk> I feel better
[00:58] <calc> Keybuk: yuck
[00:58] <calc> Keybuk: i'm glad i don't use git :)
[01:00] <TheMuso> Keybuk: Ok, I feel your pain now.
[01:03] <Rocket2DMn> cjwatson, hi.  I see that you are in charge of the Installer Team, do you have good contact with the Wubi guys?
[01:03] <Keybuk> Rocket2DMn: we keep at least one of them tied up in the basement at all times
[01:03] <Rocket2DMn> cjwatson, I wanted to let you know that the link to the Ubuntu Forums from the wubi homepage is no longer good, that forum area was removed this evening - is that something you can pass along to them?
[01:04] <Rocket2DMn> Keybuk, probaby a good place :)
[01:05] <cjwatson> Rocket2DMn: I talk to them every now and again, but it would be better to mail Agostino directly: https://launchpad.net/~ago has his address
[01:05] <Rocket2DMn> ok, i'll do that, thanks cjwatson
[01:30] <Mavericks> hello everyone anyone applied for a job @ canonical - If this is the wrong place to ask, I apologize beforehand - I am little desperate, and any help will be appreicated
[01:33] <cjwatson> Mavericks: this really isn't the right place, although I'm not sure what would be. What is the problem?
[01:34] <Mavericks> I wanted to find out if anyone around here (any developer) had a chance to apply for jobs @ cannoical, and would like some feedback
[01:35] <Mavericks> as i did apply, and am given 21 day grace time for their decision
[01:35] <Mavericks> I am actually a student, and that makes it all the more complicated
[01:40] <cjwatson> I'm not sure what you're looking for feedback about, is the thing ...?
[01:40] <cjwatson> if you applied, you ought to get feedback in the usual way for job applications
[01:40] <Mavericks> ok
[01:41] <Mavericks> well, so far no correspondence, and i have four days left until end of 21 day grace time - i think it is too late, and i am also guessing that the recession might have had an impact
[01:41] <cjwatson> beyond that I'm not really sure what you're asking other applicants for :-)
[01:42] <Mavericks> feedback regarding general procedures, what kind of applicants are their first preference, and sort of suggestions/tips on passing that first round interview phase
[01:43] <cjwatson> if you're concerned about progress, you should probably send a nag mail to the HR people
[01:43] <Mavericks> people who had applied before,  or had some experience with canonical would know a bit and i thought would be able to help prospective applicants
[01:43] <cjwatson> www.ubuntu.com/employment is pretty clear about what kinds of applicants generally get first preference: "Please note that in general preference will be given to existing community contributors"
[01:44] <cjwatson> though obviously that's not always going to be overriding if somebody else really good comes along
[01:45] <Mavericks> yeah i have seen that, but some sort of correspondence would be nice. i guess with the huge volume of job apps. , it is really tough
[01:45] <Mavericks> sigh
[01:46] <cjwatson> I don't have an insight into the current volume of applications; I imagine it will depend somewhat on the hiring manager for the particular post being advertised
[01:48] <Mavericks> yeah , makes sense
[01:49] <lamont> Keybuk: heh.  thanks
[01:52] <ember> cjwatson when you have time can you look at http://bugzilla.gnome.org/show_bug.cgi?id=556114
[01:53] <cjwatson> ember: yes, it's on my enormous to-do list
[01:53] <cjwatson> (already)
[01:53] <ember> heh just a reminder, i was checking the merge for 0.4.1 and i saw that
[01:54] <cjwatson> I will deal with gparted >= 0.4.2 by feature freeze, at least
[01:54] <cjwatson> or intend to at any rate
[01:55] <cjwatson> however, there are other things ahead of it in my list
[01:59] <Mavericks> cjwatson: have you come across students who work for canonical by chance?
[02:00] <Mavericks> i mean in the IRC ,, or if you happened to meet before any of such student developers
[02:07] <cjwatson> Mavericks: it happens from time to time, sure
[02:09] <Mavericks> ok. "it happens from time to time,sure" helps a LOT
[02:10] <ScottK> Mavericks: You are really off topic for this channel.
[02:14] <Mavericks> cjwatson: my emphasis was on the assurance i got from that statement, and wanted to express that using caps on LOT
[02:15] <Mavericks> thank you ScottK and persia for the responses
[02:15] <Mavericks> i didn't intend to flood the IRC with these questions, and as I was talking to cjwatson, I tried to locate the HR for ubuntu
[02:18] <ScottK> Mavericks: Ubuntu doesn't have HR. It is a free software project.
[02:18] <Mavericks> Oops, my bad. I mean't to say HR for Canonical.
[02:19] <ScottK> Right, which gets back to this being totally the wrong place.
[02:21] <cr3> where's the wiki page providing a sample bug format for requesting sponsorship?
[02:21] <ScottK> There isn't a set form.  Just subscribe ubuntu-main-sponsors or ubuntu-universe-sponsors to the bug.
[02:36] <ovnicraft> hi, when i clone displayconfig-gtk from launchpad give the pkg for ubuntu, how i can get the src?
[02:37] <jdong> Keybuk: You've made my day. Someone else who feels Git is ridiculously unintuitive to the uninitiated...
[05:36] <spenser> Hi can anyone enlighten me on how to setup a branch of the linux kernel on a personal git server that keeps up to date with the latest mainline?
[06:08] <dholbach> good morning
[06:10] <ion_> morniŋ
[06:12] <dholbach> hiya ion_
[06:12] <ion_> Hi
[07:25] <pitti> Good morning
[07:30] <directhex> morning pitti
[07:30] <ion_> morniŋ
[07:43] <gimpuzmani_> hi
[07:58] <PecisDarbs> pitti: good morning, just for info sake, I did a updated patch for #298424, few things ironing out
[07:58] <pitti> PecisDarbs: I saw
[07:59] <PecisDarbs> I could do a patch for jockey, but I didn't know if you allow to use subprocess there :)
[07:59] <pitti> PecisDarbs: sure, I use subprocess all the time
[08:00] <PecisDarbs> ok, then I will do it for jockey too
[08:00] <pitti> cool
[08:12] <primes2h> pitti: Hi, what about jockey icons that come up in emblems? Are you planning to remove them in time for Jaunty?
[08:14] <pitti> primes2h: hm, that should already be fixed...
[08:14] <pitti> jockey (0.5~beta3-0ubuntu11) jaunty; urgency=low
[08:14] <pitti>     - Move status icons from emblems/ to actions/, emblems/ are wrong.
[08:17] <primes2h> pitti: I have jockey (0.5~beta3-0ubuntu13) but jockey icons are still in nautilus->Edit->Backgrounds and emblems->emblems
[08:18] <pitti> primes2h: hm, indeed; can you please file a bug and assign it to me? looks like a packaging bug
[08:19] <primes2h> pitti: ok.
[08:19] <dholbach> good morning, seb128! didrocks told me what you guys found out about the sponsoring script - I fixed it - thanks a bunch
[08:20] <seb128> dholbach: hello, thank you!
[08:20] <seb128> dholbach: I'm guessing that was bugs with no comments triggering the issue but was not sure
[08:21] <dholbach> seb128: that was exactly it
[08:21] <dholbach> seb128: in those cases I now display the bug reporter
[08:23] <seb128> dholbach: ok good
[08:30] <primes2h> pitti: done, bug #330421. There is also another place where jockey icons are present. see bug report.
[08:37] <primes2h> pitti: thanks
[08:39] <IntuitiveNipple> Q: Should a package install using update-alternatives fail when the install scripts use the update-alternatives --quiet option? I've got a user with failed installs of gij-4.2 and apt is 'stuck'
[08:41] <IntuitiveNipple> update-alternatives man-page claims --quiet isn't yet implemented
[08:45] <mok0> I would appreciate a "soonish" ACK of jeuclid in the NEW queue, since we have a dependent waiting for it (scilab)
[09:11] <lool> pitti: Hey, the glibc in the archive has a "rm -f $(CURDIR)/po/*.mo" which the one in bzr doesn't seem to have
[09:11] <pitti> lool: hm, very weird; I built it from the bzr tree..
[09:12] <lool> is ~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package the good branch?
[09:13] <lool> pitti: Oddly, this rm is present twice in the archive
[09:13] <lool> >-------rm -f $(CURDIR)/po/*.mo
[09:13] <lool> >-------rm -f po/*.mo
[09:13] <lool> in clean::
[09:14] <pitti> lool: I branched from that and pushed mine separately; I asked doko to pull mine into that
[09:14] <pitti> lool: however, I didn't touch any po/mo stuff, so it shouldn't differ
[09:15] <lool> pitti: It might be that I'm not looking at the right branch, I don't see your commits
[09:16] <pitti> lool: https://code.edge.launchpad.net/~pitti/ubuntu-toolchain/glibc-locales-debmerge is mine
[09:16] <pitti> lool: oh, hang on, I also merged with Debian, which might have pulled in that fix
[09:16] <pitti> lool: I just can't push to ~ubuntu-toolchain, which is why I had to do it like that
[09:16] <pitti> someone in ~ubuntu-toolchain please pull my branch
[09:19] <lool> pitti: I see your changelog entries, but not commits; I guess doko did the merge himself
[09:20] <doko> didn't merge yet ... will do
[09:20] <lool> doko: pitti's changelog entries are in the tree though
[09:20] <lool> Hmm perhaps I added them
[09:21] <lool> Grmpf, I'll have to revert my commits to drop them now
[09:21] <pitti> lool: bzr-rebase FTW :)
[09:22] <lool> pitti: I'll try, but last time I used it, I was really disappointed
[09:22] <lool> I ended up bzr uncommitting and bzr stashing a bunch of times
[09:24] <lool> Now because I needed the tarball I worked from both an apt-get source tree and the bzr tree to offer my changes for merging; as a result I mixed pitti's changes in the archive with mine when I committede to bzr
[09:24] <lool> pitti: How did you build glibc directly from the bzr tree?  ln -s . debian and bzr bd?
[09:31] <pitti> lool: tar xzf ../glibc_*orig.tar.gz --strip-components=1 and then just debuild -S /debuild -us -uc -b
[09:32] <pitti> I should learn bzr-builddeb some day..
[09:33] <lool> pitti: But the glib branch doesn't have a debian dir
[09:33] <pitti> lool: no, that *is* the debian dir
[09:34] <pitti> bzr get lp:.... debian
[09:34] <lool> Ok; I usually keep the branch name as dir
[09:34] <pitti> yeah, I don't do it like that either, it also breaks debcommit, etc.
[09:35] <lool> Yes, ln -s . debian helps for dch/debcommit
[09:35] <lool> I guess it's historical due to the vcs-import
[09:36] <doko> now merged
[09:42] <lool> wow bzr rebase worked like a charm here, excellent
[09:43] <asac> anyone knows what the group "dip" stands for?
[09:43] <asac> like Bug 292203
[09:46] <asac> Keybuk: when replugging USB modems duplicates the hal entry is that a udev issue?
[09:48] <petski> asac, seems to be "Dial-Up IP"
[09:51] <asac> hmm wiki.ubuntu.com down, anyone?
[09:51] <seb128> asac: no
[09:52] <asac> hmm ... seems my dns has problems
[09:52]  * asac reconnects
[09:57] <sistpoty|work> seb128: would you be willing to act as motu-release delegate for ubuntu-desktop for jaunty?
[09:58] <lool> Hmm is it on purpose that the bootchart update recreates all my initramfses, not just the current one?
[09:58] <seb128> sistpoty|work: which means grant desktopish freeze exception right?
[09:58] <sistpoty|work> seb128: yep
[09:58] <pitti> lool: I think so, yes
[09:58] <seb128> sistpoty|work: yes
[09:58] <sistpoty|work> seb128: excellent, thanks!
[09:58] <seb128> you're welcome
[09:58] <directhex> hm, i need to read up on appropriate bribes for seb128
[09:58] <seb128> ;-)
[09:59] <directhex> how do you feel about cake?
[09:59] <seb128> what I like is people helping on desktop updates ;-)
[10:01] <lool> pitti: Ok; any reason for bootchart to be specific in this respect?
[10:01] <pitti> lool: I don't think it's special at all; other packages like cryptsetup or lrm regenerate all as well, AFAIR
[10:01] <seb128> lool: why should it be limited to the current one?
[10:01] <pitti> lool: also, you might want to compare speed with different kernels, etc.
[10:02] <seb128> lool: you want to be able to bootchart using any installed linux version no?
[10:02] <lool> Hmm I don't know
[10:03] <lool> I think we don't automatically change all initrds because we want to allow keeping safe working ones around
[10:03] <lool> At least I think that's the rationale behind e.g. udev only updating the current initrd
[10:03] <lool> even if I might want the latest udev and its fixes in all initrds, we don't update all because we want to keep the old ones working
[10:04] <seb128> ok, that makes sense too, better to let somebody who has a clue about a policy reply now ;-)
[10:04] <lool> The thing is I can understand either of bootchart or udev's behaviors, but not mixing the two in the archive
[10:05] <seb128> do we have a policy about that?
[10:06] <lool> seb128: I think you have a point that this should be in policy, I agree
[10:08] <PecisDarbs> pitti: attached patch for jockey for sl_modem.py to #295158, check it out if that's ok
[10:08] <pitti> PecisDarbs: thanks a lot! won't have time for that today, but that can wait well until after FF anyway
[10:08] <PecisDarbs> pitti: will it make it into Jaunty? :)
[10:09] <pitti> PecisDarbs: sure
[10:09] <directhex> FF is for upstream versions, not package versions, right?
[10:09] <PecisDarbs> that's all I need to know, thanks :)
[10:09] <pitti> directhex: no, for features
[10:09] <lool> seb128: I filed #330455
[10:09] <lool> But I guess I should rather be bringing this up on ubuntu-devel
[10:09] <seb128> bug #330455
[10:09] <pitti> directhex: bug fix only upstream versions are okay
[10:09] <seb128> right, I was going to suggest that
[10:09] <seb128> lists are better for such discussions
[10:10] <directhex> pitti, okay, gotcha. that gives me, hrm, 2 days to get monodevelop 2 beta in. and gnome-subtitles 0.8 (which dep-waits on something in NEW)
[10:43] <apw> pitti, guess what ... i have some more changes for apport, same branch.  the first two changes on there seem pretty obvious, the last needs some review as it needs to run some of the hooks earlier and there is possibly a better way to do that
[10:44] <pitti> apw: ah, great; can you please mail me? I'm terribly busy today
[10:48] <Laney> are REJECT/ACCEPT mails sent to any publicly accessible place?
[10:49] <sistpoty|work> any archive admin around, who'd know why sabnzdplus was rejected? (the reject mail contained no hint)
[10:50] <pitti> sistpoty|work: ScottK rejected it, and wanted to send out one
[10:50] <Laney> sistpoty|work: It has been reuploaded to NEW anyway
[10:51] <sistpoty|work> pitti: ah, I see, thanks
[10:51] <sistpoty|work> Laney: ah, then I guess it was on request from the packager
[10:51] <pitti> ScottK: please CC: ubuntu-archive@ for reject mails
[10:51] <sistpoty|work> Laney: as I told the packager to check with ubuntu-archive in regards for the .js thingies in there
[10:52] <Laney> sistpoty|work: Actually I think I remember some talk in -motu yesterday
[10:52] <Laney> maybe check the irclogs
[10:52] <sistpoty|work> Laney: good idea, thanks
[11:12] <asac> StevenK: yt?
[11:13] <StevenK> asac: Hum?
[11:14] <asac> StevenK: i wanted to push connman and wonder if you would be available for a quick archive round ;)
[11:14] <asac> since its mobile you seem to be a perfect match ;)
[11:32] <ScottK> pitti: I did cc ubuntu-archive, but it was moderated.
[11:32] <ScottK> sistpoty|work: I sent mail to the address in your GPG key.
[11:34] <ScottK> sistpoty|work: Also (archive hat off/motu hat on) I reviewed an update and re-uploaded it last night.
[11:36]  * StevenK grins at ScottK's last line
[11:37] <directhex> which hat is easier to bribe?
[11:40] <Keybuk> asac: no, almost certainly not
[11:40] <Keybuk> it could be a kernel issue
[11:40] <Keybuk> but I expect it's a HAL isue
[11:44] <asac> Keybuk: could i check by restarting hal?
[11:44] <asac> i assume so ;)
[11:45] <Keybuk> yes
[11:45] <Keybuk> the reason it's unlikely to be a udev issue is that udev actually doesn't keep any kind of in-memory database or list of devices
[11:50]  * ogra points lool to bug 231960 ... there is that scott guy who seems to be able to point you to a policy
[11:51] <cjwatson> ScottK: I've adjusted the moderation settings so that your mails should be auto-accepted in future
[11:53] <Keybuk> ogra: and I fixed that bug afterwards ;)  what's your point?
[11:53] <ogra> Keybuk, that lool just filed bug 330455
[11:54] <cjwatson> Keybuk: it's unusual for packages to regenerate *all* initramfses, and has the practical problem that you can be left without any working backup initramfs
[11:54] <cjwatson> everything else just regenerates the current one for this reason
[11:54] <Keybuk> I agree
[11:54] <Keybuk> but I got bored of people nagging at me every other week because bootchart only regenerated the current one
[11:54] <Keybuk> (or only regenerated the -generic one, not the -server one, etc.)
[11:54] <cjwatson> the -generic/-server bit was unfortunate, I agree
[11:55] <ogra> Keybuk, you say "its ubuntu policy" in my bug so i thought i should point lool to the person which knows where its written down ;)
[11:55] <Keybuk> since people install bootchart for doing tests, I figured they are likely to be trying to compare different kernels
[11:55] <cjwatson> perhaps we should have an update-initramfs to regenerate all kernels of the current ABI?
[11:55] <Keybuk> ogra: like most ubuntu policy, it's written down in someone's head ;)
[11:55] <cjwatson> s/to /option to /
[11:55] <ogra> haha
[11:55] <Keybuk> cjwatson: then you couldn't compare two kernel ABIs with bootchart, etc.
[11:55] <cjwatson> yeah, it's not an entirely obvious case
[11:55] <cjwatson> I do agree that it should be documented for all other cases
[12:10] <ogra> cjwatson, so by the looks of it, yesterdays d-i build doesnt have the slug firmware :(
[12:10] <sistpoty|work> ScottK: ah, thanks... (/me admits to not having checked that adress for two weeks or so *g*)
[12:11] <ogra> (20081029ubuntu18 is what i tested)
[12:11] <cjwatson> cjwatson@cocoplum:~/ubuntu/dists/jaunty/main/installer-armel/current/images/ixp4xx/netboot$ zcat initrd.gz | cpio -it | grep firmware/NPE
[12:11] <cjwatson> lib/firmware/NPE-C.02020201
[12:11] <cjwatson> is that not correct?
[12:11] <cjwatson> lib/firmware/NPE-B.01020201
[12:11] <ogra> weird
[12:12] <ogra> ~ # ls /lib/firmware/
[12:12] <ogra> ~ #
[12:12] <cjwatson> slug is ixp4xx, yes?
[12:12] <ogra> yep
[12:12] <cjwatson> you're absolutely sure you're booting the current image?
[12:13] <ogra> yes, the former ones didnt boot
[12:13] <cjwatson> I'd be double-checking if I were you, since there should be a number of other files in /lib/firmware/ too
[12:13]  * ogra agrhs
[12:14] <ogra> sorry, i downloaded the right one but used the upslug command from my bash history (which indeed dumped di-nslu2-test.bin and not di-nslu2.bin into the flash)
[12:14]  * ogra slaps head and starts over
[12:16] <ogra> pitti, evolution-indicator supposed to replace my mail notification plugin automatically ?
[12:17]  * ogra starts getting annoyed having his desktop cluttered with 100s of little notification windows
[12:17] <pitti> ogra: no, I don't think so
[12:17] <pitti> ogra: I don't know how the transition will be done yet, I'll ask the DX team
[12:17] <ogra> ah, k but its the same function then at least
[12:24] <amitk> ogra: what ppa is this notification work available in?
[12:26] <ogra> cjwatson, looks better :)
[12:26] <ogra> amitk, see other chan
[12:27] <cjwatson> ogra: oh good
[12:27]  * ogra wishes he had ifconfig in d-i ...
[12:28] <cjwatson> you have ip
[12:28] <liw> mvo, ping
[12:29] <mvo> liw: pong
[12:29] <ogra> oh, right, i always forget out it :)
[12:29] <ogra> *about
[12:30] <seb128> dholbach, mdz: you had the ssh agent issue right? can you tell me if yesterday's upgrade fix the bug for you?
[12:30] <liw> mvo, I've just pushed the new-plugins branch again, it has plugins for nfs-common, kdeblibs5-dev, and language packs; I did not write one for fglrx, since that needs a UI and we need to discuss how to deal with that
[12:31] <mvo> liw: ok, thanks. I will check it out.
[12:31] <mvo> liw: I will probably have to modify the scd0 one a bit, but otherwise the previous push looks good
[12:31] <Riddell> liw: new plugins?  kdelibs?  what's all this?
[12:32] <liw> mvo, I can imagine there being a lot of bugs, but I didn't want to write tests, since these things seem best tested with your existing distupgrade tests
[12:32] <liw> Riddell, we're integrating update-manager and computer-janitor code bases
[12:33] <mvo> liw: I'm finishing some work that the DX team requested now, then I'm all yours
[12:33] <liw> Riddell, i.e., just refactoring how upgrades and related tweaks work, no functionality changes anywhere
[12:33] <liw> mvo, ack
[12:38] <bigon> hi
[12:39] <bigon> does anybody know which program network manager uses to get the dhcp lease?
[12:41] <mdz> seb128: I'm in the office today but will upgrade my home system tomorrow
[12:41] <mdz> bigon: dhclient
[12:41] <lool> cjwatson, Keybuk: what about allowing a list of kernels to update-initramfs for?  much like we have menu.lst per-kernel kopts: we could include all 2.6 or all 2.6.28 or specific flavours etc.
[12:41] <seb128> mdz: ok, let me know next time you try then!
[12:41] <Keybuk> lool: that sounds over-complicated
[12:42] <lool> Keybuk: Would it be good enough to only update-initramfs on all kernels on the initial install and not on upgrades of bootchart?
[12:42] <bigon> mdz: I was asking because it seems that some post-exec scripts of dhclient are not executed
[12:42] <lool> Keybuk: What's complicated in a list of kernels for which you care to always update the initramfs?
[12:42] <lool> The default would be current behavior and people can change it to all if they dare
[12:43] <dholbach> seb128: fixed here
[12:43] <seb128> dholbach: danke!
[12:43] <Keybuk> lool: it sounds like a very random "configuration option to solve the problem" solution
[12:43] <lool> Keybuk: it would solve user complaints while allowing us to default on what's sane?
[12:44] <lool> Keybuk: You changed upstart to silence the complaints but increasing the risk of breakage
[12:44] <Keybuk> lool: what are the complaints?
[12:44] <lool> s/upstart/bootchart  :-)
[12:44] <lool> Keybuk: 12:54 < Keybuk> but I got bored of people nagging at me every other week
[12:45] <Keybuk> no, I mean, what are the current user complaints?
[12:45] <lool> Keybuk: My complaint is that this puts my systems at risk
[12:45] <Keybuk> of what?
[12:45] <lool> Of a bootchart upgrade updating all my initrds and breaking all of them
[12:45] <Keybuk> can you forsee a breakage?
[12:46] <lool> I keep older kernels because I want to try them out with current ubuntu or because I want to recover with them
[12:46] <Keybuk> what kind of breakage are you expecting?
[12:46] <lool> For instance the recent udev breakage with the md devices
[12:46] <pitti> there's still an initrd.bak, isn't there?
[12:46] <Keybuk> you'll be broken by that anyway
[12:46] <Keybuk> if the currently installed udev doesn't work with the older kernel
[12:46] <Keybuk> it won't work with the older kernel
[12:46] <lool> Would I have received a bootchart update along the new udev, I wouldn't have been able to boot my system easily anymore
[12:46] <Keybuk> getting out of the initramfs just means it won't fail so quickly
[12:47] <mdz> bigon: I believe it supplies its own dhclient-script
[12:47] <lool> Keybuk: The fact is I could boot with the older initrd
[12:47] <lool> pitti: Don't think so
[12:47] <bigon> mdz: it's quite annoying
[12:47] <cjwatson> mvo: do you think I could drop aptitude's recommendation of libparse-debianchangelog-perl to a Suggests?
[12:47] <Keybuk> lool: why did you install bootchart, out of interest?
[12:47] <Keybuk> installing bootchart would have instantly broken your current running kernel
[12:48] <lool> Uh?
[12:48] <Keybuk> so you would have had to have had a fallback kernel there anyway
[12:48] <lool> I had bootchart installed already when that happened
[12:48] <cjwatson> mvo: I want to make tasksel have the option to run aptitude in the installer; recommending libparse-debianchangelog-perl pulls quite a lot of stuff into the debootstrapped set
[12:48] <Keybuk> any particular reason?
[12:48] <lool> I just bootchart every boot and I take a look from time to time
[12:49] <mdz> bigon: it may be that NM's script needs to be fixed to invoke the same hooks as the default one
[12:49] <mvo> cjwatson: I need to check what it is used for to be certain but for now I would say it is fine
[12:49] <cjwatson> mvo: changelog parsing is not particularly useful in the installer, but it does mean that people would need to install libparse-debianchangelog-perl in order to get changelog parsing after boot; this seems like a fairly reasonable tradeoff
[12:49] <mvo> cjwatson: agreed
[12:49] <cjwatson> it's used for the "view changelog" option - it parses the changelog and displays it in some more digested way
[12:50] <cjwatson> all right, I'll do that then
[12:50] <lool> Keybuk: So what do you propose to stop updating all initramfs-es each time bootchart is updated?
[12:50] <cjwatson> my installer change is still a little ropey - for some reason only packages that are actually to be installed are showing up in aptitude
[12:50] <Keybuk> lool: I don't see a problem with updating them all
[12:51] <soren> Keybuk: I do.
[12:51] <soren> Keybuk: I might have some rather old kernels that don't work very well with a newly generated initramfs.
[12:51] <lool> I see that as an issue, I think cjwatson understands the issue as well (I don't know whether he cares), pitti also mentionned initrd backups (I don't know whether he cares)
[12:52] <Keybuk> soren: then they won't work very well with the userland either
[12:52] <cjwatson> mvo: hmm, alternatively I could say that it doesn't really matter much if we pull those packages into debootstrap since they're already in standard
[12:52] <cjwatson> they won't be in Priority: required so there'll still be a smaller set available
[12:52] <cjwatson> maybe I'll try pulling them in and see who complains
[12:53] <soren> Keybuk: That sounds reasonable.. :)
[12:53] <Keybuk> "updating initramfs is bad because the new udev might not work with the older kernel"
[12:53] <Keybuk> if the new udev doesn't work with the older kernel, you're not going to have a /dev after you boot
[12:53] <Keybuk> so you're pretty doomed anyway
[12:53] <Keybuk> we run mdadm and lvm from udev these days
[12:53] <Keybuk> so you're still doomed
[12:54] <lool> I just gave an example of an udev upgrade where the old initrd allowed me to boot and not the new one
[12:54] <mvo> cjwatson: how much additional space it will cost? if its not too bad that should be fine I guess
[12:54] <lool> I goot at least start up my system with networking and downgrade udev
[12:54] <lool> *could
[12:54] <cjwatson> it's additional space we're using in the default system anyway - it only makes a difference for minimal debootstrapped systems
[12:55] <asac> StevenK: can you look at connman(-gnome) NEW please?
[12:57] <cjwatson> mvo: it's a couple of hundred KB until you add the HTML and XML output backends
[12:57] <cjwatson> mvo: maybe the right answer is actually to downgrade the HTML and XML bits of libparse-debianchangelog-perl to Suggests
[12:57] <cjwatson> aptitude only uses rfc822 output
[12:58] <ogra> grmbl, so d-i expects a link to the slug firmware to be in place in /lib/firmware ...
[12:58] <mvo> cjwatson: that sounds good to me
[12:59]  * ogra sighs ... why cant it be easy
[13:03] <ScottK> cjwatson: Thanks (for whitelisting me on ubuntu-archive).
[13:18] <bigon> mdz: I will open a bug for that
[13:44] <dratone> Hello everyone
[13:47] <dratone> Hi
[13:50] <cros13> evening all
[13:51] <cros13> I got a really weird issue
[13:51] <cros13> with jaunty
[13:52] <cros13> my boot time doubled after running an update this morning
[13:54] <cros13> bootchart shows a pile of dmraid-activate instances
[14:01] <dratone> I was wondering, I want to become active in ubuntu development, but the information page left me with a few questions. Is there someone here who could give me some more information regarding becoming active in the development?
[14:02] <cody-somerville> dratone, certainly!
[14:02] <cody-somerville> What page did you read exactly?
[14:02] <cody-somerville> There are a few.
[14:02] <dratone> cody-somerville: I read https://wiki.ubuntu.com/UbuntuDevelopers
[14:04] <cody-somerville> dratone, Okay, great. Thats one of the more comprehensive pages.
[14:04] <dratone> But it didn't quite make clear to me how to actually 'get started'
[14:04] <cody-somerville> Ah
[14:04] <cody-somerville> We have the page for that! :)
[14:04] <dratone> I was hoping you might ;)
[14:04] <cody-somerville> https://wiki.ubuntu.com/MOTU/GettingStarted
[14:10] <cjwatson> dratone: in addition to what Cody said, UbuntuDevelopment is probably a better starting point than UbuntuDevelopers
[14:10] <cjwatson> UbuntuDevelopment is a page full of resources; UbuntuDevelopers is about the process for joining the development team (which you'd be doing once you're a little more familiar with the resources)
[14:12] <cody-somerville> Ah
[14:13] <cody-somerville> good catch
[14:13] <dratone> Ok, that does make things a bit clearer, thanks. I'll read up and get back in a little bit
[14:13] <dratone> thanks
[14:14] <cjwatson> I've edited UbuntuDevelopers to provide links to other pages up top
[14:26] <radix> Is it possible to pre-seed debuild with a set of packages so it doesn't need to download them (without using some kind of caching proxy)? I'm thinking of somehow preseeding /var/cache/apt with a bunch of packages
[14:27] <ogra> apt-get install -d <packagelist>
[14:27] <ogra> not sure debuild has an extra option for that
[14:27] <radix> ogra: I'm not sure what you mean
[14:27] <radix> okay
[14:28] <ogra> -d tells apt to download the packages but not install them
[14:28] <radix> yes I know about it
[14:28] <ogra> they end up in /var/cache/apt
[14:28] <radix> oh sorry, I was ambiguous
[14:29] <radix> hmm, maybe I'm confused
[14:29] <radix> I was assuming that debuild uses the /var/cache/apt that's in the chroot
[14:30] <radix> so I'd need to somehow get the packages into that one
[14:30] <radix> oops oops
[14:30] <cjwatson> radix: this doesn't match any debuild I'm used to. Are you perhaps talking about pdebuild?
[14:30] <radix> I've been saying "debuild" but I mean "debootstrap"
[14:30] <cjwatson> oh
[14:30]  * radix finishes his coffee
[14:30] <cjwatson> how about --make-tarball/--unpack-tarball?
[14:31] <radix> cjwatson: oh, great
[14:31] <radix> sorry, I don't know how I missed it
[14:31] <radix> thanks very much for dealing with my confusion, ogra and cjwatson: )
[14:31] <cjwatson> I don't think the tarball has to be complete; it unpacks it and then carries on with whatever else it was told to do
[14:31] <maxb> I use a simple wrapper around debootstrap that bindmounts my /var/cache/apt/archives into the new root, so that it shares my normal apt cache
[14:32] <radix> maxb: oh, interesting
[14:32]  * ogra knows a bunch of people doing that 
[14:32]  * maxb pastebinds
[14:32] <maxb> -d
[14:33] <ogra> i wonder why debootstrap never grew an option for it :)
[14:33] <maxb> http://paste.ubuntu.com/119222/
[14:33] <radix> maxb: thanks
[14:33] <maxb> Clearly I should tidy it up and turn it into a patch for debootstrap
[14:33] <maxb> one day :-)
[14:33] <radix> maxb: huh, I was thinking that wouldn't help me because my guest is a different distro, but... I could bind mount it to something like /var/cache/apt-hardy or something
[14:34] <radix> and that way my various guest chroots could use the same one
[14:34] <maxb> that's an option. Personally, my /var/cache/apt/archives is a pool of mixed intrepid and jaunty packages
[14:35] <radix> maxb: oh, interesting
[14:35] <maxb> I have another wrapper script so that when I run apt-get autoclean, I do it with an alternate sources.list that contains both distros
[14:37] <radix> I think I'll just use a separate cache directory :)
[14:38] <radix> anyway, as usual #ubuntu-devel is fantastically helpful :-)
[14:44] <ogra> gar
[14:44] <ogra> my self built d-i doesnt boot the slug ...
[14:45]  * ogra doesnt get what that is 
[14:55] <ogra> hmr
[14:55] <ogra> *hrm even
[14:56]  * ogra wonders wahatd different between the d-i in the archive and his ... nothing changed ...
[14:56] <ogra> *whats
[14:58] <ogra> ha ... silly ,me not building in a pbuilder ...
[14:58]  * ogra makes note to not forget to update the build-deps if doing so
[15:04] <dratone> Hi Again. I've read the pages but.. I'm still not sure on what to actually do :) I know most of the stuff (worked with some form of linux for about 9 years, Debian/Ubuntu and other debian based distro's for the past 7 so the stuff I'm pretty well aware of but I'm not sure on what i can actually do as a developer :) *I know, it sounds dumb*
[15:08] <fasix> hi
[15:08] <fasix> http://forum.ubuntu-it.org/index.php?topic=262207.0
[15:08] <fasix> hel me
[15:08] <fasix> help me
[15:09] <dratone> Ehmm, I think you need #ubuntu instead of #ubuntu-devel, though i could be mistaken.
[15:10] <Keybuk> http://news.bbc.co.uk/1/hi/technology/7894763.stm
[15:10] <Keybuk> "The world's biggest mobile phone makers and network operators have backed plans to create a universal phone recharger." ... "The micro-USB connector will be used as the common charging interface."
[15:10]  * Keybuk passes out
[15:11] <Keybuk> the world has gone sane
[15:12] <soren> Keybuk: It'll pass.
[15:12] <ogra> sigh .. and that now where you can get mini-USB power upplies everywhere, so i need an adapter now ?
[15:12] <ogra> *supplies
[15:13] <Keybuk> ?
[15:14] <ogra> well, i have about ten devices that come with mini usb power supply, charging through it ...
[15:14] <ogra> i wonder why they dont go with mini
[15:14] <Keybuk> because micro-usb is the current standard?
[15:14] <soren> ogra: It's a plot to annoy you.
[15:14] <ogra> soren, yeah, conspiracy against me all over the world ... i always knew it
[15:16] <Keybuk> ogra: are you sure you're not confusing the two?
[15:16] <ogra> yes
[15:16] <ogra> micro is about half as thick ... similar width and form
[15:17] <ogra> my n810 has a micro, the n800 has mini
[15:17] <Keybuk> right, that sounds about right
[15:17] <Keybuk> mini was obsoleted by micro
[15:17] <Keybuk> all newer devices use micro
[15:17] <ogra> and my (this week arriving) n85 will have micro
[15:18] <ogra> still, its annoying, they could simply keep a standard if it already quasi-established itself ...
[15:18] <Keybuk> the best bit about standards is there are so many to choose from ;)
[15:19] <ogra> yeah
[15:19] <Keybuk> you may as well claim they should have kept the old A/B type plus from the USB 1.0 days
[15:19] <ogra> well, thats at least still around
[15:19] <ogra> you can still buy new pronters using them
[15:19] <ogra> *printers
[15:20] <Keybuk> are you sure?
[15:20] <ogra> i think i saw one last week
[15:20] <Keybuk> I've only seen printers using the newer Type-B plug
[15:20] <Keybuk> which looks a bit like the old Type-B plug, but isn't _quite_ compatible ;)
[15:21] <ogra> ah well, i wont stop the world from moving forward i guess ...
[15:22] <ogra> its just such a waste of resources to invent a new standard every year just to sell new power supplies
[15:24] <Keybuk> micro came first
[15:25] <Keybuk> and that was simply because they needed a smaller connector for the increasingly smaller devices
[15:26] <ogra> are you sure ?
[15:26] <ogra> i actually saw my forst micro in the n810 ... my first mini is more than a year ago
[15:29] <Keybuk> according to Wikipedia ;
[15:30] <emgent> Keybuk: i love your post about GIT! :)
[15:33] <Keybuk> ogra: every device that uses Micro USB came with a cable that had a Type A on one end and a Micro-B on the other
[15:33] <Keybuk> every device that uses Mini USB came with a cable that had a Type A on one end and a Mini-B on the other
[15:34] <ogra> and most of the ones i have also came with a power supply
[15:34] <Keybuk> so if all new devices are going to have a Mini-B socket, they will assumedly come with a cable
[15:34] <ogra> to charge over mini
[15:34] <Keybuk> did the power supply have a hard-wired cable in it?
[15:34] <ogra> yes
[15:34] <Keybuk> how weird
[15:34] <Keybuk> I've not seen that
[15:34] <Keybuk> I've got a couple of USB power supplies now
[15:34] <ogra> i have about ten of them here
[15:34] <Keybuk> they're plug sockets with a USB Type A socket in the top
[15:34] <Keybuk> so you just plug the cable into them
[15:35] <ogra> from camera to GPS
[15:35] <ogra> some BT devices i have too
[15:35] <Keybuk> kooky
[15:35] <Keybuk> you can buy universal USB charger plugs in most good stores
[15:35] <Keybuk> they look a bit like a "Swiss travel adapter", but instead of having lots of holes in the top, they just have a USB socket
[15:36] <Keybuk> or just go to an Apple store in each country and get theirs, which are soooo dinky and cute
[15:36] <Keybuk> then you just need to take one plug, and one or two cables
[15:36] <Keybuk> instead of the suitcase full of chargers, adapters and bricks
[15:36] <ogra> well, i dont need to since i got tons for the hardwired ones :)
[15:38] <ogra> hrm
[15:39] <ogra> hw-detect in d-i force udev to disconnect network devices ?
[15:40] <ogra> cjwatson, so the 'console-setup-udeb -' fix works fine, i get d-i noninteractively running up to the ssh server and can connect just fine
[15:41] <ogra> cjwatson, though now it kills the connection on "Detecting disks and all other hardware" (i think thats hw-detect or some such)
[15:41] <ogra> i can re-login with ssh installer@192.168.1.77 and pw "install" (like it should be) ... but it respawns at exactly that point to drop me out again
[15:43] <ogra> argh !!!!
[15:43] <ogra> 0 pages swap cached
[15:43] <ogra> Out of memory: kill process 2488 (sshd) score 84 or a child
[15:43] <ogra> Killed process 6977 (sshd)
[15:43] <ogra> sigh
[15:43] <ogra> Keybuk, shrink udev !
[15:43] <Keybuk> err
[15:44] <ogra> i only have 30M
[15:44] <Keybuk> if your udev is running out of memory, and it's 137, you have some interesting problems
[15:44] <Keybuk> udev doesn't *use* much memory
[15:45] <Keybuk> [6291] udev_rules_new: temporary index used 17900 bytes (895 * 20 bytes)
[15:45] <ogra> ~ # cat /proc/meminfo
[15:45] <ogra> MemTotal:          28324 kB
[15:45]  * ogra cries
[15:45] <ogra> why does lenny work :/
[15:45] <Keybuk> [6291] udev_rules_new: rules use 46332 bytes tokens (3861 * 12 bytes), 12857 bytes buffer
[15:45] <Keybuk> I think that ~64 KB is small enough
[15:46] <ogra> hmm
[15:46]  * ogra shakes his fist towards oom-killer
[15:48] <directhex> ogra, ah, oom. let me tell you a story of oom. it involves £300,000 of useless computers
[15:48] <ogra> were they 133MHz/30M ARM systems ?
[15:48] <ogra> else i'm not so intrested
[15:49] <directhex> ogra, dual quadcore xeons. doesn't ubuntu sshd have oom_adj set to -17?
[15:49] <ogra> no idea about the settings in the installer udeb
[15:49] <jcastro> evand: I need to fill out the bug contact info for debian-installer, whom would you say handles the bugs for d-i more, you or cjwatson?
[15:50] <ogra> jcastro, isnt teher an installer team ?
[15:50] <ogra> *there
[15:50] <evand> jcastro:  cjwatson
[15:50] <jcastro> ogra: yeah but I try to nail it down to one person when I can
[15:50] <ogra> ah
[16:01] <calc> yipee my x200 just arrived
[16:01] <calc> its so much smaller than my old laptop
[16:02] <cjwatson> jcastro: what evand said - which contact info is this? I thought I'd filled it out in the obvious places
[16:03] <ogra> cjwatson, would i gain any ram if i excluded console-setup-fonts-udeb as well ?
[16:03] <jcastro> cjwatson: it's the bug supervisor info in lp: https://bugs.launchpad.net/debian-installer
[16:04] <cjwatson> ogra: I'd expect you'd get a bit; also the keymaps
[16:04] <jcastro> cjwatson: it's not obvious and most of them aren't filled out so I am hitting the top100 basically.
[16:04] <ogra> good
[16:04] <cjwatson> jcastro: why is it appropriate to set that to an Ubuntu contact?
[16:04] <cjwatson> I mean, as it happens, I'm an upstream developer too
[16:05] <cjwatson> but it seems to me that it's the job of the upstream project to fill that in if they're interested, and in the case of upstream d-i, bugs shouldn't be reported in LP at all ...?
[16:05] <jcastro> it's supposed to be who to contact in the ubuntu project who is looking at those bugs
[16:05] <cjwatson> that makes no sense
[16:06] <cjwatson> the bug supervisor on a project should be somebody upstreamish, surely
[16:06] <jcastro> it can be, if that project is interested
[16:06] <cjwatson> and if they aren't, we should mark the project as not using LP for bugs
[16:06] <jcastro> from what I've seen so far it's the person who is weeding through the bugs and reporting those upstream
[16:06] <cjwatson> the only bug on upstream d-i right now does not belong there
[16:06] <cjwatson> it should be filed on the appropriate Debian package instead
[16:07] <ScottK> jcastro: I agree with cjwatson.  That's the upstream project, not Ubuntu.
[16:07] <jcastro> it lists the debian bug tracker as the upstream tracker
[16:07] <jcastro> so you're saying when the project has an upstream bug tracker that that field shouldn't exist?
[16:07] <ScottK> It definitely shouldn't have Ubuntu specific information in it.
[16:07] <cjwatson> what ScottK said
[16:08] <cjwatson> we already have a space for the Ubuntu contact; it's the bug contacts for the package
[16:08] <cjwatson> (possibly filtered, given that there can be multiple contacts)
[16:08] <cjwatson> there's no need to abuse the upstream bug supervisor field for that
[16:09] <jcastro> ok I am having a hard time finding the ubuntu bug contact
[16:09] <ScottK> Honestly I think the entire concept of upstream projects for projects that don't use Launchpad is pretty broken.
[16:09] <cjwatson> it's useful for d-i because the upstream code import lives there
[16:09] <cjwatson> and in general upstream projects in LP are a hook for such things
[16:10] <ScottK> It's not at all clear to a casual observer that these are not the actual project home.
[16:11] <ScottK> ... but that's kind of OT, so nevermind
[16:11] <cjwatson> jcastro: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+subscribe lists the bug contacts (in a slightly obscure way); you could intersect that with people who actually do useful work
[16:11] <cjwatson> expand out teams and intersect with ubuntu-dev, or something
[16:12] <jcastro> ok I think there is a disconnect with what you guys think that first field is for, and what the lp people think that field is for.
[16:12] <cjwatson> jcastro: in this specific case I'm happy to be the upstream contact, BTW - I just think it's fairly meaningless
[16:12] <cjwatson> I'm astonished that the LP people think that the upstream bug supervisor should be filled with an Ubuntu contact address; that violates everything I know about the LP data model
[16:13] <cjwatson> Ubuntu != upstream is built right into lots of assumptions in Launchpad, even when it's actually slightly inconvenient (native packages)
[16:15]  * pitti sighs at python-kde4-dev pulling in half of KDE; I clearly need phonon-backend-xine to build a python KDE package :/
[16:19] <Riddell> pitti: seems reasonable to me, python-kde4 includes phonon bindings
[16:19] <seb128> pitti: did you try not installing recommends?
[16:19] <pitti> seb128: yes
[16:19] <seb128> ok, seems that's not it then ;-)
[16:19] <pitti> Riddell: yeah, I guess so :) (nevermind)
[16:27] <greg-g> seb128: can I ask you to clarify this sentence: "COPYING states it's GPL where the copyright lists
[16:27] <greg-g> LGPL as license
[16:27] <greg-g> " from https://lists.ubuntu.com/archives/ubuntu-archive/2009-February/024963.html (sorry about the line break)
[16:27] <seb128> greg-g: what is not clear
[16:27] <seb128> ?
[16:27] <greg-g> where does it say LGPL?
[16:27] <seb128> greg-g: the copyright file in the debian directory?
[16:28] <greg-g> ohhhh, sorry, I'm upstream, I haven't messed with the packaging, they just sent me that email
[16:28] <seb128> greg-g: whoever did the packaging wrote in the debian directory that the source is under LGPL which is wrong
[16:28] <seb128> greg-g: let the package know that the issue is a packaging one
[16:29] <greg-g> seb128: doing so now, thanks for the clarification.
[16:29] <seb128> you're welcome
[16:31] <LaserJock> Main packages don't have to have Suggests in Main do they?
[16:32] <ScottK> LaserJock: No.  Recommends, yes, but not Suggests.
[16:33] <LaserJock> right, just making sure ;-)
[16:34]  * Laney cuddles whoever is AAing today
[16:35] <soren> Can someone explain why Aspectj is in multiverse?
[16:49] <pitti> soren: if it's free software, then just because nobody filed an ubuntu-archive bug to move it to universe, I suppose
[16:50] <soren> pitti: http://changelogs.ubuntu.com/changelogs/pool/multiverse/a/aspectj/aspectj_1.5.3-1/aspectj-doc.copyright looks free to me.
[16:50] <pitti> soren:   aspectj |    1.5.4-1 | unstable/contrib | source, all
[16:50] <soren> ...but I'm not a cool archive admin like yourself, so what do I know? :)
[16:51] <pitti> soren: please file a bug about moving it then; thanks for spotting
[16:51] <soren> contrib means it's free, but depends on non-free stuff?
[16:51] <pitti> yes
[16:51] <soren> Cool. thanks.
[16:51] <pitti> most likely because of earlier non-free java deps
[16:52] <soren> pitti: Exactly.
[16:52] <soren> pitti: Filed. Thanks!
[16:53] <mvo> james_w: the bzr-builddeb snapshot looks good, the only change I noticed is that it puts the debs/changes files into ../build-area again (the latest packaged one put the final stuff into ../ )
[16:53] <james_w> mvo: were you building a source package?
[16:54] <mvo> james_w: yes (bzr-buildpackage -S)
[16:54] <mvo> (not a big deal, just wanted to mention it)
[16:56] <james_w> mvo: hmm, works for me, do you have "Placing result in" as the last line of the output?
[16:57] <mvo> james_w: oh, I guess its because its a sponsored build and debsign failed
[16:58] <james_w> mvo: ah, yeah, that'll do it
[16:58] <mvo> nevermind then :)
[16:58] <james_w> I want to make it work better by not using "../build-area"
[16:59] <james_w> I think it will work, you just get a complaint about "directory name is not <source>-<version>" or something
[16:59] <james_w> which can probably be removed, as I believe it makes no difference
[16:59] <mvo> yep
[17:05] <ogra> cjwatson, "Loading additional components" is that anna ?
[17:06] <ogra> it loads a lot of unused stuff
[17:06] <cjwatson> yes
[17:06] <cjwatson> use lowmem
[17:06] <ogra> like ltsp-client-builder
[17:06] <ogra> it switches to lowmem immediately after boot
[17:06] <cjwatson> which level?
[17:06] <ogra> there are levels ?
[17:06] <cjwatson> yes
[17:06] <ogra> oh, i didnt know
[17:06] <cjwatson> cat /var/lib/lowmem
[17:07] <ogra> 2
[17:07] <cjwatson> hmm
[17:07] <cjwatson> it doesn't go higher than that
[17:07] <cjwatson> can you get me a syslog please?
[17:08] <ogra> http://paste.ubuntu.com/119296/
[17:10] <ogra> the try before it actually didnt download all that stuff and jumped to hw-detect
[17:10] <cjwatson> well, ltsp-client-builder alone isn't going to help very much
[17:10] <ogra> or i missed that, but i doubt it
[17:10] <cjwatson> nearly everything else there is mandatory
[17:10] <ogra> weird
[17:10] <ogra> i wonder why i got further before
[17:10] <cjwatson> phase of the moon?
[17:11] <ogra> hmm, and why is it pulling in localechooser now
[17:11] <cjwatson> low-memory problems can sometimes not be entirely deterministic, depending on exact ordering
[17:11] <ogra> localechooser - is in the default cfg
[17:11] <cjwatson> that's only the initrd
[17:11] <cjwatson> localechooser is meant to be run once the network console is up
[17:11] <ogra> ah
[17:12] <ogra> well, for sure our kernel is 500k bigger (compressed) ... and i would suspect debian has less things in d-i as well ..
[17:12] <cjwatson> not by very much
[17:13] <cjwatson> anyway, you can't solve low memory problems by randomly shooting at the thing you notice that you like least :)
[17:13] <cjwatson> you have to profile
[17:13] <ogra> well, i have a working setup in debian so i'll start comparing
[17:13] <ogra> but the kernel might be our biggest issue here
[17:14] <ogra> i'm not sure to what the 500k translate uncompressed
[17:14] <ogra> but surely a lot for that arch
[17:15] <ogra> if i could swap before doing anything else ...
[17:15] <cjwatson> ltsp-client-builder is installed because it's Priority: standard; it's the same reason that it gets pulled in unnecessarily on netboot installations
[17:15] <cjwatson> can we arrange to pull that in only on ltsp installs instead?
[17:15] <ogra> sure, it should only be in when preseeded
[17:16] <cjwatson> ok, I'll take care of that
[17:16] <ogra> thanks
[17:16] <ogra> but i doubt that buys me enoug
[17:16] <ogra> h
[17:17] <cjwatson> just needs extra preseeding in debian-cd and an override change
[17:17] <ogra> ltsp-client-builder is quite tiny scripting
[17:17] <cjwatson> no, it almost certainly won't, it's just that it had been irritating me for some time and you mentioned it :)
[17:21] <ogra> cjwatson, hmm, going to menu in the serial console i see "free memory for lowmem install" below "Download installer components" shouldnt that be the other way round ?
[17:22] <cjwatson> ogra: it's after it in Debian too
[17:22] <ogra> ok
[17:23] <cjwatson> ogra: I think the point of that step is to ditch the syslog from the early phases of the installer while you get the partitioner going
[17:23] <ogra> ah, makes sense
[17:23] <ogra> i wonder if it will get to OOM if i dont use ssh
[17:23] <ogra> and just stay within serial
[18:12] <kirkland> Keybuk: enjoyed your git post, ditto :-)
[18:14] <LaserJock> kirkland: OMG, you must be a dilusional Canonical-brain-washed bzr fanboi too!!! ;-)
[18:14] <kirkland> LaserJock: yeah, that's me
[18:15] <Keybuk> a Novell person was doing that bitch at me earlier
[18:15] <mathiaz> slangasek: are you working on an openldap 2.4.14 upload to unstable?
[18:15] <Keybuk> I retored "I suppose you think we should all use GroupWise?"
[18:15] <slangasek> mathiaz: "working" :)
[18:15] <kirkland> hehe
[18:15] <slangasek> mathiaz: I'm laying the groundwork, at least
[18:16] <mathiaz> slangasek: ok - anything would be ready before FF?
[18:16] <slangasek> mathiaz: that's vaguely my hope
[18:16] <slangasek> mathiaz: among other things, we get to ditch db4.2 then :)
[18:16] <mathiaz> slangasek: I'm planning to work on a 2.4.14 before FF
[18:16] <mathiaz> slangasek: yeah - that's one of the main thing :D
[18:17] <mathiaz> slangasek: oh - and thanks for taking care of samba 3.3.0!
[18:17] <slangasek> sure :)
[18:17] <kirkland> Keybuk: i move ecryptfs-utils from git over to bzr about 2 weeks ago and my upstream-maintainer life is so much happier
[18:17] <kirkland> Keybuk: surprisingly, the other two main contributors, individuals who work for IBM and Red Hat, have openly stated how easy bzr is
[18:18] <kirkland> Keybuk: and have specifically mentioned the 'bzr push' command as ridiculously easy :-)
[18:18] <ogra> what ?
[18:18] <ogra> it doesnt do what git does !
[18:18]  * ScottK discovered it was totally even easier after learning of bzr push :parent.
[18:18] <ogra> that has to be wrong :P
[18:19] <Keybuk> kirkland: the best bit was that in the process I discovered another neat bzr command
[18:19] <Keybuk> bzr branch . ssh://.../
[18:19] <Keybuk> ie. you can make a branch of your working copy and put that branch on another machine
[18:20] <LaserJock> that is rather nifty
[18:20] <kirkland> that is a neat little gem
[18:20] <LaserJock> Keybuk: clearly the problem was you weren't using github
[18:21] <cjwatson> ssh:// doesn't work, does it? sftp://
[18:21] <Keybuk> cjwatson: err, sftp or bzr+ssh
[18:21] <cjwatson> (I filed a bug earlier today asking for ssh:// to be an alias for sftp://)
[18:22] <james_w> jelmer has just posted a patch making it say "you probably wanted bzr+ssh://" if you use ssh://
[18:22] <Keybuk> james_w: that's idiotic
[18:22] <Keybuk> if it knows what you mean, it should just fdi
[18:22] <Keybuk> I just wish bzr could support a directory containing a repository of multiple branches *and* a working tree of one of those branches
[18:22] <james_w> yeah, that's what I think
[18:22] <cjwatson> :parent> neat
[18:23] <cjwatson> and :submit :public :push :this :bound, although I can't find 'bzr help' documentation on those
[18:23] <james_w> just pointing out that bzr is fixing the complaint, not criticising you for not getting it right in the first place :-)
[18:24] <james_w> cjwatson: are you filing a bug? if not I will
[18:26] <cjwatson> for the docs? I will
[18:26] <cjwatson> bug 330535 for jelmer's thing
[18:28] <cjwatson> james_w: ah, bug 262969 maybe?
[18:31] <james_w> cjwatson: they are not actually directory services, but it's close enough I think
[18:33] <cjwatson> james_w: they're in the directory service registry ...
[18:33] <cjwatson> the AliasDirectory stuff
[18:34] <james_w> oh, my apologies
[18:35] <slangasek> sigh, I really hate the openldap ITS
[18:45] <slangasek> doko: did the issues causing python2.4/python2.5 to need libdb4.2 ever get resolved?
[18:48] <doko> slangasek: ?
[18:48] <slangasek> doko: after openldap gets updated, python will be the only thing holding db4.2 in main
[18:48] <slangasek> actually, it'll be the only thing holding db4.2 in the archive
[18:48] <doko> slangasek: not on supported architectures
[18:49] <slangasek> that doesn't help us get rid of db4.2
[18:49] <slangasek> if we have to have it for unsupported archs, we have to have it
[18:49] <slangasek> unless we kill off those archs entirely, that is
[18:50] <doko> I don't care much about this, maybe just upload a python2.4/python2.5 with a db4.x version you do want. python2.6 seems to be fine with db4.7
[18:51] <doko> the build should succeed despite failing db tests
[18:55] <slangasek> doko: so instead we'll have broken python modules on those archs? :(
[18:56] <slangasek> doko: I was really hoping someone was working on the issue upstream
[18:57] <doko> slangasek: no, upstream isn't interested in minority archs. last thing rejected was the fix to fix float handling on old arm abi. at least this doesn't affect us
[18:58] <slangasek> doko: which are the affected archs?  Perhaps I could send out a call for porters
[19:00] <doko> slangasek: libdb4.2-dev [!amd64 !i386 !lpia], libdb4.6-dev [amd64 i386 lpia] you might want to have an python2.5 upload to get current test results
[19:03] <mun> hi
[19:03] <mun> does anyone know why i'm getting a syntax error near unexpected token `(' on line 14? http://pastebin.com/m3dc05706
[19:05] <RainCT> mun: out of curiosity, what language is that?
[19:05] <mun> RainCT: it's from a configure file. i believe it's a shell script.
[19:06] <RainCT> weird one :)
[19:09] <maxb> mun: is that csh?
[19:09] <mun> maxb: i really don't know. there's no header.
[19:10] <mun> maxb: should it be csh?
[19:10] <maxb> well, it's certainly not Bourne shell
[19:10] <mun> right. i'll set the header to csh and see
[19:10] <mun> oh it all works! thanks
[19:21] <red-lichtie> I have a question about kernel packaging. As I see it, modules with experimental status are not build (delivered) as part of the standard kernel distribution. Would it not be better to distribute these modules and add them to modprobe.d/blacklist instead ? This way, if someone wants to use an experimental module, they don't have to compile everything ?
[19:22] <red-lichtie> Or am I missing a simple way of compiling a commented out module in the config and adding it quickly to my system ?
[19:30] <jelmer> Keybuk, bzr supports bzr+ssh://, git+ssh://, svn+ssh:// and sftp://. Aliasing ssh:// to one of them is going to cause confusion.
[19:31] <ScottK-desktop> red-lichtie: #ubuntu-kernel is probably better for that question.
[19:31] <red-lichtie> Thanks
[19:33] <slangasek> jelmer: well, I guess I would rule out two of those as obviously incorrect choices, but YMMV :)
[19:39] <maxb> I don't think there's anything wrong with bzr+ssh:// - the level of redundancy is the same as http:// in a web browser
[19:45] <slangasek> maxb: if you omit "http://" from a url passed to a web browser, the web browser will DTRT
[19:45] <slangasek> mathiaz: har, for openldap 2.4.14 supposedly including a bunch of GnuTLS fixes, it would be nice if the code actually compiled
[19:46] <slangasek> mathiaz: btw, no fix in 2.4.14 for the V1 CA cert issue
[19:47] <maxb> Indeed, the point I was hinting at is that despite being autofilled (in that context) the http:// is still considered a sensible part of the url
[19:48] <mathiaz> slangasek: I saw an email on openldap-software about that
[19:49] <slangasek> mathiaz: which part, the build failure or V1_CA_CERT?
[19:49] <mathiaz> slangasek: I don't know if the bug has been fixed though (I'm refering to the build failure)
[19:49] <slangasek> ok
[19:49] <slangasek> http://www.openldap.org/lists/openldap-software/200902/msg00103.html, I guess
[19:50]  * mathiaz nods
[19:50]  * slangasek snorts at the follow-up, "I suggest you file an ITS"
[19:51] <mun> hi
[19:51] <mun> if a Makefile has the definition CFLAGS = @CFLAGS@ where would @CFLAGS@ be defined?
[19:55] <slangasek> mun: the @VARIABLE@ convention is related to autoconf; you should never see such a line in Makefile, it should appear in Makefile.in but be substituted with a value when generating Makefile.
[20:01] <mun> slangasek: ok thanks
[21:00] <pmo> are you the owners of ubuntuforums.org ?
[21:01] <pmo> just found traces of JS:Pdfka-AL [Expl] in it
[21:01] <RainCT> pmo: I think there is #ubuntuforums
[21:01] <pmo> ah ok ty
[21:38] <lool> directhex: Heya, can I ask you for help on a C# update?
[21:39] <lool> directhex: Basically: http://paste.ubuntu.com/119400/ is what I asked to slomo, but seb128 I could ping you as well
[21:40] <lool> Erf, Tasque uses the name "API Application" to register to RTM's services
[21:41] <lool> Woohoo, it works
[21:45] <btQuark> btw: would it be possible to couple tomboy to evolution?
[21:45] <kees> Keybuk: around?  I'm looking at getting kerneloops to not run as root, but I suspect that will affect the dbus changes you made.
[21:48] <TheMuso> superm1: Takashi has another sound git tree, located here: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
[21:48] <TheMuso> superm1: Thats where a lot of the alsa driver development work happens, and then its merged back into alsa-kernel, less often than it should be IMO.
[21:55] <allquixotic> bryce: Hey
[21:58] <allquixotic> bryce: I got the feature freeze message from Steve Langasek. The UXA testing is still messy. 24 mixed/better/same vs. 9 worse/broken/locks up. :( Are we going to have to ship with EXA, and if so, have you heard anything back from Intel about speeding its 2D up at all?
[21:58] <superm1> TheMuso, gah. this is the first patch i've seen that IDT churned out that didnt go right into alsa-kernel.  I really didn't want to get *this* involved... just wanted to make sure that a laptop worked right :)
[21:59] <TheMuso> superm1: Yeah I can understand that.
[22:12] <kirkland> bdmurray: just making sure, you know that there's a browser search plugin for http://people.ubuntu.com/~kirkland/search.html, right?
[22:13] <bdmurray> kirkland: no I didn't
[22:13] <kirkland> bdmurray: "Install the Browser Plugin"  ;-)
[22:13] <slangasek> mathiaz: it looks like the slapd test suite hangs for me during build, while running one of the concurrency tests - if you have some time to try to reproduce/debug this, that would be helpful
[22:14] <mathiaz> slangasek: sure
[22:14] <mathiaz> slangasek: is the code in debian svn up-to-date?
[22:14] <slangasek> mathiaz: yes
[22:46] <directhex> lool, someone might already be looking at evolution# - check in oftc #debian-mono
[22:54] <lool> directhex: But then the update I prepared is ubuntu specific
[22:56] <RAOF> lool: That's the new upstream release?  0.19.2.1?
[22:56] <lool> RAOF: Yes
[22:56] <lool> RAOF: Check my PPA if you like, I pushed the sources with detailed changelog entries of my changes
[23:17] <bryce> allquixotic: yes we will have to ship with EXA.  I did talk to Intel about it and they said it sounded like a rational plan given the state of UXA
[23:17] <bryce> allquixotic: so far they've not given up any tips for improving EXA performance
[23:18] <slangasek> Keybuk: I'm intrigued by the use of $ENV{UTC} in the util-linux udev rule.  Is this really guaranteed to always be set in udev's environment?
[23:23] <allquixotic>  bryce: Argh
[23:23] <allquixotic> bryce: That's a shame that we can't get things a little better from either side. As long as we ship UXA though I'll be using it
[23:23] <allquixotic> got to run.... thanks
[23:43] <directhex> can someone with write access to Importance please bump https://bugs.launchpad.net/ubuntu/+source/mono-addins/+bug/330440 ? as well as fixing monodevelop, it appears to fix a critical issue with f-spot plugins not working
[23:43] <StevenK> directhex: So, where's my tomboy upload?
[23:43] <RainCT> directhex: which importance do you want?
[23:44] <directhex> RainCT, i don't even know the options, since i can't see them
[23:44] <RainCT> heh
[23:44] <RainCT> directhex: http://wiki.ubuntu.com/Bugs/Importance
[23:44] <directhex> StevenK, i believe DktrKranz has been at the head of gnome# issues. i haven't touched it
[23:45] <directhex> argh compiz has decided that my favourite decoration mode for firefox should be "none at all" and doesn't give me window borders unless i fullscreen & unfullscreen my ff window :(
[23:45] <DktrKranz> directhex, StevenK: tomboy has been recently uploaded
[23:46] <directhex> RainCT, it is a Medium. "# A bug that has a moderate impact on a core application. " AND "# A bug that has a severe impact on a non-core application. "
[23:46] <directhex> DktrKranz, neato!
[23:46] <RainCT> directhex: already set it :)
[23:47] <directhex> i should start work on my praise-filled mail to ubuntu-devel & ubuntu-motu thanking people for their help on mono-related transitions
[23:47] <DktrKranz> directhex, only evolution-sharp is out, we're almost done :)
[23:47] <StevenK> DktrKranz: The tomboy upload drops libgnome2.0-cil and friends?
[23:48] <StevenK> DktrKranz: And tomboy is DEPWAIT on  libgnomepanel2.24-cil
[23:48] <slangasek> StevenK: fixing that requires resolving the gnome-sharp2/gnome-desktop-sharp2 packaging still, doesn't it?
[23:49] <StevenK> slangasek: No idea, I'm chasing this from a purely NBS angle :-)
[23:49] <StevenK> But yes, libgnomepanel2.24-cil is in universe
[23:49] <slangasek> StevenK: yeah, you probably need to put that one on hold; note that the NBSes are my fault, yet they're still there :)
[23:49] <RainCT> argh.. glest-data is hanging at 68154k/68155k
[23:49] <DktrKranz> StevenK, it drops NBSes, and libgnomepanel2.24-cil needs to be promoted
[23:49] <directhex> oh, that explains it
[23:50] <directhex> i was thinking "huh, i see that package" but forgot that it was NEW
[23:50] <directhex> so universe
[23:50] <slangasek> oh, but if libgnomepanel2.24-cil is here now, that's fixable :)
[23:50] <directhex> slangasek, https://launchpad.net/ubuntu/jaunty/i386/libgnomepanel2.24-cil/2.24.0-1ubuntu1
[23:50] <slangasek> StevenK: I'll promote gnome-desktop-sharp2
[23:50] <StevenK> slangasek: Excellent
[23:50] <directhex> neato! ^_^
[23:51] <directhex> DktrKranz, can you mail me a list of people i need to thank for helping the gnome# transition?
[23:51] <cjwatson> BTW, people have been complaining about daily CD builds not working due to libart*-cil
[23:51] <StevenK> Now, how to fix texlive ...
[23:51] <cjwatson> http://cdimage.ubuntu.com/daily/current/report.html is empty though
[23:51] <slangasek> hmm
[23:52] <DktrKranz> directhex, thank or blame? So you can start for blaming me :)
[23:52] <cjwatson> and http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html doesn't show anything obvious
[23:52] <StevenK> libart2.0-cil or libart2.24-cil ?
[23:52] <cjwatson> so I don't quite know what's going on; I suppose they might be looking at old images
[23:52] <cjwatson> StevenK: a conflict between the two
[23:52] <slangasek> cjwatson, StevenK: it's a conflict between the two of those, yummy
[23:52] <StevenK> Oh, fun.
[23:52] <slangasek> so that'll shake out once we have everything building against the new version
[23:53] <directhex> it's just gnome# issues
[23:53] <slangasek> I guess people want tomboy and f-sharp to both be installable at the same time
[23:53] <RAOF> Silly people.
[23:53] <cjwatson> given that they're both in desktop ... :)
[23:53] <StevenK> slangasek: You tell funny jokes
[23:53] <cjwatson> wonder why ubuntu-desktop doesn't come out as uninstallable
[23:53] <directhex> and DktrKranz has been sprinkling magic dust on gnome# issues
[23:53] <directhex> cjwatson, recommends: not depends:
[23:53] <StevenK> That should get sorted out with this tomboy issue
[23:53] <slangasek> cjwatson: because tomboy is a Recommends only
[23:53] <cjwatson> directhex: hmm. it'd be nice if britney regarded that as mandatory
[23:53] <slangasek> as is f-spot
[23:53] <cjwatson> at least recommends from metapackages
[23:54] <cjwatson> maybe I should fix that
[23:54] <directhex> slangasek, because mono isn't on all arches, afaik
[23:54] <directhex> slangasek, that or a concession to the "omg no monoez" crowd
[23:54] <slangasek> directhex: no, the metapackages are arch-dependent binary packages
[23:54] <slangasek> directhex: there are lots of severable bits of the desktop listed in the Recommends, not just the mono stuff
[23:54] <directhex> slangasek, in either case, it's a transitory problem - albeit the highest profile package is the last one fixed
[23:55] <directhex> oh, and which lovely archive admin let my very first package through NEW?
[23:56] <directhex> well, second if you count mono-basic, but that was based on never-uploaded packaging work by someone else
[23:56] <cody-somerville> directhex, It was I! The most wonderful person in the room which I stand.
[23:57] <directhex> cody-somerville, yay! have some cake!
[23:57] <DktrKranz> directhex, what about baking cookies (as Debian guys did)=
[23:58] <directhex> DktrKranz, depends. my cookies might offend any vegetarians present
[23:59] <DktrKranz> directhex, anyway, I'll mail you about *real* changes about gnome#, so they can be of aid to Debian guys