[00:00] <Laney> Yes, and I'd imagine that check would work on a source package
[00:05] <loic-m> Laney: thanks, I just come back from reading the lintian man page and was still confused ;) (and I was running it against the dsc...
[00:05] <Laney> it's still a good idea to run it on your binary .changes file though
[00:06] <ScottK> Lines longer than 80 are OK in debian/copyright if they come from copying in the license.
[00:09] <loic-m> ScottK: thanks.
[00:10] <loic-m> Laney: I modified a debian/control with useless spaces + one line of 91 characters, debuild -S -sa + pbuilder build the package, but when I run lintian -I on any of the files in pbuilder, I get no output
[00:11] <ScottK> I think debian/copyright was the only file that used to have a lintian check for 80 characters and they ditched that due to more pain than it was worth.
[00:11] <loic-m> Laney: and I checked the .deb produced has the same mistakes
[00:13] <loic-m> ScottK: so there's no way command to automatise those kind of checks? I was trying to see what's feasible as per nhandler suggestion in the ml :(
[00:14] <ScottK> For debian/control build-deb and dep lines longer than 80 is just fine.
[00:14] <ScottK> I think there's too many exceptions and it's not worth the trouble.
[00:14] <ScottK> It's really a minor issue.
[00:14] <ScottK> I have my Kate set with a line at 80 columns so it's really obvious
[00:17] <loic-m> ScottK: thanks.
[00:27] <directhex> ScottK, minor issue, but i hear the new ftpmaster assistants will reject over it
[00:41] <jcfp> Please review http://revu.ubuntuwire.com/details.py?package=sabnzbdplus - thanks
[00:44] <directhex> ew, python
[00:44] <jcfp> :/
[00:45] <cody-somerville> python packages are a charm to review
[00:45] <jcfp> I must agree it isn't designed for easy packaging
[00:45] <directhex> i don't do python packages
[01:21] <ScottK> directhex: Considering there was a lintian check for lines over 80 chars in debian/copyright and it got pulled, I doubt it'd result in a rejection.
[01:21] <ScottK> I may well be wrong though.
[01:26] <ScottK> jcfp: I'm looking at your mochikit request.
[01:41] <ScottK> jcfp: Don't delete uploaders from debian/control and don't put the maintainer change in debian/changelog.
[01:42] <jcfp> ScottK: no other problems?
[01:42] <ScottK> jcfp: Not so far.  I fixed those.
[02:15] <ScottK> jcfp: That was it.  mochikit uploaded.  Thank you for your contribution to Ubuntu.
[02:16] <jcfp> ScottK: thanks :)
[02:16] <ScottK> jcfp: No.  Thank you.
[02:19] <hyperair> Laney: ping
[02:25]  * StevenK stares at the weather applet
[02:25] <StevenK> "39 degC, feels like 42.1 degc"
[02:26] <lfaraone> Hi, what's the proper way to package libabiword (blocking the building of another package dropped from the last release)? It's dependent on abiword, and will only work if you have the same abiword version installed. They'd be built fromt he same source. Do they need to be split into different binary packages?
[02:26] <ScottK> Did they remove 90% of the cities in Australia 'because no one knows where they are anyway"
[02:27] <ScottK> StevenK: ^^
[02:27] <ScottK> lfaraone: I think abiword is used by Xubuntu, so I'd talk to a Xubuntu dev like cody-somerville or NCommander.
[02:28] <cody-somerville> lfaraone, That sounds about right. Is it not currently?
[02:30] <lfaraone> cody-somerville: currently abiword is not built with --enable-libabiword.
[02:30] <lfaraone> cody-somerville: so we can't package python-abiword, which sugar-write-activity depends (I'm a SugarLabs guy).
[02:31] <cody-somerville> lfaraone, Okay. Sounds sane to me.
[02:33] <lfaraone> cody-somerville: Ok, shall I prepare a debdiff where we have that flag enabled that I've tested?
[02:33] <cody-somerville> lfaraone, sure.
[02:33] <cody-somerville> lfaraone, upload it to a ppa
[02:50] <lfaraone> Is there any pressing reason why I shouldn't use distcc for compilations?
[03:27] <ScottK> superm1: Would you mind reviewing http://revu.ubuntuwire.com/details.py?package=rt28xx-linux-sta (it uses dkms, so I think it'd benifit from a look by you)?
[03:51] <loic-m> In a rule file, when declaring variables, can I use a variable I declared just one line above to set another variable, like in  http://paste.ubuntu.com/108861/ ?
[03:51] <nhandler> Yes loic-m
[03:51] <loic-m> Thanks a lot
[04:40] <fabrice_sp> Hi. Any chance to have dvdstyler reviewed? It's a DVD authoring tool, with more the 88000 downloads (at least 9000 for Ubuntu), and has already been advocated by mok0. You can find it at http://revu.ubuntuwire.com/details.py?package=dvdstyler. Thanks.
[04:43] <ScottK> What the heck.  I'll look.
[04:44] <fabrice_sp> Thanks ScottK !
[04:45] <nhandler> fabrice_sp: Why do you have uscan_repack instead of a normal get-orig-source target?
[04:46] <fabrice_sp> nhandler, it has been requested by mok0 to make it more automatic to get the orig tarball (download + repack in one shot)
[04:46] <nhandler> So why couldn't the get-orig-source rule be used to do that?
[04:47] <fabrice_sp> get-orig-source call that script
[04:47] <fabrice_sp> and it's also called from the watch file
[04:47] <fabrice_sp> so it's a way to do it the same way with a get orig or a uscan
[04:48] <ScottK> fabrice_sp: Why compat 6?
[04:48] <nhandler> fabrice_sp: Ok, I didn't see the get-orig-source in there
[04:49] <fabrice_sp> ScottK, you're right, I'm using any special functions. I think I had to bump it to get rid of a lintian warning
[04:49] <fabrice_sp> nhandler, ok
[04:49] <loic-m> Is there a way to verify that a get-orig-source target in debian/rules works?
[04:49] <fabrice_sp> ScottK, I'll put 4 again, and check that
[04:49] <ScottK> fabrice_sp: If it's 6, then you also need to version your debhelper build-dep.
[04:49] <ScottK> OK
[04:49] <nhandler> loic-m: make -f debian/rules get-orig-source
[04:50] <loic-m> thanks nhandler
[04:50] <nhandler> fabrice_sp: I would only drop to 5
[04:50] <fabrice_sp> ScottK, you're right.
[04:51] <nhandler> fabrice_sp: What is ubuntu.patch?
[04:51] <nhandler> And debian.patch?
[04:51] <fabrice_sp> Does that mean that if I put 5, I also need the version in build-dep?
[04:51] <nhandler> Yes
[04:51] <nhandler> Build-Dep on debhelper (>= 5)
[04:51] <ScottK> Does your desktop file have an icon?
[04:52] <ScottK> Because if it does, you want at least a version with dh_icons with is about 5.0.51 or so.
[04:52] <fabrice_sp> nhandler, it comes from upstream. He has a script (builddebian) that build the package for lenny and ubuntu, and it uses this script to apply it. I'm not using them as they are for control file
[04:52] <fabrice_sp> ScottK, the icon comes fom upstream
[04:53] <ScottK> Yes, but we have an icon cache so you want to call dh_icons.
[04:53]  * nhandler heads off to bed
[04:53] <fabrice_sp> ok
[04:53] <vorian> nn nhandler
[04:54] <ScottK> fabrice_sp: See man dh_icons.
[04:54] <loic-m> nite nhandler
[04:54] <ScottK> Set your build-dep to whatever version introduced that and your compat to 5.
[04:54] <ScottK> Then add it to your debian/rules.
[04:54] <fabrice_sp> ScottK, will do. thanks
[04:54] <fabrice_sp> (good night nhandler)
[04:56] <fabrice_sp> dh_icons has been added with version 5.0.51, so I'll update control, compat and rules
[04:57] <ScottK> fabrice_sp: Look at the licensing header for wxVillaLib/thumb_md5.cpp.  You need to mention that in debian/copyright.
[04:58] <loic-m> For my get-orig-source target, I use $(DEBIAN_DIR)/../.. so the .orig.tar.gz is created in the directory above the package directory
[04:59] <fabrice_sp> ScottK, you're right. I thought I had reviewed all the source, but I must have forgotten this one. As it's public domain, I put that as licence?
[04:59] <loic-m> However to make the .orig.tar.gz i need to tar a directory that's the same name as the directory I work in
[04:59] <ScottK> fabrice_sp: I'd put that entire paragraph in debian/copyright.
[04:59] <loic-m> It sound insane, but is it ok?
[05:00] <ScottK> loic-m: Shouldn't it be the name of the new version, not the one you're in?
[05:00] <fabrice_sp> ok
[05:01] <loic-m> ScottK: You're right, since actually it'll only do the job if there's a new upstream version
[05:02] <loic-m> ScottK: since my version is the same as upstream atm, it gives me headaches, but actually it will never be a problem, right?
[05:02] <ScottK> loic-m: If your rule were smart, it'd notice it's the same version and stop.
[05:04] <loic-m> ScottK, can you have a lok at http://paste.ubuntu.com/108866/ please?
[05:05] <loic-m> should i add an "if" or is it ok considering nobody's going to target get-orig-source as long as there's no new upstream version?
[05:07] <ScottK> loic-m: I'm not an expert on get-orig-source writing.  I'd have it test if there's a new version or not.
[05:09] <fabrice_sp> ScottK, adding that (http://paste.ubuntu.com/108867/) in debian/copyright for wxVillaLib/thumb_md5.cpp is fine?
[05:10] <ScottK> fabrice_sp: Looks fine to me.
[05:11] <fabrice_sp> ok. I'm building the package, to check the dh_icons stuff. As soon as it gets built, I'll upload the new version
[05:12] <ScottK> fabrice_sp: It FTBFS for me.  http://paste.ubuntu.com/108869/
[05:13] <fabrice_sp> ScottK, that's what I'm just looking at. Changes in ffmpeg introduce this error (it has been built before for Jaunty in my PPA)
[05:13] <ScottK> ffmpeg is like that.
[05:13] <fabrice_sp> ScottK, I know :-/
[05:17] <fabrice_sp> it seems upstream has made a patch 3 days ago. I'll apply it and build again. Thanks for your review anyway!
[05:17] <loic-m> ScottK: actually testing for a new version might defeat the use of uscan --force-download, so I'd use the package directory to build the orig.tar.gz, even though I dl the upstream zip in the above directory and create the orig.tar.gz in the above directory too
[05:18] <loic-m> Hopefully it's ok
[06:33] <savvas> when I create a new package, do I have to subscribe any teams? the ubuntu sponsors?
[06:34] <savvas> https://bugs.launchpad.net/ubuntu/+bug/95685
[06:37] <Amaranth> wow, old bug
[06:39] <Amaranth> savvas: ubuntu-universe-sponsors, btw
[06:40] <Amaranth> Wait, I think that's for changes to packages
[06:42] <savvas> eh, I'll just leave it like that
[06:42] <savvas> I've sent it to REVU :p
[06:44] <persia> REVU is the right place.  No subscription required.
[06:45] <savvas> woohoo!
[06:45] <savvas> oh no, damn dependencies..
[08:22] <fabrice_sp> Hi. Any MOTU to review DVDStyler? I lost the advocate of mok0, because of fixing some issues detected by ScottK and fixing a FTBFS because of latest version of ffmpeg (http://revu.ubuntuwire.com/details.py?package=dvdstyler)
[08:50] <didrocks> morning everyone
[08:53] <fabrice_sp> Hi didrocks
[09:03] <didrocks> Hi fabrice_sp
[09:05] <fabrice_sp> only French guys speaking this morning :-)
[09:06] <persia> C'est un bon matin pour Ubuntu :)
[09:08] <fabrice_sp> wouah persia: you are a fluent French writer ;-) Perhaps, we should switch the channel' language to French ;-) (and you scared mangilimic lol)
[09:09] <syockit> Hey, don't do that!
[09:09] <persia> Aren't there already several francophone channels?
[09:09] <syockit> Any guides to writing rules for cdbs?
[09:09] <persia> syockit, google for "CDBS Documentation" and visit the duckcorp site.
[09:10] <didrocks> persia: congrats' :)
[09:10] <persia> didrocks, ?
[09:10] <didrocks> persia: for you French :)
[09:10] <didrocks> your*
[09:10] <didrocks> persia: and yes, there is one channel #ubuntu-fr-devel for French people
[09:10] <persia> C7est mon premiere langue, mais je ne parle jamais dans trent ans.
[09:11] <didrocks> persia: ah d'accord, je comprends mieux :-)
[09:11] <persia> I thought there was :)
[09:12] <didrocks> persia: the other channels are not developpers related, more community or admin ones
[09:13] <persia> At some point I remember there also being development stuff in #ubuntu-classroom-fr, but maybe that was just scheduled talks.
[09:14] <fabrice_sp> I didn't knew about #ubuntu-fr-devel. Will have a look (even if no French channel will replace ubuntu-motu ;-) )
[09:14] <didrocks> persia: yes, it's now #ubuntu-fr-classroom and we try to handle regular session. But this is more an "event" channel: most of the time, people are just idling
[09:15] <persia> Much like #ubuntu-classroom.  Makes sense.
[09:15] <didrocks> Exactly
[09:29] <emgent> morning
[09:49] <Piratenaapje> I'm currently trying to package my first application for Ubuntu, and am kind of stuck. I have to write a debian/rules files, and this allways seems to use make. The application I'm packaging does not use make to install itself, and because of that, does not use make at all. Is there a way to write this file without the use of make? Can I replace the make calls with my own installer script?
[09:50] <directhex> Piratenaapje, yes and no
[09:51] <directhex> Piratenaapje, debian/rules is a makefile. end of story. however, in a makefile, you can call other executables such as, say, a compile.sh file you write in debian/rules
[09:52]  * persia notes that there are cases where debian/rules isn't a makefile, but use of a makefile means that most of the available documentation will be helpful.
[09:52] <Piratenaapje> So I could just call my installer script instead of calling make?
[09:53] <persia> Piratenaapje, debian/rules has several rules.  See http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules for the required targets.
[09:53] <Piratenaapje> Allright, Ill have a look at it, thanks
[09:54] <persia> So, you'd write debian/rules in such a way that for each of the required targets, it called the appropriate bits of the upstream build system to create the package.
[09:54] <persia> OOh!  make is now "MUST".  Cool!
[09:57] <directhex> Piratenaapje, an example of a non-make build system which you can call from inside debian/rules would be ant, which i'm sure persia here has more than enough interaction with
[10:00] <persia> Python distutils is probably at least as common
[10:06] <directhex> perhaps, but i see you as a java person for some reason
[10:08] <Webspot> If any MOTUs are around and available, could they review my package? It's a GTK widget to embed openstreetmap into applications: http://revu.ubuntuwire.com/details.py?package=osm-gps-map
[10:14] <DktrKranz> Webspot, I'll have a look
[10:14] <Webspot> DktrKranz: Thanks.
[10:14] <fabrice_sp> x
[10:15] <persia> directhex, Certainly, although I believe in pointing at alternatives when someone is learning.  Also, ant is annoying because of the number of things that have to be installed to make debian/rules clean work.
[10:43] <Piratenaapje> Hmm I'm nearly done with the debian/rules file I think, but still having a problem with the install part
[10:43] <Piratenaapje> dh_gencontrol keeps failing:
[10:43] <Piratenaapje> dh_gencontrol -- -pgrnotify
[10:43] <Piratenaapje> dpkg-gencontrol: error: package grnotify not in control info
[10:45] <DktrKranz> Webspot, commented
[10:45] <Webspot> DktrKranz: Thanks. I'll check it out.
[10:46] <Piratenaapje> I could just reuse the control file I allready have, but that's a pretty ugly thing to do.
[10:48] <persia> Piratenaapje, debian/control must include all packages that the package will build before the package starts building them.
[10:48] <Piratenaapje> It only builds 1 package: grnotify
[10:49] <Piratenaapje> Package: grnotify
[10:49] <Piratenaapje> Source: grnotify
[10:49] <Piratenaapje> That's from my control file
[10:49] <persia> Piratenaapje, please pastebin your debian/control
[10:50] <Piratenaapje> http://paste.ubuntu.com/108922/
[10:51] <jcfp> looking for reviewers for http://revu.ubuntuwire.com/details.py?package=sabnzbdplus - the necessary update of mochikit has been done so that problem no longer exists
[10:52] <persia> Piratenaapje, You want to have two stanzas in your debian/control.  One starting Source: and one starting Package:.  Take a look at some other debian/control files for examples.
[10:52] <Piratenaapje> persia, ok thanks, I'll look around a bit
[11:04] <Piratenaapje> Yay, packaging is done :D. Thanks everyone
[11:05] <Piratenaapje> First some food, and then time to upload it :)
[11:15] <tuxmaniac> Dear All, I want to add readme.source file for dpatch in debian folder. But the first line in thewiki page says from Janty you can just link it to the existing directory. Is this a symlink that is referred to or a file which just has the link mentioned?
[11:15] <tuxmaniac> because I am on Intrepid and /usr/share/doc/dpatch/README.source.gz  iss not available in there and gives me an error
[11:15] <Elbrus> tuxmaniac: I think just mention the file in the text in readme.source.
[11:16] <Elbrus> if a user tries to build it needs dpatch and thus has the file
[11:16] <Elbrus> IIAC
[11:16] <tuxmaniac> Hmm okk Elbrus thanks
[11:18] <Elbrus> tuxmaniac: see http://packages.ubuntu.com/jaunty/all/dpatch/filelist
[11:18] <Elbrus> and indeed not on Intrepid
[11:19] <tuxmaniac> Elbrus: yep. So I also suppose it is just the link to the file as text content of Readme.source.
[11:20] <Elbrus> yes
[11:21] <persia> Generally, I'd recommend something of the form of "THis package uses dpatch for patch management.  Please see /usr/share/doc/dpatch/README.source for details."
[11:21] <persia> Or some other phrasing, but the point is to make it pleasant for a human to read.
[11:59] <DktrKranz> broonie, thanks for uploading ;)
[11:59] <broonie> np
[12:00] <DktrKranz> Hoping it will have a different ending than previous try
[12:31] <Ape3000> Where can I find a sponsor that would accept this: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/238179/comments/17
[12:33] <pochu> Ape3000: #ubuntu-desktop, but not likely today (I'd suggest you ask on Monday or on a working day)
[12:33] <pochu> Ape3000: also, you should attach a debdiff and not a diff.gz there
[12:33] <Ape3000> So where do I get the debdiff?
[12:34] <pochu> debdiff nautilus_2.25.3-0ubuntu2.dsc nautilus_2.25.3-0ubuntu3.dsc > debdiff
[12:35] <pochu> Ape3000: we require diff.gz for new upstream releases, but for new debian revisions, a debdiff is easier to review
[12:36] <Ape3000> But you cannot find the changed code in dsc-files
[12:36] <pochu> Ape3000: the debdiff command will diff the two complete packages
[12:36] <Ape3000> k
[12:36] <pochu> including the diff.gz and orig.tar.gz where you made your changes
[12:37] <pochu> just run the command without redirecting it to a file and you will see :)
[12:44] <Piratenaapje> Is there anything special I need to add to the debian/rules file to add my manual entry? I made a debian/packagename.1 file, but it's not getting included for some reason.
[12:45] <persia> Piratenaapje, You want dh_installman and to create debian/package.manpages
[12:45] <Piratenaapje> persia: I allready call dh_installman, it just isn't including my file for some reason
[12:46] <persia> You have a debian/manpages file?
[12:47] <Piratenaapje> Whoops no, silly me
[12:53] <Piratenaapje> persia: Weird, I didn't read anything about a manpages file in the maintainers guide, but it works now. Thanks
[12:55] <persia> Piratenaapje, It's a good idea to read the manpages for the dh_* tools when using them.
[13:06]  * didrocks strongly agrees. Furthermore, those manpages (dh_*) are clear enough to understand what is currently done over the package.
[13:08] <didrocks> if anyone wants to give some love to http://revu.ubuntuwire.com/details.py?package=loggedfs, she/he's very welcome :)
[13:12] <quadrispro> w-scan need some love, too -> http://revu.ubuntuwire.com/details.py?package=w-scan (it's almost ready to be advocated)
[13:14] <quadrispro> s/need/needs
[13:20] <binarymutant> are there certain days that the archive admins check the jaunty queue and email out any problems they find, etc ?
[13:21] <james_w> jaunty queue?
[13:22] <binarymutant> I'm not sure how else to put it, the queue that advocated packages from revu go to
[13:22] <nhandler> The New Queue
[13:22] <binarymutant> ya thanks :) the New queue
[13:22] <james_w> it's done every so often
[13:23] <binarymutant> like a once a week or month thing?
[13:23] <nhandler> binarymutant: And I would assume that the Archive Admins each have their own personal schedule for when they go through the queue.
[13:23] <nhandler> Usually, it takes about a week
[13:23] <james_w> more than once a week
[13:23] <binarymutant> thats cool, thanks for that info :)
[13:24] <persia> There are currently four archive admins that have committed to looking at the queue once a week, although it doesn't always get cleared each day.
[13:25] <binarymutant> thats cool that they have made a commitment
[13:25] <binarymutant> they should get more karma :)
[13:26] <persia> They certainly should.
[13:26] <Piratenaapje> I just uploaded my package to REVU, how long does it usually take to show up? Or does not showing up yet mean I did something wrong?
[13:27] <Piratenaapje> Disregard that
[13:27] <binarymutant> thanks for the help
[13:28] <persia> Piratenaapje, Generally it shows up in 5-10 minutes, and otherwise ask for a REVU Admin to help (although it maybe only matters for the future)
[13:28] <Piratenaapje> Yeah it just showed up :)
[13:28] <d7415> hi, if I want to add an new package to ubuntu, that has already been set up for Debian (but not in their repos) should I change the Maintainer field in debian/control? And is it better to work with the source tar.gz and recompile it?
[13:30] <persia> d7415, Yes, change the maintainer field, and no, don't repackage it.
[13:30] <persia> d7415, If it's expected to get into Debian soon, it's probably better to just let that happen, and sync it.
[13:31] <Piratenaapje> So, I should now wait untill I get feedback from a reviewer or MOTU?
[13:31] <persia> Yep.
[13:32] <Piratenaapje> Allright, guess it's best I start studying for my exams then :s
[13:33] <d7415> persia, ok - just to check that, if I have a tar.gz with a debian/ folder and a deb, I should get the deb and open it up? or run debuild on the tar?
[13:34] <d7415> and I don't think it's going in - it has a .deb available for download though
[13:36] <persia> d7415, If you have a tar.gz with a debian/ folder, it would benefit from repackaging, usually.
[13:37] <persia> Mind you, it's usually not best to repackage something someone else is packaging without talking to them.
[13:38] <d7415> ok. I might start looking at packaging it locally and get in touch with the developer
[13:38] <d7415> thanks for the help
[14:38] <lfaraone> Hi, how can I tell debuild to use a different compiler instead of GCC?
[14:38] <persia> lfaraone, debuild doesn't use gcc
[14:39] <persia> debuild uses make
[14:39] <lfaraone> persia: well, it calls make which calls gcc.
[14:39] <persia> Well, it calls debian/rules, which does whatever.
[14:39] <lfaraone> persia: my main workstation is slow. I have another machine which is uber-fast, and I'm thinking of using distcc to speed  it up. without editing the makefile, is there anyway to change what compiler is called?
[14:39] <lfaraone> persia: (building abiword)
[14:40] <lfaraone> persia: In this case, make is eventually called.
[14:40] <persia> You'd have to either patch the upstream build system to use something else, pass some options in debian/rules if the upstream build system supports that, or fiddle with symlinks in your build environment to confuse the build system.
[14:42] <persia> lfaraone, Confusing the build system is probably your best option.  There's a guide on using distcc with pbuilder at http://blog.edseek.com/~jasonb/articles/pbuilder_backports/advpbuilder.html
[14:48] <lfaraone> persia: would it be unbearably slow to run a build on a uber-fast-processer-machine with sshfs for disk-IO? (I only have one machine I want to cluster)
[14:49] <persia> Depends on your patience.  network filesystems are *slow*.
[14:50] <persia> If I had that situation, I'd probably set up a build server on the fast machine, and dput stuff from the slow machine.
[14:50] <persia> deb-o-matic might be a relatively lightweight place to start
[14:52] <lfaraone> persia: hm, /me looks.
[14:57] <gregor_> Who is responsible of youtube-dl? Can you please add support, to download higher resolution videos? keepvid.com presents me a better version to download, example link: http://keepvid.com/?url=http%3A%2F%2Fde.youtube.com%2Fwatch%3Fv%3Dlqt9_9np4-8
[14:58] <persia> gregor_, For that, I'd recommend filing an enhancement request upstream.
[14:59] <james_w> gregor_: http://www.arrakis.es/~rggi3/youtube-dl/
[14:59]  * persia admires james_w's google-fu
[14:59] <james_w> copyright file :-)
[14:59] <persia> gregor_, Contact information is at Freshmeat.
[15:00] <persia> james_w, I always forget to do that.
[15:00] <gregor_> yes, also checking the website james give me ;)
[15:35] <pochu> does it happen to you that you think you get too many mail and think you should unsubscribe from some mailing lists, but then end subscribing to some more all the time? It even looks like a loop
[15:36] <pochu> while (true) { printf("I should unsubscribe from some mailing lists\n"); subscribe_ml(); }
[15:38] <persia> pochu, I'd recommend filtering your mailing lists, and having an ignore bundle.  When you think you should unsubscribe, push it to the ignore bundle.  If you find yourself looking at it often enough, bring it back.
[15:38] <laga> persia: i wish thunderbird had a "kill this thread" button for emails. it works for newsgroups, though
[15:39] <persia> laga, You might find a local SMTP->NNTP gateway helpful ...
[15:39] <laga> persia: i might find a proper MUA helpful.
[15:40] <cody-somerville> Whats the correct way of regenerating autoconf files if you have to?
[15:40] <persia> Depends on the problem statement :)  If the problem is "I'd like to be able to read mail in a sane way", then yes.  If the problem is "Thunderbird lacks this feature, and I'm too lazy to code it", then no :)
[15:40] <laga> persia: haha. true. :)
[15:48] <dooooomi> what if the maintainer of a package changes while still in revu? should this be mentioned in the changelog, or should the previous changelog entry simply be replaced?
[15:50] <ScottK> dooooomi: You can credit multiple people in one changelog entry.
[15:53] <dooooomi> ScottK: ok, i'll do that. i was just wondering because for all packages i've looked at the first entry only said something like "initial release" and nothing else
[15:53] <ScottK> Is this based on my comment yesterday?
[15:53] <ScottK> I did a comment about something like this, but don't recall which package.
[15:55] <dooooomi> ScottK: it is :)
[15:55] <dooooomi> ScottK: the package is http://revu.ubuntuwire.com/details.py?package=pyliblo
[15:55] <ScottK> Right.
[15:55] <ScottK> So here's what to do ....
[15:56] <ScottK> Edit debian/changelog so that it's just got the initial entry from the previous person
[15:56] <ScottK> Then do dch Updated package:
[15:57] <ScottK> Then when you open the changelog in your editor, it'll have a section for you and a section for the previous person's work.
[15:57] <anakron> Hi all!!
[15:58] <anakron> someone here use basilisk2? a macintosh emulator?
[16:01] <dooooomi> ScottK: thanks!
[16:05] <persia> anakron, I have
[16:06] <anakron> it doesn`t have a desktop file and i want to help doing one
[16:06] <anakron> but i dont know which category i must add it
[16:06] <loic-m> contrib/otherosfs like uae?
[16:07] <anakron> ill copy our conversation here
[16:08] <anakron> hey, i wanna know if someone here think that the search tool could be better if it looks into the bug report
[16:08] <anakron> and not only headers
[16:09] <anakron> because when i try to find bug reports about "desktop files" it's difficult to define a good search, because the search tool doesn't look into the body of the bug report
[16:09] <persia> anakron, Categories=System;Emulator;
[16:09] <anakron> ok thanks
[16:09] <anakron> :)
[16:10] <persia> anakron, http://standards.freedesktop.org/menu-spec/latest/apa.html lists all the Categories, and can help to pick something.
[16:10] <anakron> :) thanks!
[16:10] <persia> For some emulators, for instance, the correct choice would be Game;Emulator;
[16:11] <anakron> ok
[16:11] <anakron> ill do a desktop file and upload it to the bug report
[16:11] <anakron> but now i must wash the dishes
[16:11] <anakron> :)
[16:11] <loic-m> anakron: actually e-uae might be a bad example, the menu file has section="Applications/Emulators"\ but nothing appears in Gnome
[16:11] <anakron> ok
[16:12] <anakron> bye!
[16:12] <persia> loic-m, Do you have the menu and xdg-menu packages installed?
[16:12] <loic-m> persia: I've backported the packages on intrepid amd64
[16:13] <loic-m> and installed the deb. I've got the menu file in /usr/share/menu/
[16:14] <loic-m> and the pixmaps in /usr/share/pixmaps/
[16:14] <persia> loic-m, Yes, but do you have the menu and xdg-menu packages installed?
[16:14] <dooooomi> ScottK: what did you mean by "the licensing for the packaging points the license"? what exactly should i change?
[16:16] <loic-m> persia: sorry, I didn't understand. I don't have menu or menu-xdg installed
[16:16] <ScottK> Generally it's something like "Packaging is licensed under GPL v 2 or later.  See above."
[16:17] <loic-m> persia: should the e-uae package depend on both?
[16:17] <ScottK> dooooomi: It's a small point, but you want to point someone to the full text of the license in question.
[16:18] <persia> loic-m, Please don't make it depend on them, but if you want to see the Debian menu (constructed from menu files) you need to install those packages.
[16:18] <Piratenaapje> REVU warned me that I had several common errors in my package, is there any way to generate the lintian file without uploading to REVU first?
[16:18] <loic-m> persia: the problem is users will look for an entry on the menu (e-uae has a gui)
[16:18] <dooooomi> ScottK: oh, ok
[16:18] <persia> Actually, you might have to depend on menu when providing a menu file: check the menu package documentation, but don't depend on menu-xdg: that just makes menu files appear in GNOME/KDE/XFCE
[16:19] <persia> loic-m, Then please also provide a .desktop file.
[16:20] <loic-m> persia: do the package need to depend on menu if I use a .desktop file?
[16:20] <persia> loic-m, Please include both a menu file and a .desktop file.
[16:22] <loic-m> persia: the menu file is already in the package, I'll read menu pkg doc to see if e-uae need to depend on menu, and I'll try to make a desktop file too
[16:23] <persia> loic-m, That sounds like a good plan.
[16:23] <loic-m> persia: however the package comes straight from Debian and has been sponsored "recently", the maintainer seems active so I'll get in touch with him, he might be also working in Ubuntu
[16:26] <persia> loic-m, I'd recommend creating a .desktop file, testing it, and filing a bug in Debian.
[16:26] <Piratenaapje> I'm an idiot, why didn't I google my question first?
[16:26] <persia> It's not really worth a push to Ubuntu just for a .desktop file.
[16:27] <persia> Piratenaapje, Also, please run lintian on your binary build: it provides a separate set of tests.  I recommend running `lintian -iIv` to get maximum verbosity.
[16:27] <Piratenaapje> persia: ok thanks :)
[16:30] <Piratenaapje> Hmm, still alot of things to fix
[16:30] <loic-m> persia: i'll do that, thanks
[16:44] <anakron> hi again
[16:45] <weboide> Hey all, I'm trying to package a tarball but it says it needs to be built into another directory than the source dir (for autoconf reasons I guess), How can I do that in debian/rules?
[16:46] <persia> weboide, You could create a ./build directory and then build it there in your build: rule.
[16:47] <weboide> persia: And I don't need to clean this up?
[16:48] <persia> weboide, You do need to clean it up, but you do that in your clean: rule.
[16:48] <weboide> persia: okay, thanks for your help :)
[16:48] <anakron> one question
[16:49] <anakron> if the package doesn't give an icon
[16:49] <anakron> and i want to add an icon for a desktop file
[16:49] <anakron> how i can do it
[16:50] <persia> I like gimp for creating icons, personally.
[16:51] <anakron> but i and it like
[16:51] <anakron> Icon=basilisk2
[16:51] <anakron> and upload the icon too?
[16:51] <anakron> http://basilisk.cebix.net/ this is the homepage of basilisk2
[16:52] <anakron> i should use that apple like an icon?
[16:52] <persia> Dunno if you can: that was the Apple logo at one point.
[16:53] <anakron> yeah i know
[16:53] <anakron> im looking in source package if there is any icon
[16:54] <persia> I'd recommend using an .xpm or .svg icon, as otherwise you have to uuencode and uudecode it, which is annoying (unless you can convince upstream to ship it).
[16:54] <weboide> persia: Do you have any idea of a package that I can learn from?
[16:54] <anakron> i found one ico file in his Windows files...
[16:54] <anakron> =S
[16:54] <persia> anakron, Excellent.  imagemagick can convert that into .xpm, and you're all set.
[16:55] <anakron> ok
[16:55] <persia> weboide, I think torcs does that, if I remember correctly.  Of course, you'd probably like a smaller source package :)
[16:55] <tdomhan> does the merge-o-matic merge from debian testing or unstable?
[16:55] <persia> tdomhan, I think it merges from the last sync source for a package, which is usually unstable, but can be testing or experimental.
[16:55] <weboide> persia: okay, I'll check it out :)
[16:56] <anakron> mmm
[16:56] <anakron> there are two icons
[16:56] <anakron> one is called basilisk2.icon
[16:56] <anakron> and the other is basilisk2GUI.icon
[16:56] <anakron> and they are different
[16:57] <persia> Which seems like the right one?
[16:57] <anakron> ... one is a face
[16:58] <anakron> and the other is a PC
[16:58] <persia> They are about the same size?
[16:58] <anakron> :O
[16:58] <anakron> yes
[16:59] <anakron> i think that i only put there basilisk2
[16:59] <persia> Then pick the one you think should be best, and submit a .desktop file that uses that one.
[16:59] <anakron> and upload both
[17:00] <anakron> then the maintainer should choose
[17:02] <Piratenaapje> If I force an upload to REVU with the same version number, the current version will be replaced right?
[17:03] <ScottK> Piratenaapje: Yes.  No need to force, just delete the existing .upload file in your local directory.
[17:04] <persia> anakron, No, pick one, and present a patch the maintainer can easily apply.  Mention in the bug description that there is another one, that the maintainer may choose if they like.  That makes is easier for the maintainer if they don't care which icon is used.
[17:04] <anakron> ok
[17:05] <Piratenaapje> ScottK: ok thank you
[17:06] <Turl> hello, I did an updated version of proxychains, how can I upload it to revu?
[17:07] <ScottK> Same way you did before.
[17:07] <Turl> ScottK: I'm not the package maintainer
[17:08] <ScottK> So it's an existing package in Ubuntu?
[17:08] <Turl> yep, this version was out long ago, but the maintainer never upgraded the package
[17:09] <Turl> any way of updating it then ScottK?
[17:09] <ScottK> In that case, make a bug against the package in Launchpad, attach the diff.gz to the bug, and subscribe ubuntu-universe-sponsors to the bug.
[17:10] <Webspot> Hi. How can I package something, with CDBS, from a VCS that uses autogen.sh to create a configure file?
[17:10] <Turl> ScottK: I updated the .orig.tar.gz too, should I upload it? or you want a debdiff?
[17:11] <ScottK> Turl: If you have a particular interest in the package, you might consider asking the Maintainer to let you take it over in Debian.
[17:11] <ScottK> Turl: No.  The sponsor will get the upstream tarball themselves.
[17:11] <ScottK> Since a debdiff would include all the upstream changes, it's of little point.
[17:11] <Turl> ScottK: I'm doing this for a friend who needs it, and well, I did it, so why not contribute it?
[17:12] <ScottK> Sure
[17:12] <Turl> ScottK, ok then
[17:12] <Turl> ScottK: the package is in my ppa, if you want to take a look https://launchpad.net/~turl/+archive
[17:12] <persia> Webspot, You can either run autogen at packaging time, or have the build system run it before configure at build-time.  Check the CDBS Documentation for the guidelines on running things pre-configure.
[17:13] <ScottK> Turl: I don't have time currently.  If you do as I suggested it'll get looked at in due course by a sponsor.
[17:14] <Webspot> persia: But if I run it before building, it then complains that it's changed in relation to the .orig.tar.gz.
[17:15] <Turl> ScottK: done https://bugs.launchpad.net/ubuntu/+source/proxychains/+bug/250973
[17:15] <Piratenaapje> Hmm I can't figure out why I'm getting this warning:
[17:15] <Piratenaapje> W: grnotify source: changelog-should-mention-nmu
[17:16] <Piratenaapje> the XSBC-Original-Maintainer value in debian/control and in debian/changelog are byte for byte the same
[17:17] <persia> Webspot, You're using a patch system?  In that case, create a patch that is the result of having run autogen if you want to do it at packaging time.
[17:18] <Webspot> persia: Okay. Thanks :)
[17:19] <ScottK> Turl: That's good, but for Ubuntu it should be -0ubuntu1 not -1.  If it ever gets into Debian, we want their revision to be higher.
[17:21] <persia> Piratenaapje, What version number are you using?
[17:21] <persia> Or rather, revision number
[17:22] <Turl> ScottK: the package is in debian already iirc
[17:22] <Piratenaapje> persia: of what? lintian?
[17:22] <Turl> ScottK: http://packages.debian.org/etch/proxychains
[17:23] <Piratenaapje> 2.1.6 if so
[17:23] <ScottK> Turl: I mean this version.
[17:23] <persia> Piratenaapje, Of grnotify
[17:24] <Turl> ScottK: should I fix it and reupload the diff.gz?
[17:24] <ScottK> Turl: Yes.  I didn't look, but I'm guessing you also need to update the maintainer for Ubuntu.
[17:25] <Piratenaapje> persia: I'm currently not using any revision controls system :p
[17:25] <ScottK> Turl: The simplest way to do this is install the ubuntu-dev-tools package and then run update-maintainer from the package dir.
[17:25] <Turl> ok ScottK
[17:25] <persia> Piratenaapje, OK.  What's the first line of your debian/changelog?
[17:25] <Piratenaapje> grnotify (1.0.2) unstable; urgency=low
[17:25] <persia> OK.  I see the issue.
[17:26] <persia> Does grnotify have an upstream or is it Ubuntu-specific for some reason?
[17:27] <Piratenaapje> It's Ubuntu-specific for now
[17:27] <persia> Is it the same as grnotify.sourceforge.net ?
[17:27] <Piratenaapje> yes
[17:27] <persia> Then it has an upstream :)
[17:27] <Piratenaapje> Oh right :s
[17:28] <persia> So, the part in parentheses is of the form ${version}-${revision}
[17:28] <persia> You'd want something like 1.0.2-0ubuntu1 for a first upload to Ubuntu.
[17:28] <persia> We track the revision number separately from the version so that we can upload multiple revisions of the same version with bugfixes, etc.
[17:29] <Piratenaapje> Oh alright
[17:29] <Piratenaapje> But that doesn't fix my problem I think?
[17:29] <persia> Now, the NMU warning you're getting is because without the revision, the system that tries to detect whether you are uploading to Ubuntu or Debian is confused.
[17:30] <persia> Once you change to 1.0.2-0ubuntu1, it will go away.
[17:30] <persia> In Debian, the changelog signer must match either the Maintainer or one of the Uploaders in order to not be considered an NMU.
[17:30] <persia> We use a very trivial method to detect Ubuntu revisions: a check for the string "ubuntu" in the revision number.
[17:31] <persia> So, your package is being judged against Debian uploader etiquette, which results in that warning.
[17:31] <Piratenaapje> Yay, no warnings now, thanks
[17:35] <Piratenaapje> So when can I expect for someone to look at my package? Next REVU day?
[17:37] <persia> Piratenaapje, Well, you could ask here for reviews, although people frown on anyone asking more than once every 25-30 hours.
[17:37] <persia> It may be that the queue gets down by next REVU day, but as you can see, it's currently quite large, so it may be a while.
[17:38] <tuxmaniac> Piratenaapje: the other way round could also be ping someone you know and request (politely) for a review when free. I have been waiting forone package of mine since last Ubuntu dev cycle :-P
[17:39] <Piratenaapje> Well, it isn't that urgent, I'm just hoping I can get it in before the freeze.
[17:39] <tuxmaniac> Piratenaapje: and also I tell you this becuase you would wait for say 2 weeks and then the reviewer gives you a big list of review points
[17:40] <Piratenaapje> tuxmaniac: I've filed a bug request for someone to package it about a year ago. Still no response, so I decided to do it myself :p. So I'm not really in a hurry ;).
[17:40] <tuxmaniac> Piratenaapje: by the time you fix it freeze would be in place. Also since 2 advocacies are needed you might end up waiting (mostly) for the next dev cycle. So ping someone you know politely and get it done ;)
[17:41] <tuxmaniac> Piratenaapje: revu link?
[17:41] <Piratenaapje> tuxmaniac: I don't know any MOTU's, so no luck there ;)
[17:41] <Piratenaapje> http://revu.ubuntuwire.com/details.py?package=grnotify
[17:46] <persia> Piratenaapje, There are bunches of MOTU in this channel.  Also, never turn down an offer for a review, even from someone who isn't MOTU: just having another pair of eyes on something can help a lot.
[17:47] <Piratenaapje> Well, if anyone has the time to review it, feel free to ;)
[17:50] <Turl> ScottK: it's fixed, https://bugs.launchpad.net/bugs/250973
[17:50] <ScottK> Turl: Great.  I don't have time/focus for a proper review now, but someone will get to it.
[17:50] <Turl> ok :)
[17:53] <Chris`> Did Norbert come in here this morning?
[17:55] <frith> hello does anyone here know if i can set gcc search dirs per user?   gcc -print-search-dirs
[17:55] <frith> so that would include my custom dir
[18:16] <loic-m> When writing a .desktop file, can I just use full path for the icon or is this frowned upon?
[18:20] <Webspot> If there is an MOTU avaliable, would they be able to review the changes I've made to osm-gps-map on REVU: http://revu.ubuntuwire.com/details.py?package=osm-gps-map Thanks.
[18:25] <AnAnt> Hello, I am working on a package that is mainly LGPL+BSD. But there is a perl script included with this package (which is NOT linked against anything else), is there a problem with this ?
[18:27] <Laney> AnAnt: Just put its license info in debian/copyrithg
[18:27] <AnAnt> Laney: thanks
[18:28] <Laney> (spelt correctly, of course)
[18:33] <dooooomi> if someone feels like reviewing a python extension module: http://revu.ubuntuwire.com/details.py?package=pyliblo
[18:38] <persia> loic-m, please use only the bare name.  No path, no extension.
[18:46] <loic-m> persia: thanks
[18:52] <loic-m> persia: my desktop file passes validation, and I know I've got to use dh_desktop to install it, but I've read the complete packaging guide + man and still have questions
[18:53] <loic-m> persia: the guide says I've got to use dh_desktop in binary, but binary only has this: binary:	binary-clean binary-indep binary-arch
[18:53] <loic-m> since dh_menus is in binary-arch, shouldn't dh_desktop be there too?
[18:54] <loic-m> Also, is the .desktop file name just ".desktop" or "name-of-pkg.desktop"?
[19:11] <persia> loic-m, dh_desktop doesn't install the desktop file: you'll need to do that with dh_install
[19:11] <persia> Since dh_desktop can't rename files, use ${package}.desktop
[19:12] <DktrKranz> persia, are you one of the ubuntuwire admins? rcbugs could be restarted at this point.
[19:13] <DktrKranz> (or pointed to the correct release)
[19:13] <persia> DktrKranz, I'm not.  I'm only an ubuntuwire website editor (I can change the list of tools, but not do anything with the tools).
[19:15] <DktrKranz> wgrant, please read above when you catch up, thanks ;)
[19:26] <CarlFK> http://packages.ubuntu.com/jaunty/amd64/ffmpeg2theora/filelist is missing ... basically everything
[19:36] <afflux> CarlFK: bug 315356
[19:36] <CarlFK> thanks.  been meaning to search for that
[19:40] <CarlFK> should this be this: DEB_MAKE_INSTALL_TARGET := install PREFIX=prefix=\$\(DEB_DESTDIR\)usr
[19:40] <CarlFK> it works, but it makes me think something isn't quite right
[19:41] <CarlFK> this part: PREFIX=prefix=
[19:53] <afflux> CarlFK: are you still at ffmpeg2theora? That doesn't work for me.
[19:56] <afflux> CarlFK: the makefile does not pass the prefix variable to scons (which is used for building, the makefile seems to be only for compatability), so scons tries to install to /usr/local instead of DEB_DESTDIR
[19:57] <CarlFK> afflux: I hacked together what is needed to make it work
[19:58] <CarlFK> with trunk, which includes an updated Makefile (I got head to add that so my hack didn't have to patch Makefile, which was giving me a headache :)
[19:58] <afflux> ah, I see.
[19:58] <CarlFK> check the bugreport, I just dumped my script
[19:59] <CarlFK> i sent a nice post to the deb maintainer, and got a generic "please follow the procedures at bugs.debian.org
[19:59] <CarlFK> went there, couldn't figure out what to do, gave up
[19:59] <Laney> CarlFK: Run reportbug -B debian
[20:00] <CarlFK> Laney: in any particular dir?
[20:00] <Laney> It'll just let you type in a bug report
[20:02] <afflux> CarlFK: a debdiff is in generall far more useful than a script using echo and sed. my solution for this bug, however, would be just adding the "common-install-impl:: scons install destdir=$(DEB_DESTDIR)" target to debian/rules.
[20:03] <CarlFK> that seems better
[20:03] <afflux> CarlFK: note that that's a newline after ::
[20:04] <CarlFK> I figured someone would improve on what I did.  it was more proof that 'it doesn't take much'
[20:04] <CarlFK> afflux: I have it working for me.  run reportbug :)
[20:06] <afflux> CarlFK: you mean me?
[20:11] <CarlFK> afflux: yes.  I am just passing on the advice I was given when I tried to offer what was needed to make it work
[20:11] <afflux> CarlFK: ok. Why do you think this should go to debian? They seem to be using an older, unaffected version.
[20:13] <CarlFK> afflux: who said I was thinking?  I have 0.0 clue who to tell what.
[20:13] <afflux> ah ok ;)
[20:13] <Laney> Can someone advise me on what to do here: http://paste.ubuntu.com/109083/
[20:13] <Laney> is adding -fPIC to AM_CPPFLAGS in Makefile.am right?
[20:24] <hyperair> mok0: ping
[20:30] <Laney> (or should I not care?)
[20:32] <mok0> hyperair: pong
[20:34] <hyperair> mok0: regarding sigx, i've fixed the issues you mentioned in your comments. could you take a look?
[20:35] <mok0> hyperair: yes
[20:35] <hyperair> mok0: thanks
[20:35] <mok0> hyperair: don't thank me yet :-}
[20:36] <hyperair> mok0: =p
[20:41] <afflux> CarlFK: patch added to the bug, waiting for sponsoring.
[20:43] <emet> how can I go and request Qt Creator be packaged?
[20:45] <afflux> emet: no need, someone did that before you: bug 309880
[20:46] <Laney> grargh
[20:46]  * Laney kills ghc
[20:53] <hyperair> Laney: i've uploaded bansheelyricsplugin to mentors.debian.net like you suggested =p
[20:53] <Laney> hyperair: I'd take it to #debian-mono
[20:54] <hyperair> Laney: on which server?
[20:54] <Laney> oftc
[20:54] <hyperair> ah
[20:57] <mok0> hyperair: Have commented, 2 small things
[20:57] <hyperair> mok0: ah thanks. but regarding doc-base, are you sure it's not already hooked up?
[20:58] <hyperair> mok0: see debian/libsigx-2.0-doc.doc-base
[20:58] <mok0> Sorry I missed that one!
[20:59]  * mok0 kicks self
[20:59] <hyperair> hahaha
[21:02] <mok0> hyperair, are you prepared to help with work on packages that are not your own?
[21:02] <hyperair> mok0: why not
[21:03] <hyperair> mok0: what brought that up?
[21:03] <hyperair> mok0: and by the way, i've just uploaded sigx again, with the change done to debian/copyright as per your comment
[21:03] <mok0> hyperair: you need it if you want to go for motuship
[21:04] <mok0> hyperair: great
[21:04] <hyperair> hmm motuship eh
[21:05] <hyperair> should i apply?
[21:05] <mok0> hyperair: you need a portefolio of bug fixes, merges, syncs etc.
[21:06] <hyperair> merges and syncs eh? i've never done any of those
[21:07] <mok0> hyperair: they are a vital part of the workflow
[21:07] <Laney> they are our bread and butter
[21:07] <hyperair> hm
[21:07] <hyperair> i'll go poking around for details of those then
[21:08] <mok0> hyperair: there aren't many merges left
[21:08] <mok0> hyperair:  you know DaD?
[21:09] <hyperair> mok0: never heard of it
[21:09] <mok0> http://dad.dunnewind.net/universe.php
[21:09] <mok0> It the one most motus prefer
[21:10] <mok0> hyperair: we also have mom: http://merges.ubuntu.com/universe.html
[21:11] <mok0> Mom has a nice graphics thing at the bottom
[21:11] <hyperair> i see
[21:11] <hyperair> so between dad and mom which is preferred?
[21:11] <mok0> hm, it looks like merges are going up lately
[21:11] <mok0> ah, no those are syncs actually
[21:12] <hyperair> come to think of it i know nuts about merging/syncing. how does a non-motu submit a merge/sync anyway?
[21:13] <mok0> hyperair: many like Dad, because you can leave a small comment there
[21:13] <mok0> hyperair: you file a bug at launchpad, and attach a debdiff
[21:14] <hyperair> i see
[21:15] <hyperair> does launchpad keep track of whatever you've done, or do you have to dig through old archived mail for it?
[21:15] <mok0> syncs are unmodified Debian packages, but we need people to check that the changes do not introduce regressions and that they are generally safe
[21:15] <hyperair> mok0: would debdiffs still be required for syncs?
[21:15] <mok0> So for a sync, you make a small report on a LP bug
[21:15] <hyperair> ah
[21:16] <mok0> hyperair: no debdiffs for syncs, only excerpts of changelogs
[21:16] <hyperair> i see
[21:16] <mok0> hyperair: there are some guides on how to do it
[21:16] <hyperair> when are merges needed?
[21:16] <mok0> hyperair: when a Debian package has been modified in an Ubuntu specific way
[21:17] <mok0> hyperair: some things are different in Ubuntu, so some packages need to be modified
[21:17] <mok0> When a new version appears at Debian, you need to merge those modifications to the new version of the package
[21:18] <mok0> ... and then we add a "ubuntu1" tag to the package release string
[21:18] <hyperair> ah
[21:18] <hyperair> right
[21:19] <mok0> Mom & Dad can automatically do most of the merging
[21:19] <mok0> but some conflicts often remain, and they need to be resolved by hand
[21:20] <mok0> There is a script called "grab-merge", but beware it deletes the cwd. I removed that line from the script
[21:20] <hyperair> i see
[21:21] <hyperair> so must a package be listed on mom in order for grab-merge.sh to work?
[21:22] <mok0> Let's see... I use the Dad script, will just check Mom's
[21:22] <hyperair> dad script eh
[21:23] <mok0> yeah, mom doesn't have one it seems
[21:23] <hyperair> eh? it doesn't?
[21:23] <Webspot> Are there any MOTUs available to review changes I've made to my REVU package, osm-gps-map? Thanks. http://revu.ubuntuwire.com/details.py?package=osm-gps-map
[21:23] <hyperair> i thought the one listed here.. https://wiki.ubuntu.com/UbuntuDevelopment/Merging is mom's
[21:24] <mok0> hyperair: anyway, it's good etiquette just to check with the last person who merged
[21:24] <hyperair> mok0: check that the last person doesn't have plans for it?
[21:27] <mok0> hyperair: exactly
[21:30] <hyperair> mok0: ah i see
[21:30] <tdomhan> how long are the delays after packages appear on mom/dad after a newer version of a package was released in the debian repos?
[21:31] <mok0> tdomhan: not sure. I think the script runs at least once aday
[21:32] <hyperair> mok0: thanks for the advocate
[21:32] <hyperair> mok0: and the advice
[21:33]  * hyperair needs to head to bed now *yawn*
[21:38] <mok0> g'night hyperair
[21:38] <hyperair> mok0: g'night
[21:40] <Webspot> I've got another package I've just made today - pyofa - It's a python module for libofa, which makes audio fingerprints. If there's an MOTU available, could they look at this too: http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :)
[21:47] <fransman> mok0: does it looks into the debian experimental as well?
[21:48] <fransman> talking about bug #320607
[21:55] <loic-m> From what I've read, Debian uses menu files while Ubuntu uses .desktop files for including an application in the desktop (Gnome/KDE/Xfce) menus
[21:55] <loic-m> Is it correct?
[21:56] <Piratenaapje> Someone told me the .orig.tar.gz should have a different name then the folder name. Is this true? And if so, what should I call the folder or .orig file?
[21:57] <loic-m> Piratenaapje: folder name has a - where .orig.tar.gz has a _ for separating app name and version numbers
[21:57] <mok0> loic-m: yes
[21:57] <Piratenaapje> loic-m Ah thanks, I already somehow fixed that without knowing :s
[21:58] <loic-m> mok0: so if an app synced from Debian doesn't have a desktop file, what do Debian devs prefer - that we submit the .desktop file + rules patch to them or just patch the package when it arrives in Ubuntu?
[21:59] <loic-m> s/desktop/.desktop/
[21:59] <mok0> loic-m: heh, good question. The best for us is of course if the Debian maintainer puts the .desktop entry in the package.
[22:00] <mok0> loic-m: but we do carry many merges that are basically only the addition of a .desktop file
[22:00] <loic-m> mok0: and the lines in debian/rules no? Can they do that if they don't use the .desktop file (=it will install it on Debian systems too)
[22:00] <tobi_> is it only a sync if you drop the ubuntu changes of a, until then, merged package? Or if a package that was synced before gets updated in debian, and this version shall be used in ubuntu, too, is that a sync too?
[22:02] <mok0> loic-m: I am not sure what the Debian policy on .desktop entries are... if they actively disencourage it
[22:02] <mok0> tobi_:  yes it's always a sync if the package is unmodified
[22:02] <tobi_> ok thx
[22:03] <mok0> tobi_: but after the Debian Import Freeze, every sync needs to be argued for and tested
[22:07] <loic-m> mok0: I might just email the Debian maintainer then, but if I file a bug in Debian do I just add the .desktop file, or a diff bw the diff.gz?
[22:13] <coppro> apt-get usage quqestion: I'd like to stop using packages from a specific PPA. Is there a quick command to, once I've removed it from my sources.list, downgrade all the packages to the repo versions?
[22:14] <tobi_> mok0: what are good reasons for a sync? bug fixes/features?
[22:20] <mok0> tobi_: yes. Bug fixes are important.
[22:22] <mok0> tobi_: often people paste excerpts of the changelog to document upstream's work
[22:27] <mok0> tobi_: https://wiki.ubuntu.com/SyncRequestProcess
[22:35]  * RainCT hugs VirtualBox
[22:52] <jdong> `.
[22:55]  * RainCT watches jdong 
[22:56] <jdong> oh don't worry at the success I'm having with WDS/802.11N, you'll see some mangled ^A's too.
[23:26] <maco> does motu handle multiverse too?
[23:28] <jdong> yrd
[23:28] <jdong> err, that's one-handed yes.
[23:29] <maco> haha
[23:29] <maco> ok
[23:29] <maco> is sun-java6-jre broken in hardy?
[23:30] <maco> i got a call from a 9 year old asking why her laptop wont update. it's giving her this error "E: I wasn't able to locate a file for the sun-java6-jre package. This might mean you need to manually fix this package. (due to missing arch)"
[23:30] <SherokiX> good night
[23:31] <jdong> I could've sworn I just brought a hardy system (with Java) up to date this afternoon
[23:31] <jdong> I would be more suspect of local breakage
[23:34] <maco> er ok...