[00:11] <__Ali__> i just installed a package i created, nut it doesn't appear in synaptic?
[00:11] <__Ali__> but*
[01:18] <anakron> how do you go to home folder in python
[01:18] <anakron> $HOME
[01:18] <anakron> ~
[01:18] <anakron> or something else
[01:18] <anakron> hi all
[01:21] <Chris`> anakron: Hi, why don;t you test and find out? :)
[01:22] <anakron>  i wsa testing yesterday
[01:22] <anakron> but ill try to find out looking it into other python programs
[01:22] <Chris`> OK good luck
[01:43] <ScottK> anakron: I don't have reference material in front of me, but you ought to be able to access the envirnment and find out what $HOME  using the os module.
[01:43] <anakron> i tried it, but nothing happened
[01:47] <ScottK> I'd ask in #python then.
[02:11] <anakron> HI al
[02:34] <anakron> ping Scottk
[02:34] <anakron> did you ask in #python?
[02:35] <ScottK> anakron: I was suggesting that you ask in #python
[07:43] <etech> do you know if openoffice 3.0.1 will be in bACKPORTS FOR UBUNTU INTREPID?
[07:48] <Laibsch> etech: you can grab it from my ppa even for hardy, my nick is r0lf
[08:03] <etech> Laibsch, yes. there is appa, but i would prefer to install it from the backports if it will appear there
[08:12] <henrik-hw0> ATT: quick question on library management.
[08:12] <henrik-hw0> in the package's .symbol file do i need to list the symbols of plugins as well as the main library?
[08:13] <henrik-hw0> nothing liks directly to the plugins, well except for the main lib of course.
[08:15] <henrik-hw0> plugins are only loaded runtime.
[08:17] <pochu> henrik-hw0: I'd say if plugins are not in $libdir, then no. But I'm don't know well how the symbols stuff works..
[08:18] <henrik-hw0> i guess they are only used for checking for ABI breakage. if that is so then listing plugin symbols is irellevant.
[08:18] <henrik-hw0> plugins go in /usr/lib/librarynameVERSION/
[08:19] <pochu> then I think they shouldn't
[08:20] <henrik-hw0> pochu: thanks. i'll make a note of it on REVU in any case.
[08:34] <henrik-hw0> another question: does it make sense to depend on linux-headers-2.6 instead of linux-headers if the software only runs on 2.6 kernels?
[08:35] <stdin> linux-headers-2.6 doesn't exist
[08:36] <stdin> and Ubuntu only ships 2.6 kernels anyway
[08:37] <henrik-hw0> stdin: dpkg -l linux-headers-2.6
[08:37] <henrik-hw0> leftover?
[08:37] <stdin> $ dpkg -l linux-headers-2.6
[08:37] <stdin> No packages found matching linux-headers-2.6.
[08:37] <henrik-hw0> i see
[08:38] <stdin> apt-cache policy shows no package either
[08:39] <stdin> why does the library need linux-headers anyway?
[08:39] <henrik-hw0> no... another package this time. :)
[08:40] <henrik-hw0> i'm drowning in them. :(
[08:40] <henrik-hw0> stdin: even have multiple versions of the same packages for added joy. :/
[08:42] <stdin> you should probably depend on the specific headers package for a kernel module
[08:42] <stdin> linux-headers-2.6.27-11-generic and linux-headers-2.6.27-11-server
[08:43] <stdin> or linux-headers-2.6.28-6-generic / linux-headers-2.6.28-6-server for jaunty
[08:44] <henrik-hw0> originally i did that, superm1 felt it would only make the package hard to maintain. (kernel header packages change a lot from version to version)
[08:45] <soren> stdin: Erm.. No, you shouldn't.
[08:45] <soren> The resulting binaries should have strict dependencies like that, but certainly not the source packages.
[08:46] <henrik-hw0> not using the module assistant.
[08:47] <henrik-hw0> using dkms meaning deps are hard-coded.
[08:47] <henrik-hw0> the "binary" package is in fact built at install time.
[08:48] <soren> You're completely defeating the purpose of dkms if you make the depencies so strict.
[08:48] <soren> dependencies, I mean.
[08:50] <henrik-hw0> noted. it's a looooooong list. i look forward to shortening it.
[08:50] <soren> Eh?
[08:50] <soren> Which list are we talking about?
[08:51] <henrik-hw0> the list of _specific_ kernel header packages to depend on.
[08:51] <soren> Don't shorten it. Remove it
[08:51] <soren> The only dependency you should have is dkms.
[08:52] <directhex> the entire purpose of dkms being to install the requisite deps & use them to compile a module
[08:53] <henrik-hw0> ah. dkms depends on kernel-headers. good. :)
[08:54] <henrik-hw0> i'll do that then. thank you very much!
[09:01] <_stochastic_> If I'm repackaging a newer version of an already packaged program, is it proper to submit a debdiff to launchpad under the [needs-packaging] bug or submit the newer package to REVU?
[09:06] <directhex> _stochastic_, repackaging from scratch?
[09:07] <_stochastic_> directhex, I'm not sure yet, there were major changes in the upstream version
[09:07] <directhex> generally you should never file a need packaging bug or use revu for things already in the archive
[09:08] <directhex> just submit the updated packaging info in the form of a debdiff to a regular bug (or to debian)
[09:08] <_stochastic_> oh, my mistake, it's a whishlist upgrade bug
[09:08] <_stochastic_> bug #195039
[09:08] <_stochastic_> whoops
[09:08] <_stochastic_> wrong one
[09:09] <_stochastic_> bug #306974
[09:09] <_stochastic_> a debdiff is already attached, Universe sponsors are subscribed but it sits and waits
[09:16] <_stochastic_> directhex, would you mind taking a look at that debdiff, it's a month old; I think it may need some work (that I'm more than happy to do if it does)
[09:18] <directhex> i'm not the right person to ask for C apps
[09:18] <_stochastic_> okay thanks anyway
[09:19] <_stochastic_> any idea who would be the right person to pester?
[09:32] <hyperair> _stochastic_: what seems to be the issue?
[09:33] <_stochastic_> hyperair, could you take a glance at the debdiff on bug #306974 (I'd really like to work on ironing out any issues before the Jaunty deadline)
[09:34] <hyperair> _stochastic_: i'm not a MOTU, but yeah sure =p
[09:34] <hyperair> which also means i can't give an ACK
[09:34] <hyperair> but it looks like it's fix commited
[09:34] <hyperair> which means it should be on its way, no?
[09:35] <_stochastic_> I just switched it to that because there's a debdiff attached, is this wrong?
[09:35] <hyperair> wrong.
[09:35] <_stochastic_> whoops
[09:35] <hyperair> fix commited means it's been uploaded already
[09:35] <hyperair> switch it back
[09:35] <_stochastic_> okay, sorry
[09:35] <hyperair> also i don't see a debdiff
[09:35] <hyperair> a debian diff.gz doesn't count. a debdiff is a difference between two debian packages
[09:37] <hyperair> if you like, i could help you clean up that bug report, which should speed up things, i guess
[09:37] <_stochastic_> a debian diff won't solve the bug?  I'd need to upload a debdiff?
[09:37] <_stochastic_> sure
[09:37] <Laney> NOOOOO
[09:38] <hyperair> yeah a debdiff's needed
[09:38] <hyperair> Laney: uh what?
[09:38] <Laney> diff.gz is right
[09:38] <hyperair> it is?
[09:38] <iulian> Please attach diff.gz if it's a new upstream version.
[09:38] <Laney> for a 0ubuntu1 version
[09:38] <hyperair> but it should be a merge request, no?
[09:39] <iulian> _stochastic_: The version number is incorrect, it should be: 0.4.2-0ubuntu1
[09:39] <hyperair> oh you mean it isn't in debian?
[09:39] <iulian> hyperair: The new version, no.
[09:39] <hyperair> aah
[09:39] <hyperair> i see
[09:39] <hyperair> whoops, my bad then
[09:40] <iulian> As far as I can see, the Debian maintainer doesn't want to upload a new version until Lenny is released.
[09:40] <hyperair> wah
[09:41] <hyperair> is there anywhere i can read about the procedure for these needs-upgrade bugs?
[09:42] <iulian> Hmm, not sure.  I think we have a wiki page explaining this.
[09:42] <iulian> One second.
[09:42] <hyperair> a quick google search doesn't seem to show
[09:43] <iulian> I found https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate but this page shows how to upgrade a package.
[09:43] <iulian> We usually just attch the new diff.gz if it's a new upstream version.
[09:43] <iulian> s/attc/attach
[09:44] <_stochastic_> iulian, does the deb maintainer's unwillingness to release an upstream until Lenny prevent MOTU from releasing an upstream?  I changed the version number and uploaded the changed diff.gz
[09:45] <_stochastic_> 0.3.2 is so buggy it's unusable
[09:47] <directhex> prevent? no
[09:47] <directhex> but it means procedure needs to be followed
[09:47] <directhex> especially the version number
[09:47] <iulian> _stochastic_: We can still upload new upstream versions to Ubuntu, even though the Debian maintainer doesn't want to upload it to Debian.
[09:47] <_stochastic_> version number is fixed
[09:48] <iulian> _stochastic_: OK, I will have a closer look at it.
[09:49] <_stochastic_> ah, the version number inside the changelog does need some fixing too
[09:50] <iulian> _stochastic_: Yeah, fix the version from the debian/changelog.  The name of the file doesn't matter.
[09:51] <iulian> _stochastic_: Please see that wiki page I pasted above to see how to upgrade a package properly.
[09:52] <_stochastic_> that debian diff is not of my origin, I'm just trying to push for this to get fixed, is it best to start over from scratch?
[09:54] <iulian> _stochastic_: OK, if you don't want to work on this, I will comment on the bug.  I see that Dinxter is pretty active.
[09:54] <iulian> _stochastic_: The process is not hard, it's explained briefly in that wiki page.
[09:55] <_stochastic_> iulian, I do want to work on this, okay, I'll gladly work on this
[09:55] <_stochastic_> or comment on the bug too
[09:55] <iulian> _stochastic_: Excellent, please let me know if you encounter problems.
[09:56] <iulian> OK, I will in a moment.
[10:04] <iulian> Hiya DktrKranz.
[10:05] <iulian> _stochastic_: Commented.
[10:05] <DktrKranz> hey iulian
[10:05] <DktrKranz> iulian, will you be at MOTU release meeting today?
[10:05] <iulian> DktrKranz: Yes.
[10:05] <DktrKranz> cool
[10:06]  * DktrKranz needs to figure out how to fix haskell-happs-state FTBFS
[10:10] <directhex> ew, haskell
[10:13] <_stochastic_> iulian, I've made the version change and re-uploaded (sorry about that dumb upload earlier)
[10:15] <_stochastic_> gah, TobyDox beat me to it!
[10:19] <iulian> _stochastic_: I'm having a look at it right now.
[10:21] <Laney> yay haskell
[10:23] <Laney> DktrKranz: I bet it wasn't rebuilt when hslogger was updated so nobody picked this up earlier
[10:24] <Laney> it seems to be looking for a particular version
[10:26] <DktrKranz> Laney, exactly. I need to determine if there is a chain to follow
[10:26] <Laney> somebody restarted happs development recently btw, yay!
[10:27] <Laney> (happstack)
[10:27] <DktrKranz> someone must love us, we removed gnat-4.* compilers without the need for a transition \o/
[10:31] <Laney> http://happstack.com/faq.html
[10:31] <Laney> "Why did you put all the packages in one repository? We are going to reorganize code amongst the packages and perhaps even deprecate some. Having one repository will drastically reduce the administrative overhead of this process." <3
[10:33] <DktrKranz> "should one of us get hit by a bus" <- we need more volunteers to push in the streets
[10:35] <DktrKranz> GOT IT!
[10:35] <Laney> do share
[10:36] <DktrKranz> I missed libghc6-happs-data rebuild
[10:36] <DktrKranz> I'm pushin it right now
[10:37] <DktrKranz> I'll do another test, just to make sure
[10:39] <Laney> these haskell transitions are a pain
[10:39] <DktrKranz> indeed
[10:40]  * DktrKranz wonders if we managed everything yet
[10:41] <DktrKranz> it's not that easy to see if packages have been rebuilt
[10:42] <DktrKranz> anyway, now it's should just a matter of rebuilds
[10:42] <DktrKranz> so, we could eventually SRU packages
[10:42] <DktrKranz> given that there are unmetdeps no more
[11:30] <pkt> Any autotools experts? I have a package (tulip) where after autoreconf, host_os detection is broken
[11:49] <sistpoty|work> hi folks
[11:50] <iulian> Hey sistpoty.
[11:50] <sistpoty|work> hi iulian
[11:55] <DktrKranz> jpds, I plan to do an emergency upload (0.61 ?) of ubuntu-dev-tools to incorporate changes in http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/315, several scripts are broken right now. Sounds reasonable for you?
[12:30] <jpds> DktrKranz: Sure, hit it.
[12:30] <DktrKranz> jpds, gracias
[12:31]  * jpds goes to find out why they broke.
[12:31] <jpds> Ah,I tought packages= went recursively.
[12:33] <DktrKranz> no
[12:33] <DktrKranz> I faced a similar issues
[12:35] <jpds> DktrKranz: You might want to LP: #324749 the upload.
[12:37] <DktrKranz> jpds, gah! too late :(
[12:37]  * jpds closes manually.
[12:37] <DktrKranz> I'll close at hand
[12:50] <hefe_bia> Hi! I got a package through REVU but it was rejected from NEW because it slipped through that upstream had changed its license back to GPL-2 (from 3). I have now corrected copyright and re-uploaded to REVU (http://revu.ubuntuwire.com/details.py?package=gebabbel). Maybe somebody can have a look?
[12:57] <DktrKranz> hefe_bia, if you changed only copyright line, I guess it's safe to reupload without going through the whole process. Who uploaded it?
[12:58] <hefe_bia> DktrKranz: persia uploaded. In REVU you can debdiff to the previous version to verify that I only have changed GPL version.
[13:00] <DktrKranz> hefe_bia, if persia couldn't manage another upload, I can do it if he or mok0 don't mind
[13:09] <hefe_bia> DktrKranz: They don't seem to be around. So if it is ok not to go through the whole process again regarding such a minor change, it might be better I'll ask persia when he's back online.
[13:10] <hefe_bia> Just would be happy to get this one done before FF ;)
[13:10] <Laney> you can usually just fix and upload
[13:11] <hefe_bia> Laney: I don't have upload rights.
[13:12] <Laney> read [get somebody else to] upload
[13:14] <hefe_bia> Laney: Wouldn't I risk that persia accidentally uploads it again? I don't know the process that well.
[13:14] <Laney> hefe_bia: I mean that you don't have to go through revu again, not speaking for who should do the upload
[13:16] <hefe_bia> Laney: ok, now I understand ;) I think it's best to wait until persia is around and ask him to reupload.
[13:35] <slytherin> NCommander: pm?
[13:35] <NCommander> slytherin, sure
[13:38] <ScottK> NCommander: Any word on soprano?
[13:39] <NCommander> ScottK, huh?
[13:39]  * NCommander is currently putting about four or five fires at once
[13:39] <slytherin> is packaginga software considered as 'derived software'?
[13:39] <ScottK> NCommander: Remember a coupld of days ago you said you'd look into why soprano wasn't installable on armel?
[13:39] <ScottK> NCommander: It's currently blocking KDE builds.
[13:39] <NCommander> Ok, let me do that
[13:40] <ScottK> Thanks.
[13:40] <NCommander> I'm sorry, I'm dealing with OMG WE"RE TWO WEEKS FROM FEATURE FREEZE time
[13:40] <ScottK> slytherin: People argue about that.  I don't think there's a clear answer.
[13:41] <slytherin> ScottK: I was reading this license - http://jcharts.sourceforge.net/license.html Condition 3 is the one I am concerned about.
[13:41] <ScottK> slytherin: That should be fine.
[13:42] <slytherin> ScottK: I guess I am still going to mail the upstream author.
[13:42] <ScottK> slytherin: Couldn't hurt, but that's very close to the advertising clause in the old 4 clause BSD license which is considered (hold your nose) DFSG free.
[13:43] <slytherin> ScottK: in worst case the package would end up in multiverse, right?
[13:44] <ScottK> I think so.
[13:44] <directhex> anyone reckon ironscheme is worth packaging?
[13:45] <sistpoty|work> directhex: I assume we have enough scheme interpreters already... or would that help mono/.gnu in some regards?
[13:46] <sistpoty|work> directhex: otoh, I'm not aware of scheme compilers (at least not working ones)... but that knowledge is from two years back ;)
[13:46] <directhex> sistpoty|work, well, it'd allow writing scheme apps w/ access to all mono libs. i don't know if anyone cares though, it's not as if scheme's really all that popular outside research departments and gimp plugins
[13:47] <sistpoty|work> directhex: ah, I see... maybe you could try to google for scheme apps that use mono libs? and see if there exits more than only a handful?
[13:49] <directhex> sistpoty|work, i don't know whether people really use things like ironscheme or ironlisp or even ironpython & ikvm outside "tinkering" status. question is, is it a "build it and they will come" or a "yet another junk package"
[13:52] <sistpoty|work> directhex: hm... that's a good question... and I can't really say I'd know the answer
[13:53] <directhex> sistpoty|work, i would like as many iron* as possible, to allow people to use "any" language yet get all the benefits of mono... but the gig question is how much time it's worth.
[13:54] <directhex> sistpoty|work, ironclad is also interesting, as it allows use of compiled cpython in ironpython
[14:13] <anakron> hi all
[14:29] <aboudreault> hi ppl.
[14:30] <aboudreault> i have a small question about the changelog file...
[14:32] <aboudreault> If i take a package from debian, (ie package X version 1.4.0) and i want to build the package for ubuntu. Even if the version that i want to build is the same as the debian package, should i create another entry with "debchange" ?
[14:33] <mok0> aboudreault: make it X_1.4.0-0ubuntu1 (assuming that the Debian version is 1.3.*)
[14:33] <mok0> aboudreault: I misread your question, sorry
[14:34] <aboudreault> oh... u r right... in any case... i must add "ubuntu1"
[14:34] <mok0> aboudreault: if the package is the same, you should not change anything, just build the package
[14:34] <mok0> aboudreault: if you fix something, append "ubuntu1"
[14:35] <dolanor> Hello
[14:35] <dolanor> needs a MOTU to advocate the fsniper package :) : http://revu.ubuntuwire.com/details.py?package=fsniper
[14:35] <aboudreault> ok, only if i fix something i'd add "ubuntu1". good
[14:35] <aboudreault> thanks mok0.
[14:37] <aboudreault> mok0: sorry, last question.. this is the line of the debian package: X (1.6.0-1) experimental; urgency=low
[14:38] <mok0> aboudreault: ok
[14:38] <aboudreault> Is it ok if i let the "experimental" ?
[14:38] <aboudreault> Is it very important ?
[14:38] <mok0> aboudreault: it should be jaunty or whatever release you are compiling it for
[14:39] <mok0> aboudreault: but you don't need to touch it if you don't make modifications
[14:39] <mok0> aboudreault: I keep forgetting that you aren't doing modification
[14:40] <aboudreault> :)
[14:41] <aboudreault> that's great. i'll finish this package and upload it to launchpad.
[14:48] <aboudreault> mok0: arg i forgot this problem... gpg: skipped "Francesco Paolo Lovergine <frankie@debian.org>": secret key not available
[14:48] <aboudreault> i must sign the package for launchpad
[14:49] <pochu> aboudreault: dpkg-buildpackage -k$keyid -S
[14:49] <pochu> where $keyid = something like 0xAE498D18
[14:50] <aboudreault> oh, i take this in note too. thanks a lot.
[14:50] <pochu> mok0: hey, just in case I didn't explain myself well, my mail wasn't personal, it's just that I think the takeover should had been public, but I'm happy with you being the new liason ;)
[14:55] <mok0> pochu: then you shouldn't have written the email
[14:56] <mok0> pochu: it doesn't make sense to write and say "Hey I'm angry about not being asked but I would have said no anyway"
[14:57] <slytherin> aboudreault: what are you trying to do exactly?
[14:59] <mok0> pochu: I know it wasn't personal :-)
[14:59] <ScottK> mok0: It won't suprise you to find I disagree.  I'd put it as you don't have the job until you are hired.  We like hiring you, we'd just like to actually do that before you do the job.
[15:00] <mok0> ScottK, yeah... except... we had already started working
[15:00] <mok0> ScottK, so there was no way I could pretend it was not a de-facto thing
[15:01] <ScottK> Understand.
[15:02] <mok0> Anyway, I need to get hold of bigjools and tell him not to consider the MOTU priorities
[15:02] <mok0> I think it
[15:02] <mok0> is too late
[15:03] <ScottK> It's a wiki.  You can just edit it.
[15:04] <mok0> ScottK, yes, but I am somewhat wary to destroy the evidence, so to speak
[15:04] <mok0> I can put a note there though
[15:05] <ScottK> mok0: If it's a proper wiki, it'll have versioning, so the history is there.
[15:05] <aboudreault> pochu: Am i wrond if i say that i should always use "debuild" instead of "dpkg-buildpackage" if i always use cowbuilder to build my packages ?
[15:05] <mok0> Right, but if ppl come along to read the ML in the next few days, they will want to be able to see what all the fuzz was about
[15:06] <pochu> aboudreault: no idea, never used cowbuilder
[15:06] <pochu> but I think debuild is just a wrapper around dpkg-buildpackage
[15:06] <aboudreault> cowbuilder is just a wrapper for pbuilder.
[15:07] <aboudreault> ha.
[15:07] <ScottK> I'd say then make a reply to the ML and say what you've done.
[15:09] <hyperair> asac: ping
[15:13] <bddebian> Heya gang
[15:14] <sistpoty|work> hi bddebian
[15:15] <bddebian> Hi sistpoty|work
[15:17] <iulian> Heya bddebian.
[15:19] <bddebian> Hi iulian
[15:30] <jdong> lovely.
[15:30] <jdong> Brasero on x86_64 just told me that it burned "381"MB on my 4.3GiB ISO.
[15:30] <jdong> sounds like someone didn't put enough longs on that variable name ;-)
[15:36] <ScottK> jdong: Are you OK with the backports improvement spec?
[15:36] <jdong> ScottK: sorry I'm out of touch with the outside world; can you link me to it and I'll read it over?
[15:36] <ScottK> Just a moment.
[15:37] <jdong> k, I need to run to class; I'll check my scrollback for the link
[15:37] <geser> Hi bddebian
[15:40] <ScottK> jdong: https://blueprints.launchpad.net/intrepid-backports/+spec/selective-backport-support
[15:52] <bddebian> Heya geser
[16:56] <henrik-hw0> RALink WiFi drivers now fixed up and tested. Any eager souls online?
[17:00] <jpds> AndrewGee: osm-gps-map accepted into jaunty.
[17:05] <jlc> henrik-hw0: ping
[17:05] <henrik-hw0> jlc: hi.
[17:06] <jlc> hello
[17:06] <jlc> do you have a driver for rt2860 for  jaunty-mid-lpia.img?
[17:07] <henrik-hw0> i have a driver for rt2860 but i haven't tested it on hardware nor LPIA.
[17:07] <jlc> ok, I can probably test it then
[17:07] <henrik-hw0> jlc: it would be nice to get some feedback if it works on that configuration.
[17:08] <jlc> is it i386 and not lpia?
[17:08] <henrik-hw0> jlc: it's an architecture independent package.
[17:08] <jlc> dkms?
[17:08] <henrik-hw0> jlc: yup.
[17:08] <jlc> k
[17:09] <jlc> were is it at
[17:09] <jlc> I'll install the lpia version of jaunty and i386 and test it out
[17:09] <henrik-hw0> jlc: http://revu.ubuntuwire.com/details.py?package=rt2860-linux-sta
[17:12] <jlc> henrik-hw0: is there a deb for it or just source?
[17:13] <henrik-hw0> jlc: if you wait i could upload it to PPA.
[17:13] <jlc> henrik-hw0: I can wait, downloading daily build iso's now
[17:14] <jlc> brb, need to make some lunch
[17:16] <jdong> ScottK: I like the general idea and behavior described in the spec, though I'm not 100% confident that pinning is the method we should settle upon for effecting it
[17:16] <jdong> ScottK: I'd like to look more into mvo's "NotAutomatic" flag
[17:17] <ScottK> jdong: Yeah, well I was going to just leave that as an implementation detail to mvo.
[17:17] <ScottK> If you're OK with the concept, I want to push to get it approved.
[17:17] <jdong> ScottK: gotcha; but yea, I love the concept
[17:26] <loic-m> I'm dealing  with a package that has Ubuntu modifications for some translations (2 languages)
[17:26] <loic-m> Upstream has released many moer versions of the program, so their new .po files are different
[17:26] <loic-m> What's the method to deal with that?
[17:27] <loic-m> Can we drop the ubutnu modifications (strings translated differently)?
[17:53]  * sistpoty|work calls it a day and heads home... cya
[18:16] <asomething> I know about http://qa.ubuntuwire.com/uehs/  but is there anything that will automatically email me when a new upstream package is released for Ubuntu? Debian PTS does this for stuff I maintain there..
[18:28] <quadrispro> hi superm1! I've added a comment here http://revu.ubuntuwire.com/details.py?package=w-scan
[18:28] <quadrispro> superm1: let me know! ;)
[18:29] <superm1> quadrispro, yeah lets wait until a few days before FF.  if it gets into debian buy then we'll sync it in, if not we'll upload something like UPSTREAM-DEBIAN~ubuntu1
[18:29] <superm1> so it gets synced at jaunty+1 automagically
[18:29] <quadrispro> superm1: perfect!
[18:32] <ScottK> superm1: If you want it to be automatic make it something like -0build1
[18:33] <superm1> ScottK, can you expand that to a real version number.  Lets say debian had 0.1-1, you mean 0.1-0build1 ?
[18:33] <ScottK> Yes
[18:34] <Laney> Is it just "ubuntu" that blocks autosyncing?
[18:34] <ScottK> 0.1-1~ubuntu1 you'd need to requestsync to get it synced
[18:34] <ScottK> I think it's the other way around that build is special and doesn't block it.
[18:34] <Laney> ah
[18:34] <Laney> I was going to suggest 0debian1, but never mind
[18:35] <superm1> wouldn't 0.1-1~build1 be more representative of the fact that it's -1 from debian though?
[18:35] <ScottK> I suppose.
[18:35] <superm1> or maybe this is all just irrelevant
[18:35] <ScottK> I actually think it's better to -0ubuntu1 and then requestsync when the time comes
[18:40] <RainCT> (btw, if someone here wants a bitesize packaging task, I've got one)
[18:45] <jpds> What should we do with bugs of packages which have been removed from the archives? Mark them as Won't fix?
[18:47] <JontheEchidna> I would think that we could won't fix non-packaging bugs
[18:48] <JontheEchidna> packaging bugs could probably only be won't fixed if the bug either don't apply to packages in currently supported series
[18:48] <jpds> JontheEchidna: The package was in the archive when the bug was filed but has since been removed.
[18:48] <JontheEchidna> or if the package is no longer in any currently supported series
[18:48] <pochu> jpds: yeah, either wontfix or invalid
[18:50] <jpds> pochu: vale.
[19:00] <ScottK> I'd say wontfix if not sru worthy and the package is still in a supported release.  Leave it open if potentially SRU worth.  Invalid if it's not in a supported release.
[19:19] <EagleScreen> hello i have a small problem, when i run dch -i or -e to edit the changelog, my email address appears wrong in the changelog
[19:19] <EagleScreen> DEBMAIL variable has the right value
[19:21] <oojah_> EagleScreen: DEBEMAIL
[19:21] <oojah_> (note the extra E)
[19:22] <EagleScreen> oh thanks
[19:23] <oojah_> no probs :)
[19:26] <ScottK> EagleScreen: Also minus points for asking the same question in multiple channels.
[19:27] <EagleScreen> some persons who can help me are in a channel but not in the other..
[19:28] <EagleScreen> is it bad to ask something in all related channels?
[19:34] <maxb> EagleScreen: In much the same way as cross-posting across multiple mailing lists of a project, it's discouraged
[19:34] <Amaranth> EagleScreen: Yes, you should ask in one channel, wait to see if you get a response, then maybe try somewhere else.
[19:35] <rexbron> Does anyone have any suggestions for working around non-http accessable directories in tarball urls?
[19:35] <rexbron> In my case, http://ffado.org/files/<tarball> is accessable
[19:35] <rexbron> but http://ffado.org/files/ 404s
[19:36] <piratenaapje> rexbron: Is there a page that links to the latest tarball?
[19:36] <piratenaapje> rexbron: Like the home page?
[19:36] <rexbron> there is the downloads page that links to the tarball
[19:37] <piratenaapje> you could try something like
[19:37] <rexbron> but that  url changes with each release
[19:37] <rexbron> and kind of defeats the purpose if uscan imo
[19:37] <rexbron> of rather
[19:37] <piratenaapje> rexbron: in your debian/watch file: http://downloadspage referral link
[19:38] <piratenaapje> where referral link is the link in the html code
[19:38] <rexbron> I'll take a look
[19:38] <piratenaapje> rexbron: An actual example I use: version=3
[19:38] <piratenaapje> https://www.getdropbox.com/downloading?os=lnx /download\?dl=packages/nautilus-dropbox-(.*)\.tar\.bz2
[19:38] <EagleScreen> yes, you have reason, i asked very soon in the other channels, i must be more patient, sorry, i will try to do not do this again
[19:39] <RainCT> urgh.. Number 1 on the Launchpad 3.0 list should be making it faster
[19:39] <ScottK> +1 for RainCT
[19:42]  * JontheEchidna doesn't like the web interface for copying packages in ppas
[19:42] <JontheEchidna> but I guess that's soyuz not launchpad?
[20:08] <ScottK> Soyuz is part of Launchpad.
[20:08] <ScottK> For Soyuz though I think stuff like don't FTBFS if a build-dep is uninstallable, just dep wait is a lot more important.
[20:39] <pochu> or being able to sync packages from Debian without needing an archive admin
[20:47] <vadi2> Hi - how to make a window that popups up when a user is installing a package to tell them something important?
[21:23] <mok0> vadi2:  look at debconf
[21:28] <POX> vadi2: ... or via debian/NEWS (see `dch --news` and f.e. apt-listchanges package)
[21:28] <ScottK> Debconf is for questions, not informing.
[21:28] <vadi2> hm
[21:28] <vadi2> and does debian/news get shown to people?
[21:29] <vadi2> I think what I was looking for is "update-notifier", but it is hard to figure out
[21:29] <maxb> vadi2: It depends.... how critical is the information?
[21:29] <vadi2> quite
[21:29] <vadi2> the program got renamed
[21:29] <vadi2> need to inform them, or they think it dissapeared
[21:30] <maxb> Hm. I'm not sure that would normally be proactively notified
[21:30] <dtchen> it shouldn't be, really
[21:30] <ScottK> Generally users don't get notified of such things.  It just happens.
[21:30] <vadi2> So if they keep updating from our repository, they won't have a way of telling
[21:30] <dtchen> at most, provide a migration path via a symlink (if necessary)
[21:31] <vadi2> the logo, program name are changed
[21:31] <dtchen> err, did the package name or the binary executable name change?
[21:31] <vadi2> both did
[21:31] <ScottK> Turn the old package name into a dummy package that depends on the new one.
[21:31] <dtchen> well, the former is simple: provide a dummy...
[21:31] <vadi2> That's what we did, so they are able to upgrade to the rename
[21:32] <vadi2> They can still miss though imho, so I'd like a notification
[21:32] <dtchen> you could also make said dummy package provide a symlink in /usr/bin if you're really concerned
[21:32] <vadi2> ?
[21:32] <vadi2> This is a graphical app
[21:33] <dtchen> with a menu entry?
[21:33] <vadi2> When they go to the usual applications - accessories place, it will not be there
[21:33] <vadi2> right
[21:33] <vadi2> another name with another logo will be there
[21:33] <dtchen> if it has a menu entry, why would you want the user to be concerned?
[21:33] <vadi2> because the old one will be gone
[21:33] <dtchen> just document in the change prominently in debian/control:^Description
[21:34] <vadi2> eh?
[21:34] <dtchen> "This package replaces oldpackage and provides a new blahblahblah in Applications> blahblahblah"
[21:35] <dtchen> FWIW, using updatenotifier
[21:35] <vadi2> They might miss that during the upgrade though
[21:35] <vadi2> I for one don't look at all of the packages that are being upgraded when there's a bunch :\
[21:35] <dtchen> sure, but keep in mind that many users will ignore update-notifier's notices
[21:35] <vadi2> that too, but at least its a better change
[21:35] <vadi2> *chance
[21:35] <vadi2> it gives a tooltip and whatnot
[21:36] <dtchen> well, it's quite straightforward; see /usr/share/doc/update-notifier/HOOKS
[21:36] <vadi2> aha :)
[21:37] <vadi2> I don't have such a file :(
[21:37] <vadi2> only /usr/share/doc/update-notifier/ and /usr/share/doc/update-notifier-common/
[21:38] <dtchen> if you need examples, see libasound2.p{ostinst,rerm} in the alsa-lib source package
[21:40] <vadi2> alsa-utils? alsa-lib doesn't exist
[21:40] <dtchen> alsa-lib is the name of the *source* package
[21:40] <dtchen> also, HOOKS is viewable at http://package-import.ubuntu.com/u/update-notifier/jaunty/annotate/head%3A/HOOKS
[21:42] <vadi2> thank you
[21:53] <khashayar> Anyone interested in revuing http://revu.ubuntuwire.com/details.py?package=rtirq
[21:54] <khashayar> It's a very tiny package, easy to review :-)
[22:16] <AndrewGee> Whoops. I was looking through the needs-packaging bugs. Found one unassigned, so decided to work on it. Just found someone already started packaging it on REVU, but didn't assign the bug. I've uploaded on top of them. What should I do?
[22:16] <dtchen> combine the efforts
[22:45] <__Ali__> how can you ask Build-Depends to go for 4.2 =< gcc < 4.3?
[22:53] <pochu> __Ali__: Build-Depends: gcc-4.2 ?
[22:53] <__Ali__> is it the same as gcc (= 4.2)?
[22:55] <__Ali__> i guess not, thanks!
[22:58] <directhex> ubuntu is capable of having multiple parallel-installed gcc versions
[22:58] <directhex> each has its own package and own command name
[22:58] <ScottK> Put it in bulid-dep twice.
[22:59] <ScottK> True.
[22:59] <directhex> gcc-4.2 contains gcc-4.2
[22:59] <ScottK> build-dep on the versioned package should do it.
[23:00] <directhex> gcc-defaults is the source package whose "gcc" package contains the current ubuntu default and the "gcc" symlink
[23:45] <zMoo> hi
[23:45] <zMoo> when we upload a package using dput
[23:46] <zMoo> can we see this package in revu immediatly?
[23:47] <zMoo> I can not see my package
[23:47] <zMoo> is it normal?
[23:48] <maxb> It's not entirely immediate
[23:49] <zMoo> I see
[23:49] <maxb> Give it 5 minutes, if it's still not there, then come back here if it hasn't shown up
[23:49] <zMoo> it was 10-15 mintues ago
[23:52] <maxb> Say what the package name is, then, so if a REVU admin looks at this channel, they know what to look for
[23:53] <zMoo> the package is called swac-play
[23:56] <zMoo> "A new package has been accepted into REVU: swac-play" OK
[23:57] <zMoo> I'll wait 5 minutes
[23:58] <zMoo> the package is now in the list of packages that "Needs Review"
[23:58] <zMoo> \o/
[23:58] <zMoo> great
[23:58] <zMoo> I can now go sleep
[23:59] <zMoo> thank you maxb