[02:41] <sbalneav> Evening all.  I'm trying to package up cnetworkmanager, and running into a problem.  It's got a setup.py, and a Makefile that calls setup.py for install, etc targets.  In my rules, I've got DEB_PYTHON_SYSTEM=pysupport, and include /usr/share/cdbs/1/class/python-distutils.mk, and dh_pysupport under the binary-install/cnetworkmanager:: stanza.  But, none of the actual cnetworkmanager bits get included in the package.
[02:48] <pting> i'm building php5 from source (php5_5.2.10.dfsg.1-2ubuntu6.3)... apt-get source php5 && dpkg-buildpackage -rfakeroot -uc worked great... i was able to generate the debs... however, subsequent dpkg-buildpackage -rfakeroot -uc seems to invokes a unpatch task in debian/rules... and it always fails at unpatching suhosin.patch... since this is my 1st attempt at building a package from source... am i possibly doing something wrong
[02:48] <pting> ? i'm on karmic
[02:51] <ScottK> sbalneav: It's unlikely yo uneed the  binary-install/cnetworkmanager:: stanza.  I'd try removing that.  Even easier, I'd try the debhelper 7 tiny rules.
[02:52] <ScottK> pting: Mostly likely it's a bogus patch that doesn't unpatch reliably or a bug in the packge clean rule.  You ought to start from a clean source each time you build it.
[03:03] <pting> ScottK, hum.. i ran dpkg-buildpackage without modifying the source after a apt-get source php5... i'll try it again just to make sure
[03:03] <sbalneav> ScottK: Yer some kinda freakin' genius.  Thanks!
[03:10] <sbalneav> ScottK: One other stupid question.  It's definitely doing things now, and I'm using the rules.tiny.  but it's trying to run tests as part of the makefile in the check: target.  Any clues as to how I should turn that off?  it's trying to contact a dbus socket for network-manager, which blows fairly big chunks in a pbuilder chroot :)
[03:12] <sbalneav> Should I just patch the makefile to remove the target?
[03:18] <pting> ScottK: strange... here's the steps to repo it... apt-get source php5 && cd php5-5.2.10.dfsg.1 && fakeroot ./debian/rules configure && fakeroot ./debian/rules clean .... and the unpatching fails
[03:18] <pting> maybe it's because i'm calling t he rules tasks manually heh
[03:22] <JontheEchidna> sbalneav: It'd be better to see if there's a variable you can pass to the build to disable tests, but otherwise patching the tests out would work.
[03:24] <pting> well, imma heading out... the more i look at this problem, the more i think it's a bug... i'll look at it some more later... happy holidays everyone
[03:31] <ScottK> sbalneav: You're supposed to be able to pass 'nocheck' to and skip checks, not sure exactly how you do that in this case.
[03:38] <sbalneav> Hmm, well DEB_BUILD_OPTIONS=nocheck doesn't seem to do it...
[03:38] <sbalneav> and dpatch-edit-patch patch foo gives me: dh: Unknown sequence unpatch (choose from: binary binary-arch binary-indep build clean install)
[03:45] <ScottK> Not sure of the details.  Sorry.
[03:47] <sbalneav> NP!  Thanks for the help!
[03:47] <sbalneav> I'll just keep banging at it with the ball-peen hammer 'till it works :)
[03:56] <kklimonda> what would be a version for 1.80 beta1 release when the stable one is going to be 1.80? 1.80~b1-0ubuntu1?
[03:57] <ScottK> That would work.
[04:19] <sbalneav> ScottK: got it.  Just followed https://wiki.ubuntu.com/PackagingGuide/Python to the very letter.  Thanks for all the help!
[04:19] <ScottK> No problem.  Glad it worked out.
[04:23] <sbalneav> Since there's so few of us edubunters, and we've lost laserjock :( I'm gonna go for motu
[04:23] <maco> sbalneav: why not go for edubuntu-dev? they should have their own upload rights infrastructure soonish, right?
[04:23] <sbalneav> I'm already maintaining the sabayon package, and just updated irssi-plugin-xmpp today
[04:24] <sbalneav> this is my first package from scratch.
[04:24] <sbalneav> maco: That I'm not sure of, I'd have to check with highvoltage.
[04:25] <maco> archive reorg means instead of motu / core-dev, its switching over to general / ubuntu desktop / ubuntu server / kubuntu / edubuntu / blah blah blah
[04:25] <maco> kubuntu desktop and ubuntu desktop at least are done with being setup i think, but i dont know about edubuntu
[04:28] <sbalneav> well, either edubuntu-dev or motu, my packaging-fu has to improve :) hence, my diddling tonight.  And cnetworkmanager's such a delightful little tool.  Controlling network manager from the command line's more my thing anyway :)
[04:28] <maco> wait what?
[04:28] <maco> thats possible? AWESOME
[04:28] <sbalneav> I'll push it to my ppa
[04:29] <sbalneav> uno momento por favor
[04:29] <jdong> maco: you haven't seen cnetworkmanager before?
[04:29] <jdong> you're missing out :)
[04:29] <jdong> but yeah, it's a full blown CLI networkmanager client
[04:29] <maco> jdong: i just use ifup!
[04:29] <jdong> lol *eyerolls* ;-)
[04:30] <maco> well i did silly things to my system due to a broken cd drive (installed on 64bit machine, kept the 64bit /etc to avoid reconfiguring krb/openafs/vpn, then moved the disk to 32bit machine)
[04:31] <maco> so a lot of stuff is kinda broken *shrug* including knetworkmanager reporting that there's already a client running
[04:31] <maxb> wow!
[04:31]  * maxb installs cnetworkmanager
[04:31] <sbalneav> https://edge.launchpad.net/~sbalneav/+archive/ppa
[04:31] <maco> i dont care to debug it because 1) its certainly pebkac 2) i can workaround it easy enough
[04:31] <sbalneav> for karmic
[04:32] <maco> (other things that break when doing that: i have to use startx and audio is busted. i totally do not recommend keeping a cross-arch /etc)
[06:37] <nigel_nb> maco: when would u get the time to help finish with that vmbuilder that you helped me start off?
[06:38] <maco> yeah.... i think someone pointed out that the package included quilt hooks and that i should thus back up and explain it the quilt way instead of the normal way
[06:39] <nigel_nb> oh oh
[06:39] <nigel_nb> which means we get to do it again all over?
[06:39] <maco> i dont remember how far we got
[06:39] <nigel_nb> we got as far as actually editing the diff for the correct directories
[06:40] <maco> ok
[06:40] <nigel_nb> the diff was written to correct the bug when it was actually installed
[06:40] <maco> so make a debian/patches directory in the package
[06:41] <nigel_nb> we didn't get that far
[06:41] <nigel_nb> the last time, the edited debdiff didn't work on dry run
[06:41] <maco> pastebin your edited one
[06:42] <maco> because my edited one did :P
[06:42] <maco> oh i think there was one line where the whitespace was off...
[06:42] <nigel_nb> huh
[06:42] <nigel_nb> okay
[06:42] <nigel_nb> wait
[06:42] <nigel_nb> I did the whole thing again
[06:42] <maco> ok
[06:42] <nigel_nb> and I donno if the result showed that it worked or not :P
[06:42] <maco> huh?
[06:43] <nigel_nb> wait, I'll get you what it said
[06:44] <nigel_nb> Hunk #1 succeeded at 26 (offset -1 lines).
[06:44] <nigel_nb> patching file VMBuilder/plugins/libvirt/templates/libvirtxml.tmpl
[06:44] <nigel_nb> thats a complete success ?
[06:44] <maco> yes
[06:45]  * nigel_nb blushes 
[06:45] <nigel_nb> ok, so what do I do next?
[06:45] <maco> now make a debian/patches directory in your source package
[06:46] <nigel_nb> inside the debian directory rite?
[06:46] <maco> well if inside the debian directory, then simply patches
[06:46] <maco> and set: export QUILT_PATCHES=debian/patches
[06:46] <maco> (may want to just plain put that in your .bashrc)
[06:47] <nigel_nb> where in the .bashrc does this go?
[06:47] <maco> anywhere
[06:47] <nigel_nb> done
[06:47] <maco> then itll be set for you all the time when you're working on packages
[06:48] <nigel_nb> ah okay :)
[06:48] <maco> if you didnt run that command on its own though, do so
[06:48] <nigel_nb> the patch?
[06:48] <maco> the export...
[06:48] <maco> since .bashrc takes effect on new shells (or after you run: source ~/.bashrc)
[06:49] <nigel_nb> it say set:: command not found
[06:49] <nigel_nb> extra :?
[06:49] <maco> dont put the word set:
[06:50] <maco> just
[06:50] <maco> export QUILT_PATCHES=debian/patches
[06:50] <nigel_nb> okay, my stupdity, sorry
[06:50] <nigel_nb> done
[06:50] <maco> dtchen says i should  point out that "source" is *only* an ok command to use in bash, dont put it in scripts
[06:51] <nigel_nb> meaning I have to run in manually?
[06:51] <maco> no meaning if youre making scripts for a packge, dont use the command "source"
[06:52] <nigel_nb> oh okay
[06:53] <dtchen> e.g., http://pastebin.com/d1fb25a21
[06:54] <nigel_nb> ah, that way :)
[06:55] <nigel_nb> source command actually updates bash?
[06:55] <jmarsden> nigel_nb: No, source command only exists in bash, not in sh
[06:56] <nigel_nb> jmarsden: oh okay, but what is its exact function?
[06:56] <dtchen> from bash(1): Read and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename
[06:56] <jmarsden> It reads lines of a file and executes them as you they were right there in your script
[06:57] <jmarsden> nigel_nb: help source
[06:57] <nigel_nb> now, why didn't I try help, I tried man
[06:57] <nigel_nb> thanks guys :)
[06:58] <jmarsden> nigel_nb: For bash internal commands, use help, for external commands, use man :)
[06:58] <dtchen> I always refer to man, because not everyone uses bash(1)
[06:58] <nigel_nb> never realized that, now I'm embarassed to know how much of a newbie I actually am :(
[06:59] <jmarsden> dtchen: well, someone who uses source without thinking about it probably *does* use bash :)
[06:59] <dtchen> hence why I use man page references :-)
[07:01] <nigel_nb> okay, what next?
[07:05] <nigel_nb> maco: off to bed?
[07:05] <maco> nigel_nb: by the way when dtchen says bash(1) he means "man 1 bash"
[07:06] <maco> soon, yes. feeling rather sick
[07:06] <maco> after this cup of tea
[07:06] <nigel_nb> how free are you on sunday?
[07:07] <maco> busy. school projects and a dinner outing
[07:07] <nigel_nb> in a sense we're in the same boat
[07:07] <nigel_nb> I'm out with cold
[07:07] <nigel_nb> worked all night
[07:07] <nigel_nb> now its 12:37 PM
[07:07] <maco> i feel like the top of my head is trying to kersplode off. i think i have a sinus infection :(
[07:07] <nigel_nb> strange, I got up yday at someting like 4 PM
[07:08] <nigel_nb> oh oh
[07:09] <nigel_nb> get to a doc soon
[07:09] <nigel_nb> or get some tylenol sinus (not sure if its OTC)
[07:10] <maco> i have lots of sudafed, ill be ok :)
[07:11] <nigel_nb> been off the clinic note stuff for quite some time, dont remember the cold drugs :(
[07:11] <nigel_nb> in real life, I work as a medical transcriptionist
[07:31] <nigel_nb> maco: want to do this later? :)
[07:31] <maco> yeah
[07:31] <nigel_nb> thought so, and I feel guilty keeping you up when u're sick
[07:31] <nigel_nb> some time on sunday?
[07:31] <maco> as i said busy sunday
[07:32] <maco> maybe saturday?
[07:32] <maco> well its technically saturday now
[07:32] <maco> but i mean the saturday evening that comes in 15 hours :P
[07:32] <nigel_nb> well, its saturday afternoon for me now
[07:33] <nigel_nb> and I got work tonight
[07:33] <nigel_nb> :(
[07:33] <nigel_nb> which extends to next week
[07:35] <nigel_nb> how about some time next week then, if u're free
[07:42] <nigel_nb> maco: ?
[07:42] <maco> ok
[07:42] <maco> are you in au or nz or something?
[07:42] <nigel_nb> go to bed :)
[07:42] <maco> timezones are confusing.
[07:42] <maco> hehe its almost 3am here
[07:42] <nigel_nb> a little way too ahead
[07:42] <maco> on saturday
[07:42] <nigel_nb> I'm in India
[07:42] <maco> ah ok
[07:43] <nigel_nb> 2:42
[07:43] <nigel_nb> I know
[07:43] <nigel_nb> I added you to my clock
[07:43] <maco> ah ok. i just have europe in my clock list
[07:43] <nigel_nb> its 1:15 here :)
[07:43] <nigel_nb> and I'm fatigued
[07:43] <nigel_nb> I'm a little more ahead of "that" time :P
[07:44] <nigel_nb> btw, I did mail you sometime last week
[07:44] <nigel_nb> or I think I mailed you, from LP
[07:46] <nigel_nb> I'm off then, catch you later :)
[07:51] <mannyv> fabrice_sp, if you are around did you still have some merges you wanted a hand with, im running our of sync requests
[07:52] <fabrice_sp> mannyv, I have an upgrade
[07:52] <fabrice_sp> let me check
[07:52] <fabrice_sp> :-)
[07:52] <fabrice_sp> well: merge/sync
[07:53] <mannyv> oh i was going to say i havent done  an upgrade before
[07:53] <fabrice_sp> uim: I upgraded it for Karmic, and now, Debian has a newer version
[07:54] <fabrice_sp> it's a kind of 'messy' package
[07:54] <mannyv> well i could give it a shot, about time i got my hands dirty
[07:55] <fabrice_sp> unstable has 1.5.7 (because of a build dependency), and Lucid 1.5.6 :-)
[07:55]  * fabrice_sp has to check if he has more merge/sync waiting in MoM
[08:04] <fabrice_sp> mannyv, you can also have a look at hydrogen
[08:05] <fabrice_sp> I had a quick look, and it should be a merge
[08:05] <mannyv> ok uim and hydrogen
[08:05] <fabrice_sp> yes
[08:05] <fabrice_sp> and I've just seen that porthose stole me a sync! ;-)
[08:06] <fabrice_sp> so for any contributor: remember to ask previous uploader, before working on a merge or a sync
[08:07]  * fabrice_sp goes back to sponsoring :-) 
[08:16] <mannyv> fabrice_sp, I was having a look at cyrus-sasl2-heimdal and there is no difference between the ubuntu and debian package  http://pastebin.com/f38ce0ad9, except for the standard maintainer/original-maintainer fields. It builds fine but I cant do a test install because one of its depends is waiting for a merge
[08:17] <mannyv> it should have been a sync and not a merge last time too
[08:17] <fabrice_sp> which depends?
[08:18] <mannyv> Depends: libsasl2-modules (>= 2.1.23.dfsg1-3) but 2.1.23.dfsg1-2ubuntu1 is installed
[08:22] <fabrice_sp> hmm: this package is in main... I can't help you more than saying: ask to zul to see if he is willing to work on the merge again
[08:23] <mannyv> ok i will talk to him next time he is around, and i am awake, good night =)
[08:23] <fabrice_sp> good night :-)
[08:23] <fabrice_sp> by the way: did you put in MoM that you are working on hydrogen and uim merge?
[08:25] <fabrice_sp> Did it for you :-)
[10:13] <stochastic> Is there any reason why Raul http://packages.debian.org/source/squeeze/raul and Flowcanvas http://packages.debian.org/source/squeeze/flowcanvas have not yet been pulled from squeeze into Lucid?  Is there a proper way to request these?
[10:13] <fabrice_sp> stochastic, are they 3.0 source format?
[10:13]  * stochastic isn't sure what that means
[10:13] <fabrice_sp> by the way, what about bug 479156?
[10:14] <fabrice_sp> hmm, flowcanvas is 1.0 format :-/
[10:14] <stochastic> fabrice_sp, that has been committed for Lucid's codbase
[10:14] <fabrice_sp> no idea then
[10:14] <fabrice_sp> u-u-s has been subscribed. So you want someone to review it?
[10:15] <fabrice_sp> it's still in progress
[10:15] <stochastic> fabrice_sp, I'm not sure what to mark that bug
[10:15] <fabrice_sp> do want your debdiff to be sponsored?
[10:16] <stochastic> fabrice_sp, I've committed the code changes to the bzr branch of ubuntustudio's seeds, but for it to be fixed in Karmic, someone else will need to push the debdiff
[10:16] <stochastic> I don't have the upload privileges
[10:16] <fabrice_sp> oh, for karmic. so it's a SRU
[10:17] <stochastic> yeah, but I'm not sure if the bug deserves a SRU fix for karmic
[10:17]  * stochastic hasn't ever filed an SRU before
[10:17] <fabrice_sp> you should subscribe ubuntu-sru team, then
[10:17] <fabrice_sp> !sru
[10:17] <fabrice_sp> just follow the guide ;-)
[10:17] <stochastic> fabrice_sp, do you think that bug deserves an SRU?
[10:17] <fabrice_sp> let me check
[10:18] <stochastic> or should it just get fixed in Lucid and be left at that?
[10:18] <fabrice_sp> not sure it's worth a SRU
[10:18] <stochastic> that's what I was thinking
[10:18] <fabrice_sp> what do think ubuntustudio members?
[10:19] <stochastic> ??? who are you asking?
[10:20] <stochastic> I can raise the issue at the next Ubuntu Studio Developer's meeting (Dec 13th)
[10:23] <stochastic> fabrice_sp, so what's the proper way to request Raul and Flowcanvas?
[10:26] <fabrice_sp> new packages should have been synced. Ask an archive admin, because I don't know
[10:27] <stochastic> fabrice_sp, do you know of any archive admins that would be around?
[10:27] <geser> as autosync needs now more handholding as in the past, I get the impression it's get done less frequent
[10:31] <stochastic> geser, would you know any archive admins that would be responsive a this time on a saturday?
[10:33] <geser> stochastic: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
[10:34] <fabrice_sp> have to go. Bye
[10:34] <geser> nobody on the weekends, unless you are lucky to reach one of them and presuade him
[10:35] <stochastic> geser, okay thanks.  I'll wait
[11:34] <cjwatson> stochastic: raul and flowcanvas (among others) are on their way in now
[11:45] <geser> anyone familiar with python-central around?
[11:50] <pochu> mvo and doko, but they're not around :)
[11:50] <pochu> POX too
[11:50] <pochu> geser: what's up?
[11:50] <geser> bug 490731
[11:53] <geser> hmm, when thinking more about it, isn't this more a dpkg problem? I remember something about changing a directory into a symlink
[12:02] <pochu> geser: sounds like a bug in the package
[12:02] <pochu> it should rmdir the directory in preinst I think
[12:02] <geser> yes, "A directory will never be replaced by a symbolic link to a directory or vice versa;" (policy 6.6.4)
[12:15] <stochastic> cjwatson, thank you very much!
[12:26] <stochastic> grr, flowcanvas failed to build
[13:00] <stochastic> hmm, on this build log: http://launchpadlibrarian.net/36472094/buildlog_ubuntu-lucid-i386.flowcanvas_0.5.1-1_FAILEDTOBUILD.txt.gz there's a line that says "sh: gcc: not found"  what could be causing gcc not to be found on a compile?
[13:02] <geser> stochastic: that line appears in all build logs, you can ignore that
[13:03] <geser> "error: 'uint32_t' has not been declared
[13:03] <geser> looks like a missing include (or a missing define)
[13:03] <stochastic> geser, yeah, it looks like it's a compiler issue with the code.  It built fine in Debian.
[13:03] <geser> stochastic: debian still uses gcc 4.3 by default, right? Ubuntu has gcc 4.4
[13:04]  * stochastic checks debian, but knows we use 4.4
[13:04] <stochastic> yes, that's correct
[13:04] <geser> did you do a testbuild before requesting the sync, didn't you?
[13:05] <stochastic> no, I was just eager to start building higher level packages
[13:06] <stochastic> geser, so the proper way to go about fixing this is to file a 'fails to build' bug on flowcanvas, get a patch cooked up, then make a debdiff?
[13:07] <geser> yes, and forward it to debian and upstream. Debian will have the same problem once it moves to gcc 4.4
[13:07] <stochastic> okay, will do.
[16:14] <ScottL> i'm working with the ubuntu studio developers trying to package lv2 apps for lucid
[16:14] <ScottL> but i don't think i've set up my pbuilder correctly for using lucid
[16:14] <ScottL> it doesn't seem to find the new lv2 apps already in lucid for building these new ones
[16:15] <ScottL> can someone answer a few questions about setting up pbuilder for newer releases
[16:17] <ScottL> this is the information that i've been following:   https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/gs-pbuilder.html
[16:18] <geser> ScottL: do you have universe enabled in your pbuilder?
[16:22] <ScottL> geser, to be honest, i'm not sure  i did update pbuilder with --othermirror "deb http://archive.ubuntu.com lucid universe mulitiverse"
[16:25] <ScottL> geser, are you talking about settings in ~./pbuilderrc?   I just found this in the wiki for pbuilder
[16:25] <geser> better check inside your pbuilder (pbuilder login) if universe is enabled (e.g. by looking at /etc/apt/sources.list)
[16:40] <ScottL> geser, i loging into the pbuilder and found sources.list but I don't know how to open it, gedit, less, vi, nano all don't work
[16:41] <geser> cat or install less (apt-get install less)
[16:45] <ScottL> geser, i forget about cat and quite frankly i didn't think to try apt-get inside the chroot environment, but I should have, brb
[16:46] <geser> a pbuilder chroot is very minimal so everything you need you have to install
[16:46] <ScottL> geser, using cat it i found that it only includes the main repository, so I could echo "deb etc, etc lucid universe" >> /etc/apt/security.list  no?
[16:47] <ScottL> but how would I save the changes under the chroot?
[16:47] <ScottL> obviously i need to read up on the chroot instead of just the pbuilder stuff
[16:47] <geser> either that (but then you need pbuilder login --save-after-login) or use the steps on the pbuilder wiki page
[16:48] <ScottL> i'll try the login --save-after-login....man, thanks a million
[16:49] <ryanakca> When a library bumps it's SONAME (libfoo1 -> libfoo2), and I bump it in control, do I have to add a conflicts or a replaces for libfoo1 ?
[16:50] <geser> no, that way you can have libfoo1 and libfoo2 both installed (unless you have a file conflict)
[16:50] <jmarsden> ryanakca: Usually, yes.  If the two libs can coexist on a system, no.
[16:50] <porthose> ScottL, have a look at pbuild-dist in ubuntu-dev-tools, I find it handy for managing multiple pbuilders :)
[16:50] <ryanakca> jmarsden: How can I find out if the can coexist?
[16:50] <jmarsden> ryanakca: Try installing them both and see if they conflict :)
[16:51] <ryanakca> jmarsden: lovely :)
[16:51] <geser> ScottL: btw your nick is pretty close to ScottK :)
[16:57] <ScottL> porthose, I read about that and I look forward to having that as I dabble in backporting jack, ardour, celt, ffado for ubuntu studio
[16:57] <ScottL> porthose, but i want to keep it simple until i feel like i have thing a little more under control ;P
[16:58] <porthose> ScottL, cool :)
[16:58] <ScottL> geser, yeah, our last names even have the same number of syllables   :D
[16:58] <ScottL> oh, it appears that it's working btw    thanks you guys, big time help
[17:00] <qnix> hmm... what the other tool similar to cowbuilder/pbuilder ?
[17:01] <qnix> cbuilder? something like that...
[17:01] <geser> sbuild?
[17:01] <qnix> yea! thx.
[17:02] <qnix> What are the benefits to use it instead of cowbuilder&
[17:43] <mok0_> qnix, the real advantage of sbuild is that you can use it with LVM snapshots
[17:44] <qnix> so, the chroot is never corrupt or something?
[17:44] <qnix> I've never had problem with my current setup. (not using snapshot)
[17:45] <hyperair> it really depends which technology you prefer
[17:45] <hyperair> i prefer cowbuilder since my space isn't limited.
[17:46] <davromaniak> hi
[17:46] <davromaniak> I would like to know if there's a template page for the laptop tests on the wiki
[17:46] <qnix> Currently, My build machine is a openvz vm, so I guess sbuild will not bring me any benefit.
[17:47] <qnix> It works well, and I can move my build machine anywhere easily.
[17:47] <qnix> Anyway, will try sbuild a day for sure.
[17:48] <ryanakca> libqinfinity bumped its SONAME from 1 to 2 between 1.0~beta3-1 and 1.0~beta4-1, are these the correct conflicts? http://paste.ubuntu.com/335401/
[17:56] <fcuk112> doing a merge using grab-merge.  i updated the files that appeared in the REPORT file under the debian folder, but apart from that i do not see any other changes that need to be made.  does this mean i need to raise a sync bug?
[17:57] <fcuk112> the patches under debian/diff still apply.
[18:02] <geser> ryanakca: why the conflicts at all?
[18:03] <geser> fcuk112: which package did you work on?
[18:03] <fcuk112> geser: it's dash.
[18:04] <ryanakca> geser: Wait, I don't need them now that I look at it, I didn't want an old version of libqinfinity-dev to be installed alongside libqinfinity2, so I would just need to have a conflicts between libqinfinity2 and libqinfinity1 so that the two don't get installed together.
[18:05] <geser> ryanakca: can't they both be installed at the same time?
[18:06] <ryanakca> geser: Well, wouldn't having libqinfinity-dev and both libqinfinity1 and libqinfinity2 installed at the same time cause confusion? If I had libqinfinity-dev installed and upgraded to libqinfinity2, I would want to make sure libqinfinity-dev got upgraded too
[18:07] <geser> fcuk112: the files mentioned in the REPORT are files that MoM can't merge itself (listed at Conflicts). This files need human action. But they might be other changes which MoM could apply itself (like new patches in debian/patches)
[18:08] <fcuk112> geser: there's no debian/patches folder, just debian/diff - i checked those and they still appear to apply (no changes).
[18:08] <fcuk112> geser: so i just updated 2 files which appeared in the REPORT file.
[18:08] <fcuk112> geser: so no additional changes to add in the changelog => should it be a sync?
[18:10] <porthose> fcuk112, you should be asking yourself, in debian/changelog what changed to caused the initial delta :)  If the change that caused the delta is still needed then merge the package if not sync it :)
[18:10] <geser> fcuk112: then check if the other Ubuntu changes got included in the Debian package
[18:12] <geser> ryanakca: only if you care about users, the buildds will pick up the latest available version
[18:12] <ScottK> ryanakca: Generally you want the libraries themselves to co-installable for transition purposes.
[18:12] <ryanakca> geser, ScottK: OK. So no conflicts / whatsoever?
[18:12] <ryanakca> conflicts/replaces
[18:15] <geser> no
[18:15] <fcuk112> geser: these are the previous ubuntu changes: http://pastie.org/729226.  how do i check if these have been applied in the debian package?
[18:17] <geser> what about the changes from -2ubuntu1?
[18:18] <fcuk112> geser: http://pastie.org/729232
[18:18] <geser> you should have a patch with all the Ubuntu delta (or look at LP for the changes between each upload) and check if the debian/changelog mentions them (you might also look into the changed files)
[18:19] <fcuk112> geser: these changes have been picked up in the new version.
[18:21] <geser> fcuk112: if I don't know what is left after the merge attempt from MoM, I create a debdiff between the Debian version and the MoM version and look what is inside
[18:22] <fcuk112> geser: OK, thanks.
[19:45] <ari-tczew> is debhelper 7.3.16 somehow specially changed than 7.3?
[19:52] <jgoppert> how do i build a package that depends on sudo-ldap, i need to export SUDO_FORCE_REMOVE=yes, i tried doing this in my preinst script but this didn't work
[20:21] <jgoppert> s there any way to have a package export an environment variable exported before conflicting packages are removed?
[20:23] <jgoppert> *is there any way to have a package export an environment variable before conflicting packages are removed
[20:31] <ScottK> jgoppert: It's probably better if you explain what problem you are trying to solve.
[20:37] <jgoppert> i was trying to create a meta-package for ldap client that had sudo-ldap and other packages, but sudo-ldap requries that you export SUDO_FORCE_REMOVE=yes, i tried to put this in the hsl-desktop.preinst file but it didn't run before the conflicting packages were removed, which triggered the sudo-ldap.prerm script that check for the exported variable
[20:40] <jgoppert> i asked over at debian-mentors and was told to just give up on sudo-ldap and try to use pam
[20:41] <ScottK> Probably good advice, although it's not really a part of the system I know a lot about.
[20:45] <jgoppert> well thanks for you input Scott
[21:45] <jgoppert> if i want to package a vimrc.local file in a meta package for my workstations how should i install it?
[21:47] <jgoppert> the meta package doesn't have a makefile, should i just put the install command in debian rules?
[21:50] <geser> yes
[21:50] <jgoppert> thanks
[22:57] <Guest39184> Have few questions about packaging. anyone willing to help ?
[22:58] <nhandler> Guest39184: Try asking the questions. People will respond if they know the answer
[22:58] <Guest39184> ok is there any skeleton script for rc scripts in debian ?
[22:59] <Guest39184> or are any special requirements for rc scripts ?
[23:01] <Guest39184> sorry.. by debian i mean ubuntu of course :)
[23:10] <Guest39184> can anyone pls confirm that this applies also to ubuntu ? http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
[23:15] <ScottK> Guest39184: Sort if.  We use upstart instead of sysvinit, but it's got a compatibility mode, so that should work.
[23:18] <Guest39184> I am trying to create a package for a software that does not use autoconf but just a plain makefile. I created package skeleton with "dh_make -s -c gpl" but i do not know how to tell in rules file that makefile is located in src/ directory not in package root. Any ideas ?
[23:27] <geser> either "cd src && make" or "make -C src"
[23:35] <Guest39184> geser, thx works great
[23:38] <Guest39184> I understand that in install target of makefile binaries should be copied to $(DESTDIR)/bin and configuration files to $(DESTDIR)/etc. Is this correct? Where should I copy man pages ?
[23:42] <geser> $(DESTDIR)/usr/bin ($DESTDIR is usually debian/tmp as the staging directory for packaging building)
[23:43] <sebner> mighty geser, as lively as ever, especially at that time :)
[23:43] <geser> Hi sebner :)
[23:52] <Guest39184> so binaries to $(DESTDIR)/usr/bin and manpage to $(DESTDIR)/usr/share/man/man8
[23:53] <ScottK> If they are in section 8, yes.
[23:57] <Guest39184> I would like to create a package for 10.04 release. Which version of ubuntu should I use to create the source package?