[00:26] <quentusrex> Anyone around for some packaging advice? I'm trying to learn how to handle conffiles special... But I can't figure out how to tell the packager that these files are conffiles...
[00:36] <micahg> quentusrex: have you seen this? https://wiki.ubuntu.com/PackagingGuide/HandsOn
[00:38] <quentusrex> micahg, I'll read it now
[00:47] <quentusrex> micahg, where can I get info on what folders different files should be in?
[00:48] <micahg> quentusrex: this should be for the most part: http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html
[00:49] <micahg> let me see if I can find an ubuntu specific one
[00:50] <micahg> quentusrex: here's the complete apckaging guide with lots of examples: https://wiki.ubuntu.com/PackagingGuide/Complete
[00:52] <quentusrex> will pbuilder output properly built files? or will it just test?
[00:53] <maco> yes itll output debs
[00:53] <maco> i have my pbuilders in ~ so the debs end up in ~/pbuilder/result/
[00:54] <quentusrex> ok
[00:55] <quentusrex> launchpad seems to actually have some resources now
[00:55] <quentusrex> for the last few weeks it has taken many hours to get a package to start building...
[00:56] <quentusrex> now it only took 20 minutes for the queue
[00:58] <jdong> lol don't jinx it
[00:58] <jdong> I've been racing mozilla-dailyteam-ppa for my thunderbird crack.
[00:58] <jdong> and every time my virtualized AMD64 seems to win ;-)
[01:15] <ScottK> At release time a lot of the PPA buildd's were re-purposed to be release mirrors.
[02:40] <EzraR> can you edit a dpatch with a text editor? rather would it still work after?
[02:41] <EzraR> this patch from DD does more than it says it does and I need it to do part of it but dont want all of it
[02:44] <ScottK> EzraR: If you move entire hunks or don't change the number of lines, yes, but be careful
[02:45] <RoAkSoAx> hey guys anyone know if there's a way to see in what talks someone is registered for the UDS
[02:45] <ScottK> RoAkSoAx: Look through the schedule for your name.
[02:46] <RoAkSoAx> ScottK, yeah I;m doing that but I was wondering if there;s was a way to see only the talks that I would be registered to without having to search through the schedule, but i guess there's not
[02:46] <RoAkSoAx> ScottK, anyways, at what time is the talk for the Future of MOTU?
[02:46] <ScottK> Not that I know of.
[02:46] <EzraR> ScottK: so in other words just make a new one
[02:47] <ScottK> Tuesday at Noon.
[02:47] <EzraR> ScottK: :)
[02:47] <RoAkSoAx> ScottK, awesome. thansk :)
[02:49] <maco> er, dont they get shoved around daily?
[02:49] <ScottK> They do
[02:49] <ScottK> It's just that currently that one is invisible on the schedule.
[02:50] <ScottK> (See MOTU ml)
[02:51] <maco> oh
[03:02]  * txwikinger wonders about dimap with load on demand
[03:34] <poseidon> What directory are third party programs usually compiled in on ubuntu?
[03:37] <maco> poseidon: if you compile yourself, they end up in /usr/local/bin/
[03:37] <maco> after you "sudo make install"
[03:38] <poseidon> well the src is in my home directory.  But I can use ./configure --prefix=/usr/loca/bin, right?
[03:38] <maco> if you dont set a prefix, itll end up in /usr/local/bin after you compile
[03:38] <maco> if you were to set that prefix, itd end up in /usr/local/bin/bin
[03:38] <poseidon> oh, ok
[03:39] <maco> because it automatically appends bin/ lib/ share/ etc
[03:39] <poseidon> that is starting to make a lot more sense now.  I was always wondering where binaries, data, scripts went.
[03:40] <poseidon> so binaries in bin, libraries in lib and config settings in etc.  What is share/ used for?
[03:57]  * ScottK hands poseidon http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
[03:57] <poseidon> ScottK, oooh.  Thank you very much
[03:58] <ScottK> You're welcome.
[04:05] <RoAkSoAx> vorian, are you going to the UDS?
[04:07] <vorian> RoAkSoAx: nope, dholbach and cjwatson hate me
[04:07] <vorian> :P
[04:07] <vorian> i wasn
[04:07] <vorian> 't very active for karmic
[04:08] <RoAkSoAx> vorian, yeah... that;s a shame I was really looking forward to meeting u in person
[04:09] <vorian> maybe in the spring
[04:09] <vorian> i'll work my ass off
[04:09] <vorian> :)
[04:09] <RoAkSoAx> haha same here :)
[04:10] <RoAkSoAx> ok then... next UDS it is :)
[04:11] <vorian> sure
[04:11] <vorian> plus texas sucks
[04:11] <vorian> you'll likely to get killed by some mexican drug cartel
[04:12] <vorian> they'll cut your head off and roll it into a general session
[04:12] <ScottK> I think that's only in Houston.
[04:13] <RoAkSoAx> vorian, hahaha yeah I think so..,. I;ve been recommended to go to a texan bar to see texans dance like in the movies, lol!!!
[04:13] <RoAkSoAx> ScottK, yeah that's only in Houston
[04:14] <RoAkSoAx> but I live in Miami... which it is supposed to have one of the higher crime rates
[04:14] <vorian> no, that's in el paso
[04:15] <ScottK> Ah, right.
[04:15] <vorian> RoAkSoAx: yeah, just be cautious about the hookers
[04:15] <vorian> they won't tell you there hookers until they are ready to leave, if you catch my drift
[04:16] <RoAkSoAx> vorian, hahaha yeah I know what u mean
[04:16]  * ScottK gently reminds vorian this is allegedly a family friendly channel.
[04:16] <vorian> and most ladies are connected to really big dudes who will be carrying a pistol or two
[04:17] <vorian> whoopes
[04:17] <vorian> just trying to warn him
[04:17] <vorian> Dallas/FortWorth is a wild place
[04:17] <vorian> y'all should get a group and go up to the Big Texan in Amarillo
[04:18] <ScottK> Last time I was there was on a high school trip.
[04:18] <ScottK> Let's just say that the chaperones were overmatched.
[04:18] <vorian> i have an aunt who lives in arlington
[04:18] <vorian> i'm sure
[04:19] <RoAkSoAx> the other night I was watching a TV show of detectives that have to solve crimes in 48 hours or something like that... and It was in dallas... lots of weird thing happens there...
[04:20] <vorian> depends on the area
[04:21] <RoAkSoAx> yeah well there's crime everywhere...
[04:21] <vorian> not in Soda Springs Idaho
[04:22] <RoAkSoAx> vorian, that's where u at right now?
[04:22] <RoAkSoAx> right?
[04:23] <vorian> RoAkSoAx: yup
[04:23] <vorian> we got about 4 inches of snow today
[04:23] <vorian> it was awesome
[04:23] <RoAkSoAx> vorian, alright then... my next stop Soda Springs - Idaho...
[04:23] <vorian> any time, we have plenty of room
[04:24] <vorian> these houses were about 1/2 of what they were in Ohio
[04:24] <RoAkSoAx> vorian, here in Miami is sunny, not so hot nor cold... and real state is really cheap
[04:25] <RoAkSoAx> apartments in downtown close to the beach that were 700k now are ~300k
[04:25] <vorian> $300,000
[04:25] <RoAkSoAx> yes
[04:25] <vorian> oh my
[04:26] <RoAkSoAx> still expensive though... but from 700k to 300k, that;s a big difference
[04:26] <ScottK> They'll get cheaper when global warming floods you out.
[04:26] <vorian> my house has two kitchens 6 bedrooms, hot tub, barn big peice of land 3 car garage - for less than 150k
[04:27] <vorian> same house would have been more that 2x that in Ohio
[04:27] <ScottK> 6 X that here
[04:28] <RoAkSoAx> ScottK, hahaha probably... but I have to enjoy in the meanwhile
[04:28] <vorian> i bet
[04:28] <vorian> the downside is it's a town of 4k people
[04:28] <ScottK> RoAkSoAx: As long as you didn't buy on the bottom few floors, just get a boat.
[04:28] <vorian> but we have a cool gueiser
[04:29] <RoAkSoAx> vorian, that's awesome!! I definitely gonna pay u a visit... I've heard that;s the potato state?
[04:30] <vorian> yeah man
[04:30] <vorian> our ssuper market sells 50pbs of taters for 9.99
[04:31] <vorian> we also have a spring here that is naturally carbonated
[04:32] <RoAkSoAx> ScottK, hahah hopefully i will someday!! It would be awesome to have a yacht!!
[04:32] <vorian> fosswire
[04:32] <RoAkSoAx> vorian, wow!! here everything si expensive
[04:38] <RoAkSoAx> well I'm off guys. See you vorian take care man
[04:38] <RoAkSoAx> ScottK, I guess I'll see you tomorrow or monday
[04:38] <RoAkSoAx> night
[04:43] <vorian> see ya
[05:09] <EzraR> Add ubuntu_hardening.dpatch patch, fix FTBFS caused by -D_FORTIFY_SOURCE=2
[05:10] <EzraR> is that a special case or cause it to be FTBFS under normal setup
[05:16] <ScottK> We need to keep that patch.  The hardening is standard for us.
[05:19] <EzraR> ok
[07:20] <fcuk112> https://bugs.edge.launchpad.net/ubuntu/+source/xdg-user-dirs/+bug/381490 does the patch look ok? how do i know if a package should be sponsored by main or universe?
[07:20] <fcuk112> also, can someone tell me what to do with https://bugs.edge.launchpad.net/ubuntu/+source/libavg/+bug/474004?  when i apt-get source i get version 0.8 back, so i'm not sure if i can just post a patch.
[07:23] <fabrice_sp> fcuk112, main or universe: look at the package page
[07:24] <fabrice_sp> about libavg: you can get 0.8 source, run uscan --verbose to see if it fetch the 0.9 source, and un uupdate on the tarball to generate the 0.9 source directory
[07:24] <fcuk112> which package page?
[07:24] <fabrice_sp> https://bugs.edge.launchpad.net/ubuntu/+source/xdg-user-dirs
[07:25] <fcuk112> is there a search page for packages or do you manually put it together?
[07:26] <fabrice_sp> packages.ubuntu.com
[07:26] <fabrice_sp> it still a bit behind launchpad, but should be ok
[07:27] <fcuk112> what is un uupdate - a typo?  you mean i should just extract the tarball?
[07:28] <fabrice_sp> nope. man uupdate: uupdate - upgrade a source code package from an upstream revision
[07:29] <fcuk112> i get 2 tarballs, 1 with orig on it.  on which one do i run uupdate?
[07:29] <fcuk112> in it
[07:30] <fabrice_sp> orig should be a symlink to the upstream tarball
[07:30] <fabrice_sp> so it's the same
[07:30] <fcuk112> ah sorry ^_^
[07:30] <fabrice_sp> ;-)
[07:32] <fcuk112> ok cool, now i have the libavg-0.9.0 folder.  it seems it already updated the changelog for me.  now what should i do?
[07:34] <fabrice_sp> check if there are patches. If so, check if they still apply
[07:35] <fabrice_sp> check also the README (if any), to see what are the changes, and the recommender dependencies
[07:35] <fabrice_sp> and check if the dependencies in debian/control are still ok
[07:47] <fcuk112> ok, the patches look like they have already been incorporated, so i removed the diff files in the patches folder and removed the entries from the series file.  there is no README file (only NEWS), how do i know whether the depencies configured in debian/control are still correct?  is it a matter of trying to recursively installing it?
[07:51] <fabrice_sp> try to build the package and have a look at the 'configure' step can help
[07:51] <fabrice_sp> it may not requires nes depepdencies
[07:51] <fabrice_sp> new dependencies
[07:55] <fcuk112> so i should run ./configure && make in the libavg-0.9.0 source folder?  won't it fail because i have not installed any of the dependencies?
[07:56] <fabrice_sp> do you have a pbuilder installed?
[07:56] <fabrice_sp> or a chroot?
[07:57] <fcuk112> i have pbuilder yes
[07:58] <fabrice_sp> so you can generate the source for the package (debuild -sa), nad build it with pbuilder
[07:58] <fcuk112> ok
[07:59] <micahg> fcuk112: don't forget to make a changelog entry regarding dropping the patch
[08:01] <fcuk112> ok
[08:02] <fabrice_sp> right: make sure you explain in the changelog all your changes
[09:33] <fcuk112> humm getting this error from pbuilder: dpkg-shlibdeps: error: couldn't find library avg.so.0 needed by debian/python-libavg/usr/lib/libColorNode.so.0.0.0 (ELF format: 'elf32-i386'; RPATH: '').
[09:39] <fabrice_sp> fcuk112, perhaps because avg lib got renamed
[09:39] <fabrice_sp> check in your build directory
[09:41] <fcuk112> hummm, pbuilder already removed the build directory.
[09:42] <fcuk112> am i allowed to do ./configure && make in the libavg-0.9.0 folder before i run pbuilder?  it may throw up the errors quicker, though it would change some files.
[09:43] <fabrice_sp> hmm, I think you would need the build deps also in this case
[09:45] <fcuk112> true, what if i did sudo apt-get install libavg to get the deps first.
[09:45] <fabrice_sp> you can use apt-get build-dep libavg
[09:45] <fcuk112> ok
[09:45] <fabrice_sp> but it will install stuff on your main system
[09:46] <fcuk112> that's ok, i'm running in a VM.
[09:46] <fabrice_sp> ok :-)
[09:46] <geser> login into your pbuilder and do it there or install a pbuilder-hook which gives you a shell if a build fails
[10:41] <fcuk112> hummm, ./configure && make worked in the source folder, however when i now try debuild -S -kxxx i get this kind of output : http://www.pastie.org/699474
[10:42] <fcuk112> as the make updated the binaries, can i still package it?
[10:45] <azeem> fcuk112: debuild -S is to build a source package
[10:45] <azeem> fcuk112: you need to run the clean target first; AIUI debuild -S should do this, so apparently your clean target does not really clean up the build tree
[10:53] <fcuk112> ah, make clean fixed it nicely.
[10:57] <azeem> fcuk112: do you have a clean: target in debian/rules?
[10:58] <fcuk112> azeem: yes, it says   $(RM) -r build* debian/stamp-*
[10:58] <fcuk112> azeem: with clean:: prefix, is that what you meant?
[10:58] <azeem> prefix?
[10:58] <azeem> I mean a Makefile rule
[10:59] <fcuk112> debian/rules: http://www.pastie.org/699485
[11:00] <azeem> if you run "fakeroot debian/rules clean", is your $(RM) line executed?
[11:02] <fcuk112> azeem: yes.
[11:03] <fcuk112> azeem: but i think the problem was that i ran make in the actual source folder to test, hence had to run make clean to reverse.
[11:03] <azeem> oh, right
[11:03] <azeem> I was just going to say; the object files in your above paste were below src/, not build/
[11:13] <fcuk112> if we could get the compilation speed of "go" that would be a big win
[13:10] <fcuk112> i still have this error: dpkg-shlibdeps: error: couldn't find library  avg.so.0 needed by debian/python-libavg/usr/lib/libColorNode.so.0.0.0 (ELF format:  'elf32-i386'; RPATH: '').
[13:10] <fcuk112> setup a pbuilder hook and when i try to grep for the file i get this: http://www.pastie.org/699559
[13:41] <fcuk112> debian/rules unchanged and looks like this: http://www.pastie.org/699485
[13:55] <hedkandi_> hello I've put a new package on revu: a simple rss editor. I'm here to encourage you to revu it.
[13:55] <hedkandi_> Anyone interested?
[13:59] <hedkandi_> It's a small application written in C++ relying on wxWidgets and GMetaDOM
[14:00] <hyperair> it might be a good idea to mention the package name as well
[14:00] <fabrice_sp> and a link to revu (even if I don't have time to revu it now)
[14:00] <hedkandi_> indeed, it's called rssedit
[14:01] <hedkandi_> however it's not on the revu page yet. I ftp'd it last nite and I don't think it's been processed.
[14:01] <hedkandi_> Is there a chron job that does the processing or does someone go and unpack it manually?
[14:01] <fabrice_sp> ?! Revu process the upload in less than 20 minute,s IIRC
[14:01] <fabrice_sp> cron
[14:02] <hedkandi_> oh dear I wonder what's happened to it then!?
[14:02] <fabrice_sp> did you log to revu?
[14:03] <hedkandi_> I used ftp
[14:03] <hedkandi_> ftp revu.ubuntuwire.com
[14:03] <hedkandi_> anon login
[14:03] <hedkandi_> cd incoming
[14:03] <fabrice_sp> to the web interface, I mean
[14:03] <fabrice_sp> you have to use dput
[14:03] <hedkandi_> I didn't use dput
[14:03] <fabrice_sp> that's why your package didn't show
[14:03] <hedkandi_> why do I have to use dput?
[14:04] <fabrice_sp> because it upload signed package (you upload the changes file)
[14:05] <fabrice_sp> !revu | hedkandi_
[14:05] <hedkandi_> I created a signed package and ftp'd it
[14:06] <hedkandi_> if you look at the code for dput, all it does it open an ftp connection and do what I did.
[14:06] <fabrice_sp> as you want: the wiki pages explains what you have to do, but you can do it your own way
[14:06] <hedkandi_> I know that some people prefer to use dput, but it's not obligatory
[14:07] <hedkandi_> It just says on the webpage something about "uploads to revu should be signed source packages"
[14:07] <hedkandi_> which mine was.
[14:08] <hedkandi_> maybe it didn't have my gpg key?
[14:08] <fabrice_sp> did you read the wiki page?
[14:09] <hedkandi_> I did
[14:09] <hedkandi_> many times
[14:09] <hedkandi_> and I can't say I thought it was helpful
[14:09] <hedkandi_> but that's another story
[14:09] <fabrice_sp> did you do that : It is important that you login to REVU at least once before you upload first package. If this is not done then REVU will not have your GPG key imported from Launchpad and the package will get rejected automatically.
[14:09] <fabrice_sp> you can make it better: it's a wiki
[14:10] <hedkandi_> I am in the process of doing so
[14:10] <hedkandi_> Indeed, if you'd like to view my article on the subject, I'll show it to you.
[14:10] <hedkandi_> but right now I'd prefer to know what happened to my source package please!
[14:11] <fabrice_sp> did you do that : It is important that you login to REVU at least once before you upload first package. If this is not done then REVU will not have your GPG key imported from Launchpad and the package will get rejected automatically.
[14:11] <hedkandi_> well I logged into wiki.ubuntu.com
[14:11] <hedkandi_> is that the same?
[14:11] <hedkandi_> heehee
[14:12] <fabrice_sp> no
[14:12] <hedkandi_> okay then. I'll have another go!
[14:12] <fabrice_sp> you have to log to revu
[14:12] <hedkandi_> thanks for the advice!
[14:12] <hedkandi_> see you later.
[14:12] <fabrice_sp> it was in the wiki
[14:12] <fabrice_sp> bye ;-)
[15:11] <lamalex> is there somewhere i can can get extra pbuilder debug info?
[15:11] <lamalex> i get this
[15:11] <lamalex> W: Failure trying to run: chroot /var/cache/pbuilder/base.cow/. mount -t proc proc /proc
[15:11] <lamalex> E: debootstrap failed
[15:11] <lamalex> but not sure where/how debootstrap is failing
[15:12] <dtchen_> it isn't debootstrap per se
[15:13] <dtchen_> it's chroot
[15:13] <dtchen_> can you actually chroot successfully using that command?
[15:14] <lamalex> well no but it rm -rf's /var/cache/pbuilder/base.cow
[15:17] <lamalex> any suggestions for how to test what's breaking?
[15:17] <dtchen_> well, basics like ensuring that /var/cache has sufficient space, etc.
[15:17] <lamalex> it does
[15:18] <lamalex> 82gb available
[15:18] <lamalex> should be suffecient ;P
[15:19] <dtchen_> whta process triggers that error, i.e., what are you attempting?
[15:19] <dtchen_> what*
[15:20] <lamalex> cowbuilder --create
[15:22] <lamalex> as root
[15:24] <adama> lamalex: we tend to call those farmers :/
[15:25] <lamalex> adama: what?
[15:25] <lamalex> oh
[15:26] <hyperair> lamalex: ^Z cowbuilder and chroot manually
[15:27] <lamalex> happens so fast, is there a way to do it before it tried?
[15:27] <hyperair> heh
[15:27] <hyperair> let's see...
[15:28] <hyperair> http://groups.google.com/group/ec2ubuntu/browse_thread/thread/e377df1c730f114f this has a similar error message
[15:28] <hyperair> mount is failing for some reason then
[15:30] <lamalex> super weird
[15:30] <hyperair> indeed
[15:31] <hyperair> try mounting proc elsewhere and seeing if that works?
[15:32] <lamalex> ok it's definitely something in my config
[15:32] <hyperair> heh
[15:32] <hyperair> lemme see?
[15:33] <hyperair> i get something else entirely if i remove my config
[15:33] <hyperair> E: Package cowdancer has no installation candidate
[15:33] <hyperair> =p
[15:34] <lamalex> heh
[15:35] <hedkandi_> sorry folks, I have uploaded my package to revu at 1420 and it's not registering.
[15:35] <hedkandi_> could someone please check the error logs and tell me why not?
[15:35] <hedkandi_> it doesn't like something.
[15:35] <hedkandi_> I gave it a signed dsc file and a tarball on ftp
[15:36] <geser> did you login on revu before you first upload? and did you only upload the source package?
[15:36] <hyperair> hedkandi_: you need to give it a signed _source.changes file
[15:37] <hedkandi_> is that part of a debian source package?
[15:37] <hedkandi_> I think not
[15:37] <geser> no, but you need that for upload
[15:37] <lamalex> hyperair: it breaks with a custom debootstrap script, so I think that's the issue. I'm trying to create an image of an ubuntu derivative
[15:37] <hedkandi_> ah but it doesn't say that on the wiki page
[15:38] <geser> which wiki page?
[15:38] <lamalex> it builds a jaunty image fine. Wonder why it's breaking though I didnt change much
[15:38] <hedkandi_> https://wiki.ubuntu.com/MOTU/Packages/REVU
[15:38] <hyperair> lamalex: ah. i see
[15:38] <lamalex> i really only chnaged the mirror locations
[15:38] <hyperair> lamalex: did you mkdir /proc?
[15:39] <hedkandi_> it says "Packagers can upload their packages to REVU"
[15:39] <hedkandi_> and a .changes file is NOT part of a source package
[15:39] <lamalex> hyperair: shouldn't /proc exist already?
[15:39] <hyperair> hedkandi_: sure it isn't. but you need it to upload something with dput.
[15:39] <lamalex> isn't that a pretty importanti dir
[15:39] <geser> hedkandi_: "Uploading to REVU is done with dput. "
[15:40] <hedkandi_> Uploads to REVU should only be signed source files, with the original tarball
[15:40] <hyperair> hedkandi_: even if you upload using plain ol ftp you need to upload with _source.changes
[15:40] <hedkandi_> it doesn't say it is obligatory to use dput.
[15:40] <hyperair> but it's obligatory to add your .changes file
[15:40] <hedkandi_> it doesn't say that
[15:40] <hedkandi_> on the wiki page
[15:41] <hyperair> okay, lemme rephrase
[15:41] <hyperair> stfu, do what i say, and watch it work, or continue arguing and get nowhere.
[15:41] <geser> hedkandi_: yes, you should only "upload" the _source.changes file (with dput), and not the _i386.changes file because you forget to pass -S to dpkg-buildpackage
[15:41] <hedkandi_> is there a link for _source.changes format?
[15:42] <lamalex> it gets generated with debuild -S
[15:42] <geser> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debianchangesfiles
[15:42] <hedkandi_> thx for the help!
[15:42] <geser> but why do you need that? debuild -S build it for you
[15:43] <hyperair> lamalex: i think one of the udebs should setup /proc, but it's not?
[15:47] <lamalex> hmm
[15:48] <lamalex> anyway to debug which it is? it's possible our archive is incomplete
[15:48]  * hyperair doesn't know
[15:49] <hyperair> i think the first step would be to find out why mount is failing
[15:49] <hyperair> is it because mount is missing, or mount is not properly setup, or /proc is missing?
[15:50] <lamalex> i think i may have figured it out..
[15:50] <hyperair> ?
[15:51] <lamalex> our archive doesn't have the debootstrap udeb
[15:51] <lamalex> which i htink sets up /proc
[15:51] <hyperair> ah
[15:51] <hyperair> i see
[15:51] <dtchen_> yeah, that would do it
[15:53] <hyperair> does it set up /proc?
[15:53] <hyperair> i dion't see it in the debootstrap udeb
[16:02] <lamalex> maybe it doesn't ijust read something online that gave me that inclination
[16:07] <fcuk112> i still have this error: dpkg-shlibdeps: error: couldn't find library  avg.so.0 needed by
[16:07] <fcuk112>                           debian/python-libavg/usr/lib/libColorNode.so.0.0.0 (ELF format:  'elf32-i386'; RPATH: '').
[16:07] <fcuk112> 13:10 <         fcuk112 > setup a pbuilder hook and when i try to grep for the file i get this:
[16:07] <fcuk112>                           http://www.pastie.org/699559
[16:07] <fcuk112> i still have this error: dpkg-shlibdeps: error: couldn't find library  avg.so.0 needed by
[16:07] <fcuk112>                           debian/python-libavg/usr/lib/libColorNode.so.0.0.0 (ELF format:  'elf32-i386'; RPATH: '').
[16:07] <fcuk112> 13:10 <         fcuk112 > setup a pbuilder hook and when i try to grep for the file i get this:
[16:07] <fcuk112>                           http://www.pastie.org/699559
[16:07] <fcuk112> oops sorry to paste twice
[16:17] <hedkandi_> okay
[16:33] <EzraR> I need to update a patch but am unsure what the correct change is anyone able to help?
[16:34] <EzraR> http://pastebin.com/d19803bb
[16:39] <lfaraone> How do I include an upstream changelog with CDBS?
[16:39] <lfaraone> *a cdbs-using package
[16:40] <ScottK> Should be automagic, but you can include it in binaryname.docs (or doc, I don't recall) in your debian dir (like binaryname.install for other stuff)
[16:42] <ripps> lfaraone: It should be chosen automatically, but you cans specify it manually in the rules file with DEB_INSTALL_CHANGELOGS_ALL
[16:43] <lfaraone> ripps: well, upstream ships `debian/` in their orig.tar.gz, and their changelog is debian/changelog.
[16:43] <lfaraone> ripps: I'm not sure if there's an automagic way to handle that, other than by extracting the changelog from the upstream tarball and renaming it.
[16:45] <ScottK> I think including debian/changelog in the doc file will work
[18:06] <bbigras> anyone good with python package can help fix this problem with the apt-zeroconf package from their ppa http://pastebin.ca/1672338 . there's a "ImportError: No module named aptzeroconf.daemon" error when the package is installed but the init script works if used by hand. the ppa is at https://launchpad.net/~apt-zeroconf/+archive/ppa
[18:36] <hedkandi_> can I ask, does the .changes file for revu need to have any specific name?
[18:37] <hedkandi_> is hello.changes.asc okay?
[18:38] <hedkandi_> please?
[18:43] <hyperair> hedkandi_: out of curiosity, what are you trying to do?
[18:43] <hedkandi_> upload a package to revu
[18:43] <hyperair> (if this message got through already, sorry -- network issues)
[18:44] <hyperair> hedkandi_: then why don't you just use debuild -S to generate your .dsc, .diff.gz, AND your .changes file?
[18:44] <hyperair> why go through the trouble of creating the .changes file by hand?
[18:44] <hedkandi_> am i not allowed to?
[18:45] <hyperair> it's just error prone and tedious
[18:45] <hedkandi_> I rather think the opposite
[18:45] <hyperair> why don't you generate your .dsc, and .diff.gz by hand as well then?
[18:45] <hedkandi_> If I do it my way I understand what's happening.
[18:45]  * hyperair coughs and mutters something along the line of control freak
[18:45] <hyperair> fine, do what you want. i won't stop you.
[18:45] <hyperair> >_>
[18:46]  * hedkandi_ is
[18:46] <hyperair> it's your time you're wasting after all
[18:46] <hedkandi_> I think that's rude actually and unhelpful as well
[18:46] <hedkandi_> who's moderating this channel?
[18:48] <yofel> hedkandi_: I also don't understand why you want to create a file using your own method instead of using the automatic process that usually takes only a few seconds...
[18:49] <dtchen_> hedkandi_: to answer your question, yes, the .changes file needs to be an actual .changes file named .changes, unsurprisingly.
[18:50] <dtchen_> hedkandi_: this is outlined in Debian Policy regarding source packages
[18:50] <hedkandi_> thanks folks
[18:50] <hedkandi_> I thought it was a file extension
[18:50] <hedkandi_> my mistake.
[18:51] <hedkandi_> just seems a bit weird to call a file .changes which hides it
[18:51] <hedkandi_> what IS the point of hiding it?
[18:51] <hedkandi_> it is the most important file in the upload
[18:51] <hedkandi_> ???
[18:51] <dtchen_> hmm? _source.changes isn't hidden...
[18:52] <hedkandi_> you just said "named .changes"
[18:52] <dtchen_> Ubuntu does source-only uploads, unlike debian
[18:52] <dtchen_> Debian*
[18:52] <dtchen_> hedkandi_: sorry, I was being imprecise
[18:52] <hedkandi_> now you're saying it's called _source.changes?
[18:52] <dtchen_> hedkandi_: when a source package is generated, it's always sourcepackage_version_source.changes for that file
[18:53] <dtchen_> e.g., pulseaudio_0.9.20-0ubuntu1~~karmic~ubuntuaudiodev1_source.changes
[18:54] <dtchen_> hedkandi_: i.e., it's still just as important that you name the file properly for your source package and version, but dpkg-buildpackage automates that
[18:54] <dtchen_> hedkandi_: hence why others have implied that you should use the tools available instead of editing by hand
[18:54] <hedkandi_> indeed, but I'm afraid I really don't understand those automated tools
[18:55] <hedkandi_> I'd prefer to write my own
[18:55] <dtchen_> hmm, I presume, then, that you're building your own debian/* ?
[18:55] <dtchen_> i.e., not using debhelper, etc.
[18:55] <hedkandi_> I posit that it would take me more time to understand all the complicated tools that are available
[18:55] <hedkandi_> than write my own
[18:56] <hedkandi_> and if I write my own I gain a good understanding of the topic AND the ability to fix them
[18:56] <dtchen_> sure, but you could also learn the existing tools and fix bugs in them. :-)
[18:56] <hedkandi_> I'm afraid I didn't understand the wiki page at ubuntu so I'd rather do it myself
[18:56] <directhex> i certainly wouldn't advocate a package built in that way
[18:56] <hedkandi_> indeed, this is a good proposition, and in the past I have suggested some brilliant bug-fixes
[18:57] <dtchen_> hedkandi_: what came of those suggestions in Debian?
[18:57] <hedkandi_> but then someone in charge says he can't change it because it would break backwards-compatibility or
[18:57] <hedkandi_> he thinks it should behave in a weird / undocumented manner
[18:57] <dtchen_> with whom did you speak?
[18:58] <hedkandi_> so I just have this attitude that I should do it myself
[18:58] <hedkandi_> and really all I need to do it myself are the specifications for how the system operates, and
[18:58] <hedkandi_> they should, I think be available
[18:58] <serialorder> if i include an auto close tag for LP in a changelog and the referenced bug has several duplicates will it close the duplicates as well?
[18:58] <hedkandi_> I have documented what I have discovered and I have posted an article on my website
[18:58] <hedkandi_> so that other people can do things an alternative way.
[18:59] <m4rtin> hedkandi_: I think, also, that you are not so much as learning how it works, as wasting a great deal of time re-inventing the wheel
[18:59] <hedkandi_> well I don't want to waste YOUR time, obviously
[18:59] <dtchen_> serialorder: no, only the listed one. The duplicates don't really matter, since they already are slaved to the master.
[18:59] <hedkandi_> so I'm sorry if I have
[19:00] <dtchen_> (no offense intended to anyone aggravated by the master/slave semantics)
[19:00] <hedkandi_> however, I only asked for a few small snippets of information like the names of files to upload to revu
[19:00] <hedkandi_> which is not asking a lot.
[19:00] <hedkandi_> I am allowed to spend my time as I wish.
[19:01] <serialorder> dtchen_, what do you mean?
[19:01] <m4rtin> hedkandi_: absolutely, but if you use the existing procedures then your packages will be more likely to be accepted. Nevertheless, if you have an interest in how packaging works, I can see how it can be interesting to write your own
[19:02] <dtchen_> serialorder: I mean that duplicates don't need to have their statuses changed, since they're already marked duplicates
[19:02] <serialorder> oh ok
[19:03] <hedkandi_> I appreciate that you MOTU people think you have discharged your responsibility to provide
[19:03] <directhex> hedkandi_, you upload a .changes file, using dput, which will also upload the required source package files
[19:03] <directhex> e.g. banshee_1.5.1-1_source.changes
[19:04] <hedkandi_> stuff about packages, but I have spent days struggling over it.
[19:04] <directhex> which contains checksums for banshee_1.5.1-1.dsc, banshee_1.5.1-1.diff.gz, banshee_1.5.1.orig.tar.gz and will upload them too
[19:04] <dtchen_> hedkandi_: just a suggestion: please try to avoid using the "us versus them" mentality. We're all attempting to work on packages, and how we get there is debatable, but offensive/defensive separation isn't really conducive here.
[19:04] <hedkandi_> indeed
[19:04] <hedkandi_> there's no I in team!
[19:05] <directhex> there's M and E though
[19:05] <hedkandi_> indeed.
[19:05] <hedkandi_> what fun
[19:06] <hedkandi_> my basic thesis however is that creating a package is really very simple, and I shouldn't have to use or learn
[19:06] <hedkandi_> a zillion scripts
[19:07] <hedkandi_> and actually if you look at some of those dpkg-scripts or dput etc
[19:07] <hedkandi_> they are really big programs that import loads of things and launch other things
[19:07] <hedkandi_> and it seems to me to be totally unnecessary
[19:08]  * hyperair wonders if hedkandi_ came from gentoo
[19:08] <directhex> okay, so don't use dput. manually use ftp and md5sum
[19:08] <hedkandi_> I've made my own packages with a handful of commands
[19:08] <directhex> which would work
[19:08] <hyperair> and sha1sum and sha256sum
[19:08] <directhex> those too, yes
[19:08] <directhex> i think there's a guy you want to talk to, actually
[19:08] <hyperair> i'd still suggest using debuild -S, examining the .changes file generated, and then learning from there
[19:08] <hedkandi_> well actually I don't mind using dpkg-source... that's the only one I use
[19:08] <directhex> manoj. he's also rejected the concept of making "computers" do repetitive menial tasks, and prefers doing things by hand
[19:09] <hyperair> lol
[19:09] <hedkandi_> But here is a valid suggestion which I would like you to consider:
[19:09] <hedkandi_> I think it is entirely okay to upload a debian source package to revu .
[19:09] <hyperair> erm yes, we all upload debian source packages to revu.
[19:10] <hyperair> don't we?
[19:10] <hedkandi_> no
[19:10] <hyperair> then what do you upload?
[19:10] <hyperair> rather, what do you call that which you upload?
[19:10] <directhex> i upload debian source packages to debian
[19:10]  * hyperair sighs. technicalities.
[19:11] <directhex> and occasionally to ubuntu
[19:11] <hyperair> speaking of debian source packages, do the stuff in ubuntu support source version 3?
[19:11] <hedkandi_> there is a technical difference between a debian source-package and a debian package-update
[19:11] <hyperair> er what?
[19:11] <hyperair> what's a package-update?
[19:11] <hedkandi_> a source-package is described by a .dsc file which has a section underneath "Files:"
[19:12] <directhex> hedkandi_, yes. technically one of those things exists, and one doesn't
[19:12] <hedkandi_> Included in that list of files is a debian/ directory which must include four further files
[19:12] <hedkandi_> changelog, rules, copyright and control
[19:12]  * hyperair digs out some dscs to look at
[19:12] <hedkandi_> A debian package-update is described by a .changes file and there are no required files
[19:12] <hedkandi_> That is the difference
[19:13] <hedkandi_> The "revu" upload will delete a debian source-package because it lacks a .changes file
[19:13] <hedkandi_> and this is my view is silly.
[19:13] <hedkandi_> I ask that this be changed.
[19:13] <hyperair> but why
[19:13] <hyperair> why do you think it's silly?
[19:13] <hyperair> the .changes is used for authentication
[19:14] <hyperair> just as the actual ubuntu and debian archives, and the PPAs figure out who's uploading what
[19:14] <hedkandi_> the .dsc is similar in format to the .changes file and also contains authentication data
[19:14] <hyperair> hmm it does eh..
[19:14] <hyperair> yeah it does
[19:14] <hedkandi_> the .dsc file usually contains md5 checksums and you can sign it as well.
[19:15] <hedkandi_> but anyway, I'm going back to work
[19:15] <hedkandi_> thanks for your help
[19:15] <hyperair> sha1 and sha256 for me
[19:15] <hedkandi_> I look forward to getting my package accepted to ubuntu soonish.
[19:19] <directhex> i would under no circumstances advocate a package which can't be tested & built by standard means. the pressing reason to use "normal" tools is to ensure that people other than yourself are able to maintain a package in your absence. unlike debian, ubuntu has a policy that any packager can update any package - and this is requires because the ubuntu dev community simply sin't large enough for individual package ownership beyond ad-
[19:19] <directhex> hoc "last touched" approaches. if you have a package which a casual observer can't upload a bugfix for, you have a potentially problematic package
[19:27] <hedkandi_> directhex, the debian policy provides for all that you require. I am working within the debian policy. That policy
[19:28] <hedkandi_> does not enforce the use of tools like dput and so forth.
[19:28] <hedkandi_> and thus I am free to use my own tools if I want to.
[19:28] <hedkandi_> and I will still produce debian packages, and no-one will be able to tell from looking at them
[19:28] <hedkandi_> what tools I used to produce them
[19:29] <hedkandi_> let's try not going off-topic shall we?
[19:29] <jdong> well we're not the ones who spent the last 4 hours talking about this.
[19:29] <jdong> if you want to build your own tools to handle Debian source package generation, you're welcome to do so, but discussion of such is off topic for this channel.
[19:31] <directhex> who's being offtopic? if i can't test-build your package, i won't upload it. i need to be able to regenerate the source package to sanity-check it.
[19:31] <hedkandi_> okay then
[19:33] <EzraR> anyone familiar with "ubuntu hardening" patches?
[19:33] <directhex> good lord what an ego. "i know better than everything a thousand debian developers have learnt over the last 15 or so years, and i'll act all offended if you suggest otherwise"
[19:34] <dtchen_> I can understand the desire to learn the process, but writing a tool may not be the most efficient manner
[19:34] <kees> EzraR: yup, sure.  https://wiki.ubuntu.com/CompilerFlags
[19:34] <EzraR> I have a source that changed the code a hardening patch was applyied to can someone tell me if this looks like a correct fix
[19:35] <dtchen_> unfortunately, it is how programming tends to be taught
[19:35] <EzraR> http://pastebin.com/m6a9a5124
[19:36] <kees> EzraR: it looks like upstream decided to add IRGRP | S_IROTH, so I'd just leave upstream as-is.
[19:36] <EzraR> i asume the orig person that made the patch was making the perms more restrictive though
[19:36] <EzraR> upstream also added user read and other read perms
[19:37] <kees> EzraR: right, it's a safe assumption, but it looks like upstream has a different idea, which is fine.
[19:37] <EzraR> kees: ok because I was told that hardening is standard for ubuntu and should be left in
[19:39] <kees> EzraR: the issue was lacking the "mode" parameter, which upstream has fixed.
[19:39] <EzraR> kees: ok
[19:42] <EzraR> my next question is what would be the proper thing to do if I fix a bug during a merge that someone has already assigned themselves to?
[19:44] <ajmitch> directhex: share the gossip, where's that from?
[19:45] <directhex> ajmitch, hm? the last god knows how long in here!
[19:46] <ajmitch> oh fun
[19:46]  * ajmitch thought you were quoting from a mailing list or something :)
[19:47] <serialorder> how long does it usually take for a ppa upload to show up in launchpad?
[19:48] <ajmitch> 5-10 minutes
[19:48] <ajmitch> directhex: I just read the scrollback, how very formal
[19:51] <serialorder> never mind i had an erro
[19:54] <hyperair> ajmitch: few hours.
[19:54] <hyperair> oh whoops wrong context
[19:55] <hyperair> directhex: replace "act all offended" with "accuse you of being rude and call for moderators to kick/ban you" and it'll be about right
[19:59] <pkern> directhex: yada yada yada
[20:20] <hedkandi> well thanks for telling me about debuild -S that was actually reasonably easy!
[20:20] <hedkandi> bye
[20:22] <directhex> o_o
[20:22]  * directhex connects head to desk
[20:22] <serialorder> haha
[20:25] <serialorder> my main complaint about the build tools is they are too easy =P
[20:25] <serialorder> when you first start out its really easy to build things without knowing whats going on
[20:25] <serialorder> but its really not a complaint =)
[20:31]  * hyperair facepalms
[20:46] <siretart> reading source code might in some case be helpful as well. oh well.
[20:48] <ajmitch> siretart: unless it's cdbs
[20:49] <ajmitch> though cdbs source is better than its documentation :)
[20:50] <quinda> This may be a silly question, but I'm interested in learning how to package.  There's a [needs-packaging] bug for the latest version of Pygame on Launchpad, but that package has also been requested for Debian.  My understanding is that Ubuntu pulls packages from Debian, so does that mean I shouldn't package the new version and get 'ahead' of what Debian has?
[20:51]  * quinda hopes that didn't sound too stupid, I'm still learning how everything ties together
[20:52] <ripps> quinda: go ahead and package it and then submit to both debian and ubuntu
[20:56] <quinda> OK, thanks. Looks like I'll have to read up on Debian's processes too, then :)  I only found out about the Debian bug because it was linked on the PyGame site.
[20:56] <ScottK> quinda: It's a good question.
[20:57] <ScottK> In general we prefer to get stuff from Debian, but we will also do our own updates.  I'd suggest get it updated here and then offer to help the Debian maintainer update it in Debian.
[21:00] <quinda> Thanks.  I'll have a shot at packaging it then.  Spent most of the weekend reading the wiki, fingers crossed this will go smoothly.
[21:01] <Amaranth> updating an existing package is usually pretty simple
[21:01] <Amaranth> unless upstream has gone bonkers and changed how everything works between releases
[22:56] <fcuk112> ./configure && make in the source folder worked fine, debuild -S worked fine, but when i pbuilder build i get the following error: dpkg-shlibdeps: error: couldn't find library avg.so.0 needed by debian/python-libavg/usr/lib/libColorNode.so.0.0.0 (ELF format: 'elf32-i386'; RPATH: '').
[22:56] <fcuk112> Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
[22:56] <fcuk112> To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH.
[22:56] <fcuk112> any idea where i should be looking?
[23:05] <maxb> fcuk112: The Note that dpkg-shlibdeps gave you is likely relevant. Where *is* avg.so.0 ?
[23:12] <fcuk112> maxb: i setup a pbuilder hook and did a grep for it: http://www.pastie.org/699559
[23:12] <fcuk112> maxb: however there is no libavg folder under dist-packages or site-packages.
[23:13] <maxb> Clearly there is. Or grep would not print: Binary file usr/lib/python2.6/dist-packages/libavg/avg.so.0 matches
[23:14] <maxb> Something is very broken about this software if it is installing libraries into /usr/lib/ which link against a python module .so
[23:38] <ScottK> bdrung: How come we can't get matplotlib to be a sync?
[23:39] <bdrung> ScottK: some ubuntu users complains to much.
[23:39] <ScottK> bdrung: What does that man?
[23:39] <ScottK> man/mean
[23:42] <bdrung> ScottK: https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/301007 is not done, yet.
[23:42] <bdrung> ScottK: https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/303158
[23:43] <ScottK> bdrung: I just saw you uploaded a merge.  Are we carrying some change that can't go back to Debian?
[23:44] <bdrung> ScottK: only one change: "Explicitly depend on python-tk as workaround for LP #301007; drop these changes if an auto backend discovery is implemented by upstream."
[23:44] <ScottK> bdrung: It seems reasonable for Debian to consider this too.
[23:44] <bdrung> ScottK: i do not want to apply this in debian, because it only a workaround for the default and not the correct solution
[23:45] <ScottK> bdrung: Is the upstream feature planned in time for Squeeze?
[23:46] <bdrung> ScottK: we have discussed it with upstream and IIRC they liked the idea. i do not know how far we are in reaching it
[23:47] <ScottK> OK, well it seems that if it isn't coming soon, Debian users would likely be better off with a work around than nothing too.
[23:47] <ScottK> If not, I question why ours are.
[23:47] <bdrung> until now no debian user complained (opened a bug report)
[23:49] <ScottK> I think it's good if developers make improvements ahead of user's complaining.
[23:50] <ScottK> Particularly in Debian with their long release cycles.
[23:50] <bdrung> i think we should contact upstream first
[23:50]  * ajmitch hopes that debian does manage to get python 2.6 as default
[23:53] <kklimonda> well, imo if package by default uses Tk it should at least recommend it (I remember having the same conversation about this bug some months ago that's why I'm speaking now ;) )
[23:53] <maxb> Would be nice, but given how painful 2.5->2.6 is, I would understand if they don't
[23:54] <ajmitch> maxb: most packages have been updated for 2.6, but it'd make it even better if lucid & squeeze have the same major version
[23:54] <ajmitch> and thankfully not everything is as complex as LP to get working on 2.6 :)
[23:54] <maxb> heh
[23:55] <maxb> Fingers crossed, edge.lp.net goes 2.5 tomorrow
[23:55] <kklimonda> was running on 2.4 till now?
[23:56] <maxb> yes
[23:56] <ajmitch> maxb: thanks to a lot of your efforts
[23:56] <maxb> I helped :-). Barry and Gary and Salgado did the heavy lifting struggling with Zope.
[23:57] <ajmitch> so it'll be running on 2.6 in the next release or two?
[23:58] <maxb> No. Currently the plan is to get it on 2.5 now, and defer major efforts to get it onto 2.6 until the datacentre gets upgraded to Lucid
[23:59] <ajmitch> I thought that with the 'encouragement' for developers to run the latest ubuntu release, there'd be some urgency
[23:59] <ajmitch> since I don't know what's happening with keeping 2.5 around for lucid yet
[23:59] <ajmitch> it's probably something that'll be discussed at UDS