[00:25] <porthose> DktrKranz, ping! The link I mailed you is now good.  Shortly after I sent that mail to you my cable modem went up in a ball of flames :(
[02:28] <ScottK> porthose: Is it on youtube?
[02:33] <porthose> ScottK, na didn't have time to grab my phone was to busy putting the fire out :)
[02:34] <ajmitch> get your priorities right next time please
[02:34] <porthose> hahaha
[07:45] <dholbach> good morning
[07:57] <DktrKranz> porthose: oki thanks, I'll have a look as soon as my email client quits to bother me :)
[10:29] <eric_> Is there someone who could review my program? http://revu.ubuntuwire.com/details.py?package=cortina
[12:27] <shadeslayer> hi small question,when signing files gpg agent doesnt seem to be running,any ideas on how to fix this? Im using kubuntu
[12:43] <ScottK> shadeslayer: Look in your .gnupg directory at the gpg conf file and make sure "use-agent" is present and not commented out.
[12:44] <shadeslayer> ScottK: its there :)
[12:44] <shadeslayer> ScottK: the problem is that it doesnt detect any user-agent
[12:44] <ScottK> That should be sufficient from a configuration perspective.  I'm not sure then.
[13:11] <xteejx> Afternoon all.
[13:15] <xteejx> How long does it take a merge to be looked at? (in general I mean I'm not in a rush)
[13:16] <shadeslayer> xteejx: well you could ask someone here to look at it it
[13:17] <xteejx> Oh cool Ok then it's bug 592622...please be nice it's the first one I've done on my own ;) hehe
[13:17] <xteejx> mutliverse? Doh!
[13:32] <jariq> What do you think about packages generated with cpack (module of cmake) ? Does anyone use it to generate packages ?
[13:37] <shadeslayer> hi is there a example of a transitional package i can study?
[13:40] <Rhonda> shadeslayer: Just make an empty package (no debian/package.install file or similar) which has a Depends on the new package and contains as sole entry a symlink for the copyright file
[13:41] <Rhonda> erm, s/copyright file/doc directory/
[13:41] <shadeslayer> Rhonda: i was reading this : http://baraujo.net/blog/?p=17
[13:43] <shadeslayer> Rhonda: is that ok?
[13:44] <Rhonda> Is one way to do it. Looks like the transitional package will end up with all the docs in it, too. And Arch: any is just wrong, it should be Arch: all
[13:44] <shadeslayer> Rhonda: btw can i place the entry anywhere in the control file,or should they be back to back?
[13:45] <shadeslayer> Rhonda: ah ok
[13:45] <Rhonda> You can put them anywhere, but putting them last is a good idea.
[13:45] <Rhonda> There is special casing for the first binary package stanca, appart from that there is nothing special.
[13:46] <Rhonda> So ordering does only matter for the first two entrys: Source, and first Package.
[13:47] <shadeslayer> ah...
[14:01] <shadeslayer> Rhonda: btw for maverick,in the changelog i write unstable or unreleased
[14:07] <Rhonda> shadeslayer: Erm, definitely not unreleased. I think unstable is proper for maverick, but then I'm not a Ubuntu dev yet. :)
[14:07] <shadeslayer> :)
[14:07] <shadeslayer> Rhonda: i went with UNRELEASED
[14:08] <Rhonda> I would expect that to get rejected when being uploaded.
[14:08] <shadeslayer> somebody answered in #kubuntu-devel :)
[14:08] <shadeslayer> Rhonda: oh im uploading to bzr
[14:08] <Rhonda> That's pushing, not uploading. ;)
[14:08] <shadeslayer> then will request a merge with the kubuntu-members branch...
[14:08] <shadeslayer> bzr is not co-operating right now :P
[14:13] <ScottK> Rhonda: FYI, we put the actual release name in debian/changelog, so if he had been uploading, maverick would be correct.
[14:54] <xelister> I would like to debug kmail in lucid-proposed, but it seems there are no -dbgsym's for lucid-proposed?
[14:55] <xelister> how to by hand build and install needed -dbgsym for kmail...? will it be 100% compatible with lucid-proposed's kmail (so I can get information about a crash that already occured on the PPA installed kmail from lucid-proposed)?
[15:29] <shadeslayer> hi anyone working on https://merges.ubuntu.com/d/derivations/REPORT ?
[15:29] <shadeslayer> if not id like to take it up
[15:31]  * shadeslayer wonders how the same version is already in the repo
[15:31] <shadeslayer> !merge
[15:32] <xteejx> How long does it normally take once sponsors have been subscribed to a merge for them to take a look at it? (In my case it's only been 2 hours and I'm not complaining :))
[15:38] <shadeslayer> xteejx: got a sec?
[15:38] <xteejx> shadeslayer: Sure
[15:38] <shadeslayer> xteejx: can you teach me how to merge a package? like the basic overview
[15:38] <shadeslayer> i cant really follow the wiki
[15:39] <shadeslayer> i know packaging,but merges look different :)
[15:39] <xteejx> shadeslayer: I'm probably not the best person to ask I'm only learning myself everything MOTU related and merging is my first kinda motu thing lol
[15:39] <xteejx> yeah the wiki was hard for me to follow too
[15:40] <xteejx> I can *try* and explain it as I know it, I've done 2 merges so far
[15:40] <shadeslayer> xteejx: yeah sure
[15:40] <shadeslayer> xteejx: you can use the merges youve done as examples
[15:43] <xteejx> shadeslayer: The basics of it is, you use the grab-merge script on the wiki to grab the packages, i.e. the base, debian and current ubuntu packages, then read the REPORT and change/fix what it says, update the changelog, debuild -S it to build a source package, try to build it in pbuilder and if all is fine and works, debdiff the differences between the debian.dsc & new-ubuntu.dsc and also old-ubuntu.dsc & new-ubuntu.dsc
[15:43] <xteejx> Hope that gives some help, that's how I understand it
[15:45] <shadeslayer> xteejx: ok and how do i use the script?
[15:45] <xteejx> download it to where you want to build and sh ./grab-merge/.sh
[15:45] <xteejx> .sh
[15:45] <shadeslayer> xteejx: ohh...
[15:46] <shadeslayer> xteejx: but you just said,that grab the merge script to grap the packages.. how do i do that?
[15:46] <xteejx> use the script to do it
[15:47] <BlackZ> shadeslayer: have you read https://wiki.ubuntu.com/UbuntuDevelopment/Merging ?
[15:47] <shadeslayer> BlackZ: i am reading that,but i cant understand how to use the script
[15:47] <xteejx> download it
[15:47] <xteejx> use it
[15:48] <BlackZ> shadeslayer: man grab-merge and read the section "DESCRIPTION"
[15:48] <shadeslayer> ah
[15:48] <BlackZ> I think you will understand
[15:48] <xteejx> BlackZ: Is grab-merge in the repos??
[15:49] <shadeslayer> yep
[15:49] <xteejx> bloody hell there's me using the script haha :D
[15:49] <BlackZ> xteejx: yes, it's included in the ubuntu-dev-tools package
[15:49] <xteejx> sudo apt-get install grab-merge
[15:49] <xteejx> oops wrong window ;)
[15:49] <BlackZ> there's no need to do that
[15:49] <BlackZ> just sudo apt-get install ubuntu-dev-tools
[15:50] <shadeslayer> ahh i see thats how you use it :D
[15:50] <xteejx> I have that installed, so I must already have it and not noticed hehe
[15:50] <BlackZ> if you already have it, so you have grab-merge too
[15:50] <shadeslayer> grab-merge webkitkde :P
[15:50] <BlackZ> -so
[15:50] <xteejx> BlackZ: Thanks, didn't know we had it in repo hehe
[15:52] <xteejx> I think my last merge went well, debuild and pbuilder worked perfectly, updated changelog and edited the control file
[15:53] <BlackZ> xteejx: oh, is it uploaded?
[15:54] <xteejx> no have subscribed sponsors, awaiting a look
[15:54] <xteejx> bug 592622
[15:54] <BlackZ> ah, then just wait :)
[15:55] <xteejx> What are the difference between the light/dark green merges?
[15:57] <geser> different value in the Priority field of the package
[15:58] <xteejx> ahhh :) thanks geser makes sense now
[18:09] <nisshh> hey, id like to get my app into the ubuntu repos, didrocks told me id have to get it uploaded by a MOTU, can someone help me out?
[18:10] <didrocks> nisshh: you should go to the REVU process (https://wiki.ubuntu.com/MOTU/Packages/REVU)
[18:10] <nisshh> didrocks: yea i was just looking at that
[18:31] <fabrice_sp> When happened the last sync of new packages from Debian? I'm trying to see is invalidating bug 589156 or not
[18:32] <fabrice_sp> it seems that all this packages has been accepted on the 30th of May in Unstable
[21:04] <ndemir> Hello. I am trying to understand the process of the packages for universe. I am looking packages in REVU and i can see packages that is not added to universe althoug it is in REVU for years. For example; here is a packaging wish for cdemu from 2007: https://bugs.launchpad.net/ubuntu/+bug/105452 I saw that one of the answers to this wish is from the developer of cdemu. He created cdemu deb package and uploaded it to REVU and PPA. But it is still not in un
[21:05] <ndemir> 105452
[21:06] <ndemir>  https://bugs.launchpad.net/ubuntu/+bug/105452
[21:06] <ndemir> any answer?
[21:08] <tumbleweed> ndemir: it takes some effort to get a package into Ubuntu. If the packager loses interest tehn someone else needs to do it
[21:08] <ndemir> but it has been 3 years since the bug has been opened.
[21:08] <ndemir> this is not about interest.
[21:09] <ndemir> tumbleweed
[21:09] <tumbleweed> ndemir: there are many bugs that have been opened that long. But not enough manpower to deal with them
[21:09] <tumbleweed> if you want to get involved, wiki.ubuntu.com/Bugs
[21:13] <ndemir> tumbleweed: yes i want to get involved but first of all i want to understand the process. and it seems really interesting to me that the developer of an application creates a package for ubuntu nearly two years ago, but this package is still not in universe.
[21:13] <ndemir> as i said, this is one of the similar situations.
[21:13] <tumbleweed> ndemir: the way the process usually works, is:
[21:14] <tumbleweed> the package gets maintained by someone in Debian, and gets pulled into Ubuntu
[21:15] <tumbleweed> it's often not the developer of the application that maintains it
[21:16] <tumbleweed> getting something into Debian isn't a once-off drive-by process - it needs someone who'll package future versions and deal with bugs
[21:16] <ScottK> ndemir: We possibly have the manpower to review ~10% of the submissions we get properly.
[21:16] <tumbleweed> packages can off course be maintained directly in Ubuntu, but that's rarer
[21:18] <ndemir> ScottK, tumbleweed: i think now i understand the way you follow. Rather than maintaining the package directly in Ubuntu, you choose the way to get the package from Debian.
[21:18] <ScottK> ndemir: If you have a focused interest in a package, that's usually better.
[21:20] <tumbleweed> ndemir: maintainers in Debian look after their own packages. In Ubuntu almost all packages are maintained big a big group of people who don't know the packages they are working on. During each release cycle, we are lucky if a particular package gets looked at once.
[21:24] <ndemir> Scottk, tumbleweed: So it means that it would be better if i would do the same thing. Is there a page that i can learn this process? The process that getting packages from Debian.
[21:24] <tumbleweed> ndemir: this particular package isn't in Debian
[21:26] <ndemir> tumbleweed: sorry. i did not understand.
[21:26] <ScottK> ndemir: Once it's in Debian, we automatically sync up to Debian import freeze and then after that you can request to have new packages sync'ed up until feature freeze.  After that it will wait until the next release cycle
[21:28] <tumbleweed> if you want to maintain cdemu, you can submit it to Debian. There is lots of documentation on that procss here: http://www.debian.org/doc/devel-manuals
[21:34] <ScottK> Also see mentors.debian.net
[21:35] <ndemir> ScottK and tumbleweed: thanks for your information. It seems that if i will maintain a new package i should do it for Debian. if i want to do something about packaging for Ubuntu, i should follow bugs.
[21:37] <tumbleweed> ndemir: packages *can* be maintained in Ubuntu, but if they aren't ubuntu-specific it probably makes a lot more sense to do it in Debian
[21:38] <tumbleweed> you've seen the REVU queue :)
[21:38] <BlackZ> ndemir: the fact is it's better to upload them in debian
[21:38] <BlackZ> it'd have more benefits
[21:38] <BlackZ> and you will get BTW your work in ubuntu, with the sync
[21:38] <tumbleweed> (and Debian is better suited to package maintainance)
[21:39] <BlackZ> ndemir: but if you want to do something for ubuntu try fixing bugs or merging packages (just for example)
[21:39] <tumbleweed> ndemir: there's packaging work to do in Ubuntu too, but it's more to do with fixing problems and syncing new versions over from Debian: wiki.ubuntu.com/MOTU
[21:39] <MTecknology> "Some [proprietary licenses] may be called "free" licenses but have many limitations which you will not be aware of until you are in the middle of a lawsuit." MeThinks_TrueCrypt_License
[21:47] <Rhonda> ScottK: Makes sense when thinking about how you do releases, thanks for the headsup. :)
[21:47] <ScottK> You're welcome.
[22:03] <imbrandon> afternoon all
[22:05] <arand> Hrm, I'm trying to file a debian package update request but I'm not sure if this is proper: http://pastebin.org/325207
[22:09] <tumbleweed> arand: yes (although there is another bug in the merged set of three). Have you tested to see if it does fix them?
[22:09] <tumbleweed> did you see the requests for removal in 471642?
[22:09] <arand> tumbleweed: Yes, and it was removed from testing
[22:11] <tumbleweed> arand: I'd give you bug a title along the lines of "new upstream version (foo) fixes critical bugs"
[22:11] <tumbleweed> (you could also just reply to 471642)
[22:12] <arand> tumbleweed: I have not, hmm, I really should I guess, let's see if just slapping the new version as package-in-package like the old one does work..
[22:54] <carstenh> arand: is there a way to test pango-graphite?
[22:55] <arand> carstenh: I don't know, apart from making sure it doesn prevent all of gnome from starting on login
[22:56] <arand> I'm not even half sure what it's meant to be doing. Only thing I know is that it's a downright nuisance at the moment..
[22:57] <arand> carstenh: It seems like the new version fits in the packaging mold neatly though, it seems...
[22:57] <carstenh> arand: I could just upload it, but I won't upload something I can't test.
[22:58] <carstenh> you need to create a new orig.tar.gz containing the old one ... weird cdbs
[22:59] <arand> Yea, but it doesn't seem to be much besides that in need of doing..
[22:59] <carstenh> by testing I mean that I can see it does something, an empty package would also not cause a broken gdm
[23:00] <carstenh> yes, packaging is easy, checking it the patch still applies must also be done. but someone needs to understand what this thing is supposed to do ;)
[23:00] <carstenh> s/it/if/
[23:00] <arand> afaik, if you install it, along with e.g. ttf-sil-doulos you should see a new font in use by default on the system, if I've understood things correctly...
[23:01] <carstenh> I don't use something you would consider as "desktop environment"
[23:02] <imbrandon> screen ? heh
[23:02] <carstenh> and my default system font is "fixed"
[23:02] <arand> Ah, well that makes things trickier I guess
[23:02] <carstenh> imbrandon: still X, but nothing that looks like kde, gnome oder xfce4
[23:04] <imbrandon> ahh
[23:07] <arand> Right.. so the .orig. is just the proper upstream archive within an archive... :S
[23:08] <carstenh> imbrandon: http://stateful.de/~carsten/tmp/100612OhP4MaAhIHE/screenshot.png nothing special, just no menus or panels ...
[23:09] <arand> No nickcolor in irssi? How on earth do you cope?
[23:14] <jpds> http://spooky.ubuntuwire.com/~jpds/Screenshot.png
[23:16] <carstenh> arand: I already use all my colors in my prompt and if you got a good tft you see also different colored backgrounds ;) http://stateful.de/~carsten/tmp/100612E0lhWJBy8Yg/screenshot.png
[23:39] <carstenh> arand: since this bug is release critical and also very old you can prepare a NMU (that means e.g. you choose -0.1 as debian revision number and you do not touch the packaging unless you really need to) and ask the sponsor to upload it to the delayed queue instead of reporting an additional bug. finding a sponsor who is able to test it does not seem to be easy, but you could at least try it by writing a mail to debian-mentors@lists.debian.org
[23:40] <arand> Ok, so that's like an SRU but for debian?
[23:41] <carstenh> a "Stable Release Update" is an update targeted at the stable release, right?
[23:42] <carstenh> since the package is not in stable it is a bit different, but both have in common that they avoid needless changes
[23:44] <carstenh> a "NonMaintainer Upload" fixes bug when the real maintainer does not have the time to do so but it should not change things that do not need to be changed, that is job of the maintainer
[23:45] <carstenh> arand: http://www.debian.org/doc/developers-reference/pkgs.html#nmu
[23:47] <arand> Hmm, right, I'm not sure a whole new version would pass by those requirement, especially when taken into account how much clue I have about the package's functionality itself..
[23:48] <arand> (zilch)
[23:48] <carstenh> arand: one thing might not be that obvious: using a debian revision number lower than the next maintainer upload would be in combination with uploading to the delayed queue is done to give the maintainer some time to upload his package, in this case the debian archive software throws your version away
[23:49] <arand> But I'm building the new version on my maverick test machine now though, at least I can check i the bug apperas to have gone away..
[23:49] <carstenh> arand: a whole new version is perfectly ok if nobody is willing to backport the fix, the requirements are less strict that when you do a SRU
[23:50] <arand> carstenh: Ah, ok, well the package seems to have fallen somewhat out of maintenance as far as I can tell by the debian bug report..
[23:51] <carstenh> arand: you need to build in a sid chroot (or pbuilder) and also upload the binary to the webspace you use to publish the package, debian does not use source-only uploads
[23:51] <tumbleweed> arand: sounds like the lack of maintainance is upstream, not in debian. It's worth trying to get the DD to upload the new version before doing so in ubuntu
[23:52] <arand> carstenh: Is that just a matter of "pbuilder-dist sid --create"?
[23:52] <carstenh> tumbleweed: that's what he tries to (NMU)
[23:54] <carstenh> ok, "the" DD ... he has still a chance to upload it before the NMU would move from delayed to the archive
[23:54] <tumbleweed> NMUing new versions isn't really done, though
[23:54] <carstenh> arand: i guess so, if pbuilder-dist lucid --create would be the correct command for lucid
[23:55] <arand> carstenh: Ah, but I thought I had to use a sid chroot, no? I'm already using pbuilder for all my building otherwise)
[23:56] <carstenh> tumbleweed: this bug is from 2008 and the new upstream version is from 2009. i don't see why one should wait longer and I already did NMUs for new versions
[23:56] <tumbleweed> actually he does look very inactive
[23:56] <carstenh> arand: pbuilder is a kind of a chroot
[23:57] <carstenh> tumbleweed: one could argue if the package should be orphaned
[23:58] <tumbleweed> carstenh: yeah, new versions are QA uploads, not orphaning
[23:58] <tumbleweed> unfortunatly the orphaning process is slow
[23:59] <carstenh> tumbleweed: there is even an example of a -0.1 NMU in the developers reference
[23:59] <carstenh> | If a new upstream version is packaged in the NMU, the Debian revision is set to 0, for example 1.6-0.1.
[23:59] <tumbleweed> yes