[00:11] <crimsun> StevenK: will you be handling on the libsdl1.2 merge?  (I'm looking at bug 180221 ATM)
[00:11] <ubotu> Launchpad bug 180221 in libsdl1.2 "sound doesn't work using libsdl1.2debian-pulseaudio binary package" [Medium,Fix committed] https://launchpad.net/bugs/180221
[00:12] <crimsun> handling the*
[00:13] <StevenK> It needs to be merged again?
[00:13] <crimsun> yep, new upstream version
[00:14] <StevenK> Grumble. asc doesn't differ with Debian
[00:15] <StevenK> crimsun: Yeah, I'll look at merging it. I'll bleat if I have any issues
[00:15] <crimsun> StevenK: ok, thanks.
[01:10] <somerville32> imbrandon, ping.
[01:10] <somerville32> imbrandon, Where can I find the script to sync accounts with launchpad groups on a machine?
[01:16] <nenolod> somerville32, it's part of the revu code
[01:16] <YokoZar> Would adding myself as a MOTU candidate to the MOTU meeting agenda be appropriate?
[01:17] <nenolod> DarkMageZ, have you contacted debian-legal yet ?
[01:17] <nenolod> DarkMageZ, or did you chicken out?
[01:19] <DarkMageZ> nenolod, i'm polishing the email. i'll send you my draft soon
[01:19] <nenolod> groovy
[01:21] <somerville32> nenolod, I see the code to grab the gpg keys but are you sure the code for getting the ssh keys are in the revu trunk?
[01:21] <crimsun> YokoZar: normally you'd send an e-mail to motu-council@u.c detailing your application.  It's standard practice to CC people who can vouch for you.
[01:21] <YokoZar> crimsun: I've already done that
[01:22] <crimsun> YokoZar: if you feel you need to say something in the meeting, then sure, please do add yourself.
[01:23] <YokoZar> crimsun: Ahh, but otherwise it's just handled by email fine?
[01:26] <crimsun> yes
[01:26] <crimsun> (I just re-read the e-mail from Sat.)
[01:27] <imbrandon> nenolod: no it isnt part of revu, somerville32 one moment
[01:27] <imbrandon> i'll find the bzr branch
[01:28] <imbrandon> Fujitsu: do we have that on LP under the ubuntuwire project yet ?
[01:29] <Fujitsu> imbrandon: It's in a bzr branch under my ~, I think.
[01:29]  * Fujitsu looks.
[01:29] <Fujitsu> orko:~fujitsu/lpusers is the bzr branch. I'll symlink it under my public_html.
[01:29] <imbrandon> kk, cool
[01:30] <imbrandon> somerville32: ^^
[01:30] <Fujitsu> somerville32: http://people.ubuntuwire.com/~fujitsu/bzr/lpusers
[01:30] <Fujitsu> Erm, permissions issue, I think.
[01:31] <somerville32> 403 :]
[01:32] <imbrandon> somerville32: note when looking at it, its talored for our use , so i would audit it before using it
[01:32] <Fujitsu> somerville32: bzr branch it.
[01:32] <imbrandon> Fujitsu has done a great job at abstracting most of it though, so should be fairly simpe to cusomize
[01:33] <imbrandon> simple*
[01:33] <somerville32> That was quick
[01:33] <somerville32> It branched just like that *snap*
[01:33] <Fujitsu> It's only one file, so...
[01:33] <imbrandon> i'd imagine there are only a few revisions, we dident have it in bzr for a long time
[01:33] <imbrandon> and its only one file
[01:33] <nenolod> imbrandon, sorry. my mistake. i thought he was looking for GPG. :)
[01:34] <somerville32> I just associated bazaar with natural slowness no matter what :P
[01:34] <Fujitsu> somerville32: It's only slow when branching enormous trees from LP, really.
[01:34] <imbrandon> or pushing them
[01:34] <imbrandon> hehe
[01:35] <Fujitsu> That too.
[01:35] <Fujitsu> Though bzr+ssh works.
[01:35] <imbrandon> would be cool if bzr kept stats on how many times a branch was "branched"
[01:36] <crimsun> to be fair, bzr 1.0 is scads faster than what was in feisty.
[01:36] <Fujitsu> The HTTP server would have to do that.
[01:36] <imbrandon> Fujitsu: right but that wouldent work for bzr+ssh etc
[01:36] <Fujitsu> crimsun: It's quite good, except for huge trees over HTTP(S).
[01:36] <somerville32> Fujitsu, Does this script crawl sub-teams?
[01:37] <Fujitsu> somerville32: +rdf does that automatically.
[01:40] <imbrandon> somerville32: as i said its talord for our use ( like where the sshd looks for key files and such, you'll likely want to change some bits )
[01:40] <imbrandon> just fyi
[01:40] <somerville32> Such as looking to ensure you're there? lol
[01:41] <Fujitsu> That bit's probably not so necessary now that we're not screenscraping.
[01:41] <imbrandon> such as /home/<user>/.ssh/authorized_keys on a "default" system instead of /srv/ssh-keys/<user>.key
[01:42] <imbrandon> and it assumes there is already a ubuntu-dev system group
[01:42] <imbrandon> and a few other misnomers
[01:42] <imbrandon> yea the sanity check for me probably isnt needed anymore now that +rdf works
[01:43] <imbrandon> before it was html scraping and it was needed to ensure the LP ui dident change unexpectedly on us
[01:43] <somerville32> Is there a reason why you place the keys in /srv/ssh-keys/ instead of the user's home directory?
[01:43] <imbrandon> to make backups on the UW servers easier
[01:43] <imbrandon> we backup the critical services but not user data
[01:43] <Fujitsu> It also means that we don't have to create ~user/.ssh if it doesn't exist, setting permissions.
[01:44] <imbrandon> right
[01:44] <somerville32> Is it possible to get sshd to look in both places?
[01:44] <imbrandon> no , unfortunately
[01:44] <somerville32> So I'll have to change the AuthorizedKeysFile option?
[01:45] <imbrandon> leaste not openssh-server with ubuntu, never looked into another sshd
[01:45] <imbrandon> somerville32: either that or the script
[01:45] <imbrandon> i would change the former though
[01:45] <imbrandon> personaly
[01:46] <imbrandon> bbiab
[01:46] <somerville32> What is the token for the username?
[01:46] <somerville32> %h is home directory from what I can gather
[01:46] <imbrandon> %u
[01:47] <Fujitsu> somerville32: Note that the script allows users to manually add additional keys to the file, if they wish.
[01:47] <imbrandon> #AuthorizedKeysFile     %h/.ssh/authorized_keys
[01:47] <imbrandon> AuthorizedKeysFile      /srv/ssh-keys/%u.key
[01:47] <imbrandon> ^^ orko's sshd_config option
[01:47] <imbrandon> if thats what you mean
[01:59] <nenolod> hmm
[01:59] <nenolod> well,
[02:00] <nenolod> DarkMageZ is about to send the report of our analysis of zsnes's legality to debian-legal. :)
[02:03] <ion_> What is the result?
[02:04] <bddebian> Heya gang
[02:04] <ion_> Hi
[02:05] <bddebian> Hi ion_
[04:39] <pwnguin> is it okay for files to retain the redhat name?
[04:39] <ScottK> TheMuso: If your up for looking into a powerpc FTBFS, http://launchpadlibrarian.net/11144671/buildlog_ubuntu-hardy-powerpc.papaya_0.97.20031122-5.3_FAILEDTOBUILD.txt.gz is available...
[04:39] <ScottK> pwnguin: Context please.
[04:40] <pwnguin> dpkg-query -S redhat-*
[04:41] <ScottK> dpkg: *redhat-** not found.
[04:41] <pwnguin> hmm
[04:41] <pwnguin> does it only search installed stuff?
[04:41] <LaserJock> yep
[04:42] <pwnguin> ok, well for example
[04:42] <pwnguin> install-data: /usr/share/app-install/desktop/redhat-manage-print-jobs.desktop
[04:44] <pwnguin> the desktop file itself also has Categories=GTK;Monitor;System;X-Red-Hat-Base;
[04:47] <ScottK> I'd say look at the licensing of the files in the package and see if Redhat claims any trademark restrictions.
[05:09] <TheMuso> ScottK: I'll look at it when I get a chance, thanks.
[05:21] <nenolod> hi.
[05:22] <vorian> aloha :)
[05:22] <nenolod> does anyone know if the audacious-1.4.5 / audacious-plugins-1.4.4 task has been looked at yet?
[05:22] <nenolod> it fixes some critical bugs
[05:22] <nenolod> and people keep filing duplicate upgrade requests
[05:26] <ScottK> TheMuso: Great.
[05:39] <slangasek> bddebian: did you get anywhere with your jugglemaster segfault?
[05:41] <ScottK> Heya bddebian.
[05:43] <bddebian> slangasek: No :-(  persia was going to check it out.
[05:43] <bddebian> Hi ScottK
[05:44] <bddebian> slangasek: I almost have newpki-client building with wx2.6 too.  Maybe it'll segfault as well. :)
[05:47] <slangasek> bddebian: you have a backtrace posted anywhere for the segfault?
[05:47] <bddebian> It's less than helpful but let me check
[05:50] <bddebian> slangasek: I have like every dbg and dbgsym package on the planet installed and I get this: http://paste.debian.net/46105
[05:51] <slangasek> eew it uses dpatch, maybe I don't care enough to look into it. :)
[05:51] <slangasek> hah, it segfaults in the C++ constructors?
[05:52] <slangasek> well, this will be fun
[05:52] <bddebian> yeah, weird huh?
[05:52] <slangasek> nah, "fun"
[05:52] <slangasek> weird would be if it segfaulted in the destructors on startup
[05:52] <bddebian> heh
[05:53] <bddebian> persia also noticed some weirdness on amd64 with -fPIC
[05:53] <bddebian> In fact I don't think it even built on amd64
[05:56] <slangasek> hmm, this is the package that was newly uploaded and depends on wxwindows 2.4, innit
[05:56] <bddebian> yup
[05:56] <slangasek> well, I'll see for myself soon enough what happens on amd64, since that's where I started
[05:56] <slangasek> /usr/bin/ld: jmdlx.o: relocation R_X86_64_32 against `JMFrame::sm_eventTable' can not be used when making a shared object; recompile with -fPIC
[05:57] <bddebian> Yep, that's it
[05:57]  * slangasek rolls his eyes
[05:57] <slangasek> Dear upstream, your source code is a waste of electrons.  Hugs and bunnies, Vorlon
[05:57] <bddebian> hah
[05:58] <slangasek> $ wx-config --ld
[05:58] <slangasek> g++ -shared -fPIC -o
[05:58] <slangasek> $
[05:58] <slangasek> yes, that's a completely wrong way to be linking an executable kthx
[05:58] <bddebian> Yeah, I had to change that.  It was doing --ldflags
[05:58] <bddebian> I know, it is still wrong but..
[06:00] <slangasek> ah, right, I see that's part of the patch.  Well, the original sin is still upstream's
[06:00] <bddebian> aye
[06:01] <slangasek> hum, this should work
[06:03] <slangasek> ok, which of the apps did you try to run that gave you this segfault?
[06:03] <bddebian> jmdlx
[06:03] <slangasek> right, the only one that's wxwidgets, gotcha
[06:04] <slangasek> no segfault on amd64
[06:04] <slangasek> will try i386
[06:04] <bddebian> what'd you change?
[06:06] <slangasek> I got rid of the wx-config --ld bit and restored the $(CXX) invocation
[06:07] <bddebian> f**king lameage :-(
[06:11] <slangasek> hmm, that seems to fix the segfault on i386 for me
[06:12]  * bddebian is an idiot as usual
[06:12] <slangasek> lots of Pango-WARNINGs about invalid UTF-8 strings...
[06:13] <slangasek> related to the style
[06:13] <bddebian> Yeah, it still needs some work with UTFication
[06:14] <slangasek> er, all ascii is valid utf8 though
[06:14] <slangasek> so the problem seems to be with passing something in that's not really a C string
[06:15] <bddebian> Does it bomb or just throw warnings?
[06:16] <slangasek> throw warnings
[06:16] <slangasek> but there's also garbage on the window
[06:17] <bddebian> :-(
[06:23] <slangasek> wouldn't the easy way of this to just be to kill the jmdlx package and say "Qt and aalib are good enough"?
[06:23] <bddebian> would work for me :-)
[06:24] <slangasek> I mean, yeesh, all it does is render a juggling stick figure
[06:24] <bddebian> Still have newpki-client and ctsim though.  I've talked to the ctsim developer/maintainer and he isn't to keen on switching :-(
[06:26] <bddebian> Anyway, I have to get my fat arse to bed.  Thanks for looking at that!  Would you mind passing along what you changed?
[06:26] <StevenK> slangasek: I wonder if I could convince to fix bug 180274 ...
[06:26] <ubotu> Launchpad bug 180274 in bluez-libs "Please sync bluez-libs (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/180274
[06:26] <bddebian> Uh oh, wife is up now
[06:27] <StevenK> convince you, even
[08:54] <persia> slangasek: Thanks ever so much for a sane solution for jmdx :)
[08:57] <slangasek> persia: I'm not convinced that the saner solution wouldn't have been to punt the package... :)
[08:58] <persia> slangasek: I'd agree with that, but don't really want to carry extra deviation if we can help it.  With luck, Helmut will apply your patch, and wx2.4 will be that much closer to going away.
[08:58] <persia> Now if only there was a similarly sane solution for gnue-*
[08:59] <persia> (and, no, that's not a request.  Those packages are in odd limbo, and are more likely to get tossed than fixed)
[09:02] <AnAnt> Hello, if I am packaging software, from which the source is in SVN, how should I mention that in the watch file ?
[09:03] <persia> AnAnt: Can you convince upstream to make a release?
[09:03] <man-di> AnAnt: watch files dont support SVN
[09:04] <AnAnt> persia: they put release as jar file
[09:04] <man-di> would probably I nice feature to have
[09:04] <man-di> AnAnt: with a version number in jar name?
[09:04] <persia> man-di: I disagree: snapshots are harder to maintain.
[09:04] <man-di> persia: in Java-Country thats unfornately a common way we need to go
[09:05] <persia> man-di: Really?  Upstream releases are that unreliable?  Unfortunate :(
[09:05] <AnAnt> man-di: I don't remember ? but the jar has binary, the java source code is in SVN
[09:05] <man-di> persia: some upstreams release only binary builds
[09:05] <persia> man-di: Hmm.  Can they not be educated (with a stick, if necessary)?
[09:06] <man-di> persia: I tried with electro shocks for some...and failed
[09:06] <man-di> persia: normal answer: You dont need the source, use our binary build
[09:07] <persia> AnAnt: There's some guidelines on using get-orig-source to pull from VCS at https://wiki.ubuntu.com/PackagingGuide/Basic#head-4bb01b3c07548aaf98e85ac7eb7983e632f8eb38, but not much a watch file can do :(
[09:07] <persia> man-di: Right.  Lovely.  Definitely the right spirit.  I suppose they'd object to maintaining a set of source tarballs for each release in a LP project?
[09:07] <man-di> AnAnt: if the jar has a version number in its name you can at least match the binary jar to notify you when new release was made
[09:08] <man-di> persia: too much work for them
[09:09] <man-di> persia: they press some button in their development IDE and *whoops* they have a binary jar release
[09:09] <persia> man-di: Hmm.  It's usually a two or three line script.  Oh well.
[09:09] <man-di> persia: thats all they wanna do
[09:09] <white> Fujitsu: are you coming to the debian miniconf?
[09:09] <AnAnt> man-di: hmm, look, the software is josm
[09:09] <persia> man-di: Have we filed bugs against eclipse and netbeans to generate source tar.gz files as part of the same click?
[09:09] <man-di> speaking as a Java coder: most Java coders have no clue
[09:10] <man-di> AnAnt: I looked at josm some time ago...and cried out loud
[09:10] <man-di> persia: hehe
[09:10] <AnAnt> man-di: http://josm.openstreetmap.de, and I am actually making a package for the nightly build, which they say that it is stable
[09:10] <man-di> persia: that would be neat
[09:10] <AnAnt> man-di: cried out loud for what ?
[09:11] <persia> man-di: Even if they were distro-local patches, it would help in some cases, and pushing upstream makes everyone's life easier :)
[09:11] <man-di> AnAnt: because it didnt work with free runtimes
[09:11] <man-di> persia: most java upstreams know only windows
[09:11] <persia> man-di: What do they use for IDE?
[09:12] <man-di> persia: most people use Eclipse, Netbeans, JBuilder, IntelliJ
[09:12]  * persia used TogetherJ and NetBeans back when a Windows & OS/400 Java developer
[09:12] <AnAnt> man-di: free runtimes ?
[09:12] <AnAnt> man-di: all the jar files they depend on are GPL'ed
[09:12] <man-di> AnAnt: GCJ and all classpath based runtimes
[09:12] <AnAnt> man-di: they only require sun java
[09:12] <man-di> AnAnt: thats the problem
[09:12] <persia> AnAnt: Does it work with icedtea?
[09:13] <AnAnt> man-di: I think they are doing a version for that (I saw that icedtea in their SVN log)
[09:13] <AnAnt> persia: I think they are doing a version for that (I saw that icedtea in their SVN log)
[09:13] <persia> AnAnt: I read all the rows :)
[09:13] <AnAnt> ok
[09:13] <man-di> AnAnt: thats nice but GCJ would be better
[09:14] <persia> AnAnt: More generally, if you can get it to work with icedtea, we'd consider it free in Ubuntu, but having it work with gcj would be vastly superior, as it could also be free in Debian.
[09:14] <AnAnt> but, is there a problem if I made the package Depend & Build-Depend on sun java jdk ?
[09:14] <persia> AnAnt: It goes in multiverse
[09:14] <man-di> AnAnt: it depends on non-free software then (and this software is not portable)
[09:15] <AnAnt> man-di: so in Debian too it would be i non-free, right ?
[09:15] <man-di> contrib
[09:15] <AnAnt> ok
[09:15] <AnAnt> does Debian consider icedtea free ?
[09:15] <man-di> if all code is GPL
[09:15] <man-di> debian has icedtea yet
[09:16] <man-di> has *no* icedtea yet
[09:16] <AnAnt> so to use icedtea, I should do: update-java-alternatives -s <what> ?
[09:16] <AnAnt> man-di: oh yes, indeed, they don't
[09:17] <man-di> AnAnt: No, use JAVA_HOME=.....something....
[09:17] <persia> AnAnt: purge sun java, install icedtea.  Better, use sbuild or pbuilder, and set your build dependencies.
[09:17] <man-di> AnAnt: for building I mean
[09:17] <AnAnt> yes, I use pbuilder indeed
[09:18] <AnAnt> I think i'll use sun java, it worked like that
[09:18] <persia> AnAnt: That makes it multiverse, which is not preferred.  Please at least give it a try.
[09:19] <AnAnt> persia: I want to put the package in Debian too
[09:19] <persia> man-di: Is icedtea in plan for Debian, or is it waiting for the "official" source release?
[09:21] <AnAnt> man-di: ok, I have a question, if a package is built with icedtea jdk, would it work with sun java jre ? and vice versa ?
[09:23] <man-di> persia: we want to use the same source package as for Ubuntu
[09:24] <man-di> AnAnt: it should
[09:24] <bucatoamano> kubuntu channel operator has said me here i can get help, i am not good enoght to do a debian package for my application http://ubuntuforums.org/showthread.php?t=652843
[09:24] <persia> man-di: Is the current Ubuntu source not DFSG free?  Should I be reading debian-devel-java@ archives?
[09:24] <bucatoamano> so if someone is interested to do it :) let me know
[09:25] <man-di> persia: it ist afaik
[09:25] <persia> bucatoamano: We would help you package it if you had questions, but we don't take packaging requests.
[09:25] <bucatoamano> ok
[09:25] <persia> man-di: That's what I thought from looking.  I'm not sure why it was in universe.
[09:25] <AnAnt> persia: ok, I have another question, the latest release is josm-1.5, yet I am packaging the nightly build, which according to the website is also stable (but not a release), so how should I version it ? 1.6r<svn release #> or what ?
[09:26] <AnAnt> icedtea is in universe ?
[09:26] <persia> bucatoamano: If you'd like to make a packaging request, put a tar.gz somewhere as part of an upstream project, and file a bug against "Ubuntu" (no source package) with the "needs-packaging" tag.
[09:26] <man-di> persia: AFAIK (I may be wrong) its in universe because GCJ is the default runtime in Ubuntu and one Java runtime in main is enough
[09:26] <persia> bucatoamano: The bug should have a short description of the package, a link to the upstream project homepage, and a small advertisement to interest one of the packagers.
[09:26] <persia> man-di: I meant universe vs. multiverse :)
[09:27] <man-di> persia: I'm a lazy Debian-man so I dont know for real
[09:27] <man-di> persia: ah
[09:28] <man-di> persia: I think its just that we dont uploaded it yet, I needs some adjustments, Ubuntu and Debian are more different then one would expect
[09:28] <persia> AnAnt: I like to grab 1.5 and apply the additional changes as patches in most cases, as this tends to cause less end-user confusion.  If you want, 1.6~svnyyyymmdd is the common construction for snapshots just before release, and 1.5+svnyyyymmdd is the common construction for snapshots when there is not a near upcoming release.
[09:28] <AnAnt> ok
[09:29] <persia> man-di: Depends on expectations :)  I think of them as fairly different, despite sharing >95% of source.
[09:30] <man-di> persia: the lest 5% is that what makes it complicated anf big packages like icedtea hit that problems easily
[09:30] <persia> man-di: Yep.  It doesn't help that that 5% tends to be things like the kernel, libc, etc. :)
[09:30] <man-di> persia: e.g. there is libgif-dev vs. libungif-dev
[09:31] <AnAnt> ok I think there is a problem in ubuntu's java virtual packages
[09:31] <persia> man-di: I thought that transition was happening for both.
[09:31] <AnAnt> ok I think there is a problem in ubuntu's java virtual packages , java-compiler, java-virtual-machine, java-runtime,...
[09:31] <man-di> persia: last I looked at it we needed one for Ubuntu and the other for Debian
[09:31] <AnAnt> none of them depend on icedtea
[09:31] <man-di> AnAnt: they are virtual pacakges
[09:32] <AnAnt> oops sorry
[09:32] <man-di> AnAnt: and provided by some packages
[09:32] <persia> Official word is from comparing bug #174252 with Debian bug #410287.
[09:32] <ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252
[09:32] <ubotu> Debian bug 410287 in mirrors "mirror submission for debian.mirror.web4u.cz" [Wishlist,Open] http://bugs.debian.org/410287
[09:32] <man-di> AnAnt: for Build-Depends use real package names, not virtual packages, please
[09:32] <AnAnt> java2-runtime depends on icedtea, bad me !
[09:32] <persia> Errr.   Debian bug #401287
[09:32] <ubotu> Debian bug 401287 in libgif4 "libungif to libgif transition" [Wishlist,Open] http://bugs.debian.org/401287
[09:33] <AnAnt> man-di: 1. why ? 2. how about in Depends ?
[09:33] <man-di> AnAnt: to get reproducible builds, for Depends use "real package | virtual package"
[09:33] <persia> man-di: Looks like any variance there is just a matter of transition schedules.  libgif is the future.
[09:35] <man-di> persia: firefox-dev was another issue, sure, all are transitions in action but the problem is that big packages that you wanna keep in sync on both distros always hit some transition-in-the-works
[09:35] <persia> man-di: Well, yes.  Dktrkranz is working on a tool that parses rene output and generates a nice transition tracker web page.  Should help everyone.
[09:36] <slangasek> StevenK: 180274> on Monday when I'm on archive duty, or at very least, tomorrow when I can pretend to be awake and don't have to fight off typos like "tomowwor"
[09:36] <AnAnt> hmm, I think java-* virtual packages should depend on java[12]-* virtual packages
[09:49] <Fujitsu> white: Regrettably not. The family has decided that we must go on holiday - I can't attend LCA at all.
[09:49] <white> bah
[09:50] <AnAnt> man-di: they support IcedTea since October
[09:50] <Fujitsu> white: I concur.
[10:04]  * persia notes that MOTU SWAT may want to examine bugs subscribed to the security team to pull several universe bugs that are being filed around now
[11:35] <white> Hobbsee: what about catching up now?
[11:35] <white> Hobbsee: do you have my Australian mobile number?
[11:37] <Hobbsee> white: i don't think i do
[11:38] <Hobbsee> white: 9th or so is good, though
[11:39] <white> Hobbsee: you got mail
[11:39] <white> 8th or 9th would be good
[11:39] <Hobbsee> cool, OK
[11:40] <white> i forgot to write an email to the sydney ml, but if you know anyone, just bring them along ;)
[11:40] <Hobbsee> i don't.  i suggest you email them
[11:40] <Hobbsee> well, i know of some, but only on irc, etc
[11:40] <white> well who is there?
[11:41] <white> btw can anyone reproduce http://bugs.gentoo.org/show_bug.cgi?id=203777 ?
[11:41] <ubotu> bugs.gentoo.org bug 203777 in Vulnerabilities "dev-libs/libcdio < 0.78.2-r2 Buffer overflow via long filename in Joliet (CVE-2007-6613)" [Normal,Assigned]
[11:46]  * persia notes that it is a very good idea to subscribe to a bug when posting a debdiff.
[11:50] <white> Hobbsee: got my phone number?
[11:50] <Hobbsee> white: yes
[11:51] <white> good :)
[11:51] <white> Hobbsee: i'll read mail until tomorrow/sunday and then leave Germany, so either mail me place/time or call me on tuesday, when I am in .au :)
[11:52] <Hobbsee> ok
[12:00] <ChrisGibbs> Gday all
[12:00] <Hobbsee> heya ChrisGibbs
[12:00] <Hobbsee> ChrisGibbs: fancy going south and getting your key signed?  white is looking for people to meet
[12:02] <ChrisGibbs> when?
[12:05] <Hobbsee> ChrisGibbs: wednesday
[12:05] <mruiz> hi all
[12:06] <ChrisGibbs> Hobbsee: Soz to plead ignorant but "key signed" ???
[12:06] <Hobbsee> ChrisGibbs: do you have a gpg key yet?
[12:06] <Hobbsee> !gpg
[12:06] <ubotu> gpg is the GNU Privacy Guard.  See https://help.ubuntu.com/community/GnuPrivacyGuardHowto and class #8 on https://wiki.ubuntu.com/ClassroomTranscripts
[12:07] <ChrisGibbs> Hobbsee: nope haven't bothered yet
[12:07] <Hobbsee> ChrisGibbs: ahh. you'll need it for packaging
[12:08] <ChrisGibbs> Hobsee: Think i came in 1/2 way through a conversation.... looks like i will half to catch up :)
[12:17] <AnAnt> Hello, if the copyright holder be someone other than the author, should that holder be some company (as Canonical?) or could it be some group (that is not actually a company)
[12:19] <persia> AnAnt: When a work is created, copyright is held by the author.  In some cases, the author may choose to assign copyright to someone else (another person or some corporate entity (whether registered with a government or not)).
[12:20] <AnAnt> persia: yeah, could that someone else be some group, which is not a corporate entity ?
[12:20] <persia> Once copyright is assigned, the assignee becomes responsible for licensing.  In general, except in work-for-hire situations, it is best for the author to either retain copyright, or assign to some party holding copyright for a larger work for which the creation under consideration is but one part.
[12:21] <mruiz> MOTU Q&A today ?
[12:22] <persia> AnAnt: "corporate entity" means any group of persons that carries an individual identity.  Most nation states allow registration of selected corporate entites, which entitles registered entities to many of the rights of natural persons, but unregistered entities are acceptable for copyright ownership, so long as there is a well defined identity (although most nation states do not honor protection of principles from liability claims in such cases)
[12:22] <man-di> AnAnt: in US law it can afaik be anyone
[12:23] <persia> man-di: Not just US.  Applies to all signatories of the Berne convention.
[12:23] <man-di> AnAnt: in german law the assignment issue is a bit more cimplicated
[12:23] <persia> mruiz: Holiday break, but ask a question here, if you like.
[12:23] <persia> man-di: Do you need confirmation from the assignee to assign copyright in Germany?
[12:23] <mruiz> persia, I do
[12:24] <man-di> persia: the german law doesnt know copyright assignment
[12:24] <persia> man-di: Even for work-for-hire?
[12:25] <man-di> persia: depends
[12:25] <man-di> I'm no lawyer
[12:25] <AnAnt> what a complex issue
[12:26] <persia> AnAnt: What are you trying to accomplish.  While none of us is your counsel, we can probably point to a similar case that might be a way to resolve your need.
[12:26] <persia> ?
[12:26]  * persia notes that several major German companies appear to assert copyright over the content on their website, and thinks German copyright must be complex indeed.
[12:27] <AnAnt> persia: well, we are doing a distro based on ubuntu, called "Ubuntu ME", so some of us did some artwork packages
[12:27] <AnAnt> persia: we are not a company, we are just some people on a mailing list
[12:27] <AnAnt> persia: anyways, I am doing the packaging
[12:28] <mruiz> persia, full interdiff uploaded ;-)
[12:28] <AnAnt> persia: so I dunno wether to set the copyright holder to the named persons who did the work, or what
[12:28] <AnAnt> persia: so I dunno wether to set the copyright holder to the authors, or what
[12:29] <persia> AnAnt: OK.  There are three simple ways to address that.  1) list the individual copyright holders in debian/copyright, 2) have all the individual copyright holders agree there is a "Ubuntu ME team", and assign copyright to the team (yes, this is questionable in some jurisdictions, but if all the individuals continue to agree, there will be no problem: see earlier note about liability protection), 3) register your team with some nation state.
[12:29] <persia> #1 is the common solution (it's easiest)
[12:30] <persia> mruiz: Why tell me?  Better to get the status, assignment, and subscriptions correct :)
[12:31] <mruiz> persia, as you did the last comment... status, assignment and subscription are ok ... ;-)
[12:31] <ChrisGibbs> Hobbsee: Soz got booted from server, what were you saying b4 about meeting up with white?
[12:31] <persia> mruiz: Sure, but I usually process the queue in one or two swipes a day.  Someone else will likely upload it.
[12:32] <Hobbsee> ChrisGibbs: meeting.  wednesday probably.  sign keys, which you'll need for doing anything packaging based, bzr based, etc.  lunch or dinner - unsure which.
[12:32] <ChrisGibbs> Hobbsee: hmmm i have to work on Wednesday, i will ask on Mon if i can score an RDO
[12:32] <Hobbsee> cool
[12:33] <white> ChrisGibbs: beersigning yeaaaaaaah :)
[12:33] <mruiz> persia, I know... that's the idea: interaction with the entire team :-)
[12:36] <persia> Bah!  packages.qa.d.o doesn't report contrib/ and non-free/ anymore !
[12:43] <AnAnt> I did an upload to REVU 15 minutes ago, yet I can't see it on REVU's website
[12:44] <persia> AnAnt: which package?
[12:45] <mruiz> I was working on a watch file fix (bug 180113) but UEHS doesn't list the package (gnustep-ppd) anymore and my contribution isn't uploaded yet. Any idea?
[12:45] <ubotu> Launchpad bug 180113 in gnustep-ppd "Debian watch file doesn't work" [Low,Incomplete] https://launchpad.net/bugs/180113
[12:45] <AnAnt> persia: usplash-theme-ubuntume
[12:46] <persia> mruiz: Interesting.  Does the old watchfile work again for some reason?
[12:46] <mruiz> persia, let me check...
[12:47] <persia> AnAnt: I don't see it in either the upload queue or the rejected queue.
[12:47] <mruiz> persia, I got the same error
[12:47] <persia> AnAnt: I do see http://revu.ubuntuwire.com/details.py?package=usplash-theme-ubuntume however, so I'm guessing you hit just the wrong timing :)
[12:49] <persia> mruiz: In that case, I'd recommend reporting that you can still reproduce the bug, and that your patch still fixes it, and resubmitting to the sponsors queue.  On the other hand, I don't understand why this package was in UEHS anyway: it looks like a sync from Debian, in which case the watch file is better submitted to Debian.
[12:50] <mruiz> many patches work in Debian... how is the procedure to submit them ?
[12:51] <persia> mruiz: The reason we don't include packages from Debian in UEHS is that we rely on the Debian maintainers for the updates in most cases.  When we get enough hands to be able to keep everything in UEHS up to date, maybe chasing those will be more interesting.  There is one exception: we do include orphaned packages in UEHS, but that is only because there is no Debian maintainer: if it is maintained, we don't want to update without a good reason.
[12:51] <AnAnt> persia: meaning what?
[12:52] <persia> mruiz: To submit bugs to debian, first test on Debian (chroots and VMs are popular).  If you can reproduce, you file a bug in the BTS by sending mail.  http://www.debian.org/Bugs/Reporting provides an overview of the process.
[12:53] <AnAnt> persia: so I should just re-upload ?
[12:53] <AnAnt> persia: isn't REVU on revu.tauware.de ?
[12:53] <persia> AnAnt: Assuming you are talking about "a good reason", that being it includes some new feature or bugfix that a member of ubuntu-dev believes will improve the next release sufficiently to be worth possibly having different tarballs from the Debian update.
[12:53] <persia> AnAnt: It's already uploaded, no?  Also, REVU works at both sites: same machine, different names.
[12:54] <AnAnt> persia: how do I know that it is uploaded ?
[12:54] <persia> AnAnt: You see the page with your upload (from the URL I provided above).
[12:55] <AnAnt> persia: ah, ok, it's on REVU now, thanks
[12:56] <AnAnt> ok, can anyone please review: http://revu.tauware.de/details.py?package=usplash-theme-ubuntume ?
[13:34] <persia> mruiz: Only one of debdiff or interdiff is required.  Debdiff when the orig.tar.gz is unchanged, and interdiff when it is changed.  Native packages always get only a debdiff.
[13:50] <slytherin> Wow, multiverse FTBFS almost reduced to zero. :-)
[13:59]  * mruiz writes persia's comments
[13:59] <mruiz> I need some guidance with the bug 180131, please
[13:59] <ubotu> Launchpad bug 180131 in gshutdown "Debian watch file doesn't work" [Low,In progress] https://launchpad.net/bugs/180131
[14:01] <slytherin> mruiz: what help do you need?
[14:02] <vorian> mruiz: If I understand correctly, the scan should only see released sources, not release candidates.
[14:03] <slytherin> mruiz: I think the problem is with upstream versioning. In Debian/Ubuntu terms 2rc > 2
[14:03] <mruiz> vorian, interesting...
[14:04] <vorian> mruiz: if you only use (*.) the scan will produce results for anything that follows the program-
[14:06] <slytherin> A little help please. if a package is split with one of the package being -common, where should .desktop file go?
[14:24] <zul> morning
[14:26] <nenolod> mruiz, hehe. sorry for any misunderstanding about audacious{-plugins}. i had done the bump in debian, so it was easy for me to just quickly make a debdiff for those bumps.
[14:26] <mruiz> nenolod, no worries ;-)
[14:26]  * nenolod wanted to wait for upse to get built first before bumping audacious
[14:28] <nenolod> mruiz, at any rate, not yet a MOTU, so can't upload the bump
[14:28] <nenolod> ;)
[14:35] <mruiz> vorian, the correct syntax is (.*) ;-)
[14:36] <vorian> mruiz: normally yes
[14:37] <vorian> but if you had a package-1.1 and package-dev and package-editor, uscan would download the latest version of the three
[14:37] <mruiz> vorian, we are talking about versions
[14:50] <joejaxx> !checkinstall
[14:50] <ubotu> checkinstall is a wrapper to "make install", useful for installing programs you compiled. It will create a .deb package, which will be listed in the APT database and can be uninstalled like other packages. See https://help.ubuntu.com/community/CheckInstall - Read the warnings at the top and bottom of that web page, and DO NOT interrupt CheckInstall while it's running!
[14:50] <joejaxx> lol
[14:56] <Hobbsee> checkinstall was best when it segfauted.
[14:57] <zul> checkinstall is never ever best
[15:03] <Hobbsee> zul: excluding when it segfaulted.  that was a really nice touch.
[15:15] <warp10> When I fix a bug in Ubuntu and want to send it back to Debian, what's best to do, sending the whole debdiff or just the patch to the source code?
[15:16] <white> warp10: send the patch, if you do not want to NMU
[15:17] <warp10> white: and they will take care of changelog, control, etc., right? Ok, thank you!
[15:17] <white> warp10: if you changed something in debian/control, like dependencies or so, then it is part of the patch :)
[15:17] <white> warp10: you are normally acknowledged in the changelog with "Thanks to ...", if you provide a patch for a bug
[15:19] <warp10> white: well, sure! But I have no changes in control, this time. :)
[15:22] <geser> warp10: if you forward the patch towards Debian, could you also tag it (for the stats)? see https://wiki.ubuntu.com/Bugs/Debian/Usertagging
[15:24] <warp10> geser: I was just looking at it. Looks like I should add origin-ubuntu, ubuntu-patch and hardy
[15:31] <warp10> When reporting the bug to Debian, is it a good idea to add a link to the report on LP, too?
[15:31] <white> yes, can't hurt
[15:33] <\sh> moins
[16:34] <martoss> hi all, can anyone point me on documentation how-to package python applications distributed with distutils ( installs with setup.py )?
[16:35] <martoss> I've looked throug the wiki section and the links there, but the only option seems to me to manually edit the rules file.
[16:36] <azeem> which rules file?
[16:37] <martoss> in debian/
[16:37] <azeem> as in, how do you generate rules in the first place?
[16:37] <martoss> i can do this via dh_make but this is probably a stupid way
[16:37] <martoss> since dh_make is meant to package ./configure make make install packages.
[16:40] <mattva01> why do I get this  error in soyuz :dpkg-source: error: Files field contains invalid filename `apjava_1.0.0.-1ubuntu1.tar.gz'
[16:40] <martoss> ".-" is this ok?
[16:41] <mattva01> oh ah
[16:59] <RainCT> martoss: http://wiki.debian.org/DebianPython/NewPolicy
[17:00] <RainCT> martoss: the "CDBS + distutils" section explains the easiest way
[17:01] <martoss> ah ok, thx
[17:01] <RainCT> btw, if you don't get answers about Python here you might have more luck in #debian-python (server irc.oftc.net)
[17:01] <RainCT> np
[17:03] <martoss> ok, i think i will try it out. Is there some interest of including the package (eric4) in the repos?
[17:03] <\sh> martoss: eric4 as in python-qt/kde4 ideß
[17:04] <\sh> ?
[17:04] <martoss> yep, the IDE
[17:04] <martoss> currently it depends from qscintilla (which i compiled and installed from the debian source package from unstable)
[17:05] <\sh> and on pykde4 i hope ,-)
[17:05] <martoss> nope, it should only depend on pyqt4 not pykde4
[17:06] <\sh> martoss: yeah...would you like to talk to torsten marek, the debian maintainer of eric3
[17:06] <\sh> http://qa.debian.org/developer.php?login=shlomme@debian.org
[17:07] <Kopfgeldjaeger> hello. could someone please sponsor avidemux 2.4? https://bugs.edge.launchpad.net/ubuntu/+source/avidemux/+bug/178845
[17:07] <ubotu> Launchpad bug 178845 in avidemux "Avidemux 2.4" [Wishlist,Confirmed]
[17:07] <martoss> ah ok, i can ask him, if he intends to package eric4, I am also fine with this :-)
[17:08] <\sh> martoss: just work with him on that...I think he likes to have some help
[17:19] <warp10> Please review http://revu.ubuntuwire.com/details.py?package=tennix , a cute little tennis game.  The comments of the last reviewers have been addressed, and it is waiting for it's first advocacy.
[17:48] <white> TheMuso: come to the beersigning event ;)
[17:50] <Adri2000> warp10: I really like this game! :) I'll try to take a look at it (the package). but I see it's already in debian pkg-games svn. do you know what's the status of it? why not try to get it in debian first?
[17:52] <warp10> Adri2000: the package in debian is stuck from weeks and is based on a previous release. My one will be sponsored into debian by my mentor (pitti) in the next days. And, yes... it's very addictive! :D
[17:52] <Kmos> Adri2000: the status is down.. i've uploaded it to debian games svn
[17:53] <Kmos> anyone touch in it.. and not interested in release it in debian
[17:53] <Adri2000> warp10: so you are not going to maintain it with the pkg-games team?
[17:55] <totopalma> ui, hi :)
[17:55] <warp10> Adri2000: I think so, altough I haven't discussed about it with pitti: we focused on packaging errors.
[17:57] <white> !info venkman hardy
[17:57] <ubotu> Package venkman does not exist in hardy
[17:57] <white> bah
[17:57] <white> ubotu: learn source packages damnit
[17:57] <Adri2000> warp10: ok, then you should take over the itp and update the package in svn
[17:57] <white> !info mozilla-venkman hardy
[17:57] <ubotu> mozilla-venkman: Javascript debugger for Mozilla based applications. In component universe, is optional. Version 0.9.87.2-1ubuntu1 (hardy), package size 225 kB, installed size 1444 kB
[17:58] <white> !info mozilla-venkman gutsy
[17:58] <ubotu> mozilla-venkman: Javascript debugger for Mozilla based applications. In component universe, is optional. Version 0.9.87-6ubuntu1 (gutsy), package size 221 kB, installed size 1452 kB
[17:58] <warp10> Adri2000: taking over the ITP? How should I do that?
[17:58] <white> !info mozilla-venkman feisty
[17:58] <ubotu> mozilla-venkman: Javascript debugger for Mozilla based applications. In component universe, is optional. Version 0.9.87-6ubuntu1 (feisty), package size 221 kB, installed size 1452 kB
[17:59] <white> !info mozilla-venkman dapper
[17:59] <ubotu> mozilla-venkman: Javascript debugger for Mozilla and Firefox. In component universe, is optional. Version 0.9.85-4 (dapper), package size 260 kB, installed size 472 kB
[18:00] <Adri2000> warp10: change the owner of the bug
[18:01] <Adri2000> and add a comment saying you're working on it
[18:02] <warp10> Adri2000: great. Ok. I'll do that. And will take care of svn too :)
[18:02] <Kmos> i think I own that ITP :)
[18:02] <Kmos> lol
[18:02] <Kmos> warp10: feel free to change it
[18:03] <warp10> Kmos: Ok, ty :)
[18:04] <white> i assume that #456520 is fixed in the venkman version in universe?
[18:34] <Kopfgeldjaeger> could someone please sponsor avidemux 2.4? bug #178845
[18:34] <ubotu> Launchpad bug 178845 in avidemux "Avidemux 2.4" [Wishlist,Confirmed] https://launchpad.net/bugs/178845
[19:05] <Adri2000> warp10: where do you see the SDLMain.* is LGPL?
[19:06] <warp10> Adri2000: I asked upstream, and upstream asked to SDLMain's authors. I got the email in CC
[19:06] <Kopfgeldjaeger> so no sponsor here :(
[19:08] <Adri2000> warp10: hmm ok
[19:18] <Adri2000> warp10: you're closing the wrong bug report (the duplicate)
[19:20] <warp10> Adri2000: ouch! too bad :-S Ok, I'll upload it again
[19:21] <Adri2000> warp10: I'm not sure you want to have the version in the man page, because you'll need to update it at each new version
[19:23] <warp10> Adri2000: it has been added by upstream. I drafted the manpage, he reviewed it. Since he will add it to future releases, probably he is fine with that
[19:23] <Adri2000> ah ok, good then
[19:34] <warp10> I had a connection trouble while uploading to revu. Now I can't upload anything, even with -f. Any revu admin here?
[19:37] <Adri2000> warp10: (not me). I suppose you test-built in a hardy pbuilder? I'm having problems with mine right now and can only test in a gutsy one
[19:38] <warp10> Adri2000: I tested, of course: it builds fine
[19:41] <Adri2000> warp10: for your revu problem, you need one of sistpoty,hobbsee,siretart,pkern
[19:43] <warp10> Adri2000: I'm trying again. Looks like he is uploading now.
[19:51] <warp10> Adri2000: good: my last upload is shown in tennix page, now
[20:00]  * persia notes there is a MOTU Meeting starting in #ubuntu-meeting now (and apologises for the lack of the usual 5-10 minute notice)
[20:05] <Adri2000> warp10: do you know what's the license of data/* ?
[20:05] <crevette> hello
[20:06] <DaveMorris> binaries for programs are installed to /usr/bin aren't they?
[20:06] <crevette> is there a way to patch a source to replace binary resources (in my case pixmaps)
[20:16] <soren> crevette: Usually, that's achieved by providing a uuencoded replacement and uudecoding it during build.
[20:21] <crevette> soren: do you have a link which explain how to do ?
[20:24] <soren> crevette: Not off the top of my head, no. I'm sure it's on the wiki somewhere.
[20:24] <soren> It's not that hard, though.
[20:24] <soren> You create the uuencoded version, add sharutils as a build-dependency, and hook into the build: target in debian/rules
[20:27]  * persia notes that uudecode should be called in build: and rm in clean: when adding icons and the like
[20:50] <persia> Ubulette: If you have license to redistribute, include them.  If not, you can't.  If you want the original favicon.ico files, contact the websites and ask permission to redistribute.
[20:51] <warp10> Adri2000: sorry for late answer, I was AFK. All files in data/ are under GPL2, they have been made by the author (except  audio take from Melodyloops, as stated in debian/copyright)
[20:52] <Ubulette> persia, problem is prism already contains icons, they were shipped by mozilla, not sure if they asked or not. So i'm holding back prism-webapps for now.
[20:52] <persia> Ubulette: Did the Mozilla Foundation extend you a license to redistribute?  If so, it's their bother (but always good to check).
[20:53] <Ubulette> persia, i've filed a bug upstream against the prism package because there's no mention of anything for that
[20:54] <persia> Ubulette: By "no mention", do you mean "no license to redistribute" or "no discussion of licensing terms between upstream websites and the Mozilla Foundation"?
[20:54] <Ubulette> but the problem remains for any webapp.. the icon is supposed to represent the web site (ie the application)
[20:54] <Ubulette> persia, nothing at all, icons are just shipped
[20:55] <persia> Ubulette: What are the redistribution terms of the tarball in which they are shipped?
[20:55] <Ubulette> even tricker, they are bundled into .webapp files
[20:55] <Ubulette> triple licenced GPL / LPGP / MPL
[20:56] <Ubulette> (LGPL)
[20:56] <persia> Right, so any of those licenses permit redistribution, so we're safe to redistribute for prism (although your upstream bug is a good check).
[20:56] <Ubulette> 2 / 2.1 / 1.2 respectively
[20:57] <persia> For prism-webapps, you are upstream, so it becomes your responsibility to contact the websites concerned and secure redistribution rights for the icons, so you can then license them to the rest of us as GPL (or whatever).
[20:58] <Ubulette> yep, that's what I expected.
[21:03]  * persia points out bug #180388 to those interested in Malone sponsoring workflow
[21:03] <ubotu> Launchpad bug 180388 in malone "Please add status "patched" in bug reports" [Undecided,New] https://launchpad.net/bugs/180388
[21:08]  * persia requests that people not include "debian/changelog: re-added Ubuntu entries" in the remaining Ubuntu changes section of the changelog.  While this is essential retention, it is not worthy of comment.
[21:10] <Kopfgeldjaeger> any sponsor here?
[21:12] <\sh> persia: add it to the motu rules ;) (Re: uudecode in build and rm in clean)
[21:12] <persia> \sh: Where?  I thought that was just standard practice.
[21:13] <\sh> persia: seems not if you noticed it ;)
[21:14] <persia> \sh: Just expanding on the advice previously given :)
[21:15] <\sh> persia: :)
[21:58] <mok0> happy new year folks!
[22:17] <LaserJock> oh darn, did I miss the MOTU meeting?
[22:17] <stgraber> yep
[22:17] <LaserJock> grrr :(
[22:20]  * ScottK too.
[22:20] <ScottK> It'd be nice if someone would mention meetings starting here if they remember it.
[22:20] <LaserJock> yeah
[22:21] <DaveMorris> I'm looking for someone to revu my small package - http://revu.tauware.de/details.py?package=libserial
[22:21] <geser> LaserJock, ScottK: I looked at my scroll-back for #ubuntu-meeting and the only topic was time and date for the next meeting
[22:22] <LaserJock> darn
[22:22] <ScottK> geser: Thanks.
[22:22] <LaserJock> my new laptop has some keyboard ... oddities
[22:40] <nenolod> thoughts on multiverse/flashplugin-nonfree: there's an extension (open source) available for this which allows for direct integration with pulseaudio
[22:41] <nenolod> we should package this up and add a recommends to flashplugin-nonfree
[22:41] <nenolod> (unless this has been done already, then just ignore me ;))
[22:45] <TheMuso> nenolod: I like the sound of that.
[22:45] <stgraber> nenolod: libflashsupport ?
[22:47] <stgraber> uploaded to hardy/universe recently
[22:47] <warp10> persia: may I request the sync for torcs (whose you are the last uploader)?
[22:50] <nenolod> stgraber, yeah
[22:51] <nenolod> stgraber, flashplugin-nonfree should depend on it, and it should build an amd64 variant using ia32-libs-dev if it does not already :)
[22:51] <nenolod> s/depend/recommends/
[22:52] <persia> warp10: Please don't.  The last Debian update doesn't actually fix the openAL issue.  I'm working on a new upstream openAL, and have yet to determine if I care about the try/catch patch.
[22:53] <warp10> persia: ah, ok. I didn't know about that. :)
[22:54] <persia> warp10: Of course, if there's an even newer torcs of which I am yet unaware, and you can't get it to crash by selecting the openAL audio output and breaking openAL, then by all means, please sync :)
[22:55] <\sh>  fontforge: Depends: libgif4 (>= 4.1.4) but it is not going to be installed yay
[22:56] <warp10> persia: well, I don't think so :)
[22:56] <warp10> Adri2000: thank you for your advocacy :)
[22:57] <persia> \sh: It's just waiting for everything else to not use libungif.  Additional patches for additional affected packages to bug #174252 are welcome.
[22:57] <ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252
[22:58] <\sh> persia: well, who is  Ilya Eremin <che_guevara_3@bk.ru>?
[22:58] <\sh> and who sponsored the upload of fontforge (0.0.20071110-1build2) hardy; urgency=low
[22:58] <\sh> when debian/control is diffing against debian?
[22:59] <\sh> it should be ubuntu not build
[23:00] <persia> \sh: Check the signature on the .dsc and https://launchpad.net/~che-guevara-3
[23:01] <persia> \sh: If there were changes outside of changelog for an -XbuildY revision, please upload an -XubuntuY candidate to fix this.
[23:02] <Fujitsu> Both build1 and build2 contain changes.
[23:02] <Fujitsu> How strange.
[23:03] <\sh> Fujitsu: correct
[23:03] <\sh> persia: hell, I can't upload :)
[23:05] <LaserJock> do we have an easy way to check who signed an upload?
[23:05] <persia> \sh: You can propose a candidate.  Do your candidates ever get rejected?
[23:06] <Fujitsu> LaserJock: I look at -changes.
[23:06] <LaserJock> Fujitsu: but how to you figure out who signed?
[23:06] <Adri2000> LaserJock: gpg --verify *.changes
[23:07]  * TheMuso uses mutt and tracks -changes, and only needs to execute a command in mutt to show who signed the upload.
[23:07] <Fujitsu> Or use your favourite MUA's GnuPG feature.
[23:07] <LaserJock> ah
[23:07] <TheMuso> Fujitsu: exactly.
[23:07] <\sh> persia: well, I'm fighting right now with wine (after that I can propose a debdiff for fixing the stuff)
[23:07] <persia> \sh: Understood.  Thanks.
[23:08]  * nenolod works on libflashplugin-nonfree recommends: patch
[23:08] <nenolod> utoh.
[23:09] <nenolod> libflashsupport provides 64-bits package on amd64
[23:09]  * nenolod fixes that first ;)
[23:09] <TheMuso> nenolod: You think thats wise?
[23:10] <TheMuso> nenolod: If only a 32-bit ver is available, it may not work with pulseaudio, depending on how it communicates with pulse in the first place.
[23:10] <TheMuso> on amd64.
[23:10] <LaserJock> Fujitsu: meh, I can't get evolution to do it yet. I'll have to dig around
[23:14] <persia> LaserJock: If you've the evo dependencies installed, copy & paste from the archive to gedit, and use the Edit/Verify menu item.
[23:14] <Fujitsu> LaserJock: I thought Evo did OpenPGP by default.
[23:14]  * persia still likes gpg --verify *.dsc
[23:14] <Fujitsu> Look down the bottom of the message.
[23:15] <TheMuso> nenolod: It seems that libflashsupport links directly against pulseaudio.
[23:15] <TheMuso> How do you propose making a 32-bit only version of libflashsupport to work with the 64-bit pulseaudio?
[23:15] <LaserJock> well, it opens the signiture if you have it in your keyring
[23:15] <LaserJock> but it complains that it can't find the key if you don't
[23:16] <Fujitsu> LaserJock: Doesn't it ask if you want to grab the key?
[23:16] <LaserJock> no
[23:16] <geser> \sh: Hobbsee sponsored the last fontforge upload
[23:16] <persia> LaserJock: It also gives you the keyid if you don't, and you can ask a keyserver about the owner
[23:16] <LaserJock> yeah, that's a lot of work to just find who signed the stupid thing ;-)
[23:16] <TheMuso> nenolod: At the least, you want to prevent it building on powerpc/sparc/ia64/hppa
[23:17] <Fujitsu> Do we want to add the remaining 54 source packages with binaries depending on libungif4g to the bug?
[23:18] <\sh> geser: well..somehow it's not build .. the binary is still pointing to libungif
[23:18] <persia> Fujitsu: Makes sense.  killing libungif is a target for hardy, but it's not NBS yet, for various complicated reasons.
[23:18] <Fujitsu> That's going to be one massive bug.
[23:18] <geser> LaserJock: there aren't that many people doing sponsoring, so you would have all needed keys in your keyring soon
[23:19] <persia> This is why we typically use NBS for transitions rather than Malone, but better one massive bug than lots of little issues without proper tracking.
[23:19] <LaserJock> geser: true
[23:19] <geser> \sh: fontforge DEPWAITS on libspiro-dev
[23:19] <LaserJock> \o/, I killed seahorse
[23:19] <TheMuso> geser: Not any more.
[23:20] <nenolod> TheMuso, yes
[23:20] <nenolod> TheMuso, i'm working on it
[23:20] <TheMuso> nenolod: Ok.
[23:20] <geser> TheMuso: I should update the ftbfs page more often :)
[23:20] <nenolod> TheMuso, as far as pulse goes, 32-bit pulse lib works with 64-bit server
[23:21] <TheMuso> nenolod: Um, but thats still a problem.
[23:21] <nenolod> TheMuso, how so?
[23:21] <TheMuso> nenolod: As the 32-bit flash, will be using a 32-bit lib to try and talk to a 64-bit lib.
[23:21] <persia> nenolod: Are you going to need to stuff yet another package into ia32-libs, just after the recent upload?
[23:21] <nenolod> TheMuso, yeah. i'm working on that.
[23:21] <TheMuso> persia: My point exactly.
[23:21] <nenolod> persia, no.
[23:21] <nenolod> as far as i know there is a 32 bit pulse lib in ia64-libs.
[23:22] <persia> TheMuso: As long as it's done by message-passing-abstraction, it oughtn't be an issue.  Same reason flash works with ai32-libs in the first place.
[23:22] <nenolod> haha cool. gnome-panel just crashed.
[23:22] <TheMuso> persia: Well at the least, it needs testing.
[23:22]  * nenolod uses apport to automatically file a bug.
[23:22] <persia> TheMuso: Absolutely.
[23:23] <nenolod> TheMuso, at the moment, libflashsupport does not work at all on amd64.
[23:23] <persia> nenolod: Does that not happen multiple times a day for you?  I thought it was just the nature of hardy.
[23:23] <nenolod> no
[23:23] <nenolod> first time it has done it for me ;)
[23:23] <TheMuso> nenolod: Right, just like its useless on the other aches I mentioned.
[23:23] <TheMuso> arches
[23:23] <nenolod> TheMuso, yeah. i already fixed Architectures:
[23:23]  * persia decides to actually look at the apport report and maybe file a bug for the next crash
[23:24] <nenolod> well
[23:24] <nenolod> i may have defective RAM or something (i just replaced it)
[23:25] <nenolod> neat
[23:25] <nenolod> firefox is crashing
[23:26] <Fujitsu> Does anyone here know why there is only a small fraction of the libungif4g rdepends already on the bug?
[23:29] <persia> Fujitsu: Maybe mostly main?
[23:30] <Fujitsu> There were only 3 or 4 in main, I believe.
[23:30] <persia> No idea then.  Maybe it's like the Update Maintainer Field bug, where new tasks only get added when someone plans to work on them.