[00:25] <sebner> bdrung: right, stays at "None" (even though I have effects enabled)
[01:01] <GanonKiller> is combat arms still in development for linux?
[01:07] <GanonKiller> is combat arms still in development for linux?
[02:39] <aakshay> hi.. i am making the package using the packaging guide. the rules file is not complete as shown in tutorial..
[02:40] <aakshay> does anybody know how to adjust rules file in pakaging..
[02:44] <aakshay> does anybody know how to edit rules file in pakaging.. its not showing makefile in it
[02:45] <RAOF> What do you mean?
[02:45] <RAOF> The debian/rules file is a makefile, with various standard targets that the build process calls to make things happen.
[02:46] <aakshay> raof: the rules file is not showin any rules in it
[02:46] <aakshay> raof: its been restricted by developer
[02:47] <aakshay> raof: its showin  < #!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make.  # Uncomment this to turn on verbose mode. 
[02:48] <RAOF> aakshay: You should pastebin the rules file rather than paste it into IRC
[02:48] <RAOF> (The pastebinit tool is useful here)
[02:48] <aakshay> i m sorry.. i dont know how. it's my first time here...
[02:49] <aakshay> raof: can u plz tel where is the pastebin option?
[02:50] <RAOF> You can install the “pastebinit” package.  That gets you the pastebinit tool, which you can use like so: “pastebinit debian/rules”, and it'll copy the debian/rules file to a pastebin and then return the URL.
[02:50] <RAOF> You then want to paste the URL in here.
[02:51] <aakshay> thanx...let me do this... plz wait.
[02:51] <hallyn> if a bug affects debian as upstream, can i just hit 'also affects' in LP and it'll do the right thing wrt debian bugs, or do i need to separately file a debian bug through email?
[02:52] <RAOF> You need to separately file a debian bug through email; Launchpad doesn't (yet!) _actually_ forward the bugs upstream.  That's a way to link existing upstream bugs into the Launchpad bug.
[02:53] <hallyn> RAOF: thanks!
[02:56] <aakshay> roaf: URL is "http://pastebin.com/SsusCmzz"
[02:57] <aakshay> roaf: plz suggest something
[02:57] <RAOF> Right.  As I suspected.
[02:57] <RAOF> So, that *does* have all the targets of interest.
[02:57] <aakshay> sorry??
[02:57] <RAOF> The “%:” target is a catch-all target.
[02:57] <RAOF> It matches everything.
[02:57] <aakshay> okiez... it has this
[02:58] <aakshay> roaf: so wat i can do ?
[02:58] <RAOF> That's a fairly typical debhelper 7 rules file.
[02:58] <RAOF> aakshay: Well, what do you want to achieve?
[02:58] <aakshay> roaf: i am learning packaging
[02:59] <aakshay> so i came across this file to edit this
[02:59] <aakshay> roaf: but its not showing the complete rule file.. so i get stucked at this point
[03:00] <RAOF> That *is* the complete rules file.
[03:00] <aakshay> roaf: yes..
[03:01] <aakshay> roaf: please suggest something
[03:01] <RAOF> I'm not sure what you're trying to do.
[03:02] <aakshay> roaf: i m doin packaging using deb-helper..... for this we need to edit the control, changelog, rules etc files
[03:02] <RAOF> That rules file will work for a simple package with no unusual requirements.  Whether you need to modify it, and how you need to modify it, depends on what the software you're trying to package needs.
[03:04] <aakshay> roaf: i am using deb-helper and packaging the simple hello-2.1.1 soy=urce....m doing this from ubuntu packaging guide..
[03:05] <aakshay> roaf: *source
[03:06] <aakshay> roaf: thanx for help...;-)
[03:07] <RAOF> I'm still not sure what your question is :/
[03:10] <aakshay> roaf: my question is how can i view my rules file completely.... there is no rules defined in it....;)
[03:11] <RAOF> You *are* viewing your rules file completely.  That file defines a catch-all rule - “%:”.
[03:11] <aakshay> roaf: these rules are inbuilt in it.... which are not there in this file...
[03:11] <aakshay> okiez...
[03:12] <RAOF> So when debian/rules is called with “debian/rules build”, Make looks for the ‘build’ target, finds that ‘%:’ matches “build”, and executes the commands there (specifically, it runs “dh build”, because $@ gets substituted to the target name).
[03:14] <aakshay> roaf: okiez.. let me try it other way...
[03:14] <aakshay> roaf: thanx again for your help..;)
[03:15] <aakshay> roaf: bye...
[03:16] <RAOF> Good luck!
[03:20] <wgrant> lamont: The extras.ubuntu.com resigning stuff doesn't seem to be working. It's now signed with the original PPA key, which isn't in the default keyring.
[04:38] <RAOF> @pilot out
[04:44] <TheMuso> lol udevbot
[05:17] <RAOF> Ok!  Who'd like to burn a few CPU cycles sponsoring a new mesa & Radeon DDX?
[05:38] <RAOF> For those playing at home, http://cooperteam.net/Packages/mesa_7.9+repack-1ubuntu1.dsc and http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2-1ubuntu2.dsc are awaiting someone's pleasure.
[05:40] <StevenK> RAOF: You mean you aren't a coredev yet?
[05:44]  * RAOF takes this as more evidence it's time to get his application wiki page in order.
[05:45] <StevenK> RAOF: When you're done, point me at it and I'll stamp it
[05:46] <RAOF> Thanks :).
[05:46] <RAOF> I'm off for some exercise now; I'll be back online later.
[05:49] <StevenK> RAOF: http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2.orig.tar.gz is 404
[05:52] <RAOF> StevenK: Now it's there.
[05:52] <StevenK> RAOF: Yah, I just grabbed it, thanks
[05:52] <StevenK> RAOF: Slow wet string?
[05:52] <RAOF> No; forgetting to -sa
[05:53] <StevenK> Ha
[05:58] <RAOF> Note that there's a semi-dependency on the new mesa in the new xserver-xorg-video-ati
[05:59] <StevenK> RAOF: So mesa should be uploaded and built first?
[06:00] <RAOF> A new option in the new ati won't work until the new mesa is installed.
[06:01] <RAOF> Peoples systems won't break unless they add an xorg.conf option before installing the new mesa; I don't think the ordering is particularly important.
[06:02] <RAOF> Specifically, the ForceGallium option won't work until you've installed the new mesa, which builds the gallium driver.  It's only interesting if you want to test that.
[06:02] <RAOF> Now, really going off to exercise :)
[06:48] <kees> cjwatson: cpu-checker can be demoted to universe (I removed it from update-manager-common)
[06:58] <ebroder> Does...anybody know why apt-get update in my natty schroot would be giving "Undetermined Error" when trying to download the natty-updates Packages and Sources files from my approx server?
[07:01] <pitti> Good morning
[07:32] <dholbach> good morning!
[07:51] <ebroder> In the interests of whittling down the sponsoring queue, anybody want to mark https://code.launchpad.net/~hrw/ubuntu/natty/byobu/fix-cpu-freq-on-smp-arm/+merge/41427 as merged as of r89?
[07:51] <dholbach> ebroder, done
[07:52] <ebroder> Thanks
[07:52] <dholbach> de nada
[07:53] <ebroder> Looks like https://code.launchpad.net/~smoser/ubuntu/natty/euca2ools/euca2ools-1.3.1/+merge/41105 was merged as of r25
[07:54] <didrocks> good morning
[07:55] <dholbach> ebroder, done
[08:10] <dholbach> RAOF, I had a chat with amaranth about bug 395692 yesterday - he said that it's unmaintained upstream
[08:11] <dholbach> it's probably safe to just upload it
[08:17] <ebroder> dholbach: https://code.launchpad.net/~smoser/ubuntu/lucid/mountall/bug649591/+merge/37105, merged as of r337 :)
[08:18] <dholbach> server team ^ mark your branches as merged!
[08:18] <ebroder> dholbach: I'll stop and just harrass SpamapS next time I see him :)
[08:19] <ebroder> And smoser, I guess
[08:34] <RAOF> dholbach: Yeah.  I can't upload it, though, so I again call for sponsorship :)
[08:34] <dholbach> ok, I'll have a look into it in a bit
[08:52] <RAOF> StevenK: Are you able to upload mesa or -ati, or should I cast around for other sponsors?
[08:53] <pitti> RAOF: toss me the URL to a source.changes, I'm happy to upload stuff for you
[08:54] <StevenK> RAOF: I got distracted
[08:54] <StevenK> RAOF: Sorry
[08:54] <dpm> good morning cjwatson, great work with the interview on planet ubuntu, it was a very interesting read!
[08:54] <RAOF> StevenK: No problem.  I'll punt it to pitti, then, since it's late for you.
[09:14] <pitti> cjwatson: eww, "ps aux|grep cdimage" on antimony looks like there's a lot of stuck build live processes -- do you think we should kill them wholesale?
[09:23] <geser> somebody else having problems with booting his natty system? grub greeted me today with "grub rescue>" instead the usual menu :(
[09:24] <pitti> I just dist-upgraded and rebooted, worked fine here
[09:24] <pitti> geser: did some package (kernel/grub) fail to configure or so?
[09:24] <ebroder> geser: You probably didn't install the new grub, and the configuration doesn't seem to work with older grub
[09:24] <geser> not that I noticed on the update yesterday
[09:26] <geser> ebroder: I remember seeing the usual debconf question on which harddisk to install grub. What need I to do to fix it?
[09:26] <ebroder> geser: Check the logs from yesterday around, uh...22:46 UTC. Probably the same thing bdrung ran into
[09:27] <ebroder> geser: If you can manage to boot once, "grub-install /dev/sda" should fix it for now, and "echo SET grub-pc/install_devices /dev/sda | sudo debconf-communicate" should fix it forever (substituting your harddrive of choice for /dev/sda)
[09:27] <geser> ebroder: -rw-r--r-- 1 root root 104084 2010-11-24 18:22 /boot/grub/lua.mod (if you mean that)
[09:27] <ebroder> geser: Oh, never mind then
[09:28] <ebroder> geser: Well, following cjwatson's script from earlier, does "insmod normal" then "normal" get you anything interesting?
[09:30] <geser> ebroder: here is the output from debconf-show for grub-pc: http://paste.ubuntu.com/536214/
[09:30] <ebroder> geser: Yeah, this isn't bdrung's problem
[09:31] <geser> if it's matter I use RAID and LVM (/boot is on RAID1, / on LVM on RAID1)
[09:33] <ebroder> geser: Unfortunately it's 3:30AM my time, and I meant to go to sleep 2 hours ago. Hopefully cjwatson will be around soon and can undoubtedly be more helpful than me in any case
[09:34] <geser> I've to leave in a few minutes too (first for work then university) and should be back around 16 UTC
[09:43] <RAOF> pitti: When you're free, http://cooperteam.net/Packages/mesa_7.9+repack-1ubuntu1_source.changes and http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2-1ubuntu2_source.changes
[09:46] <pitti> RAOF: debdiff looks fine to me; thanks, uploaded
[09:48] <RAOF> pitti: Thanks muchly.  That should get us a long way towards fitting on a CD.
[09:48] <pitti> oh, just uplaoded ati; /me looks at mesa
[09:49] <RAOF> Heh.  -ati's not going to slim the CDs down much :)
[09:50] <pitti> that's what made me wonder :)
[09:51] <pitti> oops
[09:51] <bilalakhtar> It appears there is a large list of NBS packages with no reverse deps. Why isn't someone cleaning them up?
[09:51] <pitti> RAOF: can you please rebuild the source.changes with -sa?
[09:51] <pitti> RAOF: my upload will be rejected, as the orig isn't there
[09:52] <pitti> bilalakhtar: it's mostly the old kernel ABI; cleaning up now
[09:52] <bilalakhtar> thanks pitti
[09:53] <RAOF> pitti: Ah, yeah, sorry.
[09:53] <pitti> RAOF: (if you rebuild, you'll have to reupload .dsc and diff.gz as well)
[09:55] <StevenK> bilalakhtar: It's a manual process
[09:56] <bilalakhtar> StevenK: of course it is :)
[09:56] <StevenK> From my looking, it's just a kernel
[09:56] <StevenK> You should see the list when it has 3 or 4 kernel versions in it
[09:57] <pitti> should look much better in the next runm
[09:57] <RAOF> pitti: There you go, should be good.
[09:58] <pitti> RAOF: yep, thanks; uploading
[09:58] <StevenK> pitti: You've already killed -5?
[09:59] <pitti> StevenK: yep, since d-i was rebuilt against -6
[09:59] <StevenK> pitti: Okay, then I won't try :-)
[10:00] <pitti> and the old .35-22 kernels, too, plus three "no rdepends" packages
[10:00] <pitti> warp10: warp11? physically impossible!
[10:00] <pitti> warp10: hey Andrea, how are you?
[10:00] <warp10> pitti: That's transwarp!
[10:01] <warp10> pitti: pretty fine, thanks, and you? :)
[10:01] <StevenK> Actually, I didn't think transwrap had numbers, they are just spacetime corridors?
[10:02] <pitti> warp10: I'm great, thanks!
[10:02] <bilalakhtar> pitti: Are you still in the OEM team or you're back?
[10:02] <warp10> StevenK: yeah, think so. Sort of conduits through transwarp space
[10:03] <warp10> StevenK: at least for Borg transwarp drive, IIRC
[10:03] <pitti> bilalakhtar: I'm back since last UDS
[10:03] <bilalakhtar> pitti: oh cool!
[10:09] <mdz> pitti, hi
[10:09] <pitti> hey mdz
[10:09] <mdz> pitti, wondering if the retracer is down; I filed a crash report yesterday which is untraced as yet (bug 680968)
[10:10] <pitti> mdz: seems the amd64 one is
[10:10] <seb128> pitti, do we have natty retracers already?
[10:10] <pitti> seb128: no, we don't
[10:10] <mdz> seb128, but that was a maverick crash
[10:10] <mdz> which the U1 team wants to look at
[10:10] <seb128> mdz, sorry I hijacked your question
[10:10] <pitti> restarted the amd64 one
[10:11] <mdz> pitti, thanks
[10:11] <pitti> mdz: thanks for pointing out; I guess LP rollout
[10:11] <seb128> mdz, I was just thinking about natty yesterday because of unity testing
[10:11] <seb128> mdz, I your question made me think about it again ;-)
[11:29] <cjwatson> kees: cpu-checker> the problem is that qemu-common recommends it
[11:30] <cjwatson> dpm: thanks :)
[11:30] <cjwatson> pitti: need to consult with lamont I think, as killing the trigger scripts on antimony won't kill the actual build processes on the livefs buildds
[11:30] <cjwatson> lamont: ^-
[11:31] <pitti> ah, right
[11:31] <pitti> lamont: it seems that there are a lot of stuck livefs build jobs on the buildds right now? at least antimony has a plethora of very old calls there (ssh sessions, right?)
[11:45] <soren> Argh.
[11:45] <soren> Just... argh.
[11:48] <bilalakhtar> soren: why?
[11:49] <mdz> pitti, thanks for getting the amd64 retracer back up. I can now see that my bug is one of many apparent duplicates with equivalent stack traces
[11:49] <pitti> :)
[11:49] <mdz> pitti, I wonder why the retracer did not match them as duplicates in fact
[11:49] <seb128> mdz, is there any missing symbols in the stacktrace?
[11:49] <seb128> like ?? lines
[11:50] <mdz> seb128, hmm, yes
[11:50] <seb128> that's why
[11:50] <mdz> there is one missing gobject symbol
[11:50] <seb128> the autodup works only with exact matches
[11:50] <seb128> exact and complete functions
[11:50] <pitti> mdz: there's some difference in the 4th and 5th line of stack trace top
[11:51] <mdz> pitti, a few, though there are many which have identical stacktracetop
[11:52] <mdz> seb128, I see, thanks
[11:52] <mdz> I wonder why it isn't resolving that symbol
[11:52] <soren> pitti: Is pkgbinarymangler's test suite supposed to work as a regular user (and on systems that already have it installed)?
[11:52] <pitti> soren: yes
[11:52] <pitti> it's supposed to take the local binaries
[11:52] <pitti> and it's all done in a temp directory
[11:52] <pitti> soren: it runs on the buildds during package build, after all
[11:52] <soren> pitti: If I run "test/run -v", I get a whole stack of these:     os.symlink('/usr/bin/dpkg-deb.pkgbinarymangler', os.path.join(self.srcdir, 'dpkg-deb.pkgbinarymangler'))
[11:52] <soren> OSError: [Errno 17] File exists
[11:53] <soren> pitti: Yes. As root.
[11:53] <pitti> soren: that's from a failed run, you have to remove this file manually
[11:53] <pitti> soren: I run it as user here
[11:53] <soren> pitti: Sorry, which one is "this file"? :)
[11:53] <pitti> dpkg-deb.pkgbinarymangler
[11:54] <soren> Oh, that one!
[11:54] <soren> Yeah, there it goes. Lovely. Thanks.
[11:54] <pitti> "bzr clean-tree --ignored --unknown" for the win :)
[11:54]  * pitti has that aliased as "bzcln"
[11:54] <soren> pitti: Now that I have you attention anyway. I'm stunned that noone has noticed that the dpkg-deb wrapper fails if the path has a space in it.
[11:54] <mdz> the libglib and libgobject symbol info seems to be missing
[11:55] <pitti> soren: it happens seldomly enough
[11:55] <seb128> mdz, could be that the ddeb retrievers bugged and that there is no dbgsym for glib on that arch for that version
[11:55] <ari-tczew> archive admins: why squid3 is on blacklist? there is a new debian revision merge. is it possible to do?
[11:56] <soren> pitti: Err.. Except when you click on a deb on a web site and it attempts to get installed through software center.
[11:56] <pitti> soren: I try to quote my variables, but well, it's shell..
[11:56] <soren> pitti: I have a patch, just need a test case.
[11:56] <pitti> soren: what's that to do with the mangler?
[11:56] <soren> pitti: If someone has pkgbinarymangler installed, and their locale's "Downloads" has a space in it (in Danish it's "Hentede Filer
[11:56] <soren> "), you can't install deb's from firefox.
[11:57]  * cjwatson is currently running http://paste.ubuntu.com/536260/ - approach may be of interest to others with large queues of apport-generated bugs
[11:57] <seb128> mdz, doesn't seems to be the case, http://ddebs.ubuntu.com/pool/main/g/glib2.0/
[11:57] <seb128> not sure why then...
[11:57] <cjwatson> (sort of like a special-purpose version of bughelper optimised for very quickly scanning and duplicating lots of bugs onto a known base)
[11:57] <pitti> soren: I'm still puzzled, but perhaps it'll clear up in your MP
[11:58] <soren> pitti: I'm not sure what is unclear.
[11:58] <soren> ?
[11:58] <soren> pitti: ...and if I don't know, I can't clarify it in my mp :)
[11:58] <cjwatson> ari-tczew: squid3 # overrides squid-cgi; needs manual resolution
[11:58] <pitti> soren: where does the mangler come into play when you install .debs from firefox?
[11:58] <ari-tczew> cjwatson: I see this one. so, merge-able
[11:58] <ari-tczew> ?
[11:58] <cjwatson> may not be true any more
[11:58] <soren> pitti: It wraps dpkg-deb
[11:59] <soren> pitti: dpkg -i -> dpkg-deb -x -> fail
[11:59]  * cjwatson checks the bzr history
[11:59] <pitti> aah
[11:59] <ari-tczew> cjwatson: is it possible to check who did this change?
[11:59] <pitti> soren: right, now I understand; sorry :)
[11:59] <cjwatson> log message was "initial sync blacklisting for maverick"
[11:59] <cjwatson> it was probably me
[11:59] <cjwatson> I can't check for sure due to the way the archive admin shell access setup works
[11:59] <cjwatson> but I don't think it matters
[12:00] <ari-tczew> cjwatson: I dunno why this one didn't handle by MoM?
[12:00] <cjwatson> ari-tczew: because it ignores everything on the sync-blacklist
[12:00] <cjwatson> ari-tczew: I've unblacklisted it
[12:00] <ari-tczew> cjwatson: thanks!
[12:01] <ari-tczew> cjwatson: another issue with MoM: do you think that adding blank line at the end of debian/changelog is an issue?
[12:02] <cjwatson> yes, though a minor one
[12:02] <ari-tczew> cjwatson: ok, I'll report a bug
[12:22] <seb128> mdz, pitti: ok, I figured why the glib symbols are missing
[12:23] <mdz> seb128, oh! what is it?
[12:23] <seb128> mdz, pitti: the retracers doesn't have a maverick-updates ddeb source
[12:23] <pitti> oh, crud
[12:23] <seb128> I'm fixing it
[12:23] <pitti> seb128: merci
[12:23] <seb128> they still have lucid-proposed and lucid-updates
[12:23] <seb128> pitti, yw
[12:23] <pitti> seb128: that was because we often copy SRUs from lucid-proposed to maverick (same for natty)
[12:24] <pitti> but that doesn't reflect on the ddebs archive
[12:24] <pitti> seb128: so please leave those in
[12:24] <pitti> (proper soyuz support for ddebs FTW..)
[12:24] <seb128> ok
[12:24] <seb128> I will just add the maverick ones
[12:24] <mdz> seb128, nice work
[12:24] <seb128> thanks ;-)
[13:12] <ari-tczew> pitti: could you accept packages in karmic-proposed? ;-)
[13:13] <bilalakhtar> ari-tczew: <pitti> Pinging an ~ubuntu-sru member to accept packages won't help, sorry
[13:13] <bilalakhtar> that's what he said to me a few months ago
[13:14] <ari-tczew> bilalakhtar: odd.
[13:14] <bilalakhtar> ari-tczew: try the poke, since karmic-proposed is a somewhat staler section of SRUing ATM
[13:16] <ari-tczew> bilalakhtar: SRU work should be welcome. Answer which you showed me is pretty ignorant.
[13:17] <bilalakhtar> ari-tczew: my answer was for an SRU into lucid-{proposed,updates} at a time when maverick was devel release
[13:17] <soren> pitti: Can you review lp:~soren/pkgbinarymangler/no-mangle-args please?
[13:17] <bilalakhtar> your case is different
[13:17] <bilalakhtar> soren, ari-tczew: pitti seems /away for lunch
[13:18] <soren> bilalakhtar: I can wait :)
[13:20] <ari-tczew> bilalakhtar: I say that pitti's answer seems to ignorant, not yours.
[13:20] <bilalakhtar> ari-tczew: in that line, s/my/pitti's/
[13:21] <mr_pouit> and why would it be "ignorant"?
[13:23] <ari-tczew> this answer is like 'I don't care, not my problem, still wait'
[13:24] <mr_pouit> or maybe "~ubuntu-sru members aren't archive admins, only archive admins can accept packages, so you have to wait for the next archive admin day"?
[13:25] <mr_pouit> but it's better to jump to conclusion as you did, and treat people as ignorant :]
[13:27] <ari-tczew> mr_pouit: I'm pinging pitti as archive admin, not as sru team member.
[13:28] <ari-tczew> and I'm not here to guessing about other people sentences
[13:28] <ari-tczew> answer is answer
[13:28] <seb128> the point is that people do work on those tasks when they have time
[13:29] <seb128> doing IRC ping is usually of no use, it just create stress and discussions
[13:29] <seb128> if you wait a bit SRU will be reviewed in the regular way
[14:00] <ari-tczew> cjwatson: could you also take a look on package 'fai' on blacklist?
[14:00] <ari-tczew> it seems to be outdated
[14:00] <ari-tczew> \sh: has uploaded changes this year
[14:00] <cr3> hi folks, anyone happen to know if there's a way to enable a wireless card, bcm4322 in this case, where rfkill unblock still doesn't seem to unblock the interface?
[14:02] <\sh> ari-tczew: stop spreading fud pls...fai is already updated on maverick
[14:02] <\sh> ari-tczew: and it's a native ubuntu package, because we really can't sync from debian at this stage
[14:03] <ari-tczew> \what do you want from me? version looks like merged with debian. if version is -0ubuntu1 then it suggests to be ubuntu packaging
[14:04] <ari-tczew> \sh:  ^
[14:05] <\sh> ari-tczew: https://launchpad.net/ubuntu/+source/fai/3.4.3ubuntu1 <- this is an ubuntu native package
[14:05] <azeem> how would a debian-native-with-ubuntu-changes version look like?
[14:06] <\sh> azeem: the same like an ubuntu native
[14:06] <azeem> ok
[14:06] <ari-tczew> lol
[14:06] <azeem> so in essence, it wasn't really possible for ari-tczew to tell
[14:07] <\sh> azeem: you can see it on ubuntu1 ?
[14:07] <\sh> if it's a package with -0ubuntu1 (which is actually not a native package) but a package with originates in ubuntu
[14:07] <azeem> whatever
[14:08] <azeem> I still think it wasn't obvious that 3.4.3ubuntu1 is a ubuntu native package and doesn't need a merge to 3.4.4
[14:08] <\sh> if it's a package with something behind the version+<somthing like an ubuntu string> it's normally a native with ubuntu changes
[14:09] <mdz> dholbach, where do the minutes from CC meetings get posted?
[14:10] <cjwatson> ari-tczew,\sh: it was sync-blacklisted because it had been removed, so it makes sense to unblacklist it now (the Ubuntu version number will still stop it being autosynced, but now it will at least show up on MoM)
[14:10] <cjwatson> ari-tczew: ideally, just file bug reports about these things and subscribe ubuntu-archive, so that the archive admin of the day can take care of them
[14:11] <ari-tczew> cjwatson: ATM \sh blamed me about unblacklist
[14:11] <cjwatson> well, the reason for the blacklist entry no longer applies so I've removed it
[14:11] <ari-tczew> aha
[14:11] <\sh> cjwatson: oh well...
[14:12] <cjwatson> \sh: I think you may misunderstand what the sync-blacklist does
[14:12] <ari-tczew> maybe archive admins should review all list to get update information
[14:12] <pitti> ari-tczew: I can, yes
[14:12] <cjwatson> \sh: packages that simply have Ubuntu changes don't belong there - there are other, better, ways to stop them being synced
[14:13] <\sh> cjwatson: no..there was a reason...I think the sync blacklist entry was already there before it was even removed...I can't remember anymore..but in the past there was this ubuntu fai team who took care about FAI
[14:13] <cjwatson> the sync-blacklist is for (a) packages that break the autosync process for one reason or another, usually binary package name clashes with another source package but occasionally something else (b) packages that have been deliberately removed from Ubuntu but are still in Debian (c) packages that are divergent in Ubuntu but don't use the *ubuntu* versioning scheme
[14:14] <cjwatson> \sh: the blacklist entry said you are mistaken
[14:14] <cjwatson> fai # stevenk, blacklisting due to removal, see bug 419099
[14:14] <cjwatson> \sh: when it was simply modified in Ubuntu, it did not require a sync-blacklist entry
[14:14] <cjwatson> \sh: this is a non-issue, really
[14:15] <pitti> soren: looking
[14:16] <\sh> cjwatson: ok..as said, I thought there was already such an entry before the removal...what could we do to only have a special group of people taking care of this package?
[14:17] <cjwatson> \sh: you already have that
[14:17] <cjwatson> \sh: you don't need a sync-blacklist entry for that.  it's a great big hammer for special purposes that have nothing to do with what you're asking.
[14:19] <cjwatson> \sh: of course, that special group of people must include MOTU; Ubuntu development is cooperative and they have upload access.  But I'm sure that they generally won't walk over your changes if the package is generally being well-maintained.
[14:19] <cjwatson> if somebody's clearly actively taking care of a package then that's generally sufficient for MOTU to leave them to it
[14:21] <\sh> cjwatson: so best practice as always...
[14:24] <pitti> soren: nice one, thanks! merged, uploading now
[14:24] <soren> pitti: np
[14:24] <pitti> soren: hm, seems that lool beat me to it
[14:25] <soren> pitti: Ah. Yeah, I wanted to make you the reviewer, but launchpad beat me to it and sent it to everyone.
[14:25] <pitti> lool: are you going to upload mangler, or want me to?
[14:28] <pitti> lofidellity: uploading now
[14:29] <pitti> sorry lofidellity
[14:29] <pitti> lool: mangler uploaded, FYI
[14:31] <lool> pitti: I was takingit, yes
[14:31] <lool> pitti: I assigned it to me and pushed the changes
[14:31] <freeflying> pitti, how can I make changes to language-support-input-zh-hans?
[14:31] <lool> pitti: I did additional tweals
[14:31] <lool> tweaks
[14:32] <pitti> lool: merci
[14:32] <pitti> freeflying: in lp:langpack-o-matic, support-depends/*
[14:32] <pitti> freeflying: you can tell me what needs to be changed, or do a branch
[14:33] <pitti> freeflying: then I'll need to rebuild the package (that happens mostly automatically)
[14:33] <freeflying> pitti, I will make a branch, and send you for review
[14:33] <pitti> freeflying: thank you!
[14:33] <freeflying> pitti, or which way you prefer?
[14:34] <pitti> freeflying: branch sounds great
[14:35] <freeflying> pitti, ok
[14:37] <pitti> tseliot: FYI, I'm going to convert bcmwl to the new dh_modaliases in lp:ubuntu/bcmwl, so that I have a real-world test case for jockey development
[14:38] <lamont> pitti / cjwatson: still wondering about those livecdfsbuilds?
[14:38] <tseliot> pitti: great! I look forward to seeing the result of your work :)
[14:38] <pitti> lamont: cdimage@antimony:~$ ps ux|grep buildlive|wc -l
[14:38] <pitti> 56
[14:38] <pitti> lamont: so, yes
[14:39] <pitti> tseliot: dh_modaliases exists now, test case, too; now I need to add the jockey support for it
[14:39] <pitti> tseliot: (exists in my local branch, not uploaded yet)
[14:39] <freeflying> pitti, I plan to make language-support-input-zh-hans depends on ibus | fcitx, does the scripts support it?
[14:39] <pitti> freeflying: yes, the dependencies are just copied verbatim
[14:40] <tseliot> pitti: good. I'll do my part in nvidia-*, fglrx and in nvidia-common (the python library) when dh_modaliases is uploaded
[14:40] <freeflying> pitti, and there is no natty available under support-depends, so I'd make changes in maverick? thanks
[14:41] <pitti> freeflying: actually no, we need to copy maverick/ to natty/ first and then change stuff there
[14:41] <pitti> freeflying: it's the first support-depends change in natty
[14:41] <freeflying> pitti, I see
[14:42] <cjwatson> pitti: is that something that somebody needs a reminder of as part of NewReleaseCycleProcess?
[14:43] <lamont> pitti: you just want me to kill the amd64/i386 livefs builds with fire?
[14:43] <freeflying> pitti, so are you going to copy it first, and then I make my branch? or vice versa?
[14:43] <pitti> cjwatson: we could add it there, but since these never get uploaded automatically, it could just happen when first needed
[14:43] <cjwatson> hm, ok
[14:43] <pitti> freeflying: I can do that now and push if you want to
[14:44] <pitti> freeflying: (before you branch)
[14:44] <pitti> cp -r support-depends/{maverick,natty}; bzr add support-depends/natty; bzr commit
[14:44] <pitti> something like that
[14:45] <freeflying> pitti, thanks, then I will branch it after your push :)
[14:45] <Rovanion> When running autogen.sh to build Docky from source I get the error that I'm missing the package: 'gnome-keyring-sharp-1.0'. There seems to be no such package in the Ubuntu repositories or Docky PPA. What can I do?
[14:45] <pitti> freeflying: done
[14:46] <pitti> lamont: I guess we can just eradicate them all and start over at that point; not much value at trying to rescue the two "good" ones (if there are any)
[14:46] <Laney> Rovanion: This isn't the channel for such questions, but that is an error for pkg-config. The file you're looking for is called gnome-keyring-sharp-1.0.pc. It's in libgnome-keyring1.0-cil-dev.
[14:46] <Laney> (in general, try apt-get build-dep packagename)
[14:46] <lamont> amd64 had nothing queued, i386 had a plethora
[14:47] <Rovanion> Laney, apt-get build dep has been failing because, according to #ubuntu, some amd64 repository is down
[14:48] <lamont> i386 is clean and waiting for you
[14:48] <pitti> lamont: cheers; buildlive processes are down to 8 now (from 56)
[14:49] <ml> hello. im looking for an ubuntu dev to help resolve a package issue regarding main inclusion
[14:49] <pitti> lamont: for xubuntu, kubuntu, mythbuntu, and ubuntu DVD
[14:49] <lamont> cool.   back to my day off then
[14:49] <pitti> lamont: oh, enjoy Thanksgiving!
[14:49] <Rovanion> Laney, I seem to have cleared my xchat log with a keybinding. What were you saying that I should do? And forgive me for using the wrong channel. I thought this was where I should turn to get help when developing in an Ubuntu environment
[14:49] <pitti> lamont: will the remaining 8 just time out by themselves?
[14:49] <lamont> which architecture are they?
[14:50] <pitti> hm, how do I tell?
[14:50] <lamont> hrm... /me goes and looks
[14:50] <pitti> ssh -t -o StrictHostKeyChecking no -o BatchMode yes buildd@royal.buildd /home/buildd/bin/BuildLiveCD -s ps3 -d natty xubuntu
[14:50] <cjwatson> look for the ssh processes and look up the hostnames in cdimage/bin/buildlive
[14:50] <pitti> lamont: oh, royal -- is that ppc?
[14:50] <lamont> ppc
[14:50] <pitti> cjwatson: right, figured a second after I asked, sorry
[14:50] <cjwatson> powerpc+ps3 runs sequentially after powerpc
[14:50] <lamont> more to the point, what machines are they.
[14:50] <cjwatson> so that would be the natural result of killing a powerpc livefs build
[14:51] <pitti> lamont: I see exactly one ssh process to royal
[14:51] <lamont> I only killed the ones on cardamom
[14:51] <lamont> from 10:06 london time today
[14:51] <lamont> want it dead, or let it run?
[14:52] <Riddell> ml: what's up?
[14:52] <pitti> lamont: I guess kill them all for now
[14:52] <pitti> lamont: I have a hunch that they took ages because of the apt compressed indexes thing
[14:52] <pitti> that hit UEC builds as well
[14:52] <pitti> I uploaded a new apt this morning which reverts that
[14:53] <pitti> so they will hopefully work now
[14:53] <ml> Riddell, i need to get help to resolve lp bug #311029 if possible. to resolve it we need to move libssh2-dev to main. current situation is that curl is configured without ssh support because libssh2-dev is in universe
[14:53] <lamont> I see no ssh-invoking-BuildLiveCD processes on antimony
[14:53] <lamont> s/no/no more/
[14:54] <ml> Riddell, decision to disable ssh in curl was made in lp bug #175891
[14:54] <pitti> lamont: I killed the cron.daily-live processes around it now, so that they stop running into each other
[14:55] <apw> is anyone running near alpha-1 natty with the traditional UI ?
[14:55] <pitti> lamont: as I said, there was just one:
[14:55] <apw> i don't seem to have any window decorations
[14:55] <lamont> cool. victory and turkey are mine
[14:55] <pitti> cdimage  22326  0.0  0.0  46384  3392 ?        S    10:26   0:00 ssh -t -o StrictHostKeyChecking no -o BatchMode yes buildd@royal.buildd /home/buildd/bin/BuildLiveCD -s ps3 -d natty xubuntu
[14:55] <pitti> lamont: thanks a bunch!
[14:55]  * apw notes that in english 'thanks a bunch' is generally carries negative connotations
[14:56] <pitti> apw: thanks for pointing out
[14:56] <pitti> lamont: so, "thank you very much" :) (and enjoy the turkey)
[14:56] <apw> 'thanks a lot!' is more happy sounding
[14:56] <diwic> pitti, setting "APPORT_SYMPTOMS_DIR=. ubuntu-bug audio" does not seem to work, it still looks for it in /usr/share/apport/symptoms
[14:56] <lamont> apw: depends on the tone.
[14:56] <Riddell> ml: we generally don't want two libraries in main doing the same thing, and libssh is already in main, so a start would be to check if curl can be made to use libssh instead of libssh2 or if whatever uses libssh can be made to use libssh2
[14:57] <pitti> diwic: hmm:
[14:57] <pitti> symptom_script_dir = os.environ.get('APPORT_SYMPTOMS_DIR',
[14:57] <pitti>                                     '/usr/share/apport/symptoms')
[14:57] <diwic> pitti, what file is that in?
[14:57] <pitti> diwic: does it work with `pwd`? there might be a chdir issue here
[14:57] <lamont> apw: interesting, both 'thanks a lot' and 'thanks a bunch' (and 'thank you very much') can go either way easily
[14:57] <pitti> diwic: /usr/share/pyshared/apport/ui.py
[14:58] <apw> lamont, yeah though i tend to assume bunch is bad and lot is good when in a tonless environ such as here
[14:58] <ml> Riddell, okay hm. i read some about that and it seems to me that libssh2 is superior (support multithreading, active developed and so on) but i understand the reasoning. heres what i refer to http://www.libssh2.org/libssh2-vs-libssh.html
[14:58] <lamont> I'll remember that.:-p
[14:58] <apw> :)
[14:58] <diwic> pitti, aha, I'm running a too old version of apport, I guess
[14:59] <pitti> diwic: ah, sorry; it's just in natty
[14:59] <lamont> I mostly go with my knowledge of the speaker, and assume they're thanking me if I don't know them.  That has the bonus value of annoying the sarcastic unknown twits
[14:59] <Riddell> ml: but otherwise you want to follow https://wiki.kubuntu.org/MainInclusionProcess to get libssh2 into main
[15:00] <diwic> pitti, as a workaround, can I copy ui.py to ".", hack it, and have PYTHON_PATH set to ".", would it pick up the right ui.py then?
[15:00] <ml> Riddell, also cant find any evidence that curl would compile with libssh, only libssh2 is mentioned in the manual
[15:01] <pitti> diwic: yes, except that it's PYTHONPATH :)
[15:01] <pitti> diwic: or install python-apport from natty
[15:01] <Riddell> ml: so needs checking if kdebase-runtime and remmina can compile with libssh2
[15:02] <ml> Riddell, (i dont even use the kde kubuntu) ;-)
[15:03] <dholbach> mdz, we haven't had anything on our agenda for quite a while, but also only managed to meet very irregularly - whenever we did we put minutes into the team reports
[15:03] <mdz> dholbach, so they only go into the team reports, not also emailed to a list or something?
[15:03] <dholbach> mdz, which list do you think would make sense?
[15:03] <diwic> pitti, I noticed that more than 10 options does not work well with apport-cli, is that fixed in natty as well?
[15:04] <pitti> diwic: that's news to me
[15:04] <pitti> I don't think I ever specified more than 3
[15:04] <Riddell> ml: that's irrelevant, if you're doing packaging in ubuntu you work everywhere you need to
[15:04] <mdz> dholbach, I'm not sure. The TB usually sends them to ubuntu-devel-announce
[15:04] <dholbach> yes, because it's "technical news"
[15:05] <mdz> dholbach, what's the equivalent for non-technical news?
[15:05] <dholbach> I feel it'd drown in noise in ubuntu-users@ and other places
[15:05] <dholbach> ubuntu-news? :)
[15:05] <diwic> pitti, ok, anyway, it shows up as "10" and when you want to select that, pressing the "1" in "10" makes it take the 1 item instead
[15:05] <ml> Riddell, okay :) i checked that libssh2 dont have any dependencies outside main
[15:05] <dholbach> but I don't think that's a mailing list any more
[15:05] <dholbach> like a public one
[15:10] <pitti> tseliot: hmm - bcmwl has debian/patches/*, but the debian/rules never actually applied them
[15:10] <tseliot> pitti: right, because dkms does
[15:10] <pitti> tseliot: ah, right
[15:10] <pitti> tseliot: i. e. we need to ship them, not apply them inline?
[15:11] <tseliot> pitti: yep
[15:11] <pitti> thanks
[15:11] <tseliot> np
[15:11] <pitti> tseliot: so, no "3.0 (quilt)" for now :)
[15:11] <tseliot> pitti: no, not yet ;)
[15:13] <ml> Riddell, i created MIR request in lp bug #681423  does it look ok?
[15:17] <Riddell> ml: " it replaces libssh" have you checked if it can do that?
[15:18] <Riddell> ml: this will be a security concious package, have you checked its security history?
[15:18] <pitti> tseliot: actually, would it be that bad to apply the patches at source package build time already?
[15:19] <pitti> tseliot: it'd remove the requirement for "patch" at runtime
[15:19] <pitti> tseliot: but it might be a license problem?
[15:19] <tseliot> pitti: yes, unfortunately, since we have to apply different patches for different kernel versions
[15:19] <pitti> ok
[15:19] <ml> Riddell, hm your right. can i reword it into "it can be made to replace libssh, already in main" ?
[15:22] <Riddell> ml: well do you know that it can?
[15:23] <ml> Riddell, well yes. but it would require rewriting some parts of applications currently using libssh.. so its not a trivial undertaking. the libssh2 does not seem to offer a libssh wrapper api
[15:23] <geser> cjwatson: how can I debug the cause for my grub boot issue in natty? I get only an error about a not found UUID and a grub_rescue prompt (I try booting from a RAID)
[15:24] <Riddell> ml: right, so for the mean time it would need to duplicate what libssh does, that should go in the MIR
[15:25] <pitti> tseliot, superm1: FYI, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/bcmwl/natty/revision/21 are the packaging changes to use dh_modaliases, and http://paste.ubuntu.com/536335/ is the result
[15:26]  * tseliot has a look
[15:26] <pitti> tseliot, superm1: oh, adding a Conflicts:/Replaces: to the old modalias package now, to clean up on upgrade
[15:26] <cjwatson> geser: what happens when you 'insmod normal'?
[15:26] <cjwatson> geser: and were there any errors on upgrade?
[15:27] <tseliot> pitti: it sounds good to me
[15:27] <geser> cjwatson: I don't remember seeing any errors on upgrade
[15:28] <ml> Riddell, ok thanks ill rewrite that.. also looking for past security issues
[15:28] <pitti> tseliot: it just occurred to me that this has a nice side effect: we don't explicitly need to test for apt package sources in jockey any more, since the package headers just won't be available when the driver packages aren't
[15:31] <tseliot> pitti: do you mean to say that jockey currently checks the availability of universe and multiverse?
[15:31] <pitti> tseliot: right after a fresh installation you won't have any apt packge lists, you need to run apt-get update first
[15:31] <geser> cjwatson: "error: unknown filesystem" when I try "insmod normal"
[15:31] <pitti> tseliot: before jockey actually checked that, you would get the drivers displayed, but they wouldn't install, because the package wasn't available in apt yet
[15:32] <pitti> tseliot: now, as soon as you enable multiverse, or any other repo with extra drivers, they will just be picked up by jockey at the right time
[15:33] <tseliot> pitti: aah, I see what you mean now. It should happen the same in case of PPAs. This is definitely a welcome feature :)
[15:33] <apw> pitti, i assume you get informed of merge-requests for udev automaticially ?
[15:33] <cjwatson> geser: how about 'ls', and could you also give me the module names listed by 'lsmod'?
[15:33] <pitti> apw: I'm not sure; did you just send one?
[15:34]  * pitti syncs mail
[15:34] <apw> https://code.launchpad.net/~apw/udev/volume-key-updates/+merge/41870
[15:34] <pitti> apw: yep, got it
[15:34] <apw> pitti, cool, wondered how automated it really was
[15:34] <pitti> apw: note that I won't directly merge this, I'll apply the changes upstream and then get it from there
[15:35] <apw> pitti, ahh should i be doing something different to get these to your attention thats easier to handle?
[15:35] <pitti> apw: it's automatic and easy "enough" for me, but if you prefer, you can send format-patch files against upstream git
[15:36] <pitti> apw: (with those it'll be super-easy for me to push them upsream)
[15:36] <pitti> apw: git://git.kernel.org/pub/scm/linux/hotplug/udev.git
[15:37] <geser> cjwatson: ls => (hd0) (hd1) ; lsmod => Unknown command 'lsmod'
[15:37] <apw> pitti, will do
[15:37] <pitti> apw: (but don't worry too much about this one; I'll just get the diff from the MP)
[15:37] <ari-tczew> what do you think, makes sense rebuild libproxy in karmic? bug 456907
[15:38] <cjwatson> geser: blast, no lsmod.  I suspect the appropriate raid modules weren't built-in.  can you get in with a live CD?
[15:38] <apw> pitti, well if you are going to do so feel free to take a 'Signed-off-by: Andy Whitcroft <apw@canonical.com' for them
[15:38] <pitti> apw: I was going to set you as the author, and me as sign-off
[15:38] <pitti> credit where credit is due :)
[15:39] <geser> cjwatson: sure, luckily I have an USB stick with grub lying around from which I can boot
[15:39] <apw> for the kernel the author is also mean to sign them off, so if you need them
[15:39] <apw> sign them off as well, and everyone in the chain as it were
[15:40] <pitti> apw: ah; udev is small, we don't care much about that really
[15:41] <apw> pitti, whatever works :)
[15:41] <ebroder> apw: I'm having problems with window decorations in my natty VMs (and NVIDIA machines). It looks like compiz is erroring out (possibly segfaulting?) instead of falling back to metacity when you don't have OpenGL support
[15:41] <apw> ebroder, that might explain my mess
[15:42] <ebroder> apw: My panel still worked, so I was able to open a terminal and run metacity by hand
[15:42] <cjwatson> geser: once you've chrooted in and bind-mounted /dev /proc /sys, I need the output from 'sudo grub-install --debug <whatever your usual grub-install devices are, probably /dev/sda and /dev/sdb?>'
[15:43] <apw> ebroder, for me the appearance settings have been turned to 'None', so far turning them back has worked ...
[15:44] <ebroder> apw: Huh, if you can get compiz to run at all, sounds like you have a different issue
[15:44] <apw> ebroder, i think it just died
[15:46] <ml> Riddell, i updated description for #681423
[15:50] <Riddell> ml: groovy, now you just wait for a main inclusion person to get round to doing the review
[15:50] <Riddell> ml: you should probably comment on the original bug pointing at the MIR bug
[15:50] <ml> Riddell, thanks alot for your help! i did point out the MIR bug :)
[15:51] <ml> Riddell, somewhat offtopic, digging around i found somewhat discouraging traces from libssh developer regarding not wanting to merge the libs into a single effort: http://daniel.haxx.se/blog/2010/03/04/two-competitors-or-one-united/
[15:53] <Riddell> tsk
[15:53] <ml> riddell, and it seems libssh2 is from one of the curl devs, probably why they didnt try to support libssh
[15:56] <geser> cjwatson: http://bienia.de/tmp/grub_sda.log and http://bienia.de/tmp/grub_sdb.log
[16:00] <cjwatson> /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=abstraction --device /dev/md0
[16:00] <cjwatson> devabstraction_module=
[16:00] <cjwatson> hmm with a capital hmm
[16:01] <cjwatson> geser: I think  sudo grub-probe -vv --device-map=/boot/grub/device.map --target=abstraction --device /dev/md0  should be the next step
[16:04] <dmart> kees: hi, do you have a moment?
[16:04] <geser> cjwatson: http://bienia.de/tmp/grub-probe.log and http://bienia.de/tmp/device.map if you need the device.map too
[16:05] <cjwatson> geser: yes, indeed I was going to ask for that.  I think the problem is that you have your md devices listed in device.map
[16:06] <cjwatson> when you list a device in device.map, grub treats them as if they were BIOS-accessible
[16:06] <geser> so edit the device.map and leave only the harddisk in and rerun grub-install?
[16:06] <cjwatson> this policy was less clear in the past and maybe you added them to work around some other bug, or you might just have suffered from this changelog entry:
[16:06] <cjwatson>     - Don't include MD devices when generating device.map (if you're using
[16:06] <cjwatson>       RAID and upgraded through 1.98+20100702-1 or 1.98+20100705-1, you may
[16:06] <cjwatson>       need to fix this up manually).
[16:07] <cjwatson> (grub2 1.98+20100706-1)
[16:07] <cjwatson> there was a 1.98+20100705-1ubuntu1 version in maverick with this flaw, unfortunately
[16:07] <geser> I didn't add them manually
[16:07] <cjwatson> ok, you were probably unlucky enough to have upgraded through that version then
[16:08] <cjwatson> maybe I should try to clean it up automatically, I was just scared of breaking some working setup
[16:08] <cjwatson> it might have to be a debconf question :-/
[16:11] <geser> cjwatson: http://paste.ubuntu.com/536354/ after I deleted the entries for (hd2) and (hd3)
[16:11] <ari-tczew> doko: could you take  a look for this bug 681447 ?
[16:12] <cjwatson> hmm
[16:12] <cjwatson> geser: maybe I broke RAID scanning or something.  can you wait while I bring up a test environment?  might take a little while
[16:13] <geser> sure, no hurry
[16:13] <cjwatson> thanks
[16:13] <cjwatson> it's possible, there was a hairy patch merge that could have been relevant
[16:14] <geser> cjwatson: my setup is: md0 is a RAID1 for /boot and md1 is LVM-on-RAID1 for /, /home, etc.
[16:15] <geser> I know how I can boot my system from my usb-stick with grub, so this is only a big annoyance currently for me
[16:17] <cjwatson> I'll try to mimic that as closely as I can
[16:19] <seb128> mdz, do you still have the .crash for the bug you reported earlier? do you think you could submit it again to see if the retracer works for the glib symbols now?
[16:21] <mdz> seb128, I do, yes
[16:21] <mdz> seb128, now?
[16:21] <seb128> mdz, when you want
[16:21] <seb128> mdz, the retracer are running with the updated sources
[16:21] <mdz> seb128, uploading now, it is 60MB so will take a little while
[16:22] <seb128> ok, thanks
[16:22] <mdz> seb128, right, that's what I meant. thanks.
[16:22] <mdz> hmm, actually apport must be reporting the uncompressed size, it's only a 3.6MB file
[16:24] <mdz> seb128, https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/681460
[16:25] <seb128> mdz, thanks
[16:41] <cjwatson> http://status.qa.ubuntu.com/qapkgstatus/grub2 - quite pleased with that for a day's bug work
[16:42] <ogra_ac> yeah, you mopped up a lot of dirt today
[16:42] <doko> ari-tczew: why? just merged it
[16:42]  * ogra_ac is happy to finally have hix bugmail box getting quiet again :P
[16:42] <pitti> cjwatson: you triaged ~600 bugs?!? wow
[16:43] <pitti> cjwatson: ah, I guess part of that was your magic script you pointed out earlier?
[16:43] <cjwatson> pitti: sadly I think you read that wrong :-)
[16:43] <cjwatson> ah, the colours are misleading
[16:43] <pitti> cjwatson: triaged went up from ~30 to a little under 600
[16:43] <cjwatson> the top circle is actually where the New line will drop to when it next draws a line segment
[16:44] <ogra_ac> should be between 100 and 200 i'd guess by the bugmail i got
[16:44] <cjwatson> I don't know why the colours don't match
[16:51] <geser> can a core-dev please give-back libssh on amd64? it failed to upload due to a bug in LP. https://launchpad.net/ubuntu/+source/libssh/0.4.5-2/+build/2012262
[16:51] <seb128> geser, done
[16:52] <geser> thanks
[16:52] <seb128> yw
[16:52] <siretart> pitti: regarding the new emacs upload: with '23.1+1-4ubuntu7.1' being in lucid-proposed, would '23.1+1-4ubuntu7.1+maverick1' be an acceptable version number for maverick-proposed?
[16:53] <pitti> siretart: yes, but a simple 7.2 will do as well; or 7.10.10
[16:54] <siretart> ok. I'd prefer to go with +maverick1, because then we can still use 7.2 for the next lucid SRU.
[16:55] <ari-tczew> doko: I saw subscribed toolchain hackers, so I'd ask you for review or sponsorship
[16:56] <doko> ari-tczew: what do you win? the version number?
[16:56] <ari-tczew> doko: hmm.. more code?
[16:57] <ari-tczew> maybe merging is something another than we do
[16:57] <mdz> seb128, hmm, the backtrace in 680968 actually seems worse than the old one
[16:57] <mdz> seb128, er, I mean bug 681460 is worse than bug 680968
[16:58] <mdz> in terms of missing symbols
[16:58] <seb128> mdz, yeah, I suck, I just fixed that, I added the ddeb for updates and proposed but the normal proposed source was missing
[16:58] <seb128> mdz, if you try again that should work now ;-)
[16:58] <seb128> mdz, I checked with an apt-cache policy in the retracer this time
[16:58] <mdz> seb128, ok, i'll try again
[17:00] <seb128> mdz, thanks
[17:01] <mdz> seb128, https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/681472
[17:12] <mvo> hey cjwatson - if you have a moment I would like to hear your opinon about bug #670629 - we need to display a eula there and the current pkg just fails if the user refuses. because the package is so popular it will likely cause a lot of failed installs from people runing with noninteractive frontend or just clicking etc. so I was wondering if we should just make it install on refusal but not download the fonts
[17:12] <mvo> cjwatson: my feeling is that the current approach (exit 1) is (much) more correct
[17:12] <mvo> but the amount of dupes to expect is also substantial
[17:13] <seb128> mdz, ok, so it worked this time but you don't get a better stacktrace due to a known retracer "limitation"
[17:13] <superm1> pitti, very cool. and yeah that's a great side effect
[17:13] <seb128> mdz, it cleans all the infos on detected duplicates and it figured you opened a duplicate
[17:13] <mdz> seb128, it was good enough to get it auto-duped, though
[17:13] <mvo> (others are of course invited to comment on this issue too :)
[17:13] <seb128> mdz, right
[17:13] <cjwatson> mvo: your alternative approach sounds OK as long as it's easy to change one's mind (so dpkg-reconfigure should work, apt-get --reinstall install, etc.)
[17:14] <cjwatson> mvo: in fact you could make it quite smooth if dpkg-reconfigure installed or deleted the fonts depending on your answer :)
[17:14] <cjwatson> mvo: it's a bit nasty because dependencies on that package would be made into a lie, but that's OK in this case I think because you aren't supposed to Depends: on local fonts anyway
[17:15] <mvo> cjwatson: thanks, I have similar feelings about it, its not really 100% correct, but will save our users a lot of headache (and the triagers as well)
[17:15] <mvo> cjwatson: I will make it so that depending on the answer the fonts are either downloaded or removed
[17:16] <cjwatson> sounds good to me
[17:17] <mvo> thanks
[17:18] <Laney> how does debian get away with not having the eula?
[17:19] <mvo> Laney: I think in the long(er) run they will have to display it as well
[17:20] <Laney> presumably you'll have to alter the license of the packaging otherwise I could just remove it
[18:39] <micahg> siretart: .YR.MO.X is more common in Ubuntu, +seriesX is more common in Debian for stable updates
[18:40] <geser> cjwatson: re my grub problem: I just noticed that disks are now sdb and sdc (as sda was the usb-stick I booted from). I downgraded grub for now so I can (hopefully) boot without the usb-stick again.
[18:41] <geser> should I repeat the output you requested for sdb and sdc?
[18:42] <cjwatson> geser: I guess so although I don't think it will matter very much
[18:42] <cjwatson> geser: check that the boot loader on your USB stick is still what you expect it to be :-)
[18:45] <geser> the error I got after removing the (md0) and (md1) from the device.map remains
[18:47] <geser> at least the grub.cfg looks like I remember from the past again after the downgrade, so I hope it will boot
[18:52] <cr3> hi folks, I have a package that is mostly python but with some C compilation, so architecture: any instead of all, and when I build in the ppa, I get: /bin/sh: python2.7: not found. any ideas what might be wrong?
[18:52] <geser> cr3: most likely missing python-all-dev in Build-Depends
[18:52] <cr3> geser: will try, thanks
[19:15] <Chipaca> hi all. Is anybody here a moderator of ubuntu-devel?
[19:35] <cjwatson> Chipaca: yes.  I've approved your post
[19:35] <Chipaca> cjwatson: awesome, thank you
[19:36] <Chipaca> cjwatson: why do my emails look so vacuous on https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/032169.html, any idea?
[19:44] <cjwatson> Chipaca: I don't know, sorry.  compare mime structures?
[19:44] <Chipaca> cjwatson: yeah, got to do that i guess
[19:45] <Chipaca> that's what i get from using a version 0.5 mua :)
[19:46] <ajmitch> Chipaca: probably mailman choking a bit when archiving it, it at least looks fine in evolution
[19:47]  * ajmitch is just trying to find out why surveymonkey.com isn't resolving :)
[19:49] <ebroder> Hmm...can anybody point me in the right direction for why plymouth wouldn't be setting the color palette or UTF-8 mode correctly on shutdown when it's running in text mode?
[20:15] <mvo> lool: can you re-push lp:~lool/vmbuilder/fix-run-script-group-perms please? LP/bzr is a bit confused currently, but if you re-push it with a new name it should be fine and then I merge it into vmbuilder
[20:15] <bdrung> ebroder: can you draft an interface for bug #681242?
[20:27] <ebroder> bdrung: Sure
[20:31] <ebroder> bdrung: Do you feel a compelling need for anything more clever than -B/--builder? I'm thinking that maybe the configuration file should be a separate bug (since I can work around that with bashrc aliases)
[20:31] <bdrung> ebroder: maybe a environment variable instead of config file?
[20:32] <bdrung> ebroder: we have already SPONSOR_PATCH_WORKDIR
[20:33] <ebroder> Environment variable works for me
[20:35] <ebroder> bdrung: Commented
[20:46] <lamont> kirkland: is this true that I hear you're trying to sneak byobu-by-default into natty?  DO NOT DO THIS
[20:55] <highvoltage> now onw.
[20:56] <highvoltage> lamont: you mean more than the byoby-enable message that's currently displayed at login?
[20:58] <lamont> highvoltage: byobu's belief that admins log into a machine to monitor it is just one of the many issues I have with that can of c*^*()&9
[20:58] <lamont> and yeah, that
[20:58] <lamont> s part of it
[21:25]  * quadrispro doing a bit of sponsoring
[21:29] <sebner> quadrispro: good to see you, quick question, when I want a dependency on jackd (no b-d, just dependency), which package should I use? jackd, jackd2, ..?
[21:30] <quadrispro> sebner, jackd. It depends on jackd2 | jackd1
[21:31] <sebner> quadrispro: take my thanks :)
[21:31] <quadrispro> you're welcome :)
[21:43] <paissad> hello all, there are some persons who encounter a problem about the start of an init.d script
[21:43] <paissad> they say that the script start before the system gets an ip address, here is the related init.d script
[21:43] <paissad> http://ps3mediaserver.org/forum/viewtopic.php?f=3&t=154&p=39964#p39964
[21:44] <paissad> i thought that the following was enough, why is it not the case ?
[21:44] <paissad> # Required-Start:    $local_fs $remote_fs $network
[21:44] <paissad> and further, is there a workaround ?
[21:44] <paissad> thanks in advance for helping
[22:42] <Volvo> So, nmbd wont run on Ubuntu. Are there any plans to fix it so that SAMBA can work ?
[22:45] <micahg> Volvo: bug 596064
[22:51] <Volvo> It fails to start, Period. Someone has mispatched it ?
[22:53] <Volvo> Its been like this for too long. Is anyone going to fix it ?
[22:55] <Volvo> Works perfectly well if i install the upstream x2 version from source that is, from samba.org
[22:56] <Volvo> Upstream Debian -> Upstream samba.org == x2. Whats really the problem here ?
[22:56] <Volvo> seiflotfy: Hows the media TODAY :)
[22:57] <xnox> Lintian gave me this: warning: collect info objdump-info about package xiphos-dbg failed
[22:57] <Volvo> I guess that if you really want to scare off people from using Ubuntu for servers this is a way to do it.
[22:58] <xnox> should I not be building -dbg packages at all? (this is updating to newer upstream using debian packaging)
[22:58] <Volvo> xnox: YES, because wo those you cant properly debug a package as if at all.
[22:59] <micahg> Volvo: it's assigned, so it's on someone's list, idk about the priority, maybe #ubuntu-server can help
[22:59] <xnox> Volvo, Yes as in "do not build -dbg on Ubuntu, rely on -dbgsym. Do build -dbg package on Debian?"
[23:00] <micahg> xnox: no, you can build it if you want
[23:00] <Volvo> micahg: Show the bug url for the bug you showed because this has been going on for waaaay too long now. I feel a feud of some sort.
[23:00] <micahg> xnox: there are toolchain changes in natty
[23:01] <xnox> micahg, yes toolchain changes. It's just for the first time I see lintian tripping with objdump-info on a -dbg package! BTW xiphos does link agains xulrunner....
[23:02] <RAOF> Volvo: Whereas I look at that bug and see steady progress towards working out what's wrong.
[23:02] <micahg> Volvo: huh?, yes, it's marked as affecting releases back to Lucid, you might want to contact zulcss in #ubuntu-server during Canadian business hours
[23:02] <RAOF> And with patches to test, to boot!
[23:02] <micahg> xnox: I know :), is it compatible with xul20 yet?
[23:04] <xnox> Hmmm =) considering I'm upstream, I'm the first one to upgrade to natty (noone is using f15 either) and I have build problems then I don't think it is =)
[23:04] <Volvo> RAOF: Heheh, whilst id had done it in under 10 hours no matter how bad itd been you mean :) micahg: Thank you very much, ill look into that. Youre very good at what you do and i admire that. Keep up the good work!.
[23:04] <xnox> micahg, will natty ship xul-1.9.2?
[23:04] <micahg> xnox: no
[23:04] <xnox> haha =)
[23:04]  * xnox xiphos is blocking upgrades on xul20 and gtkhtml......
[23:05] <bdrung> xnox: it would help to do the gtkhtml first
[23:05] <micahg> xnox: we  either have to port it or drop it :)
[23:05] <micahg> xnox: BTW, it's not blocking for xul, just needs to be done by March :)
[23:06] <xnox> bdrung, working on it =)
[23:06] <xnox> micahg, either xul20 or webkit =)
[23:06] <bdrung> micahg: don't drop it! you will generate an angry ubuntu user otherwise, who will blame the mozilla team. :p
[23:06]  * xnox sorry to all the xul lovers =)
[23:07] <bdrung> i don't like the xul update policy
[23:07] <micahg> bdrung: 5k by install on popcon
[23:08] <micahg> bdrung: no, we'll try to help if xnox doesn't get to it first
[23:08] <xnox> omg I better hurry =)
[23:09] <xnox> 5k people but that is excluding those who are running xiphos of ppa or including those?
[23:09]  * xnox is amazed. Build finished, back to work.
[23:09] <micahg> xnox: that's only those that have popcon enabled and have ever installed it
[23:09] <bdrung> xnox: i think it includes ppas
[23:11] <bdrung> xnox: 5k popcon ~= 25k (assuming 9M user)
[23:11] <bdrung> xnox: the package with the highest popcon count that i maintain is vlc (778k)
[23:12] <xnox> 8865  libsword8                      10648   939  9263   443     3 (Unknown) for me =)
[23:12] <bdrung> micahg: you failed rounding (5955 -> 6k)
[23:13] <bdrung> oh, we have 12k for gnomesword
[23:16] <xnox> libgtkhtml-editor-3.14.so.0.0.0 is this correct?
[23:16] <xnox> it used to be libgtkhtml-editor.so.0
[23:17] <micahg> xnox: this might be useful: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[23:19] <xnox> "bash upstream with libtool manual" yes i do remember reading that..... long time ago.
[23:19] <xnox> It's just I don't uderstand why they renamed libgkthml-editor now, even though it doesn't build with gtk3 yet =)
[23:20] <micahg> xnox: I have to give you the link because I still don't know exactly how it works :)
[23:21] <Volvo> micahg: There seems to be absolutely no interrest in #ubuntu-server to make any kind of server going.
[23:22] <micahg> Volvo: it's a holiday in the US and evening/night in Europe, so you're not likely to get much of a response right now
[23:23] <Volvo> micahg: Aha, holiday. Im in Europe myself and im mostly online to do what i like best. Code for OSS and answer users questions.
[23:23] <Volvo> Maybe theyre microsofters that doesnt like GNU/Linux ... im just guessing of course.
[23:23]  * micahg has no where to be for the Holiday so just answering queries in IRC :)
[23:23] <xnox> Is 6k users enough to push updates to backports? =)
[23:24] <micahg> xnox: sure, as long as there are no crazy rdepends
[23:24] <Volvo> Thats what good people do.
[23:24] <xnox> Our ppa is very popular but backports can have a wider audience ;-)
[23:24] <Volvo> Microsoft people go to conferences (booring ones) sit there and get bum-rot :)
[23:25] <bdrung> xnox: 1 user would be enough for backports. :)
[23:25]  * micahg is almost an official backporter
[23:26] <bdrung> micahg: i am waiting for the backport natty changes for not installing all backports by default
[23:26] <Volvo> micahg: Be honest, how long have you been packaging for ? / I can help if i wish.
[23:27] <micahg> Volvo: I've been working with packaging for about a year and a half now
[23:27] <xnox> micahg your are awesome =)
[23:27] <Volvo> micahg: Not bad, not bad at all.
[23:28] <micahg> Volvo: I still have plenty to learn
[23:28] <Volvo> micahg: And learn you shall.
[23:28] <bdrung> it's an exponential learning curve :)
[23:28] <xnox> BTW I have just graduated with Electonics Engineering degree MEng. I'd love get into Open-source / linux / with packaging stuff work. But so far I have found just one graduate entry level job in the uk.
[23:28] <xnox> I wish there were more jobs in OSS.
[23:29] <Volvo> micahg: Uni student, private or company etc ?
[23:29] <micahg> xnox: http://webapps.ubuntu.com/employment/
[23:29] <bdrung> micahg: wow, that list got quite long
[23:29] <micahg> Volvo: working for a company
[23:29] <micahg> bdrung: indeed :)
[23:30] <Volvo> micahg: If i look at their frontpage or some subpage i dont see "Microsoft gold partner", right ?
[23:30] <micahg> Volvo: you might...
[23:30] <micahg> actually noy
[23:30] <micahg> *not, but I think they are anyways
[23:31] <micahg> Volvo: my work happens to be with OSS though
[23:31] <Volvo> Hmmz, doesnt mean youre tainted, but if you want you can priv the name and ill look it up.
[23:32]  * micahg wonders if this qualifies for OT
[23:32] <Volvo> Ah! Cool. There are many companies that love OSS
[23:32] <Volvo> For Oh so many reasons or treasons towards them.
[23:32] <bdrung> micahg: do you have time for sponsoring?
[23:33]  * xnox facepalm. I had xiphos in the /usr/local/bin from development........
[23:33] <micahg> bdrung: maybe, I was going to look at the rhythmbox-radio-browser bug
[23:33] <bdrung> xnox: why should a ubuntu developer install something in /usr/local? ;)
[23:33]  * xnox wants bash to print `which $command` if it's not in /usr/bin or /usr
[23:33] <bdrung> micahg: can you look at bug #678283?
[23:34] <micahg> bdrung: sure
[23:34] <bdrung> micahg: thanks
[23:34] <micahg> bdrung: in a bit though?
[23:34] <bdrung> micahg: it doesn't hurry
[23:34] <xnox> bdrung, waf-cache + build + install < 2s. Debuild + dpkg + libeatmydata > 2s
[23:34] <micahg> bdrung: k, I'll do it after dinner
[23:35] <bdrung> xnox: either build a package or build it locally (without installing it)
[23:35] <xnox> right xiphos works fine with new gtkhtml and xul20 =)
[23:35] <xnox> uploading to ppa for testing =)
[23:55] <quadrispro> bye all