[00:00] <jdong> I see the patch for it in some sketchy 1.4.14 "prerelease".... probably not final release material at this point
[00:00]  * jdong opens up his SRU tomboy note instead :)
[00:00] <emgent> Fujitsu: I go to sleep :)
[00:01] <emgent> It`s 1.00 am
[00:01] <emgent> night all
[00:01] <Nafallo> night emgent
[00:01] <Fujitsu> Night emgent
[02:24] <RB2> LaserJock, you still around?
[02:24] <LaserJock> RB2: I am
[02:25] <RB2> Quick additional question if you have a minute. Once an upstream debian package is released, what determines how long it takes to filter into the Ubuntu repos? I'm not familiar with the process.
[02:30] <LaserJock> RB2: well, we sync our packages from Debian at the beginning of every release cycle
[02:30] <LaserJock> which is every 6 months
[02:30] <RB2> Ahh, ok. That makes sense.
[02:30] <LaserJock> on top of that Ubuntu developers may select to bring in Debian packages if they are wanted to fix bugs, add features, etc.
[02:32] <RB2> ok, thanks again for your time!
[02:36] <jdong>  vlc (0.8.6.release.e+x264svn20071224+faad2.6.1-0ubuntu2) hardy; urgency=low
[02:36] <jdong> sheesh!
[02:40] <Fujitsu> jdong: That was partly my idea.
[02:41] <Fujitsu> It has embedded copies of x264 and faad, so it's nice to track their versions too, plus it's ugly and cumbersome, so it's an incentive to unembed them.
[02:41] <Fujitsu> Speaking of which, I need to remove x264 from vlc, as it's in multiverse.
[02:42] <jdong> Fujitsu: how on earth did vlc end in universe?
[02:42] <jdong> Fujitsu: AFAIK it has all of its encoding abilities intact
[02:43] <Fujitsu> jdong: I really, really don't know.
[02:43] <Fujitsu> And we can't demote it.
[02:43] <Fujitsu> Without demoting other stuff.
[02:44] <Fujitsu> We at least need to remove the embedded multiverse source package from it.
[02:44] <jdong> Fujitsu: heh well we're kinda screwed... either way....
[02:44] <jdong> Fujitsu: I mean we could just turn off all the encoders at buildtime
[02:44] <jdong> Fujitsu: which is in effect what we need to do to make it unencumbered
[02:45] <crimsun> jdong: history lesson: it has origins in Debian.  I separated the bits post-hoary, but it essentially crippled the player, so I left the embedded bits in.  And then I stopped caring for it.
[02:45] <jdong> crimsun: thanks
[02:45] <Fujitsu> faad is in universe nowadays, but x264 is not.
[02:45] <crimsun> come to think on it, that was about the time the wxw2.4->2.6 crack was happening.
[02:46] <crimsun> back then, all the crap was in multiverse.  I voted to have the whole crackfulness demoted to multiverse.  A lot of people balked.  Oh well.
[02:47] <Fujitsu> We might be able to force more sanity on it by merging with Debian in Intrepid, but it's far too late for Hardy.
[02:48] <jdong> crimsun: IMO we should demote the whole stack to multiverse
[02:48] <Fujitsu> I'll look at what needs demotion.
[02:48] <jdong> I don't want to strip out half of the featureset of VLC
[02:48] <jdong> even more people will balk at that
[02:48] <Fujitsu> It would be nice if we could split it out into a multiverse plugins package, like gstreamer.
[02:49] <jdong> Fujitsu: is it modular enough for that to happen though?
[02:49] <Fujitsu> I doubt it.
[02:50] <jdong> me too
[02:50] <Fujitsu> It's an insecure media player which shares code with MPlayer and Xine.
[02:50] <Fujitsu> It can't be modular.
[02:51] <Fujitsu> Urk.
[02:52] <Fujitsu> Anybody up for demoting mythbuntu-live? They might not like that.
[02:52] <Fujitsu> Oh. MythTV itself is in multiverse. Not too bad, then.
[02:54] <jdong> Fujitsu: maybe we need to come up with some sort of organized double-build system for stuff like this
[02:54] <Fujitsu> If we send freeplayer and mythbuntu-live to multiverse, vlc and its multitude of binaries can go there too.
[02:54] <jdong> Fujitsu: heck even ffmpeg I'm not too happy about the half-neutered appraoch we do currently
[02:56] <Fujitsu> Anybody got any other solutions, or should I get all three demoted?
[02:56] <Fujitsu> mythbuntu-live is already breaking the rules.
[02:57] <superm1> go ahead and bring mythbuntu-live to multiverse, that's not a big deal
[02:57] <superm1> i'm nto sure why it was put in universe in the first place
[02:57] <Fujitsu> It already depends on lots of stuff in multiverse.
[02:57] <superm1> yeah
[03:02] <Fujitsu> Soyuz shouldn't even be letting mythbuntu-live be in universe, as its source is in multiverse...
[04:56] <slangasek> azeem: heh, the moto and evolution plugins don't seem to cross-index very well :/
[05:14] <LaserJock> slangasek: would strncpy and strncat be better?
[05:14] <LaserJock> sorry wrong channel
[05:47] <jdong> what do y'all folk think about making update-manager more aggressive at removing/downgrading/forcing non-hardy-origin packages away during the upgrade?
[05:48] <jdong> when I did my upgrade last night, a lot of my heartaches were caused by stale presence of 3rd party debs, overly aggressive backports, etc.
[05:48] <jdong> IMO anything that is not of Hardy origin after the upgrade should cause update-manager to raise a red flag
[05:49] <LaserJock> hmm, maybe as an option
[05:49] <LaserJock> that sounds pretty invasive to just do
[05:50] <jdong> LaserJock: right, either as an opt-in option or simply to alert the user or dump to /var/log as post-upgrade debugging info
[05:50] <jdong> LaserJock: because one of my ABI-incompatible packages actually caused every GTK menu creation to yield a segfault.
[05:50] <jdong> LaserJock: and it was only thanks to apport which tipped me off to what was going on
[05:51] <LaserJock> well, if you were a user I'd tell you it's your own darn fault and serves you right ;-p
[06:37] <imbrandon> evening all
[06:49] <TheMuso> imbrandon!
[06:49] <imbrandon> heya TheMuso
[06:49] <TheMuso> Long time no see.
[06:50] <imbrandon> :)
[06:50] <imbrandon> been working alot, took a little break from IRC, but I'm still arround/alive
[07:41] <LaserJock> imbrandon, TheMusoL you both have an email coming your way
[07:41] <imbrandon> cool , ok
[07:42] <LaserJock> bah, TheMuso ^^
[07:42] <TheMuso> right
[07:42] <imbrandon> LaserJock: sent yet? i dont see anything
[07:42] <LaserJock> I'm running to bed now though
[07:43] <LaserJock> yeah, *just* sent
[07:43] <imbrandon> ahh okies, gnight
[07:46] <Hobbsee> oh noes, email
[07:48] <LaserJock> imbrandon: get it?
[07:48] <imbrandon> LaserJock: i dont see it, but sometimes my mail is slow
[07:49] <imbrandon> if you want "speedy" delivery try bholtsclaw@mac.com , other accounts tend to delay delivery an hour or so sometimes
[07:49] <LaserJock> well, I just wanted to make sure it went out
[07:50] <imbrandon> ahh i'm sure i'll get it, just takes a bit sometimes
[07:50] <TheMuso> LaserJock: I have no comment, as I am preparing to step down from MOTU SRU.
[07:50] <LaserJock> well, any input is valued
[07:51] <LaserJock> but we'll see anyway how it goes
[07:51] <Hobbsee> TheMuso: already?
[07:51]  * LaserJock out
[07:52] <TheMuso> Hobbsee: For SRU, yes. Too many other things going on, and I don't feel I can do it justice If I'm not paying full attention.
[07:52] <Hobbsee> ahhh
[07:54] <imbrandon> LaserJock: got the mail, i'll add my 0.2c soon
[07:54] <imbrandon> probably before you wake
[08:56]  * Hobbsee whinges.  There's another kmos-type coming :(
[08:59] <geser> Hobbsee: please tell that is not true :(
[08:59] <jscinoz> hmm
[08:59] <Hobbsee> geser: i wish i could tell you that.
[08:59] <Hobbsee> geser: fortunately, he's only in kubuntuland yet.
[08:59] <jscinoz> I'm torn, i have a package in progress, and since it is too late for hardy, I need to know if i package it for debian, will it by synced available in Intrepid?
[08:59] <jscinoz> provided i get it into debian soonish
[09:00] <Hobbsee> jscinoz: yes
[09:00] <jscinoz> alrighty then
[09:00] <jscinoz> quick question..
[09:00]  * Hobbsee looks for a *very* large drink.
[09:00] <jscinoz> rofl
[09:01] <Hobbsee> hehe :)
[09:02] <jscinoz> ok, this game im packaging, has two source packages, the client and server binaries, and the data files, currently the data package is too big to likely be included (750mb deb, 710mb orig.tar.gz) i can call dh_builddeb with -- -Zlzma to get the deb down to 693mb, but would this still be too big?
[09:03] <jscinoz> as this game is quake3 based, if i extract the main .pk3, the game can still read it just fine, and this results in better compression with lzma, as it can work on each individual file rather than the pk3 (which is simpyl a renamed zip) with this method the .deb is now 556mb
[09:04] <jscinoz> the downside of this, once the deb is installed and decompressed the installed-size is much larger (1.3gb vs 750mb)
[09:04] <jscinoz> what would be the best option?
[09:04] <harrisony> jscinoz, what game is it
[09:04] <jscinoz> urbanterror
[09:04] <harrisony> ahh fun game :)
[09:05] <jscinoz> anyideas on the file-size issue?
[09:06] <jscinoz> I'm leaning towards higher deb size, but lower isntalled size (693/730)
[09:06] <geser> jscinoz: my suggestion is to talk to the archive admins (both of Ubuntu and Debian) about their opinion as it's them who decided if it's acceptable for the archive
[09:06] <jscinoz> if i did the other thing it would be (553/1320)
[09:06] <jscinoz> alrighty
[09:06]  * jscinoz heads to #debian-games on irc.oftc.net
[09:26] <Hobbsee> fixed.
[10:16] <RainCT> morning
[10:57] <jscinoz> in my watch file i need it to find a link on the page http://www.teeworlds.com/?page=downloads pointing to teeworlds-0.4.2-src.tar.gz (obviously replacing 0.4.2 with (.*) or something like that) how would i do this, everything i've tried has failed >_<
[11:01] <siretart> apachelogger: the updated pulseaudio plugin has been accepted into hardy. could you please clean up malone?
[11:04] <RainCT> jscinoz: version=2
[11:04] <RainCT> jscinoz: http://www.teeworlds.com/?page=downloads http://www.teeworlds.com/files/teeworld$
[11:04] <jscinoz> thanks
[11:04] <RainCT> argh
[11:04] <jscinoz> wait i got it to work.
[11:04] <RainCT> jscinoz: http://www.teeworlds.com/?page=downloads http://www.teeworlds.com/files/teeworlds-(.*)-src.tar.gz
[11:05] <RainCT> terminals are evil :P
[11:05] <jscinoz> version=3
[11:05] <jscinoz> http://www.teeworlds.com/?page=downloads (?:.*)/teeworlds-([\d.]+)-src.tar.gz
[11:05] <jscinoz> that also worked
[11:05] <jscinoz> which would be better to use?
[11:05] <RainCT> jscinoz: yours would continue working if they change the place where they put the tarballs
[11:05] <jscinoz> so i should use mine?
[11:06] <jscinoz> thanks :)
[11:07] <RainCT> jscinoz: yes. no problem :)
[11:10] <jscinoz> hmm this is strange
[11:11] <jscinoz> im making a get-orig-source rule and it wont cd >_<
[11:11] <jscinoz> cd $(TMPDIR)/teeworlds-$(VERSION)-src stays in ./ >_<
[11:16] <jscinoz> ack
[11:29] <jscinoz> anyone see anythign wrong with "cd ./tmp.IJDKSb9119/teeworlds-0.4.2-src"?
[11:30] <jscinoz> because the darn thing will not cd
[11:30] <jscinoz> and i have no idea why
[11:30] <RainCT> jscinoz: I'm not sure but it might be that each line is being executed in its own subshell
[11:30] <jscinoz> if i pastebin the whole section would that help?
[11:30] <RainCT> jscinoz: so that it actually does cd, but it gets back to where it was on the next line
[11:31] <jscinoz> how would i stop that from happening?
[11:31] <jscinoz> http://pastebin.com/m634c8a2e
[11:33] <jscinoz> wait i fixed it
[11:33] <jscinoz> all is well :P
[11:33] <RainCT> nice, what was the problem?
[11:35] <jscinoz> what you said
[11:35] <jscinoz> strung the commands together with a ;
[11:35] <jscinoz> :P
[11:35] <RainCT>  :)
[11:36] <RainCT> if you want to have it over multiple lines, using $(stuff here...) should work
[11:37] <jscinoz> i used..   command args; \ (newline) othercommand otherargs: \ etc
[11:38] <RainCT> that's an option, too :)
[11:40] <jscinoz> now to work around this strange custom build system
[11:41] <jscinoz> basically my debian/rules first has to build the build system then build the package
[11:41] <jscinoz> >_<
[11:46] <jscinoz> oh god thats infuriating
[11:46] <jscinoz> uploading a 750mb package to PPA which built fine on my system and failed on theirs.
[11:48] <megabyte405> I need some help getting a package sponsored and uploaded.  I have the AbiWord 2.6 packages all ready to go, all necessary MIR's approved, and so now i just need them sponsored in/uploaded  - bug 202174
[11:48] <ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Medium,New] https://launchpad.net/bugs/202174
[11:49] <megabyte405> I have followed the sponsorship steps already
[12:15] <deepak_> hi , i want to contribute to ubuntu and  you can see my details hear https://launchpad.net/~apenguinlinux can any mentor can suggest me how to start bcz i am new to ubuntu philosophy and how they work is the same as Debian does of bit different. i am comfortable with Debian way of working? Please suggest me ?
[12:19] <RainCT> Hi deepak_
[12:19] <deepak_> RainCT, hi
[12:21] <RainCT> deepak_: Is there anything particular you are interested in or just bug fixing in general?
[12:21] <WujcioL> Can somebody explain me howto create no-compilated package for some python program??
[12:22] <deepak_> RainCT, i am interested in packaging of the packages which i do maintain Debian and also bug fixing
[12:22] <RainCT> WujcioL: http://wiki.debian.org/DebianPython/NewPolicy
[12:22] <RainCT> WujcioL: does the program have a setup.py file?
[12:22] <WujcioL> thanks
[12:23] <WujcioL> no it doesn't have it
[12:23] <WujcioL>  http://wiki.debian.org/DebianPython/NewPolicy
[12:23] <WujcioL> http://wiki.debian.org/DebianPython/NewPolicy
[12:24] <deepak_> RainCT, or new packages which are not in Debian and ubuntu .so i will create for both. so at the same time both distribution have new packages.
[12:25] <deepak_> RainCT, But i haven't find any group like debain-perl .. etc or any ITP type of stuff??
[12:25] <RainCT> deepak_: Ubuntu automatically imports new/updated packages from Debian at the start of a development cycle
[12:26] <deepak_> RainCT, yes that correct but instead of taking it from Debian , i want to package it.
[12:27] <RainCT> deepak_: ITP's are called needs-packaging bugs in Ubuntu (you can find them searching for the needs-packaging tag)
[12:27] <deepak_> RainCT, oh ok
[12:28] <RainCT> deepak_: and Ubuntu has some groups but they aren't that visible as in Debian as the packages in Ubuntu is community maintained (instead of having a Maintainer everyone can change them)
[12:31] <RainCT> deepak_: for new packages:
[12:31] <RainCT> !revu
[12:31] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[12:31] <deepak_> RainCT,ok
[12:31] <RainCT> deepak_: but if you are already involved in Debian I recommend to get them in there instead of into Ubuntu as that way both distros (+ derivatives) get it
[12:33] <deepak_> RainCT, yes i thought the same thing . but lets take an example .one of my packages libnet-tftp-ruby
[12:33] <RainCT> deepak_: ah, forgot to say that about syncs when they are no longer done automatically you can request them manually, see https://wiki.ubuntu.com/SyncRequestProcess
[12:34] <deepak_> RainCT,  oh ok
[12:35] <RainCT> WujcioL: if it hasn't a setup.py if it isn't a module you can use dh_install to place the files where you want, and if you use cdbs don't include python-distutils.mk (which depends on setup.py) but rather call dh_pycentral/dh_pysupport manually
[12:35] <RainCT> WujcioL: or you can just write the setup.py file yourself
[12:37] <elmargol> dpkg-shlibdeps: failure: no dependency information found for /usr/lib/libmicrohttpd.so.4 :/
[12:37] <elmargol> how do I fix this?
[12:38] <RainCT> deepak_: you said something about libnet-tftp-ruby before, what's with it?
[12:39] <deepak_> RainCT, libnet-tftp-ruby is not available in ubuntu (Currently) so was thinking that i will go ahead with this package in ubuntu ,
[12:39] <deepak_> RainCT, where "Need Packaging"  tag i will will find out?
[12:40] <RainCT> deepak_: it will be synced into Intrepid once the archive opens
[12:40] <deepak_> RainCT, ok
[12:40] <RainCT> deepak_: for Hardy it's to late to get new packages into it
[12:41] <deepak_> RainCT, ubuntu releases are faster then Debian . :)
[12:59] <deepak_> RainCT, where i can find 'Needs packaging " tags .like if i will go for new packages
[13:01] <RainCT> deepak_: for existing ones https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging
[13:01] <RainCT> deepak_: to file one yourself, file a bug and then on the Actions panel at the left go to "Edit description/tags"
[13:02] <deepak_> deepak_, oh ok
[13:37] <tacone> hello, I am looking for online resources about packaging php scripts
[14:27] <apachelogger> siretart: sure
[17:35] <LaserJock> Balaams_Miracle: hi :-)
[17:35] <Balaams_Miracle> LOL!!! :-)
[17:36] <LaserJock> Balaams_Miracle: are you wanting to do a completely new package, never been in Debian/Ubuntu before?
[17:36] <LaserJock> or just an update to an existing one
[17:37] <Balaams_Miracle> LaserJock: It would be a brand new package, but it's not mine. It was suggested to me by someone in the forum, and i think it would be a great addition to the already extensive repo's. The package is here: http://sourceforge.net/projects/easymp3gain/
[17:38] <LaserJock> Balaams_Miracle: check out https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[17:42] <Balaams_Miracle> LaserJock: So... If i understand correctly, i would need to file a needs-packaging bug. Correct?
[17:42] <LaserJock> yeah, that's usually the first step
[17:44] <Balaams_Miracle> I see... I think :-)
[17:45] <Balaams_Miracle> Well, if i hit a snag or something, i'll let you guys (and gals?) know.
[18:21] <xtknight> anyone mind getting an upload going on Bug 213827 ?
[18:21] <ubotu> Launchpad bug 213827 in flashplugin-nonfree "typo in prerm file breaks failed-upgrade processing" [High,Fix committed] https://launchpad.net/bugs/213827
[18:22]  * LaserJock runs
[18:22] <sebner> xtknight: LaserJock is ready :P
[18:22] <xtknight> flashplugin is your favorite package
[18:26] <blueyed> xtknight: that typo is quite irrelevant. The code block only gets called with an unknown prerm argument.. it's only cosmetic, AFAICS.
[18:27] <blueyed> ..but I might be totally wrong, so.
[18:30] <blueyed> xtknight: the error for Tiziano appears to be in postinst: "dpkg (subprocess): unable to execute post-installation script: Exec format error"
[18:31] <xtknight> blueyed, ah i have no idea what's going on w/ his setup
[18:32] <jdong> and I quote: "You'll probably have to remove the flashplugin-nonfree block from /var/lib/dpkg/status and try again. That's a last resort, though."
[18:32] <jdong> spawn cjwatson to yell at xtknight :)
[18:32] <xtknight> lol
[18:32] <xtknight> well i dont see errors in postinst
[18:33] <xtknight> and it seems 'cho' would make prerm fail
[18:33] <blueyed> xtknight: well, yes, but the next line would be "exit 1" anyway..!
[18:34] <xtknight> blueyed, when the command fails, the debian script receives an error and stops.  this prevents installing other packages
[18:34] <xtknight> at least afaik
[18:34] <blueyed> xtknight: the same for "exit 1", no?
[18:34] <jdong> xtknight: in the future it's better to ask him to edit his prerm/postinst script to not set -x
[18:34] <jdong> xtknight: or exit 0
[18:35] <jdong> xtknight: editing dpkg/status is extremely strongly discouraged, the last time I suggested that I was yelled at by all the core folk :)
[18:35] <xtknight> jdong, apparently a lot of my "methods" yield that
[18:35] <blueyed> xtknight: so your debdiff should probably change the "exit 1" to "exit 0", too.
[18:36] <xtknight> hmm
[18:36] <xtknight> odd.  there must be a reason "exit 1" is there though
[18:37] <blueyed> xtknight: maybe.. but I think it's rather the same oversight as with "cho".
[18:37] <jdong> xtknight: IMO there really shouldn't be a reason to purposely fail in a dpkg installation script
[18:38] <jdong> unless continuing the installation will result in serious data loss, breakage, etc
[18:38] <jdong> which I doubt would ever be true with flash
[18:38] <xtknight> yeah i agree
[18:38] <xtknight> because it would break the whole debian thing and require you to *gasp* edit the status file
[18:38] <xtknight> ;)
[18:38] <superm1> guys, vnc4server is very very broke in hardy currently.  if you move the mouse when you have vnc.so loaded, it will crash X.  what would folks think about my adding a postinst that will disable vnc.so in /etc/X11/xorg.conf and display a warning?
[18:38] <superm1> touching conf files is against policy, but there is no other immediate solution that i see
[18:39] <jdong> superm1: is it possible to disable vnc.so at build time?
[18:39] <superm1> jdong, it FTBFS now
[18:39] <superm1> oh crap, that makes this more difficult then doesn't it ....
[18:39] <jdong> superm1: I'm pretty shaky about the idea of editing xorg.conf from a postinst
[18:39] <superm1> can't change the postinst :)
[18:39] <jdong> superm1: haha
[18:39] <jdong> last-minute archive removal? :)
[18:39] <LaserJock> please do
[18:39] <superm1> well the thing is the vnc4server "binary"
[18:39] <superm1> works
[18:39] <superm1> its just vnc.so that's broke
[18:40] <superm1> so if you use it as a standalone x server that's fine
[18:40] <jdong> superm1: ok, can we just not install vnc.so?
[18:40] <superm1> well if it built sure
[18:40] <superm1> but that also causes breakage..
[18:40] <superm1> because if someoen has that in xorg.conf
[18:40] <superm1> X won't start
[18:40] <jdong> superm1: well if someone has that in xorg.conf the error log should be obvious why it failed
[18:40] <jdong> superm1: and people who have it in xorg.conf probably know what they're doing.
[18:41] <superm1> well not necessarily...
[18:41] <xtknight> blueyed, the problem is, the clause with "exit 1" doesn't do the same as the clause above it (when the if statement is true)
[18:41] <superm1> we have functions in mythbuntu control centre that enable it for you in gutsy
[18:41] <superm1> by touching xorg.conf and putting it in place
[18:41] <jdong> superm1: ah
[18:41] <superm1> so i
[18:41] <jdong> superm1: well it should definitely be mentioned in the release notes if it's this broken
[18:41] <superm1> 'm trying to look at the best migration path
[18:41] <superm1> well its not just going to hurt us of course though
[18:41] <jdong> right
[18:41] <superm1> so i was hoping to help everyone in the process
[18:42] <blueyed> xtknight: what do you mean with "the same"? Surely it doesn't, otherwise there would no other block  be required. I've left a comment in the bug.
[18:42] <jdong> but still, editing xorg.conf from a postinst is a bad idea IMO
[18:42] <superm1> well what about if it just checks that its an upgrade from gutsy in the postinst
[18:42] <superm1> and if it is then touch xorg.conf
[18:42] <jdong> superm1: does the package already have debconf support so we can pester the user interactively about this?
[18:42] <superm1> no it doesn't
[18:43] <jdong> superm1: otherwise an update manager notification hook?
[18:43] <superm1> well adding the debconf support would be trivial though
[18:43] <superm1> the more important thing would be fixing the FTBFS though
[18:43] <superm1> i spent a good week and a half of evenings trying to port it to the new xorg stuff
[18:43] <superm1> without any luck
[18:44] <superm1> oh interesting though, debian has some sort of solution for the ftbfs
[18:44] <superm1> well i'll revisit this then
[18:45] <xtknight> blueyed, would asking the original maintainer of the package be a good idea?
[18:45] <overbenny> hello, can someone re-sync the REVU uploaders keyring?
[18:46] <LaserJock> superm1: does vnc still include it's own Xorg version?
[18:46] <superm1> yeah it does (unfortunately)
[18:46] <superm1> vnc4server does
[18:46] <superm1> there was a fork called baracuda
[18:46] <superm1> that i started to package, but then realized it wasn't feature complete enough to replace vnc4server
[18:47] <LaserJock> vnc was one of the first packages I worked on
[18:47] <superm1> so would it be acceptable you suppose to propose the debconf question, "Detected that vnc.so is loaded from xorg.conf, this is gone for the hardy package due to bug blah blah.  Would you like it removed from xorg.conf for you?"
[18:47] <blueyed> xtknight: who would that be? asac?
[18:47] <xtknight> blueyed, i guess before changing exit 1 to exit 0 willy nilly i better be sure it's not breaking anything else.  it seems stopgap to me at best
[18:47] <superm1> and then call the pyhton script I wrote to remove it?
[18:47] <superm1> *python
[18:48] <xtknight> blueyed,  debian maintainer  Bart Martens <bartm@knars.be>
[18:48] <LaserJock> what a mess, shipping another X
[18:48] <xtknight> well maybe someone else introduced the exit 1 code, i'll have to see
[18:48] <blueyed> xtknight: ahem, the package is quite different in Debian. At least the prerm.
[18:48] <superm1> LaserJock, yeah i wish that was better thought out
[18:48] <superm1> but its do the monolithic history of XFree86
[18:49] <LaserJock> I worked on vnc4 and wxwidgets, good projects for newbs ;-)
[18:52] <blueyed> xtknight: sure, you need to be sure. But you understand that the typo is only cosmetical here, yes? http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-exitstatus
[18:52] <blueyed> xtknight: so, "exit 1" is the same as "exit 127" (command not found)
[19:17] <xtknight> blueyed, ah sorry i was AFK
[19:17] <xtknight> blueyed, but yea i understand
[19:17] <xtknight> because falling thru to exit 1 would do the same thing i guess
[19:26] <xtknight> asac, would you by any chance know why "exit 1" is in the debian scripts for flashplugin?
[19:26] <xtknight> or any idea who made the flashplugin for ubuntu
[19:26] <xtknight> so that i could ask them
[19:27] <asac> xtknight: please paste. in general it should work (except for the typo)
[19:27] <xtknight> asac, won't exit 1 give dpkg troubles?
[19:27] <xtknight> one sec i'm pasting prerm and postinst
[19:28] <xtknight> prerm : http://paste.ubuntu-nl.org/63094/  ;   postinst: http://paste.ubuntu-nl.org/63095/
[19:29] <asac> xtknight: it only returns exit 1 in case there is an error
[19:29] <asac> should be ok imo
[19:29] <xtknight> asac, ah alright, so the errors he was getting when installing my new package is due to the old package having screwed something up?
[19:30] <xtknight> cuz he got errors in postinst, and the error is only in prerm
[19:30] <asac> yeah ... the old script will still be run
[19:30] <asac> so he is somewhat lost
[19:31] <xtknight> ah so old prerm of old pkg is run when you install a new version of the same package?
[19:31] <xtknight> makes sense i guess
[19:32] <xtknight> blueyed, he got this error first dpkg (subprocess): unable to execute old pre-removal script: Exec format error
[19:32] <xtknight> so postinst of new one is failling becaues prerm of old one is failling
[19:32] <xtknight> or someting
[19:33] <xtknight> purging the old one would have yielded the same error he got in the beginning
[19:33] <xtknight> so i do not see that he has any option besides editing the dpkg status file to get rid of the old package
[19:34] <xtknight> which i think is perfectly acceptable when the package has a problem
[19:35] <xtknight> i also do not see why "exit 1" is a problem because it is supposed to quit when the package has an issue.
[19:35] <xtknight> but cho is cosmetic
[19:36] <xtknight> so at least he'd know something wrong if exitcode was 1
[19:37] <geser> xtknight: according to http://women.debian.org/wiki/English/MaintainerScripts the new prerm is run if the old one fails
[19:38] <xtknight> geser,  ah well new prerm also would have failed (as it would still fall through to exit 1)
[19:39] <geser> xtknight: why has dpkg a problem with executing the prerm script (which is usually a shell script)?
[19:40] <xtknight> i don't know, i'm confused why he had the bug in the first place.  somehow he got an old package on his Hardy
[19:40] <xtknight> i can't reproduce his problem
[19:40] <xtknight> and i have no idea how to fix it.  changing "cho" to "echo" wouldn't do it.  Bug 213827
[19:40] <ubotu> Launchpad bug 213827 in flashplugin-nonfree "typo in prerm file breaks failed-upgrade processing" [High,Fix committed] https://launchpad.net/bugs/213827
[19:41] <xtknight> so the title is wrong.  it's an old flash package (which triggers exit 1 in prerm) causing him trouble, not a typo
[19:44] <geser> xtknight: the exit 1 shouldn't cause the exec format error
[19:44] <xtknight> geser, yea "cho" causes this, but the end result would be the same (dpkg failing with nonzero error code) if it went thru to exit 1
[19:44] <xtknight> he's screwed either way, right?
[19:44] <xtknight> i do think the "cho" patch should go in, but at least it won't be fixing the reporter's problem
[19:45] <xtknight> "exit 1" came right after cho
[19:46] <geser> the "cho" should cause a "command not found" error but not a exec format error
[19:46] <xtknight> oh?
[19:46] <xtknight> o dpm
[19:46] <xtknight> err..  i don't even know what exec format error means
[19:46] <geser> I'd suggest to test if the bug submitter can execute other shell scripts and check if /bin/sh is correct (or broken)
[19:46] <xtknight> i think he somehow got a tainted package on his system
[19:46] <xtknight> or something else is messed up
[19:47] <xtknight> yeah
[19:54] <xtknight> geser, thanks for your input
[20:35] <LaserJock> so we went through an email discussion, blog post, and MOTU Meeting and still can't get a name for Universe Apprentices?
[20:40] <sebner> LaserJock: if that's the only blocker it's somehow stupid
[20:47] <LaserJock> well, I'm sort of regretting saying anything now
[20:50] <ScottK2> As long as it's not monkeys or hackers, I'm pretty much fine.
[20:52] <LaserJock> I agree
[20:53] <LaserJock> ScottK2: I noticed againin the meeting notes that it's "contribution" to Ubuntu not specifically Universe
[20:53]  * ScottK2 missed the meeting, so if that's what's decided, I can live with it.
[21:14] <spacepluk> hi, i
[21:15] <spacepluk> i'm trying to setup a chroot to make a source package. I've followed the instructions on this howto https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/appendix-chroot.html. Is this outdated?
[21:16] <LaserJock> yeah
[21:16] <LaserJock> try wiki.ubuntu.com/PackagingGuide
[21:17] <spacepluk> LaserJock: thanks
[21:21] <spacepluk> LaserJock: so this chrooting guide is supposed to work on hardy? https://wiki.ubuntu.com/DebootstrapChroot
[21:21] <jdong> oh deities, what's the best way of using LVM to implement a COW "overlay" type of temporary workspace?
[21:21] <LaserJock> spacepluk: I think so yeah
[21:21] <jdong> i.e. i have /srv and am about to do some horribly wreckless thing. I want to do it on a snapshot and be able to either (1) revert to the original (2) make the new overlay the default, really fast.
[21:22] <spacepluk> LaserJock: thanks :)
[21:50] <mok0_> ZZzzzz
[22:38] <jdong> ack that's really annoying
[22:38] <jdong> ctrl-u shows source in firefox
[22:45]  * jdong crackports banshee for fun
[22:45] <Nafallo> crackport?
[22:45] <Nafallo> is that like in Amsterdam?
[22:46] <RAOF> jdong: Yeah, that'd be awesome.
[22:47] <RAOF> Nafallo: I think that's where you backport a snapshot of svn trunk :)
[22:47] <Nafallo> RAOF: in Amsterdam? :-)
[22:47] <jdong> RAOF hits the nail on the head :)
[22:48] <jdong> actually the debian experimental package this time :)
[22:48] <jdong> so it's not as cracky as a svn backport + drop all debian/patches :D
[22:48] <RAOF> It does have the problem of not actually being feature complete, of course.
[22:51] <crimsun> mm.  gcj-4.2 just ate 1.3 GB RAM for breakfast and didn't stop to blink.  And sent my system into a near-spiral o' death for 1 hr.
[22:51] <RAOF> crimsun: Is this meant to surprise us? :X
[22:52] <crimsun> no, I'm bemoaning that I'll have to buy more RAM just to debug these issues.
[22:52] <RAOF> I remember building Azureus - gcj ate all my 1GB of ram, 4GB of swap and then OOMd.
[22:53] <crimsun> actually it looks like it went through 5.5 GB swap, too.  Nice.
[22:53] <jdong> RAOF: and that's a good reason not to build azureus with gcj :D
[22:53] <jdong> not to mention gcj has an incomplete and incompatible java.nio stack
[22:54] <jdong> so the fact that azureus even worked with gcj is astounding
[22:54] <crimsun> so, anyone have a box with at least 4 GB RAM?  ;)
[22:54]  * RAOF should've asked for a couple of sticks for his birthday :)
[22:57] <jdong> crimsun: PPA?
[22:58] <crimsun> jdong: I don't think testing internal fixes on a PPA is Good Practice.
[23:00] <Nafallo> Fujitsu: around?
[23:00] <jdong> crimsun: oh come on, a crimsun-crack-dept team would be awesome!
[23:00] <RAOF> I'm sure the LP servers would appreciate the work.  They sit around idle far too much!
[23:00] <RAOF> They'll get rusty.
[23:08] <spacepluk> bye