[00:00]  * nhandler only reviewed a few packages
[00:00] <mok0> Now, if all MOTUs would just take 1 every day...
[00:01] <mok0> We'd be back on track over the weekend...
[00:01] <mok0> "Back on track" meaning that people would get their upload reviewed within a week
[00:01] <handschuh> mok0: how many active MOTUs are on revu?
[00:02]  * slytherin is still waiting for REVU hackers to implement tagging system
[00:02] <nhandler> handschuh: Based on the stats page, not many (http://revu.ubuntuwire.com/stats.py)
[00:02] <mok0> handschuh: Hard to say... maybe around 10
[00:03] <nhandler> The Top Advocators list hasn't even been filled yet
[00:03] <mok0> Some of the people in top 15 aren't MOTUs
[00:03] <handschuh> mok0: ok ... do MOTUs loose their MOTU status sometimes?
[00:03] <nhandler> handschuh: I believe it expires every few months
[00:03] <mok0> handschuh: If they don't renew it
[00:04] <handschuh> mok0: good to know, thanks
[00:05] <mok0> handschuh: If you look at https://edge.launchpad.net/~motu/+members you can see that quite a few have their membership expire
[00:05] <mok0> handschuh: perhaps some of them have moved on the main developers
[00:07] <emgent> heya
[01:08] <james_w> thanks freeflying
[01:09] <james_w> lfaraone: hi, still around?
[01:27] <freeflying> james_w: hi
[01:28] <freeflying> james_w: u r welcome
[01:29] <james_w> freeflying: I knew I had seen your name somewhere related to this, but I forgot it was you that wrote the file originally :-)
[01:31] <freeflying> james_w: btw, I will upload a svn sanpshot of new fcitx to ubuntu later
[01:31] <james_w> freeflying: shall I refrain from syncing that fixed Debian version then?
[01:33] <freeflying> james_w: I will based on the version in Debian :)
[01:33] <james_w> cool, less work for me :-)
[01:40] <lfaraone> james_w: yes
[01:40] <james_w> hi lfaraone
[01:40] <james_w> how are you?
[01:41] <lfaraone> james_w: fine, thanks.
[01:41] <lfaraone> james_w: I was working on a new package, and was wondering if bzr-builddeb is safe enough for a packaging newbie.
[01:42] <james_w> should be
[01:43] <lfaraone> james_w: kk.
[02:15] <Leon_Nardella> MOTU sponsors ack for sync. <-- What does this mean in a bug report?
[02:22] <james_w> Leon_Nardella: if someone who does not yet have upload rights request that we pull an updated package from Debian a developer must first confirm the request before it is processed, so that we make sure that it won't cause problems
[02:23] <james_w> the act of confirming it is known as "sponsoring", and so that comment means that a developer is happy for the sync to take place
[02:24] <Leon_Nardella> Thanks, james_w
[02:51] <lfaraone> james_w: I've looked at the bzr-builddeb docs, and I'm wondering how I'd import from an upstream bzr tree.
[02:52] <james_w> why would you import?
[02:52] <james_w> if upstream is in bzr then branch to add the packaging
[02:52] <persia> Or merge if you've already history
[02:53] <persia> Same thing ought work for git, hg, svn, etc.
[02:53] <lfaraone> james_w: well, ideally I'd like to not have my repo version the upstream code, since I won't be touching that.
[02:54] <nhandler> REVU is no longer being used for new upstream releases, correct?
[02:54] <james_w> this was something expressed in the Kubuntu meeting the other day as well
[02:54] <NCommander> hey persia
[02:54] <james_w> if you are going to use a distributed VCS, which is great at merging by definition, why would you then layer a patch system on top, which is not going to be as good at merging?
[02:55] <ScottK-laptop> james_w: Because we're a Debian derivative and they use patch systems mostly.
[02:55] <james_w> if you are not going to patch the upstream source at all then that's obviously not a very convincing argument
[02:55] <james_w> ScottK-laptop: true, and that argument I appreciate.
[02:55] <ScottK-laptop> In the case of KDE, not using a patch system would make coordination with Debian substiantially harder.
[02:56] <james_w> ScottK-laptop: mentioning Kubuntu probably wasn't wise, this is a new package.
[02:56] <ScottK-laptop> Also there are performance reasons.
[02:56] <lfaraone> james_w: this is a new package that I am targeting for ubuntu, but am going to submit to debian.
[02:56] <james_w> lfaraone: yeah, but you'll be the maintainer in Debian I assume, so there's no problem with that part.
[02:56] <ScottK-laptop> wget the tarball then then play with the debian dir in the VCS is a lot faster.
[02:57] <lfaraone> ScottK-laptop: see... that's the problem, there is no real "tarball"... as this is a "BZR release"
[02:57] <james_w> ScottK-laptop: if the upstream is in bzr then performance is going to be ok for this package. I accept your point in general.
[02:57] <ScottK-laptop> Ah.
[02:58] <ScottK-laptop> So what's a bzr release?
[02:58] <james_w> presumably not really a release at all
[02:58] <lfaraone> ScottK-laptop: it's a "here's the code we've written, we havn't really 'released' it yet, but it's OK to use"
[02:59] <ScottK-laptop> As james_w says then.
[02:59] <ScottK-laptop> pre-release snapshot.
[02:59] <jdong> eesh nothing more painful than fixing Debian over the phone with the fols :)
[02:59] <jdong> folks*
[03:00] <nhandler> REVU is no longer being used for new upstream releases, correct?
[03:00] <ScottK-laptop> jdong: You could be fixing Vista.  That's probably more painful.
[03:00] <jdong> I did find a good use for Skype as a remote desktop type program :)
[03:00] <ScottK-laptop> nhandler: Generally, yes.
[03:00] <jdong> "Alright now point the webcam at the monitor..."
[03:00] <persia> nhandler, Wasn't ever intentionally
[03:00] <nhandler> persia: Wiki pages used to tell people to use REVU for new upstream releases
[03:00] <jdong> and it turned out to be the 180-day e2fsck on the main storage drive with is 1.5TB
[03:01] <jdong> any guesses how many decades that'll take?
[03:01] <persia> james_w, ScottK: Note that this argument isn't about bzr vs. others, it applies generally to VCS packaging.  There are two ways to do it: either include upstream source or don't.  Both have drawbacks of various sorts, and both have advantages.
[03:01] <ScottK-laptop> persia: Agreed.
[03:02] <persia> nhandler, Please fix that.  They aren't correct.  People should add the .diff.gz to a bug.
[03:02] <nhandler> persia: Most of them have already been patched. I just wanted to confirm this before I commented on a certain package on REVU which is for a new upstream release
[03:03] <ScottK-laptop> james_w: Is someone working on making bzr work with python 2.6?
[03:04] <james_w> ScottK-laptop: yes
[03:04] <james_w> ScottK-laptop: I believe it is compatible
[03:04] <ScottK-laptop> james_w: OK.  It has some from __future__ import stuff in it.
[03:04] <ScottK-laptop> That means it needs checking.  As long as someone is doing it.
[03:05] <james_w> or rather I should say, "it is compatible". However, we have had a couple of bugs since that point due to things being missed
[03:05] <james_w> it seems python2.6 removed a couple of things without deprecation, though they may of course be considered internal
[03:05] <ScottK-laptop> We're going to have 2.6 in Jaunty (not as default I'd expect), so ...
[03:05] <ScottK-laptop> Lovely.
[03:05] <james_w> I haven't seen the __future__ stuff though, I'll take a look, thanks.
[03:06] <nhandler> persia: Upon closer examination of the package, they are actually renaming it from 'foo' to 'foo-x.y' to allow multiple versions to be installed at the same time.
[03:06] <ScottK-laptop> wgrant just grepped the entire archive's python packages for me and that's one that came up.
[03:06] <ScottK-laptop> nhandler: Doesn't need to go on REVU.
[03:06] <james_w> from __future__ import generators
[03:06] <ScottK-laptop> There you go.
[03:06] <james_w> it's in the embedded configobj
[03:06] <nhandler> Thanks ScottK-laptop.
[03:07] <james_w> ScottK-laptop: happen to know off hand what will happen with that one?
[03:07] <ScottK-laptop> james_w: No.  I've been avoiding the topic (2.6) up to now.
[03:08] <james_w> ScottK-laptop: ok, thanks. I'll file a bug.
[03:10] <wgrant> Hmm.
[03:11] <wgrant> I doubt that needs a change...
[03:11] <wgrant> Because generators have been available by default since at least 2.5, and probably 2.4 too.
[03:12] <lfaraone> Hey, in my python debian package the setup.py is located in $BASEOFPACKAGE/gasp/setup.py, rather than where it would normally. How do I tell CDBS that?
[03:12] <ScottK-laptop> lfaraone: If you grab pymilter there's a setup.py in a non-standard location in that package.
[03:14] <lfaraone> ScottK-laptop: thanks
[03:21] <lfaraone> ScottK-laptop: yeah... I looked at it, and am still stumped...
[03:22] <lfaraone> ScottK-laptop: despite the rules I adopted, it still tries to use the default.
[03:22] <ScottK-laptop> lfaraone: Pastebin your debian/rules
[03:24] <james_w> DEB_PYTHON_SETUP_CMD = gasp/setup.py ?
[03:24] <lfaraone> james_w: er... I _just_ figured that out. heh...
[03:25] <CarlFK>  "Package liblame-dev is not available,... following packages replace it:   libmp3lame-dev"   "I've changed the liblame0     library name to libmp3lame0, and some packages are not yet in Lenny, so some     others packages aren't installable" - ﻿http://www.debian-multimedia.org/
[03:25] <CarlFK> how can I work around that?
[03:26] <CarlFK> output from apt-get build-dep transcode ﻿http://dpaste.com/92833
[03:28] <ScottK-laptop> james_w: I just did it with a build rule that said python ./debian/spf-setup.py build - Your way is more CDBS like.
[03:28] <james_w> my way may not even work though :-)
[03:30] <lfaraone> james_w: oh, it works perfectly!
[03:30] <james_w> score!
[03:30] <lfaraone> james_w: (just installed the resulting package, "import gasp" worked properly)
[04:21] <james_w> has anyone encountered d-shlibs before?
[04:21] <james_w> or the d-devlibdeps command provided by it?
[04:29] <serialorder> I have a stupid (read simple) question. On the merge-o-matic status pages there are two different colors of green, what do the different colors mean?
[04:31] <james_w> I believe it is the priority of the package
[04:32] <ScottK> It's to do with how recently it's been merged.  The greener the more recent.
[04:32] <ScottK> I don't understand the exact algorithm though.
[04:40] <james_w> on main: apt-setup -> installer -> red
[04:40] <james_w> apt -> important -> orange-yellow
[04:40] <james_w> at -> standard -> green-yellow
[04:40] <james_w> acpid -> optional -> light green
[04:41] <james_w> ipsec-tools -> extra -> dark green
[04:44] <ScottK-laptop> OK.  That makes sense.
[05:22] <stefanlsd> ScottK: the fix future import for spambayes. I've been through them all, i think there were problem ones that we moved up in the debian version (above __author__ and ___credits___) - there are some that havent moved. Did you just patch to move them higher as a matter of course?
[05:29] <artfwo> Hi! May I ask what is the proper way of packaging software with debian/ included?
[05:30] <stefanlsd> !packaging
[05:31] <artfwo> Well, I want to maintain debian/ directory in my program myself and when I try to build the package from source I get warnings about "native" package
[05:32] <artfwo> The debian mentors FAQ suggests not using native packages for general purposes, so I need an advice on those
[05:33] <stefanlsd> artfwo: Someone may be able to advise better, but i believe its generally discouraged for upstream to maintain /debian
[05:34] <stefanlsd> artfwo: Often something changes on the debian side, and we need to update /debian stuff for multiple packages. If bugs are filed, we cant fix them, etc
[05:34] <artfwo> so, is it better for me to exclude debian/ from the tarball and provide .diff.gz instead?
[05:34] <stefanlsd> artfwo: yes, better
[05:35] <artfwo> ok, thanks for clarifying this :)
[05:35] <stefanlsd> artfwo: http://www.mail-archive.com/debian-mentors@lists.debian.org/msg17466.html       also has a thread about it
[05:37] <artfwo> hmm, I see
[06:49] <slytherin> If I am dropping any previous Ubuntu changes when doing a merge, do I have to mention them in changelog? Or is it sufficient to mention in the bug.
[06:50] <Hobbsee> the latter
[06:50] <Hobbsee> you keep the remaining ubuntu changes in the changelog
[06:51] <slytherin> Hobbsee: thanks
[06:51] <Hobbsee> slytherin: you're welcome
[07:13] <slytherin> geser: persia: Debian's latest lucene2 version uses libdb4.5-java as build dependency. Is it ok to switch to libdb4.7-java?
[09:35] <persia> slytherin: I'm a big fan of dropping older versions of db.  What's the user data migration strategy?
[09:36] <persia> slytherin: The issue is that often different versions of db don't have binary-compatible storage, so depending on how or why it's used, transition can be tricky.
[09:39] <soren> persia: I was under the impression that the db formats were compatible, and the problems only arose when transactions were involved.
[09:39] <soren> Is that not so?
[09:39] <persia> soren, I'm a little hazy on the details.  I thought that some version changes caused larger effects than others.  More than anything, I think it's worth investigation rather than blindly changing the version.
[09:40] <soren> Oh, certainly.
[09:40] <persia> I do know that for some packages, you can change the version without worry, and for others you need to take care.  I have no idea where lucene2 falls on that scale.
[09:41] <soren> https://wiki.ubuntu.com/HardyReducingDuplication agrees that only transactions are a problem.
[09:43] <persia> soren, Thanks for tracking down a resource for that.
[09:43]  * soren tips his hat
[09:44] <persia> slytherin: In the hopes you scan backscroll from irclogs.ubuntu.com: that's the doc you want to check against lucene2 to take your decision.
[09:45] <persia> soren, Do you know if anyone is working to drop those completely, rather than just pushing stuff to universe?
[09:45]  * persia still sees *lots* of libdb* packages in jaunty
[09:46] <soren> persia: Dunno. I think Debian intends to drop them, so we'd better follow suit.
[09:47] <persia> Well, there's a couple archive-admins who scan sync-packages-only-in-Ubuntu and drop them every few weeks.  I just like to move in advance for clearly useless stuff like that.
[09:47] <persia> Personally, I doubt Debian will drop them during Lenny.
[11:30] <deufrai> Hi there, I need advice about packaging.
[11:31] <deufrai> I'm working (first of all) on a binary package for an app I wrote, to get the feeling about how things are done
[11:32] <deufrai> and I got a hard time having a menu entry right
[11:33] <deufrai> here is my menu file => http://pastebin.com/m511004c3
[11:33] <deufrai> I'm working with dh-make tools, and got sure my 'rules' file do call dh_installmenu
[11:35] <deufrai> usr/share/menu/qrest file _is_ part of the generated binary package, but after installing the package on my 8.04 system, I still miss the menu entry
[11:35] <deufrai> any advice ?
[11:37] <azeem> deufrai: is this a GNOME or KDE app?
[11:38] <deufrai> this is a Qt app, but I don't intend to tighten it to either wm
[11:38] <azeem> it should probably have a .desktop file then, rather
[11:39] <azeem> could be that menu files are not displayed in the Ubuntu menu by default
[11:39] <deufrai> azeem: oh, right. I'll dig in the .desktop direction
[11:39] <geser> iirc  the menu package isn't installed by default, Ubuntu prefers to use .desktop files
[11:40] <deufrai> where should this file be installed ?
[11:40] <azeem> see the freedesktop.org spec
[11:40] <deufrai> azeem: ok, thanx
[12:01] <deufrai> azeem: great ! Still need to find the right category. Thanx for your help
[12:01] <deufrai> geser: you too
[12:58] <et3> hello everyone
[12:59] <et3> I want to package fonts.  I have never made a package before.
[12:59] <et3> Besides the editing a debian control file.  What do I do?
[13:00] <slytherin> et3: have you read all the packaging documentation?
[13:00] <et3> slytherin: I've browsed through it last night.
[13:01] <et3> I have pbuilder ready
[13:01] <et3> I don't have a key yet
[13:02] <slytherin> et3: so that documentation should tell you all the files you need to create. And since this is the first time you are creating package I suggest take a look at some existing packages.
[13:02] <et3> slytherin: like hello-world?
[13:03] <slytherin> et3: yup
[13:04] <et3> alright.
[14:01] <ScottK> stefanlsd: Yes.  I just moved them all and I don't think it was needed.
[14:04] <nhandler> Is there a way to figure out if a package in Debian has been renamed?
[14:33] <geser> nhandler: check the changelog, but that only works if you knew the new name
[14:36] <persia> You could also use grep-dctrl to look for Replaces: headers, which are a good indicator.
[14:42] <sebner> persia: do you plan to vote before you leave? (May missunderstood your mail)
[14:42] <savvas> If I want to provide three packages in different sections (devel, libs and libdevel), does anyone know what section do I use for the source?
[14:43] <azeem> the most appropriate one I think
[14:43] <azeem> probably devel
[14:43] <savvas> um.. devel?
[14:43] <savvas> oki dokie
[14:45] <persia> sebner, For anyone who applied previously to the 20th, yes.  I'm nearly done with those reviews.
[14:45] <sebner> persia: I see, thx
[14:45] <persia> For people who applied after the 20th, I doubt I'll be able to do so.
[14:46] <persia> savvas, libs usually.
[14:46] <persia> savvas, Just remember to be more specific in the binary sections.
[14:46] <savvas> hm..
[14:46] <persia> hm.. ?
[14:46] <savvas> hold a sec
[14:46] <savvas> it's for ccod: http://ccod.sourceforge.net/
[14:47] <persia> And which packages are you planning?
[14:47] <savvas> from what I see, it provides/builds ccod (binary) libcsp.so (library) and a header for include/ folder
[14:47] <savvas> ccod, libcsp and libcsp-dev
[14:48] <savvas> it's not anything official, just playing arond with my PPA :)
[14:48] <savvas> *around
[14:48] <persia> savvas, I'd probably use "devel" as the section for the package, and provide ccod (devel), csp (web), libccodX (libs), and libccod-dev (libdevel).
[14:49] <persia> Also, why not for the archive, if it's not packaged?
[14:49] <savvas> I'm afraid I'm not that good with cdbs and making packages yet
[14:49] <savvas> as it is, I'm patching the ./configure and the Makefile.in to get the job done
[14:50] <persia> I'd recommend working on it towards the primary archive.  Once you have it in fairly good shape, get some MOTU review.
[14:50] <mok0> savvas: hmmm
[14:50] <persia> savvas, Mostly just a social thing: if it's good for you, and you did the work, may as well share so nobody else has to do it.
[14:50] <savvas> mok0: I know, not a good solution, but I think ccod is not using standard makefile and configure, correct me if I'm wrong
[14:51] <savvas> persia: now that you mention it, I have a fairly good package of libbusiness-issn-perl: https://launchpad.net/~medigeek/+archive
[14:51] <mok0> savvas: oh, I don't know what it's using. It's just that patching configure and Makefile.in is not a good way to go
[14:52] <james_w> should a daemon really be trying to open /dev/null with O_CREAT?
[14:52] <mok0> savvas: If you must go that way, it's better to patch configure.ac
[14:52] <mok0> savvas: and Makefile.am
[14:52] <mok0> james_w: no
[14:53] <persia> savvas, Well, if you've a good package, get some reviews :)  I'm sure someone will find a couple issues (always happens when I package things), and then it can be part of Ubuntu.
[14:53] <persia> james_w, Only O_CREAT, or is that one of several flags?
[14:54] <savvas> mok0: well I see that the debuild sequence of commands actually instructs the make install with DESTDIR= variable that points to the correct debian/tmp/ directory, but it doesn't use that. Also there is no --prefix argument for ./configure
[14:54] <james_w> O_CREAT | O_APPEND | O_RDWR
[14:54] <mok0> persia: you said yesterday that you were looking at supercollider-gedit... apparently you didn't finish your review?
[14:54] <savvas> mok0: any handy links I could read about? :)
[14:54] <persia> james_w, A defensive programmer will often add O_CREAT when opening things for output to avoid a crash.  This is especially useful for /dev/null because you don't care about the output anyway.  Mind you, without some other flags, it's kinda useless.
[14:54] <mok0> savvas: ... you mean about ... configure.ac?
[14:55] <savvas> mok0: yes, and Makefile.am
[14:55] <mok0> savvas: I'll go look
[14:55] <persia> mok0, I haven't, but will definitely do so before I leave.
[14:55] <savvas> persia: great, thanks for the info, but.. where do I apply for review?
[14:55] <persia> mok0, Also, thanks for clearing some of the old ones.  It's looking less bad.
[14:55] <mok0> persia: great. AFAICS supercollider itself is in the "update" section
[14:55] <persia> !revu | savvas
[14:56] <savvas> I see, thanks!
[14:56] <persia> mok0, Yep.  That's a bug in REVU that I've reported to the REVU hackers, but I want to leave it alone so they can try to fix it.
[14:56] <savvas> let me bookmark that link :)
[14:56] <persia> savvas, There are also other ways to get reviews, but that's the most common method.
[14:56] <mok0> persia: ... because that's the last upload from May still hanging around...
[14:56] <persia> savvas, General rule of thumb is that two Ubuntu devs should have looked at a package before it gets approved.
[14:57] <persia> mok0, Wow!  Thanks for chasing the others.
[14:57] <savvas> now the other question: is it better to aim for a debian package or an ubuntu package?
[14:58] <mok0> savvas: here's a nice little short one: http://www.developingprogrammers.com/index.php/2006/01/05/autotools-tutorial/
[14:58] <persia> savvas, Hard to say, but Debian is generally preferred.
[14:58] <persia> I'm not sure either is "better", but it's always more polite to share.
[14:58] <mok0> savvas: otherwise look at the GNU documentation for automake and autoconf, it's really good
[14:59] <slytherin> mok0: if you come across any java packages on revu, let me know.
[14:59] <mok0> slytherin: will do :-)
[14:59] <savvas> or do they cross-exchange packages?
[14:59] <savvas> ok, we'll start from ubuntu going upstream :)
[14:59] <savvas> *we'll = I will heh
[14:59] <savvas> thanks mok0, noted
[15:00] <savvas> let's see if I can tame this puppy
[15:00] <mok0> savvas: go go go
[15:00] <savvas> ah one last thing! should the maintainer use gpl for packaging or follow the license of the included code?
[15:00]  * mok0 is hungry but fridge is empty :-(
[15:01] <mok0> savvas: just follow the license of whatever you're packaging
[15:01] <persia> savvas, Well, if you do your packaging completely from scratch, I'd recommend using the same license as upstream (unles it's particularly onerous).
[15:01] <savvas> hm.. ccod is licensed with MIT license
[15:02] <persia> savvas, Alternately, if you're copying packaging from another package, you might have to use the licensing for that packaging code.
[15:02] <savvas> and the package with dh_make suggested gpl in debian/copyright for the packaging
[15:02] <mok0> savvas: you can use the 3-clause BSD with that I think
[15:02] <persia> savvas, That gives you a *lot* of flexibility, but it means you'd do better to avoid GPL packaging, as it might lead to questions about the license of patches, and could conceivably cause issues sending stuff upstream.
[15:02] <savvas> the what? :P
[15:02] <mok0> savvas: it does that every time :-)
[15:03] <savvas> ok thank you both
[15:03] <savvas> so for the ccod packaging I put everything under MIT/X consortium whatever license
[15:03] <persia> mok0, "BSD" license can only be used by the Regents of the University of California (see /usr/share/common-licenses/BSD).  Please recommend "MIT" or "ISC" as portable licenses with similar intent.
[15:04] <persia> (there are *many* "BSD-like" licenses, but they aren't properly BSD, and so "BSD" is at best confusing)
[15:06] <savvas> so.. I'm right? MIT-licensed packaging for MIT-licensed code?
[15:09] <savvas> bah anyway, that's minor details, let me see if I can actually package it properly :)
[15:09] <mok0> persia: ok
[15:10] <savvas> weird, there's no MIT in common-licenses, it's not that common I presume? :)
[15:10] <persia> savvas, There is no "right".  The recommendation would be to use the same license where you can.  Just check your sources carefully to make sure that you can use that license.
[15:12] <savvas> I'm really not good with legal documents - I can just promise that I'll try heh..
[15:12] <slytherin> savvas: nobody is, not even those who make the law. :-P
[15:15] <savvas> :)
[15:17] <persia> Trying is the important part.  Licenses are important, but for the most part as long as you check the license for any code you copy, and license any code you write in a way that is compatible with that with which it will integrate, you're fine.  There's lots of sites that list various charts of license compatibility.
[15:17] <handschuh> I am looking for someone who can take a look at the package uiflite (http://revu.ubuntuwire.com/details.py?package=uiflite) and maybe be the second advocate
[15:20] <james_w> mok0: hey, in your collectd merge left it with an unsatisfiable build dependency on libupsclient1-dev, was that intentional?
[15:21] <mok0> james_w: yes
[15:21] <stefanlsd> persia: arn't you meant to be in the mountains?
[15:21] <mok0> james_w: because there's a bug in the current package that makes the build fail
[15:21] <james_w> ah, ok
[15:22] <james_w> might be good to note that in the changelog in future :-)
[15:22] <mok0> james_w: you are right..,. finding the bug link...
[15:24] <mok0> bug 299489
[15:24] <persia> stefanlsd, Not yet.  I like to give a few days notice so I can complete the list of things I've compiled to do before I leave.
[15:25] <mok0> Ah, fix released
[15:25] <james_w> ah, that one
[15:26] <mok0> james_w: I am hoping the build will resume once the depends are satisfied
[15:26] <james_w> it's not really fix released
[15:26] <mok0> james_w: "a sync has to be requested"
[15:26] <james_w> yeah
[15:26] <james_w> don't know where
[15:26] <mok0> james_w: or a merge?
[15:28] <james_w> mok0: it looks like it needs a merge
[15:28] <mok0> Saturday afternoon... everyone is downloading movies for tonight... my network conn has slowed to a crawl
[15:30] <mok0> james_w: You have a special interest in nut?
[15:30] <james_w> nope, no idea what it is
[15:30] <mok0> james_w: it's a UPS client
[15:31] <mok0> at least part of it is... that is why it is used by collectd I guess
[15:31] <mok0> james_w: ok, I will merge it and upload
[15:32] <slytherin> persia: where are you leaving?
[15:33] <james_w> thanks mok0
[15:34] <persia> slytherin, That's an interestingly phrased question.  I'll answer "Japan".
[15:34] <slytherin> persia: going on vacation?
[15:34] <mok0> UDS?
[15:34] <persia> slytherin, That is the intent.
[15:35] <persia> mok0, I'll end up there as part of it.
[15:35] <slytherin> persia: ok
[15:35] <james_w> mok0: I would check that something that uses the pkgconfig file from nut will build correctly. The change in -9 doesn't look sufficient to fix all the problems to me.
[15:36] <mok0> james_w: thanks for the warning
[15:36] <james_w> mok0: the pkg-config file will tell whatever is building against libupsclient that it should use -L/usr/lib but the libraries will be in /lib
[15:36] <mok0> james_w: oh? I though he fixed that
[15:37] <slytherin> persia: so how long will you not be available for sponsoring bugfixes/syncs/merges? :-D
[15:37] <james_w> mok0: the symlinks will now be correct, but the pkg-config file may now be wrong.
[15:37] <mok0> james_w: Hmm. The pending package assumes it's going to find the library in /usr/lib.
[15:38] <mok0> james_w: I am not sure that collectd uses pkgconfig, but I will check.
[15:38] <persia> slytherin, 2-4 weeks, depending on a wide variety of factors.  I'll have network access by the 3rd or 4th, but don't know how busy I'll be with UDS, and then getting back.
[15:38] <james_w> it does
[15:38] <mok0> james_w: I don't see that those libraries belong in /lib
[15:39] <mok0> They _really_ ougth to go in /usr/lib
[15:39] <james_w> mok0: that was the Debian maintainers decision, and what led to these issues in the first place
[15:39] <slytherin> persia: no issues, I will bug geser. :-)
[15:39] <jpds> Hello all.
[15:39] <mok0> It may even be policy? Where universe components are supposed to put things?
[15:39] <azeem> mok0: the binary is in /bin, so the libs should be there as well, no?
[15:39] <mok0> azeem: hmm
[15:39] <azeem> we had this discussion before with LaserJock
[15:40] <azeem> I think he filed the Debian bug
[15:40] <mok0> azeem: ... and why is the binary in /bin?? It's not an essential system component
[15:40] <azeem> apparently they think it is
[15:40] <slytherin> jpds: hi
[15:40] <azeem> mok0: well, /bin is also for stuff which is needed before /usr is mounted, not sure this is the case here
[15:40] <persia> Yeah.  Unless it's needed before /usr is mounted, it ought be in /usr.  main/universe doesn't matter for this: it's related to how the package works.
[15:41] <mok0> azeem, james_w, in my opinion the whole nut package belongs in /usr
[15:41] <geser> slytherin: bug me? for what? /me checks scrollback
[15:41] <persia> It's not about being "essential", it's about being part of the early startup cycle.
[15:41] <persia> mok0, Check the rdepends properly.  Maybe something needs it in /bin & /lib
[15:41] <mok0> persia: a UPS client is essential before mounting /usr?? Naahh
[15:42] <persia> mok0, Well, when does it startup?
[15:42] <mok0> persia: OK, I will take a good look
[15:42] <persia> If it's started by a udev hook, quite possibly.
[15:42] <laga> or maybe if it's fscking /usr and losing power.. *shrug*
[15:43] <persia> laga, Well, that's a use-case for why, but unless it actually could get started before /usr mount, the package doesn't support that use case (which is a different sort of bug).
[15:45]  * mok0 is hampered by the slow internet... there's a delay on every character typed on my remote system terminal connection :-(
[15:45] <RainCT> mok0: yeah, I know this :P
[15:48] <mok0> Hm, well I'll need to make a link from /usr/lib/libupsclient1.so to /lib/libupsclient1.so.0.0.0 otherwise the pending build will not make it.
[15:51] <mok0> Ah, this slow internet is killing me. I have to move close my laptop, leave my comfy position in the couch and fire up my linux box. *Sigh*
[16:17] <JonReagan> hey folks... can I keep certain open source libraries that are third party in my project if I keep the licenses and credits available?
[16:18] <handschuh> JonReagan: in source form?
[16:18] <JonReagan> yeah.. well, they are .jars
[16:18] <JonReagan> and I think I may be able to remove some
[16:18] <handschuh> JonReagan: then the asnwer is no
[16:19] <JonReagan> but some have been modified from the original source, and others are no longer available
[16:19] <handschuh> s/asnwer/answer
[16:19] <JonReagan> dangit.
[16:19] <JonReagan> well, thanks for letting me know
[16:19] <handschuh> JonReagan: you should consider making them separate packages
[16:20] <JonReagan> ah, k
[16:20] <handschuh> JonReagan: or, if the external libraries are really trivial, include the sourcecode
[16:20] <handschuh> JonReagan: can you name me the external jars?
[16:21] <JonReagan> eh... yeah... it will take me just a sec
[16:25] <JonReagan> most of the jars have to do with ant and other apache services (batik, jakarta, etc.)
[16:25] <JonReagan> but one in particular
[16:25] <JonReagan> will be hard to separate
[16:25] <JonReagan> because apparently the host project for it is dead
[16:27] <handschuh> whats the name of the project?
[16:27] <handschuh> (that you want to package)
[16:27] <JonReagan> openproj
[16:27] <JonReagan> it's in REVU
[16:28] <JonReagan> http://revu.ubuntuwire.com/details.py?package=openproj
[16:28] <handschuh> ok I will check the orig.tar.gz
[16:29] <JonReagan> thanks!
[16:29] <JonReagan> slytherin posted a comment for some to-do stuff
[16:29] <JonReagan> some of the things I have already fixed, but I haven't created a new build yet.
[16:30] <handschuh> where are the jars in the orig.tar.gz?
[16:31] <JonReagan> they are under... *checks own package*
[16:31] <handschuh> found them
[16:31] <handschuh> contrib/lib it was
[16:32] <JonReagan> yup, that's it
[16:32] <handschuh> ok the common-* jars are in the repos
[16:32] <JonReagan> ah, k
[16:32] <handschuh> junit also
[16:32] <handschuh> the jasper-folder looks also very good
[16:33] <handschuh> groovy is the same
[16:33] <geser> JonReagan: have you checked if some of the jars are already packaged?
[16:33] <JonReagan> I looked for the JasperReports
[16:33] <JonReagan> but couldn't find it
[16:33] <handschuh> geser: we are checking this right now  :-)
[16:34] <JonReagan> I found a jasperlib or something like that, but I was not sure if it was the same thing
[16:34] <slytherin> JonReagan: you should find most of the jars packaged already. I couldn't find jasper reports. The only *jasper* package in Ubuntu is related to jpeg image processing
[16:34] <handschuh> JonReagan: most of the jars are already in the repos
[16:35] <JonReagan> ah, k
[16:35] <JonReagan> so, then, I just need to remove the jars, and add them as dependencies?
[16:35] <handschuh> JonReagan: well basically, yes
[16:35] <handschuh> JonReagan: but you have to change the build.xml
[16:35] <JonReagan> there's a little extra work besides that :)
[16:36] <JonReagan> oh, ok... that's not too bad
[16:36] <slytherin> handschuh: That may be not be always true
[16:36] <slytherin> JonReagan: Take a look at build.xml if it has hard coded paths referring those jar files. If not you may not even need to patch build.xml
[16:37] <JonReagan> yeah, looks like it has hard coded links to the jars
[16:40] <handschuh> JonReagan: you can easyly check if the jars are in the repos by using http://packages.ubuntu.com/
[16:40] <JonReagan> thanks! I didn't even know a package search existed
[16:41] <JonReagan> if the program calls for certain jars to be there, does that mean I need to call for them to be installed before the program configures itself?
[16:42] <handschuh> you need to add the packages as dependencies
[16:43] <JonReagan> that will do it?
[16:43] <JonReagan> sorry... I'm a noob. ;)
[16:43] <handschuh> also, you probably have to adjust the classpath (some say you don't have to do that, but I always had to do)
[16:43] <persia> JonReagan, There are four fields in debian/control that are interesting for Java package dependencies.
[16:44] <persia> Build-Depends: needs to contain all the packages required to run debian/rules clean
[16:44] <JonReagan> ah
[16:44] <persia> Build-Depends-Indep: needs to contain all the packages required to build the package, excepting those already in Build-Depends:
[16:44] <JonReagan> so I need to create a new field for those packages
[16:44] <persia> Depends: needs to contain all the packages required to install or run the package (excepting Priority: required or above)
[16:45] <persia> Recommends: needs to contain all the packages that should be installed at the same time (keep this list small: it's essentially Depends, except that if the program doesn't crash without it, Recommends should be used)
[16:45] <persia> Build-Depends and Build-Depends-Indep belong in the source stanza
[16:46] <slytherin> JonReagan: If you go through my comments, they should clear most of your doubts.
[16:46] <persia> Depends and Recommends belong in the binary stanza
[16:46] <JonReagan> thanks!
[16:48] <JonReagan> I understand now... thanks folks!  I've gotta run, but I will give it a shot
[16:48] <directhex> persia, i don't think you explained the diff between b-d and b-d-i there
[16:49] <handschuh> JonReagan: you do have to add some additional java-packages before getting your program into the repos
[16:50] <JonReagan> oh, I do?
[16:50] <handschuh> JonReagan: there are unfortunatly many java packages missing in the repos
[16:50] <handschuh> JonReagan: yes :-(  I could not find all your jars in the repositories
[16:51] <JonReagan> oh
[16:52] <JonReagan> that means that the program has to include the jars, which is a REVU no-no?
[16:53] <handschuh> JonReagan: no that means before you can continue working on openproj, you have to make shure that all the jars you want to use are in the repositories
[16:53] <handschuh> JonReagan: I am also suffering on this
[16:54] <JonReagan> ah, so I would have to package the .jars then
[16:55] <handschuh> JonReagan: yes - it might be good to start with a small package first
[16:56] <JonReagan> k, thanks
[16:57] <JonReagan> I'll need to talk to the head dev before continuing.  Does revu stay open until feature freeze?
[16:57] <directhex> it stays open full stop. actually getting a package into a given release version is another matter
[16:57] <handschuh> JonReagan: no, revu is always open
[16:59] <JonReagan> oh ok
[17:00] <LaserJock> morning MOTUers
[17:01] <mok0> Evening
[17:01] <LaserJock> mok0: hello! how've you been?
[17:01] <mok0> LaserJock: oh, busy :-)
[17:02] <mok0> LaserJock: been doing a bit of ubuntu work lately, though
[17:02] <LaserJock> mok0: excellent
[17:05]  * mok0 needs to reboot
[17:23] <radix> Is there a widely accepted version scheme for prerelease packages? Like, if upstream released 1.0rc1 and I want to package that, what should I call it?
[17:24] <directhex> radix, generally, if they number it as 1.0rc1, go for 1.0~rc1
[17:24] <directhex> radix, if they number it as 0.9.9 or something, no problem
[17:24] <radix> right
[17:24] <radix> okay
[17:25] <radix> for some reason I was brainfarting and thinking that ~ could only be in the debian version part, but I guess it can go into the upstream version part too
[17:56] <Elbrus> up to now I have used pdebuild to test and build my packages, but now I try to build lazarus, but it doesn't work, because it does patching before it goes into the jail.
[17:56] <Elbrus> It looks like sbuild can handle it beter.
[17:56] <Elbrus> Can I use the same tar balls I use for pbuilder for sbuild?
[17:58] <LaserJock> sbuild normally just uses  a chroot I think
[17:59] <LaserJock> so you could unpack a pbuilder chroot and set sbuild/schroot up to use it
[18:01] <hyperair> Elbrus: how about good ol debuild -S followed by pbuilder
[18:02] <Elbrus> hyperair: thanks, I am just looking into possibilities because until now pdebuild worked great for me and felt secure enough...
[18:02] <Elbrus> I liked the jail, pbuilder doesn't do that, right?
[18:03] <hyperair> Elbrus: the whole purpose of pbuilder is to jail the build
[18:03] <RainCT> Can a package show a message with Yes/No buttons after installation?
[18:03] <LaserJock> Elbrus: I believe pdebuild is just debuild -S + pbuilder
[18:03] <hyperair> yeah actually i think so too
[18:03] <Elbrus> aha..
[18:03] <RainCT> Like the notification that Firefox shows, but asking if you want the application to be restarted automatically
[18:04] <hyperair> i usually use a combination of a custom pbuilder script and pdebuild. something like pdebuild ==pbuilder ~/bin/pbuilder-<release>
[18:05] <hyperair> RainCT: take a look into the fast user switch applet package, whichever that is. i remember it popping up some window asking if i wanted to replace my power button with it
[18:07] <RainCT> uhm.. no postinst file there
[18:09] <RainCT> hyperair: I can't find anything there, but thanks
[18:10] <hyperair> hmm strange
[18:10] <hyperair> well look into debconf then
[18:14] <RainCT> I don't think debconf would work for what I want to do
[18:18] <slytherin> RainCT: IIRC, the FF restart dialog is FF magic and not packaging magic.
[18:19] <slytherin> RainCT: you may want to take look at postinst of some of the servers (apache2, squid), but not sure you will find what you are looking for.
[18:22] <hyperair> slytherin: how about the fusa magic? how is that done?
[18:22] <slytherin> hyperair: no idea
[18:23] <hyperair> hmm
[18:24] <geser> the FF restart diaglog is a postinst with update-notifier magic
[18:27] <geser> and the fusa update note comes from gnome-panel.postinst
[18:34] <et3> I'm having problems publishing my key
[18:35] <geser> et3: can you be more verbose?
[18:35] <et3> well, what's the keyserver name?
[18:35] <jmarsden> et3: CAn be be more specific?  ssh key?  gpg key?  and what problem?
[18:35] <et3> keyserver.ubuntu.com?
[18:35] <et3> gpg key
[18:36] <et3> I'm trying to add a gpg key to launchpad
[18:36] <geser> keyserver.ubuntu.com is correct
[18:36] <geser> which error do you get?
[18:37] <et3> et3@kilo:~$ gpg --send-keys 4E028549 --keyserver keyserver.ubuntu.com
[18:37] <et3> gpg: "--keyserver" not a key ID: skipping
[18:37] <et3> gpg: "keyserver.ubuntu.com" not a key ID: skipping
[18:37] <et3> gpg: no keyserver known (use option --keyserver)
[18:37] <et3> gpg: keyserver send failed: bad URI
[18:38] <nhandler> et3: Use 'gpg --send-keys --keyserver keyserver.ubuntu.com <KEY-ID>'
[18:38] <et3> nhandler: thanks
[18:38] <jmarsden> See https://help.launchpad.net/YourAccount/ImportingYourPGPKey
[18:38] <nhandler> You're welcome et3
[18:38] <nhandler> et3: That is from https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Uploading%20the%20key%20to%20Ubuntu%20keyserver
[18:39] <et3> It's sent.
[18:40] <nhandler> ;)
[18:40] <et3> I didn't violate it's integrity by announcing it's ID did I?
[18:40] <nhandler> et3: No you didn't. That is the key id, which is public on LP and the keyserver anyway
[18:41] <et3> alright, well it's a good think I didn't announce the passphrase: "asdf8322ujhvki"
[18:41] <et3> (kidding)
[18:42] <jdong> WHOO, BSOD!
[18:42] <jdong> boy that was scary, full-screened XP VM bluescreened.
[18:42] <et3> I tried to use the _actual_ passphrase in seahorse and it said it wasn't the right thing.  so...  I don't know.  Is the gpg key useless.
[18:43] <et3> jdong: what?  lol
[18:45] <jmarsden> et3: TRy   date |gpg -sa    and enert the passphrase, if you see otuput surrounded by "BEGIN PGP MESSAGE" and "END PGP MESSAGE" then it is fine.
[18:45] <jmarsden> s/enert/enter/
[18:47] <et3> jmarsden: it said I needed a passphrase to unlock it
[18:47] <jmarsden> Right, the one you used on your gpg key :-)
[18:48] <et3> damn... maybe I typed it in wrong.
[18:48] <et3> is that going to be a problem?
[18:48] <jmarsden> et3: I thought you were wondering if you had the passphrase right and if they key was working...
[18:48] <nhandler> et3: Without your password, your key is useless. You will need to create a new key
[18:48] <jmarsden> et3: If you don't know the passphrase, that key is useless, to you or anyone else
[18:48] <et3> jmarsden: thanks.
[18:48]  * et3 makes a new one.
[18:49] <jdong> oh that's REAL nice.
[18:49] <jdong> chkdsk /F even dies off the installation CD.
[18:50] <geser> et3: did you already upload the broken key?
[18:55] <et3> geser: I canceled it
[18:55] <et3> jdong: ...what did you do?
[18:55] <geser> good, as you can't delete a key from a keyserver once you uploaded it
[19:11] <ryanakca> How can one search for packages by maintainer?
[19:12] <geser> grep-dctrl perhaps
[19:15] <ryanakca> geser: thanks
[19:17] <ryanakca> Can a program be under GPLv2 and its packaging under GPLv3?
[19:24] <LaserJock> ryanakca: is the program GPLv2 only?
[19:30] <ryanakca> LaserJock: *nod*... so I guess, no?
[19:30] <LaserJock> ryanakca: I think no
[19:31] <LaserJock> ryanakca: it's sort of one of those "like anybody cares", but generally I think packaging should just be the same as the program itself, that way you don't run into problems
[19:33] <ryanakca> LaserJock: *nod*, just curious... I don't mind, really... it's not as if anybody is going to ``TIVOise'' my package.... but thinking about it... the packaging doesn't depend on the program itself, does it? You could distribute the debian/ alone  ... so couldn't it be different?
[19:33] <ryanakca> Hmm... and he's gone :)
[19:34] <et3> how long would it take one of you to package a few fonts?
[19:39] <et3> let me be less specific.  If you wanted to put just one file (like a wallpaper) into a package for your own repository, how would you go about doing that?
[19:39] <et3> and how long does it take?
[19:52] <james_w> ryanakca: yeah, you are correct I believe, but what happens to ./debian/patches/ for instance
[19:55] <ScottK> et3: I'd find a similar package and use that as a basis for the one I wanted.
[20:00] <ryanakca> james_w: True...
[20:01] <ryanakca> james_w: easier to just stick it all under the same license
[20:01] <james_w> definitely
[20:02] <ScottK> ryanakca: It could be different, but it should be compatible.  It's 99% simpler just to make it the same as the package itself.
[20:04] <directhex> hm. does anyone know the OOo build process at all?
[20:07] <ScottK> directhex: I know enough to know that I don't want to know more.  You'll probably have to talk to calc.
[20:08] <directhex> i seem to have replied to my own question
[20:08]  * mok0 shrieks at nut package: would NEVER have advocated that piece of crap
[20:08] <directhex> i *THINK* i've patched this 462 MiB monster for the mono 2.0 transition, but wanted to clarify some thnigs about the build process
[20:09] <slytherin> directhex: I know two things. 1. It needs about 10GB of disk space to build. 2. It takes hours to build, something like whole night. :-)
[20:10] <directhex> slytherin, well, when i say "i think" i mean "i can't easily test it until my pbuilder has mono 2, which means a main sponsor needs to upload mono 2"
[20:12] <slytherin> directhex: hmm, so why is mono 2 stuck? No sponsors?
[20:12] <directhex> aye. alpha 1 is history now, so that's the next thing to wait for
[20:12] <directhex> and since it needs to land in NEW due to the changes, that's the NEXT hold-up
[20:13] <ScottK> directhex: You can use loging and -save-after-login to add locally built packages to your pbuilder.
[20:14] <ScottK> loging/login
[20:14] <slytherin> directhex: what scottk suggested. I have used it to evaluate how far I could go in breaking jboss circular build deps.
[20:16]  * ScottK did it to pre-build all of KDE for a KDE version update.
[20:16] <ScottK> That takes a long time too.
[20:17] <et3> so... I actually created a file called "./..'"
[20:22] <coppro> lies
[20:24] <et3> coppro: no _youre_ a lie...
[20:25] <NCommander> The cake is a lie
[20:26] <et3> ./..' exists
[20:26] <coppro> of course it does
[20:27] <et3> coppro: you're just mad because you can't do it.
[20:28] <coppro> of course I can
[20:28] <coppro> touch "..'"
[20:29] <et3> that's cool.
[20:31] <et3> I'm pretty sure I want a file called that in a package of my own rep
[20:31] <et3> s/rep/repo
[20:31] <coppro> all characters except \0 and / are legal in Unix
[20:31] <coppro> (in filenames)
[20:32] <coppro> I'm just having trouble believing you'd actually want such an esoteric name
[20:32] <et3> lol.  I was kidding but I learned something.
[20:32] <et3> C++0x
[20:33] <coppro> C++0x is awesome :)
[20:34] <et3> I've never tried it.  It is a ridiculously 31337 name though
[20:35] <mok0> ha, the new debian package creates a symlink  /lib -> /libupsclient.so.1.0.0
[20:35] <mok0>  that's gonna make people real happy... :-P
[20:36] <mok0> here comes my cat
[20:36] <et3> mok0: but does it make the symlink:  "/" -> "~/..'... um... 0\\0\\0 \0 ~//~. !?"
[20:36] <mok0> et3: /lib -> :-(
[20:36] <et3> lol
[20:37] <mok0> their build machines will break
[20:37] <et3> :~(
[20:38] <mok0> et3: one of the reasons I was cursing that package a while back...
[20:38] <mok0> Oh well, I'll fix it for Ubuntu and forward a patch...
[20:39] <et3> alright.
[20:58] <RainCT> can someone tell me how to mark bugs as duplicates in bugzilla?
[21:12] <nellery> RainCT: at the bottom of the bug page, there's a section called "bug status change", and you can select to mark it as a duplicate there
[21:14] <RainCT> nellery: but apparently only if you have permissions to do this :)
[21:14] <RainCT> nellery: already got someone to mark it as duplicate, but thanks :)
[21:14] <nellery> RainCT: Ah, alright
[21:14] <nellery> no problem
[21:23] <NCommander> RainCT, poke
[21:27] <savvas> hey, about revu, do we upload as -D UNRELEASED or jaunty?
[21:29] <nhandler> savvas: jaunty
[21:29]  * RainCT is poked by NCommander 
[21:29] <RainCT> savvas: jaunty
[21:29] <savvas> thanks - in the future, the latest dev release, right?
[21:29] <RainCT> savvas: yep
[21:30] <NCommander> RainCT, can we please hide the "Advocate this Upload" button from Contributors
[21:30] <RainCT> NCommander: it should be
[21:30] <nhandler> RainCT: It isn't
[21:30] <RainCT> oh right
[21:31] <RainCT> missed that one when I changed how permissions work
[21:32] <RainCT> fixin'..
[21:33] <savvas> RainCT: E: libbusiness-issn-perl_0.91-1_source.changes: bad-distribution-in-changes-file jaunty < should I ignore this or add in lintian overrides?
[21:34] <jpds> Ignore.
[21:34] <RainCT> savvas: ignore
[21:34] <NCommander> That's still broken?
[21:34] <RainCT> savvas: is that an old upload?
[21:34] <NCommander> Geeze
[21:34] <RainCT> NCommander: I installed lintian from hardy-backports, not sure how up2date it is
[21:34] <nhandler> NCommander: I belive collin watson was going to manually update lintian
[21:35] <RainCT> but remember that the lintian report file isn't update
[21:35] <RainCT> +d
[21:35] <NCommander> The jaunty version still has that issue
[21:35] <RainCT> oh ok
[21:35] <RainCT> :/
[21:35] <savvas> RainCT: nope, a shiny new one, libbusiness-issn-perl doesn't exist in neither debian nor ubuntu
[21:36] <RainCT> yeah I see..   /me thinks that distro names should be announced before so that there's time to let all tools know them :P
[21:36] <savvas> is there a sudo update-lintian-warnings tool ?:P
[21:39] <savvas> er.. one last thing, should I add my name as the maintainer or the ubuntu motu?
[21:39] <savvas> it's still not uploaded, just trying to upload a close-to-perfect package heh
[21:40] <RainCT> savvas: Maintainer is Ubuntu MOTU Team <ubuntu-motu@lists.ubuntu.com>
[21:40] <nhandler> savvas: You should set 'Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>' as the Maintainer
[21:40] <nhandler> You are the XSBC-Original-Maintainer
[21:40] <RainCT> savvas: XSBC-Original-Maintainer can be your name
[21:40] <savvas> I see, cool :)
[21:40] <RainCT> (not sure if I typed that right, so check it someone else)
[21:40] <savvas> no it's correct, I have some experience with that from bugs :p
[21:41] <RainCT> *somewhere
[21:41] <RainCT> ok :)
[21:41] <nhandler> RainCT: It is 'Ubuntu MOTU Developers' not 'Ubuntu MOTU Team'
[21:41] <RainCT> savvas: see? ;)
[21:41] <savvas> I was talking about the xsbc :)
[21:42] <savvas> oh well changing
[21:45] <gouki> Depending on the version present on the changelog, PPA will generate appropriate sources.list, correct? Or will it only allow jaunty now?
[21:46] <RainCT> gouki: yes, it will
[21:46] <gouki> RainCT, thank you.
[21:48] <savvas> one (really) last thing, in case I need to fix something, the current version is 0.91-1.. the new version would be 0.91-2 or something like 0.91-1.1 ?
[21:48] <savvas> or is that a personal favourite? :p
[21:48] <RainCT> savvas: on REVU? don't change the version
[21:49] <savvas> ah so I just do the changes and dput the new stuff again?
[21:50] <savvas> well.. here goes nothing :)
[21:50] <RainCT> right
[21:50] <RainCT> but dput -f or delete the .upload file, else dput will complain
[21:51] <savvas> thanks, I was used to the PPA way, you know, push a release and upload
[21:51] <gouki> Any thoughts of why pbuilder is failing with 'Aptitude couldn't satisfy the build dependencies' when all packages are correct?
[21:51] <savvas> *a version
[21:51] <RainCT> gouki: is your pbuilder up2date?
[21:51] <gouki> RainCT, yes :(
[21:52] <gouki> Oh, I'm getting a warning about libssh2-1-dev being a virtual package. Is that a problem?
[21:52] <RainCT> maybe
[21:53] <gouki> RainCT, fixable?
[21:53] <RainCT> NCommander: (fixed)
[21:53] <NCommander> yay
[21:53] <savvas> hm.. three lintian problems: http://revu.ubuntuwire.com/revu1-incoming/libbusiness-issn-perl-0811222254/lintian
[21:54] <savvas> looks like it's about nmu, but I was told that that is not used in ubuntu
[21:54] <RainCT> savvas: wrong version number :)
[21:54] <RainCT> savvas: it should be 0.91-0ubuntu1, not 0.91-1
[21:54] <RainCT> savvas: and it's XSBC-Original-Maintainer, not Original-Maintainer
[21:55] <savvas> woops
[21:55] <RainCT> (if you have this right, then it's also because of the version number too)
[21:55] <savvas> here we go again :P
[21:56] <savvas> are you sure it's 0.91-0ubuntu1 ? I'll give it a go
[21:56] <RainCT> savvas: if upstream's version is 0.91, then yes
[21:56] <savvas> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[21:56] <savvas> XSBC-Original-Maintainer: Savvas Radevic <vicedar@gmail.com>
[21:56] <RainCT> savvas: -0ubuntu1 means Debian Revision 0, Ubuntu REvision 1
[21:56] <savvas> ah, I see
[21:56] <RainCT> (ie, not in Debian and for the first time in Ubuntu)
[21:56] <RainCT> that should be correct
[21:57] <savvas> cool, thanks for the tip :)
[21:57] <gouki> Apparently removing that package (libssh2-1-dev) fixed the problem. The problem is that the software looses 30% of its capabilities without it.
[21:57] <RainCT> gouki: uhm.. doesn't seem like a virtual package to me
[21:58] <gouki> RainCT, that's the warning I got from pbuilder :S
[21:58] <RainCT> ah wait
[21:58] <savvas> now, for the new upload, do I use debuild -S -sd or debuild -S -sa ? Since the orig.tar.gz didn't change, I'm not sure :\
[21:58] <RainCT> savvas: -sa for now
[21:58] <serialorder> Hi all, if I am applying a bugfix that involves removing a few troublesome lines from debain/postinst is there a preferred method of doing it? Should I actually remove the lines or comment them out?
[21:58] <savvas> ok
[21:59] <jmarsden> gouki: I think that "virtual package" warning can mean "I can't find that package"... so check your pbuilder has all the repositories enabled that you think it has?
[21:59] <RainCT> serialorder: if they are useless, remove them, if they may be needed in the future comment them out
[21:59] <RainCT> serialorder: but I don't think there's any rule on this
[21:59] <gouki> jmarsden, OK. How can I check pbuilders repositories?
[22:00] <serialorder> RainCT: ok thanks
[22:00] <RainCT> gouki: pbuilder --login
[22:00] <RainCT> if you want to modify something add --save-after-login
[22:00] <gouki> Thanks!
[22:01] <jmarsden> gouki: Also check https://wiki.ubuntu.com/PbuilderHowto#Universe%20support for how to add Universe, and use that as an example for any other repos you need.
[22:01] <gouki> jmarsden, thank you.
[22:10] <savvas> RainCT: sorry for bugging you, but how do I purge the older upload?
[22:10] <RainCT> savvas: why would you want to do this?
[22:11] <savvas> oh we don't?
[22:11] <savvas> sorry :P
[22:11] <RainCT> (and only admins can purge)
[22:11] <savvas> I'm really new to this, I was suggested to start sharing my packaging :)
[22:13] <savvas> so now I wait for the package to be approved or argued, heh
[22:13] <nhandler> savvas: Two MOTUs need to advocate the package for it to enter the New Queue
[22:14] <savvas> nhandler: thanks, are you familiar with the procedure for inclusion in debian?
[22:14] <nhandler> savvas: Debian is a little different
[22:15] <nhandler> I believe you just need one Debian Developer to sponsor the upload for you
[22:15] <RainCT> but easy! :P
[22:15] <nhandler> Let me get you a link to the procedure
[22:15] <savvas> cool
[22:15] <RainCT> nhandler: yep
[22:15] <RainCT> savvas: http://mentorns.debian.net
[22:15] <RainCT> err, http://mentors.debian.net
[22:15] <RainCT> upload it there and send a message to the mentors ML (you'll find info about this at the webpage)
[22:16] <nhandler> savvas: Once you upload it to m.d.n, you will want to send a RFS (Request for Sponsor) email to the debian-mentors mailing list
[22:16] <nhandler> savvas: http://mentors.debian.net/cgi-bin/maintainer-intro
[22:16] <gouki> Can I have the same software, with different versions on the changelog, uploaded to the PPA? Say for hardy, intrepid and jaunty?
[22:16]  * RainCT decides to stop talking as nhandler is answering everything anyway ;)
[22:16] <RainCT> gouki: yep
[22:17]  * RainCT has already broken his decision :P
[22:17] <savvas> I guess the only thing that needs to be changed now is jaunty to unstable and perhaps the maintainer fields
[22:17] <savvas> I'll read on, thanks!
[22:17] <RainCT> savvas: and the version number, to -1
[22:17] <savvas> but..
[22:17] <savvas> argh! :P
[22:17] <nhandler> RainCT: Do we have a wiki page that talks about some of the things you need to look at when sending an Ubuntu package to Debian?
[22:17] <savvas> ok, different distros, different policies :)
[22:18] <RainCT> nhandler: not that I know of, but if you write one I'll give you a hug!
[22:18] <savvas> you'll have a hug from me too! lol
[22:18] <nhandler> RainCT: I'm not the best at writing up stuff like that, but I'll try to put something basic together in the next day or so
[22:18] <nhandler> Any suggestions for the wiki name?
[22:19] <savvas> DebianTransition ?
[22:19] <RainCT> nhandler: dunno, but it should be somewhere under https://wiki.ubuntu.com/Debian
[22:19] <RainCT> Debian/NewPackages perhaps
[22:19] <savvas> much better
[22:20] <RainCT> wait, https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers already has something
[22:20] <nhandler> RainCT: I thought about that.I think I'll just add on to the ForUbuntuDevelopers page
[22:20] <RainCT> expand that if you think there's something missing.. and we should link it from somewhere in MOTU/
[22:22] <savvas> ForUbuntuMaintainers then? :)
[22:22] <savvas> or Packagers, heh
[22:26] <et3> I tried to push my branch onto launchpad using bzr
[22:27] <et3> I got this error:  Permission denied (publickey).
[22:27] <RainCT> et3: have you told Launchpad what your SSH key is?
[22:27] <et3> does bzr not know my public key or what?
[22:27] <et3> yes... but I'm not using ssh
[22:27] <et3> should I be?
[22:28] <savvas> et3: https://launchpad.net/people/+me/+sshkeys
[22:28] <savvas> (I think)
[22:29] <et3> savvas: thank you. I'll check it out
[22:29] <et3> savvas: that's my public key :S
[22:29] <savvas> et3: you can easily create it with Applications > Accessories > Passwords and Encryption > Key > create > Secure shell key
[22:30] <et3> It's already made
[22:30] <savvas> et3: do you have a key listed in Passwords and Encryption keys with a small key and a terminal icon next to it?
[22:30] <et3> yes
[22:30] <et3> and I sent launchpad the key
[22:30] <et3> that you found actually
[22:31] <savvas> did you change the username/domain?
[22:31] <et3> you can't ssh into my computer using that key can you?
[22:31] <et3> savvas: on what?>
[22:33] <savvas> et3: (keep your info private) look at the name on Passwords and Encryption keys for that key, compare it with the output of: echo `whoami`@`hostname`
[22:34] <nhandler> RainCT: I added a few bullet points to the wiki page. I have to run out now, but I'll finish cleaning it up later.
[22:35] <et3> okay so they both say rickrollVirus@yourComputer
[22:35] <et3> (kidding)
[22:35] <savvas> lol
[22:35] <savvas> et3: what's your branch by the way?
[22:36] <et3> im experimenting with packaging
[22:36] <et3> https://code.launchpad.net/codeshift-wallpapers
[22:36] <et3> I just started a few hours ago
[22:36] <et3> I haven't uploaded anything yet
[22:37] <savvas> et3: have you read http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html ?
[22:38] <et3> yes
[22:38] <et3> only instead of saying "2 Revisions pushed" it says "do it yourself" or something like that
[22:40] <et3> so... do I need to tell bzr about my public key or something?
[22:40] <savvas> um, I would try to readd my ssh
[22:40] <et3> are you implying I need to ssh somewhere?
[22:41] <savvas> no no
[22:41] <savvas> wait
[22:41] <savvas> https://launchpad.net/people/+me/+editsshkeys
[22:41] <et3> I uploaded my ssh key
[22:42] <savvas> I know, try removing it and reuploading it
[22:42] <savvas> et3: in the meantime, try: bzr launchpad-login
[22:42] <savvas> see if it shows your launchpad username
[22:43] <et3> it replied correctly
[22:44] <savvas> try pushing again
[22:44] <et3> isn't it infinately intelligent to have remembered my ID? ^^  ahhh... technology is amazing.
[22:44] <et3> alright
[22:44] <savvas> bzr push lp:~codeshiftster/codeshift-wallpapers/main
[22:45] <savvas> It ought to ask you to verify your key now
[22:45] <savvas> or authorize its usage
[22:46] <et3> I deleted it
[22:46] <et3> I need to put it back
[22:46] <savvas> go go go :)
[22:47] <et3> that's not fair
[22:49] <et3> it still denies me
[22:49] <et3> what am I doing wrong?
[22:49] <savvas> do you have a shotgun handy? :)
[22:49] <savvas> just kidding :p
[22:49] <et3> lol... noo....
[22:50] <et3> import shotgun;
[22:50] <et3> why do you axe me that?
[22:51] <savvas> heh, nothing
[22:52] <savvas> I really have no idea, try making a new key or something
[22:52] <savvas> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
[22:52] <et3> alright
[22:53] <et3> maybe its because it was dsa and not rsa
[22:53] <savvas> well I have rsa
[22:53] <savvas> the dsa should be in ~/.ssh/id_dsa.pub
[22:54] <savvas> try with rsa, if it works, then I sense a bug
[22:54] <savvas> by the way, the correct channel is #launchpad :)
[22:55] <et3> alright
[22:55] <et3> right... I should have thought of that
[22:56] <et3> I just thought it was a MOTU thing
[22:56] <et3> I need to go eat
[22:56] <et3> thanks
[23:09] <savvas> et3: actually, more like #ubuntu-devel and #launchpad instead of motu, but I'm really not that sure
[23:23] <RainCT> omg.. reportbug is telling me about 2575 bugs with a similar description to that one of an ITP I'm filling and wants me to confirm that they aren't the same showing them in groups of 5 -.-
[23:24]  * RainCT hates whoever wrote that :P
[23:26]  * directhex makes it groups of 7, for RainCT's benefit
[23:27] <RainCT> directhex: wow, that makes a big difference :P
[23:27] <directhex> RainCT, 40% more efficient!
[23:27] <RainCT> that's an argument :P
[23:28] <directhex> RainCT, if you told a corp "wanna be 40% more efficient", you think they'd say "bugger off"? no!
[23:32] <RainCT> directhex: but it's still 367 times of writing n and pressing enter :(
[23:37] <serialorder> can someone tell me what the difference between  a sync and a merge is, I am a bit confused on that point
[23:39] <RainCT> serialorder: a sync is just copying the package over from Debian and rebuilding it
[23:40] <RainCT> serialorder: a merge is done when a package was modified in Ubuntu and consists in taking the new version from Debian and applying those changes from the Ubuntu version that are still relevant to it
[23:41] <serialorder> then if I grab a package in MoM and all of the ubuntu changes have been included upstream
[23:41] <serialorder> mom will automatically name that package-verubuntu1
[23:41] <serialorder> should I rename that to just package-ver
[23:41] <RainCT> serialorder: you should request a sync then
[23:44] <serialorder> it already has a sync request
[23:44] <serialorder> does that mean I should not grab from MoM then but from the debian repository?
[23:45] <RainCT> serialorder: if it already has a sync request, just wait for the archive admins to do the sync
[23:46] <serialorder> ok