[01:35] <ScottK> tumbleweed: Please try to avoid too many recommends (see how devscripts handles this)
[02:09] <paissad_> hello guys, i maintain a package for about 1 year now, .. but recently there's someone who contributed about some useful changes in the packaging .. i would like to add his name somewhere but i hesitate where to mention his name
[02:09] <paissad_> in the debian/changelog ? ... int the README.Debian ? ....
[02:10] <paissad_> i think about creating THANKS.Debian :P
[02:10] <paissad_> how would you proceed ?
[02:10] <udienz> ari-tczew, already removed
[02:10] <micahg> paissad_: packaging changes would go in debian/changelog
[02:11] <ari-tczew> udienz: so now you have to wait for core-dev response
[02:11] <paissad_> micahg, yes the changes will be mentionned in debian/changelog indeed, but i'm talking about mentionning the name of a contributor
[02:12] <micahg> paissad_: something like this is fine: https://launchpad.net/ubuntu/+source/xulrunner-2.0/2.0~b8+build1+nobinonly-0ubuntu1
[02:13] <paissad_> micahg, ok thanks
[06:56] <dholbach> good morning!
[06:57] <evaluate> morning
[09:31] <iulian> Morning dholbach.
[09:31] <dholbach> hey iulian
[09:43] <akoskm> hi
[09:47] <akoskm> how can I change file contents on installation? there would be a line what I have to add to /etc/environment
[11:19] <bdrung> tumbleweed: massfile branch fixed and pushed
[12:21] <paissad> hello guys, i absolutely have to add some change in a default config file /etc/file.conf .... but the matter is i wonder wether i should do the changes automatically whenever someone upgrade to newer version of the package
[12:22] <paissad> or wether i prompt the user if he want to do the changes or not (but i should ^^)
[12:22] <paissad> but he should*
[12:29] <geser> paissad: dpkg has some conffile (files in /etc) handling and asks about changed files on upgrade (or is it ucf who does it?)
[12:29] <paissad> oO
[12:30] <paissad> ucf ?
[12:30] <Laney> it's dpkg
[12:30] <Laney> dpkg and ucf are two alternative implementations of conffile handling AIUI
[12:31] <geser> !info ucf
[12:31] <geser> paissad: ^^
[12:31] <paissad> ok, so i don't have to worry about that
[12:32] <paissad> but i would like to warn users to at least change the value of an OPTION in their conffile
[12:33] <geser> paissad: if you ship a changed file in /etc dpkg will ask what to do during the package upgrade (install the new version, keep the old one, show diff)
[12:33] <Laney> if you just change it they will be prompted accordingly
[12:33] <Laney> if they have modified it, otherwise it will be set for them
[12:33] <bdrung> tumbleweed: are you there?
[12:35] <paissad> ok, another question:
[12:35] <paissad> lintian shows this warning !
[12:35] <paissad> package-contains-empty-directory usr/share/pms-linux/database/
[12:35] <paissad> but i do have a file debian/pms-linux.lintian-overrides
[12:35] <paissad> with the content:
[12:35] <paissad> pms-linux binary: package-contains-empty-directory usr/share/pms-linux/database/
[12:36] <paissad> is my lintian-overrides file wrong ?
[12:36] <rdw200169> just tell lintian to shut the heck up... thats what i do...
[12:36] <paissad> i prefer considering as much as possible all warning that lintian show
[12:39] <paissad> if have an empty dir in my package usr/share/foo/emp-dir/
[12:39] <paissad> how must i add "it's lintian-override"
[12:39] <paissad> its*
[12:40] <geser> paissad: why to you have an empty directory in the package in the first place?
[12:40] <Laney> why does the package need an empty directory?
[12:40] <Laney> if it's to write to, that's an FHS violation
[12:40] <paissad> !info fhs
[12:40] <paissad> ok ^^
[12:40] <Laney> https://secure.wikimedia.org/wikipedia/en/wiki/Filesystem_Hierarchy_Standard
[12:41] <paissad> Laney, the program will create some file there
[12:42] <paissad> Laney, i do know that empty dirs should not be created ^^
[12:42] <geser> paissad: in theory /usr/share can be mounted read-only
[12:42] <paissad> oO
[12:42] <Laney> it should be somewhere under /var
[12:43] <Laney> and furthermore the program should handle creating the directory itself
[12:44] <paissad> Laney, yes indeed, the program does create it automatically
[12:44] <paissad> Laney, but i would like to remove that dir when i use --purge
[12:45] <paissad> Laney, i could create /var/lib/pms-linux/database/ and make a symlink to /usr/share/pms-linux/database
[12:46] <paissad> good idea or not ?
[12:47] <paissad> in any case, i will need the lintian-overrides (i just want to know what is wrong with the lintian-ovverides i wrote)
[12:47] <geser> would it be too much work to let it use /var/lib/... directly?
[12:47] <Laney> dpkg will not remvoe a non-empty directory on purge anyway
[12:48] <Laney> you need a maintainer script
[12:49] <paissad> geser, i would have to change the source if i want to creates the files in /var/lib instead of default dir !
[12:49] <paissad> geser, i already modified some stuffs in the source
[12:50] <paissad> Laney, rm -rf /var/lib/pms-linux/database/* (postrm)
[12:51] <Laney> so remove those last two characters and you have no need to create it in your packaging :)
[12:52] <paissad> hmm, i don't get what you mean
[12:52] <paissad> last two chars ?
[12:53] <Laney> rm -rf /var/lib/pms-linux/database
[12:53] <paissad> please, why don't you only tell me about the lintian-overrides ^^
[12:53] <paissad> :(
[12:54] <Laney> because it's wrong and unnecessary
[12:54] <paissad> my God
[12:54] <paissad> Laney, you're driving me crazy :D
[12:54] <geser> paissad: and file a bug upstream that it wants to write to /usr (see the FHS: /usr Secondary hierarchy for read-only user data)
[12:55] <geser> lintian.override should only be used for "false-positives" and not to hide (packaging) bugs
[12:56] <paissad> ok
[12:56] <paissad> it's not a packaging bug (according to me)
[12:57] <geser> then an upstream bug (writing to /usr) which should be fixed
[12:59] <bdrung> RainCT: you wrote the man page of update-maintainer. do you allow relicensing it under the ISC license?
[13:19] <paissad> Laney, geser, i all files and/or dirs that the program need to create are elsewhere (/var/lib/ for example) is accepted that anyway accepted i symlink them to /usr/share/pms-linux/ ?
[13:19] <paissad> if all*
[13:21] <paissad> i think yes
[13:33] <geser> paissad: yes
[13:33] <paissad> ok thanks
[13:34] <paissad> i changed the source to write database contents to /var/lib/pms-linux/database
[13:43] <RainCT> bdrung: sure
[14:18] <bdrung> RainCT: thanks
[14:55] <paissad> quilt is complicated :(
[14:55] <paissad> complicate*
[14:57] <highvoltage> compared to.... ?
[14:58] <paissad> i used to use patch programm directly ( i had no problem) .. but i wan to try quilt now since patches may grow up and if i understand correctly, quilt applies a series of patches
[14:58] <paissad> highvoltage, compared to patch command
[14:59] <paissad> a have a debian/patches dir which contains the .diff files and a file named series (which contains the name of each .diff file to apply)
[14:59] <highvoltage> I found it quite usable, I guess it depends on exactly what you want to patch and how
[15:00] <highvoltage> where did those .diff files came from? did you create them with quilt?
[15:00] <paissad> highvoltage, no, i created them using diff command
[15:01] <paissad> diff -U 3  file.orig file
[15:01] <paissad> diff -U 3  file.orig file | file.diff
[15:01] <highvoltage> I speak under correction, but I guess the right way to do it if you have existing patches would be to do a quilt add on the file and then apply your old patches, and then let quilt handle the creation of the patch files
[15:01] <paissad> diff -U 3  file.orig file | tee file.diff
[15:01] <highvoltage> see https://www.wzdftpd.net/blog/index.php?post/2008/02/05/3-quilt-a-patch-management-system-how-to-survive-with-many-patches for example
[15:09] <tumbleweed> bdrung: I am now, thanks. (Been offline, making mountains of ravioli today)
[15:10] <tumbleweed> ScottK: what's the issue with many recommends? surely they are preferable to depends?
[15:10] <evaluate> hello
[15:11] <evaluate> would a request to NOT sync a package to ubuntu be taken into consideration if it would come from the upstream maintainer?
[15:12] <tumbleweed> evaluate: packages can be added to the sync blacklist, yes http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[15:12] <bdrung> tumbleweed: i am working on update-maintainer but i don't know how to add test cases
[15:12] <evaluate> tumbleweed, ok, thank you
[15:13] <tumbleweed> bdrung: I'd imagine you'd have to patch open like I did for the config tests
[15:13] <bdrung> evaluate: which package?
[15:13] <evaluate> bdrung, It's not in debian yet, but I hope it soon will be...
[15:13] <tumbleweed> evaluate: and it's something that can't be maintained in debian for both debian and ubuntu?
[15:13] <cdbs> evaluate: If it has a version number like -0ubuntuX, then it won't be synced automatically
[15:14] <tumbleweed> cdbs: people will spend time trying to merge it, though
[15:14] <bdrung> evaluate: what are the reasons for not wanting it to be synced?
[15:15] <evaluate> tumbleweed, no, I actually started hating ubuntu as of today. I hate where it is going. I really wanted to get involved with both ubuntu and debian, but I may have to rething this
[15:15] <evaluate> well, for one the recent changes, read indicator, notify, etc. They are not mature, yet still you enforce them on people, this is not the way to do it IMHO
[15:16] <tumbleweed> evaluate: it's perfectly ok for you to maintain your package in debian and not care about ubuntu, you don't have to. At the same time, it's nice if you do.
[15:16] <evaluate> I worked my ass off to get indicator support for my app, but it lacks some serious features (e.g. I can't display any items in the indicator menu that contain underscores, the underscores get trimmed off). WTF is that?
[15:16] <tumbleweed> personally, I'm not a unity fan either (and in fact, I primarily use debian)
[15:17] <evaluate> tumbleweed, I seriously would love to do that, but the sh*t that's going on is making it impossible for me to do so...
[15:18] <tumbleweed> evaluate: without something more concrete, we can't really give you much guidance
[15:18] <evaluate> I mean, why would you enforce the indicator on people of it can't even display underscores in it's menu items. Also, why would you enforce a notify daemon that's not configurable AT ALL
[15:18] <evaluate> tumbleweed, well, I gave you an example. underscores in the indicator menu. They get trimmed off.
[15:19] <evaluate> tumbleweed, just a sec
[15:19] <evaluate> https://lists.launchpad.net/ayatana-dev/msg00052.html
[15:19] <bdrung> evaluate: underscore are trimmed off on menus too, because they have a special meaning.
[15:19] <tumbleweed> dunno if my system is just broken, but I don't seem to have notify-osd when I use "Ubuntu Classic" desktop
[15:20] <evaluate> bdrung, no, not the way I use them...
[15:22] <bdrung> evaluate: for what do you use the underscores?
[15:22] <evaluate> bdrung, I'm working on a clipboard manager. I need to put the clipboard history in the menu, and people sometimes also copy stuff that contains underscores
[15:23] <evaluate> and it looks like hell if you copy 'g_signal_connect' and see 'gsignalconnect' in the menu
[15:23] <bdrung> ok, that makes sense
[15:24] <evaluate> I also don't understand Mike's attitude on configuration: http://www.webupd8.org/2010/05/mark-shuttleworth-its-ok-to-customize.html
[15:24] <evaluate> He used to be cool and stuff...
[15:25] <cdbs> evaluate: Its just that underscores in the menu items aren't a concern for the devs
[15:26] <evaluate> cdbs, that wasn't my point. It seems that many things aren't a concern for the devs lately, examples being configurability and the ease to change things...
[15:26]  * cdbs would not like to take up that matter
[15:26] <evaluate> they seem to want to enforce a certain look to all people. If I wanted that I could've stayed with win$hit or OSX...
[15:26] <bdrung> evaluate: isn't a lack of configurability common for new projects? they will gather configurability over time (after they are requested)
[15:27] <evaluate> bdrung, well, yeah, but apparently Mike stated that he wouldn't like to receive patches to change the behaviour of notify-osd (see the link I pasted above)
[15:27] <cdbs> evaluate: yes, remember that nothing is perfect in its early years
[15:27] <cdbs> s/years/releases/
[15:28] <cdbs> Even Mac OS was a failure until 10.1 came along
[15:28] <evaluate> I mean, I would understand it if he would say that he won't spend his time coding it, because he sees something else as being more important, but NOT ACCEPTING PATCHES?
[15:28] <evaluate> WTF?
[15:28] <bdrung> evaluate: Mike? did you mean Mark?
[15:28] <evaluate> yeah, Mark
[15:28] <evaluate> my bad
[15:29] <cdbs> You can't blame SABDFL for that, he sets goals. He has more serious matters of concern than to think of underscores
[15:29] <ScottK> tumbleweed: They are still installed by default and so lots of recommends means a huge install for stuff most people won't use.
[15:29] <bdrung> evaluate: the only solution is to fork notify-osd (or implement something else) if you want a different behaviour.
[15:29] <tumbleweed> ScottK: so you'd rather have suggests were possible, and less dependancies where possible. I'm with you on that
[15:29] <ScottK> tumbleweed: Yes.
[15:29] <evaluate> there also is a notify-osd patch that has been created over a year ago by someone, but it's been discontinued. If they really wanted they could've merged the changes, because it seems to be working fine...
[15:30] <tumbleweed> ScottK: otoh, we haven't added any dependancies in this work, (than I know of) only BDs
[15:30] <ScottK> tumbleweed: As an example, as installed dget won't work, but if you run it, it fails telling you to install wget or curl (IIRC).
[15:30] <ScottK> tumbleweed: Great.
[15:30] <tumbleweed> ScottK: yeah, sounds familiar
[15:30] <evaluate> bdrung, like I said, that wasn't the idea. Why would I want to fork something if that feature can easily be integrated into the main program without loosing any of it's current usefulness or functionality?
[15:31] <cdbs> evaluate: I just got 3 patches accepted, one for indicator-session, one for dbusmenu and another for notify-osd. (all of these are ayatana projects)
[15:31] <evaluate> cdbs, did any of them bring additional features to them?
[15:31] <ScottK> evaluate and cdbs: This is probably more on topic in #ayatana.
[15:31] <azeem_> it is fine to reject patches if they compromise the design
[15:32] <azeem_> the patch author is free to fork thn
[15:32] <azeem_> then*
[15:32] <cdbs> evaluate: the devs are busy coping with the changes (GTK3, Python 2.7, etc). If you want to write a patch and get it accepted, then feel free to ping the devs. They are friendly with prospective devs who follow their coding style and designs
[15:32] <evaluate> ScottK, sorry, I was initially asking about the inclusion (or exclusion therefore) of a package from ubuntu
[15:32] <cdbs> And if you want a modification in the design, then file a bug with the ayatana-design project (let us stop this discussion here)
[15:34] <evaluate> ok, back on topic then. Who should I talk to, to get my program on that blacklist?
[15:35] <ScottK> Why do you want it blacklisted?
[15:35] <tumbleweed> bdrung: hmm, we did add a D on python-gnupginterface, and it's only used by one script (which I never use)
[15:35] <evaluate> ScottK, because I don't want it to be synched over from debian, when it will be uploaded there...
[15:35] <ScottK> evaluate: As long as it's got an XubuntuY revision number it won't be sync'ed over.
[15:35] <bdrung> evaluate: to get back to your initial question: you can request to blacklist a package from syncs, but you need a good reason. your request will be rejected if the reason is "i don't like ubuntu". that's the freedom open source gives us.
[15:35] <cdbs> evaluate: I would recommend you to get the package uploaded to Debian, sync then, and then make local changes in Ubuntu
[15:36] <bdrung> tumbleweed: you can move that to recommends
[15:36] <cdbs> Is the package intended to be repackaged in Debian?
[15:36] <cdbs> s/package/upstream tarball/
[15:36] <evaluate> cdbs, that's my point, I don't want to spend another bazillion hours to get it to play nicely with ubuntu, just because the ubuntu people feel it's ok to enforce unusable stuff on their users
[15:37] <tumbleweed> bdrung: done, and I'll file a bug about scripts failing nicely without recommends / suggests
[15:37] <cdbs> evaluate: please mention why you *don't* want a sync
[15:37] <bdrung> evaluate: you have to make your package DFSG incompatible to prevent it from getting into ubuntu. ;)
[15:38] <Laney> plenty of packages don't care about the ayatana stuff
[15:38] <Laney> there's no requirement for you to
[15:39] <evaluate> bdrung, well, if you sync it over, YOU will have to take care of the awkward stuff that will happen with it with the ayatana stuff...
[15:39] <ScottK> evaluate: I misunderstood what you were after.
[15:39] <ScottK> evaluate: Yes.  It's Ubuntu's problem then.
[15:39] <evaluate> ok then, that works with me :-)
[15:43] <paissad> highvoltage, now i understand quilt, yes indeed, it's quite usable ;)
[15:44] <evaluate> ScottK, to clear it up. I got angry at the fact that because the ubuntu devs implemented stuff in ubuntu that shouldn't have made it there, because it's not stable and usable enough yet, users file bugs at programs like mine, like 'implement support for indicator' or 'indicator menu doesn't work properly'...
[15:45] <ScottK> evaluate: I can understand feeling that way.
[15:45] <ScottK> I think it's reasonable to adapt to it, accept patches for it, or say it's a distro problem as you please.
[15:45] <ScottK> So just mark the bug whatever your equivalent of wontfix is and move on.
[18:01] <paissad> i'm done ... ^^
[18:01] <paissad> i have to make ask some user options for 1st installation or during configure about the user who run the program's daemon etc ...
[18:01] <paissad> i don't want really want to use debconf (really complicated)
[18:01] <paissad> really
[18:02] <paissad> my Godness
[18:03] <paissad> i just want to do something like this ... ask the user, the domain name, port, sharing dirs ...
[18:08] <Riddell> debconf can be complicated but it does sound like the right tool for the job
[18:18] <geser> and debconf is the only policy-compliant tool for questions during package installation
[18:35] <ari-tczew> congrats to AnAnt for syncing package from experimental without build test - git-buildpackage
[18:37] <micahg> ari-tczew: do you know he didn't test?
[18:37] <ari-tczew> micahg: I guess
[18:55] <ari-tczew> anybody know how can I fix this ftbfs: /usr/bin/ld: unrecognized option '-Bsymbolic-functions;-Wl'
[18:59] <tumbleweed> ari-tczew: -Wl,foo means gcc please pass foo to ld. So if ld is getting a -Wl, someone has made a typo or something
[19:01] <ari-tczew> tumbleweed: heh, still don't know how fix ftbfs
[19:01] <tumbleweed> ari-tczew: work out how that got there (start by replicating it locally)
[19:01] <ari-tczew> tumbleweed: ok, leaving this one, thought that it's easy to fix
[19:04] <Leon_Wallch_Deve> I have a problem connecting two ui files... If anywone have time please answer here (http://www.qtforum.org/article/35341/create-a-thread-to-the-one-ui-to-be-connected-with-the-qcloseevent-of-the-main-ui.html). Thank you :)
[19:16] <carstenh> hi, deborphan/1.7.28.3 has been unblocked in debian and will presumably enter squeeze before its release. it includes fixes for the two bugs that are fixed in the ubuntu's version. could someone please sync deborphan from debian to ubuntu n*?
[19:17] <carstenh> it also includes other fixes and translation updates.
[19:19] <micahg> carstenh: ok, I'm looking into it
[19:19] <carstenh> micahg: thanks :)
[19:20] <carstenh> micahg: the dbgsym changelog entry is incomplete, but the according code is correct and complete.
[19:21] <micahg> carstenh: what about the french man page?
[19:21] <carstenh> micahg: fixed in .1
[19:21] <carstenh> | * Recode note regarding bug reporting from the French l10n team to UTF-8. LP: #352744, Closes: #603907
[19:22] <micahg> carstenh: ah, ok, great, I just need to test build before I request the sync
[19:22] <carstenh> :)
[19:28] <micahg> carstenh: looks good, I'm requesting the sync
[19:29] <carstenh> micahg: fine, thanks a lot
[19:30] <micahg> carstenh: bug 693905 if you wish to subscribe
[19:33] <ari-tczew> micahg: thanks
[19:34] <micahg> ari-tczew: what did I do?
[19:34] <ari-tczew> micahg: taking a look on deborphan. did you see comment on MoM?
[19:34] <micahg> ari-tczew: oops, sorry no
[19:34]  * micahg needs to remember to check
[19:35] <ari-tczew> micahg: you're golden
[19:35] <micahg> ari-tczew: did you file a bug already?
[19:35] <ari-tczew> micahg: not yet
[19:35] <ari-tczew> micahg: however, I wasted only 5 minutes today morning, so don't afraid
[19:35] <carstenh> micahg: I'm already on the "to be notified" list :)
[19:36] <ari-tczew> micahg: I planned to do it today evening, if you have done this, no problem, but please remember check in future comments
[19:36] <micahg> ari-tczew: ok, thanks
[19:36] <micahg> carstenh: cool
[22:43] <blueyed> I want to upload a fix for apt-build, which is a Debian native package. should I use 0.12.37-0ubuntu1 for the version?
[22:44] <ari-tczew> blueyed: is it new upstream release?
[22:44] <crimsun> if it's an Ubuntu-specific change, 0.12.37ubuntu1
[22:45] <ari-tczew> +1 ^^
[22:45] <carstenh> ari-tczew: native packages are always new upstream releases ;)
[22:45] <ari-tczew> blueyed: or send changes to Debian git and we can get full source from git
[22:47] <blueyed> It is not Ubuntu specific. The same bug applies to Debian.
[22:47] <blueyed> I just wanted to get it fixed, and would have forwarded it.
[22:48] <blueyed> I might just forward the debdiff without upload.
[22:49] <blueyed> ari-tczew: are you involved in apt-build?
[22:49] <ari-tczew> blueyed: nope
[22:50] <blueyed> oh nice, my two patches are in git already (from looking at the changelog)
[22:53] <blueyed> well, part of it.
[22:56] <blueyed> Is there a recommended version to get the Git commit upstream? Send them to the bug, if there is one?
[22:57] <crimsun> would you clarify, please?
[22:58] <ari-tczew> blueyed: report a bug on BTS
[22:59] <blueyed> I have cloned the apt-build repo and am about to commit my fix. Is there a best way to get it to the Debian developer? e.g. via git-send-email to a bug.
[22:59] <Laney> a git-formatted patch on the BTS is the best way usually
[22:59] <blueyed> ari-tczew: there's a bug already. I will try sending the commit there.
[22:59] <blueyed> k, thanks, Laney.
[23:15] <akoskm> hi! where to place the bash script in debian/rules if I want to run it after the installation?
[23:44] <carstenh> akoskm: debian/postinst is run after the installation, but i'm sure you don't want to place your script there without prior adaption
[23:45] <carstenh> akoskm: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[23:46] <carstenh> akoskm: http://wiki.debian.org/MaintainerScripts
[23:51] <akoskm> carstenh, thank you. I have to run this script to update the classpath variable in /etc/environment. I can't find any already implemented scripts for doing such things. If you have better idea I really appreciate it.
[23:52] <carstenh> akoskm: is this your private package or something you intend to upload?
[23:54] <akoskm> no, for now it's just my test package (qt jambi, java binding for Qt). I want to upload later and make it available for download
[23:56] <carstenh> akoskm: changing files in maintainerscript is bad and mostly a policy violation
[23:56] <carstenh> akoskm: you should read http://www.debian.org/doc/packaging-manuals/java-policy/x85.html
[23:57] <carstenh> akoskm: ubuntu is based on debian, so the debian policy applies on ubuntu too
[23:59] <carstenh> akoskm: looking how exactly other packages have solved such problems is often a good idea