[00:57] <_16aR_> I'll just have fixed the problems Dave hasn't fixed on fsniper (watch file, and distrib version name change). Can anyone review it ? It is a directory watcher/script automater based on inotify (very practical to sync directories on the fly) : http://revu.ubuntuwire.com/details.py?package=fsniper
[01:02] <_16aR_> and another one : hexdiff, a package to visually analyse binary differences between 2 files (in hexa off course). Nobody has put any comments right now, so it could be cool to look at it : http://revu.ubuntuwire.com/details.py?package=hexdiff
[01:06] <_16aR_> just added some debian/examples for fsniper
[01:34] <nellery> would a new Debian release fixing only incorrect licensing in a package (which is serious severity on debian BTS) be worthy of a merge?
[01:34] <cody-somerville> nellery, depends. Is the package violating Ubuntu policies?
[01:35] <nellery> cody-somerville: the packages debian/copyright file claims that the package is distributed under LGPL, when it is GPL
[01:36] <cody-somerville> slangasek, ^^
[01:36] <slangasek> hrm?
[01:36] <nellery> (note that there are 6 related packages involved)
[01:36] <cody-somerville> slangasek, Can you advise nellery?
[01:36] <cody-somerville> nellery, Is there a bug report in Ubuntu yet?
[01:37] <nellery> cody-somerville: I don't believe so
[01:37] <slangasek> I would say it's worth merging, but I'm not volunteering to merge it...
[01:37] <cody-somerville> nellery, theres your answer :)
[01:37] <nellery> cody-somerville, slangasek: thanks
[01:48] <xnox> does anyone has experience with random mini-dinstall hick-ups?
[01:52] <xnox> I dput local *.changes; then mini-dinstall --batch; then apt-get update;
[01:52] <xnox> and when I do apt-get install my_package
[01:52] <xnox> it gives me errors mismatched size
[01:54] <maxb> Odd
[01:54] <maxb> All I can say is that I found reprepro more to my taste than mini-dinstall
[01:55] <maxb> Unless it's a *really* trivial local repo, in which case I can post the shellscript I use for my "dump some debs in a directory" style repo for pbuilder
[01:58] <xnox> maxb: that would be *really* usefull for me know
[01:58] <xnox> maxb: And i'll checkout reprepro
[02:01] <maxb> http://bazaar.launchpad.net/~maxb/%2Bjunk/apt-generate/annotate/head%3A/apt-generate
[02:02] <xnox> maxb: thanks!
[03:18] <jsmidt> I'm trying to build the mono package in Jaunty.  I get this error: debian/dh_makeclilibs -i -m 1.0 --internal-mono
[03:18] <jsmidt> Unknown option: internal-mono
[03:19] <jsmidt> Does anybody recognise what error this is and/or how to fix it?
[03:39] <Bsims> Can anyone point me to a tutorial to build multi binary debs... I want to package and host kde 3.5x built against Ubuntu Current... I am not entirely ignorant of how dpkg works used it for single binaries.
[03:39] <HorizonXP> if i need to remove PDO from PHP, should I bother with recompiling the debian package, or just install PHP from source?
[03:40] <Bsims> I looked through the Debian New Maintainer's Guide and it didn't go into multibinary debs
[03:40] <maxb> Don't know about a tutorial, but there's really not all that much to it - you just have multiple binary stanzas in debian/control, and install the relevant files into debian/PACKAGENAME as you would be doing in a single-binary package, but for more than one
[03:41] <LaserJock> Bsims: you can look at the KDE 3.5 packages to get an idea
[03:41] <LaserJock> Bsims: but that is an enormous task to do right
[03:41] <Bsims> maxb: Hrm I may took a look see at the current packages
[03:41] <Bsims> LaserJock: I was hoping there was a script kind of like buildkde that dumped a Pile'O'Debs
[03:42] <maxb> Bsims: I have to say.... packaging an entire DE sounds incredibly hard. Is it really worth it?
[03:42] <LaserJock> Bsims: no, you'll want pbuilder/sbuild and build the packages in the right order
[03:42] <Bsims> maxb: Well I run nightly neon and well 4.x as it stands at the moment sucks at least as far as I am concerned
[03:42]  * Bsims nods thanks LaserJock nice to know the RIGHT tool to research
[03:44] <LaserJock> there's a reason why Kubuntu has dropped 3.5, it's a lot of work to maintain
[03:44] <LaserJock> any project that size is
[03:44]  * Bsims nods I remember the transition to 3.x for KDE
[03:45] <Bsims> thing is I've refined my dot file from 1999 to current... I /know/ how 3.5 works at least from a user perspective
[03:45] <maxb> pbuilder is a tool for building packages in a clean build environment. Making packages that build in a clean environment is important, but you would probably want to start out simply building the packages in your existing installation. For that, see dpkg-buildpackage (or debuild, a thin wrapper over that)
[03:45] <LaserJock> Bsims: sure
[03:45] <Bsims> And for me 4.x isn't there yet
[03:45] <nhandler> persia: Are you going to upload gebabbel from REVU? Or do you want me to go ahead an upload it for you?
[03:45] <maxb> When you do want to prove that it builds cleanly, I think pbuilder is a bit easier to get to understand than sbuild
[03:46]  * Bsims nods maxb I've used dpkg-buildbackage but only for single binary packages
[03:46] <LaserJock> when you want .debs that are distributable you want pbuilder/sbuild
[03:46] <maxb> You definitely want to look into using cowdancer's cowbuilder wrapper for pbuilder - the speed benefit is considerable
[03:46] <Bsims> Coool
[03:46] <LaserJock> I don't trust dpkg-buildpackage alone for any binary building
[03:46]  * Bsims makes notes
[03:46] <Bsims> LaserJock: worked for me for pan
[03:47] <LaserJock> for personal consumption yeah
[03:47]  * Bsims grins well yeah but that was my focus before
[03:47] <maxb> dpkg-buildpackage is appropriate for when you are developing the package. pbuilder or sbuild is for when you are checking its sane for release to an audience
[03:47] <maxb> or when it needs to build for a different distro than you are running
[03:48]  * Bsims /does/ have to whine about kubuntu deciding to convert existing .kde directories to kde4 surely .kde4 would have been less disruptive
[03:48] <maxb> The invocation of dpkg-buildpackage is the same whether you're building a single-binary or multi-binary source
[03:48]  * Bsims adds notes about what to use when
[03:48] <ScottK> Bsims: That's what we did during Hardy when we were trying to support co-installability
[03:49] <Bsims> maxb: I tried turning it loose on the source and telling it multi-binary and it got confuseled
[03:49] <Bsims> ScottK: IIRC its how Debian handled it back then
[03:49] <LaserJock> you don't tell it multi-binary
[03:49] <ScottK> Bsims: If you want current KDE, kde3.5.10 is packaged and in Hardy.  It'd just be a matter of rebuilding them.
[03:49] <maxb> What do you mean "telling it multi-binary". There's no such option
[03:49]  * Bsims nods I'll look there
[03:49] <maxb> multi-binaryness is a property of the source package - not the command you use to build the source package
[03:49] <Bsims> Not for dpkg-build package
[03:50] <Bsims> Sorry telling dh_make that its multiple binary
[03:50] <LaserJock> Bsims: you shouldn't be using dh_make
[03:51] <LaserJock> dh_make is for getting a template for creating a source package from scratch
[03:51] <Bsims> LaserJock: what should I be using, I was following the Debian New Maintainers guide
[03:52] <Bsims> Mostly thats what I use it for.... is converting tar.gz that is too new to be packaged on ubuntu
[03:52] <LaserJock> Bsims: ok, but you really really don't want to do that for KDE
[03:52] <LaserJock> Bsims: you want to grab the Hardy source packages and just rebuild them on Intrepid or whatever release you running
[03:53]  * Bsims nods does sound like far less work
[03:53] <LaserJock> when you consider how much time went into those packages, yeah
[03:54]  * Bsims grins and I appriciate it... 
[03:54]  * Bsims sends donations at tax time labled packager's beer fund
[03:56] <Bsims> I guess in part my hostility to 4.x for kde is I have spent years refining how kde works for me and don't wanna change
[03:56] <LaserJock> that's reasonable, it's just hard for a project to progress without breaking some old habits first
[03:57] <Bsims> But would it kill them to let me add a shortcut to that toolbar with a right click?
[03:57]  * Bsims winks
[03:57] <Bsims> LaserJock: when I got started Debian was bragging about how the Potato had landed
[03:58] <Bsims> and that was after a year or so of SuSe back when they spelled it that way
[03:58]  * Bsims winces damn 1999 doesn't seem that long ago
[03:59]  * Bsims smiles 4.x will get there... 3.x did eventually
[03:59] <LaserJock> 4.2 is very nice
[03:59] <LaserJock> and I've been using gnome for years
[04:00] <Bsims> LaserJock: I am running nightly neon to avoid conficts with the 3.5 packages I installed third party... I know bad bad me
[04:00]  * Bsims grins and well its purty... but I can't figure out how to add shortcuts to it's toolbar nor install themes for kopete
[04:00] <Bsims> minor issues I know but still
[04:01] <Bsims> That and k3b hasn't made the move yet... its my prefered cd burner app on any platform
[04:02]  * Bsims laughs sad as I spend the time not in Pan, firefox, transmission and K3B is in a urxvt terminal running GNU Screen
[06:43] <xnox> is it an RC bug if the source code files have licensing information missing?
[07:06] <dholbach> good morning
[07:06] <iulian> Good morning Daniel!
[07:06] <dholbach> hiya iulian
[07:07] <iulian> How are you this morning?
[07:07] <dholbach> very good, just need another coffee to get going :)
[07:07] <dholbach> how are you?
[07:08] <iulian> I am drinking my tea...
[07:08] <iulian> No more school till 9th of Feb!
[07:08] <dholbach> :-)
[07:08] <iulian> Yaay!
[07:09] <dholbach> yoohoo :)
[07:18] <jamesty1>  /j #ruby
[07:18] <jamesty1> oops
[07:18] <jamesty1> still 1/2 asleep
[07:20] <savvas> lies!
[07:21] <jamesty1> heh it's 8am here
[07:22]  * jamesty1 grabs coffee
[09:23] <artfwo> Hello! I need some help with Debian Policy versioning: will Hardy support building packages with Standards-Version bumped to 3.8.0?
[09:24] <dholbach> artfwo: the  Standards-Version  field should not affect build-ability :)
[09:25] <artfwo> but what if I specify "Homepage" field in debian/control? It's unsupported in 3.7 series, that's the "default" for Hardy, as far as I can tell
[09:27] <artfwo> will such a control file be parsed without errors by packaging tools on Hardy?
[09:27] <leleobhz> leleobhz@dsp2:~$ sudo ld -Bdynamic -r -lxview -lolgx
[09:27] <leleobhz> ld: cannot find -lxview
[09:27] <leleobhz> for ubuntu, what is wrong?
[09:28] <leleobhz> (libs instaled) may be a bug?
[09:38] <persia> artfwo, If you use a newer standards version than is available in a given release, you may not have support for certain new features: you'd have to check the underlying tools (dpkg in the case of Homepage).
[09:39] <persia> leleobhz, Do you also have the -dev packages installed?  Can you find the libraries manually (in /usr/lib)?
[09:40] <artfwo> persia: there's a lot of features for 3.8.0 standards; is there an automated way to check compability with all the tools? Or is it just okay to stick my package at 3.7.3 if I want to build it on older Ubuntu releases?
[09:43] <persia> artf
[09:43] <persia> artfwo, The actual number you use doesn't really matter, although it's nice when it's accurate.
[09:44] <persia> More important is that if you rely on any tool features you should check to see if they are supported for a given target.
[09:44] <persia> There's no automated way to do this: far too many tools, and far too many use cases for the tools.
[09:45] <persia> So just changing Standards-Version: won't make any difference at all: it's changing the other things that make a difference.
[09:45] <artfwo> understood, thanks!
[09:45] <persia> For example, if you want to know if Homepage is supported, determine which tools are likely to look (at least dpkg, maybe others), and check their changelogs.
[10:34] <tuxmaniac> can some one unsubscribe universe-sponsors from bug 322648. It looks like its invalid because of a merge needed. Another pair of eyes is appreciated
[10:37] <tuxmaniac> another question. How do I find the reason for the removal of a package from multiverse? the bug in question is bug 293585
[10:39] <dholbach> tuxmaniac: I replied to the libgeda bug
[10:45] <dholbach> tuxmaniac: no idea when it was removed - in any case it was removed from Debian too
[10:47] <tuxmaniac> dholbach: aah thanks for the second answer
[10:47] <tuxmaniac> regarding the first one, i missed it completely. Relied a bit on http://qa.ubuntuwire.com/multidistrotools/science.html#outdatedandlocalinB
[10:47] <tuxmaniac> and forgot to see the naming of the package
[10:47] <tuxmaniac> dholbach: thanks for the review comment
[10:49] <AndrewGee> If I want to something which has two configure scripts, with CDBS, how would I go about doing this. It's like I want to do the whole process twice, I guess.
[10:56] <hyperair> could someone review my package geanyvc please? http://revu.ubuntuwire.com/details.py?package=geanyvc
[10:59] <dholbach> tuxmaniac: https://launchpad.net/ubuntu/+source/spim/+publishinghistory
[11:00] <dholbach> tuxmaniac: click on the expander in the "Deleted" row
[11:00] <tuxmaniac> dholbach: i already did that. Thanks for digging that info
[11:01] <dholbach> no worries
[11:02] <hyperair> mok0: codelite seems to ftbfs on a few architectures. do you know where i can get access to an ia64 buildd for testing purposes?
[11:02] <mok0> hyperair: no, sorry
[11:02] <hyperair> sigh.
[11:02] <mok0> did you ask on #ubuntu-devel?
[11:02] <hyperair> so what should i do about it?
[11:02] <hyperair> eh?
[11:03] <hyperair> no i didn't
[11:03] <hyperair> i'll go ask
[11:03] <hyperair> no wait, i did
[11:03] <hyperair> a few days ago
[11:03] <hyperair> no reply
[11:03] <mok0> yeah, it a problem
[11:03] <hyperair> i tried using qemubuilder, but it doesn't support ia64
[11:03] <mok0> hyperair: perhaps refer upstream to the errormessage? Perhaps he'll know what to do
[11:04] <hyperair> mok0: i did refer upstream. he's the one who came up with the fix, but i can't test it without an ia64 buildd
[11:04] <hyperair> mok0: and he doesn't have an ia64 machine to test out either
[11:04] <mok0> hyperair: sigx still has problems also, seems only to work on i386-derived archs
[11:04] <hyperair> mok0: so it seems
[11:04] <hyperair> stupid scons
[11:05] <mok0> hyperair: of course the poor-mans fix is to exclude those archs
[11:05] <hyperair> that would mean anything depending on that library wouldn't work
[11:05] <mok0> hyperair: yes, but it wouldn't anyway, since the library doesn't build
[11:06] <hyperair> mok0: true.
[11:07] <mok0> hyperair: Fortunately, the packages built on the most important archs
[11:07] <hyperair> yeah
[11:08] <hyperair> but failed for every other.
[11:08] <hyperair> i tried looking into qemubuilder for ia64, but it seems qemu doesn't have ia64 support
[11:09] <mok0> hyperair: no
[11:09]  * mok0 goes to meet buddy for lunch... see you in a while
[11:09] <hyperair> alright see you
[11:14] <apw> if one is modifying the debian part of a package sync'd from debian (a file in debian which is copied in wholesale) should you be adding that as a patch in the patches directory or just modifying it directly?
[11:15] <apw> also can someone remind me of thee magic command to build a patch
[11:17] <Piratenaapje> apw: diff -Nurp package-directory.old/ package-directory.new/ > name.patch
[11:17] <apw> there was some debfoo command which you could debfoo <patchname> and then edit the source and it did the right thing
[11:18] <Piratenaapje> apw: do you mean dpatch?
[11:19] <apw> ahhh that sounds more like it thanks
[11:20] <Piratenaapje> apw: http://www.tuxmaniac.com/blog/2008/01/25/dpatch-just-superb-a-short-how-to/
[12:29] <a|wen> hmm, zapping in jaunty calls MAKEDEV in the postinst, and no newer version in debian ... that doesn't look good
[12:34] <cornucopic> Hi! I have just confirmed a bug, Can I assign myself to fix it?: https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/321863
[12:35] <cornucopic> This will be my first ever attempt..Seems like a easy fix. So can I just go ahead and assign it?
[12:41] <persia> cornucopic, Yes: please assign yourself if you plan to fix it.
[12:42] <cornucopic> Cool..
[12:42] <cornucopic> persia, Is it also necessary to confirm the issue in a latest dev release?
[12:43] <persia> cornucopic, No, but it's necessary to fix the issue in the latest dev release *first*, and it's likely that confirming/testing there will be a component of that.
[12:44] <cornucopic> persia, That brings me to my next question: What is the best way to setup a development test bed?
[12:44] <cornucopic> I am looking at https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
[12:45] <freeflying> cornucopic: chroot+Xephy
[12:45] <persia> cornucopic, Install on a spare machine, install on a machine that you can afford to troubleshoot when it breaks, install in a VM, or use a chroot.
[12:45] <cornucopic> I am looking at using VirtualBox/KVM m/c as my test bed..
[12:46] <cornucopic> Which bits do I install there? the nightly ISO;s..? If that is the case, how do I keep updated.. by updating the packages?
[12:47] <cornucopic> freeflying, What is Xephy?
[12:47] <cornucopic> freeflying, Google doesn't have a answer
[12:47] <freeflying> cornucopic: xserver-xephyr - nested X serve
[12:48] <persia> cornucopic, I'd suggest installing a recent Alpha, and dist-upgrading.
[12:48] <freeflying> cornucopic: sorry for typo :)
[12:48] <persia> freeflying, xephyr has other issues ...
[12:48] <freeflying> persia: what's that?
[12:48] <cornucopic> freeflying, np.
[12:48] <cornucopic> persia, hmm..
[12:49] <persia> freeflying, Need for locally installed support for remote X access (e.g. Xinput, etc.), which can mix parts of the test system and local system in confusing ways.
[12:51] <freeflying> persia: hehe
[12:51] <persia> freeflying, So, if you're testing e.g. Xubuntu Jaunty on Kubuntu Jaunty, Xephyr works great, but if you're e.g. testing Ubuntu MID Jaunty on Kubuntu Intrepid, it's painful.
[12:52] <freeflying> persia: for such a case, I would use emulator :)
[12:52] <persia> freeflying, Yeah.  A VM is easier :)
[12:54] <cornucopic> persia, So I am done installing a Alpha version..Now where do I get the package sources?
[12:54] <persia> cornucopic, apt-get source foo
[12:54] <cornucopic> ah..okay..thanks :-)
[13:02] <cornucopic> persia, Once the source modifications are made, I will build the package with Pbuilder? PPA? sbuild?
[13:03] <persia> Any of those work.  pbuilder or sbuild are probably better for an initial test build, just because they can build the same version twice.  Of those, I happen to use sbuild, but many here use pbuilder.
[13:04] <cornucopic> hmm..
[13:06] <_16aR_> I'll just have fixed the problems Dave hasn't fixed on fsniper (watch file, and distrib version name change). Can anyone review it ? It is a directory watcher/script automater based on inotify (very practical to sync directories on the fly) : http://revu.ubuntuwire.com/details.py?package=fsniper
[13:18]  * mok0 takes a look at fsniper
[13:20] <jcfp> MOTUs, sabnzbdplus (binary newsreader, written in python) needs a second advocate - please consider for review: http://revu.ubuntuwire.com/details.py?package=sabnzbdplus
[13:56] <henrik-hw0> Just fixed a package with WiFi drivers... (rt28xx-linux-sta) but this was split into two by request from superm1.
[13:57] <henrik-hw0> Can anyone have a look? Being WiFi drivers IMO they need to make it into Jaunty before deadline.
[13:57] <mok0> henrik-hw0: I agree
[13:58] <mok0> henrik-hw0: I already advocated the unsplit package AFAIR
[13:58] <mok0> henrik-hw0: link?
[13:59] <henrik-hw0> http://revu.ubuntuwire.com/details.py?package=rt2870-linux-sta
[13:59] <henrik-hw0> http://revu.ubuntuwire.com/details.py?package=rt2860-linux-sta
[13:59] <mok0> thx
[14:00] <mok0> henrik-hw0: I guess they should go -> main eventuall
[14:02] <henrik-hw0> main - that's for officially supported packages, no?
[14:04] <mok0> henrik-hw0: yes, and packages that ship on the CD
[14:04] <mok0> henrik-hw0: The archive-admins will decide
[14:06] <mok0> henrik-hw0: Be prepared for 1 problem
[14:15] <henrik-hw0> I'll email RALink about the problem.
[14:23] <a|wen> ScottK: what to do with a package that does use makedev in the postinst? (remember seeing a message on ubuntu-devel-announce about it not being feasible)
[14:23]  * ScottK looks around for someone who knows ....
[14:24] <mok0> henrik-hw0: great, thanks!
[14:25]  * a|wen considered filing a bug and get someone with powers to give it a reasonable importance
[14:25] <james_w> https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027184.html
[14:25] <james_w> a|wen: what does said package do with makedev?
[14:27] <a|wen> james_w: try to create /dev/v4l
[14:28] <james_w> a|wen: and what does that device do?
[14:28] <james_w> is it associated with hardware?
[14:28] <james_w> the fact that it is not numbered suggest it isn't, or at least that it will be problematic to migrate away from it
[14:29] <a|wen> james_w: it has something to do with video4linux ... i guess
[14:29]  * a|wen tries to find out exactly what it does ... it checks for /dev/video0 as well
[14:30] <james_w> the idea is that the kernel creates device nodes via udev
[14:32] <a|wen> james_w: running it seems to generate 196 device creation errors
[14:35] <Piratenaapje> I've packaged a couple of new applications now, what would be recommended for me to do next? Patch testing and reviewing?
[14:36] <mok0> Piratenaapje: stick'em in your PPA. We're short on reviewers :-)
[14:38] <Piratenaapje> mok0: I didn't create one yet, guess I'll do that next :p
[14:38] <a|wen> james_w: the big question is: is it important, so we need to do something about it?
[14:39] <mok0> Piratenaapje: it's real easy, on LP
[14:39] <oojah> a|wen: Isn't /dev/v4l normally a directory?
[14:39] <mok0> oojah: no, it's probably created by the driver
[14:39] <a|wen> oojah: it's very likely
[14:40]  * a|wen has no video devices to check it
[14:40] <hyperair> mok0: should i just leave sigx and codelite as it is, or find some fix/exclude the architectures?
[14:40] <oojah> mok0: You sure? I'm fairly certain /dev/v4l/video0 would be created by the driver.
[14:42] <gaspa> a|wen: i've some... what's the package in question?
[14:42] <a|wen> gaspa: zapping
[14:49] <Piratenaapje> Hmm why does my ppa only build the i386 version? :s
[14:50] <mok0> Piratenaapje: it should build all, aren't they queued?
[14:50] <Piratenaapje> No, only the i386 is queued
[14:50] <mok0> Piratenaapje: give it some time
[14:51] <Piratenaapje> mok0: One package is building the rest as well, just the one with architecture "all" is only build i386
[14:51] <gaspa> a|wen: I've not Tv devices, only bttv framegrabber... but i guess postinst of zapping is not the right place to have device creation...
[14:52] <mok0> Piratenaapje: that's because it only needs to be built once
[14:52] <a|wen> gaspa: exactly what i noted ... but the question is if it actually hurts anything
[14:52] <Piratenaapje> mok0: Right :p
[14:52] <mok0> Piratenaapje: i386 builder builds "all" arch
[14:53] <Piratenaapje> mok0: Ok, it's just a bit confusing
[14:53] <gaspa> a|wen: do you mean "without makedev"?
[14:53] <mok0> Piratenaapje: he, yeah
[14:53] <a|wen> gaspa: as it is read only i don't suppose it gets allowed to do anything with makedev
[14:54] <mok0> Piratenaapje: what is confusing is the arch name "all" ... it should be called "indep", "noarch" or the like
[14:54] <gaspa> a|wen: in fact
[14:55] <a|wen> gaspa: or can it actually hurt so it should be patched out?
[14:56] <gaspa> a|wen:  i think it doesn't hurt, though it's irritating having so much errors.
[14:57] <james_w> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=148831
[14:58] <gaspa> james_w: but devices shouldn't be created by apps...
[14:58]  * iulian wonders why ubottu is not capable of showing a link when writing the bug # privately.
[14:58] <james_w> xawtv does "test -c /dev/.devfsd -o -c /dev/video0 -o -c /dev/v4l/video0 && mkdev="false""
[14:59] <james_w> gaspa: I know, just adding to the information
[14:59]  * mok0 just got another 4G RAM in his rig today :-P
[14:59] <gaspa> james_w: i see.
[14:59] <james_w> I assume the "/dev/.devfsd" check is for udev not running
[15:01] <ara> dholbach: I made some suggested changes in the package (ubuntu-qa-tools) and I uploaded a new version
[15:01] <gaspa> james_w: ok, xawtv does it better ( :P ), anyway I still don't like it ... they simply shouldn't crash without a /dev/video-something...
[15:02] <james_w> gaspa: for sure
[15:02] <james_w> gaspa: if you know what the solution is then please go ahead, I'm just trying to work out what to do
[15:03] <a|wen> gaspa: i have a pending debdiff on the package already (for something completely different); that was why i noted it
[15:04] <james_w> a|wen: you could reply to the ubuntu-devel mail asking for guidance in this situation
[15:04] <gaspa> ok
[15:06] <gaspa> a|wen, james_w: i didn't have the right hardware to fully test it, but I'll have a look.
[15:06] <james_w> cool, thanks gaspa
[15:07] <a|wen> gaspa: cool, thx ... please let me know if you want to start patching before my debdiff is in (ends in ubuntu1)
[15:08] <gaspa> a|wen: ok. ( looking at sources... oh, what a mess... :| )
[15:09] <a|wen> gaspa: i know...
[15:19] <Piratenaapje> What are my chances of actually getting a mentor after applying?
[15:20] <Piratenaapje> Everyone seems kind of busy now
[15:20] <nhandler> Piratenaapje: Pretty good last I checked
[15:20] <cody-somerville> Piratenaapje, about 1 in 16
[15:20] <nhandler> hauts and the mentoring reception have been doing a nice job of getting mentors for people
[15:20] <Piratenaapje> Alright, time to have a go at it :p
[15:21] <bddebian> Heya gang
[15:21] <iulian> Hiya bddebian.
[15:21] <bddebian> Hi iulian
[15:23] <nhandler> Hey bddebian
[15:23] <cody-somerville> Hi bddebian
[15:23] <bddebian> Hi nhandler, cody-somerville
[15:26] <geser> Hi bddebian
[15:34] <slytherin> geser: after long time. :-)
[15:35] <ScottK> Piratenaapje: You can just ask questions here as you have them too.  A formal mentor isn't required.
[15:37] <slytherin> nhandler: ping. need to discuss your comments on monajat
[15:38] <slytherin> what is the usual process to upload a package from revu into archive? How do I generate the notification mail?
[15:38] <Piratenaapje> ScottK: well, basicly I need to know what I should do next, I've packaged a couple new applications myself, but am not sure where to look now.
[15:39] <ScottK> slytherin: You'll get mail back from Soyuz after the upload.  Just add REVU to the subject and forward to the list.  I usually trim it a bit for readability, but it's not required.
[15:41] <slytherin> ScottK: Ok. I thought they were auto generated mails
[15:46] <a|wen> hi everyone... we have a goal of getting rid of aRts (the kde3 soundserver) for intrepid. in that regard there is a number of packages that needs rebuilding w/o arts-support
[15:47] <ScottK> arts is so unsupported that upstream closed every single pending bug as wontfix.
[15:47] <a|wen> the status is tracked on https://wiki.kubuntu.org/RemoveArts if anybody wants to help out ...
[15:47]  * ScottK encourages people to help out...
[15:48] <ScottK> Piratenaapje: It's really a question of what you want to do as you're a volunteer.
[15:48] <dholbach> a|wen: for intrepid?
[15:48] <ScottK> dholbach: For Jaunty.
[15:48] <a|wen> dholbach: for jaunty of course
[15:48] <dholbach> a|wen: right-o - I was a bit scared already :-)
[15:49] <a|wen> hehe :)
[15:49] <a|wen> I would also really appreciate a review on the 3 debdiff's awaiting in bug 320915 - zapping, cmus and xsidplay
[15:51] <Piratenaapje> ScottK: Well, basicly any task that a MOTU should do, but I'm not sure what task I should try first
[15:52] <ScottK> Piratenaapje: At this point we're getting to where we need to focus on bug fixes.
[15:52] <Piratenaapje> ScottK: so I should review and test patches?
[15:52] <ScottK> If you look at the output of the Universe section of merges.ubuntu.com and see anything that looks like we really ought to have it, preparing a merge would be useful.
[15:52] <ScottK> That too.
[15:53] <DktrKranz> dholbach: scared? Hardy had a library transition via SRU ;)
[15:53] <Piratenaapje> ScottK: Doesn't the last uploader usually provide the merge?
[15:54] <ScottK> Piratenaapje: Generally, but after Debian Import Freeze, it's usually considered a free for all.
[15:54] <ScottK> The question is there anything that really needs doing that's been missed.
[15:57] <Piratenaapje> ScottK: Alright, I'll try to see if anything comes up
[15:57] <JontheEchidna> Who do I subscribe to sync requests for packages in main?
[15:58] <ScottK> ubuntu-main-sponsors
[15:58] <JontheEchidna> Thanks
[15:59] <cherva> Can I upload a package to the revu site if it is not mine? It's the ubuntu-tweak package witch needs to be added another repo to make people able to apt-get it?
[16:00] <JontheEchidna> Can I ack my own universe sync request and subscribe the archive admins?
[16:00] <ScottK> JontheEchidna: Yes.
[16:00] <JontheEchidna> sweet
[16:00] <a|wen> oh no, JontheEchidna with pow'as
[16:00] <JontheEchidna> muwahahaha
[16:01] <lajjr> hola
[16:01] <lajjr> sorry hello everyone..
[16:01] <lajjr> I have a quick ?
[16:04] <lajjr> I have a launchpad account and I have been packaging items. When you send to revu is it better to have it in you ppa and revu..??
[16:04] <Piratenaapje> ScottK: would you recommend me to apply for mentorship, or will I be able to become a MOTU anyway if I contribute?
[16:04] <JontheEchidna> lajjr: It won't hurt to have it in both places
[16:05] <lajjr> great..
[16:05] <ScottK> Piratenaapje: It's a question of personal style.  Getting a mentor is absolutely not required.  I'm not convinced it helps much, but if you're to shy to ask questions in public, then maybe you should...
[16:06] <ScottK> Up to you really.
[16:06] <lajjr> JontheEchidna: thank you..
[16:06] <Piratenaapje> ScottK: I don't mind that much really with asking questions, but I guess I prefer to have someone to fall back to.
[16:06] <Laney> I guess it's a bit harder to find tasks at the start without a mentor feeding them to you, but I managed to get along fine (did I?) without one
[16:07] <JontheEchidna> lajjr: you're welcome. If you do put it in a PPA it does show that it at least builds and it makes for easier runtime testing
[16:07] <JontheEchidna> but putting it in a PPA is definitely not required
[16:08] <Piratenaapje> Ok thanks for the advice, I guess I'll ask for mentorship anyhow :p.
[16:08] <a|wen> argh, it supports 81 music formats, and i've heard about none of them! ... removing arts also consist of testing obscure music players
[16:09] <lajjr> ok cause I just completed all the setup from my building systems and testing. But the ppc has to be tested by me..ppa does't build that one..right?
[16:12]  * lajjr leaving
[16:26] <bddebian> Heya geser (late) :)
[16:48] <Chris`> How does one go about getting backporters for a package?
[16:49] <loic-m> Chris`: you can backport it yourself in a first time
[16:49] <Laney> !backport
[16:49] <Chris`> What if the distro doesn't have that package and if it is new in Jaunty?
[16:50] <Laney> it's the same
[16:50] <Laney> (AFAIK), ScottK can confirm
[16:50] <ScottK> That's correct
[16:51] <hyperair> could someone review my package http://revu.ubuntuwire.com/details.py?package=geanyvc please?
[16:51] <ScottK> Actually I'm even more inclined to approve those as they have a 0% chance of breaking the existing package.
[16:52] <loic-m> ScottK: when are backport request processed? 1 every two weeks?
[16:52] <ScottK> It varies.
[16:52] <ScottK> There's a multi-step process.
[16:53] <ScottK> First it has to get tested, then a backporter has to approve, then an archive admin has to do it.
[16:53] <loic-m> Chris`: you can make the process easier by trying to build it for the release you want it to be backported to, using f.e. "prevu pkge_name", then checking if it runs
[16:53] <ScottK> None of those have a particularly fixed schedule.
[16:53] <loic-m> Chris`: also providing backported packages on the bug report so others can try it
[16:54] <doctormo> Hey guys, does anyone have a second to help me with an amd64 build problem? It seems it can't find libc.so.6 on that platform.
[16:54] <loic-m> ScottK: thanks
[16:57] <Adri2000> info: for french speaking people, there is a packaging session in #u-classroom beginning in a few minutes
[16:57] <Chris`> Adri2000: About what?
[16:57] <Adri2000> packaging :)
[17:04] <jpds> g'evening dholbach.
[17:04] <dholbach> hiya jpds
[17:06] <jpds> doctormo: Hmm, odd, could you possibly pastebin the error at paste.ubuntu.com?
[17:07] <Laney> james_w: Since when were you an archive admin? Or is this random sync processing? :O
[17:07] <doctormo> jpds: http://launchpadlibrarian.net/21693635/buildlog_ubuntu-intrepid-amd64.wizardpen_0.6.0.3-0doctormo2_FAILEDTOBUILD.txt.gz
[17:07] <doctormo> no need to pastebin, it's available for all
[17:07] <james_w> Laney: nothing gets past you does it? :-)
[17:07] <ryanprior> The maxima and wxmaxima packages are outdated in Ubuntu and Debian. Can I help fix that?
[17:07] <Laney> not when it's my bugs ;)
[17:08] <james_w> Laney: I'm in training, that was my first sync run.
[17:08] <Laney> To be honest, I saw your name and thought I'd cocked something up
[17:08] <james_w> heh
[17:09] <james_w> don't worry though, I'm being "sponsored", so I can't rm the archive or anything :-)
[17:10] <Laney> bah, that's no fun
[17:10] <jpds> doctormo: Maybe you need to heed: "To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH."
[17:10] <Laney> nice one though, moar power!
[17:11] <doctormo> jpds: I don't think I know enough about deb packaging to do to that. Is LD_LIBRARY_PATH something that's set in the rules?
[17:11] <doctormo> jpds: And how would I know what the correct dir to add is?
[17:11] <azeem> libc.so.6 should be in the default search path
[17:13] <doctormo> azeem: could it be that the build server go muddled? it was very busy, took 5 hours to build.
[17:13] <azeem> does it build in your pbuilder?
[17:14] <azeem> and did you test-build it on amd64?
[17:14] <doctormo> azeem: no, I'll have to look up what that is
[17:20] <doctormo> azeem: OK found howtos and running through them now. It's taking it's time to make the pbuilder. this is to be expected?
[17:20] <doctormo> azeem: oh it only happened on amd64 too
[17:20] <loic-m> What is the way to get a translation (man page, .po file...) for a packaged program? I'm thinking it doesn't go into the package, so where do we send it (as well as upstream of course ;) )?
[17:20] <loic-m> s/get/upload/
[17:21] <azeem> doctormo: you'll probably have to inspect the build system and see whether it does anything weird with RPATH on amd64 (or maybe if $libdir is /usr/lib64 or something)
[17:51] <rgreening> ScottK: ping
[17:51] <ScottK> rgreening: Pong.
[17:51] <rgreening> ScottK: bug/321891
[17:52] <rgreening> ScottK: I have updated the bug and made the required changes to ensure this packages builds and operates as expected.
[17:52] <ScottK> rgreening: OK.  I'll have a look at it.  I appreciate you sticking with it.  kvirc is a bit of a pain.
[17:52] <rgreening> ScottK: I have built locally and tested, and do not see any further issues.
[17:52] <ScottK> Great.
[17:52]  * ScottK looks
[17:52] <ScottK> bug 321891
[17:52] <rgreening> ScottK: no problem. I learned a lot on this package.
[17:53] <rgreening> and continue to learn more all the time. ty for helping ScottK
[17:53] <ScottK> No problem.  It never stops (the learning)
[17:56] <rgreening> :)
[17:56] <rgreening> As long as there are helpful motu's like you :)
[18:02]  * a|wen still offers a motu silverplate of debdiff's in bug 320915 :)
[18:06] <rgreening> \o/ no more arts
[18:08] <jacob> i'm working on packaging snes9x-gtk from scratch, and i'm beginning to notice that it is becoming a licensing problem. the project as a whole has a non-commercial use license, but it contains GPL, LGPL, and other types of code. the snes9x-x package currently in multiverse has these problems as well, but they are kind of ignored. is it still possible to get this packaged at least to the extent to fit in multiverse?
[18:14] <loic-m> jacob: I'm happy you're working on packaging it, I was looking at it too ;)
[18:15] <loic-m> jacob: the author also already has some packages on his ppa at https://launchpad.net/~bearoso/+archive/ppa you could get in touch with him
[18:15] <james_w> jacob: what's the overall license? some home-grown one?
[18:16] <jacob> james_w: yes, i'll pastebin
[18:16] <jacob> loic-m: i've looked at them - they don't have very good copyright or control files :-!
[18:16] <loic-m> jacob: if Debian packages snes9x-x (and they do, even though it's in non-free) then they might have already looked into it$
[18:17] <loic-m> jacob: I didn't look at them yet ;)
[18:17] <anteaya> if this is the wrong channel for this question, I will accept a re-direct. Who can tell me if the repos are functioning properly?
[18:17] <jacob> james_w: http://paste.ubuntu.com/111320/ is the provided copyright, the license is at the bottom
[18:18] <jacob> though it doesn't really match the copyrights in the header files nor their licenses
[18:18] <james_w> ugh
[18:19] <jacob> heh, yeah. i kinda wonder how this project can legally exist. :P
[18:19] <james_w> it can't really, if what you say is correct
[18:19] <james_w> that license seems ok for multiverse, but not if it links with GPL code
[18:19] <doctormo> azeem: ok the pbuilder is set up, and I just run it through for i386, seems it can't find deps: E: pbuilder-satisfydepends failed.
[18:20] <jacob> james_w: http://paste.ubuntu.com/111321/ is a quick licensecheck
[18:21] <james_w> ./dsp1emu.c is apparently copyright to the team, but GPL, which is silly
[18:21] <jacob> there are a few like that
[18:21]  * ScottK lunches while kvirc builds ...
[18:21] <james_w> ./jma/crc32.cpp is the first thing to check out though, as it's a different copyright
[18:22] <james_w> if that is linked in to the final executable then it's game-over for this version of the package I fear
[18:23] <jacob> would hate to have to see it removed, but the current version in multiverse is exactly like this, minus the GTK stuff. should anything be done with it?
[18:23] <james_w> urgh, how much duplication is there between these packages?
[18:23] <ScottK> Sounds like it should go too.
[18:24] <jacob> james_w: between snes9x-x and snes9x-gtk? a lot. in fact, the only difference is the addition of a gtk/ directory in the source and where ./configure is ran from
[18:26] <james_w> wonderful
[18:26] <coppro> When does the REVU day start?
[18:26] <james_w> it seems the crc32.cpp isn't compiled in the Debian package
[18:26] <james_w> er, no, it appears it is
[18:27] <ScottK> Sounds like upstream ought to be contacted and asked to relicense with a GPL compatible license.
[18:27] <jacob> in the event that i could get upstream to re-release as GPLv2/3, would it be worthwhile to package?
[18:27] <coppro> http://revu.ubuntuwire.com/details.py?package=metakit <-- Reviews please!
[18:27] <jacob> stole my words. :P
[18:29] <james_w> jacob: yeah, if you can that would be great
[18:29] <james_w> jacob: removing some instances of this code from the archive would be appreciated as well
[18:30] <james_w> there are some bugs open about this I believe
[18:31] <jacob> will see what i can do, thanks :)
[18:35] <jacob> james_w: actually, i found some interesting posts that say the jma/ and zsnes sources were relicensed by the original authors for the snes9x license, in that case should those authors be contacted?
[18:36] <james_w> do you have a link?
[18:36] <jacob> james_w: it's by no means concrete, but hopefully i can find something else: http://www.snes9x.com/phpbb2/viewtopic.php?p=20545#20545
[18:37] <james_w> that would make it ok
[18:37] <james_w> but there would normally be some record
[18:38] <jacob> i'll see if i can get snes9x/jma/nsrt/whoever-owns-the-code to put an exception clause in the source headers
[19:03] <azeem> doctormo: that's a kind of question better targetted at the whole chan
[19:03] <azeem> I don't use pbuilder, so can't help you particularly well
[19:06] <doctormo> azeem: thanks for your help so far. :-)
[19:06] <doctormo> It seems as if pbuilder can't find debuild > 7, pbuilder-satisfydepends-dummy: Depends: debhelper (>= 7) but it is not installable
[19:07] <doctormo> http://paste.ubuntu.com/111336/
[19:08] <ScottK> doctormo: Debhelper 7 is only in backports on Hardy.
[19:08] <ScottK> You need to have that and you don't.
[19:09] <jreinhardt> Hi everybody
[19:09] <doctormo> ScottK: this is building on intrepid. is pbuilder set up for hardy?
[19:10] <ScottK> doctormo: libpng12-0 |   1.2.27-1 |      intrepid | amd64, i386
[19:10] <ScottK> Look what version is in your log
[19:11] <doctormo> ScottK: looks like hardy
[19:13] <jreinhardt> A while I packaged an quite interesting LaTeX package (well, at least I find it interesting) and put it on REVU. Perhaps someone can review it. Especially the watch file and the LaTeX install part. http://revu.ubuntuwire.com/details.py?package=pgfplots
[19:24] <hyperair> mok0: got time for a revu or two? =p
[19:26] <mok0> hyperair: I will postpone the pleasure until tomorrow :-)
[19:26] <hyperair> mok0: hahah
[19:27] <hyperair> alright i'll come bug you again ;)
[19:27] <mok0> hyperair: ok... tomorrow's revu day
[19:27] <hyperair> oh it is?
[19:27] <hyperair> awesome!
[19:27] <mok0> hyperair: yep, every friday
[19:27] <hyperair> eh?
[19:28] <hyperair> okay, now i know
[19:28] <hyperair> i'll prepare a list of packages and then come bugging every friday
[19:28] <hyperair> =p
[19:28] <mok0> hyperair: heh
[19:32] <hyperair> mok0: regarding codelite and sigx's ftbfs, should i just leave it?
[19:33] <mok0> hyperair: you'll have to find out what upstream thinks... it may be a limitation of the software
[19:33] <hyperair> mok0: in the case of codelite, ia64 has a fix implemented upstream, but untested
[19:33] <mok0> hyperair: ah
[19:34] <mok0> hyperair: ... but you can't test it?
[19:34] <hyperair> mok0: i don't have an ia64 cpu lying around, and qemu won't cut it
[19:34] <hyperair> and i don't have access to an ia64 buildd
[19:34] <mok0> hyperair: yes it's a problem
[19:35] <hyperair> yeah it is
[19:35] <loic-m> mok0: Thanks for your review of cdemu
[19:36] <mok0> loic-m: you're welcome
[19:36] <mok0> hyperair: I suggest you try to work out the problems little by little
[19:36] <hyperair> mok0: little by little how?
[19:37] <hyperair> mok0: it's a small fix.. a patch to configure
[19:37] <hyperair> upstream thinks it'll solve the issue
[19:37] <hyperair> mainly because there are missing compilation flags for x64 (his configure script looks in uname -m and checks if it's x64)
[19:37] <mok0> hyperair: well first thing is to check that it doesn't cause a regression
[19:38] <hyperair> mok0: there won't be a regression because the fix will only affect ia64 builds, and you can't regress further than ftbfs can you
[19:38] <mok0> hyperair: if not, submit a debdiff again -> -0ubuntu3
[19:38] <jacob> james_w: here's something tricky: the maintainer of the -gtk port of snes9x releases his code as GPLv3 as a patch and as patched sources. is this effectively stating that the author is dual-licensing his own gpl'd code with snes9x-licensed code since he is the distributor of the GPLd GTK portion?
[19:38] <mok0> hyperair: heh, no, I was just worried that the fix could affect the platforms that it works on
[19:39] <hyperair> ah
[19:39] <hyperair> don't worry, it won't =)
[19:39] <hyperair> at least, i think it won't. i ahven't seen the fix yet
[19:39] <mok0> hyperair: alright
[19:39] <hyperair> mok0:         if [ "$arch" = "x86_64" ]; then
[19:40] <hyperair> mok0: that's the issue. it doesn't detect ia64
[19:40] <mok0> aha
[19:40] <hyperair> mok0: patching that one line to if [ "$arch" = "x86_64" ] || [ "$arch" = "ia64" ] should do the trick
[19:40] <hyperair> mok0: should, but untested
[19:40] <hyperair> also, i have no idea about the hmma arch
[19:41] <hyperair> hppa sorry
[19:41] <mok0> hyperair: hm. Perhaps there are other examples of software doing similar tricks
[19:41] <hyperair> but what?
[19:42] <hyperair> mok0: wait, is hppa 64bit or 32bit?
[19:42] <mok0> hyperair: ... 32 bits
[19:42] <mok0> hyperair: I don't think it's much used anymore
[19:42] <hyperair> hmm
[19:43] <mok0> We threw out the last hppa machine 5 years ago
[19:43] <hyperair> lol
[19:43] <mok0> At that time, the typical PC was 5-10 times faster
[19:44] <hyperair> uh ouch
[19:44] <mok0> of course they're stable like rocks
[19:44] <hyperair> ah
[19:44] <hyperair> but rocks don't move ;)
[19:45] <mok0> I don't even know if HP makes hppa architecture machines anymore
[19:45] <mok0> However, we have some HP rackserver blades and they are *really* nice
[19:46] <mok0> one is a dual quadcore ;-P
[19:46] <hyperair> wah
[19:46] <mok0> Ideal for running VMs
[19:47] <hyperair> hmm in both issues it was an issue about -fPIC
[19:47] <hyperair> i wonder if qemu does hppa
[19:47] <mok0> hyperair: I don't think so
[19:48] <hyperair> yeah qemulator doesn't have it in the list of options
[19:48] <hyperair> damnit
[19:48] <mok0> hyperair: in fact, it doesn't even work on all i386 arch machines
[19:48] <mok0> ... work WELL, rather
[19:49] <hyperair> hm?
[19:49] <hyperair> i managed to run windows xp on qemu once
[19:49] <mok0> To really work well, it requires a CPU with vmx
[19:50] <hyperair> that's kvm isnt it
[19:50] <hyperair> you don't necessarily need kvm
[19:50] <mok0> yes
[19:50] <hyperair> can live with kqemu =p
[19:50] <mok0> that's very slow though
[19:50] <hyperair> doesn't matter, as long as it gets the building done
[19:50] <hyperair> it's just for testing purposes after all
[19:50] <mok0> hehe yes
[19:51] <hyperair> qemu can do ppc though
[19:51] <hyperair> that would be useful for sigx's ppc ftbfs
[19:51] <mok0> Yes, that's right
[19:52] <mok0> wrt. sigx, is it supposed to be portable?
[19:53] <hyperair> oh yes definitely
[19:53] <hyperair> he used scons because he wanted it to be ultraportable it seems
[19:53]  * hyperair headdesks
[19:53] <mok0> ha
[19:53] <Chris`> So merging Debian packages, is that handles by the MOTU or is it an automated process?
[19:53] <mok0> Chris`: eerrr, both actually
[19:54] <mok0> Chris`: it's semi-automated to be exact
[19:54] <Chris`> mok0: How does it happen then? ;-/
[19:54] <hyperair> run a script, tidy it up, upload a debdiff
[19:54] <hyperair> get it sponsored
[19:54] <hyperair> or if you are a sponsor, then sponsor your own package =p
[19:54] <mok0> Chris`: do you know DaD?
[19:55] <Chris`> mok0: Nope :)
[19:55] <mok0>  http://dad.dunnewind.net
[19:55] <hyperair> mok0: does a report have to be on dad before the grab_merge.sh can work?
[19:55] <mok0> hyperair: no
[19:56] <hyperair> ah
[19:56] <mok0> hyperair: grab-merge just downloads that "merge-package"
[19:56] <hyperair> merge-package?
[19:56] <hyperair> what's that
[19:56] <Chris`> "1.0-0ubuntu1	1.0.1-1" Does that mean that I update to 1.0.1-1ubuntu1 ?
[19:57] <mok0> Chris`: not sure I understand
[19:57] <Chris`> http://dad.dunnewind.net/adblock-plus/
[19:57] <mok0> hyperair: it's what grab-merge downloads
[19:57] <hyperair> Chris`: depends whether or not the differences between debian and ubuntu packaging can be dropped
[19:58] <hyperair> Chris`: if it can be dropped, then sync. otherwise merge
[19:58] <hyperair> Chris`: since it's already up there it's supposed to be merged i should think
[19:58] <mok0> Chris`: I think that's a bad example, because it's not a true merge
[19:59] <mok0> http://dad.dunnewind.net/mpich
[20:00] <mok0> Chris`: from the names you can see that -8ubuntu1 has ubuntu changes
[20:00] <mok0> but there's a newer version from Debian: -9
[20:01] <Chris`> I will have a look & try to work it out :)
[20:01] <mok0> Chris`: so, if you look in REPORT, you can see that there's a conflict in debian/control
[20:02] <mok0> Chris`: if you use the grab-merge script, it will download and unpack everything for you
[20:03] <Chris`> I don't know how to use grabmerge so I am using dget -x
[20:03] <mok0> Chris`: but beware, because grab-merge want's to clear out the current directory
[20:04] <mok0> Chris`: it's simple: "grab-merge mpich" for example
[20:04] <mok0> Chris`: I put grab-merge in ~/bin
[20:04] <mok0> Chris`: and edited it so it doesn't delete cwd
[20:05] <mok0> then I can always cd /tmp; grab-merge blahblah
[20:05] <Chris`> bash: /bin/grab-merge: Permission denied
[20:06] <Chris`> Oh chmod +x
[20:07] <mok0> http://pastebin.com/fde30d42
[20:08] <rgreening> ScottK: ping
[20:08] <mok0> A patch for grab-merge to make it safe, and to unpack everything inside a new directory
[20:09] <ScottK> rgreening: Just about to upload it.
[20:09] <rgreening> so I assume it was all good then?
[20:10] <Chris`> mok0: Is that only half a script?
[20:10] <ScottK> rgreening: Yep.  Just uploaded it.  Thank you for your contribution to Ubuntu.
[20:10] <rgreening> no... ty for your help :)
[20:12] <AndrewGee> I'm just packaging something up which uses a configure script twice. Is there an easy way to do this with CDBS?
[20:21] <RAOF> AndrewGee: It will undoubtedly be easier to just use the 'dh' command from debhelper 7.
[20:21] <Pici> mok0: I added !dad
[20:21] <AndrewGee> RAOF: Okay. I'll investgiate that then.
[20:21] <Adri2000> !dad
[20:22] <RAOF> AndrewGee: It's about as easy as cdbs (you call "dh build" in your build: target, for example), but it's much easier to do funky things with.
[20:22] <AndrewGee> RAOF: Okay. Sounds good. I'd better get learning then. Thanks for your help :)
[20:23] <mok0> Pici: thanks
[20:27] <james_w> jacob: ouch, I can't really parse that
[20:28] <jacob> james_w: hehe, i thought i worded that weird.
[20:29] <hyperair> mok0: could you sponsor bug #322896 and bug #322899 please? the debdiff's attached to both.
[20:30] <jacob> james_w: snes9x is under its own non-gpl-compatible license. the -gtk port is available as a patch under the GPL3. however, the maintainer of this port also released patched sources of his own GPL code and Snes9x-licensed code.
[20:31]  * mok0 looks
[20:31] <james_w> jacob: I think I can't parse it as it doesn't make much sense :-)
[20:31] <jacob> james_w: since it was the author of the GPL patch that also released the original snes9x sources, would it be acceptable in this case to have the GPL3 code inside a non-GPL branch?
[20:32] <james_w> jacob: "the -gtk port is available as a patch under the GPL3." <- patch to snes9x?
[20:32] <jacob> james_w: yes, sorry.
[20:33] <jacob> it's confusing to explain :P
[20:34] <mok0> hyperair: cool, you're using the email interface to LP
[20:34] <Laney> grr, my computer hardlocked and killed my Jaunty VM
[20:34] <jacob> basically, there is GPL code inside a non-GPL product. but, the author of the GPL code has released the whole sources, his code and the non-gpl code
[20:34] <Laney> any newcomer fancy some light mentorship for an easy bug.......? ;)
[20:35] <hyperair> mok0: yeah. i tried to file the two new bugs by sending mails to new@bugs.launchpad.net, but it didn't work
[20:35] <james_w> jacob: no problem
[20:35] <Piratenaapje> Laney: me :D
[20:35] <hyperair> mok0: it did for my needs-packaging bugs though
[20:35] <Laney> Piratenaapje: WOO! I fear it may be uninteresting though
[20:35] <Piratenaapje> Laney: well, I can at least take a look at it
[20:35] <Laney> bug #321533
[20:35] <Laney> should just need a sync
[20:35] <hyperair> mok0: it's also a little annoying in that if you file a bug via the email interface, it doesn't email you back regarding the bug number
[20:35] <Piratenaapje> Laney: My first sync :p
[20:35] <james_w> jacob: "the maintainer of this port also released patched sources of his own GPL code and Snes9x-licensed code." <- that's the -gtk maintainer releasing parts of snes9x under a dual license?
[20:36] <Laney> Piratenaapje: Good, that's fun!
[20:36] <Piratenaapje> Laney: I'll have a try :)
[20:36] <Laney> needs building, installing and testing (that's the part I can't do)
[20:36] <Laney> if it works then requestsync it
[20:36] <Piratenaapje> Laney: why can't you test it?
[20:36] <Laney> because my VM died
[20:36] <Laney> need to reinstall it
[20:36] <Laney> and learn to take snapshots :(
[20:37] <Piratenaapje> Laney: well, I don't have a working vm either atm :p
[20:37] <Laney> ooer
[20:37] <jacob> james_w: yes, though he's not releasing snes9x under a different license, but i'm wondering that since he bundled his own code with it that a dual license is implied
[20:37] <james_w> jacob: implied is dangerous
[20:37] <Piratenaapje> Laney: What machines would I need to test it in?
[20:38] <Laney> Piratenaapje: Anything running Jaunty would be best
[20:38] <james_w> jacob: there are multiple people with copyright in snes9x (and hence -gtk) so one person dual-licensing their contributions doesn't tell us anything about the code as a whole
[20:38] <Laney> some people like to test X applications from pbuilder, but I've not done that before
[20:39] <jacob> james_w: well - not that the whole software package is dual-licensed, but that it's released as two pieces merged into one: the snes9x core under the snes9x license, and the GTK patches under the GPL
[20:40] <jacob> james_w: the -gtk port was written by one person as well if that makes a difference
[20:40] <james_w> jacob: ah, that's valid.
[20:40] <Piratenaapje> Laney: From pbuilder? I'd find that a bit strange :p
[20:40] <james_w> jacob: however, if they are built in to one thing, as I believe they are then the GPL kicks in and the snes9x parts *have* to be licensed under the GPL
[20:41] <james_w> jacob: that's a fundamental part of the GPL, there's no way around it. The GPL does allow you to "bundle" GPL and non GPL (e.g. on Ubuntu CDs) but doing it in one executable is forbidden.
[20:42] <jacob> james_w: even though the person released his own GPL code combined with snes9x code? it almost seems like there's an exception
[20:43] <james_w> jacob: ah, that's true, you can release your code under the GPL with exceptions (e.g. to link with 4 clause BSD), so we may be able to take advantage of that
[20:44] <Piratenaapje> Laney: basicly all I have to do is follow the "preparing new revisions" guide ?
[20:44] <james_w> jacob: it should be noted in the source package COPYING or something if that is the case, we can't assume it is implied
[20:44] <jacob> james_w: if it helps any, http://www.snes9x.com/phpbb2/viewtopic.php?t=3703 has the full package details of the port & patches
[20:44] <Laney> Piratenaapje: No, the sync request process - we get this package from Debian
[20:44] <jacob> james_w: ok, i'll see if the author will note this
[20:45] <Piratenaapje> Laney: so I just have to test the version provided?
[20:45] <Laney> Piratenaapje: test the revision in Debian
[20:46] <mok0> hyperair: codelite fix is uploaded
[20:46] <Laney> make sure all Ubuntu changes aren't needed any more (hint: I did the last merge and think it's a sync...), build, test and requestsync
[20:46] <hyperair> mok0: okay thanks
[20:46] <mok0> hyperair: let's watch it build now
[20:46] <hyperair> mok0: hahah if only it began so fast
[20:47] <hyperair> powerpc already started it seems
[20:48] <mok0> hyperair: it's started on the ppc
[20:49] <mok0> ah
[20:49] <mok0> he scrollback
[20:49] <hyperair> lol
[20:50] <james_w> jacob: "Note that certain parts of certain ports (e.g. the ZSNES SuperFX core) are under different licenses and you must be sure to satisfy those licenses as well."
[20:50] <james_w> jacob: something else to watch out for :-/
[20:50] <mok0> That build farm is awesome
[20:51] <jacob> james_w: that was one of the portions that was supposedly excepted for use in snes9x, but i still need a response from upstream on that
[20:53] <james_w> jacob: I found your post requesting clarification, thanks for that. Reading a few other posts suggests that they don't really subscribe to the DFSG view of software freedom, so this may not be that easy
[20:53] <jacob> james_w: yeah, it probably won't. i think it's worth the fight though :P
[20:54] <mok0> uh-uh, looks like there's a new gcc in jaunty's toolchain
[20:58] <Piratenaapje> Laney: Ok, I built it, how do I check if Ubuntu changes are needed?
[20:59] <Laney> check what they are and see if the reason for them is still present
[20:59] <Piratenaapje> Alright
[21:00] <hyperair> mok0: great are we going to have every lib bumped to 0c2a or whatnot now?
[21:00] <mok0> hyperair: 0c2a?
[21:01] <hyperair> mok0: i don't know, i see quite a few libs with strange sonames and someone told me that it was because of a change in gcc versions or something
[21:01] <Piratenaapje> Laney: the reason for the patch is still present :S
[21:01] <mok0> oh? I haven't seen that
[21:01] <Laney> Piratenaapje: you sure?
[21:02] <Piratenaapje> Laney: I'll pastebin to be sure :p
[21:02] <hyperair> libsigc++-2.0-0c2a <-- an example
[21:02] <maxb> The c2 and a suffices relate to ABI transitions
[21:02] <hyperair> libgtkmm-2.4-1c2a <-- another example
[21:03] <Laney> Piratenaapje: see line 82 in pidgin-libnotify.c
[21:03] <hyperair> ABI transitions.. which ABI?
[21:03] <Piratenaapje> Laney: I opened a wrong patch by mistake :s
[21:03] <Laney> the changelog is your friend
[21:03] <maxb> I believe c2 relates to when a change was made to g++ such that the ABI of all C++ libraries changed simply by recompiling them
[21:04] <Piratenaapje> Laney: 1 patch is directly fixed in the source, the other one is provided by the debian package
[21:04] <Laney> that's usually the way it works
[21:04] <Laney> for backported patches
[21:04] <hyperair> maxb: and 'a'>?
[21:05] <maxb> http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html is the definitive document on the c2 transition
[21:05] <mok0> Fascinating...
[21:05] <jpds> pe
[21:06] <Piratenaapje> Laney: I'll try to install it in a virtual machine, and if it works I can do the requestsync?
[21:07] <Laney> yes sir
[21:07] <Piratenaapje> Lanay: I feel pretty silly for making such stupid mistakes though :p
[21:07] <Laney> everyone makes mistakes!
[21:08] <Laney> Piratenaapje: You can either convert the existing bug into a sync request or file one with requestsync and dupe that one to it (with a comment preferably). Assuming it all works that is.
[21:09] <maxb> http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html is the one for the c2a transition
[21:09] <maxb> hyperair: ^
[21:09] <Piratenaapje> Laney: I'll convert it I guess, starting to install Jaunty in VirtualBox now
[21:10] <Laney> awesome
[21:11] <hyperair> maxb: thanks. that was very informative =)
[22:03] <Piratenaapje> Laney: https://bugs.launchpad.net/ubuntu/+source/pidgin-libnotify/+bug/321533 ,it works under jaunty ;)
[22:07] <maxb> Piratenaapje: I retitled it (LP 321533) using the quasi-official title format for sync requests
[22:08] <Piratenaapje> maxb: Ah oops, I based my title on someone else's title, guess they were wrong too :p
[22:08] <jpds> quasi-official? It's hard-coded into requestsync :)
[22:09] <maxb> But not written down anywhere as policy
[22:10] <maxb> Piratenaapje: The other thing you need to do is subscribe ubuntu-universe-sponsors for review&approval
[22:10] <Piratenaapje> the SyncRequestProcess wikipage indeed doesn't say anything about the titile
[22:11] <maxb> Piratenaapje: except don't do that right now
[22:11] <Piratenaapje> maxb: Laney is supposed to sponsor it, do I need to subscribe them then?
[22:11] <maxb> "The current package has no Ubuntu changes." <--- this is a lie
[22:11] <Piratenaapje> ?
[22:11] <maxb> https://launchpad.net/ubuntu/+source/pidgin-libnotify shows an ubuntu-specific change
[22:12] <Piratenaapje> which is fixed in the debian release
[22:12] <maxb> The sync request is invalid
[22:12] <maxb> ah
[22:13] <maxb> Piratenaapje: See the section "Content of a sync request" on SyncRequestProcess
[22:14] <maxb> The current bug does not fulfil all of the bullet points
[22:14] <ScottK> Then rather than say "No Ubuntu changes", say "Ubuntu changes all incorporated in Debian."
[22:14] <Piratenaapje> Hmm ok
[22:14] <ScottK> maxb: What is it missing?
[22:15] <maxb> #
[22:15] <maxb> If there are Ubuntu changes apart from debian/changelog or if FeatureFreeze is in effect:
[22:15] <maxb>     * A copy of the entries from debian/changelog corresponding to the changes relative to the current version in Ubuntu
[22:15] <maxb> # If there are Ubuntu changes:
[22:15] <maxb>     * a description of each of the Ubuntu changes (a bullet point list is fine, but copies of debian/changelog aren't)
[22:15] <maxb>     * a brief explanation of why each one may be dropped (e.g., it's been merged into Debian, is no longer appropriate, etc.)
[22:15] <maxb>     * an explicit confirmation that the Ubuntu changes should be overridden
[22:19] <Piratenaapje> Alright should be fixed now
[22:21] <Piratenaapje> maxb: Why do I have to wait with subscribing ubuntu-universe-sponsors?
[22:21] <maxb> Only until you'd fixed the things I mentioned
[22:21] <Piratenaapje> maxb: Is it ok now?
[22:26] <jmarsden|work> I'm hoping to get an updated package (biblememorizer) into Jaunty.  It has been synced from Debian in the past and hopefully will be in future also, but right now uploading to experimental and trying to get synced from there will probably not happen quickly enough, I'm told... so can I get a -0ubuntu1 into Jaunty somehow?  Via REVU??  Or how?
[22:30] <jmarsden|work> It is at http://revu.ubuntuwire.com/details.py?package=biblememorizer if REVU is the right way to go with this.
[22:30] <maxb> Piratenaapje: I reckon it's fine now - I added the debian/changelog entry that SyncRequestProcess asks for
[22:30] <Piratenaapje> maxb: Alright thank you, subscribing them
[22:30] <ScottK> jmarsden: How long will it take to get it uploaded to experimental?
[22:30] <maxb> jmarsden|work: I think REVU is strictly for *new* packages.
[22:31] <ScottK> jmarsden|work: If in fact it can't get sync'ed the best way is to make a bug, attach the .diff.gz to the bug and subscribe ubuntu-universe-sponsors to the bug.
[22:32] <jmarsden|work> I'm not sure, but the Debian person who I asked suggested it could be uploaded but then might get stuck awaiting approval by archiev admins or something along those lines; I'll check back with him.
[22:32] <maxb> jmarsden|work: See https://wiki.ubuntu.com/SponsorshipProcess for the long version of what ScottK said
[22:32] <jmarsden|work> OK, thanks.
[22:32] <ScottK> jmarsden|work: If it has to go through New, then they are likely correct about the timing.
[22:33] <directhex> NEW sucks
[22:34] <directhex> 214 packages and counting
[22:34] <ScottK> New is a necessary PITA, but I can understand why it's not a priority in Debian right now.
[22:35] <jmarsden|work> OK, it sounds like I need to be asking "does it have to go through NEW"?  Thanks, that helps.
[22:44] <directhex> ScottK, it's not fun to feel like you're being punished for fixing bugs though - e.g. changing arch from any to all means NEW
[22:45] <ScottK> Right.
[22:47] <directhex> and purely selfishly as an ubuntu contributor, NEW right now is the anti-6-month-release-cycle-friendly way to do business
[23:14] <Piratenaapje> Should I set the status of a [needs-packaging]-bug to fix-committed once I uploaded it to REVU?
[23:16] <nhandler> Piratenaapje: No. Fix Committed is for when a MOTU uploads it
[23:17] <Piratenaapje> nhandler: Thought so, thanks