[00:00] <imbrandon> LaserJock: i dont really think its nessesary as those links arent even correct
[00:00] <imbrandon> as the disclaimer said
[00:00] <imbrandon> but i guess it wonthurt
[00:01] <LaserJock> imbrandon: hmm, those are interesting links though
[00:02] <LaserJock> not what I thought they were on first reading
[00:03] <huats> hey guys
[00:03] <LaserJock> hi huats
[00:04] <huats> I am making a so called fake sync, I am reporting every debian changes to a ubuntu orig.tar.gz (which differs from the one in debian...). Do I need to put the debian changelog and the debian copyright. Or can I keep the ubuntu ones ?
[00:05] <LaserJock> huats: how do the tarballs differ?
[00:05] <huats> Oh by the way, another question (not related to the first one), I am a new ubuntu member ... how can I activate the ubuntu.com address ?
[00:06] <huats> LaserJock: they are not the same :)
[00:06] <LaserJock> huats: well, I gathered that ;-)
[00:06] <LaserJock> huats: what's different about them?
[00:06] <LaserJock> huats: try sending email to your ubuntu.com address and see if it works
[00:06] <huats> LaserJock: let me check again, I have started that a long time ago so I have to remember :)
[00:07] <huats> LaserJock: it was not functionning....
[00:07] <huats> yesterday
[00:07] <huats> I'll try again..
[00:08] <LaserJock> huats: you might ask somebody in #canonical-sysadmin on Monday, but if it doesn't work I think you file an RT ticked (rt at canonical.com I think)
[00:08] <huats> ok
[00:08] <huats> I'll have a look on monday so
[00:12] <huats> LaserJock: Ok I hav seen the differecnce...
[00:13] <huats> what can I telll you about ?
[00:13] <LaserJock> well, why is there a diff, what kind of stuff is changed?
[00:14] <LaserJock> in general I would think if you were to do a fakesync I would think  you would stay as close to Debian as possible
[00:16] <huats> ok
[00:16] <huats> why there is a diff, I don't know...
[00:27] <LaserJock> huats: I guess you kinda need to know what the  changes are and enough about why they are there to see if any changes need to be kept
[00:27] <huats> ok
[00:30] <huats> LaserJock: I'll investigate on that thus :)
[00:31] <huats> LaserJock: thanks :)
[00:32] <huats> good night all
[00:32] <LaserJock> cya
[00:35] <cyberix> I'd need to make a few minor changes to my package, which now is in the repositories.
[00:35] <cyberix> So what is the process?
[00:36] <minghua> cyberix: Main package or universe package?
[00:38] <cyberix> Well, multiverse
[00:38] <cyberix> I suppose the process is the same as for universe
[00:39] <LaserJock> cyberix: file a bug, attach a debdiff, subscribe u-u-s
[00:40] <minghua> cyberix: Yeah, basically what LaserJock said.  Also see https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue.
[01:26] <pochu> Good night folks!
[01:48] <owh> Just saw this email on the udd list https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-December/002696.html - discussing the out of sync nature for three packages that is, the source and the binary are not the same.
[01:48] <owh> The packages discussed are logjam, qemu and aumix.
[01:49] <owh> I started writing a response to the list but thought it might be smarter to discuss this here first.
[01:49] <Fujitsu> owh: I responded to the bug he filed already. What is there to discus?
[01:49] <Fujitsu> s/discus/discuss/
[01:50] <owh> I haven't seen your response in the bug yet, but I'm wondering if there is a procedure to catch this "out of sync" nature because it could potentially be used as a way of introducing more sinister binaries.
[01:51] <Fujitsu> How can sinister binaries be introduced? The worst that can happen is that some are out of date.
[01:51] <Fujitsu> (and we have a page to catch those, now)
[01:51] <persia> owh: It generally only happens when an older version FTBFS.  There's no binary upload, so it's not likely to be sinister.
[01:52] <owh> Well, the email I linked to specifically states: "the maintainer grabbed from a broken CVS"
[01:52] <persia> owh: Sure, but "broken" doesn't mean "sinister"
[01:52] <Fujitsu> I wouldn't call that sinister.
[01:52] <owh> My question is, "could it be?"
[01:53] <owh> I'm not saying it is.
[01:53] <somerville32> ...
[01:53] <owh> I'm trying to ask if the procedures used have any holes in it that this is showing?
[01:53] <owh> That is, "Is this the tip of an ugly iceberg?"
[01:53] <Fujitsu> It is the tip of the FTBFS iceberg, but it can't be sinister.
[01:54] <persia> somerville32: Thanks for reviewing people's packages on REVU.  If you don't mind, could you share your comments in this channel when you do so?
[01:54] <Fujitsu> Well, if we have something sinister in the archive, we've got larger problems than out-of-date binaries.
[01:54] <somerville32> persia, Alrighty.
[01:54] <owh> Sure.
[01:54] <persia> somerville32: Thanks :)
[01:55] <owh> So Fujitsu, what you're saying is that this is *only* the visible end where source did not build, no other problem?
[01:56] <Fujitsu> owh: What do you mean? This situation only occurs when the source doesn't build... there's nothing to *be* visible in any other case.
[01:56] <somerville32> so If the new source package doesn't build, then the old binary still exists?
[01:57] <Fujitsu> Correct.
[01:57] <Fujitsu> It won't be dominated, and will remain published until it is.
[01:57] <owh> So, the qemu example was a case of poor testing, but successful building?
[01:58] <Fujitsu> Where's this?
[01:58] <owh> In that email?
[01:58] <owh> s/?/./
[01:58] <Fujitsu> Oh, I didn't see that reply.
[01:59] <owh> Perhaps it would be a good idea for a MOTU to put that into writing on the list to highlight what is going on so no-one jumps to any conclusions and it all explodes in a flurry of emails?
[02:00] <Fujitsu> ... we only have a CVS qemu in Hardy. A broken package in Hardy. Wow.
[02:00] <owh> I mean that the tone of the two emails could be construed as an issue as I started to do before I came here to talk about it.
[02:00]  * Fujitsu generally follows a policy of letting -devel-discuss users live in their own little world.
[02:01] <Fujitsu> What issue did you see, exactly?
[02:01] <owh> Well as I read it, likely from inexperience, I saw three packages where src and binary were out of sync with little reference to where the binary came from.
[02:01] <Fujitsu> Erm, even better, qemu on Hardy does work.l
[02:02] <Fujitsu> What gave you the idea that the qemu binaries were out of sync?
[02:02] <owh> There seemed to be a tone that there was a problem, but from the discussion here I'm just hearing that its FTBFS.
[02:03] <Fujitsu> There are no qemu FTBFSes (except for archs where it has never built) in any release except edgy, and that's just powerpc.
[02:03] <owh> The same email. Mind you it had very little on detail and reference, but I thought it would be prudent to ask.
[02:04] <owh> It's pretty hard to tell if the person sending the email in the first place is talking out of the wrong orifice at the best of times.
[02:06] <owh> Thanks for your time all. Happy to hear there is no issue.
[02:06] <persia> owh: Well, there is an issue: packages shouldn't fail to build from source, and should be fixed, but it's not a dangerous issue.
[02:07] <Fujitsu> And, as I said in the bug, we can now see what FTBFSes we have on our plate fairly easily.
[02:08]  * persia cheers Dktrkranz and geser
[02:08] <Fujitsu> Yep.
[02:08] <owh> Is there a link that shows those packages so a wider group could assist? Or is that counter productive?
[02:09] <Fujitsu> http://qa.ubuntuwire.com/ftbfs.
[02:09] <persia> owh: Depends.  If the wider group is up to submitting patches to get them to work, it would be helpful.  Filing bugs isn't so helpful.
[02:09] <owh> No kidding :)
[02:10] <Fujitsu> We could really do with a mass-giveback soon, due to bug #160439
[02:10] <ubotu> Launchpad bug 160439 in soyuz "Some builds fail when they should depwait" [Medium,Triaged] https://launchpad.net/bugs/160439
[02:10] <owh> So is there any point in me mailing that link to udd, or should I just leave well enough alone?
[02:12] <owh> Text along the lines of "These are examples of FTBFS, here are some others. If you have patches to fix it, please do so."
[02:12] <persia> owh: Careful: that might be considered inflammatory.  Some people seem to believe there is a distinction between users and developers.
[02:12] <owh> ROTFL
[02:13] <persia> Fujitsu: Do we have a means to distinguish which packages are affected?
[02:13] <owh> Sorry, that sounded flippant, it wasn't intended as such.
[02:13] <Fujitsu> The examples given in the  reply to the email are not FTBFSes.
[02:13] <Fujitsu> persia: Not at the moment, but it would be quite easy to grab build logs and grep for them.
[02:14] <persia> Fujitsu: Ah.  True.  From what I have seen, I had the impression that a mass-give-back would be considered, if someone were to dig up which were the affected packages and submit the list.
[02:14] <Fujitsu> It would be easier to just throw everything at the buildds again, thought.
[02:14] <Fujitsu> s/thought/though/
[02:15] <Fujitsu> hppa will all be given back within a couple of weeks anyway, and the others don't have a whole lot of FTBFSes.
[02:15] <persia> Fujitsu: Yes, but proposing that makes the buildd-admins whine about resources, and point at the fact that we've never caught up (on all archs)
[02:16] <Fujitsu> Grr, Soyuz is being silly again.
[02:17] <Fujitsu> There has been one item stuck in the i386 and powerpc queues for at least several hours now, and I can't see it anywhere. They seem to be up to date, but /+builds says otherwise. Yay.
[02:18] <Fujitsu> persia: hppa should catch up within a couple of weeks, and the other archs are generally fairly up to date.
[02:18] <persia> Fujitsu: Yes, but you are talking about 1000 packages.  I had complaints about that volume when asking about the < Dapper rebuilds.
[02:19]  * persia isn't convinced by the buildd-load argument, but is just sharing
[02:20] <Fujitsu> Less than 200 packages on each arch is nothing.
[02:21] <persia> Fujitsu: True.  I guess I'm misreading the FTBFS page then.
[02:24] <Fujitsu> There are 1168 packages with issues, but less than around 200 failures on !(lpia|hppa). lpia is always ahead of everything else anyway, and hppa is special... I don't see why anybody would have a problem with it.
[02:25] <persia> Fujitsu: For the < 200 failures, I don't imagine it would be an issue.  Someone might want to get fed 20/day or something, but that's the only issue I can see being raised.
[02:45] <Fujitsu> That looks bad.
[02:45] <Fujitsu> Hey bddebian.
[02:46] <bddebian> Heya gang
[02:46] <bddebian> Hi Fujitsu
[02:54] <ScottK> heya bddebian and Fujitsu.
[02:55] <bddebian> Hi ScottK
[02:56] <Fujitsu> Hi ScottK.
[03:02] <bddebian> persia: You around by any chance?
[03:02] <persia> bddebian: Yes
[03:03] <bddebian> persia: Got a minute for a /query?
[03:10] <mdomsch> ScottK: thanks for the firmware-addon-dell comments
[03:10] <mdomsch> XS-Python-Version and XB-Python-Version are deprecated for use with python-support, per the warnings at build time and http://wiki.debian.org/DebianPython/NewPolicy
[03:11] <ScottK> mdomsch: You need either pyversions or XS-Python-Version.  Unless I missed it you have neither.
[03:11] <mdomsch> yeah, I added pyversions to satisfy
[03:13] <mdomsch> and persia spent quite some time explaining the versioning to me, so I can get that right next time
[03:13] <ScottK> Good.
[03:14] <ScottK> Did you also take care of python versus python-all-dev?
[03:14] <ScottK> You understand the difference?
[03:14] <persia> mdomsch: Something I failed to mention before, which might be nice next time, is the option of distributing -0dellN from l.d.c, as -0ubuntu1 would always be higher, making the issue transparent.
[03:15] <mdomsch> indeed
[03:15] <ScottK> persia: I saw you recommended a linda over-ride for the package.  Why is that?
[03:15]  * persia looks at REVU again to build context
[03:15] <mdomsch> just for the piece that's a yum plugin
[03:15] <mdomsch> it goes into an odd directory, /usr/lib/yum-plugins.d or somesuch
[03:16] <mdomsch> arguably, as yum isn't the default on debian/ubuntu, I should skip that
[03:16] <ScottK> Yes, but why does it go there?
[03:16] <ScottK> That too, why install it at all?
[03:16] <mdomsch> but, yum is available in universe
[03:16]  * ScottK learns something new every day.
[03:16] <ScottK> That is just wrong.
[03:16] <persia> ScottK: because yum doesn't look in the /usr/share hierarchy (but not installing it is probably a better solution than a linda override)
[03:17] <persia> ScottK: code sharing.  I don't think it's bad to have tools, but you're right that we shouldn't encourage use.
[03:17] <ScottK> Well OTOH if yum is in the repos it'd be wrong to work at not supporting it.
[03:18] <ScottK> Sounds like a bug in yum then (at least the yum package on Debian).
[03:18] <persia> ScottK: Yes, certainly.  yum should allow packages supporting yum to be policy compliant :)
[03:23] <mdomsch> brb
[03:27] <ScottK> Bug filed.
[03:27] <ScottK> Marked another one invalid while I was there.
[03:30] <somerville32> ScottK, I thought pysupport didn't require pyversion or the Python-Version fields
[03:32] <ScottK> It does AFAIK.
[03:36] <somerville32> No, if you don't have pyversions than it uses current
[03:36] <ScottK> I'm not saying it won't run, just that it's supposed to be there.
[03:37] <somerville32> Not according to the docs for python-support
[03:37] <somerville32> You should only have a pyversions file if the module doesn't work with all python versions
[03:38] <ScottK> Right.  For what definition of all?
[03:39] <somerville32> ScottK, ie. If it requires a specific version
[03:40] <persia> somerville32: Right.  So anything without it should work with python < 1.0, right?
[03:40] <ScottK> Yes, exactly.
[03:41] <somerville32> You mean python > 1.0 ?
[03:42]  * mdomsch hates "all" in discussion of versions
[03:42] <mdomsch> you're going to get bit at some point
[03:42] <persia> somerville32: No, I mean python < 1.0
[03:42]  * persia agrees with mdomsch
[03:43] <somerville32> I'm using the same semantics the document does
[03:43] <persia> somerville32: What does the document mean by "all"?
[03:44] <somerville32> any?
[03:44] <mdomsch> >= 0.0
[03:44] <Fujitsu> `all' simply means anything in the distro, though it gets a little nasty as we add new versions.
[03:45] <persia> OK.  I see.  For python-central, I read it as needing XS-Python-Version, and for python-support, I read it as needing XB-Python-Version.
[03:45] <somerville32> negative.
[03:45] <somerville32> You don't need X[BS]-Python-Version fields.
[03:45] <somerville32> You don't need debian/pycompat
[03:46] <somerville32> You don't need to call dh_python after dh_pysupport
[03:46] <persia> Right.  Everything needs XB-Python-Version, and python-central also needs XS-Python-Version.
[03:46]  * persia agrees with not calling dh_python
[03:47] <somerville32> X[BS]-Python-Version fields should be removed when using python-support
[03:48] <mdomsch> the wiki is unclear on this point
[03:49] <mdomsch> but the code throws warnings for XB-Python-Version present when using python-support
[03:49] <somerville32> The docs for python-support are quite clear
[03:50] <mdomsch> indeed
[03:50]  * persia suspects the "New Python Policy" of being insufficiently new, and goes back to non-python things.
[03:52] <ScottK> The "New Python Policy" is pretty much unmaintained right now.  Fixing that has recently been discussed in Debian.
[04:28] <mdomsch> ScottK, new upload of firmware-addon-dell to revu with your suggested changes, thanks
[04:28] <ScottK> mdomsch: You're welcome.
[04:28] <mdomsch> I made equivalent changes to firmware-tools, but...
[04:28] <mdomsch> upstream is converting from distutils to autoconf
[04:28] <mdomsch> and there's some serious breakage in the upstream package right now
[04:28] <ScottK> Yummy.
[04:29] <ScottK> Right, so let's stick with this one then.
[04:29] <mdomsch> so until that's resolved, I can't do another upload
[04:29] <ScottK> You can continue to upload revisions to the distutils version to REVU
[04:29] <Fujitsu> Moving to autoconf? That sounds a bit odd.
[04:29] <mdomsch> Fujitsu, I wasn't too pleased to see that
[04:30] <mdomsch> in fact, it's cost me ~4 hours work trying to fix the breakage so far
[04:42] <ScottK> I don't suppose you can just write your own distutils setup.py and ignore the upstream autoconf stuff.
[04:53] <mdomsch> ScottK, no, I'm just going to make upstream fix their brokenness with autotools independent of debian packaging
[04:53] <mdomsch> and once that's good again, finish whatever is left of the deb packaging
[04:53] <mdomsch> for now, as you suggested, I'm just redoing the upload
[04:53] <mdomsch> w/o all of upstream's latest changes
[05:00] <Fujitsu> What is our policy on creating a Homepage field when merging? IMO it's unnecessary delta...
[05:00] <imbrandon> Fujitsu: imho it should be sent upstream, not here
[05:01] <imbrandon> maybe a wishlist bug upstream
[05:01] <Fujitsu> (I'm actually doing some sponsoring for the first time in ages)
[05:01] <Fujitsu> imbrandon: Debian, you mean?
[05:01] <imbrandon> yea
[05:01] <persia> Fujitsu: I don't see any reason to block sponsoring for it: the tools will be broken one way or the other.
[05:02] <Fujitsu> persia: I guess. I'm sending it back for other changes anyway.
[05:03] <imbrandon> yea , in my school of sponsoring too ( i'm pretty unique on somethings ) if that is the only change i would just change it myself ( e.g. revert it, then let the contributor know you reverted it ) and upload anyhow
[05:03] <persia> Fujitsu: If you're kicking it back anyway, maybe it's worth reinforcing the minimal-deviation idea.
[05:03] <persia> The only exception being .desktop files, due to the magic of app-install-data
[05:03] <Fujitsu> persia: That's what I've done.
[05:03] <Fujitsu> Yes.
[05:04] <persia> imbrandon: I used to be a member of that school, but it means they don't get upload credit.  I'm currently on the fence, and subscribing to push-back in most cases.
[05:05] <imbrandon> persia: sure they do, you can add something to the changelog etc and still leave them as the person in the changelog
[05:05] <persia> (although, thinking about it, maybe they shouldn't get upload credit, and will need to hit more bugs to build credits if everyone does the fix & upload thing)
[05:05] <imbrandon> that added the entrie
[05:05] <imbrandon> you have to sign the file anyhow
[05:05] <persia> imbrandon: That would be wrong.
[05:05] <imbrandon> nah its done quite a bit in both debian and ubuntu, i dont see how its wrong
[05:05] <persia> imbrandon: The person who closes the changelog should be the last person to touch the package.
[05:06] <Fujitsu> persia: That deliberate loss of upload credit is an interesting idea indeed.
[05:06] <persia> imbrandon: It's wrong because both the person reporting the changes being completed and the date the changes are completed are incorrectly reported.
[05:06] <imbrandon> how its always done in the rcs packages i work on its the first person to add an entry
[05:07]  * mdomsch uploads new firmware-tools
[05:07] <persia> Fujitsu: It gets more patches through faster too.  I think most people would be happy getting their patches in, even without being the Changed-By name, and if they want to get accepted, they need to get it right.  Maybe worth discussing Friday?
[05:07] <Fujitsu> I suspect so.
[05:07] <ember> persia: devede fixed
[05:08] <persia> imbrandon: It should be the last person to add an entry.  dch does the right thing.
[05:08] <persia> ember: Great.  Of course, that means you're at the bottom of the least-recently-touched queue, but it shouldn't be more than a couple days.
[05:08] <imbrandon> dch dosent account for multi-people editing
[05:08] <imbrandon> on a single upload
[05:08] <persia> imbrandon: Yes it does.  Try it.
[05:08] <ember> he hates me
[05:08] <ember> :o
[05:09] <persia> ember: No, I just sponsor in least-recently-touched order to avoid anyone having to wait forever for a response.
[05:09] <imbrandon> okies, i conceed probably wrong, but it is a common practice
[05:10] <persia> imbrandon: Maybe, but people who do that should be using dch, and follow the new accepted correct practice.
[05:11] <imbrandon> anyhow new subject, anyone care to give me a 5 minute primer to git ( i'm familiar with svn cvs bzr(kinda) ) so it shouldent take long to get me a basics enough to do a branch and a diff etc
[05:11] <imbrandon> persia: likely
[05:12] <imbrandon> i just am trying to do a bit-o-kernel patching from fedora-->suse-->fedora-->xebian-->ubuntu and git seems to be the common link
[05:12] <imbrandon> ( yes xebian not debian )
[05:15] <imbrandon> okies , guess i'm gonna do some trial and error
[05:15] <mdomsch> imbrandon, are you going to be cherry-picking?
[05:16] <mdomsch> e.g. grabbing specific commits from one tree to pull into another?
[05:16] <imbrandon> mdomsch: yea, some xbox specific patches
[05:16] <imbrandon> yea
[05:17] <mdomsch> so, you need both trees/branches in the same local git tree
[05:17] <mdomsch> then you choose the specific commits from say fedora-branch you want
[05:17] <mdomsch> and you git cherry-pick <commit-id>  (from your working-branch)
[05:17] <imbrandon> well the main thing is .... well ok
[05:18] <imbrandon> here is the deal, say i can get a "working" local directory
[05:18] <imbrandon> thats a git branch of our current ubuntu kernel
[05:18] <mdomsch> yep
[05:18] <mdomsch> git branch working
[05:18] <mdomsch> git checkout -f working
[05:18] <imbrandon> then i make a working-diff dir thats basicly a cp -Rav of the working
[05:18] <imbrandon> with patches i grab from multi places
[05:19] <imbrandon> cvs/svn/raw diff
[05:19] <imbrandon> etc
[05:19] <mdomsch> sure
[05:19] <imbrandon> untill i get it "they way i want"
[05:19]  * persia mistakenly accepted a merge :(
[05:19] <imbrandon> can i then make a "git bundle" or somehing i can hand to someone with git commit access
[05:19] <imbrandon> between the two
[05:20] <mdomsch> well, you're outside of git as soon as you do the cp -rav
[05:20] <mdomsch> instead do
[05:20] <Fujitsu> persia: I'm sponsoring one too, but that's because it happens to contain a bugfix for a bug that I hit.
[05:20] <mdomsch> git clone upstreamurl
[05:20] <mdomsch> git branch working
[05:20] <mdomsch> git checkout -f working
[05:20] <mdomsch> apply patch #1
[05:20] <mdomsch> git commit -a -m 'message for patch #1'
[05:20] <mdomsch> repeat
[05:21] <imbrandon> ok git commits localy like bzr ?
[05:21] <mdomsch> yes
[05:21] <persia> Fujitsu: Sponsoring merges isn't bad: personally, I'd like to see merges for any significant Debian bugfixes, I just have to be careful, as I often make mistakes with merges (so usually sponsor other things).
[05:21] <imbrandon> nice, ok
[05:21] <mdomsch> then, when you haev it "the way you want"
[05:21] <mdomsch> you publish the tree somewhere somehow
[05:21] <imbrandon> yup, thats exactly what i was looking for
[05:21] <mdomsch> e.g. rsync it to a web server
[05:21] <imbrandon> cool, yea
[05:22] <Fujitsu> persia: Oh, right, forgot about your general aversion to them.
[05:22] <imbrandon> thanks mdomsch
[05:22] <mdomsch> and tell your friend to pull from the working branch of the tree you just rsynced
[05:23] <persia> nxvl: You don't need "Closes" when closing a LP bug.  Rather, it's preferred not to use it (although it works)
[05:23] <mdomsch> imbrandon, git-request-pull formats the email you can send to request the pull
[05:24] <imbrandon> nice
[05:24] <imbrandon> i've just been getting used to the nice things about bzr ( really distributed rcs ) but git ( without having actualy used it yet ) seems nice(er)
[05:25] <imbrandon> i'm sure they both have their place though
[05:25]  * mdomsch hasn't used bzr yet
[05:25] <mdomsch> but I think they're similar conceptually
[05:25] <Fujitsu> bzr rocks, and just reached 1.0.
[05:25] <Fujitsu> I've not used git very much.
[05:25] <imbrandon> man once i found bzr-svn and bzr-cvs i never looked back
[05:25] <mdomsch> git is fully distributed
[05:25] <imbrandon> mdomsch: so is bzr
[05:25] <mdomsch> yep
[05:25] <persia> imbrandon: They optimize for different cases, but both are nice in preference to what went before.
[05:26] <mdomsch> at work, some teams are forced to use clearcase
[05:26] <imbrandon> and i love the plugins , i can work with a svn tree like its a bzr branch and still push it back too
[05:26]  * minghua played with both bzr and git, but hasn't known enough to do a comparison.
[05:26] <imbrandon> never touching svn
[05:26] <mdomsch> so, when the servers are down, or out of sync in the various geographies
[05:26] <persia> clearcase!  Didn't that die a proper death last decade?
[05:26] <mdomsch> they can't commit or sync
[05:26] <Fujitsu> Hahahahahaha.
[05:26] <Fujitsu> Clearcase, yay,.
[05:27] <mdomsch> there's a tool I'm reading about, git-buildpackage
[05:27] <imbrandon> hrm there might even be a bzr-git, i might have to look heh
[05:27] <mdomsch> for maintaining debs in git
[05:27] <Fujitsu> imbrandon: I don't believe there is.
[05:27] <persia> mdomsch: If you decide to use git-buildpackage, you may also be interested in pristine-tar
[05:27] <imbrandon> mdomsch: yea bzr-buildpacakges and svn-... and cvs-... too ( not positive obut cvs-... )
[05:29] <minghua> imbrandon: Of course there is a cvs- one, it's the oldest (and probably the root of all these).
[05:29] <imbrandon> hrm anyone know if someone produces a usb disk that uses real ramchips vs flashchips ?
[05:29] <Fujitsu> imbrandon: Wouldn't that be a bit... volatile?
[05:30] <imbrandon> Fujitsu: yea, it would be intended to be
[05:30] <imbrandon> as like say a slow swapdevice when nothing else is avail
[05:30] <imbrandon> vs swap over ethernet
[05:31] <persia> imbrandon: I've seen PCI, IDE, and PCIe RAM devices, but never USB.
[05:31] <imbrandon> persia: ide?
[05:31] <imbrandon> that might work too
[05:31] <imbrandon> hrm
[05:32] <persia> imbrandon: Yep.  Generally with a battery to make them less volatile.  You could presumably wrap it with a IDE->USB converter.
[05:32] <imbrandon> yea
[05:32] <imbrandon> yea i was thinking a batery would be needed in the usb one
[05:33] <imbrandon> like a thumbdrive + ram + bat
[05:33] <imbrandon> plus some EE person to make it all work :)
[05:33] <persia> imbrandon: Of course, I don't have any brands or anything.  These are the sorts of kit in the boxes of loose stuff on the bottom shelf at the components shops.
[05:33] <imbrandon> right
[05:33] <imbrandon> gives me something to look at though
[05:34] <imbrandon> ( for context if intrested see "Other Hardware Thoughts" on http://www.not404.com/node/52 , almost at the bottom )
[05:34] <persia> imbrandon: Expect a budget of ~ $50 USD (I think) if you can find somewhere that sells cheap unbranded chinese kit.
[05:35] <imbrandon> yea i'd imagine, but it would make the diffrence between 64mb ram and ++ in a xbox without soder, making the 733Mhz + nvidia box  maybe worth using as a workstation, abet slow yes
[05:36] <imbrandon> and even with soder iirc you can only hit 256
[05:37] <persia> imbrandon: You've found a market niche.  Find a manufacturer, get an importer to smooth customs for 10-15%, and you've a hobby business.
[05:37] <imbrandon> :)
[05:38] <imbrandon> i already make "xbox controler port to usb hub" cables at home for $$ , cheap but still heh
[05:38] <imbrandon> its funny the controler port on a xbox is just a funny shaped usb port
[05:39] <imbrandon> thus enabling people to mod their xboxes without opening the case or voiding anything ( not that they even still amek them )
[05:39] <imbrandon> or hooking up keyboards and mice
[05:40] <imbrandon> or using usb thumdrives as memorycards
[05:40] <imbrandon> or tons of other things
[05:43] <imbrandon> wow, i hate patents, i searched for it and the first thing that came up was a patent
[05:43] <imbrandon> http://www.patentstorm.us/patents/6219736.html
[05:43] <imbrandon> so someone has thought about it
[05:46] <minghua> imbrandon: Move out of US. :-)
[05:46] <imbrandon> :P
[05:46] <persia> imbrandon: That only means you can't design or manufacture it without permission from the patent holder.
[05:47] <Fujitsu> I think that wins the prize for the most uses of microcontroller in a paragraph.
[05:47] <imbrandon> lol
[05:47] <minghua> persia: Really?  Even if I make it for myself, instead of selling it for profit?
[05:48] <persia> minghua: Well, right.  One cannot design or manufacture such a device for sale or free distribution.  One can use privately, or resell if designed or manufactured by someone else.  For more details, seek counsel.
[05:49] <imbrandon> hrm is this it? it seems like the right keywords but the actual design dosent look like what i ment
[05:49] <imbrandon> http://www.controlchips.com/usbram.htm
[05:50] <persia> imbrandon: That appears to be an implementation of the patent you listed earlier, although were one to construct something today, it might make sense to use faster USB.
[05:51] <imbrandon> right
[05:51] <imbrandon> that page looks last updated 2004
[05:51] <imbrandon> so its not real uptodate
[06:35] <imbrandon> StevenK: round?
[06:40] <imbrandon> StevenK: un-ping
[06:41]  * persia notes that the U-U-S queue has reached single digits again, and encourages someone else to review the rest of them.
[06:41] <persia> (special points available for anyone willing to do bug #133888)
[06:41] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the <IP_ADDRESS> release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[07:16] <StevenK> imbrandon: Unpong
[07:17] <StevenK> imbrandon: Besides, I'm a square
[07:23] <persia> ember: Are you familiar with watch files?
[08:51] <jonnymind> hello.
[09:06] <warp10> Hi all
[09:46] <jekos1> has anyone compiled Cedega successfully?
[09:49] <harrisony> jekos1: it failed for me, i find wine works better anyway
[09:59] <jekos1> harrisony: it tried to compile but failed too. I've downloaded it from CVS (53 M), it will be pity to make up with compilation
[10:00] <harrisony> then again, i tried it early this year
[10:00] <harrisony> but i find wine works all the time
[10:01] <persia> It's REVU day again!
[10:01] <persia> 30 Candidates today in need of review.
[10:02] <harrisony> ARGH!, i was going to try get a package done for revu day, but stupid pbuilder isnt liking me
[10:02] <persia> harrisony: What's wrong with pbuilder?
[10:04] <harrisony> persia: keeps throwing errors when i use pbuilder-dist (from the ubuntu-dev-tools package) some errors about ' in the sources list or something
[10:04] <harrisony> (on the initial create)
[10:05] <persia> harrisony: Ah.  Have you hunted down the sources.list it tries to use?  Perhaps there's a typo.
[10:06] <DarkMageZ> harrisony, have you edited any pbuilder configuration files? what command are you using to create the pbuilder?
[10:06] <harrisony> DarkMageZ: pbuilder-dist hardy create (pbuilder-dist is found in ubuntu-dev-tools)
[10:07] <DarkMageZ> harrisony, what about "sudo pbuilder create --distribution <distro>"
[10:08] <DarkMageZ> harrisony, then edit /etc/pbuilderrc and enable universe and multiverse then "sudo pbuilder update --overide-config"
[10:08] <harrisony> DarkMageZ: im doing that now, pbuilder-dist is nicer when it comes to mutiple versions
[10:08]  * pochu has a lot of pbuilder-$distro in his $PATH :-)
[10:09] <DarkMageZ> "sudo pbuilder build --basetgz=/var/cache/pbuilder/warty/base.tgz lol.dsc" :P
[10:10]  * persia thinks warty isn't a very useful base these days
[10:10] <pochu> heh
[10:10] <DarkMageZ> i was trying to avoid dapper vs gutsy vs hardy debate :P
[10:10] <harrisony> wouldnt mind finding a warty cd to see what it was like in ye old days
[10:11] <DarkMageZ> harrisony, ye old days were only 2004... you were 12. this makes you VERY old :P
[10:11] <harrisony> DarkMageZ: hahaha very very, what was i doing when i was 12, hmm
[10:12]  * persia asks the 7 packagers with "Updated Packages" on REVU to submit interdiffs to bugs and subscribe the sponsors queues if they wish to request upload.
[10:19] <LucidFox> Yes, persia, just saw that, and uploaded interdiff
[10:19] <LucidFox> so the updated packages section of REVU is going to be phased out?
[10:20] <persia> LucidFox: Not any time soon, but it only gets looked at on Mondays, and not so often at that.  There's a better chance of getting review & sponsorship from the sponsors queue.
[10:20]  * persia often scans the "Updated Packages" section, and archives candidate revisions that are older than the archive versions
[10:23] <pochu> persia: would it be useful if REVU distingished from main and universe packages?
[10:23] <pochu> so MOTUs concentrate their work in universe packages
[10:23] <persia> pochu: Not really.  All NEW packages go to universe, and updated packages don't really belong on REVU anyway.
[10:23] <pochu> hmm, right
[10:24] <pochu> I was thinking on updated packages, as Ive just seen gnome-terminal there, but you're right
[10:24] <persia> pochu: If someone has a NEW package for main, best plan is to get it into universe, and file a MIR
[10:25] <persia> On the other hand, sometimes a sponsor requests a signed upload somewhere, and REVU is a handy resource.  Once LP gets proper dget support for PPAs, etc. (very soon now, might even be in edge), this becomes less useful.
[10:25] <pochu> I think it's already there in malone. Not in soyuz yet, but soon.
[10:27] <Supremus> hello
[10:27] <persia> pochu: Right :)
[10:27] <Supremus> persia, hello :D
[10:27] <persia> Supremus: Hi
[10:28] <pochu> persia: but as you said, updates shouldn't go to revu, so that's alright
[10:28] <persia> pochu: Feel like a few reviews?  I'll paste if you can't find the person online.
[10:29] <pochu> persia: why not? :)
[10:29] <persia> pochu: Just ping the person, prep stuff in a pastebin, and post to the channel :)
[10:30]  * persia wonders if any packagers are around and want to request a review for their upload
[10:32] <pochu> persia: you might want to paste this in deskscribe. I reviewed it last night for ember, but would be fine to post it so nobody reviews it until those issues are fixed. http://paste.ubuntu.com/2783/
[10:34] <persia> pochu: pasted.  Thanks.
[10:34] <persia> pochu: I generally try to explain each one a little, as the lintian output isn't always very clear.
[10:35] <pochu> well, I talked with ember about those who were complicated - the .desktop one :)
[10:35] <persia> pochu: Right.  In this case it's OK because it's just documentation of an IRC conversation, but if you happen to hit a new one :)
[10:36] <pochu> ok :)
[10:36] <pochu> bbl, will pick up one for review when i'm back
[10:38] <jonnymind> Uhm, sorry for jumping in, but I am reading about REVU and universe...
[10:39] <jonnymind> I thing I am doing how I am been told to do, that is, posting a new package in REVU.
[10:39] <persia> jonnymind: No need to apologize.
[10:39] <jonnymind> *think
[10:40] <persia> jonnymind: If you have a package that is not in Ubuntu, REVU is the best way to get it into Ubuntu.
[10:40] <jonnymind> persia: more than apologizing (which never hurts when you're wrong), I am asking for the correct procedure to follow...
[10:40] <persia> jonnymind: First, make a perfect package.
[10:40] <jonnymind> OIC. Thnx.
[10:40] <persia> Second, upload to REVU
[10:41] <jonnymind> persia: First and second should be ok then  :-)
[10:41] <persia> Third, wait for REVU day, and tell everyone the URL for your package REVU entry.
[10:41] <persia> Fourth, fix all the issues the reviewers discovered.
[10:41] <persia> Fifth, reupload
[10:41] <persia> (steps 4 & 5 may repeat a surprising number of times, depending on policy changes, and the varying skills of the reviewers)
[10:42] <jonnymind> persia: and next REVU day is?
[10:42] <persia> sixth, when your package is in the NEW queue, wait for feedback from the archive admins to see if it will be rejected.
[10:42] <persia> seventh, download and enjoy
[10:42] <persia> jonnymind: It's REVU Day now (and for abother 2898 minutes)
[10:42] <jonnymind> Oh
[10:42] <jonnymind> In this case...
[10:43] <jonnymind> http://revu.tauware.de/details.py?package=falcon
[10:43] <jonnymind> As I said in the notes of the bug...
[10:43] <jonnymind> (let me pick it...)
[10:44] <jonnymind> bug 174470ù
[10:44] <ubotu> Launchpad bug 174470 in ubuntu "Package for the Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
[10:44] <pochu> jonnymind: a watch file would be appreciated
[10:44] <jonnymind> the package is marked as 0.8.5, and I am cleaning the version and finalizing debug for 0.8.6 stable release in these days, but the packaging process is complete.
[10:45] <jonnymind> persia: watch file?
[10:45]  * persia suspects that the previous would benefit from s/persia/pochu/
[10:46] <pochu> jonnymind: in debian/changelog, version should be -0ubuntu1 and not -1, do not put more messages than * Initial release, close your launchpad bug with 'LP: #174470', s/unstable/hardy/, and put a break line in middle of the 'falcon (0.8...' line and the changes one, and same between the changes one and the timestamp one
[10:47]  * persia notes that additional entries in the changelog to explain distribution-specific patches are also acceptable.
[10:47] <jonnymind> tnx
[10:47] <jonnymind> doing
[10:47] <pochu> jonnymind: a watch file is a file which allows you to download the upstream tarball using a tool named uscan. Very useful. See https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[10:49] <pochu> jonnymind: if used dh_make, it created a watch.ex file with some example lines, as a webserver, a ftp page, a webpage, sourceforge...
[10:51] <pkern> jonnymind: availabe -> available
[10:52] <jonnymind> Uhm...
[10:52] <pkern> jonnymind: debian/copyright should be improved.
[10:52] <jonnymind> pkern: how?
[10:53] <pochu> jonnymind: debian/control: there's a new standars version :) put yourself as 'XSBC-Original-Maintainer', and put 'Ubuntu MOTU Developers<EMAIL_ADDRESS>as the Maintainer (Ubuntu is team maintained). Improve the short description so it reflects what the package is for (if it's the engine, the dev files...). And a Homepage filed in the source part would be nice.
[10:53] <persia> apachelogger: Why didn't you advocate libksquirrel?
[10:54] <jonnymind> Great.
[10:54] <jonnymind> pochu: doing
[10:54] <pkern> jonnymind: Yay.  Yet another licence.  Reproduce it in full in debian/copyright, list the authors and their copyrights (the licence headers in the files refer to AUTHORS, which does not exist...)
[10:55] <pkern> jonnymind: And take debian/copyright of an existing package as a template.
[10:55] <jonnymind> pkern: yes. Uhm... atm I am the sole autor, but I do have an AUTHORS file; I just failed copying it in the package :-)
[10:57] <pkern> I did not evaluate the freeness of the licence, though.
[10:57]  * pochu checks the license
[10:57] <pochu> heh
[10:57] <pkern> pochu: <3
[10:57] <jonnymind> pkern: the license is thought to be more free than usual.
[10:57] <persia> jonnymind: More free than ISC?
[10:58] <pkern> jonnymind: Is it based on some other licence?
[10:58] <jonnymind> pkern: it's apache2 license with extra openness for scripts and pre-compiled items.
[10:58] <jonnymind> also, as falcon is meant to be an embeddable language, it frees the embedding applications.
[10:58] <jonnymind> That's quite a controversal matter for i.e. python.
[10:59] <pkern> Except that they need to reproduce a notice that they use the language.
[10:59] <jonnymind> however, plesase, go check.
[10:59] <apachelogger_> persia: didn't know I have to ;-)
[10:59] <pkern> Well, got to go, anyway.
[10:59] <jonnymind> yes, they do need to do that.
[10:59] <persia> apachelogger: You don't, but if a MOTU doesn't advocate their own package, it doesn't look very interesting to others :)
[11:00] <jonnymind> pkern: (et al), I am currently having a lawyer filing a request at OSI for omologation.
[11:00] <apachelogger> hehe, I added an advocate, thanks :)
[11:00] <persia> apachelogger: No problem: I'm just trying to clean up for REVU day.  We've a large number of advocated packages today, so I'm hoping for some uploads.
[11:01] <slomo> siretart: libavutil1d has a soname change...
[11:01] <slomo> siretart: .1d -> .49
[11:01] <jonnymind> pochu: should I add maintainers also to binary package sections?
[11:04] <persia> Supremus: About patching.  Have you read https://wiki.ubuntu.com/PackagingGuide/PatchSystems ?
[11:04] <persia> jonnymind: Maintainer only needs to be in the source section.  it gets mangled by the buildds for the binaries anyway.
[11:04] <jonnymind> k
[11:04] <pochu> IANAL, but the license looks good.
[11:05] <Supremus> persia, no... :'(
[11:05] <jonnymind> pochu: how should I file the home page in the source part?
[11:05] <pochu> jonnymind: you _need_ to add a LICENSE file to your upstream tarball, though
[11:05] <pochu> a link to a webpage is not enough
[11:05] <jonnymind> Uhm... it should be there. Let  me see
[11:05] <pochu> there's a copyright file with a link.
[11:05] <persia> Supremus: Essentially, we try to match the patch system in Debian as closely as possible, and use the patch systems to adjust files, rather than creating duplicates.  Maybe worth a read.
[11:06] <jonnymind> It's there!
[11:06] <jonnymind> pochu: it's there in the root, called LICENSE.
[11:06] <jonnymind> Ops
[11:06] <jonnymind> License.
[11:06] <jonnymind> Should that be uppercased?
[11:06] <slomo> siretart: and there are some bugs you can close now and some that are trivial to fix... like building against libfaad2-dev, package newer snapshot bugs... and #434494, #439970
[11:06] <pochu> jonnymind: the homepage, put 'Homepage: http://url.com' under Build-Depends
[11:07] <jonnymind> k
[11:07] <pochu> heya slomo
[11:07] <Supremus> persia, you speack about wxmaxima?
[11:07] <persia> Supremus: Yep :)
[11:07] <pochu> jonnymind: heh, I see. I saw copyright and thought that was it :)
[11:07] <Supremus> persia, :D
[11:08] <Supremus> persia, is not correct?
[11:08] <pochu> jonnymind: usually licenses are named COPYING, afaik
[11:08] <slomo> hi pochu
[11:08] <pochu> jonnymind: but that's not something you need to change ;)
[11:08] <Supremus> becouse the icon there is
[11:08] <jonnymind> pochu: the issue is a bit confusing; they said COPYING is for GNU things, and this is definitely not.
[11:08] <persia> Supremus: No.  The old version has a patch against the upstream .desktop file.  You've removed the patch, and put a .desktop file in debian.  You want to update the patch to have your changes.
[11:08] <pochu> slomo: reminder, gstreamer patch :) http://emilio.pozuelo.org/~deb/dont_hardcode_distribution.patch
[11:08] <slomo> pochu: later, sorry :)
[11:09] <pochu> slomo: sure, want a mail?
[11:09] <slomo> sure
[11:09] <pochu> :)
[11:11]  * persia grumbles about debian/ in orig.tar.gz
[11:12] <Supremus> persia, ok I try
[11:12] <jonnymind> Eh?
[11:12] <jonnymind> debian in orig?
[11:12] <jonnymind> It shouldn't be there.
[11:12] <jonnymind> let me see...
[11:12] <persia> jonnymind: Not your package.  A different package.
[11:12] <jonnymind> Ah :-)
[11:14] <jonnymind> allee: I am really tring to do a "respectful" thing. I wrote falcon primarily because I thought that the other scripting engines were not "respectful" enough of their host applications (and also the languages, at times they were not... respectful enough of the users).
[11:14] <jonnymind> Ops.
[11:14] <Supremus> persia, but is non correct put the desktop file in debian folder?
[11:14] <jonnymind> I meant all:, but autocompletion did the rest.
[11:15] <persia> Supremus: The debian/ folder is where the .desktop file goes if (and only if) upstream does not yet have a .desktop file.  Any package with a .desktop file in debian/ should have an upstream bug to fix that.  In this case, upstream does the right thing.
[11:16] <Supremus> ok
[11:16] <persia> jonnymind: I'm lost.  Do you need more input, or was the above sufficient for you to prepare a new candidate?
[11:17] <jonnymind> persia: I think it's ok; except for the watch thing, I need more time to get it.
[11:17] <persia> jonnymind: Watch files are tricky.  In addition to the wiki page, the uscan manual (man uscan) may be helpful.
[11:18] <jonnymind> thanks.
[11:18] <persia> LucidFox: I can't reconstruct your diff.gz from your interdiff.  Did you use -p1?
[11:19] <LucidFox> yes
[11:19] <pkern> jonnymind: Did you already submit it to debian-legal?
[11:19] <persia> LucidFox: Ah.  combinediff doesn't support hunk-splitting, so that can't be used to generate the new diff.gz.
[11:20] <jonnymind> pkern: no. How's that done?
[11:20] <persia> Would you mind putting up an interdiff without -p1?
[11:20] <persia> pkern: Can we submit licenses that aren't for Debian to debian-legal?
[11:21] <jonnymind> persia, pkern: also, this thing is "free" in the OSI sense (cc, apache) rather than in the GNU sense (GPL).
[11:21] <jonnymind> debian is a bit more GNU centric; afaik, ubuntu is more OSI centric (i.e. launchpad license...)
[11:21] <Fujitsu> Launchpad is entirely non-free. There is no known license.
[11:22] <LucidFox> persia> uploaded
[11:22] <persia> LucidFox: Thanks.
[11:22] <jonnymind> Fujitsu: yes, I refer to the contents not to the platform.
[11:22] <persia> LucidFox: Just fro curiosity, which document suggests -p1?
[11:22] <LucidFox> the wiki page
[11:22] <LucidFox> https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
[11:23] <Fujitsu> Hah, I just got a 500.
[11:23] <Fujitsu> (from that wiki page)
[11:23] <persia> LucidFox: Any suggestions on how to make it more clear?  I read that as asking for an interdiff without -p1 for sponsoring, and explaining why.
[11:24] <persia> LucidFox: Especially I'm confused given the bit about how to test an interdiff.
[11:25] <LucidFox> I think the page should explain what a "consolidated interdiff" and "full interdiff" is. Namely that a consolidated one uses -p1 while a full one doesn't.
[11:25] <jonnymind> pkern: Should the authors be listed explicitly in the copyright file, or is an AUTHOR file in the docs dir ok?
[11:25] <persia> LucidFox: Hmm.  I suspect you're right.  I'll try to make that more clear.
[11:27] <persia> LucidFox: Missing get-orig-source for repacked tarball.
[11:28] <pkern> jonnymind: All copyright owners should be listed.
[11:28] <jonnymind> Ok
[11:29] <Supremus> persia, thanks a lot is work
[11:29] <jonnymind> pkern: Uhm... I am already in and there's noone else ;-)
[11:29] <persia> Supremus: Good news!
[11:29] <jonnymind> I'll remove the reference to the committee that is currently an empty set (sadly)
[11:29] <LucidFox> The tarball isn't repacked
[11:30] <LucidFox> or wait... it was a bz2
[11:30] <persia> LucidFox: The watch file gives me a bz2 file, and I want a gz file.
[11:30] <LucidFox> ack
[11:30] <persia> LucidFox: This will probably be fixed for hardy+1, and we can use bz2 files, but for now, we still need the get-orig-source rules.
[11:38] <persia> Supremus: That looks nice and small.  Good work.
[11:40] <persia> Supremus: Although, the patch doesn't apply :(
[11:41] <jonnymind> pkern: the copyright you refer to for the complete list of holders is the on that is installed in doc or the one that is in DEBIAN int he source package (or both)?
[11:41] <Kmos> pkern is not online anymore
[11:42] <LucidFox> Can get-orig-source assume that the upstream version is up to date?
[11:42] <LucidFox> (That is, that the package uses the last upstream version available?)
[11:43] <persia> LucidFox: It can.  Personally, I'd prefer that it got the source for the current version, but policy is quite clear that it should get the tarball for the newest upstream version.
[11:44] <persia> LucidFox: As a result, get-orig-source can usually use uscan to grab the tarball, and then manipulate from that.
[11:44] <geser> is a rmadison expert around? shouldn't "rmadison -u debian -s unstable -a source jd" result only in one line? I get two lines which seems to confuse requestsync
[11:45] <persia> geser: You get two lines because the m69k & s390 builds aren't complete.
[11:45] <persia> geser: This is expected, if a little annoying.
[11:45] <geser> persia: even if I tell I want source only?
[11:46] <persia> geser: Hmm.  Good point.  I missed the "-a source" part
[11:46] <geser> I also get all architectures listed when querying debian
[11:47] <geser> compare it with "rmadison jd" and "rmadison -a source jd" for Ubuntu
[11:48] <jonnymind> persia: I am repacking.
[11:48] <persia> jonnymind: repacking?
[11:48] <jonnymind> Regenerating the package along your corrections.
[11:49] <persia> jonnymind: Good, although you shouldn't give me any credit: I didn't even look at your package :)
[11:50] <Kmos> geser: http://qa.debian.org/madison.php?package=jd&a=&b=&c=&s=unstable
[11:50] <Kmos> bug in madison.php ?
[11:50] <jonnymind> :-) yes, "your" was plural.
[11:50] <geser> Kmos: that's the question
[11:51] <jonnymind> (English is a funny languge at times ;-)
[11:51] <Kmos> -a means architecture
[11:52] <persia> geser: It's a bug on the debian server (if it's a bug).  I can replicate in sid, including getting a single line when querying for -a source.  The rmadison source doesn't even check the value.
[11:53] <persia> Err.  "getting a single line when querying for -a source against Ubuntu"
[11:53] <LucidFox> Uploaded new interdiff with get-orig-source
[11:54] <jonnymind> pochu: reuploaded
[11:54] <jonnymind> pkern: reuploaded
[11:54] <Kmos> persia: right.. it's a bug in madison.php
[11:54] <persia> jonnymind: For the best package, it's best to get new reviewers for each upload.  Best to advertise your URL again, and ask for reviewers.
[11:55] <persia> Kmos: Do you know how to patch it?
[11:55] <jonnymind> Uhmm... yes.
[11:55] <jonnymind> in this case...
[11:55] <jonnymind> Bug #174470
[11:55] <ubotu> Launchpad bug 174470 in ubuntu "Package for the Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
[11:56] <Kmos> persia: i'll mail Christoph Berg about it.. if I have access to madison.php I can fix it for sure
[11:57] <Kmos> the rmadison only querys the url.. so we can't do anything
[11:57] <persia> Kmos: No need to bother anyone until there is a patch.
[11:58] <persia> Kmos: Rather, a tested patch.
[11:58] <Kmos> http://qa.debian.org/~myon/madison.php?package=jd&a=source&b=&c=&s=unstable
[11:58] <Kmos> the myon own madison still have that bug
[11:58] <Kmos> persia: there is access to the source of it ?
[11:58] <persia> Kmos: Right, which means it might not be madison.php, but could be dak ls directly.
[11:59] <persia> Kmos: Yes.
[11:59] <Kmos> persia: we're I can get madison.php ?
[11:59] <pochu> jonnymind: still no watch?
[12:00] <frenchy> persia: I hope that someone is paying you for this, you're an animal!
[12:00] <persia> Kmos: I don't know, but I do know that the source of all the debian websites is intended to be available somewhere.  Might need some research: the answer is likely in a package description or on a wiki.
[12:00] <Kmos> another example
[12:00] <Kmos> http://qa.debian.org/madison.php?package=smc&a=source&b=&c=&s=unstable
[12:00] <jonnymind> pochu: I'll add a watch when I am confident with the mechanism...
[12:00] <persia> frenchy: Would you like to help ?
[12:00] <Kmos> for smc package
[12:00] <jonnymind> pochu: i.e. I need to study it.
[12:01] <Kmos> persia: i will try =)
[12:01] <pochu> jonnymind: I suggest you to look at other packages' watch file
[12:01] <persia> Kmos: Good luck.  Just remember to try to find the solution before you email the maintainers.  Those are some of the busiest people in Debian.
[12:01] <jonnymind> pochu: where do I find the watch file in a package?
[12:01] <frenchy> persia: I can't keep up.  But if you need a hand the least I could do is offer you help seeing as how you've been good to me.
[12:01] <pochu> jonnymind: in debian/watch
[12:02] <jonnymind> OIC
[12:02] <persia> frenchy: Thanks for that, and sharing advice with others is always welcome.  I had intended to be joking about helping pay me, but it was only a joke :)
[12:02] <frenchy> persia: I'm still madly trying to finish off coding Me TV ... but if you're hurting.
[12:02] <pochu> jonnymind: and use 'uscan --verbose' in debian/.. to see how it works ;)
[12:03] <frenchy> persia: I wanted to get Me TV squared away so I could focus on maintaining.  It's hard doing both.
[12:03] <persia> frenchy: No.  I like doing this.  For Me TV, you just need to get the testers lined up: the package has been looking good for a while.
[12:03] <jonnymind> pochu: testing it...
[12:03]  * persia notes that uscan --verbose also works in the base package directory
[12:03] <jonnymind> OOOOO impressing!
[12:04] <pochu> persia: that's where I meant :)
[12:04] <jonnymind> gian@hplin:~/tmp/falbuild/falcon-0.8.5$ uscan --verbose
[12:04] <jonnymind> -- Scanning for watchfiles in .
[12:04] <jonnymind> -- Scan finished
[12:04] <Kmos> persia: ok. thx
[12:04] <jonnymind> ;-P
[12:04] <pochu> persia: it doesn't work in debian/, but does in debian/.. ;-)
[12:04] <persia> pochu: :)
[12:04] <pochu> jonnymind: it found nothing!
[12:05] <jonnymind> pochu: acute ,-)
[12:05] <frenchy> persia: There's a couple of loose-ends.  I've been trying to round up testers for DVB-S so I can confirm that it's fully supported.
[12:05] <pochu> jonnymind: should say either 'upstream has the same version as us', or 'upstream has a newer version, downloading'
[12:05] <jonnymind> pochu: I am studying the topic.
[12:05] <persia> frenchy: That's the hardest part.  Good luck.
[12:05] <pochu> jonnymind: oh, ok :-)
[12:05] <frenchy> persia: And to be any kind of alternative to klear I have to have scheduled recordings.
[12:05] <frenchy> persia: Thanks.
[12:06] <frenchy> persia: I'll promise that I'll be back when I have time to focus better.  I'd rather do one thing well than 2 things poorly.
[12:07] <persia> frenchy: I'd agree to that.  Also, if you make perfect apps upstream, that's as helpful to us as if you maintain things perfectly :)
[12:08] <frenchy> persia: Yeah, I see that now that I've been a packager as well.
[12:11] <jonnymind> pochu: in a range 0-10, what is the necessity of watch for package approval?
[12:11] <persia> jonnymind: 10
[12:11] <pochu> heh
[12:11] <persia> (or a working get-orig-source, where watch is impossible)
[12:11] <jonnymind> I see.
[12:12] <jonnymind> I am lucky having a site then.
[12:12] <pochu> jonnymind: it's *easy* to create a watch file, specially if you are upstream :)
[12:12] <persia> jonnymind: The problem is that we mostly rely on Debian to grab new upstreams.  For packages only in Ubuntu, we need the watch file so we know when to update the package.
[12:15] <jonnymind> you're right, it was easy:
[12:15] <jonnymind> Newest version on remote site is 0.8.5, local version is 0.8.5
[12:15] <jonnymind>  => Package is up to date
[12:15] <jonnymind> :-)
[12:15] <jonnymind> Wiki tend to hide context informations.
[12:16] <jonnymind> pochu: The watch file should be copied in the DEBIAN dir of the source package, right?
[12:19] <pochu> jonnymind: right
[12:19] <pochu> debian/ dir
[12:19] <pochu> so it goes to diff.gz
[12:19] <jonnymind> Great, thanks
[12:21] <jonnymind> pochu: Ok, this should be everything.
[12:22]  * pochu waves at POX_ :-)
[12:22] <POX_> hi :)
[12:22] <pecisk> hi people, I want to contribute package to universe, what shall I do?
[12:23] <persia> pecisk: Are you familiar with the way that packages are made for Ubuntu?
[12:23] <pecisk> more or less, yes
[12:25] <pecisk> persia: but in this case it is even simpler. I would like to upload yaz packages. They have debian control files already, and they succesfully build on Ubuntu, so it is matter of changing info and support contact.
[12:25] <persia> pecisk: In that case, look through https://bugs.launchpad.net/ubuntu/+bugs?file.tag=needs-packaging to find an interesting unclaimed package, wrap it in a .diff.gz, and submit to REVU.
[12:25] <persia> pecisk: Ah.  A specific package.  In that case, you want to put it on REVU.
[12:25] <persia> !revu
[12:25] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[12:25] <pecisk> thanks
[12:37] <pochu> persia: do you know why revu doesn't pick the orig.tar.gz from the previous upload? http://revu.ubuntuwire.com/details.py?package=falcon
[12:37] <pochu> jonnymind: mind building the source package with '-S -sa' options, and reuploading? so we get the .orig.tar.gz
[12:38] <persia> pochu: Because REVU doesn't use anything from the previous upload except when making a debdiff.  That's intentional, so the .changes file will be correct.  That feature never actually got heavy use for other reasons, and the final solution will be something else, but we retain that behaviour because nobody thinks it's important enough to fix.
[12:39] <pochu> I see. thanks
[12:43] <pochu> bbl
[12:44] <jonnymind> pochu: immediately
[12:46] <jonnymind> pochu: done; sorry, I beleived the orig was included by default.
[12:46] <jonnymind> ops, still uploading
[12:46] <jonnymind> pochu: upload complete
[12:49] <Supremus> persia, now wxmaxima is ok
[12:51] <persia> Supremus: Please close a bug in your changelog.  Also, see William's comment.
[12:53] <Supremus> persia, :'( sorry
[12:54] <persia> Supremus: Each one is closer.  You'll have it soon.
[12:55] <Supremus> :D
[12:55] <Supremus> tanks
[12:56] <Supremus> *thx
[13:05] <Supremus> persia, now is ok :D :D :D
[13:06] <persia> Supremus: See Siegfried's comment
[13:07] <Fujitsu> See Siegfried's comment that says to see mine, yep.
[13:07] <Supremus> persia, :'( :'( :'(
[13:07] <persia> Fujitsu: Just a matter of timing.  RainCT hit the review of the latest candidate first :)
[13:08] <Fujitsu> persia: Not the latest.
[13:08] <RainCT> heh
[13:08]  * persia is behind, and clearly needs to poll more often :)
[13:08] <Fujitsu> Ah, the latest one added a bug number.
[13:09] <persia> Still....  The categories aren't addressed.
[13:09] <Fujitsu> Correct.
[13:11] <Supremus> I misunderstood your comment, sorry
[13:12] <geser> Fujitsu: Hi, is debian bug #448437 something for ~motu-swat? the upload says it's a security fix
[13:12] <ubotu> Debian bug 448437 in unp "unp: Incomplete filename escaping" [Important,Fixed] http://bugs.debian.org/448437
[13:14] <Fujitsu> geser: Looking.
[13:17] <Fujitsu> geser: Quite possibly..
[13:17] <DaveMorris> I'm around if people wanted to revu 1 of my packages - http://revu.tauware.de/details.py?package=libserial
[13:28] <geser> DaveMorris: why have you a binary-install/libopensg-dev::
[13:28] <geser> target in your debian/rules file for libserial?
[13:33] <DaveMorris> must be a copy and paste error, since I'm working on that package as well
[13:34] <DaveMorris> but it's meant to do what the code says,
[13:36] <DaveMorris> geser: any other changes before I upload a fixed version?
[13:37] <geser> DaveMorris: why do you have "DEB_INSTALL_DOCS_ALL := -XREADME -XNEWS" in debian rules and list NEWS and README in debian/docs? Does it sound a little bit contradictionary?
[13:37] <DaveMorris> right, so I'll remove them from debian/docs
[13:38] <DaveMorris> and i guess I won't need the deb-install_docs bit then
[13:47] <tsmithe> persia, hi - thanks for the revu. i'd like to make one more change. how do i add a notification (like the firefox reload required one) to inform the user about the soundfont situation?
[13:48] <persia> tsmithe: I'm not sure.  Given that anyone who is actually doing anything with samplers likely has some soundfonts, I think we can call it a user-education issue for now: otherwise you'd want to touch all the soundfont clients.
[13:49] <jimqode> what is the name of the package that does automounting in ubuntu?
[13:49] <tsmithe> jimqode, the application is gnome-volume-manager
[13:49] <tsmithe> package has the same name
[13:49] <jimqode> tsmithe, thank you!
[13:50] <tsmithe> persia, hmm. i just don't like having an apparently non-function application without some kind of reasoning given, especially if it is "my" package
[13:50] <tsmithe> *non-functioning
[13:50] <tsmithe> jimqode, no problem
[13:50] <persia> tsmithe: I understand.  I think you've documented it well in README.Debian.  You might look in the alsa package or the firefox package to see how the notification works.
[13:51] <tsmithe> i'm on it right now :)
[13:51] <tsmithe> i get the impression that most users don't check README.Debian
[13:52] <persia> tsmithe: They don't, but that's the standard way to provide that type of information.
[13:57] <dsop> is there some motu around, who is willing to advocate for my package http://revu.tauware.de/details.py?package=gcutils ?
[13:58] <dsop> Still searching for a second advocate since 2 weeks :/
[13:59] <persia> dsop: You might get someone more interested if you explained why it's a good package (e.g. what it does).  There are a few people looking at cvs to git migrations who may find it useful, and be encouraged to advocate & sponsor it.
[14:01] <DaveMorris> geser: I've fixed those issue in libserial
[14:03] <dsop> Okay. Let's explain it a bit. A lot of people deal with using git and cvs the same time. There is a public cvs repository but the developers use git to do their work. Therefore they use git-cvsexportcommit and git-cvsimport which does the job perfectly but it's not quit handy. Therefore gc-utils just wrap these commands to make it more handy and to make it possible to easily import cvs repositories into git and commit back from the git reposito
[14:05] <dsop> gcutils just aim to make daily tasks easier for those who want to have their cvs in git.
[14:13] <persia> dsop: My apologies.  That didn't seem to have the desired effect.  Maybe it's just a bad time of day.  You might try again in 5 or 6 hours.  I'd try a shorter into paragraph, and be sure to include the link to the REVU page at that time.
[14:24] <jonnymind> persia: btw, I am searching for sponsors too. Is there anywhere else I should search for or should I just stick here?
[14:25] <LucidFox> What would be the best way to get into Ubuntu a package from debian-multimedia.org that's not in Ubuntu?
[14:25] <persia> jonnymind: This is the place.  Just as a matter of nomenclature, you're currently seeking advocates for your reviewed package (as you recently got reviewers for your new package9
[14:25] <persia> LucidFox: Err.  Is it already perfect?
[14:26] <jonnymind> persia: ok. Sorry for being a bit pedantic, I just want to do things The Right Way (TM).
[14:26] <persia> jonnymind: No worries: I'm the pedantic one :)
[14:27] <jonnymind> :-)
[14:27] <LucidFox> Let's suppose I adapt it for Ubuntu. What would be the next step? REVU?
[14:28] <persia> LucidFox: If you're adapting, REVU is best.
[14:29] <persia> For the REVU submission, don't worry about minimal diff.  We did that a couple years ago, and ended up with a bunch of buggy packages (not all from debian-multimedia: mostly from other random repos, but the idea that only Debian should sync is pretty firm these days)
[14:30] <persia> On the other hand, if you get it linda & lintian clean (or as close as is possible with the current disagreements), and send a patch back to debian-multimedia, they may well accept it.
[14:45] <siretart> slomo: thanks for notifying me. will do another upload tonight
[14:53] <pochu> jonnymind: http://revu.ubuntuwire.com/revu1-incoming/falcon-0712161350/lintian
[14:53] <jonnymind> Acc.
[14:53] <jonnymind> I forgot.
[14:53] <jonnymind> let me remove it.
[14:54] <pochu> jonnymind: wait, don't upload yet
[14:54] <jonnymind> k
[14:56] <pochu> jonnymind: in debian/changelog, you don't need to put 'close your launchpad...', just LP: #174470
[14:56] <pochu> jonnymind: you can put it though, but you don't need to :)
[14:56] <jonnymind> I see. Well, I have nothing particular to write there so...
[14:57] <pochu> :)
[14:58] <pochu> jonnymind: in control, update the Standards Version to 3.7.3. And improve the short description to reflect that the -dev package contains development files, and the other package contains whatever
[14:59] <jonnymind> 3.7.3, wow, a moving target...
[15:00] <jonnymind> pochu: uhm... what do you mean with "improve description"?
[15:00] <pochu> jonnymind: debian/copyright - see /usr/share/doc/python/copyright, you need to put the entire license if it's not GPL or LGPL or GFDL. Also use the same template
[15:00] <pochu> jonnymind: the 3 package have the same short description
[15:00] <jonnymind> pochu: ok; I thought that the whole license thing was only for the /doc things (well, it really seemed so).
[15:00] <pochu> jonnymind: I'd change in the -dev package the short description to 'The Falcon Programming Language - development files'
[15:00] <jonnymind> Eh?--no.
[15:01] <pochu> but remember that it should be less than 60 (or 80, not sure) chars
[15:01] <jonnymind> pochu: the last paragraph should be different.
[15:01] <pochu> jonnymind: yes, but sometimes you will only see the short one.
[15:01] <jonnymind> Uhm, so I should move the last para at top.
[15:01] <pochu> nope
[15:01] <pochu> the last one is fine
[15:02] <jonnymind> Ok
[15:02] <pochu> only change the first line so they are not the same
[15:02] <pochu> jonnymind: some times you will only see the long description ;)
[15:02] <pochu> so it needs to stay there too
[15:04] <jonnymind> pochu: Let's clarify. There is a first paragraph in each package description which is generic, and one last that is specific;
[15:04] <jonnymind> pochu: you are suggesting to use just one paragraph, starting differently, for each package description?
[15:05] <pochu> jonnymind: I don't have more time, need to go. But I'd suggest you to check the binary packages with lintian to see if there are some errors there. 'lintian *.deb' will check the binary files, and 'lintian *_i386.changes' (if you have i386 architecture) will check both binary and source
[15:05] <pochu> jonnymind: wait, let me see
[15:06] <jonnymind> pochu: Binaries were all clear
[15:06] <jonnymind> Just, I forgot to run lintian on the source ...
[15:08] <pochu> jonnymind: if you run it against the .changes file it will run it in both binary and sources :-) so you don't forget one or the other ;)
[15:08] <jonnymind> k
[15:10] <pochu> jonnymind: see this file. The short description says whether it contains the shared files, the development files... or whatever. And the long description contains it too. That's the best way to put it imho. http://revu.ubuntuwire.com/revu1-incoming/libgnomekbd-0712141820/libgnomekbd-2.21.4/debian/control
[15:10] <jonnymind> perfect, thank you
[15:11] <jonnymind> Ok, understood
[15:11] <pochu> Just remember: no more than 80 chars per line :)
[15:13] <jonnymind> Yes, I crunched away "programming language" from the other description lines.
[15:14] <bddebian> Heya gang
[15:14] <Fujitsu> Hi bddebian.
[15:14] <pochu> bddebian!
[15:14] <bddebian> Hi Fujitsu, pochu
[15:16] <jonnymind> Uhm...
[15:16] <jonnymind> I understand lintian should understand this:
[15:16] <jonnymind> ember: falcon_0.8.5-0ubuntu1_source.changes: bad-ubuntu-distribution-in-changes-file hardy
[15:16] <jonnymind> wpk: falcon source: newer-standards-version 3.7.3 (current is 3.7.2)
[15:16] <jpatrick> jonnymind: ignore those
[15:16] <jonnymind> K
[15:16] <pochu> jonnymind: that's because you have an old lintian version :)
[15:16] <jonnymind> (however they are a bit confusing for the newcomer...)
[15:17] <RainCT> btw, is there a linda for 3.7
[15:17] <RainCT> * 3.7.3?
[15:17] <jonnymind> pochu: done all. Shall I upload?
[15:18] <Fujitsu> RainCT: Not yet.
[15:19] <pochu> jonnymind: if nobody wants to check it, do it. I'll build it and look at it later.
[15:19] <pochu> Later folks
[15:20] <jonnymind> later
[15:20] <bddebian> Bye pochu
[15:20] <Fujitsu> Bye pochu.
[15:38] <jonnymind> persia: Is there any problem if the final version of the package has a different version number?
[15:39] <persia> jonnymind: First, why ask me?  Second, what do you mean?
[15:40] <jonnymind> persia: Uhm... why ask you, because you seem the most competent person being currently online here
[15:40] <persia> jonnymind: That's certainly not true, but thank you :)
[15:41] <jonnymind> then, what I mean is, I'd like to finalize this version as 0.8.6 to start even-odd release convention for development versions.
[15:41] <persia> OK.  The current upstream is 0.8.5?
[15:41] <jonnymind> so, when I'll be done cleaning up docs and running killer tests the version should be marked 0.8.6 rather than 0.8.5 as it is marked now.
[15:41] <jonnymind> yes
[15:42] <jonnymind> Just, I wouldn't want to ruffle up feathers here, as ppl is working on 0.8.5.
[15:42] <persia> OK.  I'd suggest running the two in parallel.  While you're finalising upstream for 0.8.5->0.8.6, work with REVU on the packaging.  Once you're ready, bump the upstream, and polish the packaging for 0.8.6.  Get that uploaded.
[15:43] <persia> jonnymind: No worries.  People are mostly reviewing debian/ and licensing, etc.  That stuff is usually independent of the sorts of changes that would be 0.8.5 -> 0.8.6, and most people here don't really care about version numbers, as long as they change when new code is released.
[15:44] <jonnymind> Fine, thanks.
[15:44] <jonnymind> Ah, for the license question. From the wikis, I understood that the copyright in the debian/dir didnt' have to include the license, which had to be included in the share/doc tree.
[15:45] <jonnymind> Should I copy the license there too?
[15:45] <jonnymind> (I mean, in the share/doc/<p>/copyright files).
[15:47] <persia> If your license is not in /usr/share/common-licenses/, you need to include the full text of the license in debian/copyright, which should be automatically copied to /usr/share/doc/<package>/copyright.
[15:48] <jonnymind> Ok, thank you.
[15:50] <jonnymind> In the copyright, I'll skip the commentary... it's anyhow included in the License file, which I do ship everywhere.
[16:12] <tsmithe> persia, others, please check out http://revu.tauware.de/details.py?package=mscore
[16:12] <tsmithe> the package has previously had one advocate (persia)
[16:12] <Nafallo> oh
[16:13] <Nafallo> that's better then random numbers :-)
[16:13] <tsmithe> it is a notation program for linux, :)
[16:13] <tsmithe> Nafallo, random numbers?
[16:13] <persia> tsmithe: Yes, but I don't like it any more.  You should use install or dh_install rather than cp.
[16:13] <Nafallo> tsmithe: ?package=$package :-)
[16:14] <persia> tsmithe: Also, you likely want to use dh_link
[16:14] <tsmithe> Nafallo, ah well, it has a number too. the number is quite nice; 1024
[16:14] <tsmithe> persia, ok. i have to use cp, as the symlink usr/share/mscore can only be created after the files have been dh_install'd
[16:14] <tsmithe> ah
[16:14] <tsmithe> i understand about dh_link now :p
[16:14] <persia> tsmithe: Right, which is why dh_link appears after dh_install :)
[16:15] <tsmithe> yes :)
[16:16] <tsmithe> wait, no. same problem: dh_install creates the mscore-<whatever> directory. then, the symlink is created to usr/share/mscore. then, the .u-n file is installed to usr/share/mscore. this all happens to make upgrading the package easier; this release creates mscore-0.7, next may be mscore-0.8. i don't want to have to keep updating the rules file for each release, if it can be helped
[16:16] <tsmithe> the symlink can't be created before the mscore-<whatever> directory, because whatever is creating the symlink will not know then what <whatever> is
[16:18] <persia> tsmithe: Why version /usr/share/mscore?
[16:19] <persia> tsmithe: Anyway, you can get that from dpkg-parsechangelog, but I agree that dh_link would have trouble.
[16:19] <tsmithe> upstream said he wants to make it possible for other users, not necessarily ours, to install more than one version concurrently for testing. some files there are version specific, so he versions /usr/share/mscore
[16:20] <persia> tsmithe: That's a good reason then :)  The other alternative to make me happy is to use install instead of cp.
[16:21] <tsmithe> ok then. what are the advantages?
[16:21] <persia> tsmithe: It looks nicer?
[16:22] <persia> You can set the permissions.
[16:22] <tsmithe> i don't need to set special permissions? but ok, i'll do ask you say. i need to make another upload to explain the versioning of /usr/share/mscore anyhow
[16:23] <persia> tsmithe: Don't worry about it.  If /usr/share/mscore needs to be versioned, your solution works, my aesthetic preferences aside.
[16:23] <tsmithe> i want to make the new upload :)
[16:53]  * tsmithe wonders why revu is taking so long to show his latest upload
[16:58] <warp10> I'm packaging a software whose Makefile installs in /usr/local. Using dpatch to modify the originale Makefile is a good way to modify the path or should I follow another way?
[16:58] <DaveMorris> warp10: no configure I assume
[16:58] <persia> tsmithe: Are you sure you uploaded to REVU?  I can't find it.
[16:59] <tsmithe> no - you're right. i just checked my e-mails and looks like i accidentally uploaded to ubuntu.
[16:59] <persia> warp10: Sometimes the Makefile will have a means to override the default location, in which case you want to pass make the right arguments.  If you do patch the upstream makefile, patching it to be configurable is preferable, as you can pass that patch upstream, and drop it in the next release.
[16:59] <warp10> DaveMorris: it is. It's a simple software written in C, just make && make install
[17:03] <warp10> persia: so, just modifying the paths in the makefile through a patch is not a polite way to do it, is it?
[17:04] <persia> warp10: That would be a patch you'd have to maintain.  If you update the makefile to allow the passing of a variable with a default of /usr/local/ if not set, then you can just pass the variable in debian/rules, and upstream might want the patch.
[17:06] <warp10> persia: ok, thanks. Indeedn, the makefile has a prefix variable. Probably this is what I'm looking for.
[17:07] <persia> warp10: That makes it easy then :)
[17:08] <warp10> persia: unofrtunately, this is a game, so I should install it in /usr/games, but the prefix variable is used for icon and .desktop file too, so probably I have to edit the Makefile anyway
[17:09] <warp10> s/unofrtunately/unfortunately
[17:09] <persia> warp10: Well, you could shift things around in debian/rules after the $(make) install call.
[17:09] <warp10> persia: using cp?
[17:10] <persia> warp10: No, mv.  You don't want extra copies, do you?
[17:10] <warp10> pecisk:ops, mv of course. Thank
[17:10] <persia> (e.g. mv debian/tmp/usr/games/applications debian/tmp/usr/share/applications)
[17:10] <warp10> s/pecsik/persia :)
[17:11] <tsmithe> persia, apachelogger, anyone else: http://revu.tauware.de/details.py?package=mscore&upid=1025 please :)
[17:20] <jimqode> does anyone know what command gnome "switch user" feature calls?
[17:23] <DaveMorris> wrap10 you could always get the program to build with something like autotools instead (although this is harder)
[17:25] <warp10> DaveMorris: Thanks. Anyway, I'll probably try to modify the rules, I need (a lot of) practice with rules and makefiles :)
[17:27] <persia> DaveMorris: That's a fairly invasive patch, no?
[17:27] <DaveMorris> persia: yeah, but I was thinking doing it for upstream, then just consume :)
[17:40] <RainCT> can someone check bug 176147 and bug 176192 please?
[17:40] <ubotu> Launchpad bug 176147 in usbmount "Update maintainer field in version <IP_ADDRESS>" [Wishlist,Incomplete] https://launchpad.net/bugs/176147
[17:40] <ubotu> Launchpad bug 176192 in eterm "Candidate for version <IP_ADDRESS>debian1-2ubuntu2" [Wishlist,Incomplete] https://launchpad.net/bugs/176192
[17:42] <persia> RainCT: Those are fine.  Please put them back in the sponsors queue.  Sorry for the confusion.
[17:43] <tsmithe> persia, do you know if fluidsynth can be made to work with the old freepats stuff at all? or does it require the soundfont?
[17:44] <persia> tsmithe: I don't know offhand.  I just used a soundfont, as I couldn't even get timidity to work properly without one.
[17:44] <RainCT> persia: ok, thanks :)
[17:44] <tsmithe> ok, single sound fonts are a lot more convenient, it has to be said. hopefully, the notification in mscore should be adequate in the meantime
[17:45] <persia> RainCT: In the future, it might be worth mentioning in the bug comment that you don't expect to maintain the delta, and are really just pushing the maintainer change as otherwise the package isn't policy compliant when you attach the patch.
[17:46] <RainCT> persia: Okay. Is it encouraged to do such changes or is it prefered to just update the maintainer?
[17:47] <persia> RainCT: Probably better to just update the maintainer.  The other stuff is fairly useless, and likely to be overwritten.  If you can find another bug to fix along the way, that's a bonus.
[17:50] <joejaxx> i hope Gnomefreak feels better :(
[17:51] <somerville32> joejaxx, hmm?
[17:53] <somerville32> What is the package name for gtk dev stuff?
[17:54] <joejaxx> should be libgtk${version}-dev
[17:55] <Daviey> siretart: ping
[18:02] <zul> 'noon
[18:13] <chantra> hi there
[18:33] <warp10> persia: I still have problems with paths
[18:33] <persia> warp10: Even when you use mv?  I guess you need a patch then.  I still think it would be best to use variables so that you can push upstream, rather than maintaining an Ubuntu-specific diff.
[18:34] <warp10> persia: makefile set the prefix to /usr/local and install executable to $(PREFIX)/bin, so if I pass /usr/games as prefix to make, it installs to /usr/games/bin
[18:35] <persia> Right.  It should install to $(PREFIX)/$(BINDIR)
[18:37] <warp10> persia: I could fix everything with mv in debian/rules, but It doesn't look polite to me
[18:38] <persia> warp10: As long as you do it in debian/rules, it's polite, if annoying for you.  Patching the Makefile is more invasive, but if you can do it in a way that works for both you and upstream, depending on the variables passed to make, then you can send the Makefile patch upstream, and call it contribution, which is always polite.
[18:39] <persia> Patching the makefile agressively, or changing the build system completely would be less polite (although sometimes it is required).
[18:40] <warp10> persia: Ok. I'll use mv in makefile and contact upstream to find a solution togheter
[18:40] <persia> warp10: Finding a solution together is the best way :)
[19:06] <joejaxx> does anyone have a good example of a source package that build multiple binary packages and does not use cdbs?
[19:06] <joejaxx> s/build/builds/g
[19:07] <tsmithe> mscore!
[19:08] <persia> joejaxx: The trick is to use dh_install just so: the dh_install manpage is quite informative, but you might have to read it a few times (took me about five or six to get it).
[19:12] <joejaxx> persia: i am actually talking about the format of the rules file :)
[19:12] <joejaxx> persia: for example different configure flags for both packages
[19:13] <tsmithe> hmm that does sound awkward. i'd be interested to see how you'd do that without building the sources multiple times
[19:13] <persia> joejaxx: For that, it's mostly about using -i for the debhelper calls in the build-arch: rule and -a for the debhelper calls in the build-arch-indep: rule.  IF you want something very involved, you might look at wxedgets2.6, but it's not easy to follow.
[19:15] <joejaxx> persia: ok
[19:29] <joejaxx> persia: ah fun :D
[19:29] <joejaxx> persia: it is easy to follow :D
[19:29] <joejaxx> thanks for this example
[19:29] <joejaxx> its exactl what i needed
[19:29] <joejaxx> exactly*
[19:29] <siretart> Daviey: sorry, I don't like virtual table tennis
[19:30] <persia> easy?  I find it one of the strangest debian/rules around, but it does handle the case of mixed arch-any & arch-all with all sorts of different options and recompiles.
[19:31] <joejaxx> persia: yeah
[19:31] <joejaxx> for me it is
[19:31] <joejaxx> i cannot stand 2-4 liner rule files
[19:32] <joejaxx> which is why i do not like cdbs
[19:32] <joejaxx> lol
[19:32] <persia> joejaxx: Simplicity is bad?  OK.  As long as it works for you :)
[19:33]  * tsmithe doesn't like cdbs because he has to check loads of included files to see what's going on
[19:35] <Ubulette> cdbs is really good if you already know how to do complex packages without it. otherwise, it's just dark magic.
[19:37] <persia> Ubulette: Maybe.  Depends on how you learn.  If you start knowing make well, CDBS is reasonably well documented.  If you don't, it's perhaps a little odd.  Personally, I understand complex packages in CDBS, but really messy debian/rules confuse me: especially when they try to mix shell scripting & make.
[19:43] <Ubulette> I prefer cdbs but sometimes, it makes the package impossible to understand by anyone else than the author.
[19:47] <persia> (or another CDBS person)
[19:53] <joejaxx> yes! exactly! :P
[19:53] <joejaxx> its the blackbox of debian packaging haha
[19:53] <joejaxx> :P
[19:54] <joejaxx> two-liner debian/rules file -> cdbs "blackbox" -> debian package magically appears
[19:54] <joejaxx> :P
[19:55] <joejaxx> hello LaserJock :)
[19:56] <LaserJock> hi joejaxx
[19:57] <joejaxx> :)
[19:57] <Daviey> siretart: Any chance of another push of gnucash to your PPA :)
[19:58] <siretart> Daviey: do you have a source package for review for me?
[19:59] <LaserJock> siretart: you've got gnucash in your PPA?
[19:59] <Daviey> siretart: no :(, trying to - but pbuilder keeps failing :(
[20:01] <Daviey> LaserJock: he does
[20:01] <siretart> LaserJock: well, in the meantime, we have even created a gnucash team for having a gnucash team ppa
[20:01] <siretart> I would have already removed it from my ppa if I could
[20:01] <LaserJock> siretart: what is the purpose of the PPA?
[20:01] <Daviey> oh :(
[20:02] <Daviey> LaserJock: I'm guessing frequent SVN checkout builds
[20:02] <Flare183> what is the difference between using the regular rules file and using/refering to the cdbs folder?
[20:02] <joejaxx> that is why i have not used my ppa yet
[20:02] <joejaxx> there is no way to revoke packages
[20:03] <persia> joejaxx: siretart: packages may be removed from a PPA by request to the LP devs.
[20:03] <joejaxx> persia: i mean direct way :D
[20:08] <Ubulette> good. debdiffs posted to bug 164640. not sure i should subscribe main sponsors or let seb128 decide
[20:08] <ubotu> Launchpad bug 164640 in xulrunner-1.9 "Build Firefox 3 against a subpixel-patched cairo" [Medium,Triaged] https://launchpad.net/bugs/164640
[20:10] <TheMuso> Hey folks.
[20:10] <persia> Ubulette: He's one of the main sponsors, so it's likely the same either way.
[20:10] <persia> Good morning TheMuso
[20:10] <dfiloni> persia: ping
[20:11]  * persia watches a small white sphere float off into the distance
[20:12] <Ubulette> persia, I guess I have to change the status for libcairo and also add fontconfig
[20:12] <dfiloni> persia: I'm reading your latest comment on bug #172588. Salvatore Palma is a my friend, it is a newbie, what he should?
[20:12] <ubotu> Launchpad bug 172588 in atanks "[atanks] no .desktop file " [Low,In progress] https://launchpad.net/bugs/172588
[20:12] <dfiloni> persia: step to step
[20:12] <TheMuso> c
[20:12] <TheMuso> ugh
[20:13] <persia> dfiloni: It's entirely the wrong time of day here for me to answer that effectively.  Perhaps someone else could help?  Otherwise, try me in ~15 hours (although ~39 would probably be better)
[20:14] <dfiloni> persia: what time is it for you?
[20:14] <persia> 05:14
[20:14] <dfiloni> persia: oh my god, why you aren't on your bed?
[20:15] <joejaxx> persia: :P
[20:15] <persia> I think it was said best as "sleep is for the week"
[20:16] <Ubulette> pun intended ?
[20:17] <persia> Ubulette: I suspect.  It was a quote.
[20:18] <Ubulette> :)
[20:19] <dfiloni> persia: I wil contact you tomorrow to say what Salvatore Palma should do
[20:19] <dfiloni> persia: sorry, this evening
[20:19] <persia> dfiloni: No need to wait.  Ask someone else to help.
[20:19] <dfiloni> ok
[20:22] <somerville32> week or weak? :S
[20:23] <dfiloni> persia: go to sleep, in the latest days you was connected on irc 24h at day
[20:31] <joejaxx> lol `screen` ftw :)
[20:35] <Ubulette> persia, i've just pushed to revu my "native" mozilla dev package we've talked about a few days ago.
[20:35] <Ubulette> see, i didn't give up on it.
[20:36] <warp10> persia, and other: I upped the package I was working on. I would be happy to read your comments on it. http://revu.ubuntuwire.com/details.py?package=tennix
[20:38] <LaserJock> poor persia
[20:38] <persia> warp10: Isn't bug #176723 a duplicate of bug #149847?
[20:38] <LaserJock> he's the new crimsun ;-)
[20:38] <ubotu> Launchpad bug 176723 in ubuntu "[needs-packaging] Tennix" [Undecided,In progress] https://launchpad.net/bugs/176723
[20:38] <ubotu> Launchpad bug 149847 in ubuntu "[hardy]  [needs-packaging] Tennix 0.4.1" [Wishlist,Invalid] https://launchpad.net/bugs/149847
[20:39] <persia> LaserJock: Except I try to avoid updating alsa (but dangerously am currently touching alsa-tools)
[20:39] <LaserJock> heh
[20:39] <LaserJock> persia: commented on gc-utils btw
[20:39] <joejaxx> LaserJock: haha
[20:39] <joejaxx> :P
[20:39] <warp10> persia: just before starting to work on it I searched on launchpad, but 149847 is invalid so it didn't show up and I missed it
[20:40] <persia> LaserJock: Thanks.  It had been a couple weeks and needed another yes or no.
[20:40] <dsop> LaserJock: thanks
[20:40] <Ubulette> http://revu.tauware.de/details.py?package=mozilla-devscripts
[20:40] <persia> warp10: Invalid?  Strange status for a needs-packaging bug.  Mind sorting it out.  Given that almost nothing makes it in the first REVU round, it's not likely worth an upload until you get a real review.
[20:41] <LaserJock> persia, dsop: it looked pretty good except it needs deps on cvs and git-cvs :-)
[20:41] <dsop> LaserJock: i'll add it right now.
[20:44] <warp10> persia: yes, it's status is invalid. I have found it just before asking your review, when I saw someone upped before me
[20:44] <persia> warp10: It probably wants to be changed back to "In Progress" and assigned to you, and the new one set as a dup, just to keep the bug database accurate.
[20:45] <warp10> persia: Ok, I'll do that
[20:45] <persia> warp10: Thanks.
[20:46] <dsop> LaserJock: should i also update to standards 3.7.3?
[20:46] <warp10> persia: ok, done
[20:47] <persia> warp10: Exccellent.  Change the bug in your local source, and include it in the update after your next review.
[20:47] <dsop> LaserJock, persia: and lintian warns me that i use the binary-arch target, should i use the binary-indep target to do all the dh_* stuff in debian/rules?
[20:49] <dsop> because my package is arch independent
[20:49] <warp10> persia: ok :)
[20:51] <griffinc> Hi, I have read the MOTU wiki pages on syncing but had a question about what to document in the launchpad bug report.
[20:51] <griffinc> I had been working on launchpad #173117 (wmbinclock) as a merge and geser noted that the current Debian sid package built and installed fine in a hardy pbuilder.  I was able to verify this so he suggested a sync.
[20:51] <ubotu> Launchpad bug 173117 in wmbinclock "Please upload merge wmbinclock-0.5-5 (universe) from debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/173117
[20:52] <griffinc> The previous Ubuntu packages had included xlibs-dev, x11proto-xext-dev, and libxt-dev as Build-Depends due to the xorg transition.  xlibs-dev has been deprecated in fact.  Now that the xorg transition is over, those build-depends can be removed, which is why I believe the Debian package works now.
[20:52] <griffinc> So, in my sync request, do I just explain this in the bug report?  I don't really understand what I'm supposed to document.  Do I document this in the changelog or does the sync process take care of the changelog?
[20:53] <griffinc> I have worked on a previous merge but this is my first sync.  :-)
[20:55] <Adri2000> griffinc: there is no ubuntu changelog at all in a sync, we take the debian package as it is. you need to say in the bug report the rational for the sync, but it's just for the sponsor who will ack the sync and for the archive admin who will process it
[20:55] <persia> griffinc: Yes.  For sync requests, I recommend including three pieces of information:  1) the version you wish to sync, where it comes from (usually Debian unstable (main)) and where it goes to (usually universe).  2) An explanation of why it should be synchronised.  Discuss any Ubuntu delta that will be removed, and any benefit that will be gained by the sync (this should be just a few lines).  Mention that it builds correctly.  3) The Debian ch
[20:55] <Adri2000> persia: cut at "3) The Debian ch"
[20:55] <persia> Adri2000: Also for documentation if there is an issue with the synchronised package.
[20:56]  * persia hates buffers "3) The Debian changelog since the last merge or sync."
  It seems pretty straightforward.  Thanks!
[20:58] <persia> dsop: I'm not the best person to ask about that.  I think build-indep is better.
[20:58] <persia> griffinc: There's a requestsync program in ubuntu-dev-tools that some people think makes it easy.
[20:59] <dsop> LaserJock: i updated gc-utils. thanks for the review and for the suggestions. I added git-cvs and cvs as a dependency
[20:59] <griffinc> persia, yes, I saw that documented in the wiki.  I'll try that out.  thank you for the help.
[21:48] <ikonia> imbrandon: are you awake and do you have a moment free please.
[21:50] <persia> ikonia: Unless you really need imbrandon, you may have better luck asking your question generally.
[21:50] <ikonia> I actually need imbrandon
[21:50] <ikonia> I'm picking up a previous conversation and would like to ask his opinion on how to handle it due to the bug being worked on and how it effects other bugs
[21:51] <persia> ikonia: Ah.  Oh well.  You get to wait then.  If you get bored, ask around :)
[21:52] <ikonia> no problem happy to wait, it won't take long once imbrandon has 2 minutes free
[21:52] <ikonia> be nice to put a few things to bed properly,
[21:52] <somerville32> !ask | ikonia   :P
[21:52] <ubotu> ikonia   :P: Don't ask to ask a question. Just ask your question :)
[21:54] <ikonia> somerville32: I'm looking for a discussion with an individual. Please don't waste channel buffer with pointless ubotu posts to me
[21:54] <somerville32> IRC is stateless. Please don't waste the channel asking if someone is around ;]
[21:55] <persia> Err.  There's no buffer limit.
[21:55] <persia> You're both right, but maybe it's good to be careful about tone :)
[21:56] <crimsun> ikonia: if this question regards flashplugin-nonfree, it doesn't block on Brandon being present.
[21:56] <crimsun> (We don't have maintainers for the pools of packages as Debian does.)
[21:57] <ikonia> I appriciate that, I'd like to follow up conversation I had with him to follow up his work
[21:57] <somerville32> May I suggest e-mail?
[21:57] <somerville32> :]
[21:58] <ikonia> somerville32: I request you be quiet
[21:58] <ikonia> I was asking if a member of the team had a momenent of free time
[21:58] <ikonia> nothing more
[21:58] <somerville32> ikonia, It seems like you're upset
[21:58] <ikonia> not at all
[22:06]  * pochu contemplates how persia falls asleep on his keyboard :-)
[22:06] <pochu> persia: where are you from? I don't why I supposed you were from central europe
[22:06] <pochu> s/why/know why/
[22:07] <persia> pochu: Now I'm curious.  That's not one of the usual locations I hear :)
[22:08] <pochu> persia: which ones do you usually hear? :)
[22:09] <Ubulette> japan ? indonesia ?
[22:09] <Ubulette> korea ?
[22:09] <persia> pochu: Western Europe.  Asia.  North America.
[22:09] <persia> (the last is correct, although I'm not there now)
[22:10] <persia> Actually, there was also an Australia earlier today (also not common).
[22:10] <pochu> I bet your nick is the most pronnounced one on this channel :P
[22:11] <persia> pochu: I'm not sure.  I think there are stats somewhere though.
[22:12] <Ubulette> the last in JST was Yakutsk but i wouldn't have bet a kopeck on it :)
[22:12] <pochu> yeah, the question is where :-)
[22:13] <pochu> I'm off, have an exam tomorrow. Good night folks!
[22:13] <harrisony> night pochu
[22:15] <somerville32> persia is the most said word in this channel
[22:15] <persia> somerville32: Really?  What's #2?
[22:17] <somerville32> package
[22:17] <RainCT> lol
[22:17] <RainCT> gratz persia :P
[22:17] <persia> That's just not right.  Package.  package.  package.  package.  package.  package.  This is a channel about packaging, and making packages.
[22:18] <somerville32> Persia: You'll need to say it another 21 times, persia :P
[22:19] <RainCT> somerville32: where are the stats, btw
[22:19] <RainCT> hahah
[22:19] <somerville32> http://www.ubuntuircstats.org
[22:24] <Ubulette> not on a lot of archives but here is what i got: http://paste.ubuntu.com/2803/
[22:25] <persia> Ubulette: Thanks.  That makes me feel better.  Beating "the" would just be bad.
[22:26] <Ubulette> you're still the 1st human
[22:26] <somerville32> The bot only started like, today
[22:26] <persia> Ubulette: well, yes.  And unfortunately still above package. (package should be higher, but I'm not going to type it 645 times)
[22:27] <somerville32> lol
[22:28]  * Fujitsu finds it a bit odd that persia is right near the top for every time period.
[22:28] <persia> Fujitsu: Shhh!
[22:28]  * somerville32 doesn't find it odd at all.
[22:28] <crimsun> ah...I remember those days.  :-)
[22:29] <Ubulette> maybe persia is in the ISS above our heads :)
[22:29] <somerville32> I remember when my name used to be in the top few
[22:29]  * somerville32 was proud of himself, lol
[22:30] <somerville32> Although, it could mean I was doing more talking than packaging back then, haha
[22:30] <Ubulette> package + packages > persia :)
[22:30] <persia> \o/
[22:37] <crimsun> holy geeb...ia32-libs_2.2ubuntu1.tar.gz  (433.5 MiB).  This is going to take a while...
[22:38] <persia> Why is it monolithic again?
[22:45] <harrisony> Anyone have a good debian/watch file for google code projects, doesnt seem to like me
[22:45] <imbrandon> persia: possibly it just generates diffrent bins but the same source
[22:45] <imbrandon> just a guess
[22:46] <crimsun> the isp of this coffee shop is not going to be pleased.
[22:47] <somerville32> Is the IT infrastructure that bad there?
[22:47] <persia> imbrandon: unfortunately now.  3 binaries: the libraries, the dev librariles, and the gcc library.
[22:47] <persia> s/now/not/
[22:48] <crimsun> somerville32: no, it's actually quite good.  Can't complain about free wifi, but I'm blatantly abusing the AUP.
[22:48] <somerville32> Ah.
[22:48] <crimsun> then again, I normally wouldn't be caught dead dgetting ia32-libs source.
[22:49] <imbrandon> man i think i FINALY might have found a mail app i like just as well as webmail
[22:49] <somerville32> imbrandon, what app? :)
[22:50] <imbrandon> i could never get mutt the way i liked it , gui apps are too bloated for my computer useage , so alpine it is
[22:50] <imbrandon> somerville32: alpine
[22:50] <imbrandon> e.g. pine 5.x
[22:50] <imbrandon> seems perfect, i got almost everything the way i like it, keybindings and all
[22:51] <imbrandon> been using it only 2 days now though
[22:51] <mok0> I have strange build failures on the buildd, can someone help please?
[22:51] <imbrandon> mok0: like? a log or pastebin would be helpfull
[22:51]  * mok0 pastebins
[22:52] <imbrandon> plus alpine intergrates nano quite nicely :)
[22:52] <imbrandon> heh
[22:52] <mok0> imbrandon: http://pastebin.ubuntu.com/2804/
[22:53] <mok0> line 350
[22:53] <zul> evening
[22:53]  * imbrandon looks
[22:53]  * Ubulette uses mutt since 96~97, and mail/mailx before that :P
[22:53] <imbrandon> heya zul
[22:54] <crimsun> (you'd probably want to poke lamont for it)
[22:54] <imbrandon> Ubulette: yea i liked mutt as far as features but i could ever get the keybindings and folders just the way i liked them
[22:55] <imbrandon> mok0: yea i have no idea, but i'm with crimsun you might have to poke lamont
[22:55] <imbrandon> the hppa buildd's might be having issues
[22:56] <imbrandon> crimsun: btw did you see my email re: flashplugin-nonfree to -devel ? i know youve had intrest in the package in the past
[22:56] <mok0> imbrandon: it builds fine for me both in i386 and amd64. I can't reproduce this error
[22:56] <mok0> who's lamont?
[22:56] <imbrandon> mok0: yea likely a buildd error os somekind, poke lamont durring the week UK time
[22:57] <imbrandon> he is the canonical hppa god
[22:57] <mok0> imbrandon: ok, but package fails on all platforms except i386
[22:57] <Ubulette> imbrandon, you can customize everything, really
[22:58] <crimsun> imbrandon: No.  (I'm /way/ behind on e-mail; there're ~12K in the queue.)
[22:58] <imbrandon> Ubulette: yea i know, but after a few weeks i just couldent get it "quite right"
[22:58] <imbrandon> crimsun: wow
[22:59] <imbrandon> crimsun: basicly were at the stage now where the 2 viable choices imho are , knowingly break konq ( not a good idea ) or force a 60mb download of r48 for gutsy on back
[22:59] <imbrandon> and r115 for hardy forward
[22:59] <somerville32> imbrandon, Have you thought about contacting upstream?
[23:00] <imbrandon> somerville32: yea, but their awnsers is fix konqueror
[23:00] <imbrandon> e.g a sru for konq with untested new svn only code
[23:00] <imbrandon> not cool
[23:01] <imbrandon> infact its only in novel atm , not even upstream
[23:01] <imbrandon> so realy realy new
[23:01] <somerville32> Have we ever asked them to change how they package upstream or permission to distribute?
[23:01] <imbrandon> s/novel/novell , s/novell/suse
[23:01] <zul> bah no one uses konq anyways ;)
[23:01] <persia> zul: Except Kubuntu users by default
[23:02] <crimsun> ok, patching kde is a non-starter
[23:02] <imbrandon> somerville32: we cant
[23:02] <somerville32> imbrandon, we can't ask them?
[23:03] <imbrandon> we have and we cant
[23:03] <imbrandon> they dont grant rights to anyone to do so
[23:03] <crimsun> I agree with Scott's response
[23:04] <zul> persia: elinks would be a better choice for kubuntu users ;)
[23:04] <persia> crimsun: patching KDE for gutsy?
[23:04] <imbrandon> crimsun: i tend to also, but more opinions is good, specialy since i know you've delt with it before
[23:04] <imbrandon> somerville32: sorry to be so short with you, dont mean to be, but yes weve been down that road
[23:05] <crimsun> hmm, not all of Scott's response.  Clarification: test the kde changes in Hardy.  For the currently supported stable releases, go the 60MB route.
[23:05] <imbrandon> right thats whay i thought his response was
[23:05] <crimsun> 115 doesn't fix any security issues and seems to be only a feature-add.
[23:06] <imbrandon> right, x264
[23:06] <imbrandon> and gtk menus
[23:07] <crimsun> anyhoo, that's my fairly useless $0.02.  :-)
[23:07] <imbrandon> and imho even an invasive change to the package to make it grab the 60mb one for a stable release would 1 make us not have to sru more updates on new releases
[23:08] <imbrandon> and would be better than a patch to kde
[23:09] <persia> imbrandon: If you're doing that, why not do the full download for every release, including current development, freezing the version at something considered stable.  Saves trying to detect the system carefully.
[23:09] <imbrandon> and basicly say sorry to those in .au that loose a liver due to isp charges , the cost of using a binary blob
[23:10] <crimsun> man, we really should just have *ubuntu-desktop Conflict flashplugin-nonfree and rip the latter out of hardy.
[23:10] <imbrandon> persia: i would have to check if the r115 ( e.g. current ) is in the archive also, if it is that could be an option
[23:10] <persia> crimsun: Why bother with the conflict: ?
[23:11] <persia> flashplugin-nonfree goes away about 3 months after we stop updating the md5sum anyway.
[23:11] <crimsun> persia: well, pedantically we shouldn't, but it's a total pain to deal with flashplugin-nonfree.
[23:11] <persia> (or rather, becomes completely useless)
[23:11] <imbrandon> really i guess there is the 5th option of group deciding to have it blacklisted ( not to import it from debian ) and remove it from hardy, and go the 60mb route for sru's
[23:12] <persia> crimsun: Sure.  I'm all for archive removal.  I just don't think it also needs a Conflicts:
[23:12]  * persia likes the 5th option, but not being a flashplugin-nonfree user isn't sure that means much
[23:12] <crimsun> firefox's plugin finder wizard handles it ok.  Do Opera, Konqueror, Epiphany, etc. have similar capability?
[23:13] <imbrandon> crimsun: right now r115 breaks everything but firefox anyhow, infact in r115 it specificly looks for the FF UA string
[23:14] <imbrandon> the konq patch part of it spoofs the UA to r115 just because of that
[23:14] <crimsun> how nice.
[23:14] <imbrandon> yea
[23:14] <persia> Epiphany doesn't seem to have that sort of functionality (although it could likely be exposed).
[23:14] <imbrandon> basicly adobe is saying if your not FF or IE, screw you
[23:15] <imbrandon> litterly in code
[23:15] <imbrandon> the new unreleased opera apparently has a patch too, but even opera ( atleaste on linux ) has the same issue
[23:15] <persia> That makes it easy then.  Set up all the other browsers not to work with flashplugin-nonfree, and have firefox use the internal plugin finder.  If anyone complains, point at the Adobe support documentation.
[23:16] <persia> (and blacklist the package)
[23:16] <imbrandon> persia: well thats one issuse, konq automaticly loads FF/mozilla plugins that are installed
[23:16] <imbrandon> from upstream, thats not us, its a konq "feature"
[23:17] <persia> imbrandon: Ah.  And I suppose that Adobe refusing to work with it is insufficient for it to not load.
[23:18] <imbrandon> right
[23:19] <crimsun> ia32-libs seems nasty (just from reading debian/README.build)
[23:25] <imbrandon> heh
[23:28] <imbrandon> gouki: ping
[23:29] <cyberix> imo https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff is quite wtf
[23:29] <RainCT> bug 174123 can be unsubscribed from u-u-s
[23:29] <ubotu> Launchpad bug 174123 in ubuntu-dev-tools "No manpage or --help option for check-sysmbols" [Low,Fix committed] https://launchpad.net/bugs/174123
[23:29] <cyberix> The example is about turning a Debian package into an Ubuntu package?
[23:30] <persia> cyberix: Yep.  That's a lot of what we do.
[23:31] <cyberix> But the page says the example is about changing _one word_ in package description.
[23:31] <cyberix> It says nothing about transpackaging.
[23:32] <persia> cyberix: It's written for someone who generates a first Ubuntu variation from one of the 13,000 Debian source packages in the Ubuntu archive.
[23:32] <crimsun> the principle is creating a suitable patch.
[23:33] <persia> RainCT: absolute paths in .desktop files break themes
[23:33] <crimsun> it's certainly not an "optimal" example [is there one?]; feel free to contribute something "better."
[23:33] <RainCT> persia: where did I put one?
[23:33] <cyberix> persia: K. It might want to state that then.
[23:34] <persia> RainCT: xsensors.  The old value also broke themes, so it's not a regression.
[23:34] <RainCT> wasn't that a menu file?
[23:34]  * RainCT checks the debdiff
[23:34] <persia> RainCT: xsensors-0.50/debian/xsensors.desktop
[23:35] <RainCT> oh, right
[23:37] <RainCT> persia: sorry, debdiff replaced
[23:38] <persia> RainCT: Thanks.
[23:40] <persia> RainCT: It still breaks themes (has an extension), but don't worry about it.  As I said before, it's not a regression.
[23:41] <RainCT> uhm.. I should go to bed lol
[23:41] <totopalma> RainCT, hi :)
[23:42] <RainCT> hey totopalma
[23:56] <persia> RainCT: If you're planning a lot of those, you might consider one bug with many tasks.  That way any discussion can be seen in a single bug log.