[02:28] <blackmoon-105> hi, i'd want to keep updated and fix bugs for the freepops package (i want to be a mantainer), i've already create a project on launchpad for this.
[02:30] <blackmoon-105> now i must only download the source code from ubuntu fix it and reupload?
[02:33] <micahg> blackmoon-105: it would actually be best if you have an interest in a single package to work with the Debian maintainer and have all the uploads go through Debian except if a fix has to get in before a deadline
[02:33] <persia> blackmoon-105, And to be clear, no we're not trying to make you run through a maze.
[02:33] <persia> The *best* way to maintain a single package is to work on it upstream and ensure it works well in Ubuntu.
[02:34] <persia> This is made easier if you work in Debian, as it eases communication with the Debian maintainer.
[02:34] <persia> This is also made easier if you have handy access to the upstream code changes, which is why you might set up a vcs-import branch on LP, so you can cherrypick.
[02:34] <persia> *but* if you just want to fix a bug, you can do that in Ubuntu ignoring all the rest of it.
[02:35] <persia> We MOTU tend to focus on the bugfixes, rather than any sort of package maintenance.  We fix the bugs in Ubuntu, and try our hardest to ensure the bugs are fixed in other places.  Because of this, we often recommend *starting* in the other places, because then the bug only has to be fixed once.
[02:39] <blackmoon-105> persia: i tought to maintain it for keep the pakage updated
[02:40] <blackmoon-105> and other minor fixes
[02:40] <persia> Yes, a package maintainer will keep the package updated and perform minor fixes.
[02:40] <blackmoon-105> because freepops from ubuntu repo doesn't work as well
[02:41] <persia> But there are no maintainers in Ubuntu.
[02:41] <persia> So, we're happy to help you with specific tasks (fixing a bug, updating the package), but we're likely to encourage you to take each change and coordinate with the Debian maintainer and the upstream developers.
[02:42] <blackmoon-105> i'ma alreandy in contact with th debian developer
[02:42] <persia> If you're working on *lots* of packages, you'll fit in fine.  If you are working only on one package, you'd probably find working directly with upstream (being their liaison into Ubuntu), and with the Debian maintainer (watching Ubuntu bugs, forwarding patches, coordinating, etc.) more satisfying.
[02:42] <persia> Excellent.
[02:43] <persia> So, easiest way to handle things from an Ubuntu perspective is to make the package perfect in Debian, and file a sync request
[02:43] <persia> !sync
[02:43] <blackmoon-105> i'm workin ganly with this package and i've got the working ones in my ppa..
[02:44] <blackmoon-105> i've already submitted all patches to the debiam mantainer but
[02:45] <blackmoon-105> the apply of the changs is not standard
[02:45] <blackmoon-105> and without a trick are not applied in ubuntu
[02:46] <blackmoon-105> wich build a debian version without the ubuntu changes
[02:46] <persia> What?
[02:46] <persia> Which package?
[02:47] <blackmoon-105> freepops
[02:49] <persia> So, the latest version I see in debian is .02.9-4.2, which is the same as the latest version I see in Ubuntu.
[02:49] <persia> Did it not build correctly?  What went wrong?
[02:50] <blackmoon-105> persia: no it's build correctly..
[02:50] <blackmoon-105> but it doest work fine
[02:50] <blackmoon-105> for example
[02:51] <blackmoon-105> freepops it's a demon wich start at boot but in ubuntu without the patch doesn't do it
[02:52] <blackmoon-105> then
[02:53] <blackmoon-105> some other minix thinng like the entries in the menu (for the plugin updater) are not shown in k/ubuntu
[02:54] <blackmoon-105> if you grab the source
[02:55] <blackmoon-105> under the buildfactory directory you'll see a  "debian-ubuntu" and "debian-ubuntu-dapper"
[02:57] <blackmoon-105> for get the pakage to work correclty con content of this directories must be copied under "debian" dir before compile it
[02:57] <blackmoon-105> once at time
[02:58] <persia> What?  Why?
[02:58] <persia> There should exist a debian/ directory that works well for both Debian and Ubuntu.  All the other packages have one.
[02:58] <blackmoon-105> persia: it should...
[02:59] <persia> Can you create one that works?
[03:00] <blackmoon-105> yes i've created a working packages for all release of ubuntu: https://launchpad.net/~marco/+archive/freepops
[03:02] <persia> blackmoon-105, Does that package work also for Debian?
[03:03] <blackmoon-105> persia: i don't know
[03:04] <blackmoon-105> persia: i know only that debian work fine with the standard version of the package
[03:17] <blackmoon-105> persia: do you think the there is a way for fix it?
[03:20] <blackmoon-105> this is one of the reasons why I asked if I could be the package maintainer (or working directly with the ubuntu team)
[03:25] <persia> blackmoon-105, Sorry: got distracted by local events.
[03:26] <persia> I suspect there is a way to fix it so that it can work with one debian/ directory for both Debian and Ubuntu.
[03:26] <persia> What trick is missing?
[03:27] <blackmoon-105> the trick is to copy (with "make -C buildfactory debian-dsc-ubuntu") the contents of "debian-ubuntu" in "debian"
[03:28] <blackmoon-105> the same for "debian-ubuntu-dapper" (when build the dapper packege)
[03:28] <persia> Ah, that's not something we can do.
[03:32] <blackmoon-105> persia: the only thing maybe is to get the debian source and apply the ubuntu pathes every time before build...
[03:33] <persia> I'm looking at the differences in debian/ for your maverick version to the version we ship in maverick.
[03:33] <persia> You've removed the build-dep-indep on luadoc: does that not affect building documentation?
[03:34] <persia> You've added a dependency on the "menu" package: best to get this from ${misc:Depends} or not at all.  Note that the menu package is not used at all in the production of menus by default for any Ubuntu flavour.
[03:35] <persia> You've added some manual stuff to the postinst: are you sure this wouldn't be better handled with dh_installinit?
[03:36] <persia> Importantly, you appear to be ignoring the user feedback from debconf about whether they want freepops to run as a daemon, which seems unfriendly.
[03:36] <persia> You've removed the comments from the debconf templates: not sure why.
[03:37] <persia> You've added a .desktop file: *excellent*.  Note that you don't have to add usr/share/applications to *dirs: putting it in *install is sufficient.
[03:38] <persia> We don't generally like tools that download random code from the internet, so the freepops-updater scripts aren't very interesting.  We'd prefer to see the plugins packaged, and the updates available managed through the repository.
[03:39] <persia> There's fuzziness in the translations: this ought be fixed.
[03:41] <persia> You may find using "install -D -m 644 modules/src/winsystray/freepops-32.xpm ${CURDIR}/debian/freepops/usr/share/pixmaps/freepops.xpm" and similar more satisfying in debian/rules, but it's lots easier to use freepops.install and install with that (man dh_install)
[03:42] <persia> So, in summary, I think you can achieve your goal of getting it to show in the menu more easily by submitting the .desktop files to Debian, and installing them with dh_install.
[03:43] <persia> You may want to discuss the postinst, and what might be happening with the debian maintainer.  I suspect that the default is to not start the daemon (which is both normal and correct), and since Ubuntu doesn't show unimportant questions, the user is never asked, so it never starts.
[03:43] <blackmoon-105_> opps
[03:43] <persia> Does all that make sense?
[03:44] <blackmoon-105_> now i check..
[03:49] <blackmoon-105_> persia: but without the menu package this work again?
[03:50] <persia> The menu package has to do with the .menu files, not .desktop files.  Completely unrelated to the change you are trying to accomplish.
[03:51] <blackmoon-105_> ah ok
[03:52] <blackmoon-105_> i don't have understand this: Importantly, you appear to be ignoring the user feedback from debconf about whether they want freepops to run as a daemon, which seems unfriendly.
[03:53] <blackmoon-105_> [sorry but i'm very tired, here are 5 a.m.]
[03:53] <persia> Feel free to take a break and ask again later if you'll be more productive.
[03:53] <persia> So, you modified the postinst.
[03:53] <persia> And ou commented out the line that checked the value from db_get freepops/init
[03:54] <persia> And then you *always* run the invoke-rc.d and update-rc.d calls.
[03:54] <blackmoon-105_> i've i've modified postinit because with the standard one the demon doesn't start..
[03:54] <persia> But the user is asked by debconf "Start freepopsd automatically after each boot?" and you should only start it when they answer "yes".
[03:55] <persia> It's not starting because the user is answering no by default.
[03:55] <persia> Which is correct behaviour.
[03:55] <persia> The other way to do it is to remove the debconf question, and use dh_installinit.
[03:55] <persia> But the debconf question is there for a reason: you might ask the debian maintainer.
[03:56] <persia> Note that the user can get it to start on every subsequent boot with `dpkg-reconfigure -plow freepops` and answering the question "Yes".
[03:56] <blackmoon-105_> ah ok
[04:00] <blackmoon-105_> persia: other things?
[04:00] <persia> hrm?
[04:01] <blackmoon-105_> there are other things to report?
[04:02] <persia> Not that I see obviously.
[04:02] <blackmoon-105_> ok :)
[04:02] <persia> But if you talk with the Debian maintainer, and investigate each of your changes, I'm sure you'll get better feedback there.
[04:03] <persia> If you don't understand something, or behaviour is different in Debian and Ubuntu and you don't understand why, feel free to ask here.  We're always happy to help.
[04:03] <persia> And thanks a lot for trying to fix this package.
[04:05] <blackmoon-105_> the changes i've made are all submitted to debian developer wich have uploaded cvs and he say to me to do "make -C buildfactory debian-dsc-ubuntu"
[04:06] <blackmoon-105_> i know that he used this tecnique also for build packagese for debian etch
[04:08] <persia> blackmoon-105_, Is there a reason that the changes are not suitable for Debian directly?
[04:10] <blackmoon-105_> maybe because some libraries wiche are not present in the old releses of debian are build staticaly inside the demon
[04:10] <blackmoon-105_> and in the earlier version are used as external packeas
[04:10] <blackmoon-105_> *packages
[04:11] <blackmoon-105_> if i remember goog, this is the reason of this thing
[04:13] <persia> Where is that in your changes?  I didn't see it, or is it in 2.9.5 and new from 2.9.4?
[04:15] <blackmoon-105_> no this is on old change
[04:16] <blackmoon-105_> this thing came with one of first release..
[04:18] <blackmoon-105_> sorry but now i must to go to sleep because i'm veeery tired...
[04:18] <blackmoon-105_> thank oyu very much for help :)
[04:19] <persia> Sleep well.
[04:19] <blackmoon-105_> thank you
[04:19] <blackmoon-105_> bye :)
[07:17] <udienz> micahg, around?
[07:30] <goesspoerr> !ping
[07:38] <dholbach> good morning
[09:43] <kklimonda> tumbleweed: oh, btw - you did sponsor two of my hamster-applet uploads afair. Would you mind commenting on my motu application?
[09:43] <kklimonda> (I do seem to gather endorsments at a really slow pace :/)
[09:45] <tumbleweed> kklimonda: sure
[09:45] <kklimonda> https://wiki.ubuntu.com/KrzysztofKlimonda/MOTUApplication
[09:47] <kklimonda> if you need bug numbers I think I can dig them out - I don't keep as good track of them as ari-tczew, but I did gather what I could find.
[14:44] <tumbleweed> geser: yay, web_link was on my todo list :)
[14:58] <geser> tumbleweed: there is one occurance left: in manage-credentials before the function can be removed
[15:55] <udienz> does anyone interest to maintain poedit in Debian?
[15:56] <micahg> udienz: did you need something?
[15:56] <udienz> this packages is orphaned, see debian bug 607749
[15:56] <udienz> micahg, this packages is outdated. i'm totally care this package, because i use this package
[15:57] <udienz> for translating
[15:58] <tumbleweed> udienz: looks like there's an adopter in the wings. debian bug 543856
[15:58] <micahg> yep
[15:58] <micahg> and a new version on mentors.d.n
[15:59] <udienz> glad to hear that, so we can sync easily
[16:01] <akoskm> hi! I'm building more packages within a single rules file with two *.install files, after the build finished and the packages are getting generated dh_duilddeb is adding "all" after the version number and before .deb in the package names, how can I avoid this? The packages names are differ so I don't need that extra "all" in them.
[16:01] <udienz> micahg, sorry about bug 712918, i have problem in database, well i'm not very good in database
[16:01] <udienz> so i'm not confident to take care phpwiki
[16:02] <micahg> udienz: ok, no problem, should I file for removal then?
[16:02] <udienz> micahg, ok, and thanks
[16:03] <udienz> i will try to update other software
[16:03] <micahg> udienz: that would be great, thanks
[16:04] <udienz> micahg, anyway what your suggest about 717168, we will waiting from debian or upgrading it?
[16:05] <udienz> rrr bug 717168
[16:05] <akoskm> nevermind, that was so lame. I have to admit
[16:05] <micahg> udienz: it's on mentors, if it can get sponsored in the next 2 weeks, that would be good
[16:10] <udienz> tumbleweed, is pull-debian-source need debian-keyring package? after i do pulling from debian an packages won't extracted, and tells me to install debian-keyrings. why debian-keyrings not Suggested in d/control?
[16:13] <tumbleweed> hmm, it probably should be. or it should only check the sig when it can't get the dsc from lp
[16:14] <udienz> tumbleweed, yup. failed when check the signature
[16:16] <tumbleweed> udienz: file a bug and I'll sort it
[16:20] <udienz> tumbleweed, done. bug 717245
[18:59] <AnAnt> Hello, can someone explain this FTBFS to me: http://launchpadlibrarian.net/64059164/buildlog_ubuntu-natty-i386.git-buildpackage_0.5.19_FAILEDTOBUILD.txt.gz
[19:08] <ScottK> AnAnt: I'd guess something's up at gbp/git.py line 502, but I didn't look at the source.
[19:10] <AnAnt>         except ValueError, err:
[19:19] <geser> when I look at http://git.debian.org/?p=users/agx/git-buildpackage.git;a=blob;f=gbp/git.py;h=1ecab9f1767dc124bc3d77273518dbac1e60a8e3;hb=HEAD#l502 I don't see why it should fail
[19:20] <geser> barry: ^^ any idea on this?
[19:23] <AnAnt> I suspect pychecker or python2.7 (or the mix of both)
[19:24] <AnAnt> there was a problem in pychecker with python2.7 , but that got fixed upstream (& uploaded to natty)
[19:28] <AnAnt> got to sleep
[19:28] <AnAnt> bye
[19:55] <barry> geser, AnAnt: looks like a bogus pychecker warning to me
[20:26] <Rhonda> Hmm, having troubles creating a cowbuilder chroot …
[20:27] <Rhonda> sudo cowbuilder --create --basepath ./natty --distribution natty --mirror http://at.archive.ubuntu.com/ubuntu/
[20:28] <Rhonda> That gives me a lot of "ln: creating hardink `/var/cache/.../$package': File exists" messages.
[20:29]  * Rhonda tries sudo rm /var/cache/pbuilder/aptcache/*.deb
[20:49] <Rhonda> humpf, now it fails with "Package 'cowdancer' has no installation candidate"