[00:00]  * jdong quietly blames upstart/udev and reboots
[00:26] <jdong> it IS kinda cool when btrfs can tear down a pbuilder as fast as reiserfs did
[00:37] <geser> pbuilder on tmpfs :)
[00:42] <jdong> haha that's what I used to do
[00:42] <jdong> the downfall was what to do about the aptcache ;-)
[00:44] <jdong> and then there's those obscene builds like openoffice :)
[00:44] <jdong> not saying btrfs handles that any better
[00:48] <jdong> HOLY CRAP thunderbird final linking balloons a lot of RAM!
[01:12] <TheMuso> bdrung: I will have a look at eclipse on powerpc. I use sbuild, so I can replicate an eenvironment where arch all packages don't get built.
[01:13] <TheMuso> I can also look on amd64/i386
[06:29] <trip0> what's the procedure for submitting a patch to a package?
[06:29] <trip0> launchpad?\
[07:07] <tonyyarusso> Can anyone tell me the name of the site that a lot of FLOSS devs use for collecting donations?  I'm totally blanking on the one I'm thinking of...
[07:14] <fabrice_sp> trip0, yes: open a bug report, attach the debdiff, and subscribe Ubuntu Sponsors for Universe
[07:15] <trip0> kk
[07:16] <trip0> tonyyarusso: paypal?
[07:16] <tonyyarusso> trip0: I was thinking of something that would show progress towards a goal.  I'm hoping I'll recognize the name if someone comes up with it, but it's not just the payment service itself.  (ie you could use paypal to make a donation on foo)
[07:58] <fale> hi
[08:11] <fabrice_sp> hi fale
[08:11] <fale> I tried to bring libboost from debian to a ppa... but it fails with this error: http://launchpadlibrarian.net/33809173/buildlog_ubuntu-karmic-i386.boost1.40_1.40.0-2ubuntu0_FAILEDTOBUILD.txt.gz any idea?
[09:37] <geser> fale: one problem is, that it tries to build with python2.4 (karmic has python2.6 as default)
[09:50] <fale> geser: I have to force the installation of python 2.5 and the compile of it?
[09:52] <geser> fale: it already installs python2.5 and python2.6 via build-depends but somewhere force it to use python2.4
[09:52] <geser> "Detecting Python version... 2.6
[09:53] <geser> but later -I"/usr/include/python2.4"
[09:54] <geser> perhaps the 'echo "using python : 2.4 : /usr ;" >> user-config.jam' causes it
[09:57] <geser> fale: you might want to look at the patch to boost1.38 to see what's needs to be changed to build with the current python versions in ubuntu (http://launchpadlibrarian.net/26972978/boost1.38_1.38.0-6_1.38.0-6ubuntu1.diff.gz)
[09:58] <fale> geser: I see.. than I'll try to make it using 2.5
[10:26] <fale> geser: I'm creating the package... soon I'll upload it.. and wait to see if I fixed it :)
[10:27] <geser> fale: if you use pbuilder you can test it yourself if you don't want to wait on the PPA builders and only upload it when you're done
[10:29] <fale> geser: :) I'll install pbuilder, than :)
[10:34] <jetienne> q. what is the correct directoryh to put a python executable ?
[10:45] <geser> like any other executable, /usr/bin
[10:49]  * fale is compiling... hoping the best
[10:50] <fale> geser: If it does compile correctly, I could try to push boost 1.40 in lynx?
[10:57] <jetienne> geser: nothing special because it is noarch ?
[10:58] <fale> jetienne: nope
[10:58] <jetienne> ok thanks
[11:00] <fale> again http://launchpadlibrarian.net/33823851/buildlog_ubuntu-karmic-i386.boost1.40_1.40.0-2ubuntu1_FAILEDTOBUILD.txt.gz :(
[11:01] <geser> fale: it took me some time to realise that with lynx you not meant the text webbrowser but the next ubuntu release (lucid) :)
[11:02] <fale> geser: ops, I call (wrongly) lynx... I'll try to change behave ;)
[11:02] <geser> fale: as boost1.40 is Debian unstable it will get auto-synced once lucide opens but will need the fix you're working now on
[11:03] <fale> geser: oki ;)
[11:03] <fale> geser: I rebuilted it... but it seems that there are problems with enums :(
[11:04] <fale> geser: I think is an error in some config, because debian is able to compile it ( http://packages.debian.org/sid/libboost1.40-dev )
[11:07] <geser> fale: don't forget that debian still builds with gcc 4.3 as default while ubuntu uses already gcc 4.4 as default
[11:08] <fale> geser: that can be a huge problem...
[11:09] <fale> geser: an OT question: because ubuntu and debian are very similar and bring packages back and forth... woudn't be easyer to have a unique repo?
[11:10] <geser> I'm not saying that this might be the problem but as there are differences in the toolchain between debian and ubuntu, a package which builds in debian might fail in Ubuntu for different reasons
[11:11] <geser> fale: not really possible, as e.g. Debian and Ubuntu have different speed of development (e.g. Debian releases once in around 2 years, while Ubuntu once every 6 months)
[11:12] <fale> I see
[11:13] <geser> and trying to coordinate which version went when into to common repo would be pretty hard
[11:15] <fale> I see
[11:16] <geser> Debian uses gcc 4.3, Ubuntu gcc 4.4; Debian uses eglibc 2.9, Ubuntu already eglibc 2.10; Debian catched now up to Gnome 2.28 like in Ubuntu, and so on
[11:17] <fale> geser: well, I don't think that debian is behind because they want it, but more because they don't have enough human-power to do everything
[11:21] <jetienne> q. what is the control files's Architecture for python code ? i tried any and all
[11:21] <joaopinto> jetienne, it should be "all" if it's entirely python
[11:21] <jetienne> ok thx
[11:23] <joaopinto> there are some efforts in progress to synchronize the toolchaing between Debian and UBuntu
[11:53] <jetienne> q. is there a way to make dh_make not to ask interactive questions ? especially the "are you sure" ones
[11:57] <joaopinto> jetienne, man dh_make
[11:57] <jetienne> joaopinto: you mean yes or no ?
[11:58] <joaopinto> jetienne, I mean it's on the manual, we can help you but we are not a replacement for the man
[11:58] <jetienne> ok :)
[11:59] <jetienne> joaopinto: well if you dont wanna help this is ok
[11:59] <jetienne> joaopinto: and yes/no wont kill you
[11:59] <jetienne> and dont assume i didnt read it
[11:59] <jetienne> no hard feeling
[11:59] <joaopinto> jetienne, If I didn't want to help I would not have answer you, which I did with a pointer to the answer
[12:00] <joaopinto> :)
[12:00] <jetienne> well i will wait and ask again
[12:00] <jetienne> as i read the "pointer" you refer to
[12:01] <jetienne> Depends: ${shlibs:Depends}, ${misc:Depends} <- where can i find the definition of those macro ?
[12:04] <joaopinto> jetienne, man deb-substvars
[12:05] <jetienne> joaopinto: well if you dont have anything to say except rtfm, please ignore me
[12:08] <joaopinto> hum, misc:Depends is not described on the manpage, it's used by debhelper, not sure for which purposes
[12:08] <jetienne> the first part is not defined either
[12:09] <joaopinto> yes it is
[12:09] <joaopinto>        shlibs:dependencyfield
[12:09] <joaopinto>               Variable settings with names of this form are generated by dpkg-shlibdeps.
[12:09] <jetienne> :)
[12:09] <joaopinto> it is set to the list of shared libraries identified by dh_shlibdeps
[12:09] <jetienne> this is not a description this is a single line saying nothing :)
[12:10] <jetienne> like what it is doing ?
[12:10] <joaopinto> jetienne, at the bottom of the man page there is a section with other relevant pages, I guess you want to understand what is dpkg-shlibsdeps is about
[12:10] <joaopinto> man dpkg-shlibdeps
[12:11] <jetienne> nah
[12:11] <jetienne> i want to make a deb and find help to do so :)
[12:11] <jetienne> i do understand you are a rftm person
[12:12] <joaopinto> jetienne, to summarize, the shlibs varialble will be replaced with the package names that provide the share libaries used by binaries on your package
[12:12] <jetienne> this is ok please ignore me, please
[12:12] <jetienne> lets be civil
[12:13] <joaopinto> jetienne, if you want to create a .deb without learning manuals, you are on the wrong place
[12:13] <jetienne> joaopinto: well many people here are ok to help
[12:13] <joaopinto> the only people feeling offended is you, I am just answering to your questions, and you don't like the help :)
[12:13] <jetienne> joaopinto: well ok. please ignore me
[12:13] <joaopinto> just ignore the answers if you don't like them, other people on the channel may like :)
[12:13] <jetienne> i dont want to fight :)
[12:14] <joaopinto> jetienne, I don't like to ignore people, again, you are the one offended, feel free to ignore me :)
[12:14] <jetienne> im not offended, just not willing to fight with somebody who think rftm is more important than coc
[12:15] <jetienne> this is ok
[12:15] <joaopinto> I am not simply rftm, I am pointing the specicif manual pages you should read related to your questions :)
[12:15] <jetienne> joaopinto: yeah right. credible
[12:15] <jetienne> you are right
[12:15] <jetienne> now please ignore me, you are discouraging other people to help
[12:17] <joaopinto> jetienne, https://wiki.ubuntu.com/PackagingGuide/Complete - it also describes the purpose of those variables you have asked about
[12:17] <jetienne> PLEASE IGNORE ME
[12:17] <joaopinto> !caps | jetienne
[12:18] <jetienne> !coc | joaopinto
[12:18] <jetienne> see if you can read that
[12:18] <joaopinto> I have read and signed, tks :)
[12:21] <jetienne> well honor your word then
[12:22] <jetienne> ok will be back during the week
[13:45] <jetienne> q. how to update the debian/changelog automatically ?
[13:46] <joaopinto> jetienne, use the dch utility
[13:46] <joaopinto> jetienne, dch -i or dch -a
[13:46] <joaopinto> jetienne, man dch for more details
[13:47] <jetienne> joaopinto: ok sorry i will have to ignore you as you keep intervinning.
[13:47] <jetienne> no hard feeling just trying to be productive
[13:49] <joaopinto> man, you must have serious problems, you get the answers and still complaining about it :)
[13:49] <directhex> yeah, wtf?
[14:07] <iulian> Oh well, he obviously doesn't like reading manual pages.
[14:08] <jetienne> arf
[14:09] <jetienne> debchange -i doesnt work if it is a native package. as opposed to what the man page say
[14:13] <iulian> Eh?
[14:13] <iulian> Are you sure you're reading the right man page?
[14:14] <iulian> "Increment either the final component of the Debian release  number or, if this is a native Debian package, the version number."
[14:14] <jetienne> yep and this add ubuntu2
[14:35] <geser> jetienne: what was the original version, what did you get and what did you expect to get as version?
[14:36] <jetienne> geser: the original version ? not sure to undersand this is a code of mine im packaging. i used dh_make --single --email myname@gmail.com --native to generate it
[14:37] <jetienne> --increment added ubuntu suffix even i used --native, as opposed to the man page
[14:37] <jetienne> but honnestly i would not have complain without the rftm episode i experienced
[14:37] <geser> why did you use --native? it's mostly for software written only for Debian/Ubuntu
[14:38] <jetienne> geser: because this is only for ubuntu
[14:38] <geser> jetienne: the package or the software?
[14:38] <jetienne> both
[14:39] <geser> dch applies by default the ubuntu versioning scheme on Ubuntu
[14:39] <jetienne> geser: this is ok, writing my own script to update changelog fix it
[14:39] <jetienne> geser: not according to the manual :)
[14:41] <geser> true, it does it always as it hard to difference between modifying Debian packages and Ubuntu-only packages
[14:41] <geser> but even then it's a good idea to use the ubuntu postfix if it's not clear from the package name that the package is Ubuntu-only
[14:42] <jetienne> noted
[14:42] <geser> just curious: what kind of application is it, that it will only be useful to Ubuntu and not Debian too?
[14:43] <jetienne> is there a tool parsing "debian/changelog" able to give the current version
[14:43] <jetienne> geser: we do not plan to support debian by lack of time to support/test it
[14:49] <joaopinto> jetienne, but some on Debian may decide to adopt your package, and if you make it native your are just making their life harder
[14:49] <joaopinto> someone
[15:03] <ys___> hi, I need some help with the ppa building system, can somebody help me?
[15:04] <ys___> I'm trying to build a package but it's current build status is "Dependency wait"
[15:04] <ys___> what should i do now?
[15:10] <jetienne> ys___: wild guessing. maybe you depend on a .deb which is not available, and the build assume it will, and so wait for it
[15:11] <ys___> the build assume it will? when?
[15:11] <jetienne> ys___: no idea. i was wild guessing
[15:11] <ys___> oh, thanks
[15:11] <jetienne> debchange -b --changelog changelog --newversion "0.01build`date +%Y%m%d%k%M%S`" "Automatic packaging" <- im focusing on this kind of thing :)
[15:14] <ys___> i don't understand that
[15:14] <randomaction> ys___: you should probably look at the build log and see which build-dependency is missing. probably you mistyped the package name, or try to depend on a package not available in Ubuntu
[15:15] <ys___> Missing build dependencies: libgconf2.24-cil
[15:15] <ys___> oh, that's truth
[15:18] <ys___> thank you, i'm retrying :)
[15:49] <dtchen> zul: WRT whois: you probably need to update config.h's VERSION macro, too
[15:59] <dtchen> zul: http://pastebin.com/dc948ea6
[17:29] <LLStarks> hi. wicd needs a package update and there's also the problem that the dbus daemon it relies on won't load.
[17:29] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/wicd/+bug/454067
[19:47] <LordMetroid> Master of the Universe please take a look at the CouchDB package installation dependencies, they are broken and couchdb can not be installed properly nor launched due to this
[20:00] <dtchen> jdong: you have a macbook 5,1 , correct?
[20:00] <dtchen> (or rather, anyone with a macbook 5,1 running os x)
[20:02] <jdong> dtchen: macbookpro 5,2
[20:04] <dtchen> jdong: does jack sense work in current Karmic?
[20:04] <dtchen> i'm having a heckuvatime finding the drivers for Darwin
[20:05] <dtchen> not even sure they're exposed, but i'm looking for the init verbs for 5,1 and 5,2
[20:08] <jdong> dtchen: no, jack sense doesn't, I have a LP bug open regarding that...
[20:08] <dtchen> jdong: i'll need some info from the mac os x side
[20:08] <jdong> dtchen: but yeah I have the system booted into OS X right now if you need me to grab anything from it
[20:09] <dtchen> jdong: since i'm unfamiliar w/ os x, i don't know offhand if the init verbs are exposed anywhere
[20:09] <jdong> ok lemme poke around a bit
[20:10] <dtchen> jdong: if we can find those, we can pretty easily patch it in using the new patch infrastructure for HDA
[20:10] <dtchen> i.e., we write a text file and put it in /lib/firmware/$(uname -r)/foo, and you pass the filename to snd-hda-intel patch=foo
[20:11] <dtchen> anyhow, let me know if you find anything; i'm offline until tomorrow afternoon. i need a break from this sound mess.
[20:15] <jdong> dtchen: sounds good (haha sorry for that awful pun); you'll hear from me if I find anything that looks useful
[20:19] <jdong> dtchen: the only thing that looks remotely "useful" is http://jdong.mit.edu/~jdong/AppleHDAPlatformDriver.kext_Info.plist within the driver...
[20:19] <jdong> dtchen: seems like some sort of mapping, though I don't have the knowledge to make heads or tails out of it
[20:20] <jdong> one of the most eye opening XML files I've seen in a while too....
[20:22] <jdong> dtchen: might be old news to you, but various internet noise like http://bbs.pcbeta.com/redirect.php?tid=349924&goto=newpost seems to have insight on what the big-blobs-of-BASE64 mean.
[20:41] <quidnunc> Is checkinstall safe if the installer is untrusted?
[20:41] <quidnunc> In other words, will checkinstall provide a reasonable degree of protection by installing in a chroot?
[20:41] <jdong> is it even safe if the installer is trusted?
[20:42] <joaopinto> quidnunc, is just as safe as the install
[20:42] <jdong> but the answer is no
[20:42] <superm1> jdong, the old problems that plagued it have been fixed AFAIK
[20:42] <jdong> checkinstall I believe uses LD_PRELOAD to trap attempts to install stuff, to divert them to a deb package
[20:42] <quidnunc> joaopinto: I thought it used a chroot so it wouldn't actually touch my filesystem
[20:42] <superm1> (security wise)
[20:42] <superm1> it still won't produce policy compliant packages of course
[20:42] <jdong> superm1: oh, I was unaware of that...
[20:43] <joaopinto> quidnunc, the install is regular, it just tracks the installed files and builds a .deb from it
[20:43] <jdong> but even a chroot is inappropriate for UNTRUSTED installers.
[20:43] <jdong> root can still circumvent chroots :)
[20:44] <joaopinto> a root process running from a chroot can break it ?
[20:44] <quidnunc> I basically want to see what the installer is going to try to do and manually grant it permissions but I also want to use checkinstall so I can easily uninstall it afterwards
[20:44] <jdong> joaopinto: absolutely
[20:44] <joaopinto> quidnunc, make -n install
[20:44] <jdong> joaopinto: in fact the truly concerned sysadmin doesn't even want to run non-root users unconfined in a chroot...
[20:44] <quidnunc> joaopinto: It is a binary installer
[20:44] <joaopinto> quidnunc, run it from a chroot :)
[20:45] <jdong> quidnunc: you can log what the installer does by putting an apparmor null complain profile around it :)
[20:45] <jdong> then your audit logs will spew over everything the installer is doing.
[20:46] <quidnunc> jdong: Yes I thought of that but it will actually do those things. I don't want it to do those things because I want to use checkinstall to make sure I can uninstall it.
[20:46] <quidnunc> joaopinto: Isn't that what checkinstall does?
[20:47] <jdong> checkinstall will do it for cooperating installers.
[20:47] <jdong> if you're concerned about a *malicious* installer, then no.
[20:47] <quidnunc> I guess I would want some kind of combination of checkinstall and apparmor
[20:47] <jdong> that's a much more challenging situation
[20:47] <joaopinto> quidnunc, no, checkinstall does not install over a chroot
[20:47] <jdong> you can use checkinstall in a chroot with apparmor protection :)
[20:47] <jdong> though that's a pain to set up ;-)
[20:49] <quidnunc> joaopinto: But it doesn't actually install right?
[20:51] <quidnunc> checkinstall says it has fstrans
[20:51] <quidnunc> An --fstrans options "causes the install to proceed in a temporary directory, thus not actually touching your system"
[20:52] <joaopinto> it does install, i mean, with the default options, i am not familiar with thtat option
[23:14] <mrooney> YokoZar: what do we do about bugs like http://bugs.winehq.org/show_bug.cgi?id=20288 where the user can't file it in Ubuntu because it's the PPA version but upstream says it is our problem?
[23:16] <ScottK> mrooney: If it's in a PPA, it's not "our" in the sense of MOTU's problem.
[23:16] <mrooney> I meant "our" in the larger Ubuntu sense :)
[23:20] <ScottK> I think PPA problems are the problems of the PPA owner
[23:46] <jdong> mrooney: hopefully the PPA owner has set up a launchpad product or some other way to track bugs then
[23:46] <jdong> I know the Mozilla team and some Kubuntu PPA documents suggest filing Ubuntu bugs on their PPA packages, and heck even that practice seems somewhat controversial around here
[23:56] <ScottK> The difference in those cases is that the same people maintain the packages and they are generally used as prestaging for stuff going into the archive.
[23:58] <jdong> right, forgot to mention that :)