[00:29] <handschuh> general question: if a package is in debian and ubuntu, will it be autosynced from debian to ubuntu, so that the maintainer only has to watch at one repository?
[00:32] <nhandler> handschuh: If it is in Debian and Ubuntu, it will only be automatically synced if no changes have been made in Ubuntu.
[00:32] <handschuh> so it would be more efficient to put a package into debian, and file a sync-packages-bug @ launchpad?
[00:34] <handschuh> nhandler: btw. thanks for reviewing my package at revu
[00:34] <nhandler> handschuh: The most efficient thing to do would be to try and get all of the Ubuntu changes applied in the Debian package. That way, the package could be automatically synced from Debian. If the changes are only needed in Ubuntu, and not in Debian, you will have to merge, not sync, the package from Debian
[00:34] <nhandler> handschuh: No problem. If you make the changes I suggested, feel free to ping me on IRC and let me know. I will gladly look over it again.
[00:35] <handschuh> I made them already :-)
[00:35] <icf7> How do I encode the ampersand in a URL, like http://ex.org/?a=b&c=d . Tried &, \&, &&, but nothing seems to work and I can't find any documentation
[00:36] <icf7> oops: How do I encode an ampersand in a URL in a
[00:36] <handschuh> nhandler: so if a program has no ubuntu-specific requirements, debian would be the best point to start?
[00:36] <icf7> *manpage*
[00:39] <nhandler> handschuh: Yes handschuh. It will then get automatically synced once the Jaunty repositories open up (automatic syncs have stopped for Intrepid).
[00:40] <handschuh> nhandler: ok thanks.
[00:41] <handschuh> nhandler: so once the package is in the ubuntu repository, it will be synced automatically if the debian version is updated - great. How much time is needed to sync a change?
[00:42] <ScottK-laptop> handschuh: If there are no Ubuntu changes it's automatic.
[00:42] <ScottK-laptop> If there are Ubuntu changes then someone has to merge them.
[00:43] <handschuh> ScottK-laptop: and how long will the change take? (hours, days or weeks)
[00:43] <handschuh> ScottK-laptop: (i am just interested)
[00:43] <ScottK-laptop> If it's automatic, during the period when autosync runs it's hours to days.  Not weeks.
[00:44] <handschuh> ScottK-laptop: great - thanks!
[00:44] <handschuh> and a merge has to be performed manually?
[00:45] <ScottK-laptop> Yes.
[00:45] <ScottK-laptop> Semi-automatically.  We have tools to assist, but manual review is required.
[00:45] <handschuh> ok
[01:00] <ethana2> Gyarr, this one package has bad dependencies
[01:03] <handschuh> nhandler: did you read the message, that I have made all the changes you suggested at revu? (not want to push; just want to be sure the note here at irc has been read)
[01:04] <nhandler> handschuh: I am looking over the package now. From looking at the debdiff, it looks like you made all of the changes I mentioned in my comment. I am now looking over the entire package a second time to make sure there isn't anything else that I might have missed the first time around.
[01:04] <handschuh> oh - I cordally thank you
[01:05] <nhandler> handschuh: Just so you are aware, your package probably will not make it into the repositories for intrepid. However, it should have plenty of time to get into jaunty
[01:06] <handschuh> nhandler: not making it into intrepid is no problem (ppa and a seperate .deb is available) but jaunty would be nice
[03:07] <nullack> Hi MOTUS :) Im hoping someone might be able to answer if the Intrepid kernel has any debugging code that would slow it down?
[03:07] <nullack> Im chasing some performance issues
[03:07] <nullack> While the kernel is in alpha
[03:09] <wgrant> nullack: MOTU has nothing to do with this. -> #ubuntu-kernel
[03:09] <nullack> wgrant: thanks
[04:05] <nellery> hi, attempting to use debuild on firefox-3.0 fails to succeed.. is there a special way it must be done?
[04:07] <wgrant> nellery: No. "fails to succeed" isn't very descriptive.
[04:11] <nellery> wgrant, good point, here's a paste
[04:11] <nellery> http://paste.ubuntu.com/47653/
[04:12] <nellery> that's after no changes
[04:12] <wgrant> sudo apt-get build-dep firefox-3.0
[04:16] <nellery> I get "E: Build-Depends dependency for firefox-3.0 cannot be satisfied because no available versions of package mozilla-devscripts can satisfy the version requirements"
[04:21] <wgrant> Sounds like you're building it somewhere that you shouldn't.
[04:21] <wgrant> nellery: You're not trying to build Intrepid's firefox-3.0 on Hardy, are you?
[04:21] <nellery> AHHH that would explain it
[04:22] <nellery> thanks :)
[04:29] <nhandler> Is there any advantage to using dh_install instead of cp in the debian/rules file?
[04:33] <persia> nhandler: You're significantly less likely to make a mistake with the target name, it sets the permissions correctly, and you can use a debian/package.install file if you have lots of things to install.
[04:33] <persia> If you don't have debhelper, consider using install to install the files.
[04:35] <nhandler> persia: I'm actually looking at a package on REVU. They use cp and chmod to install the files to the correct location with the correct permissions. They already depend on debhelper. Should I advise they switch to dh_install? Or can they leave it as is?
[04:35] <persia> Advise to switch to either install or dh_install.
[04:35] <nhandler> Ok, thanks persia.
[04:36] <persia> dh_install may be slightly preferable because it avoids tracking the install location, but that's a matter of packer convenience, rather than being a case of doing it the hard way.
[04:36] <persia> s/packer/packager/
[06:33] <fabrice_sp> Hi. I've asked for sponsorship for Bug 180384 (FTBFS for a Thunderbird add-on), but as it's an add-on for Thunderbird, should I suscribe first Mozilla Extension Team?
[06:34] <Hobbsee> oh, sweet.  i didn't realise we had -traybiff in the archives.
[06:34] <fabrice_sp> Hobbsee: only as sources until now :-)
[06:36] <fabrice_sp> I had to change references from icedove back to thunderbird to be able to build it
[06:37] <persia> fabrice_sp: Probably good to subscribe both teams.  The Mozilla Extension team will know the code best, and can either upload or comment positively, increasing the chance that a sponsor will push it.
[06:37] <persia> (or maybe you've already caught someone's interest)
[06:38]  * Hobbsee notes the patch, while long, looks correct.
[06:40]  * Hobbsee notes there's a newer versino now, but doubts it affects us.
[06:40] <fabrice_sp> Hobbsee: it's a long patch because of all the reference to icedove and iceape :-/
[06:41] <Hobbsee> fabrice_sp: yeah, i can see that.
[06:47] <ScottK-laptop> We'll all be loving ice* soon perhaps.
[06:47] <Hobbsee> fabrice_sp: uploaded, thanks.
[06:47] <Hobbsee> ScottK-laptop: it looks like they've removed the eula requirement for firefox, btw.
[06:47] <ScottK-laptop> Ah.  Good.
[06:48]  * ScottK-laptop waits for them to insist it must be called "Ubuntu with Firefox".
[06:48] <ScottK-laptop> Although I kind if wish they'd just stuck with it and we'd switched to something else.
[06:48] <Hobbsee> fabrice_sp: i ended up grabbing the debian revision, and merging your changes against it.
[06:49] <ScottK-laptop> I'm very uneasy having code in the main archives I can't patch.
[06:49] <persia> ScottK-laptop: Well, you can patch it: it's just that every patch needs an upstream ACK.
[06:50] <ScottK-laptop> persia: That's why I can't.  I've no idea how to deal with this outside entity.
[06:50] <ScottK-laptop> So it's no longer a package that a generalist can do anything with.
[06:51] <persia> Oh.  I'd recommend just shoving patches to the mozillateam, and letting them coordinate with upstream
[06:51] <ScottK-laptop> persia: Agreed as a practical matter, but that's beside the point.
[06:51] <ScottK-laptop> What about packages licensed like this that have no team?
[06:52] <persia> Do we have any of those?  In the absence of such a team, I don't see how we can support it.
[06:52] <persia> pq is a good example of such a package.
[06:52] <ScottK-laptop> I don't know if we do or not.  Policy currently allows such a thing.
[06:53] <persia> I suppose.  If we do, it's likely to be an ubuntu-unique package.  Perhaps worth a general copyright & licensing review of those anyway.
[06:53] <ScottK-laptop> What worries me a bit more is that since I'm not in the habit of reading debian/copyright for every package I touch, I may do something legally bad without knowing it.
[06:54] <ScottK-laptop> I generally assume i have the right to modify and distribute packages in the Main archives.
[06:54] <persia> That's a habit you must change: it's dangerous to not read debian/copyright
[06:54] <ScottK-laptop> Apparently.
[06:55] <persia> Even in cases of GPL & BSD, etc.  Sometimes one can't just apply a patch from somewhere else that solved the issue.
[06:55] <ScottK-laptop> I'd prefer to be protected by policy and the archive admins.
[06:55] <ScottK-laptop> True.
[06:56] <ScottK-laptop> The irony is that in some cases I'm not even allowed to pull from the upstream VCS unless it's been fully vetted and approved upstream.
[06:56] <persia> Since the problem exists with DFSG licenses, I'm not sure how you're going to get any protection unless you decide to relicense everything GPL, and drop anything which can't be relicensed.
[06:56] <ScottK-laptop> There are potential mixing problems with DFSG licenses.  That's true.
[06:56] <persia> Personally, I'd rather read the contracts I accept, rather than assume someone else did, and that they are a trusted proxy.
[06:57] <ScottK-laptop> Yes, well that's probably the smarter strategy.
[06:57] <fabrice_sp> Hobbsee: thanks! :-)
[06:57] <persia> And remember, publishing a patch can count as redistribution, especially with common patch techniques that include context.
[06:57] <ScottK-laptop> Yep.
[06:58] <ScottK-laptop> I don't think that there's a package in Debian Main that I couldn't write my own patch and add it to though.
[06:58] <ScottK-laptop> If there is, it's a bug.
[06:58] <persia> For users, it's probably safer, as they don't tend to be redistributing, but as soon as one runs apt-get source, one ought read the license.
[06:58]  * ScottK-laptop needs to be awake again in a little over 3 hours, so I should probably go to bed.
[06:59] <persia> Sure, for your own patches, but you're accepting any liability for claims that the patches aren't yours :)
[06:59] <persia> Have a good night.
[07:00] <ScottK-laptop> Yep.
[07:00] <ScottK-laptop> Good night.
[07:07] <\sh> moins
[07:45] <\sh> does anyone know nullack?
[07:45] <persia> \sh: How do you mean? keysign-know, or seen traffic on IRC?
[07:46] <\sh> persia: the irc/lp user "nullack"
[07:46] <persia> I've seen a fair bit of traffic on IRC, ML, and LP.  Tends to be in #ubuntu-bugs, #ubuntu-testing, and #ubuntu-quality
[07:46] <persia> Also active in the forums
[07:46]  * \sh just needs some vacation or some drugs to calm down..but I wonder why bugsquad people are going sometimes wild...or I just don't understand bugwork anymore...
[07:47] <\sh> could also be that I'm using the braindevice sometimes...
[07:48] <\sh> bug #246911 <- just explain to me, why we need to nomniate "in progress and assigned bugs" now for the latest ubuntu development  release?
[07:49] <\sh> this gives me a shitload more work to fiddle around with a simple report...
[07:50] <\sh> and I wonder how long I have to tell people "don't touch already assigned bugs"
[07:52] <persia> \sh: nullack was addvised not to do that recently, and has stopped.
[07:52] <persia> (or claimed to have stopped).
[07:53] <RAOF> He's perhaps a _little_ too enthusiastic, but seems willing to learn.
[07:54] <persia> You might review the BugSquad documentation, and add a note in the triage guidelines that 1) nominating for the current release is only meaningful when also nominating for other releases in the expectation of SRU, and 2) there's typically little point in nominating tasks for bugs in-progress unless you're in communication with the assignee
[07:54] <persia> He's from a long QA background, but just dipping into open-source and development.
[08:02] <\sh> persia: it's not the first time that those things are happening and actually I'm tired of repeating the problems all the time
[08:02] <persia> \sh: Understood.  I believe the only way to fix it is to adjust the bugsquad documentation.  The previous attempt was apparently unsuccessful, as it created a confusing class of "workflow" bugs.
[08:03] <persia> A more correct adjustment might be the one you just suggested, of not adjusting bugs that are In-Progress, and especially not without discussion with the assignee.
[08:03] <Hobbsee> persia: oh, it was eventually successful.  after a revert & hissy fit was thrown, it got discussed at UDS, and then my original changes were made again.
[08:03] <persia> I suspect that discussing such an adjustment at tonight's QA meeting would be the best path to success.
[08:03] <Hobbsee> trouble is, the next UDS is rather far away.
[08:04] <ajmitch> hello
[08:04] <persia> Hobbsee: No.  It reduced the volume.  It didn't solve the issue, or \sh wouldn't be happy today.
[08:04] <Hobbsee> persia: well, excluding nullack.
[08:04] <persia> Hobbsee: It's iterative: we need to look for better and better definitions and ensure they are shared between all interested parties.
[08:04] <Hobbsee> persia: that's true.
[08:05] <\sh> persia: you forget one thing about documentation: most people don't read long documents...they want to start right away...
[08:06] <persia> \sh: I know, but not adjusting the docs, and not getting buy-in from the bugsquad leaders means you have to teach each person yourself :)
[08:08] <\sh> persia: na..I'm just tired to do that...I wouldn't bother anymore to take care  about bugs...I would just randomly upload crack ;)
[08:09] <\sh> persia: who is bugsquad liason for MOTU?
[08:09] <persia> \sh: OK.  If you're feeling pain, I recommend you attend the meeting and complain (I'm asleep during that meeting).
[08:10] <persia> We don't have one specifically.  Most MOTU are part of bugsquad, and a number of bugsquad members (including me) are MOTU.
[08:10] <\sh> persia: when is it? if it's in the evening..no way...I need sleep, I'm already under heavy workload these days (real life work)
[08:10] <persia> \sh: I'm 7 hours ahead of you :)  Maybe you can get someone else to attend?
[08:11] <Hobbsee> \sh: you could just try complaining at nullack in -bugs now.
[08:11] <persia> (and maybe get nullack to take it to the meeting)
[08:11] <Hobbsee> \sh: with the hope that he'd update documentation.
[08:12] <ss_> Hi folks I want to create a deb package of a c# software (created in Monodevelop 1.0), plz refer me some links
[08:13] <Hobbsee> !packagingguide
[08:13] <ss_> thanks
[08:14] <persia> ss_: You probably also want to look at the cli-common package.  I've never done any work with C# packaging, but it seems to be a common build-dependency, so I suspect there's useful stuff there.
[08:15] <RAOF> cli-common-dev is likely what you want, yes.
[08:15] <RAOF> Gah.  I was about to point him to http://pkg-mono.alioth.debian.org/cli-policy/
[08:16] <persia> RAOF: As time passes, everyone learns that idling can be informative :)
[08:17] <RAOF> For those playing at home, the CLI policy is not only the policy you need to conform to, it also includes examples!
[08:23]  * Hobbsee sighs.
[08:25] <directhex> also look at the packaging for a "simple" c# app, such as, say, graphmonkey
[08:36] <ajmitch> all helpful suggestions, if people stick around
[08:36] <persia> And useful for those idling :)
[08:39] <directhex> is there a browser plugin packaging policy?
[08:43] <persia> directhex: Yes, but I forget the URL.  I suspect that those in #ubuntu-mozillateam have it handy
[08:44] <RAOF> directhex: Planning on doing a moonlight package?-
[08:44] <directhex> RAOF, yes, but i'd like to wait for mono 2 and an updated upstream tarball where they don't forget to include LICENSE
[08:44] <didrocks> hi there o/
[08:45] <RAOF> directhex: It's always nice when the code's distributable, yes :)
[08:46] <directhex> RAOF, it was the usual error in EXTRA_DIST_FILEs or whatever it is. but i'd rather not need to pull from svn or make awkward explanations in debian/copyright
[08:47] <RAOF> Indeed.  In a similar vein, I wonder whether I should ping google to see if they'd like to release a gdata-cil tarball which contains a build system. :)
[08:50] <directhex> try it
[08:56] <directhex> yay, ssl certificates updated across the board. took my time, it's been using a debian-made cert for ages
[10:12] <\sh> ok..I hope I didn't mess up ia32-libs ... this was my first upload of it...*pressthumbs*
[10:14] <savvas0> Hi, anyone to help me to build a package? What's the best way to make links of the executables in /usr/local/bin ? to add them in debian/links ?
[10:14] <directhex> don't use /usr/local in packages
[10:15] <directhex> /usr/local should be considered sacred by a package manager - it's where a user shoves random crap
[10:15] <savvas0> ah
[10:15] <directhex> \sh, does it contain curl libs? i think flash 10 needs it, and iirc it wasn't in the hardy release ver
[10:15] <\sh> directhex: yes.
[10:16] <\sh> directhex: could be that curl is needed for the rtmp connects...because that's one thing which didn't work on x86_64 properly..on i386 it worked
[10:16] <directhex> jms@osc-franzibald:~$ ldd /opt/firefox/plugins/libflashplayer.so | grep curl
[10:16] <directhex> 	libcurl.so.3 => not found
[10:16] <savvas0> directhex:  I put the files in /usr/share/timekpr - or should I place the executables directly in /bin ?
[10:16] <directhex> 10 explicitly links to libcurl.so.3
[10:16] <\sh> directhex: latest ia32-libs 2.2ubuntu2 ?
[10:17] <directhex> 2.2ubuntu11
[10:17] <\sh> 2.2ubuntu12 is on it's way...
[10:17] <\sh> (intrepid :))
[10:17] <directhex> savvas0, generally executables go into /usr/bin, unless it's a .net app
[10:18] <directhex> generally
[10:18] <savvas0> ok thank you very much :)
[10:18] <RAOF> (In which case wrappers go in /usr/bin ;))
[10:19] <directhex> ^^ i'm with stupid
[10:19] <quadrispro> hi guys, can someone proceed with this? bug 268059
[10:20] <quadrispro> It has been approved from motu-released
[10:20] <quadrispro> s/from/by
[10:23] <\sh> directhex: http://launchpadlibrarian.net/17689132/ia32-libs_2.2ubuntu12_amd64.deb <- new version...if you would like to test now :)
[10:32] <AnAnt_> is there a place where can I find old debian packages (.diff.gz files) ?
[10:32] <StevenK> snapshot.debian.net if you're very lucky
[10:33] <AnAnt_> old = not in oldstable even
[10:33] <wgrant> Oh. Ooooold.
[10:35] <azeem> AnAnt_: archive.debian.org, if that version got released
[10:53] <AnAnt> thanks
[11:31] <capiscuas1982> hi people, i need to MOTU persons to try and approve my package
[11:31] <capiscuas1982> https://bugs.launchpad.net/ubuntu/+bug/200232
[11:32] <capiscuas1982> it's a 1.000.000 downloads GPLv3 multimedia project to get subtitles
[11:33] <capiscuas1982> anybody to review ?
[11:45] <capiscuas1982> is everybody alive ?
[11:48] <wgrant> capiscuas1982: You would likely have more luck if you were to wait until Jaunty opens.
[11:49] <capiscuas1982> intrepid is closed already?
[11:49] <wgrant> For new packages, yes.
[11:49] <wgrant> Some weeks ago.
[11:49] <capiscuas1982> i see, thanks
[11:58] <ScottK-laptop> \sh: I see you touched ggz-grubby last.  It's one of the very few packages keeping perl 5.8 from going away.  I was wondering if you'd have a look at rebuilding it?
[12:06] <quadrispro> can anyone proceed with this? bug 268059
[12:06] <quadrispro> it has been approved by motu-release
[12:08] <\sh> ScottK: ggz-... this is something from gnome + this strange game package, right?
[12:08] <\sh> ScottK: I'll have a look just now../me needs to resolve some strange video stuff now
[12:08] <ScottK-laptop> \sh: Some kind of not IRC but like IRC thing.  Dunno.
[12:09] <ScottK-laptop> \sh: Thanks.
[12:09] <ScottK-laptop> \sh: Other than some hppa specifc pain, that's the only package keeping perl5.8 in the archive.
[12:27]  * pochu waves
[12:56] <infinito> is it possible to get a sync from debian yet?
[12:59] <ScottK> infinito: Yes.  For bug fixes or new features with a Freeze Exception.
[12:59] <ScottK> For bug fixes it's not only possible, it's encouraged.
[12:59] <infinito> ScottK: 'till when?
[13:00] <infinito> until when, i meant....
[13:00] <ScottK> It depends on exactly what it is.  The final freeze is usually the weekend before release.
[13:01] <infinito> a liitle python app
[13:03] <ScottK-laptop> infinito: New package are not possible now without a really compelling reason.
[13:04] <infinito> it's not new, it's already on ubuntu
[13:04] <ScottK-laptop> OK.
[13:04] <ScottK-laptop> Is it a new upstream release or a new debian revision?
[13:05] <ScottK-laptop> If the former and it also provides changed/new features (not just bugfix) it will need a freeze exception.
[13:06] <infinito> new upstream release with new features and bugfixes
[13:07] <ScottK-laptop> infinito: Then you'll need to look into https://wiki.ubuntu.com/FreezeExceptionProcess
[13:09] <infinito> ScottK-laptop: ok, thanks
[13:10] <infinito> ScottK-laptop: but do i need to do all the process just for a sync?
[13:11] <wgrant> Yes. A sync is no different. Why would it be?
[13:12] <infinito> ok
[13:24] <quadrispro> does anyone work on bug 268773?
[13:55]  * ScottK-laptop pokes jdong about backports.
[14:04] <\sh> ScottK: ggz-grubby doesn't build anymore
[14:05] <\sh> ScottK: http://paste.ubuntu.com/47763/
[14:06] <\sh> ScottK: but sid has a new upstream...checking if that builds nicely
[14:07] <ScottK-laptop> \sh: Great.  If it builds I'll be glad to be the first ack on FFe.
[14:08] <\sh> ScottK: forget it...it FTBFS at the same location
[14:11] <ScottK-laptop> NCommander: Got an FTBFS for you ^^^
[14:12] <NCommander> ScottK-laptop: should I run?
[14:12] <ScottK-laptop> Nah, it's not even hppa.
[14:12] <NCommander> \p/
[14:12] <NCommander> build log?
[14:12] <ScottK-laptop> http://paste.ubuntu.com/47763/
[14:13] <NCommander> that's it?
[14:13] <ScottK-laptop> \sh has more.
[14:13] <ScottK-laptop> That's where it dies
[14:14] <NCommander> should I fix the one in Ubuntu, or do a sync/merge?
[14:14] <ScottK-laptop> NCommander: For motivation, this is the last source package rebuild needed to get Perl 5.8 out of the archive (It's now cruft).
[14:15] <ScottK-laptop> NCommander: If the new one has features, just fix ours.  Otherwise, it's probably be better to update.
[14:15] <NCommander> I'll just fix it
[14:15] <NCommander> Less effort usually than a full merge + FFe
[14:20] <NCommander> Something is strangely broken]
[14:21] <ScottK-laptop> Perfect for you then, right?
[14:22] <NCommander> this looks like a bug with /usr/share/ggz/modules/ggz-grubby
[14:22] <NCommander> er
[14:22] <NCommander> ggz-config
[14:22] <NCommander> since it is not respecting DESTDIR
[14:27] <NCommander> found the "issue"
[14:28] <ScottK-laptop> Excellent.
[14:31] <NCommander> I have no idea how to fix it however ATM\
[14:31] <ScottK-laptop> Less Excellent.
[14:31] <ScottK-laptop> What's the problem?
[14:32] <NCommander> ggz-config isnt' respecting DESTDIR
[14:32] <NCommander> IF you set destdir via an environmental variable, and then add -D, it works
[14:32] <NCommander> This works on Debian
[14:32] <NCommander> This doesn't work on Ubuntu
[14:33] <NCommander> (via the makefile)
[14:37] <ScottK-laptop> libtool difference?
[14:37] <\sh> NCommander: do the fix in the new of sid
[14:45] <NCommander> ScottK-laptop: unlikely
[14:45] <NCommander> \sh: yes sir, fi your willing to write to FFe :-)
[14:46] <\sh> NCommander: fix it first, I'll write the FFe
[14:46] <NCommander> \sh: yes sir :-)
[14:46] <\sh> NCommander: thx
[14:48] <james_w> is anyone having a problem in Intrepid with upgrading ttf-dejavu-extra?
[14:48] <james_w> it's meaning that I can't currently build anything in a chroot
[14:48] <james_w> making it quite hard to submit an FFe
[14:49] <NCommander> james_w: not here
[15:00] <iulian> It's working good here too.
[15:02] <james_w> thanks, I'll give it a kick
[15:10]  * iulian stares at bddebian
[15:11] <bddebian> heya gang
[15:11] <bddebian> Hi iulian
[15:11] <bddebian> Why are you staring at me? :)
[15:15] <iulian> bddebian: Hey... I was just waiting for your message :-)
[15:15] <iulian> bddebian: If it's not polite, I won't stare at you anymore ;)
[15:15] <bddebian> :)
[15:15]  * iulian hides
[15:23] <soren> cody-somerville: Do you know if anyone is working on packaging Xfce 4.6?
[15:23] <cody-somerville> Yes, its done.
[15:24] <soren> Oh. In a PPA, I presume?
[15:25] <soren> Ah, xubuntu-dev.
[15:26] <cody-somerville> yup but I'm not sure if they're outdated
[15:27]  * cody-somerville pokes NCommander.
[15:28] <soren> cody-somerville: I presume this is Jaunty material?
[15:28] <cody-somerville> Yea, it won't make it for Intrepid : (
[15:29] <soren> Alright.
[15:30] <soren> cody-somerville: Are you using the packages in the PPA?
[15:30] <cody-somerville> me? not on this machine
[15:31] <soren> Ok.
[15:37] <geser> Hi bddebian
[15:37] <bddebian> Heya geser
[16:06] <ScottK-laptop> NCommander: Do you have a moment to look at another package (I was in the middle of this one and just found someone filed a grave bug against one of my packages in Debian).
[16:07] <NCommander> ScottK-laptop: sure, but not at the moment, need to run in a few minutes
[16:07] <geser> ScottK-laptop: re your bug closure for libb-size-perl: does NBS also list virtual packages? because libb-size-perl still depends on perlapi-5.8.8
[16:07] <ScottK> geser: Urgh.
[16:08] <ScottK> I guess it doesn't.
[16:08] <ScottK> Thanks for looking.
[16:09] <NCommander> ScottK: I also got a HPPA account ;-)
[16:09] <ScottK> Great.  BTW, Perl FTBFS on hppa last time.
[16:10] <NCommander> yay
[16:10] <NCommander> More fun ;-)
[16:10] <NCommander> ScottK: probably the test is just taking an insanely long period of time. We have that issue with perl on m68k to the point we had to bump the timeouts
[16:11] <NCommander> (the default m68k timeout is 12 hours)
[16:46]  * ScottK says what the heck and subscribes to the firefox bug.
[16:46] <liw> _the_ firefox bug? there's only one left?
[16:51] <ScottK> liw: The one about the EULA.
[16:53] <tacone> ScottK: if you need junk mail I can send you some without any kind of subscriptions
[16:53] <tacone> no problem, really.
[16:54] <ScottK-laptop> Yeah, well I finally had what I thought was a useful comment, so I added it and thought to see if there were replies.
[16:58]  * tacone checking the useful one.
[20:02] <savvas> hello! anyone with init.d packaging experience? I'm trying to run a bash script as a service, which I've done successfully, but it doesn't create the pid file in /var/run
[20:03] <savvas> here's the file: http://bazaar.launchpad.net/~timekpr-maintainers/timekpr/trunk/annotate/8?file_id=timekpr.init-20080917152032-3674lebcfed9ceve-4
[20:05] <savvas> (or trunk > folder testing > timekpr.init)
[20:11] <sebner> huhu norsetto :)
[21:39] <slytherin> geser: there?
[21:40] <slytherin> geser: did you miss bug #269074?
[21:41] <geser> slytherin: yes, I'm here
[21:42] <geser> slytherin: I didn't ack it because I don't see changes worth syncing
[21:42] <slytherin> geser: Ok. So do you think I should instead make a small ubuntu specific change to make it compiler with openjdk?
[21:48] <geser> slytherin: does it need changing? the changelog doesn't mention anything about changing to openjdk?
[21:48] <geser> slytherin: it looks it got stuck in Debian contrib due to dependencies
[21:49] <slytherin> ahh, let me check again.
[21:51] <slytherin> geser: right, aspectwerkz2 is still in multiverse in Ubuntu.
[21:52] <slytherin> No point in syncing then. I shouldn't file sync requests in night. :-(
[21:56] <verwilst> emgent: ping
[22:32]  * directhex goes postal on bugs
[22:57] <crimsun> \sh: Flash plugin also appears to need libxcb-render-util0 and its deps added to ia32-libs, too
[23:00] <directhex> in before the lock!
[23:00] <directhex> down from 47 open bugs to 18
[23:00] <directhex> and now LP is down