[00:18] <emgent> jmarsden|work: ping
[00:18] <emgent> jmarsden: ping again :)
[00:43] <jmarsden|work> emgent: I'm here...
[00:44] <emgent> jmarsden: query ?
[00:45] <jmarsden|work> You pinged at 16:18 ?
[00:45] <emgent> 1.18 am here..
[00:51] <miik> !packaging
[00:52] <miik> if i make a package, how long until i can get a ppa, and have it uploaded and compiled there?
[00:52] <miik> after i got a package upon the ppa, how long until i can have it in official repo?
[00:54] <handschuh> miik: the ppa is no requirement for getting a package into the ubuntu repositories
[00:54] <mrooney> miik: I am not remotely an expert, but I think you can do the PPA yourself
[00:54] <nhandler> !ppa | miik
[00:58] <handschuh> qq about get-orig-source: does it have to be version independent?
[00:59] <miik> !lpia
[00:59] <handschuh> well obivously is has to, but howto get the latest version
[00:59] <miik> lpia?
[01:00] <handschuh> miik: i think its intels atom platform
[01:00] <miik> oh
[01:00] <miik> thought atom was x86
[01:00] <StevenK> It is
[01:01] <StevenK> lpia stands for Low Power Intel Architecture
[01:01] <handschuh> StevenK: so ... its atom?
[01:02] <StevenK> handschuh: Yeah
[01:02] <handschuh> StevenK: ok, thx
[01:06] <miik> someone feed thato the bot
[01:07] <Pici> !botsnack
[01:13] <jmarsden|work> miik: See https://help.launchpad.net/Packaging/PPA for how to get a PPA
[01:14] <miik> ok
[01:14] <miik> yeah, i read that
[01:14] <miik> how long before i make a package, until it can get included in official repo?
[01:15] <nhandler> miik: Read https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. You need to upload it to REVU and get 2 MOTUs to advocate it.
[01:16] <miik> anyone can upload to REVU?
[01:16] <jmarsden|work> Package of a new piece of software ... takes a while unless you know MOTUs to persuade... ; package an existing piece of software, fixing a bug... not much time at all, usually, you put the debdiff into the LP bug and persuade a MOTU to look at it :-)
[01:16] <nhandler> Yes miik
[01:16] <miik> how long it take before 2 MOTU advocate it? after that, how long it take before it in repo?
[01:16] <nhandler> !revu | miik
[01:17] <miik> well, packaging is a pain in the ass, its so difficult, but im considering learning it, but dont want todo it, if its gonna be in vain, and im not gonna be able to get stuff into the repo anyways
[01:17] <jmarsden|work> miik: How long... seconds, if they are both in IRC and you persuade them to do it right away :-)  Or years, if noone cares about your software package :-|
[01:17] <miik> oh
[01:18] <jmarsden|work> miik: You might want to start by fixing bugs in existing packages rather than packaging new stuff.
[01:18] <miik> so if packaging isnt difficult enough, there is beaurocracy and stuff too
[01:18] <RAOF> miik: Packaging new programs is not necessarily the best way to start packaging.
[01:18] <miik> jmarsden_, fixing bugs is difficult, then you need to know programming. packing new package, i just download source, and package it
[01:18] <jmarsden|work> miik: Not so much bureaucracy, just too few MOTUs and a lot of stuff already in REVU
[01:18] <handschuh> could anyone review my package at: http://revu.ubuntuwire.com/details.py?package=libballoontip-java ?
[01:19] <jmarsden|work> miik: Fixing bugs can mean adding a desktop icon, or a translation to a .desktop file... not all bugs require code changes.
[01:20] <miik> oh okie
[01:20] <miik> can i just upload the .deskop file, or i need download package, add desktop file, package it, upload it?
[01:21] <nhandler> miik: You will submit your changes in the form of a debdiff. To generate the debdiff
[01:21] <jmarsden|work> Well, the first is a start, the second is better.
[01:21] <nhandler> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[01:22] <jmarsden|work> miik: https://launchpad.net/bugs/236140 is a bug where someone else uploaded a .desktop file, I did the packaging/debdiff, and the _RainCT checked it and got it uploaded to an offical repository.
[01:24] <miik> oh
[01:24] <miik> i need gpg and stuff to make a debdiff?
[01:25] <jmarsden|work> miik: TO sign it so we know it is really from you, yes.  You can make them without signing them, but that's not useful for official repo use.
[01:25] <miik> oh, ok
[01:25] <jmarsden|work> miik: man debdiff
[01:26] <miik> what point of sign them, if anyone can come with a nickname like "asd78asd8f7g" and come only once, then submit, then leave never to been again?
[01:29] <persia> Erm.  GPG is *not* a requirement for creating debdiffs.
[01:29] <RAOF> jmarsden|work: Um.  We don't require signed debdiffs
[01:29] <RAOF> In fact, we don't _accept_ signed debdiffs.  Or don't have the infrastructure for it, and I've never seen one.
[01:29] <persia> miik, When building a package for a debdiff, just use `debuild -S -us -uc` to avoid the GPG step.
[01:30] <persia> RAOF, Well, we can accept signed debdiffs.  It's just a text file.  Most of us will grumble about stripping the signature though.
[01:30] <jmarsden|work> Really? Ah, right, my bad.
[01:31]  * jmarsden|work should be working, not talking in here and trying to work at the same time... :-)
[01:42] <handschuh> under which circumstances is a get-orig-source rule needed?
[01:43] <persia> handschuh, When `uscan --force-download` doesn't automatically get the upstream source.
[01:44] <handschuh> persia: so what if uscan gets the upstream source but this file contains additional data (like binaries)
[01:45] <persia> handschuh, If there's source available for those binaries, you can just delete them in debian/rules clean.
[01:45] <persia> If there's no source available for those binaries, you need a get-orig-source to delete them when constructing the orig.tar.gz
[01:46] <handschuh> persia: ok the package contains also the source so I just modify the clean task
[01:46] <handschuh> persian: thanks
[01:47] <handschuh> sry, "perisa"
[01:47] <persia> handschuh, No problem.  Thanks for helping build the Ubuntu Java library set.  Someday we'll actually be able to use most Java apps cleanly :)
[01:48] <handschuh> persia: there is still a lot to do, but I will try to add as many packages as possible like jaxws
[01:49] <handschuh> persia: i am also working on cleaning up of old packages that have strange dependencies
[01:49] <handschuh> but first I have to learn how to make acceptable packages  ;-)
[01:52] <persia> handschuh, If you're looking for Java stuff, one of the targets for Jaunty is to get maven working, and there's a list of packages that need packaging, for which there's a few people who'd be happy to help review.
[01:54] <handschuh> persia: i will try to help as much as possible
[01:54]  * persia hunts down the spec
[01:55] <handschuh> persia: the problem is that java is to easy to bundle. so erverybody just adds the needed libraries to their package
[01:57] <persia> handschuh, Which is a security nightmare, as you might imagine.
[01:58] <directhex> hence the number of +dfsg packages some of us need to maintain
[01:58] <persia> handschuh, https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec , under bootstrapping.
[01:59] <lfaraone> Hey, would documentation that is under this license be considered debian-free: "Permission is granted to reproduction and modification, as long as proper attribution is given. Changes made in derivatives need not be under the same license. By use of the work or a derivitive, you agree to indemnify its author from any liability connected to said use. Finally, if any of the term(s) of this license is deemed invalid by a court, or if it is vio
[01:59] <handschuh> *bookmark*
[01:59] <persia> lfaraone, pastebin
[01:59] <lfaraone> persia: that's it, actually.
[02:00] <lfaraone> persia: but here you go: http://pastebin.ca/1255778
[02:00] <directhex> lfaraone, sounds pretty free to me
[02:00] <directhex> lfaraone, expat license, give or take
[02:00] <persia> lfaraone, It got cut off :)
[02:01] <handschuh> well then .. i have to take my 4 hours of sleep ...
[02:01] <lfaraone> persia: awww...
[02:01] <persia> lfaraone, Hrm.  Looks mostly ok, but I'm not sure about the bit that if the license isn't valid, it can't be distributed.  That makes me wonder if it is valid.
[02:02] <persia> I'd much prefer to see a clause saying that if any provision is invalid, the rest remain, rather than that if any provision is invalid, it cannot be distributed.
[02:02] <directhex> persia, that's called "copyright"
[02:02] <persia> Anyway, sleep well.  Maybe someone else disagrees with me.
[02:02] <persia> directhex, Right, which doesn't allow redistribution by default.
[02:02] <lfaraone> persia: The GPL has the same policy:
[02:03]  * persia reads the GPL again, sure that it's not the same
[02:03] <directhex> most licenses don't bother stating the obvious
[02:03] <directhex> the obvious being "in the absence of this license, you don't have this license"
[02:03] <persia> Um, that's not what this says.
[02:03] <directhex> i.e. copyright applies, i.e. no rights matey
[02:03] <lfaraone> persia: http://pastebin.ca/1255783
[02:04] <directhex> anyway, bedtime
[02:04] <persia> lfaraone, That says I have to follow the license even if the court says I can't, and that if I can't deal with that, I can't distribute it.
[02:05] <persia> That's different from saying if a court has a problem with the license, even if they say I can distribute it, I can't.
[02:05] <lfaraone> persia: ah, OK.
[02:06] <lfaraone> persia: (I'm the "author" of the above, CC_BY is too tl;dr for my tastes in some cases)
[02:07] <persia> lfaraone, You wrote that license?
[02:07] <persia> lfaraone, Have you considered using the ISC license?  Similar intent, but common, and without the snag.
[02:08] <lfaraone> persia: Yeah, I did. (Yes, I know it's bad to write your own, and that -motu INAL)
[02:08] <directhex> WTFPL!
[02:08] <directhex> it's dfsg-free!
[02:08] <persia> Yeah, the WTFPL is certainly dfsg-free, but it's a little in-your-face.
[02:09] <directhex> persia, if you don't like it, then clause 0 of the license permits relicensing :)
[02:09] <persia> Plus it doesn't have the attribution restriction.  ISC has the attribution restriction, which seems to be a better fit for what lfarone seeks.
[02:10] <lfaraone> persia: I'm seriously thinking of legally changing my name. _Every_ person on this earth seems to forget the second "a". :P
[02:10] <NCommander> I haven't forgotten the second a lfaraone !
[02:10]  * lfaraone gives NCommander a cookie. 
[02:10] <NCommander> yay!
[02:11] <directhex> how about "raven darktalon blood" as a new name?
[02:11] <lfaraone> persia: ISC looks cool. I'm wondering if I can condense all of the "SHOUTING FOR LEGAL AUTHORITY" to a "You disclaim the author from all liability related to use of this document/program"
[02:11] <lfaraone> directhex: Sure....
[02:11] <persia> lfaraaone: Sorry about that.  I'll try to make up for it in the future.
[02:12] <lfaraone> directhex: considereing prior to now I went as "firefoxman" :P
[02:12] <persia> lfaraone, Well, the SHOUTING FOR LEGAL AUTHORITY is about as brief as you can get without going for something like WTFPL.  I don't know of any widely supported licenses that are shorter and still provide the desired protection.
[02:13] <directhex> if you replace the SHOUTING part with LOOK AT MY LOVELY HAT, how many people do you think would notice?
[02:13] <directhex> anyway, bedtime
[02:14] <lfaraone> persia: http://en.wikipedia.org/wiki/Poetic_License just looks nice. (and rhymes!)
[02:16] <persia> lfaraone, I don't see any issues with that one, although I've not seen other software under it.  It's probably good, but I'd want a second opinion before pushing it.
[02:17] <lfaraone> persia: Ironically, the spesific use case I wrote this license for was for the reuse of another legal document I wrote (and _that_ was actually checked by a lawyer) for which I didn't want to be sued if the reuser was. But I'd also apply it to more relevent-to-ubuntu things.
[02:17] <lfaraone> *(the document being licensed was a legal document itself)
[02:17] <lfaraone> Oh, and for new packages, is debian or ubuntu prefered?
[02:18] <lfaraone> (should I go through the NPP process on Ubuntu or on Debian?)
[02:18] <directhex> debian!
[02:18] <persia> Debian is preferred.
[02:18] <directhex> don't enhance ubuntu, enhance free software. ubuntu gets the same benefit either way
[02:18] <directhex> the splash damage is desirable
[02:18] <persia> You can still use REVU to get it mostly right, but once it gets an ACK, declare your intention to publish in Debian, and we'll ignore it.
[02:19] <lifeless> ideally do both
[02:20] <lfaraone> persia: Ah, OK.
[02:20]  * directhex fails to write a limerick about picking licenses
[02:20] <directhex> anyway, BED
[02:21] <lfaraone> persia: Oh, and a wider debian politics issue: How hard is it to push patches upstream? (I'm technically a "co-maintainer" of a suite of packages I also steward in ubuntu, but the only person who has uploader rights in that group has been nonresponsive)
[02:23] <persia> lfaraone, If you're a comaintainer, you just need a DD to upload.  If none of the DD uploaders for the package are responsive, put a candidate on mentors, and ask for another DD to upload.  #debian-mentors on OFTC is a good place to ask.
[02:23] <persia> lifeless, both?  How do you mean?
[02:26] <lifeless> persia: become a debian package maintainer and an ubuntu MOTU
[02:26] <lfaraone> lifeless: heh, I'm working on it :P
[02:28] <persia> lifeless, Oh, yeah, that's a good combination for a person.  For a package, I don't see the point of Ubuntu source NEW if it's at all likely to be interesting in Debian.
[02:30] <lifeless> persia: oh, full ack; modulo freezes
[02:30] <lfaraone> persia: are the requirements for "participating" enough to qualify for universe-contributors defined anywhere?
[02:32] <persia> lfaraone, Not quantitatively.  Essentially, you need to demonstrate 1) understanding of Ubuntu ideals, 2) significant and sustained contribution, 3) integration with the development team.
[02:33] <persia> Usually involves being around and active for several months, with some expectation of continuing to be around and active, and having a few developers who are willing to speak on your behalf.
[02:35] <lfaraone> persia: ah... I guess I'm confused on what is "significant". Most of my work has been in one suite of packages (same one I am co-maintaining in debian), and I've only done work in Intrepid. (Even though I'm somehow 113 in the "msot uploads to intrepid" list)
[02:37] <persia> lfaraone, I'd recommend chatting with some of the developers with whom you've worked closely, and get their opinions on the matter.
[05:12] <fabrice_sp> Hi. In case Debian fixed a security issue with a standard new subrelease, do I ask for a sync following the SRU process, subscribing also Security team, or should I replicate the debian changes in an Ubuntu specific version?
[05:13] <fabrice_sp> in this case, Debian version change is from 0.6.0.2-2 to 0.6.0.2-3
[05:19] <wgrant> fabrice_sp: In general you should replicate the Debian changes for each Ubuntu release, following https://wiki.ubuntu.com/SecurityUpdateProcedures.
[05:20] <fabrice_sp> wgrant: I know, but in this case, the change is only in control file (to link with the correct library)
[05:21] <fabrice_sp> it's Debian Bug #504429
[05:21] <wgrant> Urgh.
[05:21] <wgrant> fabrice_sp: That doesn't make it special. Just replicate that change as with a normal security update.
[05:22] <fabrice_sp> wgrant: ok. Will follow the standard Security Update, then.
[05:23] <fabrice_sp> By the way, should I also suscribe Motu SRU at the same time that Security team?
[05:23] <wgrant> It's not a SRU.
[05:23] <wgrant> So no.
[05:25] <fabrice_sp> This is fixed in Jaunty, so if I want it in Intrepid, it's not a SRU? Sorry about that, but I don't really understand how Securtiy Updates and SRU unteracts
[05:25] <fabrice_sp> (even after looking at wiki pages)
[05:25] <wgrant> They are separate processes.
[05:25] <wgrant> SRUs are for non-security updates.
[05:25] <wgrant> While one called call a security update to a stable release a form of SRU, that's not how the terms are used.
[05:26] <wgrant> s/called/could/
[05:26] <fabrice_sp> ooook
[05:26] <fabrice_sp> I really thought a Security update eneded as a SRU
[05:26] <fabrice_sp> s/eneded/ended/
[05:27] <fabrice_sp> will follow the Security update process then. Thanks
[05:27] <wgrant> No, motu-sru is never involved.
[05:28] <NCommander> Involed w/ what?
[05:28] <fabrice_sp> so, can you please usubscribe motu-sru from bug #297475? It's another one that I have to update then
[05:29] <wgrant> NCommander: Security updates.
[05:29] <ScottK> fabrice_sp: As a practical matter the contents of -security are periodically copied into -updates, but that's a Soyuz thing that doesn't involve us at all.  Thay may be what you're thinking of.
[05:29] <NCommander> Stupid question, why aren't security updates just put in -updates?
[05:30] <wgrant> NCommander: So people can have -updates disabled.
[05:30] <NCommander> StevenK, ICMP echo
[05:30] <Hobbsee> NCommander: because some people just want security fixes
[05:30] <Hobbsee> without anything else
[05:30] <NCommander> Oh
[05:30] <fabrice_sp> ScottK: I really thought that all updates to a stable release should go to with a SRU
[05:30] <NCommander> Makes some sense
[05:30]  * NCommander would agree w/ fabrice_sp 
[05:30] <fabrice_sp> clear now :-)
[05:30] <ScottK> fabrice_sp: Ah.  Nope.  As
[05:30] <StevenK> NCommander: What's this thing you want me to look at?
[05:30] <ScottK> As you now see ...
[05:31] <NCommander> StevenK, its a no-changes SRU to a2ps so it can exist in updates (and then promoted w/i that pocket), and then a modification to xfprint4 to depend on a2ps
[05:31] <wgrant> Isn't there a bug with the command-line override tool and pocket overrides?
[05:31] <NCommander> wgrant, it worked fine on dogfood
[05:32] <NCommander> I heard that before, hence why I got bigjools to test it
[05:32] <NCommander> StevenK, https://bugs.edge.launchpad.net/ubuntu/+source/xfprint4/+bug/211335 - relevant bug
[05:32] <wgrant> Ah, bug #36022
[05:34] <StevenK> Looks like it hasn't rolled out yet
[05:34] <StevenK> NCommander: So, no, I can't.
[05:35] <NCommander> Strange that it would be fixed on Dogfood then
[05:35] <wgrant> NCommander: It could have been done directly on the DB.
[05:35] <StevenK> Which I can't do
[05:36] <StevenK> Based on the scary script error in that bug, I'm not playing.
[05:36] <wgrant> Exactly.
[05:36] <StevenK> Wait for 2.11
[05:36] <NCommander> Fair enough
[05:36] <wgrant> 2.11... 10 years? :P
[05:36] <NCommander> I would think it would be -6 years <g>
[05:36] <StevenK> Fine. The next Launchpad rollout
[05:36] <StevenK> NCommander: Sorry, but thems the brakes
[05:37] <NCommander> -EBAH :-P
[05:38]  * NCommander listens to an awesome song
[06:11] <ScottK> wgrant: I like the debian/changelog entry here: http://launchpad.net/ubuntu/jaunty/+source/mime-tools/5.427-1ubuntu1
[06:11] <ScottK> With that, I'm off to bed.
[06:11] <wgrant> ScottK: Haha.
[06:11] <wgrant> ScottK: I've filed 22 Launchpad bugs in the past 24 hours.
[06:12] <NCommander> ahahahah
[06:13] <dholbach> good morning
[06:13] <NCommander> morning dholbach
[06:13] <dholbach> hiya NCommander
[06:14]  * NCommander is eyeing over the current FTBFS lists
[06:14] <wgrant> Morning dholbach.
[06:14] <dholbach> hi wgrant!
[06:14] <wgrant> hppa made a bit of a come-back while fakeroot was broken on armel :(
[06:14] <NCommander> heh
[06:14] <NCommander> lpia is really quite broken :-/
[06:15] <wgrant> armel is still beating it relative to last night, though.
[06:15] <persia> In terms of throughput, or percentage of archive?
[06:16] <NCommander> if its the later, I worry about HPPA :-P
[06:16] <wgrant> Relative counts of pending builds. But I guess depwait isn't counted in those numbers on /+builds, so it's not right.
[06:17] <persia> Well, from the armel build failures, I'm not sure the depwait checker is doing well.
[06:17] <persia> Where's the best place to file a bug against http://qa.ubuntuwire.com/ftbfs/ ?  I'd like a link to the page with the "rebuild me" button.
[06:17] <wgrant> Indeed, it seems to only catch when deps are missing, not when the archive is borked.
[06:17] <wgrant> persia: That'd be build/+retry?
[06:18] <wgrant> Or retrybuild, one of them.
[06:18] <persia> Well, doesn't have to be direct.  I was thinking the build summary page rather than the build log.  It's two clicks to the build log, but if it's just that debhelper couldn't be installed, I can press the pretty button.
[06:18] <persia> NCommander, You look at these a lot.  What do you think of that change?
[06:19]  * NCommander usually uses the buildd command
[06:19] <wgrant> I think probably linking to the build page rather than log makes sense.
[06:19] <NCommander> no
[06:19] <NCommander> That would make things hardware because then its four or five clicks to the log
[06:19] <persia> No, two.
[06:19] <NCommander> Since retrying, while signifcant, is still only about half the build fixes
[06:19] <wgrant> Click on build page. Click on log link.
[06:19] <wgrant> s/page/page link/
[06:19] <NCommander> oh, I see
[06:20]  * persia starts retrying lpia universe alphabetically from ack where it's just build-dep stuff
[06:21] <wgrant> I wonder if LP needs to grow an 'archive breakage' state where that kind of build will go.
[06:21] <persia> Current click path is PTS -> Ubuntu -> version -> build page -> rebuild
[06:21] <wgrant> Although I guess sometimes it is real build-dep combination problems.
[06:21] <wgrant> persia: Version -> arch -> rebuild
[06:22] <persia> wgrant, No, from the version page there's a link on the top right to the build page.
[06:22] <persia> (unless that's going away early next week)
[06:23] <wgrant> persia: I can click on the version number of /ftbfs, and get https://edge.launchpad.net/ubuntu/jaunty/+source/linux-meta/2.6.27.7.11. I then click on the appropriate distroarchseries in the Builds portlet, which gets me to the build page.
[06:23] <wgrant> s/number of/number on/
[06:24] <persia> Oh.  That's not so bad then.  Ignore my request, as lots of packages need attention on multiple arches.
[06:24] <wgrant> buildd.py is useful.
[06:24] <persia> three -> two isn't enough benefit to pay one -> two for each build record.
[06:26] <NCommander> SO is it possible to get limited upload rights to main? (someone was talking about that on the list a few days ago, and with the current talk on emacs-snapshot)
[06:26] <persia> It is possible.  You need to apply to the tech board, and have a strong history of maintenance for the package in question.
[06:26] <wgrant> NCommander: Technically, yes. By policy, not entirely.
[06:27]  * NCommander would like to get upload rights to linux-ports, and linux-ports-meta
[06:27] <persia> I think we have three such people.  It's rare.
[06:27] <wgrant> And I think one of them recently became a core-dev.
[06:27] <persia> NCommander, You'll want to build some history first.
[06:27] <NCommander> persia, I'm the only one who is actively touching this package?
[06:28] <persia> wgrant, I thought we had three left, after that, but you may be right that it's only two (as only two names are springing to mind)
[06:28] <persia> NCommander, history.  It takes time.
[06:28] <wgrant> Of course, there's no UI for it...
[06:28] <NCommander> I see.
[06:29] <persia> Generally it only happens when someone has been working for long enough on main stuff to normally qualify for core-dev, except that they only expect to do a small cluster of packages, and they don't expect this to change over time.  It's a rare thing, and probably not best sought.
[06:30] <NCommander> Ah, I see
[06:31]  * NCommander schedules package retries in universe
[06:31] <persia> Start from the bottom of the list, so we don't collide :)
[06:31] <NCommander> I'm right now retrying the r-* packages
[06:31] <persia> Oh, that's fine.  I'm still on a
[06:31] <NCommander> I just jump around and retry obvious failures
[06:31] <wgrant> It might be nice to have a mass-giveback on !(armel|hppa) soon.
[06:32] <NCommander> It would be nice if LP retried failed builds once in awhile
[06:32] <persia> wgrant, Who has to schedule that?  Saves me poking things, since 6/8 packages I've examined so far would benefit.
[06:32] <wgrant> persia: Somebody with DB access, I believe. Probably infinity.
[06:33] <persia> Ah.  That's hard then.
[06:33]  * persia goes back to doing it manually
[06:33] <wgrant> Or, AIUI, he normally requests that somebody with DB access does them.
[06:33]  * NCommander pulls out the RAID utilities FTBFS
[06:33] <persia> So one of the build admins could do it?  (build admin != buildd admin)
[06:33] <NCommander> Why can't glibc believe in a stable API :-/
[06:34] <wgrant> persia: Unsure.
[06:34]  * persia goes to a likely more informed channel
[06:35] <persia> Bad time of day though.
[06:35] <wgrant> Indeed.
[06:36] <NCommander> bah
[06:36] <NCommander> /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
[06:36]  * NCommander sighs
[06:36] <NCommander> The sign of quality software: when including a header is enable to FTBFS
[06:43]  * wgrant tracks down LP bug #24 for this 24 hour period.
[06:44] <NCommander> lol
[06:45] <wgrant> I have 8 minutes.
[06:45] <NCommander> File a bug about a lack of UI for seeing people w/ limited main upload rights
[06:47] <persia> That bug already exists.  It needs to be a new one.
[06:48] <persia> wgrant, No navigation from and architecture on https://launchpad.net/+builds to the list of pending builds?
[06:48]  * persia doesn't know if that already exists
[06:48] <NCommander> I know one
[06:49] <NCommander> Private team membership causes the recent team membership list to break
[06:49] <wgrant> persia: Unfortunately that's dependent on there being such a list of pending builds.
[06:49] <NCommander> https://edge.launchpad.net/~cody-somerville
[06:49] <wgrant> And that has been deferred indefinitely.
[06:49] <NCommander> Cody's page is a prime example
[06:50] <wgrant> NCommander: Hmmm. Interesting. Maybe that's only because his last five are private.
[06:50] <wgrant> Because other people who I know have private memberships have older teams listed.
[06:51]  * wgrant files it anyway, leaving LP people to deal with it. Nyahah.
[06:51] <persia> wgrant, Ooh.  Annoying.  lpnet/ubuntu/+builds works, lpnet/ubuntu/$(release)/$(arch)/+builds works, but lpnet/ubutu/$(arch)/+builds doesn't work.  Never noticed that before.
[06:51] <wgrant> persia: That's because distroarch doesn't exist. Only distroarchseries.
[06:51] <wgrant> persia: And Ubuntu isn't the only distro on LP.
[06:51] <wgrant> Well, at the moment it is.
[06:51] <persia> Which is why it's been deferred indefinitely?
[06:51] <NCommander> wgrant, I just thought of it for your 24 bugs in 24 hours
[06:52] <NCommander> wgrant, I also have another bug
[06:52] <wgrant> persia: I don't know.
[06:53] <wgrant> Right, #24 filed, but only 23 are open :(
[06:53] <NCommander> wgrant, want another one?
[06:53] <persia> Which one got killed?
[06:53] <wgrant> NCommander: Sure.
[06:54] <wgrant> persia: Bug #297882
[06:54] <wgrant> Apparently that's present on all bug action pages.
[06:54] <wgrant> Except for the main page, which is where most actions take place.
[06:54]  * wgrant rolls eyes.
[06:54] <NCommander> wgrant, here's a hint
[06:54] <NCommander> https://edge.launchpad.net/~kamion/+related-software
[06:54] <NCommander> Look closely at the PPA section
[06:54] <wgrant> so really the bug is the other way around.
[06:55] <wgrant> NCommander: Nothing wrong with that, AFAICS. It was later copied to primary, so became public.
[06:55] <persia> Also, edit description/tags has the main page UI.  Seems odd to have two different portlets for the same purpose.
[06:55] <wgrant> NCommander: The only possible bug there is that the P3A is linkified.
[06:56]  * wgrant files two bugs about that page.
[06:56] <NCommander> wgrant, it was on that page before it was copied to primary
[06:57] <persia> wgrant, That's too many.  You have to wait an hour :p
[06:57] <wgrant> NCommander: Really? One would need to check with a security person when they next upload, I guess.
[06:58] <NCommander> wgrant, that's difficult because they can't say what packages they uploaded due to the embargo ...
[06:59] <wgrant> NCommander: Unembargoed stuff is still uploaded to the P3A.
[06:59] <NCommander> ah
[07:05]  * RAOF wonders exactly _how_ broken the nouveau branch supporting DRI2 & GL_EXT_texture_from_pixmap is...
[07:05] <wgrant> Poor sejong...
[07:05] <wgrant> RAOF: You probably don't want to try...
[07:05] <wgrant> Crack is bad.
[07:05] <RAOF> Pffft!
[07:05] <RAOF> Poppycock!
[07:06] <RAOF> Sure, it needs private branches of mesa, drm, and nouveau.  What could /possibly/ go wrong? :)
[07:06] <RAOF> Oh, and a newer x11-proto-dri2 than Intrepid has, apparently.
[07:07] <wgrant> persia: Well, I didn't realise that mass-givebacks were so remarkably easy to achieve.
[07:08] <persia> wgrant, The trick is apparently to ask at midnight on a holiday :)
[07:08] <persia> Anyone have any good suggestions for http://launchpadlibrarian.net/19636265/buildlog_ubuntu-jaunty-lpia.mplayer-libpostproc_1%3A1.0-pre1.1_FAILEDTOBUILD.txt.gz ?
[07:09] <persia> RAOF, What's your current confidence level about Jaunty?
[07:09] <NCommander> persia, gcc-3 is still in the archive for QEMU, I recommend using it (you might need to fudge the configure scripts to find it however)
[07:09] <RAOF> persia: With respect to?
[07:09] <persia> RAOF, nouveau
[07:09] <wgrant> persia: Tell upstream to die.
[07:10] <persia> NCommander, Do you really think that's the right answer?
[07:10] <persia> wgrant, I'm suggestive, but not that suggestive.
[07:10] <RAOF> persia: My guess is nouveau will stay in my PPA, and we won't sync it from experimental.
[07:10] <NCommander> persia, my main issue is that there are a lot of ways gcc 4 changed things
[07:10] <wgrant> Isn't our archive nice and happy now: http://qa.ubuntuwire.com/ftbfs/
[07:10] <NCommander> It's pathetic it still doesn't support gcc 4
[07:10] <persia> RAOF, OK.  I just like to check each cycle :)  Maybe next time.
[07:11] <NCommander> But gcc 3 -> 4 could introduce a lot of suitable regressions
[07:11] <RAOF> persia: Failing that, I could _possibly_ dkms-ify nouveau's drm build, and we could include it.
[07:11] <persia> wgrant, Well, sparc still needs help, and there's apparently no data for ia64, and hppa is still special, but very much so :)
[07:11] <RAOF> My expectation is that there won't be a nouveau release during the Jaunty cycle.
[07:12] <persia> I'd say the lack of a nouveau release during the beginning of the cycle was the key bit.  The dkmsification sounds like seriously cut crack.
[07:12] <RAOF> Right.  dkms-ifying it would be possible, but it's a work-around for it not being ready.
[07:13] <persia> Ready is better.  Introducing buggy nouveau doesn't really fit with "just works" :(
[07:13] <RAOF> That said, Jaunty should be one step closer to nouveau; it'll have a libdrm that should work with nouveau, so we'd _just_ need the kernel modules.
[07:13] <RAOF> For the moment, of course, until they require new libdrm API ;)
[07:14] <NCommander> RAOF, I could see about getting nouveau added to the ubuntu folder in the kernel if dkms isn't an option
[07:14] <persia> If libdrm is compatible, why can't we include the kernel modules?
[07:14] <persia> Or is it just that it's still trunk, which is all sorts of dangerous?
[07:15] <RAOF> Well, libdrm 2.4.1 should support nouveau, so we _could_ include the kernel modules in l-u-m or something, actually.
[07:15] <RAOF> There's no guarantee that nouveau won't require API breaking changes to drm, but that's settled down a bit.  I guess until the memory-manager's ready.
[07:16] <persia> So which is the missing bit?
[07:16] <RAOF> The kernel drm.ko + nouveau.ko.  I'll just check that Jaunty actually has a sufficiently-new libdrm, though.
[07:16]  * persia isn't sure about nouveau-by-default by nouveau-from-repo is awfully tempting
[07:16] <persia> s/by/but/
[07:17] <RAOF> Yeah, it is a bit.
[07:17] <superm1> RAOF, the source package produces these kernel modules and libdrm does it not?  why not do it like a normal package just with a dkms binary package for these kernel modules then?
[07:17] <superm1> you would be at least guaranteed that the kernel modules that were in the archive at the same time as the libdrm matched API wise
[07:18] <RAOF> Jaunty doesn't yet have libdrm 2.4.1, but it presumably will at some point.
[07:18] <RAOF> superm1: That would be possible, yes.
[07:18] <persia> superm1, Do you think that's better than trying to get them in-tree?
[07:19] <RAOF> persia: It'd be tempting to go nouveau-by-default on certain hardware; nv4x & nv3x spring to mind.
[07:19] <RAOF> I suspect that upstream might not be terribly supportive of that, though ;)
[07:19] <superm1> well it sounds like everything is in flux right now.  having an unstable driver in tree that could potentially break kernel builds doesn't seem appealing to me.  the API breakage part too...
[07:19] <persia> nouveau is bettern than nv for nv4x?
[07:20] <RAOF> persia: In every way, yes.
[07:20] <RAOF> persia: Supports xrandr1.2, has best EXA acceleration of any driver.
[07:20]  * persia has an nv4x sitting around somewhere, and gets tempted, but still doesn't like PPAs
[07:20] <RAOF> Oh, and high-quality Xv :)
[07:20] <superm1> RAOF, so libdrm 2.4.1 has everything needed for nouveau?
[07:20] <persia> How does it compare to nvidia for nv4x?
[07:21] <RAOF> persia: Faster at 2d, pretty much.  And dual-head sucks less.
[07:21] <persia> Does 3D work yet?
[07:21] <RAOF> Nouveau is faster at 2d, I mean
[07:21] <RAOF> Hah!  Not for any value of "work" that you'd want to rely on.
[07:21] <persia> heh.
[07:21] <StevenK> It may draw on the screen, but it won't look like anything?
[07:22] <RAOF> For example, 3D will currently inexorably exhaust VRAM until it's all full, and then fall over.
[07:22]  * persia remembers watching renderings of glxgears that defied explanation
[07:22] <StevenK> RAOF: Whee
[07:22] <RAOF> StevenK: While it's working, it'll do OpenArena pretty well.  On my card.
[07:22] <RAOF> Takes a while for it to exhaust 512Mb of VRAM :)
[07:23] <RAOF> superm1: Yes, libdrm 2.4.1 has everything needed for nouveau at the moment.
[07:25] <superm1> RAOF, well then i'd say if you believe the API for nouveau kernel module - >libdrm is going to stay stable enough shoot to have it in default kernel, but have a dkmsified source package on the archive ready to flip on as a backup solution
[07:26] <RAOF> A dkms-ified libdrm package is probably a better bet.
[07:26] <RAOF> We'll likely want the ability to pull in snapshots, if nothing else.
[07:31] <RAOF> Bah!  Well, that's the current adventure over, failing rebuilding Xserver with dri2 support.
[07:45] <NCommander> persia, any objections if I work on mplayer-libpostproc?
[07:46] <siretart> NCommander: what's that? mplayer-libpostproc?
[07:47] <NCommander> ask persia, he gave me the build failure log
[07:52] <siretart> NCommander: if it really is what I think it is, I'd recommend removing it from the archive
[07:52] <NCommander> ok, what is it?
[07:52] <siretart> I asked first :)
[07:54] <siretart> bah, it seems to be one of the libraries ffmpeg actually provides and mplayer copies, packaged in a new source package
[07:54] <siretart> please get it removed from the archive
[07:54] <siretart> it never built in ubuntu anyways
[07:55] <NCommander> siretart, wooo, cruft removal!
[07:56] <StevenK> File a bug
[07:56] <siretart> yes please
[09:08] <savvas> is it advisable to use circular dependencies?
[09:08] <savvas> example: smc and smc-data
[09:09] <mok0> savvas: No!
[09:09] <savvas> so i should file a bug :)
[09:09] <mok0> savvas: Yes, I'd think so
[09:10] <savvas> mok0: would you suggest using a "Recommends: smc" or "Suggests: smc" for smc-data?
[09:10] <mok0> savvas: I don't think you need anything
[09:10] <mok0> savvas: you could use "Enhances:" if you insist
[09:11] <savvas> but smc won't play without it :P
[09:11] <savvas> hm.. ok
[09:11] <mok0> savvas: smc should require smc-data
[09:11] <mok0> savvas: depends, rather
[09:11] <savvas> I see, reasonable enough
[09:12] <savvas> thanks!
[09:12] <mok0> savvas: It means if you install smc, it will also install smc-data
[09:18] <joaopinto> savvas, there is already a package for smc, what's wrong with the current dependencies :) ?
[09:19] <joaopinto> oh, it depends on smc :\
[09:20] <mok0> joaopinto: apparently there's a circular dependency
[09:20] <joaopinto> there is
[09:20] <joaopinto> I thought he was repackaging :P
[09:20] <mok0> ah
[09:21] <savvas> joaopinto: I am, but in launchpad PPA :p
[09:21] <savvas> https://edge.launchpad.net/~medigeek/+archive
[09:22] <joaopinto> savvas, packaging the latest version ?
[09:22] <savvas> yes
[09:22] <savvas> 1.6
[09:22] <joaopinto> I need to borrow it :P
[09:22] <savvas> be my guest :)
[09:23] <savvas> I used the source from apt-get source and updated the patch to match the new configure file
[09:23] <savvas> (and a new orig.tar.gz)
[09:24] <savvas> I don't know if this the correct way, but oh well :p
[09:27] <joaopinto> that's how usually do it ;)
[09:27] <savvas> joaopinto: are you the maintainer for smc/smc-data ?
[09:27] <savvas> https://bugs.launchpad.net/ubuntu/+source/smc/+bug/297978
[09:27] <savvas> just filed the dependency bug :)
[09:28] <joaopinto> saivann, nope
[10:34] <gnomefreak> is there a Jaunty changes mailing list yet, im not sure maybe i overlooked it but i couldnt find it
[10:35] <persia> There is, and an RSS feed.
[10:35] <gnomefreak> on lists.ubuntu.com?
[10:35] <persia> (really just a mail -> RSS gateway, but you may find it as convenient)
[10:36] <persia> Shhttps://lists.ubuntu.com/mailman/listinfo/Jaunty-changes
[10:36] <persia> s/`Sh//
[10:36] <gnomefreak> ah i found it thanksd
[10:37] <tonyyarusso> Any of you guys have an inkling how many years of experience in an IT field usually equates to median pay for that field?  (medians are always given on salary statistics, but I don't know how to interpret them.)
[10:40] <verwilst> tonyyarusso: you have salary stats?
[10:40] <persia> tonyyarusso, I'd suggest the 5-10 year experience bracket would probably hit median for IT, although there's *huge* variation in such a wide field.  Depending on the position, that might require more experience (IT management at a multinational) or less (non-lead Developer for large shop).
[10:42] <hyperair> does anybody know whether ubuntu has a package for wxscintilla?
[10:43] <hyperair> and if there is, what is it?
[10:44] <persia> apt-cache search returns a bunch of results for scintilla, but I don't see wx bindings offhand.
[10:45] <mok0> azeem: ping
[10:48] <tonyyarusso> verwilst: There are lots of stats from both the government and other web sites, yeah.
[10:48] <tonyyarusso> persia: That sounds fairly reasonable.  It would be as the sysadmin/it director for a very small business that does web development.
[10:48] <verwilst> tonyyarusso: where? :) /me curious
[10:48] <tonyyarusso> verwilst: The job or the stats?
[10:48] <hyperair> okay, so i've got a package for codelite ready. do i need to file a packaging request before uploading to revu?
[10:48] <persia> The problem with all of them is that they are too vague.  For a given position, there's wide variation in salary between industries (for the same work).
[10:50] <persia> tonyyarusso, You'd also need to specify location before you have a meaningful number, and unfortunately, unless you're moving here, I won't be able to give you a sensible number (I haven't done placement in the states for enough years to have no idea of appropriate salaries).
[10:50] <persia> hyperair, No, but you'll want to close a bug in the initial changelog, and you can't get the bug number until you file it.
[10:50] <hyperair> oh
[10:50] <hyperair> okay
[10:51] <tonyyarusso> persia: location is currently Minneapolis/St. Paul, MN, but the job is such that I could move anywhere and let the position follow me.
[10:53] <persia> tonyyarusso, I don't have enough insight there.  Talk to a local recruiter (not as a prospect, but in a bar after-hours).
[11:04] <handschuh> is anybody free to review http://revu.ubuntuwire.com/details.py?package=libballoontip-java ?
[11:13] <mok0> handschuh: Packaging looks good
[11:15] <handschuh> mok0:  :-)
[11:15] <mok0> handschuh: re: the comments of onskarshinde, did you add the gpl.txt file yourself?
[11:16] <handschuh> mok0: there is just a lgpl file from upstream
[11:17] <mok0> handschuh: but he wrote " The upstream archive does not contain any license information"
[11:17] <mok0> Oh, lgpl
[11:17] <handschuh> mok0: I talkte to upstram and they kindly changed it
[11:17] <mok0> handschuh: Great!
[11:18] <mok0> handschuh: I'll see if it builds for me
[11:20] <Hobbsee> ScottK: oh, that'd be mine.  ;)
[11:21] <mok0> handschuh: you still have the build.xml file in diff.gz
[11:21] <Hobbsee> i...think
[11:21] <handschuh> mok0: because I changed it to fit using cdbs
[11:22] <mok0> handschuh: ok. It is easier to maintain the package if you make it a patch
[11:22] <handschuh> mok0: ok but first I hav to learn something about the patch system  :-)
[11:23] <Hobbsee> oh.  that package.  it's sort of mine :)
[11:23] <mok0> handschuh: Great! :-) It's not hard to do
[11:23] <mok0> !quilt
[11:23] <mok0> :-(
[11:23] <handschuh> mok0: but besides this and the missing get-orig-source rule ... is there anything left?
[11:24] <mok0> handschuh: no, afaics it looks good
[11:24] <mok0> handschuh: I am not a java programmer so unfortunately I can't test to see if the package works from here
[11:25] <handschuh> mok0: :-D  great ... once I have this package working, I will add a lot more java packages
[11:25] <handschuh> mok0: was the balloontip.jar created?
[11:25] <mok0> handschuh: hang on
[11:26] <mok0> handschuh: building now
[11:27] <mok0> handschuh: I think you can use the simplepatch system of cdbs
[11:28] <mok0> handschuh: you just need to include a file in rules, and put the patch in debian/patches
[11:28] <handschuh> mok0: ok I will try to do this ... cdbs is really easy once I understood it
[11:28] <mok0> handschuh: yes it's pretty cool
[11:29] <mok0> handschuh: package didn't build... I need to update my builder
[11:29] <handschuh> mok0: is this due to a bad description in the package?
[11:30] <mok0> handschuh: I think it's my builder being out-of-date
[11:31] <mok0> handschuh: here we go again...
[11:33] <azeem> mok0: pong
[11:34] <mok0> azeem: hi, just wanted to ask for your email address but I found it :-)
[11:34] <azeem> ah :)
[11:34] <mok0> azeem: I got in touch with the qutemol guys
[11:35] <azeem> oh nice
[11:35] <handschuh> mok0: has the diff file to be in unified mode?
[11:35] <mok0> handschuh: yes
[11:35] <azeem> ah, saw your mail now (just arrived in the office)
[11:36] <mok0> handschuh: and must include the patch from the directory above the package directory
[11:37] <azeem> mok0: do you know cmake?  It might make sense to propose that to the qutemol devs as a unified build system, as it seems to nicely support all the platforms they care about
[11:37] <mok0> azeem: eerh, no I don't know cmake, in fact I do prefer gnu make
[11:38] <azeem> I do as well
[11:38] <azeem> though it's a PITA to build/support autotools projects on Windows AFAIK
[11:38] <azeem> anyway, gotta go for lunch; I'll be back later
[11:38] <mok0> azeem: in fact I don't give a damn about the windows platform ;-)
[11:39] <mok0> azeem: for all I care, people can run linux if they want to run the program :-P
[11:40] <mok0> handschuh: still building here, the archive is s-l-o-w today
[11:40] <handschuh> mok0: ok, thanks
[11:42] <handschuh> mok0: ok I got the packsystem working ... really easy  :-)
[11:42] <mok0> handschuh: good work!
[11:42] <mok0> handschuh: ideally, we'd like the only content of diff.gz to be debian/*
[11:43] <mok0> handschuh: hmm, failed again, but it's not your package
[11:44] <handschuh> mok0: can you pastebin the error?
[11:44] <mok0> handschuh: http://pastebin.com/f29fcff59
[11:45] <handschuh> mok0: a ok i know
[11:45] <handschuh> mok0: the problem is that the sun jre will not install on fakeroot because the package only installs if cou manually accept the sun-license
[11:46] <mok0> handschuh: ah! How are java packages built by the buildd, then?
[11:46] <handschuh> mok0: its a trick
[11:48] <mok0> handschuh: ... yes?
[11:48] <handschuh> mok0: just make it depending on: openjdk-6-jdk | java5-sdk |
[11:48] <handschuh> mok0: instead of only java5-sdk
[11:49] <handschuh> mok0: so if no jdk is installed, the openjdk will be installed (it does not require any manual input)
[11:49] <mok0> handschuh: ok, I'll try to change it...
[11:49] <handschuh> mok0: I will upload the fix (including the patch right now)
[11:50] <mok0> handschuh: great
[11:51] <mok0> handschuh: OK, so the build hosts have java5-sdk installed already?
[11:52] <mok0> handschuh: going to lunch, will give package a final look when I return
[11:52] <handschuh> mok0: no they don't
[11:52] <handschuh> mok0: ok, have fun
[11:52] <mok0> handschuh: see you later
[11:54] <binarymutant> I don't know if I'm phrasing this right but how do I change the ubuntu version name(in my case it's 0ubuntu1) without messing up gpg signing and dput?
[11:54] <persia> MOTU Meeting in 5 minutes in #ubuntu-meeting
[11:55] <persia> binarymutant, You change it in the changelog *before* you build the package.  Anything else is likely to cause issues.
[11:55] <binarymutant> persia, thanks :)
[12:05] <handschuh> does having a get-orig-source rule make a watchfile not to be manditory?
[12:06] <persia> handschuh, Depends on your get-orig-source rule.  I find them easier to write with a watch file.
[12:08] <handschuh> persia: w/o a watchfile I cant use uscan, right? so having both is the best. thanks
[12:08] <persia> Right :)
[12:13] <azeem> mok0: right, but currently the Linux Makefiles are second class citizens
[12:18] <hyperair> how do i reupload a package to revu? i realized after i uploaded that i forgot to run it through lintian
[12:19] <lidb> anyone can help review my packages: iptux, fqterm, ibus and llk-linux, thanks
[12:19] <persia> hyperair, rm the .upload file, and dput again.
[12:19] <hyperair> persia: i used dput -f, doesn't that do the same thing?
[12:19] <persia> lidb, Providing URLs typically gets better response, but there's currently a MOTU Meeting, so few are likely to review.
[12:20] <persia> hyperair, Well, yes.
[12:20] <hyperair> persia: revu doesn't seem to show any changes
[12:20] <hyperair> aah nevermind it's updated
[12:20] <hyperair> so. can someone review it? =p http://revu.ubuntuwire.com/details.py?package=codelite
[12:20] <lidb> persia, today is not a review day?
[12:21] <lidb> please help review: http://revu.ubuntuwire.com/details.py?package=iptux
[12:21] <persia> lidb, Today is REVU day.  This hour is MOTU Meeting.
[12:22] <lidb> persia, thanks
[12:22] <hyperair> persia: there's a REVU day?
[12:22] <hyperair> persia: when does this hour last until?
[12:23] <persia> hyperair, Until the MOTU Meeting is complete.  Probably around 13:00 UTC, unless it runs over.
[12:23] <hyperair> persia: alright thanks
[13:00] <lidaobing> now it's 13:00 UTC, motu meeting finished?
[13:01] <sebner> lidaobing: not yet
[13:19] <lidaobing> please help review my packages: http://revu.ubuntuwire.com/details.py?package=iptux http://revu.ubuntuwire.com/details.py?package=fqterm  http://revu.ubuntuwire.com/details.py?package=ibus http://revu.ubuntuwire.com/details.py?package=llk-linux
[13:19] <lidaobing> thanks
[13:20] <mok0> MOTU meeting finished...
[13:27] <mok0> lidaobing: iptux, debian/rules, get rid of comments at top of fiel
[13:27] <mok0> fiel
[13:27] <mok0> file
[13:28]  * sebner is wondering if the new copyright format is already open for use?
[13:28] <mok0> sebner: has it been finalized?
[13:29] <persia> sebner, You can use it, but you might have to fix it later.
[13:29] <sebner> mok0: well, dunno, so I'm asking ;) I just saw some comments on REVU to use the new format
[13:29] <mok0> sebner: I've been advocating it for some time now
[13:29] <sebner> persia: So it's bad to recomment it on REVU
[13:29] <lidaobing> mok0, ok, i'll fix it
[13:30] <persia> sebner, I believe current policy is that we don't express a preference.
[13:30] <sebner> kay
[13:30] <mok0> lidaobing: man page is v-e-r-y minimal. Can't you make it more useful?
[13:30] <persia> It just has to really be the right old format, or really be the right new format.
[13:30] <sebner> the questions is how new the new format is ^^ e.g when it will be stable and finalized
[13:31] <lidaobing> mok0, no more, there are no options for this program
[13:31] <mok0> lidaobing: and in the manpage, you have to escape "-" (minus) like this: \-
[13:31] <lidaobing> mok0, Ok
[13:31] <lidaobing> mok0, OK
[13:31] <mok0> lidaobing: I understand, but the description could be better
[13:31] <mok0> lidaobing: is doesn't tell you what protocol the IP client uses
[13:32] <lidaobing> mok0, I think no more minus need escape in manpage
[13:32] <mok0> lidaobing: or recognizes on the intranet
[13:32] <mok0> lidaobing: yes
[13:32] <mok0> " - send message" ... -> "\- send message" etc
[13:33] <mok0> lidaobing: Don't argue
[13:33] <lidaobing> mok0, I don't think it need quote in manpage
[13:33] <mok0> lidaobing: Don't argue
[13:33] <lidaobing> mok0, why don't argue
[13:33] <mok0> Well, if you want your package reviewed, don't waste my time
[13:33] <lidaobing> mok0, only some minus symbol need quote
[13:34] <mok0> lidaobing: I can see 3 minus that need to be escaped.
[13:34] <mok0> Jeez
[13:34] <mok0> lidaobing: And I want a better man page.
[13:35] <lidaobing> mok0, ok I will quote it, but I think it's the wrong choice
[13:35] <mok0> lidaobing: it's not
[13:35] <lidaobing> mok0, check groff(7)
[13:36] <lidaobing> it should be a hyphen in UTF8 and should be a minus in C
[13:36] <lidaobing> mok0, it's correct
[13:37] <lidaobing> mok0, only the command option need quote in manpage
[13:39] <handschuh> mok0: thanks for you comment!
[13:39] <handschuh> mok0: and advocated   :-)
[13:43] <mok0> lidaobing: you are using hyphens as bullets in a list and that is wrong
[13:43] <lidaobing> mok0, OK, I will quote it, I will upload the modified version soon.
[13:43] <mok0> lidaobing: wait there's more
[13:44] <lidaobing> mok0, OK
[13:45] <mok0> lidaobing: iptux has an empty ChangeLog file
[13:46] <lidaobing> mok0, I remember I have drop it, it should not exist in .deb file
[13:46] <mok0> lidaobing: it gets installed by dh_installchangelogs
[13:46] <lidaobing> mok0, OK, I will fix this problem
[13:46] <azeem> 0-byte ChangeLog are quite common, maybe dh_installchangelogs should detect this and skip them
[13:47] <mok0> azeem: yeah
[13:47] <mok0> azeem: ... and next version may have a true changelog
[13:47] <azeem> #  * dh_installchangelogs: When searching for changelog in v7 mode, skip
[13:47] <azeem> #    empty files. Closes: #490937
[13:49] <binarymutant> if anyone has the time to review my package, http://revu.ubuntuwire.com/details.py?package=charm, I would be very appreciative. Thanks :)
[13:49] <mok0> lidaobing: small problem with the desktop entry
[13:50] <lidaobing> mok0, I can confirm changelog does not exist in .deb file if build under jaunty
[13:50] <mok0> lidaobing: ok, fine
[13:50] <hyperair> anyone got time to review a package? http://revu.ubuntuwire.com/details.py?package=codelite
[13:51] <lidaobing> mok0, you mean Encoding? I will patch this
[13:51] <mok0> lidaobing: very good, thanks
[13:53] <Laibsch> Hi
[13:53] <Laibsch> Is it generally true that "1:3.0.0-2ubuntu1~rolf1 <= 1:3.0.0-2ubuntu1"?
[13:53] <mok0> lidaobing: don't you have a full name for the author of this program?
[13:53] <wgrant> Laibsch: That's the point of ~
[13:53] <Laibsch> My PPA just rejected an upload for this reason
[13:53] <mok0> Laibsch: yes
[13:53] <Laibsch> Oh
[13:54] <Laibsch> I see, thanks
[13:54] <lidaobing> mok0, wait, I need check
[13:54] <persia> Laibsch, dpkg --compare-versions might be a useful command for you.
[13:56] <lidaobing> mok0, no, I know he/she is a Chinese, and he never use his full name when email or talk with me
[13:56] <mok0> lidaobing: I would be good if you can find his full name, the copyright is a legal statement
[13:57] <lidaobing> mok0, do you think it really required, maybe he don't want to leak his realname
[13:57] <lidaobing> mok0, many one prefer this in China
[13:58] <mok0> lidaobing: I see. Well ask him if he wants to give his full name.
[13:58] <lidaobing> mok0, I will try
[13:58] <mok0> lidaobing: thank you
[13:59] <mok0> lidaobing: have you checked that iptux works? It segfaults for me
[14:00] <mok0> lidaobing: (on Intrepid)
[14:00] <lidaobing> it works for me
[14:00] <lidaobing> mok0, it works for me
[14:00] <mok0> lidaobing: are you on i386
[14:00] <lidaobing> mok0, yes
[14:01] <lidaobing> mok0, OK, I will test it on amd64 later
[14:01] <mok0> lidaobing: ok, I am on amd64, perhaps that is a problem
[14:01] <lidaobing> mok0, I only check the compile under amd64 use ppa
[14:01] <mok0> lidaobing: with the exception of the things we have discussed, packaging looks good
[14:01] <lidaobing> mok0, Thanks.
[14:02] <lidaobing> mok0, I will re-upload after resolve the crash problem under amd64
[14:02] <mok0> lidaobing: it compiles without problems, but running it gives a segmentation error
[14:02] <mok0> lidaobing: thanks
[14:02] <lidaobing> mok0, thanks you.
[14:02] <mok0> lidaobing: good work
[14:03] <lidaobing> mok0, thanks
[14:06] <mok0> hyperair, I will look at codelite now
[14:06] <hyperair> mok0: thanks
[14:08] <mok0> hyperair: in debian/rules, you probably want Priority: optional
[14:08] <hyperair> control or rules?
[14:08] <mok0> hyperair: control, sorry
[14:08] <hyperair> alright, i'll make the change
[14:09] <hyperair> hmm seems i forgot to set the Section
[14:09] <hyperair> i'll set it to universe/devel. is that okay?
[14:11] <mok0> hyperair: just devel
[14:11] <hyperair> okay
[14:11] <mok0> hyperair: in debian/rules, why do you need to remove DEBIAN/control ??
[14:12] <hyperair> mok0: ah that. you see, codelite actually dumps into the root of the source folder, fakeroot/DEBIAN/control when running configure
[14:13] <mok0> hyperair: ok
[14:13] <hyperair> mok0: i think it's part of codelite's deb building script
[14:14] <mok0> hyperair: codelite builds its own .debs during building??
[14:14] <hyperair> mok0: no. there's a make_deb.sh for that
[14:14] <hyperair> mok0: however, ./configure dumps a file into fakeroot/DEBIAN/control
[14:15] <mok0> hyperair: Hm. Strange
[14:15] <hyperair> mok0: make_deb.sh only copies stuff that's just been built into fakeroot/ and then runs dpkg -b or something of that sort
[14:15] <hyperair> dpkg -b fakeroot ${PKG_NAME}
[14:16] <mok0> hyperair: ... but you override all that stuff, right?
[14:16] <hyperair> mok0: i just don't call make_deb.sh. it doesn't affect the build process because nothing hits debian/
[14:16] <mok0> hyperair: that's fine
[14:17] <hyperair> mok0: i just put it in clean:: because running diff and diffstat showed that file
[14:17] <mok0> hyperair: still downloading the tarball, it's pretty big
[14:17] <mok0> hyperair: excellent
[14:18] <hyperair> mok0: thanks. there are actually a few things i'm unsure about... ./configure isn't your regular autotools configure. it seems to be some custom built one from codelite. it seems to ship certain libraries with it.. in sdk/
[14:18] <mok0> hyperair: debian/changelog, distribution is jaunty
[14:18] <hyperair> ok
[14:19] <mok0> hyperair: oh, yes, I can see that configure is not a gnu one
[14:20] <lidaobing> mok0, I can't reproduce the crash under amd64, can you send me the core file or the full backtrace, my email is lidaobing@gmail.com, thanks.
[14:21] <mok0> lidaobing: I didn't get a core file, I will need to recompile with debug enabled
[14:21] <lidaobing> mok0, thanks
[14:22] <mok0> hyperair: are you in contact with upstream?
[14:22] <hyperair> mok0: unfortunately not.
[14:23] <hyperair> mok0: however, there is a #codelite on freenode
[14:23] <mok0> hyperair: a lot of the source files do not have a license statement at the top
[14:23] <savvas> public domain! :p
[14:23] <hyperair> mok0: i thought it was pretty much safe to assume it's all GPL. the site says so, as does LICENSE
[14:24] <slytherin> LucidFox: ping
[14:24] <handschuh> slytherin: also ping
[14:24] <slytherin> handschuh: go on
[14:24] <mok0> hyperair: I know, but if there is no license clause we do not have the right to distribute that file
[14:25] <hyperair> i see
[14:25] <handschuh> slytherin: its again about http://revu.ubuntuwire.com/details.py?package=libballoontip-java
[14:25] <hyperair> mok0: in that case should i bug the author?
[14:25] <LucidFox> slytherin> yes?
[14:26] <mok0> hyperair: It is a lot of files, I count > 100
[14:26] <handschuh> slytherin: about the get-orig-source rule
[14:26] <slytherin> handschuh: I will probably review it from home. Is that fine?
[14:26] <slytherin> LucidFox: pm?
[14:26] <handschuh> slytherin: perfectly fine!
[14:26] <mok0> hyperair: that's around 25%
[14:27] <LucidFox> uh... why PM? Is it something secret?
[14:27] <handschuh> slytherin: I just need one more advocate  :-)
[14:27] <Toobaz> Hello. Somebody here once told me that bugs providing patches waiting for sponsorhip don't get much attention, and it's better to come in chat... so here I am: https://bugs.launchpad.net/ubuntu/+source/drgeo/+bug/257797
[14:27] <slytherin> LucidFox: yes, but if you are busy, I will ping later.
[14:27] <Toobaz> it is a crucial bug for the package
[14:28] <hyperair> mok0: author says he'll fix it =)
[14:28] <mok0> hyperair: cool!
[14:28] <slytherin> handschuh: just a quick note. in your build.xml diff, mkdir looks out of place. I suppose it has to be inside some target.
[14:28] <hyperair> mok0: he's eranif by the way.
[14:29] <mok0> hyperair: oh, here on freenode?
[14:29] <hyperair> yes
[14:29] <hyperair> mok0: he's on #codelite
[14:29] <LucidFox> I'm not busy, just tired
[14:29] <handschuh> slytherin: ok I will check this. feel free to ping me, if you have the time
[14:30] <slytherin> handschuh: another note, I feel the last change you are making (target 'install') should be handled in your packaging, not by patching build.xml.
[14:30] <slytherin> handschuh: I will quickly put these notes there.
[14:30] <handschuh> slytherin: Thanks!
[14:31] <binarymutant> if anyone has the time to review my package, http://revu.ubuntuwire.com/details.py?package=charm, I would be very appreciative. Thanks :)
[14:31] <mok0> hyperair: otherwise, packaging looks good. I will try to build it now
[14:32] <hyperair> mok0: thanks
[14:32] <mok0> hyperair: do you actually need autotools as a build-depends?
[14:35] <mok0> hyperair: codelite is not much use without gcc. Perhaps the package should depend on it
[14:35] <hyperair> depend or recomend?
[14:36] <hyperair> codelite still functions as an editor, just no compilation capability
[14:36] <mok0> hyperair: but it has debugging capability?
[14:36] <hyperair> that's gdb
[14:36] <mok0> Perhaps suggests: then
[14:36] <hyperair> okay
[14:37] <hyperair> so should i use gcc or shoudl i use build-essential
[14:38] <hyperair> hmm while i'm at it, i should put subversion as well
[14:38] <persia> Generally try to keep your depends and recommends as small as is sensible.
[14:38] <persia> build-essential is fairly large, and codelite probably doesn't use all of it.
[14:39] <hyperair> oh
[14:39] <hyperair> okay
[14:40] <mok0> Am I the only one REVUing at the moment? The list seems not to get any shorter :-(
[14:41] <lidaobing> mok0, maybe, :-(
[14:41] <mok0> hyperair: the build takes a while... I will submit what we talked about as comments to REVU and move along...
[14:42] <hyperair> mok0: thanks =)
[14:44] <mok0> lidaobing: I will take a look at fqterm now
[14:45] <lidaobing> mok0, thanks
[14:45] <Toobaz> I see nobody seems to be interested in sponsoring the patch... do you suggest to ask somewhere else or just wait?
[14:45]  * iulian is going to review some packages in a moment.
[14:46] <mok0> lidaobing: tell me, what is special about fqterm compared to other terminal emulators? In other words, why do we want it in Ubuntu?
[14:46] <persia> Toobaz, You've attached it to a bug and subscribed the sponsors queue?
[14:46] <Toobaz> persia: exactly
[14:46] <lidaobing> mok0, it is one of the most widely used linux BBS client in China
[14:46] <persia> Toobaz, In that case, waiting is probably the right step.
[14:46] <lidaobing> mok0, another is qterm
[14:46] <mok0> lidaobing: I see. Is it unicode?
[14:47] <Toobaz> persia: by "sponsors queue" you mean "Ubuntu Sponsors for universe", right?
[14:47] <persia> Toobaz, If the bug is against a package in universe, yes.
[14:47] <lidaobing> mok0, it designed for BBS, chinese BBS only in GBK and BIG5 encoding
[14:47] <Toobaz> persia: yes, Ok, I'll wait, thanks
[14:48] <mok0> lidaobing: You said: "one of the most widely used linux BBS client in China". Put this information in the description in debian/control, and "it designed for BBS, chinese BBS only in GBK and BIG5 encoding" as well
[14:48] <lidaobing> mok0, OK
[14:49] <mok0> lidaobing: we want as much useful information in the description as possible, so people can decide if this is software for them.
[14:49] <lidaobing> mok0, OK, thanks
[14:50] <mok0> lidaobing: Is Ubuntu getting popular in China?
[14:51] <lidaobing> mok0, at least it is the most popular distribution in China
[14:51] <nxvl> mok0: they are about to consider microsoft as the biggest cracker in china
[14:51] <lidaobing> mok0, but linux only have less than 1% share
[14:52] <nxvl> mok0: and to sue them
[14:52] <mok0> lidaobing: Oh, I heard Microsoft only sold 500 vista licenses in China :-P
[14:52] <lidaobing> mok0, much more
[14:53] <lidaobing> mok0, the goverment and big company much as a valid operation system
[14:53] <lidaobing> mok0, s/much/must
[14:53] <mok0> lidaobing: Ah, yes, that's part of the trade agreement with the US
[14:53] <lidaobing> mok0, yes
[14:54] <lidaobing> mok0, as I know, the operation system (Windows XP) is legal.
[14:54] <lidaobing> mok0, and I still use Linux
[14:54] <mok0> lidaobing: Imagine how much money the Chinese government could save by using Linux...
[14:54] <lidaobing> mok0,  as I know, the operation system (Windows XP) in my company is legal
[14:54] <lidaobing> mok0, Hmm, they don't consider this question. they have much money
[14:55] <lidaobing> mok0, consider all education system use Windows
[14:55] <mok0> lidaobing: yes future Windows users :-(
[14:55] <lidaobing> mok0, and all boys and girls in school only know Windows
[14:56] <lidaobing> mok0, I am push the widely used Linux software in China to Ubuntu and Debian
[14:56] <eMerzh> hi all....someone has some time for review my first package waiting in revu? (http://revu.ubuntuwire.com/details.py?package=sqliteman)
[14:56] <mok0> lidaobing: great
[14:58] <mok0> lidaobing: what I said above, also goes for the manpage
[14:58] <binarymutant> if anyone has the time to give any tips on my package, http://revu.ubuntuwire.com/details.py?package=charm, I would be very appreciative. Thanks :)
[14:58] <lidaobing> mok0, OK
[14:59] <Laibsch> Is there a kind soul to push https://bugs.launchpad.net/ubuntu/+source/mailgraph/+bug/221010 into -proposed?  The SRU fix is obvious and I think 0 regression potential.
[15:00] <slytherin> handschuh: does the library actually use any Java 1.5 specific APIs?
[15:00] <handschuh> slytherin: I think so ... wait
[15:01] <mok0> lidaobing: there are several authors listed in res/credits that may need to be mentioned in debian/copyright
[15:01] <handschuh> slytherin: yes it does ... enumerations are beeing used
[15:01] <lidaobing> mok0, OK
[15:03] <slytherin> handschuh: another round of comments.
[15:04] <slytherin> I am a bit free to review any java related packages. Are there any more?
[15:04] <handschuh> slytherin: thanks
[15:05] <handschuh> slytherin: i have one type more: http://revu.ubuntuwire.com/details.py?package=libauvitoapiaxis-java  ... there is no comment about cdbs needed (I will fix that for sure) but instead about the "wsdl-only"-package
[15:06] <handschuh> slytherin: why did you write 3.) ?
[15:07] <slytherin> handschuh: A convention. And you have used JAVA_HOME as /usr/lib/jvm/default-java in rules file, so ...
[15:07] <lidaobing> mok0, I need switch back to ubuntu-i386, (my amd64 system is under Debian), if any progress in iptux crash under amd64, send me a email, lidaobing@gmail.com
[15:07] <mok0> lidaobing: will do
[15:08] <handschuh> slytherin: I do need at least java 5, and the openjdk-6-jdk rule is needed because it won't build either (because it tries to install the sun jdk by default which fails because of the lack of user input)
[15:08] <handschuh> slytherin: so the dependency cant be changed
[15:08] <slytherin> handschuh: Wrong, default-jdk in jaunty is openjdk. So build dependency on default-jdk is just fine.
[15:09] <handschuh> slytherin: a thats great!
[15:09] <slytherin> handschuh: please note that arch: all packages are build only on i386, where openjdk is the defaultjdk.
[15:10] <handschuh> slytherin: do you have some time left on helping me with 2.)?
[15:11] <slytherin> handschuh: yes.
[15:11] <handschuh> slytherin: thanks. so I just add a "install" rule?
[15:11] <handschuh> slytherin: doesn't that override the existing one from cdbs?
[15:11] <slytherin> handschuh: Let me take a look at how it can be optimized.
[15:14] <slytherin> handschuh: two ways. 1. write an 'install::' target with simply one line - install balloontip.jar debian/libballoontip-java/usr/share/java/. 2. Create a debian/install file with just one line - ﻿balloontip.jar debian/libballoontip-java/usr/share/java/.
[15:14] <slytherin> ﻿I would prefer 1, since you are creating only one binary package.
[15:14] <handschuh> slytherin: will do!
[15:15] <slytherin> handschuh: In case my instructions are not clear enough or I have made some mistake please dig up cdbs documentation on ubuntu wiki. I can't try changes right now to make sure they are working.
[15:16] <handschuh> slytherin: ok, I will upload the new version very soon
[15:16] <Laibsch> could it be that there is no way to delete superseded packages in a PPA, yet, they still count towards the quota?
[15:17] <slytherin> handschuh: I may not be available then. Please feel free ask others for comments.
[15:17] <mok0> Laibsch: superseded packages are removed automatically=
[15:18] <Laibsch> https://launchpad.net/~r0lf/+archive?field.name_filter=&field.status_filter=superseded has lots of entries and I can still download from most if not all of them
[15:25] <mok0> Laibsch: oh yes. Can't you remove them manually?
[15:25] <Laibsch> no
[15:25] <Laibsch> I don't see how
[15:26] <Laibsch> https://launchpad.net/~r0lf/+archive/+delete-packages?field.name_filter=&field.status_filter=superseded is empty
[15:26] <mok0> Laibsch: Just above the table of packages, to the right, there is a link called "Delete packages"
[15:27] <Laibsch> which gives me that link
[15:28] <mok0> Huh? I get the same list of packages, but with a checkbox at each package
[15:28] <mok0> Laibsch: I am running edge version
[15:29] <lidaobing> mok0, fqterm have a interface in English, but it default startup in a Chinese Interface, this is a known bug in http://code.google.com/p/fqterm/issues/detail?id=196
[15:29] <mok0> Laibsch: there, I just was able to delete a superseded package from my PPA
[15:30] <mok0> lidaobing: Can you deal with -- and possibly fix -- that bug?
[15:31] <mok0> lidaobing: the man page is not of much help here ;-)
[15:31] <lidaobing> mok0, I will try,  but it's a little complex, relative to many code, they still want to a Chinese Interface it user have a Chinese locale
[15:31] <lidaobing> mok0, I will try to improve manpage
[15:32] <mok0> lidaobing: Yes document how you can activate the english interface
[15:32] <lidaobing> mok0, OK
[15:32] <mok0> lidaobing: I know it is boring to most people to write man pages, but it is really important. The better the man page, the more users you will have
[15:32] <Laibsch> mok0: nope, sorry.  Whenever I choose superseeded packages from the delete page, the list returns empty.
[15:32] <Laibsch> Even on edge
[15:33] <Laibsch> I'll open a support ticket
[15:33] <mok0> Laibsch: what do you mean "Choose superseded packages" ?
[15:33] <lidaobing> mok0, maybe I should choose sgml or docbook to write manpage, it's too weird to write manpage in groff
[15:33] <mok0> lidaobing: what ever you prefer :-)
[15:34] <lidaobing> mok0, :-)
[15:34] <Laibsch> mok0: By default you see the published packages.  Then you choose "superseded" status.  that is when the list returns empty for me
[15:34] <Laibsch> I can show superseded packages
[15:34] <Laibsch> But from that page as well, when I click on "delete packages", the list returns empty
[15:34] <mok0> Ah yes, you do the search?
[15:35] <mok0> No difference for me, when I press "Delete packages" I get the little checkboxes
[15:35] <mok0> ... To the far left of the screen
[15:37] <mok0> Laibsch: works perfectly for me
[15:38] <mok0> Laibsch: I get a little color-changing box saying that the files have been deleted
[15:39] <mok0> Anyone else up for a REVU?
[15:42] <Laibsch> mok0: Unfortunately, I don't
[15:42] <maix> how is that possible? : http://paste.pocoo.org/show/91150/
[15:43] <Laibsch> mok0: Are you requesting one or offering one?
[15:43] <Laibsch> REVU, that is
[15:43] <mok0> Laibsch: I'm offering a review
[15:43] <maix> i certainly didn't install xulrunner from somewhere else
[15:43] <quadrispro> RainCT: hi! did you see my last comment on installation-report-generator? -> http://revu.ubuntuwire.com/details.py?package=installation-report-generator
[15:43] <mok0> maix: could be pulled in by firefox, perhaps?
[15:43] <Laibsch> mok0: Do you also have upload privs?
[15:44] <maix> how? if it is not in the repos?
[15:44] <mok0> Laibsch: I'm MOTU
[15:44] <Laibsch> great
[15:44] <Laibsch> (15:59:22) Laibsch: Is there a kind soul to push https://bugs.launchpad.net/ubuntu/+source/mailgraph/+bug/221010 into -proposed?  The SRU fix is obvious and I think 0 regression potential.
[15:45] <Laibsch> mok0: Oh, can you also do SRU?
[15:45]  * mok0 looks
[15:45] <mok0> Laibsch: no
[15:45] <Laibsch> ping SRU people
[15:46] <mok0> Laibsch: I don't think dapper and gutsy are supported anymore
[15:46] <DktrKranz> Laibsch: pong
[15:46] <Laibsch> DktrKranz: You can do an SRU?
[15:46] <DktrKranz> yes
[15:46] <Laibsch> Can you push 221010?
[15:46] <mok0> Laibsch: he's the Man
[15:46] <Laibsch> Great!
[15:46] <DktrKranz> (any MOTUs could)
[15:46] <Laibsch> My first
[15:46] <Laibsch> mok0: said he was MOTU but could not ;-)
[15:46] <mok0> DktrKranz: it needs a SRU
[15:47] <mok0> I am just wondering if dapper and gutsy are still supported
[15:48] <ScottK> mok0: They are
[15:48] <handschuh> If someone has time, I would be glad if http://revu.ubuntuwire.com/details.py?package=libballoontip-java could be reviewed once again
[15:48] <DktrKranz> well, any MOTU could upload to -proposed
[15:48] <DktrKranz> and yes, they're supported
[15:48] <DktrKranz> they just need brave souls to prepare updates ;)
[15:49] <ScottK> mok0: Speaking of which, did you upload the havp fix you did the other day?
[15:49] <ScottK> It was the lazy unmount one.
[15:49] <DktrKranz> Laibsch: I haven't my GPG key here, so I need to postpone it this evening
[15:49] <mok0> ScottK: No i didn't
[15:49] <ScottK> mok0: Would you?
[15:49] <mok0> ScottK: sure
[15:50] <ScottK> Thanks.
[15:50] <mok0> ScottK: on it right away
[15:50] <Laibsch> DktrKranz: Ok, thanks for taking a look.  Maybe mok0 will feel brave enough if you give your blessings.  I think there is 0 regression potential and this is an upload to -proposed.
[15:51] <ScottK> DktrKranz: Would you please mark a motu-sru ack in Bug #296499
[15:51] <mok0> ScottK: It seems it didn't help the guy...
[15:51] <ScottK> mok0: I doubt he knows enough to apply the patch.
[15:52] <mok0> ScottK: he needs to edit his maintainer scripts in /var/lib/dpkg/info
[15:53] <ScottK> mok0: I expect he'll need very specific instructions on exactly what to do.
[15:53] <mok0> ScottK: I'll write a comment for him
[15:53] <ScottK> Great.
[15:54] <DktrKranz> I'm not sure what -l flag does
[15:54]  * DktrKranz checks
[15:57] <DktrKranz> Laibsch: seems trivial to fix. Is it worth the pain of an upload?
[15:57] <DktrKranz> I mean, does it produce a crash, or program behaves incorrectly?
[15:58] <Laibsch> Of course the program doesn't crash
[15:58] <Laibsch> But basically, I already did the patch.  I don't know how much more pain is left
[15:58] <Laibsch> The broken link and image certainly are ugly
[15:59] <Laibsch> how much longer is dapper supported?
[15:59] <Laibsch> about 2 years?
[16:00] <DktrKranz> 3 years on desktop platforms
[16:00] <DktrKranz> so, dapper and gutsy will reach EOL together
[16:01] <slytherin> mok0: I hope you had actually built libballoontip-java when you advocated it. :-)
[16:02] <mok0> slytherin: I did
[16:02] <mok0> slytherin: any problems
[16:03] <mok0> ?
[16:03] <slytherin> mok0: No. I am in office so I can not verify if it builds. THat is why I asked.
[16:04] <mok0> slytherin: let me try the newest version
[16:05] <Laibsch> DktrKranz: The package in question is a typical server app
[16:07] <Laibsch> I am looking at bug 227547.  There is a patch already applied to the Intrepid package which looks like http://rafb.net/p/M1npMJ97.html.  Didn't the patcher forget to comment the if-clause as well?  I am in the middle to prepare a debdiff for the hardy version.
[16:10] <slytherin> handschuh: looks pretty good now. But I can not comment if it builds and produces proper .deb file. I guess mok0 will do that. By the way, you still don't have egt-orig-source target.
[16:10] <mok0> slytherin: Package builds fine in my jaunty sbuilder. I cannot test the software though
[16:11] <mok0> handschuh: aahh, the get-orig-source target was a precondition to my advocacy
[16:12] <slytherin> mok0: Have you tried installing it? or simply open with archive manager and make sure it is not empty. Thanks in advance.
[16:12] <handschuh> slytherin: yes, the one I created is still very ugly
[16:13] <handschuh> mok0: ok I will include it right now! (will take a "few" minutes)
[16:13] <DktrKranz> Laibsch: it's fine, you already provided the patch, so you just need a sponsor. /me lacks browser support to ACK the bug, though
[16:13] <mok0> slytherin: I don't have a jaunty sytem. Look here: http://pastebin.com/f7dd9c4e7
[16:14] <mok0> slytherin, handschuh, not so familiar with java, but looks ok to me
[16:14] <slytherin> mok0: Why do you need jaunty system? It is arch all package and dependencies are minimal, it should install fine on intrepid. Anyway it looks fine.
[16:14] <handschuh> mok0: it is ok as far as i can tell
[16:14] <DktrKranz> ScottK: regarding your bug, I have not clear what -l does, I need to better understand it
[16:15] <ScottK> DktrKranz: mok0 ^^
[16:15]  * DktrKranz saw a different approach of that bug
[16:15] <mok0> DktrKranz: it allows umount not to hang
[16:15] <handschuh> slytherin: is there a smart way of creating it? Or do I have to write every step (like explained in the wiki)
[16:16] <ScottK> mok0: In any case it should be fixed in Jaunty first, so I'd suggest go ahead with that if you haven't.
[16:16] <mok0> ScottK: sure
[16:16] <slytherin> handschuh: I don't know any smart way to create it. Take a look at some existing packages.
[16:16] <mok0> ScottK: I was sidetracked for a moment
[16:16] <slytherin> handschuh: If I was at home, I would have helped you create it.
[16:17] <ScottK> No problem.
[16:17] <slytherin> handschuh: On a side note, make sure you check both source and binary package with lintian.
[16:18] <mok0> ScottK: ... I will upload the intrepid version to intrepid-proposed afterwards
[16:18] <ScottK> Sounds good.
[16:18] <handschuh> slytherin: ok, thanks
[16:33] <mok0> ScottK: what's customary, to create a new changelog entry for intrepid-proposed at the top, or simply change the top line of the latest entry?
[16:34] <handschuh> how is that get-orig-source rule: http://paste.ubuntu.com/71919/  ?
[16:39] <mok0> handschuh: line 9, you delete ballontip twice
[16:41] <handschuh> mok0: ok thanks (i just wanted to make sure it is really gone)!
[16:41] <leonel> ScottK: do you want a 1 diff for all the  patches ??
[16:41] <mok0> handschuh: it's good to be thorough... :-)
[16:42] <mok0> handschuh: if you run these lines in a Makefile, remember that each line is spawned as a separate process
[16:42] <mok0> handschuh: you may want to put a "\" at the end of each line except the last
[16:42] <handschuh> mok0: ah, thats what "\" means. thanks, I will add it
[16:43] <mok0> handschuh: yes it's a continuation character, but there must not be spaces after it
[16:44] <Laibsch> I'm not yet very familiar with debdiff.  What is that stuff after patch2 in http://launchpadlibrarian.net/19648945/wordpress_intrepid.debdiff ?
[16:46] <handschuh> mok0: so http://paste.ubuntu.com/71923/ is ok now?
[16:47] <mok0> handschuh: I think you should wrap that very long line 8 to fit ~80 chars
[16:48] <mok0> handschuh: but why are you deleting gpl.txt and README.txt?
[16:48] <mok0> and MANIFEST.MF?
[16:50] <handschuh> mok0: the library is lgpl so gpl is not needed, i think; README and MANIFEST are not needed either
[16:51] <mok0> handschuh: Unless they disturb things, I'd say just leave those files
[16:51] <handschuh> mok0: allright
[16:51] <mok0> handschuh: are there non-distributable things in there?
[16:52] <handschuh> mok0: just the binaries and the eclipse-project file as well as the documentation
[16:52] <mok0> ah, ok
[16:54] <mok0> If the only reason for repacking a tar ball is the zip archive, I've seen that people just put the zip archive in the .orig.tar.gz and unpack it in rules
[16:54] <mok0> It's dumb that dpkg can't deal with zip and bzip2 formats
[16:56] <Laibsch> somebody feel motivated to look at bug 227547?
[16:56] <handschuh> mok0: ok so how about now: http://paste.ubuntu.com/71936/
[16:56] <Laibsch> debdiffs provided
[16:57] <mok0> handschuh: looks good... does it work? I suggest you put in a dh_testdir in the rule, to make sure it is being executed in the right place
[16:58] <mok0> handschuh: (dh_testdir can be on a line by itself in the rule)
[16:59] <handschuh> mok0: works perfectly
[16:59] <mok0> handschuh: good work!
[16:59] <mok0> handschuh: long day, huh?
[16:59] <handschuh> mok0: thanks ... I am uploading it right now
[17:00] <handschuh> mok0: indeed but it is worth it!
[17:10] <handschuh> http://revu.ubuntuwire.com/details.py?package=libballoontip-java - there is something wrong with de diff.gz
[17:11] <handschuh> s/de/the
[17:12] <mok0> handschuh: yes you still have the builx.xml file in there
[17:13] <mok0> handschuh: try to delete it before building the source package
[17:13] <mok0> handschuh: (or regenerate it from the tarball)
[17:14] <handschuh> mok0: oh thank you (uploaded)
[17:15] <handschuh> mok0: but why did this work ? the build.xml was like the one from the source
[17:15] <mok0> handschuh: wanna bet? :-)
[17:16] <handschuh> mok0: don't want to
[17:16] <mok0> handschuh: heh, computer is always right...
[17:16] <handschuh> mok0: :-)    I think I got it now
[17:18] <handschuh> mok0: damn, cancel review of the latest package, there is an other small build.xml-error
[17:18] <mok0> handschuh: no problem. Take your time
[17:25] <pochu> heh, I'm the 15th commenter in REVU even if I don't review anything for a long time :)
[17:25] <pochu> RainCT: btw, this page looks nice! http://revu.ubuntuwire.com/stats.py
[17:25] <pochu> oh, and the 12th advocater :-)
[17:26] <handschuh> mok0: now, http://revu.ubuntuwire.com/details.py?package=libballoontip-java could be checked again if time is still available  :-)
[17:26] <mok0> handschuh: in a minute
[17:26] <handschuh> mok0: take your time
[17:27] <AnAnt_> Hello, thanks for sync'ing sl-modem, now I have prepared a new package that adds support for DKMS, what should I do ?
[17:28] <AnAnt_> I mean, I understand that I will file a bug against sl-modem, and attach the debdiff, but is there something else to do? subscribe someone or add some tags ?
[17:28] <iulian> NCommander: So you say that bug #297502 will be closed automatically when it hit Intrepid?
[17:29] <iulian> NCommander: If yes please unsubscribe u-u-s from the bug.
[17:37] <sistpoty> hi folks
[17:37] <iulian> Hello sistpoty.
[17:38] <sistpoty> hi iulian
[17:43] <sistpoty> quadrispro: regarding ghc6/darcs: can darcs be synced if we have a newer ghc6? (otherwise, the build-depends can easily be lowered to our version, as reason for it is the change I made for our last ubuntu version, which then got added to the debian version)
[17:44] <quadrispro> sistpoty: :) hi! mmm i don't remember if darcs can be synced, I'm going to check it...
[17:44] <sistpoty> hi quadrispro
[17:45]  * sebner winks sistpoty 
[17:45] <sistpoty> hi sebner
[17:46] <quadrispro> sistpoty: yes, it seems darcs could be synced with new version... but I'm not sure...
[17:47] <sistpoty> quadrispro: did you try to ask the person who last touched it?
[17:47] <quadrispro> sistpoty: however we can try to build the package with the current version of ghc6
[17:48] <sistpoty> quadrispro: well, if we can avoid a merge for darcs, I guess you might be able to convince me to upload the ghc6 merge ;)
[17:48] <quadrispro> sistpoty: *you* are the last uploader for Ubuntu :)
[17:48] <sistpoty> quadrispro: damn *g*
[17:48] <sistpoty> quadrispro: the one before, I think I only did a rebuild ;)
[17:49] <quadrispro> ok, however I can try to build darcs with the current version of ghc6
[17:50] <sistpoty> quadrispro: oh, cosmetical side not on gtk2hs merge (which I'm uploading atm): if you list subentries in debian/changelog, it's good style to start the dashes at the first letter of the parent entry (example: http://paste.ubuntu.com/71959/)
[17:50] <sjdurfey> im reading a held classroom session on packaging, and the developer mentioned that the *.diff.gz is a tarball that includes "instructional files to be able to apply ONE build process to all kinds of source packages", what does this mean exactly?
[17:50] <sistpoty> quadrispro: well, if we *can* sync darcs, we should do this imho, as this will in fact reduce later merging work
[17:50] <quadrispro> you're right
[17:50] <quadrispro> ok sistpoty
[17:51] <quadrispro> i'll let you know
[17:51] <sistpoty> sjdurfey: the .diff.gz is *not* a tarball, its a compressed patch
[17:51] <sjdurfey> yeah, i typed that wrong
[17:51] <quadrispro> sistpoty: now I have to go, thank you very much for your help
[17:52] <sistpoty> thanks for helping haskell packages in ubuntu quadrispro ;)
[17:53] <sistpoty> sjdurfey: a source package consists of .orig.tar.gz (the tarball you download as is from upstream) and .diff.gz (which is the debianization of it, in form of a compressed patch) [and the.dsc, which lists what files are part of a debian package]
[17:53] <NCommander> iulian, er, you closed the wrong bug ...
[17:53] <frafu> Hello,  Could anybody give me any advice? I am trying to add a gconf schemas file to a python application that uses cdbs for packaging. The setup.py contains the command to place the schemas file into /usr/share/gconf/schemas; andand this is working. My question: how can I make debian/rules register and unregister the keys?
[17:53] <sistpoty> sjdurfey: so extracting a debian source package pretty much comes down to tar -xvzf orig.tar.gz and then zcat *diff.gz | patch -p0
[17:53] <sistpoty> sjdurfey: (with some magic in dpkg-source to adjust the directory name)
[17:54] <sjdurfey> what does -p0 do?
[17:54] <joaopinto> sjdurfey, man patch :P
[17:54] <iulian> NCommander: Eh? what bug?
[17:55] <sjdurfey> alrighty
[17:55] <sistpoty> sjdurfey: tells to patch to use all directories as found in the files
[17:55] <sjdurfey> ok
[17:56] <sistpoty> sjdurfey: with -p<n> you can strip off the first n unwanted directories (just take a look at a patch)
[17:57] <NCommander> iulian, the one that was tracking the SRU to fix svk in intrepid
[17:57] <NCommander> You weren't supposed to close that one
[17:57] <frafu> You can find the debian/rules at  http://paste.ubuntu.com/71962/
[17:57] <mok0> handschuh: get-orig-source not working for me: http://pastebin.com/f1decf9d4
[17:57] <bddebian> Heya gang
[17:57] <sistpoty> hi bddebian
[17:58] <bddebian> Heya sistpoty
[17:58] <NCommander> hey bddebian
[17:58] <bddebian> Hello NCommander
[17:59] <iulian> NCommander: I can't remember if I closed any bugs.
[17:59]  * iulian is checking.
[17:59] <NCommander> iulian, don't worry about it, I'll take care of it
[18:00] <iulian> NCommander: No, I didn't close any.
[18:00] <iulian> NCommander: https://bugs.edge.launchpad.net/ubuntu/+source/svk/+bug/282793/+activity
[18:02] <iulian> Some other guy marked that as Fix Released in Intrepid.
[18:03] <iulian> NCommander: I think that he saw nxvl's SRU ack and thought that the bug was fixed in Intrepid as well.
[18:03] <NCommander> hrm
[18:03] <NCommander> I guess it got copied into updates
[18:04]  * NCommander shurgs
[18:04] <iulian> Huh
[18:06] <sistpoty> bddebian: what's the correct action for debian bug #504528, request a binNMU? if so where'd I request it?
[18:09] <iulian> NCommander: As far as I can see it didn't get copied into -updates.
[18:09] <iulian> NCommander: It's just in -proposed.
[18:11] <NCommander> so no one acked it
[18:11] <NCommander> -_-;
[18:12] <bddebian> sistpoty: Hmm, that's a darn good question.  That would probably work.
[18:13] <sistpoty> bddebian: imho a binNMU should work, but I wouldn't know where to request it?
[18:15] <sjdurfey> ok, so when "upstream developer" is mentioned, its referring to the Debian developers, and not the Ubuntu developers?
[18:20] <sistpoty> sjdurfey: could mean anything further up the stream, e.g. debian developers or the people who wrote the program in the first place
[18:20] <sjdurfey> gotcha
[18:20] <sjdurfey> thansk
[18:23] <bddebian> sistpoty: I don't really know either, sorry :(
[18:25] <sjdurfey> in the file name, what does "0ubuntu1" mean?
[18:26] <mok0> sjdurfey: it is the release string. The 0 means that the package is not in Debian only Ubuntu
[18:26] <sjdurfey> ah ok, that clarifies it for me, the answer i saw in the held classroom setting wasnt very clear, so thank you!
[18:26] <mok0> sjdurfey: The 1 at the end is a serial number that is incremented every time the package is updated
[18:27] <mok0> sjdurfey: If a package comes from Debian, it will have a release tag called "-1" or -2 or ...
[18:27] <mok0> sjdurfey: If we make local modifications to that package, it will be called -1ubuntu1, for example
[18:28] <sjdurfey> and if the modifications of a debian package only exist in ubuntu, it would be 2.20ubuntu<modification number>?
[18:29] <sistpoty> slangasek: where could I request a binNMU for debian bug #504528?
[18:29] <mok0> sjdurfey: no, we just append "ubuntu1" to the release string (the part after the final dash)
[18:30] <sjdurfey> ok, so it would be 2.2ubuntu1?
[18:31] <mok0> sjdurfey: no, I don't understand what 2.2 is
[18:31] <sjdurfey> just an example release number
[18:32] <mok0> sjdurfey: ah, the point the release number indicates a Non-Maintainer upload in debian, in that case, you are right
[18:32] <sjdurfey> cool, thanks for the clarification mok0 :)
[18:32] <mok0> -2.2ubuntu1 means second NMU in Debian, first modification in Ubuntu
[18:33] <sjdurfey> NMU?
[18:33] <mok0> sjdurfey: I maintainer upload would have an integer release
[18:33] <mok0> s/I/A
[18:33] <mok0> NMU = Non-maintainer upload
[18:33] <sjdurfey> oh ok
[18:34] <mok0> sjdurfey: someone else than the ordinary maintainer of the package fixed a bug and uploaded
[18:35] <sjdurfey> is there a place somewhere on ubuntu's site that spells out all the different subtleties in the release scheme?
[18:35] <iulian> 2.2ubuntu1 can be a native package as well.
[18:35] <iulian> + Ubuntu changes in this case.
[18:38] <sistpoty> hm... any known blockers in current jaunty that I should avoid?
[18:38] <mok0> sjdurfey: try searching the wiki, or the help site
[18:39] <sjdurfey> will do
[18:41] <mok0> sjdurfey: just googled my way to this, pretty good explanation: http://www.ducea.com/2006/06/17/ubuntu-package-version-naming-explanation/
[18:41] <sjdurfey> mok0: thanks, ill def. take a look at it
[18:44] <sjdurfey> thanks, that was a clear and concise explanation
[18:45] <mok0> sjdurfey: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[18:46] <sjdurfey> thanks, ill read through that as well
[18:47] <sistpoty> anyone wants a package reviewed on revu? please shout now, first one wins ;)
[18:47] <handschuh> mok0: sry its again about libballoon-java
[18:48] <mok0> handschuh: did you see my comment?
[18:48] <handschuh> mok0: I found the small bug in the get-orig-source rule but the other comment is somehow complicated
[18:48] <mok0> handschuh: you mean about the date of the source?
[18:48] <handschuh> mok0: the upsream authors only put the 2008.11.14 into the releases dir in cvs
[18:49] <mok0> handschuh: ok, a daily snapshot?
[18:49] <mok0> handschuh: if they have anonymous cvs access, you could also use that
[18:50] <handschuh> mok0: no they just did not want to make it an official release because the only difference to the previous one is the license that is now in every source file
[18:50] <mok0> handschuh: argh complicated
[18:51] <handschuh> mok0: it is, but I may convice them to make it an official release  :-)
[18:51] <mok0> handschuh: but it's in their cvs repo now?
[18:52] <mok0> handschuh: their latest license update I mean
[18:53] <handschuh> mok0: it does not look like
[18:53] <mok0> handschuh: meh
[18:54] <mok0> handschuh: then this is a one-off kind of distribution
[18:54] <handschuh> mok0: ah, it is!
[18:54] <handschuh> mok0: (the currenc sources are in cvs)
[18:54] <mok0> handschuh: let me send you a get-orig-source script I've done
[18:54] <mok0> handschuh: that gets stuff from CVS
[18:55] <handschuh> mok0: that'd be great
[18:55] <slangasek> sistpoty: emailing debian-release@lists.d.o, I think
[18:56] <mok0> handschuh: coming via DCC
[18:56] <bokbaard> apparently i was told to ask here about python2.6 and 8.10 :)
[18:57] <handschuh> mok0: sorry, my messenger does not yet support file transfers
[18:57] <sistpoty> slangasek: thanks
[18:57] <mok0> handschuh: huh, which one are you using? I will pastebin it then
[18:58] <handschuh> mok0: empathy
[18:58] <mok0> handschuh: pidgin here
[18:58] <hyperair> mok0: regarding the codelite package earlier.. make is used pretty much by codelite, but it's under recommends for ubuntu-desktop, so should i include it as suggests or not?
[18:58] <mok0> handschuh: http://pastebin.com/f67b67e8a
[18:58] <handschuh> mok0: thank you very much
[18:59] <mok0> hyperair: Make is a part of the minimal package set afaik, so no need to include it
[18:59] <ethana2> I just uploaded my first packages to launchpad...
[18:59] <hyperair> mok0: okay thanks
[18:59] <ethana2> what kind of time line am I looking at as far as when things start showing up in my PPA, like binary-wise?
[19:00] <mok0> ethana2: around 4 minutes
[19:00] <hyperair> ethana2: depends on how long it takes to build
[19:00] <ethana2> 4 minutes from dsc upload to available binaries?
[19:00] <mok0> :-)
[19:00] <ethana2> that's awesome!
[19:00] <hyperair> i've had longer build times than 4 minutes before
[19:00] <mok0> ethana2: it is pretty quick
[19:00] <ethana2> nice.
[19:01] <mok0> ethana2: the waiting time before it starts compile is pretty short. How soon you will have the binaries naturally depend on how long time it take to compile the package. The build machines are not awfully fast
[19:02] <hyperair> http://revu.ubuntuwire.com/feed.py?package=codelite <-- hrmm.. MOD_PYTHON ERROR
[19:03] <mok0> siretart: ^^
[19:03] <sistpoty> RainCT: ^^ ;)
[19:03] <sistpoty> heh mok0
[19:04] <directhex> hyperair, eek! quick, port it to asp.net!
[19:04] <handschuh> mok0: there is no anonymous cvs access, i think (at dev.java.net)
[19:04] <mok0> Ah, all them nick /me gets confused
[19:04] <sistpoty> directhex: heh
[19:04] <hyperair> joker
[19:04] <mok0> handschuh: :-/
[19:05] <hyperair> directhex: if mod python's doing that, asp.net would send it up in flames
[19:05] <hyperair> =p
[19:05] <mok0> Ah, I have a date with my wife... sushi time!!
[19:05] <directhex> mok0, kinky
[19:05] <sistpoty> mok0: have a good meal ;)
[19:05] <handschuh> mok0: hace fun
[19:05] <mok0> ;-) see you later!!
[19:05] <handschuh> s/hace/have
[19:05] <hyperair> mok0: have fun
[19:05] <directhex> hyperair, mod_mono and ironpython..... it's foolproof!
[19:05] <mok0> bye
[19:06] <hyperair> directhex: no, please no.
[19:06] <sistpoty> directhex: you can write good code in any language... except brainf*ck and malbolge probably :P
[19:07] <directhex> sistpoty, how about intercal? i hear that's allowed for obfuscated code contests too
[19:07] <directhex> sistpoty, and technically there are bf.net compilers, so you could write aspnet pages with it........... o_o
[19:08] <sistpoty> directhex: oh, heh *g*
[19:08] <sistpoty> directhex: I thought intercal was an urban legend *g*
[19:08] <directhex> sistpoty, it has great language constructs like "PLEASE"
[19:09] <jmarsden|work> See http://www.catb.org/~esr/intercal/
[19:09] <sistpoty> *g*
[19:09] <directhex> sistpoty, such as "PLEASE DONT DIE" every few lines to prevent it from randomly spinlocking
[19:09] <hyperair> directhex: you can't be serious
[19:09] <sistpoty> directhex: to many "PLEASE"... aborting ;)
[19:09] <directhex> actually, i think the earliest lolcode compilers are also for .net, if you want to go "I CAN HAS int" or somesuch
[19:10] <sistpoty> s/to/too/
[19:10] <slytherin> geser: ping
[19:10] <hyperair> nothing beats lolcode
[19:11] <sistpoty> but then of course, we might also port revu to SPL (who were proud that their site was hacked -- at least some attention *g*)
[19:11] <directhex> spl?
[19:11] <directhex> bottles.lol(2,0) : error 6: "HAI" expected
[19:11] <directhex> bottles.lol(17,1) : error 12: "KTHXBYE" expected
[19:12] <sistpoty> shakespeare programming language
[19:12] <sistpoty> haha
[19:12] <directhex> seems lolcode.net doesn't support BTW comments
[19:12]  * directhex deletes
[19:12] <directhex> bottles.lol(4,5) : error : Unknown variable: "LOL"
[19:12] <directhex> bottles.lol(11,9) : error : Unknown variable: "NERFZ"
[19:12] <directhex> man, this sucks
[19:13] <hyperair> xD
[19:13] <ethana2> Can you package a .bashrc and gconf keys in a .deb?
[19:14] <hyperair> ethana2: nothing that goes inside /home
[19:14] <hyperair> ethana2: well you can, but it's annoying
[19:14] <RainCT> ethana2: gconf yes (but don't ask me how :P), and .bashrc I don't know
[19:14] <ethana2> hmm
[19:15] <hyperair> ethana2, RainCT: /usr/share/gconf/{defaults,schemas}
[19:15] <ethana2> ah
[19:15] <ethana2> Is there a place other than .bashrc where one can put bash aliases?
[19:15] <ethana2> system wide
[19:15] <ethana2> including recovery boot, excluding scripting namespace
[19:16] <ethana2> or whatever you call that when..  I suppose that's dash
[19:16] <slytherin> ethana2: /etc/profile?
[19:16] <jmarsden|work> ethana2: man bash and see the FILES section.
[19:16] <hyperair> /etc/profile.d
[19:16] <ethana2> k
[19:19] <sjdurfey> ethana2: are you a frequent poster on engadget?
[19:19] <ethana2> er
[19:19] <ethana2> that flame war was...
[19:19] <ethana2> I was tired
[19:19] <ethana2> I shouldn't post when I'm tired
[19:19] <ethana2> ...very yes....
[19:19] <sjdurfey> haha, i see you on there all the time, kinda nifty chatting with someone while their not on there
[19:20] <hyperair> flame war? i wanna see =O
[19:20] <ethana2> it's really not one worth defending
[19:20] <ethana2> I've had better; this one was just a string of misunderstandings
[19:20] <ethana2> resulting in name calling
[19:20] <ethana2> ....and cursing
[19:20] <sjdurfey> goto engadget.com and look at basically any article relating to apple or microsoft
[19:20] <ethana2> haha
[19:20] <sjdurfey> ethana2: which post?
[19:21] <ethana2> hmm
[19:21] <sjdurfey> which post/article are you referring to on there?
[19:22] <ethana2> http://www.engadget.com/2008/11/12/belkin-switch-to-mac-cable-automatically-switches-you-to-mac-gi/
[19:23] <ethana2> that's the one that just...    blecch
[19:23] <ethana2> Now I know what crying is though
[19:23] <ethana2> evidently it encompasses a large range of activities that are not usually defined as crying
[19:23] <sjdurfey> haha, ill have to check that out
[19:24] <ethana2> haha
[19:24] <ethana2> he got low ranked
[19:25] <sjdurfey> who did?
[19:25] <ethana2> Zak
[19:26] <ethana2> Ok, I'm confused..  it said package upload was successful, but i'm not getting any email and it's not showing up in my ppa
[19:27] <cprov> ethana2: what is *it* ? dput ?
[19:27] <ethana2> dput, yes
[19:27] <directhex> did you dput to the right place, with the right thing in your debian/changelog?
[19:27] <ethana2> I'm checking my settings, .dput.cf
[19:27] <cody-somerville> ethana2, what did you type to upload?
[19:27] <ethana2> yep, pbuilder..
[19:28] <ethana2> dput uh....
[19:28] <ethana2> i don't remember
[19:28] <cody-somerville> ethana2, then upload it again and tell me
[19:28] <ethana2> ok, i think it was..
[19:28] <ethana2> dput *source.changes
[19:28] <hyperair> ethana2: don't do * unless there's only one .changes file there
[19:28] <hyperair> ethana2: you don't want to reupload old versions
[19:28] <ethana2> there was only one there
[19:28] <ethana2> first build
[19:28] <cprov> ethana2: dput is saying ok only means that the files were upload, not yet processed by launchpad.
[19:29] <ethana2> yes
[19:29] <cprov> ethana2: you should receive an email within 5 minutes from lp, saying that you source was either accepted or rejected
[19:30] <hyperair> ethana2: i love my lenovo
[19:30] <cprov> ethana2: if you don't, then I can check for something broken
[19:30]  * hyperair just finished reading ethana2's comments on engadget
[19:30] <ethana2> cprov: if i receive no email at all, then something is broken in launchpad, you say?
[19:31] <ethana2> hyperair: I get emotional sometimes regarding Apple....
[19:31] <hyperair> ethana2: you should either receive an acceptance or rejection email. sometimes it can take long to come
[19:31] <ethana2> *headdesk*
[19:31] <ethana2> hyperair: ok
[19:31] <hyperair> ethana2: i fully understand. i used to be that way too, but that was when i was stupidly advocating windows
[19:31] <cprov> ethana2: or you haven't followed the PPA-guide correctly
[19:31] <cprov> ethana2: and forgot to register you gpg key
[19:31] <ethana2> no, i regesitered it
[19:31] <ethana2> **meh
[19:32] <hyperair> ethana2: did you sign your packages?
[19:32] <ethana2> yep
[19:32] <hyperair> then it should work
[19:32] <hyperair> how long have you waited?
[19:32] <ethana2> i'll just wait for that email
[19:32] <ethana2> like half an hour
[19:32] <hyperair> it usually doesn't take that long
[19:33] <ethana2> well, i have my own reality distortion field
[19:33] <ethana2> it basically just increases Moore's constant around me
[19:34] <ethana2> so that even things that /can't/ go wrong do
[19:35] <slytherin> ethana2: Can't you just find what command you used from bash history?
[19:35] <ethana2> yes
[19:35] <ethana2> dput *source.changes
[19:35] <ethana2> in the pbuilder directory, with only one such file
[19:36] <slytherin> ethana2: that is your problem I guess. You didn't specify where to upload, by default it uploads to ubuntu archives.
[19:36] <fabrice_sp> what about dput my-ppa *source.changes?
[19:36] <slytherin> ethana2: And you don't have upload rights there.
[19:36] <ethana2> slytherin: incoming = ~ethana2/ubuntu/
[19:36] <hyperair> ethana2: wait a sec, did you say pbuilder directory? did you build it before uploading? you're supposed to create source packages
[19:37] <hyperair> launchpad builds it
[19:37] <ethana2> yes
[19:37] <ethana2> oh crap
[19:37] <hyperair> debuild -S
[19:37] <hyperair> hehehe
[19:37] <ethana2> ohhhhhh that was my..
[19:37] <hyperair> so that's the problem
[19:37] <ethana2> ok sorry
[19:37] <ethana2> yes, I did a debuild -sa -S
[19:37] <ethana2> after wiping the files
[19:37] <ethana2> ...after realizing i couldn't upload binaries to PPA from the pbuilder directory
[19:37] <ethana2> this all happened last night, my memory.. yeah..
[19:38] <ethana2> this morning i just ran the upload command that failed last night
[19:38] <slytherin> ethana2: what you did is correct. Since you have source.changes file. Your upload destination is wrong. Please paste your dput.cf file to pastebin.
[19:38] <ethana2> 'cause we upgraded my internet connection
[19:38]  * ethana2 does
[19:39] <ethana2> http://paste.ubuntu.com/72006/
[19:39] <hyperair> ethana2: dput my-ppa bla_source.changes
[19:39] <ethana2> (01:37:16 PM) fabrice_sp: you should have put dput my-ppa *source.changes
[19:39] <ethana2> sorry, that's a dumb mistake
[19:39] <ethana2> that should certainly do it.
[19:39] <hyperair> ethana2: default uploads to ubuntu, whereby you get angry rejection emails saying you don't have upload rights
[19:40] <ethana2> ah
[19:40] <ethana2> or just silent rejection
[19:40] <ethana2> evidently
[19:40] <hyperair> hmm well i haven't gotten silent rejection
[19:41] <hyperair> anyway ethana2, you only use -sa when .orig.tar.gz doesn't exist on launchpad. if it's been uploaded to ubuntu before you should use -sd
[19:41] <hyperair> then you get smaller uploads
[19:41] <ethana2> k
[19:41] <ethana2> it did not in this case
[19:41] <ethana2> ..i think
[19:41]  * ethana2 runs dput correctly this time
[19:49] <jdong> "Merge dan into jdong"
[19:49] <jdong> *sigh* I really don't like git's default changelog entries.
[19:49] <jdong> maybe I'm just reading it  the wrong way.
[19:50]  * hyperair tries not to burst into a fit of giggles
[19:50] <jdong> I wonder if upstream would take me seriously if I were to complain ;-)
[19:51] <hyperair> it would be given low priority i'm sure
[19:54] <ethana2> ...maybe launchpad is just having a busy day
[19:56] <hyperair> ethana2: go to #launchpad and bug someone to look at the logs for you
[19:56] <ethana2> k
[20:01] <ethana2> hyperair: no response as of yet
[20:01] <ethana2> ..and I have to take my laptop to class soon....
[20:22] <frafu> I am trying to add schemas to a python package that uses cdbs. The schemas get installed and registered properly. On removing the package, the gconf keys get also removed from the gconf database (I checked it with the gconf editor) , however the empty directory remains listed in the gconf editor. Could anybody tell me what I am doing wrong or how to also get rid of the empty entry when removing the package?
[20:25] <frafu> You can have a look at debian/rules at http://paste.ubuntu.com/72027/
[20:26]  * mok0 looks
[20:27] <mok0> frafu: "empty directory" ... is that something created by the package?
[20:29] <frafu> Yes,I mean the entry in the gconf editor that contained the keys; "directory" might not have been the best term.
[20:30] <frafu> mok0: the schemas are at http://paste.ubuntu.com/72028/
[20:30] <mok0> Ah, I am not familiar with gconf, but it sounds like it's a problem /feature of that system and not your package
[20:32] <mok0> I asked about dirs because dpkg is notoriously bad about removing directories of unstalled packages
[20:34] <frafu> mok0:   the term directory was probably misleading; thanks for looking at it.
[20:36] <mok0> frafu: It may be relevant to file a bug on gconf
[20:37] <frafu> mok0: I am new to this; there is a good possibility that it is due to me doing something wrong.
[20:41] <mok0> frafu: Can you create a small test case?
[20:45] <frafu> mok0: as I don't know for sure, how schemas should be registered in a python package, I don't really know what I should test. I will have to find other packages to look how they are doing it. Googling has not been very helpful yet.
[20:46] <mok0> frafu: You should be able to do a "manual" register/un-register from the terminal, of a simple schema??
[20:48] <frafu> mok0: ok, if it works from the terminal, I know that at least the gconf schemas file is not the culprit. Good idea.
[21:18] <binarymutant> if anyone has the time to give any tips on my package, http://revu.ubuntuwire.com/details.py?package=charm, I would be very appreciative. Thanks :)
[21:33] <handschuh> mok0: thanks again for your comments, I uploaded tha libballoontip-java package again
[21:34] <handschuh> mok0: I wrote upstream an email to add the 2009-11-14 package as a regular download
[21:35] <handschuh> s/2009/2008
[21:36] <mok0> handschuh: cool, did you see my comment?
[21:36] <mok0> Ah ok
[21:37] <mok0> handschuh: I hope you appreciate that this work is all in the interest of getting the best possible package
[21:37] <handschuh> mok0: yes but I hope to convince upstream to create a stanrdard archive
[21:38] <mok0> handschuh: upstream's are often hard to deal with... :-)
[21:38] <handschuh> mok0: of course :-)   sorry to bother you with this small package this much
[21:39] <mok0> handschuh: no no I'm here to help
[21:39] <mok0> (or at least clarify problems)
[21:39] <handschuh> mok0: thanks!
[21:40] <mok0> handschuh: Anyway, I hope this raises your respect for Ubuntu :-)
[21:41] <handschuh> mok0: it does ... and it raises my respect even more if I think about the fact that ervery package hat to met this standards
[21:41] <jimcooncat> I'm repackaging monit, and need to bump up the version so apt-get will get my custom package instead of hardy's version "1:4.8.1-2.1" . So what do I change it to?
[21:42] <mok0> handschuh: heh, well at least it goes for the packages  not coming via Debian
[21:42] <mok0> jimcooncat: from your own repo?
[21:42] <jimcooncat> mok0: yes, I made an in-office one
[21:43] <mok0> jimcooncat: I'd just bump the release info: -2.1 -> -3~jim1
[21:44] <jimcooncat> thanks mok0 I'll try that
[21:45] <mok0> jimcooncat: If a version -3 or -3ubuntu appears in the archive, it will override your version
[21:46] <jimcooncat> mok0: I don't really want that; same if a major version change. It would be cool if I could get notified though. Should I cange it to "1:20.1"?
[21:47] <webtech_m33> who works on mailscanner ?
[21:48] <webtech_m33> i am working on a new filter server with 8.10 on it.. clamav is 0.94.1 and now mailscanner says WARNING: Ignoring deprecated option --unrar
[21:48] <webtech_m33> mailscanner is ver 4.68.8
[21:50] <mok0> jimcooncat: no, it's better to pin it in apt.conf, then
[21:51] <mok0> webtech_m33: you want to contact ScottK
[21:52] <webtech_m33> mmk
[21:52] <webtech_m33> TY
[22:10] <tdomhan> does anyone have an example for an ITP bug, in order to get an package into debian?
[22:13] <ethana2> so I uploaded signed packages earlier, but just now figured out how to upload my gpg key and all that
[22:13] <ethana2> dput won't let me upload that package again, 'cause it already did it
[22:14] <ethana2> ...does that mean I don't need to do anything else, and the packages I uploaded before becoming an Ubuntero will show up in my PPA soon?
[22:16] <jimcooncat> hey it worked!!!! now I need to find a very simple way to sign my packages/repository
[22:18] <azeem> ethana2: dput just looks at the .upload file; if the upload was successful from the dput POV, but got rejected by the archive, it is likely you will have to run dput again with -f or delete the .upload first
[22:19] <ethana2> so -f is to force it..
[22:19]  * ethana2 runs with -f
[22:26] <ethana2> ok, uploaded...  I guess I'm waiting for an email?
[22:26] <handschuh> has anyone besides mok0 time to review http://revu.ubuntuwire.com/details.py?package=libballoontip-java ?
[22:30] <RainCT> handschuh: long description: s/api/API/; avoid lines longer than 80 characters (debian/copyright - the best would be to list each author on a line). Looks fine otherwise (on a first glance), but I don't feel comfortable enough with Java to advocate
[22:31] <handschuh> RainCT: I will change that
[22:32] <ethana2> HAHAHAAHAAA my first package is being built!
[22:32] <RainCT> ethana2: congrats :)
[22:32] <ethana2> ....but not for PPC.......
[22:33] <ethana2> If I wanted to contribute processing power from a PS3 to launchpad and start a build service for PPC64, how would I do that?
[22:34] <RainCT> ethana2: I don't think that's feasible, but you could ask in #launchpad
[22:34] <ethana2> hrrm
[22:35] <azeem> how much RAM does a PS3 have?
[22:35] <ethana2> pbuilder over boinc would be the strangest..
[22:35] <ethana2> it has 512MB
[22:35] <ethana2> if you use the vRAM as swap, which we do
[22:35] <ethana2> a G5 could be better, some IBM server or something
[22:38] <handschuh> RainCT: fixed it
[22:39] <RainCT> nhandler: if you want ping me whenever you comment on a package and I'll move it to "needs work" (good work, btw) :)
[22:41] <RainCT> handschuh: Cool. As I said, I don't know about / am not interested in Java, but I'm sure someone else will have a look :)
[22:42] <handschuh> RainCT: yes, I know, but if you find something that doesn't fit, let me know
[22:42] <nhandler> RainCT: It isn't a big deal. It just makes it easier on the other MOTUs to find packages that need work. I actually just got home a few minutes ago, so I haven't started reviewing (although I plan to start now). I'll send you a list of packages later. Although, hopefully, I will soon be able to mark them as needs work myself ;)
[22:42] <RainCT> nhandler: yeah, I've already found two reviewed by you in the last 5 minutes :P
[22:44] <nhandler> RainCT: Then they must not be from today. I haven't reviewed anything yet ;)
[22:45] <RainCT> nhandler: uhm I see.. August 7 XD
[22:46] <nhandler> RainCT: Is there a reason that non-motu's can't mark a package as needing work?
[22:47] <RainCT> nhandler: that they may not be correct and that some may fear commenting because they are not sure if they are right and don't want to move it to needs work
[22:48] <RainCT> nhandler: allowing them to do "recommendation" (which will basically give the package row in the index page a different bg colour so that MOTUs see it) is on my TODO
[22:48] <nhandler> RainCT: Have you also considered adding a way for a MOTU to say that they are working with the uploader on a certain package?
[22:49] <RainCT> nhandler: No. Do you have a use case?
[22:50] <nhandler> RainCT: On a few packages, I have been working with the uploader via IRC (and sometimes email) to get the package ready for the repositories. If there was a way to sort of "assign" myself to the package, that would show other people that someone else is already actively reviewing the package. That way, they won't need to waste their time doubling efforts.
[22:50] <nhandler> You would probably want to restrict the assignment feature to MOTUs though
[22:51] <sistpoty> RainCT: oh, do I need to set s.th. to move a package to needs-work nowadays? (jodviewer)
[22:51] <RainCT> nhandler: what's about leaving a comment saying "do not review until I say so"?
[22:51] <RainCT> sistpoty: it's only moved if MOTUs comment without advocating, you should know that :P
[22:51] <sistpoty> RainCT: should != is :P... thanks!
[22:52] <sistpoty> RainCT: so the cruel sql statement is still in place *g*
[22:52] <nhandler> RainCT: The comments are not visable on the main package list.
[22:52] <sistpoty> (cruel as in cruel to read)
[22:53] <RainCT> sistpoty: of course. do you really believe that I'm going to touch it? :P    (</jk>)
[22:53] <sistpoty> RainCT: haha
[22:53] <sistpoty> RainCT: /me blames persia for it in the first place :P
[22:53] <RainCT> sistpoty: persia?
[22:53] <RainCT> has he ever touched the REVU code? :P
[22:54] <sistpoty> RainCT: sure, he had the idea of negative advocations... I just wrapped up a sql statement for it
[22:54] <RainCT> heh
[22:55] <nhandler> RainCT: Why do we even allow uploads without a .orig.tar.gz?
[22:55] <RainCT> nhandler: native packages ^^
[22:57] <nhandler> RainCT: I thought native packages didn't have the .diff.gz
[22:57] <RainCT> true
[22:57] <RainCT> they've a .tar.gz, iirc
[22:58] <RainCT> wait, that's not the real reason XD
[22:58] <nhandler> I thought all packages were required to have a .orig.tar.gz.
[22:58] <nhandler> What is the real reason?
[22:58] <azeem> nhandler: historical reasons, maybe
[22:59] <RainCT> nhandler: I ought to modify the post-upload scripts so that uploads without .orig.tar.gz get a link to it if it is already there from a previous upload
[22:59] <RainCT> (TODO too)
[22:59] <nhandler> RainCT: Be sure to compare the versions in the changelog to the old .orig.tar.gz (to make sure that they match)
[23:00] <RainCT> nhandler: MD5/SHA sums :)
[23:00] <nhandler> RainCT: To check that the changelog hasn't changed?
[23:00] <RainCT> argh
[23:01] <RainCT> I should go sleep xD
[23:01] <nhandler> Good night RainCT
[23:01] <RainCT> my brain is frozen past midnight XD
[23:02] <sistpoty> RainCT: heh... I tried to use fdupes on spooky once, but gave up since it took too long *g*
[23:02] <sistpoty> (regarding .orig.tar.gz files)
[23:03] <RainCT> sistpoty: can't you tell fdupes to look for files with the same name, and not recursively?
[23:03] <RainCT> or even to just look at some known locations (which we can generate looking at the db..)
[23:03] <sistpoty> RainCT: not too sure, I didn't read *all* of the manpage :P
[23:04] <RainCT> sistpoty: uhm, it isn't that long
[23:04] <sistpoty> damn, so you caught me as non-manpage reader :P
[23:05] <RainCT> sistpoty: böser Hun.. er, sistpoty *g*
[23:05] <sistpoty> hehe
[23:12] <RainCT> If anyone's up for reviewing, the following packages are REVU Day Targets and need your love:   http://revu.ubuntuwire.com/details.py?package=sqliteman  http://revu.ubuntuwire.com/details.py?package=banihstypos  http://revu.ubuntuwire.com/details.py?package=bot-sentry
[23:17] <nhandler> RainCT: I'll look at banihstypos again once I finish with the package I am currently reviewing
[23:18] <mok0> RainCT:  I'm done for today, sorry...
[23:19] <handschuh> mok0: thanks again for your work!
[23:19] <tdomhan> I would appreciate if someone would look at bot-sentry ;)
[23:20] <james_w> hi tdomhan
[23:20] <RainCT> mok0: tomorrow morning is still REVU Day :)
[23:20] <tdomhan> hi james
[23:27] <sistpoty> tdomhan: if you're around for a little bit of time, I'll give you a review for bot-sentry ;)
[23:29] <tdomhan> sistpoty: kk I'll be around for some time
[23:29] <sistpoty> tdomhan: config.status target: either b-d on autotools-dev or remove the part that copies config.sub/config.guess pelase
[23:30] <sistpoty> tdomhan: any reason to override LDFLAGS for configure? (that will strip out -bsymbolic-functions, which might be on purpose or not)
[23:31] <nhandler> Isn't the number in debian/compat meant to match the version of the debhelper Build-Depends in debian/control?
[23:33] <sistpoty> nhandler: yep
[23:34] <sistpoty> nhandler: iirc lintian should also warn about this
[23:34] <nhandler> sistpoty: I thought it did too. However, I didn't get a warning about it when I last checked the package. Oh well.
[23:34]  * sistpoty shrugs
[23:34] <tdomhan> I am not shure about LDFLAGS, I think that was the default, wasn't it?
[23:34] <RainCT> nhandler: not necessarily
[23:35] <sistpoty> tdomhan: well, the default is to not add any LDFLAGS directive
[23:35] <RainCT> I think you can force a recent debhelper version (perhaps because you need a newer dh_ command) but use a old compat level (because you may not want/need some of the new features it introduces)
[23:35] <RainCT> i may be wrong though
[23:37] <nhandler> RainCT: In your example, you are saying that the Build-Depends for debhelper would be for a more recent version of debhelper than what is listed in debian/compat. That sounds correct. However, I do not believe the opposite is possible
[23:38] <sistpoty> hm... *using* that scheme would however seem bad to me (old-dh, that would need porting, but then using a new command?) *shrug
[23:38] <sistpoty> +*
[23:38] <tdomhan> ok I think the LDFLAGS aren't needed, I will remove them
[23:41] <sistpoty> tdomhan: /usr/lib/purple-2/*so is meant to be picked up by pidgin?
[23:41] <RainCT> nhandler: then we think the same :)
[23:42] <tdomhan> concerning config.status: you mean deleting line 14to19? why aren't they needed? and what do you mean by " b-d on autotools-dev"?
[23:46] <sistpoty> tdomhan: if you have your debian/rules to eventually update config.sub/config.guess, you should add autotools-dev as a build-dependency
[23:47] <sistpoty> tdomhan: if it's not needed (since upstream autotools files are kind of up to date), you can delete these bits in debian/rules
[23:48] <sistpoty> tdomhan: but having these there w.o. a build-dependency on autotools-dev only is of beautification value
[23:48] <sistpoty> tdomhan: anyway, the package is imho quite good ;)
[23:51] <tdomhan> sistpoty: thank you, nice too hear. isn't autotools-dev listed under the build dependencies?
[23:51] <tdomhan> and what is the problem with debhelper and debian/compat, they are both 5 aren't they?