=== ScottK2 is now known as ScottK === Snova_ is now known as Snova === QlOfp]cF is now known as LjL === evalles_ is now known as effie_jayx === Snova_ is now known as Snova === Snova_ is now known as Snova [02:53] nhandler: mind looking at bug 313820? it has been verified for a couple months now [02:53] Launchpad bug 313820 in ircd-ratbox "built source package crashes with buffer overflow" [Medium,Triaged] https://launchpad.net/bugs/313820 [02:54] Sure thing dtchen [02:54] thanks [02:57] dtchen: Have you talked to the Debian Maintainer about this issue? [02:59] i pinged, but no response [02:59] as you can see, it has been a couple months [03:36] dtchen: What do you need to do to triger the buffer overflow? [03:43] dtchen: I'm going to bed. Please add a comment explaining how to reproduce that bug, and I'll look at it tomorrow === Sikon_ is now known as LucidFox_ === LucidFox_ is now known as LucidFox === Andre_Gondim is now known as Andre_Gondim-afk [05:59] good morning [05:59] thanks for uploading that change dholbach :) [06:00] binarymutant: no worries [06:01] binarymutant: I added a changelog entry for 1ubuntu1 for you [06:02] thank you :) [06:02] Hey dholbach ! :-) [06:02] already sponsoring ;-) [06:02] fabrice_sp_: I figured that's the best way to start the day :) [06:03] dholbach, Well. I would say a coffee is not that bad ;-) [06:04] fabrice_sp_: that too :) [06:10] luisbg: can you recommend a club in Barcelona? :) [06:14] dholbach, you mean nightclub? Because club can be misunderstood in Spain :-) [06:14] fabrice_sp_: nightclub, music, dancing, yes :) [06:14] (at least in Madrid. I don't know for Barcelona :-) ) [06:14] * slangasek recommends a club soda [06:14] ok ;-) [06:15] fabrice_sp_: every other kind of club I leave to UDS attendees to figure out themeselves ;-) [06:15] do't worry: in the air plane books, you generally have some addresses of other kind of clubs... [06:15] lol [06:21] fabrice_sp_: regarding te graphviz fix - is there no way to get it to build 2.5 and 2.6 modules? [06:21] doko: ^ do you have an idea how to do it (bug 338553) [06:21] Launchpad bug 338553 in graphviz "[jaunty] libgv-python: Depends: python (< 2.6)" [Medium,Confirmed] https://launchpad.net/bugs/338553 [06:23] fabrice_sp_: sugar-base: intrepid -> jaunty :-) [06:25] dholbach, about graphviz: the package is not ready to deal with python26. We should modify at least configure and perhaps Makefile to deal with 2 build version (the build location is different in --enable-python and --enable-python2.5) [06:26] what do you mean with sugar-base? I saw that a update request is there, but I didn't saw morgs to ask him the status [06:26] fabrice_sp_: the sponsoring bug regarding python2.6 [06:28] hiya jono [06:28] dholbach, the rebuild, yes. Sorry, but I don't get your point :-( Is there something also in Intrepid? [06:28] fabrice_sp_: no, you had "intrepid" in the changelog entry [06:28] ahhh [06:28] just fixed it and re-uploaded [06:29] dholbach, sorry about that: I use intrepid for building the package in a sbuild and jaunty chroot for the change. I sometime mix things :-/ [06:29] thanks! :-) [06:29] https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases :) [06:30] dholbach, fabrice_sp_ : fix the packaging, build it twice. [06:31] dholbach, yeah, I know, but it's a shared computer, and I already have 'family problems' to have Ubuntu accepted (especially because of flash in adm64), so using a 'non stable' version could be a reason of not having a family any more! :-) [06:32] fabrice_sp_: that page explains how to do it in a "safe way" [06:32] doko, should the rules file be generic, or we could use 'hardcoded' python version (ie: if python2.5 move that files and if python2.6, move that other files) [06:33] dholbach, oh. I'll have a look then! :-) [06:34] fabrice_sp_: in the synfigstudio request quilt would not have been necessary - the debian maintainer seems to patch the source directly, so you could have just done the same [06:34] does anyone have any opinions on a good package name for a program called "rapid photo downloader" (I am the upstream author, and I'm doing my first package) http://damonlynch.net/rapid/ [06:35] two obvious choices are 'rapidphoto' or just 'rapid' [06:35] dlynch: what's wrong with rapid-photo-downloader? :) [06:35] it has not been packaged at all yet [06:35] is that not too long? [06:35] makes sure it's not being confused with anything else [06:35] ok if the length is not a problem, it's not a problem with me! :) [06:35] it's shorter than xserver-xorg-video-openchrome :) [06:36] or system-config-printer-gnome [06:36] or lots of others :) [06:36] dlynch: rock on! :) [06:36] ok that probably makes my life as a packaging novice easier then [06:36] thanks! [06:36] no worries [06:36] dholbach, I have to say I always use quilt to patch, and never look at debian modifications. I'll check with kallery [06:37] fabrice_sp_: it makes the patch shorter and is in line with what the debian maintainer does, so I thought that'd make sense :) [06:38] dholbach, sure. Should I upload a new debdiff? By the way, for Bug #348160 should I subscribe u-u-s after each package or only when having all the debdiff [06:38] Launchpad bug 348160 in imageinfo "libmagick10 transition to libmagickcore1" [Undecided,Fix committed] https://launchpad.net/bugs/348160 [06:38] fabrice_sp_: yeah, please attach a new debdoiff [06:39] fabrice_sp_: I just try to keep the sponsoring overview as short as possible, so if there's nothing to sponsor, I unsubscribe the team - just re-subscribe if you want anything uploaded :) [06:39] dholbach, will do. Thanks! [06:40] rock on! :) [06:40] * dholbach hugs fabrice_sp_ [07:00] morning o/ === thekorn_ is now known as thekorn [07:46] does someone who knows ruby want to fix ruby-gnome2 FTBFS? [07:47] (maybe a merge from Debian?) [07:55] I like my package to "suggest" any internet browser. Is there a virtual package I could suggest (e.g. sensible-browser)? [07:55] good morning [07:57] Elbrus: Suggests: www-browser [07:58] Toadstool: thanks [08:00] is there something similar for pdf-readers? [08:01] Elbrus: pdf-viewer :) [08:02] great. I was trying to find it in debian-policy... [08:03] Elbrus: http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt [08:03] Toadstool: just found it a second ago... Thanks [09:00] I am having problems with the man page section of the debian/rules file, after following the instructions at https://wiki.ubuntu.com/PackagingGuide/Complete#Necessary%20packaging%20changes [09:00] http://paste.ubuntu.com/137312/ , when running dpkg-buildpackage -us -uc I get this error : [09:00] fakeroot debian/rules clean \n debian/rules:12: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. [09:01] (sorry I was d/c a few minutes ago) [09:01] dlynch, you need to indent the commands in debian/rules (just like in a Makefile, for it is a Makefile) using tab characters, not spaces [09:02] liw: thank you, I'll try that then [11:41] Hi, can someone help me with a newbie packaging query please? [11:42] lintian complains that I have files which are changed despite using quilt (I am taking over a package)... [11:42] But one of those files is Makefile.in which seems to be changed whenever a build occurs. [11:42] HOw can I get around that problem? === korn_ is now known as c_korn [11:57] Mewcenary: delete Makefile.in in the clean rule [11:58] Thanks for the tip, I'll try that out. [11:58] soe packages so NOCONFIGURE=1 ./autogen.sh before creating the source tarball, I'm not sure whether that's applicable here [12:38] Heya gang [12:41] btm, cjwatson, Laney: not sure what happened with bug #334065. I clearly didn't process the request... I'm pretty sure it was the day that I was doing requests manually (ie without syncbugbot). Regardless, it was a mistake and I apologize [12:41] Launchpad bug 334065 in libgems-ruby "Please sync libgems-ruby 1.3.1-1 from debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/334065 [12:43] heya bddebian [12:45] Hi siretart [12:47] hi folks [12:49] Heya sistpoty|work [12:49] hi bddebian [12:49] sistpoty|work: I don't know if you noticed but I uploaded trigger-rally and -data :) [12:49] bddebian: yep, I saw that... thanks a lot! :) [12:50] NP [13:10] btm, cjwatson, Laney: fyi-- bug #334065 is now synced [13:10] Launchpad bug 334065 in libgems-ruby "Please sync libgems-ruby 1.3.1-1 from debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/334065 [13:11] cool, thanks [13:11] sure. sorry again for the mix up [14:22] is this the correct place to ask a question about a PPA build error? [14:26] Depends on whether you suspect the problem is with the PPA build environment (#launchpad) or the package source (here is reasonable) [14:31] maxb: thanks given this is my first attempt to build a deb for a PPA, I strongly suspect the latter ;-) [14:32] I got an 'ImportError: No module named gtk.gdk' in the dh_clean part of the build [14:33] I'm hoping that by simplifying the imports in the setup.py, this problem will go away [14:33] Have you built the package locally in pbuilder prevu or sbuild ? [14:33] dlynch: can you point us to the package? [14:35] maxb: I'm not sure I understand your question, but when I built it locally, I ran dpkg-buildpackage -us -uc [14:35] dlynch: Then it sounds as if your problem is a build-time dependency that is not declared in your debian/control Build-Depends [14:36] geser: I can point you to the trunk on launchpad [14:36] Packages build on the automated builders in a very minimal environment, into which the dependencies explicitly asked for in Build-Depends have been added. If you don't ask for a package in Build-Depends, you don't get it available. [14:37] maxb: I have cdbs (>= 0.4.49), debhelper (>= 7), python-central (>= 0.5.6), perl in my build depends [14:37] pbuilder replicates this scenario locally to help you check your packages [14:37] dlynch: There's no mention of any python gtk stuff there, yet you're using it in your build process - so that's the problem [14:38] maxb: ahhh ok. I think it merely came from the fact that my setup.py was importing the version number from the main script, which of course has many imports in it, including gtk [14:39] so the solution is to store the version number somewhere with no imports, I think :D [15:02] https://bugs.launchpad.net/ubuntu/+bug/348480 [15:02] Ubuntu bug 348480 in ubuntu "unable to set custom window manager" [Undecided,New] [15:03] This is actually probably not MOTUs fault, but maybe someone knows someone who knows something about this. [15:06] please forgive me for asking such a super newbie question, but is the best (only?) way to add the ~ppan package suffix via the changelog in the debian directory? [15:07] yes, the last entry in the changelog determines the package version/revision [15:08] Should people really add ppa suffixes to their packages? [15:08] geser: thanks! I already figured out that not rigidly adhering to the changelog format causes a build failure :) [15:09] cyberix: see "Versioning" in https://help.launchpad.net/Packaging/PPA [15:09] dlynch: when you use dch it helps you with the format of it [15:09] cyberix: it has the rationale for ~ppaN [15:10] right [15:10] one thing I've come across is that my debian directory is part of my python setup.py sdist output [15:10] custom packages [15:10] which is all fine and good [15:10] customized for ppas [15:10] but the problem arises when launchpad rejects the orig.tar.gz [15:10] saying it's different, even though the version didn't change [15:11] but it is different only because the contents of the debian directory have changed [15:11] I'm only trying to update my packaging stuff, not the source code itself [15:12] sorry if this is a confusing explanation [15:14] my question is this: is it a bad idea to put the contents of the debian directory in the tarball created by python setup.py sdist ? [15:14] Generally, yes. [15:15] aha [15:15] maxb: so that means to do a build, I should copy the contents of that directory myself [15:16] Does this thing you're packaging have upstream releases? [15:17] maxb: I am the upstream author, and this is my first time to package anything [15:17] The usual approach is to maintain the upstream release and the packaging separately [15:18] so I should put things like the man page pod file and the .desktop file in the upstream, and practically everything else in the debian directory? [15:20] Well, presumably you'll want to release a tarball for people and/or other distributions to use? [15:20] maxb: yes [15:20] That tarball, which would usually be foo-1.0.tar.gz gets renamed to foo_1.0.orig.tar.gz for the debian package [15:21] I store the tarballs on launchpad [15:21] Then, you unpack that tarball, add a debian/ directory to it, and build a debian source package, which generates a .diff.gz and a .dsc file that go along with the .orig.tar.gz [15:23] since this must be such a common procedure on launchpad python archives, has someone built a tool to automate as much of this as possible? [15:24] dpkg-buildpackage (or debuild) will build the source package from the unpacked directory [15:25] thank you maxb, I will look into this tool more thoroughly... and thanks very much for your guidance, it makes a lot of sense [15:41] ScottK: ping === ssweeny_ is now known as ssweeny [16:01] I'm confused by how to have a python package work for intrepid as well as jaunty. I've read the documentation at https://help.launchpad.net/Packaging/PPA, but it doesn't say what how the debian changelog entry should be entered to presumably allow the package to work on more than one release [16:06] dlynch: you need an upload for jaunty and one upload for intrepid (and if you want to support other releases too and upload for them too) [16:07] geser: and they should have separate changelogs, or the same? [16:07] and each upload needs a different pkg revision (e.g. include the disto name in the revision, e.g. ~ppaN~intrepid1) [16:08] geser: why do I need to do this when the program does not need to be recompiled? [16:08] dlynch: the minimalistic way would be to change the release and the pkg version in the changelog but you can also add a new entry for those "backports" [16:09] dlynch: often it's because of the runtime dependencies which are determined during build [16:10] geser: you mean the launchpad build process is clever enough to determine whether the python program can be built across more than one release? [16:11] dlynch: no, during the build some scripts scan the package and add the necessary dependecies e.g. on libraries or the python intepreter [16:11] do they "hard code" in something like 'python2.6', or do they keep the version range I specified? [16:12] dlynch: it depends on the package if it runs on several releases or not [16:12] dlynch: depends on how you packaged it [16:12] geser: my package does run on several releases [16:12] and I did package it so it will install unchanged on both jaunty and intrepid [16:12] what are the runtime dependencies on the binary package? [16:13] ${python:Depends}, ${misc:Depends}, python-gnome2, python-gtk2 (>= 2.10), python-glade2 (>= 2.10), python-pyexiv2 (>= 0.1.2), python-notify [16:14] XS-Python-Version: >= 2.5, << 2.7 [16:14] and now the same from the build package (from PPA) [16:14] you mean from the one built by the PPA? [16:14] jdstrand: thanks! [16:15] dlynch: yes. is it rapid-photo-downloader? [16:15] yes [16:17] geser: it is the same, except python-central >= 0.6.11 is now explicitly specified [16:17] dlynch: the depends on python itself are ok for intrepid, but the generated dependency on python-central (>= 0.6.11) can't be fulfilled on intrepid -> rebuild necessary to get the correct versioned dependency for intrepid [16:18] geser: if I did the build from intrepid instead, would it work for both intrepid and jaunty automatically? [16:18] or do I still need to make two different packages? [16:20] dlynch: if you build it on intrepid and "copy" then the debs to jaunty it should work on both [16:20] copying debs forward has more success than copying backwards [16:21] geser: great! thank you very much for your time! [17:36] hi, yesterday I was asking about what code is used to display the partition bar in ubiquity as seen here: http://www.askdavetaylor.com/2-blog-pics/ubuntu-install-pic6.png [17:36] I can't find it in the source, can anyone help me? [17:53] Is there some GUI tool to sync directories on different PCs? (decentralized, not stuff like Dropbox) [17:54] RainCT: version control? [17:54] :) [17:56] mrooney: well, but I don't really mind about revisions, I just want something fast and space efficient, and most important with monitoring (so that if I change something, and I'm connected to the other PC, it gets synced automatically) [17:56] perhaps fsniper + bzr would do, but I was looking for something more ellaborated :P [17:57] (uhmm no, fsniper is only for new files) [17:58] RainCT: maybe grsync? (no clue so, what it can do, haven't used it myself yet) [18:01] Looks nice, but it doesn't have the file monitoring [18:07] well, I think I'll get with plain rsync for now [18:07] s/get/go. thanks anyway [18:07] * sebner waves at sistpoty|work :) [18:08] hi sebner [18:10] Hi sebner, you've now internet during the week again? [18:10] hey sebner [18:11] RainCT: have you had a look at unison? [18:12] hi geser RainCT [18:12] nhandler: simply rebuilding the source package and starting the compiled daemon results in the symptom [18:12] geser: well, only if I return home (1h with the train). I won't do this that often. maybe 1-2 times a week [18:12] geser: oh, that one looks great :) [18:16] * sistpoty|work calls it a day... cya [18:21] nhandler: it's a case of toolchain skew; we can either leave it be for jaunty, or we can fix the source. it's fairly obvious to me that the correct thing is to fix the source, but eh, i leave it to you guys who have upload privileges. [18:31] RainCT: You might want to try giver. [18:32] cprov-afk, didn't know there WERE whiteboards. nuke 'em [18:32] * iulian is disappointed because it's unmaintained upstream. === cprov-afk is now known as cprov [18:33] directhex: right, that's the point :) [18:34] iulian, adopt upstream duties! [18:35] cprov, the only PPA wishlist for me right now is debian support [18:35] cprov, e.g. the dependency management stuff is great [18:35] directhex: really ? have you explored it ? [18:36] directhex: we've never had much feedback about it. [18:36] cprov, just added a dep on someone else's PPA to avoid needing to repackage some stuff myself. huge timesaver === Andre_Gondim-afk is now known as Andre_Gondim [18:36] also, dh7! [18:37] directhex: cool, it gets more useful when the PPAs for important projects (kde, gnome, bzr) are organized. [18:38] cprov, well, that ties into the debian question - if a ppa could build debian stuff natively, then it'd be much easier to convince migration from alioth for cross-distro teams [18:40] directhex: right, I see your point. Building debian sources natively (using debian chroots) is theoretically possible and is in our plans, but unfortunately not before July. [18:40] cprov, meh. it's been how many years so far? what's a few more months? :p [18:41] directhex: 'good things take time' seems appropriate here ;) [18:42] * cprov hides [18:42] cprov, the phrasology is "good things come to those who wait" [18:45] directhex: For dh7 (I assume you're packaging for Hardy) you can also depend on hardy-backports to get it. [18:45] ScottK, exactly! like i said, PPAs are awesome ;) [18:46] * ScottK is a lot happier with them now that they are signed. [18:51] ScottK, i was under the impression there was a debate about the role PPAs were meant to serve - i.e. not signing was an intentional "don't use me!" flag [18:53] directhex: I think there was a debate, but if it was meant that way, it was far too subtle for most users. [18:54] ScottK, "rm -fr /" is too subtle for most users ¬_¬ [18:54] Certainly. [18:55] hm, my benchmarks of vdpau are promising === _bastiao is now known as bastiao [19:09] Can someone help me figure out why a PPA plugin pack won't build on intrepid/hardy, but build perfectly on jaunty? I've already taken into account build-depends and autogen.sh scripts. [19:09] ripps: #launchpad for PPA questions. [19:35] JontheEchidna, I've been able to build kallery to get rid of aRts. The problem you had is because in the clean target, it was executing the configure target :-/ [19:36] I'll upload the debdiff soon (in Bug #348160) [19:36] Launchpad bug 348160 in imageinfo "libmagick10 transition to libmagickcore1" [Undecided,Fix committed] https://launchpad.net/bugs/348160 === fabrice_sp__ is now known as fabrice_sp === Andre_Gondim is now known as Andre_Gondim-afk [20:41] hi. a dependency for calendarserver (jaunty) is python-twisted-calendarserver_0.2.0.svn19773-5ubuntu1_amd64.deb which is trying to overwrite a file from python-twisted-core [20:42] what to do about it? [20:42] (I'm no dev, just user) [20:43] packages.ubuntu.com states to ask @motu before contacting the maintainer :) === jono_ is now known as jono [20:47] please file a bug at launchpad against that package [20:57] geser: ok [21:07] dtchen: I am still unable to reproduce that bug inside of a jaunty chroot (pbuilder) on i386. [21:08] nhandler: it's quite straightforward here. also, there's a known fix; it's unintrusive; it's trivially correct. it kinda makes sense to apply it *before* release. [21:09] dtchen: I know. However, Luca also said he was unable to reproduce it, so I'm questioning if there is a need. [21:09] well, that's really up to you guys [21:10] dtchen: I have to run out for a little bit. I'll look at it again when I get back [21:10] do you want me to write an exploit PoC or something? ;) [21:13] nhandler: If dtchen says it needs fixed, I'd fix it. [21:29] JontheEchidna, I've update Bug #348160 with the patch for kallery (that drop aRts also). If you want to have a look [21:29] Launchpad bug 348160 in kallery "libmagick10 transition to libmagickcore1" [Undecided,Confirmed] https://launchpad.net/bugs/348160 [21:31] fabrice_sp: col, I can probably look at it after dinner [21:31] ok. I'll be in my bed at that time ;-) [21:36] ScottK: TheMuso re-uploaded pencil with an updated copyright file :-) [21:37] khashayar: Thanks. === DrKranz is now known as DktrKranz [21:44] ScottK: I've been doing little more than pinging people. Thanks go to you. [21:45] khashayar: Source is accepted. It'll go to binary New after it builds. [21:46] khashayar: The short description could be more gramatical. Try pencil is a _________ and it should flow from that. The current one is a bit awkward. [21:46] ScottK: Thanks a lot! [21:47] khashayar: Thank you for making Ubuntu better. [21:48] ScottK: So, when I want to tidy things up (like the short description), do I file a bug against the package with a patch? [22:11] khashayar: Yes. === Snova_ is now known as Snova [22:34] I am wondering if someone could look over a personal project of mine and help me get things up to standards for Jaunty... https://code.edge.launchpad.net/~ausimage/+junk/PbParser [22:34] fabrice_sp: I'm looking at synfigstudio, but the program crashes after the splash screen. Does it run for you? [22:35] I have it working in with intrepid... but since the python changes in Jaunty I am unclear... I really would like to see this avaible in Karmic ;) [22:50] ausimage: I gave it a quick look and it doesn't need any packaging changes due to the python2.6 transition [22:50] what about the setup switch? [22:50] to specify the different layout [22:51] also I had questions if I am putting the icon where it is supposed to be [22:52] geser? [22:54] ausimage: cdbs is patched to do the right thing and you don't have any settings or custom targets which break it [22:54] ok... I was not sure if the icon going into icon was correct or if it belongs in pixmaps [22:55] looking at that icon now [22:55] have you checked your desktop file with "desktop-file-validate"? [22:55] also I a had a question about the best way to include the manpages... [22:56] um no did not know it existed [22:56] and you shouldn't hard-code the path to the icon as it breaks themeing and auto-selecting of the icon format [22:56] how should I do it? [22:57] how should I do it? [22:57] sorry :/ [22:58] * ausimage pulls up his desktop file [22:58] install your pbparse.svg as /usr/share/pbparse.svg and use "Icon = pbparse" [22:59] if I remember correctly at least Gnome should find the svg file and use it [22:59] and cdbs puts it where it supposed? [23:00] I thought icons should have a specific location under /usr/share?? [23:01] sorry, missed the pixmaps dir: /usr/share/pixmaps/pbparse.svg [23:01] and gnome checks there for any images not in the current path? === bluesmoke_ is now known as Amaranth [23:02] I don't know exactly the search order but yes, it should find it there (if your icon theme doesn't provide an own one) === Andre_Gondim-afk is now known as Andre_Gondim [23:16] * ausimage made geser changes and is awaiting the arrival on his ppa === asac_ is now known as asac === Andre_Gondim is now known as Andre_Gondim-afk