[00:36] <awen_> i'm working on the libapache-mod-layout and making that work for apache2 ... what is the right way to rename it to libapache2-mod-layout?
[00:41] <awen_> the important thing is that the old libapache-mod-layout doesn't stay behind in the archive
[00:44] <crimsun> if necessary, you could file an archive removal request for libapache-mod-layout source+binary
[00:45] <crimsun> I'm not up-to-speed on Apache/2 modules, however; you need to ensure that what's available in 6.06 LTS is available and/or able to be migrated for 8.04 LTS.
[00:48] <awen_> crimsun: should you then make some sort of "migration" package with the old name?
[00:50] <crimsun> awen_: you would need a transition package IFF that is the proper Apache -> Apache 2 migration path.
[00:50] <crimsun> awen_: again, I know nothing about that migration; others here are more knowledgable regarding it.
[00:50] <awen_> crimsun: do we know who might know that?
[00:52] <crimsun> slangasek or persia
[00:57] <awen_> crimsun: okay, thanks... then i'll just need to catch one of the some time
[01:14] <joejaxx> wow nice
[01:14] <joejaxx> virtualbox runs on os/2
[01:20] <persia> awen_: If you can get the source to also generate a libapache2-mod-layout binary package, that would be a good first step.  The second step would be to create a dummy libapache-mod-layout package and test an upgrade from Dapper to Hardy to make sure that someone with apache + libapache-mod-layout gets a smooth upgrade to apache2 + libapache2-mod-layout.
[01:21] <persia> awen_: If the smooth upgrade doesn't work, the dummy package doesn't help.
[01:21] <awen_> persia: so i should keep the libapache-mod-layout as source name, but change the package name?
[01:23] <persia> awen_: Right.  Changing source package names should be avoided when following the same upstream, to prevent another source NEW delay.  There will still be a binary NEW delay with a new binary package, so you might want to do the upgrade testing against a PPA or local repo before committing.
[01:24] <awen_> persia: okay, i thought so... how do you make such a dummy / migration package?
[01:24]  * persia wishes the apache removal was listed on http://wiki.debian.org/OngoingTransitions
[01:25] <persia> awen_: In debian/control have a stanza for the now obsolete binary package that depends on the new binary package, with a description indicating it is a dummy package, and don't install any files in the dummy package.
[01:28] <awen_> persia: okay, i'll do that
[01:31] <awen_> persia: it doesn't seem that apache is made as a dummy package for apache2... do we know how that migration should work when upgrading?
[01:32] <bddebian> Heya gang
[01:32] <persia> awen_: Not exactly.  I can't find documentation for that transition: it seems to be of the "apache is bad, let's remove it" variety.  Maybe we don't need the transition.
[01:32]  * persia searches the ML archives again
[01:34] <awen_> persia: okay... i also wondered why i couldn't find any other apache module migration packages, so you might be right :/
[01:38] <persia> awen_: Digging through the mailing lists, it appears that different packages chose different routes for the migration.  According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429126 there doesn't seem to be a maintainer decision in Debian about the way to proceed with this package.  Maybe just bump the build-depends, leave the binary package name the same, and make sure it works with apache2.
[01:38] <ubotu> Debian bug 429126 in libapache-mod-layout "please update/request removal of your package" [Serious,Open]
[01:39] <awen_> persia: all the other modules has changed name to libapache2-mod* , so not to confuse people i think the name should be changed?
[01:40] <awen_> source name remains the same of course :)
[01:41] <persia> awen_: You may if you like.  My investigation of apt-cache shows that 2 in 3 packages appear to have made a binary name transition, and 1 in 3 didn't (yet many of the 1 in 3 now depend on apache2).
[01:42] <awen_> persia: okay, i'll go with the majority then :) ... but it's good that we are persistent :)
[01:42] <persia> The argument in favor of using the new name and dropping the old is that the obsolete packages will stay on upgraded systems and the system admin can schedule the apache upgrade separately from the OS upgrade.
[01:43] <persia> The argument in favor of using the old name is that administrators will be upgraded to the newest version with no hassle (although the web applications might break).  Going with the majority is likely safe, as with the current two ways to do it plan, most upgrades will break.
[01:46] <awen_> if just all chose the name changing path, it would be pretty safe to do an upgrade... might be something to warn about, as this likely applies to a dapper->hardy upgrade (LTS-2-LTS)
[01:49] <awen_> persia: when the package is done, what should i then do with it
[01:49] <awen_> ?
[01:51] <persia> awen_: Yes.  This transition apparently needs closer investigation :)  If you'd like to look at what all 154 packages currently do, and send a recommendation to the ubuntu-server@l.u.c, it may be well received, and would be a good first step to making this a safe transition.
[01:52] <persia> When you have a tested patch, submit it to the sponsors queue.  Look through "Preparing New Revisions" on https://wiki.ubuntu.com/MOTU/Contributing for some guidelines on best practice and procedure for requesting sponsoring.
[02:03] <johandc> Hi, i want to build a source package on my 4-way sparc64 server, but somehow dpkg-buildpackage is only using one cpu to compile. How can i set something like the -j 8 flag with dpkg?
[02:04] <persia> johandc: You likely just have to pass a different value of $(MAKE) to debian/rules.  Someone did it across the Debian archive - might be worth searching for "Debian parallel build" to see if you can find their instructions.
[02:05] <johandc> Ahh, sounds easy. I'll take a look.
[02:06] <persia> johandc: Also note that some packages have Makefiles that will cause single-threaded builds anyway, so you might not get the expected results.  Further, some packages have Makefiles that assume serial build, which may cause FTBFS (this is the minority).
[02:07] <persia> johandc: Ah.  `dpkg-buildpackage -j9` ought do what you want (assuming 8 cores).
[02:07] <johandc> I just found that you can really just pass the -j8 option directly to dpkg-buildpackage. However, as you say, 1 out of 10 packages fail with parallel builds.
[02:07] <johandc> Ahh i see, i have four cores, so that should be -j5 then.
[02:08] <persia> johandc: Well, depends on the overall architecture.  numcores+numiochannels is the right calculation, but most people don't have multiple parallel IO channels in their hardware.
[02:10] <johandc> Ahh, that makes sense :)
[02:10]  * persia misses backplane servers
[02:13] <johandc> Hehe, this is actually some old iron i'm reviving here. A Sun Enterprise 440-R with 4 Gb Ram and 4 300Mhz UltraSparc-II CPUs.
[02:13] <johandc> However we depend on openafs, which has been broken for sparc64 for quite a while, so i'm keen to se if the new release will build :)
[02:14] <persia> johandc: Ah.  I've just been chasing that sync bug :)  Changelog makes it look like it should.
[02:15] <johandc> It also fixes a gutsy bug with 1.4.5, Russ wanted to wait for 1.4.6 which is out now.
[02:16] <persia> I think it'd be better to extract and backport the patch to 1.4.5 if trying to apply to gutsy, rather than trying to upgrade.  Pushing a new upstream in a SRU has a very high barrier to approval.
[02:16] <johandc> Build completed successfully on gutsy sparc64 without any patches!
[02:17] <persia> Do you mean, no additional patches, or is upstream clean now?
[02:17] <johandc> *Jumps happily up and down*
[02:17] <johandc> I mean, i didn't have to modify the source myself. I could just get deb-src and run buildpkg
[02:18] <johandc> Ohh wait.
[02:18] <johandc> I still need to compile modules-source
[02:24] <awen_> persia: interdiff has been uploaded :) ... halfway through all the old apache1.3 modules now, and a lot work generated for ubuntu-universe-sponsors ;)
[02:25] <Fujitsu> awen_: Are you testing that they actually work?
[02:26] <awen_> Fujitsu: only had one thing to upload until now, and this has been testet... the rest is removal requests
[02:26] <Fujitsu> Ah, good to see them go.
[02:27] <awen_> luckily the functionality has been moving to the core, or is avaible in another package already, in nearly all the cases until now
[02:27] <Fujitsu> I will be glad to see http://qa.ubuntuwire.com/debcheck/debcheck.py?dist=hardy&list=universe%2donly%2drelationship%2dDepends&arch=EVERY somewhat shorter.
[02:29] <awen_> Fujitsu: yes... i've forwarded 9 of those to the sponsors since yesterday :)
[02:33] <persia> awen_: Just a note: "I" used in bug descriptions is not very informative, especially when added by someone other than the bug submitter :)
[02:35] <awen_> persia: you have a point there :) ... normally i just add notes, didn't really think of that
[02:51] <awen_> persia: when doing a new upstream release should the source package then be included, or is it enough with the interdiff?
[02:57] <persia> awen_: As long as the package has a working watch file or get-orig-source rule, the interdiff is sufficient.
[03:01] <awen_> persia: it sounds like i need to provide the source also
[03:02] <persia> awen_: Which package?  Let's look at a specific case, which can then be abstracted for the future general case.
[03:02] <awen_> bug 145528
[03:02] <ubotu> Launchpad bug 145528 in libapache-mod-layout "[UNMETDEPS] libapache-mod-layout has unmet dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/145528
[03:06] <persia> awen_: In this case, you would want to add a watch file to your candidate package.  This is especially important, as the download URL identified in debian/copyright is no longer valid, so the package does not currently identify the upstream source correctly.
[03:07] <awen_> shouldn't the link in the copyright file be changed then?
[03:07] <persia> awen_: Yes.  To restore the upstream indicator, in addition to the new upstream version, you'll want to update debian/copyright and add a watch file.
[03:08] <awen_> persia: what should the watch file contain... do you have an example/description?
[03:09] <persia> awen_: Man uscan for a description. Look at https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch for a discussion.
[03:11] <persia> awen_: I've reassigned the bug to you.  Please unassign, and push back to the sponsors queue when you've fixed that.
[03:12] <awen_> persia: okay, i'll have a look at that
[03:13] <persia> awen_: Thanks.
[03:13] <awen_> persia: what does the version=3 mean in the guide?
[03:14] <persia> awen_: watch file syntax version 3.  The current standard.
[03:14] <CyberMatt> Just so everybody knows i'm busy with the th holidays and that and I probably won't be active that much until December 28 and if this message goes anywhere where it not wanted i apologize
[03:21] <awen_> persia: now these original source packages contains a folder with the same name as the tar-gz file instead of just having the contents in the root of the archive... anything you should be aware of there?
[03:22] <persia> awen_: dpkg should be smart enough to handle that.
[03:22] <awen_> persia: okay :)
[03:29] <awen_> persia: just to be 100% sure now... do we start with *-0ubuntu0 or *-0ubuntu1 as initial version*-0ubuntu0
[03:29] <awen_> persia: just to be 100% sure now... do we start with *-0ubuntu0 or *-0ubuntu1 as initial version?
[03:30] <persia> "-0ubuntu1" meaning "Debian Revision 0", "Ubuntu Revision 1".  Since Debian always starts with revision 1, this makes it safe to merge or sync if Debian is updated.
[03:31] <awen_> persia: i was correct then :)
[03:42] <nenolod> are we in DebianImportFreeze yet?
[03:42] <persia> nenolod: Yes.
[03:42] <nenolod> fghgds.
[03:42] <persia> nenolod: Why fghgds?
[03:42] <nenolod> can someone import inspircd and upse from debian unstable? (there is a sync bug for inspircd, but there's nothing to sync for either package.)
[03:43] <nenolod> they both compile fine under hardy and introduce no new major problems
[03:43] <persia> nenolod: How do you mean "nothing to sync for either package"?
[03:43] <nenolod> persia, nothing in ubuntu to merge. ;)
[03:44] <persia> nenolod: Ah.  Right.  Do they provide any interesting features or fix any outstanding bugs?
[03:45] <nenolod> persia, they are new packages. inspircd provides a more modernized ircd package than what ubuntu presently offers, and upse provides a better PSX module player than what modplug provides in audacious.
[03:48] <persia> nenolod: OK.  That sounds useful.  Each one just needs a sync request bug.  Subscribe the universe sponsors for new stuff in universe.  They'll likely get pushed to the archive admins with a minimum of fuss, but the archive admins might be a bit about pulling them: I don't believe there are any manual queue processing days scheduled for next week.
[03:48] <nenolod> right.
[03:49] <nenolod> persia, i'll fix the one sync request bug and create one for upse then.
[03:49] <persia> nenolod: Thanks.
[03:49] <persia> nenolod: Since we're past DIF, it's a good idea to summarize why the package should be in hardy at the top of the sync request bug (above the Debian changelog).
[03:55] <nenolod> persia, hmm. it won't let me select an arbitrary sourcepackagename
[03:56] <persia> nenolod: File requests for new packages against Ubuntu with a summary like "Please sync foo version-revision into universe from Debian unstable (main)"
[03:57] <persia> (no source package: just https;//bugs.launchpad.net/ubuntu/+filebug
[03:57] <persia> )
[03:57] <nenolod> oh, ok. :)
[03:58] <joejaxx> nice
[03:59]  * joejaxx just wrote a nice little script to download fedora source archives :)
[04:00] <persia> joejaxx: Does it have a function to automatically compare patches against Ubuntu, and generate a new patch set as a candidate application for an updated revision?
[04:00] <joejaxx> no
[04:01] <joejaxx> but i can probably add that
[04:01] <joejaxx> this is for packages that are not in ubuntu
[04:01] <persia> joejaxx: That'd be fairly cool.
[04:01] <joejaxx> as it is a process to get source from fedora at the moment
[04:01] <joejaxx> i will write that up tomorrow
[04:02] <joejaxx> the feature you requested that is
[04:02] <persia> For packages not in Ubuntu, it's likely also very interesting, but then my wishlist enhancement would be to automatically generate a candidate Debian-format package from the source.
[04:02] <persia> joejaxx: Cool.  Thanks :)
[04:02] <joejaxx> you are most welcome :)
[04:04] <joejaxx> haha import.ubunt.com :P
[04:04] <joejaxx> ubuntu*
[04:04] <joejaxx> oh whoops i need to build this in a hardy chroot
[04:05] <persia> joejaxx: Exactly what I was thinking.  Having a list of packages in Fedora, SuSE, etc. that aren't in Ubuntu, with candidates ready for review would be a nice step along the path to world domination.
[04:05] <joejaxx> yeap
[04:06] <joejaxx> should be very interesting
[04:07] <joejaxx> persia: it is funny
[04:07] <joejaxx> i am always scripting something
[04:07] <joejaxx> like i created a crawler for launchpad to retrieve build logs for packages
[04:08] <joejaxx> lol
[04:08] <persia> joejaxx: You know about http://qa.ubuntuwire.com/ftbfs/ right?
[04:08] <joejaxx> since there was not an easy way to do that
[04:08] <joejaxx> sure
[04:08] <minghua> Interesting idea indeed.  Although it's probably going to be a bit problematic with different package names for the same software...
[04:08] <joejaxx> but i wanted the actual build logs
[04:09] <persia> minghua: Surely.
[04:09] <joejaxx> and no one could point me to a central place for them
[04:09] <joejaxx> :P
[04:09] <joejaxx> so i just run lp-crawl buildlogs distro <pkgname>
[04:09] <joejaxx> lol
[04:10] <joejaxx> minghua: alias list
[04:10] <joejaxx> an alias list*
[04:11] <imbrandon> with 20k+ aliases :)
[04:11] <joejaxx> imbrandon: lolol
[04:11] <imbrandon> heya joejaxx
[04:11] <persia> joejaxx: Part of the issue is that an alias list is insufficient, due to differences in how packages are split.
[04:11] <joejaxx> persia: you can get around that :)
[04:12] <joejaxx> imbrandon: hello
[04:12] <minghua> persia: If it's done on source package level, splitting is probably not a big deal.
[04:17] <joejaxx> :)
[04:18] <joejaxx> gaahhh
[04:18] <joejaxx> no
[04:18] <joejaxx> fedora uses python :(
[04:18] <Fujitsu> ... is that a problem?
[04:18] <joejaxx> it means i have to package a python package now
[04:19] <Fujitsu> Haha.
[04:19] <joejaxx> yeah
[04:19] <joejaxx> it stinks
[04:19] <joejaxx> :\
[04:21] <joejaxx> anyone have a tutorial on packaging python apps?
[04:21] <joejaxx> :\
[04:21] <joejaxx> or a link to the policy rather
[04:21] <persia> nenolod: Better to redescribe/retitle a bug than file a new one and mark a duplicate.  Very few submitters ever complain about someone hijacking their bug.
[04:21] <Fujitsu> http://wiki.debian.org/DebianPython/NewPolicy, I think.
[04:22] <joejaxx> Fujitsu: ok
[04:22] <persia> minghua: Yes, for most cases source package splits are more similar than binary package splits, but there are exceptions, even there.
[04:22]  * minghua needs to learn python packaging as well.
[04:22] <nenolod> persia, the comments lead me to believe that the inspircd bug may have been entirely incorrect, so i decided to start from scratch. sorry. :P
[04:22] <joejaxx> we use python-central in ubuntu right?
[04:23] <joejaxx> i have seen that in packages
[04:23] <persia> nenolod: Understood.  More than anything, the comments appeared to me to be a request for the changelog, etc.  Doesn't really matter, except that it increases bug churn.
[04:23] <persia> joejaxx: Either python-central or python-support, as you like.
[04:24] <joejaxx> this should be interesting
[04:25] <joejaxx> it should be funny packaging a package that is in a language that i do not know
[04:25] <joejaxx> lol
[04:26]  * joejaxx goes to read python debian policy
[04:33]  * minghua notes that there is a /usr/share/doc/python-dev/python-policy.html/ directory.
[04:43] <awen_> persia: a new interdiff of mod_layout is ready... thanks for all the help and good night :)
[04:44] <persia> awen_: Excellent.  Good night, and thanks for working through those: hardy apache will be less confusing in part due to your efforts.  Please be sure to unassign yourself and resubscribe the sponsors queue to get it uploaded.
[04:45] <awen_> persia: thanks... and it's already done
[04:49] <minghua> Hmm, so ubuntu-keyring package is actually ubuntu-ARCHIVE-keyring...
[04:50] <persia> minghua: Right, because of the no-binary-uploads thing.
[04:50] <minghua> persia: Eh?  How is that related?
[04:51] <minghua> I just want to have a keyring of all (core) developers' keys.
[04:51] <persia> minghua: Because all builds are signed by the archive, there's no need to pass the developer keyring to end-users (or at least that was the thought).
[04:51] <persia> For keyrings for a specific LP group, there's a script.  I'll try to find the source...
[04:51]  * minghua thinks persia is wrong, but let my check first.
[04:52] <minghua> persia: Don't bother, I don't really need it.
[04:54] <persia> minghua: OK.
[04:54] <minghua> persia: No, you are wrong.  The source packages (.dsc) is still signed by the uploader.
[04:55] <minghua> persia: And in both Debian and Ubuntu, the signature for the binary package is not publicly visible anyway (they are in the .changes files in Debian).
[04:55] <persia> minghua: I still believe I'm right that the justification for not including all the keys in the keyring was because of the no binary uploads.  I don't have a strong opinion about whether this is correct or not.
[04:56] <minghua> persia: Debian has the DDs' keys in a keyring package so that people can check the source packages.
[04:57] <minghua> persia: In Debian the authentication of binary packages are done on APT level instead of the individual package level.
[04:57] <minghua> persia: So I don't see it related to binary upload in any way.
[05:00] <persia> minghua: Maybe I'm wrong then.  Anyway, the source I thought would do it actually pulls the SSH keys, which doesn't help you.
[05:01] <Fujitsu> persia: REVU has a script to do it.
[05:02] <minghua> persia: Thanks anyway.  What I was really looking for is actually debian-keyring, which is useful when pulling Debian packages.
[05:03] <persia> Fujitsu: Thanks
[05:03] <persia> minghua: http://codebrowse.launchpad.net/~revu-hackers/revu/trunk/annotate/sistpoty%40ubuntu.com-20071209131716-o9h8b78c3kg2etaz?file_id=revukey-20060622101810-953d1fd4f9521e28 ought to be a good place to start if you want a keyring for a given LP group.
[05:04] <persia> Or maybe http://codebrowse.launchpad.net/~revu-hackers/revu/trunk/annotate/sistpoty%40ubuntu.com-20071209131716-o9h8b78c3kg2etaz?file_id=fetchlaunchpadkeys.py-20060622101814-d24e46fc40cf5420
[05:06] <minghua> persia: Thanks.
[06:30] <warp10> Hi all!
[06:38] <Fjodor> Hi all. Is there a channel for backports, and if not, would this be the place?
[06:39] <crimsun> I don't know of one, but perhaps jdong or imbrandon does?
[06:39] <Hobbsee> jdong: ping.  backports questoin
[06:39] <crimsun> (otherwise, see https://help.ubuntu.com/community/UbuntuBackports#head-37a793d5ee480081f1c9f19e07fcdcdae5e6a9ed if you're interested in requesting a new one.)
[06:40] <jdong> I'm alive
[06:40] <jdong> sup?
[06:40] <Fjodor> Actually, I'm not sure if I have asked before (bad wetware memory), but I requested it on launchpad (no response yet), and just wanted to hear if there was anyone I could ping, since I'm idling at the keyboard anyways :-)
[06:41] <jdong> yeah, I was encased in exam season the past few weeks
[06:41] <jdong> if you've filed a lp bug please link to it and I'll take a look right now
[06:41] <Fjodor> Anyways, just wondered about compiz things. Recent stuff seems to be backported, except for compizconfig-settings-manager
[06:41] <Fjodor> jdong: Excellent. I'll go find it :-)
[06:42] <Fjodor> jdong: https://bugs.launchpad.net/bugs/175450
[06:42] <ubotu> Launchpad bug 175450 in gutsy-backports "Please backport compizconfig-settings-manager" [Undecided,New]
[06:43] <Fjodor> And I've had my share of exam stress as well, which might account for my lack of memory of much else, so I can sympathise :-)
[06:43] <jdong> Fjodor: mvo performed the compiz backport, I'd try to check with him or Amaranth or some other compiz know-it-all to see if this is compatible with Gutsy
[06:43] <jdong> Fjodor: I don't feel confident enough to approve it off the bat.
[06:44] <Hobbsee> jdong: it should be.  and if not, it's only backports.

[06:44] <Fjodor> mvo or or Amaranth. Got it. Thanks :-)
[06:44] <Fjodor> Amaranth: ping?
[06:44] <Hobbsee> *cough*flashplugin-nonfree*cough*
[06:44]  * Hobbsee doubts they're here, this close to christmas
[06:44] <jdong> Hobbsee: :)
[06:44] <Hobbsee> !jdong | jdong
[06:44] <ubotu> jdong: <Hobbsee> jdong: yes, but you're FULL OF CRACK!
[06:45] <Fjodor> Hobbsee: Ok, I'll take your word for it since you most probably know them better. Just noticed that Amaranth at least had an account online ;-)
[06:46] <Hobbsee> this is true
[06:46] <jdong> Fjodor: he always has an account online :)
[06:47] <crimsun> flashplugin-nonfree was removed from -proposed, at least
[06:47] <crimsun> (I haven't followed the rationale, but I presume it makes sense.)
[06:47] <Hobbsee> crimsun: i meant last time
[06:47] <Fujitsu> Flash never makes sense, silly crimsun.
[06:48] <Fjodor> jdong: Naturally :-)
[06:48] <crimsun> I dunno, it makes plenty of sense to me.  I just avoid it.  :)
[06:58]  * persia notes that flashplugin-nonfree was removed from -proposed because it broke konqueror (segfaults), and points at https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024877.html for discussion
[07:00] <crimsun> persia: right, thanks.
[07:02] <Hobbsee> meh.  who uses konq to browse flash anyway?
[07:09] <persia> Hobbsee: Anyone with local flash content?
[07:09] <Hobbsee> doesn't work wiht firefox?
[07:10]  * persia thought konq attempted to render thumbnails in local windows, and crashing wouldn't be ideal.
[07:11]  * Hobbsee doesn't use konq for anything more than file browsing, and kioslaves
[07:11] <Hobbsee> for http/https, i use firefox.
[07:11] <persia> Hobbsee: *local* flash :)
[07:11] <Hobbsee> yeah, but still
[07:11] <Hobbsee> why would you have *local* flash anyway?
[07:12] <persia> Hobbsee: Maybe you saved something nifty?  Maybe you're a flash developer?  Maybe you need to preview things before they go live?  Lots of use cases.
[07:12] <Hobbsee> 1. possible.  2&3: madness.  take out and shoot.
[07:15] <Fjodor> Hobbsee: For some odd reason that I can't pinpoint exactly, you just earned a smiley-face in my little black book :-P
[07:15] <Hobbsee> hehe :)
[07:15]  * Hobbsee earns doom-worthy things - not smiley faces.
[07:17]  * persia gives Hobbsee a smiley face of doom
[07:17] <Fjodor> Hobbsee: Those would probably also amount to positive notes in my book, but then again, I'm somewhat twisted ;-)
[07:18]  * Hobbsee DOOOOOOOOOOOOOOOOOOOOMS persia
[07:20]  * ScottK2 uses Konqueror for web browsing all the time.
[07:35] <minghua> Hmm, perl 5.10.
[08:02] <Amaranth> Fjodor, jdong: None of the compiz stuff in hardy can be backported
[08:03] <Amaranth> We did an update that was compatible with gutsy just so we could do a backport before breaking compatibility, i guess ccsm didn't have any interesting changes
[08:35] <\sh> moins
[09:11] <imbrandon> Amaranth: any idea what causes the "white" screen when compiz is enabled and user switching is used?
[09:11] <Amaranth> imbrandon: nvidia sucks
[09:11] <imbrandon> i did a little searching but only came up with "turn copmiz off"
[09:11] <imbrandon> heh
[09:12] <imbrandon> Amaranth: true true, any work arrounds you know about ?
[09:12] <Amaranth> If you create a texture after you do a VT switch away from the X server the texture gets no memory allocated
[09:12] <Amaranth> in this case the texture is the fullscreen gnome-screensaver window so it looks like a blank white screen
[09:12] <Amaranth> you can blindly type your password though :P
[09:12] <imbrandon> yea , this is for my father-in-law though
[09:13] <imbrandon> heh
[09:13] <Amaranth> Nope, I just make sure IRC isn't my active window before switching then blindly type my password
[09:13] <imbrandon> on my system i just dont use user switching
[09:13] <Amaranth> Otherwise your choices are don't have a screensaver or don't use compiz
[09:13] <imbrandon> :)
[09:13] <imbrandon> ahh, alt+s also works too fyi
[09:13] <imbrandon> re-brings up the gdm window
[09:14] <Amaranth> sure, alt-s is the shortcut for switch user on the lock screen :)
[09:14] <imbrandon> okies anyhow i just had him turn window effects off, that seems to work for now
[09:15] <imbrandon> hes almost 70 and dosent really use the eye candy anyhow
[09:15] <imbrandon> as long as he has frostwire + amarok he's happy :)
[09:16] <imbrandon> well and evolution, i've never seen someone send out so much "junk" that wasent spam
[09:16] <imbrandon> lol
[09:16] <Amaranth> hehe
[09:17] <imbrandon> you know the "FW: FW: FWD: ..." jokes anyone thats been on the net more than 6 months has probably seen 1000 too many of
[09:17] <imbrandon> ugh
[09:17] <Amaranth> oh man i still get those from my grandmother
[09:18] <StevenK> imbrandon: Where in apt-mirror should I be looking to fix this :80 thing?
[09:18] <imbrandon> yea i pipe them all to a folder then he wonders why on the off chance he sends me a "regular message" i dont see it for a week ( about the time i glance in the folder )
[09:19] <imbrandon> StevenK: um 2 places, the main one "arround" line 380ish , lemmme look exactly
[09:19] <imbrandon> the second would be the clean.sh generation
[09:20] <imbrandon> StevenK: sub proceed_index_gz  ( line 367 in my copy but i have a few local only changes )
[09:21] <imbrandon> so might not be exact
[09:21] <StevenK> get_variable("mirror_path") should DTRT
[09:22] <StevenK> Wait, mirror_path is the wrong place
[09:22] <imbrandon> well yea but then it appends the $path thats actualy a mangled uri
[09:23] <imbrandon> that should end up host.name.com striped
[09:29] <\sh> hmmm
[09:30] <\sh> somehow the ssl support for wine32 on x86_64 doesn't work...I think it doesn't catch up with the libssl from ia32-libs
[09:31] <imbrandon> wine is actauly working on *64 now ?
[09:31] <imbrandon> cool
[09:31] <\sh> imbrandon, since gutsy afaik...we are building wine with 32bit on amd64
[09:32] <imbrandon> ahh cool, i havent really tried x86_64 since edgy, just ran 32bit
[09:32] <imbrandon> other than the ocasional test in a vm
[09:33] <imbrandon> i'd be really cool if we ( e.g. debian based distros ) got real bi-arch support
[09:33] <\sh> well, there is a problem not having libssl support, e.g. icrap from bitten peach will fail
[09:33] <imbrandon> ouch
[09:34] <\sh> but only on x86_64
[09:34] <imbrandon> anything higher than iTunes 4.7 working ?
[09:34] <\sh> and as I'm the fcker who took the change to update 0.9.46 to 0.9.51 I have to fix it ;)
[09:35] <imbrandon> hehe
[09:35] <\sh> s/change/chance/
[09:35] <imbrandon> i barely can use wine, let alone debug problems with it :) but if i can help lemme know
[09:35] <\sh> imbrandon, dunno...I'll test it later on when I find the solution for the problem
[09:35] <imbrandon> k
[09:35] <\sh> imbrandon, no one can debug problems in wine...wine is da problem ;)
[09:36] <imbrandon> yea latests iTunes and Photoshop are the only things in my windows VM anymore
[09:36] <imbrandon> and PS works fine, i've just been too lazy to install it
[09:36] <imbrandon> in wine
[09:36] <imbrandon> s/install/reinstall
[09:37] <imbrandon> esp since persia or someone pointed me to pdfedit , no more need for acrobat
[09:37] <imbrandon> :)
[09:38] <\sh> hmm...I never used anything to create pdfs then ooffice...that's enough for CVs and stupid people wanting pdf or .doc files for their inbox instead of plain ascii
[09:38] <imbrandon> StevenK: hrm seems the first replace makes $path empty
[09:38] <imbrandon> StevenK: one sec
[09:38] <\sh> catching another coffee
[09:38] <imbrandon> \sh: yea , i mostly need it to edit existing pdfs arround the office, instead of make new ones, afaik oo.o only exports them
[09:39] <\sh> imbrandon, yepp
[09:39] <imbrandon> unless its a resume i rarely make "new" pdf's anymore
[09:40] <imbrandon> or some report for work that php/asp dumps a pdf of
[09:40] <\sh> imbrandon, btw...knowing that revu is at siretarts university, do you have some other hardware for ubuntuwire?
[09:40] <imbrandon> people.uw.com has a staging revu install but its far overloaded atm to put a full one on it
[09:40] <imbrandon> s/full/main
[09:41] <imbrandon> staging.revu.ubuntuwire.com
[09:41] <\sh> imbrandon, na ... about revu online I don't care :)
[09:41] <\sh> I just wanted to know what I can do to supply more hardware :)
[09:41] <imbrandon> \sh: yea we have other hardware but its all at capasity or over so ... heh
[09:41] <imbrandon> in other words :)
[09:42] <\sh> e.g. we are repairing an ibm bladecenter in the moment...we have 4 blades inside (so with 2x xeon 3.0GHz 4GB ram and mostly 36.4 2.5" U320 SCSI HDs inside
[09:42] <\sh> there is a need for 8 HS20 blades more :)
[09:42] <imbrandon> \sh: well you can ship new boxes here is you want to the US or to Nafallo in EU , we both host hardware for UW
[09:42] <\sh> imbrandon, hosting is not the problem...that's already fixed :)
[09:42] <imbrandon> or if you can host we can talk more too ... :)
[09:43] <\sh> imbrandon, and traffic is also not a problem
[09:43] <imbrandon> ahhh drop by #ubuntuwire and chat me up a bit
[09:43] <\sh> imbrandon, done :)
[10:06] <\sh> moins DarkSun88
[10:06] <DarkSun88> Hi Stephan :)
[10:15] <Fjodor> Amaranth: Ah, ok. Thanks for clarifying :-) Merry christmas :-)
[10:56] <imbrandon> ugh wtf
[10:56] <imbrandon> it worked when i uploaded it .... :(
[10:59] <hyper___ch> hiho, when I create a .deb file out of source code, it will then only work for the system architecutre I comiled it for, right? I mean I have 32-bit system so the .deb wouldn't work on 64bit?
[11:00] <imbrandon> hyper___ch: correct
[11:00] <imbrandon> you can use the PPA to compile for both if you wish
[11:01] <hyper___ch> imbrandon: thx :) as probably only a few motus have all possible system architectures it means that most packages in ubuntu are compiled and maintained by different people for the different architecture, right?
[11:01] <imbrandon> wrong
[11:02] <imbrandon> they are managed via source only and uploaded that way, then the buildd's build for all arches
[11:02] <\sh> hyper___ch, most MOTUs have x86_32 and only some of them have x86_64 archs...
[11:02] <hyper___ch> so what do the MOTUs then? I assumed they make the .deb available?
[11:03] <hyper___ch> damn, you know I thought I did understand the whole thing now ;)
[11:03] <\sh> hyper___ch, but for building packages it doesn't matter...if your source is not compiling on x86_64 or sparc or hppa you have to look at it and fix it hopefully
[11:03] <imbrandon> they upload the dsc and such th source package
[11:04] <hyper___ch> ahhh......
[11:04] <StevenK> imbrandon: Still looking at it?
[11:04] <hyper___ch> that explains a few things
[11:04] <hyper___ch> thx
[11:04] <imbrandon> StevenK: sorta moved onto email but i still have it open
[11:06] <imbrandon> the first regex seeems broken
[11:07] <\sh> someone with time could upload drupal5_5.5-1ubuntu1 :) found http://www.sourcecode.de/~shermann/drupal5/5.5/ please debuild -S -sa -v5.3-1ubuntu1 -k<your gpg key id> , thx :)
[11:10] <geser> \sh: in progress
[11:10] <\sh> geser, thx
[11:11] <\sh> btw...does ppa now have this 1G limit?
[11:12] <Fujitsu> \sh: I don't believe it is enforced technically yet.,
[11:13]  * geser has still a 1.2 GiB PPA
[11:15] <geser> since when have bug pages (for a package) a RSS feed?
[11:15] <imbrandon> geser: since the last LP release
[11:25] <jonnymind> Hello,
[11:25] <jonnymind> what happened to revu?
[11:25] <Fujitsu> jonnymind: The server appears to have had a nasty problem, and nobody has physical access at the moment.
[11:26] <jonnymind> IC.
[11:26] <jonnymind> :-(
[11:26] <geser> \sh: uploaded
[11:27] <\sh> geser, thx a lot
[11:33] <\sh> packages.debian.org is down somehow...happy whatever ,-)
[11:40] <\sh> cool....ppa build of wine already finished :)
[11:43] <effie_jayx> \sh,  what version?
[11:43] <awen_> mod_random.c:380: error: expected expression before 'random_conf'
[11:43] <awen_> mod_random.c:380: error: initializer element is not constant
[11:43] <awen_> mod_random.c:380: error: (near initialization for 'random_module_cmds[0].cmd_data')
[11:44] <\sh> effie_jayx, 0.9.51 :)
[11:44] <awen_> anyone here knows some c code, so i can get this baby fixed and get the new version of the package out the door? :)
[11:44] <\sh> but for gutsy...
[11:45] <awen_> http://awen.dk/mod_random.c
[11:45] <\sh> Not Found
[11:45] <\sh> The requested URL /mod_random.c was not found on this server.
[11:45] <\sh> Apache/1.3.37 Server at awen.dk Port 80
[11:47] <awen_> \sh: sorry... now it's there
[11:51] <\sh> awen_, what about the theory that (void *) APR_XtOffsetOf is not a constant?
[11:53] <awen_> \sh: i think you are right... as it is a function, then it probably isn't constant enough
[11:54] <\sh> well googling for it, shows that it's used somehow in the way you did
[11:54] <awen_> can you see, what can be done about it? (my knowledge of C is still somewhat limited)
[11:55] <awen_> \sh: yeah, it seems there have been some sort of change to what is possible between apache2 to apache2.2
[11:56] <\sh> hmm...let's check out libapr ;)
[11:57] <\sh> awen_, greping for the term it says in gutsy libapr1 that it's now known as APR_OFFSETOF
[11:58] <\sh> shermann@home-p4-64:~/source/apr-1.2.7$ grep "APR_XtOffsetOf" *
[11:58] <\sh> CHANGES:  *) Renamed APR_XtOffset -> APR_OFFSET and APR_XtOffsetOf -> APR_OFFSETOF.
[11:58] <awen_> \sh: just saw that... i'll just give it a try :)
[11:59] <geser> if my google hit is still uptodate then all APR_XtOffsetOf and APR_OFFSETOF are all macros
[11:59] <\sh> geser, yepp...but APR_OFFSETOF is now the right term
[11:59]  * \sh trusts upstream :)
[12:00] <\sh> hmm...
[12:01] <\sh> wine is crashing on my emt64 machine...how nice
[12:02] <\sh> does anybody have a real amd64 machine and can check wine 0.9.51 from deb http://ppa.launchpad.net/shermann/ubuntu gutsy main
[12:02] <\sh>  ?
[12:03] <\sh> looks like that my xeon emt64 is not as compatible as it should
[12:03] <\sh> grmpf s/xeon/p4/
[12:11]  * \sh is going to prepare the stuff for this xmas thing...bbl
[12:25] <\sh> damn...I hate these days...now this supporting stand for the tree just broke in my hand...*grmpf*
[14:25] <penguin42> Hi
[14:26] <penguin42> I think the gnome debs need an anti-build dependency; I think they fail to build correctly if the old libthread-dev and libpthread20 packages are installed
[14:27] <StevenK> That is termed a Build-Conflict
[14:27] <StevenK> How do they fail to build correctly?
[14:28] <penguin42> They build but fail with the error GThread-ERROR **: file /build/buildd/glib2.0-2.14.1/gthread/gthread-posix.c: line 140 (): error 'Function not implemented' during 'pthread_getschedparam (pthread_self(), &policy, &sched)'
[14:29] <penguin42> I got this building rhythmbox from source (either from the deb or from the rhythmbox svn)
[14:29] <penguin42> there is also an easily missed warning of /usr/bin/ld: warning: libpthread.so.0, needed by /usr/lib/libgnomeui-2.so, may conflict with libpthread.so.20
[14:30] <penguin42> if you google for that Function not implemented on pthread_getschedparam you'll see a lot of unanswered threads going back quite a way of people having the same thing
[14:31] <penguin42> I would have had those packages installed since I upgraded from feisty - they aren't in gutsy and frankly it's a pitty that they didn't get removed during a dist-upgrade
[14:33] <penguin42>  #81169, #97092, #115511 are all other bugs people are having with libpthread-dev
[14:36]  * penguin42 isn't really sure where to file this - do I file it on pthreads or some gnome libs?
[14:37] <StevenK> I seem to recall something like this being discussed a while back, but I'm not sure what became of it. I'd suggest you just purge those troublesome packages and deal.
[14:38] <penguin42> yeh I have
[14:39] <penguin42> thing is it's just taken me a few hours to track it down and I can see there are loads more guys having the same problems
[14:45] <StevenK> Then file a bug against a Gnome library and ask for suggestions
[14:47] <penguin42> ok, glib looks possible - I'm just adding a comment to the end of someone elses comment at the moment
[14:48] <StevenK> I would suggest you also bring this up in #ubuntu-devel -- after the holiday season. :-)
[14:48] <penguin42> after the holiday season I'll be back at work!
[14:48] <penguin42> (well not on a sunday but still...)
[14:48]  * penguin42 gets to hack on stuff during his holidays
[14:49] <zul> morning
[14:54] <penguin42> StevenK: OK, that's #178266
[15:33] <bddebian> Heya gang
[15:36] <awen_> if i have a package named 2.4.2-8build1 was is then the next ubuntu version number?
[15:37] <Nafallo> awen_: any 2.4.2-99ubuntu1
[15:37] <Nafallo> baah
[15:37] <Nafallo> awen_: 2.4.2-8ubuntu1 even
[15:38] <awen_> okay... thx Nafallo, that "build" confused me
[15:38] <Nafallo> awen_: why?
[15:38] <awen_> haven't seen it used before
[15:38] <Nafallo> k
[15:38] <awen_> especially because the append of build1 was a ubuntu change
[15:39] <Nafallo> that's wrong then :-)
[15:39] <awen_> Nafallo: thought so :)
[15:40]  * persia notes that Ubuntu users -buildN to indicate changelog-only updates for rebuilds, as there is no support for binary NMUs.  -build1 is correct, but a special case.
[15:40] <persia> s/users/uses/
[15:41] <awen_> persia: okay.. but 2.4.2-8ubuntu1 is correct then?
[15:41] <persia> awen_: Yes.
[15:42] <awen_> persia: if a new source package is build where one of the packages is removed from debian/control, does this package then get removed from the archives?
[15:42] <persia> awen_: Unless the architecture set changes at the same time, yes (and the exception is a bug).
[15:43] <awen_> persia: okay
[15:51] <awen_> persia: bug 145542 can i have you unsubscribe the archive maintainers
[15:51] <ubotu> Launchpad bug 145542 in libapache-mod-fastcgi "[UNMETDEPS] libapache-mod-fastcgi" [Wishlist,Incomplete] https://launchpad.net/bugs/145542
[15:51] <persia> awen_: No.  Only the archive admins can unsubscribe.
[15:52]  * persia encourages awen_ to ask things generally, as others may have faster or better answers.
[15:53] <dfiloni_> anyone know why revu is offline?
[15:54] <persia> dfiloni: Some issue with the server that can't be resolved remotely.  The person with local access is ill.
[15:54] <dfiloni> persia: ok thanks
[15:55] <dfiloni> persia: why my name is in bug contacts in wxwidgets2.8. I'm scared :)
[15:55] <persia> dfiloni: Didn't you subscribe as a bug contact?
[15:55] <dfiloni> *?
[15:56] <dfiloni> persia: I have subscribed only in 133888 bug
[15:56]  * persia didn't think there was any auto-subscribe for bug contacts.
[15:57] <bddebian> persia: Don't you ever sleep? :-)
[15:57] <persia> bddebian: Yes.  Typically when you are in the office, actually focusing on your job :)
[15:57] <bddebian> Uhm, that would be never :-)
[15:57] <persia> See.
[16:00] <geser> Hi bddebian
[16:00] <bddebian> Heya geser
[16:13] <persia> awen_: In addition to removing libapache-mod-fastcgi from control, consider cleaning it out of debian/rules and removing the support files (maintainer scripts, debhelper files, etc.)
[16:14] <awen_> persia: yes, probably a good idea
[16:21] <awen_> should a debian/compat file be made if it doesn't exist?
[16:43] <pochu> awen_: yes, for debhelper compatibility >= 5 iirc
[16:44] <dfiloni> pochu: do you have in your pc wxwidgets2.8 2.8.6.1?
[16:44]  * pochu is surprised that wx2.8 /only/ has 8 bugs, as wx2.6 has.
[16:44] <pochu> I'd have expected it to have dozens of bugs, given the current and past discussions in debian-devel :)
[16:44] <pochu> dfiloni: yep
[16:45] <dfiloni> pochu: can you send to me diff and dsc file?
[16:45] <pochu> Sure.
[16:46] <pochu> Do I have your mail?
[16:46] <pochu> dfiloni: I don't know whether you have updated it after I got it
[16:46] <dfiloni> pochu: d.filoni@devid-filoni.com
[16:47] <dfiloni> pochu: I don't know, but I think is the lastest version that I've done
[16:47]  * persia notes that there is an interdiff posted in bug #133888, and would be willing to walk anyone through reconstructing the package therefrom
[16:47] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the 2.8.6.1 release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[16:48] <pochu> dfiloni: sent
[16:48] <pochu> persia: diff.gz is easier ;-)
[16:49] <persia> pochu: Yes, but I'm not in any way convinced that the file you just sent matches the file from the interdiff, and interdiff -> diff.gz is one command.
[16:49] <persia> (combinediff -z interdiff, old-diff.gz)
[16:49] <pochu> persia: btw I wasn't able to attend the MOTU meeting - what was the discussion regarding interdiff this friday? I saw you proposed getting rid of it.
[16:50] <pochu> persia: Is that interdiff up-to-date?
[16:50] <persia> pochu: Everyone who attended the meeting had no issues with interdiff.  That interdiff is the one I approved.
[16:50]  * persia moves writing minutes higher on the TODO queue
[16:51] <dfiloni> persia: How I can get source from interdiff?
[16:52]  * pochu wonders what an iterdiff is :-P
[16:52] <persia> OK.  Interdiff is documented at https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
[16:52] <pochu> heh, just kidding ;-)
[16:53] <pochu> I mean that I have never done one, as I haven't needed it yet :-)
[16:53] <dfiloni> *can I :P
[16:53] <pochu> But should be an interesting read
[16:53] <persia> If you have an interdiff file and the old diff.gz with `combinediff -z packagename_version-revision.diff.gz packagename_newversion-newrevision.interdiff.gz | gzip --best -c - > packagename_newversion-newrevision.diff.gz `
[16:54] <persia> From the new diff.gz, you can use filterdiff to extract the debian/ directory, and grab the new upstream source from either the watch file or the get-orig-source rule in debian rules (specific commands on the wiki page).
[16:55] <persia> Then, you unpack the upstream source, apply the diff from the constructed diff.gz, and you have a new package directory.  From this, you can create the source package with the standard package build tools (debuild, dpkg-buildpackage, etc.).
[16:55] <DrKranz> persia, does your script on ubuntuwire does this by itself?
[16:57] <persia> DktrKranz: Yes, but it breaks a lot, which is why it's not linked from the Interdiff page.
[16:57] <DrKranz> so, I guess I have to follow the procedure above
[16:58] <persia> DrKranz: You can try my script.  You're also welcome to improve it.  While my script works in some cases, I find I usually do it manually anyway.  I keep meaning to fix the script, but haven't gotten around to it yet.
[16:59] <DrKranz> I need to learn how to use interdiff properly, so I have to learn how it works before attempting to automate the process
[17:00] <persia> DrKranz: Basically, it tracks the differences between two patches.  This allows the conversion of the old patch into a new patch, creating the new diff.gz.  The rest of the instructions are more about creating a source package from a diff.gz.
[17:01] <DrKranz> Ok, I'll have a look to upload wxwidgets
[17:01] <DrKranz> on my PPA for testing purposes
[17:13] <DrKranz> persia, I received "combinediff: Garbled patch". Is this OK?
[17:14] <awen_> DrKranz: no... you should receive empty output
[17:14] <persia> DrKranz: Erf?
[17:14]  * persia tries
[17:15] <DrKranz> persia, it is from your interdiff in bug 133888
[17:15] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the 2.8.6.1 release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[17:17] <persia> DktrKranz: `combinediff -z wxwidgets2.8_2.8.4.0-0ubuntu3_2.8.6.1-0ubuntu1.interdiff.gz wxwidgets2.8_2.8.4.0-0ubuntu3.diff.gz | gzip --best -c - > wxwidgets2.8_2.8.6.1-0ubuntu1.diff.gz` gives me no output, and a clean wxwidgets2.8_2.8.6.1-0ubuntu1.diff.gz
[17:18] <dfiloni_> persia: also to me
[17:18]  * DktrKranz inverted .diff.gz and .interdiff.gz
[17:19]  * persia has made that mistake lots & lots of times :)
[17:19]  * DktrKranz is on his way to make that mistake again
[17:20]  * dfiloni_ do the same thing....
[17:31] <DktrKranz> dfiloni_, persia, uploading wxwidgets2.8 to my PPA for a final test build
[17:32] <persia> DktrKranz: Thanks.
[17:32] <dfiloni_> DktrKranz: thanks
[17:32]  * pochu hugs y'all
[17:33] <DktrKranz> heya pochu! :)
[17:33] <pochu> This is the upload with more people involved I've ever seen :-)
[17:36] <DktrKranz> I don't know, but at least eight eyes looked at that
[17:36] <dfiloni> pochu: wow
[17:36] <DktrKranz> uploading 32 Mb can be frustrating sometimes...
[17:37] <pochu> specially when you put foo-security instead of foo and then the upload was rejected o.O
[17:38] <DktrKranz> heh
[17:38] <pochu> The difference is that that happened to me with wesnoth which is 60 or 70 MB :-/
[17:38]  * DktrKranz thinks to who pushes openoffice...
[17:39]  * persia notes that upstream also looked at it, in addition to at least 3 MOTUs and 2 active Contributors
[17:39] <stgraber> that's why I do packaging of big packages on a dedicated server with 100Mb/s internet :) (well, that's mainly homemade packages for some schools)
[17:39] <DktrKranz> \o/
[17:39]  * dfiloni don't think... no more stress about package for him
[17:39] <DktrKranz> stgraber, my aDSL is 30Kb during uploads...
[17:39] <DktrKranz> :)
[17:39] <pochu> persia: who's the other MOTU? bluekuja?
[17:39] <pochu> dfiloni: hehe
[17:39] <persia> pochu: Yes.
[17:40] <pochu> Ah, cool. I didn't know he reviewed it :)
[17:40] <dfiloni> pochu: all this for my guilt
[17:40] <pochu> That's five then, even more that what I was counting ;)
[17:40]  * DktrKranz limited to some tests, not a full review
[17:40] <persia> pochu: six: don't discount upstream :)
[17:41] <pochu> dfiloni: you rock! :-)
[17:41] <pochu> persia: did upstream tested dfiloni's package? o.O
[17:41] <DktrKranz> what about someone who has glasses? does he count as double?
[17:41] <dfiloni> DktrKranz: I think no body had gone a full review
[17:41] <persia> pochu: I don't know about tested, but commented on my review of the interdiff.
[17:41] <dfiloni> *nobody
[17:42]  * persia looked at every byte of dfiloni's work at least twice
[17:42] <dfiloni> persia: GREAT!
[17:42] <DktrKranz> dfiloni, what comes next? world 0.2, new upstream version?
[17:43] <dfiloni> DktrKranz: new upstream version
[17:43] <DktrKranz> ok, remember to provide a patch for pollution and some more trees
[17:43] <pochu> DktrKranz: 2.8.7.1 :-/
[17:43] <dfiloni> DktrKranz: 2.8.7.1 version.. I'm scared
[17:44]  * pochu wonders why they don't bug bug-fix *only* releases
[17:44] <pochu> s/bug/do/
[17:44] <persia> pochu: Do you really want to be looking at wxwdigets 14.7?
[17:45] <pochu> But 6 half reviews are W: hotwire: package-contains-empty-directory usr/share/omf/hotwire/
[17:45] <pochu> woops
[17:45] <pochu> persia: please, oh please, I don't ;-)
[17:45] <DktrKranz> pochu, IIRC, wxwidgets was at 2.8.6.1
[17:46] <pochu> DktrKranz: you dont remember correctly :P dfiloni already has it packaged
[17:46] <dfiloni> now I'm working at 2.8.7.1 version
[17:46] <DktrKranz> erm... so I really missed something....
[17:46] <DktrKranz> interdiff was related to 2.8.6.1
[17:47] <pochu> DktrKranz: you are supposed to upload 2.8.6.1
[17:47] <pochu> DktrKranz: 2.8.7.1 is ... weird
[17:47]  * DktrKranz breathes again :)
[17:47] <DktrKranz> pochu, I guess wxwidgets* is weird... :)
[17:48] <dfiloni> pochu: do you want to see latest lintian output about wxwidgets2.8?
[17:48] <pochu> dfiloni: I saw it when you pasted it :-)
[17:49] <dfiloni> pochu: I'm really scared, I will work on it in the next day and happy new wxwidgets2.8
[17:49] <pochu> dfiloni: that, and the fact that they added a new editor in a ?bugfix? release is why I say it's weird ;)
[17:49]  * DktrKranz hopes Debian provide a new package *soon*
[17:49] <dfiloni> pochu: they added a new editor that add some lintian warnings/errors
[17:49]  * pochu is afraid that won't happen
[17:50] <DktrKranz> latest mail by bernd suggested to talk to debian-ctte
[17:50] <persia> DktrKranz: That's strange and contentious.  Upstream is working with Debian (and dfiloni with upstream) to make that happen.
[17:51] <DktrKranz> persia, I think it's because Ron doesn't want his package hijacked
[17:51] <DktrKranz> (his own words)
[17:52] <persia> DktrKranz: Yes.  Exactly.  Hijacks are bad, so I don't blame Ron, but it's awkward for Maintainers when upstream only works with 2.8.
[17:52]  * persia thanks Matthias for having put 2.8 in Ubuntu several releases back
[17:53] <pochu> What is funny is that wx2.8 only has 8 bugs in LP, as wx2.6 has
[17:53] <persia> pochu: Why is that funny?
[17:53] <DktrKranz> pochu, I think boa-constructor's one are related to wxwidgets2.6 :)
[17:54] <DktrKranz> upload completed \o/
[17:54] <pochu> persia: because Ron's main reason to not package wx2.8 is that wx2.8 is half broken, IIUC
[17:54] <pochu> s/half broken/buggy/
[17:54] <persia> pochu: 2.4 has no bugs, but that's mostly because nobody cares, rather than because it's not buggy.
[17:55] <pochu> persia: bug if an application crashes, and it's an wx bug, then someone moves the crash to wxwidgets
[17:55] <pochu> Although I agree that there are a lot of package to which nobody looks
[17:56] <pochu> Anyway, I have used aMule, and phatch, and Filezilla which wx2.8 and I don't think wx2.8 is that buggy.
[17:56] <persia> pochu: Right.  Since nobody uses any of the packages that depend on 2.4, it gets no bugs.  Most packages use 2.6, which is pretty stable, so it only gets a few bugs.  A few packages use 2.8, but it has just as many bugs as 2.6.  I suggest this indicates 2.8 is buggier than 2.6.
[17:56] <persia> (and, no, not that buggy)
[18:02] <AnAnt> Hello, when's the next sync with Debian ?
[18:02] <persia> AnAnt: Late April.
[18:03] <AnAnt> there are a couple of packages on Debian, that aren't on Ubuntu
[18:06] <persia> AnAnt: If there is a specific package that provides some useful feature for hardy, compiles, installs, and generally behaves well on hardy, and doesn't break anything, please file a sync request for inclusion.  Some packages will be missed, but the current focus is on integration, bugfixing, and implementation of specific hardy features, rather than including everything that can be found.
[18:07] <AnAnt> persia: what decides if it provides useful feature for hardy ?
[18:09] <persia> AnAnt: The opinion of the person researching the inclusion, based on their understanding of possible use cases.  If that person is not an Ubuntu developer, the reasoning behind inclusion is reviewed by a sponsor.
[18:10] <AnAnt> persia: well, one of them is swt-gtk
[18:11] <AnAnt> persia: the swt libraries are now provided by a new source package called swt-gtk
[18:11] <AnAnt> persia: instead of eclipse source package
[18:11] <persia> AnAnt: This is in Debian?
[18:11] <AnAnt> persia: yeah
[18:12] <persia> AnAnt: Does it also apply to the eclipse source package currently in Ubuntu?
[18:12] <AnAnt> persia: meaning what ?
[18:14] <persia> AnAnt: Well, if the current Ubuntu eclipse no longer provides the swt libraries, then swt-gtk is clearly needed in order to prevent a fairly serious regression in hardy.  On the other hand, if the last pull from Debian was before the transition, it may be safe to postpone the transition until hardy+1.
[18:14] <persia> Note that it being safe to postpone doesn't mean it should be postponed, only that someone should determine what effect the transition may have, so as to avoid too much additional work towards hardy release preparation.
[18:15] <AnAnt> persia: I don't think that the change will impact eclipse
[18:15] <AnAnt> persia: because the names of the binary packages are different
[18:17] <persia> AnAnt: OK.  If you want swt-gtk in hardy, please investigate the impact and rationale, and file a bug.  I'm not very familiar with the Ubuntu Java plans, and don't really understand why it both is and isn't related to changes that may have happened in eclipse in Debian.
[18:19] <txwikinger> persia: who decides to discontinue a package, or rather put in a transitional package pointing to the replacement?
[18:20] <persia> txwikinger: Any Ubuntu Developer.  Non-developers who have researched that either a package should be removed or that a transition is needed are encouraged to document it in a bug (with a patch if required), and forward to the sponsors queue.  (see https://bugs.launchpad.net/~ubuntu-universe-sponsors for a bunch of current examples related to apache)
[18:21] <txwikinger> ok.. thanks
[18:23] <persia> txwikinger: Just for completeness, Ubuntu also pulls a lot of transitions / removals that were planned in Debian, especially at the beginning of each release cycle.
[18:24] <txwikinger> I found a package due to the MOTU bitesizes which seems to be replaced by another
[18:24] <persia> txwikinger: Which package?
[18:24] <txwikinger> beep-media-layer
[18:24] <txwikinger> beep-media-player
[18:24] <txwikinger> supposedly replaced by audacious or something like that
[18:25] <txwikinger> Bug #116809
[18:25] <ubotu> Launchpad bug 116809 in beep-media-player "no icon in kubuntu feisty's kde menu" [Wishlist,In progress] https://launchpad.net/bugs/116809
[18:26] <AnAnt> persia: how do I request a certain pacakge to be synced ?
[18:26] <persia> txwikinger: That would be related to Debian Bug #422681.  There are some reverse dependencies that need investigation (bmp-mp4, xfce4-xmms-plugin, bmp-musepack, bmp-alarm).  Once those are cleaned up, a removal request may be placed.  It's likely not worth fixing the missing icon bug.
[18:26] <ubotu> Debian bug 422681 in ftp.debian.org "RM: beep-media-player -- RoM; RoQA; abandoned upstream; superseded by bmpx and audacious" [Normal,Open] http://bugs.debian.org/422681
[18:26] <txwikinger> sorry.. got the wrong bug: Bug #66322
[18:26] <ubotu> Launchpad bug 66322 in beep-media-player "bmp is deprecated by upstream ==> please replace it by Audacious" [Wishlist,New] https://launchpad.net/bugs/66322
[18:28] <persia> AnAnt: Bug #176721 is the last bug I filed of that type.  You might use it as a template.  Subscribe ubuntu-universe-sponsors to the bug once it is ready to get approval.
[18:28] <ubotu> Launchpad bug 176721 in ubuntu "Please sync uqm-russian 1.0.0-1 into multiverse from Debian unstable (contrib)" [Wishlist,Fix released] https://launchpad.net/bugs/176721
[18:30]  * persia idles
[18:30] <AnAnt> ok, thanks
[19:06] <pwnguin> is it really nessecary for azureus to have  -J-Xmx64m?
[19:06] <pwnguin> err
[19:06] <pwnguin> Xmx1024M
[19:09] <siretart> revu back.
[19:10] <bddebian> w00t siretart :)
[19:12] <dfiloni_> thanks for the good news siretart :)
[19:15] <siretart> i'm told the server room was too hot
[19:15] <siretart> not good
[19:15] <pwnguin> yikes
[19:22] <Nafallo> siretart: get a DC :-P
[19:23] <emgent> 	
[19:23] <emgent> Christian Democracy ? :)
[19:23] <geser> siretart: get some fresh air from outside into the room, it should be cold enough :)
[19:26] <siretart> geser: the room has no windows
[19:27] <emgent> siretart, heya :)
[19:33] <dfiloni> siretart: do you want to say che a linux pc, a "tux" is hot?
[19:33] <dfiloni> *tha
[19:33] <dfiloni> t
[19:33] <dfiloni> *do you want to say that a linux pc, a "tux" is hot?
[19:42]  * jonnymind is away: dinner
[19:48]  * awen_ is wondering what to do about libapache-mod-tsunami
[19:50] <awen_> we have version 3.0, but it doesn't work with apache2 ... and the version existing for apache2 was branched off at version 2.0 and is still this version
[20:00] <bluefoxicy> Firefox 3.0b2 is out, but Gutsy-backports reflects 3.0a8
[20:00] <bluefoxicy> does backports not carry Firefox or is there just nobody interested in backporting it?
[20:00] <bluefoxicy> (I'm not interested in running Hardy this early)
[20:01] <pochu> bluefoxicy: 3.0b2 needs to go first to Hardy. Then a backport can be requested.
[20:02] <bluefoxicy> pochu:  ah, ok.  Hardy still ships 3.0a8 or non?
[20:02] <pochu> b1
[20:03] <pochu> \o/ wxwidgets2.8 uploaded
[20:03] <pochu> dfiloni__, persia, bluekuja, cheers
[20:05] <bluefoxicy> pochu:  nods.  Launchpad is where to suggest backport?
[20:05] <pochu> bluefoxicy: launchpad.net/gutsy-backports/+bugs, yes
[20:05] <bluefoxicy> ok
[20:07] <bluefoxicy> lol X broke on hardy
[20:07] <pochu> intel?
[20:11] <bluefoxicy> yeah, under vmware
[20:11] <bluefoxicy> it said something about [ missing arguments when I asked for more details
[20:11] <Ubulette> it seems b2 will not be in hardy before xmas. it's ready but we have a dep in the NEW queue (nss)
[20:12] <bluefoxicy> kay.
[20:13] <bluefoxicy> b1 wasn't bad, I was just guessing b2 was in hardy already
[20:13] <pochu> Ubulette: poke Hobbsee when she's back. She can do NEW.
[20:14] <bluefoxicy> will Thunderbird on Hardy use xulrunner?
[20:14] <Ubulette> it's not ready yet
[20:14] <bluefoxicy> (really I'm trying to reduce my RAM usage to help my usage of VMware)
[20:15] <Ubulette> (thunderbird 3.0)
[20:15] <bluefoxicy> ok
[20:15] <Ubulette> same for seamonkey 2.0
[20:15] <bluefoxicy> seamonkey irritates me
[20:15] <Ubulette> why ?
[20:16] <bluefoxicy> I would have thought they could have made a combined Firefox + Thunderbird that used the same config directories but as i understand Seamonkey is Mozilla Suite with its own configuration directories
[20:16] <Ubulette> correct
[20:16] <bluefoxicy> picking up Seamonkey instead of FF/TB right now would probably drop my RAM usage a bit <_<
[20:17] <bluefoxicy> (since FF and TB use their own copies of the XUL and GRE and thus there's a lot of stuff that COULD be shared memory between them but isn't, mostly library rodata and .text)
[20:17] <Ubulette> i have seamonkey 2.0 ready but asac prefer to wait for it to be xulified before we push it to hardy
[20:18] <bluefoxicy> asac?
[20:18] <Ubulette> yes, ~asac
[20:19] <bluefoxicy> oh person asac, not acronym asac
[20:21] <Ubulette> https://edge.launchpad.net/~asac
[20:22] <Ubulette> but if you want to try it, it's in my ppa
[20:22] <Ubulette> https://edge.launchpad.net/~fta/+packages
[20:22] <bluefoxicy> pochu:  OK X is bitching that get-edid isn't installed
[20:23] <bluefoxicy> I installed read-edid, trying to fix.
[20:25] <bluefoxicy> failsafe X server is saying [ too many arguments and it doesn't know how to fix the 10 shared/default-x-server X server.  i did a telinit 1 and told it to xfix and it fixed it though
[20:26] <bluefoxicy> .... except it got the resolution wrong and selected the WRONG keymap.
[20:26] <bluefoxicy> (us while the terminal is on dvorak)
[20:31] <bluefoxicy> ... yeah xfix no more running that <_<
[20:31] <bluefoxicy> can you make it do exactly what it does on the live cd @_@
[20:35] <dfiloni__> pochu: now I'm here
[20:41] <warp10> Great! Looks like REVU is up now
[20:41] <siretart> lets see for how long :)
[20:41] <dfiloni> warp10: yes
[20:49] <CheGuevara> question, i am modifying a universe package and the build-depends is all on one line, is it worth changing it to be no longer then 80 characters on one line
[20:51] <geser> no, that's only unnecessary delta to debian
[20:52] <warp10> I have just uploaded a package: http://revu.ubuntuwire.com/details.py?package=tennix If someone wont take a look, thanks in advance!
[20:53] <CheGuevara> ok thanks geser
[20:53] <warp10> s/wont/want
[20:58] <\sh> grmpf...I really new it..why do I have to play with software which is broken by default
[21:17] <\sh> gna...now I have a ati x1300 pro but ati drivers arenot working :(
[21:39] <\sh> has anyone a clue what hoary-loud-experimental is?
[22:15] <\sh> WTF since when is NJAM commercial software?
[22:20] <\sh> hell he merged njam2 to a commercial app
[23:17] <ScottK2> imbrandon: Are you around?
[23:17] <imbrandon> yup
[23:17] <imbrandon> make it ok?
[23:18] <nenolod> hi. i have a debdiff for audacious in ubuntu to make it use pulseaudio by default.
[23:18] <nenolod> ;)
[23:19] <ScottK2> imbrandon: Yes.
[23:19] <imbrandon> good good
[23:19] <ScottK2> imbrandon: Any chance for getting together for lunch tomorrow.
[23:19] <imbrandon> sure
[23:20] <ScottK2> Are you working or at home tomorrow?
[23:20] <imbrandon> would have to be semi early ( i have family stuff after 4pm )
[23:20] <imbrandon> i'm off work untill jan 2
[23:20] <imbrandon> :)
[23:20] <ScottK2> Ah.
[23:21] <ScottK2> So something noonish would work?
[23:21] <imbrandon> sounds good
[23:21] <imbrandon> yup
[23:22] <imbrandon> still up for bbq?
[23:22] <ScottK2> Yes.
[23:22] <imbrandon> cool
[23:22] <imbrandon> you got my home # incase something pops up right ?
[23:23] <ScottK2> Gates at 103rd and State Line at Noon then?
[23:23] <imbrandon> sounds perfect
[23:23] <ScottK2> See you then.
[23:23] <imbrandon> ok, have fun :)
[23:23] <ScottK2> nenolod: You probably ought to talk to jdong.  IIRC he recently redid all the packaging for that.
[23:24] <jdong> what am I redoing?
[23:25] <imbrandon> jdong: 17:18:13 < nenolod> hi. i have a debdiff for audacious in ubuntu to make it use pulseaudio by default.
[23:26] <jdong> ah, I don't think I've touched either in the messing of the stack yet. avidemux is probably what ScottK2 was thinking of
[23:26] <jdong> pulse sounds like a crimsun thing :)
[23:26] <nenolod> at any rate, someone take care of it please :D
[23:26] <nenolod> https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/175536
[23:26] <ubotu> Launchpad bug 175536 in audacious "[Harty] audacious not work fine with pulseaudio" [Undecided,New]
[23:27] <imbrandon> harty ?
[23:27] <imbrandon> :)
[23:27] <nenolod> harty. :D
[23:28] <nenolod> harty the tarty hedgehog
[23:28] <nenolod> hmm. that wasn't as funny as i thought it would be.
[23:28] <nenolod> oh well. :P
[23:29] <jdong> that's what the ffmpeg team said about their monthly API changes :)
[23:30] <nenolod> at any rate, that's the debdiff. have fun with it.
[23:30] <nenolod> anyone in particular i should subscribe to the bug?
[23:31] <awen-> nenolod: change status to confirmed, assign to nobody and subscribe ubuntu-universe-sponsors
[23:31] <awen-> that's what i've been told (it's a universe package right?)
[23:32] <nenolod> awen-, so standard procedure. thanks.
[23:32] <awen-> nenolod: that usually works for me
[23:32] <jdong> nenolod: yeah let's handle it as u-u-s for now :)
[23:33] <jdong> I'm packing bags and preparing to fly home tomorrow so I don't feel coherent enough to sponsor tonight
[23:34] <nenolod> caveats: audacious hasn't been tested with pulseaudio much.
[23:36] <jdong> nenolod: well considering how we plan on making it default (AFAIK) it's not a bad idea to test it this way before it's too late :)
[23:37] <nenolod> jdong, i'm testing it now.
[23:37]  * awen- is a little scared that 1/3 of the bugs assigned to ubuntu-universe-sponsors is "his"
[23:37] <nenolod> jdong, some gentoo users have reported bugs. I'm not sure what the deal is there yet (unable to reproduce)
[23:39] <jdong> nenolod: As long as you plan to follow through with it I'd say it's good for upload.
[23:40] <nenolod> jdong, of course i plan to follow through with it :D
[23:40] <jdong> :)
[23:41] <nenolod> it seems that pulseaudio doesn't like large fragments
[23:41] <nenolod> so i'll probably have to backport some fixes i made to 1.4 plugins for ubuntu