[00:00] <pochu> blueyed: I've to go for a dogwalk now, but I'll try that when I'm back. Thanks!
[00:01] <blueyed> welcome, have fun :)
[00:23] <gilir> hi
[00:24] <gilir> there is a little problem with REVU :) http://revu.tauware.de/details.py?package=awn-extras-applets
[01:02] <ScottK2> Dear everyone: Please stop and think about if your change is appropriate to Debian before sending them a patch and a bug.
[01:08] <tacone> sorry
[01:09] <tacone> is it still valid to propose software ?
[01:09] <pochu> You can always propose. It may well not be accepted though :)
[01:09] <tacone> oh, I'd get very angry then :-D
[01:10] <pochu> tacone: we are near Feature Freeze so it's likely a bit late...
[01:10] <pochu> tacone: but is that new software or changing a default application?
[01:10] <tacone> new software
[01:10] <tacone> may sound stupid. a little game, which work like a charm with ubuntu
[01:10] <tacone> there's already a .deb on getdeb.net
[01:11] <pochu> You have 10 days until Feature Freeze. After it your chances are low.
[01:11] <pochu> tacone: is it Debian? How is it called?
[01:11] <tacone> where should I propose ?
[01:11] <tacone> teewars
[01:11] <pochu> File a needs-packaging bug in Launchpad, (and a RFP in Debian)
[01:11] <tacone> it's got nice reviews. and it's very simple and addicting. http://www.getdeb.net/app/TeeWars
[01:12] <tacone> should I propose that in debian too ?
[01:12] <TheMuso> tacone: If it gets into Debian first, its a lot easier to get into Ubuntu.
[01:13] <pochu> The game looks nice indeed
[01:13] <tacone> themuso: it's already packaged
[01:13] <tacone> there's a .deb on getdeb.net.
[01:13]  * pochu looks for bddebian to get it packaged in pkg-games :)
[01:14] <pochu> But he isn't around...
[01:14] <TheMuso> tacone: Yes, but that may need extra work before its accepted into Debian/Ubuntu.
[01:14] <tacone> I understand that.
[01:15] <tacone> I don't know how to file a need packaging bug. where do I specify 'need packaging' ? in the bug title ?
[01:16] <vorian> is a rules error or dependency error?
[01:16] <vorian> http://paste.ubuntu-nl.org/54796/
[01:16] <vorian> :)
[01:18] <pochu> tacone: yes, and add a "needs-packaging" tag
[01:20] <tacone> just submitted. looking for the change of attaching a tag
[01:21] <tacone> done, nice !
[01:21] <tacone> https://bugs.launchpad.net/ubuntu/+bug/189118
[01:21] <ubotu> Launchpad bug 189118 in ubuntu "Teewars would be a nice inclusion for hardy" [Undecided,New]
[01:21] <tacone> :-)
[01:21] <effie_jayx> vorian,  looks like a file missing
[01:21] <effie_jayx> I am no expert though
[01:21] <effie_jayx> :D
[01:21] <vorian> you are doing awesome effie_jayx :)
[01:22] <effie_jayx> vorian,  I am going the distance... :D
[01:22] <bddebian> Heya gang
[01:22] <vorian> i'm converting my package to be compliant with the debian/python policy
[01:35] <effie_jayx> the updated souce seems to have several files changed. there is a whole bunch of files that are in .install file that are not in the soucer package... do this get created or I have to find the list somewhere?
[01:40] <imbrandon> hrm does gparted safely resize a ext3 part ?
[01:40] <vorian> imbrandon: sure, i just did one a few weeks back
[01:40] <imbrandon> cool
[01:41] <vorian> it needs to lead though
[01:41] <imbrandon> yea thats no biggie
[01:47] <vorian> ah, there is no setup.py
[01:54] <ScottK2> slangasek: Excellent responsiveness on sync requests today (sync done less than an hour after I request it).  Thanks.
[01:57] <slangasek> ScottK2: nah, I think I need to get a start on those earlier in the day, so I can be /off/ that page by the time your sync requests come through ;)
[01:58] <slangasek> (looks like I won't get any new processing done today, for instance...)
[02:01] <bddebian> heh
[02:06] <slangasek> jdong: bug #175344: are you sure it was the intention of the original bug submitter to request a backport, as opposed to an SRU?  The bug title here comes from Kmos, who I think may have misapprehended the submitter's concerns
[02:06] <ubotu> Launchpad bug 175344 in gutsy-backports "Please backport ntfs-3g 1.1120 from Hardy" [Undecided,In progress] https://launchpad.net/bugs/175344
[02:08] <jdong> slangasek: for the specific issue the submitter cited, yeah, it's SRU material .However, there's also new features (faster perforamcne, relatime support and default) that make the release worthwhile in any case
[02:08] <ScottK2> * twitch *
[02:08] <ScottK2> jdong: Then shouldn't the SRU be done first.
[02:09] <jdong> ScottK2: I think they are independent matters that can be approached in any order
[02:09] <zul> icky
[02:09] <slangasek> yes, the order shouldn't matter
[02:09] <jdong> ScottK2: if we SRU it, I'd also like to look at the 5+ other issues addressed in the versions between gutsy and hardy :)
[02:09] <ScottK2> jdong: OK.  My experience has been that once you do the backport the interest in working out the SRU goes WAY down.
[02:09] <jdong> ScottK2: and before long, that's gonna be the same thing as just a backport :D
[02:09] <slangasek> but I'm not sure if pushing a backport with this poor user's name in the changelog is the right thing either, since I don't think that's what he was requesting
[02:10] <ScottK2> Slap jdong's name on it then.
[02:10] <jdong> slangasek: Only my name gets put in the changelog, right?
[02:10] <jdong> ScottK2: only if Canonical sends me an official Ubuntu scapegoat t-shirt :)
[02:10] <ScottK2> jdong: You've been wearing that one for years.
[02:10] <slangasek> jdong: uh, I've been following the same convention as for syncs, which is that the original bug submitter gets their LP id used in the backport
[02:11] <jdong> slangasek: interesting :)
[02:11] <ScottK2> slangasek: Normally for a backport I'd suggest you put whoever ack'ed it for backporters.
[02:11] <slangasek> if I should use you for all of them instead, that would certainly save on typing ;)
[02:11] <jdong> slangasek: the other archive admins previously have been following the convention that it goes to the approving backporter
[02:11] <slangasek> ok, that's fair
[02:11] <jdong> slangasek: yeah I think that's a better way of doing it
[02:11] <ScottK2> slangasek: Your odds of having someone mind after problems go way up that way.
[02:12] <jdong> slangasek: often times backport requesters aren't of the technical skill level of a sync requester and would be less able to deal with the responsibility of the changed-by blame trail ;-)
[02:12] <jdong> slangasek: not to mention FTBFS mail should be directed at a backporter :)
[02:12] <jdong> not that I'm all that interested wine didn't build on sparc256 or whatever :)
[02:12] <slangasek> right, let me go through and redo these... :)
[02:13] <jdong> hehe :)
[02:13] <jdong> who's the ntfs-3g dude around here?
[02:13] <ScottK2> I like the stick the tag on jdong no matter who did it plan.
[02:14] <ScottK2> That'd be you, now.
[02:14] <jdong> :)
[02:14] <jdong> I was wondering if we should update to the latest upstream release before review
[02:14] <jdong> release*
[02:14] <jdong> http://ntfs-3g.org/releases.html their release notes always sound intriguing
[02:14] <jdong> though that 2121 release sounds scarily intrusive
[02:14] <ScottK2> Well I'd be really careful about an ntfs-3g backport no matter which version it was.
[02:15] <jdong> ScottK2: the main mode of failure for one would be some sort of FUSE API incompatibility blowup
[02:15] <jdong> causing ntfs-3g to be inoperable
[02:15] <jdong> historically the QA from ntfs-3g upstream is quite superb
[02:15] <zul> everytime i see ntfs it makes my skin crawl
[02:15] <jdong> I believe they have a test suite too :) (gasp!)
[02:17] <blueyed> How can I search for packages which build-depend on a given package?
[02:18] <StevenK> blueyed: grep-dctrl
[02:21] <jdong> slangasek: so you're the poor unfortunate soul stuck with processing all those backports I triaged this weekend? :D
[02:22] <slangasek> yes
[02:22]  * jdong gives slangasek half of this yummy cardboard^Wprotein bar he's snacking on :)
[02:22] <slangasek> next time, take a Wednesday off to do those ;)
[02:22] <jdong> haha :)
[02:22] <pochu> Night MOTUland!
[02:22] <jdong> ask backports requestors. I don't do this often :D
[02:23] <vorian> how does the debian/python policy apply to a package which is built with a configre/makefile?
[02:23] <vorian> this is killing me :P
[02:24] <blueyed> StevenK: thanks, but I can't get it to do what I want.. would I have to grab some Contents file for this?
[02:24] <blueyed> I've tried e.g. "grep-available -F Build-Depends sun"
[02:25] <StevenK> Contents lists what packages provide what file, that is hardly revelant
[02:25] <StevenK> blueyed: grep-dctrl -FBuild-Depends -sPackage sun < /var/lib/apt/lists/*Sources
[02:28] <slangasek> jdong: do you think 175344 should also have an SRU, then?  If so, would you mind nominating it for gutsy?  (TTBOMK I still can't nominate bugs without them immediately being accepted)
[02:28] <jdong> bug 175344
[02:28] <ubotu> Launchpad bug 175344 in gutsy-backports "Please backport ntfs-3g 1.1120 from Hardy" [Undecided,Fix released] https://launchpad.net/bugs/175344
[02:28] <jdong> slangasek: :-/ I'm hesitant to do so because I'm not sure what the scope of that SRU would be
[02:29] <jdong> I'm not familiar with upstream's codebase or release habits
[02:29] <slangasek> ok
[02:29] <jdong> but I will add a comment
[02:29] <jdong> and also flip (presumably Kmos's) invalid marking on Ubuntu
[02:30] <TheMuso> jdong: You can check the activity log for that.
[02:30] <jdong> 10 Dec 07 18:49   Marco Rodrigues  ntfs-3g: status  New  Invalid
[02:30] <jdong> surprise!
[02:31] <blueyed> StevenK: thanks, works (in zsh). I'd expected more packages then 25 though (B-d on sun's java)
[02:34]  * Hobbsee refuses to comment, but wonders about how many *other* good bugs have been mangled, due to him, and if anyone plans on reverting the changes
[02:34] <Hobbsee> i guess people will rereport, particularly in hardy+1
[02:40] <sgbirch> Can somebody plz help.  I am in the debian NM queue and am maintaining a couple of packages which are also in Ubuntu, xball and vobcopy.  My sponsors have uploaded new versions of both programs recently.  How can I get them uploaded to Ubuntu as well.  They are both in sid.
[02:41] <ScottK2> vorian: The build system doesn't affect policy.
[02:42] <blueyed> sgbirch: they are both in Ubuntu already. To get the latest release synced, you should file a sync request.
[02:42] <blueyed> sgbirch: I could file the sync request, if you want.
[02:42] <ScottK2> vorian: Either convince the upstream makefile to shove stuff into policy compliant locations or make your own setup.py, add it to the debian/dir and then use that.
[02:43] <ScottK2> blueyed: Better he files it and you ack it.
[02:43] <blueyed> ok
[02:45] <sgbirch> blueyed: This is actually my first ever contact with Ubuntu folks.  I normally hang out in the debian areas.  So I dont know how to file a sync request.  Can you point me to the docs so I can RTFM plz?
[02:45] <ScottK2> sgbirch: Do you use pbuilder for test bulding?
[02:46] <blueyed> sgbirch: docs are at https://wiki.ubuntu.com/SyncRequestProcess
[02:46] <sgbirch> blueyed: Oh ... I just noticed your offer to file the sync req.  Would you please, that would be great.  Two packages .... xball and vobcopy.
[02:46] <blueyed> I'm testing currently if they build and will do so then. Seems more straightforward, doesn't it, ScottK?
[02:47] <ScottK2> blueyed: Yes, but if you do it, he doesn't learn and can't do it himself the next time this comes up.  We want to help everyone learn that comes here.
[02:47] <sgbirch> ScottK2: No, I use a clean VM loaded with sid
[02:48] <mruiz> hi all
[02:49] <ScottK2> sgbirch: OK.  You might want to consider setting up an Ubuntu Hardy VM so you can test build on our toolchain.  It'd make it more credible/less work for us if you've already done the test build when you come ask.
[02:50] <mruiz> I'm preparing a new version for mnemosyne but upstream packages it as <file>-<version>.tgz. Should I repackage it ?
[02:51] <ScottK2> mruiz: Just rename it.  That's not repackaging.
[02:51] <ScottK2> mruiz: You have to rename .tar.gz to .orig.tar.gz in any case.
[02:52] <sgbirch> ScottK2: OK .. I am happy to do that.  Although I am working towards DD I run Ubuntu on all my machines :-)  I really want the two packages I currently maintain and future packages to always go into debian and ubuntu.  So the Ubuntu learning curve is important to me.
[02:52] <ScottK2> Excellent.
[02:52] <ScottK2> sgbirch: I'm the same.  I run Ubuntu, but am in NM.
[02:53] <sgbirch> ScottK2: Very cool.
[02:53] <mruiz> ScottK2, thanks... I'm asking as tgz is different to tar.gz ;-) . I read that tar.bz2 should be processed in a different way
[02:53] <ScottK2> sgbirch: Welcome.  You might also want to consider doing packaging work in Ubuntu and maybe becomine a MOTU.
[02:53] <ScottK2> mruiz: I missed the bz2 part.  Yes.  You need to reroll that.
[02:53] <mruiz> :-)
[02:54] <sgbirch> ScottK2: Yes ... that is very much on my mind, Id like to do that.  I actually do packaging professionally in my day job ... but that doesn't mean I am an expert by any means :-)
[02:54] <ion_> A tar.bz2 only needs to be recompressed, not repackaged entirely.
[02:54] <ScottK2> sgbirch: Well we're always looking for help.
[02:55] <sgbirch> ScottK2: How long have you been in the NM queue?
[02:58] <vorian> belated thanks ScottK :)
[03:35] <ScottK2> Oh well.  I guess he left
[03:35] <ScottK2> vorian: You're welcome.
[03:35] <vorian> :)
[03:43] <mruiz> bye all
[03:43] <mruiz> good night
[03:43] <bddebian> ScottK2: Did you scare another one away? :)
[03:43] <bddebian> Night mruiz
[04:02] <nixternal> w00t! GO BLUE!
[04:02] <nixternal> sorry, seen the umich :)
[04:03] <jdong> yay, from my state :)
[04:04] <nixternal> hey, I need some opengl love here...I have a file that includes <GL/gl.h>, that is apparently a part of mesa-common-dev, I shouldn't have to dep on that should I
[04:04] <jdong> go umich people :)
[04:04] <nixternal> jdong: my state too! :)
[04:04] <vorian> booo
[04:04] <nixternal> ahh, one of them hairy nut fans
[04:04] <vorian> :D
[04:04] <jdong> nixternal: I always thought you were in chicago for some reason?
[04:04] <vorian> shouldn't it be libglu1-mesa-dev
[04:04] <nixternal> you know, I need to stop saying that, because people who do not know about a buckeye may wonder
[04:04] <jdong> vorian: and your highway patrol owes me money!
[04:05] <nixternal> jdong: I am, but I was born in Benton Harbor, MI
[04:05] <vorian> lol
[04:05] <nixternal> all of my family is there
[04:05] <nixternal> hahahaha
[04:05] <vorian> jdong: yah yah yah :)
[04:05] <jdong> nixternal: ah, ok, cool :)
[04:05] <jdong> vorian: seriously, blinker lights too bright?
[04:05] <nixternal> Penguicon in DTown in a couple of months, who's going?
[04:05]  * vorian raises his hand
[04:05] <nixternal> jdong: let me guess, clear tail lights?
[04:05] <jdong> nixternal: depends on whether or not This Wonderful Educational Institution will give me time off ;-)
[04:06] <jdong> nixternal: and actually, no, stock lights on a grand cherokee
[04:06] <nixternal> I will be broke, so everyone is buying me food and drink
[04:06] <jdong> nixternal: but admittedly they are stunningly bright in the night
[04:06] <nixternal> wow
[04:06] <vorian> with Michigan plates I bet :P
[04:06] <jdong> vorian: yup
[04:06] <jdong> :)
[04:06] <nixternal> I got pulled over because they said my blinker lights were to bright here in Chicago...but my truck has custom carbon fiber tail lights
[04:06] <jdong> vorian: no front plate so no laser tickets :)
[04:06] <vorian> that would be your first problem
[04:06] <nixternal> oh, and they are damn bright
[04:06] <jdong> nixternal: ah, interesting :)
[04:06] <nixternal> it is a xeon bulb that you can find in some fog lights :p
[04:07] <nixternal> err
[04:07] <nixternal> zenon I think is what they are
[04:07] <jdong> nixternal: I was let off with a warning, though my sarcasm nearly cost me the $120 :D
[04:07] <jdong> xenon
[04:07] <nixternal> hahaha
[04:07] <nixternal> xenon, that, that's it
[04:07] <jdong> I've been considering adding HID front and LED rear lights
[04:07] <vorian> oh bother
[04:07] <nixternal> I am ordering some LED from ebay for the rear myself
[04:07] <jdong> I even have a nice strip of Luxeon Star and Nichia CS reds that I stripped off an ambulance light bar
[04:07] <jdong> (legally!!)
[04:08] <vorian> nixternal: anywhere but ebay!
[04:08] <nixternal> haha
[04:08] <nixternal> vorian: best price for them
[04:08] <jdong> I'm guessing I should NOT use those lights in Ohio :)
[04:08] <nixternal> well the place I might order from has an ebay store
[04:08] <nixternal> I am starting to hate opengl
[04:09] <jdong> slangasek: you still awake?
[04:09] <jdong> nvm I answered my own question
[04:10] <vorian> nixternal: are you looking for `The OpenGL utility library development environment'?
[04:11] <slangasek> jdong: because you saw me still doing archive processing? :-P
[04:11] <jdong> slangasek: well I had no idea whether that was activity or LP lag :)
[04:12] <jdong> slangasek: but it was regarding the bzr-svn tangle, I noticed jpatrick also had requested/approved a bzr-svn backport
[04:12] <jdong> slangasek: at any rate, hold off on both for now and let me look at this 0.4.7 that jelmer wants :)
[04:13] <jdong> and with that, I disappear off into the night :)
[04:13] <jdong> aaahhh the LP mail has started!
[04:14] <jdong> slangasek: oh btw I bet at least 2 of the backports you processed today will instnatly end up in source NEW so if you could push those through after you're done too... *hugs*
[04:15] <nixternal> vorian: I figured it out I think
[04:15] <nixternal> might help to update patches/series
[04:15] <vorian> schweet
[04:16] <ScottK2> bddebian: No.  He heard you were coming.
[04:17]  * jdong wonders if there will be nuclear fallout from firefox-3.0 entering gutsy-backports :)
[04:17] <vorian> lol
[04:17] <StevenK> jdong: For someone who has disappeared, you talk a lot
[04:17] <jdong> StevenK: I'm a bad magician... I can never disappear completely on the first try
[04:19] <slangasek> jdong: ah, I think I'm running away for the night after the backports themselves are done, sorry
[04:20] <jdong> slangasek: sure thing :)
[04:21]  * StevenK kicks libosso
[04:22] <StevenK> I change the dbus security policy for its dbus service, and now hildon-desktop SEGVs inside libosso
[04:22] <StevenK> s/its/libosso's/
[04:30] <bddebian> ScottK2: Heh, zing :-)
[04:57] <tonyyarusso> Hi, I have two lintian warnings I would like explained to me - "W: kompozer source: desktop-file-but-no-dh_desktop-call" and "W: kompozer source: out-of-date-standards-version 3.7.2 (current is 3.7.3)".  Are these things I need to worry about?
[04:59] <firestormx37> hello, i would like to get involved and help with bugs or packaging, but i am not sure where to start.  I have been reading all the getting started and faq pages, but I need help finding something small and easy to start with.  Can anyone help me out?
[04:59] <StevenK> tonyyarusso: The first means you are installing a .desktop file and don't call dh_desktop in your rules file
[04:59] <StevenK> tonyyarusso: The second you can update if you're worried about the warning
[04:59] <tonyyarusso> StevenK: What changes are there in the standards version that I would need to update?
[05:00] <StevenK> tonyyarusso: There is a checklist installed by the debian-policy package
[05:00] <tonyyarusso> StevenK: Okay, I'll look for that.
[05:00] <tonyyarusso> desktop thing first..
[05:03] <tonyyarusso> StevenK: Would that go in install: build or binary-indep: build install?
[05:05] <StevenK> tonyyarusso: In binary-indep
[05:06] <StevenK> tonyyarusso: The first word there is the target name itself, the others are what that target depends on.
[05:06] <tonyyarusso> StevenK: I still don't quite understand that.
[05:07] <StevenK> tonyyarusso: binary-indep is a Makefile target, which requires that the targets build and install are up to date before it runs
[05:07] <tonyyarusso> ok
[05:15] <tonyyarusso> Okay, the only warning I have now from lintian is "W: kompozer source: not-binnmuable-all-depends-any kompozer-dev -> kompozer"
[05:17] <tonyyarusso> What's binnmuable mean?
[05:17] <StevenK> Able to be binary-only NMU'd, a Debian-ism
[05:18] <StevenK> Means you don't use (>= ${binary:Depends}) in kompozer-dev's Depends line.
[05:18] <tonyyarusso> Yeah, I was using Depends: kompozer (= ${binary:Version})
[05:19] <StevenK> Oh, that should be okay
[05:19] <StevenK> Actually, >=
[05:19] <StevenK> binary:Depends is my brain going funny
[05:20] <tonyyarusso> the lintian notes suggest Depends: kompozer (>= ${source:Version})
[05:21] <tonyyarusso> perhaps I should try that?
[05:22] <StevenK> tonyyarusso: Sure. My memory might be faulty
[05:22] <tonyyarusso> k
[05:26] <tonyyarusso> all right, looks good now
[05:29] <LucidFox> Would anyone like to sponsor bug #187576? I'd like to get the new upstream version to Ubuntu first before packaging it for Debian
[05:29] <ubotu> Launchpad bug 187576 in smplayer-themes "Upgrade to smplayer-themes 0.1.15" [Wishlist,Confirmed] https://launchpad.net/bugs/187576
[05:31] <jdong> ugh this channel does not help my insomnia
[05:32] <jdong> LucidFox: I'm gonna have to try my best to ignore you till tomorrow morning.... Need my sleep for classes ;-)
[05:32] <LucidFox> heh
[05:34] <tonyyarusso> I wonder what percentage of Ubuntu contributors are students
[05:39] <crimsun> a non-trivial portion.
[05:46] <tonyyarusso> Please review: http://revu.tauware.de/details.py?package=kompozer
[05:55] <ScottK2> jdong: Sleep IS what the classes are for.
[06:08] <tonyyarusso> Well, I guess now it's just time to go to bed and wait.  If someone's considering looking at that kompozer upload, it should be all pretty straightforward changes, so hopefully nothing too complicated to worry about.  'night
[06:17] <ScottK2> tonyyarusso: Why is an upgrade on REVU?
[06:17]  * ScottK2 just looked at two packages and found copyright problems in both.  Urgh.
[06:18] <TheMuso> ScottK2: Perhaps we should have something about people getting copyright checked out before submitting a package...
[06:19] <ScottK2> TheMuso: I think running grep -ir copyright * over the package should definitely be mentioned.  These packages had all been reviewed several time before too, so MOTUs aren't looking hard enough either.
[06:20] <TheMuso> I think there is an assumtion that other MOTUs will look at the copyright.
[06:20] <ScottK2> That or the archive admins will do it.
[06:25] <ScottK2> Good night all.
[06:43] <dholbach> good morning
[06:46] <tonyyarusso> ScottK2: Because I thought it was supposed to be?  Please enlighten me.
[06:51] <LucidFox> dholbach> Not yet, but I'll talk to the original maintainer, thanks for the tip. You can unsubscribe u-u-s for now.
[06:51] <dholbach> LucidFox: will do - thanks for taking care of it!
[06:54] <tonyyarusso> Since ScottK2 went to bed, anyone care to tell me what the proper process for getting upgrades approved and uploaded is?
[06:55] <superm1> tonyyarusso, generally attaching to a bug and subscribing u-u-s
[06:56] <superm1> tonyyarusso, but after FF, new versions will need to go through motu-release
[06:56] <superm1> bug fixes can still be attached to a bug though
[06:57] <tonyyarusso> superm1: Ah, all right.  And if I do it that way, it should probably be a debdiff rather than the full thing, right?
[06:57] <superm1> tonyyarusso, well all depends on the situation
[06:57] <superm1> and the patching scheme used for the package
[06:57] <superm1> previously interdiffs were the way to go
[06:57] <superm1> if all of the patching is constrained to the debian/ directory
[06:57] <tonyyarusso> superm1: It was just packaging info updates - debian/control, debian/rules, and debian/changelog I think are all that changed.
[06:57] <superm1> the more ideal route is to link to the new archive, and then attach a diff of the two debian/ directories
[06:58] <superm1> or even better, use a get-orig-source rule to build the archive needed for the .orig.tar.gz
[06:58] <superm1> but if you debdiff two new versions alltogether, it will be a very large diff usually
[06:59] <superm1> understand?
[06:59] <tonyyarusso> Sorry, no...
[06:59] <superm1> okay so lets say you've got hello-world-v1 and hello-world-v2
[06:59] <tonyyarusso> okay, good so far :)
[06:59] <superm1> between the two versions, there are tons of upstream changes
[06:59] <superm1> they decided that they wanted to add this wacky GUI and stuff
[07:00] <tonyyarusso> hehe
[07:00] <superm1> so you go and package up the new version based on the old one's packaging
[07:00] <superm1> and you're all said and done
[07:00] <superm1> so you debdiff the two dsc's, and its a 10 meg debdiff
[07:00] <superm1> well that would be silly to upload
[07:00] <superm1> your changes were just in the debian directory
[07:01] <superm1> and the diff for your changes is only like 15k
[07:01] <tonyyarusso> Okay, still following.
[07:01] <superm1> so instead, in that case you can just do a diff between the old debian directory and new debian directory
[07:01] <superm1> and upload that diff instead
[07:01] <superm1> just in your comments on the bug explain that its a diff of the debian directories, and provide a link where someone grab hello-world-v2
[07:02] <tonyyarusso> I wasn't aware diff operated on directories - or do you do it file by file?
[07:02] <superm1> you can do it recursively
[07:02] <tonyyarusso> ah
[07:02] <superm1> the switches are something like -urN
[07:02] <superm1> unified recursive something something
[07:02] <tonyyarusso> now, as far as this link, which file precisely is it going to?  Which portion is "interesting" to a reviewer?
[07:02] <superm1> well it wouldnt be for review
[07:03] <superm1> it would be for a new version
[07:03] <superm1> so if its say a merge from debian
[07:03] <superm1> and they have that new version, just say to grab the .orig.tar.gz from there
[07:03] <superm1> if on a website say to grab it from there
[07:03] <superm1> the most ideal case though, you can write a rule in debian/rules that will grab the right file for the person
[07:03] <superm1> if its not already present
[07:04] <tonyyarusso> Now, in my particular case today, the .orig.tar.gz is completely unchanged.  Do I even need a link then?
[07:04] <superm1> now in that case you can just use a debdiff
[07:04] <tonyyarusso> I wish I had that kind of debian/rules fu, but sadly, I simply don't (yet)
[07:04] <superm1> because you're not including any new .orig.tar.gz
[07:04] <superm1> so no new upstream changes
[07:04] <dholbach> (-N treats non-existant files as empty in the 'old' directory)
[07:04] <tonyyarusso> So debdiff makes sense now, but I should know all this other stuff for later.
[07:05] <superm1> well that's just one type of case, but yeah its a good idea to understand it
[07:05] <superm1> there are more complex cases depending upon how the package adopted a patching system which you might come across some day
[07:06] <superm1> like mplayer for example
[07:06]  * tonyyarusso installs a 1TB drive in his brain for this...
[07:06] <superm1> be careful with that one, its fun
[07:06] <tonyyarusso> I'm told I should start using quilt for my package, if I'm brave someday
[07:06] <tonyyarusso> (it's a mozilla thing)
[07:07] <superm1> everyone has their preferences on patching systems, you'll eventually learn which ones are easier for you to work with
[07:07] <superm1> after seeing how they operate
[07:09] <superm1> dholbach, ah.  i've wondered about that
[07:09] <superm1> but never looked at the man page :)
[07:09] <LucidFox> tonyyarusso> I prefer simple-patchsys for CDBS packages and dpatch for plain debhelper packages.
[07:09] <tonyyarusso> So, if I'm going to create a bug whose sole purpose is the be the carrier of this diff, should I bother trying to cite it in changelog or does it not matter?
[07:09] <LucidFox> tonyyarusso> yes, mention it in the changelog
[07:10] <tonyyarusso> okay
[07:11] <LucidFox> tonyyarusso> as for recursive diffs, superm1 is right - run it with -urn
[07:11] <LucidFox> -urN
[07:11] <LucidFox> (u)nified format, (r)ecursive, include (N)ew files
[07:11] <tonyyarusso> LucidFox: wrt the changelog, I have 3 things that I did (all quite minor).  How would you suggest I write that, with the bug #?
[07:12] <LucidFox> * Fixed such-and-such issue (LP: #xxx)
[07:12] <tonyyarusso> I meant as in should I list the same LP bug three times?
[07:12] <LucidFox> no, once is sufficient
[07:12] <tonyyarusso> okay
[07:13] <LucidFox> its sole purpose is to let the upload automatically close the bug
[07:13] <tonyyarusso> Oh, that's nifty.
[07:14] <LucidFox> As for patches, does the package use CDBS?
[07:15] <tonyyarusso> No.  (not yet at least)
[07:17] <LucidFox> Ah, that's a shame. The CDBS simple-patchsys is not that in name only, it's really the simplest patch system out there.
[07:18] <superm1> the only thing i don't like about the simple-patchsys is that all patches in that directory are "automatically" applied.
[07:18] <superm1> so if you want to turn off one
[07:18] <LucidFox> Ah, indeed.
[07:19] <superm1> even temporarily you gotta move it out of the directory
[07:19] <crimsun> whew, well there went a few hours of testing.
[07:19]  * crimsun uploads and drags off to sleep
[07:19] <LucidFox> superm1> but doesn't it only apply files with the .diff and .patch extensions?
[07:20] <superm1> LucidFox, i think so, but again, you gotta rename it then
[07:20] <superm1> which makes the diff's huge
[07:20] <LucidFox> (granted, that won't help if you want to just minimize the delta, which is achieved by removing just one line with dpatch)
[07:20] <superm1> exactly
[07:21] <superm1> but be it as it may, easy to use otherwise
[07:22] <tonyyarusso> Any preferences for what I should name a debdiff?
[07:23] <LucidFox> I name it the same as the dsc/diff.gz, but with the .debdiff extension
[07:24] <LucidFox> package_version-XubuntuY.debdiff
[07:24] <tonyyarusso> makes sense
[07:26] <tonyyarusso> In LP, there's the checkbox for "this attachment is a patch" - does that include debdiffs, in the sense more like "this attachment has code to fix it"?
[07:28]  * tonyyarusso guesses yes
[07:29] <mok0> tonyyarusso: yes
[07:29] <tonyyarusso> sweet
[07:30] <tonyyarusso> All right, I think it's all ready to go - https://bugs.edge.launchpad.net/ubuntu/+source/kompozer/+bug/189174 if you want to see if there's anything wrong with that.
[07:30] <ubotu> Launchpad bug 189174 in kompozer "kompozer needs minor packaging fixes" [Undecided,New]
[07:31] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[07:34] <master_obredar> hello
[07:35] <master_obredar> need help please
[07:45] <LucidFox> gah!
[07:45] <LucidFox> well... he will learn patience
[07:48] <slytherin> Can anyone help me investigate this issue. There is a source package aspectwerkz2 which is supposed to provide binary libaspectwerkz2-java (arch all). Launchpad says build was successful but I can not find the binary anywhere.
[07:48] <superm1> slytherin, did you check the hardy NEW queue?
[07:48] <slytherin> superm1: where to check it?
[07:48] <superm1> https://edge.launchpad.net/ubuntu/hardy/+queue
[07:49] <superm1> the first time a binary is introduced to the archive, it sits there
[07:49] <superm1> until an archive admin acks it
[07:49] <superm1> if this was already in the archive, then just give it some time to propagate the mirrors
[07:50] <TheMuso> Packages that are already in the archive that introduce new binaries also sit in binary new.
[07:50] <slytherin> superm1: Ah, it is there in 'New' queue.
[07:50] <slytherin> superm1: When will it get processed?
[07:50] <superm1> when archive admins have time
[07:51] <superm1> on a regular basis though at least
[07:51] <superm1> since its right before feature freeze, you can see its a mad rush to get things in
[07:51] <tonyyarusso> They seem to tend to let them sit for a while, then plow through a bunch in a few hours from time to time
[07:51] <slytherin> superm1: Th reason I am asking is that there are other packages which FTBFS due to absence of this package
[07:52] <superm1> slytherin, they haven't entered depwait?
[07:52] <slytherin> superm1: I checked just now. They have entered depwait
[07:52] <superm1> see for example, i uploaded gmyth a few days ago
[07:52] <superm1> https://edge.launchpad.net/ubuntu/+source/gst-plugins-bad0.10/0.10.5-5ubuntu3/+build/504499
[07:53] <superm1> and its in depwait now
[07:53] <superm1> ah okay
[07:53] <superm1> slytherin, once the binaries get released some automatic job eventually releases the depwait packages to try again
[07:54] <slytherin> superm1: Ok. Thanks for info.
[07:54] <superm1> np
[08:08] <LucidFox> Apparently, icedtea-java7 has been rejected from Debian. Gah.
[08:10] <LucidFox> dholbach> I've got a reply from the original maintainer of smplayer, posted it in bug #188964
[08:10] <ubotu> Launchpad bug 188964 in smplayer "Please sync smplayer 0.6.0~rc1-1 from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/188964
[08:11] <dholbach> LucidFox: rock on!
[08:12] <slytherin> LucidFox: Why is icedtea rejected?
[08:13] <LucidFox> no idea
[08:14] <apache|mobile> hm
[08:14] <apache|mobile> long island iced tea?
[08:17] <slytherin> Can anyone sponsor the debdiff attached to bug 183164
[08:17] <ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
[08:17] <mok0> Can PostSript documents, for which there is no "source", be distributed?
[08:17] <slytherin> oops, I just realised the package is in main.
[08:18] <LucidFox> heh
[08:25] <RAOF> mok0: PostScript is source, even if it isn't generally easily editable source :)
[08:25] <mok0> RAOF: So it's only PDF documents?
[08:26] <mok0> That require "source"
[08:30] <slytherin> persia: Can you somehow accelerate the acceptance of debdiff on w3c-dtd-xhtml bug. :-D
[08:30] <LucidFox> lol
[08:31] <LucidFox> why don't you ask a core-dev?
[08:32] <slytherin> LucidFox: Just asked on #ubuntu-devel. Looks like no one is awake there. :-)
[08:34] <mok0> slytherin: no-one's awake here either
[08:35] <LucidFox> apparently, there was a netsplit
[08:35] <slytherin> mok0: I interact with persia regularly, he knows what the problem is about and he reads logs. :-)
[08:36] <mok0> Heh
[08:43] <mok0> How does + something sort in the version number? For example 3.0 vs. 3.0+p1 vs. 3.0.1 ??
[08:43] <mok0> "p1" means "patch level 1"
[08:48] <TheMuso> moDo you know of dpkg --compare-versions
[08:48] <TheMuso> gah just went offline
[08:50] <pkern> Hobbsee: I would appreciate if you could sponsor #189186 ;)
[09:41] <rulus> Can someone take a look at my package (http://revu.tauware.de/details.py?package=gtkvd) please? It's ready for advocation. Thanks a lot!
[09:47] <dholbach> nixternal, persia, soren, geser: are you OK if I set up the polls for the motu-release team members?
[09:47] <soren> dholbach: Sure thing.
[09:48] <geser> dholbach: sure
[09:49] <jpatrick> nixternal is sleeping
[09:49]  * dholbach just renames the team in LP according to the motu meeting discussion
[09:49]  * dholbach also updates the documentation
[09:50] <dcordero> hi
[09:51] <dcordero> there are an easy way for apply a diff.gz with a lot of .diff file in it?
[09:51] <dcordero> something like patchGreat -p1 < ../file.diff.gz ?
[09:53] <_ruben> zcat patches.gz | patch -p1 *might* do the trick
[09:54] <lucas> or patch -p1 <( zcat ../file.diff.gz )
[09:54] <lucas> (see man bash)
[09:56] <dcordero> yep, i thought that maybe there are a command for that. thanks
[10:00] <HighNo> hi there, I'd like to ask for the exact status of integration of my package as someone has filed bug 137339 for me
[10:00] <ubotu> Launchpad bug 137339 in ubuntu "They must include BlueProximity in repositories" [Wishlist,New] https://launchpad.net/bugs/137339
[10:01] <pkern> Hobbsee: dholbach already acked it (thanks, eh)
[10:01] <HighNo> It seems it has been hanging around without any action now for a long time.
[10:02] <Fujitsu> HighNo: That's not a long time.
[10:02] <Fujitsu> The exact status is most probably that nobody has started, nor is planning to in the foreseeable future.
[10:03] <HighNo> Fujitsu: OK :-) Anyway are there ways to speed things up? Can I help in any way?
[10:03] <Ng> HighNo: package it yourself with the help of the fine people in here :D
[10:03] <Fujitsu> You could package it yourself. Unless someone else has a specific interest, it's unlikely to get done.
[10:03] <HighNo> Ng: it is already packaged for feisty but works (as told by users) on gutsy and hardy
[10:04] <slytherin> HighNo: So what is problem then?
[10:04] <HighNo> Is there somewhere I can upload it to to check wether the package has formal errors and that deps are OK for hardy?
[10:05] <HighNo> slytherin: how does it get into the official repository?
[10:05] <HighNo> official being universe of course
[10:06] <Ng> HighNo: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[10:06] <slytherin> HighNo: Oh you mean to say you have packaged it outside of ubuntu. Submit it to revu. But first make sure there are no severe packaging problems by trying to build it in pbuilder
[10:07] <HighNo> ok, thanks for the info - could I still make it into hardy if I do it all by myself and do it now?
[10:07] <HighNo> (just to time my efforts)
[10:08] <Ng> HighNo: feature freeze is only just over a week away, and I'd expect things to get quite busy between now and then
[10:08] <RAOF> HighNo: Technically possible, but unlikely.  Especially since no one seems to have been terribly interested before this.
[10:08] <slytherin> HighNo: FeatureFreeze is on 14th Feb.
[10:10] <dcordero> nxvl, i have answer you in Bug #177443
[10:10] <ubotu> Launchpad bug 177443 in photoprint "photoprint should recommend or require icc-profiles package" [Undecided,Confirmed] https://launchpad.net/bugs/177443
[10:11] <HighNo> ok, thanks. I'd give it a try. I hope to broaden the user base by including it into the official feed. there are about 1k users atm...
[10:13] <slytherin> HighNo: even if it does not get included in official repos you can have your own repo in the form of PPA. :-)
[10:17] <dholbach> nixternal, persia, soren, geser: done and mail to lists sent out
[10:17] <HighNo> slytherin: but that won't help people adding it easyly and finding it easily via apt/synaptic/etc., right?
[10:19] <slytherin> HighNo: of course it will. PPA is all about your own repository which can be added via synaptic/apt etc
[10:19] <geser> slytherin: re lucene2: does the latest lucene2 in Debian unstable fix the dtd problem? It builds fine here (in a pbuilder) and the changelog mentions a fix for the tests
[10:20] <slytherin> geser: Let me check.
[10:26] <HighNo> slytherin: that's what I meant. People have to add my repo first. People who don't know my software won't add that repo by themselves... This would probably not increase user count :-)
[10:26] <slytherin> yes, I just suggested a workaround. It is not a solution
[10:27] <slytherin> geser: changelog has some mention for fix but not about what exactly is the fix.
[10:27] <sistpoty|work> hi folks
[10:28] <slytherin> geser: I will try building it just to confirm and then file a sync request.
[10:28] <geser> Hi sistpoty|work
[10:28] <sistpoty|work> hi geser
[10:31] <pkern> dholbach: That "n hours from now" stuff is annoying.
[10:32] <pkern> dholbach: As I tend to act on mails immediately.
[10:32] <dholbach> pkern: I'll follow up on the mail with a reminder a day before the polls close :)
[10:35] <pkern> dholbach: Heh.
[10:54] <slytherin> geser: even if lucene2 from debian unstable builds in Ubuntu, it uses Sun Java. What about bug 185917 then?
[10:54] <ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
[10:55] <geser> slytherin: that would be my next question :)
[10:57] <geser> slytherin: can the same changes be applied to the recent package?
[10:58] <slytherin> geser: As I don't know what exactly debian guys do to bypass/disable/fix the tests, I can not comment on that.
[11:00] <slytherin> My preferred course of action is that we concentrate on fixing lucene2 2.2.x for which I have a patch ready. If needed we can have a merge with FFE later.
[11:04] <persia> slytherin: Best to wait on the queue.  It does get processed, even if it takes a bit.
[11:05] <persia> superm1: diff -urN debian/ is not a good way to track updates.  I've seen too many patches lost because they were in the diff.gz.  While the documentation still needs updating, please advocate the presentation of the new diff.gz for new upstreams.
[11:05] <slytherin> persia: You have dropped in at right time. Your comments are expected on the whole lucene2 issue. :-)
[11:06] <geser> slytherin: I've looked into the diff.gz and it is in debian/patches/81_prevent-network-access.dpatch. It simply comments testEncoding() out.
[11:08] <persia> The last scheduled REVU day for hardy has now concluded.  Packagers, please keep watching REVU: if a reviewer wants your package for a feature goal, they will likely keep commenting.  If not, consider uploading to a PPA for hardy, and make sure it's perfect for next cycle.
[11:08] <slytherin> geser: Smart move. :-)
[11:09] <dcordero> what is the right place for all the .py files of a python coded application?
[11:11] <persia> slytherin: I don't have a lot to say about lucene2, other than "Good Luck" and "Please keep chasing this, universe for hardy would be great!".
[11:11] <persia> dcordero: http://wiki.debian.org/DebianPython/NewPolicy is probably the right place to start
[11:11] <geser> slytherin: what about backporting this patch to the current version in Ubuntu?
[11:12] <dcordero> thanks persia
[11:12] <slytherin> geser: If commenting the test is the way we want to go then it is not that hard.
[11:13] <persia> Wouldn't it be better to get feedback on the DTD patch before uploading a workaround?
[11:14] <slytherin> persia: geser: We have to make a decision, 1) fix 2.2.x our way and have icedtea as dependency  2) sync debian version for now to fix FTBFS and then apply our DTD patch and use icedtea as build dep later.
[11:16] <persia> slytherin: And 3) Do nothing now, and then apply some FTBFS fix and use icedtea as build-dep later.  Why is 2.3 better?
[11:17] <slytherin> persia: I have no idea. I haven't even looked it. The discussion started few minutes before you arrived.
[11:17] <persia> slytherin: Just a few minutes before I wrote anything :)
[11:18] <slytherin> :-)
[11:18] <geser> persia: there is no need to update to 2.3, I've just seen that a new version hit unstable and checked if it resolves our FTBFS
[11:18] <geser> if we get 2.2.x to build then we can keep it and merge 2.3 in hardy+1
[11:18] <persia> geser: Right.  It was just the mention of a sync for a new upstream this close to FF that made me reflexively ask "Why".
[11:19] <geser> if we need additional changes we can apply them to 2.2 too
[11:20]  * persia looks at upstream
[11:21] <geser> as long as we fix the FTBFS I don't have a preference which way to go
[11:21] <persia> There's a heap of API changes, according to http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_3_0/CHANGES.txt.  Might be a lot of transition work to get it in for hardy.
[11:22] <geser> then it's probably better to fix 2.2
[11:22] <persia> On the other hand, lots of bugfixes, and it's supposed to be faster.
[11:22] <slytherin> persia: what transition are you talking about?
[11:23] <persia> slytherin: lucene2 2.2 -> 2.3.  API changes often means someone has to do extensive testing and porting.  Best to push these pre-DIF, unless there is some external driver pushing the update.
[11:23] <geser> persia: and lucene2 did never build successfully so not much to transition
[11:23] <slytherin> geser: +1
[11:25] <geser> and packages build-depending are now in depwait instead of perhaps ftbfs if they need an adaption to the new api, so no big regression in this point
[11:25] <emgent> heya people
[11:26] <persia> geser: It's arch;all, so it only FTBFS for us.  solr-common has a dependency, and there's a couple packages on REVU as well.
[11:27] <HighNo> I am somewhat puzzled atm, the docs of creating packages talk of 'try using pbuilder' as you stated above. My package is python only, so no building takes place at all or am I missing the point here?
[11:27] <slytherin> persia: geser: will be back in half hour.
[11:28] <persia> HighNo: You're missing the point.
[11:28] <persia> A "source" package is in a format that can be built with debuild, sbuild, pbuilder, etc.
[11:28] <persia> A "binary" package is in a format that is ready for installation on a target machine.
[11:29] <geser> persia: with which version of lucene2 are the packages in REVU tested? we can fix 2.2 if it helps the packages in REVU to get into the archive
[11:29] <persia> For python packages, "source" packages usually have all the development docs, and a layout that makes it easy for people to hack on them.  "binary" packages then put all the necessary .py files to run in the right directories to be byte-compiled at installation time.
[11:30] <persia> geser: netbeans expects 2.2.  I haven't been following the others as closely.
[11:31] <persia> We can probably leverage some QA resources from the Petersburg hb team, but they'd be happier with 2.2.  On the other hand, if someone wants 2.3 for some reason, netbeans can be adjusted.
[11:31] <jpatrick> DEB_INSTALL_MANPAGES_kmplayer_common = kxineplayer.1 - is that valid?
[11:32] <geser> persia: then keep 2.2
[11:32] <persia> jpatrick: Just use debian/kmplayer-common.manpages.
[11:33] <jpatrick> binary package is kpmayerl-common
[11:33] <jpatrick> arg
[11:33] <jpatrick> persia: ok
[11:33] <geser> jpatrick: nice typo
[11:33] <persia> jpatrick: The other works, but CDBS hooks aren't very transparent, and it's best to make the packages easy for others to update :)
[11:34] <jpatrick> persia: I hope it will pick it up from "docbook2x-man debian/kxineplayer.1.docbook"
[11:35] <persia> jpatrick: I think you still need a hint for dh_installmanpages, but may as well try it.
[11:44] <HighNo> persia: Ok, then can you please help me what exactly should I upload at REVU if I have a complete package. I have it as a tar.gz (complete dir) and also as a ready to install .deb file. I tried do "decipher" the wiki pages at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages what the .deb file should be like and what it should include but I got lost somewhere. Is there an easy checklist for a package?
[11:46] <persia> HighNo: You want an orig.tar.gz, a diff.gz, and a .dsc.  From these, you should generate a source.changes file, which is what you upload to REVU.  I'm distracted by several other things, and don't know much about python packaging: you'd do better to ask specific questions to the channel generally to get your answers.
[11:47] <persia> Also...
[11:47] <persia> !packaging | HighNo
[11:47] <ubotu> HighNo: 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
[11:48] <HighNo> persia: thanks for the info, the url's are all known to me as I have gotton lost there too often... :-/
[11:51] <sistpoty|work> geser: how can I prolong my membership? didn't find anything on my lp page, nor on the motu page (though I also didn't get a reminder mail from LP yet)
[11:51] <persia> HighNo: http://wiki.debian.org/DebianPython/NewPolicy may also be useful.  You might want to look at some other python packages as well, and if you find one with a similar license, consider using that as a template.  The use of distutils is looked upon favorably.
[11:51]  * Hobbsee waves
[11:51] <sistpoty|work> hi Hobbsee
[11:51] <geser> Hi Hobbsee
[11:51] <persia> sistpoty|work: You should be able to get it from the team members list.
[11:52] <HighNo> persia: thank you very much - that seems a good idea and a new url to me :-)
[11:52] <sistpoty|work> persia: didn't find anything there (though I must admit, LP sometimes confuses me *g*)
[11:53] <sistpoty|work> I did find that leave the team button though *g*
[11:53] <persia> sistpoty|work: You might have to wait until you are about to expire, and then do something.  It'd be on one of the links on the left.  In the worst case, if you got bumped, just use the "Join Team" link, and someone would fix it within a few hours.
[11:53] <sistpoty|work> persia: ok, thanks... then I'll just be patient :)
[11:53] <persia> On the other hand, for other teams I administer, I often see notices that people have extended their membership.  I think LP sends you a reminder when the membership is about to expire.
[11:54] <sistpoty|work> yes, it should do this... at least it did for ubuntu-dev membership
[11:54]  * persia notes that ~ubuntu-dev should have no non-team members
[11:55] <sistpoty|work> iirc the plan was to have this get cleaned out via the normal expiration, instead of doing it manually
[11:56] <persia> sistpoty|work: Right.  Just don't renew your membership if you are asked :)
[11:56] <sistpoty|work> persia: I was already and didn't ;)
[11:57] <persia> sistpoty|work: In that case, you get a gold star :)
[11:57] <sistpoty|work> :)
[12:00] <sistpoty|work> oh, now since the final REVU day is gone, may I abuse sparky for a ghc6 test build? (it will cause REVU to be unreachable a little bit, due to high memory usage and swapping)
[12:00] <sistpoty|work> will only take 10-14 hours I guess *g*
[12:01] <zorglu_> q. im trying to use lzma to compress my .deb, i have seen stuff using 'dpkg-deb --build -Zlzma' but my dpkg-deb doesnt seem to understand it as it report 'dpkg-deb: unknown compression type `lzma'!"'. any idea suggestion on which dpkg-deb start supporting this lzma compression type ?
[12:01] <persia> sistpoty|work: Err.  Yes, but there are still some packages there that will go into hardy.  Does spooky still not do it's thing?
[12:01] <pkern> zorglu_: Which release?
[12:02] <zorglu_> pkern: im running feisty here
[12:02] <persia> zorglu_: Build in a hardy chroot
[12:02] <persia> s/t's/ts/
[12:02] <sistpoty|work> persia: nope, spooky still needs to get installed... OTOH I install spooky during the weak maybe
[12:02] <pkern> zorglu_: Gutsy, if not hardy.  But you should testbuild in a hardy chroot anyway, as persia said (or pbuilder fwiw).
[12:02] <sistpoty|work> and testbuild there then
[12:02] <zorglu_> persia: you mean that the default dpkg-deb of hardy, support lzma ?
[12:03] <persia> sistpoty|work: OK.  I've also a sparc that I keep meaning to install.  I'll see if I can get to it later in the week.
[12:03] <sistpoty|work> oh, cool
[12:04] <persia> It's only a 400S, so it might take a couple days to build ghc6, even if I get it up.
[12:04] <zorglu_> pkern: do you know if dpkg-deb on gutsy support lzma ?
[12:04] <persia> zorglu_: Looks to have been included in 1.14.15, from 7th January.
[12:05] <zorglu_> persia: oh quite recent then.
[12:05] <persia> zorglu_: I may be mistaken.  Feel free to check the source for various releases to see when the support was really added.
[12:06] <zorglu_> persia: wow this seems to be a lot of work just for that :)
[12:06] <zorglu_> persia: pkern: thanks
[12:07] <Hobbsee> bug  #189186
[12:07] <ubotu> Launchpad bug 189186 in gobby "Please sync gobby 0.4.6-3 from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/189186
[12:07]  * slytherin is back
[12:18] <mruiz> morning all
[12:23] <persia> awen: Please submit your diff.gz for imapsync to a bug.
[12:23] <persia> tonyyarusso: Are you all set with kompozer, or do you still need the REVU entry?
[12:24] <persia> martoss: Similarly, submitting a diff.gz in a bug will give you a better chance of getting eric updated for hardy.
[12:25] <cyberix> Does the "Ready for upload" status guarantee that my package will be built and get into Hardy before freeze?
[12:25] <persia> cyberix: No.  It needs to be in the NEW queue.
[12:26] <persia> And even if it is there, it doesn't guarantee it will be built and distributed pre-freeze, only pre-release.
[12:27] <cyberix> I'm trying to make sure everything goes ok. Mainly, I don't want the package to be left out just because someone forgot to put it forward.
[12:27] <persia> Things entering the NEW queue post-freeze need special exceptions to be included in the release.
[12:27] <persia> cyberix: Did you check the queue yet?
[12:27] <cyberix> The build queue, yes.
[12:27] <cyberix> The package doesn't appear there.
[12:27] <persia> The NEW queue?
[12:27] <cyberix> Where do I find that one?
[12:28] <cyberix> That is before or after the build queue?
[12:28] <persia> replace +builds with +queue in your URL
[12:29] <cyberix> "There’s no page with this address in Launchpad."
[12:30] <soren> https://launchpad.net/ubuntu/hardy/+queue
[12:30] <cyberix> thanks
[12:30] <soren> The +queue one is per suite. +builds is distro-wide.
[12:31] <cyberix> No, my package is not in the new queue
[12:31] <persia> soren: Ah.  I didn't know that worked.
[12:31] <persia> cyberix: In that case, you need an uploader.
[12:31] <soren> persia: Eh?
[12:31] <persia> soren: https://launchpad.net/ubuntu/+builds
[12:32] <cyberix> I supposed second advocate would do the uploading.
[12:32] <persia> I always used https;//launchpad.net/ubuntu/$release/+builds or https://launchpad.net/ubuntu/$release/$arch/+builds
[12:32] <persia> cyberix: Generally.  Sometimes they are away from their key, and someone else uploads.
[12:33] <sistpoty|work> cyberix: if it wasn't uploaded until I get home, I'll upload it (as I was the first advocate).
[12:33] <cyberix> sistpoty|work: Thanks.
[12:43] <soren> persia: Oh? How do you usually find it?
[12:43] <soren> persia: Or did you just not know of that page?
[12:43] <persia> soren: I usually get there from +queue
[12:44] <soren> persia: Oh, right.
[12:46] <geser> slytherin: persia and I agreed to keep lucene2 2.2. Is disabling that specific test useful or should we try to fix w3d-dtd-xhtml instead?
[12:47] <geser> from the Debian bug against w3c-dtd-xhtml it looks as it might take some time to convince the maintainer
[12:48] <slytherin> geser: I have already added debdiff to Ubuntu bug. Now waiting for it to be sponsored. Why not to it right way instead of disabling the test.
[12:49] <geser> slytherin: if it just needs sponsoring that let's do it the right way
[12:49] <slytherin> :-)
[12:55] <rexbron> Hi, I am looking for a review of two packages, Open Libraries and openFX: http://revu.ubuntuwire.com/details.py?package=openlibraries http://revu.ubuntuwire.com/details.py?package=openfx
[13:00] <sistpoty|work> theseinfeld: just saw your comments on revu... linda is a little bit outdated, so you can ignore the output regarding standards-version
[13:00] <theseinfeld> ok sistpoty
[13:00] <sistpoty|work> theseinfeld: however you should build-depend on debhelper (>= 5.0.0) and set dh_compat to 5 (not too sure if there are plans to deprecate v4 already)
[13:01] <theseinfeld> roger that
[13:02] <theseinfeld> sistpoty: building, and soon uploading with compat 5 and debhelper >5.0.0
[13:03] <theseinfeld> will this work with the ppa building?
[13:03] <slytherin> theseinfeld: Sure. debhelper has been at version 5 for long time
[13:04] <theseinfeld> oh yeah
[13:04] <theseinfeld> I have 5.6.0 on gutsy
[13:05] <geser> and hardy has already debhelper 6
[13:05] <Coper> Can a MOTU review my new package http://revu.ubuntuwire.com/details.py?package=console-freecell
[13:06] <theseinfeld> done and done!
[13:07] <martoss> if I upload sth with dput, how can i force to dput the orig.tar.gz as well?
[13:08] <theseinfeld> dpkg-buildpackage -sa
[13:08] <theseinfeld> martoss add -sa
[13:08] <martoss> ah ok, I used debuild
[13:08] <Ng> debuild -S -sa :)
[13:09] <ScottK> martoss: add -sa works for debuild too
[13:11] <persia> martoss: Also, keep in mind that packages already in the repositories uploaded to REVU are not likely to get much attention.  You'd do better with a bug.
[13:11] <\sh> moins
[13:11] <martoss> filing a bug with dsc, and diff?
[13:12] <yamal> ScottK: regarding your review of sabnzbdplus: would it be best to just remove only that template (or even just that one file), or to simply leave all templates out that are not included in the package anyway?
[13:12] <geser> Hi \sh
[13:12] <persia> martoss: Just the diff.gz.  The .dsc can be reconstructed by the sponsor.
[13:13] <martoss> ok
[13:13] <ScottK> yamal: Just that one file.  It was the only one that was licensed differently (unless of course you find more that I missed).
[13:15] <persia> yamal: Also note that the use of shortened names or other aliases for Maintainer or changelog entries is very much not preferred.  Perhaps you could collaborate with someone if you really need to avoid exposing your name?
[13:16] <yamal> Though it might make sense to just remove a potential problem by getting rid of all template interfaces that aren't getting included in the package anyway
[13:16] <yamal> ScottK: but of course I'm not a licesing compatibilty expert
[13:18] <ScottK> yamal: Does the template not get installed in the binary package (I didn't have time for a full review last night)?
[13:18] <yamal> ScottK: no, only the (completely gpl-licensed) Default one does.
[13:18] <yamal> I already figured the other ones would be a licensing minefield
[13:19] <ScottK> persia: There's one template file with Apache licensing.  If it doesn't get included in the binary, it's probably OK.  What do you think?
[13:19] <ScottK> Maybe it doesn't need repacking then.
[13:19] <persia> As long as the file includes the proper licensing internally, and is not included in the binary package, seems OK to me.  I'd still encourage mention in debian/copyright.
[13:20] <ScottK> Definitely needs mention, but it needn't be repacked then.
[13:21] <ScottK> yamal: Consider my comment modified to add the copyright and license info to debian/copyright.
[13:22] <persia> Generally, repacking only makes sense to me if the source cannot be distributed.  As long as the binaries are constructed to be distributable, mixed-license source oughtn't be a problem (although it makes writing debian/copyright annoying and painful)
[13:23] <persia> (Note that the complete lack of copyright or licensing attribution counts as "source cannot be distributed")
[13:23] <persia> Err.  "copyright attribution or licensing"
[13:23] <yamal> ScottK/persia: just a mention of this file, or its complete license and such (for the stuff that isn't included in the package anyway)? In that case just repacking is much easier
[13:25] <ScottK> yamal: copyright and complete license as it's distributed with the source package.  Please don't repack.  You should only repack when there isn't a reasonable alternative (which there is in this case).
[13:25]  * yamal cries
[13:25] <ScottK> The concern I had that lead to my original comment was you can't link Apache and GPL licensed code.  Not an issue in this case.
[13:25] <persia> yamal: repacking means that we have to trust you.  For that, you'd have to come visit me for a couple weeks, at a minimum.  not repacking is likely easier than that :)
[13:26] <ScottK> yamal: I think it's just the one file that had the different license.  All license's must be mentioned, but minor copyright holders can be omitted.
[13:27] <yamal> persia: all you'd have to trust is 3 extra lines in get-orig-source ;)
[13:28] <yamal> ScottK: these extra templates have lots of different licenses and copyright holders I think
[13:28] <persia> yamal: Maybe, but still, it breaks the md5sum :(
[13:28] <ScottK> yamal: Maybe.  The google one was the one that lept out at me.
[13:28] <yamal> persia: upstream releases a zip file, it's allready modified anyway
[13:29] <ScottK> yamal: The thing I did to find this is run grep -ir copyright * in the source package.  Try that in the template dir and see how much comes up.  As long as the licenses aren't different, I don't think you need to mention them.
[13:34]  * persia didn't have enough time during REVU day, and has just advocated a few things.  Second advocates or rejections welcome.
[13:34] <yamal> smpl/templates/static/MochiKit/Sortable.js isn't any good either. It's copyright header tells the reader to find the full license in another file that isn't there
[13:34] <yamal> ScottK: that would be undistributable, woudln't it? ^^^
[13:35] <ScottK> yamal: It would be.  That needs to be removed.
[13:36] <psicus78> Hi everybody, just a question: isn't version 0.6.5+svn3280 less than 0.6.5+svn3280-0 ?
[13:36] <persia> psicus78: `dpkg --compare-versions $(new) gt $(old) && true || false` will answer your question better than any of us.
[13:37] <psicus78> persia: thanks
[13:37] <persia> psicus78: Oops.  That should be echo true and echo false.
[13:39] <juliank> ScottK: GPL-2+ and Apache License 2.0 can be linked, as the GPL code can be used under the GPL 3. (Does not apply to GPL 2 only code)
[13:40] <ScottK> juliank: Agreed.  I didn't check an entire GPL package to make sure it was all GPL 2+.
[13:40] <ScottK> For one little template file. ...
[13:40] <ScottK> It's not installed anyway, so it turns out to be a moot point.
[13:40] <persia> (especially one that isn't used in the build)
[13:47] <ScottK> persia: New lintian is in Gutsy backports now, so all the whining should be synchronized.
[13:50] <persia> ScottK2: Great.  Next cycle, let's do that sometime prior to the completion of the last REVU Day :)
[13:50]  * persia is amus3d by the timing, but agrees it will significantly improve policy compliance analysis for the next 11 weeks
[13:51] <yamal> is there a _the_ BSD License? thought there was several different licenses using that name?
[13:52] <persia> yamal: There is a "The BSD License".  You can find a copy in /usr/share/common-licenses/BSD.  It should not be used except by the Regents of the University of California, although there are many derivatives.  For new work, I'd recommend using ISC over BSD.
[13:52] <vorian> thanks for the ack ScottK :)
[13:52] <vorian> and being patient with me
[13:53] <ScottK> vorian: No problem.  Thank you for contributing.
[13:56] <yamal> persia: it's about files in 'plotkit'. the files all refer to their projects website (http://www.liquidx.net/plotkit/) for the license
[13:57] <yamal> but all it says there is "PlotKit is copyright (c) 2006 Alastair Tse. Licensed under the BSD License". Seems dangerous to just assume that equals the BSD license in /usr/share/...?
[13:58] <ScottK> A full copy of the license MUST be included in the package, so you either have to add the license or remove the files.  Since the BSD license says copyright University of California Regents and there is more than one BSD license, there's no way to know what they want by that.
[14:03] <warp10> Hi all!
[14:04] <LucidFox> hi warp10
[14:04] <warp10> hey LucidFox
[14:15] <effie_jayx> Is there a way of knowing which new files are not in debian/*.install when doing an upgrade?
[14:16] <effie_jayx> I have tried debuild -us -uc && dh_install --list-missing
[14:17] <effie_jayx> but it complains about unmet build dependencies. is it necesary then to install them before a pacakge upgrade... isn't there another way?
[14:20] <slytherin> effie_jayx: unmet dependency means that your machine doesn't have some of the packages needed for building. :-)
[14:21] <effie_jayx> slytherin,  I understand. but I can't use something like pbuilder to keep all those dependencies separate from my actual sistem?
[14:21] <effie_jayx> s/sistem/system
[14:22] <slytherin> effie_jayx: are you using hardy at present?
[14:22] <effie_jayx> slytherin,  not on this machine
[14:22] <effie_jayx> I generally build stuff here and take it to my other pc. this one is faster building
[14:23] <slytherin> effie_jayx: ahh then debuild may not work for you.
[14:24] <effie_jayx> slytherin,  I must have build dependencies. I got it
[14:28] <ScottK> effie_jayx: You can use pbuilder login to have a hardy chroot you can do stuff in.
[14:33] <effie_jayx> ScottK,  but I would need to install the dev tools
[14:33] <ScottK> Yes, but in the chroot, so it won't affect your system.
[14:33] <effie_jayx> ok
[14:33] <effie_jayx> sounds much better
[14:33] <ScottK> Once you exit the chroot, it all goes away.
[14:34] <effie_jayx> do a bindmount of the place where I hace the .source..
[14:34]  * effie_jayx gets to it
[14:36] <ScottK> Of just use cp from outside the chroot to copy the stuff into the chroot location.
[14:38] <effie_jayx> in an update of a package if debian/copyright is wrong
[14:38] <effie_jayx> example the URL for the project has changed
[14:39] <effie_jayx> how do I change that... I obviously didn't debianize the package... but I should add my modification
[14:39] <effie_jayx> how can I reflect it?
[14:41] <dcordero> hi
[14:41] <ScottK> Mention it in debian/changelog.  That's enough
[14:42] <emgent> heya
[14:50] <martoss> what can i do if pbuilder create fails with:
[14:50] <martoss>  -> installing dummy policy-rc.d
[14:50] <martoss> E: Malformed line 1 in source list /etc/apt/sources.list (dist)
[14:51] <martoss> ouch..., my fault :-)
[14:52] <Ace_NoOne> hi there - say I've got an hour to kill, how could I contribute? where to start?
[14:53] <slytherin> Ace_NoOne: an hour is not sufficient. :-)
[14:53] <LucidFox> ScottK, you will probably refuse, but I have two packages that I originally packaged for Ubuntu, perhaps you could sponsor them into Debian? (One of them has been waiting on m.d.n for ages)
[14:54] <Ace_NoOne> slytherin: I figured - nevertheless, give me some pointers, for the future
[14:54] <slytherin> Ace_NoOne: just kidding. you may want to confirm some bugs if you are using hardy or review some documentation
[14:55] <Ace_NoOne> okay, sounds good - is there a to-do list? I suppose there is a ticket system for development-related issues
[14:56] <ScottK> LucidFox: I'm not a DD.  Sorry (just started NM).
[14:57] <LucidFox> ah... I was told you were :) never mind then
[14:57] <slytherin> Ace_NoOne: launchpad.net is the bug tracking system.
[14:57] <slytherin> what is NM?
[14:58] <Ace_NoOne> slytherin: thanks - is there a to-do list for documentation issues as well?
[14:58] <slytherin> Ace_NoOne: #ubuntu-doc is appropriate channel for asking
[14:59] <Ace_NoOne> ok slytherin, cheers for now
[15:02] <slytherin> is it a policy that unless 'all' the binary packages related to a source package don't get accepted in 'New' queue, they won't show up on mirrors? I am waiting for latest linux-image-powerpc to fix a booting issue but looks like linux-image-lpia is still waiting for acceptance which is causing other binaries not being uploaded to mirrors.
[15:08] <geser> slytherin: NM = New Maintainer application in Debian
[15:11] <geser> slytherin: you mean the linux 2.6.24-6.10 upload? lpia is the only arch were it successfully build
[15:11] <slytherin> geser: Really? I assumed it built for all arch. :-(
[15:12] <geser> slytherin: https://edge.launchpad.net/ubuntu/hardy/+source/linux/+builds
[15:13] <geser> slytherin: one arch in binary NEW should be blocking other moving to the archive
[15:13] <effie_jayx> ScottK,  I did it. :D but what should I be looking for.. I was specting some list. I have to look through a log?
[15:13] <slytherin> hmm
[15:13] <slytherin> funny error - EE: Missing modules (start begging for mercy)
[15:13] <geser> slytherin: in the case of linux every ABI jump needs to go through binary NEW as the ABI is included in the package name
[15:16]  * slytherin will be unable to try new kernel on his ibook for few more days. :-(
[15:20] <slytherin> geser: the problem for linux build looks to be same everywhere - 2 missing modules
[15:23] <bddebian> Heya gang
[15:23] <effie_jayx> hey bddebian
[15:23] <bddebian> Hello effie_jayx
[15:25] <sistpoty|work> hi bddebian
[15:26] <geser> Hi bddebian!
[15:26] <bddebian> Hi sistpoty|work, geser
[15:27] <dcordero> somebody know can i add add extra repositories to my pbuilder?
[15:27] <geser> dcordero: the wiki page has it, let me find the url
[15:28] <tonyyarusso> persia: I should be all set - I'm informed that it should have been done with LP, not REVU, so everything's in line over there now instead.
[15:29] <geser> dcordero: sorry, I misremembered
[15:29] <geser> dcordero: try pbuilder --update-config and --other-mirror
[15:29] <dcordero> geser, ;) thanks
[15:36] <slytherin> dcordero: you can modify your pbuilderrc and then pbuilder update --override-config
[15:36] <dcordero> my main problem is that all the changes are not saved :/
[15:36] <RainCT> Hey
[15:37] <dcordero> for example, if i update a extra repository then if i login to pbuilder with --login i can check that the souces.list is without my lines :/
[15:39] <slytherin> dcordero: you mean you do pbuilder login before adding repository or after adding repository?
[15:39] <dcordero> after of course
[15:41] <slytherin> dcordero: Did you do - pbuilder update --override-config - after adding repos?
[15:41] <dcordero> nop
[15:41] <dcordero> :/
[15:53] <nxvl_work> dcordero: i have just replied on Bug #177443
[15:53] <ubotu> Launchpad bug 177443 in photoprint "photoprint should recommend or require icc-profiles package" [Undecided,Confirmed] https://launchpad.net/bugs/177443
[15:55] <ScottK> dcordero: There is also a save after login option on pbuilder (man pbuilder for the exact syntax).
[15:56] <uniscript> package versioning question. Is it true that a package in a later distro must have a higher version number than one in an earlier distro otherwise distupgrade won't work?
[15:58] <dcordero> nxvl_work, ok i understand know, the only problem is that i sent the wrong file. The needed is .debdiff instead diff.gz
[16:00] <ScottK> uniscript: Yes.  Where won't work means you don't get the right version installed.
[16:00] <uniscript> OK so I have to build my packages in time distro order then :(
[16:00] <uniscript> I was hoping to build then reverse time order (going back in time)
[16:00] <ScottK> That or just number them in reverse order
[16:01] <uniscript> hmm there is that
[16:01] <uniscript> OK thanks, even if I didn't like the answer at least I know what i have to do :)
[16:01] <nxvl_work> dcordero: exactlt
[16:01] <ScottK> uniscript: When I'm building for a PPA I normally version ~release~ppa1 where release is the name I'm building for.
[16:01] <nxvl_work> dcordero: exactly
[16:01] <ScottK> uniscript: Since they're in alphabetical order, that gives you ascending versions through the releases.
[16:02] <uniscript> yup that's one way, thanks
[16:02] <ScottK> uniscript: i.e. 1~dapper1~ppa1 is a lower version number than 1~edgy1~ppa1
[16:02] <dcordero> nxvl_work, ok, thanks for help, i'll sent the correct .debdiff
[16:02] <uniscript> btw is ~ magic or the same as - ?
[16:02] <ScottK> It's also the naming scheme we use for backports.
[16:03] <ScottK> ~ is less than anything else.
[16:03] <uniscript> so if you use it for backports, shouldn't I use something below that?
[16:03] <ScottK> So 1~1 is a lower version number than 1
[16:03] <uniscript> aha
[16:03]  * sistpoty|work heads home
[16:03] <sistpoty|work> cya
[16:03] <ScottK> uniscript: Stick the ppa bit on the end and you're clear of namespace collission
[16:04] <uniscript> OK. Great. Thanks
[16:04] <uniscript> so 1~1~1 < 1~1
[16:04] <jpatrick> yep
[16:04] <uniscript> hey I can do debianmaths :)
[16:04] <jpatrick> ScottK: great news on our Debian thing
[16:05] <ScottK> I agree.  I'ts definite progress.
[16:05] <geser> uniscript: dpkg --compare-versions 1~1~1 \< 1~1 && echo true || echo false gives true
[16:06] <uniscript> btw is there a nice script that will take a debian dir and tarball and make me 4 debs (or more)?
[16:06] <ScottK> jpatrick: We just need to keep the naysayers on our side of the interface under control.
[16:06] <uniscript> (I have pbuilder, just don't want to type lots of commands)
[16:06] <jpatrick> ScottK: well, I'm going to keep shoving NEW Kubuntu packages towards them
[16:06] <ScottK> Excellent.
[16:08]  * jpatrick goes to join ubuntu-dct
[16:08]  * uniscript says  thanks and slopes off to bed
[16:10] <mok0> ScottK: ping
[16:10] <jpatrick> mok0: yeah, he's around
[16:11] <ScottK> mok0: Pong - I saw the updated debdiff, but haven't had a chance to look at it yet.
[16:11] <mok0> ScottK: I hope it's more to your liking :-)
[16:11] <ScottK> From your description I imagine it will be.
[16:12] <mok0> ScottK: I also repacked torque's tarball to exclude that postscript file
[16:12] <ScottK> mok0: OK.  You understand the issue?
[16:13] <mok0> Yes, I do
[16:13] <mok0> But I don't think it's what upstream intended
[16:13] <ScottK> It was interesting to me to discover than grep works on postscript files.  It hadn't ocurred to me that it would.
[16:13] <mok0> ScottK: well, they are plain ascii files
[16:13] <ScottK> Agreed, but absent proof, there's nothing we can do.  Maybe you could contact them.
[16:14] <ScottK> Yeah.  I just hadn't thought about it before.
[16:14] <mok0> ScottK: I could do that, but I am hoping that the package can pass before feature freeze
[16:14] <ScottK> mok0: I wasn't thinking about for this upload, but for a future update.
[16:14] <mok0> ScottK: yes, good idea
[16:15] <mok0> Who has the final verdict on the license issue?
[16:15] <jpatrick> archive admins?
[16:16] <mok0> I'd like to make sure they notice that parts of the license has expired
[16:17] <jpatrick> best put a note in debian/copyright then
[16:18] <ScottK> Excellent suggestion.
[16:18] <mok0> jpatrick: Hmm, I don't want to put my interpretation of the license in copyright. I just want to ping the archive admins
[16:19] <ScottK> mok0: But you've got a reference that says part of the license is expired.  I think that's not your interpretation, but defacto part of the license.
[16:20] <mok0> ScottK: Right. It should not be necessary, but several people who have looked at the license missed that fact
[16:20] <ScottK> I think it's worth adding for clarity.
[16:20] <mok0> ScottK: Ok
[16:22] <nxvl_work> dcordero: you also need to "attach" the debian bug report to the LP one
[16:23] <dcordero> my debdiff size if 1,2 Mb :/
[16:23] <ScottK> That's fine.
[16:24] <nxvl_work> dcordero: whats the output of "lsdiff *.debdiff"
[16:24] <slytherin> time to go home. Bye all. See you tomorrow.
[16:24] <mok0> ScottK: Should I say then that the license with out pp. 1 and 2 is reminiscent of the BSD license with an advertising clause?
[16:25] <dcordero> nxvl_work,  /tmp/ files
[16:25] <ScottK> No.  The thing you need to say about is the parts of the license that no longer apply.  The advertising bit I think is OK.
[16:25] <nxvl_work> dcordero: pastebin it please
[16:26] <nxvl_work> dcordero: http://pastebin.com/
[16:27] <dcordero> nxvl_work, http://pastebin.com/m4da384b6
[16:27] <nxvl_work> dcordero: something is wrong in there
[16:28] <nxvl_work> dcordero: how did you build the package?
[16:28] <dcordero> i have download the package from debian unstable
[16:28] <dcordero> i have apply my diff.gz to it
[16:28] <dcordero> i have debuild it
[16:28] <dcordero> i have download the package from ubuntu
[16:29] <nxvl_work> mmm
[16:29] <nxvl_work> that's not the correct way
[16:29] <emgent> heya nxvl_work :)
[16:29] <nxvl_work> did you see the wiki link i sent to you?
[16:29] <nxvl_work> emgent: hi!
[16:29] <dcordero> not yet
[16:29] <nxvl_work> dcordero: there is step by step how the merges must be done, give it a look
[16:30] <dcordero> nxvl_work, ok
[16:30] <nxvl_work> dcordero: if you don't understand anything just ask :D
[16:39] <superm1> persia, thats why i said its important to check what patching system the package uses
[16:40] <superm1> and said that those cases need to be handled differently
[16:44] <dholbach> does anybody of you use amule?
[16:44] <dholbach> if so, it'd be nice if somebody took care of bug 189243
[16:44] <ubotu> Launchpad bug 189243 in libcrypto++ "please sync libcrypto++ 5.5.2-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/189243
[16:45] <dholbach> (the new libcrypto++ will require amule to be rebuilt / transitioned)
[16:47] <amarillion> Is anybody going to FOSDEM this year by chance?
[16:47] <amarillion> http://www.fosdem.org
[16:51] <nxvl> dholbach: i will take a look :D
[16:51] <nxvl> when i fix my xorg
[16:51] <dholbach> nxvl: party on!
[16:51] <dholbach> :-)
[16:56] <mathiaz> soren: if Conflicts and Replaces are used at the same time, it means that the old package should be removed.
[16:57] <mathiaz> soren: in our case, we just want mysql-server to override mysqld.8 from mysql-doc-5.0
[16:57] <nxvl> dholbach: what is what you are asking for? to do the merge or to prepare amule for that merge?
[16:58] <soren> mathiaz: Well, Replaces certainly allows mysql-server-5.0 to overwrite the file.
[17:03] <soren> mathiaz: There's plenty of precedent for doing what I'm suggesting, but I must admit, I can't seem to come up with a really good explanation why the conflict needs to be set.
[17:04] <soren> mathiaz: Well...
[17:04] <mathiaz> soren: using Conflicts makes sure that the old version of the package is not installed anymore.
[17:04] <ScottK> Which would seem appropriate in this case.
[17:04] <soren> mathiaz: Yeah.. And while it's not *strictly* necessary, you probably want them to be in sync.
[17:05] <mathiaz> soren: right. At the same time, there is a new package for mysql-doc-5.0 which works well with mysql-server-5.0
[17:05] <mathiaz> soren: so the two packages should be upgraded correctly.
[17:06] <mathiaz> soren: I wonder what happens if the restricted repository has been disabled, and Conlicts is not used.
[17:06] <soren> mathiaz: Then it just overwrites the file from the doc package.
[17:06] <mathiaz> soren: then the old version mysql-doc-5.0 wouldn't be upgraded and would stay installed.
[17:06] <soren> Right.
[17:07] <mathiaz> soren: in this case it wouldn't be a problem.
[17:07] <mathiaz> soren: with a Conflicts, mysql-doc.5.0 would be removed.
[17:07] <mathiaz> soren: which is not something that would be expected.
[17:08] <soren> That's true.
[17:08] <soren> This is quite a bit of a special case as the file is not just moving between packages, but between components.
[17:09] <Nightrose> amarillion: yes I know a few who will - why?
[17:10] <tjaalton> superm1: ooh, project-x! :)
[17:10] <superm1> tjaalton, yeah we needed it for mytharchive in trunk, but i think everyone wins with that one :)
[17:11] <mathiaz> soren: so what about using Replaces only and test the upgrade to see if it has the expected outcome ?
[17:11] <tjaalton> superm1: indeed, I'm happy now that I upgraded my vdr box to hardy :)
[17:11] <tjaalton> so I can test that
[17:11] <soren> mathiaz: Sounds good.
[17:11] <superm1> tjaalton, i dont think in its current form it forces you to use the iced tea jre, so please file bugs related to that if they crop up
[17:12] <soren> mathiaz: Replaces should be sufficient to kill the bug.
[17:12] <superm1> (i tested it with iced tea as my jre and things worked)
[17:12] <tjaalton> superm1: ok, I'll try to find time to test it soon
[17:13] <mathiaz> zul: do you tackle mysql upgrade problem ?
[17:14] <mathiaz> zul: only using a Replaces, instead of Replaces+Conflicts ?
[17:14] <zul> Replaces+Conflicts right now but I can remove the Conflicts after lunch
[17:16] <mathiaz> zul: were you able to reproduce the upgrade failure ?
[17:16] <zul> no I guess I didnt have mysql-docs installed
[17:25] <Riddell> mok0: ping
[17:25] <mok0> Riddell: pong
[17:25] <Riddell> mok0: what type of data is wvs1.dat?
[17:26] <mok0> Riddell: What do you mean?
[17:26] <Riddell> mok0: well specifically is it a preferred modifyable form
[17:26] <Riddell> this is in xtide-wvs1-data-20020219
[17:27] <mok0> Riddell: I don't think it's easily modifiable
[17:27] <Riddell> mok0: ok, multiverse it is then
[17:27] <mok0> Riddell: The data is public domain
[17:28] <Riddell> mok0: right, but it it's not in source form then it's non-free
[17:28] <mok0> Riddell: how do you define "source form"?
[17:29] <Riddell> mok0: "preferred modifiable form"
[17:29]  * mok0 googles
[17:30] <mok0> ... and finds nothing of interest...
[17:30] <Riddell> if it's the format that's used when editing and modifing the data that's source, if it's just a binary blob without source then it's non-free
[17:30] <Riddell> which is fine, just means it goes into multiverse
[17:31] <mok0> Riddell: ok, whatever. It's just the non-free part... it's actually not so
[17:31] <Riddell> without source, it's non free
[17:31] <Riddell> freedom is about more than just being able to copy it
[17:31] <mok0> Riddell: OK.
[17:32] <mok0> Riddell: you can modify it using a program that reads/writes the data file. I don't see why you'd want to modify the world's shorelines though :-)
[17:33] <mok0> Riddell: I mean, it's _legal_ to modify it
[17:36] <soren> mok0: Well, if it's modifiable with a particular program, that sounds like it actually *is* in its preferred modifiable form.
[17:37] <amarillion> Nightrose, well I thought it'd be cool to meet up with the MOTU crowd
[17:37] <soren> mok0: The question is: Does someone, somewhere have a "source file" of some sort that is used to generate that file or would anyone who wanted to edit that file prefer to edit that file directly (with whatever program)?
[17:38] <mok0> soren: I just found something
[17:38] <mok0> You can get the data in ascii format
[17:38] <Nightrose> amarillion: come to R!ddel´s packaging session then ;-)
[17:38] <mok0> http://rimmer.ngdc.noaa.gov/mgg/coast/getcoast.html
[17:39] <amarillion> ah cool, I didn't see that in the schedule
[17:39] <amarillion> yet
[17:39] <amarillion> I'll be there :)
[17:39] <soren> mok0: It's like.. If you have a package that has some pre-rendered graphics in it, but you don't have the povray source (or whatever it's made in), but you have the graphics itself, then even though you can edit the images directly with the gimp or whatever, the "preferred modifiable form" is the povray source.
[17:40] <mok0> soren: Ok, makes sense.
[17:40] <mok0> soren: I think Riddell went off  to upload the data to multiverse...
[17:41] <soren> Riddell: Are you reading this?
[17:41] <ScottK> mok0: Well if you can add the ascii form to a updated package, then it can be moved.
[17:41] <mok0> ScottK: That would be a bit silly
[17:42] <ScottK> Why?
[17:42] <soren> mok0: The question you need to ask yourself is:
[17:42] <ScottK> What is the preferred form to edit the data?
[17:42] <mok0> ScottK: Because -- users would not need it, really.
[17:42] <soren> If you wanted to edit those data, would you be making changes directly to that file with whatever program is needed to do so, or would you prefer to edit it somewhere else and then generate that file.
[17:42] <ScottK> mok0: But that's nothing to do with the point.
[17:43] <soren> If the former, then everything is good. It doesn't have to be clear text if that's not the preferred form for editing it.
[17:43] <mok0> ScottK: Well, we'd be having a package with data that nobody cares about
[17:43] <Riddell> mok0: yes, I accepted into multiverse
[17:43] <mok0> Riddell: thx
[17:43] <Riddell> soren: it would still need a way to compile one into the other
[17:43] <soren> Riddell: Yes.
[17:43] <soren> Riddell: I was just getting to that bit :)
[17:44] <mok0> Riddell: the ascii source is available, it even has instructions on how to use it in matlab
[17:44] <soren> It wouldn't help to just *also* ship the ASCII version if it's not what the program uses.
[17:44] <mok0> soren: exactly. you need some way to "compile" it
[17:44] <soren> Precisely.
[17:45] <soren> Otherwise, it's not really the preferred modifiable form.
[17:45] <soren> It just looks like it to the untrained eye.
[17:45] <soren> "Hey, it's ASCII. It must be what I'm supposed to edit."
[17:45] <Riddell> suggesting that users would not need source code is unlikely to go down well in a free software project
[17:45] <soren> GIF's can be turned into postscript, which is ASCII, but I'd sure prefer to edit GIF's to edit the resulting postscript.
[17:46] <mok0> Riddell: Until global warming really gets going, I doubt that anyone would want to edit the shoreline data :-)
[17:46] <soren> mok0: They might.
[17:46] <soren> mok0: For experimenting or whatever.
[17:47] <mok0> I settle for non-free :-)
[17:47] <mok0> those 2 people can get the data in ascii form from the web
[17:48] <mok0> Riddell: Are Jave class files "non-free"??
[17:48] <mok0> Java
[17:48] <Riddell> mok0: yes of course
[17:49] <mok0> Riddell: you can generate the .java code from them with a program
[17:49] <soren> mok0: If you wanted to edit them, any sane person would prefer to edit the .java file.
[17:49] <Riddell> if you have the source then that's fine
[17:49] <soren> mok0: That's all that counts.
[17:49] <LucidFox> mok0> You can generate source code from .NET assemblies as well
[17:49] <Riddell> ..and the build system and a free compiler
[17:49] <LucidFox> that doesn't make them free
[17:49] <soren> that's completely beside the point.
[17:50] <mok0> so, what matters is the _format_?
[17:50] <soren> YEs.
[17:50] <soren> I can disassemble the linux kernel, too, and fiddle around with a hex editor, but I'd by far prefer to edit the C source code.
[17:51] <mok0> soren: that's not the same thing as with java, though
[17:51] <mok0> soren: I think all that's lost in the disassembly of .class files is the comments
[17:51] <soren> mok0: Not completely, but for the sake of this argument, the analogy is sound.
[17:52] <mok0> soren: your povray example was different, though
[17:52] <soren> I realise.
[17:52] <soren> What matters is the format any sane person would prefer to work with.
[17:53] <mok0> soren: I understand.
[17:53] <mok0> But you still have the _freedom_ to reformat and edit
[17:54] <soren> I've come across people who get a kick out of editing java byte code. They're clearly insane and not interesting in this discussion :)
[17:54]  * soren -> cook dinner
[17:54] <mok0> soren: you don't need to. you can disassemle byte code into perfectly understandable java source code
[17:54] <mok0> assemble
[17:55] <mok0> Even has the same variable names
[17:59] <mok0> soren, btw, the mac_addr trick solved my kvm problems completely! We have now deployed a couple of virtual servers in testing for production!
[18:01] <ScottK> Any xubuntu folks here?
[18:01] <jeromeg> yep
[18:02] <ScottK2> jeromeg: Do you know janimo?
[18:02] <jeromeg> ScottK2: jani monoses ?
[18:02] <ScottK2> Yes
[18:02] <jeromeg> ScottK2: the one that modifies our seeds
[18:02] <jeromeg> :)
[18:03] <ScottK2> From reading hardy-changes it looks like she's uploading her Sugar packages with -1 versions instead of -0ubuntu1 and they aren't from Debian.  Someone ought to mention this to her.
[18:03] <ScottK2> jeromeg: ^^
[18:03] <Riddell> possible gender realignment
[18:03] <ScottK2> OK.
[18:03] <ScottK2> Her/His
[18:03] <ScottK2> Sorry
[18:04] <Riddell> ScottK2: I've just had this conversation with him on ubuntu-archive
[18:04] <ScottK2> OK.  Good.  Nevermind then jeromeg.
[18:04] <Riddell> alas I let through a couple before I noticed
[18:04] <jeromeg> ScottK2: ok
[18:04] <jeromeg> got to go
[18:04] <jeromeg> bye
[18:04] <gpocentek> ScottK2: the sugar packages are not related to Xubuntu in fact :)
[18:05] <gpocentek> unless he changed this without any warning
[18:05] <ScottK2> OK.
[18:06] <ScottK2> My mistake about that then.
[18:06] <ScottK2> Thanks.
[18:06] <gpocentek> no problem
[18:29] <mok0> Riddell: xtide-data should be moved to multiverse, then
[18:40] <mruiz> for new upstream versions, should I attach to the bug the interdiff only?
[18:41] <mok0> mruiz: as I understand it, it has to be the diff.gz
[18:42] <mruiz> mok0, I asked weeks ago and it's under discussion...
[18:43] <mok0> mruiz: look in the minutes of last MOTU meeting
[18:43] <mruiz> thanks mok0 ... I'll do it
[18:43] <ScottK> mruiz and mok0: diff.gz
[18:43] <mok0> mruiz: they decided against the interdiff
[18:43] <mok0> ah, there you go :)
[18:43] <ScottK> BTW, you don't have to be an actual MOTU to come to the meetings and discuss.
[18:44] <mruiz> ScottK, I forgot it :-(
[18:45] <mok0> ScottK: xtide-data also contains binary data, so cf. discussion above, it should be moved to multiverse
[18:46] <mok0> ... and then it would make sense to move xtide there as well
[18:46] <ScottK> Which is then a discussion point for you with upstream about wouldn't they like it to be Free so more people could use it.
[18:46] <ScottK> No
[18:46] <ScottK> Not unless it's a hard dependency
[18:46] <mok0> ScottK: Let me check
[18:46] <mok0> ScottK: but xtide is useless without the data
[18:46] <ScottK> Hmm.
[18:47] <ScottK> Note sure.
[18:47] <ScottK> Can the data be gotten elsewhere?
[18:47] <mok0> I don't know off-hand
[18:48] <ScottK2> I'm not sure what the right answer is then.
[18:48] <ScottK2> I'd ask Riddell.
[18:49] <jdong> well.. you can'
[18:49] <jdong> err
[18:49] <mok0> ScottK; he's off at the moment
[18:49] <jdong> you can't depend on the multiverse -data package anyway, right?
[18:49] <jdong> unless you want to just "make up" a virtual package
[18:49] <jdong> which sounds shady
[18:50] <mok0> xtide recommends: xtide-data
[18:50] <jdong> well a recommends is fine
[18:50] <jdong> does the program do anything at all without its -data?
[18:50] <mok0> jdong: no, not really
[18:50] <jdong> :-/
[18:50] <mok0> jdong: it doesn't crash
[18:50] <jdong> technically I think the "right answer" is the engine goes in universe and the data goes in multiverse
[18:51] <jdong> but it's kinda silly to me until there's actually a free -data alternative
[18:51] <mok0> jdong: well, that's the consequence of the rules
[18:51] <mok0> jdong: the data _is_ free, it
[18:51] <mok0> is in the public domain
[18:51] <jdong> then why does it go into multiverse?
[18:51] <mok0> jdong: but it is in binary form
[18:51] <jdong> well... what kind of data are we talking about?
[18:52] <mok0> jdong: "non-preferred modifiable format"
[18:52] <jdong> like images or sounds?
[18:52] <mok0> jdong: some of it is "harmonics data"
[18:52] <mok0> the program uses it to predict the tide at any given time
[18:52] <jdong> well ScottK2 is right, this seems like something to talk to an archive admin about
[18:53] <mok0> jdong: I did
[18:54] <mok0> jdong: I packaged the shore-line data, that shows a map of the world on xtide's display, and it must go in multiverse because it is binary
[18:54] <mok0> jdong: I then discovered, that xtide-data, which is in universe, also contains binary data.
[18:54] <mok0> jdong: so, consequently, it should be moved as well
[18:55] <ScottK2> jdong: I'm testing for a postgresql 8.3 backport now.  So far Gutsy and Feisty look good.
[18:55] <jdong> ScottK2: cool
[19:07] <rulus> If somebody has time to review my package (http://revu.ubuntuwire.com/details.py?package=gtkvd) that would be great. I'd really like to have it in for Hardy. Thanks :)
[19:19] <jdong> jussi01: are you still looking for work to do? I've got a really simple favor to ask
[19:21] <jussi01> jdong: ask!
[19:21] <jussi01> !ask | jdong
[19:21] <ubotu> jdong: Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
[19:21] <jussi01> ;P
[19:21] <jdong> jussi01: file a sync request for bzr-svn from Sid
[19:22] <jdong> please and thank you and all that stuff
[19:22] <jussi01> jdong: ok, sure :D
[19:23] <jdong> now I've got to get to class :)
[19:23] <jussi01> see ya
[19:36] <Riddell> ScottK2, mok0: xtide doesn't seem to depend on xtide-data
[19:36] <mok0> Riddell: No, it's recommended
[19:36] <mok0> Riddell: but it also contains binary data
[19:37] <Riddell> meh
[19:38] <mok0> Riddell: you started this ;-)
[19:40] <Riddell> mok0: I don't see any binary data in xtide source
[19:40] <mok0> Riddell: Go down in the file
[19:41] <Riddell> mok0: pardon?
[19:41] <mok0> Riddell: near the top of the file, a bunch of string data is stored. Further down in the file there are binary numbers
[19:42] <Riddell> mok0: are you talking about xtide or xtide-data?
[19:42] <mok0> xtide-data
[19:42] <Riddell> right, I already put that into multiverse
[19:42] <mok0> Riddell: the file  harmonics-dwf-20070318-free.tcd
[19:43] <cbx33> hey all what's the last date I can submit bug fixes to universe?
[19:43] <Riddell> cbx33: a few days before release
[19:43] <cbx33> Riddell, which is when?
[19:43] <cbx33> ;)
[19:43] <Riddell> well universe, up until release
[19:44] <Riddell> !release
[19:44] <cbx33> ok
[19:44] <cbx33> great
[19:44] <ubotu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
[19:44] <mok0> Riddell: Can you take care of bug 188093 at the same time?
[19:44] <ubotu> Launchpad bug 188093 in xtide-data "[needs-sync] xtide-data-20070318-1 from sid" [Undecided,New] https://launchpad.net/bugs/188093
[19:48] <jussi01> when using request sync, do I need to include the version, and if so, what is the syntax?
[19:49] <pochu> jussi01: not neccesarily. Only if requestsync fails to autodetect it.
[19:49] <jussi01> pochu: ok, thanks
[19:49] <pochu> jussi01: requestsync --help (or requestsync(1) ) will tell you the syntax, in case you need to specify it
[19:49] <jussi01> pochu: ahh, great, thanks
[19:50] <jussi01> hmmm, however Im getting this error: The environment variable DEBEMAIL needs to be set to make use of this script.
[19:50] <pochu> jussi01: set it :)
[19:50] <jpatrick> jussi01: put: "export<EMAIL_ADDRESS>into .bashrc
[19:51] <jussi01> jpatrick: thanks
[19:52] <jcfp> any revu admins around? please resync the key ring
[19:53] <jpatrick> jussi01: https://wiki.kubuntu.org/SyncRequestProcess
[19:53] <geser> jpatrick: the other sync :)
[19:54] <jussi01> jpatrick: Im there...
[19:54] <jpatrick> geser: ah, sorry
[19:55] <geser> jpatrick: sorry, to many different sync requests in the last few lines
[19:56] <RainCT> persia: ^
[19:56] <geser> jpatrick: I've seen jcfp requesting a keyring sync and you answering with a wiki page without checking the nicks
[19:57] <jpatrick> geser: what? My msg was for jussi01
[19:57] <geser> exactly
[19:57] <geser> my error
[19:57] <jpatrick> err
[19:57] <jussi01> jpatrick: still giving me the error... :(
[19:58]  * jpatrick pours coffee for himself and geser
[19:58] <jpatrick> jussi01: restart the konsole session
[19:58] <jussi01> aye
[19:59] <geser> ". .bashrc" would also work
[20:00] <jussi01> jpatrick: bug filed :)
[20:00]  * RainCT would be happy if someone reviewed http://rainct.homelinux.net/openbox_3.4.6-0ubuntu1.dsc :)
[20:05] <mok0> Riddell: ping?
[20:05] <Riddell> hi mok0
[20:06] <mok0> Riddell: did you see the message about bug 188093?
[20:06] <ubotu> Launchpad bug 188093 in xtide-data "[needs-sync] xtide-data-20070318-1 from sid" [Undecided,New] https://launchpad.net/bugs/188093
[20:07] <Riddell> mok0: yes, but I'm busy on other archive bits just now
[20:07] <mok0> Riddell: OK, fine, I just wanted to make sure that you didn't miss it
[20:09] <jussi01> jdong: when you come back from class, bug 189361
[20:09] <ubotu> Launchpad bug 189361 in bzr-svn "Please sync bzr-svn 0.4.7-1  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/189361
[20:11] <firestormx37> i would like to get involved by helping out with packaging or bugs, can anyone help me get started.  I have read a lot of the guides and faqs on the wiki, but I am not sure where to start.  I'm looking for something easy to start with.
[20:12] <cbx33> hey guys
[20:12] <cbx33> if I have a pacakge called memaker-themes
[20:12] <cbx33> and it's version is 0.1.1
[20:12] <cbx33> and i set it at 0ubuntu1
[20:12] <cbx33> what should the orig.tar.gz call
[20:12] <jussi01> firestormx37: I assume you have looked at /topic ?
[20:12] <cbx33> cos debuild is complaining
[20:12] <firestormx37> no. i'm sorry what is that
[20:13] <cbx33> (expected memaker_0.1.1.orig.tar.gz or memaker-themes-0.1.1-0ubuntu1.orig)
[20:13] <jpatrick> cbx33: memaker-themes_0.1.1.orig.tar.gz
[20:13] <mruiz> ff3 will be the default browser for Hardy?
[20:13] <jussi01> firestormx37: type: /topic into your irc client ;)
[20:13] <cbx33> jpatrick, that's what I thought
[20:13] <cbx33> but it doesn't like it
[20:13] <cbx33> as you can see
[20:13] <fdoving> cbx33: it depends on the name you set in debian/control - for the source package.
[20:14] <cbx33> Source: memaker-themes
[20:14] <fdoving> cbx33: you can have a memaker-theme binary package, coming from a memaker_0.1.1.orig.tar.gz source.
[20:14] <ScottK2> mruiz: Yes
[20:14] <cbx33> fdoving,
[20:14] <ScottK2> For Ubuntu
[20:14] <cbx33> yes this will produce multipkle binaries
[20:14] <cbx33> but it's just not picking up the source pacakge
[20:15] <cbx33> source tar sorry
[20:15] <firestormx37> jussi01, if you are talking about the wiki site listed there, then yes I have read them, but i'm still not sure how to get started
[20:15] <mruiz> thanks ScottK2 ... then firefox as depends should be replaced by firefox3
[20:16] <vemon> does it make sense to create a get-orig-source rule (when there is a need to repack) which uses uscan to get the source?
[20:16] <vemon> that feels a little stupid if what's wanted is really the original source (and not the newest) for the package
[20:16] <cbx33> fdoving, ??
[20:17] <vemon> refering to: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
[20:17] <fdoving> cbx33: give debuild what it expects, (expected memaker_0.1.1.orig.tar.gz or memaker-themes-0.1.1-0ubuntu1.orig)
[20:17] <cbx33> ko
[20:17] <cbx33> it can't have the former
[20:17] <cbx33> that's in use
[20:17] <fdoving> cbx33: as the latter is a directory, which i personally rarely use directly, i'd go fo memaker_0.1.1.orig.tar.gz
[20:18] <mok0> ScottK: Is the new debhelper being backported?
[20:18] <ScottK2> mruiz: Not replaced.  I'd do firefox-3.0 | firefox
[20:18] <cbx33> fdoving, but that presents a bit of a problem
[20:18] <ScottK2> As I understand it firefox will still be in Universe
[20:18] <cbx33> as I already have a memaker_0.9.4.orig.tar.gz
[20:18] <fdoving> cbx33: you should use the same orig.tar.gz, then only thing that changes once you add your 0ubuntu1 changes, is the .diff.gz
[20:18] <cbx33> well......the themes pacakge is going to be totally seperate
[20:19] <cbx33> at the mo it's not going into univers
[20:19] <cbx33> just into a ppa
[20:19] <fdoving> if it's going to be totaly separate you need to edit debian/control and set the source name to something new, memaker is taken.
[20:19] <fdoving> memaker-themes
[20:19] <fdoving> for example.
[20:19] <cbx33> ^^^ I did
[20:20] <cbx33> Source: memaker-themes
[20:20] <fdoving> then debuild should expect memaker-themes_0.1.1.orig.tar.gz
[20:20] <cbx33> yeh
[20:20] <cbx33> but it doesn't
[20:21] <cbx33> the only thing that could be causing the problem is the directory it's in
[20:21] <cbx33> memaker-themes-0.1.1-0ubuntu1
[20:21] <cbx33> is that wrong?
[20:22] <fdoving> no. that doesn't really matter.
[20:22] <fdoving> debuild will figure that out.
[20:22] <cbx33> is it because of the 0ubuntu1 perhaps?
[20:25] <Coper> Can a MOTU review my new package http://revu.ubuntuwire.com/details.py?package=console-freecell
[20:26] <cbx33> ok why the heck isn't this working
[20:26] <jpatrick> cbx33: call the dir memaker-themes-0.1.1
[20:26] <cbx33> ahhh got it
[20:26] <cbx33> i think
[20:27] <cbx33> changelog
[20:46]  * RainCT would be happy if someone reviewed http://rainct.homelinux.net/openbox_3.4.6-0ubuntu1.dsc :)
[20:48] <ScottK2> RainCT: Please put it on REVU if you want it reviewed.
[20:48] <jpatrick> RainCT: that's twice today
[20:59] <mruiz> hahaha
[21:00]  * RainCT decides he will just upload it
[21:01] <dcordero> hi
[21:01] <RainCT> Hi dcordero
[21:02] <dcordero> i am fully lost with merging process pfff
[21:02] <RainCT> dcordero: what's the problem?
[21:02] <dcordero> i have read 4 times the wiki about merging :)
[21:02] <dcordero> my packages it isn't on Mom
[21:02] <RainCT> heh
[21:03] <RainCT> the MoM time is over (until Hardy+1's cycle starts)
[21:03] <dcordero> so, i cant merge?
[21:04] <RainCT> you can, just without MoM (well, or you might be able to still use it, but it isn't needed anyway)
[21:05] <dcordero> and his husband Dad dead too?
[21:05] <RainCT> to do a merge basically you just need to dget the source from Debian that you want to merge (you'll find a link to the .dsc in packages.debian.org), unextract it (dpkg-source -x *.dsc)
[21:06] <dcordero> grab-merge only do that?
[21:06] <mok0> dcordero: http://dad.dunnewind.net/universe.php
[21:07] <mok0> ubotu, ! dad
[21:07] <ubotu> Sorry, I don't know anything about dad - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[21:07] <mok0> ubotu, ! merge
[21:07] <ubotu> Sorry, I don't know anything about merge - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[21:07] <dcordero> mok0, i know dad
[21:08] <mok0> dcordero: then why don't you just use the grab-merge.sh tool that's there?
[21:08] <RainCT> then get the source from Ubuntu too, copy the text from Ubuntu's changelog into Debian's (only leave the new entries at the top but replace all others)
[21:09] <RainCT> (well, or get the changelog from packages.ubuntu.com if you don't need Ubuntu's source)
[21:09] <mok0> RainCT:  grab-merge gets all that stuff in 1 go
[21:09] <RainCT> and then apply the changes you want to Debian's source, add a changelog entry and ready
[21:09] <dcordero> mok0, my package dont appear on Dad, that is the problem
[21:09] <RainCT> mok0: yes, but I don't like it :P
[21:10] <mok0> Ah, you guys!! :-P
[21:10] <RainCT> as it modifies the unextracted source, I always delete it an unextract again (just keeping the changelog) :P
[21:10] <RainCT> but on this case dcordero said that the package isn't on DaD anyway
[21:11] <dcordero> RainCT, ok i understood it's exactly how i did it, but i deleted the ubuntu changelog and used debian changelog only
[21:12] <gilir> hi, there is some admin of REVU around here ?
[21:12] <RainCT> dcordero: ok, then you just need to replace the changelog with Ubuntu's + new entries in Debian's, so that the entries that are only in Ubuntu's changelog are conserved
[21:13] <dcordero> and then the debdiff between dsc from debian and the new dsc or between the old dsc from ubuntu and the new dsc generated?
[21:13] <mruiz> bye all
[21:13] <RainCT> dcordero: between the 'old' Debian and your new one
[21:14] <dcordero> ok, i understand now, thanks
[21:14] <RainCT> np :)
[21:15] <RainCT> mok0: ah, and explaining what the process actually is is also better for new people than just using a script doing magic (except if it is CDBS) :D
[21:16] <mok0> RainCT: true. In fact, I don't know myself what most of the diffs are, that grab-merge creates :-)
[21:22] <gilir> I am the only one who have a nice error in REVU ? :) http://revu.tauware.de/details.py?package=awn-extras-applets
[21:22] <blueyed> RainCT: I've addressed your comments in http://revu.ubuntuwire.com/details.py?package=jedit - can you look at it again, please?
[21:25] <RainCT> gilir: me too
[21:28] <gilir> RainCT: thanks :) is it possible to contact the admin of REVU ?
[21:30] <blueyed> siretart: can you look at why the package(s) is/are broken? ^^
[21:30] <RainCT> gilir: I'd try re-uploading it first. I guess the people in group https://launchpad.net/~revu-hackers are probably all admins (I only know sistpoty who isn't online atm)
[21:31] <blueyed> See https://wiki.ubuntu.com/MOTU/Packages/REVU for a full list of them
[21:31] <RainCT> blueyed: sorry, dinner. I don't remember how good I checked it last time but I don't think that I could find much more :)
[21:32] <blueyed> RainCT: you might want to advocate it then.. the only "critical" part is debian/copyright IMHO.
[21:32] <dcordero> only 4,5K my debdiff?
[21:33] <dcordero> i read in the wiki that be a lot of weight file
[21:33] <dcordero> should be
[21:34] <RainCT> Coper: console-freecell looks pretty ok, I'll finish checking it later (haven't looked at the binary yet). (Until now the only "issue" that I could find is that you don't need the comments on the top of debian/rules, but that has no importance so don't re-uploaded unless there's some other problem) :)
[21:35] <RainCT> dcordero: no, 4,5 is probably ok
[21:35] <dcordero> ok, i'll sent it to launchpad, my 4 sent :) ufff
[21:35] <dcordero> 4º
[21:36] <ScottK2> Coper: I'm looking at it now too.
[21:36] <ScottK2> Coper: See my comment on REVU
[21:36] <gilir> RainCT: thanks :)
[21:41] <blueyed> protonchris: are you still looking for something to fix? (just read your mail) I'd say that there should be plenty of things available.
[21:42] <blueyed> See e.g. https://wiki.ubuntu.com/MOTU/TODO or bugs tagged "bitesize"
[21:42] <paas> RainCT: Hi, I've fixed the lintian errors/warnings and uploaded a new package, cheers
[21:42] <cbx33> hey guys
[21:42] <cbx33> when publishing to a PAA
[21:42] <cbx33> PPA
[21:43] <cbx33> how long till my source package gets built?
[21:43] <blueyed> cbx33: depends on the queue.. (which you cannot see unfortunately)
[21:43] <jdong> bug 189361
[21:44] <ubotu> Launchpad bug 189361 in bzr-svn "Please sync bzr-svn 0.4.7-1  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/189361
[21:44] <jdong> cool
[21:44] <cbx33> ahhh ok blueyed thought as much
[21:44] <ScottK2> Coper: Two easy changes and I'll advocate.  Ping me on IRC when you get them fixed.
[21:45] <ScottK2> It's a nice little game.
[21:51] <blueyed> jdong: are you working on the bug? I can confirm that it builds in Hardy.
[21:52] <jdong> blueyed: I asked jussi01 to do that for me
[21:53] <jdong> wait aren't syncs supposed to be subscribing the archive admin?
[21:53] <ScottK2> Yes
[21:53] <blueyed> yes, they need to get ACKed and subscribed then
[21:53] <jdong> ok,
[21:53] <jdong> subscribed or assigned?
[21:53] <ScottK2> subscribed
[21:54] <jdong> excellent
[21:54] <jdong> someone on u-m-s can de-subscribe them
[21:54] <jdong> u-u-s rather
[21:54] <RainCT> blueyed: count a +1 from me then if this makes you happy :)
[21:56] <RainCT> blueyed: well, I think I'm even going to check it again :)
[21:57] <jussi01> jdong: all good with that bug?
[21:57] <RainCT> paas: cool, can you give me a URL?
[21:57] <siretart> blueyed: look at what?
[21:58] <jdong> jussi01: yep, I've acked and subscribed -archive
[21:58] <jdong> jussi01: thanks for your help!
[21:58] <paas> RainCT: http://revu.tauware.de/details.py?package=libtuxcap
[21:58] <jussi01> jdong: np :) I learnt how to use requestsync so that was good:)
[21:58] <jdong> sweet
[21:58] <effie_jayx> persia,  ping
[21:58] <jdong> I've always done them manually :D
[21:59] <jussi01> jdong: that makes it extra easy :D
[21:59] <siretart> blueyed: please consider advising people to use https://answers.launchpad.net/revu/+addquestion
[22:02] <jdong> Anyone know where bluekuja has been recently?
[22:05] <RainCT> paas: please use a patch system for those changes in the source, especially considering that you are using CDBS (so you just need to add 1 line to debian/rules to set it up)
[22:06] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[22:07] <paas> RainCT: ok, will look into it right away
[22:08] <RainCT> paas: $ man cdbs-edit-patch   will help
[22:09] <jdong> RainCT: simple-patchsys is beautiful :)
[22:10] <RainCT> jdong: yehhh :)
[22:10]  * jdong shudders at memories of adding a patch to quilt
[22:10] <RainCT> hehe
[22:11] <RainCT> or even dpatch (well, not using it, but adding it to debian/rules)
[22:11] <ScottK2> I've been meaning to ask ...
[22:11] <blueyed> jdong: I've unsubscribed u-u-s from the bug..
[22:11] <blueyed> siretart: <gilir> I am the only one who have a nice error in REVU ? :) http://revu.tauware.de/details.py?package=awn-extras-applets
[22:13] <blueyed> jdong: quilt is not that easy, yes, but I think dpatch is the best.. e.g. when disabling some patch.
[22:13] <ScottK2> In cdbs-edit-patch and dpatch-edit-patch I can fire them up, throw a patch diff at the source in the chroot, exit and I'm done (modulo editing 00list and dpatch comments).  Is there an equivalent workflow for quilt?
[22:14] <blueyed> ScottK2: I've not found one..
[22:16] <ScottK2> I was afraid of that
[22:16] <siretart> blueyed: looks like someone (read sistpoty or me) has done a cleanup and removed the directory because of disk shortage. I haven't done such a cleanup recently, so best to ask sistpoty here
[22:17] <blueyed> siretart: so re-uploading would fix it?
[22:18] <siretart> blueyed: very likely
[22:18] <blueyed> gilir, please re-upload your package (see above).
[22:19] <gilir> blueyed: ok thanks :)
[22:20] <jcfp> siretart: could you sync the revu keyring please?
[22:24] <effie_jayx> I may have made a mistake and posted the wrong debdiff :S
[22:25] <effie_jayx> what can I do... just upload the right one?
[22:26] <blueyed> Does somebody know why icedtea-java-7 got rejected from Debian NEW? I could not find any mailinglist where those reasons would get posted.
[22:26] <blueyed> effie_jayx: yes, and then delete the wrong one.
[22:27] <blueyed> Wow.. dholbach's sets are really great :)
[22:27] <effie_jayx> blueyed,  thanks...
[22:29] <effie_jayx> blueyed,  where can I erase the old attachment?
[22:29] <blueyed> see the attachments section, click edit, click delete (or thelike)
[22:31] <gilir> blueyed , siretart : same error, with a different upload number :) http://revu.tauware.de/details.py?package=awn-extras-applets
[22:31] <vemon> should the upstream changelog be installed with a package if it contains only technical stuff?
[22:31] <vemon> (which it actually should contain)
[22:32] <geser> blueyed: afaik only the uploaded/maintainer gets the rejected mail. My guess is it that it didn't match the dfsg.
[22:32] <vemon> if i've understood correctly the NEWS file would be the one to install if one would exist..?
[22:33] <blueyed> geser: too bad.. those rejections should be more public.. and it's also bad that it got rejected, of coure.
[22:33] <blueyed> +s
[22:33] <blueyed> vemon: yes, the upstream changelog often contains technical/detailed data, which should be made available.
[22:34] <ScottK2> vemon: I'd install them both
[22:34] <vemon> ok. thanks!
[22:37] <blueyed> Is there some guide to setup revu for local testing/development? :)
[22:38] <blueyed> ..seems to be difficult, but I want to make some (minor) UI improvements, and like to test them..
[22:38] <effie_jayx> how do I remove a patch in simple-patchsys
[22:38] <effie_jayx> ?
[22:39] <jpatrick> effie_jayx: delete the .diff
[22:39] <effie_jayx> jpatrick,  won't it complain at build time?
[22:39] <jpatrick> effie_jayx: shouldn't
[22:39] <effie_jayx> jpatrick,  mkkey
[22:40] <geser> blueyed: IIRC someone setup a second copy of revu somewhere on ubuntuwire.com (or perhaps somewhere else). I'm not sure if it was Fujitsu or someone else. Perhaps #ubuntuwire can help.
[22:40] <geser> effie_jayx: simple-patchsys applies all patches it can find in debian/patches
[22:40] <ScottK2> blueyed: Talk to imbrandon
[22:43] <blueyed> effie_jayx: you can rename it to something != .diff or .patch probably, too.
[22:43] <blueyed> geser, ScottK2: I prefer to develop on localhost.. :)
[22:43] <effie_jayx> If I did a patch and the package got uploaded. now I need to fix soemthing I have to change it in a new patch right?
[22:43] <blueyed> effie_jayx: patch=debdiff?
[22:44] <ScottK2> blueyed: REVU is non-trivial to set up.  It has a lot of hard coded paths and other painful elements.
[22:44] <blueyed> effie_jayx: you can also adjust your patch in a new debdiff
[22:44] <blueyed> ScottK2: sounds awful.. but I expected it anyway.
[22:44] <ScottK2> Source is on Launchpad.
[22:45] <effie_jayx> blueyed,  all I need is to fix some Line I erased ... I have to edit the patch or make a new one... then generate a new debdiff
[22:45] <geser> blueyed: they could help you to set it up on your localhost
[22:46]  * effie_jayx goes for the fix
[22:50] <dcordero> nxvl_work, i has answer you on Bug #177443
[22:50] <ubotu> Launchpad bug 177443 in photoprint "photoprint should recommend or require icc-profiles package" [Undecided,Confirmed] https://launchpad.net/bugs/177443
[22:50] <jdong> blueyed: thanks for unsubscribing; and yeah dpatch is arguably almost as easy to use as cdbs's patchsys, and I like dpatch's comments and disabling abilities
[22:50] <jdong> mainly the comments
[22:52] <vemon> is the copyright of the packaging scripts really necessary in debian/copyright?
[22:52] <vemon> haven't seen that in any package yet
[22:54] <paas> RainCT: I'm now using the patch system and have uploaded a new version. http://revu.tauware.de/details.py?package=libtuxcap
[22:56] <DktrKranz> blueyed, are you still interested in bug 158252?
[22:56] <ubotu> Launchpad bug 158252 in dspam "dspam won't start:  /var/run/dspam missing in tmpfs" [Medium,Confirmed] https://launchpad.net/bugs/158252
[22:58] <RainCT> paas: it seems like you are still modifying 2 files (CMakeLists.txt) without patch system
[22:58] <RainCT> well, gonna go
[22:58] <RainCT> good night :)
[22:58] <paas> good night
[23:16] <nxvl_work> dcordero: replied :D
[23:19] <CyberMatt> http://revu.tauware.de/details.py?package=jailkit the latest motu comment is inalid i repacked the tarball because of a flawed upstream debian/
[23:19] <CyberMatt> directory
[23:26] <somerville32> CyberMatt: I don't think it is invalid.
[23:27] <CyberMatt> why not repack the upstream tarball mark it with repackedx
[23:28] <RAOF> CyberMatt: Because the source package, as you have provided it, is invalid.
[23:29] <CyberMatt> hmm vailidate for me
[23:30] <RAOF> CyberMatt: Easy steps to reproduce: download the files you've posted to revu into a new directory.  Try to run dpkg-source -x *.dsc, and it fails.
[23:30] <CyberMatt> hmmm why is it doing that
[23:31] <dcordero> nxvl_work,  replied :D
[23:31] <CyberMatt> i can reup with a note in the changelog
[23:31] <RAOF> Because your tarball has an invalid name: you actually want to change the package _version_ to "2.5+repack-0ubuntu1", so your .orig.tar.gz can be called _2.5+repack.orig.tar.gz
[23:32] <CyberMatt> oh shoot
[23:32]  * CyberMatt should have seen
[23:33] <RAOF> When you repack you have to change the version number, too :)
[23:33] <CyberMatt> D'oh
[23:34] <RAOF> CyberMatt: Additionally, since you've repacked the original tarball, I'd add a get-orig-source target to debian/rules to show what you've done in the repack.
[23:35] <CyberMatt> mmm maybe all idid was rn -rf debian/
[23:36] <CyberMatt> and re-debianize
[23:36] <RAOF> CyberMatt: Even so.
[23:36] <RAOF> You should probably add a watch file, too.
[23:37] <somerville32> CyberMatt: keyword is "maybe"
[23:37] <nxvl_work> dcordero: in a quick look it seems ok now, let's wait for a sponsor to check it :D
[23:39] <CyberMatt> g-o-s is a big pain and its also abuse of make
[23:39] <dcordero> nxvl_work, wooo :D
[23:40] <RAOF> CyberMatt: I dispute both those points.  If all you've done is rm -rf debian, it's trivial (even more so if you add a watch file).  In what way is it an abuse of make?
[23:40] <dcordero> nxvl_work, was hard for me haha
[23:40] <nxvl_work> dcordero: thats on the first times, then it would be easy
[23:40] <nxvl_work> dcordero: i promise
[23:40] <dcordero> i hope
[23:40] <dcordero> :)
[23:41] <nxvl_work> dcordero: why don't you ask for a mentor?
[23:41] <nxvl_work> dcordero: it makes things easiest
[23:41] <nxvl_work> dcordero: https://wiki.ubuntu.com/MOTU/Mentoring/Contributor
[23:42] <CyberMatt> what we should do with g-o-s is do another maintainer script that can be called by the user much more effective
[23:42] <RAOF> CyberMatt: What's so hard about "debian/rules get-orig-source".  That's user-callable.
[23:43] <dcordero> nxvl_work, yep i think that i should do it
[23:44] <CyberMatt> not hard i just don't like anything in a makefile that doesn't need to be in a makefile
[23:45] <CyberMatt> just IMHO ill do it
[23:46] <ion_> Why is that?
[23:47] <CyberMatt> make launching wget seems creepy but i'm paranoid  :)
[23:47] <ion_> ...
[23:48] <ion_> Does sh launching wget seem creepy? How about the operating system launching wget? Or the computer launching wget?
[23:59] <CyberMatt> don't ask me to explain logical paranoia is somewhat of an oxymoron