[00:00] <micahg> arand: BTW, abiword 2.8.4 just hit maverick
[00:01] <crimsun> thank goodness :-)
[00:01] <ajmitch> does 2.8.4 fix a few problems?
[00:02] <arand> Nice.
[00:02] <micahg> s/hit/uploaded/
[00:03] <crimsun> ajmitch: yes
[00:03] <arand> It fixes the crash-on-help one, although that should hopefully be fixed with my svn cherrypick.
[00:04] <arand> ...In lucid as well
[00:04] <crimsun> not least of which is the xmlCleanupParser() madness
[00:04] <crimsun> which historically makes pulse look bad, but it's in fact people not bloody reading the libxml2 API
[00:04] <ajmitch> uh
[00:04] <ajmitch> how does that have anything to do with pulse? :)
[00:05] <arand> Uh, what? Was pulse involved in this?
[00:05] <crimsun> calling xmlCleanupParser() multiple times tramples all over the pulse client's TLS vars
[00:05] <crimsun> as a result, the offending pulse client (the program abusing xmlCleanupParser()) segfaults, with the stack trace pointing to pulse
[00:06] <ajmitch> oh that must have been a bundle of fun
[00:06] <crimsun> I combed through the archive toward the end of the Lucid cycle to fix this
[00:13] <arand> One good thing with a new abiword is that 2.8.2 seems to FTBFS on my MM system as well :/
[01:01] <crimsun> would a member of ~ubuntu-release please unsub the team from bug 568619 so I won't spam everyone?
[03:33] <AnAnt> Hello, how can I fix this bashism: echo -e "text text \n text text \t text ..." ?
[03:33] <AnAnt> if I remove -e, it would work fine with dash, but not with bash
[03:58] <crimsun> AnAnt: check the xpg_echo shell option and act appropriately
[03:58] <crimsun> AnAnt: in bash, that is
[03:59] <AnAnt> crimsun: thanks, I used printf instead
[05:07] <imbrandon> evening all
[05:13] <ajmitch> hi imbrandon
[05:14] <imbrandon> heya ajmitch
[05:17] <imbrandon> so its kinda cool, i picked up this tiny 11inch dell from like 1999, its funny its like its got all the features of the new "mini"s just slower
[05:18] <imbrandon> got lucid loaded on it, but it dosent like gnome/unity much , toooooo slugish , like firefox takes 2 minutes to load
[05:18] <imbrandon> lol
[05:18] <imbrandon> so i got lucid but i apt-get installed fluxbox + a few other lighter apps and its great little mobile machine to use to ssh into other boxes etc
[05:19] <imbrandon> for free ;)
[05:20] <imbrandon> its 700mhz, so its not "terrible"
[05:22] <ajmitch> not bad
[05:24] <imbrandon> i think most of the slowness is the only 128mb ram, it maxes out at 256 says dells website if i can run accross a 256mb pc-100 sodimm at somepoint
[05:25] <imbrandon> sooo whats new in motu ?
[05:27] <imbrandon> ajmitch: http://support.dell.com/support/edocs/systems/latl400/en/ug/specs.htm
[05:27] <imbrandon> heh
[06:35] <_Andrew> #debian
[06:35] <_Andrew> woops
[07:00] <_Andrew> Anyone know why when I do "dh_install --sourcedir=debian/tmp --fail-missing" and inside my install script it has the following.. "usr/bin" my package fails to find something installed in debian/tmp/usr/bin/xyz ?
[07:11] <persia> _Andrew: I may be mistaken, but I believe --fail-missing only fails if there are things in the temporary directory that are unallocated to any package, rather than if there are things missing from the temporary directory.
[07:13] <_Andrew> Here's the error message.. "debian/tmp/usr/bin/cpack exists in debian/tmp/ but is not installed to anywhere"
[07:14] <dholbach> good morning
[07:14] <_Andrew> I'm using compatibility level 6 and have tried "debian/tmp/usr/bin", "debian/tmp/usr/bin/*", "usr/bin", "usr/bin/*" and probably some other combinations.
[07:15] <_Andrew> It never seems to find it in the .install file
[07:16] <persia> One of the changes in compatibility level 7 was some new logic to make the .install files make more sense :)
[07:17] <persia> I tend to list stubborn files explicitly and individually.
[07:18] <_Andrew> Can't because this package is for hardy
[07:19] <_Andrew> Otherwise yes, I'd bump up the compat in a heartbeat :D
[07:19] <persia> How did it work before you started fixing it?
[07:20] <_Andrew> I specifically lists all the programs.. I think I already tried that. but I'll give it another go
[07:20] <_Andrew> It**
[07:20] <persia> That seems about right, from my memory.  Best practice when working with older packages is to touch the absolute minimum.
[10:27] <G> It's been a while since I've done Debian style packaging, but I'm looking to get back into it, I've got a package that has downloaded as: foo-0.2.1-source.tar.gz and extracts as foo-0.2.1-source, the example at https://wiki.ubuntu.com/PackagingGuide/Howtos/PackagingFromScratchHelloDebhelper shows 'tar -xf hello-x.y.tar.gz hello-x.y' so my question is, does the -source matter, or is that something I have to rename out?
[10:28] <persia> The name of the directory in the upstream tarball matters not at all.
[10:29] <Rhonda> It neither matters for dpkg-source, it though issues a warning which can get ignored. :)
[10:30] <Rhonda> When packaging inside a VCS I usually have the directory only named VCS for consistency issues.
[10:31] <umang> Hi, I maintain a package on Debian that entered sid after the Lucid DIF. If I want it to be imported into maverick then do I have to file a bug or will it automatically happen after MM's DIF?
[10:31] <G> persia: Rhonda: great, thats for that (and thanks for the hint abotu the warning)
[10:32] <persia> umang: It ought enter the NEW queue automatically.
[10:33] <Rhonda> umang: It hopefully will automatically happen _before_ MM's DIF. :)
[10:33] <Rhonda> … because after DIF there isn't any automatism for that anymore.
[10:34] <umang> persia, Rhonda: so I don't need do anything for it to be included in maverick?
[10:35] <persia> umang: It wouldn't hurt to track the progress through https://launchpad.net/ubuntu/maverick/+queue but it ought require no action on your part.
[10:37] <umang> persia, I'm not able to find it under any of the statuses. So I presume it will enter one of those queues later?
[10:37] <persia> Right.  The archive admins usually wait until the current packages sync has made significant progress before syncing the new packages.
[10:38] <umang> persia, Thanks! :)
[10:38] <persia> I'd recommend checking again in a week or so.  if you still haven't seen it in any of the queues by a few weeks before DIF, then it may merit investigation.
[10:38] <persia> With luck, you'll only ever notice it in DONE.
[10:40] <umang> persia, Sure, I'll do that. :)
[10:45]  * Rhonda still waits for packages.ubuntu.com to display maverick …
[10:45] <Rhonda> … and for wesnoth-1.8 syned into maverick. ;)
[12:15] <mok0> Any schroot users? I am getting loads of messages of the following type, and it is starting to annoy me. I already tried to edit /etc/schroot/schroot.conf, but to no avail.
[12:15] <mok0> W: line 19 [karmic-0f03ab72-3520-4df4-a561-e3d55c218892]: Deprecated key 'run-exec-scripts' used
[12:15] <mok0> I: This option will be removed in the future; please update your configuration
[12:15] <mok0> W
[12:20] <azeem> mok0: yeah, it's pretty annoying
[12:20] <geser> mok0: do you have a "run-exec-scripts" line in your schroot.conf?
[12:20] <mok0> I removed it
[12:21] <geser> and still this warning?
[12:21] <azeem> mok0: karmic-0f03ab72-3520-4df4-a561-e3d55c218892 means it's from a session
[12:21] <persia> The only way I found to make that go away was to regenerate the schroots.
[12:21] <azeem> mok0: so umount those bind mounts and close all sessions
[12:21] <mok0> Lemme see
[12:21] <azeem> (I don't understand why schroot needs sessions anyway)
[12:21] <persia> `schroot -e -c ${SESSIONID}` automates that.
[12:22] <persia> azeem: Because sometimes you want to run several in parallel, or you might want to have persistent schroots for some reason, etc.
[12:22] <azeem> hrm
[12:22] <mok0> There are no mounted work volumes
[12:22] <mok0> persia: what is SESSIONID?
[12:23] <persia> mok0: I'm not entirely sure.  When I use schroot with lvm, the necessary magic value appears in the lvs output.
[12:23] <azeem> mok0: probably karmic-0f03ab72-3520-4df4-a561-e3d55c218892 or without the karmic-
[12:23]  * persia is still learning about schroot-without-lvm
[12:23] <persia> I think it's with the karmic
[12:23] <azeem> persia: those should be a specially requested operation though, not the default
[12:23] <azeem> I assume sbuild is to blame here
[12:24] <persia> azeem: Kinda.  So, when sbuild crashes, the schroot doesn't close.  this can be useful in many ways, but also annoying sometimes.
[12:24] <mok0> There are similar lines for my jaunty builder
[12:25] <persia> By default, schroot opens a session, and closes it when complete.  This is essential if one has configured schroots to be used on a multiuser box, or if one wants to do parallel builds with sbuild, etc.
[12:25] <mok0> You think I should enter the schroots, and make the change to /etc/schroot... etc there?
[12:25] <persia> Keeping the session open after exit requires a special command-line argument.
[12:25] <persia> mok0: That may work: regeneration is likely cleaner.
[12:25] <mok0> persia: yeah, sometimes the roots stay around even after the build finishes, but that's not the case for me now
[12:27] <mok0> persia: I'm not sure I understand "regenerate"... run mk-sbuild again?
[12:27] <persia> What I did was remove the stanzas from schroot.conf, remove the storage (either LV or /var/lib/schroot/... ) and then rebuild them from scratch.
[12:28] <persia> This is not necessarily the optimal solution.
[12:28] <mok0> persia: I have so many schroots
[12:28] <mok0> 13...
[12:28]  * persia wrote one-line wrapper script around mk-sbuild that day
[12:29] <mok0> Hmm :-)
[12:30] <persia> for i in dapper hardy jaunty karmic lucid maverick; do for j in amd64 armel i386 powerpc; do mk-sbuild --arch=$j $i; done; done takes care of Ubuntu.  Debian is similar.
[12:30]  * persia may have mistyped syntax
[12:31] <persia> Note that this will take a while, and it is advised to be network-near a mirror of at least the buildd stuff.
[12:31] <persia> (and use --debootstrap-mirror=...)
[12:31] <mok0> persia: fortunately, I have an apt-proxy
[12:32] <mok0> on the local network
[12:32] <persia> That works too, at least for some subset :)
[12:32] <mok0> persia: can't remember... do you need to edit schroot.conf first?
[12:33] <persia> I just deleted everything that I was replacing from there.
[12:33] <persia> Also remember to remove the backing storage configuration, as mk-sbuild is a bit fragile about that.
[12:33] <mok0> *sigh*
[12:34]  * mok0 procrastinates: I think I'll do it... sometime
[12:35] <mok0> In fact, I might just figure out what part of sbuild issues those messages and zap them :-)
[12:35] <persia> I'm sure it's something inside the schroot.  if you figure out what, probably best to write an exec script that cleans up elderly schroots on intialisation.
[12:39] <mok0> Hm. Nothing inside the schroot
[13:13] <G> does lucid have a buggy autoconf?  it's generated a configure script with includedir=$PREFIX/include, instead of includedir=$PREFIX/usr/include, is there a standard fix for that?
[13:15] <Rhonda> G: What's wrong with that? includedir=$PREFIX/include seems to be correct to me?
[13:15] <Rhonda> … because usually PREFIX itself is /usr
[13:16] <G> is there any way I can verify what debuild is executing (such as -v) so I can see what it's passing to autoconf.sh?
[13:17] <azeem> G: try DH_VERBOSE=1
[13:17] <azeem> (wild guess)
[13:18] <G> azeem: ohhh thanks
[13:18] <G> (it's been a while)
[13:30] <G> hmmm, this is confusing I can't seem to get any debhelper logging :S
[13:32] <piju> http://9w2pju.blogspot.com/2010/05/ubuntu-hams-t-shirt-artwork-from-9w2pju.html
[13:32] <piju> what do you think?
[13:51] <mok0> piju, Interesting. How is HAM radio related to Ubuntu? Just curious
[13:51] <mok0> Internet over HAM?
[13:53] <piju> mok0; join #ubuntu-hams
[13:54] <mok0> piju: I'm not a HAM operator. Just curious
[13:54] <piju> ubuntu got lots of ham radio applications
[13:54] <piju> try apt-cache search ham radio
[13:55] <piju> shackbox is a distro for ham radio, made from ubuntu distro
[13:55] <piju> you can use ubuntu for ham radio
[13:55] <porthose> http://packages.ubuntu.com/lucid/hamradio/
[13:55] <piju> morse code, APRS, echolink (VOIP), etc
[13:55] <piju> design your antenna, and many more
[13:55] <mok0> Woa
[13:55] <mok0> Heh
[13:56] <piju> where do you come from ?
[13:56] <mok0> Denmark. in this country, I think it is pretty near impossible to get a license unless you want to spend every free hour
[13:56] <piju> you can ask your local ham radio club, how to get a ham license
[13:57] <piju> we can talk over ham radio
[13:57] <mok0> piju: You need to learn morse code
[13:57] <piju> im from Malaysia
[13:57] <piju> mok0; in the US, no more morse code test
[13:57] <mok0> piju, what's wrong with IRC :-)
[13:57] <mok0> piju: yeah I read that
[13:58] <piju> there is lot of open source developer who are ham radio too
[13:58] <piju> #hamradio
[13:58] <mok0> piju: my interest in ham would be more like tunneling internet over it
[13:58] <piju> yes, we have echolink for that
[13:58] <piju> VOIP
[13:58] <piju> i can talk using my pc to a man who are driving in England
[13:58] <piju> and vice versa
[13:59] <mok0> piju, somehow I'm not impressed :-)
[13:59] <piju> you can talk to astronout if you a ham radio
[13:59] <piju> mok0; yes, i know that. you are generation of computer, not radio
[13:59] <mok0> piju: errh
[13:59] <piju> even most advanced military still use radio
[14:00] <piju> international space station too
[14:00] <mok0> piju: encrypted probably
[14:01] <piju> encrypted ?
[14:01] <piju> yes. for sure. military will use encryption
[14:01] <mok0> piju: I would assume that the military encrypt their radio communication. I may be wrong
[14:02] <mok0> ah
[14:02] <piju> but, not for ham radio
[14:02] <mok0> piju: I see
[14:02] <piju> ISS also not encrypting their broadcasting
[14:02] <piju> you can listen to them
[14:02] <mok0> piju: that would be research thought
[14:02] <mok0> though
[14:02] <piju> mok0; i know a ham radio from Denmark
[14:02] <mok0> piju: where?
[14:03] <mok0> where in dk  I mean
[14:03] <piju> i dont remember
[14:03] <piju> but he is a ham
[14:03] <mok0> I think ham guys are pretty rare here
[14:04] <mok0> b/c of the steep requirements for getting a license
[14:10] <tarzeau> how can i get someone to have a look at a package in revu?
[14:10] <Rhonda> By dropping in a hint with more content, like URL or package name or similar.
[14:11] <tarzeau> http://revu.ubuntuwire.com/revu1-incoming/fracplanet-1005071518/fracplanet_0.4.0-1ubuntu3.dsc it's a tool to create 3d fractal planets
[14:12] <tarzeau> http://revu.ubuntuwire.com/revu1-incoming/sea-defender-1005071521/sea-defender_0.9-1.dsc is a small recreational game where you defend oil tankers being hit by torpedos
[14:12] <tarzeau> Rhonda: thanks for the hint
[14:13] <G> so, last question for now (I'm about to head to bed), should I run this 'autogen.sh' and have it as a patch to the build, or should I add it to the debian/rules file?
[14:15] <tarzeau> G: which package/software is it?
[14:16] <G> tarzeau: it's a library (dep for an end package I'd like to do) qpixmap
[14:16] <G> tarzeau: the tarball comes with an autogen.sh file (they released straight from git)
[14:17] <tarzeau> G: i see
[14:17] <G> Doing it as a patch would be cleaner right?
[14:17] <tarzeau> G: the cleanest would be upstream releasing without you having to run it
[14:18] <G> true, but for now (while I contact upstream)
[14:18] <tarzeau> G: i don't know, all my upstreams cooperate on these things with me
[14:18] <G> so there isn't a given standard
[14:22] <tarzeau> G: i think that's the best i know about it: http://sam.zoy.org/lectures/20050910-debian/
[14:23] <tarzeau> G: what does your autogen.sh do?
[14:24] <eagles0513875> hey guys i have a question relating to a piece of software that has made some others in the current lucid repos obsolete
[14:24] <tarzeau> yes?
[14:24] <eagles0513875> can anyone point or direct me as to the proper procedure in getting something into the next release
[14:24] <tarzeau> eagles0513875: what is it, url?
[14:24] <eagles0513875> tarzeau: mysql workbench
[14:24] <eagles0513875> it has replace mysql admin and query browser which are still in the repos
[14:25] <eagles0513875> those have reached their eol
[14:25] <eagles0513875> http://dev.mysql.com/downloads/workbench/5.2.html#downloads tarzeau
[14:26] <eagles0513875> im more then willing to repackage it if need be as i need to learn about packaging and want to learn about it
[14:26] <tarzeau> eagles0513875: i have no idea. i wonder what the debian people do with the mysql packages...
[14:26] <eagles0513875> tarzeau: that package was created upstream at mysql
[14:27] <tarzeau> i really don't know
[14:27] <G> tarzeau: basically everything except clean the kitchen sink (generates ./configure, Makefile's etc
[14:28] <eagles0513875> G: any idea then how i should go about getting a new package into the new release and possibly backported to lucid
[14:28] <tarzeau> eagles0513875: i don't think backporting it to lucid makes sense here?
[14:29] <eagles0513875> ill be back later to continue working on this
[14:44] <Rhonda> \o/ - seems like maverick sync is open, bug #109434 sent me a mail :)
[14:49] <tarzeau> Rhonda: they already synced on 9.5 if not earlier
[14:54] <Rhonda> tarzeau: Well, there was an ubuntu diff in lucid, so I guess that might be the reason for the "delay".
[14:54] <tarzeau> Rhonda: aha. any idea what happens with sea-defender and fracplanet now?
[14:55] <Rhonda> No clue, I don't have the time for that myself, sorry.
[16:34] <fagan> Does anyone package any vala apps for the repo?
[16:35] <fagan> Im looking for guidance about how to do the vala ppa stuff for quickly
[17:08] <MTecknology> !info php5
[17:23] <Riddell> slangasek: you uploaded bug 519541 but didn't accept it or note your SRU approval?
[17:23] <slangasek> Riddell: I uploaded it in a sponsor capacity, would prefer a second vote of confidence from another SRU team member for the acceptance
[17:45] <benste> hi, this channel was fullfilled by those who do some packaging work right ? - I'm trying the latest gnome-power-manager from git master but didn't finish to compile it becuase autogen quotes it needs gnome-keyring0 but there is no such package in ubuntu - what can I do ?
[17:47] <benste> someone here ?
[17:51] <benste> solved - hidden in libgnome-keyring-dev
[19:59] <fabrice_sp> mannyv, will you take care of libclass-trait-perl merge/sync?
[20:00] <micahg> ari-tczew: i'll try to get to libjdic-java early next month
[20:00] <mannyv> fabrice_sp, yeah I can look into that
[20:01] <fabrice_sp> mannyv, you're the one that last touched it :-)
[20:02] <ari-tczew> micahg: I'm glad and amazed of yours memory and solidity :))
[20:03] <micahg> ari-tczew: I noticed all the merges you were doing so I figured it would be on you mind ;)
[20:04] <ari-tczew> micahg: yea, I'll try to merge libjdic-java if you'll have done fix ftbfs on debian :>
[20:05] <micahg> ari-tczew: I was going to merge in ubuntu first and then push the fixes up to debian
[20:06] <ari-tczew> micahg: feel free, your choice :)
[20:06] <micahg> ari-tczew: k, thanks
[21:02] <MTecknology> how can I see if I have any packages that were installed that werent' from the repos that are currently running
[21:03] <carstenh> ask google about ask-listrepository and grep for dpkg/status in its output
[21:04] <MTecknology> carstenh: thanks
[21:23] <MTecknology> carstenh: hm?? I'm not finding anything useful
[21:27] <carstenh> MTecknology: sorry, a typo ...
[21:28] <carstenh> MTecknology: bugs.debian.org/504460
[21:29] <carstenh> MTecknology: download it, run chmod a+x apt-listrepository and then ./apt-listrepository | grep dpkg/status
[21:43] <MTecknology> carstenh: thanks
[22:05] <ari-tczew> fta: are you planning merge chromium-browser with debian unstable?
[22:05] <fta> ari-tczew, no. please read the bug(s) as for why
[22:06] <fta> ari-tczew, and remember debian used our package, not the opposite
[22:08] <ari-tczew> fta: ok thanks for information
[23:14] <mirsal> hello