[02:42] <MTecknology> can you have make-kpkg build something that you can push to a ppa?
[07:25] <am_> hi guys, i am trying to build a package with dpkg-buildpackage -rfakeroot and i keep getting the error :dpkg-deb: control directory has bad permissions 655
[07:25] <am_> i have tried setting the permissions of debian/control  manually to 755 but it still gives the warning
[07:26] <am_> i also have dh_fixperms in my debian/rules
[07:26] <G> am_: check the perms on 'debian/'
[07:30] <am_> G 755 on debian/
[07:30] <am_> drwxr-xr-x  4 am am  4096 2010-05-23 16:00 debian
[14:27] <tumbleweed> anyone know of any current gs issues in maverick? This won't build. http://stefanor.uctleg.net/tmp/albatross/
[15:07] <am_> hi guys, i have my code in git, and have a separate branch for the debian files needed for packaging
[15:10] <am_> is there some way that i can tell the build system / lintian to ignore the .git file and just not include it
[15:31] <geser> tumbleweed: do you have an error message from a build?
[15:34] <geser> am_: see the -i / -I option from dpkg-source: debuild -I.git and/or -i.git should hopefully do it
[16:19] <tumbleweed> geser: http://paste.ubuntu.com/438372/
[16:27] <arand> Anyone got a minute to sponsor hardy..lucid-proposed in Bug #581331 ?
[16:27] <geser> tumbleweed: I don't know of any gs issues and ghostscript in maverick is the same as in lucid-updates
[16:28] <tumbleweed> geser: hmm. It builds fine on sid, and I swear I tested that patch on maverick a few days ago
[16:28] <tumbleweed> that patch being a patch unrelated to the gs bug, which is the reason I'm building it
[16:30] <fabrice_sp> tumbleweed, I've just rejected ap ackage that FTBFS with the same error as the one you're having
[16:30] <fabrice_sp> so it seems some error in gs
[16:30] <geser> gs got update in lucid-updates and maverick ten days ago, can you check if it also happens with the gs from original lucid? perhaps it's a regression from the SRU
[16:37] <tumbleweed> ok, it was a gsfonts upload 3 days ago
[16:43] <fabrice_sp> tumbleweed, does that mean that actual version of gsfonts in maverick is buggy?
[16:43] <geser> fabrice_sp: most likely
[16:43] <tumbleweed> fabrice_sp: still trying to work out what's going on
[16:43] <tumbleweed> if I downgrade then upgrade in my pubilder, it still builds
[16:43] <tumbleweed> so, something to do with font registration (which is what that upload changed)
[16:44] <geser> the changelog for gsfonts mentions Debian bug 582113 which mentions a patch which needs to get applied to gs which maverick is missing (not update-gsfontmap)
[16:45] <geser> tumbleweed: if you have time, can you check if applying the patch from Debian bug 582110 fixes gs in maverick again?
[16:45] <tumbleweed> oh, yes, missed that
[16:45] <tumbleweed> geser: will do
[18:30] <cpscotti> Hey, anyone there to help me finishing a SRU? I've already did most of what is said in https://wiki.ubuntu.com/StableReleaseUpdates but I'm not exactly sure about some points..
[18:37] <a|wen> cpscotti: which bug are you preparing the SRU in?
[18:38] <cpscotti> a|wen:  579747
[18:38]  * ScottK waves to a|wen.
[18:38] <cpscotti> a|wen: 480772
[18:41] <a|wen> hi ScottK!
[18:41]  * a|wen knows he has been a bit away lately ... busy with thesis :)
[18:44] <a|wen> cpscotti: the first or the second one is teh right one?
[18:44] <cpscotti> well, the first one is the actual bug. But I fixed the bug upstream
[18:45] <cpscotti> and then another guy saw it (via debian/watch) and issued the fix on the second bug #
[18:45] <ari-tczew> cpsscotti: please write: bug ####number
[18:45] <ari-tczew> just like that: bug 579747
[18:46] <cpscotti> oh.. thanks!
[18:46] <cpscotti> got it
[18:46]  * Laney thinks that mk-sbuild installs too much stuff in the base chroot
[18:46] <ari-tczew> Laney my friend, nice to meet you
[18:46] <a|wen> cpscotti: so you want to update to a new upstream release in an SRU?
[18:46] <cpscotti> a|wen: so.. the problem is that I shouldn't have fixed it upstream?
[18:46] <Laney> hello
[18:47] <cpscotti> a|wen: the new upstream version ONLY adds this bug fix
[18:47] <ari-tczew> Laney: how many security fixes have you done?
[18:47] <cpscotti> and the package is unusable in lucid (resulting from incompatibility with another package that was changed for lucid.)
[18:48] <ari-tczew> cpscotti: what the bug is considering to SRU?
[18:49] <Laney> I don't know, and I don't really want to have this conversation, sorry
[18:49] <fabrice_sp> ari-tczew, what is the point of asking that?
[18:49] <a|wen> cpscotti: then it should be possible to do ... first you need to write explicitly (document from changelog) that this is the only fix; note down that the package has no rdepends (i suppose it doesn't); and a package should be prepared with the version number 1.1-0ubuntu0.1 targeted at lucid-proposed
[18:50] <cpscotti> ok, after doing that, how can I upload it?
[18:50] <ari-tczew> Laney: full of professionalism
[18:50] <a|wen> cpscotti: another thing; you should not assign the bug to ubuntu-sru (that is forbidden), you should only subscribe them, when the SRU is ready
[18:50] <cpscotti> a|wen:  ah.. oh.. well.. I've been trying many (probably forbidden) stuff..
[18:51] <cpscotti> a|wen: last thing, where to upload that ubuntu0.1 version?
[18:51] <a|wen> cpscotti: if you have upload rights, you can upload it to the proposed queue ... if not, attach it to the bug
[18:52] <ari-tczew> fabrice_sp: because I'd like to know about it. I want to know how many security fixes have done this MOTU. I'm thirsty of this knowledge.
[18:52] <fabrice_sp> ari-tczew, it's not a matter of quantity. It' a matter of quality
[18:52] <a|wen> cpscotti: also you need to update the description of the bug in the beginning, and write a test-case of how to reproduce the error and how to check it is fixed with the new version
[18:52] <cpscotti> a|wen: ok.. so then I'll attach it to the bug 480772 ?  right?
[18:54] <a|wen> cpscotti: you can choose any of the two bugs ... in bug 579747 you have already nominated for lucid like you should
[18:55] <cpscotti> a|wen: that version that was already submitted to maverick doesn't count?
[18:55] <debfx> could someone please upload this lucid SRU or at least open the task for lucid so it appears on the sponsoring page: bug #573591
[18:55] <a|wen> cpscotti: count as?
[18:55] <cpscotti> the upload for lucid
[18:56] <ari-tczew> fabrice_sp: yea, that's right, that's right! but he doesn't understand, that I prefer to fixing security issues instead of FTBFS. so as I can say that he can't be a MOTU because he doesn't fixing security issues. Analogous situation.
[18:56] <cpscotti> well.. ok.. I get it
[18:56] <cpscotti> a|wen:  the difference will be de "ubuntu0.1", right?
[18:57] <a|wen> cpscotti: exactly
[18:57] <a|wen> debfx: do you have a minimal test-case to add to the bug description?
[18:58] <a|wen> debfx: nominated for lucid
[18:58] <fabrice_sp> ari-tczew, I don't see the point of 'attacking' laney. Being a MOTU is also about community integration and trust. If you sems to be aggressive, you will have problems to have good comments to your application. But anyway: this is off-topic...
[18:59] <fabrice_sp> let's focus on fixing lucid and making maverick a good release
[19:00] <debfx> a|wen: the reporter posted a test case in the first comment but I had to do some changes to make it work
[19:01] <a|wen> imagemagick in maverick needs a no change rebuild, until then all builds against it fails; anyone around who can do that rebuild?
[19:01] <a|wen> debfx: then add your improved test-case to the bug description :)
[19:03] <ari-tczew> fabrice_sp: just constructive discussion. nothing to attack. arguments, negotiations...  making maverick good release? check your e-mailbox for requests :)
[19:04] <fabrice_sp> I know: I'm sponsoring stuff right now (some of them, old...)
[19:05] <ari-tczew> fabrice_sp: and I'm glad for this. Thanks for your work and time.
[19:06] <fabrice_sp> thank you for your time also ;-)
[19:08] <a|wen> cpscotti: just ping me if you have further questions or think that the SRU is done, and i'll look through it
[19:09] <cpscotti> a|wen: ok.. thanks.. I'll surely fix this all this week
[19:16] <imbrandon> a|wen: whats imagemagick need the rebuild for ? i can do the upload but need a reason
[19:18] <a|wen> imbrandon: new graphviz version has changed the name of some of the packages
[19:21] <imbrandon> k
[19:26] <fabrice_sp> hey imbrandon !
[19:27] <fabrice_sp> time for bug 531973?
[19:31] <imbrandon> a|wen: done
[19:31] <imbrandon> fabrice_sp: heya
[19:31] <imbrandon> fabrice_sp: sure, i'll grab it now
[19:31] <a|wen> imbrandon: thanks a lot!
[19:33] <debfx> a|wen: done
[19:34] <tumbleweed> geser: that patch sorted the ghostscript issue: bug 584597
[19:35] <a|wen> debfx: perfect ... now we'll just have to wait till one of the sru people comes along
[19:39] <imbrandon> fabrice_sp: done
[19:40] <fabrice_sp> imbrandon, great! thanks  a lot!
[19:44] <debfx> a|wen: I thought SRUs are uploaded and then held in the queue unitl they are approved by ubuntu-sru
[19:47] <a|wen> debfx: i've always let the SRU people do the upload ... but looks like the policy says so; i'll look at it in a minute
[20:03] <a|wen> debfx: uploaded to the -proposed queue, now awaiting approval
[20:03] <debfx> a|wen: thanks!
[20:53] <geser> tumbleweed: thanks for testing and preparing a debdiff
[20:54] <arand> Anyone got a minute to sponsor hardy..lucid-proposed in Bug #581331 ?
[20:56] <maco> so if i uploaded something to lucid-proposed and its waiting on SRU ACK  & so is in Unapproved state, but now i want to tweak the debian/changelog (add another bug # i didnt know about before)... do i just upload and it overwrites or do i need someone to reject the unapproved package first?
[21:03] <arand> maco: If I remember correctly you will need it rejected first, but take that as a vague guess, rather.
[21:04] <Laney> I thought that you didn't
[21:04] <Laney> . o O ( try it and see )
[21:04] <maco> heh
[21:04] <tumbleweed> geser: np
[21:07] <arand> Laney maco: Yea, my guess is based on something I think I remember someone saying at some point, so yea, might likely be wrong :/
[22:09] <ajmitch_> yay for LP having updated sid info again
[22:10] <Laney> yeah that apt-ftparchive bug got fixed
[22:12] <ajmitch_> now I get to watch bzr merge-package fail
[22:17] <imbrandon> sounds like too much fun
[22:19] <ajmitch_> I'm sure it is, if it'd work right :)
[22:19] <ajmitch_> conflicts are to be sort of expected, but it's not being helpful with regards to what's conflicting in debian/{control,rules}
[22:53] <ScottL> i'm working on bug #581786 and i need to remove an existing config file so that new configurations will be applied and a new config file written when the updated of ardour is downloaded and installed
[22:54] <ScottL> can the postinst file be something like this:
[22:55] <ScottL> for ~/.ardour2/ardour.rc rm ~/.ardour2/ardour.rc
[22:55] <arand> ScottL: Ah, that about the mute button not doing nuffink by default?
[22:55] <ScottL> yes arand
[22:55] <arand> ScottL: *hugs*
[22:55] <pochu> you're not allowed to touch user's home directories in maintainer scripts
[22:56] <ScottL> oh, pochu, do you have another suggestion?
[22:56] <pochu> do it in the program :)
[22:56] <pochu> (but in a sane way)
[22:57] <ScottL> i'm pretty new to bug fixing and packaging, but i'm not sure how
[22:57] <ScottL> what i found building ardour in ppa is that it seems to build correctly with the new settings
[22:57] <ScottL> it installs well, but the settings are still there, even for new songs
[22:58] <ScottL> BUT if you delete the existing file in the home dirctory and let ardour rebuild it
[22:58] <ScottL> then the new settings are in the config file in the home directory
[22:58] <ScottL> so any suggestions are welcome :)
[22:58] <carstenh> ScottL: no maintainer script should ever do anything in someones home, this would be a release critical bug
[22:59] <pochu> ScottL: sorry I've never used ardour, but can't users change the settings from the program preferences or whatever?
[22:59] <ScottL> carstenh, okay, thanks
[22:59] <pochu> ScottL: why do you need to change them upon upgrade?
[23:00] <ScottL> pochu, with the setting as is, the mute button is turned off by default
[23:00] <ScottL> yes the user could change the settings (four different options each time) but this would be required for each new project
[23:00] <ScottL> quite possibly for each new track (i didn't check this though)
[23:01] <ScottL> to be honest (as a user) this does *not* seem a sane setting to me
[23:01] <ScottL> the upgrade would be to turn the settings on by default (as one would expect when pushing the mute button)
[23:02] <ScottL> but as i said, the existing config file would need t be modified or deleted
[23:02] <ScottL> i have to go afk for a bit (family is outside) but if anyone has any suggestions, I'm open to them :)
[23:07] <arand> Have you seen:  http://tracker.ardour.org/view.php?id=2832 "Confirmed as still a problem in latest 2.0. Fixed in A3." Might se if you can find _how_ it was "solved"
[23:07] <ScottL> i did arand
[23:08] <ScottL> it was an old bug originally if i remember correctly and paul said he thought he had fixed it
[23:08] <ScottL> although i'm not sure to what "A3" refers
[23:09] <arand> ScottL: And isn't the patch in http://tracker.ardour.org/file_download.php?file_id=902&type=bug exactly what we want?
[23:10] <ScottL> yes and no arand
[23:10] <ScottL> if the ardour.rc file is not in the users home directory then yes, if not then no
[23:12] <arand> ScottL: Right so the home file will override the /etc/ one...
[23:13] <arand> ScottL: But On a fresh install it would work
[23:13] <arand> ?
[23:13] <ScottL> yes, arand :)
[23:16] <arand> ScottL: Hmm, in that case, since you _Do not touch home_ I don't think there's really a good solution (others correct me if I'm wrong), since you can't mess in home, and you can't have etc overriding home either, it's kind of lost since ardour has messed up those in the first place it seems...
[23:21] <imbrandon> i think its bluez-compat
[23:21] <imbrandon> err mistype
[23:21] <micahg> ScottL: add a wrapper script around the binary
[23:43] <ScottL> micahg, what would the wrapper script do if i we cannot touch home?
[23:43] <micahg> ScottL: wrapper script is installed, you can touch home in it if you're careful
[23:44] <micahg> ScottL: Here's a simple example of a wrapper script: http://launchpadlibrarian.net/43565621/edbrowse_3.4.1-1_3.4.1-1ubuntu1.diff.gz
[23:46] <ScottL> oh, that's a brilliant suggestions, thanks
[23:47] <micahg> ScottL: you might want to just rename it to .old or something rather than removing
[23:50] <ScottL> micahg, certainly
[23:50] <ScottL> qjackctl has something similar (wrapper script) that i am somewhat familiar