[00:41] <sim> Hi
[00:41] <sim> I have some issue with a ppa build
[00:42] <sim> here is the build log file:
[00:42] <sim> http://launchpadlibrarian.net/49573645/buildlog_ubuntu-lucid-amd64.linux_2.6.32-21.32%2Bnet5bigxp.1_FAILEDTOBUILD.txt.gz
[00:42] <sim> and the interesting part is:
[00:42] <sim> dpkg-deb: building package `linux-image-2.6.32-21-preempt-dbgsym' in `../linux-image-2.6.32-21-preempt-dbgsym_2.6.32-21.32+net5bigxp.1_amd64.deb'.
[00:42] <sim> dpkg-deb (subprocess): data: internal gzip error: read(4096) != write(0): No space left on device
[00:44] <sim> I am not a packaging specialist bu it looks like there is no space left on device
[00:44] <sim> or my package is wrong
[00:44] <sim> anyway, any hints are welcome
[02:40] <ScottK> askhl_: Depending on what python packages one has installed and what release we are discussing having all three of those is quite normal.
[02:40] <ScottK> If you want help with non-Ubuntu packaging, you should try #ubuntu-packaging.
[02:51] <askhl_> ScottK, thank you
[02:51] <ScottK> No problem.
[04:37]  * ajmitch wonders why bzr merge-package is being so unhelpful with changes in debian/control
[04:37] <ripps> Can someone please tell me what's wrong with gmpc amd64 build? It's done this on and off throughout Lucid's development cycle, and now, it suddenly started doing it again. http://bit.ly/8XaWut
[08:08] <dholbach> good morning
[08:10] <ajmitch> morning dholbach
[08:10] <dholbach> hi ajmitch
[08:11] <ajmitch> how's it going?
[08:11] <dholbach> good good - how 'bout you?
[08:12] <mok0> hey dudes
[08:12] <dholbach> hey mok0
[08:42] <toabctl> i try to package some software but get the following error: $ dpkg-source -b loco
[08:42] <toabctl> dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
[08:42] <toabctl> but in the same directory are 2 files: loco_1615.debian.tar.gz and loco_1615.orig.tar.gz
[08:42] <toabctl> any ideas?
[08:47] <hyperair> toabctl: i think you need to give dpkg-source -b a dsc file?
[08:47] <toabctl> hyperair, i have no .dsc file.
[08:48] <toabctl> hyperair, i just have the original source tree (which i pack to a .orig.tar.gz) and a debian directory (which i pack to debian.tar.hz)
[08:48] <hyperair> if you've got a .debian.tar.gz and a .orig.tar.gz how can you not have a .dsc file?
[08:49] <hyperair> and the version seems kinda weird as well. "1615"? where's the debian revision
[08:53] <mok0> hyperair, probably a native package
[08:54] <sim> Hi
[08:54] <hyperair> mok0: mm yes, probably.
[08:54] <hyperair> toabctl: have you extracted the loco packaeg?
[08:54] <toabctl> hyperair, mok0 it my own source-code
[08:54] <toabctl> it's just a svn repository.
[08:55] <sim> I am looking for a way to restrict the targets (for ppa build)
[08:55] <hyperair> toabctl: what are you trying to do, then?
[08:55] <mok0> toabctl: is it a native package?
[08:55] <sim> Here is the ppa: https://launchpad.net/~sguinot/+archive/net5big-xp
[08:55] <toabctl> mok0, what means native?
[08:55] <toabctl> hyperair, i want to package my own software as a debian package.
[08:55] <mok0> toabctl: strictly Ubuntu, not useful for anything else
[08:55] <sim> The amd64 build fail because there is no space left on device
[08:55] <sim> apt-get install hard-disk :)
[08:56] <hyperair> toabctl: and what are you trying to do with dpkg-source?
[08:56] <toabctl> mok0, no. it's a webinterface for an embedded device.
[08:56] <mok0> toabctl: then you shouldn't make it native
[08:56] <sim> on the other hand, i am not interested in building _all_ the kernel binary (or non-binary) packages
[08:56] <toabctl> hyperair, originallly, i tried to build it with dpkg-buildpackage but the "dpkg-source" command failed.
[08:56] <sim> just 2 or 3 of them should be enough for me
[08:57] <hyperair> toabctl: did it say why?
[08:57] <sim> so, there is anyway to give some options to the ppa buildbot
[08:59] <toabctl> hyperair, it's the same error. dpkg-buildpackage just executes: "dpkg-source -b loco"
[08:59] <hyperair> toabctl: how did you invoke dpkg-buildpackage?
[09:00] <arand> sim: https://help.ubuntu.com/community/Kernel/Compile#Modify%20the%20source%20for%20your%20needs Has some instructions on how to disable building -rt and -xen for example, if you don't need them it might save you some space hopefully...
[09:00] <sim> arand: actually I could keep this ones :)
[09:00] <hyperair> toabctl: your pwd should be your source directory (as in, .orig.tar.gz is in ../ and debian/changelog is in ./debian/changelog), and run dpkg-buildpackage -b
[09:01] <toabctl> hyperair, dpkg-buildpackage -us -uc -rfakeroot
[09:01] <hyperair> toabctl: you need to either specify -b or -S, i think.
[09:01] <hyperair> toabctl: do you want a binary or a source package?
[09:03] <toabctl> hyperair, both
[09:03] <sim> arand: I am not very confortable with modifying the package controls by removing some targets
[09:03] <hyperair> toabctl: then add a -b
[09:03] <hyperair> toabctl: dpkg-buildpackage -b -us -uc -rfakeroot
[09:03] <sim> modifications have to be less intrusive as possible
[09:04] <arand> sim: Like mentioned in #lp, I think you don't have much choice otherwise...
[09:06] <toabctl> hyperair, what about the source format ( i use 3.0 quilt). i thought i need also a debian.tar.gz in SOURCE/../
[09:07] <toabctl> hyperair, i use a Makefile to create a release with:
[09:07] <toabctl> $ dpkg-source -b loco
[09:07] <toabctl> tail: cannot open `loco/debian/changelog' for reading: No such file or directory
[09:07] <toabctl> dpkg-source: error: tail of loco/debian/changelog gave error exit status 1
[09:07] <toabctl> sorry. wrong post.
[09:07] <toabctl> release: revision
[09:07] <toabctl> 	@echo $(RELEASENAME)
[09:07] <toabctl> 	tar cfz ../$(RELEASENAME_ORIG) ../loco/ --exclude-vcs --exclude=loco/debian
[09:07] <toabctl> 	tar cfz ../$(RELEASENAME_DEBIAN) ../loco/debian --exclude-vcs
[09:07] <toabctl> ^^ that's it
[09:07] <toabctl> hi dholbach
[09:17] <dholbach> hi toabctl
[09:19] <BlackZ> can someone sponsor bug #588664 ?
[09:58]  * hyperair tickles sebner 
[09:58]  * sebner pets hyperair 
[09:58] <hyperair> sebner: you use maverick, right?
[09:59] <sebner> hyperair: hrm, in fact I use lucid with some packages from maverick :P
[09:59] <hyperair> lol
[09:59] <sebner> hyperair: LTS! I want a stable system now and then :P
[09:59] <hyperair> hehehe =p
[10:00] <hyperair> i thought you were all about bleeding edge
[10:01] <hyperair> i was wondering how client-side-decorations were done in maverick.
[10:02] <sebner> hyperair: wth is client-side-decoration?
[10:02] <hyperair> sebner: moving window decorations from the window manager's role to each applications' roles.
[10:03] <hyperair> sebner: i'm wondering how they're intending to pull it off without resulting in inconsistency horror.
[10:04] <sebner> hyperair: is that even implemented already?
[10:04] <hyperair> sebner: from what i heard, they attempted to turn it on in lucid, but ran into all kinds of walls and turned it back off.
[10:04] <hyperair> and it's back on maverick, or so i've heard.
[10:05] <sebner> hyperair: dunno, try maverick alpha1 later in a vm :P Ack about the horror stuff though
[10:06] <hyperair> sebner: there was an open letter by some kwin dude.
[10:06] <hyperair> sebner: considering all that was said about how the notification area was *inconsistent*, it's really puzzling why they're now straying down the CSD path.
[10:06] <sebner> hyperair: desktop team should care about gnome-shell and improve integration in ubuntu then going wild alone again ..
[10:07] <sebner> *than
[10:07] <RAOF> CSD has been on the road map for a long time.
[10:07] <RAOF> (GTK roadmap)
[10:07] <kklimonda> heh, lets not talk about gnome-shell ;)
[10:08]  * sebner hides
[10:08] <sebner> hyperair: RAOF is now a coninical guy, we have to watch out! Psssssssssssssst :P
[10:09] <StevenK> sebner: If you're going to troll, how about you at least type correctly? :-)
[10:10] <kklimonda> hyperair: applications that support csd should look the same. one thing I'm not sure about is running remote applications but then I find remote features of X11 a relic of the ancient past.. ;)
[10:10] <sebner> StevenK: full ack ^_^
[10:11] <sebner> StevenK: .. and I don't troll RAOF, he is a valued member of debian-cli ;)
[10:24] <slytherin> What is process for SRU these days? Attach debdiff, get it reviewed and upload OR attach debdiff, upload and get everything reviewed?
[11:07] <dupondje> dholbach: a question on bug (https://bugs.launchpad.net/bugs/588166) you commented. So the depends needs to be in main also for a main package right? else it can't be synced ?
[11:07] <dholbach> dupondje: exactly
[11:08] <dupondje> ah k :D
[11:08] <dupondje> sounds logic :)
[11:09] <keffie_jayx> I have question on the patches... If a patch is in the list t be applied and somehow the source directory has changes in name due to version numbers... does the patch still gets applied or one has to manully fix the paths in the  patch
[11:10] <mok0> keffie_jayx: without knowing for sure, I would think that you need to fix the paths
[11:11] <keffie_jayx> I think so too
[11:11] <c_korn> keffie_jayx: you don't need to update the patch if the source directory name changed.
[11:11] <keffie_jayx> thanks
[11:12] <c_korn> the patches are run with -p1
[11:15] <mok0> c_korn: that depends on what way the paths have changes
[11:15] <mok0> s/changes/changed
[11:15] <c_korn> of course. if the path inside the source directory changed the patches have to be changes for sure
[11:16] <c_korn> I thought keffie_jayx just meant a source directory name change
[11:16] <c_korn> s/changes/changed/
[11:16] <c_korn> :)
[11:16] <keffie_jayx> it is just the source directory
[11:16] <keffie_jayx> versions
[11:16] <mok0> c_korn: your left pinky is also misbehaving :-)
[11:16] <keffie_jayx> I am finding out why a patch won't get applied
[11:16] <mok0> keffie_jayx: hm
[11:16] <keffie_jayx> it is active in the list, the patch system is quilt
[11:16] <mok0> keffie_jayx: then c_korn is right
[11:16] <keffie_jayx> series lists it
[11:17] <keffie_jayx> and it must be another patch overriding changes
[11:17] <mok0> keffie_jayx: or reversing the changes
[11:17] <keffie_jayx> or simply not found in the source and therefore not patch, but I guess that would FTBFS
[11:17] <mok0> keffie_jayx: I could see that happening
[11:18] <keffie_jayx> thanks guys
[11:19] <mok0> keffie_jayx: we didn't solve the problem though
[11:19] <keffie_jayx> you got me out of my doubt
[11:19] <keffie_jayx> I think you did
[11:20] <keffie_jayx> now it is up to me to findout why on earth the patch is set to be applied and it doesn't patch the code :)
[11:20] <mok0> keffie_jayx: weird indeed
[11:20] <mok0> keffie_jayx: step through them manually using quilt
[11:21] <keffie_jayx> I was actually reading them one by one
[11:21] <mok0> keffie_jayx: but try to apply them, that might result in an explanation
[11:22] <keffie_jayx> ok
[11:28] <dupondje> dholbach: https://bugs.launchpad.net/ubuntu/+source/libutempter/+bug/589103
[11:37] <keffie_jayx> most weird
[12:35] <BlackZ> mr_pouit: patch for bug #588664 fixed
[12:43] <jariq> I am not sure what to do then there is new upstream release available. Should I create new orig.tar.gz file and start with clean changelog ???
[12:44] <BlackZ> jariq: nope, just add a new changelog entry, and yes, you need a new .orig.tar.gz for the new upstream release
[12:45] <jariq> BlackZ: thx
[14:09] <xteejx> Hey guys, I want to start to package for Ubuntu, mainly new ones on LP. I've had a quick look at the PackagingGuide on the wiki but it's a little confusing. Can anyone direct me to more "dummy" level tutorials or anything like that please? (if they exist)
[14:09] <azeem> dunno about other tutorials, but if you questions about the PackagingGuide, you can ask them here
[14:10] <xteejx> ahh ok :)
[14:12] <xteejx> Would source that builds/compiles with "./configure make make install" be easier to package than something that hasn't got these, or are these scripts easy enough to make that it doesn't make any difference?
[14:12] <xteejx> Sorry if I don't make too much sense, not with it today :(
[14:13] <cpscotti> afaikm, if you use the standard (./conf, make , make install ) everything will get better for you
[14:13] <cpscotti> really
[14:13] <cpscotti> xteejx: for example, most of the packaging guides use this
[14:13] <cpscotti> (unless your app is in python or the like)
[14:14] <xteejx> well I'm not a dev so I'd be picking an easy-ish one to package for my 1st time :)
[14:15] <Laney> I advise you not to start with packaging new software
[14:15] <xteejx> really? why?
[14:15] <Laney> both because it's very difficult and because it tends to lead to unmaintained packages in the archive
[14:16] <Laney> it's a better idea to get to grips with how stuff works by fixing existing bugs. And we have enough of those to work on
[14:16] <xteejx> hmm...first point fair enough, but I been part of bug control and bugsquad for 2-3 yrs now I'm not likely to abandon things ;)
[14:17] <xteejx> ok then...any guides on fixing bugs that is easy to follow? lol
[14:17] <ari-tczew> xteejx: don't be discouraged. On my example, I've started packaging on simple merges, looking for Ubuntu Development procedures etc.
[14:17] <cpscotti> Laney:  I always felt like the developers themselves should (when applicable) do the packaging.. this way.. they take responsibility for both the app and the package... does this makes sense for more people on the community?
[14:18] <cpscotti> (and well.. if you do things right.. and you get the correct docs, packaging for debian is pretty easy and straight forward)
[14:18] <xteejx> hmmmm....i thought merges were done automatically or is that syncs? :S
[14:18] <Laney> cpscotti: They can do it indeed if they wish, but working in partnership with a distro developer also works very well IME
[14:19] <cpscotti> well.. in my case I simply forgot the other distros (made the app for and packaged for ubuntu)
[14:19] <cpscotti> (even though the app should run ok on all the rest)
[14:20] <ScottK> I think it depends.
[14:20] <Laney> as long as you keep the upstream and packaging stuff reasonably unentangled then it's alright
[14:20] <Laney> so that other distros can incorporate your stuff if they want
[14:20] <ScottK> I maintain anything I'm involved in upstream for in Debian/Ubuntu but no way am I qualified to touch RPM packaging.
[14:21] <ScottK> So as long as you're involved in the distro you're packaging for and understand how it works, it's great.
[14:21] <xteejx> well I understand most of the work process
[14:21] <cpscotti> for sure.. when I was making my first package I was advised (here) to keep every unplugged.. and really .. the debian/watch scheme is just beautiful
[14:21] <ScottK> If it's hard for someone else to package your work for another distro, you're probably doing it wrong (your upstream work).
[14:22] <xteejx> I'm not a dev :P
[14:22] <cpscotti> ScottK: good point.
[14:23] <xteejx> Ignore me I'm already confused
[14:23] <cpscotti> involving more than one does forces things to follow the standars
[14:23]  * xteejx crawls back into his cave
[14:24] <ScottK> xteejx: No need to do that, but really making entirely new packages is about the most complex thing there is to do.
[14:24] <ScottK> It's really better to learn packaging through updates and bug fixes so you can learn a little bit at a time.
[14:24] <xteejx> ScottK: I see. Well I don't wanna end up drowning in the deep end :)
[14:25] <xteejx> Any suggestions?
[14:25] <ScottK> Not specific ones.  I'm kind of tied up with $WORK at the moment.
[14:25] <Laney> Take a look at the bugs for your favourite package and see if you can fix them
[14:25] <Laney> Scan merges.ubuntu.com for any packages you like and see if you can merge them with Debian
[14:26] <Laney> Have a look at the FTBFS list for stuff to solve
[14:26] <xteejx> My favourite package....hmmmm lol
[14:26] <xteejx> ftbfs? fail to build?
[14:26] <Laney> yes
[14:27] <xteejx> Where do I find those ones - certainly sounds easier than building entire package
[14:28] <Laney> the link is in the topic
[14:29] <dupondje> there are ALOT of ftbfs :(
[14:30] <dupondje> so alot of work :)
[14:30] <ari-tczew> dupondje: go ahead
[14:30] <xteejx> could some of them be stupid things like missing build-deps?
[14:30] <dupondje> ari-tczew: sure. But did some merges/syncs last days
[14:30] <xteejx> alot? It shows 9
[14:31] <xteejx> this is the right link? http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[14:31] <dupondje> http://qa.ubuntuwire.com/ftbfs/
[14:31] <xteejx> bloody hell there is a few !
[14:31] <ari-tczew> universe (589)
[14:32] <dupondje> you won't feel bored the next days :)
[14:32] <xteejx> Does it matter that I'm using Lucid?
[14:32] <Laney> You'll at least want a maverick chroot, and maybe a VM depending on what you're up to
[14:33] <xteejx> FTBFS stuff
[14:33] <geser> xteejx: no, you need at least a maverick pbuilder (or similar) for test-building
[14:34] <xteejx> oh god
[14:34] <xteejx> I'll look into how to set one up....
[14:34] <dupondje> is there btw a possibility to build things for like ia64 or armel ?
[14:34] <ari-tczew> the nice work on ftbfs is fix: "Package is waiting on another package" because we can combine job - fixing ftbfs though by merge/sync
[14:34] <xteejx> not without those archs where you are i dont think
[14:35] <ScottK> It depends on the bug.
[14:35] <ScottK> Some you can fix based on the build logs, but usually it's hard.
[14:36] <xteejx> Is anyone else getting a "Lost something?" error with LP when trying to look at build logs?
[14:37] <geser> dupondje: for armel there is (through qemu) but I don't know how fast and compatible it is. For ia64 I don't know (and I wouldn't care too much about ia64).
[14:38] <tumbleweed> geser: armel in qemu is totally usable
[14:38] <geser> xteejx: yes, known problem. The script generates currently broken links. Remove the "1.0" from the link and it should work
[14:39] <tumbleweed> (and certainly faster than my real hardware for weird old architectures)
[14:39] <xteejx> thanks geser :)
[14:43] <dev__> To start package building/fixing bug for ARM, can you suggest any package ??
[14:43] <dev__> I am reading complete conversation and now I am sure bug fixing is the best first step to start.
[14:44] <dupondje> feel free to pick anything
[14:44] <dev__> How to find packages with Bug ?
[14:44] <dev__> k
[14:44] <dupondje> its always nice to choose a package you use ..
[14:44] <dupondje> then you fix your own problems :)
[14:44] <dev__> should be small and simple one ?
[14:44] <dev__> k
[14:44] <geser> it would be really nice if hdf5 could get fixed on armel to build as that would (hopefully) allow to get octave3.2 build on armel which would allow to get the many octave packages get build on armel
[14:44] <dev__> dupondje, thx
[14:45] <xteejx> the ubuntu archive site is crawling along!!
[14:45] <dev__> k. so hdf5 can be good start for me.
[14:46] <dupondje> http://launchpadlibrarian.net/49300098/buildlog_ubuntu-maverick-armel.hdf5_1.8.4-patch1-2_FAILEDTOBUILD.txt.gz
[14:46] <dupondje> enjoy ! :D
[14:47] <dutchie> so with the FTBFS stuff, should we create a bug report to document it?
[14:47] <geser> only if you have a fix to sponsor
[14:47] <dutchie> ok
[14:48] <dev__> Which is main package for hdf5   ? hdf5-tools or h5utils ?
[14:48] <geser> hdf5 is the source package
[14:48] <geser> the FTBFS list lists only source packages
[14:50] <dev__> fine. Let me start with first task. If I stuck with some problem I will ask you ppl :)
[14:50] <dev__> thx
[15:09] <xteejx> How can I check if I installed the chroot correctly, i.e. can I check the Ubuntu version after i 'sudo chroot /var/chroot'?
[15:09] <geser> lsb_release -a
[15:09] <xteejx> I tried that...command not found :S
[15:10] <geser> sudo apt-get install lsb-release
[15:10] <xteejx> sudo...command not found lol oh hang on I'm root anyway :P
[15:10] <BlackZ> xteejx: or run cat /etc/issue directly
[15:11] <xteejx> both worked great thanks guys :)
[15:25] <mcas> hi
[15:26] <mcas> i want to fix a bug where a service is installed as dep but not started at the right time
[15:26] <mcas> i think i had to tweak the .postinst file from the package
[15:27] <mcas> can i simply say if /etc/init.d/mysql status is running  -> ok else /etc/init.d/mysql start ?
[15:28] <dupondje> I think the order should be changed then
[15:29] <mcas> how can i do this dupondje
[15:29] <dupondje> that the dep-service is started before its needed
[15:29] <mcas> which file is it?
[15:29] <dupondje> no idea directly, but think thats the best way of fixing it
[15:31] <mcas> the dep-service is in controlfile as recommends
[15:33] <dupondje> the the dep-service is normally started before the post.install of the package you install
[15:37] <ScottK> dupondje: If it's a recommends, you can't rely on that.
[15:37] <ScottK> All you can rely on is that the package is unpacked.
[15:37] <mcas> ScottK: that exactly what i see
[15:38] <mcas> do i have to change it from recommend to depend?
[15:38] <ScottK> That wouldn't change anything about what you can rely on.
[15:39] <mcas> so i have to go my first plan? checking mysql and if its not running start it by myself?
[15:44] <ScottK> Normally you don't do that.
[15:44] <ScottK> Generally there are system methods such as sysv init sequencing or upstart jobs to get the events in the right order.
[15:45] <mcas> but my postinst tries to connect to mysql when mysql isn't running
[15:59] <mcas> the status of mysql ist installed ok unpacked
[16:03] <ScottK> Technically you could do this with pre-depends, but that sort of solution probably isn't suitable for the official archive.
[16:04] <mcas> i think bacula, the package i work on, is in main, so i need a solution that works for the official archive
[16:04] <mcas> i am talking about bug #321091
[16:06] <dupondje> mcas: I dunno, but maby check how other packages do it ?
[16:07] <dupondje> guess there are some other that depend on mysql ?
[16:07] <azeem> but none might try to use mysql in their postinst
[16:07] <dupondje> I bet some do ... :)
[16:10] <mcas> i am looking for other packages ;-)
[16:10] <dupondje> guess mythtv does ...
[16:16] <mcas> dupondje: mythtv has mysql as dep not recommend... i'll try this
[16:17] <dupondje> bacula needs mysql to work ?
[16:18] <soren> bacula-director-mysql does.
[16:19] <soren> It can use a number of different metadata storage backends and they each have their own package.
[16:20] <dupondje> bacula-director-mysql should depend on mysql then no ?
[16:21] <mcas> i think so
[16:23] <dupondje> if bacula-director-mysql NEEDS mysql to work, then it should depend on it instead of recommend imo :)
[16:24] <azeem> dupondje: supposedly, it can connect to a remote mysql as well
[16:25] <mcas> azeem: correct but then should it bring up a message like postfix where i can select where my mysql runs
[16:25] <dupondje> yea indeed
[16:26] <dupondje> and if its local
[16:26] <dupondje> the user should assure MySQL is running ofc ..
[16:26] <mcas> ok ... how can i make such a selection :-D
[16:27] <dupondje> you say 'like postfix'
[16:27] <dupondje> hrhr :) apt-get source postfix :)
[16:28] <mcas> hrhr... and i thougt this would be a good bug to start my packaging work ;-)
[16:28] <dupondje> yea
[16:28] <dupondje> sometimes you thing: 'oh it seems easy'
[16:29] <dupondje> think*
[16:29] <azeem> mcas: it's certainly a difficult bug
[16:30] <mcas> i thought there were a definition of server-papercuts... "easy to fix" ...
[16:30] <mcas> :-)
[16:31] <mcas> how long until alpha2 deadline?
[16:35] <c_korn> mcas: https://wiki.ubuntu.com/MaverickReleaseSchedule
[16:36] <mcas> thx c_korn
[16:41] <ScottK> mcas: No, you've selected quite a difficult problem to work on.
[16:45] <dutchie> i'm looking into the FTBFS of anerley on maverick. I'm building out of lp:ubuntu/anerley with "bzr bd --builder=pdebuild", and seeing a different error to the one at http://launchpadlibrarian.net/48167454/buildlog_ubuntu-maverick-i386.anerley_0.2.3-1_FAILEDTOBUILD.txt.gz
[16:45] <dutchie> not sure what's going on
[16:59] <dupondje> dutchie: looks like missing dependency
[17:00] <dutchie> dupondje: it gets as far as building on my machine though :/
[17:01] <Laney> what's the new error then?
[17:01] <dutchie> too many args for some function or other
[17:02] <dutchie> http://media.joshh.co.uk/anerley-build.log is what I got from "bzr bd --builder=pdebuild"
[17:02] <Laney> er, that package has been removed from Debian
[17:03] <dutchie> anerley?
[17:03] <Laney> yeah
[17:03] <dutchie> great
[17:03] <dutchie> shall I stop working on it then?
[17:03] <Laney> sounds like a plan
[17:04] <MTecknology> You guys normally use schroot for making chroot environments?
[17:05] <Laney> I do (through the mk-sbuild wrapper), dunno about anyone else
[17:08] <MTecknology> !info red5
[17:08] <hyperair> everything uses debootstrap anyway
[17:08] <MTecknology> According to this - https://launchpad.net/ubuntu/lucid/+source/red5 - doesn't red5 exist in 10.04 ??
[17:08] <dupondje> MTecknology: to build I use pbuilder ... :)
[17:09] <dupondje> MTecknology: look @ the building
[17:09] <dupondje> its waiting for a dependency
[17:10] <dupondje> http://launchpadlibrarian.net/48313001/buildlog_ubuntu-maverick-i386.red5_0.9.1-1_MANUALDEPWAIT.txt.gz
[17:11] <MTecknology> !info groovy-doc
[17:11] <MTecknology> !info libmina2-java
[17:12] <MTecknology> !info libmina2-java maverick
[17:13] <MTecknology> dupondje: so that needs to exist first...
[17:14] <dupondje> MTecknology: yea ofc, you can't build a package that depends on packages that doesn't exist ...
[17:15] <MTecknology> dupondje: I don't see it existing in LP :(
[17:16] <MTecknology> I was exited to see a package for red5 though :P
[17:17] <dupondje> seems like they are not yet synced from debian
[17:17] <MTecknology> dupondje: thanks for that :)
[17:17] <MTecknology> dupondje: it won't be in lucid then?
[17:17] <MTecknology> because of the import freeze beign long gone?
[17:21] <dupondje> forget it for lucid
[17:21] <dupondje> for maverick it should maby be possible
[17:25] <MTecknology> dupondje: thanks a bunch :)
[17:29] <ari-tczew> you can file a sync request for non-existing packages
[17:29] <ripps> Can someone please help me figure this out, I'm starting to get emails from people telling me how the gmpc-trunk amd64 package is broken now. http://launchpadlibrarian.net/49586888/buildlog_ubuntu-lucid-amd64.gmpc_0.20.0%2Bgit20100502.ffa5341-0ubuntu1~ripps1~lucid_FAILEDTOBUILD.txt.gz
[17:31] <ari-tczew> ripps: maybe it's ftbfs due to gcc 4.4
[17:31] <geser> ripps: can you pastebin the code around the mentioned line in the error message?
[17:32] <ripps> ari-tczew: that is a possibility, it went through this on and off throughout lucid development, but it worked after lucid was released, it just started doing this again a few weeks ago.
[17:35] <ripps> geser: here's the whole file, it's not that long: http://pastebin.com/vqmMZDqD
[17:36] <ripps> public
[17:36] <ripps> that's the line it's having trouble with?
[17:38] <geser> which language is that?
[17:38] <geser> vala?
[17:39] <ripps> geser: I know portions of gmpc code is vala
[17:39] <ripps> it says it's a gob file
[17:40] <ripps> I think all of gmpc's vala code is kept seperate in src/vala. so, no I don't think it's vala
[17:45] <geser> I assume it can't resolve the "GmpcMetaWatcher" as the other error is about it too
[17:48] <ripps> geser: I don't understand why this seems to come and go, the developer hasn't changed the code in months
[17:50] <ripps> And only with amd64 nontheless
[17:53] <ari-tczew> !info vte
[17:53] <geser> ari-tczew: !info works on binary package names not on source ones
[17:54] <ari-tczew> ok then:
[17:54] <ari-tczew> !info libvte-dev
[17:54] <ari-tczew> can I get !info from DEbian?
[17:54] <geser> don't know
[17:55] <geser> !info libvte-dev sid
[17:55] <geser> !info libvte-dev unstable
[17:56] <ari-tczew> nice
[17:56] <ari-tczew> I'm pissed due to outdated packages.ubuntu.com
[17:56] <Laney> I never use that
[17:56] <Laney> lp/ubuntu/+source/package is always up to date
[17:56] <ari-tczew> Laney: you not, other people yes
[17:57] <Laney> me not, because it's always out of date ;)
[17:57] <geser> I mostly only use it to the package for a file (as replacement for apt-file)
[17:57] <ari-tczew> site is out-of-date because now it's orphaned
[17:58] <ari-tczew> I'm looking on packages.ubuntu.com for packages information
[17:58] <geser> for that I use "apt-cache show"
[17:59] <geser> unless I need information for an older release
[17:59] <ari-tczew> easier for me is write package name in firefox (packages.ubuntu.com search engine)
[18:01] <ari-tczew> Laney: would you update your comment on my wiki that I'm not enough MOTU due to I use packages.ubuntu.com? ;-D
[18:01]  * Laney groans
[18:02] <Laney> I was trying to help you find an alternative
[18:02] <ari-tczew> uhm, so thanks, love you :)
[18:12] <ari-tczew> what about script syncpackage? when it will be oficially use by developers?
[18:12] <Laney> I don't think it will; we are waiting for sync-in-launchpad
[18:22] <kklimonda> ari-tczew: wrt outdated p.u.c just use rmadison i it can query both ubuntu and debian and got really fast at some point
[18:32]  * abogani2 waves
[18:32] <abogani2> Anyone could help me in the upload package process?
[18:33] <BlackZ> abogani2: what upload?
[18:33] <abogani2> BlackZ: linux-rt_2.6.31-11.154
[18:34] <BlackZ> abogani2: is it in pending upload into a -proposed archive?
[18:35] <abogani2> I uploaded it 8 hours ago but It is right now in unapproved queue and I don't know the reason. :-(
[18:35] <abogani2> BlackZ: ^
[18:36] <BlackZ> abogani2: the packages uploaded in -proposed have to be manually approved
[18:36] <abogani2> BlackZ: Ok Who man I should beg?
[18:38] <BlackZ> abogani2: is there a open bug?
[18:41] <ari-tczew> BlackZ: did you thought about using bazaar instead debdiffs?
[18:41] <BlackZ> ari-tczew: heh, you're right
[18:41] <BlackZ> are the debdiffs wrong?
[18:42] <abogani2> BlackZ: It fix three open bugs at least.
[18:42] <ari-tczew> BlackZ: debdiffs aren't wrong, but bazaar is like a fashion, modern system for patches and not only
[18:43] <BlackZ> ari-tczew: OK, next time I will use bazaar
[18:44] <ari-tczew> I had a problem to get used to it bazaar, but it's simply to use
[18:44] <dutchie> is there anything a nobody like me can do about FTBFS like http://launchpadlibrarian.net/49085811/buildlog_ubuntu-maverick-i386.critterding_1.0-beta12.1-1_FAILEDTOBUILD.txt.gz?
[18:44] <Laney> is sdl now fixed?
[18:44] <lfaraone> Laney: I remember hearing it was, but don't quote me.
[18:45] <BlackZ> ari-tczew: if there aren't problems for the sponsors I will use bazaar in the next
[18:45] <Laney> dutchie: Just try a test build of it now and see if sdl works. If yes, ask for a give-back. If no, investigate that.
[18:45] <dutchie> doing it now
[18:45] <dutchie> seems to be working
[18:46] <lfaraone> Laney: can non-motus request give-backs, or do we need to "sponsor" the request?
[18:46] <dutchie> at least, libdirectfb-dev has installed
[18:46] <Laney> lfaraone: the latter
[18:46] <slytherin> dutchie: You are doing the build in chroot, right?
[18:46] <Laney> lfaraone: I'll usually just do one if someone asks on irc
[18:46] <dutchie> slytherin: yes, pbuilder
[18:47] <slytherin> lfaraone: people usually just ask on IRC. Similar to how MOTUs can ask core-devs for give backs.
[18:47] <Laney> I see that it got rebuilt a few days ago for the directfb transition
[18:47] <Laney> so I'd wager that we can just give back critterding now
[18:48] <slytherin> lfaraone: There is no process for give back really. Because failed build are auto-retried after some time.
[18:48] <Laney> dutchie: given back, thanks
[18:48] <dutchie> ok
[18:49] <dutchie> what does that mean?
[18:49] <slytherin> dutchie: The build is scheduled for retry.
[18:50] <dutchie> ok
[18:50] <dutchie> there were a couple more like that I saw
[18:56] <MTecknology> so for a sync request - how does bug 589295 look?
[18:56] <slytherin> too bad. :-P
[19:23] <dutchie> critterding has built locally now
[19:26] <dupondje> what mirror contains armel packages ? :s
[19:27] <jpds> dupondje: None.
[19:28] <jpds> Well, actually; there are a couple of ports mirrors.
[19:30] <jpds> dupondje: http://ftp.tu-chemnitz.de/pub/linux/ubuntu-ports/
[21:05] <geser> MTecknology: mina2 (source package for libmina2-java) is up-to-date with unstable in maverick, but it also is in dependency wait
[21:08] <Tallken> hi! I need to understand why a kismet newcore hackish package can detect libpcap's support for PPI in ./configure but not in the ./configure part of debian/rules binary. TIA
[21:09] <geser> MTecknology: one of those nice cyclic build-depends: libspring-2.5-java waits on libtiles-java (tiles) which waits on libspring-core-2.5-java (libspring-2.5-java) to get build
[21:09] <geser> MTecknology: you need to figure out, how to break those cycle to get those packages build, so mina2 can get build and then red5
[21:26] <geser> Tallken: do you have a links to build logs for both cases?
[21:32] <MTecknology> geser: wow.. that looks exciting
[21:37] <MTecknology> geser: so one of those doesn't actually depend on the other but states that it does?
[21:38] <Tallken> geser: no, is it needed? snippet of configure output on both cases: «PPI log format: yes» VS «PPI log format: no - PPI logging unavailable, upgrade libpcap». Note: I'm running a hackish packaging attempt, I just copied the debian/ dir from kismet-2009 to the kismet-2010 dir.
[21:39] <dutchie> looking at ocropus, in debian/rules it contains "AUTOMAKE=automake-1.9 ACLOCAL=aclocal-1.9 autoreconf -ivf". This seems a little wrong, as even Lucid has automake 1.11
[21:39] <geser> MTecknology: it does depend (as far as I can tell), but you need to figure out how to build one of those two so you can get the other build, so you can undo your modification to the first so it get can build as intended now
[21:40] <Rhonda> dutchie: But does it work with automake 1.11?
[21:40] <dutchie> well, no
[21:40] <dutchie> but that can't be helping
[21:40] <Rhonda> Then it doesn't seem so wrong to me. :)
[21:40] <MTecknology> geser: so you tweak A so B can build and thus C can build; then remove the modification to A so it can build correctly with C now existing?
[21:40] <dutchie> it doesn't work with 1.9 either though
[21:41] <geser> Tallken: not really needed, but without a log to look at it is hard to give any hints/advice
[21:41] <Rhonda> dutchie: oh.
[21:44] <geser> MTecknology: almost, tweak A so it can get build (now without the dependency on B), as A is now available B can get build now too, as B is now available too we get let the "original" A get build (undo the tweak). that C can now get build too is a nice bonus
[21:44] <geser> when I see cyclic build depends, in most cases -java packages are involved.
[21:45] <geser> Debian hasn't that problem, as the DD uploads the build debs too
[21:45] <geser> only Ubuntu has this boot-strapping problem
[21:46] <MTecknology> is it possible for an ubuntu dev to upload the deb temporarily?
[21:46] <geser> no
[21:47] <geser> but what could be done is something like was done for "cup" (https://edge.launchpad.net/ubuntu/+source/cup/+changelog)
[21:48] <MTecknology> oh...
[21:48] <Tallken> geser: I assumed it would be something simple, since the only check the configure seems to make is checking for DLT_PPI in pcap.h , so I thought "Maybe it's fakeroot that's blocking something or something else". I can't provide you with the exact logs since I'm disconnecting, but what are you looking for in them?
[21:49] <MTecknology> +++ cup-0.11a+20060608/cup_0.11a+20060608-1_all.deb.uue
[21:49] <MTecknology> geser: that looks.......
[21:52] <geser> Tallken: I don't know. There is no guarantee that I would see the difference that explains it. fakeroot is only used during the "install" phase and creating of the debs, the compilation is done as a normal user
[21:54] <MTecknology> geser: So if I can get libspring-core-2.5-java to build in a PPA; you could take that and upload it then everything else would be able to build - then remove that modification just as was done there?
[21:54] <geser> MTecknology: that is a work-around for the problem, but you might need to talk to an archive admin that he lets such a package through NEW (I assume that those source packages didn't get build successfully till now so the binary debs need NEW processing)
[21:55] <geser> MTecknology: yes
[21:56] <geser> you could also try contacting the DD for those packages if they have any hints how to resolve this boot-strapping problem in Ubuntu
[21:56] <MTecknology> geser: I REALLY like Red5 in the sense that FMIS is $5k and this is free - and once this is fixed seems a whole massive amount easier - I'm guessing this fight is worth it - and others could benefit :)
[21:56] <Tallken> geser: I just deleted CFLAGS lines out of rage and it worked -_- ; will trim down the line
[22:00] <geser> MTecknology: I hope that that is the only cyclic build-dependency to get red5 build and doesn't get any bigger (I didn't check all build-dependencies but only looked at those LP shown, it might be that once those get resolved it waits on an other package)
[22:01] <MTecknology> geser: no :(
[22:01] <Tallken> geser: «CXXFLAGS = -g -Wall» is the culprit ?!?! tested twice... makes no sense...
[22:01] <geser> MTecknology: it might even qualify for an SRU (as it's currently FTBFS), but that would be an interesting SRU
[22:02] <MTecknology> !sru
[22:02] <MTecknology> !ftbfs
[22:03] <MTecknology> what's that last one?
[22:03] <geser> Fails To Build From Source
[22:03] <MTecknology> so once building it might not even make it into lucid?
[22:03] <geser> sorry, I assumed you know already this abbrevations
[22:04] <geser> yes
[22:04] <MTecknology> I knew the first one but forgot some - the second i didn't
[22:04] <MTecknology> java sucks... doesn't it..
[22:05] <MTecknology> I'll have to sound really desperate and use a lot of flattery :P
[22:11] <geser> MTecknology: looks like you need to also resolve this http://launchpadlibrarian.net/49103797/buildlog_ubuntu-maverick-i386.portlet-api-2.0-spec_1.0-2_FAILEDTOBUILD.txt.gz (for maverick)
[22:12] <MTecknology> geser: ugly stuff :D
[22:37] <sim> arand: thanks for your help
[22:44] <Tallken> geser: for some reason "-Wall" was borking the detection of the PPI thing. I've no clue why.