[00:02] <CyberMatt> i just don't like the idea of make connecting out
[00:02] <jcfp> Just read above that when repacking the upstream tarball, one needs to rename. Is there any guidelines as to what to add to the version; I'm seeing "repack" mentioned here, "dsfg" or so on some package out there... does it somehow depend on the changes made?
[00:03] <CyberMatt> don't know why i don;t i just don't
[00:06] <CyberMatt> i removed the upstream debian/ it had problems
[00:06] <CyberMatt> but if a g-o-s is needed it will get done
[00:08] <CyberMatt> i just a) don't like it b) want to keep my rules as uncomplex as possible
[00:09] <RAOF> jcfp: Yes.  "dsfg" indicates that files which are not compatible with the Debian Free Software Guidelines have been removed.  "repack" is a bit more general; in this case it's because upstream ships a debian/ directory themselves.
[00:13] <CyberMatt> gotta go vote
[00:13] <jcfp> RAOF: so unless I'm certain all the not-completely-free-by-debian-strict-interpretation stuff has been removed, "repack" is the way to go
[00:14] <RAOF> jcfp: If there's stuff that isn't completely-free-by-debian-standards, it's not going to go in the archives at all.
[00:15] <CyberMatt> unless in contrib or non-free
[00:15] <StevenK> We don't have the concept of contrib, as it were
[00:15] <RAOF> It's just a guideline.  If you're removing stuff to make it acceptable for the archives, repack it as dfsg.
[00:16] <CyberMatt> but who uses those execcpt to get flash nvidia carq and dvd + codecs
[00:17] <jcfp> what if upstream release includes a directory with some windows binaries. remove? keep only those that are foss licensed and include source in the tarball?
[00:17] <jcfp> and what with those binaries in a release that dont come with the source but are under, say, gpl
[00:17] <RAOF> jcfp: I'm not sure.  I'd be tempted to remove anything not built from source, but if they're windows binaries...
[00:18] <RAOF> jcfp: If they're released under the GPL, we need to provide source.  Which should be in the source package :)
[00:20] <jcfp> RAOF: so in any case, of those files only the ones that are gpl-or-compatible licensed AND have their source included in the upstream release may even be kept?
[00:20] <jcfp> when repacking, that is
[00:21] <RAOF> jcfp: I'm not experienced enough on the debian-legal side, and I haven't read the DFSG recently.  My feeling would be "if it's not built from source that exists in the source package, it shouldn't be there"
[00:22] <jcfp> RAOF: thanks, i'll just copy that feeling ;)
[00:25] <imbrandon_> eww why would someone put binarys of any kind ( let alone windows ) in a source release tar
[00:25] <imbrandon_> seems creepy
[00:25] <RAOF> imbrandon_: When they're distributing mono libraries?
[00:26] <imbrandon_> RAOF: and ... ? they can be built just the same
[00:26] <RAOF> It's pretty creepy, but it's not terribly uncommon.
[00:26] <jcfp> imbrandon_: a python program... with win32 helper binaries; it's about sabnzbdplus on revu
[00:26] <RAOF> imbrandon_: Yeah, but unlike, say, C code the mono .dll binaries can be run anywhere.
[00:27] <imbrandon_> jcfp: i can understand that in a win32 binary download tar , but not a source tar
[00:27]  * jcfp isn't in control of upstream releasing habits
[00:27] <imbrandon_> RAOF: sure, but thats not the point, ELF can run on non linux too under certain cercumstances, but WHY
[00:28] <RAOF> imbrandon_: Well, in the case that I'm thinking of (Tao), it's because the build system was a stone cold bitch.
[00:28] <imbrandon_> jcfp: sure, totaly understandable, but you can ask/influence them :)
[00:29] <RAOF> And it was a lot of effort to actually build the damn thing (if you even could).  And they weren't really meant to be installed system-wide, either.
[00:29] <imbrandon_> :P
[00:30] <jcfp> imbrandon_: if time wasn't running out for getting things in hardy, I'd concentrate my efforts with them.
[00:30] <jcfp> but now... :(
[00:31] <imbrandon_> well if they wernt built from the source thats in the source tar then no dont include them
[00:31] <imbrandon_> bottom line
[00:31] <imbrandon_> but better to get upstream to remove them, for *now* you can repack dfsg
[00:31] <imbrandon_> etc etc etc
[00:32] <jcfp> ok than i'll do that. remove all but those who include source AND are gpl-or-compatible licensed
[00:33] <jcfp> I guess it wouldn't be okay to just remove things on the basis that they're not needed?
[00:34] <imbrandon_> not really
[00:34] <jcfp> e.g. I really need a (licensing or copyright related) excuse
[00:34] <imbrandon_> but you can not install them :)
[00:34] <imbrandon_> note installing them and not including them in the source is totaly diffrent :)
[00:34] <imbrandon_> s/note/not
[00:35] <imbrandon_> its a tad devious but its not uncommon
[00:35] <jcfp> I always fear that reviewer coming by saying I deleted to much/not enough/etc
[00:36] <imbrandon_> when repacking a tar change as little as humanly possible
[00:36] <imbrandon_> thats the rule of thumb
[00:36] <imbrandon_> but say there is something in the source that upstream includes that you dont really want, you simply leave it in the source but dont install it via the deb
[00:38] <imbrandon_> see what i mean ?
[00:38] <jcfp> imbrandon_: sabnzbdplus contains two extra interface templates (couple of dozen files each) that have a small number of files that have improper licensing
[00:38] <imbrandon_> inproper lic is not "i dont want" that needs to be fixed/removed
[00:39] <jcfp> following this; I end up deleting only those specific files, leaving the rest
[00:39] <imbrandon_> "i dont want" == <blah> builds two plugins i dont want to support so i'm not gonna install them
[00:39] <imbrandon_> jcfp: yes
[00:40] <jcfp> bah :( writing 5 pages of copyright stuff for the remaining files with which nothing is ever done.
[00:40] <imbrandon_> well improper lic == not non-gpl lic
[00:40] <imbrandon_> err dosent
[00:40] <jcfp> I know
[00:41] <imbrandon_> if your wanting to remove them just so you dont have to change the debian/copyright thats wong
[00:41] <jcfp> the problematic files have no license, or specify only "BSD License" without specifying which one
[00:41] <jcfp> or giving full text
[00:42] <ion_> Have you contacted upstream?
[00:42] <imbrandon_> umm which one? "BSD" is only one license, there are many variants but "BSD" lic is only one
[00:43] <jcfp> ion_: I think iĺl pressure them once more
[00:43] <jcfp> imbrandon_: some bsd licenses are not gpl-comp
[00:43] <ryanakca> Would anybody happen to have a link to the debian changelog "what to do, and what not to do" guide?
[00:44] <imbrandon_> jcfp: most bsd lic variants arent gpl compat , but that changes the fact very little
[00:44] <jcfp> imbrandon_: they don't specify, that's the point. Just "BSD License", without any further text
[00:45] <imbrandon_> jcfp: and thats my point, specifiy WHAT ?
[00:45] <RAOF> Hit them upside the head!
[00:45] <jcfp> with the better part of the program under gpl
[00:51] <jcfp> creative commons v3 - is that a free license?
[01:04] <blueyed> http://revu.ubuntuwire.com/details.py?package=jedit
[01:05] <blueyed> woops.. wrong channel.. ;)
[01:05] <blueyed> jcfp: kind of.. see http://www.gnu.org/licenses/
[01:06] <blueyed> jcfp: I've meant http://www.gnu.org/philosophy/license-list.html
[01:07] <blueyed> does not mention CC-3 though..
[01:08] <jcfp> yeah went there but no info. google tells me debian didn't consider CCv2 ok, http://people.debian.org/~evan/ccsummary
[01:08] <jcfp> but v3... still searching
[02:08] <JediMaster> Hey guys, I'm producing a .deb, I've got the bulk of it done, and some pretty complex install scripts
[02:08] <JediMaster> I was just wondering if the upgrade scripts get passed what version is currently installed, and what version is being installed so you can run particular scripts on upgrades?
[02:09] <RAOF> JediMaster: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html may help you.  There's a better summary somewhere, though.
[02:09] <RAOF> And the short answer is "yes"
[02:10] <JediMaster> thanks
[02:14] <JediMaster> is there a "proper" way to access databases for applications you are installing to install new SQL and upgrade it?
[02:14] <RAOF> I remember such a discussion recently, maybe on the MOTU ML?  I think there's a database-common package, which does something like that?
[02:14] <JediMaster> e.g. I've got a mysql database that needs to be installed from an sql dump on fresh install, and on upgrade run through the differences between each version
[02:15] <JediMaster> I can do it easily enough, it's just password access I need to address
[02:17] <JediMaster> btw, if anyone's interested, I've written a utility in php to track changes to MySQL databases for projects, it can track both schema and row changes to particular tables, take a peek at phpMyVersion on sourceforge, the latest svn version is working pretty well
[02:17] <JediMaster> hopefully it can be of some use to someone here =)
[02:18] <ion_> ActiveRecord migrations are awesome.
[02:19] <JediMaster> yeah, I've heard of it, this is a little web interface with a fairly powerful SQL parsing engine that reads through the latest changes in the mysql SQL log periodically and can track multiple databases on multiple projects (all MySQL mind you)
[02:20] <JediMaster> think the difference is that this can track row changes as well as schema
[02:21] <ion_> The migrations feature takes care of migrating both schema and data.
[02:21] <JediMaster> ah cool, well I probably re-invented the wheel =)
[02:21] <JediMaster> only took a day or two to do anyhow
[02:23] <ion_> And it’s database-agnostic. ;-)
[02:23] <JediMaster> how does it keep track of changes if it's on a database without binary log files?
[02:24] <JediMaster> does it just compare schema and row data?
[02:24] <JediMaster> like a sort of diff
[02:25] <JediMaster> am I right in thinking "debian-sys-maint" has full mysql access to the local databases? and if so, is it possible to get the password so upgrade scripts can alter particular dbs?
[02:29] <JediMaster> heh, never mind, found the password in plain text in a file only readable by root, perfect =)
[02:29] <ion_> The change for each revision of the database layout – i.e. migration – is in a separate file, with the filename starting with the version number. ActiveRecord stores the current version in a special table the database. Each migration contains the rules what to do when the database is being upgraded to that version, as well as when the database is being downgraded from that version. If the database says it’s version 10, there are migrations 1..15 ...
[02:29] <ion_> ... available and the migrations are run, the migrations 11..14 would be run by default. For instance, the first migration could add the tables “posts” and “comments”, the second migration could rename the table “posts” as “articles” and the third migration could add a “comments_count” field to the “articles” table, and fill the field in for each article that exists in the database.
[02:30] <JediMaster> yeah sounds very much like what I've written, execpt the sql is in a php array indexed by the version
[02:32] <ion_> Some samples of actual migration files: http://glu.ttono.us/articles/2005/10/27/the-joy-of-migrations
[02:33] <JediMaster> oh weird, is that ruby?
[02:33] <ion_> Yep, ActiveRecord is bundled with Rails.
[02:34] <JediMaster> nice, I'm afraid I'm calling php scripts from deb package install/upgrade scripts lol
[02:34] <JediMaster> ok, got to run, thanks for the help =)
[02:37] <wastrel> hi, i have a bug with upstream fix that needs MOTU to update into ubuntu.
[02:37] <wastrel> bug 184505
[02:37] <ubotu> Launchpad bug 184505 in jppy "jppy fails to launch" [Undecided,New] https://launchpad.net/bugs/184505
[02:37] <bddebian> Heya gang
[02:38] <RAOF> Yo!  bddebian!
[02:39] <bddebian> Hi RAOF
[02:40] <RAOF> Hm.  I wonder if I want to ask for gnome-keyring-sharp to be synced from Sid.
[02:43] <RAOF> What the hell.  It's got no bugs in the bts, it's been essentially stable for a while, and it seems not unlikely that people (ie: me) will want it.
[02:44] <emgent> heya
[02:49] <ScottK> wastrel: The ideal solution is you make an updated package with the patch, attach it to the bug and subscribe ubuntu-universe-sponsors to the bug.  If you need help with that, ask.
[02:51] <wastrel> diy eh
[02:52] <tuxmaniac> anybody seen laserjock around ?
[02:53] <tjgillies> !seen laserjock
[02:53] <ubotu> Sorry, I don't know anything about seen laserjock - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[02:54] <tjgillies> im surprised botty doesn't have that function
[03:02] <crimsun> wastrel: heh.  Are you working on it?
[03:03] <PriceChild> tjgillies, /msg seenserv help
[03:04] <tjgillies> PriceChild, thnx
[03:06] <wastrel> crimsun, that's a negative.  don't have the time or energy.
[03:06] <wastrel> cleaning out my email inbox :]
[03:08] <crimsun> wastrel: heh, ok.  Pretty simple fix.  Uploaded.
[03:08] <crimsun> I'm not even going to think about my inbox, which I can't even access for another few weeks.
[03:09] <wastrel> yeah but i don't have an environment set up for building packages
[03:09] <wastrel> thanks
[03:09] <crimsun> if you're on broadband, it doesn't take but a few minutes.
[03:10] <crimsun> ScottK: glad to see you're on the nom for MOTU Release Team
[03:13] <ScottK> crimsun: Thanks.
[03:13] <Hobbsee> oh yes, i should vote with that
[03:14] <TheMuso> Same.
[03:14]  * RAOF just has.
[03:19]  * ScottK should too.
[03:22] <ScottK> Oddly enough the other tab open in that browser window had US Presidential primary election results in it.
[03:25] <StevenK> I so hope Hilary becomes president
[03:26] <RAOF> StevenK: Why?
[03:26] <StevenK> Then she can point to Bill Clinton and say "I did not have sexual relations with that man."
[03:26] <RAOF> :P
[03:26]  * ScottK laughs.
[03:27] <StevenK> RAOF: She seems a little more 3 dimensional than Obama. And lets face it, she is loads better than Dubya
[03:28] <ScottK> She's pretty well unelectable though.
[03:28] <RAOF> It seems that pretty much everyone satisfies the latter constraint.
[03:28] <ScottK> Very few people are neutral on her.
[03:28] <StevenK> ScottK: Oh?
[03:28] <ScottK> It's roughly 40% love her, 50% hate her, and 10% are uncertain.
[03:29] <StevenK> RAOF: Well, I like her better than Obama. He seems a little, um, "Oh woe is me. Look what I've had to deal with."
[03:29] <RAOF> I haven't been following particularly closely, but whta I've seen of Obama makes me favour him.
[03:29] <wastrel> figures i heard were 30%ish hate her
[03:29] <ScottK> Depends on the poll I guess.
[03:29] <StevenK> ScottK: So, today is Super Tuesday, right?
[03:29] <ScottK> Yes
[03:29] <wastrel> which matches well with the 30% of complete idiots who approve of W still
[03:29] <StevenK> ScottK: So, out of today, we get two candiates for the presidentancy?
[03:30] <wastrel> hrm o4o apply in here :]
[03:30] <ScottK> Maybe
[03:30] <wastrel> i'm going back to my email
[03:30] <StevenK> ScottK: I'm a little unclear. The elections are *far* more complicated than us convicts
[03:30] <ScottK> Yes.  Understand.
[03:31] <ScottK> It's extremely unlikely that anyone will have enough delegates to their respective party conventions after today to be sure to win.
[03:31]  * TheMuso mehs at the US presidential race.
[03:31] <ScottK> Excellent
[03:31] <ScottK> TheMuso: Would you please motu-sru ack Bug #120445
[03:31] <ubotu> Launchpad bug 120445 in firestarter "Firestarter firewall continuously crashes no matter which desktop or screen it's on." [Medium,Fix released] https://launchpad.net/bugs/120445
[03:32] <StevenK> I'm a little interested, but I'm also interested in why libosso causes hildon-desktop to SEGV
[03:32] <StevenK> If anyone wants to cringe, I can explain the bug
[03:32] <ScottK> The short version is after tonight my prediction is the McCain will about have it in the bag and the dems will still be split.
[03:32] <TheMuso> ScottK: If I remember how to state that its worth an SRU, sure. :p
[03:32] <ScottK> I'll stop now.
[03:33] <StevenK> Isn't Dubya Republican?
[03:33] <ScottK> Yes
[03:33] <ScottK> But he's not running.  Term limited
[03:33] <StevenK> Right, more reason to like Hilary
[03:33] <StevenK> ScottK: I knew that bit
[03:33] <LucidFox> Oh no. USA politics on an Ubuntu channel. :/
[03:33] <ScottK> He's pretty unusual as Republicans go.
[03:33] <StevenK> (Thank $DEITY he can't run)
[03:34] <bddebian> WTF, did someone say there's a reason to like Hitlery?
[03:35] <StevenK> Oh yes, compare her to Naziism, that'll make me respect your point of view.

[03:36] <LucidFox> And USA politics being talked about by an Australian, no less. :)
[03:36] <StevenK> I'm curious enough to discuss them, but I don't care much.
[03:36] <RAOF> As their largest colony, it's only fair :P
[03:36] <ion_> You have used the Hitler card. You have no Hitler cards left.--MORE--
[03:37] <StevenK> RAOF: It only seems that way thanks to Howard
[03:38] <RAOF> True.  I was just trying to remember how to spell facicious.
[03:38] <RAOF> And failing :)
[03:38] <StevenK> Haha
[03:38] <StevenK> RAOF: Oh yes, I hit level 65 last night. :-)
[03:38] <RAOF> StevenK: Cool, cool.
[03:38] <LucidFox> Well, since Australia is their _largest_ colony, it means Russia isn't their colony. That's a relief. :
[03:38] <LucidFox> )
[03:39]  * RAOF hasn't been Wowing much recently.
[03:39]  * StevenK kicks libosso and dbus
[03:40] <RAOF> StevenK: To move the topic back onto something vaguely resemling "on", do you want to help me close the gtk-engine-nodoka ITP, or shall I hit the sponsor ML?
[03:40] <bddebian> StevenK: Nah, she's not a nazi, just a socialist.
[03:41] <StevenK> RAOF: I'd rather not review something, just because I don't want to drop state.
[03:41] <RAOF> StevenK: This isn't a "now" proposition, really.  It's just a "do you want first crack at it sometime".
[03:41] <RAOF> And also a "how lazy can I be" question ;)
[03:43] <StevenK> RAOF: Send it to mentors, and I'll grab it if someone else doesn't
[03:43] <RAOF> K.  It's already there, but I'll advertise it too then.
[03:45]  * StevenK sighs at libosso
[03:45]  * RAOF is reminded of "porko rosso" each time you say that.
[03:46] <bddebian> What is porko rosso?
[03:46] <RAOF> A Miazaki anime.  Possibly misspelled.
[03:46] <bddebian> Ah
[03:47] <RAOF> About a pig, who flies bi-planes.
[03:47] <bddebian> Hmm
[03:48] <StevenK> RAOF: libosso is Nokia's abstraction layer over dbus
[03:48] <RAOF> What does it abstract?
[03:48] <StevenK> The message passing bit
[03:49] <StevenK> So, both system and session buses
[03:49] <TheMuso> StevenK: I'm about to head into a mess of work also. That being the espeak audio output fiasco.
[03:49] <TheMuso> As soon as I get this cvs snapshot packaged.
[03:49] <StevenK> I'm starting to really hate this.
[03:50] <RAOF> My major experience with dbus has been in python, where there doesn't seem to be anything *to* abstract.
[03:51] <StevenK> libosso installs a dbus/system.d file that is frightening.
[03:51]  * Hobbsee is glad that the MOTU election stuff is nothing like the US presidential elections
[03:51] <StevenK> Changing that seems to have a negative effect on hildon-desktop that SEGVs
[03:52] <StevenK> RAOF: http://paste.ubuntu.com/4235/
[03:52] <bddebian> Hobbsee: Why so we can't disparage you for your views? :-)
[03:52] <Hobbsee> :P
[03:52] <RAOF> StevenK: Ah, the old "security is for pansies" config file.
[03:53] <StevenK> RAOF: "Security? What security?"
[03:53] <RAOF> "We implicitly trust every app on this system"
[03:53] <StevenK> BAD
[03:54] <StevenK> RAOF: pitti wisely took one look at the file and said, "libosso isn't getting main goodness until you fix that."
[03:54] <RAOF> Oh, dear.  Very much yes.
[03:55] <StevenK> RAOF: So, I have a very different file right now, and hildon-desktop SEGVs
[03:55] <TheMuso> StevenK: ouch indeed
[03:55] <ion_> Haha, nice config.
[03:55] <StevenK> From what I can work out, libosso takes a bunch of handlers and stuffs them into a GSList inside a GHashTable (yay for abstract data structures)
[03:55] <RAOF> Because why catch errors when you can just ensure that the daemon will never sanity check you!
[03:56] <StevenK> With the config file that I showed you, it works. With mine (any of mine, it seems any change I make doesn't help) it SEGVs
[03:57] <ion_> Quality software from one of the most aggressive lobbyists for EU software patents. :-)
[03:58] <TheMuso> If this is the kind of code nokia produces, I'm not sure I want to touch another of their products.
[03:59] <ion_> One word: symb**n
[04:00] <TheMuso> ion_: If their devices were accessible, no problem.
[04:00] <TheMuso> ion_: Do they still use symbian?
[04:01] <StevenK> TheMuso: On their phones, yes
[04:01] <TheMuso> StevenK: Hrm. The latest talks etc don't appear to work with them, so far as I know. Its all damn nokia.
[04:01] <StevenK> TheMuso: They did jump a major Symbian version which isn't backward-compatible
[04:02] <StevenK> That was a little while ago, though
[04:02] <TheMuso> right
[04:02] <TheMuso> nevertheless
[04:02] <LucidFox> Suppose I want to restore Mozilla branding in iceowl 0.7-2 and rename it back to Sunbird; do I need it to pass REVU, or can I just upload sunbird 0.7-2ubuntu1 directly to Ubuntu?
[04:02] <TheMuso> the only 3rd edition symbian phones that seem to be supported are nokia
[04:02] <StevenK> TheMuso: Ah yes, that's it. 3rd edition.
[04:02] <StevenK> TheMuso: My N80 is 3rd edition
[04:03] <TheMuso> StevenK: So is my 5700
[04:03] <StevenK> I am gettting so convinced to buy a flip phone
[04:03] <TheMuso> I personally couldn't think of anything worse.
[04:04] <StevenK> The N80 has two Navi-keys, when you slide it closed and lock it, you need to press the left and then the right key to unlock it
[04:04] <StevenK> And then if hit the dial key, you can dial the last number
[04:04] <StevenK> While it's in a pouch on your belt, it's *very* easy to do that
[04:06]  * StevenK has a theory about this libosso problem
[04:06] <TheMuso> StevenK: Re the phone, sounds like fun
[04:07] <StevenK> TheMuso: It really isn't.
[04:07] <TheMuso> You really need to install a keypad auto lock program, unless the phone has such a feature.
[04:08] <TheMuso> My previous phone, I used an autolock app, which was great. My new one however, has this feature, although it only works when the phone is at the standby screen.
[04:09] <StevenK> TheMuso: autolock doesn't help, since it doesn't change how you unlock the phone
[04:09] <StevenK> TheMuso: Locking the phone isn't the problem, it's how completly and utterly trivial it is to unlock it by accident
[04:09] <TheMuso> StevenK: right
[04:15] <imbrandon_> ugh anyone else here on new(er) apple hardware ?
[04:16] <imbrandon_> i cant get the damn numlock to activate
[04:19] <tonyyarusso> Is there a Launchpad status for "fix available" as in someone's written the code, but it's not in Ubuntu yet?
[04:19] <StevenK> Fix Commited
[04:20] <tonyyarusso> Ah, okay.  I thought that meant it had been like send to the LP build queue or something.
[04:21] <LucidFox> So, Fix Committed can be used for bugs fixed upstream?
[04:22] <tonyyarusso> Sounds like it..
[04:22] <StevenK> tonyyarusso: I wouldn't use Fix Commited for that
[04:22] <tonyyarusso> StevenK: care to explain further how you would use it?
[04:23] <StevenK> tonyyarusso: If I'd uploaded it, I'd put the bug in the changelog and set it to In Progress when I'd uploaded it.
[04:23] <StevenK> Launchpad would then close it for me
[04:24] <tonyyarusso> StevenK: What if you had attached the fix to the bug but didn't have archive upload rights?
[04:24] <StevenK> Um. That doesn't affect me, so I don't use it that way
[04:25] <tonyyarusso> :P
[04:25] <ScottK> One of the LP devs had a long blog post last year the told us exactly how we were supposed to use all the status and that we were wrong to do it any other way.  Google probably knows about it if you talk to it nice.
[04:25] <Aloha> you gotta rub it the right way
[04:25] <imbrandon_> fsk this is makin me mad, how can i assign the numlock function to an "f" key ?
[04:27] <tonyyarusso> "Fix Committed: a developer has committed his/her fix to the project's codebase.", "In Progress: a developer has taken responsibility to fix the bug and has begun work." - given that "the codebase" in this case (just Ubuntu packaging info) resides in the archives, I'm guessing "In Progress" is best for me.
[04:29] <TheMuso> StevenK: Does your theory pan out?
[04:29] <StevenK> Nope
[04:29] <StevenK> libosso hates me
[04:29] <TheMuso> I'd be hating it I think
[04:29] <bddebian> Gads evolution sucks
[04:31] <StevenK> Argh
[04:32]  * RAOF is bathed in the sweet music of complaint :)
[04:32] <bddebian> heh
[04:33] <ScottK> Sounds like RAOF has children.
[04:33]  * ScottK is soaked in it daily
[04:33] <bddebian> heh
[04:34] <RAOF> The nearest child to me is the baby that lives below our flat :/
[04:36] <Aloha> RAOF, i just watched hot fuzz last night. good movie
[04:36]  * RAOF is perplexed by the non-sequiter.  It is, however, a good movie.  At least the first time.
[04:38] <LucidFox> bddebian> I use kmail
[04:39] <LucidFox> Despite having GNOME. That's the least ugly email client I've seen.
[04:39] <LucidFox> What's frustrating is that it's literally the last KDE3 application I still use.
[04:40] <bddebian> I used Thunderbird.  It's OK, but evolution tried to be outlook like or something
[04:40] <LucidFox> Thunderbird is good.
[04:41]  * ScottK uses Kmail too.
[04:41] <LucidFox> Enigmail, however, is ugly - and I _do_ need PGP support.
[04:42] <ScottK> Gutsy and later Kmail comes with all the bits you need for PGP already installed and configured (you just need to tell it what key to use).
[04:42]  * tonyyarusso actually thought Enigmail was pretty good, especially compared to Evo's handling
[04:43] <Aloha> i like the evolution plugin
[04:43]  * TheMuso had better get the washing in before the weather turns any more nasty... could storm here very soon.
[04:43] <Aloha> TheMuso, does washing == laundry?
[04:44] <StevenK> Aloha: Yes
[04:45] <Aloha> RAOF, i only said i watched it because you said "flat" and it reminded me of the movie because we don't talk like that here :)
[04:46] <StevenK> Since he didn't say 'Arr-part-ment' ?
[04:46] <Aloha> StevenK, i live in a condo ;)
[04:46] <StevenK> Aloha: Merely an example. :-)
[04:47] <Aloha> StevenK, we say "ah-part-ment" at least in this part of the country :)
[04:47] <StevenK> Heh
[04:48] <bddebian> Aloha: Where are you?
[04:48] <slangasek> arr-part-ment?  pirate country?
[04:48] <StevenK> bddebian: On IRC
[04:49] <bddebian> pfft
[04:49] <slangasek> judging by his ISP, I'm guessing Kentucky
[04:49] <StevenK> slangasek: Slightly exaggerated
[04:50] <slangasek> StevenK: I have no idea what you're exaggerating, unless you're mocking commonwealthers inability to pronounce r's in the first place ;)
[04:50] <StevenK> Or l's, based on nuclear?
[04:51] <slangasek> Texas is a separate country
[04:51] <bddebian> That's nucular
[04:51] <StevenK> Haha
[04:51] <bddebian> They wish
[04:51] <StevenK> "The United States of America. Oh, and Texas."
[04:51] <Rushido-Fokkusu> Zatsu nukuraru
[04:52] <superm1> StevenK, hey now we're not our own country anymore.
[04:52] <superm1> StevenK, that was many years ago :)
[04:52] <bddebian> s'ok, it'll be Mexico again soon
[04:56]  * jdong applies for a Linus of the Day Award
[04:56] <jdong> I needed a homework organizing system, and none of the existing TODO/calendaring apps quite fit my bill
[04:57] <jdong> so I got together a bunch of hackish ruby scripts to manipulate a directory tree of plaintext files into a TODO list :D
[04:58] <Flannel> jdong: tried tdl?
[04:59] <jdong> Flannel: yes in fact, my implementation was quite inspired by tdl
[05:00] <jdong> Flannel: but tdl didn't do exactly what I needed, and its on-disk format was a bit too complex for my tastes
[05:00] <Flannel> jdong: for curiositys sake, what about tdl didn't you like/didnt work/whatever?
[05:01] <jdong> Flannel: my main criteria were (1) Can be parsed/edited by a human with generic editors (2) Is easily manageable via bzr for concurrent disconnected mirrors
[05:01] <jdong> I believe tdl uses a binary storage system which is not ideal for merging
[05:02] <Flannel> bzr does binary diffs though, right? unlike cvs
[05:02] <jdong> Flannel: not really, last time I checked. It recognizes binary files are "different" and will go into manual conflict resolution
[05:02] <jdong> which is not all that helpful
[05:02] <jdong> if I add a TODO from computer A and delete one from computer B, then try to merge...
[05:03] <jdong> bzr would tell me there's tdldb.THIS and tdldb.OTHER
[05:03] <Flannel> Oh, I dont mean for merging, I mean just in the DB itself.  Storage.
[05:03] <jdong> that's awesome, but..... yeah
[05:03] <Flannel> Yeah, tdl is binary formatted.
[05:03] <jdong> Flannel: right, bzr can store binaries perfectly
[05:03] <Flannel> it does incremental storage?
[05:03] <jdong> yes
[05:03] <jdong> it uses a diff algorithm internally to represent binary changes
[05:04] <Flannel> Alright.  Itd be crazy if something so new didnt
[05:04] <jdong> I recall, however, the performance of diffing massive binaries is not up to par with its competitors
[05:04] <jdong> mostly because its competitors have natively implemented diffs
[05:06] <ion_> bzr is orders of magnitude away from up to par in performance from certain competitors. :-)
[05:06] <jdong> ion_: they're getting better though
[05:06] <lifeless> ion_: when did you last test
[05:06] <lifeless> ion_: and what base
[05:06] <jdong> they've come a long way and definitely make steady, predictable progress
[05:06] <jdong> and look at that, here comes a bzr guy to the rescue :D
[05:07] <jdong> lifeless: I'm guessing he tried to pull one of the many 5000+ file bzr branches off launchpad ;-)
[05:07] <lifeless> jdong: have you upgraded to packs ?
[05:07] <jdong> in which case, I feel quite sorry for him :)
[05:07] <jdong> lifeless: locally, yes, but I haven't had the opportunity to try anything over the network with packs
[05:08] <jdong> lifeless: is it significantly improved?
[05:08] <lifeless> jdong: you should do 'bzr upgrade sftp://bazaar.launchpad.net/....'
[05:08] <lifeless> jdong: followed up by 'bzr reconcile <same url>'
[05:08] <lifeless> jdong: for each of your branches
[05:08] <jdong> lifeless: I'll do that
[05:08] <lifeless> jdong: about 5000 times faster in your case
[05:08] <ion_> lifeless: Just bzr --help from a warm cache takes 0.45 seconds here. git does many of the most used operations in much less than that.
[05:08] <jdong> lifeless: well that's a good speedup :)
[05:09] <lifeless> ion_: thats a very meaningful benchmark
[05:09] <jdong> lifeless: people get fussy when help doesn't immediately arrive!
[05:09] <ion_> If --help takes that, the rest of the operations probably take *at least* that.
[05:09] <StevenK> lifeless: One thing to keep in mind, the version of bzr in Gutsy doesn't support packs
[05:09] <lifeless> 0.325 real seconds for me
[05:09] <jdong> bzr --help  0.18s user 0.04s system 98% cpu 0.223 total
[05:09] <lifeless> StevenK: ppas for the win. kthxbye.
[05:10] <jdong> StevenK: backports
[05:10] <jdong> StevenK: though admittedly bzr-svn lags behind ;-)
[05:10] <StevenK> I prefer lifeless's soltuion.
[05:10] <lifeless> ion_: you are making many assumptions about what --help has to do; this is strange for someone that has used git (making assumptions is strange I mean)
[05:10] <StevenK> I avoid crackports
[05:10] <jdong> fine fine, trust some random PPA over the backports team :)
[05:10] <lifeless> the bzr developers ppa
[05:10] <lifeless> not exactly random
[05:11] <jdong> I was being sarcastic, you guys have a wonderful ppa
[05:11] <lifeless> k lol
[05:11] <StevenK> That sounded more bitter
[05:11] <lifeless> why isn't backports a ppa ?
[05:11] <jdong> no, it's just after-coding bitterness
[05:11] <ion_> lifeless: Having to wait half a second for something to happen every time you run a command just feels slow after getting used to getting results almost immediately.
[05:12] <StevenK> Dear hildon-desktop, stop segfaulting. kthxbye
[05:12] <lifeless> ion_: I'd guess at some problem in your setup
[05:12] <lifeless> how long does 'time python -c ""' take for instance
[05:12] <ScottK> Well we could just stop packaging anything that's hosted on LP and automatically pull in from upstream PPAs.
[05:12] <jdong> lifeless: (1) ppa's weren't invented 3 release cycles ago (2) I don't feel like downloading some of those 30+MB source archives just to change 2 lines in changelog and reupload them...
[05:12] <ion_> lifeless: 0.1 s
[05:13] <jdong> lifeless: (3) ppc/sparc/friends would probably not be happy
[05:13] <jdong> (4) no packages.ubuntu.com listings.... (minor reason)
[05:13] <lifeless> jdong: YHBT HTH HAND KTB
[05:14] <ScottK> (5) PPAs not part of Ubuntu
[05:14]  * jdong tries to match those letters onto a dvorak keyboard....
[05:14] <jdong> many backports testers/contributors are setting up PPAs to test backports, though
[05:14] <jdong> which is an interesting and good use for PPA
[05:14] <ScottK> Agreed.
[05:14] <lifeless> ion_: so nearly 25% of the 'slowness' of bzr is bare bones python startup
[05:15] <jdong> but why Backports doesn't use PPAs altogether is the same reason why we don't just have a MOTU ppa and ditch Universe
[05:15] <lifeless> ion_: now, we know that python is very slow at loading modules, we're looking at ways to refine it further so its not slow in this regard
[05:15] <TheMuso> jdong: If mol were used on ppc, IMO packages could be built for PPC for PPAs.
[05:15] <ion_> lifeless: Yes, obviously having to load the python interpreter and a bunch of python modules causes the initial startup delay.
[05:16] <lifeless> ion_: anyhow, its scaling that matters: if we pay a constant overhead compared to something written in C, but beyond that are comparable, its not a big deal IME - and we're certainly getting enough refuges from git.
[05:17] <lifeless> ion_: in fact, see rusty russel's recentish blog post 'git is the slowest modern vcs'
[05:17] <ion_> Will do
[05:17] <jdong> TheMuso: that would be interesting
[05:17] <jdong> TheMuso: I don't personally think PPA's on common arches are as useful as PPAs on exotic ones
[05:18] <jdong> as far as a developer/tester tool
[05:19] <TheMuso> jdong: Well since mol allows you to run either OS X or Linux on top of Linux, IMO its worth investigating.
[05:19] <tonyyarusso> That's true.  an x86 PPA is nice for distributing stuff to the public, but doesn't add value for development.
[05:19] <TheMuso> Mol authors claim almost 100% speed
[05:19] <TheMuso> I fI remember correctly.
[05:19] <StevenK> lifeless: I have Rusty's problems with git, too
[05:20]  * TheMuso doesn't remember seeing anything about that on Planet LA
[05:20] <TheMuso> unless its not sindicated. Anybody got a link?
[05:20] <StevenK> TheMuso: http://ozlabs.org/~rusty/index.cgi/tech/2008-01-07.html
[05:20] <ion_> lifeless: The “My first git whine for 2008” post? That one seems to be about PEBKAC. :-)
[05:20] <TheMuso> StevenK: Thanks.
[05:20] <LucidFox> Well, for me personally, PPA is useful for test-building on Hardy. Paying for traffic and all, it would be to expensive to do on my local machine.
[05:21] <StevenK> ion_: Oh, yes, because the error messages are *so* useful
[05:22] <lifeless> ion_: 'interface usabilility'
[05:22] <lifeless> ion_: a hard to use interface will be used wrongly; design drives interface. Gits design drives its usability, and human time doing the wrong thing is vastly more costly than 0.5 seconds when you personally run a command.
[05:23] <TheMuso> interesting read
[05:23] <ScottK> For me, not having to learn N + 1 VCS that isn't used anywhere else is a big driver.
[05:23] <ion_> I guess i’ve just been lucky, since my subjective UI experience with git has been at least as good as with bzr.
[05:24] <StevenK> It does raise the point, "Rusty is smarter than me, and if he can't use git, what chance do I have?" :-P
[05:27] <ion_> I used to be a bzr fanboy. :-)
[05:28] <lifeless> ion_: well, I'd be interested in knowing what you need from us to be able to switch back
[05:33] <RAOF> I think the thing many people would miss from git is the bisecting tool, which doesn't seem to have a bzr counterpart.
[05:33] <RAOF> I haven't used it for my own projects (I never introduce regressions, ever :P), but it was great fun with nouveua.
[05:33] <RAOF> s/misspelling/nouveau/
[05:35] <ion_> lifeless: The subjective “feeling” is somewhat difficult to quantify. The responsiveness is a big part of it. How branches reside under the same project tree by default and everything is designed around that is another part of it (bzr switch feels more like an afterthought compared to that). It would be nice if long output was piped to a pager by default (AFAIK someone’s been working on that already).
[05:35] <lifeless> RAOF: as in 'bzr-bisect'
[05:35] <lifeless> https://edge.launchpad.net/bzr-bisect
[05:35] <RAOF> Ah, right.  Not yet in bzrtools :)
[05:36] <lifeless> ion_: the branch model in git we consider rather ugly
[05:36] <RAOF> I did think that was an obvious candidate.
[05:36] <lifeless> ion_: bzr switch is going to get some polish added to it
[05:37] <ion_> Git’s branch model is something i fell in love with, but i don’t blame anyone for disagreeing. :-)
[05:37] <RAOF> It seems like an implementation detail that's been accidentally exposed, to me.
[05:38] <RAOF> Particularly the *arcane* syntax for extracting branches from a tree.
[05:38] <ion_> In fact, i had hoped bzr worked like that before i had actually studied git enough to know it works like that.
[05:40] <LucidFox> Any Python gurus here? I need to patch setup.py to accept a --root=/path/ command option, but I don't know how to read that option
[05:40] <lifeless> ion_: we're going to do something to allow bzr to be git-like in this respect
[05:40] <RAOF> LucidFox: It's not using distutils?  I was under the impression that had such an option by default.
[05:40] <lifeless> but hopefully more stylish
[05:40] <LucidFox> it is using distutils
[05:41] <ion_> lifeless: Nice
[05:41] <LucidFox> it's just hardcoded to install the desktop file to /usr/share/applications
[05:41] <RAOF> lifeless: I suggest ponies.  They're very stylish.
[05:41] <RAOF> LucidFox: Ah, fun.
[05:41] <ion_> raof: May i suggest unicorns?
[05:41] <StevenK> lifeless: For 1.2, or later?
[05:41] <lifeless> StevenK: pipeline
[05:41] <RAOF> LucidFox: Why not just patch it to hardcode the right path? :)
[05:41] <StevenK> Ah, right
[05:43] <StevenK> Hah
[05:43] <LucidFox> that would solve it, but I would like to have a patch I could send upstream
[05:43] <StevenK> It works if the config file has <allow own="*"/>
[05:44] <RAOF> LucidFox: Fair enough, yeah.  I forget how to get those options out of distutils, though.
[05:44] <StevenK> Is there any way to query dbus to see what the libosso service owns?
[05:44] <RAOF> StevenK: So it's not so bad.  You can just impersonate any system service.
[05:44] <StevenK> Twitch
[05:44] <RAOF> Hello!  I'm policykit!
[05:45] <RAOF> No, really!
[05:45] <StevenK> RAOF: Well, I'd like to lock it down, but I need to know what it wants to own first.
[05:45] <RAOF> StevenK: Have you checked out the d-feet dbus debugger?
[05:45] <TheMuso> Hrm. That was a close one.
[05:45] <TheMuso> May consider going offline soonish...
[05:46] <TheMuso> As it is, its nearly the end of the work day, so its not all bad.
[05:46] <RAOF> Eh.  Lightning only makes computers super-powerful.
[05:46] <TheMuso> I wish/
[05:46] <StevenK> RAOF: For about 2 ms anyway
[05:46] <StevenK> Then they decide they can't handle the power
[05:46] <RAOF> They only need a couple of hours rest to recover afther their exertions :)
[05:49] <StevenK> RAOF: Are there hardy packages for d-feet?
[05:49] <RAOF> StevenK: Yup.  In universe, have been for a couple of weeks.
[05:49] <StevenK> Sweet
[05:50] <TheMuso> One more close one, and I'm outa here...
[05:50]  * TheMuso glances nervously at the sky
[05:53] <ion_> The universe has been known to grab some of its computing power back from computers via lightning.
[05:55] <StevenK> RAOF: Grah. d-feet doesn't help
[05:56] <RAOF> StevenK: Really?  Damn.  I was sure I saw some sort of "owner" field somewhere there.
[05:56] <ScottK> LucidFox: Look at debian rules in pymilter (source pacakge name) at the install for python-milter.
[05:56] <ScottK> That may be an example of what you want.
[05:56] <LucidFox> thanks
[06:14]  * StevenK kicks moinmoin, too
[06:15] <StevenK> A nice way of seeing what groups moinmoin thinks I'm in would be nice
[06:52] <slangasek> StevenK: hmm, who else was sharing the libldap rebuilds?
[06:53] <StevenK> slangasek: persia
[06:54] <slangasek> and which part of the alphabet did he get? :)
[06:54] <StevenK> slangasek: The middle bit
[06:55] <slangasek> ok
[06:55] <slangasek> there seem to be a lot of remaining reverse-deps all over the alphabet
[06:56] <slangasek> certainly including mine, which I'm just now starting on
[06:56] <StevenK> How much is left, I can take some more
[06:57] <slangasek> hmm, some 50 left
[06:57] <slangasek> little less than that
[07:00] <StevenK> slangasek: I remember uploading a bunch, but I didn't check if they built or anything
[07:01] <slangasek> StevenK: there are a total of 6 build failures in Debian from the binNMUs for this transition
[07:01] <slangasek> down to 5 now
[07:01] <slangasek> (was 10 originally, but I think I synced the remainder as they got fixed anyway)
[07:23] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[07:42] <vemon> i sent an updated (new upstream version) of jack-rack to launchpad a while ago. any motus care to take a look at it? (LP #187190)
[07:42] <ubotu> Launchpad bug 187190 in jack-rack "[update] jack-rack" [Wishlist,Confirmed] https://launchpad.net/bugs/187190
[07:43] <TheMuso> I'll take care of it.
[07:44] <TheMuso> vemon: Does debian have it yet?
[07:47] <vemon> TheMuso, no the don't. otherwise i would have requested a sync
[07:47] <vemon> they
[07:47] <dholbach> good morning
[07:47] <Aloha> TheMuso, if a packge is in universe and a new release is available, is the maintainer required to package it , or can anyone submit to REVU?
[07:47] <Aloha> dholbach, morning!
[07:48] <TheMuso> Aloha: Anybody can package it, but its better to get it into Debian first. However, if you want it in Ubuntu, and the Debian maintainer hasn't responded/has no intension of doing it, you don't put it on REVU. You file a bug, attach at least the .diff.gz file from the new package, which either has a watch file, or a get-orig-source rule in debian/rules, and subcsribe ubuntu-universe-sponsors
[07:50] <Aloha> TheMuso, thnx
[07:52] <TheMuso> vemon: DId you check that there were no other changes needed to comply with standard 3.7.3?
[07:58] <LucidFox> TheMuso> So diff.gz uploads can now be sponsored? Interdiffs are no longer necessary?
[08:06] <TheMuso> LucidFox: No they are no longer necessary.
[08:06] <LucidFox> Great.
[08:08]  * LucidFox uploads the diff.gz to bug #187576
[08:08] <ubotu> Launchpad bug 187576 in smplayer-themes "Upgrade to smplayer-themes 0.1.15" [Wishlist,Confirmed] https://launchpad.net/bugs/187576
[08:09] <vemon> TheMuso, no i didn't :/ i just assumed i would get errors if there were problems
[08:10] <vemon> TheMuso, is there a tool to check the compliance?
[08:10] <TheMuso> vemon: No.
[08:11] <TheMuso> vemon: But things look ok.
[08:12] <vemon> i made a few other changes to the package also since it wouldn't build out of the box with the new upstream version
[08:14] <vemon> for example removed tarball.mk include from the rules file since i couldn't figure out where it's needed and it just caused errors in the build
[08:14] <vemon> would it be a good idea to notify the original packager about the new upstream version in ubuntu?
[08:15] <vemon> i don't have a debian installation @ home so i can't test the package in debian but the sync to debian unstable would probably be quite trivial
[08:18] <TheMuso> vemon: At least file a bug abot it, yes.
[09:28] <shibata> Hi, all.
[09:36] <dcordero> hi
[10:35] <sistpoty|work> hi folks
[10:35]  * LucidFox nods
[10:38] <geser> Hi sistpoty|work
[10:38] <sistpoty|work> hi geser
[10:49] <sistpoty|work> man-di_: thanks for picking up changes in sdl-image1.2 (still wanted to report a bug in BTS, but forgot to do this until now :/)
[11:16] <geser> Fujitsu: do you remeber why the "Changed Blogroll to point to Planet Ubuntu instead of Planet Debian" change got dropped during your merge of wordpress in November?
[11:21] <Fujitsu> geser: I don't recall... it may have been to do with Debian dropping the change that introduced the Planet Debian link in the first place. I forget.
[11:26] <geser> Fujitsu: how do we handle wordpress in the previous releases? there is a new wordpress version out (as usual with security fixes)
[11:32] <Fujitsu> geser: Find the patches for any of our releases that are vaguely up-to-date, I guess.
[11:32] <Fujitsu> The policy for most releases seems to have been to run away, however.
[11:33] <emgent> heya
[11:51] <sistpoty|work> dholbach: btw.: I'll be around at 22nd, so I could hold the library packaging session there
[11:51] <dholbach> sistpoty|work: that's awesome!
[11:51] <sistpoty|work> np ;)
[11:52] <dholbach> sistpoty|work: if you think you need two sessions, that's fine - just add them as "part 1" and "part 2"
[11:52]  * dholbach hugs sistpoty|work
[11:52] <sistpoty|work> dholbach: yes, I'll definitely need to sessions. Will add them tonight (don't have login credentials here atm)
[11:52]  * sistpoty|work hugs dholbach
[11:53] <dholbach> sistpoty|work: I can add it for you - no problem
[11:53] <sistpoty|work> k, thanks!
[11:53] <dholbach> awesome
[12:17] <slytherin> geser: Can you anyway push for the DTD issue. I have the debdiff attached. We need to fix lucene2 as soon as possible since netbeans 6 is waiting for it.
[12:18] <geser> is it bug #183164?
[12:18] <ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
[12:18] <slytherin> geser: yes
[12:21] <geser> slytherin: you need a core-dev for it to sponsor
[12:21] <slytherin> geser: I know. I thought you could bribe someone. :-P
[12:22] <geser> dholbach: could you assign a main sponsor for bug #183164?
[12:22] <ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
[12:22] <dholbach> geser, slytherin: I was a bit hesitant as I wanted to see how the Debian discussion turns out
[12:23] <persia> dholbach: The DD doesn't want to fix it that way.  In any case, it won't get resolved by FF, and blocks some features that at least I want to include in hardy.
[12:24] <slytherin> dholbach: That is the reason I have made minimal change. Just to fix what we want.
[12:26] <persia> The other alternative is disabling parts of the test suite for build-deps, but that doesn't really seem ideal (or hand-building, which makes buildd admins cry)
[12:30] <dholbach> ok... I'll do the upload - would you agree to do the merge (in hardy+1) and watch if there's any negative fallout from this change?
[12:34] <slytherin> dholbach: Sure. I will keep a watch.
[12:34] <dholbach> great, thanks
[12:34] <mruiz> morning all
[12:35] <smarter> hi everyone
[12:35] <smarter> I've updated my bespin package: http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin
[12:35] <smarter> It has been rejected because of a debian/copyright error
[12:36] <smarter> Could someone please review it?
[12:39] <sistpoty|work> smarter: just took a short look at the debdiff, your debian/copyright still seems to be wrong
[12:40] <smarter> sistpoty|work: why?
[12:40] <sistpoty|work> smarter: you mention files under GPL2, but refer to LGPL-2 link in /usr/share/common-licenses
[12:40] <smarter> sistpoty|work: I refer to both
[12:40]  * sistpoty|work looks at plain debian/copyright
[12:42] <sistpoty|work> smarter: ah... I'd exchange the links that refer to GPL/LGPL to make it more clear (the GPL link is directly below the LGPL disclaimer and the LGPL link below the GPL disclaimer)
[12:43] <dholbach> slytherin: can you join #ubuntu-devel - pitti and asac are looking at it
[12:48] <shibata> persia: Thank you for advocating. By the way, where do I write "This package should upload in multiverse." for REVUer or uploader? In REVU comment? or debian/copyright?
[12:50] <persia> shibata: Don't worry about it.  That was my comment to indicate to the next reviewer that I thought it belonged in multiverse, so they could pass that on in discussions with the archive admins.
[12:51] <shibata> persia: I see. thanks again.
[12:55] <persia> shibata: Also, my apologies for the too-brief review of kita2.  Please review RainCT's comments, and submit a new candidate.
[12:56] <RainCT> Heya
[12:56] <shibata> persia: I'm doing it now.
[12:57] <persia> RainCT: Thanks for catching all that :)  Perhaps you can find a problem with the other packages I advocated last night?
[12:58] <smarter> sistpoty|work: oh, right
[12:58] <shibata> Hi RainCT. Thank you for revu and comment of kita2 package. I have some questions about kita2.
[12:59] <RainCT> persia: heh don't worry, I'm just picky :)
[13:00] <RainCT> shibata: np, just ask :)
[13:00] <persia> RainCT: That's a good thing :)
[13:00] <shibata> RainCT: About No. 0, If I would like to create and to install some files which does not exist in original .tar.gz, then which should I create it in original source tree by use dpatch or in debian/ directory?
[13:00] <smarter> sistpoty|work: Uploaded ;) http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin
[13:00] <RainCT> shibata: in debian/
[13:00] <RainCT> shibata: patch systems are only useful to modify files that are already in the .orig.tar.gz
[13:00] <smarter> sistpoty|work: oh, I forgot to change the "the complete text of ..." line
[13:01] <smarter> sistpoty|work: just a minute
[13:01] <sistpoty|work> smarter: don't hurry because of /me... I cannot do in depth reviews here at work anyways
[13:01] <RainCT> shibata: but for adding new files, using a patch system just make it more difficult and don't make sense (a patch is more difficult to read than a plain file, it can't be edited directly, etc.)
[13:03] <shibata> RainCT: I see about No. 0. Next is about No. 3, If I change original source tree and/or add new file (for instance, launcher), then I think that I *must* write about it in README.Debian or README.Debian-source, is it right?
[13:03] <smarter> sistpoty|work: okay, I'll stop bothering you ;)
[13:03] <sistpoty|work> heh
[13:04] <persia> shibata: Only add to README.Debian when the contents are interesting to end-users, and only add to README.Debian-source when you expect other members of the maintenance team to be confused by something you did.  For a simple file addition, you needn't do either.
[13:04] <frafu> Hello, mousetweaks is a module that passed revu a few days ago, and I received a build failure email due to a missing dependency; the building procedure happened 9 hours ago: https://edge.launchpad.net/ubuntu/+source/mousetweaks/2.21.90-0ubuntu1/+build/507079 However, in the upload queue there are debs of mousetweaks build 16 hours ago: https://edge.launchpad.net/ubuntu/hardy/+queue?start=60 Does the presence of the debs in the queue n
[13:05] <persia> frafu: buffer: "debs in the queue n"...
[13:05] <RainCT> frafu: your message was cut "in the queue n"
[13:05] <frafu> Hello, mousetweaks is a module that passed revu a few days ago, and I received a build failure email due to a missing dependency; the building procedure happened 9 hours ago: https://edge.launchpad.net/ubuntu/+source/mousetweaks/2.21.90-0ubuntu1/+build/507079
[13:05] <frafu> However, in the upload queue there are debs of mousetweaks build 16 hours ago: https://edge.launchpad.net/ubuntu/hardy/+queue?start=60
[13:05] <frafu> Does the presence of the debs in the queue not mean that the build was successful 16 hours ago? Thus why has it been build a second time 9 hours ago?
[13:05] <geser> frafu: compare the architecture.
[13:06] <geser> frafu: only hppa failed to build, the others build successfully so far (lpia is still in the build queue)
[13:06] <RainCT> shibata: no, a README file isn't necessary for that (as persia just said). it's easy to notice that you added that file just having a fast look at debian/rules or debian/install (I don't remember what you used), and users shouldn't worry about it anyways (only if it would be changing the behaviour of the application in some important way)
[13:07] <persia> s/important/interesting/
[13:07] <RainCT> persia: :)
[13:07] <frafu> So there are 5 architectures?
[13:08] <geser> frafu: six: i386, amd64, powerpc, sparc, lpia and hppa
[13:09] <persia> Did we drop ia64?  We used to have that as well.
[13:09] <geser> frafu: add ia64 and make it seven
[13:09] <frafu> Will the build system automatically retry, or does the fact that I received a failure notice imply that I have to intervene?
[13:10] <persia> frafu: Depends on the reason for failure.  Typically "Failed to build" requires manual intervention.
[13:10] <geser> persia: that happens why I try to list the architectures from memory without checking :)
[13:10] <persia> geser: I understand.  I was sure it was six as well until I started typing, and you commented while I was still going back so s/six/seven/ :)
[13:12] <persia> frafu: This one looks a little odd, as I'd expect it to have gone DEPWAIT rather than FAILED.  I'd watch the status of libpanel-applet2-dev on hppa, and when that is looking healthy, ask for a give-back.
[13:12] <geser> frafu: looking at the build log: hppa has broken dependencies, you can't do anything about it besides helping to resolve them
[13:13] <geser> persia: iirc soyuz doesn't catch broken deps and automatically retries later
[13:13] <shibata> persia, RainCT: I understand. Last question does not relate to kita2. When I create new package, which prefer to use CDBS or debhelper without specific problem?
[13:13] <persia> geser: Then why are so many packages listed as DEPWAIT at http://qa.ubuntuwire.com/ftbfs ?
[13:14] <geser> persia: they wait on missing packages or a specific version
[13:14] <persia> Ah.  The difference between cannot-install and does-not-exist.  That makes sense.
[13:15] <frafu> I assume that when release time has arrived, all architectures will ship the same modules; correct?
[13:15] <persia> shibata: Best is to make your debian/rules as readable as possible.  If you do nothing special, CDBS is nice.  If you need lots of CDBS overrides, and can make it more understandable with a normal makefile, don't use CDBS.
[13:16] <persia> frafu: That's the goal, although only i386, amd64 and sparc were promised for gutsy.  I'm not sure whether the final architecture determination has been made for hardy yet.
[13:17] <smarter> The kde4-style-bespin package should now be ready for re-upload ;) http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin
[13:17] <frafu> When will the package appear in universe? Once the module has been successfully built on all architectures?
[13:18] <vemon> is anyone else experiencing extreme slowliness with packages.ubuntu.com?
[13:18] <shibata> persia, RainCT: Thank you very much for answers. I'm fully satisfied.
[13:19] <persia> vemon: There were some DNS changes announced recently.  You'll likely have a better experience with rmadison and apt-cache search anyway.
[13:19] <RainCT> frafu: no, it will appear soon (if it isn't there already) for those architectures for which it is already built
[13:19] <geser> frafu: they will appear in universe once the build packages pass binary NEW (are accepted by an archive admin)
[13:20] <RainCT> frafu: ah, well, then what geser says too :P
[13:20]  * persia points at https://launchpad.net/ubuntu/hardy/+queue
[13:20] <RainCT> geser: so all binaries are manually checked before being published?
[13:21] <persia> RainCT: Only lightly.
[13:22] <geser> RainCT: yes, but only once (when they are new), but I don't know what exactly gets checked
[13:22] <geser> "old" packages get published as soon as they got build
[13:24] <RainCT> ah, only when they are new. ok, this makes sense, thanks :)
[13:38] <frafu> The package that has gone into the queue fails to register the schemas. I have an updated version that fixes the issue on my computer. However, coming sunday or monday a new upstream version will be released that includes other fixes. Should I wait for the new upstream to also fix the schemas issue?
[13:41] <persia> frafu: I'd wait for the new upstream, to reduce the load on the buildds.  No point fixing it today and uploading again on Monday.
[13:41] <persia> (unless you need testers desperately)
[13:47]  * RainCT wonders why pbuilder installs fakeroot each time it build something -.-
[13:48] <RainCT> s/build/builds
[13:49] <jdong> anyone have suggestions for how to write a fast "fake" pbuilder-satisfydeps just to check of build-deps are satisfied for pkg $foo on distro $bar?
[13:49] <frafu> persia: what happens if the universe admins reject it due to the schemas issue? Will I have to propose an updated version for universe or go again the revu route ?
[13:50] <jdong> My first idea was to evoke pbuilder on just basically the control file in question and a dummy rules file
[13:50] <norsetto> howdy folks
[13:50] <jdong> my second idea was to write my own pbuilder-satisfydeps that queries rmadison :)
[13:50] <gaspa> norsetto: uella'
[13:50] <norsetto> hola gaspa
[13:51] <RainCT> jdong: look at get-build-deps in ubuntu-dev-tools
[13:51] <RainCT> jdong: I think I have a check to see if all dependencies are satisfied there
[13:53] <persia> frafu: If it is building, it was already accepted.
[13:53] <ScottK> frafu: You go back to revu, but it only takes one advocate to get it uploaded
[13:53] <ScottK> Or not in this case.
[13:57] <frafu> persia: Above it was said: "they will appear in universe once the build packages pass binary NEW (are accepted by an archive admin)". So the universe admins check it before the build and after the build!?
[13:57] <jdong> RainCT: that uses the local system's apt repo data, which isn't all that useful for me...
[13:57] <jdong> RainCT: I know the pbuilder dummy build method will work and be trivial to code, while the rmadison approach will not be trivial... just a matter of which is faster
[13:58] <jdong> RainCT: for backports, looking for a way to shortcut fetching a 50MB source archive, having debuild turn it into a source archive, copy that into a temp dir.... if the build-deps don't even meet
[14:00] <uniscript> apt-get build-dep package?
[14:02] <uniscript> man dpkg-checkbuilddeps
[14:02] <uniscript> shame it works off the debian/control file rather than the .dsc file :(
[14:04] <jdong> uniscript: well... backports builds can be against any distro release, not the active one running
[14:04] <geser> jdong: rmadison doesn't say you if all build-depends are installable at the same time
[14:04] <sistpoty|work> jdong: maybe with having all distros in sources.list and a senseful pinning and overriding this for apt-get
[14:04] <uniscript> true
[14:04] <jdong> uniscript: and consists of building against $release, $release-updates, $release-backports, and nothing else
[14:05] <jdong> which is smoemthing that's not true about my host system
[14:05] <uniscript> talking of backports I'm writing an mpdebuild that adds things like a distribution list to basically a pdebuild command
[14:05] <persia> frafu: Your source package won't be removed from the archive because of issues with binary NEW.
[14:05] <uniscript> is this a stupid idea?
[14:05] <jdong> uniscript: one of the most common complaints I get about prevu is "Why the hell did it download 200MB of crap just to say it couldn't do it??"
[14:05] <RainCT> jdong: ah ok
[14:06] <jdong> uniscript: well pbuilder-dist I think does what you're thinking
[14:06] <uniscript> you mean take a list of distros and go off and let me drink tea?
[14:07] <geser> jdong: can't you do "apt-get -s build-dep pkg" before try the real build to check if the build-depends can be installed?
[14:07] <jdong> uniscript: well no, it can maintain concurrent pbuilders for a list of distros. which to build can be specified as a CLI argument rather than a bunch of --basetgz/ --mirror/ whatnot
[14:08] <uniscript> OK mine just builds them all hacking the dch for me, etc.
[14:08] <jdong> uniscript: which can be combined with simple shell scripting to achieve your effect
[14:08] <jdong> geser: in a pbuilder type cleanroom, yes
[14:08] <uniscript> one snagglet is how do I force a rebuild of the .orig.tar.gz and .diff.gz it keeps the old one and ends up being the wrong thing built
[14:08] <jdong> geser: in a cleanroom, I can also just patch -p0 the diff.gz, replace the rules file with an empty/skeleton one
[14:08] <jdong> :)
[14:08] <uniscript> jdong: well this is my simple shell script :)
[14:08] <jdong> which will be even easier than trying to hook a pre-build command
[14:08] <frafu> persia, geser, RainCT: many thanks for your help and clarifications about the build failure and schemas issue. :)
[14:09] <jdong> uniscript: whatever script helps you, you should make. it's none of our business what you hack up unless it starts producing faulty build resuilts ;-)
[14:10] <jdong> uniscript: I have much more questionable scripts lying around :D
[14:10] <uniscript> OK but where are all these cool scripts hanging out. I can't be the first to do this.
[14:11] <jdong> uniscript: you might be
[14:11] <uniscript> please no :)
[14:11] <jdong> uniscript: prevu does some of the similar stuff (mangling debian/changelog, managing multipe pbuilders)
[14:11] <jdong> uniscript: but it's too specialized for your needs, probably
[14:11] <uniscript> worth a try
[14:12] <jdong> uniscript: yeah it's all in python and should be easy to mangle for your personal needs. I've tried to keep the code clean and organized
[14:12] <jdong> uniscript: packages are in Ubuntu, bzr branches on product prevu in LP
[14:12] <uniscript> installing package now
[14:12] <uniscript> or is the gutsy one very old?
[14:13] <uniscript> hmm docs?
[14:13] <uniscript> 1:0.4.3
[14:15] <slytherin> persia, Can I specify version in control file like this - >= 1.1-5ubuntu1 ?
[14:17] <persia> slytherin: I think so.  Try and see?  Also, asking the channel generally often results in a faster response.
[14:18] <slytherin> persia, Ok. One more question specifically for you. :-) Do you think I should try libdb4.6-java (main) as build dep for lucene2 instead of ibdb4.6-java. Or do you prefer minimal changes
[14:19] <uniscript> is there a dpkg-buildpackage option or something that says: don't use a source package you may see lurking above me, make a new one and build that?
[14:19] <persia> slytherin: I don't understand your question.  Maybe there was a missing letter?
[14:20] <slytherin> persia, Should try replacing build dep libdb4.5-java (universe) with libdb4.6-java (main) for lucene2. Or as of now you prefer minimal changes?
[14:20] <slytherin> s/try/ i try
[14:20] <ScottK> Generically we want to push everything to 4.6.  Dunno about this case.
[14:21] <persia> slytherin: I'd test it.  Getting rid of everything but db4.2 and db4.6 would be nice.  Getting rid of db4.2 is hard :(
[14:21] <slytherin> Ok. I will try.
[14:21] <ScottK> FYI we have a libdb4.6-ruby now that appears to work fine for anything that doesn't need db transaction support.
[14:21] <ScottK> Actually it's bin new.
[14:26] <bddebian> Heya gang
[14:27] <HighNo> hi there -  while running lintian on my package I get "bad-distribution-in-changes-file feisty" so what exactly should I put as distribution here?
[14:27] <bddebian> Should be hardy in debian/changelog now
[14:27] <HighNo> ok, thanks
[14:28] <geser> Hi bddebian
[14:28] <norsetto> heya bddebian
[14:28] <persia> hey bddebian
[14:28] <sistpoty|work> hi bddebian
[14:28] <bddebian> Hi geser, norsetto, persia
[14:28] <bddebian> and sistpoty|work :-)
[14:30] <dcordero> hi
[14:30] <bddebian> Hello dcordero
[14:31] <xivulon> hi all, I am wubi-installer.org author
[14:31] <xivulon> I have a request about nsis package which is needed to build wubi
[14:32] <xivulon> At the moment I am using nsis-2.34 via wine, but it would be better to use the nsis native package
[14:33] <xivulon> Except that nsis is using 2.33 atm
[14:33] <xivulon> can some good soul look at it?
[14:34] <xivulon> I'd do it myself except that I am not very experienced in packaging and it's a bit too late in the cycle (wubi should ship with the Live CD) for experiments
[14:35] <xivulon> Gentoo does have a 2.34 package if that can help (amd64 would be much appreciated)
[14:36] <ScottK> Debian is still on 2.33 and the Debian maintainer is generally pretty active.  I wonder if there is a reason he's holding back.
[14:37] <ScottK> You might ask him (Paul Wise <pabs@debian.org>) if he's any plans to update soon.  No point in us duplicating the work if he's got it in hand.
[14:38] <xivulon> Gentoo 2.34 is not marked as stable yet
[14:38] <xivulon> so probably yes
[14:38] <xivulon> thanks ScottK will contact Paul
[14:39] <xivulon> do I need to file a bug report anyway?
[14:39] <slytherin> xivulon, can you not try using 2.33? I mean what are the changes in 2.34 which need for your work?
[14:40] <xivulon> I have change a few bits and pieces to use nsdialog as opposed to installoptions, which provides a much saner environment for custom forms
[14:40] <xivulon> I'd have to roll back all the changes
[14:41] <HighNo> Hm, is it impossible to create a package for hardy with feisty's tools? I now get the same error from lintian "E: blueproximity_1.2.2_i386.changes: bad-distribution-in-changes-file hardy" but additionally I get errors from dch: "dch warning: Recognised distributions are:
[14:41] <HighNo> {warty,hoary,breezy,dapper,edgy,feisty}{,-updates,-security,-proposed} and
[14:41] <HighNo> UNRELEASED."
[14:42] <jpatrick> HighNo: feisty didn't know hardy
[14:42] <slytherin> HighNo, use pbuilder and create a chroot for hardy
[14:42] <linux__alien> Hi i ve joined a team in launchpad.net and ve been eagerly waiting to start the tasks. the team had the mentoring option available but i am not able to contact the person who leads the team
[14:42] <jpatrick> norsetto: you around mate?^^
[14:42] <linux__alien> can someone here help me how to go about now from this step. I am very much interested in contributing to Ubuntu
[14:42] <norsetto> jpatrick: certainly :-)
[14:42] <HighNo> slytherin: I should use pbuilder with an python only package? I will check that anyway
[14:44] <slytherin> HighNo, pbuilder helps you create chroot. So you can build for distribution other than your system
[14:44] <HighNo> slytherin: ok, thanks - I didn't know that.
[14:45] <HighNo> slytherin: what size will that chroot env be for hardy? my disk space is very low at the moment
[14:46] <slytherin> HighNo, the basic is about 75 MB. Depending on the build dependency of your package additional packages will be installed in chroot
[14:46] <frafu> persia or anybody else: https://edge.launchpad.net/ubuntu/hardy/+builds?build_text=libpanel-applet2-dev&build_state=all finds no matching build; but the dependency was used to build mousetweaks for other architectures. Is this not a contradiction: the libpanel package is not listed in the hardy builds, but has been used as a dependency!?
[14:47] <persia> frafu: Try searching from https://launchpad.net/ubuntu/+builds  Maybe it was built in gutsy, or before.
[14:50] <frafu> persia: it does not find it either. Could it be a "minus" vs "hyphen" problem?
[14:51] <superm1> ugh.  someone uploaded another mplayer without updating bzr.
[14:51] <norsetto> stevenk: was looking at merging bacula, and noticed gnome-session was added by you as a recommend to bacula-traymonitor. Do you believe this is still still needed?
[14:52] <persia> frafu: No idea.  Try #launchpad
[14:52] <frafu> persia: ok
[14:54] <linux__alien> could some one here tell me is there any mailing list to contact the mentors in launchpad ?
[14:54] <linux__alien> My prospective mentor has not given contact details :)
[14:55] <persia> linux__alien: How was your prospective mentor assigned?
[14:56] <linux__alien> persia, i found a topic which was very interesting and i clicked on the join button of the team and the person approved me thats it
[14:56] <linux__alien> and ve been eager to contact the person and start working but i am not able to unfortunately :(
[14:56] <persia> linux__alien: Which team?
[14:57] <linux__alien> ya sure will give you the link https://launchpad.net/~gnome-uis
[14:57] <linux__alien> GTK interfaces for Commandline Tools
[14:57] <uniscript> highno: but it does continue despite the warnings
[14:57] <linux__alien> thats the team persia
[14:58] <persia> linux__alien: That team needs a wiki page, but https://launchpad.net/~seif might be a good person to ask how to get more involved.
[14:58]  * uniscript responds to old post sorry
[14:58] <linux__alien> true but unable to meet the person :(
[14:59] <linux__alien> i dont have the email ID too ;(
[14:59] <linux__alien> :(
[15:01] <geser> frafu: buildds work on source packages so check for source package and not the binary one
[15:01] <shibata> If I create file which is same name of package in debian/ directory, but when run debuild, its file is deleted (because its name is special for build?). How do I escape its problem? Can I create which with other name and rename when dh_install in debian/*.install file?
[15:02] <geser> frafu: https://edge.launchpad.net/ubuntu/+source/gnome-panel/1:2.21.90-0ubuntu1/+build/501097
[15:04] <persia> shibata: That only happens when you use CDBS.  dh_install cannot rename files.  Some people use a debian/contrib/ directory to work around it.
[15:06] <persia> linux__alien: Hrm.  If they don't provide an email address, and you can't find them on IRC, and they haven't uploaded any packages (from which you could pull the email address), it's tricky.  You might try asking if anyone in #ubuntu-desktop can point you at something that needs doing.
[15:07] <shibata> persia: It happens in kita2, I use debian/contrib.  Thank you.
[15:08] <norsetto> stevenk: reason for asking is that now bacula-traymonitor suggests kde|gnome-desktop-environment and gnome-session is a dep of gnome-core (which is a dep of gnome-desktop-environment)
[15:11] <frafu> geser: how did you get that link? Is there a search page?
[15:17] <geser> frafu: first find out which source package is it (here gnome-panel), then to go https://edge.launchpad.net/ubuntu/+source/gnome-panel, click on "hardy" (in the version history), then "Show builds"
[15:18] <frafu> geser: anyway;If I get it right, there is nevertheless something wrong going on as I can see the libpanel-... package with synaptic in my hardy i386 installation, but it does not show up among the built packages
[15:18] <frafu> geser: thanks for the how to
[15:19] <geser> frafu: https://edge.launchpad.net/ubuntu/hardy/+source/gnome-panel lists the successfully build "Binary Packages" with the arch
[15:19] <geser> frafu: from looking at the build-log for gnome-panel in hppa it looks like gnome is there a mess currently
[15:23] <frafu> geser: am I getting something wrong? libpanel-applet2-dev shows up in synaptic in my ubuntu hardy installation; consequently it has been successfully built for the i386 architecture. Correct?
[15:24] <frafu> Consequently it should also show up here: https://edge.launchpad.net/ubuntu/hardy/+builds?build_text=libpanel-applet2-dev&build_state=all
[15:25] <frafu> or am I getting something wrong?
[15:26] <persia> frafu: apt-cache showsrc libpanel-applet2-dev ,ay be usefully instructive
[15:26] <persia> s/,ay/may/
[15:27] <Lutin> geser: could you have a look at the binutils-avr merge ? the debian/ubuntu diff seems ... kind of weird
[15:28] <geser> frafu: only source packages have build records, and libpanel-applet2-dev is a binary one
[15:28] <norsetto> whats up jpatrick?
[15:28] <_MMA_> ScottK: If you wanna tackle another bite-sized bug like the Scribus one here ya go. Bug 189598 Thanx for the Scribus one BTW.
[15:28] <ubotu> Launchpad bug 189598 in mixxx "Mixxx is missing icon (Hardy)" [Undecided,New] https://launchpad.net/bugs/189598
[15:29] <dcordero> i have been fixing easy bug, like Depends problem, .desktop missing. But when i see a Bug like Bug #189553 i dont know how can i fix that, and it's marked as bitesize :/
[15:29] <ubotu> Launchpad bug 189553 in jabref "crash on startup" [Undecided,New] https://launchpad.net/bugs/189553
[15:29] <jpatrick> norsetto: I was pointing to: "< linux__alien> Hi i ve joined a team in launchpad.net and ve been eagerly waiting to start the tasks. the team had the mentoring option available but i am not able to contact the person who leads the team"
[15:30] <geser> Lutin: ah that one :) binutils-avr is a native package. I had to change a symlink in the tar.gz to point to the right binutils.tar.gz from binutils-source
[15:30] <linux__alien> jpatrick, i am here yes whats it :)
[15:30] <geser> Lutin: and this change doesn't show up in the patch
[15:30] <Lutin> geser: ahh ok :). thanks for the explanation
[15:30] <norsetto> jpatrick: ah, thanks for pointing that out, I completely missed that
[15:31] <norsetto> linux_alien: so, what team are you talking about?
[15:31] <jpatrick> linux__alien: norsetto's the contact for the motu-mentoring team :)
[15:31] <norsetto> jpatrick: yeah, but I'm not sure thats what he is looking for ;-)
[15:32] <jpatrick> norsetto: me neither, but just in case ;-)
[15:33] <linux__alien> hey thanks jpatrick let me become an Ubuntero . Am almost done in that process just one more step to finish and be right back here :)
[15:33] <linux__alien> one sec
[15:33] <linux__alien> :)
[15:40] <linux__alien> jpatrick, i am stuck in the last step of becoming an Ubuntero I ve got the email from launchpad and ve installed the FireGPG also and now selected the Big Paragraph (key) and selected decrypt but FireGPG says that is not a valid PGP key
[15:44] <jussi01> when running desktop-file-validate im getting the following error: warning: key "Encoding" in group "Desktop Entry" is deprecated
[15:44] <jussi01> how do I fix?
[15:46] <jussi01> is it simply to remove it?
[15:47] <bddebian> jussi01: Yes, remove it from the desktop file
[15:48] <jussi01> bddebian: thanks
[15:48] <frafu> geser, persia: thanks; now it makes sense.  :)   (my first concrete example of a binary package that has a different name as the source; probably because the source produces more than one binary. )
[15:49] <frafu> persia: you told me about the mousetweaks building failure due to a dependency to watch the status of libpanel-applet2-dev on hppa, and when that is looking healthy, ask for a give-back. How do I ask for a give back?
[15:50] <frafu> persia: should I ask for it on #launchpad It?
[15:51] <_MMA_> frafu: persia told me 5 mins or so ago he was going to bed. Maybe you'll get lucky and he's lurking.
[15:54] <frafu> Maybe somebody else knows it: how can I ask for a give back of a package with a build failure due to a dependency?
[15:54] <jussi01> could someone remind me of the command for extracting a package from a .dsc?
[15:54] <pochu> frafu: you can ask in #ubuntu-devel, an archive admin will give it back.
[15:54] <jussi01> nm, got it
[15:55] <Hobbsee> frafu: ask a buildd admin in #ubuntu-devel
[15:55] <Hobbsee> frafu: would be helpful to always mention which package, though
[15:56] <frafu> pochu, Hobbsee: thanjks
[15:59] <mathiaz> zul: so you were able to reproduce the mysql upgrade failure and using replaces+conflicts fixed the problem ?
[15:59] <zul> yes
[16:00] <jussi01> once ive added a patch to a bug, I then subscribe u-u-s?
[16:01] <mathiaz> zul: seems like we're good to go for another upload
[16:02] <zul> mathiaz: okies will upload :)
[16:03] <linux__alien> norsetto, i ve become a Ubuntero
[16:03] <linux__alien> norsetto, i am ready for the tasks :)
[16:04] <joejaxx> what is the format for closing LP bugs through changelog entries again?
[16:04] <joejaxx> * file
[16:04] <joejaxx>    - TExt
[16:04] <norsetto> linux__alien: good, what is it you would like to do?
[16:04] <joejaxx>    (LP: #NUMBER) ?
[16:04] <norsetto> joejaxx: LP: #xxxxxx
[16:04] <joejaxx> norsetto: anywhere?
[16:05] <norsetto> joejaxx: yes (but a logical place would help ;-))
[16:05] <joejaxx> norsetto: ;)
[16:06] <linux__alien> norsetto, some bug fixing to start with simple ones and then move to development :)
[16:06] <linux__alien> norsetto, i ve contributed to couple of open source projects in the past
[16:06] <zul> mathiaz: uploaded
[16:07] <mathiaz> zul: great ! thks.
[16:07]  * jussi01 is impatient... 
[16:07] <linux__alien> norsetto, i ve only one computer ( a laptop which runs Ubuntu 7.10) i can download some packages and fix and test those packages separately thats what i am exactly looking for
[16:07] <norsetto> linux__alien: it would be good if you start looking at some bugs then, concentrate on the ones in universe
[16:07] <linux__alien> for example if there is gonna be a bug in a text editor download that text editor source, fix it , compile it and test it and submit it
[16:08] <linux__alien> norsetto, before i start i want to be in constant touch so that i would go in the right direction as this is a huge project i dont want to go in an other direction so can you take me in your team if you can and i can be in contact with you through email and of course would log in here too
[16:08] <linux__alien> norsetto, is that fine with you ?
[16:09] <norsetto> linux__alien: well, I would suggest to start with something simple, to get your hand on the tools and processes, or you have them already under control?
[16:09] <linux__alien> no norsetto i dont have them under the control so can you assign me the simplest ones so that i can get used to it
[16:10] <norsetto> linux__alien: ok, perhaps it would be better to start reading some docs then, before you actually try to fix a bug?
[16:10] <linux__alien> i can get used to the processes and tools as you say i dont even know what would be the easiest and toughest so it would be really good if you could mentor me :)
[16:10] <slytherin> Can someone paste last attachment of bug 185917 in pastebin? I am getting timeout when trying to view it.
[16:10] <ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
[16:11] <linux__alien> norsetto, sure i could do it parallely and if you assign me a smallest thing i can do this and parallely work on it once i feel i am comfortable. what do you say ?
[16:11] <linux__alien> do point me to the docs as well
[16:11] <norsetto> linux__alien: you should really read this page first: https://wiki.ubuntu.com/MOTU/GettingStarted
[16:12] <norsetto> linux__alien: all the links should be there to start you in the right direction
[16:12] <linux__alien> ok sure will do that then ?
[16:12] <norsetto> linux__alien: in the packaging guide there is an example that you should follow
[16:13] <linux__alien> ok !!! will try that too
[16:13] <linux__alien> i ll write a small software and package it too a Hello world and try it out for sure :)
[16:14] <linux__alien> norsetto, one small thing if you dont mind do you ? :)
[16:14] <shibata> persia, RainCT : I updated kita2: http://revu.tauware.de/details.py?package=kita2
[16:14] <norsetto> linux__alien: of course I don't, what is it?
[16:15] <linux__alien> just wanted to be in touch with you as i would like to take you as my mentor so i want to know how to contact you apart from IRC. i really like to know that
[16:15] <linux__alien> norsetto, so that i could ask you doubts then and there and tell you my progress too
[16:15] <norsetto> linux__alien: I'm pretty busy nowadays, I can't get really any more pupils right now
[16:15] <linux__alien> me alone :)
[16:15] <norsetto> linux__alien: I can help you with your first bug, thats no problem
[16:16] <norsetto> linux__alien: everybody here can help you, just ask
[16:16] <linux__alien> that would be the biggest task for me :) true hence i joined the launchpad but didnt get any updates :(
[16:16] <linux__alien> thats why i became totally lost
[16:16]  * LucidFox removes "linux" from the list of words that ping him :)
[16:17] <norsetto> linux__alien: or ask in ubuntu-motu or ubuntu-motu-mentors (you should subscribe to these m.l. if you haven't done so already)
[16:17] <linux__alien> i ve not done it what does MOTU stand for ?
[16:17] <slytherin> Can someone paste last attachment of bug 185917 in pastebin? I am getting timeout when trying to view it. And please paste to pastebin.com
[16:17] <ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
[16:18] <LucidFox> linux__alien> Masters of the Universe
[16:18] <LucidFox> named after the "universe" repository in Ubuntu
[16:18] <linux__alien> what does mean
[16:18] <linux__alien> what does that mean
[16:18] <LucidFox> it means Ubuntu developers who contribute to the universe and multiverse repositories
[16:18] <dcordero> Bug #189553
[16:18] <ubotu> Launchpad bug 189553 in jabref "crash on startup" [Undecided,New] https://launchpad.net/bugs/189553
[16:18] <linux__alien> Oh Ok
[16:18] <LucidFox> (as opposed to core developers, who contribute to main and restricted)
[16:19] <linux__alien> Universe and Multiverse contains free as well non-free softwares?
[16:20] <slytherin> LucidFox: Need a favour
[16:20] <mok0> ScottK: piinnnggg!
[16:21] <LucidFox> linux__alien> universe contains free (as in freedom software) whose redistribution is not impended
[16:21] <mok0> linux__alien: Universe contains only free software
[16:21] <mok0> heh
[16:21] <LucidFox> while multiverse contains non-free software, as well as free software with impended (for example, by patents) redistribution
[16:21] <linux__alien> norsetto, so ok i ll start reading it and whats my first bug :)
[16:21] <linux__alien> ?
[16:21] <LucidFox> slytherin> How can I help?
[16:21] <linux__alien> mok0, Multiverse?
[16:22] <slytherin> LucidFox: Can you please paste last attachment of bug 185917 in pastebin? I am getting timeout when trying to view it. And please paste to pastebin.com
[16:22] <ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
[16:23] <mok0> linux__alien: see ^^^
[16:23] <norsetto> linux__alien: once you have gone through the basics, we will look at some bugs
[16:24] <linux__alien> norsetto, ok in that case give me a day's time i ll read through the MOTU/Getting Started link and then the packaging guide and get back here as soon as possible
[16:24] <LucidFox> slytherin> http://paste.ubuntu.com/4260/
[16:24] <norsetto> linux__alien: ok, if I'm not here ask and somebody will help you
[16:25] <slytherin> LucidFox: thanks
[16:25] <linux__alien> norsetto, sure will do that i ll subscribe to MOTU and MOTU-mentors mailing list
[16:25] <LucidFox> linux__alien> Indeed. I, for example, will always be glad to help you on this channel.
[16:25] <linux__alien> MOTU-mentors is for mentors or for people to be mentored?
[16:26] <norsetto> linux__alien: both
[16:26] <LucidFox> speaking of that control file, isn't build-depending on -jre pointless because -jdk pulls it?
[16:27] <linux__alien> thanks a lot LucidFox norsetto
[16:27] <norsetto> linux__alien: np
[16:33] <LucidFox> Could someone please look at bug #187576 and sponsor the upload? I'm going to submit the package to Debian, but I'd like to have the entire Ubuntu history in the changelog, like I did for smplayer itself
[16:33] <ubotu> Launchpad bug 187576 in smplayer-themes "Upgrade to smplayer-themes 0.1.15" [Wishlist,Confirmed] https://launchpad.net/bugs/187576
[16:34] <LucidFox> (and RainCT, if you're here, I uploaded just the diff.gz - so you can use it rather than the interdiff)
[16:35] <slytherin> persia: geser: FYI ... I have added the debdiff to bug 189602. I will be glad if you can make sure once more that lucene2 builds in pbuilder with this fix. :-)
[16:35] <ubotu> Launchpad bug 189602 in lucene2 "Use local DTD to fix build failure on buildd" [Undecided,Confirmed] https://launchpad.net/bugs/189602
[16:39] <LucidFox> Then go through slytherin's bug first. It's more important. :)
[16:41] <slytherin> LucidFox: I would rather have it handled by persia or geser since they know all the context. I hope you don't mind. :-)
[16:41] <mok0> Does anyone read & understand russian here?
[16:41] <LucidFox> я
[16:41] <LucidFox> mok0> I'm a Russian
[16:42] <mok0> LucidFox: Cool! Can you help me with a translation? Please look at bug  189554
[16:42] <ubotu> Launchpad bug 189554 in courier "update from gutsy to hurdy fails on courier-mta" [Undecided,New] https://launchpad.net/bugs/189554
[16:42] <mok0> LucidFox: Can you tell me what the error message is?
[16:43] <LucidFox> mok0> replied in the bug
[16:43] <LucidFox> there wasn't much to translate anyway :)
[16:43] <mok0> LucidFox: super!
[16:43] <mok0> LucidFox: I am trying to understand what the problem with this bug report is
[16:44] <mok0> LucidFox: Heh! :-)
[16:44] <mok0> Not much help there :-)
[16:44] <LucidFox> I've asked for additional information
[16:45] <mok0> LucidFox: thanks
[16:46] <mok0> LucidFox: perhaps igor has a hard time with english
[16:46] <neuroStuMIT> Hi, sorry to interrupt but I have a question: I am trying to build a deb package but I keep getting the following error when I run
[16:46] <neuroStuMIT> $dpkg-buildpackage -rfakeroot
[16:46] <neuroStuMIT> dpkg-buildpackage: unable to determine source package is
[16:47] <mok0> neuroStuMIT:  are you in the right directory?
[16:47] <neuroStuMIT> dpkg-parsechangelog: error: cannot open debian/changelog to find format: No such file or directory
[16:47] <neuroStuMIT> dpkg-buildpackage: unable to determine source package is
[16:47] <neuroStuMIT> yes I am one directory down from the src
[16:48] <mok0> neuroStuMIT:  you need to be where the debian dir is
[16:48] <neuroStuMIT> ok so I tried it in /package/debian/ and I got the same error
[16:49] <neuroStuMIT> and in ~/package/
[16:49] <mok0> you have to be in package/
[16:49] <geser> does debian/changelog exist?
[16:49] <neuroStuMIT> ok I just got it sorry
[16:49] <neuroStuMIT> thanks
[16:49] <neuroStuMIT> yes it does
[16:50] <mok0> if you get something when you say ls debian/changelog you are in the right place
[16:50] <LucidFox> mok0> in this case, I could translate in both directions - no later than yesterday I did that on IRC, synchronously :)
[16:50] <mok0> LucidFox: nice!
[16:54] <neuroStuMIT> what does this mean
[16:54] <neuroStuMIT> dpkg-genchanges: error: badly formed line in files list file, line 1
[16:55] <bobbo> Can someone give me a bit of help with Bug #188070? I need to know what version number the fix should have
[16:55] <ubotu> Launchpad bug 188070 in showfsck "No need to be bash-specific" [Undecided,Confirmed] https://launchpad.net/bugs/188070
[16:57] <geser> bobbo: the next version would be 1.4ubuntu2
[16:57] <bobbo> Ok thanks
[17:00] <RainCT> LucidFox: heh. still need someone to upload #187576?
[17:00] <LucidFox> RainCT> yes
[17:01] <LucidFox> and TheMuso told me that interdiffs are no longer needed - the diff.gz is sufficient
[17:03] <RainCT> LucidFox: right, we decided against interdiff on the last MOTU meeting
[17:04] <LucidFox> Awesome.
[17:06] <slytherin> geser: I hope you saw my last message. :-)
[17:09] <geser> slytherin: yes, I subscribed myself to that bug at will test-build it tomorrow (so the new w3c-dtd-xhtml is available on the mirror I use) and will sponsor it afterwards
[17:10] <slytherin> geser: Thanks. :-) w3c-dtd-xhtml has already built successfully. Should be available on mirrors in few hours I guess
[17:10] <geser> slytherin: I didn't get out how often and when the german mirror gets updated. It looks like once daily
[17:11] <slytherin> geser: Anyway time for me to go home. See you tomorrow. :-)
[17:17] <geser> LucidFox: re bug #189470: are the packages "sunbird" and "iceowl"? so could we drop "iceowl"?
[17:17] <ubotu> Launchpad bug 189470 in iceowl "Restore Mozilla branding and blacklist iceowl from autosync" [Wishlist,New] https://launchpad.net/bugs/189470
[17:19] <LucidFox> geser> There's no "sunbird" package
[17:19] <LucidFox> I'm proposing repackaging iceowl as sunbird
[17:21] <geser> !info sunbird hardy
[17:21] <ubotu> sunbird (source: lightning-sunbird): Sunbird stand-alone Calendar. In component universe, is optional. Version 0.7+nobinonly-0ubuntu2 (hardy), package size 7792 kB, installed size 23212 kB
[17:21] <geser> hardy has sunbird
[17:21] <ryanakca> Hmm... favorite C++ IDE? I'm using vim at the moment...
[17:25] <ryanakca> oops, wrong channel :)
[17:25]  * ryanakca thought he was in -offtopic
[17:26] <LucidFox> geser> Then iceowl can simply be removed from the archive and blacklisted
[17:27] <RainCT> sistpoty|work: I've just read the "Copyright question" topic on debian-devel.. about your message there, I don't see that the license says anything about modifying or not modifying it, it just says that you have to leave the copyright notice on the files, you have to credit the university on programs using it and that you can't use the names of the authors for promotional use
[17:27] <sistpoty|work> RainCT: and that's the point... it doesn't allow it (and hence it's not allowed)
[17:27] <LucidFox> Original BSD license?
[17:28] <sistpoty|work> nope, modified one, but quite similar
[17:29] <RainCT> sistpoty|work: doesn't allow what?
[17:29] <RainCT> ah
[17:29] <mathiaz> zul: regarding your libxen3 diff, don't you need to replace/conflicts libxen3.1 also ?
[17:30] <sistpoty|work> RainCT: if s.th. is not explicitely allowed by a license, it's not granted (hence no license at all -> nothing allowed)
[17:30] <RainCT> sistpoty|work: okay I understand your point now, but it doesn't make sense.. if it wasn't allowed to modify it, there would be no need to say that you can't modify the copyright notice from the headers
[17:30] <mathiaz> zul: there may be some issue with upgrades from gutsy
[17:30] <LucidFox> geser> May I subscribe ubuntu-archive to the removal request directly, or do I need someone to approve it first?
[17:32] <sistpoty|work> RainCT: good point... so maybe 1) could be interpreted to allow modification (apart from...), but I guess the license isn't the very best to not be more clear on this
[17:32] <geser> LucidFox: an MOTU needs to ACK it or you wait till you are a MOTU yourself
[17:32] <LucidFox> Thanks. I'll subscribe u-u-s then.
[17:34] <LucidFox> RainCT, smplayer-themes reupload ping (in case you didn't see the one in PM)
[17:34] <RainCT> LucidFox: I'm already downloading it :)
[17:35] <LucidFox> ah, I see
[17:35] <sistpoty|work> RainCT: looking at the standard BSD license, maybe there is s.th. not quoted in the mail, which does allow modification
[17:39] <jdong> LucidFox: what do you need ack for?
[17:40] <LucidFox> bug #189470
[17:40] <ubotu> Launchpad bug 189470 in iceowl "Remove iceowl from the archive and blacklist from autosync" [Wishlist,New] https://launchpad.net/bugs/189470
[17:41] <jdong> cool
[17:41] <jdong> can't we just glob for (something_cold)(birdname)
[17:41] <jdong> :D
[17:41] <LucidFox> lol
[17:42] <joejaxx> lol
[17:42] <LucidFox> that's the one we were talking about - I also have a sync request from debian-multimedia in need of acking...
[17:42] <joejaxx> anyone here particularly fond of python packaging?
[17:42] <Amaranth> jdong: ice* except icecast?
[17:42] <geser> jdong: good that tea is not a bird :)
[17:42] <jdong> Amaranth: cast isn't a bird :)
[17:42] <LucidFox> namely, Bug #182819
[17:42] <ubotu> Launchpad bug 182819 in ubuntu "Please sync wxsvg 1.0b8.1-0.1 from debian-multimedia.org unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/182819
[17:42] <joejaxx> lol
[17:42] <Amaranth> oh, and icedtea
[17:43] <joejaxx> there are looks of ice apckages
[17:43] <joejaxx> icewm
[17:43] <Amaranth> jdong: i meant for a match on stuff we don't want :P
[17:43] <joejaxx> lol
[17:43] <Amaranth> joejaxx: ehh, that one isn't important
[17:43] <joejaxx> Amaranth: lol
[17:43] <joejaxx> yess it is :)
[17:43] <Amaranth> I have _never_ met someone who used icewm
[17:43] <joejaxx> Amaranth: you met me :)
[17:43] <joejaxx> lol
[17:44] <Amaranth> lalalalalala
[17:44] <joejaxx> :P
[17:44] <Amaranth> I can't _hear_ you
[17:44]  * Amaranth runs
[17:44] <joejaxx> rofl
[17:52] <mohbana_> hi guys i want to build something from source, what do i need to do? are there any guides available
[17:54]  * sistpoty|work heads home
[17:54] <sistpoty|work> cya
[17:55] <zul> mathiaz: point
[17:57] <RainCT> mohbana_: what is it what you want to build?
[17:59] <mohbana_> wxdownlod fast
[18:00] <RainCT> mohbana_: but you have te source for the package, or from the author's website?
[18:00] <mohbana_> yes i got it from the site
[18:00] <RainCT> mohbana_: then look if there's a README o INSTALL file or something like that where it explains how to do it
[18:14] <warp10> Hi all!
[18:14] <ScottK> _MMA_: I did the scribus one because I was working on scribus.  I don't have a generic interest in icon bugs.  Thanks.
[18:14] <ScottK> mok0: Pong
[18:14] <mok0> Hey ScottK!
[18:15] <mok0> I have  a couple of comments to your comments
[18:15] <ScottK> Welcome back to another fun day with Courier.
[18:15] <ScottK> Sure
[18:15] <mok0> ScottK: I just need to find the bug page
[18:16] <afflux> whats the difference between Depends: xyz (< 5) and Depends: xyz (<< 5)?
[18:16] <mok0> bug 188746
[18:16] <ubotu> Launchpad bug 188746 in courier "[needs-merge] courier_0.58.0.20080127-1" [Undecided,In progress] https://launchpad.net/bugs/188746
[18:17] <mok0> ScottK: about the init scripts: I think the ubuntu changes are still worthwhile.
[18:17] <mok0> ScottK: it seems the Init headers are still somewhat lacking in the debian edition
[18:17] <LucidFox> afflux: << 5 means all versions below 5, but not version 5 itself; <= 5 means all versions below 5 and version 5
[18:17] <_MMA_> ScottK: I see. np. I got mixxx handled now.
[18:18] <LucidFox> not sure about < 5, or whether it's even allowed
[18:18] <norsetto> warp10: hey warpie
[18:18] <afflux> LucidFox: okay, since it's "all versions below" what I want to have, I'll just use <<. Thanks.
[18:18] <mok0> ScottK: and he's using echo instead of the proper log_* statements
[18:19] <warp10> heya norsetto! Nice to see you around
[18:19] <norsetto> won your battle against the evil empire of microbes?
[18:20] <LucidFox> lol
[18:21] <warp10> norsetto: nope... I asked a cease-fire, but they disagree -_-
[18:21] <norsetto> warp10: nuke them
[18:22] <warp10> norsetto: that would be great... if they are in another person's body :P
[18:22] <ScottK> mok0: I agree about the log statement.
[18:22] <norsetto> warp10: ah right, its always the little details that loose me
[18:22] <warp10> norsetto: :D
[18:23] <ScottK> The lsb header part of the init I would look very closely at.
[18:23] <mok0> ScottK: Then there's your comment about ldap which I don't understand
[18:23] <ScottK> mok0: The current Ubuntu ones I did about 8 months ago when I knew less than I did now, so don't assume they're right.
[18:23] <ScottK> Look at the current package in Hardy.  It's got another revision.
[18:24]  * norsetto -> dinner
[18:24] <mok0> ScottK: there's some information about which processes should be running that is not in debian's
[18:24] <ScottK> It was a new change rebuild for LDAP transition, so that debian/changelog entry needs to get added to the merged package.
[18:24] <ScottK> mok0: Right and I don't know which is right.
[18:25] <ScottK> mok0: Does that make sense?
[18:25] <mok0> ScottK: init scripts: I will look more carefully.
[18:25] <mok0> ScottK: ldap transistion: is that in ubuntu?
[18:26] <ScottK> mok0: Yes.  slangasek did a no change rebuild last night or this morning.
[18:26] <mok0> ScottK: no change rebuild? Of the old version?
[18:27] <ScottK> Yes
[18:27] <ScottK> https://launchpad.net/ubuntu/hardy/+source/courier/0.58.0-1ubuntu2
[18:27] <mok0> ScottK: ok
[18:27] <ScottK> All you need to do for that is add his debian/changelog entry into your package and then re-diff debian/changelog
[18:27] <mok0> ScottK: so, the new version incorporates some changes that are needed for the ldap transistion?
[18:28] <mok0> ScottK: sure, I just want to understand what the changelog entry should say :-)
[18:28] <ScottK> No.  The code isn't changed, it's just built against the newer library version so it's linked to the shared libraries differently.
[18:28] <ScottK> You should grab the current Hardy package and copy/paste the one that's in there.
[18:29] <mok0> ScottK: Got it. finally.
[18:29] <mok0> :-)
[18:29] <ScottK> No problem.
[18:29] <mok0> ScottK: next, is your torque comment.
[18:29] <ScottK> Yes.
[18:30] <mok0> Have you seen my reply?
[18:30] <ScottK> No.  Just got back to my desk from a meeting
[18:30] <mok0> http://revu.ubuntuwire.com/details.py?package=torque
[18:30]  * ScottK looks
[18:31] <ScottK> mok0: Perfectly reasonable answer.  Sounds good.
[18:31] <mok0> ScottK: Great...
[18:31] <ScottK> I suspect I'll advocate it, but haven't finished reviewing  yet.
[18:31] <mok0> ScottK: but now the package has the "Needs work" icon, and I don't know what to do
[18:32] <mok0> ScottK: ok
[18:32] <ScottK> It was a bit of a suprise when I tested your watch file and it found a new version.
[18:32] <mok0> thx
[18:32] <mok0> ScottK: I understand...
[18:32] <ScottK> I wanted to get the question out there and get it answered rather than leave it sitting.
[18:33] <mok0> ScottK: good point. I guess most developers are still not on the newest version of gcc
[18:33] <ScottK> Makes sense
[18:34] <mok0> ScottK: It'd be great if you have time to review it.
[18:34] <ScottK> I'll try and work time to finish it into the next 24-48 hours.
[18:35] <mok0> ScottK: That's perfect
[18:49] <ScottK> mok0: You're planning on looking at the courier postinst bug too, right?
[18:49] <mok0> ScottK: Yeah, I got LucidFox to translate :-)
[18:50] <ScottK> Great.
[18:50] <mok0> ScottK: not that it helped much :-)
[18:50] <ScottK> Yeah.
[18:51] <mok0> It might be difficult to reproduce
[18:51] <mok0> But I will check the script carefully
[19:31] <vorian> ping warp10
[19:38]  * norsetto <- dinner
[19:46] <jdong> ScottK: ping, regarding 145805
[19:46] <jdong> ScottK: am I correct in understanding that just a no-source-change rebuild is necessary to resolve the issue?
[19:47] <ScottK> That's what I understand from reading the bug.
[19:48] <jdong> ScottK: in all their quibbling it's really not clear what on earth is actually going on
[19:48] <ScottK> Henrik set the bug to invalid when he should have said fix released and looked into SRU.  The bug filer is apparently a somehat prominent blogger and it's all downhill from there.
[19:51] <jdong> ScottK: *sigh* well I replied to the bug hoping to get a clearer description
[19:51] <jdong> ScottK: I have a feeling the response will be quick... and probably not pretty
[19:59] <dcordero> hi
[20:00] <ScottK> mok0: Did you run your .debs through the current lintian for torque?
[20:02] <chillywilly> man I hate RHEL...
[20:02] <chillywilly> up2date sucks compares to apt
[20:02] <ScottK> mok0: 6 errors, 26 warnings (some of which I can see just need over-rides), and I didn't count the info notices.
[20:03] <jdong> chillywilly: well that's why it was replaced with yum
[20:06] <warp10> vorian: pong
[20:07] <vorian> :)
[20:07] <vorian> warp10: I had the upgrade ready, I just wanted to check with you first since you assigned yourself
[20:08] <chillywilly> jdong: yea but I don't see yum available with this old RHEL4 install...
[20:09] <warp10> vorian: well, really I have been subscribed to the bug by someone else, just a mistake. I was trying to unsubscribe myself but my network just crashed :S
[20:09] <vorian> warp10: :)
[20:09] <vorian> no worries
[20:10] <vorian> That's what I wanted to check
[20:10] <warp10> vorian: great :)
[20:10] <vorian> thanks warp10 :)
[20:11] <warp10> vorian: np ;)
[20:38] <mohbana_> does anyone use adobe reader instead of the evince that comes with ubuntu?
[20:38] <ion_> Hopefully not. :-)
[20:39] <mohbana_> evince doesnt render fonts properly, when i view some documents they appear blury
[20:39] <ScottK> Does evince support data input to encrypted PDFs?
[20:39] <ScottK> kpdf does not (at least in Gutsy).
[20:45] <mok0> ScottK: It's been a while since I last compiled torque. Sorry, my bad.
[20:45] <ScottK> mok0: No problem.  It's just that you were wondering what to do next ;-)
[20:45] <mok0> ScottK: heh, I will take a look.
[20:47] <mok0> ScottK: I found a possible explanation of 189554
[20:47] <ScottK> Excellent.
[20:47] <mok0> ScottK: The script will fail if /etc/courier for some reason does not exist
[20:47] <TheMuso> ScottK: I'd poke the tech board mailing list about your application. I think its been lost in the pile somewhere.
[20:48] <ScottK> TheMuso: I agree.  I'm trying to figure a polite way to do it.  I need to probaby wait a day for that.
[20:48] <TheMuso> ScottK: right
[20:52] <Coper> ScottK: are you the same as ScottK2?
[20:52] <ScottK> Coper: Yes
[20:52] <ScottK> That's my laptop
[20:53] <Coper> You added a comment to console-freecell about using hyphen as minus sign.
[20:54] <ScottK> Yes
[20:54] <Coper> Is that a problem with my package or is it a problem with the upstream?
[20:54] <ScottK> In the man page source you need to properly escape the hyphen.  It's just \- instead of -
[20:55] <ScottK> I don't recall if the man page is upstream or in debian/
[20:56] <Coper> hmm, so do I just add a patch in debian/patch or just change in the man source file?
[20:58] <ScottK> You should patch it.  Is the upstream active for this game?
[21:00] <Coper> The doc/freecell.6 exist in the tar.gz file that I has build my package from.
[21:01] <ScottK> Yes.  So it should be patched.  If your upstream is active, you might ask them to fix it and re-rekease,
[21:01] <ScottK> If you had that committment, I'd be willing to advocate now with you just modifying the upstream  source directly.
[21:03] <Coper> okej, so I just have to change all - to \- in all places in tha man source file and rebuild my dsc file
[21:05] <ScottK2> Coper: If you get upstream to agree to fix it.  Otherwise it's add dpatch and patch it.
[21:09] <HighNo> I need help (hopefully the last time) with building my package for REVU. It seems that every howto states I only should "dpkg-buildpackage -S -sa -rfakeroot" and upload the _source.changes to REVU. But I don't get it - it only is a signed part of the changelog. How can anybody rebuild my package with just that information?
[21:11] <smarter> HighNo: when you do "dput revu foo_source.changes" foo.orig.tar.gz, foo.dsc and foo.diff.gz are also uploaded
[21:11] <HighNo> ok, that makes sense
[21:11] <smarter> the .changes file is just here to list them
[21:11] <smarter> and to check the md5 sum
[21:11] <HighNo> so that's why they are in there...
[21:12] <smarter> and instead of dpkg-buildpackage ... you can do "debuild -S -sa"
[21:13] <HighNo> can or must do?
[21:14] <smarter> I'm not an expert but afaik it's the same
[21:14] <smarter> except it's shorter :)
[21:16] <HighNo> :-)
[21:17] <HighNo> grrrrrr. I start thinking I am stupid. I just can't build my package for hardy...
[21:18] <HighNo> why on earth do I get this error from dput/lintian: E: blueproximity_1.2.2_source.changes: bad-distribution-in-changes-file hardy
[21:19] <smarter> HighNo: are you using gutsy?
[21:19] <HighNo> I am using feisty but I have setup a bpuilder environment with hardy bootstrap
[21:19] <smarter> Does this error prevent you from uploading your package?
[21:20] <HighNo> yes
[21:20] <smarter> what's the revision number of your package?
[21:20] <smarter> should be 1.2.2-0ubuntu1
[21:21] <HighNo> ok, so where do I have to put that? in the changelog? so I have to adapt the dch command?
[21:21] <smarter> yes, it's in debian/changelog
[21:21] <ScottK2> HighNo: Just edit the version number in your debian/changelog entry
[21:23] <HighNo> ok, another question then - does the debian changelog file reflect the overall changes that the upstream package made or does it reflect the changes I have made to the upstrem package to get it running with ubuntu?
[21:23] <smarter> HighNo: Changes you made
[21:24] <smarter> usually, in the initial version of the package "  * Initial release (LP: #XXXXXXXX)" is enough
[21:24] <HighNo> hm, so the real changes/advances of a new version don't make it into this file but some hidden changelog anywhere in the package's docs?
[21:25] <smarter> usually, the changelog is automatically(except if the changelog file has a weird name) installed in /usr/share/doc/name-of-your-package/changelog.gz
[21:25] <Coper> Do I have to add patch somewhere in my rules file to patch my package?
[21:26] <smarter> HighNo: you should read https://wiki.ubuntu.com/PackagingGuide/Complete
[21:26] <smarter> Coper: patch system: https://wiki.ubuntu.com/PackagingGuide/Complete#head-21ed4ac3719256a0ce4c5f563206591eb5448329
[21:27] <HighNo> smarter: I like the idea because I am also the author of the upstream package and did not like creating a doubled changelog. I guess my debian changelog is never filled with anything but plain releases then...
[21:27] <smarter> that's not a problem
[21:28] <HighNo> smarter: I did read so much but probably too much and couldn't focus on the right things
[21:28] <Coper> smarter: yes I'm reading following example one and added the patch: patch-stamp to the rules file but don't I have to add anything more to my rules file the in that page?
[21:29] <smarter> Coper: if you're using CDBS you just need to add "include /usr/share/cdbs/1/rules/simple-patchsys.mk" and no stamp things
[21:31] <smarter> HighNo: add this to your debian/rules: DEB_INSTALL_CHANGELOGS_ALL := ChangeLog
[21:31] <smarter> (if your changelog file is named ChangeLog)
[21:32] <Coper> smarter: okey, but I don't use CDBS but only debhelper.
[21:32] <smarter> Coper: I don't know how to proceed with pure debhelper, sorry
[21:33] <Coper> okey, I think that I rewrite my package with cdbs then.
[21:34] <smarter> that will be easier I think :)
[21:47] <geser> Coper: which patch system do you want to use?
[21:51]  * jdong should try cdbs one of these days
[21:51] <jdong> always been on my todo list
[21:51] <HighNo> smarter: thanks, I will try
[21:51] <ion_> It’s usually nice. :-)
[21:51] <jpatrick> jdong: you don't know what you're missing, mate
[21:52] <jdong> jpatrick: that's what people have been telling me :)
[21:52] <pochu> What's the way to proceed if I uploaded a package to the archive instead of to REVU? The package is intended to go to the archive but I wanted to upload it to REVU so it got a review first...
[21:52] <jdong> pochu: probably poke an archive admin to nix it
[21:52] <pochu> At least the policy allows MOTUs to upload packages on their own... :-)
[21:56] <TheMuso> jdong: For the cases where cdbs can be used, it is VERY good.
[21:57] <jdong> TheMuso: the cdbs propaganda appears very compelling :)
[21:57] <TheMuso> jdong: If the package usese configure/make etc, its golden.
[21:57] <TheMuso> uses
[21:58] <TheMuso> Either that, or packages using python-distutils.
[21:58] <joejaxx> recommends are *only* installed by default for metapackages?
[21:58] <joejaxx> as that is what it looks like in apt.conf.d
[21:58] <TheMuso> And sure, other cases can be made to work, but they require a little more knowledge of cdbs.
[21:59] <soren> joejaxx: Right.
[21:59] <joejaxx> soren: ok great just wanted to clarify :D
[21:59] <soren> joejaxx: And only for metapackages in main.
[21:59] <soren> joejaxx: iirc.
[21:59] <joejaxx> soren: it looks like the other sections are there as well
[22:00] <soren> joejaxx: Oh, so they are.
[22:00] <joejaxx> :D
[22:00] <soren> joejaxx: I'm living in the past, clearly.
[22:01] <joejaxx> soren: hey atleast you had a definite answer for me :D
[22:01] <joejaxx> soren: i just wanted to confirm :D thanks :D
[22:01] <soren> joejaxx: np :)
[22:01] <soren> joejaxx: I'm full of definite answers. Some of them are even correct. It's pretty cool.
[22:02] <joejaxx> soren: lol :P
[22:02] <pochu> Anyone can have a look and tell me the package is nice? :) http://revu.ubuntuwire.com/details.py?package=emesene
[22:02] <mok0> ScottK: New courier patch in LP
[22:04] <gilir> hi
[22:07] <DRebellion> Would somebody mind sparing a moment to review my first (=D) package? http://revu.tauware.de/details.py?package=monkeystudio
[22:12] <HighNo> whooohooo, thanks to all. My first package is finally upped at revu. When/where can I see it on the webpage? It's called 'blueproximity'
[22:12] <saivann> Is there someone from the ubuntu sponsors for universe team that can take a look at bug 181417 ? Actual libofx package in ubuntu contains non free files, that can be fixed by merging the package from debian which is the new fixed upstream release
[22:12] <ubotu> Launchpad bug 181417 in libofx "Please merge 0.9.0 from debian unstable" [High,New] https://launchpad.net/bugs/181417
[22:15] <crimsun> saivann: generally sponsors approve and upload tested source packages (i.e., attached debdiffs)
[22:15] <crimsun> saivann: namely, the debdiff should be attached already when requesting a sponsor.
[22:16] <saivann> crimsun : Ok, I'll do that right now then
[22:17] <RainCT> persia: does your advocation for kita2 still apply?
[22:21] <ScottK> mok0: Thanks.
[22:23] <mok0> DRebellion: I put some comments on revu. Didn't try to build though
[22:24] <DRebellion> mok0: thanks, I'm I'll take a look (it does build :P)
[22:25] <ScottK> DRebellion: Did you run lintian on the .deb(s)?
[22:27] <DRebellion> :/ that I forgot. I'll have to work on it tomorrow now
[22:28] <RainCT> good night
[22:29] <norsetto> pochu: there is a little problem with uscan due to the funny version numbering upstream is using
[22:35] <HighNo> what steps are necessary to make an uploaded file (dput to revu) appear on the website? I did not get any error message but it is not popping up since almost 30 mins now. the name is blueproximity
[22:36] <ember> can someone have a look/review "deskscribe" http://revu.tauware.de/details.py?upid=995
[22:37] <HighNo> Package and changes are signed and lintian is happy too.
[22:38] <TheMuso> HighNo: Have you followed all the steps to get going with revu, including joining the appropriate launchpad team? I can't think of its name right now.
[22:38] <vorian> https://launchpad.net/~ubuntu-universe-contributors
[22:39] <HighNo> TheMuso: yes, I have joined that group yesterday and also uploaded and registered my gpgkey
[22:39] <TheMuso> vorian: Thanks.
[22:39] <vorian> no problemo :)
[22:40] <TheMuso> Right. I am guessing the keyring needs to be synced.
[22:40] <TheMuso> And, I can't do that unfortunately.
[22:41] <HighNo> TheMuso: that can be true, I have registered two keys but the second one is the one I used and it was registered today...
[22:42] <HighNo> TheMuso: will my upload be recognized after syncing the keyring or do I have to upload again?
[22:43] <TheMuso> HighNo: I am not sure.
[22:43] <TheMuso> Ok. Looks like I can sync.
[22:44] <HighNo> TheMuso: please tell me when I should try to upload again
[22:44] <TheMuso> or not
[22:45] <HighNo> :-/
[22:45] <TheMuso> no I can't sync it seems
[22:46] <HighNo> But I guess you can tell me when the next sync is due?
[22:47] <TheMuso> No I am not sure whether they sync automatically or not.
[22:48] <HighNo> I've read (in the many many wiki pages I read yesterday and today) that the keyring is synced once per day automatically
[22:51] <TheMuso> Right.
[22:55] <norsetto> g'night all
[23:30] <Legendario> hello
[23:31] <Legendario> is there a way to specify the path ok the make file on the cdbs debian/rules ?
[23:38] <Legendario> can anyone here tell me this?
[23:38] <ion_> DEB_MAKE_MAKEFILE
[23:44] <saivann> Is there someone from the ubuntu sponsors for universe team that can take a look at bug 181417 ? Actual libofx package in ubuntu contains non free files, that can be fixed by merging the package from debian which is the new fixed upstream release
[23:44] <ubotu> Launchpad bug 181417 in libofx "Please merge 0.9.0 from debian unstable" [High,New] https://launchpad.net/bugs/181417