[00:02] <emgent> heya
[00:02] <NCommander> emgent, hola
[00:02]  * NCommander is seeing how well launchpad works at 14.4k
[00:06] <ScottK> NCommander: Probably not too bad with no CSS or images.
[00:06] <NCommander> It works in lynx
[00:06] <NCommander> I'm looking for packages that are crufty ;-)
[00:09] <NCommander> someone needs o change the topic in here
[00:09] <NCommander> It still says the next MOTU meeting is today at 8 UTC
[00:09] <NCommander> *4 UTC
[00:11] <ScottK> NCommander: So change it.
[00:11] <tbielawa> hello everybody!
[00:11] <NCommander> ScottK, I'm not a member of ubuntu-irc, thus no ops power here
[00:13] <ScottK> NCommander: Try it.
[00:14] <NCommander> O_O;
[00:14] <ScottK> NCommander: OK.  Now fix it.
[00:14] <NCommander> ScottK, I'm trying, but I'm seriously lagging
[00:18] <slytherin> I was wondering if anyone has already evaluated possibility of getting java-3d in repository.
[00:19] <NCommander> slytherin, what's the license?
[00:20] <slytherin> NCommander: I haven't looked yet. That is why I asked.
[00:20] <slytherin> NCommander: I think it is redistributable binary only.
[00:21] <slytherin> NCommander: I am wrong, part BSD part GPL. :-)
[00:26] <slytherin> when using cdbs, if I am specifying all the locations appropriately in debian/install file then do I actually need install target in rules file?
[00:34] <azeem> slytherin: no, cdbs would do it for you
[00:35] <slytherin> azeem: cool
[00:35] <azeem> one could argue the other way round: *If* you need an install: target, either the build system is broken or the package is too complex for cdbs
[00:36] <ScottK> azeem: Sendmail uses CDBS.  No package is too complex for CDBS if you want it bad enough.
[00:39] <slytherin> I use CDBS mainly for java apps and I feel CDBS really makes life easier.
[01:23] <foxbuntu> anyone have a quick minute to ack a package?
[01:38] <tgm4883_laptop> If anyone has some spare time to revu a package i'd appreciate some input on mythstream-parser-youtube.  I have 8 other packages that are parsers too but want to make sure I did this one right before I upload them all
[01:40] <ScottK> foxbuntu and tgm4883_laptop: Your odds go up if you provide a link to the packagae on REVU.
[01:41] <tgm4883_laptop> ScottK, sorry, thanks   http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube
[01:41] <foxbuntu> http://revu.ubuntuwire.com/details.py?package=mythbuntu-log-grabber
[01:43] <superm1> tgm4883_laptop, i left you a few comments there to address
[01:43] <tgm4883_laptop> superm1, thanks
[01:54] <foxbuntu> sorry but to put two and two together, for any that might be willing to revu my package, thanks: http://revu.ubuntuwire.com/details.py?package=mythbuntu-log-grabber
[04:37] <foxbuntu> sorry but to put two and two together, for any that might be willing to revu my package, thanks: http://revu.ubuntuwire.com/details.py?package=mythbuntu-log-grabber
[04:40] <NCommander> hello world :-)
[05:05] <foxbuntu> would someone be able to revu my package, it would be greatly appreciated: http://revu.ubuntuwire.com/details.py?package=mythbuntu-log-grabber
[05:11] <ScottK> foxbuntu: If it's not a review day, asking once a day is considered polite.
[05:11] <ScottK> Any Java packaging meisters around?
[05:11]  * ScottK suddenly remembers there's a channel for that...
[05:12] <foxbuntu> ScottK, sorry was just popping in and out and figured with all the people coming and going hoping for someone new willing to help out
[05:12] <ScottK> foxbuntu: Just so you know ...
[05:13]  * foxbuntu notes and will stop asking
[05:16] <ScottK> This has been a very slow cycle for new packages.  I know it's frustrating on that end of the problem.
[05:22] <RoAkSoAx> hey yall
[05:25] <foxbuntu> ScottK, its alright as long as it gets there I guess, I have a brandnew app I need to complete anyways
[06:08] <TomJaeger> Alright, here's the deal.  Chances are, you're gonna hate me after this, but I don't care.
[06:09] <TomJaeger> Basically, I'm going to ask that my package be taken down from revu unless someone commits to reviewing it
[06:09] <TomJaeger> I'm really unhappy how this has all played out and I feel like you guys haven't been honest upfront.
[06:10] <TomJaeger> I feel like I'm a valuable member of the community, and I'll continue to do my part, but I don't think this is how you should be treated.
[06:11] <white> TomJaeger: ?
[06:11] <white> TomJaeger: are you trying to get a new package in? If you give me a link to a patch, I can give you some comments :)
[06:11] <TomJaeger> I've been putting a lot of work into getting my package accepted and except for some wisecracking and some condescending attitude, I haven't gotten any response whatsoever
[06:12] <TomJaeger> white, yeah, I've been trying to do that for a week or so
[06:12] <white> TomJaeger: do I get a link now? :)
[06:12] <TomJaeger> http://revu.ubuntuwire.com/details.py?package=easystroke
[06:13] <white> so it is a completely new package?
[06:13] <TomJaeger> yes
[06:13] <ScottK> TomJaeger: I'm not sure why, but this has been a really slow cycle for reviews.  I remember it being frustrating on that end of the equation.
[06:13] <ScottK> white: Everything on REVU is supposed to be completely new stuff.
[06:13] <white> TomJaeger: intentions to bring it into debian?
[06:13] <white> ScottK: ah
[06:13] <wgrant> ScottK: But in practice it is not.
[06:13] <TomJaeger> ScottK, this is not really the problem, the problem is that nobody ever told me what the deal was
[06:14] <ScottK> TomJaeger: I don't think we knew.
[06:14] <ScottK> It's not like was all got together and said "Let's not review stuff for Intrepid".
[06:14] <ScottK> It just seems to be working out slowly.
[06:14] <TomJaeger> white, I don't have a debian system running and I think it's bad practice to personally support things that you can't test
[06:15] <ScottK> TomJaeger: It's quite possible for most types of packages to use Ubuntu and a Debian chroot to test effectively.
[06:16] <TomJaeger> ScottK, this case is pretty sensitive to the version of xserver, among other things (they sometimes gratuitously change stuff from one version to the next)
[06:18] <white> TomJaeger: are you going to maintain the package or is it a one time contribution?
[06:20] <TomJaeger> ScottK, it wouldn't have been such an issue if someone had told me that it's going to get reviewed eventually, or what I could do to speed up the process, but as it stands, I feel like I'm completely at the mercy of an elite group of MOTUs and the uncertainty has kind of held back other stuff that I had to do.
[06:20] <TomJaeger> white, yes, I do stand behind the software I write.
[06:21] <white> TomJaeger: just wondering, because it states that the MOTUs are the maintainer
[06:21] <wgrant> white: That is our policy at the moment, unfortunately.
[06:21] <wgrant> Some of us feel that it shouldn't be the case.
[06:21] <TomJaeger> I thought you were supposed to do that
[06:22] <wgrant> TomJaeger: That is correct.
[06:22] <white> TomJaeger: sounds like interesting software, i do suggest you setup a debian chroot, fill an ITP bug against wnpp on bugs.debian.org and send an email to debian-mentors@ for a sponsoring request
[06:22] <TomJaeger> It's one of the things I changed after a reading lots reviews for other packages
[06:23] <white> TomJaeger: if it works with the versions of xserver in debian and ubuntu, it could just be synced
[06:23] <TomJaeger> see, nobody has told me before that this is the way to go about this
[06:23] <white> TomJaeger: this way a broader community can benefit from it
[06:23] <white> TomJaeger: this is the debian way, but both debian and ubuntu (and all other derivates) will benefit from it :)
[06:24] <wgrant> Getting things into Debian first is almost always a better idea.
[06:24] <white> TomJaeger: and you could be the maintainer of the package :)
[06:25] <TomJaeger> The thing is, debian had a broken xserver / wacom-driver combination for like 6 months and nobody felt like doing anything about it, that's why I don't really trust debian at this point
[06:25] <white> TomJaeger: did you bring that to someones attention? it is always possible to send patches to the debian bts :)
[06:26] <TomJaeger> it was too obvious.  If anybody really did care, they would have fixed it, it was just a wacom driver update
[06:26] <white> any php guys here? If i use strip_tags() does it remove any php,java,html,$others tags from a string?
[06:26] <tgm4883_laptop> If any motu has some extra time to revu something, I'd sure appreciate another look at http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube
[06:27] <white> it sounds a little unreliable :)
[06:27] <white> TomJaeger: often the debian maintainers are pretty busy and stuff that is obvious to a certain user does not have to be obvious for the maintainers :/
[06:27] <TomJaeger> there wasn't any bug reports filed either
[06:28] <wgrant> TomJaeger: THen file a bug?
[06:28] <white> TomJaeger: see, next time just fill a bug ;)
[06:28] <white> s/fill/file/
[06:28] <wgrant> If something in one of my packages is broken on some config that I don't have, you can't expect me to fix it unless I know the problem exists. And I want to fix it.
[06:28] <TomJaeger> if I'm not running debian, why would I file a debian bug report?
[06:29] <tuxmaniac> good morning all
[06:29] <white> TomJaeger: because it makes sense fixing bugs upstream
[06:29] <ScottK> TomJaeger: We routinely forward bug reports to Debian that relevant to them too (often with patches, but not always).
[06:29] <TomJaeger> debian is upstream?
[06:29] <ScottK> For Ubuntu, sure.
[06:29] <white> TomJaeger: :)
[06:30] <ScottK> TomJaeger: There are over 1,000 Debian Developers and ~100 in Ubuntu.  We want to get as much work out of them as we can.
[06:31] <TomJaeger> So if I file a bug report that I have a certain problem on ubuntu and based on the versions of the relevant packages I suspect that the same bug exists in debian, you're saying they're not going to laugh at me?
[06:31] <white> TomJaeger: it would be nice, if you could verify that the bug exists in debian as well
[06:31] <white> TomJaeger: it is not too hard to setup a chroot ;)
[06:32] <TomJaeger> complete with x server and everything?
[06:32] <TomJaeger> are there instructions out somewhere?
[06:33] <white> TomJaeger: alternatively, you could also use one of the many emulation softwares around :)
[06:34] <TomJaeger> it seems easier to actually install debian than doing the whole chroot thing
[06:34] <white> TomJaeger: on debian sid the package FTBFSes, see http://paste.debian.net/14299/
[06:36] <TomJaeger> wow, python2.5 is a build dependency and it fails to find python
[06:37] <white> TomJaeger: are you familiar with cowbuilder/pbuilder?
[06:37] <white> TomJaeger: you might want to check it out, since it is an essential tool for building a final package and finding all build-depends
[06:37] <TomJaeger> I've used pbuilder before, though I prefer to just dump the package to my PPA and then see what happens
[06:38] <white> TomJaeger: i can recommend cowbuilder, it uses pbuilder and symlinks and is pretty fast
[06:39] <TomJaeger> okay, I'll check it out, but what you posted was a simple dpkg-buildpackage in a chroot, right?
[06:39] <white> TomJaeger: it was a build with cowbuilder
[06:39] <TomJaeger> ouch
[06:40] <white> essentially it is dpkg-buildpackage in a chroot :)
[06:40] <nxvl> damn libtool!
[06:43] <TomJaeger> white, so does cowbuilder automatically install dependencies or not?
[06:43] <NCommander> nxvl, what evil is it doing now?
[06:43] <white> TomJaeger: it uses pbuilder and yes it installs a minimal chroot and then all the build-depends
[06:43] <nxvl> NCommander: courier doesn't build in intrepid but it does on debian (same source package) because of libtool
[06:44] <TomJaeger> but how can it not find python if python-2.5 is a build-depend?
[06:44] <NCommander> nxvl, well libtool is about as nice as a pile of cow dung
[06:44] <TomJaeger> anyway, I'm capable of figuring out the details, that's not the issue
[06:45] <nxvl> NCommander: http://paste.ubuntu.com/35777/
[06:45] <TomJaeger> so you're telling me is that what I should do is try to get the package accepted into debian first?
[06:45]  * wgrant always supports that idea.
[06:46] <nxvl> TomJaeger: i use revu for revision, and once acepted in ubuntu forward it to debian
[06:46] <nxvl> debian inclusion process is widely slower than ubuntu one
[06:46] <white> nxvl: but without having a maintainer in debian, you won't get the package in
[06:46] <TomJaeger> oh, it's even slower than ubuntu?
[06:47] <NCommander> nxvl, it's fast in Ubuntu if you nag around here
[06:47] <NCommander> :-)
[06:47] <white> TomJaeger: it depends on who is reviewing it and when, can be very fast or very slow
[06:47] <white> TomJaeger: you need to find a sponsor
[06:47] <nxvl> white: you can always maintain packages
[06:47] <TomJaeger> well, I've made a decision not to go around begging for someone to review it anymore.
[06:48] <white> nxvl: of course, as long as you maintain them in debian :)
[06:48] <TomJaeger> That's too humiliating and time-consuming
[06:48] <nxvl> NCommander: please! a package can wait 2 months on incoming.d.o before it's inclusion
[06:48] <nxvl> white: that's what i meant
[06:48] <NCommander> nxvl, Oh, THAT inclusion
[06:48] <NCommander> THat's normal
[06:48] <NCommander> :-)
[06:48] <white> TomJaeger: it is an email to a mailinglist and then see, if someone picks it up
[06:48] <NCommander> It's because of the way dak handles new packages thats so braindead
[06:48] <wgrant> It's the same in Ubuntu...
[06:48] <TomJaeger> The thing is, I don't even mind it taking it a little bit longer, but I'd prefer not to be kept in the dark about the process.
[06:49] <white> NCommander: you need manual processing
[06:49] <TomJaeger> white, are you talking about debian?
[06:49] <nxvl> almost all of my debian sponsors are ubuntu developers
[06:49] <NCommander> white, yup, but its a pain to do it in dak IMHO. I don't know how Soyuz is in that respect
[06:49] <nxvl> :D
[06:49] <tgm4883_laptop> On an initial package, do we always have to list a bug?  ie, if i'm just packaging something new, do I need to also file a "needs packaging" bug?
[06:49] <wgrant> NCommander: What's so painful about it?
[06:50] <white> NCommander: why?
[06:50] <white> NCommander: it's quite easy actually :)
[06:50] <NCommander> Well, dak has six queues
[06:50] <TomJaeger> honestly, I'm not sure if I can take any more of this bureaucracy
[06:50] <NCommander> white, your a debian archive admin?
[06:50] <NCommander> (or run dak?)
[06:50] <wgrant> TomJaeger: What bureaucracy?
[06:50] <white> NCommander: i maintain dak for debian-edu
[06:50] <NCommander> Heh
[06:50]  * NCommander runs dak for the lenny m68k release ;-)
[06:50] <NCommander> Importing the entire debian archive
[06:50] <NCommander> That was fun
[06:50] <wgrant> TomJaeger: We need to stop awful packages from getting into Ubuntu. The barrier for entry is quite low.
[06:50] <white> NCommander: you have one NEW queue with all the new packages :)
[06:50] <nxvl> white: in ubuntu archive admins are faster than debian ones
[06:51] <NCommander> white, I find manually setting overrides for each package to be rather tedious
[06:51] <NCommander> white, I'm not sure if debian-edu has a contrib or non-free section
[06:51] <white> nxvl: well i am sure that if you pay some people to do NEW processing, it will be faster ;)
[06:51] <white> NCommander: we use "local", so no main, contrib or non-free
[06:52] <NCommander> white, do you require overriding every new package that hits your Incoming?
[06:52] <TomJaeger> wgrant, then tell people that their packages are probably not going to be expected, then they know what to expect instead of checking revu every day for half an hour and nothing happening
[06:52] <white> NCommander: yes
[06:52] <TomJaeger> s/expected/accepted/
[06:52] <white> NCommander: and deactivate override emails
[06:52] <NCommander> Out of the box, any package that isn't recongized needs manual intervention to be added to the archive and set the m/c/nf switch
[06:52] <nxvl> white: that's what i meant
[06:52] <NCommander> I dunno
[06:52] <wgrant> TomJaeger: Doesn't it tell you everywhere that you should ask?
[06:52] <nxvl> :D
[06:52] <NCommander> I'd find it tedious to do
[06:52] <NCommander> But thats just me
[06:53] <TomJaeger> wgrant, what do you mean, ask?
[06:53] <white> NCommander: you need to do some scripting, when you have something like openoffice hitting the queue ;)
[06:53] <wgrant> TomJaeger: You're meant to ask in this channel for people to look at your package...
[06:53] <NCommander> I need to do some scripting to import the m68k unstable binaries, and weed out ones for versions not in testing
[06:53] <TomJaeger> yeah, right, like that's going to accomplish anything
[06:53] <wgrant> Why wouldn't it?
[06:53]  * NCommander thinks TomJaeger been around d-sponsors too long
[06:53] <wgrant> If people know that your package exists, they are more likely to review it.
[06:54] <white> TomJaeger: it can be quite useful to interact with a sponsor
[06:54] <white> especially at the beginning
[06:54]  * NCommander agrees with white 
[06:54] <NCommander> white, do you run britney on your dak server?
[06:54] <white> no way
[06:55] <NCommander> ah, so you avoiding that piece of braindamage ;-)
[06:55] <white> indeed
[06:55]  * NCommander has to set it up >.<;
[06:55] <white> NCommander: my spare time is not unlimited ;)
[06:55] <NCommander> I ran britney before
[06:55] <NCommander> WIthout the connected dak server
[06:55] <NCommander> So it shouldn't be such a nightmare to get running I hope
[06:56] <TomJaeger> well, this is the only package I'm ever going to try to get in (unless I write another piece of software), packaging is not my forte, but I'll do it if it needs to be done.  I really don't know anybody who is a MOTU and who I could ask.
[06:58] <white> TomJaeger: that is not unusual
[06:58] <white> and quite often it is also fun to get to know other people and their motivations
[06:59] <white> at least i made it a habbit to have some small talk with sponsorees
[06:59] <TomJaeger> be that as it may, I don't think I have the time for all that social interaction
[06:59] <TomJaeger> if I see a bug that annoys me and I figure out how to fix it, I'll tell people
[07:00] <TomJaeger> If I have something to share with the community, I'll share it
[07:00] <TomJaeger> but that's about the extent of involment that I want to commit myself to
[07:01] <TomJaeger> if that makes me an ubuntu anti-social, then that's okay with me, I'd still like to think I'm helpful at least to some people
[07:01] <white> well, then do that and file the bugs, send an email for the package, ...
[07:01] <TomJaeger> at this point though, my primary concern is that I just don't want to deal with this issue anymore
[07:01] <TomJaeger> it's just been taking up too much of my time
[07:02] <white> TomJaeger: you are not making it easy for people to help you :)
[07:04] <white> TomJaeger: here is a guide for debian and once it's in debian it can easily be synced I guess: http://mentors.debian.net/cgi-bin/welcome
[07:05] <TomJaeger> all right, I'll try the debian route (even if that means it definitely won't make it into intrepid)
[07:06] <TomJaeger> which is frustrating, because this is what I've been working towards
[07:06] <white> when will intrepid be frozen?
[07:06] <tacone> white: 28th august I guess
[07:07] <TomJaeger> maybe three weeks from now
[07:07] <white> well, you could state your ubuntu involvement in the mail to debian-mentors@ and maybe someone, who is a MOTU and a DD will pick it up
[07:08] <TomJaeger> well, maybe
[07:08] <TomJaeger> the important thing is not to get your hopes up, though, because you are going to get disappointed
[07:09] <white> it might also not be the best idea to add a new package just before a release
[07:09] <white> bugs quite often tend to be discovered after an upload
[07:11] <TomJaeger> there's only one release every six months so this is what you're going to have to go for
[07:12] <white> a package can age though and bugs can easily be fixed in a development version
[07:12] <white> it gets harder when it comes to fixing bugs in a stable version :)
[07:14] <TomJaeger> so-called stability is overrated.  If something works for you, it works for you, the package doesn't have to be ten years old for that
[07:15] <TomJaeger> it's just a slap in the face of users who are seeing bugs that are fixed in later versions that are not deemed stable
[07:19] <TomJaeger> so does revu send out email notices if there are comments?
[07:20] <white> TomJaeger: that might be your personal view, i am pretty happy that certain servers use a stable release, instead of bleeding edge software :)
[07:21] <TomJaeger> the software that I'm developing is desktop software, not server software
[07:22] <white> and of course you always test it on all the different hardwares available to assure that it runs for everyone? You must spend a lot of time on testing ;)
[07:23] <TomJaeger> So my users have two choices: They can either use a six-month old version from the archives that is deemed stable but nevertheless does have bugs that -- while they might be annoying -- aren't really dealbreakers or they could use the latest version and if they have an issue with it they can just send me an email and I might within a few days.
[07:24] <TomJaeger> *I might fix it within a few days
[07:24] <white> this is the typical upstream vs. maintainer discussion a lot of debian people (and ubuntu i assume) have with upstreams :)
[07:25] <TomJaeger> of course I can't test every possible situation, but if an issue arises, I usually know how to fix it.  That's better than to just live with it.
[07:26] <TomJaeger> But this thing is, even if I might not agree with you guys, I'll still be willing to do things your way to get the software accepted into the archives.
[07:27] <andrew_sayers> TomJaeger: You're assuming that your users want to spend that sort of time and social effort with you.
[07:27]  * Treenaks is building a package of http://www.pharscape.org/component/option,com_forum/Itemid,68/page,viewtopic/t,425/
[07:27] <Treenaks> tiniest package _ever_ :)
[07:28] <TomJaeger> For example, even though it was a pita, I backported all the license clarifications and actually released a new upstream version with the same code, but including a license header.
[07:30] <TomJaeger> andrew_sayers, it's enough if only a fraction of the user base is willing to do that because people tend to have the same problems.
[07:30] <TomJaeger> You have to listen to them, though and not dismiss everything out of hand
[07:31] <andrew_sayers> Yeah, but the others need the out-of-date stable version.
[07:32] <TomJaeger> If they don't care enough to try out the latest version if they have a problem and they're also too lazy to contact me, then I don't care
[07:32] <TomJaeger> anyway, that's not the issue
[07:32] <TomJaeger> if I try to get a package accepted into a distribution, I'll play by the distribution's rules
[07:33] <TomJaeger> and if that means pain-in-the-ass backporting, then I'll do it
[07:33] <andrew_sayers> Well, I have no argument with that :)
[07:35] <TomJaeger> What I do have a problem with is if I ask if I should go through all this trouble and you're all like, yeah, go ahead and then nothing happens.
[07:36] <TomJaeger> The appropriate response would have been: Don't even bother to try to improve your package before you're sure anybody will be looking at it
[07:36] <white> TomJaeger: i gave you some advice now, I suggest you go and follow it. Constant blaming here will unlikely result in finding someone, who is willing to work with you
[07:37]  * porthose agrees with white
[07:38] <TomJaeger> well if I had any hope in finding anybody to work with me, I'd probably wouldn't be writing this.  This is based on the experience I previously had in this channel not on this encounter.
[07:39] <TomJaeger> That said, I do appreciate your trying to help me and I'll try to follow the advice
[07:42] <TomJaeger> So what I'm going to do is I'll unassign myself from the bug report, I'll add a comment to my revu page that I'll still be willing to work on the package, but that I'm just not going to check revu anymore, so they should email me if they have any comments and then I'll see if I can get the software running in a debian chroot or, failing that, a debian installation and then I'll try to get it into debian first
[08:09] <Druui> hi
[08:24] <ion_> superm1: Thanks a lot for the information! I was just wondering about that.
[08:25] <superm1> huh?  what did i say?
[08:27] <superm1> ion_, ^?
[08:28] <ion_> superm1: You informed all of us that you went away at 10:01 and came back at 10:19. We’re thankful for the useful information.
[08:28] <superm1> ion_, i informed?  oh no.  if my IRC proxy is informing people when i get disconnected....
[08:28] <superm1> was it just a nick change?
[08:28] <superm1> or actual away announce
[08:28] <ion_> It was an away announce in the form of a nick change.
[08:29] <superm1> ion_, yeah i had an internet hicup locally
[08:29] <ion_> Yeah, i was just saying, thanks for informing us about that.
[08:29] <superm1> but my IRC proxy does do that (it's typically more useful when i actually disconnect for extended periods of times :))
[08:51] <Iulian> Good morning.
[09:28]  * persia notices backscroll and points out that REVU sends all the comments to a mailing list, which may be easier than polling the site for those waiting for package reviews.
[09:29] <nxvl> persia: it should send them to the uploaders e-mail aswell
[09:29] <persia> nxvl: That sounds like a good idea.  Do you want to file the bug?
[09:30] <nxvl> persia: i'm just about to sleep, but i will do tomorrow morning
[09:30] <nxvl> :D
[09:30] <nxvl> i'm sick of libtool
[09:31] <persia> nxvl: I'll do it now then: it's stupidly frustrating to have to check the site every day when the system has notifications anyway.
[09:31] <nxvl> yep
[09:31] <persia> heh bug #254081
[09:33] <nxvl> the LP OpenID API should have some way to check e-mail addresses
[09:33] <nxvl> or at least ask for them in login time
[09:33] <nxvl> i think
[09:33] <nxvl> well
[09:33] <nxvl> i'm gone now
[09:33] <persia> They are available from the package anyway.  Good night.
[09:33] <nxvl> read you later (or tomorrow)
[09:33] <persia> (or, worst case, the associated GPG key)
[09:33] <nxvl> persia: heh, true
[09:50] <persia> I've an init script issue: http://paste.ubuntu.com/35805/ exits with a non-zero value when /proc/asound is not present.  Does anyone have any suggestions on how to force it to both end the init script and provide an exit value of 0 ?
[10:01]  * persia reads more about {}
[10:02] <stefanlsd> persia: what about putting it in an if statement?
[10:05] <persia> stefanlsd: Yeah, that was my next try :)
[10:05] <stefanlsd> yeah. should work.  the  [   ]   is short notation for  the linux command   test
[10:06] <stefanlsd> and the || used in the example says - only run the next part of the command if the first part fails.    (as opposed to && which says - run the next part only if the first part returns success)
[10:07] <persia> Right.  I only want to send the log message and exit the init script when there aren't any sound devices
[10:07] <persia> (it doesn't make sense to poll the sound devices when there aren't any)
[10:10] <stefanlsd> persia: probably want something like this - http://paste.ubuntu.com/35810/
[10:11] <persia> stefanlsd: I just tried it with [ ! -d /proc/asound ]; then, and an extra echo Trapped.
[10:11] <persia> It did trap it, but it didn't exit
[10:13] <stefanlsd> persia: should work - http://paste.ubuntu.com/35812/   here u can see the last echo doesnt run...
[10:21] <persia> stefanlsd: Thanks for the hint.  As it turns out, the original logic was correct: it's just that log_end_msg and log_warning_msg are failing.
[10:21]  * persia doesn't feel particularly insightful today
[10:21] <slytherin> Is it necessary to use @ubuntu.com address in changelog if you have one?
[10:21] <persia> No, although most people do.
[10:22] <slytherin> persia: is there anything for/against it?
[10:24] <persia> I try to use my @ubuntu.com email for everything Ubuntu because it makes it easier for me to filter my mail.
[10:26] <porthose> bobbo: ping
[10:26] <laga> \sh: "your wifes"? ;))
[10:26] <laga> just reading your blog post
[10:32] <slytherin> persia: what are your thoughts on this? https://bugs.launchpad.net/bugs/183139
[10:34] <persia> slytherin: Personally I like it, but 1) I think it would be better to ask in #ubuntu-java (but nobody is there right now), and I'd like to hear from yuriy, as he had some things to say about how Java was working with Kubuntu: I don't know if such a switch would break something there.
[10:36] <slytherin> persia: right, that is a point even I considered. A particular look and feel is part of JRE and does not depend on native libraries IIRC. A java app with GTK LNF will be as much odd one out on Kubuntu as much one with Metal KNF.
[10:38] <persia> slytherin: Right, although someone of the art & branding persuasion may feel that having Java be metal is somehow preferable.
[10:39] <persia> Basically, if yuriy (or someone else who has interest in both Java and Kubuntu) says GTK isn't more broken, I'd like to see it switched.  If it is more broken, I'm less sure.
[10:40] <slytherin> persia: I will attach few screenshots of an example application to that bug and let people comment on that.
[10:40] <persia> slytherin: That makes sense.  You might also try asking if anyone in #kubuntu-devel has an opinion.
[10:40] <persia> (perhaps post-screenshots)
[10:41] <slytherin> persia: I will talk to yuriy first.
[11:28] <Laney> Does a new microrelease SRU version number need ~hardy1 (or similar) at the end? As the package will be the same as the one in Intrepid
[11:30] <geser> Laney: yes, or something other between the version in hardy and the version in intrepid
[11:30] <Laney> geser: Even if the versions in Hardy and Intrepid are the same?
[11:32] <Laney> done it anyway
[11:32] <geser> Laney: does intrepid have already the new version?
[11:32] <Laney> geser: Yeah
[11:32] <geser> how can then hardy and intrepid have the same version? or do you mean after the SRU?
[11:33] <Laney> That's what I mean, yes
[11:33] <Laney> They will both be at .17-0ubuntu1 then
[11:34] <geser> as the hardy version and the intrepid version are build in different environments it's better to upgrade the package when someone upgrades from hardy to intrepid
[11:40] <emgent> moin
[11:48]  * slytherin takes a break for some food after a successful merge.
[11:49]  * Laney merges with slytherin 
[11:50] <slytherin> persia: geser: I will be glad if anyone of you can sponsor this merge - bug 227125
[11:51] <Laney> k0p: umit is built!
[11:51] <Laney> rlaney@chicken:~/dev/ubuntu/packaging/glom$ rmadison umit umit | 0.9.5-0ubuntu1 | intrepid/universe | source
[11:52] <Laney> oh, source only :O
[11:52] <Laney> well, LP says it's built :(
[11:53] <k0p> hmmm
[11:53] <geser> binary NEW: https://edge.launchpad.net/ubuntu/intrepid/+queue?queue_state=0&queue_text=umit
[11:53] <k0p> Laney, is need a requirement to compile?
[11:54] <k0p> what means that?
[11:55] <sebner> k0p: in some days it will hit the archive
[11:56] <geser> k0p: every new package gets inspected by an archive admin before it gets included into the archive
[11:56] <k0p> geser, but the sources is already on the archive
[11:56] <k0p> sebner, :) ok
[11:57] <geser> k0p: first the source needs to pass NEW, and later also the newly build debs
[11:58] <k0p> hmm ok
[11:59] <k0p> thanks everyone
[12:02] <geser> slytherin: jabref uploaded
[12:02] <slytherin> geser: thanks. :-)
[12:04] <slytherin> geser: can you please also ack removal of libjaxp1.2-java from archive? bug 251973
[12:06] <geser> I knew I've forgotten something
[12:09] <geser> slytherin: are there perhaps some third party apps that might need it? or will they work with libjaxp1.3?
[12:10] <slytherin> geser: I don't know. Should we really care about third party apps?
[12:11] <geser> slytherin: not really, I just wonder as Debian has it still in their archive and Ubuntu seldom moves ahead with removing packages
[12:12] <slytherin> geser: yes, Debian having old packages in archives is what causes people to keep using it even. But in this particular case there are no rdepends or reverse-build-depends.
[12:19] <geser> slytherin: is JAXP 1.3 the successor or JAXP 1.2?
[12:19] <slytherin> geser: yes
[12:22] <slytherin> geser: LOL, even jaxp1.3 is in end of life. There will be no further releases.
[12:22] <geser> slytherin: ACKed as upstreams also considers 1.3 as EndOfLife, so it's really time to drop 1.2
[12:24] <slytherin> geser: Do you have any non-VM installation of intrepid, is it stable enough? I was thinking about upgrading so that I can give more time on actually testing some java apps/libs.
[12:25] <geser> slytherin: my desktop is running intrepid since some weeks now, without problems (at least for me)
[12:25] <slytherin> geser: that is cool. I will upgrade today then. :-)
[12:26] <slytherin> I was thinking of upgrading my ibook first but its power adapter is broken and repair will take time.
[12:26] <geser> slytherin: please report bugs for any upgrade issues you encounter
[12:27] <slytherin> sure. :-)
[13:23]  * RainCT uploads ubuntu-dev-tools 0.35
[13:51] <slytherin> LucidFox: your timing is perfect. I was waiting for you. :-)
[13:51] <LucidFox> You fixed electric?
[13:54] <RainCT> what is debuild's -v option for?
[13:54] <slytherin> LucidFox: yes, only 2 changes not done. Everything else fixed.
[13:55] <elmargol> If I build a qt4 application it required opengl now?
[13:55] <elmargol> requires
[13:55] <LucidFox> elmargol> Only if it depends on QtOpenGL
[13:56] <geser> RainCT: without looking into the code, my guess is that it gets passed to dpkg-genchanges: Causes  changelog  information  from all versions strictly later than version to be used.
[13:57] <RainCT> geser: ah, thanks
[14:08] <slytherin> LucidFox: any comments? I am going out for some work for 2-3 hours.
[14:08] <LucidFox> slytherin> let me see
[14:14] <LucidFox> slytherin> You can generate the XPM icon from any other image in, say, GIMP, and then put it in the debian directory
[14:14] <penguin42> Does anyone here know nspluginwrapper? I've put in a launchpad entry asking for it to be upgraded to the latest version; is there any chance of that happening for Intrepid - the version in Hardy has a nasty problem with flash crashing regularly that's apparently fixed (#254422)
[14:15] <slytherin> LucidFox: is that so urgent?
[14:15] <LucidFox> probably not
[14:15] <LucidFox> let me test-build it
[14:22] <slytherin> Can anyone please explain what this condition means? ifeq (,$(filter $(DEB_HOST_ARCH), alpha))
[14:23] <LucidFox> It checks if the package is being built on the alpha platform, I think
[14:23] <LucidFox> slytherin> http://paste.ubuntu.com/35845/
[14:24] <ion_> On any other platform than alpha, i think.
[14:24] <slytherin> LucidFox: I have java home properly specified.
[14:24] <LucidFox> ah\
[14:24] <LucidFox> indeed
[14:24] <LucidFox> and I even explicitly exported JAVA_HOME when that failed
[14:25] <LucidFox> actually, with CDBS, you need to use JAVA_HOME_DIRS instead of JAVA_HOME
[14:25] <LucidFox> and list the allowed JAVA_HOME values
[14:26] <LucidFox> Ah, wait
[14:26] <LucidFox> I get it
[14:26] <LucidFox> everything is fine
[14:26] <slytherin> LucidFox: no, JAVA_HOME_DIRS is needed when you are using multiple jdk, for different arch
[14:26] <LucidFox> but I'm building the source package on Hardy, which doesn't have default-java
[14:27] <slytherin> :-D
[14:27] <LucidFox> Well, I think at least the _source_ package should build on hardy, if not the binary package
[14:28] <LucidFox> And I was under the impression that JAVA_HOME_DIRS makes ant.mk try the listed JAVA_HOMEs in order until it finds a valid one
[14:29] <slytherin> LucidFox: yes, you are right. But since it is arch all package it will be compiled on i386, so other JAVA_HOME will not come into picture anyway.
[14:30] <LucidFox> I've changed the line to
[14:30] <LucidFox> JAVA_HOME_DIRS := /usr/lib/jvm/default-java /usr/lib/jvm/java-6-openjdk /usr/lib/jvm/java-6-sun
[14:30] <LucidFox> now it builds
[14:31] <LucidFox> now building the binary package in pbuilder
[14:31] <slytherin> LucidFox: Then change it to ﻿JAVA_HOME_DIRS := /usr/lib/jvm/default-java /usr/lib/jvm/java-5-sun /usr/lib/jvm/java-6-sun please.
[14:32] <LucidFox> why not openjdk first?
[14:32] <LucidFox> I can insert java-1.5.0-sun, but I'd like to keep openjdk
[14:33] <slytherin> LucidFox: default-java is symlink to openjdk
[14:33] <LucidFox> On Intrepid. But not Hardy.
[14:33] <slytherin> LucidFox: but the update is for intrepid right? :-)
[14:34] <LucidFox> Yes, but I need to build the source package first before uploading it
[14:34] <slytherin> LucidFox: on hardy it will build with sun jdk since there is no openjdk in build depends.
[14:34] <slytherin> I mean for you at least.
[14:34] <LucidFox> I don't have Sun JDK installed! It's proprietary! :p
[14:34] <LucidFox> just kidding
[14:35] <LucidFox> but this will allow it to be backported
[14:35] <LucidFox> (hopefully)
[14:35] <slytherin> LucidFox: Build it in intrepid pbuilder. It is risky matter to upload something to intrepid but testing it in hardy pbuilder.
[14:35] <slytherin> LucidFox: if you are thinking about backport, then it will be good to also add openjdk in build depends.
[14:36] <LucidFox> I'm testing the binary package in intrepid pbuilder
[14:36] <LucidFox> but to test something in pbuilder (or to upload  it to Ubuntu for that matter), I need to build the source package first :)
[14:37] <slytherin> LucidFox: Ok. Whatever way you want to do it. I am going now. Will be back after 2-3 hours.
[14:37] <LucidFox> All right
[14:37] <LucidFox> I'll be still online then
[14:43] <persia> RainCT: To answer the question differently, -v is used when uploading something that spans several changelog entries, as when processing a merge from Debian.
[14:44] <persia> sebner: Please fix bug #256347
[14:45] <sebner> persia: I'm unsure "how" ;)
[14:45] <persia> sebner: Well, how did the package get this way: did you package it through REVU?
[14:46] <sebner> persia: yes, I was first and my package is better but I don't want to be rude :)
[14:46] <persia> sebner: Ah.  Right.  Grumble.  This is why it's good to file an ITP :)
[14:46] <persia> Anyway, can it be merged?
[14:47] <persia> Also, if the package isn't based on the Debian package, it might be good to mention that in the bug, although I still think it's worth doing a merge.
[14:47] <persia> (depends on things like the orig.tar.gz, etc.)
[14:48] <sebner> persia: In generel I can merge it though it differes sometimes
[14:48] <sebner> persia: how are my changes to convince him to make me the debian maintainer?
[14:48] <persia> sebner: Are the orig.tar.gz files the same?
[14:48] <persia> Your chances are fairly low, although you may be able to be co-maintainer.
[14:49] <persia> When you package something, it's best practice to file either an RFP or ITP in Debian: the former if you want someone else to be Maintainer, and the latter if you want to be maintainer.
[14:49] <sebner> persia: I'm sure he not even contaced upstream -.-
[14:50] <persia> sebner: He could have copied your package, changed it to put in his name, and he would still be able to be "Original Maintainer".  This seems odd, but is a consequence of the goal of basing everything off Debian.
[14:51] <sebner> persia: however I think it's better if I try first 1) ask if I can be (co-)maintainer 2) convince him to take some patches (manpage ,..) so we can sync it
[14:52] <persia> sebner: That does sound better.  You could even have the conversation in the bug: first note that you didn't base the package off his, but created it separately, and would be happy to collaborate.
[14:53] <sebner> persia: because I have good contact with upstream and package another programm of him :P
[14:53] <sebner> morning afflux :)
[14:54] <sebner> persia: *packaged
[14:54]  * afflux kicks the loose cable in the hub under the table
[14:54] <afflux> heya sebner :>
[14:54] <sebner> afflux: wlan?
[14:54] <persia> My.  Looking at the "patch", I think it's fairly clear there is no common history between the packages.  I wonder why he thinks you based it off his package.
[14:54] <afflux> sebner: ni ni ni!
[14:55] <sebner> persia: dunno, debian guys ....
[14:55] <persia> sebner: Indeed.  That's exactly the sort of upstream coordination that would suit you well as the Debian Maintainer, but now that there is another one, you'll need to coordinate.
[14:55] <persia> sebner: Careful: there's no small number of Debian developers here :)
[14:55] <sebner> persia: hrhr, I know :P
[14:56] <sebner> persia: btw, how you got attention to that (small) bug? O_o
[14:57] <azeem> he's not a DD
[14:57] <azeem> AFAICT
[14:57] <azeem> (or she)
[14:57] <sebner> azeem: who?
[14:58] <azeem> hrm, I thought this was about https://launchpad.net/bugs/256347
[14:58] <sebner> azeem: sure he isn't
[14:59] <sebner> azeem: he has 2 packages in Debian
[14:59] <sebner> huhu DktrKranz
[14:59] <persia> sebner: I (try to) watch all the bugs as they arrive in #ubuntu-bugs-announce.  Some of them I think out be escalated.
[14:59] <DktrKranz> aloha sebner
[14:59] <azeem> sebner: well, it's not clear whether it's a man or a woman from the name, I think
[14:59] <sebner> azeem: https://edge.launchpad.net/~angel-abad  ;)
[15:00] <sebner> persia: kk, btw. what about you being a DD?
[15:00] <azeem> sebner: oh, so it's a Ubuntu guy, rather :P
[15:00] <persia> sebner: What?
[15:00] <sebner> persia: no intention to become one?
[15:01] <sebner> azeem: not that active though
[15:01] <persia> sebner: No time, really.  I maintain 1 package in Debian (and might add some more if I have time), and work with a collaborative Debian team.  I don't find not having upload rights blocks me much.
[15:01] <sebner> persia: kk :)
[15:02] <DktrKranz> sebner, what about YOU to become one? :P
[15:03] <persia> sebner: One of the requirements when undergoes the NM process is a demonstration that one can allocate sufficient time to be a good DD.  It's not all about technical knowledge or understanding the social contract.
[15:03] <sebner> DktrKranz: you can mentor me if you are one :P
[15:03] <sebner> persia: I see :)
[15:03] <persia> sebner: It doesn't quite work that way: you'll want to get an AM from the Front Desk if you want to do NM.
[15:04] <sebner> persia: joke ;)
[15:04] <persia> sebner: Why?  It's a reasonable goal, and if you're as active as you are, it may be useful to be a DD.
[15:05] <azeem> becoming a DM takes less time and is quite useful as well
[15:05] <sebner> persia: hrmpf, People are telling me I should apply for motu. Even more you and DktrKranz are telling me to become a DD. Calm down folks xD
[15:06] <DaneM1> Hi, everybody.  I'm a novice at packaging (trying to learn), and I'm trying to package the latest version of empathy for hardy.  It compiles just fine using the ./configure && make && make install method, but when I try to compile it in pbuilder, it errors out.  I've copied the build-depends from the one in the intrepid source repos., and made packages (using pbuilder) for the dependencies that are not in the hardy repos.  Can
[15:07] <persia> sebner: Well, they are different.  Typically one applies for MOTU after completing the demonstration period.  In Debian, it's wise to apply early, as then one's work (e.g. collaboration on almanah) counts towards the demonstration.
[15:07] <persia> On the other hand, if you want to focus your time on MOTU, we shan't complain :)
[15:07] <sebner> persia: you say it man :)
[15:13] <RainCT> persia: thanks for the info (I was away)
[15:15] <mok0> Hmm, my upload to REVU never showed up.
[15:15] <persia> RainCT: -v and -k and what not are the sorts of things that are useful as MOTU, but fairly meaningless when requesting sponsorship.  There might be some others.  Might you have time to collect them on a wiki page?  I'm thinking it might be good to have a doc for new MOTU that covers the differences between things that are to be sponsored and things that are to be uploaded.
[15:20] <mok0> Has anything changed wrt REVU over the summer? (apart from the layout)
[15:21] <RainCT> mok0: Yes, it has a new suer system. You authenticathe over OpenID with Launchpad, now
[15:21] <persia> mok0: The means by which one logs in, the means by which keys are synced, and more.  Usage is mostly the same.
[15:22] <RainCT> mok0: and instead of getting the keys from all members of revu-uploaders periodically, they are synced for the individual users each time they log in
[15:22] <mok0> RainCT: how would that affect an upload?
[15:23] <mok0> RainCT: perhaps I need to log on once using openid?
[15:23] <RainCT> mok0: You have to log in once before you upload so that your key is synced. Also, you can merge your old account after logging in, so that you get your MOTU status back.
[15:23] <mok0> :-)
[15:23] <mok0> RainCT: thanks
[15:24] <RainCT> yw :)
[15:25] <mok0> RainCT: hey that's cool!
[15:25] <DaneM1> would somebody mind helping me with my packing problem?
[15:25]  * mok0 re-uploads
[15:25] <persia> DaneM1: Please describe said problem.
[15:26] <DaneM1> I'm a novice at packaging (trying to learn), and I'm trying to package the latest version of empathy for hardy.  It compiles just fine using the ./configure && make && make install method, but when I try to compile it in pbuilder, it errors out.  I've copied the build-depends from the one in the intrepid source repos., and made packages (using pbuilder) for the dependencies that are not in the hardy repos.
[15:26] <persia> mok0: No need for that: just ask for queue reinsertion :)
[15:26] <azeem> DaneM1: you will have to quote the error for us being to help you
[15:27] <DaneM1> I want to learn some stuff, test empathy with Asterisk, and make my work available to anybody who wants it :-)
[15:27] <mok0> persia: arghh didn't see your note before I uploaded.
[15:27] <DaneM1> sure.  One min.
[15:28] <DaneM1> Here's a sample.  I'll pasebin the rest...
[15:28] <DaneM1> libtool: link: x86_64-linux-gnu-gcc -shared  .libs/pyempathymodule.o .libs/pyempathy.o   -Wl,-rpath -Wl,/tmp/buildd/empathy-2.23.6/libempathy/.libs -lffi /usr/lib/libgconf-2.so /usr/lib/libglade-2.0.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libfreetype.so -lz -lfontconfig 
[15:28] <DaneM1> .libs/pyempathymodule.o: In function `pygobject_init':
[15:28] <DaneM1> /usr/include/pygtk-2.0/pygobject.h:315: undefined reference to `PyImport_ImportModule'
[15:28] <DaneM1> /usr/include/pygtk-2.0/pygobject.h:337: undefined reference to `PyObject_GetAttrString'
[15:28] <persia> mok0: reuploading works too, but REVU admins (when they are around) can just copy the .changes from rejected into the queue, which saves bandwidth and later rejection cleanup.
[15:28] <mok0> DaneM1: missing dependency
[15:28] <DaneM1> (sorry if I spammed...not sure how much I can paste)
[15:29] <DaneM1> figured that.  I really don't know what to do though; I've searched google and added a bunch of python and other stuff to build-depends, to no avail.
[15:29] <DaneM1> should I pastebin any files so you can see what I've been trying?
[15:30] <persia> Better to use a pastebin rather than pasting directly in the channel.  paste.ubuntu.com is one.
[15:30] <DaneM1> ok
[15:30] <RainCT> DaneM1: Which version do you want? If 2.23.6 is enough you might be able to rebuild the version from Intrepid for Hardy
[15:30] <laga> DaneM1: okay, so you backported the dependencies with pbuilder and now you're trying to build empathy in pbuilder?
[15:30] <DaneM1> empathy-2.23.6
[15:31] <mok0> DaneM1: Let's see your Depends line too
[15:31] <DaneM1> laga: that's right.  I've built the depends (telepathy and missioncontrol stuff) using pbuilder.
[15:31] <persia> Actually, a pastebin of debian/control would be better than just the depends.
[15:32] <DaneM1> mok0: sure...pastebinning my control file
[15:33] <DaneM1> http://pastebin.ubuntu.com/35860/
[15:33] <laga> DaneM1: and now you're building empathy in pbuilder?
[15:33] <DaneM1> much of it is copied from the intrepid source package (hope that's not considered plaigurism or some such).
[15:33] <DaneM1> laga: yes.
[15:33] <laga> DaneM1: well, you need to make sure the dependencies are available in pbuilder
[15:34] <laga> otherwise, pbuilder will just use what's available in the repositories
[15:34] <DaneM1> laga: nodnod.  I've used --login --saveconfig and added them to the archive using another terminal, then installed them using the logged-in terminal.
[15:35] <laga> ah. okay.
[15:35] <mok0> DaneM1: but did you update your pbuilder recently?
[15:35] <DaneM1> mok0 hmmm...don't think so.  I'll do that now.
[15:36] <DaneM1> mok0: "0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded."
[15:37] <ScottK> Hello mok0.
[15:37] <ScottK> It's been a while since I've seen you.
[15:37] <mok0> ScottK: yeah, I've been busy doing other stuff
[15:38] <mok0> Now I am resurfacing...
[15:39] <ScottK> Great.  Glad to have you back.
[15:39] <mok0> :-) thanks
[15:39] <mok0> Good to be back
[15:39] <DaneM1> here's the error in its entirety: http://pastebin.ubuntu.com/35865/
[15:40] <mok0> DaneM1: yeechhh
[15:40] <DaneM1> mok0: hehe...no fun here :-p
[15:41] <mok0> DaneM1: Looks like pygtk-codegen-2.0 is having trouble
[15:41] <mok0> That could be the cause of your problems
[15:41] <DaneM1> hmm...I wonder if I should specify that explicitly as a build-depend...
[15:42] <DaneM1> that's odd...it's not in the hardy repos, as far as I can tell
[15:42] <mok0> DaneM1: It looks like it's run alright, but it fails
[15:43] <DaneM1> mok0: any idea why it would build find on my fully updated hardy install, but not in a fully updated pbuilder?
[15:43] <mok0> DaneM1: It's in python-gtk2-dev
[15:43] <mok0> DaneM1: not right now :-)
[15:44] <DaneM1> mot0: maybe the package is messed-up.  Should I try clearing the archive?
[15:44] <mok0> DaneM1: I don't think that will  help
[15:44] <DaneM1> k
[15:45] <DaneM1> mok0: I'm going to try making a new pbuilder...maybe that will help (I've messed with this one a lot)
[15:45] <mok0> DaneM1: what is the version of  python-gtk2-dev in your pbuilder/workstation respectively?
[15:45] <DaneM1> checking...
[15:46] <DaneM1> mok0: lol!  It's not even installed on my workstation!
[15:46] <DaneM1> mok0: maybe if I remove it entirely from the build-depends...
[15:46] <mok0> DaneM1: Huh? And you can build the package?
[15:47] <DaneM1> mok0: yeah!  very strange.  I wonder if the library(ies) are provided by another package
[15:48] <mok0> DaneM1: ... or perhaps that codegen thing is not called when it isn't installed, and it's not really needed
[15:48] <DaneM1> mok0: could be.  I'm trying a build without python-gtk2-dev...
[15:48] <mok0> DaneM1: k
[15:51] <DaneM1> mok0: OK...now we're getting somewhere: I have a different error, later in the compile process!
[15:51] <mok0> DaneM1: your first log does say: "Warning: Constructor for EmpathyChatroom needs to be updated to new API"
[15:51] <DaneM1> mok0: (lines separated by "\"): dh_installchangelogs ChangeLog \ install: cannot stat `ChangeLog': No such file or directory \ dh_installchangelogs: command returned error code 256
[15:51] <DaneM1> mok0: what does that mean?
[15:52] <azeem> it means there's no ChangeLog file
[15:52] <mok0> the dh_install... is called from debian/rules
[15:52] <DaneM1> hehe should I just rename changelog to ChangeLog?
[15:52] <mok0> DaneM1: no
[15:52] <DaneM1> k
[15:53] <mok0> DaneM1: check in rules
[15:53] <DaneM1> nodnod.
[15:53] <mok0> DaneM1: you can change the name there
[15:53] <DaneM1> it was called ChangeLog in rules.  Changed it to lowercase...trying again
[15:54] <RainCT> bobbo: why does mozilla-checky have a ubuntu2 revision but not a ubuntu1? :P
[15:54] <mok0> DaneM1: Perhaps you should check in the empathy writeup... it seems the newest version requires a very new version of python-gtk2
[15:55] <DaneM1> mok0: where might I find the writeup?
[15:55] <ScottK> RainCT: I read your mail on mozilla stuff.  I think that needs to be on a wiki page somewhere if it's not already.
[15:55] <mok0> DaneM1: I suppose it must be in the tarball
[15:55] <mok0> DaneM1: README?
[15:55] <DaneM1> mok0: aah...silly me :-)
[15:56] <mok0> nomen est omen
[15:56] <DaneM1> mok0: it just says to use ./autogen.sh, make, make install, then run empathy.
[15:57] <mok0> DaneM1: it doesn't say anything about what else is required?
[15:57] <DaneM1> mok0: no :-(
[15:57] <mok0> DaneM1: what about upsstream''s website?
[15:57] <DaneM1> looking
[15:59] <porthose> nxvl: ping
[15:59] <nxvl> porthose: :D
[16:00] <mok0> DaneM1: be back in 15 min
[16:00] <DaneM1> k
[16:00] <porthose> could you update junior.csv for me my bzr is broken right now
[16:00] <porthose> bobbo paired with suman
[16:01] <nxvl> ok
[16:01] <bobbo> porthose: pong
[16:01] <porthose> nxvl thx
[16:01] <bobbo> sorry!
[16:01] <porthose> bobbo: np
[16:01] <nxvl> porthose: starting date today?
[16:01] <porthose> nxvl: yes
[16:03]  * porthose goes back to fixing bzr
[16:05] <RainCT> ScottK: okay, I'll write it down somewhere
[16:06] <nxvl> porthose: just rm -rf and branch
[16:06] <porthose> nxvl: will try that :)
[16:10] <nxvl> porthose: pushed
[16:10] <porthose> :)
[16:42] <LucidFox> Is "debian-changelog-line-too-long" a blocker for updated packages?
[16:43] <Kopfgeldjaeger> nm 0.7 in intrepid \o/
[16:43] <Treenaks> Kopfgeldjaeger: but it breaks on my pcmcia/umts card
[16:44] <mok0> LucidFox: can't you fix it?
[16:44] <LucidFox> I can, but is it allowed?
[16:44] <Kopfgeldjaeger> yeah, it probably really needs some (eeh.. damn much) tuning
[16:44] <LucidFox> when sponsoring someone else's package
[16:44] <persia> LucidFox: No, but if the too-long changelog entry is in the most recent changelog, it's best to get it fixed before uploading.
[16:44] <LucidFox> yes, it is in the most recent entry
[16:45] <persia> LucidFox: Yes, if you just add whilespace to the changelog, and want to give them credit, that's usually fine.
[16:45] <mok0> LucidFox: it is just the wrapping that needs fixing
[16:45] <persia> If you do something more substantive, it's good to add it to the changelog so you get a multiple-author changelog.
[16:57] <persia> norsetto: actually, there's a few things that FTBFS because of the timidity thing: something appears to have changed in the way chroots handle /sys for intrepid, which made that significantly less of a corner case.
[16:57] <RainCT> how can I mark code blocks on the wiki?
[16:59] <tgm4883_laptop> If any motu has some extra time to revu something, I'd sure appreciate another look at http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube
[16:59] <persia> RainCT: https://wiki.ubuntu.com/HelpOnFormatting
[16:59] <RainCT> thanks
[17:00] <LucidFox> Is it possible to validate man pages without building a package and running lintian against it?
[17:01] <RainCT> LucidFox: try man --warnings
[17:02] <LucidFox> tried, and it doesn't print any warnings
[17:02] <persia> LucidFox: You can fiddle with nroff -man and lexgrog if you like.
[17:02] <LucidFox> but lintian does
[17:02] <persia> Which error?
[17:04] <LucidFox> W: electric: manpage-has-errors-from-man usr/share/man/man1/electric.1.gz 256: warning: `cadrc' not defined
[17:04] <LucidFox> This is the only warning lintian gives - but when I open it in mc, it prints a different warning entirely
[17:04] <LucidFox> man --warnings -l electric.1 doesn't produce any warnings at all
[17:07] <persia> Strange.  That seems to be exactly the command lintian runs against it.
[17:08] <persia> Maybe the groff_man or groff_mdoc manpages can help?
[17:08] <LucidFox> I've looked at the source for /usr/share/lintian/checks/manpages
[17:09] <mok0> LucidFox: did you try lexgrog?
[17:09] <RainCT> ScottK, fta: https://wiki.ubuntu.com/MozillaTeam/Extensions/Merging
[17:09] <RainCT> (improvements are welcome)
[17:09] <ScottK> RainCT: Thanks.
[17:10] <LucidFox> "lexgrog electric.1" doesn't generate any warnings either
[17:11] <persia> LucidFox: Hmmm..  Frustrating, that.
[17:11] <ScottK> RainCT: Looks reasonable to me, my only comment is that I'm not sure Debian can write Iceweasel/Firefox in anything visible to the end user without trademark problems.
[17:11] <LucidFox> Guess I'll have to rebuild the package on every manpage change
[17:11] <RainCT> ScottK: I don't know, but I've seen packages in Debian that do this
[17:11] <LucidFox> Oh come on...
[17:12] <RainCT> ScottK: but being the extensions which says which says that it works with Iceweasel and Firefox I don't see why it might be a problem
[17:12] <ScottK> RainCT: Make sense.
[17:12] <LucidFox> Just because "Firefox" is a Mozilla trademark doesn't mean everyone suddenly can't use the "Firefox" in any text whatsoever.
[17:12] <LucidFox> * the word
[17:12] <ScottK> Understand.
[17:13] <persia> LucidFox: But likely not in the context of a computer program except when referencing the specific trademarked product.
[17:13] <azeem> "Remember, it's spelled `Netscape', but pronounced `Mozilla'"
[17:13] <persia> (depends on where it's trademarked, where the text exists, and prevailing fashions in interpretation of trademark law in the jurisdiction in which the conflict is considered)
[17:14] <LucidFox> So I can't say "This program works under Windows" just because I can't distribute software and call it "Windows"?
[17:16] <Kopfgeldjaeger> http://changelogs.ubuntu.com/changelogs/pool/main/j/john/john_1.7.2-3ubuntu1/changelog <-- hm, interesting changelog entry
[17:16] <persia> LucidFox: Rather, if you use the word "Windows" in the context of computer software, you should mean "Microsoft Windows" explicitly, rather than some other meaning.
[17:16] <persia> Mind you, this is a poor example, as "Windows" itself isn't trademarked for use in Computer Software
[17:17] <persia> (although e.g. "Windows XP" is)
[17:17] <LucidFox> From my understanding, "Firefox" being a Mozilla trademark simply means that you can't distribute something and call it Firefox without their permission. I don't think it prohibits you to distribute software claiming that it's "a Firefox extension", which is what the question is about.
[17:17] <persia> You also are prohibited from referring to epiphany-browser as "Firefox".
[17:17] <LucidFox> Someone does that?
[17:18] <RainCT> persia: yes, but because then you would be claiming that Epiphany *is* Firefox, not that it can be used with Firefox, like in the case of the extensions
[17:19] <persia> RainCT: Well, maybe.  None of us is likely to provide actual legal advice to Debian in #ubuntu-motu, nor should they accept it if we tried (SPI has counsel for that). :)
[17:29] <RainCT> Adri2000: still nothing new about MoM?
[17:31] <ScottK> dholbach: A couple of us are discussing an idea for harvest.  Would you be able to join us on #ubuntu-quality ?
[17:38] <RainCT> bobbo: ping
[17:39] <Adri2000> RainCT: Keybuk replied to some bugs a few days ago
[17:42] <bobbo> RainCT: hey
[17:44] <RoAkSoAx> hay guys, i have a question! Is there a policy about triaging [need-packaging] bugs? (I mean, for example, if some package is currently unmaintained... how should we set the Status and Importance)
[17:44] <bobbo> RainCT: can you email or /msg me it? I'm just about to go out
[17:45] <RainCT> bobbo: I just wanted to ask if you tested mozilla-checky with Firefox 3
[17:45] <bobbo> RainCT: I dont think I have been working on mozilla-checky...
[17:45] <RainCT> bobbo: the last revision is from you
[17:46] <bobbo> RainCT: ah, no I wasnt aware I should have been testing it
[17:46] <RainCT> RoAkSoAx: Not that I know.. Just check if it's in Ubuntu or the current Ubuntu development version and if it isn't and the licensing is fine, mark it as confirmed
[17:47] <RainCT> bobbo: You've added firefox as an alternative dependency to it, but Debian doesn't have iceweasel as one, and the homepage says that it was tested with Firefox 1.0
[17:47] <bobbo> RainCT: so you want me to test it on an Intrepid firefox 3 to make sure it is actually an alt dependency?
[17:48] <RainCT> bobbo: I removed it again, and did some some other changes necessary for the package to work with SeaMonkey (see my mail on ubuntu-motu@)
[17:49] <RainCT> bobbo: but yes, if you want you can test it with Firefox 3 and if it works add the alternative dependency again (but you'll have to figure out what symlink you've to create for Firefox to recognize it)
[17:49] <bobbo> RainCT: ah ok, I wasnt totally sure of what I was doing for that upload, so you;ve probably fixed it :D
[17:49] <bobbo> right i gotta go
[17:49] <RainCT> bobbo: okay, have fun
[17:50] <RoAkSoAx> RainCT, ok cool thanks :)
[17:51] <RainCT> RoAkSoAx: also ensure that they have the needs-packaging tag (beside having "[needs-packaging]" in the title) and set the importance to wishlist if you can
[17:51] <RoAkSoAx> RainCT, will do :) thanks
[17:51] <RainCT> but that isn't that important; I've a script for that which I run from time to time :P
[17:52] <RainCT> np :)
[17:52] <dholbach> ScottK: do you think you could file a bug about it? I'm about to leave in a bit
[17:52] <persia> RoAkSoAx: The best way to progress those bugs is to package the software: of course, please only package software that you actually want to use, and would be willing to help keep up to date.
[17:54] <ScottK> dholbach: It's more complicated then that.
[17:54] <ScottK> dholbach: You should join us in #ubuntu-quality when you have some time.
[17:54] <dholbach> I'm invited to a birthday party and need to leave in a bit
[17:55] <RoAkSoAx> persia, what if the software is no longer maintained but is still useful... wouldn't it be a deprecated piece of software after a while? and maybe is useless to package it?
[17:55] <ScottK> Sure
[17:57] <persia> RoAkSoAx: If upstream is no longer there, maybe "wontfix" is the right status for the bug.  If upstream is around, and the package is "mature" (there is a community, but no commits, and no outstanding bugs), it depends entirely on how useful the software could be.
[17:59] <RoAkSoAx> persia, perfect, that's what i wanted to know exactly, thanks :)
[18:03] <slytherin> LucidFox: I am back
[18:03] <LucidFox> slytherin> Good, I've found two more issues in electric
[18:03] <slytherin> tell me
[18:04] <LucidFox> W: electric: manpage-has-errors-from-man usr/share/man/man1/electric.1.gz 256: warning: `cadrc' not defined
[18:04] <LucidFox> W: electric: debian-changelog-line-too-long line 27
[18:05] <slytherin> ahh, I must have overlooked lintian warnings
[18:06] <LucidFox> you should run lintian on the deb after building
[18:06] <persia> (lintian -iIv, and on the $(arch).changes file)
[18:07] <slytherin> LucidFox: hmm, I am not sure what Ican do about manpage since I didn't write it. But I will fix changelog problem.
[18:07] <RoAkSoAx> is there any wikipage on how to use lintian ?
[18:07] <LucidFox> man lintian
[18:07] <LucidFox> :)
[18:07] <LucidFox> per persia's advice, I use "lintian -iIv packagename.deb"
[18:08] <RoAkSoAx> what about dsc's
[18:08] <LucidFox> slytherin> who did write the manpage, though?
[18:08] <persia> What!  No.  $(arch).changes
[18:08] <LucidFox> what's the difference? :)
[18:08] <RainCT> persia: what's the difference?
[18:08] <RainCT> :P
[18:08] <slytherin> LucidFox: it was there in debian directory in previous version, 6.x
[18:08] <LucidFox> ah
[18:08] <LucidFox> well, you can modify it
[18:09] <persia> IF you run on $(arch).changes, lintian will process all the .deb files generated by the package.  Also, it won't repeat the verbose explanation for the errors on repeats, but only once, which makes the output less obnoxious to read.
[18:09] <LucidFox> ah
[18:09] <LucidFox> I didn't know it was possible to run lintian on deb packages
[18:09] <persia> (in the case where the package only creates one .deb, it's not that different, really, except that it checks a couple things in the .changes file)
[18:10] <persia> Yep.  You can run on .deb, .changes, or .dsc
[18:10] <persia> For maximum information about a pacakge in a single run, you want to have a .changes that represents both a source and binary build.
[18:10] <LucidFox> persia> slytherin is preparing a major world-breaking update for a package removed from unstable (but still in testing), should we strive for lintian cleanliness or minimum divergence from the old Debian package?
[18:10] <persia> Of course, generating one of those safely is tricky :)
[18:11] <persia> LucidFox: If it's no longer maintained in Debian (either orphaned or removed), and we want it, strive for perfection.
[18:11] <LucidFox> aye, captain
[18:11] <slytherin> persia: mr. tuxmaniac from motu science team requested the update. :-)
[18:13] <persia> slytherin: Then you know who to poke to help test :)
[18:13] <sebner> persia: do you know if debian meebey repo something (semi-)official?
[18:14] <persia> sebner: I don't understand that question.
[18:14] <sebner> persia: forgot a "is" ^^
[18:15] <sebner> persia: http://debian.meebey.net/
[18:18] <persia> sebner: Never heard of it before.
[18:18] <sebner> persia: so a private project!? thanks :)
[18:19] <sebner> nxvl: go go go ... for motu
[18:22] <LucidFox> meebey has a website?
[18:22] <LucidFox> I didn't know
[18:22] <sebner> ^^
[18:22] <sebner> LucidFox: you know them?
[18:22] <nxvl> sebner: :D
[18:23] <LucidFox> meebey? He's Mirco Bauer, a Mono maintainer, and he's available on #debian-mono on irc.oftc.net
[18:23] <sebner> LucidFox: so his private repo?
[18:23] <LucidFox> No idea - I didn't know it existed
[18:24] <sebner> ah ok ^^
[18:24] <nxvl> sebner: i'm scared as hell
[18:25] <sebner> nxvl: why? I think you'll make it easily
[18:26] <nxvl> sebner: yep, but not having a review and being myself in front of the archives makes me scared (i think everyone is at the beginning
[18:26] <nxvl> )
[18:26] <sebner> nxvl: don't worry =)
[18:26] <RainCT> :)
[18:32] <LucidFox> sebner>
 its the playground for the official packages
 whatever goes there will end up sooner or later in debian
[18:34] <sebner> LucidFox: fine fine, thx
[18:35] <emgent> heya
[18:36] <sebner> emgent: \o/
[18:51] <slytherin> LucidFox: what is JAVA_HOME for sun-java6-jdk?
[18:51] <LucidFox> /usr/lib/jvm/java-6-sun
[18:52] <slytherin> LucidFox: are you sure? because for 5, it is /usr/lib/jvm/java-1.5.0-sun
[18:52] <LucidFox> Yes, I'm sure
[18:52] <LucidFox> I sincerely beg you to include openjdk as well, its JAVA_HOME is /usr/lib/jvm/java-6-openjdk
[18:52] <slytherin> LucidFox: yes that is what I am doing
[18:53] <marnold> Hello does anyone have any objections to re-introducing emerald-themes for intrepid
[18:54] <sebner> marnold: isn't emerald obsolete?
[18:54] <slytherin> marnold: why were they removed?
[18:55] <sebner> slytherin: isn't that a beryl thing?
[18:55] <slytherin> sebner: So emerald does not work at all with compizfusion?
[18:55] <marnold> the logs say removal of beryl but emerald is still in the repos
[18:55] <sebner> slytherin: I think that was the window manager of beryl and pretty obsolete
[18:56] <persia> marnold: Is that better then removing emerald from the repos?
[18:56] <marnold> it and the themes tarball are sti;; being maintianed upstream
[18:56] <RainCT> uh? emerald works fine here
[18:56] <marnold> still *
[18:56] <slytherin> marnold: well you first need to answer this question. "Does emerald work with compizfusion"?
[18:56] <marnold> yes
[18:57] <marnold> as i am using it
[18:57]  * RainCT can confirm that
[18:57] <marnold> and upstream still maintains it
[18:58] <marnold> and it is still in the archive
[18:58] <RainCT> yep, I think I update the package to a new version some months ago
[18:58] <marnold> looks like someone just forgot to do the themes package
[19:02] <slytherin> persia: did you get a chance to look at MoveToUniverse page?
[19:03] <RainCT> guys.. I'm working on user feeds for REVU and I need feedback on how you would like it to be
[19:03] <nxvl> RainCT: o/
[19:04] <nxvl> RainCT: that's the idea?
[19:04] <nxvl> RainCT: to have an rss feed about the comments?
[19:04] <RainCT> eg, having one entry for each package and listing all the comments in it, having individual entry for all comment against uploads from you and entries for all uploads, etc
[19:05] <RainCT> nxvl: atom, but yes
[19:05] <nxvl> RainCT: so i will need to subscribe myself to every package's feed?
[19:06] <nxvl> RainCT: wouldn't it better to use the main information from the package and send them by mail?
[19:08] <RainCT> nxvl: I said "user feed", not "package feed" (which is also planned) :)
[19:09] <RainCT> and mail notifications are also planned, but for some reason I find email stuff boring and will leave that for NCommander :P
[19:10] <nxvl> RainCT: so one feed for all my packages? that would be awesome
[19:10] <RainCT> yep
[19:14] <RainCT> nxvl: the question is, should it have entries for everyting ("Uploaded package XXX, upload id YYY" entries which would say if it is lintian clean or not and not much more, "Comment for package XXX (YYY) from ZZZ" entries for each comment, etc.) or some other structure?
[19:16] <nxvl> RainCT: i know what i did
[19:16] <nxvl> RainCT: i want to know what everyone else do
[19:17] <RainCT> nxvl: yep, with the comments I mean all comments against a package uploaded by you
[19:18] <nxvl> RainCT: yeah, what i meant is: i don't really want to get an update about if i uploaded a package
[19:18] <nxvl> RainCT: i know that i did it
[19:19] <nxvl> RainCT: what i found awesome is in mentors.debian.net you get an ACCEPTED or Rejected e-mail (as in the archive) about your packages
[19:20] <RainCT> nxvl: (about the uploaded packages:) ah, yes. but this way I can put the lintian output and such stuff there (which nobody seems to notice). also, you can subscribe to feeds from other people (like your mentee or whatever)
[19:20] <nxvl> RainCT: agreed
[19:20] <slytherin> persia: any idea why updates to netbeans packages are on revu? There should be bugs logged instead, right?
[19:20] <RainCT> perhaps a &uploads=no option could be added, but I'm not sure if that's really necessary
[19:24] <nxvl> RainCT: no, now that i understand what you meant i'm for it
[19:25] <slytherin> LucidFox: I am almost done. fixed both warnings. Added openjdk to build deps and made a small change in get-orig-source.
[19:25] <LucidFox> slytherin> Great
[19:26] <LucidFox> Have you uploaded it?
[19:26] <slytherin> LucidFox: doing a last build to be sure. 5 minutes.
[19:34] <penguin42> hi I'd like to ask for nspluginwrapper to be updated to the latest version - I can't see a Debian version of it either however; the version in Hardy is very very flaky but apparently fixed in the latest version; I've filed a launchpad bug #254422
[19:35] <crimsun> penguin42: it has been updated source-wise in a ppa.
[19:36] <crimsun> penguin42: i.e., the mozillateam has it in its ppa.
[19:36] <penguin42> ppa?
[19:37] <crimsun> penguin42: they'd appreciate feedback in their channel, too
[19:37] <RoAkSoAx> penguin42, Personal Package Archive (PPA)
[19:38] <penguin42> ah right - which is the mozillateams channel?
[19:38] <crimsun> penguin42: https://launchpad.net/~mozillateam/+archive
[19:38] <crimsun> ubuntu-mozillateam
[19:38] <penguin42> ah right, thanks I'll go and look in there - it would be great for that to get into Intrepid; the one in Hardy is very broken
[19:39] <slytherin> LucidFox: done
[19:40]  * ScottK suggests reading http://www.doxpara.com/DMK_BO2K8.ppt and then consider if they really want to install code from an unsigned repository (PPAs are unsigned).
[19:41] <laga> .ppt as in "power point"?
[19:41] <crimsun> yes, it's in powerpoint
[19:41] <ScottK> Yes.
[19:41] <penguin42> OOo can do that
[19:41] <slytherin> why not use S5. :-)
[19:41] <ScottK> I didn't put it up, just pointing to it.
[19:42] <crimsun> (in any case, I sbuilt/pbuilt the source package)
[19:42] <penguin42> well source packages are no safer
[19:43] <crimsun> penguin42: you have to trust the source package at some level.  Do a code audit over the entire base?
[19:43] <nxvl> did someone has information on how to relibtoolize a package?
[19:43] <crimsun> penguin42: fwiw, I /did/ inspect the source package.  I tend to do that (having been core-dev).
[19:43] <penguin42> crimsun: Well yes; but there's no reason to trust one more than you trust a binary package
[19:44] <crimsun> penguin42: that's the point.  You don't trust; you verify.
[19:44] <penguin42> nod; although there's been some very convincing stuff on minimal changes for barn-door sized security holes
[19:45] <ScottK> Also the .dsc's on PPAs do still have the uploader's signature.
[19:47] <ScottK> So there's a point to leverage trust in the source if you have a path to trust the uploader's key.
[19:49] <penguin42> (on a vaguely related note I tried to build an apparmour profile for nspluginwrapper - it's hard, especially since you really want one for each plugin, and in a way for each flash program
[19:50] <crimsun> flash itself has issues.  allowInsecureDomain()?  uhh
[19:51] <ScottK> Yeah.
[19:51] <ScottK> Someone looking for something really useful to do might do a survey of DNS related packages in Ubuntu to see if they've all been fixed.
[19:52] <nxvl> ScottK: they have been fixed, long ago :D
[19:52] <ScottK> nxvl: Are you sure?  I fixed one just a little over a week ago.
[19:53] <nxvl> ScottK: well, bind has :D
[19:53] <ScottK> Right.
[19:53] <ScottK> I'm not worried about the ones in Main.
[19:54] <ScottK> python-dns didn't even do TID randomization before I started beating on it in July.
[19:54] <nxvl> oh
[19:54] <nxvl> ok
[19:54] <nxvl> :D
[19:54] <nxvl> then yes
[19:54] <tacone> hello, I need a reliable way to test an intrepid packaged application with gui interface. what to use ? Is a properly binded chroot ok ? Are virtualmachines the only way (tm) ?
[19:55] <ScottK> 89 packages with DNS in the name in the archive.
[19:57] <nxvl> :(
[19:57] <nxvl> ScottK: we should add it to the server team roadmap
[19:57] <tacone> nxvl: what's up with UCSA ?
[19:57] <ScottK> nxvl: Good idea.
[19:57] <nxvl> tacone: working con config model
[19:58] <Brucevdk> Hey, I'm working on a Debian package. Currently a script just builds a directory and packages it using dpkg-deb --build). I'm trying to "adhere" more to Ubuntu packaging standards (I read the PackagingGuide, Debian Policy Manual etc.). The program is a Nautilus Python extension (which are installed into /usr/lib/extensions-2.0). Can anybody give me any pointers on the creation of a proper (small and beautiful) rules file for creating the package using
[19:58] <Brucevdk> debuild?
[19:58] <tacone> nxvl: I am working on a parser these days. I still feel the pain. painful pain. :-(
[19:59] <Brucevdk> Correction: /usr/lib/nautilus/extensions-2.0
[19:59] <nxvl> ScottK: btw, about the courier merge
[19:59] <ScottK> Yes?
[19:59] <nxvl> ScottK: i need to relibtoolize it
[19:59] <nxvl> ScottK: it's FTBFS for some reason with ubuntu's libtool
[20:00] <ScottK> OK.
[20:00] <ScottK> So the diff it going to be painful.
[20:01] <nxvl> yep
[20:01] <nxvl> i'm getting a really odd error
[20:01] <nxvl> ScottK: http://paste.ubuntu.com/35777/
[20:03] <ScottK> Dunno what to tell you.  Maybe someone else here has had enough fun with libtool in the past to help.
[20:04] <nxvl> ScottK: i'm on it
[20:04] <Flannel> Hey guys, I know this is somewhat offtopic, but in the deb file, how can Ifind out what options something (specifically the kernel) was compiled with?
[20:04] <nxvl> ScottK: i have found some information
[20:05] <alex-weej_> what does FTBFS stand for?
[20:05] <alex-weej_> Failed To Build, Fuck Sake?
[20:05] <ScottK> alex-weej_: From Source
[20:05] <crimsun> nxvl: I presume you've read http://tservice.net.ru/~s0mbre/blog//devel/networking/dns/2008_08_08, then.
[20:06] <alex-weej_> ah right
[20:06] <alex-weej_> somebody got the acronym wrong in a bug i posted, that was confusing hehe
[20:11] <ScottK> crimsun: Seems to me like just adding source port randomization is not going to be enough for long.
[20:14] <slytherin> Flannel: don't think it is possible
[20:14] <NCommander> alex-weej_, it stands from Failure to Build from Source
[20:15] <Flannel> slytherin: alright, thanks
[20:16] <tuxmaniac> nellery: are you working on bug 251281 ? If not I would like to give it a shot next week.
[20:48] <RainCT> REVU -> Your Packages -> Nice feeds icon on Firefox -> Subscribe to «Personal feed for $YOURNAME»
[20:48] <RainCT> :)
[20:54]  * RainCT wants testers ^^:P
[20:56] <RoAkSoAx> RainCT, seems to work :)
[21:00] <nhandler> What do you want testers for RainCT ?
[21:01] <RoAkSoAx> nhandler, i think for this: <RainCT> REVU -> Your Packages -> Nice feeds icon on Firefox -> Subscribe to «Personal feed for $YOURNAME»
[21:02] <nhandler> Thanks RoAkSoAx. RainCT, I was able to successfully subscribe to my personal REVU feed.
[21:04] <RainCT> great :)
[21:04] <RainCT> thanks RoAkSoAx, nhandler
[21:04] <nhandler> You're welcome RainCT.
[21:04] <RoAkSoAx> np =)
[21:04] <RainCT> Suggestions are welcome. (The «»).
[21:04] <RainCT>                 
[21:04] <RainCT>               
[21:04] <RainCT> argh
[21:05] <nhandler> Are you planning on adding rss feeds/email subscriptions on a per-package basis RainCT ?
[21:05] <RainCT> * Suggestions are welcome. (The «Lintian may be happy or not.» will change, of course).
[21:05] <RainCT> nhandler: yep (s/rss/atom)
[21:06] <nhandler> RainCT: What about subscribing to a package and getting email alerts when a comment is added or a new version is uploaded?
[21:07] <RainCT> nhandler: that's planned, but I don't like doing email stuff so it may still take a while (*whistle* unless NCommander does it) :P
[21:08] <NCommander> huh what?
[21:09] <nhandler> NCommander: Being able to get email updates when a comment/new upload occurs for a package on REVU
[21:09] <NCommander> oh
[21:29] <sistpoty> hi folks
[21:32] <sistpoty> hm... does anyone have a clue why my insert key doesn't set gvim into insert mode any longer?
[21:34] <crimsun> intrepid?
[21:34] <sistpoty> yep
[21:35] <crimsun> sorry, don't have the vm up
[21:35] <sistpoty> well, I will get used to "i" in some time I guess *g*
[21:36] <nhandler> sistpoty: What version of gvim are you using? My insert sets it into insert mode
[21:36] <sistpoty> nhandler: vim-gtk: 1:7.1.314-3ubuntu3
[21:37] <sistpoty> (but it might be anywhere I guess... maybe some kde<->gtk thingy... or in xorg?)
[21:41] <nhandler> I don't think it is an issue with the vim-gtk package. I have the same version installed. Like you said, it is probably an issue with something else like xorg
[21:44] <sistpoty> nhandler: or maybe my insert key is broken *g*
[21:44] <nhandler> Well, that isn't too dificult to test sistpoty
[21:46] <sebner> huhu sistpoty
[21:50] <sistpoty> hm... my insert key doesn't work in kde it seems, but it does work on vt... and switching back from vt to kde doesn't work *g*
[21:50] <sistpoty> but I have desktop-effects, which somehow should cheer me up about everything else being broken *g*
[21:52] <sistpoty> and... *drumroll* dpkg is localized... how interesting and amusing :)
[21:53] <sebner> sistpoty: strange things are happening *g*
[21:53] <sistpoty> heh
[21:56] <jpds> Anyone know where Flash has gone? http://download.macromedia.com/ is down.
[21:58] <sistpoty> jpds: have you tried adobe yet?
[21:58] <sebner> jpds: blame all the users who prayed for that :P
[21:58] <sebner> maybe someonw haXX0red them =)
[21:59] <jpds> sistpoty: Works from the download page. Someone was complaining about it in #ubuntu.
[21:59] <sistpoty> ah, k
[22:00] <sistpoty> jpds: is flashplugin-nonfree affected?
[22:00] <jpds> Checking.
[22:02] <jpds> sistpoty: No - it uses fpdownload.m.c.
[22:02] <sistpoty> ah, cool... thanks for checking jpds
[22:04] <tgm4883_laptop> If any motu has is bored and wants to revu something, I'd sure appreciate another look at http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube  I've fixed what superm1 commented on
[22:04]  * RainCT wonders if http://brainstorm.ubuntu.com/idea/12018/ should be left open or marked "Won't implement"
[22:06] <nhandler> RainCT: I would mark it as "Won't implement"
[22:07] <jpds> nhandler: Does Brainstorm use OpenID?
[22:08] <jpds> RainCT: Have you seen bug 149524?
[22:08] <nhandler> jpds: I know I had to make a separate account for it. I don't think they have implemented OpenID yet.
[22:09] <jpds> RainCT: Err, ignore that.
[22:09] <jpds> nhandler: OK.
[22:09]  * sistpoty recalls that someone referred to backports as the latest stable crack - a contradiction by itself *g*
[22:09] <YokoZar> RainCT: I'll mark it won't implement right now (by the way, it's relatively easy for MOTU to get brainstorm admin access if you poke the right person)
[22:11] <sistpoty> superm1: nvidia-settings uploaded... I'll leave it to you to fix what I got wrong *g*
[22:11] <RainCT> YokoZar: I already have developer & moderador status :)
[22:12] <RainCT> I'm just not sure if I'm supposed to close half of the ideas :P
[22:21]  * sistpoty takes a look at tgm4883_laptop's package
[22:22] <tgm4883_laptop> yay
[22:22] <tgm4883_laptop> thanks
[22:25] <sistpoty> tgm4883_laptop: being picky, you'll need to say that the debian packaging is Copyright (or copr.)... (C) is not enough... and there is comma after the year
[22:26] <sistpoty> tgm4883_laptop: get-orig-source doesn't get the newest upstream version but rather the current one as it seems
[22:27] <sistpoty> (and is quite useless, since no mangling is performed FWIW)
[22:27] <sistpoty> tgm4883_laptop: the long description could be a little bit more verbose
[22:27] <tgm4883_laptop> Do i need get-orig-source?
[22:28] <tgm4883_laptop> I was under the impression it was a requirement
[22:29] <sistpoty> tgm4883_laptop: in this case I guess a watch file would be more suitable... get-orig-source is mainly useful if you'll e.g. need to remove some non-free bits of upstreams release or do other mangling (e.g. convert a zip to a tar)
[22:29] <tgm4883_laptop> ok
[22:29] <tgm4883_laptop> is there documentation on how to do a watch file?
[22:30] <tacone> tgm4883_laptop: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[22:30] <sistpoty> tgm4883_laptop: or man uscan
[22:30] <tgm4883_laptop> tacone, thanks
[22:31] <tgm4883_laptop> sistpoty, " and there is comma after the year", thats correct right?  Or did you want me to remove it?
[22:31] <sistpoty> tgm4883_laptop: no, it shouldn't be there, but that's really just cosmetical ;)
[22:31] <tgm4883_laptop> ah ok
[22:32] <sistpoty> tgm4883_laptop: seems like you're missing a dependency on perl (strange, is perl no longer essential: yes in ubuntu?)
[22:32] <tgm4883_laptop> ah, yes i am, i'll add that
[22:32] <sistpoty> oh, perl is from perl-base, so forget the last comment tgm4883_laptop
[22:33] <tgm4883_laptop> ok
[22:33] <sistpoty> (which is still essential)
[22:34] <sistpoty> tgm4883_laptop: the question though is if you need some perl modules to be present and should put these in depends (have no clue about perl myself)?
[22:34] <tgm4883_laptop> I think i'm ok, as this depends on mythstream which looks to pull the modules I need.  I could list them here though too
[22:35] <sistpoty> tgm4883_laptop: that's not needed then
[22:36] <tgm4883_laptop> ok
[22:36] <sistpoty> tgm4883_laptop: however your .diff.gz contains basically all files from the orig.tar.gz as well... maybe clean doesn't remove the installed files or s.th.?
[22:36] <tgm4883_laptop> perhaps not
[22:38] <sistpoty> tgm4883_laptop: now let's come to grave issues: there's no GPL in the upstream tarball, and also no clue that any file is actually GPL
[22:38] <sistpoty> tgm4883_laptop: is it stated somewhere on the website at least?
[22:38] <tgm4883_laptop> yes
[22:38] <tgm4883_laptop> sec
[22:39] <tgm4883_laptop> at http://home.kabelfoon.nl/~moongies/streamtuned.html under the downloads section the first line says  "All code is protected by GNU/GPL" and links to the GPL
[22:42] <sistpoty> tgm4883_laptop: ok, that's good... but still you must change the source package and include a copy of the GPL in there (that's a requirement of the GPL itself)
[22:42] <sistpoty> tgm4883_laptop: maybe you could also point out where you found the initial gpl notice in debian/copyright, just to avoid confusion
[22:42] <tgm4883_laptop> oh ok, sorry about that.  I only knew the rule "don't change the source package"
[22:43] <tgm4883_laptop> ok, i'll add that too
[22:43] <sistpoty> tgm4883_laptop: well, that's one of the reasons to change the source package (and btw.: I know that rule by heart, I wrote the part for the packaging guide *g*)
[22:44] <sistpoty> brb, just out for a smoke
[22:51] <sistpoty> tgm4883_laptop: are the perl scripts source from somewhere or meant to be directly executed?
[22:51] <sistpoty> (because they miss the +x bit)
[22:51] <sistpoty> sourced even (or imported or whatever you do in perl *g*)
[22:52] <tgm4883_laptop> mythstream calls them
[22:52] <sistpoty> tgm4883_laptop: call as in shell call?
[22:52] <tgm4883_laptop> err, let me check real quick
[22:52] <tgm4883_laptop> I think I had to do something funky when I packages mythstream about that same thing
[22:59] <tgm4883_laptop> they are not +x on my box and i've installed it and it works
[23:00] <tgm4883_laptop> i'd have to dig deeper into mythstream though for 100% confirmation
[23:00] <tgm4883_laptop> sistpoty^
[23:01] <sistpoty> tgm4883_laptop: well, if it works, I don't think its much of a problem
[23:01] <tgm4883_laptop> ok
[23:02] <tgm4883_laptop> i'm adding this watch file now, after that I can just remove the get-orig-source from the rules right?
[23:05] <sistpoty> tgm4883_laptop: well, now you've got s.th. to mangle (i.e. to add the GPL to the source package)
[23:05]  * tgm4883_laptop smacks head
[23:06] <tgm4883_laptop> yep
[23:19] <sistpoty> tgm4883_laptop: just summed up the important issues on revu. please make sure to rename the .orig.tar.gz (and the upstream version in debian/changelog) so that it's clear that you needed to change the orig tarball
[23:20] <tgm4883_laptop> sistpoty, ok, so then will I have still have a .orig.tar.gz in there or just the new renamed one
[23:21] <sistpoty> tgm4883_laptop: a new, renamed one
[23:21] <tgm4883_laptop> ok.  Do you still want it to end in .orig.tar.gz?
[23:21] <sistpoty> tgm4883_laptop: of course ;)
[23:21] <tgm4883_laptop> ok, just making sure
[23:21] <tgm4883_laptop> thanks for the revu, i'll be back when it's all fixed up
[23:22] <sistpoty> tgm4883_laptop: now it's mythstream-parser-youtube_4.orig.tar.gz, and mythstream-parser-youtube_4ubuntu1.orig.tar.gz might be suitable probably
[23:22] <sistpoty> tgm4883_laptop: (don't forget that you'll then need to change the upstream version in debian/changelog as well)
[23:23] <sistpoty> which would then be 4ubuntu1-0ubuntu1
[23:23] <tgm4883_laptop> ah
[23:24] <tgm4883_laptop> ok, will do
[23:24] <sistpoty> (what you add to the upstream version is quite irrelevant, as long as it a) documents that you needed to fiddle with the orig.tar.gz and b) is consistent with debian/changelog)
[23:24] <tgm4883_laptop> ok, thanks
[23:25] <sistpoty> np
[23:28] <stryd_one> hi all
[23:30] <stryd_one> I'd like to get into packaging stuff up for ubuntu, I'm rather tech-savvy but new-ish to linux.... I've followed the links in the topic and a few google searches but I'm experiencing some information overload... Is there a "right" place to start for a newbie?
[23:32] <stryd_one> I was hoping for a step-by-step how to, just to get the first thing packaged up and get to know it a bit better (yaknow, build it, tear it to bits) but I seem to be finding a lot of conflicting information
[23:35] <Kopfgeldjaeger> https://wiki.ubuntu.com/PackagingGuide/GettingStarted
[23:35] <RainCT> sistpoty: why not use dfsg for the tarball rename? (4ubuntu1-0ubuntu1 looks really strange :P)
[23:35] <RainCT> hi stryd_one
[23:36] <stryd_one> thx Kopfgeldjaeger ... that's one of the 28 tabs I have open right now :)
[23:36] <stryd_one> hi RainCT
[23:36] <Kopfgeldjaeger> then you should probably close most of them and walk through the GettingsStarted guide ;)
[23:37] <stryd_one> exactly what i needed to hear, danke
[23:37] <sistpoty> RainCT: well, I guess dfsg is mainly used to state that some files needed to be removed due to not respecting a given license... and as I've seen debianXY in orig.tar.gz ubuntuXY seems like a logical choice
[23:37] <[cliff]> hi everyone
[23:37] <sistpoty> RainCT: however as I wrote, the exact version name is moot as long as it fulfills the goal ;)
[23:37] <[cliff]> is the packager of gshare here? i'm the dev, would like to talk
[23:38] <sistpoty> [cliff]: that would be slomo
[23:38] <sistpoty> (who doesn't seem to be around)
[23:38] <[cliff]> sistpoty, oh good to know it's still him. i'll drop him an email then. cheers
[23:38] <sistpoty> you're welcome ;)
[23:41] <sistpoty> slangasek: around and mind a query?
[23:43] <nhandler> Are the -kde4 suffixes on package names only temporary until kde4 is the default?
[23:43] <sistpoty> nhandler: no idea... maybe ask on #kubuntu-devel?
[23:44] <nhandler> Ok, I'll give that a try sistpoty
[23:48] <RainCT> sistpoty: you remembered me of the "can't stop clicking" Firefox commercial, but in your case it's a "can't stop answering" ;)
[23:49] <RainCT> well, I'm off.. Good night
[23:49] <sistpoty> heh
[23:49] <sistpoty> gn8 RainCT
[23:54] <foxbuntu> would someone be able to revu my package, it would be greatly appreciated: http://revu.ubuntuwire.com/details.py?package=mythbuntu-log-grabber