[02:41] <ubuntu4shane> !package guide
[03:36] <genupulas> my empathy not showing online gmail contacts.....can any one help me please
[03:38] <persia> genupulas, You'll want #ubuntu : this isn't a support channel, and we mostly care for packages that aren't installed by default for any flavour, so don7t do much with empathy anyway.
[03:40] <genupulas> persia,  tell me a perfect IM
[03:48] <ubuntu4shane> ok, I have a non-typical source for a python package, when I run sudo dpkg-buildpackage -us -uc in the directory it builds me a nice little deb, however that doesn't seem to be the way to do things according to this:  https://wiki.ubuntu.com/PackagingGuide/Python
[03:49] <ubuntu4shane> I would like to build a deb that would be able to go into a ppa, or ideally into a main repo.  I really need a complete a-z guide to teach me how to do this.
[03:50] <RAOF> !packagingguide
[03:50] <RAOF> A - Z!
[03:50] <ubuntu4shane> RAOF, well, sort of.
[03:50] <RAOF> It doesn't go into Python policy specifically, no.
[03:51] <RAOF> Although a quick google search will net you http://www.debian.org/doc/packaging-manuals/python-policy/
[03:52] <ubuntu4shane> RAOF, thanks, I must not have been googling correctly, that debian one, looks like an intense read
[03:53] <RAOF> Generally a google search of “debain $X policy” will get you the relevant policy document as one of the top results.
[03:53] <RAOF> That will describe the various corner-cases and decisions required to produce a proper $X package.
[03:54] <ubuntu4shane> well, I never would have thought of googling that!  :)  I'm not a programmer, or a developer, just trying to get a package packaged
[03:54] <ubuntu4shane> I'm thinking this is all over my head.
[03:55] <ubuntu4shane> This package here:  http://www.bibleanalyzer.com/download.htm  is what I would love to see properly formatted so that it could be put in a ppa or 'official' repo
[03:55] <ubuntu4shane> it is funny, written for Windows by the developer, however it is written in python, so works very nicely in ubuntu/linux
[04:13] <RAOF> If dpkg-buildpackage works you can probably put it in a PPA.
[04:13] <RAOF> To make it into Ubuntu proper, though, will require making it policy-compliant.
[04:14] <ubuntu4shane> RAOF, ok, I have a launchpad account for bugs, I seen something in there about a ppa, is that the same?
[04:15] <RAOF> Yes.
[04:15] <ubuntu4shane> RAOF, so in theory I have a ppa, and didn't know it?
[04:15] <RAOF> You've got access to a PPA, yes.
[04:16] <ubuntu4shane> RAOF, ok, I think I'm wrapping my head around this stuff, thanks
[04:17] <ubuntu4shane> the dev actually did the packaging of it for Ubuntu, but he really isn't a Linux user at all
[07:30] <dholbach> good morning!
[07:39] <Tsar_Evitsa> Hu all
[08:09] <sladen> dholbach: morgan herr holbach.  Ich sehe das wetter in Berlin ist normal
[08:11] <dholbach> sladen, Guten Morgen Herr Sladen - das Wetter in Berlin ist eine Katastrophe! Zu kalt! Zu nass!
[08:12] <Rhonda> *blinks*
[08:13]  * bilalakhtar fires up google translate
[08:16] <sladen> dholbach: ...innerhalb toleraz
[12:28] <ari-tczew> micahg: ping
[12:43] <xteejx> Hi all
[12:44] <xteejx> scikit-learn FTBFS because of a directive error in numpydoc.py. There is a fix upstream....
[12:44] <xteejx> can we just take the fixes even though there is a version difference if it still works?
[12:44] <xteejx> specifically: http://projects.scipy.org/numpy/changeset/8549
[12:45] <cjwatson> for natty, you can either backport the fixes or take a new upstream release, whichever is most convenient
[12:45] <cjwatson> if the latter, best to coordinate via Debian
[12:45] <xteejx> cjwatson: Wouldn't they ignore it, since they're in freeze?
[12:46] <cjwatson> that depends.  is it failing to build there too?
[12:46] <cjwatson> if it is, that would be RC
[12:46] <cjwatson> you should at the very least ask the Debian maintainer ...
[12:46] <xteejx> I'm assuming so with the tools in experimental
[12:46] <cjwatson> they might for instance be interested in uploading a new upstream version to experimental
[12:47] <xteejx> They doin't have the affect version., its in exp
[12:47] <xteejx> unstable, sorry
[12:47] <cjwatson> in fact, there's *already* a new upstream in experimental
[12:47] <cjwatson>  scikit-learn | 0.5-1 | experimental | source
[12:47] <cjwatson> is that sufficient?
[12:47] <xteejx> Yeah, can we take from that?
[12:47] <cjwatson> sure, requestsync
[12:47] <xteejx> :O
[12:48] <xteejx> (gain doing things the long/hard way) hehe
[12:48] <cjwatson> (-d experimental)
[12:48] <xteejx> ;)
[12:49] <xteejx> E: The environment variable UBUMAIL, DEBEMAIL or EMAIL needs to be set to let this script mail the sync request. don't think I have requestsync set up lol
[12:49] <xteejx> I'll do it manually
[12:49] <cjwatson> it would probably be time well spent to set up requestsync
[12:49] <xteejx> does it support SMTP?
[12:49] <cjwatson> sync requests filed that way are guaranteed to match certain patterns such that they get processed quickly
[12:49] <cjwatson> search for SMTP in the manual page
[12:49] <xteejx> I see
[12:59] <xteejx> All done, I added the --lp option and it worked fine
[13:39] <xteejx> How do I "extract" a debian .dsc to edit a fix?
[13:41] <ari-tczew> xteejx:  dpkg-source -x *.dsc
[13:41] <xteejx> ari-tczew: Cool thank you :)
[13:41] <ari-tczew> you're welcome
[13:43] <xteejx> sidenote; I don't know if this is any use to anyone learning but its helped me http://www.xs4all.nl/~carlo17/howto/debian.html
[13:48] <xteejx> Can we request a sync for a package in debian that we don't have?
[13:49] <ScottK> xteejx: You can, or you can just wait a bit and it will get in automatically.
[13:49] <xteejx> ScottK: Its in deb experimental, will that matter?
[13:49] <ScottK> xteejx: yes.  that will have to be requested.
[13:49] <xteejx> Ahh Ok, no prob :)
[13:49] <ari-tczew> xteejx: we have set on autosync on unstable.
[13:50] <shane4ubuntu> !packaginguide
[13:50] <xteejx> ari-tczew: So anything in exp gets missed unless its filed manually?
[13:50] <shane4ubuntu> !package guide
[13:50] <xteejx> I don't need that, I'm not packaging
[13:50] <ari-tczew> xteejx: yes. If you want something from Debian, you must request it
[13:51] <xteejx> Ok :)
[13:53] <ScottK> ari-tczew: Syncs from unstable don't need to be requested now.
[13:53] <cjwatson> xteejx: I just (coincidentally) sent mail to ubuntu-devel clarifying what you need to request manually
[13:53] <cjwatson> ari-tczew: ^-
[13:54] <xteejx> hehe :)
[13:54] <ari-tczew> ScottK: I missed write ..from Debian experimental
[13:54] <ScottK> ari-tczew: OK.  That's correct.
[13:55] <xteejx> Hmmm....the newer pkgversion depends on joblib >=0.4.5 but it fails quite badly and I don't know how to fix that :(
[13:55] <xteejx> I think I'll give up on that one to be honest :(
[14:01] <ari-tczew> xteejx: joblib is FTBFS. https://launchpad.net/ubuntu/+source/joblib/0.4.3-1
[14:02] <ari-tczew> looking on the buildlog, it's related to python
[14:02] <xteejx> ari-tczew: That's the same error in the exp version I tried
[14:02] <xteejx> I'm moving on to something else anyway. When the joblib FTBFS is fixed, the other will work
[14:26] <tumbleweed> ari-tczew: That's an interesting FTBFS. It looks like our buildds don't have /dev/shm mounted
[14:31] <ari-tczew> cjwatson: could you consider merge usbmount (universe)? last uploader is not interested.
[14:32] <ScottK> ari-tczew: He's a pretty busy person, perhaps he's not the best one to try to assign work to.
[14:32] <ScottK> ari-tczew: You might send a mail to the ubuntu-motu ML looking for a volunteer if you aren't up for it.
[14:34] <ari-tczew> ScottK: This is not very important priority. I just wanted ask cjwatson due to I think that he is familiar with similiar packages.
[14:34] <ScottK> OK.  He's one of the busier people on the Ubuntu foundations team.
[14:35] <ari-tczew> I've noticed, that he is hard-working.
[14:35]  * geser wishes that Debian would have build logs for all architectures
[14:36] <ari-tczew> tumbleweed: I pinged you yesterday. About your patch in hylafax: I suggest to replace it with upstream fix.
[14:37] <tumbleweed> ari-tczew: sure, I can look at that
[14:37] <tumbleweed> ari-tczew: I thought the DD responsible for it was busy in ubuntu?
[14:38] <ari-tczew> tumbleweed: was busy in Ubuntu?
[14:38] <tumbleweed> err, kept an eye on his package in ubuntu, and responded to bug reports
[14:38] <shane4ubuntu> I setup a ppa, and tried to add my own ppa to my system, and get this: Error: can't find signing_key_fingerprint
[14:39] <shane4ubuntu> I added a key, just today though, does it take a while to import?
[14:39] <ScottK> shane4ubuntu: PPA support is in #launchpad.
[14:39] <shane4ubuntu> ScottK, ahh, ok, thanks
[14:39] <ScottK> No problem.
[14:40] <shane4ubuntu> ScottK, on a side note does launchpad belong to ubuntu?
[14:40] <ScottK> shane4ubuntu: No.  They are separate projects that just happen to be both sponsored by Canonical.  Ubuntu is a user of Launchpad.
[14:40] <ari-tczew> tumbleweed: I've forwarded your patch to Debian. Response was very quickly. Read more on comments, debian bug 565001
[14:40] <sladen> shane4ubuntu: Ubuntu is a user of an instance of Launchpad
[14:40] <shane4ubuntu> ScottK, ok, once again, thanks + sladen
[14:41] <ScottK> sladen: There's more than one?
[14:41] <sladen> shane4ubuntu: just like anyone can run their own Apache, anyone (can if they wish) setup and run an instance of Launchpad
[14:42] <azeem> yeah; I do this every time I'm bored for 5 minutes
[14:42] <tumbleweed> ari-tczew: you saw Giuseppe Sacco's e-mail? he was active in the ubuntu bug for this, and (presumably) got this fix in upstream
[14:43] <ari-tczew> tumbleweed: yes I saw
[14:43] <shane4ubuntu> sladen, that is kind of what I thought, because if someone just goes to launchpad, sometimes it is difficult to find the right place to report a problem, but we digress, thanks for the info
[14:43] <tumbleweed> ari-tczew: I'm happy to wait for the fixed version via Debian
[14:43] <ari-tczew> tumbleweed: so, what do you think about replace your patch with fix from git?
[14:44] <ari-tczew> (avoid not shipping homemade patches, prefer to use cherry-picking)
[14:44] <tumbleweed> ari-tczew: I don't think it's worth the effort. My patch was a hack, but it'll go away when we next sync. Unless we need to merge in the meantime, in which case the upstream fix is probably preferable
[14:44] <tumbleweed> it doesn't actually matter how we fix this bug - my fix isn't *bad* just ugly
[14:47] <sladen> shane4ubuntu: I tend to hand-type the URLs;  eg.  http://bugs.launchpad.net/ubuntu/+source/package-name/+filebug
[14:47] <sladen> shane4ubuntu: since clicking your way around the maze is often quite time-consuming
[14:48] <tumbleweed> keyword bookmarks are great for that (I have lpts = https://launchpad.net/ubuntu/+source/%s)
[14:53] <cjwatson> ari-tczew: ScottK's right in general.  I looked at this one; I think we can just sync it since Debian is now installing to our current udev rules location and the rest of the changes aren't worth carrying.  I'll deal with that
[14:53] <ari-tczew> cjwatson: thanks!
[14:59]  * cjwatson uses requestsync for the first time ;-)
[15:01] <cjwatson> ari-tczew: BTW, did you check with Bhavi that he wasn't interested in doing that merge, or were you going by the comment on MoM?
[15:01] <cjwatson> hopefully this wasn't an example of a stale comment ...
[15:03] <tumbleweed> bdrung: hmm, looks like we need to set DEB_VENDOR for dpkg-source, too: http://raphaelhertzog.com/?p=942
[15:29] <bdrung> tumbleweed: yes. patches are welcome. :)
[15:33] <ari-tczew> cjwatson: as I wrote in the 2nd part of my question to you: last uploader is not interested.
[15:33] <ari-tczew> I asked Bhavi, don't worry
[15:37] <cjwatson> ok, cool, I just wanted to check your source for that comment :-)
[15:39] <ari-tczew> ; ))
[15:45] <tumbleweed> bdrung: yeah, I'll look at it. There are probably also more places we need to support UBUMAIL
[16:29] <Rhonda> I guess axp should get removed from natty?
[16:32] <micahg> ari-tczew: pong
[16:33] <ari-tczew> micahg: are you going to merge gxine (universe) ?
[16:36] <micahg> ari-tczew: that was just uploaded today to unstable, but yes, I'll do it, just not now
[16:36] <micahg> or yestaerday rather
[16:36] <ari-tczew> micahg: could you comment it on MoM?
[16:37] <micahg> ari-tczew: done
[16:37] <cjwatson> I thought we had this out already.  People shouldn't need to explicitly say that they will merge things for which they're touched-it-last; it should be the default assumption.
[16:38] <ScottK> Agreed.
[16:38] <ari-tczew> cjwatson: what's the conclusion?
[16:38]  * micahg also thought we weren't supposed to bother with debian revisions this early in the cycle
[16:38] <mr_pouit> (especially if the debian upload is a few hours old)
[16:38] <ScottK> ari-tczew: The conclusion is assume the TIL person will do it.
[16:38] <cjwatson> ari-tczew: you were the only one who thought that people needed to explicitly say, AFAICT ...
[16:39] <ScottK> There is plenty of time after DIF to deal with the ones that aren't done.
[16:39] <ari-tczew> cjwatson, ScottK: not everyone is inetrested in merging
[16:40] <cjwatson> ari-tczew: then we can deal with that after DIF
[16:40] <cjwatson> ari-tczew: at this point, it's noise
[16:40] <ScottK> ari-tczew: You are disturbing a lot of people to little purpose right now.  Patience please.
[16:40] <cjwatson> micahg: you're welcome to, but it's often not particularly urgent
[16:41] <micahg> cjwatson: right, and I have plenty of WI for Natty :)
[16:41] <ari-tczew> I just want clean up universe outstanding merges in natty.
[16:41] <Laney> post DIF is the time for that.
[16:41]  * ari-tczew is looking when is DIF...
[16:42] <Laney> (and it's worth noting that a merge is not always worthwhile)
[16:42] <Laney> (so "clean up" and "outstanding" might not be right)
[16:42] <ari-tczew> December 30th. at the end of the year.
[16:42] <cjwatson> cleaning up merges is a reasonable goal, certainly - but I think poking people about merges created yesterday is going a bit far
[16:43] <Laney> Checking the list is a ~fortnightly thing for me, so yes.
[16:44] <ScottK> ari-tczew: What would be useful is checking up on merges that are left over from Maverick and before untouched.
[16:44] <ScottK> Clearly no one is doing those.
[16:45]  * micahg actually has one claimed on that list as well :-/
[16:45] <ScottK> cjwatson: Do you still have the script you used to get a list of very stale merges and could you reasonably easily produce another list for people to work on?
[16:45] <ari-tczew> ScottK: hmmm. OK I got your point. Example, there are packages waiting so long, like gnome-* related.
[16:46] <cjwatson> ScottK: oh, yes - running
[16:47] <cjwatson> hm, now how was it I constructed the sample Sources files
[16:49] <cjwatson> ah yes, I helpfully put URLs in the spec
[16:54] <ari-tczew> I'll slow down in asking of merges. I'll be a bit busy till 10th Dec.
[16:54] <cjwatson> http://paste.ubuntu.com/526429/ - I'll sort out mailing ubuntu-devel about it in a bit
[16:54] <cjwatson> wouldn't mind cleaning up a few of my own there first ;-)
[16:54] <cjwatson> that's anything unmerged since http://snapshot.debian.org/archive/debian/20100211T033845Z/dists/squeeze/
[16:55] <ari-tczew> cjwatson: this is generated by script?
[16:55] <cjwatson> yes
[16:55] <cjwatson> http://paste.ubuntu.com/526431/
[16:55] <ari-tczew> cjwatson: huh, only 47
[16:55] <cjwatson> not as bad as you thought, eh? ;-)
[16:56] <ari-tczew> cjwatson: Certainly. I see that some of them are in main and universe.
[16:56] <cjwatson> yep
[16:57] <cjwatson> the ones in main are there due to being excruciatingly painful to do, mostly
[16:57] <ScottK> ari-tczew: You are completely welcome to sort out ttf-ubuntu-title.
[16:57] <ari-tczew> ScottK: Too hard for me. This package should review upstream author.
[16:58] <ari-tczew> cjwatson: are you able to create a special MoM department for this list?
[16:58] <ScottK> ari-tczew: OK.  Perhaps you could hunt them down and get advice?
[16:58] <cjwatson> uh, I suppose in principle but not at the moment ...
[16:58] <ari-tczew> ScottK: I can send a message.
[16:58] <cjwatson> file a wishlist bug please?
[16:59] <ari-tczew> ok
[16:59] <ScottK> ari-tczew: Sounds good.
[17:04] <ScottK> ari-tczew: Do you have an amd64 system to work on (mine are all i386)?
[17:05] <cjwatson> (for the avoidance of doubt, I generally think asking about merges is OK if they're actually blocking something else - on the principle that it's good to get unblocked as quickly as possible)
[17:07] <ari-tczew> ScottK: Unfortunately, not.
[17:07]  * achiang wonders what ari-tczew is doing with #671445
[17:07] <ScottK> OK.  Thanks.
[17:07] <ari-tczew> achiang: testing?
[17:07] <ScottK> If someone has an amd64 chroot/vm to play in and has a few minutes, I'd appreciate it if they could investigate why https://launchpad.net/ubuntu/+source/libclamunrar/0.96.4-1/+build/2025789 is failing.
[17:08] <ari-tczew> achiang: please complete DEP3 tags in your 15*.diff patch?
[17:08] <achiang> ari-tczew: will do.
[17:09] <achiang> ari-tczew: i was only asking because i haven't seen other ubuntu-sponsors assign bugs to themselves before.
[17:09] <achiang> ari-tczew: so i was curious
[17:11] <ari-tczew> achiang: If sponsor has assigned to themselve, it means that he will sponsor it.
[17:11] <ari-tczew> maybe not in 5 minutes, but will do it
[17:12] <achiang> ari-tczew: ok, thank you for the explanation. i didn't see that described in the MOTU wiki page, which is why i asked.
[17:12] <RoAkSoAx> can a -dev binary package Depend on other -dev binary packages (library -dev packages) of the same source
[17:13] <RoAkSoAx> ?
[17:15] <geser> sure, why not
[17:16] <RoAkSoAx> geser: and should all libXX-dev depend on libXX ?
[17:17] <geser> yes, else the .so symlink is dangling
[17:17] <RoAkSoAx> geser: ok thanks :)
[17:18] <DktrKranz> ScottK: I have a box, if you want to do some tests
[17:25] <seidos> what in the...never even heard of squid, haproxy, puppet, nagios, and asterisk
[17:26] <jpds> seidos: Where have you been?
[17:30] <xteejx> Hi all
[17:30] <xteejx> I'm thinking of starting on merges, have done numerous FTBFS, what is the workflow?
[17:31] <Rhonda> hurmpf
[17:31] <Rhonda> I want a better network connection.
[17:32] <Rhonda> working on sulfur is not funny from here.  %-/
[17:32] <micahg> Rhonda: PM?
[17:32] <jpds> Rhonda: traceroute?
[17:32] <Rhonda> jpds: mtr doesn't look too evil
[17:33] <Rhonda> m... said too early. Now it started give me 40% packet loss
[17:34] <Rhonda> micahg:  yes?
[17:34] <xteejx> If the only thing in REPORT is debian/control, that means it's a full merge, i.e keeping all Ubuntu changes, right?
[17:34] <xteejx> apart from any incontrol itself
[17:35] <micahg> xteejx: not necessarily
[17:35] <micahg> xteejx: but usually
[17:35] <xteejx> micahg: This is where I get confused with merges
[17:36] <micahg> xteejx: also, general rule is person who touched it last merges, but sometimes people upload a quick fix and have no interest in the package
[17:36] <xteejx> there is no mention in the debian changelog of our chnges, so I assume they werent sent upstream or not needed/implemented
[17:36] <micahg> xteejx: you might want to read the discussion about an hour ago on this channel
[17:36] <xteejx> time to scrollback ;)
[17:38] <xteejx> I get the gist of what was said :)
[17:39] <ScottK> DktrKranz: I'm guessing it's trivial to understand one you have the failed build.  Could you build it locally and have a look (if not, access later would be great)?
[17:40] <xteejx> version .65-1 in unstable 04/2008, updated 03/2010 to the version we have now
[17:40] <xteejx> I don't see any clues relating to someone working on the merge
[17:41] <Rhonda> ah, cable network, much better
[17:42] <geser> xteejx: which package are you trying to merge?
[17:43] <xteejx> geser: console-tools
[17:43] <xteejx> it was the first one without a comment on mom
[17:44] <micahg> xteejx: as cjwatson said, comments should be required to own merges
[17:44] <micahg> *shouldn't
[17:45] <xteejx> no but the last update was 3 deb versions ago in 2008
[17:45] <xteejx> ie karmic
[17:45] <micahg> xteejx: then you should be ok :)
[17:45] <xteejx> :)
[17:46] <geser> xteejx: from just a quick on the Ubuntu delta, I'd suggest you to pick an other (easier) merge for your first merge
[17:46] <xteejx> geser: Hmm, it looked easy at first glance tbh, what would you suggest? A minor version change or something?
[17:47] <geser> xteejx: it's not about minor/major version change but more about the amount and size of the Ubuntu delta
[17:47] <xteejx> Its not my first merge, but it'll be one of them :)
[17:47] <geser> you can take "lustre" from me if you want
[17:48] <xteejx> So one where our changes are small and therefore easier to do?
[17:48] <xteejx> geser: huh?
[17:48] <geser> I mean merge "lustre" (from my pending merges)
[17:48] <xteejx> Just like a good developer..here's my workload ;) hehe :)
[17:48] <xteejx> I'll have a look :D
[17:49] <Rhonda> Why would one block outgoing git:// connections?  :/
[17:49] <geser> at least I won't complain that somebody took my merges :)
[17:49] <xteejx> haha :)
[17:52] <xteejx> geser: I've looked at the changelogs, am I right in thinking this would be a full merge?
[17:53] <geser> yes, I just looked quickly at our changes and it looks like all need to be kept (I guess I forgot to forward the bashism one :( )
[17:55] <xteejx> ok have removed the diff3 markers in the bashisms.dpatch file, should be ok now?
[17:56] <xteejx> Obv will test buil
[17:56] <xteejx> d
[17:57] <xteejx> bloody fireworks
[18:05] <geser> fireworks?
[18:08] <xteejx> geser: Yup
[18:09] <xteejx> Nov 5th in the UK is a celebration of Guy Fawkes trying to blow up the houses of parliament
[18:09] <xteejx> so much for hating terrorism....
[18:10] <xteejx> hmmm the bashisms pacth doesn't apply to the new db version
[18:10] <xteejx> deb*
[18:12] <geser> check if it's still needed or if it got silently fixed
[18:12] <ari-tczew> xteejx: due to structure of file? or are you applying by patch?
[18:12] <xteejx> I'm going thru each of the to-be-patched files, loks like it's just moved around
[18:13] <xteejx> huh?
[18:14] <ari-tczew> cjwatson: bug 671542
[18:16] <xteejx> geser: None of the chnages were made upstream
[18:16] <xteejx> Could it just be the line numbers?
[18:17] <xteejx> also there's "diff --git a/ldiskfs/configure.ac b/ldiskfs/configure.ac" which I haven't seen before
[18:25] <ari-tczew> cjwatson: could you check why dssi exist on universe? It has been synced
[18:40] <bilalakhtar> ari-tczew: I just got your mail, is it true? thanks for notifying
[18:40] <ari-tczew> bilalakhtar: I don't lie. ; ))
[18:41] <bilalakhtar> ari-tczew: BTW, what do you mean by TIL ?
[18:41] <ari-tczew> bilalakhtar: Touched In Last,
[18:42] <bilalakhtar> aha
[18:43] <ari-tczew> bilalakhtar: 2nd mail sent.
[18:43] <ari-tczew> Cc'ed to Bhavi also.
[18:43]  * bilalakhtar checks
[18:45] <bilalakhtar> ari-tczew: this list of merges is what?
[18:47] <bilalakhtar> What do you mean by out-of-date merges?
[18:47] <bilalakhtar> Merges that have been stagnant since long?
[18:49] <ari-tczew> bilalakhtar: http://paste.ubuntu.com/526506/
[18:49] <bilalakhtar> thanks
[18:51] <ari-tczew> sex
[18:55] <Rhonda> \o/
[19:00]  * bilalakhtar would have bashed ari-tczew had he been here
[19:06] <Rhonda> sex is long removed from both Debian and Ubuntu
[19:07]  * Rhonda dances the happy dance: http://packages.ubuntu.com/maverick/wesnoth
[19:14]  * chilicuil dances too ^_^
[19:17] <DktrKranz> ScottK: here's debian/ content after build failure: http://pastebin.com/9dzw6Xgy
[19:21] <DktrKranz> it installs under lib64, while .install files only looks under usr/lib/
[19:31] <ScottK> slangasek: Did something change between Debian and Ubuntu where Ubuntu installs into lib64 on purpose?
[19:32] <slangasek> ScottK: in the name of all that is holy, no
[19:33] <slangasek>  /lib64 is a symlink to /lib - nothing should install to /lib6 4
[19:33] <slangasek> nor /usr/lib64
[19:33] <ScottK> OK.  I didn't think so, but I'm left wondering how this works on Debian and not Ubuntu then.
[19:34] <Rhonda> chilicuil: Do you see why I do it? ;)
[19:37] <ScottK> It wasn't built on a buildd for Debian, so hard to know.
[19:37] <ScottK> DktrKranz: Could I have the buildlog please.
[19:38] <chilicuil> Rhonda: not sure, I do dance because of a nice update in wesnoth n_n
[19:38] <ScottK> DktrKranz: Nevermind.  The buildd log is enough.
[19:41] <DktrKranz> ScottK: if you want me to do additional tests, I still have chroot open
[19:41] <ScottK> DktrKranz: I think it's OK for now.  Thanks.
[19:44] <DktrKranz> ScottK: this is build log for unstable/amd64: http://debomatic64.debian.net/unstable/pool/libclamunrar_0.96.4-1/libclamunrar_0.96.4-1.buildlog
[19:45] <DktrKranz> libtool issue?
[19:48] <ScottK> I think so.
[19:48] <ScottK> make[3]: Nothing to be done for `all-am'. is the first place they differ.
[19:49] <DktrKranz> -checking for multiarch libdir... ${exec_prefix}/lib
[19:49] <DktrKranz> +checking for multiarch libdir... ${exec_prefix}/lib64
[19:49] <DktrKranz> this is interesting
[19:50]  * ScottK wonders who slangasek needs to hunt down and kill.
[19:50] <DktrKranz> root@debomatic64:/pack/libclamunrar-0.96.4# gcc -print-multi-os-directory
[19:50] <DktrKranz> ../lib64
[19:50] <DktrKranz> that's weird...
[19:50] <slangasek> myself, maybe :)
[19:51] <slangasek> I think I was the last person to touch that part of gcc, in preparation of multiarch :)
[19:51] <ScottK> That'll save on travel time.
[19:51] <slangasek> although, I thought those patches were pushed by way of Debian
[19:51] <slangasek> so maybe the package will regress on rebuild in Debian too?
[19:52] <ScottK> It wasn't built on a buildd in Debian, but it builds correctly on DktrKranz's system.
[19:52] <slangasek> hmm
[19:52] <DktrKranz> exactly, just built on a up-to-date pbuilder
[19:52] <slangasek> time for a gcc bisect, I guess
[19:52] <ScottK> slangasek: Can I leave this with you and do you want me to file a bug?
[19:52] <sebner> ScottK: is it then murder or suicide. both prohibited though :D
[19:53] <ScottK> sebner: Suicide being prohibited is a matter of culture.  In some cultures it's an honorable alternative to disgrace.
[19:53] <slangasek> ScottK: I'm not going to have time to look at it more deeply today; if someone can bisect gcc to figure out what's changed, that would be ideal
[19:53] <slangasek> DktrKranz: fwiw, here's the gcc output for me on maverick amd64:
[19:53] <slangasek> $ gcc -print-multi-os-directory
[19:53] <slangasek> ../lib
[19:53] <slangasek> so I guess that's a natty gcc regression
[19:53] <DktrKranz> yup
[19:53] <ScottK> slangasek: As soon as you say gcc and bisect I know it's not me that will do it.
[19:54] <sebner> ScottK: in the minds but not in the law, no?
[19:54] <slangasek> :-)
[19:54] <ScottK> sebner: It's only a matter for the law if you suck at it.
[19:54] <sebner> heh
[19:54] <sebner> definitely
[19:54] <sebner> slangasek: you hear that? :P
[19:55] <ScottK> slangasek: I'll leave it for you for next week then.
[19:55] <slangasek> sebner: ah, but I only touched gcc in maverick, I haven't touched it in natty
[19:56] <ScottK> Right, so we blame doko.  He's not here this week.
[20:04] <Rhonda> chilicuil: I danced because of the screenshot ;)
[20:06] <sebner> slangasek: heh, I guess you can keep your life then :D
[20:13] <ari-tczew> what do you think about script 'requestmerge' like requestsync? Automatically creating merge requests as usual, reducing manual work.
[20:14]  * micahg thought he filed a bug for that
[20:15] <micahg> ari-tczew: not automatically, since not each new version gets merged, but as a way for a person with a diff to request a merge and subscribe sponsors
[20:16] <ari-tczew> micahg: hmm, not exactly I mean. Script can reduce a work with filing new bug, putting title and changelog from Debian.
[20:17] <micahg> ari-tczew: yes, but only if someone has worked on it or is imminently working on it, since not each version is merged
[20:17] <ari-tczew> micahg: "not each version is merged" => I don't take it in 100%. could you explain it for me?
[20:17] <micahg> bug 611121
[20:18] <micahg> ari-tczew: we don't merge every single Debian revision, therefore auto bug creation is not a good idea
[20:22] <DktrKranz> slangasek: I just looked at the gcc-4.5 delta between debian, it's quite short, and seems OK. Maybe problem has to be found in binutils.
[20:31] <DktrKranz> ScottK, slangasek: mh, no. I just reproduced the issue on Debian too, after installing gcc-4.5 and related gcc-defaults packages from experimental.
[20:31] <slangasek> ok
[20:46] <ari-tczew> micahg: are you sure that gcc 4.5 has been included in natty? not in maverick?
[20:46] <micahg> ari-tczew: it's in maverick, just not the default
[20:47] <ari-tczew> aha
[21:35] <ScottK> DktrKranz: Thanks.
[22:28] <hakermania> Hello. Can please anybody tell me why is Ubuntu still frozen ? (http://revu.ubuntuwire.com/) I am waiting 3 months now to upload my app but 2 months prior to Ubuntu Maverick (10.10) release the Ubuntu was Frozen because of the existing bugs that had to be fixed in some applications. But now I don't see a reason for Ubuntu to be frozen! REVU says nothing about uploading for Ubuntu 11.04, it only says 'Ubuntu is frozen' without any explanation. Can any
[22:29] <persia> hakermania, Ubuntu isn't frozen.
[22:30] <hakermania> That's what REVU says.
[22:30] <persia> It's probably just oversight.  Note that there's no promise everything in REVU gets reviewed, so the text is more advisory than meaningful.
[22:30]  * persia tries to figure out why
[22:31] <persia> Looks like it needs a REVU Hacker to fiddle it (I'm only REVU admin, so have limited permissions to make that kind of change)
[22:32] <persia> (and if I'm wrong, I'd like to know how to switch this)
[22:32] <hakermania> --_--' omg, I'm waiting 3 months now ubuntu to unfroze
[22:33] <hakermania> :|
[22:34] <hakermania> Please, tell me, should I only use dput to upload my app or is there any other way to upload the package from inside the site?
[22:36] <persia> dput is the right way to upload stuff.
[22:37] <persia> But getting stuff reviewed is a bit trickier :)
[22:38] <persia> tumbleweed, Do I remember correctly that you have audio logs from UDS?
[22:38] <hakermania> tumbleweed's in here? He really helped me to build the source :)
[22:47] <ari-tczew> Rhonda: I just noticed, that packages.ubuntu.com has been updated! \o/
[22:52] <tumbleweed> persia: I do for wednesday onwards ( mirrors.tumbleweed.org.za/uds-n ). Some files play best in VLC (I shouldn't have appended when reconnecting)
[22:53] <persia> tumbleweed, Thanks!
[22:53] <persia> Do you know if any other recordings are up for Mon/Tue ?
[22:53] <tumbleweed> no (which is why I started recording :P )
[22:55] <persia> Darn.  There was some stuff then I'd like to hear too, but thanks *a lot* for having Wed-Fri up.
[22:56] <tumbleweed> np, I've got the script now and will run it next UDS (assuming we don't get official recordings sooner)
[22:58] <hakermania> Should the name given on the REVU username be same with the name of my GPG key?
[22:59] <persia> hakermania, No such requirement.  My REVU username is "persia", which has no relation to my name, and only shows in my GPG key because one of my email addresses includes that.
[23:02] <hakermania> Ok, I understand this, but by simply giving dput revu package_version_source.changes how does REVU knows which user are you? Probably from the signed files, but what if the signed files have different NAME and EMAIL from you REVU account? How will REVU understand who from its users uploaded the package?
[23:04] <persia> REVU usernames are mapped to OpenID requests to launchpad.  The GPG signatures on the packages are mapped to a keyring containing the GPG keys of every LP account that logged into REVU.
[23:04] <persia> Yes, this is fragile, but basically, if you told LP your username and your GPG key, it ought just work.
[23:05] <ari-tczew> persia: hey, I saw you're revelation user. Do you use natty desktop?
[23:07] <persia> Some of my systems are still jaunty :)  What did you need tested?  What is it blocking?
[23:09] <ari-tczew> persia: I've prepared a merge. Could do I send a .deb to test for you?
[23:09] <ari-tczew> I ran this application, try to save, edit a new object and it didn't crash. Seems to be fine.
[23:10] <persia> I don't have working kernels in natty for most of the environments I *could* upgrade.  Simple test case is to create a keyfile with the maverick version, and then make sure you can *read* that keyfile with the natty version.
[23:10] <persia> (otherwise every user will want to hunt you)
[23:10] <persia> (plus I don't accept .debs that aren't in the archive)
[23:12] <ari-tczew> persia: from my side, it works fine. I'm going to upload.
[23:13] <persia> Did you try the test I suggested?  If not, you will want to get someone else to test it that way, or be prepared for some frustration.
[23:20] <hakermania> How do i tell LP my GPG key?
[23:20] <hakermania> ok
[23:20] <hakermania> found it
[23:22] <ari-tczew> persia: Create, save and load on maverick.
[23:23] <ari-tczew> why shouldn't work?
[23:24] <persia> I can't think of any reason it wouldn't work, but the program is designed to safely store cryptographic secrets, so it's probably designed to make them mostly unrecoverable.
[23:24] <persia> That makes it very important to test carefully, even though the risk of a problem is low, because the consequences of the problem have a high impact.
[23:25] <persia> I usually think of it as an equation: chance of something breaking * impact of it breaking = importance to make sure it doesn't break.
[23:27] <persia> So, for this sort of thing, create a file with the old version, read it with the new version, and feel comfortable that your upload won't make someone lose their passwords.
[23:27] <persia> (because not everyone has the luxury of sufficient hardware to test things properly before upgrading production systems)
[23:29] <ari-tczew> persia: ok, so create a file on already existing package and load on my merged?
[23:29] <persia> That's how I'd test it if I was doing the merge.
[23:30] <persia> (and how I'd test it for you if my laptops were either functional or able to run natty (depending on the laptop))
[23:31] <ari-tczew> persia: how many computers do you have?
[23:35] <persia> I lost count years ago.
[23:36]  * ari-tczew is going to bed. G'night.
[23:40] <hakermania> thx for the support. G'night