| === yofel_ is now known as yofel | ||
| pmatulis | kom | 03:32 |
|---|---|---|
| pmatulis | i'm settin up a (jaunty) server for building packages for multiple releases and archs. what is the recommended way for doing that? | 03:49 |
| RAOF | pmatulis: Both sbuild & pbuilder will do what you want, depending on how many archs "multiple" is. | 03:50 |
| pmatulis | RAOF: yet i do not want to install dependencies on my main host, i'd rather keep them contained. is schroot (+pbuilder) what i'm after? | 03:51 |
| pmatulis | RAOF: archs would just be x86_32 and x86_64 | 03:53 |
| hyperair | sbuild and pbuilder both install dependencies in a chroot and build the package | 03:53 |
| RAOF | pmatulis: Yeah, both sbuild & pbuilder build in a chroot. | 03:53 |
| adama | what does x86_32 mean? | 03:53 |
| hyperair | after building, the temporary installation is wiped clean | 03:53 |
| adama | i386? or more specific? | 03:54 |
| RAOF | adama: It's a longhand, nonstandard way of writing IA32 | 03:54 |
| adama | that doesn't answer my question | 03:54 |
| adama | does it mean i386, or something more specific? | 03:54 |
| RAOF | Yes, it means what Debian & Ubuntu call "i386" | 03:54 |
| pmatulis | hmm, so as a test i tried to build a gnome app on my server and naturally i'm missing libraries | 03:55 |
| pmatulis | if i install them they are going to be on my system permanently no? | 03:56 |
| RAOF | Yes. | 03:56 |
| pmatulis | there you go, i'd rather avoid that | 03:56 |
| RAOF | So, you build the package with pbuilder or sbuild, which will build in a chroot for you. | 03:56 |
| adama | if only we had some mechanism to remove installed packages... | 03:57 |
| pmatulis | RAOF: yes, i used pdebuild | 03:57 |
| RAOF | pmatulis: Then your package is likely buggy. | 03:57 |
| RAOF | pbuilder will install all the dependencies you list as build-dependencies; if you package doesn't build because of a missing dependency, then you need to add it :) | 03:58 |
| pmatulis | RAOF: ok, and they are listed where? | 03:59 |
| RAOF | In particular, pbuilder cannot automatically determine what dependencies are required; I suspect the halting problem is reducible to that problem :) | 03:59 |
| RAOF | pmatulis: debian/control - Build-Depends | 03:59 |
| pmatulis | RAOF: ok, will look | 03:59 |
| lifeless | and build-depends-indep | 03:59 |
| pmatulis | RAOF: btw, i originally wanted sbuild but i got an error about a missing module (dm_snapshot?) | 04:00 |
| RAOF | Yeah, but hardly anyone has any build-depends-indep. Arch-indep languages are, apparently, for the weak. | 04:00 |
| RAOF | pmatulis: That requires that you're using lvm, and have a bunch of free space in one of your VGs; unless you've deliberately set up your system for it, it's unlikely that you'll have accidentally got something that works. | 04:01 |
| pmatulis | RAOF: yes, i had space on my vg | 04:02 |
| RAOF | I think that mk-sbuild-lv.sh from ubuntu-dev-tools will actually load dm_snapshot if necessary. | 04:03 |
| RAOF | But I no longer use sbuild, because I've found it easier to build in a tmpfs with pbuilder. | 04:04 |
| pmatulis | RAOF: ok, thanks for the tips | 04:09 |
| pmatulis | RAOF: sorry, but the missing deps are indeed listed in the control file | 04:15 |
| RAOF | Then it's time for you to post a buildlog & the control file to a pastebin. | 04:16 |
| pmatulis | RAOF: http://pastebin.ca/1683208 | 04:21 |
| RAOF | pmatulis: Aaah. You don't have dpatch installed. Since this is required when building a source package, you must install it. | 04:22 |
| pmatulis | RAOF: hmm | 04:22 |
| * RAOF has another look at that control file, and wonders what happened in dpatch version 1.21 | 04:23 | |
| pmatulis | k, something is happening over here :) | 04:25 |
| mrooney | haha, lintian told me that both my postinst script was empty and ignored errors | 05:58 |
| mrooney | those warnings seem a little silly together | 05:58 |
| lifeless | plausible ;) | 06:00 |
| mannyv | StevenK, around? | 06:30 |
| === Lutin__ is now known as Lutin | ||
| StevenK | mannyv: Somewhat | 06:41 |
| mannyv | StevenK, I have modified my local version of requestsync so that I can specify a build log as an attachment when using the launchpad api, is that a patch you would be interested in? | 06:44 |
| mannyv | also i have modified grab-merge a little because it would sometimes try and grab the same source tar file several times if there are multiple entries for it in REPORT, now it checks to make sure the file doesnt exist before downloading | 06:46 |
| StevenK | To be honest, I don't maintain requestsync, it's maintained in a bzr branch, so I would make your changes in a branch and request a merge | 06:48 |
| mannyv | oh ok for some reason i had the impression it was you | 06:49 |
| mannyv | ok well i was going to do that i just figured i would scope out interest first, but I guess I can do it in the opposite order =) | 06:50 |
| mannyv | now im off to bed, good night | 06:50 |
| fabrice_sp | Hi. buildX versions will be autosync in lucid, right? | 07:13 |
| RAOF | Should be, yes. IIRC those are special-cased by the autosync. | 07:14 |
| fabrice_sp | that was also my impression. Will invalidated bug 486393 then. Thanks RAOF | 07:15 |
| ubottu | Launchpad bug 486393 in libsfml "Sync libsfml 1.5+repack1-2 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/486393 | 07:15 |
| dholbach | good morning | 07:59 |
| === dholbach_ is now known as dholbach | ||
| \sh | moins | 08:38 |
| siretart` | hi \sh | 08:44 |
| === noodles775_ is now known as noodles775 | ||
| ghostcube | https://bugs.launchpad.net/bugs/466935 | 08:59 |
| ubottu | Launchpad bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,Triaged] | 08:59 |
| ghostcube | anyone able to check this | 08:59 |
| ghostcube | still there and nothing changed | 09:00 |
| micahg | ghostcube: triaged means it's ready for a developer to look at, not that it's fixed | 09:00 |
| ghostcube | micahg: i know | 09:18 |
| ghostcube | i meant nothing changed in my settings | 09:18 |
| micahg | ghostcube: you'll want to check in #ubuntu-kernel | 09:20 |
| ghostcube | heh i had bothered them too i just thought anyone can confirm this | 09:20 |
| ghostcube | on an logitech | 09:20 |
| micahg | ghostcube: one of the maintainers already confirmed | 09:20 |
| micahg | that's why it was reopened | 09:20 |
| ghostcube | :) | 09:21 |
| === asac_ is now known as asac | ||
| AnAnt | LucidFox: Hello, did you try TL2009 ? | 11:10 |
| LucidFox | I did, yes. | 11:10 |
| AnAnt | how did it go with you ? | 11:10 |
| LucidFox | I still need to download texlive-latex-extra to verify my test document. It wants a .sty file apparently present there. | 11:11 |
| AnAnt | I see | 11:11 |
| AnAnt | I found that epstopdf is gone ! | 11:11 |
| LucidFox | It compiled with the official distribution before, so I'll compare the output with the Debian version. | 11:12 |
| LucidFox | Weird, I have epstopdf installed. | 11:12 |
| AnAnt | did you upgrade texlive-extra-utils ? | 11:12 |
| LucidFox | I didn't have the old texlive installed by default. | 11:13 |
| AnAnt | hmm, wierd | 11:13 |
| LucidFox | sikon@maia-desktop:~$ dpkg -S `which epstopdf` | 11:13 |
| LucidFox | texlive-font-utils: /usr/bin/epstopdf | 11:13 |
| LucidFox | sikon@maia-desktop:~$ dpkg -s texlive-font-utils | grep Version | 11:13 |
| LucidFox | Version: 2009-1 | 11:13 |
| AnAnt | ah, ok | 11:13 |
| AnAnt | thanks | 11:14 |
| LucidFox | Is there a more intuitive way to open manpages in yelp than Alt-F2 -> yelp man:<topic>? | 11:15 |
| highvoltage | (I guess "typing 'man topic' into a terminal" is not what you want to hear) | 11:16 |
| AnAnt | can you do a: dpkg -S `which texdoc` ? | 11:16 |
| LucidFox | highvoltage> I prefer GUI. | 11:16 |
| LucidFox | texlive-base: /usr/bin/texdoc | 11:17 |
| slytherin | LucidFox: type man topic in the search field in yelp. | 11:17 |
| LucidFox | I know about that, but yelp needs to be started for that. :) | 11:18 |
| LucidFox | When I just type man:<topic> in Alt-F2, yelp says that man:///topic cannot be opened. | 11:18 |
| slytherin | LucidFox: oh, so you want yelp to register a url handler for manpages? | 11:19 |
| LucidFox | It already is, just bugged, apparently. | 11:19 |
| LucidFox | At least from Alt-F2. It opens from Firefox without problems. | 11:20 |
| LucidFox | Looks like a bug in gnome-panel. | 11:20 |
| hyperair | gnome-help man:///irssi | 11:22 |
| hyperair | indeed that is | 11:22 |
| highvoltage | YDdraigGoch: I think you mean gnome-help man:irssi ? | 11:24 |
| highvoltage | sorry, I aimed that at hyperair | 11:24 |
| hyperair | highvoltage: sorry, i wasn't clear. | 11:24 |
| hyperair | highvoltage: i mean that's what gnome-panel launched. | 11:25 |
| hyperair | highvoltage: try it. alt+f2, type man:something, and then with yelp still open, ps -ef | grep gnome-help | 11:25 |
| hyperair | highvoltage: gnome-panel is adding unnecessary /s | 11:25 |
| highvoltage | hyperair: ah I see | 11:26 |
| AnAnt | LucidFox: did you try hyperref package ? | 11:26 |
| * LucidFox shakes her head | 11:26 | |
| AnAnt | ok | 11:29 |
| LucidFox | Shame unicode-math isn't distributed. | 11:31 |
| slytherin | Can any java expert help to solve this problem - http://paste.ubuntu.com/326018/ ? | 11:45 |
| Crusher` | slytherin: it doesn't know what method you are trying to call, so you have to cast null to either the certificate or codesigner so it knows which method you are trying to use | 12:01 |
| LucidFox | slytherin> There are two overloaded methods, and the compiler doesn't know which one to use. | 12:02 |
| LucidFox | What's with autosync? | 12:07 |
| LucidFox | Some packages seem to never be updated. | 12:07 |
| siretart` | LucidFox: there is a blacklist for the auto-sync. perhaps its listed there? | 12:17 |
| LucidFox | I mean in lucid. dbus-c++ and x11vnc, for example, are not even in NEW. | 12:18 |
| LucidFox | Even though they were added to Debian before the lucid cycle, and they're not in the blacklist. | 12:18 |
| slytherin | LucidFox: Crusher`: I understood that. But I don't know how to cast null to some type. | 12:20 |
| Crusher` | slytherin: new CodeSource(thisURL, (java.security.cert.Certificate[]) null); | 12:21 |
| slytherin | Crusher`: Oh, that simple. I didn't know that. :-( | 12:21 |
| Crusher` | slytherin: hehe, its all part of learning :) | 12:21 |
| siretart` | LucidFox: you should probbly ask that pitti or seb128 in #ubuntu-devel | 12:31 |
| * LucidFox nods | 12:31 | |
| siretart` | LucidFox: if these packages are already in dpkg source v3 format, then that's the reason | 12:31 |
| * LucidFox checks | 12:32 | |
| LucidFox | Could be, didn't check. | 12:32 |
| LucidFox | dbus-c++ isn't. I'll ask. | 12:33 |
| LucidFox | Neither is x11vnc | 12:34 |
| LucidFox | On an unrelated note, why is ttf-droid not in Debian? License issues? | 12:34 |
| LucidFox | Hmm, there's an ITP for it... *reads* | 12:35 |
| geser | was the import of new packages in Debian already run for lucid? | 13:02 |
| siretart` | geser: please ask in #ubuntu-devel | 13:06 |
| geser | I'll let the archive admins clear the current NEW queue first before asking for more | 13:19 |
| flower | how do I backport packages for 64bit on 32bit? | 13:21 |
| \sh | for i in i386 amd64 ; do build lucid $i my-package_verson-release.dsc ; done ,) | 13:25 |
| geser | flower: you have a 32bit system and want to build a package for a 64bit system? | 13:25 |
| flower | geser: right | 13:25 |
| geser | you need a 64bit pbuilder (or similar where you can build 64bit packages) and your kernel needs to be able to run 64bit programs which the 32bit kernel can't | 13:27 |
| ghostcube | geser: i may check this evening the source aof arista video transcoder | 14:15 |
| ghostcube | to see wheere it calls this stupid icon | 14:15 |
| ghostcube | and if i can set an ghost one | 14:15 |
| ghostcube | have i mentioned i luv the one packaged libxine with jackd support in his ppa | 14:18 |
| ghostcube | :D | 14:18 |
| === sharms_ is now known as sharms | ||
| bddebian | Heya gang | 15:34 |
| siretart` | hi bddebian | 15:36 |
| bddebian | Heya siretart | 15:37 |
| fmarl | hi guys, I need to talk to someone regards pyclutter-gtk and pyclutter-gst packaging. | 15:46 |
| Elbrus | fmarl: you should just state your question, nobody now knows if they can help you... | 15:47 |
| fmarl | With pyclutter 1.0 they need to be packaged separately | 15:47 |
| fmarl | there's a bug: https://bugs.launchpad.net/ubuntu/+source/pyclutter/+bug/437578 | 15:48 |
| ubottu | Launchpad bug 437578 in pyclutter "python-clutter-gtk needs to be packaged seperately" [Undecided,New] | 15:48 |
| fmarl | I've made some work to get it fixed but i need some help. | 15:48 |
| Elbrus | you do this for Debian? | 15:49 |
| Elbrus | see comment 1 | 15:49 |
| fmarl | Elbrus, no i'm just a programmer for a project that needs them | 15:50 |
| dtchen | bddebian: hi, do you have any opposition to just backporting the ALSA and pulse bits (src/audio/{alsa,pulse}) from 1.2.14 into the existing libsdl source package? | 15:50 |
| fmarl | project name is Entertainer | 15:50 |
| Elbrus | so is this private packaging or for Ubuntu? | 15:50 |
| fmarl | Elbrus, the goal should be to push these packages at least to Ubuntu | 15:51 |
| Elbrus | it is better to start at Debian | 15:52 |
| fmarl | Elbrus, yeah I know. | 15:52 |
| Elbrus | it doesn't even have this bug reported as far as I can tell | 15:52 |
| bddebian | dtchen: Probably not | 15:52 |
| Elbrus | so whatever you figure out for the packaging, at least (also) submit it in the debian bugtracker (and link launchpad to it) | 15:53 |
| fmarl | Elbrus, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505918 | 15:53 |
| ubottu | Debian bug 505918 in python-clutter "python-clutter: cannot use cluttergtk" [Important,Fixed] | 15:53 |
| Elbrus | so now your real question I guess | 15:53 |
| dtchen | bddebian: anyhow I already did it while chasing an alsa-plugins bug :-) | 15:53 |
| dtchen | bddebian: didn't ask for it to be sponsored into Ubuntu yet because I wanted to check with you about plans for libsdl in Debian | 15:54 |
| dtchen | cos it, uh, explodes the delta, understandably | 15:54 |
| Elbrus | fmarl: is there already a RFP bug? | 15:54 |
| fmarl | Elbrus, I don't know,probably not | 15:55 |
| Elbrus | and you are packing those? | 15:56 |
| fmarl | Elbrus, mine is an attempt | 15:57 |
| fmarl | Elbrus, https://code.launchpad.net/~francesco-marella/+junk/pyclutter-gtk | 15:57 |
| fmarl | https://code.launchpad.net/~francesco-marella/+junk/pyclutter-gst | 15:57 |
| bddebian | dtchen: Well I'm up for just about anything but the other members of the "team" aren't all that responsive. :( | 15:58 |
| Elbrus | fmarl: better start asking your real question I guess... I see the code but what is the problem | 15:59 |
| fmarl | Elbrus, there's someone here that can take this job? | 16:02 |
| Elbrus | which job, helping you? | 16:02 |
| Whoopie | jdong, siretart: Hi, now that we have a new VLC in lucid, could we do the SRU for karmic? | 16:02 |
| fmarl | job = review my work or start from scratch, submit it to debian | 16:02 |
| fmarl | Elbrus, sorry i'm not native-english | 16:02 |
| Elbrus | you could attach your packaging to the launchapd bug and mark it as a patch | 16:03 |
| Elbrus | better, if you are willing to maintain it, file a bug at debian (a ITP against the wnpp package) | 16:04 |
| fmarl | Elbrus, ok i'll do it | 16:04 |
| Elbrus | and search for a sponsor at mentors.debian.net / mentors@lists.debian.org | 16:04 |
| Elbrus | (please read the documentation at mentors.d.n first) | 16:05 |
| fmarl | Elbrus, to much work for a lazy programmer.. :p | 16:05 |
| Elbrus | well, you SHOULD file a bug at Debian than with RFP against wnpp with the packaging attached) | 16:05 |
| Elbrus | at least | 16:06 |
| Elbrus | and link the debian and ubuntu bugs to eachother | 16:06 |
| fmarl | Elbrus, ah ok | 16:06 |
| Elbrus | np | 16:06 |
| fmarl | Elbrus, thanks. | 16:06 |
| siretart` | Whoopie: I'm not in the SRU team, and I don't have the overview what bugs have been closed from 1.0.2 to 1.0.3 | 16:07 |
| Whoopie | siretart`: I'm talking about https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/481448 | 16:09 |
| ubottu | Launchpad bug 481448 in vlc "VLC lacks build-dep on libupnp3-dev" [Undecided,New] | 16:09 |
| jdong | Whoopie: prep a debdiff for review and I'll take a look in an hour | 16:11 |
| Whoopie | jdong: it's already in the bug report | 16:11 |
| jdong | you've got an ACK | 16:13 |
| jdong | edit the description of the bug with SRU verification procedures | 16:13 |
| Whoopie | jdong: where to find an example? | 16:16 |
| jdong | Whoopie: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure | 16:23 |
| Whoopie | jdong: do I have to upload it to karmic-proposed? | 16:34 |
| ScottK | Whoopie: You need a MOTU to do that. | 16:36 |
| Whoopie | ScottK: ok, thanks | 16:43 |
| waver_ | hi guys, I want to push this package ( http://revu.ubuntuwire.com/p/hiawatha ) to Ubuntu | 17:01 |
| ScottK | waver_: If you are really interested in the package, you might want to consider getting it into Ubuntu via Debian and maintaining it there. See mentors.debian.net for details on how. | 17:03 |
| waver_ | Thanks ScottK, I'll have a look | 17:04 |
| ari-tczew | 8 requests left to 200 bugs in ubuntu-archive! yes! | 19:01 |
| AndrewGee | Hi all. Any MOTUs available to review my package in REVU, and hopefully give the second advocation? http://revu.ubuntuwire.com/p/gpxviewer - Thanks :) | 19:08 |
| dlm | hi all | 19:09 |
| dlm | What is the requierement for became a MOTU ? | 19:09 |
| ScottK | AndrewGee: If you are interested in maintaining the package, you might consider getting it into Ubuntu via Debian. See mentors.debian.net for details. | 19:14 |
| ari-tczew | dlm: https://wiki.ubuntu.com/MOTU | 19:15 |
| dlm | ari-tczew: Thanks | 19:16 |
| ScottK | dlm: Also https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu%20Developers%20%28MOTU%29 | 19:16 |
| dlm | Scottk: thanks for the link | 19:18 |
| === nxvl_ is now known as nxvl | ||
| * jdong scratches his head at the addition of a patchsys in a SRU debdiff. | 20:04 | |
| ajmitch | that's not nearly as bad as switching to dh7-style debian/rules in a SRU | 20:05 |
| jdong | hahahahaha | 20:05 |
| jdong | well I suppose the patchsys won't hurt too much | 20:06 |
| ajmitch | usually it's only a couple of lines, but it's still not the best thing to do :) | 20:06 |
| jdong | yup | 20:06 |
| ScottK | IIRC adding a patch system is explicitly discouraged in SRUs. | 20:06 |
| ajmitch | something that the 3.0 (quilt) format is meant to help with once it's supported in LP :) | 20:06 |
| ScottK | ajmitch: Right, any patch system you want as long as it's quilt. | 20:07 |
| jdong | :) | 20:07 |
| ajmitch | exactly | 20:07 |
| ajmitch | though to be fair, there looks to be little interaction with quilt itself that you need to do | 20:07 |
| ScottK | If there's no existing patch system, I think that's correct. | 20:08 |
| ScottK | Although if you want to break your work into more than one patch, the way you do it is rebuild the source package. | 20:08 |
| ScottK | Seems a bit heavy to me. | 20:09 |
| * ajmitch stabs fetchmail | 20:10 | |
| ajmitch | I should really redirect my mail through somewhere more reliable | 20:10 |
| highvoltage | hey ajmitch, how are things? | 20:16 |
| ajmitch | good, how are you? | 20:17 |
| fabrice_sp | fcuk112, there? | 20:21 |
| ari-tczew | anyone knows, whether can I do NMU in Debian only for update/add watch file? | 20:22 |
| Laney | no | 20:23 |
| ari-tczew | pfff sucks :P | 20:24 |
| ajmitch | that's a pretty trivial change, NMUs should be for release-critical bugs | 20:24 |
| highvoltage | ajmitch: also doing good thanks | 20:25 |
| ari-tczew | but maintainers doesn't care a lot of them packages | 20:25 |
| ajmitch | highvoltage: so did you manage to get to the latest UDS? :) | 20:33 |
| av` | ari-tczew, yes, but doing an NMU for a watch file will probably get you | 20:37 |
| av` | flamed | 20:37 |
| ScottK | And whoever would sponsor it would get roasted too. | 20:41 |
| ari-tczew | [19:56] <Laney> adding bureaucracy is not a way to encourage contribution | 20:41 |
| ScottK | File a bug with a patch | 20:41 |
| ari-tczew | ;-] | 20:41 |
| Laney | debian has package maintainers | 20:42 |
| ScottK | Debian has a different maintenance model than Ubuntu and NMUs for trivial fixes doesn't make sense | 20:42 |
| azeem | if the package is in collab-maint, you can checkin a fix I guess | 20:42 |
| ScottK | Yep. | 20:43 |
| ari-tczew | if Debian has a policy such as Ubuntu, we could do a lot for DEHS statistics | 20:46 |
| ajmitch | perhaps you could argue for it on debian-devel | 20:48 |
| cjwatson | that sounds guaranteed to go badly ... | 20:49 |
| ajmitch | it'd have about as much effect as discussing it here :) | 20:50 |
| * jdong hopes ajmitch meant that in sarcasm ;-) | 20:50 | |
| jdong | the first statement, that is | 20:50 |
| Stormx2 | Hi guys. Can I ask why grip is no-longer packaged? | 20:53 |
| ajmitch | was grip ever ported to gtk+ 2.0? | 20:53 |
| highvoltage | ajmitch: I participated remotely, US visas take too long :/ | 20:54 |
| ajmitch | grip was removed from debian back in february, I believe removals from debian like that happen in ubuntu as well so that we don't carry too many old & unmaintained packages | 20:55 |
| fcuk112 | fabrice_sp: i am here. | 21:02 |
| fabrice_sp | fcuk112, about the libavg upgrade: why did you deleted the building of testplayer? | 21:05 |
| fcuk112 | fabrice_sp: when i did pbuilder build, it was failing because it ran an automatic test which required the framebuffer. | 21:06 |
| fabrice_sp | fcuk112, it wasn't possible to desactivate the test instead of desactivating the bianre? | 21:07 |
| Stormx2 | ajmitch: grip was gtk2 afaik | 21:07 |
| fcuk112 | fabrice_sp: i could not find where to disable the test. | 21:07 |
| fabrice_sp | also, I did some modifications, and now, I'm getting an error: dpkg-shlibdeps: error: couldn't find library avg.so.0 needed by debian/python-libavg/usr/lib/libColorNode.so.0.0.0 . Did yo uget this one also? | 21:08 |
| fabrice_sp | anyway, I'm building the package with your debdiff right now (wihout my modifications) | 21:08 |
| fcuk112 | fabrice_sp: yea, i got the same error when i built via pbuilder, i got around it by adding to .pbuilderrc: export LD_LIBRARY_PATH=/usr/lib/python2.6/dist-packages/libavg:$LD_LIBRARY_PATH | 21:11 |
| fabrice_sp | fcuk112, ok: so you should have added that. or something similar in the debian/rules file | 21:12 |
| fabrice_sp | also, lintian is complaining about a missing README.source. Please add it, and update the Standards-version to 3.8.3 | 21:15 |
| ari-tczew | fabrice_sp: is it not a Debian's package? | 21:15 |
| fabrice_sp | ari-tczew, it's an orphaned Debian package | 21:16 |
| fabrice_sp | why? | 21:16 |
| ari-tczew | we could not update Standards-Version if package is delivering by Debian first, right? | 21:18 |
| ari-tczew | but if it's orphaned package, ok | 21:18 |
| fcuk112 | fabrice_sp: how to run the lintian command? i just installed it. | 21:18 |
| ari-tczew | debuild -us -uc and at the end you should see warnings | 21:19 |
| fabrice_sp | or lintian <package.dsc> | 21:19 |
| fcuk112 | fabrice_sp: also i am not sure where to update standards-version. | 21:19 |
| fabrice_sp | ari-tczew, we should not update the standard-versions of a debian pacakge, but in this case, it will become an ubuntu version (0ubuntu1), so yes | 21:20 |
| fcuk112 | fabrice_sp: when i run lintian on the dsc i get: internal error: command failed with error code 2 | 21:20 |
| fcuk112 | warning: could not unpack package to desired level | 21:20 |
| fcuk112 | warning: skipping check of source package libavg | 21:20 |
| fabrice_sp | fcuk112, could you paste the full command you are running? | 21:22 |
| fcuk112 | fabrice_sp: lintian libavg_0.9.0-0ubuntu1.dsc | 21:23 |
| ari-tczew | debian/control there you can bump Standards-Version | 21:23 |
| fcuk112 | ari-tczew: thanks, ok i updated it. | 21:25 |
| fabrice_sp | fcuk112, can you pastebin the content of the dsc file? | 21:25 |
| fabrice_sp | to be able to update the standards-version, you need to add a debian/REAME.source file, as there is a patch system | 21:26 |
| fcuk112 | http://pastie.org/711880 | 21:30 |
| fcuk112 | fabrice_sp: sorry what would the contents of debian/README.source be? | 21:31 |
| av` | fabrice_sp, I don't think a README.Source is really needed | 21:31 |
| fabrice_sp | fcuk112, the dsc file seems good | 21:32 |
| av` | if the patch system is either dpatch or quilt | 21:32 |
| ari-tczew | av' +1 | 21:32 |
| fabrice_sp | av`, even with source format v1? The Debian policy still says that it's required | 21:33 |
| av` | fabrice_sp, looks to me that paste / copying the dpatch / quilt example files is pretty useles | 21:33 |
| av` | fabrice_sp, yes, someone proposed to remove its requirement for normal | 21:33 |
| av` | patch systems already | 21:33 |
| ari-tczew | what is connexion between Standards-Version and patchsystem? | 21:33 |
| fabrice_sp | av`, I know it's useless, but for the moment, it still required by Debian policy, no? | 21:34 |
| av` | actually the newer standards introduce new policies to follow | 21:34 |
| av` | and one of them is the patch-system one fabrice_sp told you before | 21:34 |
| av` | e.g adding a readme.source | 21:34 |
| fabrice_sp | it was added in 3.8.3? | 21:35 |
| * fabrice_sp looks at Debian polciy | 21:35 | |
| av` | fabrice_sp, yes, it is, but since the package won't go to debian for now, I wouldnt add it | 21:35 |
| av` | fabrice_sp, don't remember | 21:35 |
| mannyv | im looking at a package that we have had to merge for about 4 releases because the source tar ball is missing a COPYING file and we keep adding it in. | 21:36 |
| mannyv | is this something I should talk with the debian maintainer about adding as well? | 21:37 |
| mannyv | and maybe upstream or ? | 21:37 |
| fabrice_sp | the README.source is recommended, not mandatory, so fcuk112, forget the READE.source file | 21:37 |
| av` | fabrice_sp, yes | 21:37 |
| fabrice_sp | mannyv, Should be upstream | 21:37 |
| av` | fabrice_sp, it's a warning not an error | 21:37 |
| av` | fabrice_sp, so it's up to the original maintainer | 21:37 |
| fabrice_sp | av`, I know, but I've seen warnings becoming error in later version | 21:38 |
| fabrice_sp | in this case, it's ok | 21:38 |
| av` | I don't think this will ever be an error | 21:38 |
| av` | :) | 21:38 |
| fabrice_sp | not with source format V3 :-) | 21:38 |
| av` | if not dak would reject tons of packages since it has lintian-based | 21:38 |
| av` | auto-rejects now | 21:38 |
| fabrice_sp | but I have to say that it should be mandatory for some non standard pacakges | 21:38 |
| fabrice_sp | right | 21:38 |
| av` | but yes, for particular packages would be nice to have | 21:39 |
| fcuk112 | ok | 21:39 |
| av` | especially for NMUers | 21:39 |
| fabrice_sp | right | 21:39 |
| * mannyv swims upstream | 21:39 | |
| fabrice_sp | or packages with source tarball inside the tarball | 21:39 |
| fabrice_sp | :-/ | 21:40 |
| av` | like mozilla-extensions then | 21:41 |
| av` | that ships a .xpi file into the tar.gz :) | 21:41 |
| av` | but we have tools for that :) | 21:41 |
| === highvolt1ge is now known as highvoltage | ||
| fabrice_sp | av`, sure about the tools, but for a newcommer to the package, patching it as... hmmm....complex | 21:42 |
| av` | fabrice_sp, true, with tools I meant something like mozilla-devscripts | 21:43 |
| av` | don't know if you ever worked with them | 21:43 |
| fabrice_sp | av`, ohh yes :-) no: only saw them from far away | 21:43 |
| av` | for mozilla-extensions-related-stuff of course | 21:43 |
| * fabrice_sp avoids mozilla :-) | 21:43 | |
| av` | good for you :) | 21:43 |
| fabrice_sp | lol | 21:44 |
| fabrice_sp | latelly, I only have time to review the sponsoring queue... :-) | 21:44 |
| * fabrice_sp should take care of his sync/merges... | 21:45 | |
| av` | fabrice_sp, cleaning up the sponsoring queue is something great | 21:48 |
| av` | so that contributors don't have their work dropped somewhere | 21:48 |
| av` | so good work :) | 21:48 |
| fabrice_sp | av`, it's great: it also a way to learn a lot of new stuff (and discover new packages) :) | 21:49 |
| fabrice_sp | mannyv, about Bug #486181 | 21:49 |
| ubottu | Launchpad bug 486181 in piklab "Please Merge piklab 0.15.5-1 from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/486181 | 21:49 |
| mannyv | fabrice_sp, yeah? | 21:50 |
| fabrice_sp | shouldn't we wait one week, when 0.15.7 lands in testing? And avoid doing 2 merges? | 21:50 |
| fabrice_sp | (even if it's an easy one :-) ) | 21:50 |
| * mannyv has been cherry picking the easy ones | 21:51 | |
| mannyv | yeah that makes sense | 21:52 |
| mannyv | i didn't know that the new 0.15.7 would land in testing in 2 weeks | 21:52 |
| mannyv | how do you know that so I can know in the future =) ? | 21:52 |
| av` | mannyv, check the PTS :) | 21:52 |
| av` | mannyv, it has all informations you may need | 21:53 |
| fabrice_sp | a package in unstable, if everything is ok, lands in testing 10 days after | 21:53 |
| fabrice_sp | PTS is your friend, yes :-) | 21:53 |
| av` | mannyv, subscribe to a specific package and you gonna receive everything into your mail box! | 21:53 |
| av` | sweet! | 21:53 |
| mannyv | i checked in PTS | 21:53 |
| fabrice_sp | Too young, only 4 of 10 days old | 21:54 |
| mannyv | i jsut didint know when it moved from unstable to testing i guess | 21:54 |
| av` | mannyv, which one? | 21:54 |
| fabrice_sp | http://packages.qa.debian.org/p/piklab.html in this case | 21:54 |
| mannyv | i see now, i just didnt know to look for that | 21:54 |
| av` | yes, wanted to see what he meant for PTS | 21:54 |
| fabrice_sp | :-) | 21:55 |
| mannyv | av`, that is what i meant | 21:55 |
| fabrice_sp | one day for agg :-) | 21:55 |
| av` | fabrice_sp, already one day? | 21:55 |
| av` | time pass so fast | 21:55 |
| fabrice_sp | av`, my bad: only 1 of 10 days :-D | 21:55 |
| mannyv | so does that mean if there is a higher version in unstable we should just always wait, provided we 10 days before DIF? | 21:56 |
| av` | fabrice_sp, lol | 21:56 |
| av` | looked to me a bit strange that was going to migrate already | 21:56 |
| fabrice_sp | mannyv, if no serious bugs appears during that 10 days, yes | 21:56 |
| av` | all squeeze goals should be ok | 21:57 |
| av` | to migrate | 21:57 |
| mannyv | ok that is good to know =) | 21:57 |
| fabrice_sp | just too tired! That libavg upgrade + another merge killed me :-) | 21:57 |
| av` | if the packages FTBFS on a squeeze release goal arch it won't migrate :) | 21:57 |
| fabrice_sp | bed time. Bye all! | 22:00 |
| av` | have a good night :) | 22:04 |
| === cody-somerville_ is now known as cody-somerville | ||
| RoAkSoAx | hey guys. I;m merging a package and in Ubuntu we are adding -dev. So, since we are modifying configure.in, I have to rerun autogen.sh. So, if I'm already running autogen.sh do I have to add automake and libtool to Build-Deps? | 22:32 |
| azeem | RoAkSoAx: does it build if you don't? | 22:35 |
| RoAkSoAx | azeem, yes I believe so, but it shows a warning that there's no automake | 22:36 |
| kklimonda | RoAkSoAx: the official way as far as I can tell is to regenerate locally and then create patch for source | 22:37 |
| kklimonda | this way you don't have to add any additional dependencies | 22:37 |
| ari-tczew | yes! seb128 is working on syncs! MOTU go ahead! | 22:37 |
| RoAkSoAx | kklimonda, so I would just run autogen.sh again and then not add the dependecies on libtool and automake? | 22:38 |
| RoAkSoAx | kklimonda, or... adding the dependencies, and not running autogen.sh? | 22:39 |
| kklimonda | RoAkSoAx: again? you run it once, create diff between regenerated source and clean one and add it to debian/patches/ | 22:41 |
| RoAkSoAx | kklimonda, yeah but... do I still have to add automake and libtool as build-deps? | 22:44 |
| kklimonda | no, the whole point of creating a patch locally is to avoid those dependencies | 22:44 |
| av` | RoAkSoAx, no | 22:44 |
| av` | RoAkSoAx, you gonna apply a patch, so no additional deps are needed | 22:45 |
| av` | apart quilt or dpatch or whatever you use | 22:45 |
| av` | if you use quilt, I would suggest you to give a try to quilt sheel | 22:45 |
| av` | * quilt shell | 22:45 |
| RoAkSoAx | av`, i was applying it directly because debian dropped the patchsystem and I'm not introducing one again | 22:45 |
| av` | don't know how sane it is applying an autotools patch directl | 22:46 |
| kklimonda | it's not | 22:46 |
| kklimonda | applying anything outside of debian/ subdirectory currently isn't really sane imho | 22:47 |
| av` | kklimonda, agreed, apart minor changes I'm with you | 22:47 |
| av` | minor = really minor changes | 22:47 |
| RoAkSoAx | so what would be your recommendation in this particular case? | 22:48 |
| kklimonda | well, autotools related patches are huge so I'd restore patch system | 22:49 |
| av` | adding a patch system | 22:49 |
| av` | and using quilt shell | 22:49 |
| kklimonda | (the patch for transmission is over 1MB) | 22:49 |
| av` | if you want your life to be easier | 22:49 |
| RoAkSoAx | ok cool, thanks for the tip :) | 22:50 |
| av` | np :) | 22:50 |
| === stochastic_ is now known as stochastic | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!