[00:00] <xhaker> ScottK, why pass on pilot-link?
[00:03] <Jazzva> ryanakca: I suppose you can add it to schroot, then update, install what you need, remove the repo, then update again... and remove the package you need after build.
[00:04] <RAOF> ryanakca: You could use a scratch chroot.
[00:05] <RAOF> ryanakca: ie: log in with schroot, add the repo, get the build-deps, and build manually.
[00:09] <ryanakca> RAOF: is there a way to automate the build from inside the chroot?
[00:10] <RAOF> Um.  Probably.
[00:10] <RAOF> I can't think of it at the moment.
[00:10] <RAOF> (Or indeed, think at the moment at all)
[00:11] <ajmitch> argh
[00:11] <ajmitch> single mysql query filling up /tmp (a tmpfs)
[00:11] <ajmitch> hate
[00:11] <ryanakca> RAOF: hmm... ok, thanks, I'll read the manpage :D
[00:11] <ryanakca> ajmitch: ouch...
[00:12] <ajmitch> one could say that
[00:16] <ajmitch> that's why it's being moved onto another server, but it still shouldn't do that
[00:16] <ajmitch> that's just madness
[00:16] <ryanakca> ummm... how can you edit a dpatch if you can't apply it?
[00:17] <ajmitch> break it until it applies?
[00:18] <ajmitch> how are you trying to apply it? dpatch-edit-patch?
[00:18] <ryanakca> yes...
[00:18] <ryanakca> and I've tried dpatch apply-all ...
[00:19] <ajmitch> manually tweak it?
[00:21] <ryanakca> ajmitch: ok... and, since I'm merging aptitude... I guess I should file a bug under it for merging, saying that I'll provide more information & new .dsc/etc soon? (That way we don't end up being two people doing the same thing?)
[00:22] <ajmitch> aptitude, you're a brave one
[00:22] <ajmitch> that may help, but it's in main, so you'd best hope that whoever was looking at it would check the bugs first
[00:23] <ryanakca> ajmitch: *nods*... I missed mvo by a matter of minutes this morning, so I'll poke him about it when he shows up again...
[00:29] <Amaranth> ryanakca: This is why quilt > dpatch/simple-patchsys
[00:29] <Amaranth> ryanakca: you can force the patch to apply, clean up the mess, then run `quilt refresh` and you're good to go :)
[00:29] <ryanakca> :)
[00:30] <ryanakca> Amaranth: feel like complaining to the Debian maintainer for me? :D
[00:30] <Amaranth> heh
[00:34]  * ajmitch wonders how this query can cause such a massive file in /tmp to be created :)
[00:35] <StevenK> ajmitch: Because MySQL is crap? :-)
[00:35] <ajmitch> StevenK: oh I know that
[00:35]  * ajmitch is driven to drink because of it
[00:35] <StevenK> Can't use Postgres?
[00:35] <ajmitch> a single dump of this database is ~90MB
[00:36] <StevenK> Neat
[00:36] <ajmitch> the query was dying because there was only about 4GB free in /var/tmp, where I moved it
[00:36] <ajmitch> sad, no?
[00:36] <StevenK> Yeah. Neat.
[00:36] <ajmitch> and no, I can't use postgres without rewriting a bunch of this code
[00:36] <ryanakca> in Please upload merge <sourcepackagename><version> (repository) from Debian <repository> (<component>) ... is <version> the Ubuntu or Debian version?
[00:36] <ajmitch> I'd really like to
[00:37] <StevenK> ajmitch: As much I like to loathe Perl, this is one place where DBI is *good*
[00:38] <ajmitch> this is PHP
[00:38] <ajmitch> and the code uses a couple of useful things from mysql
[00:38] <StevenK> I assumed it was.
[00:38] <ajmitch> like count(*) isn't fast in postgres due to its design
[00:39] <StevenK> If I recall, count(id) (or whatever) is fast enough
[00:39] <ryanakca> ?
[00:40] <LordKow> http://merges.ubuntu.com/u/uswsusp/REPORT should i let this go until the kernel dev team gets the new kernel out?
[00:41] <ajmitch> yeah, I think it's CALC_FOUND_ROWS or something that's used
[00:41] <LordKow> 2.6.22 -> 2.6.23/.24 includes new suspend and hibernation code.
[00:42] <ajmitch> problem is, I know I'm going to have to try & 'optimise' this query so it doesn't die
[00:48] <LordKow> bug 134238 what do you guys think? put s2ram back in or not. it *should* be included with powersaved
[00:48] <ubotu> Launchpad bug 134238 in uswsusp "Please re-enable build of s2ram binary" [Undecided,Confirmed] https://launchpad.net/bugs/134238
[00:49] <StevenK> LordKow: Right, I'd suggest you leave uswsusp alone. It's fragile, and can override parts of the suspend and resume code that runs under Ubuntu userspace.
[00:51] <LordKow> correct, and we differ from debian with regard to suspend/resume & splash (ie usplash vs libsplashy).
[00:51] <LordKow> i will gladly leave it alone :)
[01:12] <LordKow> okay. working on tiger merge and we added a portugese translation before debian did. our portugese translation is basically the same as debians, but was created 2 months later. use debians? the only difference in the translation is where newlines are (same wording)
[01:12] <LordKow> (latest debian package adds the translation)
[01:19] <persia> LordKow: looking at backscroll, I noticed you were looking at the wxwindows2.4 merge.  You don't happen to be familiar with that API do you?
[01:21] <LordKow> no
[01:21] <LordKow> persia ^
[01:22] <persia> LordKow: Ah, well.  There's only about 4 rdepends, and I'd rather drop the package than merge it.
[01:23] <LordKow> persia, fair enough but that is not a decision i can make.
[01:24] <persia> LordKow: No worries: I already made the decision: it's a matter of who can code it.  The remaining few are messy, so one needs to know the API.
[01:38] <ryanakca> Is 9.1M an "acceptable size"? (to upload as a debdiff to LP for a merge?)
[01:38] <ryanakca> or should I gzip it?
[01:41] <persia> ryanakca: At that size, a gzip is preferred.  What is the size of the diff against the past Ubuntu version?
[01:41]  * persia is confused about how a debdiff can get so large
[01:43] <ryanakca> persia: in a merge... new upstream version or something of the sort... *shrugs*
[01:43] <persia> ryanakca: There are 9MB of Ubuntu-specific patches?
[01:43] <ryanakca> persia: it's the size of the diff against the past ubuntu version...
[01:43] <ryanakca> persia: no.
[01:43] <persia> ryanakca: Ah.  Please do a diff against Debian for that then.
[01:44] <ryanakca> ok... 38K seems much more reasonable :)
[01:45] <persia> Yes.  Basically, the rule is to do a debdiff against the version that contains the orig.tar.gz that you want uploaded to the archives.  Anything else is hard to read.
[01:46] <imbrandon> ( make sure and specify what version you diffed against though, diffrent sponsors assume diffrent )
[01:48] <ryanakca> ok.
[01:48]  * persia seconds imbrandon: even if there are no assumptions, it's important to know the source
[01:53] <ryanakca> persia: one last thing before I upload... what do these lines in the diff do?
[01:53] <ryanakca> only in patch2:
[01:53] <ryanakca> unchanged:
[01:54] <persia> ryanakca: That generally indicates the addition of a new file, but I'd need more context to be sure (such context would be the entire stanza of the diff, the original, and the result, and I've too long a queue to examine it now)
[01:54] <ryanakca> ex: http://pastebin.ca/794368
[01:54] <ryanakca> ok :)
[01:55] <persia> ryanakca: If Debian added a new file, and that's it, I'm right.  If I'm wrong, you'll want to look at the file in question to figure out how (and I'd appreciate a correction).
[01:56] <LaserJock> phew, so much food.
[01:56]  * LaserJock is sleepy
[01:57] <ajmitch> oh that's right, one of those funny public holidays over there
[01:58] <LaserJock> "funny"?
[01:58] <LaserJock> New Zealand doesn't have holidays?
[01:58]  * persia is happily celebrating "Honor the Laborers" Day
[01:59] <ajmitch> LaserJock: we don't have that one :)
[02:00] <LaserJock> sucks to be you ;-)
[02:00] <persia> ajmitch: You need more holidays then :)
[02:00] <LaserJock> football and turkey, couldn't get much better
[02:02] <ajmitch> hi Hobbsee
[02:03] <imbrandon> LaserJock: yea i'm stuffed and will likely call it  short night, although not yet
[02:03] <imbrandon> mucho turkey and ham
[02:04] <LaserJock> yeah
[02:04] <Hobbsee> hey ajmitch
[02:04] <imbrandon> ajmitch: is it possible to search the db.debian.org and find DD locations ( e.g. if there are any near KC )
[02:05] <imbrandon> dosent look like that info is exposed afaict
[02:08] <ajmitch> yes, it's possible
[02:08]  * ajmitch would need to dig out his password to do it
[02:09] <imbrandon> ajmitch: if you find a few moments to do that it would rock
[02:09] <imbrandon> Kansas City, Mo 64138 ( and others thats just the zipcode i'm in ) if that helps any
[02:16] <LaserJock> imbrandon: what's the population of KC?
[02:17] <imbrandon> LaserJock: ummm <1 million with the whole metro area
[02:17] <imbrandon> i would have to lookup the exact though
[02:19]  * imbrandon looks
[02:20] <imbrandon> LaserJock: according to wikipedia
[02:20] <imbrandon> As of 2006, the city had an estimated population of 447,306[4], with a metro area of nearly two million.[5]
[02:21] <imbrandon> :)
[02:21] <LaserJock> phew 2 million
[02:21] <persia> That's a city?  Wow: population density is low out there.
[02:21] <imbrandon> persia: one of the largest in the midwest, yea population density is low in the midwest
[02:22] <LaserJock> that's freakin huge
[02:22]  * persia found Boston small, with only ~3 million
[02:22] <imbrandon> heh
[02:22] <LaserJock> pfft
[02:22] <imbrandon> boston is packed and fskin huge by our standards
[02:22] <LaserJock> totally
[02:22] <imbrandon> LaserJock: reno metro is like what 750k ?
[02:23] <LaserJock> > 100k is a big city to me
[02:23] <LaserJock> imbrandon: try 300 to maybe 400k
[02:23] <imbrandon> wow
[02:23] <imbrandon> i would have thought more, guess lots of tourist though
[02:23] <LaserJock> yeah, tons of tourist
[02:24] <LaserJock> Hot August Nights gets us 800k
[02:24] <LordKow> bug 164623
[02:24] <ubotu> Launchpad bug 164623 in tiger "Please upload merge tiger-3.2.2-1 (universe) from Debian unstable (admin)" [Undecided,Confirmed] https://launchpad.net/bugs/164623
[02:24] <imbrandon> heh i've been to those, down on virginia street
[02:24] <LordKow> can someone give me their ideas on the last comment I added please :)
[02:24] <imbrandon> and the rib-fest
[02:24] <LaserJock> imbrandon: yeah, that's pretty big too
[02:24] <LordKow> i should reset the status back to in progress, i guess
[02:24] <LaserJock> imbrandon: a Cabelas store just opened up last week
[02:25] <LaserJock> imbrandon: we got people from all over, supposedly several million a year are supposed to come
[02:27] <imbrandon> :)
[02:28] <imbrandon> we just have lots of Datacenters, something about there are tons of peering points in KC because its smack in the middle of the US
[02:29] <LaserJock> mhm
[02:29] <ryanakca> persia: 3 million? Small? Then what's 116k? nano? :D
[02:29] <LaserJock> imbrandon: I went to Lawrence, KS once for a few days. I liked that area out there. I don't like the idea of tornados though
[02:30] <imbrandon> yea thats just a few miles from here
[02:30] <imbrandon> persia: umm the epoc is required isnt it 0.4.4-5 ( published ) > 0.4.4-2+debian-1
[02:30] <persia> ryanakca: A large town: likely only one or two shops of any given specialised type, and many things need to be imported.  One knows everyone of shared interest, and is not surprised to find someone similar at a party who one will never see again.  "Local" means the entire area, rather than the neighborhood, etc.
[02:31] <persia> imbrandon: Than don't use that version number.  What's wrong with 0.4.4+debian-1?
[02:31] <ryanakca> persia: heh :)
[02:31] <imbrandon> persia: because upstream uses -X also
[02:31] <imbrandon> persia: eg -2 -3 -4 etc
[02:32] <imbrandon> e.g their release is 0.4.4-2
[02:32] <persia> imbrandon: Hrm.  Upstream is even more broken than I thought.  In that case, the watch file is way broken.  Looking again...
[02:32] <imbrandon> k
[02:34] <imbrandon> yea watch may not work for them, upstream is really fubar, their tarbal is 0.4.4.tar.gz but unzip it and its really 0.4.4-2
[02:34] <imbrandon> persia: ^
[02:34] <persia> imbrandon: I can't find any evidence that upstream ever releases multiple revisions for a given version: the revision number seems only for local convenience.
[02:35] <LaserJock> persia: and I thought my home town was good sized at 4k :/
[02:35] <persia> imbrandon: you can fix that in get-orig-source :)
[02:35] <imbrandon> heh i loth getting source from vcs
[02:35] <imbrandon> err
[02:35] <imbrandon> hrm
[02:36] <persia> imbrandon: get-orig-source isn't just for VCS: use uscan to grab upstream, unpack, blow away debian/, repack sensibly.
[02:37] <imbrandon> true but what about the problem -3 will also be 0.4.4.tar.gz from upstream
[02:37] <imbrandon> upstream just needs to let me fix their shit LOL, but i've pleased with him more than a year now
[02:37] <imbrandon> to no avail
[02:37] <saivann_> Hi everyone, #ubuntu-bugs seems empty of awake people, can I ask a question about bug importance here?
[02:37] <imbrandon> pleaded*
[02:37] <persia> imbrandon: Looking at sourceforge, upstream has never released an update without bumping the upstream version: 0.3.0-2, 0.4.1-0, 0.4.2-0, 0.4.3-2, 0.4.4-2.
[02:38] <persia> saivann_: Don't let the lack of traffic bother you: just ask there.
[02:38] <imbrandon> hrm very true, i coudl probably get away with 0.4.4+debian-1 then
[02:39] <imbrandon> 0.4.4+debian-1 > 0.4.4-5 correct ?
[02:39] <persia> imbrandon: So my dpkg tells me (dpkg --compare-versions 0.4.4+debian-1 gt 0.4.4-5 && echo Woot!)
[02:39] <imbrandon> k
[02:40] <saivann_> persia : Thanks, I just wanted to know one thing, I set the importance of the bug 101943 to medium, but since it can crash or freeze a computer for a while with default ubuntu stuff, should-I change to "High"
[02:40] <ubotu> Launchpad bug 101943 in xscreensaver "Braid screensaver crashes system with compiz activated" [Medium,Confirmed] https://launchpad.net/bugs/101943
[02:40] <imbrandon> seeing how i've never used get-orig-source personaly in a p[ackage it will be a good thing(tm)
[02:40] <imbrandon> persia: thanks for the feedback, i might poke you in a few hours to take another quick glance
[02:40] <imbrandon> if your up for it
[02:41] <persia> imbrandon: No problems.  The more I get to review, the easier it is to put off actually maintaining any of the libraries I should be updating :)
[02:41] <imbrandon> heh, yea i have one thats converted to cmake i've been putting off
[02:41] <imbrandon> :)
[02:42] <StevenK> imbrandon: No DD in KC
[02:42] <imbrandon> libvisual0.4 i'm looking at you ..
[02:42] <imbrandon> StevenK: crap
[02:42] <imbrandon> StevenK: what about the state of MO or KS ? ( I seen one listed for St. Louis but thats about 4 hours away )
[02:43] <StevenK> 3 in MO
[02:44] <imbrandon> what cities ? one might be closer than stl
[02:44] <StevenK> 3 in KS, too
[02:44] <imbrandon> nice 1 out of 6 must be semi close
[02:44] <imbrandon> hopefully
[02:47] <LaserJock> imbrandon: you need a new key signed?
[02:47] <imbrandon> LaserJock: yes
[02:48] <LaserJock> for DM?
[02:48] <imbrandon> yea from a DD, i have ubuntu sigs
[02:48] <imbrandon> for DM
[02:48] <LaserJock> imbrandon: the ubuntu sigs aren't from a DD?
[02:48] <imbrandon> not the ones i currently have, my old key had ajmitch and sabdfl
[02:48] <imbrandon> but that one is revoked
[02:49] <LaserJock> doh
[02:49] <ajmitch> imbrandon: just fly here & I'll sign it again
[02:49] <imbrandon> hehe
[02:50] <imbrandon> StevenK: can i have the @debian.org emails of those 6 people ? or would that be shady use of debian resources
[02:50] <StevenK> imbrandon: I'm sorting out where they are, first
[02:50] <imbrandon> ahh ok
[02:50] <imbrandon> thanks a ton for doing that btw
[02:50] <StevenK> imbrandon: Let's just say you'll owe me. :-)
[02:51] <imbrandon> sounds fair :)
[02:52] <GoldenPony> LaserJock!!!
[02:52] <ajmitch> run now, LaserJock
[02:53] <StevenK> Ponies!
[02:53] <imbrandon> golden ones at that
[02:53] <LaserJock> hmm, how do you see who's signed your key?
[02:53] <imbrandon> you should be able to see it in gpg --list-keys iirc
[02:53] <StevenK> gpg --list-sigs <id>
[02:55]  * ajmitch looks at calendar
[02:56] <ajmitch> ah, q&a session is 1 hour after start of motu meeting?
[02:56]  * ajmitch got confused at seeing 13:00 for the q&a, since I knew that the meeting was at 1AM here
[02:56] <persia> ajmitch: Right.
[02:57] <ajmitch> so we have to keep the arguing short
[02:57] <LaserJock> hmm, --list-sigs only give me self signatures
[02:57]  * ajmitch is doubtful that he'll really be very awake by then
[02:57] <persia> Current agenda is just SRU: we should be OK if there's not a lot of "other business"
[02:57] <ajmitch> persia: we've got plenty of other issues
[02:57]  * persia looks at the agenda again
[02:57] <ajmitch> I thought they had been added to the agenda, but I guess not
[02:58] <ajmitch> our little discussion about what to do with MOTUs who don't follow policy, and how to try & prevent having that happen in the first place
[02:58] <persia> ajmitch: Add something if you want to discuss :)
[02:58] <ajmitch> that would commit me to being there :)
[03:00] <persia> ajmitch: True.  Next time should be saner: a saturday morning, and perhaps you'll want to raise it then?
[03:00] <ajmitch> maybe
[03:02] <persia> There's a couple things that seem pending: how to make sure everyone is aware of current consistent policy, how to manage process change so everyone is aware, how to deal with scaling as we get closer to Dunbar's number, etc.
[03:03] <StevenK> LaserJock: If it's only showing self-sigs, then your key either hasn't been signed, or you haven't pulled your public key off of a keyserver
[03:06] <LaserJock> StevenK: I think maybe the later
[03:06] <StevenK> LaserJock: gpg --recv-keys 0x<id>, then
[03:10] <LaserJock> alrighty, back in business
[03:10] <LaserJock> mako is a DD isn't he?
[03:12] <StevenK> YU
[03:12] <StevenK> Er
[03:12] <StevenK> Yup
[03:12] <LaserJock> alright, I guess that's my only DD sig then
[03:12]  * minghua needs his keys signed, too.
[03:13]  * StevenK just counted -- 33 DD signatures
[03:13] <LaserJock> wow, nice
[03:14] <LaserJock> if you add a new email address do you have to get new sigs?
[03:14] <StevenK> If you add a new e-mail address, that uid only has a self signature
[03:15] <minghua> StevenK: Can you sell me a couple? :-)
[03:15] <StevenK> Nope. :-P
[03:16] <LaserJock> StevenK: but does that mess me up if I need a DD sig?
[03:17] <LaserJock> does it matter what uid I use?
[03:17] <LaserJock> like I have mantha@ubuntu.com
[03:17] <LaserJock> but if I wanted to use a different address for Debian say
[03:18] <StevenK> LaserJock: No, since your AM will look at all UIDs on your key
[03:19] <LaserJock> k
[03:19] <StevenK> LaserJock: Ponies!
[03:21] <LaserJock> yes master
[03:22] <imbrandon> LaserJock: i use @imbrandon.com for debian and @kubuntu.org for ubuntu but both are on the same KEY
[03:22] <imbrandon> seems to work ok
[03:23] <LaserJock> yeah, I have one that's actually an old address
[03:23] <LaserJock> is it a good idea to remove older keyids? or is it ok to just leave them?
[03:23]  * persia thinks the key is signed, rather than the UID
[03:24] <StevenK> persia: People may choose to sign one UID
[03:24] <LaserJock> I don't think so actually
[03:24] <persia> StevenK: Really?  Interesting.  Thanks.
[03:24] <LaserJock> because I added my @ubuntu.com later
[03:24] <LaserJock> and some sigs are not on it
[03:24] <StevenK> persia: I sign using --edit-key, and the command sign asks "Really sign all UIDs?"
[03:24] <LaserJock> but I think people look at all the UIDs
[03:25]  * StevenK chuckles at imbrandon's e-mail
[03:25] <mdomsch> StevenK, go to OLS and do the keysigning for a few years...
[03:25]  * mdomsch counts 102 debian.org sigs
[03:26] <mdomsch> LaserJock, caff is really nice for handling that
[03:26] <mdomsch> apt-get install signing-party
[03:26] <StevenK> mdomsch: OLS is a little far
[03:26] <imbrandon> StevenK: did you get it ? i got a returned mail
[03:26] <StevenK> imbrandon: I got it, yes
[03:26] <imbrandon> hrm strange
[03:26] <mdomsch> it mails a separate signature to each uid you're signing
[03:26] <mdomsch> encrypted
[03:26] <imbrandon> StevenK: i got SMTP: host 70.103.162.29: 550 user account locked
[03:26] <persia> I'm looking at a multiverse package that build-depends on a wrapper package that downloads the actual contents at install-time.  Unfortunately, this just completely fails to work for the current build environment.  Does anyone have any suggestions?
[03:27] <mdomsch> and the receiver then decrypts, adds it to their keyring, and uploads it to the keyservers
[03:27] <imbrandon> ( thats my ISP's smtp server )
[03:27] <mdomsch> so you know they own the email addr
[03:27] <StevenK> imbrandon: That's master.d.o, so one of them is locked
[03:27] <imbrandon> ahh
[03:27] <imbrandon> looks like both i think, lemme look
[03:27] <imbrandon> yea they both say that, so not active?
[03:28] <StevenK> Uncertain
[03:28] <mdomsch> StevenK, I presume LCA has keysignings too, but I've never been able to go
[03:28] <Hobbsee> persia: fix the package so it doesn't.
[03:28] <persia> Hobbsee: Doesn't what?
[03:28] <Hobbsee> persia: need to access the net during build.
[03:28] <StevenK> persia: The Ubuntu buildds have no Internet access (for obvious reasons)
[03:29] <persia> Hobbsee: There are no open-source versions of the API against which the package builds available.  It needs the build dependency.  I could copy the binary blobs to multiverse directly, but that would be bad.  Any other ideas?
[03:30] <persia> StevenK: Yes, I know: I'm hoping someone will tell me a way to handle binary uploads or something.
[03:30] <StevenK> persia: Beg lamont
[03:30] <persia> StevenK: Thanks.
[03:31] <imbrandon> StevenK: ok so should i wait a few days to see if those accounts are still active or does locked mean something i'm not aware of, it said failed to deliver
[03:31] <imbrandon> seems only you got the corny email hehe
[03:33] <persia> Hmm..  Now to find a non-US, non-EU buildd admin...
[03:33] <imbrandon> heh goodluck
[03:41]  * LaserJock gets back to ponies
[03:41]  * imbrandon wonders if he will finaly get a GoldenPony :)
[03:43]  * Hobbsee cant help you there
[03:43] <ajmitch> imbrandon: you'll get an extra special one, just for you
[03:43] <imbrandon> lol
[03:44] <imbrandon> mt dew colored ?>
[03:44] <LaserJock> eww
[03:45] <ajmitch> just wrong
[03:47] <LaserJock> imbrandon: maybe a pony pulling a cart of Mt. Dew?
[03:47] <imbrandon> hahaha :)
[03:47]  * StevenK is reminded of an Australian radio ad.
[03:48] <StevenK> "G'day, I'm a draught horse. I'm used to pull big, heavy carts around. Full of beer. Er, the carts, not me."
[03:48] <LaserJock> lol
[03:48] <imbrandon> lol
[03:50] <StevenK> (It turns out the draught horse, has been replaced with a ute, and so the horse talks about the ute, and then says, "Still, I shouldn't complain. The boss got me a new job. In a factory. Making glue, I think. I start tomorrow!")
[03:50] <bmk789> is there any progress being made on the penguintv package?
[03:50] <persia> bmk789: penguintv?  What's the current status.
[03:51] <bmk789> broken
[03:51] <persia> bmk789: Are there bugs?
[03:51] <bmk789> needs a couple variables exported to run correctly, but then it runs
[03:52] <bmk789> the software itself is kinda buggy but thats not gonna be fixed with packaging
[03:52] <LaserJock> StevenK: heh
[03:52] <persia> bmk789: I meant, "Is there a bug about this problem filed on Malone?".  Sorry for the confusion.
[03:53] <bmk789> its bug #131958 on launchpad, i havent seen anything else about it
[03:53] <ubotu> Launchpad bug 131958 in penguintv "PenguinTV segfaults with GtkWarning: gtk_window_resize: assertion `width > 0' failed" [Undecided,Confirmed] https://launchpad.net/bugs/131958
[03:54] <persia> bmk789: looking at the bug history, it appears nobody is working on it.  If you know how to fix it, a patch would be great.
[03:55] <lifeless> bmk789: we'll happily take non-packaging bugfixes if they are clear and understandable.
[03:55] <bmk789> i really wish i could but i just dont know how to set it up right
[03:55] <lifeless> bmk789: well, perhaps adding a default for those environment variables, within the code, would be a good start
[03:56] <persia> bmk789: OK.  I'd be happy to help get it set correctly, I just don't use the package, and don't know how to fix it.  Does it maybe need adjustment of the default configuration file?
[03:57] <bmk789> well its python and run from a script /usr/bin/PenguinTV but i dont know how to integrate the "export ....." lines into that script to get it to work
[03:57] <bmk789> i tried just putting them in at the top but that didnt do it
[03:58]  * persia defers to someone who knows python, but is available to help with packaging questions
[03:58] <lifeless> bmk789: export lines are shell, is /usr/bin/PenguinTV shell?
[03:58] <imbrandon> persia: got a simple get-orig-source example ( or some docs woudl be better ) google is not my friend atm
[03:58] <bmk789> im assuming not since it starts with #!/usr/bin/python
[03:59] <imbrandon> os.system('export BLAH=blah')
[04:00] <imbrandon> hehe assuming os is imported
[04:00] <lifeless> imbrandon: wrong answer
[04:00] <persia> imbrandon: it's just a make rule that generates a tarball.  There are a few examples on https://wiki.ubuntu.com/PackagingGuide/Basic#CommonMistakes, but I'll see if I can find a nice repack example.
[04:00] <lifeless> bmk789: try this -
[04:00] <lifeless> import os
[04:00] <lifeless> os.environ['VARIABLE'] = 'value'
[04:00] <imbrandon> ahh much cleaner :)
[04:00] <lifeless> imbrandon: with the added advantage of actually working :)
[04:01] <imbrandon> hehe i have -0- python-foo as StevenK found out the other night, only hacks
[04:01] <lifeless> imbrandon: calling os.system() will run a sub process, but its environment is in a child process
[04:01] <persia> imbrandon: I'm not sure I like the style of http://revu.ubuntuwire.com/revu1-incoming/ike-0711191320/ike-2.0.3+dfsg/debian/rules (not very make-like), but it works.
[04:02] <lifeless> imbrandon: so it doesn't get fed back into the running python script; which is why it wouldn't work
[04:02] <imbrandon> persia: ok cool gives me something to work with atleaste
[04:02] <imbrandon> lifeless: ahhh i see
[04:02] <lifeless> imbrandon: same thing will happen with mono, C, perl etc.
[04:02] <imbrandon> yea
[04:03] <lifeless> and all shell for that matter  :)
[04:03] <lifeless> s/all/also/
[04:05] <imbrandon> persia: so get-orig-source isnt intended to run at every build correct, only manualy via debian/rules ?
[04:05] <bmk789> lifeless: i changed it to this http://pastebin.com/m6cb4f6a but it did the same thing
[04:06] <persia> imbrandon: The genpo get-orig-source (from https://launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=genpo) is a simple uscan-based repack, and might be a good example.
[04:06] <bmk789> lifeless: i added lines 20-21
[04:06] <persia> imbrandon: Right.  It's run manually only.
[04:07] <persia> imbrandon: Essentially it serves to document the repacking procedure, so that anyone else can duplicate it, and the next upstream is easy to repack.
[04:07] <imbrandon> ahh right ok
[04:08] <lifeless> bmk789: but it works when you export those variables ?
[04:09] <LaserJock> for some reason it just seems like README.Ubuntu would be better for documenting stuff than debian/rules
[04:09] <bmk789> yes when i export those before running that script it works but the edited script doesnt work
[04:09] <lifeless> bmk789: oh, two issuees
[04:10] <bmk789> ?
[04:10] <lifeless> bmk789: the main one si that LD_LIBRARY_PATH is, if I remember correctly, not something that can be trivially changed... hang on
[04:10] <bmk789> oh
[04:10] <lifeless> the runtime loader will check it
[04:10] <lifeless> but you have to tell it or something
[04:10] <lifeless> man ld.so
[04:12] <lifeless> I think you might need to rebuild some extension to know where its dependent libraries are, or some such.
[04:13] <bmk789> so its gonna take more than tweaking that file to fix this
[04:14] <persia> bmk789: You might also try in #ubutu-mozillateam for hints on making things work well with firefox.  I don't know how active they are now (seems to be US-time based, and there's a national holiday on), but can be a good source other times.
[04:16] <bmk789> i really wish i could contribute to stuff like this but i really dont know what im doing
[04:17] <persia> bmk789: Trying is the best way to learn: eventually you get something that works for you, and you share it with others.  If it also works for them, you share it with everyone, and find the next thing that annoys you :)
[04:18] <bmk789> i know i just dont wanna barge in on all the developers and be the n00b that needs everything explained
[04:19] <lifeless> bmk789: we're all noobs, all the time, on some stuff
[04:19] <persia> bmk789: Don't worry about asking questions: if you ask something really low-level, you'll get a pointer to a document, rather than an answer, but the question is still worthwhile.
[04:20] <bmk789> alright, ill give it a shot
[04:20] <persia> bmk789: Good luck.
[04:21] <bmk789> thanks
[04:25] <bmk789> would it be wrong to rename PengiunTV to PengiunTV.2 then create a shell script for PenguinTV that runs the 2 export lines then runs PenguinTV.2
[04:26] <RAOF> bmk789: That can work.  The traditional way to do that is to rename the binary to pengin.real & have penguin be the wrapper script.
[04:26] <bmk789> ah, so thats what all the .real threads are
[04:27] <RAOF> Yup.
[04:27] <RAOF> The compiz package does it, miro does it (upstream, now.  Yay!)
[04:28] <bmk789> i suppose that isnt the "proper" way to solve the problem is it?
[04:29] <RAOF> There probably is, from what I've gathered (I'm not really in possession of all the facts, though)
[04:29] <bmk789> well that does the trick
[04:30] <RAOF> There's nothing terribly wrong with a wrapper solution, though.
[04:31] <persia> The "right" solution is to have a real shared library for firefox, which I think is coming soon.
[04:37] <TheMuso> Afternoon folks.
[04:38] <StevenK> Afternoon TheMuso
[04:45] <nenolod> who do i subscribe to a bug requesting a sync from debian unstable?
[04:46] <nenolod> we just knocked out the audacious 1.3 -> 1.4 transition in debian today
[04:46] <nenolod> so, it'd be good to sync the packages in ;)
[04:51] <persia> nenolod: The same sponsors teams that you'd subscribe for a patch
[04:52] <persia> nenolod: On the other hand, if there's no Ubuntu variation, the autosync scripts will grab things soon, and if there is Ubuntu variation, it needs a merge.
[04:52] <persia> Errrr... *may* need a merge
[04:58] <nenolod> well audacious 1.4.2 needs to go in first
[04:58] <nenolod> which has new deps (libprojectm1) which aren't in ubuntu :D
[04:59] <persia> nenolod: Is libprojectm1 in main in Debian?  If so, it should hit Ubuntu NEW fairly soon.
[05:00] <imbrandon> i thought libprojectm1 was in NEW or should be soon-ish
[05:00]  * persia hasn't looked at NEW
[05:00] <nenolod> how do you view NEW?
[05:00] <nenolod> it's in debian main ;p
[05:01] <nenolod> libvisual-projectm is in NEW, but is entirely unrelated to libprojectm1
[05:01] <persia> nenolod: https://launchpad.net/ubuntu/hardy/+queue
[05:01]  * imbrandon perks up , libvisual ?
[05:02]  * imbrandon just took that over in debian
[05:02] <nenolod> libprojectm1 is not in any of hardy's queues ;)
[05:04] <persia> imbrandon: You might want to chat with DarkMageZ, who has been maintaining libvisual-plugins in Ubuntu.
[05:04] <persia> nenolod: Wait a few days: the next autosync run will probably happen when the build queues have quieted a little.
[05:04] <imbrandon> persia: yea i just filed the ITA for libvisual and libvisual-plugins in debian about 12 hours ago
[05:05] <nenolod> libvisual-projectm is a seperate package
[05:07] <imbrandon> man i need to find some mentee work for nxv*l to "learn the tools" he has a good grasp of the bug triage and packageing requiremnets, but wants to learn the "tools" better
[05:07] <imbrandon> sugestions ?
[05:08] <Hobbsee> imbrandon: unmet deps?
[05:08] <persia> imbrandon: FTBFS issues?
[05:08] <imbrandon> yea i was thinking ftbfs but either i guess would be ok
[05:09] <persia> imbrandon: More generally, pick a few things from qa.ubuntuwire.com: there's lots of little stuff, most of it packaging-related.
[05:22] <GoldenPony> LaserJock: ponies!
[05:23]  * minghua ponders about the horror when golden ponies turn into long pointy sticks.
[05:24] <GoldenPony> haha
[05:25]  * minghua actually never understands this pony business.
[05:26] <persia> minghua: As long as we have Golden Ponies we can all ride happily to another release.  Unfortunately, they can only be forged with very high-powered lasers, so sometimes it takes a while.
[05:28]  * imbrandon considers upgrading to hardy on his main workstation
[05:28] <minghua> persia: Hmm.  Lasers.
[05:28] <Hobbsee> imbrandon: don't.
[05:29] <Hobbsee> actaully, kde might not be too bad.
[05:29] <imbrandon> i'm in fluxbox + kde apps + gnome apps lol
[05:29] <imbrandon> atm
[05:29] <imbrandon> just an all arround mix
[05:29] <persia> imbrandon: You might want to check the NBS list before upgrading: just to make sure you have have a normally unstable system as a result.
[05:29] <Hobbsee> the gnome apps are breaking
[05:30] <imbrandon> yea looks like even irssi is on the NBS list
[05:30] <imbrandon> hrm
[05:30] <imbrandon> maybe i'll wait another week
[05:35]  * persia grumbles that the buildds are too responsive, and that more uploads are required to keep the delay > 1 day.
[05:36] <Hobbsee> heh
[05:36] <Hobbsee> just try hppa or something.
[05:37] <persia> Hobbsee: True.  HPPA is happy.  The others are getting hungry.
[05:37] <Hobbsee> mmmm
[05:38] <Hobbsee> yeah, must be time for a kernel upload.
[05:38] <Hobbsee> gutsy's boring.  it actually works.
[05:39] <lifeless> hardon time
[05:39] <lifeless> and
[05:39] <lifeless> turkish food; I'm hanging out for that
[05:39] <Hobbsee> ...
[05:40] <lifeless> down near jeff and pia's, theres a most excellent turkish place.
[05:40]  * persia suspects channel skew
[05:42] <Hobbsee> lifeless: goign to go visit them?
[05:45] <lifeless> thats the current place
[05:45] <Hobbsee> sounds like fun
[05:46] <lifeless> :)
[05:47] <Ahmuck> i would love to see a p2p tv app in a deb.  sopcast has a linux version for thier player, unlike joost
[05:51] <persia> Right.  Isn't there a plethora of places that indicate one should file  bug for that request?
[05:51]  * minghua wonders if Ahmuck thinks #ubuntu-motu channel as post office to Santa or something...
[05:51] <Hobbsee> minghua: likely from the forums
[05:51] <imbrandon> hahaha
[05:52] <imbrandon> he is actualy from my LUG, figures lol
[05:52] <nixternal> shoot, if santa is watching, then I want a new car (preferably one of them new Honda hydrogen ones), some new computers (preferably the fastest thing God could ever think of), and world peace!
[05:52] <persia> imbrandon: Could you pass a clue followed by a solid thwack?
[05:52] <imbrandon> persia: definately
[05:53] <imbrandon> speaking of LUG i havent seen pwnguin lately, he must be afk for the holidays
[05:55] <somerville33> Hey
[05:55] <somerville33> I'm getting an error when I attempt to generate an interdiff
[05:56] <somerville33> cody-somerville@osunta:~/packages/exaile$ interdiff -z -p1 exaile_0.2.11-0ubuntu1.diff.gz exaile_0.2.11.1-0ubuntu1.diff.gz    diff -u exaile-0.2.11/debian/rules exaile-0.2.11.1/debian/rules
[05:56] <somerville33> --- exaile-0.2.11/debian/rules
[05:56] <somerville33> +++ exaile-0.2.11.1/debian/rules
[05:56] <somerville33> interdiff: hunk-splitting is required in this case, but is not yet implemented
[05:56] <somerville33> interdiff: use the -U option to work around this
[05:56] <imbrandon> somerville33: paste.ubuntu.com is easy to rember :) and umm did you try -U ( not -u like you pasted )
[05:57] <imbrandon> -u != -U
[05:57] <imbrandon> leaste not most of the time
[05:58] <somerville33> That isn't part of the command
[05:58] <somerville33> It is a part of the output
[05:58] <somerville33> ie. "diff -u ..."
[05:58] <imbrandon> ahh
[05:58] <somerville33> And using -U does not work either
[06:01] <minghua> interdiff(1) man page says -U needs an argument, i.e. "-U n".
[06:01] <somerville33> I put 50
[06:02] <minghua> Maybe too much? :-P  Seriously though, probably interdiff doesn't work well in your case.
[06:02] <somerville33> Doesn't work with 2 either
[06:03] <somerville33> And interdiff is the SOP for new package releases
[06:03] <somerville33> *new upstream releases
[06:05] <somerville33> I'm just going to dput it to revu than
[06:14] <somerville33> Could someone review please? http://revu.ubuntuwire.com/details.py?package=exaile
[06:22] <Hobbsee> somerville33: is that tarball any different from what's already in the archive?
[06:23] <minghua> Hobbsee: If it's a new upstream, the tarball is probably not in the archive?
[06:24] <Hobbsee> minghua: they re-released 0.2.11, as they screwed it up the first time.
[06:24] <minghua> Hobbsee: I see.
[06:24] <Hobbsee> minghua: and, after a while (and after bluekuja packaged it), they decided to rename the tarball to 0.2.11.1
[06:24] <Hobbsee> but o
[06:24] <Hobbsee> but i'm not sure if they ever changed the contents of the tarball too
[06:25]  * imbrandon loves upstream sometimes
[06:25] <minghua> Sounds pretty crappy upstream releasing work...
[06:25] <Hobbsee> ahh, it appaers they have changed some stuff
[06:28] <nxvl> imbrandon: did rudy soponsored your package?
[06:28] <Hobbsee> somerville33: btw, if you've removed debian/pyversions, arent i supposed to see the file removed, somewhere in the diff between that and current gutsy?
[06:28] <Hobbsee> er, hardy
[06:29] <imbrandon> nxvl: yup, it was just uploaded about ~15 minutes ago
[06:29] <Hobbsee> whatever we're developing for now
[06:29] <nxvl> imbrandon: nice, now the only thing missing is mi mail :D
[06:29] <imbrandon> nxvl: i'm actualy working on revising that now, i'll pm you in a half sec
[06:30] <somerville33> Hobbsee: Yea, I forgot to remove pyversions. As for the tarball, I didn't modify the tarball to not include debian/ from upstream like previous releases.
[06:31] <Hobbsee> somerville33: then why's it in the changelog?
[06:32] <somerville33> Hobbsee: A mistake. I'm reuploading.
[06:32] <Hobbsee> ah
[06:32] <somerville33> The new version does not contain debian/pyversions
[06:34] <Hobbsee> cool
[06:40] <Hobbsee> somerville33: oh, what does "  * debian/README.Debian: touched to rid ghost" mean?
[06:41] <minghua> Yay, ghost!
[06:41] <imbrandon> ghosts are cool, much better than clowns
[06:41]  * imbrandon hates clowns
[06:41] <imbrandon> nxvl: sleep well, long day tomarrow
[06:42] <imbrandon> :)
[06:42] <somerville33> Hobbsee: I removed README.Debian
[06:43] <somerville33> I suppose I should make that more clear
[06:43]  * Hobbsee fixes
[06:43] <somerville33> \o/
[06:45] <Hobbsee> ah yes, must set up the gpg agent.
[06:48] <Hobbsee> uploaded
[06:49] <imbrandon> persia: ok all fixed up and uploaded to debian ( apt-mirror ) , now to just wait to sync it, thanks for the feedback
[06:50] <imbrandon> i'm still pondering putting a debian/ubuntu specifc conf files in
[06:51] <somerville33> Hobbsee: You uploaded exaile for me?
[06:55] <somerville33> Hobbsee: I would have preferred if you had told me what changes I should have made instead of just signing the package yourself and uploading. I'm attempting to become a MOTU and having a list of my uploads on launchpad is handy when applying.
[06:57] <imbrandon> somerville33: you will still be listed as the uploader via the changelog, she just sponsored the package
[06:57] <imbrandon> e.g. it will still show up
[06:57] <somerville33> Not the way she did it
[06:57] <somerville33> https://edge.launchpad.net/ubuntu/+source/exaile
[06:58] <Hobbsee> somerville33: yes
[06:58] <Hobbsee> imbrandon: no, i had to modify it.
[06:58] <Hobbsee> somerville33: well, i had to sign it.  </pedant>
[06:58] <imbrandon> ahh ( you could have still left his name hehehe )
[06:58] <Hobbsee> imbrandon: i did a Riddell.
[06:58] <imbrandon> i seen :)
[06:59] <imbrandon> somerville33: aside from that you can stil list it individualy ( i did many packages like thta pre-MOTU )
[06:59] <imbrandon> that*
[07:00] <imbrandon> ahh 4 bugs closed tonight , i feel better
[07:02] <nand`> hiya! I'd like a review of the ike package please : http://revu.ubuntuwire.com/details.py?package=ike  (one ACK to go)
[07:19] <dholbach> good morning
[07:21] <Hobbsee> morning dholbach
[07:21] <Hobbsee> somerville33: you'll probalby end up getting enough stuff uploaded that it wont matter for one upload, btw
[07:21] <dholbach> hey Hobbsee
[07:23] <somerville33> Hobbsee: Well, hopefully you'll be able to give a good recommendation by that point ;]
[07:24] <imbrandon> moins dholbach
[07:24] <dholbach> heya imbrandon :)
[08:21] <imbrandon> ...
[08:21] <StevenK> ..
[08:23] <Hobbsee> LaserRock: ponies!
[09:17] <\sh> moins
[09:18] <\sh> if anyone is interessted in cool music created with just a guitar, a gameboy, a C64 and two creative guys, check out http://www.sourcecode.de/node/924 :) download of music for free under CC license :)
[09:20]  * proppy hugs dholbach
[09:20]  * dholbach hugs proppy back
[09:21] <\sh> Nstrike...ircii-pana aka bitchx is removed from debian :)
[09:22] <proppy> dholbach: up to a one Q&A question :) ?
[09:22] <dholbach> proppy: yeah :-)
[09:23]  * highvoltage hugs the entire *#motu* (Friday!)
[09:24] <warp10> Hi all!
[09:24] <proppy> dholbach: I see a bug status I was assigned change from In progress to Triaged
[09:24] <proppy> Is that a bad thing ?
[09:24] <proppy> :)
[09:24] <proppy> I mean I not very familiar with the "triaged" status
[09:25] <proppy> outside of the hospital context
[09:25] <proppy> It means "sorted" but sorted into what ?
[09:27] <dholbach> proppy: it means that the problem in the bug is well-understood, but that there's nothing to review yet
[09:27] <dholbach> if there is, it should be 'in progress'
[09:27] <proppy> oh ok
[09:27] <proppy> I see
[09:27] <proppy> :)
[09:27] <dholbach> I linked to the policy decision I guess
[09:28] <proppy> dholbach: you're right I forgot to read the header of the mail
[09:28] <dholbach> np
[09:28] <proppy> dholbach: sorry for the disturbance :)
[09:28]  * dholbach hugs proppy
[09:30] <proppy> let's turn in back to In progress then !
[09:31] <proppy> dholbach: If i understand correctly it's fine to turn in progress when there is on REVU for example ?
[09:32] <dholbach> yeah
[09:40] <proppy> if there is example in a tooklit library, IIRC then need to be packaged in a separate nonlib package ?
[09:40] <proppy> ex: libjuce, libjuce-dev, juce
[09:42] <tjaalton> any idea how to make a for loop in a makefile that updates a variable?
[09:44] <tjaalton> "@for pkg in $(PKG); do ENV="$(ENV) $$pkg"; done" doesn't work
[09:47] <mok0> Does someone have 10 minutes to help me with a merge?
[09:47] <mok0> I've never done it before
[09:47] <persia> mok0: Sure.  Which package?
[09:47] <mok0> eigen
[09:49]  * Fujitsu wonders how 60GiB of local mirror manages to evaporate.
[09:49] <persia> mok0: OK.  The first thing to check is to make sure the tarballs are the same.
[09:49] <mok0> I only have 1
[09:50] <mok0> eigen_1.0.5.orig.tar.gz
[09:50] <persia> mok0: From where did you get that?
[09:50] <mok0> grab-merge.sh
[09:50]  * persia grumbles about grab-merge.
[09:51] <persia> mok0: OK.  Do you have the .dsc file for the latest Ubuntu upload?
[09:51]  * mok0 shrugs
[09:51] <mok0> eigen_1.0.5-1ubuntu1.dsc
[09:51] <persia> You can compare that to the latest .dsc file for the latest Debian upload, to make sure that the md5sums for the orig.tar.gz matches.
[09:51] <mok0> ok
[09:52] <persia> Sometimes with -0ubuntuX to -1 there are tarball differences which make it tricky.
[09:52] <mok0> looks good
[09:52] <mok0> same md5
[09:53] <mok0> I'm confused by all the diff.gz's
[09:53] <persia> mok0: Great news: we can do this the simple way.  I usually ignore all the diff.gz files, as they never help me much for a merge.
[09:54] <mok0> OK
[09:54] <persia> Unfortunately, it looks like there is no "base" version for eigen, which again makes it a little harder, as we can't compare two branches to a common root.
[09:55] <mok0> I think there is a weirdness when interdiff -z debian ubuntu
[09:55] <persia> I'd start with `debdiff eigen_1.0.5-0ubuntu2.dsc eigen_1.0.5-1.dsc` to find out what is changing, and if there is anything being removed that we'd prefer.
[09:55] <mok0> It looks like the date of the initial release in changelog was changed
[09:56] <persia> mok0: We don't need interdiff, because the tarball is the same.  interdiff -z is rather verbose, and I generally recommend interdiff -z -p1 for human consumption.
[09:56] <persia> mok0: The initial release date change would be correct, as each represents an initial release for a specific distribution.
[09:57] <mok0> But it was changed in debian
[09:57] <mok0> relative to what J.Ridell started out with
[09:58] <persia> mok0: Based on http://packages.qa.debian.org/e/eigen.html, I don't see any change in Debian, just an upload.  An initial release in Ubuntu is not important to Debian.
[09:58] <persia> Looking at debian/copyright, it appears that the Ubuntu version was based off that of the Debian Maintainer anyway, so it oughtn't be much variation.
[09:59] <mok0> ok
[09:59] <mok0> eigen_1.0.5-1.patch is null
[09:59] <mok0> which is weird
[10:00] <persia> mok0: That's an artifact due to merges.ubuntu.com not being a perfect merger, it's currently a human-intelligence problem.
[10:00] <persia> Essentially, MoM gets confused if there is no base version from which to branch.
[10:01]  * mok0 's head just exploded
[10:01] <mok0> you know, it *should* build
[10:01] <persia> So, the only thing you need to do is decide whether the changes to debian/cdbs/cmake.mk and debian/cdbs/kde.mk are good changes.  If you think Debian is doing the right thing, you'll want a sync.  If you think they need tweaking for Ubuntu, you'll want to generate a merge.  Let me know which you decide, and I'll help you with the next step.
[10:02] <mok0> ok, thanks persia. I need to go to a seminar now, but I'll continue when I get back. Catch you later!
[10:04] <persia> mok0: Sure.
[10:14] <warp10> dholbach: Hi! Pitti told me there is an existing list of software which needs packaging for Ubuntu. Where is it?
[10:18] <persia> warp10: https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging contains a list of 480 items, some of which are in progress, but most of which need help.
[10:20] <warp10> thanks persia, I'll check it out. Anyway, probably pitti was spoking about another list somwehere on the internet (not in launchpad), but your link should be fine for my needs.
[10:20] <TheMuso> c
[10:20] <TheMuso> ugh wrong tab
[10:21] <persia> warp10: Daniel maintains a list of needs-packaging bugs that have been committed to REVU, but I don't think that's a good list for a packager to hit: it's more a list for reviewers.
[10:21] <persia> That list is at the bottom of http://people.ubuntu.com/~dholbach/sponsoring/
[10:22] <warp10> persia: ah, ok. Thank you :)
[10:32] <mok0> persia: grrr, the seminar is in 3 hrs
[10:32] <persia> mok0: And after you've gone down to find an empty room?  How annoying.
[10:32] <mok0> persia: wrt eigen, I think debian took over the ubuntu pacakge
[10:32] <mok0> persia: yes :-(
[10:33] <mok0> I think it can be synced
[10:33] <persia> mok0: I think Ubuntu grabbed a Debian pre-release, and Debian caught up.  Note the packaging at the bottom of debian/copyright.
[10:33] <mok0> the debian version still has the ubuntu mods
[10:34] <mok0> so what do you think?
[10:34] <mok0> in such a case we drop the ubuntu tag in release, right?
[10:35] <dholbach> nixternal: can you send "REVU: Accepted: ..." mails to ubuntu-motu@ next time?
[10:36] <dholbach> nixternal: I just came across kopete-plugin-thinklight and kwest - it'd be nice if we could track all the stuff that goes into NEW
[10:36] <persia> mok0: Generally, it's worth syncing in these cases.  I don't understand the reasons for the changes to the CDBS includes, and don't understand why they aren't being pulled by build-depends anyway.  If the Debian source builds properly, and generates a proper package, it is preferred.
[10:36] <mok0> I'll try to pbuilder it
[10:38] <mok0> Success
[10:39] <persia> mok0: That's a good start.  Next step would be to compare the dpkg --contents output of the two packages to make sure that things are going in the right places.
[10:39] <mok0> So, the ubuntu version to build is... ?
[10:40] <mok0> the old or the merged?
[10:40] <persia> mok0: If the Debian package is good, it's better to just file a bug requesting a sync.
[10:40] <persia> This bug needs to include information on the nature of the Ubuntu changes, the reason why they aren't required, and the Debian changelog since the last Ubuntu version (in this case, the entire changelog).
[10:42] <mok0> persia: the problem is, I can't reproduce those differences. When I unpack the source packages, there are no differences
[10:43] <persia> mok0: Really?  That's odd.  In that case, I'd just go for a sync.
[10:43] <mok0> persia: indeed
[10:44] <mok0> ... what a boring package to merge ;-) It's just a bunch of C++ header files, anyway....
[10:45] <mok0> persia: In fact, I don't know what the files in debian/cdbs/ are for...
[10:45] <persia> mok0: Aren't they included in debian/rules?
[10:46] <mok0> persia: yes
[10:46] <mok0> kde.mk ??? why is THAT there?
[10:46] <persia> I'd say they helped build the package then
[10:47] <persia> mok0: See, maybe you do want a merge, to use the normal kde.mk, and build-depend on the standard provider :)
[10:47] <mok0> persia: you mean fix the packaging bug?
[10:48] <mok0> I'll take a look
[10:48] <persia> mok0: Yep.  One of the things we try to do with merges is make sure that the Ubuntu packages are nice and clean.  It'd be nice to do that for everything, but it's especially important for Ubuntu versioned packages.
[10:50] <mok0> persia: but isn't it preferable with a sync? And perhaps to contact the debian packager with the change?
[10:51] <mok0> there is also a dependence on quilt, but no patches
[10:51] <persia> mok0: There's too schools of thought.  I believe we should just fix it, notify Debian, and hope for a future sync.  Others believe we should notify Debian and wait, and then do a sync.  As we don't support users at this point in the cycle, it doesn't really matter which school you join, although if you follow my opinion, you're promising to pay attention later.
[10:51] <persia> s/too/two/
[10:52] <mok0> persia: I'll try fixing it
[10:52] <mok0> persia: and go on with the merge.
[10:54] <persia> mok0: Thanks.  Just please watch Debian: if we can make a sync later (even after DIF) to reduce the Ubuntu variation, it will make it easier in the future.
[10:55] <mok0> persia: I'll ping you for the next step
[10:55] <persia> mok0: You'll likely do better to ask for help with the next step generally.  I'll answer if I'm around, but you shouldn't have to wait for me if I'm not :)
[10:56] <mok0> persia: sure, thx
[11:07] <proppy> I've got  a question about installing headers in a -dev packages
[11:07] <proppy> since the Makefile miss an install rule
[11:07] <proppy> I've to install the headers myself
[11:07] <proppy> the header are mixed with sources in a src/ subdirectory
[11:08] <proppy> the only command I know to mirror a directory tree with excluding some file is rsync
[11:08] <proppy> is it worth to add rsync as a build-depend for that ?
[11:09] <persia> proppy: No, you really want to do it with dh_install.
[11:09] <persia> dh_install accepts some arguments to exclude files, or can specify files to be included on an individual basis, as proves more convenient to you.
[11:10] <proppy> you mean dh_install when it don't rely on an .install file ?
[11:10] <proppy> s/don't/doesn't
[11:11] <persia> proppy: I think dh_install can do it either way, but I'll admit that the finer points of convincing dh_install to do the right thing are beyond me.  The manual page is a little confusing, but worth reading.
[11:12] <TheMuso> You also want to be sure that you are placing the header files where other packages would expect to find them when being built.
[11:12] <proppy> persia: reading it right now
[11:12] <proppy> TheMuso: yep there are no other package right now
[11:13] <proppy> TheMuso: but I guess creating a subdirectory for the whole library and adding a .pc file is fine doesn't it ?
[11:13] <TheMuso> proppy: Nevertheless, if you do intend to package other software that uses it, or even if not, I would still make sure you have it correct.
[11:13] <TheMuso> proppy: Yes that would work. Does other software exist that depends on this package yet?
[11:14] <persia> proppy: It's only good to have a private library if you know there will never be a client package.  Otherwise you end up with a mess like we have with firefox today.
[11:14] <proppy> TheMuso: I plan to release software I've done using this package
[11:14] <mok0> persia: I know what's going on now. Like you said, jridell took over a prerelease, which has since been put into Sid. The change in the debian/cdbs/ directory (which _is_ required) has to do with an update to KDE4. The debian changelog only contains the initial entry.
[11:14] <mok0> persia: so I think it's sync.
[11:15] <TheMuso> proppy: Ah ok.
[11:15] <persia> mok0: Excellent.  Good research.  Now, does it need a build-depends tweak and deletion of debian/cbds/kde.mk, or does a sync generate the right binary?
[11:15] <persia> mok0: Right.  Time skew.  Just create the sync bug then, and subscribe the sponsors.
[11:15] <LucidFox> dholbach, kwest was actually rejected from the queue, so setting the bug as "Fix Released" was a bit premature
[11:16] <mok0> ok, i'll do that
[11:16] <proppy> TheMuso: I know a few people who are using it for crossplateform apps
[11:16] <TheMuso> proppy: Ok.
[11:16] <dholbach> LucidFox: I misintepreted https://launchpad.net/ubuntu/+source/kwest then, sorry - could you add a link to the current source package and set back to 'in progress' please?
[11:16] <TheMuso> proppy: Just as long as they know how to reference the headers.
[11:16] <proppy> but everybody seems to rely on uncompressing the tarball
[11:17] <proppy> and directly fetch header from here
[11:18] <LucidFox> dholbach> sure
[11:18] <dholbach> LucidFox: you ROCK - thanks!
[11:20] <proppy> TheMuso: every code I've seen include it just like that include "juce.h" <juce.h>
[11:20] <TheMuso> proppy: Ok.
[11:20] <TheMuso> proppy: I didn't know it was new code for software that hadn't been developed yet.
[11:20] <TheMuso> I've just seen people screw up headers when the package didn't offer make install.
[11:22] <proppy> There is some software already developed for it, but no package since the base library is not packaged
[11:22] <proppy> nor installable
[11:29] <TheMuso> Meeting in 30 minutes...
[11:47]  * TheMuso wonders if the quietness of this channel reflects on the possible number of meeting attendees.
[11:48]  * \sh 's online ,-)
[11:51] <proppy> TheMuso: where ?
[11:51] <TheMuso> proppy: In #ubuntu-meeting in approx 10 minutes.
[11:52] <dholbach> MOTU Meeting in 8 minutes in #ubuntu-meeting
[11:52] <dholbach> :)
[11:53]  * TheMuso will be there, whilst poking some packages into line. :)
[11:54] <proppy> thanks
[11:57] <sistpoty|work> hi folks
[11:59] <sistpoty|work> motu meeting about to start in #ubuntu-meeting
[12:05] <highvoltage> what is SRU?
[12:06] <Hobbsee> !sru
[12:06] <ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[12:06] <highvoltage> aaah, thanks Hobbsee
[12:09] <highvoltage> !uvf
[12:09] <ubotu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
[12:09] <highvoltage> ah right.
[12:21] <rexbron> I have an issue with a debian upstream package that seemes to include patched sources in the diff.gz
[12:22] <Fujitsu> rexbron: What is said issue?
[12:22] <rexbron> as a result, when I try and build the package, the patch rule fails
[12:22] <rexbron> Fujitsu: It's the package gtk2-engines-murrine (which is in main)
[12:22] <Fujitsu> rexbron: Is it a patch that you added that fails to apply?
[12:23] <rexbron> Fujitsu: we sent a patch upstream and now have to merge the package as the debian maintainer does things different;y
[12:23] <Fujitsu> rexbron: You need to make the patch in debian/patches apply over whatever is in the rest of the source.
[12:24] <rexbron> Fujitsu: I am unfamiler with quilt, but it seemes that the source is not being unpatched when a source package is built
[12:24] <Fujitsu> rexbron: Oh dear... so all the patches are applied in the Debian .diff.gz?
[12:24] <rexbron> Fujitsu: it is only one patch, but still
[12:24] <rexbron> ugly
[12:25] <rexbron> as a result, trying to rebuild the source package fails
[12:25] <Fujitsu> rexbron: Has that patch perhaps been applied upstream?
[12:25] <rexbron> perhaps in SVN, but not in the latest release
[12:26] <Fujitsu> So Debian has done evil things. Nice of them.
[12:27] <Fujitsu> You'll have to either unpatch the actual files (probably clearn), or drop the patch from debian/patches.
[12:27] <Fujitsu> s/clearn/cleaner/, damn lag.
[12:28] <rexbron> Fujitsu: isn't dropping the patch unadviseable?
[12:29] <rexbron> Since this is a main package, i will take it up in -devel
[12:37] <TheMuso> Well that was short and sweet.
[12:37] <rexbron> Fujitsu: Now this is odd, when I try and unpatch it myself (using the command in the rules file) it does not work....
[12:37]  * TheMuso will get these two uploads done, then hit the sack.
[12:40] <effie_jayx> Hobbsee, :D
[12:40]  * persia celebrates the abolishment of ircii-pana from hardy
[12:40] <dholbach> MOTU Q&A Session in #ubuntu-classoom in 20 minutes
[12:40] <Fujitsu> persia: Yep... but we've got 4 releases of it left.
[12:40] <Fujitsu> All with the lovely security issues.
[12:40] <proppy> ircii-pana  ?
[12:40] <Fujitsu> proppy: aka bitchx.
[12:40] <proppy> !info ircii-pana
[12:40] <ubotu> Package ircii-pana does not exist in gutsy
[12:40] <persia> proppy: BitchX
[12:41] <Fujitsu> !info bitchx hardy
[12:41] <proppy> BitchX is bad ? :)
[12:41] <persia> Fujitsu: Yep.  At least one goes away in 5 months...
[12:41] <Fujitsu> proppy: Dead and full of security holes.
[12:41] <ubotu> bitchx: Advanced Internet Relay Chat client. In component universe, is optional. Version 1:1.1-4ubuntu4 (hardy), package size 1515 kB, installed size 6524 kB
[12:41] <Fujitsu> Nooooo, it's not dead yet!
[12:41]  * rexbron is really anoyed
[12:41] <persia> Fujitsu: Wait for the publisher run
[12:42] <DktrKranz> \sh, ming looking at tikiwiki at some point? It has *many* security fixes
[12:42] <rexbron> persia: Do you have experience with quilt
[12:42] <DktrKranz> s/fixes/issues/
[12:42] <Fujitsu> DktrKranz: Many? I doubt it. See wordpress and phpmyadmin.
[12:42] <persia> rexbron: Yes, but I've a bit of an immediate stack right now, aside from my queue.  The wiki patching guide has a nice example.
[12:43] <rexbron> persia: Does it show up in diff.gz?
[12:43] <persia>  rexbron: quilt patches should be in debian/patches in the diff.gx
[12:43] <DktrKranz> Fujitsu, didn't check these two, but upstream developers mailed me a looooong list of vulns
[12:43] <rexbron> persia: ok, time it yell at the debian maintainer
[12:43] <Fujitsu> DktrKranz: Are there more than the six CVEs that I see?
[12:44] <Fujitsu> DktrKranz: wordpress has 42, for comparison.
[12:44] <DktrKranz> Fujitsu, IIRC, they released two security releases recently
[12:44] <DktrKranz> don't know exactly how many CVEs are involved, though
[12:45] <DktrKranz> 42? Yay! Is wordpress branded Micros...omething? :D
[12:45] <proppy> hi norsetto!
[12:45] <norsetto> so, where is this fantastic Q&A session everybody is speaking of?
[12:45] <norsetto> heya proppy
[12:45] <proppy> norsetto: you've just missed the meeting !
[12:46] <highvoltage> hey norsetto
[12:46] <Fujitsu> DktrKranz: wordpress should die die die.
[12:46] <highvoltage> what's wrong with wordpress?
[12:46] <norsetto> highvoltage: hi there. Did you see the last mail from dholbach?
[12:46] <DktrKranz> no, my poor blog :(
[12:46]  * Fujitsu wonders how many times more vulnerabilites the PHP webapps have over the total of the rest of the archive.
[12:46] <highvoltage> norsetto: let me check...
[12:47] <Fujitsu> highvoltage: It has so many security vulnerabilities it is really not funny.
[12:47] <DktrKranz> what about phpBB?
[12:47] <Fujitsu> DktrKranz: That's not good either.. let me check.
[12:47] <Fujitsu> Just the 20 for it.
[12:47] <Fujitsu> And I haven't triaged them yet.
[12:47] <highvoltage> Fujitsu: ouch. i run wordpress too :(
[12:48] <DktrKranz> mh...
[12:48] <DktrKranz> not many, if compared with WP
[12:48] <Fujitsu> Looks like they'll all affect at least Dapper, though.
[12:48] <Fujitsu> Except for one or two.
[12:48] <Fujitsu> DktrKranz: phpmyadmin has 22.
[12:48] <highvoltage> win 36
[12:48] <Fujitsu> drupal 25...
[12:48] <Fujitsu> (there are a bit less than 1000 overall)
[12:48] <\sh> DktrKranz, sure...can you give me a list of CVEs ? :)
[12:49] <DktrKranz> \sh, of course :)
[12:49] <persia> Right.  It's not woth a competition.  They're all bad: the competition is to see who can get to 0 first :)
[12:49] <Fujitsu> So those 4 alone make up more than 10% of the total...
[12:49] <\sh> hehe
[12:49] <\sh> there are some packages which we can't fix...and sometimes I think it's not worth the time
[12:49] <DktrKranz> heh, I think it's easier to fix bug #1 than having webapps 0 CVEs
[12:49] <ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
[12:49] <Fujitsu> persia: The solution seems to be to ban people who write PHP webapps.
[12:50] <persia> Fujitsu: Maybe, or perhaps to ban PHP webapps?
[12:50] <\sh> especially the php stuff...it's broken by default somehow, and seeing many php projects to releasing any patches for those issues, but new versions is quite difficult to follow up
[12:50] <highvoltage> Fujitsu: yeah!
[12:50] <Fujitsu> persia: Possibly, but they'll probably take their coding practises to other languages.
[12:50]  * TheMuso finally kills off another merge.
[12:50] <highvoltage> Fujitsu: you'll write me a django/turbogears based blog, right? :)
[12:50] <Fujitsu> \sh: phpmyadmin is a whole lot better, but the rest are terrible.
[12:50] <persia> Fujitsu: Maybe.
[12:51] <\sh> other projects like drupal are quite good...but not all versions in our archives can be fixed as well...
[12:51] <Fujitsu> Quite a number of the wordpress CVEs mention that it's quite conceivably a PHP bug, but they can't tell. That's not encouraging.
[12:51] <DktrKranz> \sh. Gotta go right now. Mind if I forward you tikiwiki developers' mail?
[12:51] <\sh> Fujitsu, we need some fixes to php4 in dapper...there is a hell of a lot crap
[12:51] <\sh> DktrKranz, sure, please do sh@sourcecode.de
[12:52] <Fujitsu> \sh: Note that php4 officially dies in a month.
[12:52] <DktrKranz> \sh, I will flood your mail again :)
[12:52] <\sh> Fujitsu, right, but we have it in dapper and we should fix it somehow ;)
[12:52] <DktrKranz> See you later :)
[12:52] <norsetto>  proppy: did I miss anything interesting?
[12:52] <\sh> btw..if you need some nice music while you are doing some work on universe, follow the green signs at http://www.sourcecode.de/content/cool-music-revealed :)
[12:53] <\sh> dholbach, it's also something for you as DJ :)
[12:53] <Fujitsu> Oh, I see that drupal5 is actually up-to-date with fixes in Gutsy. I didn't notice, because of that removed Soyuz feature.
[12:53] <\sh> Fujitsu, yepp...:)
[12:54] <\sh> Fujitsu, I added some fixes to it
[12:54] <\sh> oh no...i did that for feisty
[12:54] <\sh> feisty should be up2date in a few, when I get the "approved" mail from our security team
[12:54] <Fujitsu> \sh: Which releases does bug #162385 affect?
[12:54] <ubotu> Launchpad bug 162385 in drupal5 "[Security] Several Security Issues for drupal 5.x before 5.3" [Undecided,In progress] https://launchpad.net/bugs/162385
[12:55] <Fujitsu> Just Feisty?
[12:56] <\sh> Fujitsu, feisty
[12:57] <huats> hello everybody
[12:57] <\sh> Fujitsu, jepp..in gutsy it was geser who fixed it
[12:57] <\sh> Fujitsu, for the 4.x releases I still have to check...but most likely it's "un"fixable
[12:59] <persia> mok0: You need to include the debian changelog in a sync request description :)
[12:59] <\sh> Fujitsu, what about bug #162296, in hardy and debian it's removed on my request (debian removed it on my request)
[12:59] <ubotu> Launchpad bug 162296 in ircii-pana "CVE-2007-4584 stack based buffer overflow via long MODE command" [Medium,Confirmed] https://launchpad.net/bugs/162296
[12:59] <Fujitsu> \sh: I really don't know. It will just have to be left to rot, I guess.
[12:59] <\sh> Fujitsu, and reading the bug report from debian it won't be fixed in the future...
[12:59] <persia> \sh: It's fixed in hardy: the other releases are a little harder.
[13:00] <proppy> norsetto: ~SRU team is back | but not merged with ~uvf | then will be a special meeting for security issue | and dholbach will figure about timezone issue
[13:00] <\sh> persia, you mean bitchx? in hardy it's removed :)
[13:00] <proppy> but I may have got it completly wrong
[13:00] <persia> \sh: Yes, yes, and thank you :)
[13:01]  * norsetto hugs proppy, the best meeting's digest he has ever met
[13:01] <\sh> persia, don't thank me, but thank debians ftpmaster != elmo
[13:01] <\sh> where is motu-faq session now?
[13:01] <Fujitsu> Ideally we send an email to our universe security announcement list notifying people of impending doom from continuing to use bitchx.
[13:01] <persia> \sh: I thought you requested it, but thanks also go to elmo and pitti :)
[13:02] <persia> \sh: #ubuntu-classroom
[13:02] <\sh> persia, yeah...after talking to nion who agreed that's better to remove it without having a living upstream
[13:03] <TheMuso> Ok, packages uploaded, I'm off to bed.
[13:03] <TheMuso> Night folks.
[13:03] <\sh> Fujitsu, what about a transitional package of ircii-pana with depends on irssi ? ;)
[13:03] <Fujitsu> Night TheMuso.
[13:03]  * Fujitsu goes too.
[13:03] <\sh> Fujitsu, for releases before hardy
[13:04] <Fujitsu> \sh: That is evil and Kees would murder you.
[13:04] <\sh> Fujitsu, I think so ;)
[13:04] <Fujitsu> Anyway, night all.
[13:05] <Fujitsu> Tomorrow is security update and working out what ate my mirror and what else it ate day.
[13:05] <persia> night Fujitsu
[13:05] <Fujitsu> Night persia
[13:06] <propeat> night
[13:39] <pochu> does someone remember where the ubuntu logo fonts are? Or what the package is called?
[13:40] <persia> pochu: ttf-ubuntu-title maybe?
[13:45] <pochu> persia: looks like, thanks :)
[13:45] <pochu> yeah that is
[13:51] <proppy> just uploaded juce to REVU: http://revu.tauware.de/details.py?package=juce
[14:01] <effie_jayx> well
[14:01] <effie_jayx> I gotta get back to the conference
[14:01] <effie_jayx> tonigh I will hack another bug
[14:01] <huats> norsetto: my dear friend how are you ?
[14:01] <effie_jayx> and be as thorough as I was in lesson 5
[14:02] <norsetto> huats: hey, como on in the classroom
[14:02] <nenolod> juce on revu contains files outside of debian
[14:02] <nenolod> this is a bad practice. please don't do it ;)
[14:02] <huats> norsetto: it is over, I think
[14:02] <nenolod> proppy, ^^
[14:02] <proppy> nenolod: strange let me take a look
[14:03] <huats> norsetto: you were again looking by the window, and not listening the master dholbach
[14:03] <huats> :)
[14:03] <dholbach> master...? pffft :)
[14:03] <proppy> nenolod: thanks it was my fault I forget to clean the dir before building :)
[14:04] <huats> dholbach: jono  said once : "with daniel the packaging Master"... I am just repeating :D
[14:04] <nenolod> proppy, also, you should try to shoot for debian inclusion too
[14:04] <nenolod> </usual line>
[14:04] <proppy> nenolod: you mean uploading it to mentors at the same times ?
[14:05] <nenolod> proppy, right
[14:05] <proppy> nenolod: ok
[14:10] <norsetto> stdin: all are kde 4 packages in gutsy-backports already?
[14:10] <stdin> norsetto: no, just kdelibs and kdepimlibs so far (i think)
[14:11] <norsetto> stdin: ok, thanks!
[14:14] <proppy> how should I bump REVU upload ?
[14:14] <proppy> I mean should I increase a version number somehow
[14:14] <norsetto> proppy: doh?
[14:14] <norsetto> proppy: just upload it
[14:14] <proppy> like juce-0ubuntu1~revu0 ?
[14:15] <proppy> juce-0ubuntu1~revu1
[14:15] <proppy> ?
[14:15] <norsetto> proppy: keep it at the same version number, no need to change it for revu
[14:15] <proppy> norsetto: yes but it's hard to figure which upload we are talking about if the same version if overwritten ?
[14:15] <proppy> oh ok
[14:15] <proppy> then forcing the dput should be fine
[14:15] <proppy> maybing I confusing myself with ppa practices
[14:16] <norsetto> proppy: yes, use dput -f, or remove the .upload file
[14:17] <proppy> recommended pastebin commandline client ?
[14:17] <Pici> pastebinit?
[14:18] <proppy> thanks
[14:22] <proppy> by default poastebinit rely on the unavailable http://paste.stgraber.org :)
[14:23] <persia> proppy: You've hit the MOTU ideal: recursive patch requirements :)  Patch that to point at paste.ubuntu.com, and submit your paste :)
[14:26] <proppy> persia: will be glad to do that just after my revu upload :)
[14:28] <proppy> arg doesn't know if it supports paste.ubuntu.com :)
[14:30] <stgraber> proppy: you can -b http://pastebin.com
[14:30] <stgraber> proppy: unfortunately I'm not the one managing paste.stgraber.org (even if that's on my domain), I'll probably host one myself if the website isn't back shortly
[14:31] <proppy> stgraber: yep I just tried that :)
[14:38] <mok0> Does someone have time to help me with some merge questions
[14:47] <norsetto> mok0: yes?
[14:57] <mok0> norsetto: I
[14:58] <mok0> norsetto: I found a conflict in the control file, and fixed it. Should I change DaD's entry in changelog with my own?
[14:58] <norsetto> mok0: you should always do that
[14:59] <mok0> norsetto: OK. Then, I test the package in a hardy pbuilder, yes?
[14:59] <norsetto> mok0: yes
[14:59] <mok0> ... and upload to... ?
[14:59] <bluekuja> mok0, make a debdiff
[15:00] <bluekuja> and open a bug report
[15:00] <bluekuja> against the package you are merging
[15:00] <mok0> A debdiff on the source package?
[15:00] <bluekuja> a debdiff between the new ubuntu package and the debian one
[15:00] <bluekuja> new Ubuntu package (your one)
[15:01] <bluekuja> mok0, that's explained around in the docs anyway
[15:01] <mok0> I'll have a go at it
[15:01] <mok0> ... and have another look at the docs.
[15:01] <bluekuja> mok0, when the debdiff is ready, just open a bug where you report any information needed
[15:02] <bluekuja> then subscribe u-u-s
[15:02] <mok0> bluekuja: ok, will do. I've done that before
[15:02] <bluekuja> mok0, fine. so why do you ask <mok0> ... and upload to... ?
[15:02] <bluekuja> :)
[15:03] <mok0> Because I wasn't sure whether to upload the source package to REVU for review
[15:03] <bluekuja> is it a new upstream release?
[15:03] <bluekuja> or just a merge?
[15:03] <mok0> Merge
[15:03] <bluekuja> REVU is not needed then
[15:03] <mok0> OK
[15:04]  * mok0 thinks a picture of the process is starting to take form in his brain
[15:04] <bluekuja> ^^
[15:04] <mok0> :)
[15:04] <bluekuja> mok0, you should read about "how to report a sync request" as well
[15:04] <bluekuja> I've commented one of yours before..
[15:05] <mok0> I did it wrong?
[15:05] <bluekuja> yes
[15:05] <bluekuja> check it out
[15:05] <mok0> Yike
[15:05] <mok0> s
[15:05] <bluekuja> and fix it
[15:05] <mok0> ok, it's the eigen package, right?
[15:05] <bluekuja> yep
[15:06] <mok0> OK, I'll do that. Whew, there is lots to learn about this workflow
[15:07] <mok0> They should have an option over at LP, so you could just click: "This is a sync request"
[15:07] <bluekuja> ^^
[15:07] <bluekuja> it's impossible to have
[15:07] <bluekuja> a rationale changes between package and package
[15:08] <mok0> Hmm
[15:08] <mok0> If you say so...
[15:08] <mok0> I though computers were supposed to be smart ;-)
[15:09] <mok0> thought
[15:09] <bluekuja> yep, but for this case we need manual changes
[15:10] <mok0> Errr, not if you just want to sync debians version and throw away ubuntus??
[15:10] <bluekuja> sorry?
[15:10] <bluekuja> every sync needs a rationale
[15:11] <mok0> Debian has a new version of the package that compiles perfectly and needs no specific customization
[15:11] <bluekuja> (you don't need a rationale if the package is NEW)
[15:11] <Hobbsee> bluekuja: every drop of ubuntu changes needs a rationale - not every sync.  </pedant>
[15:11] <mok0> it's the same version
[15:11] <Hobbsee> gh
[15:12] <mok0> Debian started to distribute the same version
[15:12] <bluekuja> Hobbsee, yes, but I was right as well. Every sync *request* need a rationale (apart from NEW)
[15:12] <bluekuja> Hobbsee, I forgot to add "request"
[15:13]  * mok0 checks out LP
[15:14] <mok0> Yrrk
[15:14] <mok0> bluekuja: you want those changelog details in the bug report
[15:14] <bluekuja> yes
[15:14] <bluekuja> Hobbsee, is that what you mean?
[15:14] <mok0> ... and the build log?
[15:15] <bluekuja> mok0, what?
[15:15] <mok0> attach the build log, I guess
[15:15] <Hobbsee> bluekuja: not really.  you dont actually need a rationale to request a sync - assuming it doesnt get hit by feature freeze and friends
[15:15] <bluekuja> yes, it's written in my comment
[15:15] <Hobbsee> you need a rationale on why any ubuntu changes can be dropped, though
[15:15] <bluekuja> Hobbsee, agreed
[15:15] <Hobbsee> bluekuja: your statement falls over when you request a sync with no ubuntu changes after DIF.
[15:16] <mok0> There were never any ubuntu changes in this package
[15:16] <bluekuja> mok0, you should write that then
[15:16] <mok0> It was grabbed from debian before released
[15:16] <Hobbsee> bluekuja: (because you don't need a rationale for that, but by your logic, you do)
[15:16] <bluekuja> you can't assume me to know it
[15:17] <mok0> bluekuja: I thought I wrote that?
[15:17] <bluekuja> Hobbsee, exactly, plus a package gets synced automatically if there are no ubuntu changes, right?
[15:17] <bluekuja> Hobbsee, I mean at a new revision/release
[15:17] <bluekuja> mok0, no
[15:18] <bluekuja> mok0, write things clearer
[15:18] <mok0> bluekuja: ok I'll do my best
[15:18] <bluekuja> mok0, thanks
[15:18] <Hobbsee> bluekuja: until debian import freeze, yes.  after that, no.
[15:18] <bluekuja> Hobbsee, exactly
[15:18] <Hobbsee> which is why your statement wasnt' really correct.  </pedant> :)
[15:19] <bluekuja> lol
[15:19] <mok0> Hobbsee, bluekuja: ping me when you come to an agreement ;-)
[15:19] <bluekuja> mok0, add a build log
[15:19] <Hobbsee> mok0: the agreement was that i was correct, and that bluekuja needed to change his opinion.  this is simple :)
[15:19] <Hobbsee> mok0: at the moment though, as everything's still autosyncing, the point is moot.
[15:19] <bluekuja> mok0, if there are no changes, *write* it
[15:20] <bluekuja> mok0, and as Hobbsee said, it should be autosynced now
[15:20] <mok0> bluekuja: So dont be verbose?
[15:20] <bluekuja> mok0, question here is....why the package is not autosynced?
[15:20] <bluekuja> mok0, no Ubuntu changes, no DIF
[15:21] <bluekuja> so why do you ask for a sync?
[15:21] <mok0> Because it existed in a 0ubuntu1 release
[15:21] <mok0> now it becomes available with tiny changes
[15:23] <mok0> It's just a bunch of C++ header files
[15:25] <bluekuja> mok0, the section is different from the one added by riddel
[15:25] <bluekuja> mok0, actually debian has libs
[15:26] <bluekuja> and Riddell added libdevel
[15:26] <bluekuja> Riddell, what do you think about eigen sync?
[15:26] <mok0> bluekuja: I don't follow. Is that important?
[15:27] <bluekuja> mok0, actually Riddell manually changed the section from libs to libdevel
[15:27] <bluekuja> mok0, Debian has libs
[15:27] <Riddell> bluekuja: (without looking at the situation) I'm for syncing it
[15:27] <bluekuja> mok0, if we sync this, the package will get into libs again
[15:28] <bluekuja> Riddell, your last change can be dropped then?
[15:28] <bluekuja> Riddell, the section one
[15:28] <mok0> I can't see Riddell's response
[15:28] <bluekuja> mok0, huh?
[15:28] <Riddell> bluekuja: that was just to please the archive admin
[15:29] <bluekuja> Riddell, ok, fine. I gonna ack it then
[15:29] <bluekuja> thanks for answering
[15:29] <Riddell> can't remember if I poked debian about that, but I can do so again
[15:29] <bluekuja> yes, it would be great
[15:29] <bluekuja> :)
[15:30] <Ubulette> bluekuja, ahh, you're back :)
[15:30] <bluekuja> Ubulette, heya :)
[15:30] <mok0> bluekuja: so I'm off the hook?
[15:30] <Ubulette> bluekuja, any progress with seamonkey ?
[15:30] <bluekuja> Ubulette, thanks for reminding it, I think I gonna process it now
[15:30] <Ubulette> bluekuja, if not, don't worry, i can ask someone else
[15:30] <Ubulette> oh, good
[15:31]  * bluekuja grabbing reminder mail from Ubulette 
[15:31] <bluekuja> mok0, let's wait Debian for that
[15:31] <bluekuja> mok0, Riddell gonna forward the request
[15:32] <bluekuja> mok0, so we can sync the package with his latest change as well
[15:32] <bluekuja> mok0, maybe add a comment about that
[15:32] <bluekuja> and don't subscribe u-u-s until a new revision gets uploaded in Debian
[15:32] <bluekuja> Ubulette, something changed in the branch?
[15:32] <Ubulette> no
[15:32] <bluekuja> k
[15:33]  * mok0 wipes sweat from forehead
[15:33] <bluekuja> :D
[15:33] <Ubulette> bluekuja, just pull to be sure, i don't remember where you stopped
[15:33] <bluekuja> ok
[15:34] <bluekuja> Ubulette, please give me the exactly branch url
[15:34] <bluekuja> instead of LP one
[15:34] <bluekuja> so I can branch it directly
[15:34] <Ubulette> that's the one
[15:34] <bluekuja> I mean http://bazaar.launchpad.net/~mozillateam/seamonkey/seamonkey-1.1.dev
[15:34] <bluekuja> give me this next time
[15:34] <Ubulette> https://code.edge.launchpad.net/~mozillateam/seamonkey/seamonkey-1.1.dev
[15:34] <Ubulette> oh
[15:35] <bluekuja> yes, that's what you gave me
[15:35] <bluekuja> :)
[15:36] <Ubulette> you're picky. it's in the header ;)
[15:36] <bluekuja> hehe
[15:37] <bluekuja> Ubulette, is it the NEW iceape in fact?
[15:37] <Ubulette> eh?
[15:38] <bluekuja> which package does it replace?
[15:38] <Ubulette> iceape but only in hardy so far
[15:38] <bluekuja> k
[15:38] <Ubulette> no decision taken for gutsy as of today
[15:39] <Ubulette> let's wait for asac and gnomefreak to be back to discuss what's best for gutsy
[15:40] <bluekuja> okk
[15:40] <bluekuja> Ubulette, I'm building it
[15:40] <bluekuja> It will take 30 mins I guess
[15:40] <bluekuja> as alwais
[15:40] <Ubulette> more like 50m ~ 1h depending on how fast your box is
[15:41] <bluekuja> ah damn :/
[15:43] <mok0> bluekuja: how can I conveniently see when a new package becomes available from debian?
[15:43] <mok0> bluekuja: I added a comment at LP
[15:43] <bluekuja> mok0, it should appear in mom or dad automatically
[15:44] <mok0> Ah, ok
[15:44] <bluekuja> mok0, if there are no changes it gets synced
[15:44] <bluekuja> as we said before
[15:44] <bluekuja> before DIF
[15:44] <bluekuja> after DIF everything is blocked
[15:44] <mok0> But there will be changes
[15:44] <bluekuja> huh?
[15:45] <bluekuja> mok0, for eigen?
[15:45] <mok0> yes
[15:45] <bluekuja> mok0, debian should change the section
[15:45] <bluekuja> to libdevel
[15:45] <bluekuja> and upload a new revision, which will be synced here
[15:45] <mok0> yes, but there are a couple of other minor things that don't matter
[15:45] <bluekuja> mok0, like?
[15:45] <mok0> ubuntu changelog gets zapped
[15:47] <mok0> because there is no common base version
[15:48] <bluekuja> mok0, actually I think it doesnt matter since the only changes will be pushed inside Debian
[15:49] <bluekuja> I don't think the changelog will be zapped for Ubuntu, Hobbsee can you confirm?
[15:49] <proppy> I don't manage to overwrite my upload on REVU
[15:50] <proppy> http://revu.tauware.de/details.py?package=juce
[15:50] <bluekuja> mok0, and if you check other packages synced, you'll see they still have Ubuntu changelogs
[15:50] <mok0> the ones that come from debian?
[15:50] <bluekuja> yep
[15:50] <mok0> They sync against ubuntu??
[15:50] <bluekuja> mok0, no
[15:50] <geser> bluekuja: no, Debian changelogs don't have Ubuntu entries
[15:50] <proppy> let's try again
[15:51] <bluekuja> geser, who said that?
[15:51] <geser> but LP stores the old changelogs
[15:51] <bluekuja> geser, and anyway some package got Ubuntu entries
[15:51] <bluekuja> in Debian
[15:51] <geser> bluekuja: I haven't seen much Debian changelogs (from Debian) with Ubuntu entries
[15:51] <bluekuja> I've heard about it in -devel some days ago
[15:51] <mok0> the problem is, ubuntu version has no debian base version
[15:51] <bluekuja> geser, I just said "and if you check other packages synced, you'll see they still have Ubuntu changelogs"
[15:51] <bluekuja> geser, in fact that LP stores old entries
[15:52] <mok0> bluekuja: a diff3 only works if there is a common base
[15:52] <bluekuja> mok0, anyway I don't see the problem here
[15:52] <mok0> there isn't in this case
[15:52] <mok0> Well, mom can't resolve the conflict that comes
[15:53] <proppy> what is the REVU rotate time ?
[15:53] <proppy> 15min ?
[15:53] <bluekuja> geser, other packages synced = from Debian to Ubuntu
[15:53] <bluekuja> geser, maybe you misunderstood me :)
[15:53] <bluekuja> mok0, so?
[15:54] <bluekuja> mok0, if ubuntu entries gets zapped
[15:54] <bluekuja> we just sync the package, that will be the same for both distros
[15:54] <geser> bluekuja: if the Debian maintainer didn't include the Ubuntu entries (which is seldom) then the changelog inside the (new) debs don't have them anymore
[15:54] <mok0> bluekuja: I'll wait and watch when the update comes. Then we can deal with it :-)
[15:54] <proppy> oups I was uploading tu upload.ubuntu.com instead of REVU
[15:54] <proppy> :)
[15:54] <bluekuja> geser, so LP doesnt store old entries?
[15:55] <geser> LP has them (more or less) but not the debs
[15:55] <bluekuja> geser, yes
[15:55] <bluekuja> geser, binaries dont have them
[15:55] <bluekuja> but LP yes
[15:55] <bluekuja> that's what we mean actually
[15:56] <bluekuja> mok0, agreed
[15:58] <mok0> bluekuja: cool. Hey it was fun
[15:58] <bluekuja> mok0, are you sure about what you just said? :)
[15:58] <mok0> Sure. I'm trying to do another merge, now :-D
[15:59] <bluekuja> lol
[16:00] <proppy> juce updated on REVU: http://revu.tauware.de/details.py?package=juce
[16:08] <proppy> nenolod: on mentors as well :)
[16:12] <mok0> hehehe xtide builds in my brand-new hardy pbuilder...
[16:12] <lamont> persia: send me email with the details of the package that needs some bootstrapping love, and I'll see what can be done
[16:15] <mok0> Normally, can the automatic merge cope with diffs in the control file, where Maintainer -> XSBC-Original-Maintainer??
[16:17] <norsetto> proppy: do you build your packages before uploading to revu?
[16:17] <proppy> debuild -S -sa
[16:17] <proppy> on my workstation
[16:17] <proppy> and debuild -us -uc remotly
[16:17] <proppy> on http://juce.aminche.com/
[16:18] <norsetto> proppy: dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[16:19] <norsetto> proppy: you know why?
[16:19] <proppy> norsetto: it is because of (proppy) in the changelog ?
[16:20] <norsetto> proppy: yes, and the maintainer doesn't have an ubuntu address
[16:20] <proppy> maintainer should be MOTU ?
[16:20] <proppy> and originial maintainer me ?
[16:20] <proppy> just like if my package was uploaded to debian and patched in ubuntu ?
[16:20] <norsetto> proppy: yes
[16:20] <proppy> but about the (proppy) thing
[16:21] <proppy> my gpg data are looking for something like that
[16:21] <proppy> in the changelog
[16:21] <norsetto> proppy: ah, didn't get that before, no, the changelog has an ubuntu number
[16:21] <geser> mok0: depends
[16:21] <norsetto> proppy: don't worry about the (proppy)
[16:22] <proppy> norsetto: ok
[16:22] <proppy> norsetto: so I can leave it as this ?
[16:22] <norsetto> proppy: don't upload a new one yet, let me check further
[16:22] <proppy> norsetto: ok
[16:22] <geser> mok0: sometimes you get a conflict there, and sometimes not, depends if some other changes were also made (like updated Build-Depends)
[16:22] <norsetto> proppy: the (proppy) yes, but the maintainer no, you need to change it
[16:27] <norsetto> proppy: can you add a final separate line to the Description, that differentiate between the two binary packages? Something like "This package contains the development libraries and headers"for the -dev, etc.
[16:28] <proppy> you mean in the -dev description: add this line "This package contains the development libraries and headers"
[16:28] <proppy> ?
[16:29] <norsetto> proppy: for your -dev, it could be a good idea to have it Provides and Conflicts with libjuce so that you only have one -dev at a time installed (unless you want more, then you need to change the name)
[16:30] <proppy> norsetto: http://hg.juce.aminche.com/rev/6419365cb4c5
[16:30] <norsetto> proppy: I guess that libjuce should be libjuce0?
[16:31] <proppy> norsetto: http://hg.juce.aminche.com/rev/644d2d7e1b78
[16:32] <norsetto> proppy: better as a separate line (use .)
[16:32] <proppy> (05:29:27 PM) norsetto: proppy: for your -dev, it could be a good idea to have it Provides and Conflicts with libjuce so that you only have one -dev at a time installed (unless you want more, then you need to change the name) I'm not sure do get this
[16:32] <norsetto> proppy: ok, whats the problem?
[16:33] <proppy> how can libjuce-dev depends on libjuce and confligt with it at the same time ?
[16:34] <norsetto> proppy: as I said, that because your name is wrong
[16:35] <norsetto> proppy: should be libfooX, where X is the soname
[16:35] <proppy> oh ok
[16:36] <proppy> I don't understand this part
[16:36] <proppy> what is the soname ?
[16:36] <norsetto> ah ....
[16:36] <proppy> how can I get more that one installed at a time
[16:36] <proppy> I thought 0 and 1 suffix were related to ABI changes
[16:37] <proppy> i.e: if c++ abi change you want a package name change and the conflict provide thing
[16:37] <proppy> to make sure every you revert-depends get updated
[16:37] <proppy> but It seems I get it completly wrong
[16:39] <norsetto> proppy: yes, the soname should be the same if there is no ABI change
[16:40] <norsetto> proppy: the soname (what you call the 0 and 1 suffix) is an information stored inside the shared library
[16:40] <norsetto> proppy: you can see it with an objdump command for instance
[16:40] <norsetto> proppy: wanna check some shared libraries you have installed?
[16:40] <proppy> norsetto: who set it ?
[16:41] <norsetto> proppy: upstream, its not distribution dependant
[16:41] <norsetto> proppy: some sonames are a bit complex (openssl for instance)
[16:41] <proppy> norsetto: I'm compiling the .so from debian/rules
[16:42] <norsetto> proppy: yes, thats beacause the upstream makefiles don't do that, right?
[16:42] <proppy> norsetto: yep
[16:43] <proppy> norsetto: how I can rigure the so name using objdump objdump -x ?
[16:43] <norsetto> proppy: let me check the man page
[16:43] <norsetto> proppy: well, just a grep should do
[16:43] <mok0> Heh, I've done another merge.
[16:43] <norsetto> proppy: objdump -p file | grep SONAME I think
[16:45] <norsetto> proppy: try this (you should have this lib) objdump -p /usr/lib/libgstreamer-0.10.so.0.13.0 | grep SONAME
[16:46] <norsetto> proppy: you should see  SONAME      libgstreamer-0.10.so.0 (0 is the soname version number)
[16:46] <proppy> ok
[16:46] <proppy>   SONAME      libgstreamer-0.10.so.0
[16:46] <proppy> I don't see it in juce
[16:47] <norsetto> proppy: yes, because you are trying to be upstream
[16:47] <proppy> I think I'm missing a part of it
[16:48] <proppy> is this an arbitrary number ?
[16:48] <proppy> or is there a meaning attached to it ?
[16:48] <norsetto> proppy: try objdump -p file | grep NEEDED
[16:48] <proppy> norsetto: http://paste.ubuntu.com/2168/
[16:49] <norsetto> proppy: ok, you see these are all sonames
[16:49] <proppy> yep
[16:49] <proppy> norsetto: but what do they mean ?
[16:49] <proppy> is that some kind of versionning thing ?
[16:49] <norsetto> proppy: yes, its mainly abi compatibility
[16:49] <proppy> http://en.wikipedia.org/wiki/Soname
[16:49] <proppy> ok
[16:51] <norsetto> proppy: but it seems to me that you are trying to cover upstream there, which I don't think its correct
[16:52] <norsetto> proppy: to tell you the truth, I don't think your package will be accepted on this ground
[16:53] <proppy> norsetto: for generating the so file ?
[16:53] <proppy> how is the soname choosen ?
[16:53] <norsetto> proppy: how would I know? I only know the packaging side of things
[16:54] <norsetto> proppy: and not much of that too ....
[16:54] <geser> proppy: by upstream, usually starting at 0 and increased if API/ABI changes
[16:54] <proppy> ok
[16:54] <proppy> geser: it's a g++ flags ?
[16:54] <geser> that's where my knowledge ends
[16:55] <proppy> norsetto:  (05:29:27 PM) norsetto: proppy: for your -dev, it could be a good idea to have it Provides and Conflicts with libjuce so that you only have one -dev at a time installed (unless you want more, then you need to change the name)
[16:55] <proppy> norsetto: how can I have more than one -dev at a time on my system ?
[16:55] <norsetto> proppy: if you name them with the soname version number
[16:55] <proppy> I guess it's a linkflags
[16:55] <proppy> ok
[16:55] <norsetto> proppy: like libjuce0-dev etc.
[16:56] <proppy> norsetto: but -dev package usually don't change with soname right ?
[16:56] <norsetto> proppy: some do
[16:56] <proppy> norsetto: how ok
[16:56] <dholbach> have a great weekend everybody!
[16:56] <proppy> dholbach: seeya
[16:56] <norsetto> dholbach: rock well!
[16:56] <dholbach> rock on! :-)
[16:56] <proppy> You should be able to pass "-soname=name" to the linker yourself,
[16:56]  * dholbach hugs y'all
[16:57] <norsetto> proppy: your bet is my bet, I'm off my ground here
[16:57] <proppy> norsetto: I mean I understand It's bad to replace the upstream and all
[16:57] <proppy> norsetto: that's why I've provided to the upstream a way to generate the dll
[16:58] <proppy> norsetto: and a premake.lua patch
[16:58] <proppy> s/dll/so
[16:58] <norsetto> proppy: well, you would have to take over maintenance of that library replacing effectively upstream
[16:58] <proppy> norsetto: you mean forking ?
[16:59] <proppy> so soname usually begin with 0
[16:59] <norsetto> proppy: not really, I mean providing the linux side of things
[16:59] <proppy> and get bumped everytime there is an abi change ?
[16:59] <proppy> norsetto: but by that you mean shipping a tar.gz somewhere with my change it in
[16:59] <norsetto> proppy: and upstream have responded to your queries?
[16:59] <proppy> instead of making these change in the debian/ directory
[17:00] <proppy> norsetto: I'll bump the post in the forum
[17:00] <norsetto> proppy: or back through proper upstream
[17:01] <proppy> norsetto: If I maintain a linux friendly upstream
[17:01] <proppy> norsetto: some of my changes will get in the orig.tar.gz
[17:01] <proppy> norsetto: instead of being in the debian diff right ?
[17:01] <norsetto> proppy: yes, thats always better
[17:02] <james_w> proppy: it gets bumped every time there is an incompatible ABI change.
[17:03] <james_w> proppy: so if an exported function gets removed. There is a tool in ubuntu-dev-tools to try and help you to spot this.
[17:03] <james_w> if something gets added then you just need to bump the shllibs.
[17:04] <james_w> and you can deal with some of this better using a version script, but that requires more work from upstream. It's great if you have a lot of reverse-depends.
[17:04] <proppy> norsetto: post bumpped http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=2343&start=0&postdays=0&postorder=asc&highlight=
[17:04] <norsetto> proppy: your compilation fails btw
[17:06] <proppy> norsetto: http://hg.juce.aminche.com/rev/26e1d5d4e0eb descriptions ok ?
[17:06] <norsetto> proppy: I meant as a separate line, use the . as a line separator
[17:07] <norsetto> !pastebin
[17:07] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[17:07] <nxvl_work> there are some packages on qa.ubuntuwire.com/ftbfs that are not on packages.ubuntu.com like amarok2
[17:07] <nxvl_work> is there any reason for that?
[17:07] <proppy> norsetto: like this http://hg.juce.aminche.com/rev/3562d0f8cce2
[17:08] <norsetto> proppy: yes, here: http://paste.ubuntu-nl.org/45577/
[17:09] <proppy> norsetto: 64bit ?
[17:09] <norsetto> proppy: yes
[17:09] <proppy> norsetto: I should made it i386 only then
[17:09] <proppy> or fix the linking on x64 issue
[17:09] <proppy> g++ -shared -o bin/libjuce.so bin/intermediate_linux/Release/*.o
[17:09] <norsetto> proppy: why? Seems like you just forgot the -fPIC option
[17:09] <proppy> that's the line I've added to generate the so files
[17:09] <proppy> yep
[17:10] <proppy> -fPIC is missing
[17:10] <proppy> I should try to add a SONAME too
[17:10] <proppy> norsetto: correct me if I'm wrong
[17:10] <proppy> or anybody :)
[17:11] <proppy> shared library always need to have a SONAME
[17:11] <proppy> starting at 0
[17:11] <norsetto> proppy: upstream makefile is making the static library?
[17:11] <proppy> and the package name needs to be named against the version with a suffix
[17:11] <proppy> there is no such thing like libfoo
[17:11] <proppy> only libfoo0 or libfoo1
[17:11] <proppy> norsetto: yep
[17:12] <norsetto> proppy: ok, make sure they use -D_REENTRANT, and you should use that for the shared too
[17:12] <james_w> proppy: you don't need to have a soname, but if you are going to package it and put it in /usr/lib you should.
[17:12] <james_w> proppy: and where you start doesn't matter, as long as it increases monotonically, and so 0 is a good start.
[17:13] <james_w> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
[17:13] <norsetto> proppy: have a look at this too: http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries
[17:14] <proppy> about the package name does it needs to be named after the SONAME ?
[17:15] <proppy> because I've seen package which aren't
[17:15] <proppy> IIRC
[17:16] <LaserRock> if you don't care about having multiple versions available at the same time you can have just -dev
[17:16] <LaserRock> I think generally the libfoo package has the soname though
[17:17] <proppy> LaserRock: you mean multiple -dev or non-dev package ?
[17:18] <proppy> james_w: norsetto: thanks for the links (reading)
[17:18] <nxvl_work> i miss tge motu-meeting again, didn't i?
[17:19] <LaserRock> proppy: multiple lib versions
[17:19] <LaserRock> proppy: like goffice in debian now has goffice 0.4.x and goffice 0.5.x
[17:20] <LaserRock> so there is a libgoffice0.4 package with a libgoffice0.4-dev
[17:20] <LaserRock> and also a libgoffice0.5 package with a libgoffice0.5-dev
[17:20] <proppy> I see
[17:20] <proppy> 0.5 and 0.4 are SONAME ?
[17:20] <LaserRock> yeah
[17:21] <norsetto> nxvl_work: yes
[17:21] <nxvl_work> :(
[17:22] <norsetto> nxvl_work: you can check the log
[17:22] <nxvl_work> norsetto: be sure i will
[17:22] <Ubulette> bluekuja, are you done ?
[17:23] <proppy> I don't think there will be multiple ABI version of the library, I mean it's a bad thing isn't it ?
[17:23]  * proppy is thinking he is completly missing the point
[17:24] <LaserRock> if the library is in active development I don't think it's possible
[17:24] <LaserRock> :-)
[17:25] <LaserRock> even python changes SONAME sometimes ;-)
[17:25] <proppy> but I thought new so name were introduced by new version of g++ right ?
[17:25] <LaserRock> no
[17:25] <proppy> and of stdlib++
[17:25] <proppy> ok
[17:26] <proppy> I'm missing the point :)
[17:26] <LaserRock> a new version on the library
[17:27] <LaserRock> proppy: the SONAME comes from the library
[17:27] <proppy> aaaaaaaaaaaaaaaaaaaaaaaaaaah
[17:27] <proppy> I see
[17:27] <proppy> everytime you break the Binary compatibility
[17:27] <proppy> by removing function by example
[17:27] <proppy> you bump the SONAME ?
[17:27] <LaserRock> right
[17:27] <LaserRock> that's the idea
[17:27] <proppy> oook
[17:28] <proppy> and then you name the package against that ?
[17:28] <LaserRock> right
[17:28] <proppy> so that people are able to get their program working against old versions ?
[17:28] <LaserRock> yeah, basically if you write something based on a lib
[17:29] <LaserRock> you need to know it's not going to change on you
[17:29] <proppy> so shipping multiple dev package
[17:29] <LaserRock> so you can tie to a SONAME
[17:29] <proppy> only people not only to run old program
[17:29] <LaserRock> right
[17:29] <LaserRock> so in the goffice example I had earlier
[17:29] <proppy> but to compile program based on old version of the library
[17:29] <LaserRock> gnumeric uses the 0.5.x goffice series
[17:30] <LaserRock> but gchemutils/gchempaint uses the 0.4.x goffice series
[17:30] <bluekuja> Ubulette, is normal that I see some iceape binaries as well?
[17:30] <proppy> LaserRock: so for the moment as it's the first version of the package
[17:30] <proppy> there is no multiple version of the library
[17:30] <proppy> and then no multiple -dev
[17:30] <proppy> for now
[17:31] <Ubulette> bluekuja, dummy transitional packages, yes. otherwise, please show me.
[17:31] <proppy> my guess is that the upstream doesn't maintain SONAME
[17:31] <bluekuja> Ubulette, let's move to -mozillateam
[17:31] <bluekuja> :)
[17:31] <Ubulette> ok
[17:31] <proppy> on the basic you've just explained, i.e: everytime I break binary compatibility I bump the library version
[17:31] <proppy> the upstream does not provide shared library at all
[17:31] <proppy> so just like norsetto suggested I should take care over it
[17:32] <proppy> or raise the upstream concern about it
[17:32] <proppy> right ?
[17:38] <proppy> norsetto: http://hg.juce.aminche.com/rev/7e78b2d01c7a
[17:38] <StevenHarperUK> Hi, my package has been accepted onto Hardy : https://www.launchpad.net/ubuntu/hardy/+queue/?queue_state=3&queue_text=easycrypt - I have been reading teh contributing page - but its not 100% clear on how to supply a new version
[17:39] <StevenHarperUK> This is the first time I have done this
[17:39] <norsetto> proppy: whats that?
[17:39] <proppy> norsetto: should fix the compilation on x64
[17:39] <proppy> norsetto: let me upload a new version on REVU
[17:39] <proppy> norsetto: since I can't test on X64
[17:39] <StevenHarperUK> Do I create a new Bug named "Candidate revision packagename_version-revision" and follow that procedure?
[17:40] <norsetto> proppy: no need to upload, I can just do it myself
[17:42] <StevenHarperUK> Oh also I want to use the translations feature : how do I enable that for : Candidate revision packagename_version-revision
[17:42] <StevenHarperUK> sorry bad paste : https://edge.launchpad.net/ubuntu/+source/easycrypt/
[17:45] <proppy> norsetto: http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?p=12927#12927
[17:45] <norsetto> proppy: well, we shall see
[17:47] <proppy> norsetto: does it match your concern ?
[17:48] <norsetto> proppy: my concern is that if upstream don't act I don't see this thing going well
[17:49] <proppy> norsetto: everything will just go fiiiiiiiiiiiiine :)
[17:49] <proppy> norsetto: btw does the rules thing seems ok ?
[17:50] <norsetto> proppy: let me finish this first
[17:50] <proppy> okkkkk
[17:51] <proppy> np
[17:55] <norsetto> proppy: same error
[17:56] <nxvl_work> mm i'm not sure about a FTBFS bug
[17:56] <proppy> did -fPIC is passed to g++ ?
[17:57] <nxvl_work> i first try to build it and it failed, but it was a dependency  error, i update my pbuilder and then it works
[17:57] <nxvl_work> do i need to report it?
[17:58] <proppy> norsetto:  did -fPIC get passed to g++ call ?
[17:58] <james_w> nxvl_work: you could perhaps suggest increasing the Build-Depends version of that package.
[17:58] <norsetto> proppy: from the log: g++ -fPIC -shared -o bin/libjuce.so bin/intermediate_linux/Release/*.o
[17:58] <imbrandon> nxvl_work: no, you should update your pbuilder regularly
[17:58] <proppy> norsetto: ok
[17:59] <imbrandon> no need to report it
[17:59] <proppy> norsetto: and exactly same error
[17:59] <proppy> norsetto: thanks you
[17:59] <norsetto> proppy: yes, exactly the same
[17:59] <nxvl_work> ok, moving to next one
[17:59] <proppy> I have a question regarding library example ?
[17:59] <imbrandon> nxvl_work: but if the rebuild fixes the FTBFS bug then thats good, there is still something to do
[17:59] <proppy> should they get shipped in a separate package  ?
[17:59] <proppy> like binary package 'juce' for exemple ?
[18:00] <nxvl_work> imbrandon: the thing is that i don't have the server error log, or it is somewhere?
[18:00] <norsetto> proppy: here http://paste.ubuntu-nl.org/45587/
[18:01] <imbrandon> nxvl_work: if no other fixes need to be done to the package , you can either 1) ask for a giveback for the package in #ubuntu-devel or 2) you can append build1 to the version and upload ( signifying just a rebuild )
[18:01] <norsetto> proppy: usually they will go in the -doc package
[18:01] <proppy> norsetto: ahah
[18:01] <proppy> norsetto: recompile with -fPI
[18:01] <proppy> norsetto: not link with -fPIC
[18:01] <proppy> norsetto: I should pass -fPIC to the whole compilation
[18:02] <proppy> not only to the linl step
[18:02] <imbrandon> nxvl_work: see what i mean ?>
[18:02] <nxvl_work> imbrandon: i don't really understand 1)
[18:02] <norsetto> proppy: ok, isn't that what you do with that line? I must admit I didn't check what that is
[18:03] <imbrandon> nxvl_work: ok jabber me i'll explain 1) a bit more
[18:03] <nxvl_work> ok
[18:03] <norsetto> proippy: ok, I see now, you should really compile twice
[18:03] <proppy> norsetto: nop with that like I link all the .o to a .so file
[18:03] <norsetto> proppy: ok, I see now, you should really compile twice
[18:03] <proppy> norsetto: I should compile twice
[18:04] <proppy> norsetto: and since I can't override CFLAGS of the Makefile without breaking the whole compilation ..
[18:04] <norsetto> proppy: this is getting hackier and hackier ....
[18:05] <proppy> norsetto: I can't disagree
[18:05] <proppy> norsetto: the good part is that I learned a lot of thing :)
[18:05] <norsetto> proppy: oh yes, you can't beat this for learning :-)
[18:06] <norsetto> proppy: actually, not much learning from a packaging pov ...
[18:07] <proppy> norsetto: I'm glad I've understood the SONAME thing :)
[18:07] <proppy> norsetto: about the need to private a proper Makefile for people to package you stuff too
[18:08] <proppy> norsetto: I will definitly be aware of that for packaging my own things
[18:10] <proppy> norsetto: does build: got call for each binary package ?
[18:11] <effie_jayx> norsetto,  thanks for the log
[18:11] <norsetto> effie_jayx: np
[18:11] <norsetto> proppy: the build target?
[18:11] <norsetto> proppy: thats just per makefile
[18:12] <norsetto> proppy: or did I misunderstand the question?
[18:12] <proppy> the debian/rules/build target ?
[18:14] <norsetto> proppy: ok, but what is the question about build: ?
[18:15] <proppy> is it called one time for libjuce and libjuce-dev ?
[18:15] <proppy> or two times :)
[18:16] <norsetto> proppy: build knows nothing about libjuce or libjuce-dev
[18:16] <norsetto> proppy: think about a rules files divided in 4 main sections: clean, configure, build and install
[18:17] <norsetto> proppy: build is where you call make (like for a compilation from source)
[18:17] <norsetto> proppy: (ok, sometime is not make, is qtmake, or whatever, but the concept is the same)
[18:17] <proppy> ok I see
[18:17] <proppy> these are the package generation entry point
[18:18] <proppy> used by debuild
[18:18] <norsetto> proppy: so, yes, unless the Makefile provided from upstream already does that, this is something you have to instruct yourself (like you did with the .install files)
[18:19] <norsetto> proppy: after the install: rule (which is where you invoke upstream makefile to install in the buildd)
[18:19] <proppy> norsetto: so only the debhelpers actually knows about the deferrent packages ?
[18:20] <proppy> s/deferrent/different
[18:20] <norsetto> proppy: well, yes if you tell them
[18:21] <proppy> norsetto: so I believe debhelper parses the debian/control files ?
[18:22] <proppy> I see
[18:22] <norsetto> proppy: yes, some of the debhelper do parse files in debian/ (for sure changelog and control)
[18:22] <proppy> when you use cdbs
[18:22] <warp10> Hi superm1. I was looking for an easy merge to do, and I saw xmltv, whose you are the last uploader. May I take care of it? Any suggestion about the merge?
[18:22] <proppy> you can name your rule after the package name
[18:22] <proppy> I guess that's why I was a bit confused
[18:23] <norsetto> proppy: but by default if no package is specified with -p they only act on the first one of the binaries
[18:23] <norsetto> proppy: yeah, cdbs do take care of that and hides the gory details
[18:24] <proppy> norsetto: I should take a look at the code
[18:24] <proppy> norsetto: cause I don't know how to "dynamicaly" call a rule form another one
[18:24] <norsetto> proppy: debhelper?
[18:24] <proppy> norsetto: cdbs
[18:24] <proppy> norsetto: how did they manage to have rules named after packagename ?
[18:25] <norsetto> proppy: what do you mean dynamically?
[18:25] <proppy> norsetto: since the rules doesn't know anything about the packagename
[18:25] <norsetto> proppy: oh, ok, yes, I've stumbled on that snippet not long ago
[18:26] <proppy> $(patsubst %,binary-install/%,$(DEB_ALL_PACKAGES)
[18:26] <proppy> ?
[18:27] <proppy> and I guess debuild set DEB_ALL_PACKAGES env var
[18:29] <norsetto> proppy: no, thats in buildvars.mk
[18:31] <proppy> norsetto: /usr/lib/cdbs/list-packages
[18:32] <norsetto> proppy: but, what is it that you want to do?
[18:32] <proppy> norsetto: I was just curious, how cdbs managed to call n*package rules, from a single one
[18:32] <norsetto> proppy: you want to call make twice?
[18:32] <proppy> 	open (CONTROL, 'debian/control') ||
[18:33] <proppy> norsetto: yep
[18:33] <norsetto> proppy: well, what about build: build_1 build_2 for instance ?
[18:33] <proppy> norsetto: yep or I can inline then in build:
[18:34] <proppy> but if I understand how to do it staticaly
[18:34] <proppy> I was wondering how cdbs could do it from a file input
[18:34] <norsetto> proppy: well, thats most probably done in a second pass
[18:35] <proppy> or doing variable substitution on Makefile rules dependencies ?
[18:36] <proppy> norsetto: you can try the following http://hg.juce.aminche.com/rev/9781079dc3cb
[18:36] <proppy> norsetto: it compiles only once, with -fPIC passed
[18:36] <proppy> norsetto: I guess it's bad for the static library
[18:36] <proppy> norsetto: but at least I will figure out if it fixes the dynamic library one
[18:38] <norsetto> proppy: yes, thats right, the static one should not be compiled with -fPIC
[18:39] <hyper___ch> apachelogger__: *ping*
[18:40] <proppy> norsetto: but does it fix your compilation error on x64 ?
[18:41] <norsetto> proppy: for the time being is building
[18:41] <proppy> norsetto: niceee
[18:42] <proppy> norsetto: thinking about the demo (examples)
[18:43] <proppy> norsetto: they are linked against the static file, again
[18:43] <proppy> norsetto: so I believe your point of making a linux friendly upstream is even better
[18:44] <norsetto> proppy: errr
[18:45] <proppy> norsetto: same ?
[18:45] <norsetto> proppy: :(
[18:45] <proppy> norsetto: same error ?
[18:45] <norsetto> proppy: like two water drops ...
[18:47] <norsetto> proppy: gotta go, wifey is calling for dinner
[18:47] <proppy> ok
[18:47] <proppy> thanks for the helps
[18:47] <proppy> see you
[18:47] <proppy> so do I
[18:48] <norsetto> proppy: a+
[19:10] <DktrKranz> nxvl_work, around?
[19:11] <jpatrick> I think he's at work
[19:11] <RainCT> hi
[19:11] <DktrKranz> I guess so :)
[19:12] <warp10> I am working on a merge, and there is a remaining change (a bugfix) that hasn't been reported to Debian. Should I report it filing a bug on BTS, altough I am not the author of that bugifx?
[19:12] <nxvl_work> DktrKranz: yep
[19:12] <slangasek> warp10: yes, please
[19:12] <DktrKranz> nxvl_work, hi. I looked at bug 164727. I think a give-back can be enough to fix it.
[19:12] <ubotu> Launchpad bug 164727 in advi "advi FTBFS" [Undecided,New] https://launchpad.net/bugs/164727
[19:12] <slangasek> warp10: assuming you can adequately explain the reason for the change, if not feel free to ask for help here?
[19:13] <nxvl_work> DktrKranz: thats what i have done
[19:13] <nxvl_work> :D
[19:13] <warp10> slangasek: ok, thank you!
[19:14] <DktrKranz> It's a rebuild. A give-back is usually managed by buildd-admins
[19:15] <nxvl_work> the patch only changes the changelog
[19:15] <imbrandon> nxvl_work: he is talking about doing 1)
[19:15] <imbrandon> in our discussion
[19:16] <imbrandon> e.g. what geser just asked pitti in #ubuntu-devel
[19:16] <imbrandon> vs a build1 uplaod
[19:16] <geser> nxvl_work: a new upload isn't needed in that case, simply asking a buildd-admin is enough
[19:17] <nxvl_work> imbrandon: oh, ok
[19:18] <nxvl_work> geser: yes but i find better to do it myself instead of asking another person to do it for me, i feel a little lazy doing that way
[19:18] <imbrandon> ugh i need a personal DD, lol, sponsors are never on at the same time as me
[19:18] <nxvl_work> imbrandon: rudy is online
[19:18] <imbrandon> nxvl_work: hejust left for a few hours
[19:18] <imbrandon> :)
[19:18] <nxvl_work> oh
[19:19] <geser> nxvl_work: -XbuildY packages aren't autosynced anymore, so you need to file a sync request later
[19:19] <nxvl_work> i did't knew that
[19:19] <nxvl_work> ok going to ubuntu-devel
[19:20] <nxvl_work> imbrandon: or have you already uploaded it?
[19:20] <LaserJock> imbrandon: email works in all TZs
[19:20] <slangasek> personal DDs are expensive to maintain
[19:21] <LaserJock> hehe
[19:21] <nxvl_work> slangasek: heh
[19:21] <DktrKranz> :D
[19:21] <LaserJock> that'd be kinda funny, "Hello, I'm LaserJock you personal DD, how may I be of service?"
[19:21] <LaserJock> "Oh, for an actualy upload that's going to cost you $500"
[19:22] <LaserJock> "Rants on debian-devel on your behalf will be $100/email"
[19:22] <imbrandon> hahaha
[19:22] <DktrKranz> Do I need a discount if I have to manage multiple uploads?
[19:22] <imbrandon> nxvl_work: no i dident upload it
[19:22] <LaserJock> "Votes are $10, or sometimes a freebie if I feel generous"
[19:22] <DktrKranz> 500$ the first, 400$ the second... and so on
[19:23] <imbrandon> mentors are encouraged NOT to sponsor mentees uploads :)
[19:23] <imbrandon> nxvl_work: ^
[19:23] <hyper___ch> a question: how can a new package be requested or how can I make a .deb file out of the source?
[19:23] <imbrandon> !packageguide | hyper___ch
[19:23] <ubotu> hyper___ch: The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports
[19:23] <hyper___ch> thx
[19:23] <LaserJock> what the heck
[19:23] <LaserJock> I changed that
[19:24] <LaserJock> grrr
[19:24] <luisbg> hey he is LaserJock again
[19:24] <imbrandon> LaserJock: yea but i like to be able to talk to sponsors in realtime, helps fix issues faster if there are any
[19:25] <Kmos> should be https://wiki.ubuntu.com/PackagingGuide :)
[19:25] <DktrKranz> mh... is a mass-rebuild for packages which do FTBFS scheduled in the future?
[19:25] <imbrandon> DktrKranz: not sure, geser just asked pitti that
[19:25] <geser> DktrKranz: I asked pitti about it and no such massive give-back is planned
[19:26] <geser> DktrKranz: [20:03:43]        pitti | geser: no, it's not planned, I don't know how to do that wholesale
[19:26] <LaserJock> !packagingguide
[19:26] <ubotu> packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[19:26] <LaserJock> oh stink
[19:27] <DktrKranz> So, manual give-backs are required?
[19:27] <LaserJock> packageguide vs packagingguide
[19:27] <hyper___ch> imbrandon: the one I would like to have included is already requested ;)
[19:27] <DktrKranz> boring :)
[19:27] <imbrandon> LaserJock: its an alias
[19:28] <imbrandon> !packageguide is <alias> packagingguide
[19:28] <ubotu> But packageguide already means something else!
[19:28] <imbrandon> !no packageguide is <alias> packagingguide
[19:28] <ubotu> You are editing an alias. Please repeat the edit command within the next 10 seconds to confirm
[19:28] <imbrandon> !no packageguide is <alias> packagingguide
[19:28] <ubotu> I'll remember that imbrandon
[19:28] <imbrandon> LaserJock: fixed :)
[19:29] <nxvl_work> i'm supposed to go to the university but i don't want :(
[19:29] <LaserJock> imbrandon: geeze, no need to spam ;-)
[19:29] <imbrandon> oh wow, i give up :)
[19:30] <imbrandon> LaserJock: PONIES! :)
[19:30] <LaserJock> I'm trying fix this factoid mess
[19:31] <Kmos> https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles
[19:31] <Kmos> at the end
[19:31] <Kmos> ".desktop file fails validation"
[19:31] <Kmos> the command doesn't work
[19:31] <Kmos> only show the available desktop files, but not run desktop-file-validate against it
[19:33] <LaserJock> !package
[19:33] <ubotu> Sorry, I don't know anything about package - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[19:33] <LaserJock> !packaging
[19:33] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports
[19:33] <LaserJock> ah hah
[19:36] <tritium> LaserJock: do you have a minute?
[19:36] <LaserJock> tritium: sure
[19:36] <tritium> LaserJock: thanks.  I'll /query.
[19:36] <LaserJock> !packaging
[19:36] <ubotu> packaging is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[19:50] <Mez> how do I create Linda Overrides?
[20:00] <superm1> warp10, sure if you want to, have at it
[20:01] <superm1> if not, laga was going to get at it in the future
[20:04] <warp10> superm1: ok, thanks :)
[20:04] <superm1> oh and looking through bug mail you've got debdiff's on the bug now
[20:04] <superm1> i'll take a look and upload them as long as they're good
[20:13] <norsetto> superm1: are you looking at bug 164738 ?
[20:13] <ubotu> Launchpad bug 164738 in xmltv "Please upload merge xmltv 0.5.50.1 (universe) from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/164738
[20:13] <superm1> norsetto, yes
[20:13] <superm1> i'm doing a test build right now
[20:14] <norsetto> superm1: ok, I just set it in progress and assign to you if you don't mind?
[20:14] <superm1> sure no biggie
[20:16] <superm1> warp10, okay looks good i'm gonna upload this.  thanks :)
[20:16] <warp10> superm1: great! thank you! :)
[20:38] <TheMuso> Hey folks.
[20:45] <geser> Hi TheMuso
[20:49] <norsetto> hi TheMuso
[20:59] <joejaxx> anyone have a plan about the lp downtime? :) ( it is 8 horus :(  )
[21:00] <TheMuso> joejaxx: I think we just have to wear it.
[21:01] <joejaxx> TheMuso: yeah, unfortunately :\
[21:01] <joejaxx> better pull everything locally then
[21:02]  * geser will be sleeping the most time LP is down
[21:03] <TheMuso> Oh well, I have other stuff I can do while I wait. :p
[21:03] <imbrandon> its not for another 24+ hours correct ?
[21:04] <geser> Nov 25th 3:00 UTC - 11:00 UTC
[21:05] <TheMuso> Its the morning of the 24th here.
[21:07] <imbrandon> yea it seems it will be Saturday, November 24, 2007 at 9:00:00 PM here
[21:11] <imbrandon> seems for that long of a downtime they could put up a static copy of the db or soemthing
[21:13] <RainCT> can somebody please check if pbuilder-dist from hardy works correctly?
[21:15] <RainCT> I get a strange error when I use it on gutsy with the backported pbuilder, but I'm not sure if that's just me or there's really something wrong
[21:16] <RainCT> oh, today it seems to work fine :S
[21:18] <LordKow> hm my xchat icon decided to pick its own size for the tray icon. kind of dominates the rest of 'em
[21:19] <LordKow> thats better
[21:28] <LordKow> bug 139518
[21:28] <ubotu> Launchpad bug 139518 in deluge-torrent "Please sync deluge-torrent 0.5.6.2-1 from debian unstable" [Wishlist,Incomplete] https://launchpad.net/bugs/139518
[21:28] <LordKow> should i make a new bug report or use that one? it needs to be a merge
[21:29] <TheMuso> Yay! Seems the buildds are uber clogged atm.
[21:29] <LordKow> TheMuso, which means... we are working faster than the build machines can build the packages? i like that
[21:30] <TheMuso> LordKow: More due to the fact that a lot of stuff was brought in from Debian
[21:30] <LordKow> ah k
[21:31] <LordKow> with regards to the deluge-torrent bug, would it be too invasive to change the bug title and status when it was not me who filed it?
[21:31] <LordKow> its an invalid report with regards to a sync.
[21:31] <jsomers> dumb question: when using debuild -S I get the error that my secret key is not available. When using gpg --list-secret-keys I do see my name and the email address that I configured in my bashrc file
[21:31] <jsomers> any pointers on why this may still be happening?
[21:32] <LordKow> debuild -S -rfakeroot -k<your_gpg_key_id>
[21:33] <LordKow> i think that will work
[21:33] <LordKow> i always use dpkg-buildpackage
[21:33] <LordKow> and i have the GPGKEY env var set to i always use -k$GPGKEY
[21:33] <LordKow> s/to/so
[21:35] <jsomers> allright, that worked
[21:36] <jsomers> thank you very much
[21:50] <nxvl> last week of classes sux
[21:50] <nxvl> is so boring come to do nothing
[21:50] <nxvl> :S
[22:04] <SWAT> what's the best way to package a svn-revision from scratch? (I usually use pbuilder + dh_make)
[22:12] <nxvl> u can also use CDBS
[22:12] <nxvl> it's easier
[22:21] <warp10> hi zul. May I take care of the merge of nginx, whose you are the last uploader?
[22:37]  * RainCT asks if the unknown author of 404main is around as he is working on improving and cleaning it up but there's a chunk he doesn't understand :P
[22:38] <TheMuso> RainCT: No, he's not.
[22:39] <RainCT> TheMuso: do you know who he is? :P
[22:39] <geser> RainCT: which part you don't understand?
[22:40]  * geser notes it's *not* his script, but /me is learning python
[22:41] <RainCT> http://paste.ubuntu-nl.org/45631/plain/
[22:41] <RainCT> this one
[22:41] <RainCT> I understand the code but I don't know what it's for
[22:42] <RainCT> (deps is a list of build dependencies)
[22:42] <RainCT> s/build//
[22:42] <RainCT> ah ok
[22:43]  * RainCT understands it now.. should look right next time :P
[22:43] <RainCT> geser: thanks anyways :)
[22:44] <geser> RainCT: I didn't do anything, but I'm glad I could help you :)
[22:58] <LordKow> RAOF, why can deluge-torrent be synced? what about the last ubuntu package which removes the update entries from the preferences dialog, and also what about disabling auto-checking for updates? debian's version does this and we do not want it to
[22:58] <LordKow> does this, as in they DO check for auto-updates.
[23:01] <LaserJock> dang it, I can't for the life of me figure out how to get the back of this laptop off
[23:01] <LordKow> the screen?
[23:01] <LaserJock> no, the bottom
[23:02] <LordKow> ah
[23:02] <LaserJock> I took out all the screws
[23:02] <LaserJock> but it seems to be still hanging on towards the back
[23:02] <LordKow> did you take off the keyboard and the panel that goes over the power buttons, etc?
[23:02] <LaserJock> no
[23:02] <LaserJock> I'm going in from the bottow
[23:02] <LaserJock> *bottom
[23:02] <LordKow> well, some laptop manufactures will screw it down (towards the bottom of the laptop) with a couple of screw
[23:03] <LordKow> *s
[23:04] <LaserJock> I don't see any visable screws