[00:07] <bdrung> tumbleweed: you are very involved in Debian. how is your relation to Ubuntu?
[00:08] <bdrung> tumbleweed: what are your plans as MOTU besides caring about your (http://qa.debian.org/developer.php?login=stefano@rivera.za.net) packages?
[00:08] <tumbleweed> bdrung: I use Ubuntu and Debian, and work to fix things in both of them
[00:09] <bdrung> tumbleweed: did you other things besides sync and merges?
[00:09] <tumbleweed> yes, I can't say if I'll be a busy MOTU forever
[00:10] <tumbleweed> but I've been enjoying what I've been doing, and don't intend to just stop
[00:11] <tumbleweed> no, I haven't done much else. I've got my eyes on my first SRU, but the fix needs to get into maverick first
[00:11] <bdrung> tumbleweed: do you like to work on the sponsors queue once you are motu?
[00:12] <bdrung> +1 for "Ubuntu developers seem to have a hard time pushing patches upstream (either to Debian or the upstream developers). Yes, syncing and merging takes a lot longer when you do this, but it's the right thing to do and should save time in the long run. I intend to (and have begun) improve on this. "
[00:12] <tumbleweed> yes, many ubuntu patches are very quick and dirty. It takes time to do a better job :/
[00:13] <tumbleweed> as to sponsors queue, I certainly intend to have a shot at it. It's hard to know until one gets there...
[00:15] <lfaraone> bdrung: sync-package is included in ubuntu-dev-tools despite not being shipped. it's just a good idea to have them all in one place, even if they are "unsupported", I think.
[00:15] <lfaraone> wgrant: ^^
[00:15] <bdrung> tumbleweed: yes, that's not easy. the beginners have time for it, but not the knowledge and rights to do it. when they become MOTU, they have other things to do than sponsoring.
[00:16] <bdrung> lfaraone: i don't think that this makes sense. if not installed, you still have to pull a bzr branch.
[00:17] <lfaraone> bdrung: yes, but it's all maintained in one tree.
[00:17] <bdrung> wgrant: your opinion please
[00:17] <tumbleweed> bdrung: that's something about MOTU. It forces you to learn everything that you thought you could avoid learning :)
[00:18] <bdrung> :)
[00:18] <wgrant> bdrung, lfaraone: I think keeping it in the u-d-t branch is an OK idea.
[00:18] <bdrung> tumbleweed: MOTU is just about typing the right commands :)
[00:18] <wgrant> It's not optimal, but it's probably better than keeping it elsewhere.
[00:19] <lfaraone> bdrung: and not blowing things up.
[00:19] <bdrung> lfaraone: blowing things up?
[00:19] <tumbleweed> lfaraone: lol
[00:20] <lfaraone> bdrung: re the meaning of MOTU, it's about using the right commands and not causing things to break :P
[00:20] <bdrung> lfaraone: ah, ok. having two discussions at once in one channel can confuse (me).
[00:22] <bdrung> lfaraone: [MOTU] ...and to dominate the world. *muhahaha*
[00:23] <lfaraone> wgrant, bdrung, ideally, we'll get the "sync this" button and we can remove most of the functionality from ack-sru and replace it with launchpad API calls. But I agree that it will still be useful to have this script there for potential shipping in the package later. We're more likely to get code review, and encourage people to work on it.
[00:23] <lfaraone> *button in the launchpad UI
[00:24] <wgrant> lfaraone: Yes, we're thinking about that... but it's going to be a community effort.
[00:24] <lfaraone> wgrant: what work needs to be done?
[00:26] <wgrant> lfaraone: A few things like making copies go through the normal NEW/UNAPPROVED queues, we need to be able to send announcement emails without having a .changes files, that sort of thing.
[00:27] <bdrung> tumbleweed: endorsement given.
[00:28] <tumbleweed> bdrung: thank you
[00:28] <bdrung> tumbleweed: be happy that i was faster than with my motu interview ;)
[00:30] <tumbleweed> heh
[00:30] <tumbleweed> it's 1:30am and I didn't sleep last night. I should get to bed
[00:31] <lfaraone> bdrung: re ack-sru, shall I do the merge, then?
[00:37] <bdrung> lfaraone: i have local changes. please let me commit them first
[00:37] <lfaraone> bdrung: sure.
[00:57] <cpscotti> Hey, little question about SRUs: when the fix has already been uploaded to -proposed and all (just awaiting verifications), does one needs to do anything at all? Or I just have to wait paciently for the sru team?
[00:59] <cpscotti> (bug 480772 by the way.. )
[00:59] <micahg> cpscotti: if they're subscribed, wait a few days, if it's urgent, you can try pinging someone
[01:00] <cpscotti> ahh ok.. it's not urgent.. so its ok
[01:00] <cpscotti> micahg:  thanks!
[01:20] <micahg> cpscotti: also, it's a holiday weekend in the US and UK :)
[02:28] <poolie> ScottK, hi
[02:28] <ScottK> poolie: Hello.
[02:29] <poolie> can we have a talk about dkim, maybe in #launchpad-dev, to avoid roundtrips?
[02:29] <ScottK> Sure.
[06:46] <CyberCod> when a package is broken in universe, and the email address for the maintainer reads as ubuntu-motu@lists.ubntu.com (but that just gets delivery failure)  then who do I tell about it?
[06:50] <micahg> CyberCod: you can file a bug
[06:50] <micahg> CyberCod: ubuntu-bug packagename
[06:50] <CyberCod> yeah, I'm in the process of that now
[06:50] <CyberCod> thanks
[06:51] <micahg> CyberCod: if a few days go by w/out any feedback, feel free to hop in #ubuntu-bugs and ask someone to take a look
[07:16] <dholbach> good morning
[08:21] <Rhonda> ScottK: Grats on becoming DD, btw.! :)
[09:07] <rodrigo_> hi
[09:51] <jariq> I've just realised that binary packages in Ubuntu are not signed. Is this true?
[09:52] <jpds> jariq: How do you mean, not signed?
[09:53] <jariq> jpds: digitaly signed with gpg.. so one can verify integrity and origin of package
[09:53] <jpds> jariq: The Release's files are signed.
[09:54] <jpds> eg, http://gb.archive.ubuntu.com/ubuntu/dists/maverick/
[09:55] <jariq> jpds: exactly.. so it is possible to verify integrity of package when downloading from mirror.. but I cannot verify integrity and origin of package downloaded and stored on disc..
[09:55] <jariq> because package itself does not contain any signature
[09:55] <geser> jariq: the debs itself aren't signed (in Debian neither too)
[09:56] <jpds> jariq: You can check the chain of checksums.
[09:57] <geser> jariq: the Packages files contain crypto hashes (md5,sha1,sha256) of the deb, the Release file has crypto hashes of the Packages files, and the Release file is gpg-signed
[09:58] <jariq> geser: but this files are stored only on mirror... so there is no way to verify single package in offline mode?
[09:59] <geser> jariq: they are also in /var/lib/apt/lists (else apt wouldn't know which packages are available and their dependencies)
[09:59] <Laney> apt does this verification for you when it downloads the package
[09:59] <geser> but this only works for packages that are still published, you can't revalidate old package versions
[10:01] <dupondje> dholbach: thx for ack'ing ;)
[10:01] <dholbach> dupondje: de rien
[10:02] <BlackZ> hey dholbach
[10:03] <dholbach> hi BlackZ
[10:03] <jariq> I can see the pros of signing just the Release files but this way offline systems without access to mirror cannot verify origin of packages :(
[10:04] <dupondje> dholbach: My name looks french, but i'm dutch speaking :)
[10:05] <dholbach> dupondje: ahhhh ok... alstublieft :)
[10:44] <piju> hello all
[11:14]  * geser starts to hate haskell packages
[11:15] <geser> Laney: do you have a list in which order the haskell packages need to get rebuild to keep them installable on all architectures?
[11:16] <Laney> I have a graph
[11:16] <Laney> http://orangesquash.org.uk/~laney/haskell-installability/
[11:17] <Laney> geser: what's the problem?
[11:17] <jpds> Laney: What happened to ia64?
[11:17] <Laney> jpds: We removed haskell there for lucid as ghc is unbuildable
[11:19] <geser> I was looking at a FTBFS on AMD64 (twidge) and saw that one build-dep can't get installed because of those hashes(?) in the dependencies
[11:19] <Laney> yes, abi hashes
[11:19] <geser> so I uploaded as haskell-hsh rebuild to fix the dependencies
[11:20] <geser> just to get mailed by the buildds that the dependencies on the other arch (i386, armel, etc) are even more broken
[11:20] <Laney> yep
[11:20] <Laney> I usually don't look at it until later in the cycle
[11:20] <Laney> until someone pokes me that they want xmonad to work
[12:04] <soren> If anyone here is better at automake than I, I'd really appreciate a bit of assistance. I'm calling AM_INIT_AUTOMAKE([-Wall]) in configure.ac, but -Wall never gets passed to gcc. The way I read the docs, this should just happen without any further glue. What might be the problem?
[12:05] <soren> forget it.
[12:05] <soren> I'm an idiot.
[12:05] <soren> Really.
[12:13] <tamrat> quick question: it is not needed to open a sync request for new packages in debian that are not present in ubuntu, right?
[12:14] <BlackZ> when I do a merge should I do the debdiff between the old ubuntu modified package and the new one modified, right?
[12:21] <geser> tamrat: right, they should get synced any time before DebianImportFreeze. if you notice after DIF that it still didn't get synced file a sync request
[12:22] <geser> BlackZ: between "new" Debian and "merged" Ubuntu
[12:22] <tamrat> geser: ok cool
[12:39] <BlackZ> geser: I'd be happy if you can sponsor it: bug #502601
[12:43] <geser> BlackZ: don't forget to run "update-maintainer" (or do it by hand) and put the old Ubuntu changelog entries into the correct place (keep the sorting of the version)
[12:43] <BlackZ> geser: err
[12:43] <BlackZ> doing now
[12:50] <BlackZ> geser: done, check now
[12:51] <geser> BlackZ: looks good, but we usually don't touch Standards-Version. But no need to redo the debdiff for it (I will change it back during sponsoring).
[12:52] <BlackZ> geser: OK, thanks
[14:25] <Rhonda> ajmitch: Around? May I bug you about bug 528957 for a moment?
[14:35] <jariq> Could anyone please suggest package that uses CMake I could use as an example ?
[14:37] <Rhonda> Would "sudo add-apt-repository ppa:ajmitch" add it with "lucid" only for people on lucid, or would that pull in everything from there?
[14:38] <JontheEchidna> jariq: Do you want one to research how to package a cmake app, or how to use cmake in general?
[14:41] <geser> Rhonda: it should only create an entry for lucid (you can check in /etc/apt/sources.list.d/)
[14:42] <jariq> JontheEchidna: how to package a cmake app
[14:43] <Rhonda> hmm
[14:44] <Rhonda> add-apt-repository seems to depend on networking and especially keyserver being accessible.  %-/
[14:46] <geser> it also fetches the PPA signing key
[14:47] <JontheEchidna> jariq: debhelper has built-in cmake support, so as long as the packaging doesn't need to be too complicated you can just do the simple "dh $@" debian/rules file, I'm fairly sure
[14:48] <JontheEchidna> like so: http://pastebin.com/gLbT5t3q
[14:48] <Rhonda> geser: Right, it times out but the sources.list.d file is there. Thanks. :)
[14:54] <jariq> JontheEchidna: more complex example would be great
[14:57] <tumbleweed> BlackZ: you marked bug #587706 as wishlist. It's a pretty major issue for everyone in South Africa, I'd triage it a little higher
[14:57] <BlackZ> tumbleweed: generally the merge requests are with the "Wishlist" importance
[14:58] <tumbleweed> BlackZ: I suppose so. But I only solved it with a merge because I got the DD to sort it out first
[15:00] <BlackZ> tumbleweed: also, "This bug affects 1 person", I don't see many users with this problem, please read https://wiki.ubuntu.com/Bugs/Importance
[15:01] <BlackZ> all merges are "important"
[15:01] <tumbleweed> BlackZ: I am aware of that. Unfortunatly we don't have enough able hands in ZA who care. Everyone switched to UK dictionaries years ago
[15:02] <BlackZ> maybe we can set it with the "medium" or "high" importance in debian/changelog but I can't change the bug's importance
[15:02] <tumbleweed> (because of this issue)
[15:02] <tumbleweed> BlackZ: don't worry
[15:03] <BlackZ> tumbleweed: for further information ask in #ubuntu-bugs
[15:05] <tumbleweed> BlackZ: as a non-bug-control member, I've never considered importance on merge requests. They've only ever been set my the uploader.
[15:05] <tumbleweed> I just brought this up because the equivilent bug in Debian was grave
[15:06] <BlackZ> tumbleweed: assuming it's, we have a policy for our bugs
[15:07] <tumbleweed> BlackZ: yes, nm
[15:08] <BlackZ> tumbleweed: however I will try to help you with the merge
[15:08] <BlackZ> I have bookmarked it
[15:08] <tumbleweed> BlackZ: thanks
[15:10] <BlackZ> tumbleweed: but as I can see it's in the sponsor queue, so just wait
[15:10] <BlackZ> (with the debdiff)
[15:10] <fibi> hi
[15:10] <fibi> i have a quick question
[15:10] <fibi> what is the prefered way when packaging python packages: python-support or python-central
[15:12] <tumbleweed> fibi: python-support
[15:12] <tumbleweed> fibi: #debian-python on OFTC for help there
[15:12] <BlackZ> fibi: it depends, I'd use python-support in Build-Depends-Indep
[15:12] <BlackZ> (generally)
[15:13] <fibi> okay, thanks
[15:35] <ScottK> Rhonda: Thanks.
[15:42] <\sh> bah...now I know more about initramfs as I really wanted to know
[15:48]  * imbrandon yawns
[16:12] <blue_anna> does the powerpc64-smp kernel actually run in 64bit mode?
[16:23] <blue_anna> aye, now I know
[16:38] <DeeJay1> hi, question: is there some script to compare debian revisions? I mean to do sth like "compare 0.6.1 0.6.0+gitxxxx" (of course a bit more complicated)
[16:40] <geser> DeeJay1: dpkg --compare-versions 0.6.1 \< 0.6.0+gitxxxx && echo smaller || echo larger or equal
[16:41] <DeeJay1> ha, too many switches to dpkg ;)
[16:41] <micahg> geser: do I need to have my wiki page done to be on the agenda for DMB or just done by the meeting?
[16:49] <geser> micahg: preferable mostly done when you apply to give anyone (including DMB) a chance to look at it before the meeting. of course, you can add comments, endorsements, etc. to your wiki page even after you applied. the idea is to have all the endorsements and comments on your wiki page when you apply so your application doesn't get blocked on your sponsors finding time to add their endorsements (and as
[16:49] <geser>  everyone else sponsors tend to also get busy)
[16:51] <micahg> geser: k, I'll try to get that up in the next couple days then, thanks
[18:36] <ari-tczew> geser: the package which you've sponsored is FTBFS! https://launchpad.net/ubuntu/+source/steam/2.2.31-6ubuntu1/+build/1767467
[18:40] <blueyed> Is there a way to run .desktop files? I've heard about run-desktop in some security related posts, but that was meant as a prototype apparently only. In particular, I want to run *.desktop from ~/.config/autostart for the awesome window manager.
[20:18] <geser> ari-tczew: I know :( I test-built it on AMD64 where the build succeeded.
[20:18] <ari-tczew> heh
[20:19] <geser> I have no idea where amd64 and armel are different to i386 and powerpc which makes it build or fail
[20:20] <BlackZ> geser: for steam?
[20:20] <geser> yes
[20:20] <BlackZ> geser: I have tried to add the flag -wno-stack-protector
[20:21] <BlackZ> now uploading on my PPA
[20:22] <geser> this option should only be used rarely as it disables the stack protection which is a good idea
[20:22] <geser> it should only be used for packages that don't link to libc (e.g. bootloaders)
[20:23] <geser> and the ld call before that error even mentions -lc
[20:23] <BlackZ> hmm
[20:26] <geser> kees: as you are familiar with the stack protection, do you have an idea why this linking fails? http://launchpadlibrarian.net/49499611/buildlog_ubuntu-maverick-i386.steam_2.2.31-6ubuntu1_FAILEDTOBUILD.txt.gz
[20:28] <kees> ges	looking
[20:29] <BlackZ> kees: could the flag -wno-stack-protector be a solution?
[20:29] <geser> kees: the build fails with "undefined reference to `__stack_chk_fail_local'
[20:30] <kees> wwell, the issue is that it doesn't seem to be linking against libc correctly
[20:30] <geser> kees: only on i386 and powerpc? as the packages builds on amd64 and armel
[20:30] <kees> normally that error comes from things that are built without libc and don't specify no-stdlib
[20:31] <kees> that's even stranger
[20:31] <geser> the ld call contains even -lc
[20:31] <geser> which should make it link to libc
[20:32] <kees> yeah, i saw that. really weird. what happens if it drops the -lc ?
[20:32] <kees> i can dig into it in a few hours. otherwise we can follow the CompilerDefaults wiki
[20:35] <geser> kees: no hurry, I just wanted to ask if you perhaps had an idea why it fails before the stack protection gets disabled for this package
[20:42] <kees> geser: if it does get disabled, please add it to CompilerDefaults and open a bug
[20:42] <geser> sure
[20:42] <kees> thx :)
[20:43] <geser> BlackZ: do you have a maverick i386 pbuilder where you can test-build it easily? I've only an amd64 one ready.
[20:44] <BlackZ> geser: I have amd64 too
[20:44] <BlackZ> :(
[20:46] <geser> http://erl1.wordpress.com/2009/11/16/reinstallingmaking-ns-2-on-ubuntu-9-10/ mentions a similar problem and a solution (uses gcc -shared instead of ld -shared for linking) but I can't test it easily as it builds on amd64
[20:58] <arand> geser: I've got a kvm i686 with pbuilder up here, would it be of any help?
[21:06] <geser> sure, once I have something to test (but I'm currently lacking a real idea as this is a little above my knowledge)
[21:55] <dupondje> somebody knows if there is a way to build packages remotely ?
[21:56] <dupondje> want to build maverick packages on my remote debian system :)
[21:56] <dupondje> want to abuse the quad core for it :D
[21:56] <micahg> dupondje: pbuilder?
[21:57] <dupondje> but is there some easy way ? like pbuilder interacts remotely ?
[21:57] <dupondje> or really need to ssh and do pbuilder remote ?
[21:57] <micahg> dupondje: ssh?
[22:02] <pochu> dupondje: you can set up a build farm. DktrKranz wrote something for that, can't remember its name though
[22:04] <DktrKranz> dupondje, pochu: something like that is called debomatic
[22:07] <pochu> that's it!
[22:07] <pochu> hi DktrKranz :)
[22:08] <DktrKranz> hola pochu :)
[22:12] <dupondje> thx :D
[22:14] <sebner> pochu: debobreaking?
[22:49] <arand> geser: Seems like if you (blindly, as per the blog) replace "ld -E -shared" with "gcc -shared" in the configure(.ac) files, it at least build fine.
[23:03] <arand> geser: Did you have a bug for the failed build?
[23:52] <arand> geser: FYI: reported bug #588519 with a working fix (not sure if it's a *sane* fix though)