[00:24] <somerville32> choudesh, Are you okay?
[00:26]  * persia suspects a combination of auto-join and network issues.
[01:01] <Lrrr> someone's having connectivity problem
[01:11] <somerville32> choudesh_, Can you please fix your connectivity issues? You're spamming the channel.
[01:17] <TheMuso> He is obviously not around, or the connection is bad enough that he didn't get the message.
[01:17] <minghua> I'd say just temporarily ban him.
[01:18] <persia> somerville32: Thanks.
[01:18] <somerville32> \o/
[01:18] <persia> Don't forget to unban after a bit, when the autojoin has timed out and failed
[01:19]  * somerville32 sets a timer.
[01:22] <stdin> somerville32: you should probably ban-forward to ##fix_your_connection
[01:23]  * somerville32 will attempt.
[01:25] <stdin> perfect :)
[01:26]  * somerville32 wipes brow.
[01:26]  * ion_ licks brow.
[01:26] <somerville32> :]
[01:52] <Amaranth> whoa
[01:56] <somerville32> :]
[02:19] <somerville32> Ugh oh :(
[02:38] <snoutmate> hello, can i ask for re-sync of the REVU uploaders keyring ?
[02:42] <somerville32> snoutmate, sure. I'm sure a revu admin will get to it as soon as possible.
[03:07] <cyberix> https://bugs.launchpad.net/ubuntu/+bug/182455
[03:07] <ubotu> Launchpad bug 182455 in ubuntu "[needs-packaging] Micropolis" [Undecided,New]
[03:07] <somerville32> lol
[03:36]  * Hobbsee waves
[03:36] <bddebian> Hello Hobbsee :-)
[03:40] <somerville32> Hiya Hobbsee
[03:54] <bddebian> Heya persia
[03:54] <persia> Hi bddebian
[03:55] <somerville32> Sometimes I wished we all worked in the same building or something together. I made muffins today and I have a desire to share :P
[03:56] <Hobbsee> persia: what am i supposed to export to get my gpg key right?
[03:56] <persia> Hobbsee: Hrm?  How do you mean?  For signing .changes?
[03:56] <Hobbsee> persia: yeah
[03:57] <Hobbsee> Would you like to use the current signature? [Yn]n
[03:57] <Hobbsee>  signfile cli-common_0.5.6.dsc Sarah Hobbs <hobbsee@ubuntu.com>
[03:57] <Hobbsee> gpg: skipped "Sarah Hobbs <hobbsee@ubuntu.com>": secret key not available
[03:57] <Hobbsee> gpg: [stdin]: clearsign failed: secret key not available
[03:57] <Hobbsee> debsign: gpg error occurred!  Aborting....
[03:57]  * persia uses export `DEBEMAIL="Emmet Hikory <persia@ubuntu.com>"; dch -i; debuild -S`
[03:57] <persia> Hobbsee: Let me take a look at your key...
[03:57] <Hobbsee> oh, so export DEBEMAIL=hobbsee@ubuntu.com doesn't work?
[03:58] <persia> Hobbsee: If you only do that, you also need DEBFULLNAME.  I overload DEBEMAIL to only have one command.
[03:58]  * Hobbsee has overriden both usually
[03:58] <persia> You need `export DEBEMAIL="Sarah Hobbs (nick: Hobbsee) <hobbsee@ubuntu.com>"`
[03:58] <Hobbsee> persia: interesting, OK
[03:59] <persia> (or to otherwise get "(nick: Hobbsee)" in debian/changelog)
[03:59] <Hobbsee> persia: ahh, so that's the problem bit
[03:59] <persia> Hobbsee: Alternately, adjust your key to not have a comment for that identity, and you don't need the comment.
[03:59] <Hobbsee> yeah
[04:01] <Hobbsee> persia: apparently hardcoding it in .zshrc doesn't help
[04:01]  * Hobbsee hardcodes it in the script
[04:01] <persia> Hobbsee: hardcoding what?
[04:01] <Hobbsee> persia: the key ID
[04:02] <persia> Hobbsee: No.  The keyID is fairly meaningless.  To have a package that doesn't look sponsored, the identity in the debian/changelog tagline needs to be an exact string match to one of the identities listed at http://keyserver.ubuntu.com:11371/pks/lookup?search=0x7D2BCE85&op=index
[04:02] <persia> If you want to change those identities, you need to edit your local key, and resync with the keyservers.
[04:02] <Hobbsee> right, yes
[04:03] <persia> Many people hardcode DEBEMAIL or DEBEMAIL and DEBFULLNAME in their shell initialisation scripts, but I don't think hardcoding the keyID is supported, as it tends to lead to inaccurate changelogs.
[04:03]  * Hobbsee ponders dropping the nick then
[04:03] <Hobbsee> iv'e yet to see hardcoding the keyID break anything here
[04:04] <Hobbsee> although apparently, for this particular script, it didn't take the alias, nor the gpgkeyid from .zshrc
[04:04] <persia> It would show as a sponsored upload for tools that distinguish such things (like MoM).
[04:04] <Hobbsee> well, it has to be anyway, as i can't sign it with any other key
[04:04] <Hobbsee> and if i keep the debian sig, it won't get accepted into ubuntu
[04:05]  * Hobbsee can't sign it with the installer key, due to ENODRESCHER.
[04:05] <persia> If you're sponsoring, just use debuild -S -sa -k7d2bce85
[04:05]  * Hobbsee was using thsi sync script, which effectively does that :)
[04:06]  * persia suspects the sync script of checking too many things, and has always needed to further adjust with vi when using it, but has only used it when no archive admins could sync, which may not be an ideal sample set.
[04:07] <Hobbsee> persia: perhaps so.  i'm not sure what it's from.  i'm not sure if they normally use it
[04:07] <persia> Hobbsee: For sponsoring a sync: build the source package with -uc -us.  Add the correct Origin to source.changes.  debsign the .dsc and the .changes with your sponsoring key.  Upload.
[04:07] <persia> Anyway, I thought there was supposed to be an LP interface to that by now...
[04:08] <Hobbsee> persia: i ended up running the sync-script package, watching it bail out, then debsigning and uploading.
[04:08] <persia> Hobbsee: Which package?
[04:08] <Hobbsee> which is fine, according to the script
[04:08] <Hobbsee> er, cli-common
[04:08] <Hobbsee> there isnt'.  there's probably supposed to be...
[04:09] <Hobbsee> persia: actually, there won't be for a while.  stuff still gets accepted into main by default from LP
[04:09] <persia> Ah.  YALPB.  Right.  Why don't I see cli-common in Accepted?
[04:09] <Hobbsee> it's hit hardy-changes
[04:09] <Hobbsee> nothing strange should happen to it - LP will class it as a normal upload
[04:10] <Hobbsee> lp might not know about it yet, if all the runes haven't been done yet
[04:10] <persia> Hobbsee: Right.  I just want to look at .changes to see if I want to say anything for next time.
[04:10] <Hobbsee> ahhh
[04:10] <persia> Runes?  Shouldn't it hit Accepted around the same time it pushes to .changes?
[04:11] <Hobbsee> i'm not sure, tbh
[04:11] <Hobbsee> i know launchpad takes quite some time to do certain things
[04:11] <Hobbsee> fujitsu could probably tell you, if he were here
[04:12] <persia> Hobbsee: That looks like a clean sync to me.
[04:12] <Hobbsee> persia: yeah, good :)
[04:12] <persia> (Except that it required extra LP processing, but that's not easy to resolve in the presence of YALPB)
[04:12] <Hobbsee> well, it's like a normal upload.  *shrug*
[04:13] <Hobbsee> i don't see how it required more LP processing, tbh
[04:13] <persia> Well, yes, but I've been told not to do uploads for syncs because it makes LP slower.
[04:13] <persia> You're special, as you are in the right groups to do stuff, even though you can't due to YALPB.
[04:14] <LaserJock> what's the B in YALPB?
[04:14] <persia> LaserJock: Bug.
[04:14] <Hobbsee> persia: oh, does it?
[04:14]  * Hobbsee didn't use special groups, etc
[04:14] <LaserJock> ah, right
[04:15] <Hobbsee> persia: did they say why it makes LP slower?
[04:15] <emgent> good night people
[04:15] <persia> Hobbsee: pitti told me he'd rather I file 50 bugs and leave them open than file 50 bugs and close them.  Something about uploads being treated differently than syncs (although I don't understand the details).
[04:16] <Hobbsee> persia: hm, fair enough
[05:38]  * TheMuso wills the storms to arrive. Tis not often that Sydney gets them first.
[05:39] <persia> Are they coming from the east?  That seems odd.
[05:40] <TheMuso> No, west. However a few storms have past to the north and south of where I am.
[05:40] <TheMuso> So they have hit, but in non-populated areas.
[05:40] <persia> Isn't that better?  Less inconvenience, but the water table still rises?
[05:41] <TheMuso> Yes, but its quite warm and humid here, and rain is needed.
[05:41] <persia> In that case, I guess it makes sense.  We only get Typhoons here for rain in the summer, which is rarely a good thing (although the weather is milder thereafter).
[05:43] <TheMuso> nasty
[05:55] <crimsun> ok, UI discussion if anyone's around and up for some simplification.
[05:55] <crimsun> take a look at the PulseAudio menu items in http://trilug.org/~crimsun/Screenshot.png
[05:56] <persia> That's four.  Isn't Manager launched from the Device Chooser applet?
[05:56] <crimsun> well, it's nasty for one thing
[05:56] <persia> For that matter, also Volume Control, and Volume Meter?
[05:56] <crimsun> yes.
[05:57] <crimsun> padevchooser will grab, through Recommends, paman, pavucontrol, and pavumeter
[05:58] <persia> I'm not sure that paman pavucontrol and pavumeter need to be shown in the default menu then.  As long as padevchooser is there, users should get it in the panel, and then launch the others from there.  Probably good to also include .desktop files for these though, just to make app-install-data happy.
[05:58] <crimsun> I'm considering collapsing that menu akin to eog's approach
[05:59] <persia> I don't even have a menu item for eog, which annoys me when I want to launch it to browse some specific directory for which nautilus navigation would take a long time.
[05:59] <crimsun> OTOH, there's a use case I need to consider: user installs pavucontrol and scratches his/her forehead, "where's that darned menu entry?"
[05:59] <crimsun> (and yes, there're plans to overhaul the UI for the PA tools, but that's unlikely to land in 8.04)
[06:00] <crimsun> same use case applies to paman and pavumeter
[06:00] <crimsun> it does not, however, apply to padevchooser, since this last package will grab the others
[06:00] <persia> Wouldn't most users want padevchooser?  I don't understand the use case for one of paman, pavucontrol or pavumeter without this.
[06:00] <crimsun> well, the most likely case I foresee is that _only_ pavucontrol gets promoted to main and shipped with desktop
[06:01] <persia> Ah.  If that is the plan, then pavucontrol needs a .desktop entry.  Hmm.
[06:02] <persia> s/.desktop/menu/
[06:06] <crimsun> yeah, I'll just add "NoDisplay=true" to desktop* for now
[06:06] <crimsun> presently, it's just a damned mess
[06:06] <persia> I agree it's a mess.  If none of them appear in the menu, and padevchooser isn't in the session by default, how do users control their volume?
[06:07] <crimsun> through mixer_applet per usual
[06:07] <crimsun> they won't have stream-migrating abilities through it, though
[06:08] <crimsun> (which reminds me of amitk's plans for integrating troubleshooting into gnome-media, but that's another issue altogether)
[06:09] <persia> So for hardy, we'll include the new sound server (as esd is just plain cruft), but not expose the tools to manipulate it by default, preserving the current interface.  Then for hardy+1, the new upstream interface is released, and users can take advantage of the new tool by default?  That sounds sane.
[06:09] <crimsun> that's the hope.
[06:10] <crimsun> people are going to want padevchooser, though, I think.
[06:10] <persia> I expect.  Why can't that go to main and -desktop?
[06:11] <crimsun> it can, it's just a bit less likely than just pavucontrol
[06:11] <crimsun> I suppose it really just requires some effort for the MIRs
[06:12] <crimsun> need to run the ideas past pitti, though
[06:12] <persia> If there's no blockers on the MIRs, I don't see why it shouldn't be promoted.  Whether it goes into -desktop or not is another issue.
[06:12] <crimsun> or ted.  Hmm.
[06:31] <RAOF> Hm.  Where should a request for a 32bit pulseaudio alsa plugin go?  ia32-libs or alsa-plugins?
[06:32] <crimsun> both.
[06:32] <crimsun> and - UGH.
[06:33] <persia> crimsun: Didn't you have an alternative for libflashsupport in the works?
[06:33] <crimsun> persia: I didn't, no.  Debian has flashplugin-nonfree-pulse (in git)
[06:34] <crimsun> the version of libflashsupport currently in hardy is simply my GnuTLS hack on top of Fedora's git package by Lennart.
[06:35] <crimsun> Debian's flashplugin-nonfree-pulse does not support OSS, OpenSSL, GnuTLS, or ALSA - only pulse.
[06:40] <TheMuso> crimsun: Did you by chace read my core-dev app? I know you didn't respond to it, but thought you may have seen it. Since you are withdrawing from the community, one of my plans for core dev was to eventually keep the audio effort up, at least in userspace...
[06:40] <TheMuso> chance
[06:40] <TheMuso> ugh keyboad
[06:40] <TheMuso> c
[06:44] <crimsun> TheMuso: I've read the thread now (beginning with https://lists.ubuntu.com/archives/motu-council/2007-December/000659.html).  Did you have something(s) specific?
[06:48] <TheMuso> crimsun: Well, alsa-utils, -lib, and pulse stuff in main. As I said in that post, I'll gradulally work my way into it, first with bugfixes, and as I get to know them better, and see what Debian is doing as well as upstream etc, I'll be will ing to take more on
[06:48] <crimsun> TheMuso: ok, best of luck!
[06:49] <TheMuso> crimsun: thanks
[06:49] <TheMuso> crimsun: I just thought I'd tell you, as if you are ever around, I may be asking questions.
[06:49] <crimsun> TheMuso: sure, anytime.
[06:49] <TheMuso> ok
[06:49] <TheMuso> thanks
[07:01] <Hobbsee> ScottK: rofl!
[07:01] <Hobbsee> ScottK: i'm liking your and Burgundavia's discussion on LP
[07:05] <somerville32> link?
[07:05] <Hobbsee> was a couple of days ago, in here
[07:07] <persia> timestamp?
[07:09]  * Hobbsee doesn't have that part of the backscroll now
[07:09] <Hobbsee> persia: the one about how it's entirely obvious how to use LP, and the LP devs will be happy to show you how you're supposed to be doing ubuntu development on LP
[07:09] <Hobbsee> it was just very nicely worded
[07:09] <persia> Oh yes.  That was perfect phrasing :)
[07:17] <\sh> moins
[08:01] <desrt> somerville32; yo
[08:06] <desrt> somerville32; i got your email.  i googled around and found the LP bug and left a comment there.
[09:23]  * Hobbsee waves
[09:29] <amarillion> Good morning
[10:30] <LucidFox> https://launchpad.net/ubuntu/+source/d3lphin <-- What's the point of this?
[10:31] <LucidFox> Especially since there is https://launchpad.net/ubuntu/+source/dolphin
[10:31] <LucidFox> which is basically the same thing
[10:34] <geser> LucidFox: looks like it was renamed: Rename package to d3lphin - New dolphin project for KDE3 (from the changelog)
[10:34] <geser> LucidFox: Debian has dolphin now only in stable
[10:35] <LucidFox> so, it was autosynced before DIF and nobody caught it?
[10:35] <persia> One of those should likely be removed, no?
[10:35]  * Hobbsee wonders what this is about
[10:36] <geser> Hobbsee: about dolphin/d3lphin
[10:36] <Hobbsee> one's for kde3, the other is for kde4.  what's the problem?
[10:36] <LucidFox> actually, no
[10:36] <LucidFox> dolphin in Ubuntu is actually d3lphin
[10:36] <LucidFox> for KDE3
[10:36] <Hobbsee> LucidFox: correct.  and?
[10:37] <persia> Hobbsee: Are they supportable in parallel?
[10:37] <LucidFox> then perhaps one of them should be removed, and the other should have a transitional package
[10:37] <Hobbsee> persia: yes
[10:37] <Hobbsee> LucidFox: no.  would you replace kde3 with kde4, and stick kde3 as a transitional package?
[10:37] <LucidFox> erm
[10:37] <Hobbsee> persia: well, as supported as d3phin ever was.
[10:38] <Hobbsee> (which was only by it's authors)
[10:38] <\sh> afaik, dolphin for kde3 is separated from kdebase3 and dolphin in kde4 is the default in kdebase, but I could be wrong
[10:38] <LucidFox> the Ubuntu source package "dolphin" contains d3lphin
[10:38] <persia> LucidFox: KDE3 + KDE4 is special for hardy.  It's a parallel support.  Usually we don't support that, but for this case we will.
[10:38] <geser> Hobbsee: both dolphin and d3lphin are for kde3? or is one for kde4?
[10:38] <LucidFox> and the Ubuntu source package "d3lphin" _also_ contains d3lphin
[10:38] <Hobbsee> geser: d3phin is for kde3, hence the 3.  dolphin itslef is a kde4 thing
[10:39] <LucidFox> dolphin-kde4 is provided by kdebase-kde4
[10:39] <LucidFox> not by any of these two packages
[10:39] <\sh> well
[10:39] <\sh> LucidFox: is correct
[10:39] <Hobbsee> oh, hang on
[10:39] <Hobbsee> this is strange naming
[10:39] <\sh> dolphin is ubuntu package from tonio
[10:39]  * persia agrees with Lucidfox
[10:39] <\sh> and d3lphin is synced from debian looks like...both are the same
[10:40] <geser> Hobbsee: when I look at https://edge.launchpad.net/ubuntu/+source/dolphin the changelog mentions "Rebuild with kdesdk-script 4:3.5.8-1ubuntu6" so it looks like kde3 for me
[10:40] <\sh> well ours has more b-ds ,-)
[10:40] <\sh> geser: this is not important...kdelibs4-dev is important, which is kde3 , kde4 would be kdelibs5
[10:41] <Hobbsee> er, actually looking at the descriptions, not the naming, d3lpin would appear to be the debian package, dolphin source would be hte kde3 package, which is in main anyway, and dolphin for kde4 seems to be in kdebase-kde4
[10:43] <Hobbsee> therefore, it would make sense for the kubuntu people to merge dolphin with d3lphin as far as possible, and keep it there.
[10:44] <LucidFox> And if they're merged into dolphin, blacklist d3lphin from autosync?
[10:44] <\sh> this is a mess.
[10:45] <\sh> the project is named d3lphin...so debian is right...
[10:45] <Hobbsee> i think so.  but it may be able to get all of our patches back into debian for that, then sync it
[10:46] <Hobbsee> \sh: yeah.  i've no idea why they named it otherwise...
[10:46] <LucidFox> The problem seems to be that d3lphin was uploaded into Gutsy over the defunct Dolphin KDE3 branch, even though it's technically a fork
[10:46] <LucidFox> and it happened after DIF
[10:47] <LucidFox> (for Gutsy)
[10:47] <Hobbsee> erm...
[10:47] <LucidFox> in the meantime, Debian made their own package for d3lphin
[10:47] <LucidFox> which got autosynced in Hardy
[10:47] <\sh>   * Rename package to d3lphin - New dolphin project for KDE3. Add dolphin
[10:47] <\sh>     as a dummy package to ease the transition.
[10:47] <Hobbsee> i don't see the relevance of it being a fork, as such
[10:47] <\sh> that was for d3lphin (0.9.1-1) unstable; urgency=low
[10:48] <\sh> dolphin was the orignal name of the package until then
[10:48] <LucidFox> Ah.
[10:48] <Hobbsee> \sh: presumably ours never merged again, for some reason
[10:49] <LucidFox> I think it makes sense to merge into d3lphin and make dolphin transitional, to reduce divergence from Debian
[10:49] <\sh> Hobbsee: because we always worked with the upstream tarball (0ubuntuX versions)
[10:49] <\sh> Hobbsee: we never synced from debian
[10:50] <\sh> well it makes more sense to pull the changes from debian svn into kubuntu bzr and track those changes
[10:51] <Hobbsee> \sh: i doubt upstream will release again
[10:51] <LucidFox> Why not?
[10:51] <Hobbsee> because kde4 is out?
[10:51] <Hobbsee> and there are only a couple of developers on it anyway, iirc
[10:51] <persia> I thought there was another couple KDE3 releases planned to support SuSE
[10:53] <LucidFox> On an unrelated note, Hobbsee, could you please rerun the build process for https://launchpad.net/ubuntu/+source/inkblot/0.99.9-0ubuntu1 ?
[10:53]  * \sh is also stuck and fcked with galculator...
[10:54] <\sh> ubuntu mobile developers applied some hildon patches, especially for glade...and new upstream version is there...but no updated glade interfaces...
[10:54] <\sh> I could break the mobile stuff and remove the patch and merge new upstream only...and never think of hildon again
[10:54]  * Hobbsee wonders why that failed to upload
[10:55] <\sh> if this is not going to change that we can work together in a cool way, this different ubuntu releases will be the death
[10:56]  * \sh doesn't even know what a hildon device is...I though first, they were talking about a second life mobile device which is totally virtual ,-)
[10:56] <Hobbsee> \sh: speak to StevenK or mithrandir or someone who's on the mobile team about htat
[10:56] <Hobbsee> \sh: it may be that they've forgotten, or something
[10:57]  * persia points at http://live.gnome.org/Hildon for people interested in hildon
[10:57] <\sh> Hobbsee: galculator is universe...I think it#
[10:57] <\sh> i
[10:57] <\sh> t
[10:57] <\sh>  
[10:57] <\sh> j
[10:57] <\sh> u
[10:57] <\sh> Hobbsee:
[10:57] <\sh> Hobbsee:
[10:57] <\sh> f
[10:57] <\sh> c
[10:57] <\sh> k
[10:57] <Hobbsee> ?
[10:58] <persia> \sh: Are you ok, or was that a final reflex action?
[11:08] <emgent> hello there
[11:08] <ChrisGibbs> gday all
[11:08] <\sh> Hobbsee:
[11:08] <\sh> Hobbsee:
[11:08] <Hobbsee> \sh: hmmm?  all on one line?
[11:09] <jsgotangco> hello
[11:09] <persia> jsgotangco: Hi!
[11:12] <emgent> hi jsgotangco
[11:12] <persia> OK.  Who's up for a review?  There's three candidates already advocated that need sometime to upload.
[11:13] <persia> Who has a package that needs a review?
[11:13] <mok0> me
[11:13] <persia> mok0: Which one?
[11:13] <mok0> gpp4 and mmdb
[11:13] <persia> (and where's the standard advertisement?)
[11:13] <emgent> me too (merge)
[11:13]  * mok0 loads revu page
[11:14] <mok0> http://revu.ubuntuwire.com/details.py?package=gpp4
[11:14]  * persia takes gpp4
[11:15] <mok0> emgent: hehe beat you to it
[11:15] <emgent> :)
[11:17] <persia> mok0: Can you expand a bit on how gpp4 fixes bug #176211 ?
[11:17] <ubotu> Launchpad bug 176211 in ubuntu "[needs-packaging] coot" [Wishlist,Incomplete] https://launchpad.net/bugs/176211
[11:17] <mok0> persia: errr, its a dendency of coot
[11:18] <persia> OK.  Is the plan to open a task against gpp4 when the bug closes, keeping it closed, and open a new empty task for coot itself?
[11:18] <mok0> coot is based on several libraries that need to go in first
[11:18] <mok0> persia: I don't understand what you mean
[11:19] <mok0> I opened a needs-packaging bug against all of them
[11:19] <persia> mok0: I'm just thinking about bug tracking.  Either gpp4 should get it's own bug, or you'll need to do task management tracking.
[11:20] <mok0> gpp4 has its own bug AFAIR
[11:20] <persia> In that case, the changelog is wrong :)
[11:20] <mok0> could be a wrong bug number?
[11:20]  * mok0 checks
[11:21] <mok0> launchpad takes forever to load...
[11:21] <mok0> bug #176209
[11:21] <ubotu> Launchpad bug 176209 in ubuntu "[needs-packaging] gpp4" [Wishlist,Incomplete] https://launchpad.net/bugs/176209
[11:22] <\sh> grmpf damn fcking kde4
[11:22] <\sh> kde3 konversation is starting a kde4 konqui...and all carriage returns you ever can imagine are fcking around with the complete gnome desktop
[11:22]  * persia thinks that's RC
[11:23]  * persia dislikes this new proposed debian/changelog format
[11:24] <\sh> persia, hmm?
[11:24] <mok0> persia: yuc I put the wrong bug number in changelog
[11:25] <persia> \sh: e.g. http://revu.ubuntuwire.com/revu1-incoming/gpp4-0801110100/gpp4-1.0.4/debian/copyright  The idea is to use RFC822-style to make it machine readable.  In my opinion, it makes it less pleasant for humans, and RCF822 is deprecated anyway.
[11:25] <pochu> persia: you meant debian/copyright, right?
[11:26]  * pochu waves, btw :)
[11:26] <persia> pochu: Yes.  Thank you.
[11:26] <persia> mok0: Have you already uploaded the new one, or should I comment?
[11:27] <mok0> I didn't upload, might as well fix everything before upload
[11:28] <persia> Why is NEWS interesting to end users?
[11:28] <mok0> It's not
[11:28] <persia> mok0: Then it doesn't belong in the binary package :)  Same for AUTHORS (duplicate of debian/copyright).
[11:29] <mok0> persia: right
[11:30] <mok0> persia: removed AUTHORS and NEWS from debian/doc
[11:30] <persia> mok0: OK.  Watch file?
[11:30] <mok0> made one yesterday
[11:31] <mok0> will be in next upload
[11:31] <persia> mok0: Huge arch:any /usr/share.  You want libgpp4-0, libgpp4-dev, and libgpp4-0-common (or similar).
[11:32] <persia> Maybe common-dev?  Anyone else have a suggestion?
[11:32] <mok0> persia: those are data files that are _always_ needed
[11:33] <persia> mok0: Right, but do we need 10 copies in the archive?  Put them in a arch:all package, and add a Depends to make sure they get installed.
[11:33] <mok0> persia: ok, I didn't think of archive space
[11:33] <mok0> persia: will do
[11:34] <persia> mok0: Last one is that lintian doesn't like your doc-base file.
[11:34] <persia> OK.  Who's next?
[11:35] <mok0> persia: I don't have a running hardy system, only a pbuilder, so I haven't seen that lintian warning
[11:35] <persia> mok0: pbuilder --login?
[11:35] <mok0> persia: right...
[11:36] <persia> mok0: It's your lucky day.  No other advertisements.  What was your other package?
[11:36] <mok0> mmdb
[11:38] <mok0> bug 176218
[11:38] <ubotu> Launchpad bug 176218 in ubuntu "[needs-packaging] mmdb" [Wishlist,Incomplete] https://launchpad.net/bugs/176218
[11:40] <mok0> persia: should those bugs now have status "In Progress"?
[11:41] <persia> mok0: Better to put the bug in the changelog than in IRC, no?  And yes, the bugs should be "In Progress" if you've a candidate on REVU.
[11:41] <mok0> persia: closed bug in mmdb's changlog
[11:42] <persia> mok0: Past or now?
[11:42] <mok0> persia: editing files as we speak
[11:43] <persia> mok0: libmmdb0 description needs some deletion: likely doesn't contain the header files.
[11:46] <persia> mok0: watch file fails " In debian/watch no matching files for watch line"
[11:46] <mok0> persia: hmm
[11:47] <persia> mok0: There's an annoying patch to CDBS that makes me encourage the use of DEB_INSTALL_CHANGELOGS_ALL
[11:48] <mok0> persia: what's annoying about it?
[11:48] <persia> mok0: Upstream changelogs are silently dropped from all CDBS packages by default.
[11:49] <persia> mok0: Last note: fails the long-description-contains-short-description test
[11:49] <mok0> persia: huh? Weird
[11:49] <mok0> persia: ok, thanks a lot
[11:49] <persia> Does anyone else have a package ready for review?
[11:51] <stgraber> persia: http://revu.ubuntuwire.com/details.py?package=libfprint will appear on revu at the next update (so it'll be there when I get back from lunch :))
[11:52] <\sh> geser, ping resolvconf...what do you say to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431181 to get rid of the diff between ubuntu and debian?
[11:52] <persia> stgraber: Poke me when you get back, and I'll take a look.
[11:52] <ubotu> Debian bug 431181 in resolvconf "resolvconf: Please replace abuse of /dev/shm with /lib/init/rw and /var" [Important,Fixed]
[11:59] <geser> \sh: do we have /lib/init/rw in Ubuntu? I don't have it here
[11:59] <persia> geser: I don't have it either.  Have you checked Contents.gz in gutsy?
[12:02] <\sh> geser, well, I wonder what magic we have in initramfs ;)
[12:02] <geser> persia: packages.u.c lists no /lib/init/rw for gutsy
[12:03] <persia> geser: Then I say we probably don't have it.
[12:04] <\sh> geser, ok...so let's stay with our patch :)
[12:05] <StevenK> \sh: Hrm, what now?
[12:06] <stgraber> persia: I'm here and the package is on revu
[12:06] <\sh> StevenK, well, the less diffs we have between ubuntu and debian the better for us..and this diff could have saved us work....
[12:06] <persia> stgraber: URL?
[12:07] <pochu> stgraber: you know there's an ITP for it in Debian? Debian bug #460493 and Debian bug #460495
[12:07] <ubotu> Debian bug 460493 in wnpp "ITP: libfprint -- fingerprint library of fprint project" [Wishlist,Open] http://bugs.debian.org/460493
[12:07] <ubotu> Debian bug 460495 in wnpp "ITP: pam-fprint -- PAM module allowing authentication via fprint" [Wishlist,Open] http://bugs.debian.org/460495
[12:07] <stgraber> pochu: Date: Sun, 13 Jan 2008 05:27:04 UTC :)
[12:08] <\sh> oh wait
[12:08] <StevenK> \sh: Sorry, I've been out for a while, I'll need more information -- all I saw was Hobbsee's message in my away log.
[12:08] <\sh> StevenK, ah ming was already resolved :)
[12:08] <stgraber> pochu: I started packaging on the 6th, so no I didn't know :)
[12:09] <\sh> geser, did you read in this resolvconf bug report about the selinux refpolicy change?
[12:10] <StevenK> \sh: Fair enough.
[12:11] <pochu> stgraber: I saw the two ITPs on debian-devel@ this morning :)
[12:12] <pochu> stgraber: you might want to contact the owner of the ITP to share the work and collaborate, so I pointed it out to you :)
[12:12] <persia> stgraber: Based on the debian reports, I see two packages.  Is there something else to go with bug #179923, or are you planning to track tasks for this bug?
[12:12] <\sh> well...so stop for today...
[12:13] <ubotu> Launchpad bug 179923 in ubuntu "[needs-packaging] fprint" [Wishlist,In progress] https://launchpad.net/bugs/179923
[12:13] <geser> \sh: no, but I checked now the version of sysvinitrc in Ubuntu (2.86.ds1-14.1ubuntu32) and /lib/init/rw was introduced in 2.86.ds1-23, so we can't use it
[12:13] <emgent> geser, cool. i have merge ready
[12:13] <\sh> geser, oh fun...refpolicy needs it (which is also in ubuntu)
[12:14] <persia> stgraber: bashism in libfprint0-dev.install
[12:15] <persia> stgraber: You're repacking the original tarball, but don't have a get-orig-source rule.
[12:16] <\sh> geser, you know, it's a mess when packages are synced or merged without understanding the impacts...when you read the refpolicy changelog, you know we need to use /lib/init/rw in some cases, because it's manufactured for debian..and ubuntu is a bit behind of the recommended way of doing things...
[12:17] <persia> stgraber.  You also missed debian/changelog in the binary packages.
[12:17] <persia> Next?
[12:18] <\sh> anywayys.../me needs to take care of wife...
[12:19] <mok0> persia, I can't reproduce the watch file error you found
[12:20] <persia> mok0: Which package?
[12:20] <mok0> mmdb
[12:21] <mok0> persia: 33 minutes ago
[12:22] <persia> mok0: http://paste.ubuntu.com/3514/
[12:24] <mok0> persia: can you see the machine ftp.bioxray.au.dk?
[12:24] <mok0> persia, uscan --report-status works for me
[12:25] <DktrKranz> StevenK, regarding bug 182142, do you think using "[ -f /etc/dbus-1/event.d/30ppmd ] && /etc/dbus-1/event.d/30ppmd start" is enough?
[12:25] <ubotu> Launchpad bug 182142 in ppm "Trying to execute /etc/dbus-1/event.d/30ppmd in preinst, but it is still not available" [Medium,Confirmed] https://launchpad.net/bugs/182142
[12:26] <persia> mok0: Does the server maybe check the client?  uscan doesn't pass one.
[12:26] <persia> mok0: I only have issues with uscan,  Other tools work fine.
[12:26] <geser> DktrKranz: I didn't check, but why should one start a service before the files are there?
[12:27] <mok0> persia: I will check the logs on the ftp server
[12:27] <DktrKranz> geser, probably because we want it to be stopped during an upgrade
[12:27] <persia> mok0: I'll keep the unpacked source around to scan on demand.
[12:28] <geser> DktrKranz: shouldn't the service be started then in postinst? when the package is really installed?
[12:29] <mok0> persia: what's your IP number?
[12:30] <mok0> persia: n/m checks w. irc
[12:30] <persia> heh.  Better :)
[12:30] <DktrKranz> geser, sound reasonable, but I don't know the package and why it tries to start ppmd during preinst, so I'm not confident with it
[12:41] <Amaranth> It should be stop on prerm and start on postint
[12:41] <Amaranth> err, postinst
[12:45] <juliank> (LP: #182520) industrial-icon-theme is at: http://revu.tauware.de/details.py?package=industrial-icon-theme
[12:48] <broonie> geser: I have had a more detailed look at that aqsis bug - it looks to be at least partly aqsis' fault; it's replacing hte SCons-supplied Install and InstallAs methods.
[12:49] <persia> juliank: If you're going to use the new copyright format, consider X-Format-Specification, and X-Debianized-By.  See http://revu.ubuntuwire.com/revu1-incoming/gpp4-0801110100/gpp4-1.0.4/debian/copyright for an example.
[12:49] <persia> Also, the last paragraph doesn't match RFC822 requirements.
[12:49] <geser> broonie: thanks for looking
[12:53] <broonie> geser: http://scons.tigris.org/issues/show_bug.cgi?id=1884 is a (rather badly reported) upstream bug.
[12:55] <broonie> See also http://bugs.debian.org/458849; as I said the other day there's also a preexisting FTBFS for aqsis in Debian which has not had any response so I'm not convinced that resolving the immediate problem will help.
[12:58] <stgraber> persia: thanks for the review, about the get-orig-source, do you have a simple example of how to just bzip2 -d and gzip -9 the upstream tarball ?
[13:02] <pochu> crimsun: since this morning I can't play music. Totem and Rhythmbox will crash if I try to play any file. Might this be related to the alsa updates of yesterday? See bug #182443
[13:02] <persia> stgraber: https://wiki.ubuntu.com/PackagingGuide/Basic#head-4bb01b3c07548aaf98e85ac7eb7983e632f8eb38 has one
[13:02] <ubotu> Launchpad bug 182443 in totem "totem-plugin-viewer crashed with SIGSEGV in strncpy()" [Medium,Incomplete] https://launchpad.net/bugs/182443
[13:02] <persia> pochu: Did you run alsaconf set-default-card yet?
[13:02] <pochu> Nope. Should I?
[13:02] <persia> pochu: There should even be a little informative widget on your desktop with a notification telling you to do so.
[13:03] <pochu> There wasn't any.
[13:03] <pochu> Shouldn't that be called in postinst?
[13:03] <persia> Strange.  I got one.
[13:03] <pochu> Maybe I missed it :)
[13:03] <persia> Do you use GNOME or KDE?
[13:03] <Hobbsee> xfce!
[13:04] <pochu> GNOME. Maybe it dissapeared after a panel crash due to some builds
[13:04] <persia> pochu: Apply nenolod's patch :)
[13:04] <pochu> I think I'll do it, since it's accepted upstream ;)
[13:04] <pochu> But I'll ask seb128 first.
[13:05] <pochu> Since he has do upload it :)
[13:05] <pochu> s/do/to/
[13:05] <pochu> And why not call that in postinst?
[13:05] <persia> pochu: I meant locally.  It will get uploaded later, but why wait for the next package refresh?  Also, notification is better than postinst because it works in an all-gui environment.
[13:06] <pochu> $ alsaconf set-default-card
[13:06] <pochu> bash: alsaconf: command not found
[13:06] <broonie> pochu: You need to be root (sudo /usr/sbin/alsaconf ...)
[13:07] <pochu> persia: applying it locally will only benefit myself, while uploading to the archive will benefit all the devs ;)
[13:07] <pochu> broonie: oh, ty
[13:07] <pochu> Really? Not found...
[13:08] <juliank> persia: mok proposed these X-* lines less than 24 hours ago. I want to do it the way Sam Hocevar does. Once mok's proposal has been discussed and accepted, this may change.    - see http://packages.debian.org/changelogs/pool/main/m/monsterz/current/copyright
[13:08] <juliank> s/may/will
[13:08] <pochu> dpkg -S alsaconf | grep bin gives nothing
[13:09] <persia> pochu: I agree pushing to the archive is nicer, but seb127 has to upload, and already plans to.  No point having the pain locally if you can avoid it while waiting.
[13:09] <pochu> asoundconf?
[13:10] <persia> juliank: I really don't like anything going into the Ubuntu archives without information indicating who is licensing it to Ubuntu.  This is especially true as Ubuntu changelogs get dropped when it goes to Debian, so the original packager (and person licensing it to the distribution) is lost.  That's one of the reasons I don't like the new format.
[13:10] <pochu> Yeah that's the one
[13:10] <persia> pochu: Right asoundconf.  Sorry.
[13:11] <mok0> juliank: ... and which is why I think the "X-" lines are pretty nifty
[13:12] <pochu> I still got the crashes after running 'asoundconf set-default-card Intel' both as normal user and as root
[13:12] <persia> I also had to restart alsa from the init script (but I have to do that every boot anyway, so it might just be me)
[13:13] <mok0> persia, juliank: I put them in the wiki at the request of Charles Plessy; he liked to proposal
[13:14] <persia> juliank: Even aside from whether it indicates who licenses the package, your debian/copyright isn't in RFC822 format
[13:14] <juliank> mok0, persia: The original packager has to be kept if files are kept. When the package gets into Debian, the new maintainer has to keep the copyright part from the Ubuntu history.
[13:15] <juliank> persia: It's part of the proposal "Also, it is important to allow any form of free text in the file, be it before or after the machine-interpretable part."
[13:16] <persia> juliank: You're conflating copyright and licensing.  For many packages, the contents of debian/ are a shared work, based heavily on the work of previous packages, and licensed as shared.  The holder of copyright for this may not be the person providing the license to the distribution to use the files.
[13:21] <juliank> persia: But we have 'Files: *' and 'Files: debian/*', one for upstream files, one for debian files. BTW, even readahead-list was accepted without any information about debian/* in its copyright file: http://changelogs.ubuntu.com/changelogs/pool/main/r/readahead-list/readahead-list_0.20050517.0220-0ubuntu11/copyright
[13:23] <persia> juliank: You are again conflating the copyright holder for debian/ and the person who is extending the licensed work to the distribution.  These aren't always the same.  Anyway, I don't consider another package not matching my tests to be sufficient reason to lower them.  You may find another reviewer less strict.
[13:23] <pochu> persia: I'll reboot to see if it fixes it. Restarting alsa-utils didn't help.
[13:24] <persia> pochu: Rebooting shouldn't do anything restarting alsa-utils didn't do (unless you have a new kernel or libc or something).
[13:28] <pochu> persia: lol, it works now. But the notification has appeared after the reboot! o.O Maybe I did upgraded it this morning too, since there were 3 uploads.
[13:28]  * pochu looks at dpkg.log
[13:30] <pochu> Yeah, I updated alsa-utils and libc6 a couple of hours ago :/
[13:30] <pochu> Anyway it's fixed now. Sorry for the noise though.
[13:39] <josesanch> persia: Hello. Today is revu day.. what means?
[13:40] <Hobbsee> means that it's the day for me to avoid irc.
[13:41] <josesanch> hehe.. But means that motus are reviewing packages? it isn't?
[13:41] <effie_jayx> lol @ Hobbsee  dodging IRC
[13:42] <Hobbsee> josesanch: yes.  which means that it's a very good time to play inactive, if you don't want to review anything :)
[13:42] <zul> Hobbsee: it is the weekend afterall :)
[13:42] <Nafallo> Hobbsee: you fail in that regard ;-)
[13:43] <Hobbsee> zul: i'ts monday now :(
[13:43]  * Hobbsee has to go to work today, too :(
[13:44] <zul> Hobbsee: well sucks to be you then :)
[13:45] <Hobbsee> it does.  it does
[13:45] <Hobbsee> so, when's shooting people beocme legal?
[13:45] <stgraber> persia: updated package on revu http://revu.ubuntuwire.com/details.py?upid=1228
[13:47]  * pochu just got greasemonkey working in FF3 :)
[13:48] <Hobbsee> pochu: it always worked, didn't it?
[13:50] <pochu> If you change maxVersion from 2.0.0.* to something like 3.0.1.* then yes ;)
[13:54] <mok0> What is the standard suffix for a documentation package? I see both *-doc and *-docs packages
[13:55] <pochu> I think -doc
[13:57] <StevenK> steven@liquified:~% apt-cache search doc | grep -ce '-doc '
[13:57] <StevenK> 907
[13:57] <StevenK> steven@liquified:~% apt-cache search doc | grep -ce '-docs '
[13:57] <StevenK> 29
[13:58] <mok0> StevenK: Heh, that settles it :-)
[13:58] <StevenK> You'll use -docs then, since it's the underdog?
[13:58] <mok0> underdoc ;-)
[13:59] <StevenK> Wah!
[13:59]  * StevenK pelts mok0 with rotten vegetables
[13:59]  * mok0 docs
[13:59] <StevenK> And it gets worse
[14:00] <mok0> ... and that's a doc'ed fact
[14:21] <josesanch> Anyone want to review my package? http://revu.tauware.de/details.py?package=gnomecatalog
[14:30] <mok0> getting a weird error message from dpkg-gencontrol: http://paste.ubuntu.com/3524/
[14:31] <DktrKranz> mok0, missing comma
[14:32] <mok0> DktrKranz: I did not put libc in there.
[14:32] <mok0> Depends: dpkg
[14:32] <mok0> (because an empty Depends: also croaks)
[14:32] <StevenK> mok0: Paste the Depends line from the source?
[14:32] <DktrKranz> if Depends: is empty, you should omit it
[14:33] <StevenK> Right. Depends is perfectly sensible to omit in certain circumstances
[14:34] <mok0> It's a package of text files. The other has .html docs
[14:36] <mok0> Arrrrrg. Forgot comma :-/
[14:45] <josesanch> Can i help reviewing any package?
[15:07] <the_belgain> hi there, i've created a package which i'd like to get reviewed
[15:07] <the_belgain> this is my first one, should i upload it straight to REVU or get someone here to take a look over it first?
[15:07] <Hobbsee> persia: clearly you need to review faster!
[15:07] <Hobbsee> the_belgain: go straight to REVU, then give the link here
[15:09] <the_belgain> ok, thanks - i've just added myself to the universe contributors team - do i need someone here to resync the REVU uploaders keyring?
[15:09] <mok0> persia: what's this about rfc822 being deprecated?
[15:18] <juliank> Bazaar, Git, Mercurial: small benchmark and branch sizes at http://jak-linux.org/tmp/vcs-performance.pdf
[15:18] <LucidFox> the_belgain> I think the keyring is automatically resynced at certain times, but you can ask for it to be synced immediately
[15:18] <the_belgain> i've uploaded a package and it seems to have worked fine
[15:19] <the_belgain> ah, looks like i might have spoken too soon - i can't log into the REVU page with my email address
[15:20] <LucidFox> the_belgain> Normally, packages appear on REVU at most within ten minutes of upload - on even minutes
[15:21] <LucidFox> That is, hh:10, hh:20, etc.
[15:21] <the_belgain> they should all appear on the frontpage then?
[15:22] <LucidFox> If REVU accepts your key, then yes
[15:23] <LucidFox> What is the package name? (Disclaimer: I'm not a MOTU.)
[15:24] <the_belgain> dput reported that the upload was successful, so i assume it's gone in: http://paste.ubuntu-nl.org/51776/
[15:24] <the_belgain> fuppes
[15:24] <LucidFox> Wait until 15:30 UTC
[15:25] <sistpoty> hi folks
[15:25] <LucidFox> sistpoty> Welcome
[15:26] <sistpoty> hi LucidFox
[15:34] <LucidFox> the_belgain> Apparently it didn't upload
[15:34] <LucidFox> Could you check your mail?
[15:35] <the_belgain> yeah, it doesn't seem to be there
[15:35] <the_belgain> nothing in my mail yet
[15:35] <jpatrick> there are some problems with uploads disappearing
[15:37] <LucidFox> jpatrick> Could it be because the keyring hasn't been resynced?
[15:38] <the_belgain> shall i just give it 24 hours and reupload it tomorrow?
[15:38] <sistpoty> problems uploading to revu?
[15:39] <jpatrick> LucidFox: what are we talking revu or ppa?
[15:39] <LucidFox> REVU
[15:39] <mok0> sistpoty: seems rather slow
[15:39] <josesanch> ppa is not working for me
[15:39] <sistpoty> mok0: sparky is not the fastest box :/
[15:40] <mok0> sistpoty: what is it?
[15:40] <mok0> sparc?
[15:40] <josesanch> but revu works for me
[15:40] <sistpoty> mok0: cpu             : TI UltraSparc IIi (Sabre)
[15:40] <guest22> Any MOTUs here willing to review package photoml (http://revu.tauware.de/details
[15:40] <guest22> .py?package=photoml)? It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
[15:40] <sistpoty> LucidFox, the_belgain: what package didn't make it to revu?
[15:41] <guest22> Oops, that URL should be http://revu.tauware.de/details.py?package=photoml
[15:42] <LucidFox> sistpoty> fuppes
[15:42] <LucidFox> the_belgain> Are you sure you uploaded the .changes file?
[15:44] <sistpoty> the_belgain: it's there but got rejected... I'll import your key and give it back in a few minutes
[15:45] <sistpoty> the_belgain: should appear on revu with the next cron run
[15:46] <the_belgain> hi, sorry i'm back
[15:47] <the_belgain> so did it get rejected because my key hadn't made it in yet? in which case should i try tomorrow?
[15:47] <the_belgain> or is the package already queued until the next cron run?
[15:48] <josesanch> Any MOTUs would review my package? http://revu.tauware.de/details.py?package=gnomecatalog
[15:49] <pochu> We need a lintian update in REVU :)
[15:49] <sistpoty> the_belgain: your key wasn't synced yet... I imported your key and put the package back in the incoming queue, so it should appear any minute now ;)
[15:49] <the_belgain> great, cheers
[15:51] <sistpoty> the_belgain: it's on revu now ;)
[15:53] <the_belgain> excellent - this is my first package; does anyone fancy taking a look?
[15:53] <mok0> When I install sbuild, it creates an entry in /etc/group, but the gid is already assigned to a user.
[15:55] <mok0> the_belgain: I am not a MOTU, but I can take a quick look
[15:55] <the_belgain> that would be helpful, thanks
[15:56] <mok0> the_belgain: in debian/rules, get rid of the boilerplate comments at the top
[15:56] <the_belgain> incidentally, one of the things i was unsure about was that some of the runtime dependencies i had to add manually myself (see the debian/control file) as they weren't picked up by dh_shibs
[15:57] <mok0> the_belgain: I'll get to control in a minute
[15:57] <mok0> the_belgain: in rules, in the clean rule, use the construction suggested by lintian
[15:58] <josesanch> the_belgain: build-depends in libfaad2-dev witch is replaced by libfaad-dev
[15:58] <mok0> the_belgain: in rules, get rid of the commented # dh_* lines
[16:00] <mok0> the_belgain: in copyright, get rid of the line "<Put the license..."
[16:02] <josesanch> the_belgain: distclean gives an error http://paste.ubuntu.com/3525/
[16:02] <mok0> the_belgain: in control, wrap lines so they display nicely in 80 chars
[16:03] <the_belgain> josesanch: is libfaad-dev introduced in hardy?  on gutsy i there doesn't seem to be a libfaad-dev in synaptic?
[16:03] <josesanch> Yes.. in hardy there isn't libfaad2-dev
[16:03] <mok0> the_belgain: I think section:multiverse is wrong
[16:04] <the_belgain> i thought it needed to be multiverse because it pulls in lame, which is in multiverse?
[16:05] <LucidFox> the_belgain> yes, libfaad-dev is introduced in hardy
[16:05] <LucidFox> libfaad2-dev was removed from hardy
[16:05] <the_belgain> new packages should be build against hardy right - should i dist upgrade my pbuilder environment then?
[16:05] <josesanch> in changelog fuppes (0+svn578-1) should be fuppes (0+svn578-0ubuntu1)
[16:06] <mok0> the_belgain: just make a hardy pbuilder. If you're smart, you can have several side-by-side
[16:06] <mok0> the_belgain: you don't distupgrade a pbuilder
[16:06] <mok0> the_belgain: in control, use Section: miscellaneous
[16:10] <mok0> the_belgain: debian/docs: remove NEWS
[16:10] <mok0> the_belgain: get rid of debian/dirs
[16:12] <mok0> the_belgain: debian/changelog: go to launchpad, create a needs-packaging bug, assign it to your self. Put the bug number you recieve in changlog, like this: (LP: #nnnnnn)
[16:12] <mok0> the_belgain: are you there?
[16:12] <the_belgain> ok - i'd already raised a bug, i'll add it to changelog
[16:12] <the_belgain> yes i am here - thanks a lot for all the feedback; i'm incorporating it at the moment
[16:13] <mok0> the_belgain: cool, I cant create a comment on revu
[16:13] <josesanch> create an empty dir /usr/libexec
[16:14] <mok0> then you should put that in debian/dirs ^^^
[16:14] <mok0> the_belgain: good work
[16:15] <the_belgain> is the /usr/libexec comment aimed at me?  why is that needed?
[16:15] <josesanch> the_belgain: yes
[16:15] <josesanch> the_belgain: I thinks is not needed, but is created.
[16:15] <josesanch> the_belgain: the dir is empty
[16:16] <mok0> the_belgain: debian/dirs is for empty dirs you want created, and that are not created by the build
[16:16] <mok0> the_belgain: you rarely need it
[16:16]  * sistpoty is off again... cya
[16:17] <the_belgain> but i should add it in here anyway?
[16:17] <mok0> the_belgain: only if you need it created as an empty directory
[16:18] <mok0> the_belgain: is is for plugins or so?
[16:18] <the_belgain> any ideas as to why i needed to manually add Depends: for liblame, libflac, libmpcdec, libfaad?
[16:18] <mok0> the_belgain: is your code linked to those libs?
[16:20] <RainCT> I've just seen there's a Wordpress package in the repos... is there also Wordpress MU?
[16:21] <the_belgain> mok0: it looks like not
[16:21] <mok0> the_belgain: why do you need these packages then?
[16:24] <bddebian> Heya gang
[16:24] <the_belgain> well i'm wondering whether they should be being linked in - lame is definitely used for transcoding
[16:26] <mok0> the_belgain: if fuppes spawns a process that runs lame as a encoder, you should depend on the lame binary, not the library
[16:26] <mok0> the_belgain: libfaad2-dev does not exist in hardy
[16:27]  * mok0 fires up his gutsy pbuilder
[16:28] <the_belgain> fuppes doesn't need the lame binary installed - compiling from source with just the dependencies pulled in by liblame-dev (i.e. liblame0-dev, but not lame) works
[16:28] <mok0> I see
[16:29] <the_belgain> see eg. http://fuppes.ulrich-voelkel.de/wiki/index.php/Compiling_on_Linux
[16:30] <the_belgain> mok0: i've now fixed up libfaad2-dev (to be libfaad-dev) - i'll set up a hardy pbuilder and check it works
[16:34] <crimsun> pochu: there were no functional changes in the alsa uploads yesterday
[16:35] <crimsun> pochu: they were strictly to make using PulseAudio easier
[16:39] <crimsun> pochu: please attempt to reproduce the error by erasing ~/.asoundrc (and /etc/asound.conf if it, too, exists), logging out and back in, and using totem/RB
[16:44] <the_belgain> mok0, josesanch: i'm uploading an updated fuppes package incorporating all the suggested changes, so that i don't get similar feedback from anyone else reviewing it
[16:44] <mok0> the_belgain: the fuppes package also contains development libraries, which it shouldn't
[16:45] <mok0> the_belgain: in debian/ create a file name fuppes.install, that lists all the files that should be included
[16:45] <RainCT> Does anyone know if X-KDE-SubstituteUID=true (in a .desktop file) work in Ubuntu (GNOME)?
[16:46] <mok0> the_belgain: you don't need libfuppes.a, libfuppes.la, libfuppes.so,
[16:47] <the_belgain> so the fuppes.install file should contain the list of installed files, with those ones pruned out
[16:47] <the_belgain> ?
[16:48] <mok0> it should contain "usr/bin/", "usr/lib/libfuppes.so.*" and that's it
[16:49] <mok0> the_belgain: and you should write manpages for fuppes and fuppesd
[16:49] <josesanch> the_belgain: Ok. i'll review again.
[16:49] <the_belgain> surely the fuppes.install needs fuppes and fuppesd too?
[16:49] <mok0> the_belgain: it is enough to list the directory they're in
[16:50] <the_belgain> ok
[16:50] <mok0> without the leading slash
[16:51] <mok0> the_belgain: but then you need to install into debian/tmp, so in rules, change
[16:51] <mok0> DESTDIR
[16:54] <the_belgain> do you mean "usr/lib/libfuppes.so*" or "usr/lib/libfuppes.so.*" above?
[16:54] <mok0> the latter
[16:55] <mok0> libfuppes.so is only needed for linking
[16:55] <mok0> i.e. developement
[16:55] <mok0> s/lope/lop/
[16:56] <pochu> crimsun: can't reproduce it (there was a ~/.asoundrc.asoundconf too, but I didn't remove it).
[16:56] <the_belgain> ok.  should I add an ubuntu / motu dev list to the maintainers list? dpkg-buidpackage is suggesting i do?
[16:56] <pochu> crimsun: should I try removing it too?
[16:57] <mok0> Yes
[16:57] <crimsun> pochu: ~/.asoundrc.asoundconf is not used without ~/.asoundrc  (the latter includes the former)
[16:58] <mok0> the_belgain: Put this: Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com
[16:58] <pochu> crimsun: ok
[16:58] <crimsun> pochu: thus, removing the former is unnecessary and demonstrates that neither alsa-lib nor alsa-utils affected the symptom
[16:58] <crimsun> or effected, rather.
[16:58] <mok0> the_belgain: .. and put yourself in XSBC-Original-Maintainer:
[16:59] <the_belgain> done, thanks
[17:00] <the_belgain> i've got to go now; thanks again for all the help and i've uploaded an updated package with all these changes
[17:00] <mok0> the_belgain: https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#head-8c0f73c5468e3df4abfafb4cf121ed1d226e5a92
[17:03] <the_belgain> does REVU produce binary debs of submitted packages?
[17:05] <ScottK> the_belgain: No
[17:09] <mok0> Yo ScottK
[17:10] <ScottK> Heya
[17:11] <mok0> ScottK: Did you guys decide on the new member of the Council?
[17:11] <ScottK> mok0: There was mail on the nomination process to (IIRC) the MOTU ML.
[17:11]  * mok0 didn't read mail today
[17:12] <pochu> mok0: https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/003008.html
[17:13] <mok0> pochu: thx
[17:20] <imbrandon> are there any nominations yet?
[17:21] <imbrandon> btw moins all
[17:22] <pochu> hey imbrandon, and not that I know of
[17:22] <imbrandon> crimsun: quick question about sound ( sorry, dont know a better source to ask ) , if i aoss wrap a program, do i have to do anything special to other native alsa apps?
[17:22] <pochu> Hmm well I'm not a member of -council so I won't know it ;)
[17:22] <imbrandon> pochu: thanks
[17:23]  * imbrandon wonders how long the terms are, i would consider nominating myself IF it was only a 1 year term, i dont want to make a longer term commitment atm
[17:23] <pochu> imbrandon: you can step down at any moment, can't you? :)
[17:24] <imbrandon> pochu: yea
[17:24]  * pochu likes the new proposal better than the old one, but wonders whether nominating privately so the council and the TB evaluates the nominations is a good or a bad idea.
[17:25] <pochu> Maybe those evaluations should be done by the team itself...
[17:25] <LucidFox> Does pbuilder use debuild, or does it call dpkg-buildpackage directly? (Not like I care, but I'm writing a Wikipedia article on the Debian build toolchain)
[17:27] <imbrandon> LucidFox: afaik it calls dpkg-buildpackage , but i would verify that in the source to make sure
[17:28] <crimsun> imbrandon: aoss is solely for OSS apps.
[17:28] <imbrandon> right , i'm trying to make an oss only app play nice with my system
[17:28] <imbrandon> ( TeamSpeak )
[17:29] <imbrandon> so i figured the easy way was to wrap it in aoss
[17:29] <imbrandon> correct ?
[17:29] <crimsun> yes.  However, TS is a real PTA.
[17:29] <crimsun> PITA*
[17:29] <imbrandon> hehe yea, i've noticed
[17:30] <crimsun> you _may_ have luck with telling the oss emulation to skip using alsa-lib plugins
[17:30] <imbrandon> i even thought about running it in wine, just to let wine handle the abstration
[17:30] <imbrandon> abstraction*
[17:31] <imbrandon> TS3 is supose to fix all this, but that could be ages away
[17:31] <geser> pochu: the council will forward all nominations (with added comments) to the TB and doesn't do any selection
[17:31] <crimsun> e.g., # echo "TS_executable 0 0 direct" > /proc/asound/card0/pcm0[pc]/oss
[17:31] <pochu> geser: so the TB will do it, right? At least that's what I understand.
[17:31] <pochu> geser: Otherwise it seems a bit stupid to me :)
[17:31] <imbrandon> crimsun: should i try running it like that ?
[17:32] <crimsun> imbrandon: you'd need to try that and then execute TS
[17:32] <geser> pochu: yes, but I don't know how they will do it
[17:32] <crimsun> imbrandon: that, however, is only for OSS and not aoss
[17:32] <imbrandon> ok , and the latter wrapped in aoss correct?
[17:32] <imbrandon> ohh ok
[17:32] <crimsun> imbrandon: _and_ you'd likely lose software multiopen
[17:33] <imbrandon> multiopen ?
[17:33] <crimsun> commonly incorrectly called "hardware mixing"
[17:33] <imbrandon> basicly i just want to be able to use a game and TS at the same time, the game is alsa so no issues there
[17:33] <pochu> geser: I mean that it might make more sense if it was the team itself who did the selection, and not the TB, since we know ourselves better than the TB do (although I guess that's what the comments from the council are for :) )
[17:34] <imbrandon> crimsun: ahh
[17:34] <imbrandon> yea i doubt i have any kind of hardware mixing, i'm using whatever is built onboard my MB
[17:34] <pochu> geser: but this is much better than it was before (thanks ScottK ;)
[17:34] <LucidFox> imbrandon> Doesn't PulseAudio handle it?
[17:34] <LucidFox> with padsp for OSS applications
[17:34] <imbrandon> hehe ( not even sure what card it is tbh, it "just works" )
[17:35] <imbrandon> some kinda nvidia card using ac97 drivers i'm guessing , but i dont even know how to check, sound is one of my weakest points
[17:36] <imbrandon> s/one of/definately
[17:36] <crimsun> LucidFox: it doesn't work any better.
[17:36] <geser> pochu: if the MC does the selection then it it like before where. the new proposal tries to avoid it that the mc selects the new proposed members
[17:36] <crimsun> (padsp is equivalent to aoss.)
[17:37] <crimsun> imbrandon: if you want to be adventurous, probably use OSSv4
[17:37] <imbrandon> crimsun: i dont mind being adventureous hehe
[17:37] <imbrandon> s/e//
[17:37] <pochu> geser: yeah, now it's the team members who nominate themselves, but I'm not sure I like the TB doing some filtering, and the nominations being private...
[17:38] <imbrandon> really i'm looking for the easest awnser, but really i dont care, its sunday and i have not much else to do :)
[17:43] <imbrandon> hrm is OSSv4 non free ( not that i'm against that, just curious from the looks of it )
[17:43] <imbrandon> crimsun: ^
[17:43] <imbrandon> free as in code, not beer
[17:45] <geser> pochu: let's see how this ends. the process still can be improved if we see that it still has some issues, but it's an improvement
[17:46] <geser> pochu: the idea behind the private nominations was to prevent a public flaming of some nominees
[17:46] <crimsun> imbrandon: no, it's Free.
[17:46] <pochu> geser: yeah, that's what I thought, and that's why I said 'I'm not sure' instead of 'I don't like' ;)
[17:47] <jonnymind> hello all.
[17:47] <pochu> geser: but I agree this looks better. Let's see how it goes as you said :)
[17:47] <crimsun> imbrandon: it's dual-licensed GPLv2 and CDDL.  See http://developer.opensound.com/sources/
[17:47] <crimsun> err, CDDLv1
[17:47] <jonnymind> I am rewriting the debian/copyright. I would like to know; the "copyright" notice (year) refers to the package or to the upstream software?
[17:48] <imbrandon> upstream
[17:48] <pochu> Upstream. You can add a line regarding the packaging at the end of it. (dh_make adds it)
[17:48] <imbrandon> most everything except the top and bottom lines in debian/copyright should refer to the upstream
[17:49] <imbrandon> top == debinized by ..... , bottom == as pochu said
[17:49] <jonnymind> And the license that must be reported in the debian/copyright file is the license of the package or the license of the upstream software?
[17:50] <imbrandon> jonnymind: both asre refered to in that file, but the package lic is normaly only a one liner at the the bottom
[17:50] <imbrandon> the rest is all about upstream
[17:50] <jonnymind> I see.
[17:51] <imbrandon> lemme see if i can find a good example, ( note that debian is looking at making a new format policy , but that should matter not atm )
[17:52] <somerville32> Is anyone working on the queue today? I have four in there.
[17:55] <jonnymind> imbradon: if I am not wrong, python is not released under GPL license.
[17:56] <imbrandon> ... ok? how does that impact what i said ?
[17:56] <somerville32> I'm pretty sure Python isn't released under the GPL
[17:56] <somerville32> jonnymind, and try not to use double negation :P It can get confusing.
[17:57] <jonnymind> double? where?
[17:57] <somerville32> "if I am _not_ wrong, python is _not_ released under GPL license."
[17:58] <jonnymind> This is not double negation. These are two sentences.
[17:58] <imbrandon> a comma dosent make a new sentance :)
[17:58] <imbrandon> anyhow no biggie, i got your point
[17:59] <pochu> I think that's correct, isn't it?
[17:59] <jonnymind> imbradon: two verbs does.
[17:59] <jonnymind> imbradon: may I use python debian/copyright as a template?
[17:59] <imbrandon> jonnymind: no, a sentance is based on punctuation only, even if its a run on sentance, or wrong, like this one, its still one sentance.
[18:00] <somerville32> "if I am right, python is not released under GPL license"  is much clearer and removes the double negation
[18:00] <imbrandon> jonnymind: lemme look
[18:00] <imbrandon> one moment
[18:01] <jonnymind> it seems python debian/copyright would be plainly rejected by persia.
[18:01] <imbrandon> that doesnt look to be a good example, although it follow policy , its messy
[18:01] <jonnymind> Great.
[18:02] <imbrandon> jonnymind: basicly its like this ....
[18:02] <imbrandon> the first line in debian/copyright is "this package was debinized by : blah vopyright blah" refering to the package
[18:03] <imbrandon> the last line is the packaging copyright and lic again, eg if the "packaging" is gplv2 or such
[18:03] <imbrandon> everything inbetween is upstream
[18:03] <crimsun> any MOTU hopefuls searching for a quick source package update?
[18:03] <somerville32> crimsun, oi
[18:03] <crimsun> (I'll be in #ubuntu-classroom)
[18:04] <imbrandon> jonnymind: clear ?
[18:04] <imbrandon> jonnymind: take a look at apt-mirror if you want an example, it follows that format and i maintain it ( and am *part* of upstream ) so i'm familiar with it
[18:05] <jonnymind> ok
[18:05] <imbrandon> it is not in the new debian format for lenny , but its what debian and ubuntu currently follow
[18:05] <josesanch> Would any MOTUs review my package? http://revu.tauware.de/details.py?package=gnomecatalog
[18:06] <imbrandon> if you want to go ahead and use the new new enew format ( e.g. whats being encouraged to be used by new packages somming into debian via debian-mentors lemme get the url
[18:06] <imbrandon> )
[18:06] <imbrandon> http://wiki.debian.org/Proposals/CopyrightFormat
[18:06] <imbrandon> jonnymind: ^^
[18:06] <jonnymind> imbradon: the "was downloaded by" refers to the package or to the upstream sources?
[18:06] <imbrandon> "was downlaoded from" not by
[18:06] <imbrandon> if its by its a typo
[18:07] <imbrandon> and yes it refers to upstream
[18:07] <jonnymind> es, sorry, by
[18:07] <jonnymind> ok
[18:07] <imbrandon> e.g. where the source can be found outside debian/ubuntu , e.g. sourceforge etc etc etc
[18:08] <imbrandon> if someone went looking
[18:09] <imbrandon> It was downloaded from http://apt-mirror.sourceforge.net/
[18:09] <imbrandon> Copyright 2005,2006,2007  Dmitry N. Hramstov <hdn@nsu.ru>
[18:09] <imbrandon> Copyright 2007  Brandon Holtsclaw <brandon@imbrandon.com>
[18:09] <imbrandon> Upstream Authors: Dmitry N. Hramtsov <hdn@nsu.ru> Brandon Holtsclaw <brandon@imbrandon.com>
[18:09] <imbrandon> License:
[18:09] <imbrandon> This program is free software; you can redistribute it and/or
[18:09] <imbrandon> gah
[18:09] <imbrandon> sorry
[18:09] <imbrandon> wrong window, ment to pastebin
[18:09] <imbrandon> anyhow see the "upstream" url
[18:10] <pochu> persia, ember: vinagre 0.4 in Debian NEW
[18:19] <imbrandon> crimsun: is that root command you pasted litteral for any card ( the proc path )
[18:19] <imbrandon> or do i need to find my card
[18:23] <dfiloni> pochu: congratulation, I saw now you are a motu :)
[18:29] <jonnymind> persia: ping
[18:33] <jonnymind> last week, persia told me I should have added a -dbg release for my software or leave debug symbols in the release.
[18:33] <jonnymind> I'd prefer to give a separate -dbg package for various reason.
[18:34] <jonnymind> My question is: is it ok if this package conflicts with the non -dbg package?
[18:34] <jonnymind> I.e. if you can install one or the other, but not both?
[18:38] <ScottK> pochu: Thanks.
[18:38]  * ScottK agree the MC process is likely better, but has room for further improvement.
[18:39] <somerville32> ScottK, Do you plan to run?
[18:40] <ScottK> somerville32: No.
[18:40]  * ScottK has been sufficiently outspoken recently that I think running now would be divisive.
[18:40] <ScottK> Maybe some other time.
[18:43] <jonnymind> Sorry for asking such a basic question, but what's the command to run watch again?
[18:43] <jonnymind> (i suppose "watch")
[18:43] <jonnymind> *something with "watch"
[18:45] <jonnymind> Ok, it was uscan
[18:46] <crimsun> imbrandon: it's a literal command
[18:47] <LucidFox> Is there any advantage whatsoever of using simple-patchsys over cdbs+dpatch?
[18:47] <ScottK> twiki could use some security love if anyone's interested...
[18:47] <somerville32> ScottK, how much love?
[18:50] <imbrandon> LucidFox: maintainer prefrence
[18:53] <ScottK> somerville32: Look at the latest Hardy upload debian/changelog
[18:54] <ScottK> LucidFox: No 00list to keep up to date.
[18:54] <pochu> imbrandon: so at the end we will see who's up for election at https://wiki.ubuntu.com/MOTU/Council :)
[19:01] <jonnymind> imbradon:I read your notice about "there is already a package named falcon.
[19:01] <jonnymind> However, the notice is imprecise.
[19:02] <jonnymind> the bug "needs packaging" for my project has been opened in 2007, while the other package with the same name was opened in 2008.
[19:03] <jonnymind> Moreover, I was negotiating with those person about the package and binary names. We were talking about what to do, then the conversation stopped and the other package has been started.
[19:03] <jonnymind> I think we should discuss a bit the namespace question.
[19:06] <jonnymind> And also, frankly decide what to do basing on an objective criterion.
[19:08] <jonnymind> imbradon:?
[19:08] <crimsun> hmm, we need to do something about paman spewing menu items in Applications>  _and_  System>Preferences
[19:08] <crimsun> well, I think I've addressed Applications> , at least
[19:11] <jonnymind> persia: ping
[19:11] <jonnymind> pochu: ping
[19:12] <mok0> jonnymind: persia's east asia time, so he's probably sleeping by now
[19:12] <jonnymind> Oh. So the nick persia isn't random :-)
[19:12] <pochu> mok0: I thought he was in America
[19:12] <pochu> jonnymind: don't send contentless pings
[19:12] <mok0> he's in japan
[19:13] <pochu> (pong)
[19:13] <jonnymind> pochu: ok; the content is right above.
[19:14] <mok0> jonnymind: why don't you just call it "falcon-repo-manager"
[19:14] <jonnymind> mok0: mine is the language.
[19:14] <pochu> mok0: this is a programming language ;)
[19:14] <jonnymind> THAT one is the repo manager.
[19:14] <mok0> jonnymind: ah :-)
[19:14] <mok0> Anyway, I like descriptive package names
[19:15] <jonnymind> uhm... descriptive as "python" "perl" and "ruby"?
[19:15] <mok0> hehe
[19:15] <jonnymind> I like them too. And I like equality and fair treatment of equivalent merits.
[19:15] <mok0> programming languages are ok, so yours should be "falcon" and the other one "falcon-repo-manager"
[19:17] <mok0> but it will be confusing anyway, because users will conflate the two packages
[19:17] <crimsun> well, if you really want descriptiveness, you should consider "falcon-lang"
[19:17] <jonnymind> I can go for falconpl; I already told it.
[19:17] <jonnymind> it's also the name of the site.
[19:17] <jonnymind> But changing the name of the interpreter (which is ELF c code) is a bit different.
[19:18] <jonnymind> Would cause several hundrets changes needed in docs, i.e.
[19:18] <mok0> jonnymind: you need a Conflicts:
[19:19] <jonnymind> mok0: I don't see why if you install a language you should conflict with a package manager written in another langauge.
[19:19] <jonnymind> But if no other solution is viable, I can do it.
[19:19] <mok0> jonnymind: it depends what happens when you go "falcon" in the shell
[19:20] <mok0> if both packages attempt to install a "falcon" binary
[19:20] <jonnymind> Changing the name of the package is ok. Changing the name of the binary files would cause several days of work to be redone, and distress to the users.
[19:20] <mok0> exactly
[19:20] <mok0> so you need a  "Conflicts: falcon" in debian/control
[19:21] <jonnymind> Fine.
[19:21] <jonnymind> I will post a falconpl package with that conflict. We'll see what to do at a later stage.
[19:22] <mok0> jonnymind: good idea
[19:22] <mok0> jonnymind: but you may want to check out the "falcon" package, to make sure that there actually is a clash of binary names
[19:23] <jonnymind> It is: we were talking with the person developing the software, that has a falcon script that lanunches python falcon.py
[19:24] <jonnymind> And that bash script apparently goes in /usr/bin/falcon
[19:24] <jonnymind> (yet, starting a package with the same name after that we have discussed the thing with the author, and after he said he wasn't like doing packages for ubuntu seems a bit of dirty play, and exploitation of preferential position with packagers, seen from here).
[19:25] <amarillion> Hello, my package speed-game http://revu.tauware.de/details.py?package=speed-game is ready for review...
[19:33] <amarillion> ...
[19:36] <crimsun> amarillion: thanks for the post.  Someone may take a look when s/he has time.
[19:40] <rulus> I uploaded my package gtkvd http://revu.tauware.de/details.py?package=gtkvd recently too, comments from a Master are greatly appreciated ツ
[19:42] <amarillion> ok, thanks crimsun
[20:09] <josesanch> amarillion: Hello, do you has lucky with your package?
[20:13] <somerville32> crimsun, Hi, sorry it took me so long but bug #182677 for paman
[20:13] <ubotu> Launchpad bug 182677 in paman "Sponsor paman_0.9.4-1ubuntu1" [Low,Confirmed] https://launchpad.net/bugs/182677
[20:21] <crimsun> somerville32: tweaked & uploaded.  Thanks!
[20:21] <crimsun> somerville32: (the distribution == hardy, not gutsy)
[20:22] <somerville32> crimsun, sorry, I used the dch thing and didn't double check what it put in there
[20:22] <somerville32> I usually don't use dch
[20:48] <rzr> lionel: hi
[20:49] <lionel> hi rzr
[20:49] <rzr> lionel: shouldnt we use requestsync ?
[20:49] <rzr> did i miss something on https://wiki.ubuntu.com/SyncRequestProcess ?
[20:49] <lionel> you can use requestsync sure
[20:50] <lionel> It's about #182659
[20:50] <rzr> is that html garbage normal ?
[20:50] <lionel> rzr: no it was not :)
[20:50] <rzr> yea unicorn
[20:50] <lionel> and almost unreadable, that's why I changed in a plain text description
[20:51] <rzr> I guessed that
[20:51] <lionel> I don't know why you ended with a bad html description
[20:51] <rzr> but I was afraid i used the tool the wrong way
[20:51]  * rzr ran requestsync -s unicorn  dapper
[20:52] <lionel> rzr: you want in Dapper ?
[20:52] <rzr> yea because I know the driver is wroking w/ dapper kernel
[20:53] <rzr> not gutsy
[20:53] <lionel> it will land in hardy
[20:53] <rzr> anyway it's better than the current one
[20:53] <lionel> and you need then to backport in dapper (if it build/runs)
[20:53] <rzr> that's what i did on my PPA
[20:54] <rzr> but this is an important package for bewan modem owners
[20:54] <lionel> rzr: as you are the Debian maintainer, I supposed you know the package beter than me :)
[20:54] <rzr> i wish i knew it more
[20:54] <rzr> this driver is really a pain in the ass ..
[20:58] <rzr> lionel: so there is no hope for dapper ?
[20:58]  * rzr can understand that
[21:00] <lionel> rzr: once it is in hardy, you can request a backport
[21:00] <ScottK> rzr: Syncs are only for the current development release (Hardy).  We can backport to Dapper after we have it in the newer release.
[21:03] <rzr> ok makes sense now
[21:07] <RainCT> persia: would process-interdiff still make sense in u-d-t?
[22:02] <pochu> jonnymind: have you just ITP'd falcon in Debian?
[22:02] <jonnymind> pochu: yes.
[22:03] <pochu> jonnymind: heh, lucky you, falcon source package isn't in Debian ;)
[22:03] <jonnymind> How strange.
[22:04] <jonnymind> Actualluy; when I posted it to Ubuntu, it wasn't in ubuntu too.
[22:05] <jonnymind> And I offered many times to change its name openly and respectfully of ubuntu philosophy
[22:05] <emgent> hello there
[22:05] <pochu> jonnymind: not that strange. Upstream is an ubuntu member, and the packager is an ubuntu developer.
[22:06] <pochu> hi emgent
[22:07] <pochu> jonnymind: the funny thing is that you can use falcon name in Debian, but then it won't be synced to Hardy until the conflict is fixed.
[22:07] <jonnymind> pochu: there isn't any problem: I am already uploading falconpl in REVU. With a Conflict: field.
[22:08] <pochu> * Package name    : falcon
[22:08] <pochu> jonnymind: I said it because of that ^
[22:08] <jonnymind> I said in ubuntu. Not in debian.
[22:09] <pochu> That's Debian's ITP.
[22:09] <jonnymind> Yes.
[22:09] <pochu> So will you call it falcon in Debian?
[22:09] <jonnymind> Maybe.
[22:09] <pochu> Heh, ok.
[22:09] <jonnymind> We could have openly negotitiated /usr/bin/falcon. I was willing to rename the package falconpl.
[22:09] <jonnymind> The guy had my mail.
[22:09] <pochu> (that's I find funny) :)
[22:09] <pochu> +what
[22:10] <jonnymind> Even if that would have costed me several days of works in updating documentation, scripts, build systems, etc.
[22:10] <jonnymind> And would have caused problems to my users.
[22:10] <pochu> That's not neccessary. You can just Conflict with the other falcon.
[22:11] <jonnymind> Now I will just add Conflict; hope noone feels offended.
[22:11] <pochu> Not at all. At least not me :)
[22:11] <ScottK> jonnymind: Why not put your executable at /usr/bin/falconpl/falcon?
[22:11] <jonnymind> :-)
[22:12] <jonnymind> ScottK: it wouldn't been found as falcon in path, and it wouldn't be compatible with mac and windows
[22:12] <jonnymind> And solaris.
[22:12] <jonnymind> And bsd
[22:12] <ScottK> But you can put it there just in the Debian package and add the dir to the path
[22:12] <ScottK> Just move it there in debian/rules
[22:12] <jonnymind> Should I mangle the system path dir of hudred thousand users?
[22:13]  * ScottK isn't sure.  Just throwing out something else to consider
[22:13]  * ScottK would need to read FHS again to be sure
[22:13] <jonnymind> However, ubuntu MOTU can find any reasonable way to fix the clash.
[22:13] <pochu> Or /bin/falcon
[22:13] <pochu> Anyway, this is what Conflicts was created for, isn't it?
[22:14] <jonnymind> I don't want to stay in charge of the packages forever: we'll find professional packagers as the project grows. Gentoo and Fedora packaging is currently being submitted too.
[22:14] <jonnymind> Yes.
[22:14] <pochu> I'm just thinking that it will be a pain to maintain it if it's called falcon in Debian and falconpl in Ubuntu.
[22:14] <jonnymind> I cannot possibly stay in charge of all the packaging, and I don't really want to.
[22:15] <jonnymind> pochu: it is not the only case.
[22:15] <jonnymind> There are many packages shifting names between distros.
[22:15] <pochu> jonnymind: the other cases are probably a pain to maintain
[22:15] <pochu> jonnymind: but we sync packages from Debian
[22:15] <jonnymind> pochu: I am sorry about that.
[22:15] <jonnymind> I am sure we'll find a solution.
[22:15] <jonnymind> If we talk.
[22:15] <pochu> So if you package it in Debian, it can be synced to Ubuntu and you don't need to package it twice
[22:16] <pochu> But if there's already a falcon source package in Ubuntu then it won't be synced to not overwrite it.
[22:17] <jonnymind> pocuh: again, I am sorry about that.
[22:17] <jonnymind> I am sure a frank and open talk would have solved this problem before it was born, and I have started the talk and always shown very collaborative.
[22:17] <jonnymind> No, I have BEEN very collaborative.
[22:18] <ScottK> jonnymind: Conflicts is more usually used for packages that provide equivalent functionality.
[22:18] <jonnymind> ScottK: that is absolutely true.
[22:19] <ScottK> jonnymind: Have you discussed this with imbrandon?
[22:19] <pochu> jonnymind: (I'm not blaming you, just in case I'm not expressing well)
[22:20] <Nafallo> Seveas and imbrandon.
[22:20] <TheMuso> s/c
[22:21] <TheMuso> ugh damn keyboard
[22:21] <jonnymind> ScottK: No, I have discussed with the original author of the other falcon.
[22:21] <pochu> That's Seveas.
[22:21] <jonnymind> Well, I have started the discussion and replied to its e-mail.
[22:21] <jonnymind> In which he stated he wasn't going to make a package.
[22:22] <ScottK> jonnymind: Right, and he didn't
[22:22] <pochu> (which is true, the package was done by imbrandon)
[22:22] <pochu> ScottK: you beat me
[22:22] <jonnymind> Ah.
[22:22]  * pochu is eating pizza, so he's not that fast ;)
[22:22] <ScottK> jonnymind: My concern right now (not having a great interest in either package) is that if you upload your package as falcon to Debian, then it's going to cause trouble between Ubuntu and Debian that it would be better to avoid.
[22:22] <jonnymind> So Imbradon knew there was a falcon package made in december.
[22:22] <jonnymind> so it's comment here:
[22:23]  * Nafallo steals pochu's pizza so he can be fast again
[22:23] <jonnymind> http://revu.tauware.de/details.py?package=falcon
[22:23] <Seveas> packages for 'the other falcon' have existed since 2006
[22:23] <pochu> Nafallo: that would be the last slice!
[22:23] <jonnymind> seems a bit interesting...
[22:23] <pochu> Seveas: not in the Ubuntu repo
[22:23] <ScottK> Hi Seveas.
[22:23] <jonnymind> Eh? -- where?
[22:23] <Seveas> and imbrandon intended to upload them since mid 2007
[22:23] <Seveas> or even earlier
[22:23] <jonnymind> Ah... now I understand.
[22:24] <ScottK> jonnymind: However this is going to get sorted out, please sort it out here and don't upload a package with the same name as Seveas's falcon to Debian.  It's just going to cause Debian/Ubuntu confusion.
[22:24] <jonnymind> because, othwrwise ... https://launchpad.net/ubuntu/+source/falcon
[22:25] <Seveas> imbrandon will upload my falcon to debian as well
[22:25] <Seveas> at least he said he would :)
[22:25] <jonnymind> Seveas: again; the package here is named falconpl now.
[22:25] <jonnymind> That closes the question.
[22:26] <Nafallo> both packages use /usb/bin/falcom? :-)
[22:26] <Nafallo> s/m/n
[22:26] <jonnymind> I do.
[22:27] <ScottK> jonnymind: Except your Debian ITP is for a package named falcon, so it doesn't close the question at all.
[22:27] <pochu> Nafallo: and falconpl conflicts with falcon
[22:27] <jonnymind> ITP isn't related with a direct upload.
[22:27] <jonnymind> It's on the mentor's side to decide for packages.
[22:27] <Nafallo> pochu: without being the same thing? that's just ugly :-/
[22:27] <jonnymind> They will decide the name of the package as well as other details.
[22:27] <ScottK> jonnymind: ITP has the package name.
[22:28] <jonnymind> ScottK: Mentors makes packages, so they decide.
[22:28] <ScottK> Ideally a sponsor will just review the work, decide it's good, and upload.  Don't leave decisions to the sponsor.
[22:28] <jonnymind> ScottK: And if they decide that it's not good, they won't.
[22:28] <ScottK> jonnymind: Yes, but your ITP says you are making a package named "falcon".
[22:28] <Nafallo> I would rename that ITP...
[22:29]  * ScottK would hope jonnymind will.
[22:29] <ScottK> Having a consistent package namespace between Debian and Ubuntu is very important.
[22:29] <pochu> jonnymind: do you know the difference between ITP and RFP? Because it looks to me like if you were waiting for someone else to package falcon...
[22:30] <jonnymind> ScottK: I am willing to do it. I may do it. I will do it, if everyone agrees.
[22:30] <ScottK> jonnymind: What agreement is needed?  Can't you just do it?
[22:30] <jonnymind> pochu: No, I have already the package sitting here. But Mentor role is a bit more extensive than MOTU roles, so it seems.
[22:30] <jonnymind> I.e. I cannot upload the package. It must be taken by the mentor, possibly changed and then uploaded.
[22:31] <pochu> Nafallo: at least Seveas's falcon isn't written in jonnymind's falcon ;-)
[22:31] <Seveas> pochu, rofl
[22:31] <Nafallo> pochu: haha
[22:31] <Seveas> that would be sick :)
[22:31] <Nafallo> conflictorama :-)
[22:31] <ScottK> jonnymind: Depens on who's sponsoring in Debian, it's often a lot like it is here where they give you comments until they are happy.
[22:31] <Seveas> couldn't have happened either, my falcon is much older
[22:31] <ryanakca> hmm... what would you call the debian packaging structure if you were to put it on a resume? "Python, CSS, HTML, Debian Packaging System" ?
[22:31] <ScottK> Seveas: What is your falacon written in?
[22:31] <Seveas> Python
[22:32] <Seveas> and Django :)
[22:32] <Seveas> (which is Python)
[22:32] <awalton__> Seveas, why is it called falcon?
[22:32]  * awalton__ is killed by rampaging curiosity
[22:32] <Seveas> awalton__, because I liked that name and it didn't conflict with anything in Debian/Ubuntu back in 2005 when I started
[22:33] <awalton__> ah.
[22:33] <jonnymind> Well, Seveas. Falcon p.l. was started back in 2003.
[22:33] <awalton__> figured it had something to do with pythons being snakes and falcons....
[22:33] <jonnymind> And there was a site.
[22:33] <Seveas> jonnymind, search for falcon on google, you won't find yours or mine
[22:33] <Seveas> so Debian was my guideline for conflicts
[22:33] <jonnymind> falcon script
[22:34] <Seveas> doesn't cound, one would need to guess it's a language
[22:34] <RainCT> good night
[22:34] <jonnymind> Well; up to firsts of december 2007, ubuntu and debian was mine.
[22:34] <Nafallo> haha
[22:34] <Seveas> lol
[22:34] <jonnymind> And still, there was no conflict.
[22:34] <Nafallo> can't even find it on google linux first 10 :-)
[22:38] <Nafallo> oh well
[22:39] <Nafallo> we already have /usr/bin/falcon, so please don't name it the same or people will need to choice which package they want :-)
[22:39] <jonnymind> we who?
[22:40] <Nafallo> Ubuntu
[22:40] <jonnymind> I have ubuntu.
[22:40] <jonnymind> and I didn't have /usr/bin/falcon. Nor I have now.
[22:40] <Seveas> !info falcon hardy
[22:40] <Nafallo> ehrm
[22:40] <ubotu> Package falcon does not exist in hardy
[22:40] <Seveas> ubotu, ?
[22:40] <Nafallo> someone didn't get the point... :-)
[22:40] <Seveas> heh, needs to update :)
[22:40] <ion_>     falcon | 2.0.4-0ubuntu1 | http://archive.ubuntu.com hardy/universe Sources
[22:40] <lionel> binary is still in new
[22:41] <jonnymind> Oh
[22:41] <jonnymind> As mine.
[22:41] <Nafallo> jonnymind: really?
[22:41] <Seveas> no
[22:42] <Nafallo> is falconpl even source new anywhere?
[22:42] <Seveas> no :)
[22:42] <jonnymind> As someone may suspect, I must FRANKLY and OPENLY admit that didn't get very well the fact that, while I was working on the topic and finding a solution, someone (knowning the state of the things, as it/they was informed of the fact) forced this situation with an unilaterary act.
[22:42] <Nafallo> that's what I thought then :-)
[22:43] <jonnymind> http://revu.tauware.de/details.py?package=falcon
[22:43] <jonnymind> Comments for upload of December 06 18:40   (debdiff)
[22:44] <jonnymind> bug #174470
[22:44] <ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
[22:44] <Nafallo> can't see any comments on that one.
[22:45] <Nafallo> the comments where made 1st and 11th of January
[22:45] <jonnymind> But the wrost thing is that I was openly available to do any change, and was here almost every day. And I offered a solution to Seveas in the first place.
[22:45] <jonnymind> And?
[22:45] <jonnymind> the package was uploaded in december.
[22:45] <jonnymind> After days of discussions.
[22:46] <jonnymind> In which I was even told "no, don't use falconpl. Falcon is OK"
[22:46] <jonnymind> here by motus.
[22:46] <jonnymind> It was ME that went around asking again and again how to solve it.
[22:46]  * Nafallo adds comment on the bug :-)
[22:48] <pochu> Nafallo: there were a lot of comments here on IRC, as I couldn't comment on REVU by then
[22:48] <jonnymind> after I have been told that someone remembered about an utility with that name. So, I am sorry, I cannot be blamed as responsible for the situation.
[22:49] <Nafallo> did anyone?
[22:49] <jonnymind> Having that package uploaded by a person that knew both the situation and my availability to sort out problems, sorry, doesn't seem very ubuntu policy compliant.
[22:49] <Nafallo> anyway. as I see it falcon is already in the repos. it would be hard to change that one now.
[22:49] <jonnymind> persia and pochu reviewed the package in december.
[22:50] <pochu> Nafallo: no, it isn't.
[22:50] <pochu> Nafallo: you can remove it from there.
[22:50] <Nafallo> pochu: source is.
[22:51] <pochu> Nafallo: can't you remove source from soyuz?
[22:51] <pochu> (I'm not saying it should be removed, but it's possible to change it)
[22:52] <Nafallo> pochu: dunno. but it's source made it to the archive already.
[22:52] <Nafallo> pochu: it's on the mirrors :-P
[22:53] <pochu> Nafallo: I think that doesn't matter.
[22:53] <pochu> And there aren't binaries, so even easier.
[22:54] <Nafallo> https://edge.launchpad.net/ubuntu/+builds?build_text=falcon&build_state=all
[22:54] <Nafallo> there is binaries :-)
[22:54] <jonnymind> ppl, sorry for having stolen your time. I'd like to return to the technical aspects.
[22:55] <jonnymind> Why I can't make uscan to work?
[22:55] <jonnymind> I get this error:
[22:55] <jonnymind> uscan warning: In debian/watch,
[22:55] <jonnymind>   no matching hrefs for watch line
[22:55] <jonnymind>   http://www.falconpl.org/downloads/(.*)/Falcon-(.*)\.tar\.gz
[22:55] <pochu> Nafallo: not in the archive. Needs to be NEW'd
[22:55] <geser> Nafallo: but only in the binary NEW queue :)
[22:55] <Nafallo> yea exactly. so there is binaries :-)
[22:56] <pochu> Nafallo: well there are binaries for jonnymind's falcon. They are in ~/.pbuilder/hardy/result, but there are :P
[22:56] <Nafallo> pochu: they are not in any kind of queue built from anything in an archive ;-)
[22:57] <jonnymind> Nafallo: I just have seen your comment.
[22:57] <jonnymind> Sorry; I retire falcon from ubuntu.
[22:57] <jonnymind> How can I delete the package?
[22:57] <pochu> Nafallo: who cares? An archive admin can reject it with one click ;)
[22:57] <Nafallo> pochu: baah. the can kill xorg as well, with lots more clicks. that's not the point :-)
[22:58] <Nafallo> jonnymind: huh? it's not in yet.
[22:58] <jonnymind> I mean, from revu and launchpad.
[22:58] <pochu> Nafallo: But don't say things can't change just because someone uploaded a package.
[22:58] <Nafallo> jonnymind: would be so much easier to do what you've already did. rename the package :-)
[22:59] <pochu> And out of curiosity: a package needs two ACKs to be uploaded to Universe... who did ACK falcon other than imbrandon?
[22:59] <jonnymind> Nafallo: I am not changing 6 system installation scripts and 300 doc pages for this.
[22:59] <Nafallo> pochu: *sigh* you probably know exactly what I mean, so why even argue about it? :-)
[22:59] <jonnymind> Someone will find a way to package falcon when it is included in the other distros.
[22:59] <Seveas> pochu, could be persia, I did the final checks with them
[23:00] <jonnymind> I started packaging from ubuntu because I beleived in ubuntu philosophy of respect.
[23:00] <jonnymind> ...
[23:00] <pochu> Seveas: I'd be surprised if it was persia since persia was reviewing jonnymind's falcon package.
[23:01] <pochu> And since there's no REVU upload for it to look at, nor ACK in the needs-packaging bug...
[23:04] <Nafallo> pochu: I just check my logs. persia :-)
[23:04] <pochu> Crap.
[23:04]  * pochu kicks persia :)
[23:05] <Nafallo> pochu: he found blockers that got fixed before the upload as well
[23:06] <jonnymind> I understand. If anyone wants the package it's open soruce, so they'll be able to package it.
[23:07] <jonnymind> Goodbye.
[23:07]  * rzr updated http://revu.tauware.de/details.py?package=jaaa
[23:07] <Nafallo> oh well...
[23:09] <pochu> It would really annoy me if I had a package up for review and then someone else uploaded a package with the same name, so I completely understand him.
[23:09]  * pochu goes out for a godwalk
[23:18] <guest22> Any MOTUs here willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
[23:41] <bddebian> Heya gang
[23:43] <somerville32> Heya bddebian
[23:43] <cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
[23:43] <bddebian> Hello somerville32