| * persia forgets the command to do the right thing, and hopes someone else is watching. | 00:00 | |
| XSource_ | persia: you mean, about me? | 00:02 |
|---|---|---|
| persia | XSource_: Yes. | 00:02 |
| XSource_ | well I was just trying this new plug-in, didn't mean that | 00:02 |
| persia | XSource_: Ah. If you're just testing, no worries then (but be careful: most multichannel traffic is interpreted poorly) | 00:03 |
| XSource_ | and the bad thing it's in every channel | 00:03 |
| jscinoz | hey guys | 00:04 |
| ion_ | Hi | 00:04 |
| jscinoz | do i need to include orig.tar.gz for a package that has no source (game data files, they | 00:04 |
| jscinoz | 're just texturtesa nd sounds etc) | 00:04 |
| txwikinger | Happy New Year from here now too ;) | 00:04 |
| persia | jscinoz: That's source. You need a source to generate a binary (even if it's just copying files). | 00:04 |
| jscinoz | happy new year :P (was 11hours ago for me) :P | 00:04 |
| jscinoz | ah | 00:05 |
| jscinoz | also persia | 00:05 |
| jscinoz | or anyone else | 00:05 |
| jscinoz | can tar get input from stdin | 00:05 |
| jscinoz | im trying to have a pipe that extracts a zip, tars what comes out, then gzips it | 00:05 |
| jscinoz | but i dont think tar can take stdin as input | 00:05 |
| SnackPack | iirc.. | 00:06 |
| persia | jscinoz: I think tar only accepts tarfiles to stdin (zcat foo.tgz | tar xf -), but doesn't accept filestreams (I'm not even sure what a filestream would be: how does one differentiate EOF from EOS?) | 00:06 |
| SnackPack | also, zipfile header info is at the EOF | 00:07 |
| SnackPack | so it's not real suitable for piping | 00:07 |
| jscinoz | so would it be better to have unzip extract to /tmp/something and just have it read from there since /tmp gets cleaned automatically | 00:08 |
| SnackPack | you should clean up your mess anyways. :) | 00:08 |
| SnackPack | or attempt to | 00:08 |
| persia | jscinoz: Be sure to create a safe temporary directory, and clean up after yourself. /tmp only gets cleaned on reboot, which may not be often for some users. | 00:08 |
| jscinoz | alright | 00:08 |
| SnackPack | mktemp | 00:09 |
| jscinoz | snackpack, if i use mktemp, how do i inform the next command of the randomly generated directory name? | 00:17 |
| SnackPack | if I recall... | 00:17 |
| SnackPack | MYTMPDIR=$(mktemp) | 00:18 |
| SnackPack | use man mktemp for an example | 00:18 |
| jscinoz | ah yeah got it | 00:18 |
| * persia advocates := unless it's really important to perform the creation at the moment of invocation | 00:18 | |
| SnackPack | true | 00:20 |
| jscinoz | if variables set out are only needed by one build rule is it better practise to put them in that rule rather than at the beginning of the debian/rules | 00:20 |
| persia | jscinoz: Depends on what the variables do. In this case, likely. note that creating rule-scoped variables in make is done at the end of the rule definition line, rather than on a separate line. | 00:21 |
| jscinoz | hmm | 00:21 |
| jscinoz | whats the differenceb etween using, "=" or ":=" | 00:22 |
| persia | jscinoz: parse time vs. run time. http://www.gnu.org/software/make/manual/make.html#Flavors has specifics | 00:22 |
| jscinoz | ah | 00:23 |
| * txwikinger wonders what the problem with bonobo is | 00:23 | |
| Amaranth | other than its evil? | 00:25 |
| persia | Amaranth: monkeys can't be evil: no morality applies | 00:26 |
| jscinoz | persia i got the sed thing to work to add the underscores at the right place now | 00:26 |
| jscinoz | 's_\([0-9][0-9][0-9][0-9]\)\([0-9][0-9]\)\([0-9][0-9]\)_\1\_\2\_\3_' | 00:27 |
| persia | jscinoz: I'm glad to hear your problem has been addressed, but I'm sure there is a more aesthetically pleasing way to accomplish it. Was uscan --dehs completely unhelpful? | 00:27 |
| jscinoz | yes unfortunately | 00:28 |
| jscinoz | as i need both the mangled and unmangle version numbers and i could find no way to get it to output both without breaking other things. | 00:28 |
| txwikinger | it messes up something when compiling evolution | 00:28 |
| persia | jscinoz: You could make it slightly less bad by using something other than '_' as your sed delimiter. '/' is popular, or '#' | 00:29 |
| jscinoz | hmm ok i'll try that | 00:29 |
| persia | jscinoz: How about s/\(\d{4}\)\(\d{2}\)\(\d{2}/\1_\2_\3/ ? | 00:31 |
| jscinoz | ill give it a try one sec. | 00:32 |
| persia | Err... nevermind. I'm confusing sed & perl again :( | 00:32 |
| ion_ | I’d use sed -r and drop most of the backslashes. | 00:32 |
| jscinoz | dont do it that way persia? | 00:32 |
| jscinoz | *confused* | 00:32 |
| persia | ion_: Good suggestion :) | 00:33 |
| jscinoz | ill do that now :) | 00:33 |
| jscinoz | which of the \ should i remove from 's_\([0-9][0-9][0-9][0-9]\)\([0-9][0-9]\)\([0-9][0-9]\)_\1\_\2\_\3_' | 00:34 |
| ion_ | % echo foo01234567bar | sed -r 's/([0-9]{4})([0-9]{2})([0-9]{2})/\1_\2_\3/' | 00:36 |
| ion_ | foo0123_45_67bar | 00:36 |
| jscinoz | cheers | 00:37 |
| * SnackPack upgrades to hardy | 00:45 | |
| jscinoz | gah | 00:52 |
| jscinoz | it seems that later in my script it just reads these variables as null | 00:52 |
| jscinoz | rather than what they truly are. | 00:52 |
| persia | jscinoz: debian/rules is not a script, which might be part of that. | 00:52 |
| jscinoz | ugh | 00:53 |
| jscinoz | wait got it i think | 00:54 |
| persia | jscinoz: echo x$(VARIABLE)x can be surprisingly informative | 00:55 |
| jscinoz | whats the x on eachside for? | 00:55 |
| persia | jscinoz: Helps detect the difference between a space and a null | 00:55 |
| jscinoz | ah | 00:56 |
| jscinoz | ah | 00:56 |
| jscinoz | oops | 00:56 |
| jscinoz | woo got it | 00:56 |
| victor_ | $() is used for command substitution, you probably mean ${VARIABLA} | 00:57 |
| persia | victor_: In a makefile? | 00:58 |
| * persia reiterates that debian/rules is not a shell script | 00:58 | |
| victor_ | oh :) | 00:58 |
| crimsun | (well, not normally.) | 00:59 |
| persia | crimsun: it really, really, really oughtn't be. I thought the "debian/rules is not a makefile" meme even reached mass-bug-file status once, didn't it? | 01:00 |
| imbrandon | guess it depends on the #! thats at the top :) | 01:00 |
| persia | Err.. "debian/rules is not a shell script" (carefully wiping egg) | 01:01 |
| crimsun | I've seen debian/rules be a compiled executable. | 01:01 |
| ion_ | Wow :-) | 01:01 |
| crimsun | and yes, it left a rather nasty aftertaste. | 01:01 |
| persia | crimsun: Ah. I suppose it works, but... | 01:01 |
| imbrandon | heh | 01:01 |
| Amaranth | crimsun: bash | 01:02 |
| Amaranth | debian/rules could be a python script too | 01:02 |
| Amaranth | or ruby, etc | 01:02 |
| persia | I suppose it could be anything as long as it takes the right arguments, but I still believe it ought to be a makefile. | 01:02 |
| Amaranth | It can't be for some things | 01:03 |
| imbrandon | except where make is broke | 01:03 |
| Amaranth | the package for make can't have a makefile | 01:03 |
| persia | Amaranth: Why not? Lots of packages build-depend on themselves. | 01:03 |
| Amaranth | I'd hate to bootstrap that | 01:03 |
| imbrandon | bootstrap + equivs | 01:03 |
| imbrandon | heh | 01:03 |
| Amaranth | vala svn depends on itself but the releases come with preconverted code | 01:04 |
| Amaranth | it's really fun when latest svn can't be compiled with the latest release | 01:04 |
| persia | Amaranth: debian/rules for make is a makefile :P | 01:04 |
| Amaranth | you have to jump to some revision in the middle, etc | 01:04 |
| === RzR is now known as rZr | ||
| imbrandon | mmm almost newyears | 01:06 |
| imbrandon | ( here ) | 01:06 |
| Amaranth | 5 hours | 01:06 |
| persia | Bah. People in obsolete places. so behind the times. | 01:07 |
| jscinoz | ugh | 01:10 |
| crimsun | we can't all be as chronologically progressive as you, persia :p | 01:10 |
| persia | crimsun: That's just last year's thinking :) | 01:11 |
| txwikinger | Ha.. a new scale pf discrimination... chronologically challenged | 01:11 |
| jscinoz | ugh tar includes the temp directory in the orig.tar.gz directory structure | 01:14 |
| jscinoz | ie.. in the tarball we have tmp.xxxxx/sourcefolder1 sourcefolder 2 | 01:15 |
| jscinoz | any idea how to make it stop doing this. | 01:15 |
| persia | jscinoz: call it with (cd $$foo; tar czf $$bar .) | 01:15 |
| === boomer^ is now known as boomer | ||
| jscinoz | ah | 01:16 |
| jscinoz | thanks :) | 01:16 |
| jscinoz | yay got my get-orig-source all good :D | 01:23 |
| jscinoz | now.. | 01:23 |
| jscinoz | ugh | 01:27 |
| jscinoz | the .svn directories are still included in the orig.tar.gz | 01:27 |
| jscinoz | how can i strip these out somewhere between extracting the zip and building the tarball? | 01:27 |
| persia | jscinoz: You're pulling from svn directly, or upstream is providing them in the zip file? | 01:28 |
| jscinoz | upstream providing in zip | 01:28 |
| persia | jscinoz: man tar. Read about --exclude | 01:28 |
| * crimsun wonders about libsdl1.2debian-pulseaudio vice libsdl1.2debian-alsa by default. | 01:29 | |
| jscinoz | alright here goes, lets hope get-orig-source is finally working | 01:29 |
| persia | crimsun: surely pulse. The games may have (slightly) higher latency, but otherwise there are strange blocking effects (why doesn't my music play when I'm playing this?) | 01:29 |
| imbrandon | crimsun: got time to help me debug a sound issue on my imac, if not its all good ( seems alsa think my front built in speakers are headphones , ontop of that it mutes them on startup no matter what ) | 01:31 |
| jscinoz | hmm alls looking good, for my man pages should i gzip them or have dh_compress handle the compression? | 01:31 |
| persia | jscinoz: dh_compress is more likely to track current policy | 01:31 |
| imbrandon | dh_installman compresses them too doesnt it ? | 01:32 |
| * imbrandon isnt sure | 01:32 | |
| persia | imbrandon: it doesn't claim to do so in the manpage | 01:32 |
| imbrandon | ahh i'm likely mistaken then | 01:33 |
| imbrandon | been quite a while since i looked | 01:33 |
| crimsun | imbrandon: sure, but a sec, please | 01:33 |
| imbrandon | crimsun: sure no problems, and no hurries at all, i'm just watching irc as my kids play twister | 01:34 |
| crimsun | persia: I was hoping that there wouldn't be any seed issues, and there appear to be none (e.g., *ubuntu-desktop depending on libsdl1.2debian-foo) | 01:34 |
| imbrandon | hehe | 01:34 |
| crimsun | looks like we simply need to ask for libsdl1.2debian-pulseaudio's promotion | 01:34 |
| persia | crimsun: Excellent then. I welcome our new pseudopodic overlords with glee. | 01:35 |
| jscinoz | i've read over the man page of dh_compress, i'm assuming i need to create a copy of the filesystem hirachy in ./debian and place the man page and other documentation in their appropriate locations for it to work? | 01:36 |
| persia | Is Henrik Stokseth available? I've reviewed one of five REVU candidates, and wonder if the others need review, or may have some of the same issues as the first reviewed (cdemu-client) | 01:36 |
| persia | jscinoz: debian/rules install should take care of most of that for you | 01:37 |
| ion_ | Could i get a second person to advocate http://revu.tauware.de/details.py?package=hardware-connected (a program that indicates whether given hardware exists in the system; useful for scripting) and http://revu.tauware.de/details.py?package=apt-mark-sync (a program that synchronizes the “automatically installed” status of packages between different package managers)? Thanks. | 01:38 |
| * persia notes there are four other packages also awaiting a second advocate, if anyone is just watching twister and otherwise bored | 01:38 | |
| jscinoz | *confused* | 01:39 |
| persia | jscinoz: About? | 01:39 |
| jscinoz | so i have a man page, the copyright file, the debian changelog and the upstream changelog | 01:40 |
| jscinoz | i need the copyright to go uncompressed in /usr/share/doc/urbanterror, the two changelogs to go in the same directory compressed as changelog.gz and changelog.Debian.gz, and the currently uncompressed man page to go in /usr/share/man/man6/urbanterror.6.gz | 01:41 |
| jscinoz | how would i get dh_compress to do that. | 01:41 |
| imbrandon | persia: heh ok i'll look at revu | 01:42 |
| ion_ | Personally i quite like CDBS. It Does The Right Thing™ with only a few lines in debian/rules. | 01:42 |
| jscinoz | i've already mostly completed this package i dont want to start over with cdbs. | 01:42 |
| persia | jscinoz: For the manpage, use dh_installman. For the upstream changelog, use dh_installchangelogs For debian/copyright and debian/changelog, expect something else to handle it (I forget which). Call dh_compress in your binary-arch target to compress everything properly. | 01:42 |
| jscinoz | thanks | 01:42 |
| ion_ | The non-CDBS debian/rules files made by dh_make handle that just fine, of course. | 01:42 |
| crimsun | imbrandon: for a stable, supported release, or hardy? | 01:44 |
| jscinoz | thanks :) | 01:45 |
| persia | crimsun: Is the default output for pulse really all connected output devices simultaneously? | 01:50 |
| crimsun | persia: for which version? | 01:54 |
| crimsun | it wasn't for 0.9.5 or 0.9.6 | 01:55 |
| persia | crimsun: The version to be released in April with hardy (just saw a comment in the CleanupAudioJumble spec to this effect, and wanted to confirm or deny) | 01:55 |
| persia | Specifically https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble?action=diff&rev2=56&rev1=55 | 01:55 |
| crimsun | ah, for 0.9.8 it should be by default, yes. | 01:55 |
| persia | Ah. Hmm. OK. Thanks for the confirmation. | 01:56 |
| crimsun | there's some buffoonery still for hotplugged usb devices, so I need to track that | 01:56 |
| * crimsun migrates wifi hotspots | 01:57 | |
| imbrandon | crimsun: gutsy on ppc , actualy its on etch right now ( to see if it was a ubuntu specific thing ) | 01:58 |
| imbrandon | so i guess i'll put gutsy back on it later or maybe hardy | 01:59 |
| imbrandon | but i'm guessing its a core alsa thing as it happens with all linux i have put on it ( only debian based ones ) | 01:59 |
| jscinoz | argh | 02:02 |
| jscinoz | i'm building both the server and client packages for a game, the source gotten from the upstream vendor is a zip file containing a client and server folder, in my orig.tar.gz should i have both client and server in one tarball or separate for each package? | 02:03 |
| persia | jscinoz: It is best practice to have one orig.tar.gz for each upstream distributed file. If upstream combines the client and server in a single package, you may wish to have one source package (with multiple binary packages). | 02:07 |
| jscinoz | ok | 02:14 |
| crimsun | imbrandon: ok, I'll need to know whether you're using the version(s) of alsa built-in to linux-image* or whether you've used module-assistant with alsa-source | 02:23 |
| crimsun | imbrandon: also, for each of those, please grab http://trilug.org/~crimsun/alsa-info.sh, and let me know the URLs. | 02:24 |
| === LongPoin1yStick is now known as LongPointyStick | ||
| * persia declares victory over REVU, and finds alternate entertainment | 03:01 | |
| Hobbsee | heh | 03:01 |
| Hobbsee | persia: sponsorship queue? | 03:01 |
| persia | Hobbsee: Not soon. I need to take a break from looking at possible mistakes, and don't want to be unduly firm (UUS has a lower threshold for acceptance than REVU). | 03:02 |
| Hobbsee | heh | 03:02 |
| Hobbsee | true | 03:02 |
| persia | txwikinger: Good catch on the *really* old standards versions :) | 03:14 |
| jscinoz | uscan is ignoring --force-download, it doesnt download the upstream source | 03:47 |
| persia | jscinoz: Please pastebin your watch file. | 03:47 |
| jscinoz | can i just paste here as its only two lines? | 03:48 |
| jscinoz | version=3 | 03:48 |
| jscinoz | opts=uversionmangle=s/_//g ftp://ftp.snt.utwente.nl/pub/games/urbanterror/iourbanterror/source/complete/ioUrbanTerrorSource_(.*)\.zip | 03:48 |
| persia | jscinoz: I get "uscan warning: In debian/watch no matching files for watch line" with that watch file. | 03:50 |
| === harrisony is now known as harrisony1 | ||
| jscinoz | i dont get any errors, it just refuses to download it | 03:51 |
| jscinoz | it states current version is latest | 03:51 |
| jscinoz | and even with --force-download doesnt download | 03:51 |
| persia | jscinoz: What is the output of bare `uscan` in the package directory? | 03:52 |
| jscinoz | nothing | 03:53 |
| persia | And your watchfile matches http://paste.ubuntu.com/3170/ ? | 03:53 |
| jscinoz | yes | 03:55 |
| jscinoz | hmm | 03:55 |
| jscinoz | i didnt change anything but it worked this time. | 03:55 |
| jscinoz | maybe the server had a brainfart :P | 03:55 |
| persia | Odd. I don't know why I'd get different output than you, and I don't know why it works for you when it doesn't for me. | 03:55 |
| jscinoz | strange isnt it | 03:56 |
| nixternal | persia: I just installed that qdevelop and I have to say it is a mess | 04:09 |
| nixternal | it doesn't work | 04:09 |
| persia | nixternal: Ah. Please leave a note :) | 04:09 |
| nixternal | doing so now | 04:09 |
| persia | nixternal: I don't suppose you'd be up for rejecting the 6 candidates remaining as well (assuming you can find a reason)? | 04:10 |
| nixternal | do you have a list of them? | 04:10 |
| persia | nixternal: The ones with the glass on http://revu.ubuntuwire.com/ | 04:11 |
| nixternal | roger | 04:11 |
| nixternal | holy shit, a 12mb dat file | 04:12 |
| persia | which package? | 04:14 |
| crimsun | pfft. Try the ia32-libs source. ;) | 04:14 |
| crimsun | bf04278fc7870bae37175e314cde66a0 454876971 ia32-libs_2.2ubuntu2.tar.gz | 04:14 |
| crimsun | munch on that, dude! | 04:14 |
| * persia thinks urbanterror-data wins | 04:14 | |
| crimsun | it's larger than 454 MB?! | 04:14 |
| persia | crimsun: http://revu.ubuntuwire.com/details.py?package=urbanterror-data | 04:14 |
| crimsun | eww. | 04:15 |
| crimsun | thank goodness for rsync | 04:15 |
| nixternal | persia: the mame hacks | 04:16 |
| nixternal | that shouldn't even be packaged, let alone be on revu | 04:16 |
| nixternal | if it doesn't meet ppa rules, then I do not advocate..I hope that is what you were looking for on this | 04:17 |
| nixternal | if it isn't free, then you get no advocation from me :p | 04:17 |
| persia | nixternal: Doesn't meet PPA rules? | 04:17 |
| nixternal | ya, has to be free in a sense | 04:17 |
| === santiago-ve is now known as foursixnine | ||
| persia | nixternal: cheat.dat is a text file. | 04:18 |
| nixternal | ya, 12mb text file that you can't edit, and doesn't belong in universe | 04:19 |
| nixternal | don't even feel it belongs in multiverse | 04:19 |
| crimsun | err, what's the license on it? | 04:19 |
| persia | nixternal: That works for me. Last time I tried to shoot something down because it wasn't free (pq), I was overridden, so I'm not making that call any more. | 04:19 |
| persia | crimsun: http://paste.ubuntu.com/3172/ is the relevant section of cheat.dat | 04:22 |
| crimsun | eww. | 04:22 |
| crimsun | yeah, kill it. | 04:22 |
| pwnguin | progress quest? | 04:23 |
| crimsun | at best, one could use a wrapper to grab it (e.g., flashplugin-nonfree, and formerly, djbdns-installer) | 04:23 |
| persia | The arguable bit is that it says "all I ask..." and "Please...", which may not actually mean we can't, but that doing so isn't nice. | 04:23 |
| * Fujitsu wonders if such badly written licenses are enforcable. | 04:23 | |
| persia | pwnguin: Yes. | 04:23 |
| pwnguin | you dont need nonfree to shoot that down | 04:24 |
| * persia thinks it's like postcardware | 04:24 | |
| Fujitsu | Both English- and `Please'-wise. | 04:24 |
| pwnguin | useless is enough in my book | 04:24 |
| persia | pwnguin: Really? Would you like to file a removal request? | 04:24 |
| Fujitsu | pwnguin: But wrapperss involving Wine are *fun*! | 04:24 |
| Fujitsu | I think most present would love to see it killed. | 04:24 |
| pwnguin | persia: i dont count for much | 04:24 |
| persia | pwnguin: Everyone counts :) | 04:25 |
| pwnguin | if it got into the archive, i dont see how a "this is pointless" is going to take it out | 04:26 |
| Fujitsu | persia: Is cheat.dat redistributable if not distributed with MAME or a MAME frontend? | 04:26 |
| persia | Fujitsu: Actually, no. Good point. | 04:27 |
| Fujitsu | What is sdlmame-cheat? Is it a MAME frontend? | 04:27 |
| persia | Fujitsu: No, just the cheat file. | 04:27 |
| Fujitsu | Or does it not mean `MAME frontend', but `cheat.dat frontend'? | 04:27 |
| Fujitsu | The duplication of `any' in that phrase makes it a bit confusing. | 04:28 |
| persia | Still, there's a good argument that distribution without any MAME compile or any frontend may be in violation of the license. | 04:28 |
| Fujitsu | So there's no frontend at all with it? | 04:28 |
| * Fujitsu looks. | 04:28 | |
| persia | Fujitsu: Nope. The entire package is just a wrapper for the cheat DB. It's intended to go with http://revu.ubuntuwire.com/details.py?package=sdlmame, which is packaged separately. | 04:29 |
| Fujitsu | ... so it is. | 04:30 |
| Fujitsu | That's unredistributable. | 04:30 |
| * Fujitsu would advise a nuking. | 04:30 | |
| persia | Excellent. One down: 5 to go. Commenting and nuking. | 04:30 |
| * Fujitsu likes dealing with licensing if it keeps packages like that out. | 04:31 | |
| Fujitsu | Erm, licencing, I guess. | 04:31 |
| nixternal | persia: http://revu.tauware.de/details.py?package=mscore <- why are there 2 debian/ directories? one in the root directory and one in the mscore directory..is that fine? | 04:31 |
| Fujitsu | persia: I like your second mscore review. | 04:32 |
| nixternal | heh, he is like "oh that was brief, here is the full review" | 04:32 |
| Fujitsu | Yep. | 04:32 |
| nixternal | his full review is about the size of that damn mame.dat file :p | 04:32 |
| persia | nixternal: Nah. Some of my reviews actually flood the buffer, and require two comments :P | 04:33 |
| persia | The first review was interrupted as there was discussion in-channel regarding the package, and all parties were convinced it was a duplicate (it's not). | 04:34 |
| Fujitsu | I recall that discussion, and the intense confusion that abounded for some time. | 04:35 |
| persia | Fujitsu: Erm. nuking is broken :( | 04:36 |
| Fujitsu | Somebody probably wants to remove the two sdlmame-cheat orig.tar.gzs at some point. | 04:36 |
| Fujitsu | persia: One cannot nuke from the web interface, I don't think. | 04:36 |
| Fujitsu | And nuking destroys the comments and all, I believe. | 04:37 |
| persia | There are Nuke buttons on http://revu.ubuntuwire.com/index.py?archived=true for me. | 04:37 |
| Fujitsu | Ah, I'm not logged in. | 04:37 |
| persia | Also, all comments are archived at http://lists.tauware.de/listinfo/motu-reviewers, so http://lists.tauware.de/pipermail/motu-reviewers/2008-January/019164.html remains available for discussion in the future. | 04:38 |
| crimsun | mozilla-devscripts looks ok. I'd only update the FSF address in debian/rules and src/* | 04:38 |
| Fujitsu | That's true. | 04:38 |
| persia | crimsun: Please upload or reject asking for the adjustment :) | 04:39 |
| Fujitsu | persia: Does /index.py?nuke=<upid> work? | 04:39 |
| persia | Fujitsu: No. I tried http://revu.ubuntuwire.com/index.py?nuke=624 | 04:39 |
| crimsun | "No REVU account for crimsun@fungus.sh.nu exists yet." | 04:40 |
| crimsun | erm, ok. | 04:40 |
| * persia creates an account for crimsun... | 04:40 | |
| Fujitsu | crimsun: Try your primary LP address. | 04:41 |
| persia | crimsun: Actually, try the email address you usually use when uploading first | 04:41 |
| crimsun | doesn't work. | 04:41 |
| crimsun | (besides, my primary LP address is @fungus, and that's the one associated with the "old" revu account) | 04:42 |
| persia | Right. New account coming up... | 04:42 |
| crimsun | thanks! | 04:42 |
| === foursixnine is now known as santiago-php | ||
| === santiago-php is now known as santiago-ve | ||
| persia | Erm. register_user.py doesn't seem to have execute permission :( | 04:43 |
| crimsun | (I promise I really did have a rationale for saying it here in the channel instead of logging in and commenting ;-) | 04:44 |
| Fujitsu | persia: Just do it manually. | 04:44 |
| * persia investigates | 04:44 | |
| Fujitsu | persia: Or in fact just run `python register_user.py' | 04:46 |
| Fujitsu | Don't know why I didn't think of that immediately | 04:46 |
| persia | Fujitsu: Right. Thanks. | 04:48 |
| persia | crimsun: Try again | 04:48 |
| crimsun | there's nothing for me to enter | 04:50 |
| persia | crimsun: You should be able to "Recover" your password, if you control GPG key c88abda3 | 04:50 |
| crimsun | I attempted that. | 04:51 |
| crimsun | the resulting page provides no data to paste. | 04:51 |
| crimsun | (this bug has existed since the recovery option existed ;) | 04:51 |
| persia | Strange. Recovery usually works for me. | 04:52 |
| * persia hopes someone with deeper understanding of REVU can explain what I did wrong | 04:53 | |
| * Hobbsee suspects it's just borked. | 04:54 | |
| Fujitsu | ./me looks. | 04:54 |
| nixternal | persia: do you have any clarification on that second debian/ directory in the mscore package? otherwise it is a good package, builds, installs/uninstalls/purges just fine | 04:55 |
| nixternal | have no clue wth the app does though | 04:55 |
| persia | nixternal: Second debian directory? It's designed to help composers: they write songs with it. | 04:56 |
| nixternal | under the mscore/ directory there is another debian/ directory | 04:56 |
| persia | Ah. Somehow I missed that. Hrm. | 04:56 |
| Fujitsu | crimsun: Your existing account was crimsun@ubuntu.com. | 04:56 |
| * Fujitsu tries to work out why recovery isn't working. | 04:56 | |
| nixternal | holy cow, you mean I found something that you didn't persia? ;) | 04:57 |
| persia | nixternal: Fairly easy, really. | 04:57 |
| nixternal | persia: I can find the easy stuff, you, you find stuff I have never even heard of :) | 04:57 |
| persia | nixternal: That's because I make half of it up :P | 04:57 |
| nixternal | hahahahhahaha | 04:58 |
| nixternal | so I am not the only one then | 04:58 |
| persia | nixternal: The extra debian directory is part of the upstream tarball. I suppose it could be pulled in the repack, but I don't know if it matters much. | 04:58 |
| nixternal | ya, that is what I figured | 04:59 |
| nixternal | just a dirty tarball | 04:59 |
| * persia tends to review diff.gz, with only passing reference to orig.tar.gz regarding licensing and application functionality | 04:59 | |
| crimsun | you can be pedantic with Toby; he can handle it. ;) | 04:59 |
| nixternal | I tend to grab the dsc, build it, run dh_install --list-missing on it, and find the easy stuff | 04:59 |
| persia | nixternal: That's another you can kill then :) Only 3 to go. | 04:59 |
| nixternal | hehe | 04:59 |
| nixternal | persia: you want me to upload mozilla-devscripts? | 05:08 |
| Fujitsu | persia, crimsun: I think I probably know why the recovery wasn't working, though I don't have enough permissions on sparky to check - 0xC88ABDA3 won't be on the keyring until the next sync. | 05:08 |
| persia | Fujitsu: Are you resyncing now? | 05:09 |
| Fujitsu | persia: I can't. | 05:09 |
| persia | nixternal: I don't have an opinion either way. crimsun mentioned a couple issues, so I thought he was handling it. | 05:09 |
| persia | Fujitsu: Ah. I will then. | 05:09 |
| nixternal | persia: ok, crimsun mozilla-devscripts is all yours | 05:10 |
| Fujitsu | You could always just PM crimsun his password for now. | 05:10 |
| persia | Except I've purged it from my logs and don't remember it | 05:10 |
| nixternal | gonna grab a snack before new years hits, then I am going to see if the coppers are hiding so I can pull the snowmobile out for some quick laps | 05:10 |
| nixternal | brb | 05:10 |
| * Fujitsu does so. | 05:10 | |
| * persia is amused at the separation of roles between system administrators and applications administrators, and notes that some "highly secure" installations don't do as well. | 05:12 | |
| crimsun | Fujitsu: thanks. | 05:13 |
| persia | crimsun: Your name also just passed in the sync, so you should be able to recover if you lose it. | 05:13 |
| * Fujitsu notes that sparky is probably a bit too open at the moment, if an unprivileged person like he can grab passwords from the DB. | 05:14 | |
| persia | Ah. I thought you had permissions. In that case, there is an issue. | 05:14 |
| Fujitsu | My account on sparky is much the same as any other member of ubuntu-dev. | 05:17 |
| persia | Fujitsu: I see that. Conflicts with MOTD, but that's a different issue. | 05:17 |
| Fujitsu | Indeed. | 05:18 |
| persia | There are only three candidates left on REVU. Someone should find a problem with them, or upload them. Let's get it clear for the new year :) | 05:19 |
| * Fujitsu has a look. | 05:20 | |
| Fujitsu | Aha, I might be able to test inkblot. | 05:23 |
| crimsun | (looking at apt-mark-sync) | 05:23 |
| imbrandon | Fujitsu: you should be able to sync the keyring, any ubuntu-dev can | 05:34 |
| Fujitsu | imbrandon: Ah, is there a sudoers entry for it? | 05:34 |
| persia | imbrandon: don't you need to have the DB admin key? | 05:34 |
| * imbrandon notes he is not really here, just popin in a sec | 05:34 | |
| imbrandon | Fujitsu: yes | 05:34 |
| imbrandon | persia: nope | 05:34 |
| * persia retracts the statement about separation of concerns, and blames poor documentation for the appearance of security | 05:35 | |
| imbrandon | right | 05:35 |
| imbrandon | :) | 05:35 |
| imbrandon | poor docs but its all good, ones sec | 05:35 |
| imbrandon | any member of ubuntu-dev on sparky should be able to run the following ( but its not documented anywhere , yet ) | 05:37 |
| imbrandon | alias keysync='sudo -u revu1 -H /srv/revu-production/bin/revu-key update' | 05:37 |
| imbrandon | ^^ my .bashrc entry | 05:37 |
| imbrandon | persia / Fujitsu ^^ | 05:38 |
| * Fujitsu just added that. | 05:38 | |
| Fujitsu | Thanks. | 05:38 |
| * persia has "revukey" for the alias | 05:38 | |
| imbrandon | :) | 05:39 |
| imbrandon | 21 minutes localtime, almost time for bed, i'm barely makin newyears localtime | 05:40 |
| imbrandon | heh | 05:40 |
| * imbrandon is sooooo tired atm | 05:40 | |
| persia | imbrandon: Have you been awake all day? | 05:41 |
| Fujitsu | Yay, inkblot works. | 05:41 |
| imbrandon | Fujitsu: you seen my Windows XP aka "royale" theme for KDE right ? seen my latest GNOME atrocity ? | 05:41 |
| imbrandon | http://farm3.static.flickr.com/2308/2152618255_ed3e9ba526_o.png | 05:41 |
| imbrandon | persia: yea | 05:41 |
| Fujitsu | Ew. SwiftFox. | 05:42 |
| imbrandon | no , just the icon | 05:42 |
| imbrandon | its epiphany actualy | 05:42 |
| Fujitsu | Ah, good. | 05:42 |
| persia | imbrandon: I don't suppose you'd like to test http://revu.ubuntuwire.com/details.py?package=awn-extras-applets. There's an issue with orig.tar.gz now, but the packaging is nice, and it could use some ubuntu-dev testing. | 05:42 |
| imbrandon | and evolution and gnome term and pigdin , and so on | 05:43 |
| Fujitsu | Wait, aren't you a KDEer? Why are you using the GNOMEest (but best) browser? | 05:43 |
| imbrandon | persia: sure, i run awn as you can see too :) | 05:43 |
| persia | imbrandon: Yep: your screenshot gave it away | 05:43 |
| Fujitsu | persia: I think inkblot looks good. | 05:44 |
| imbrandon | Fujitsu: yea i am using gnome untill hardy release , was a self promis thing to "see the other side" | 05:44 |
| persia | Fujitsu: Don't tell me. Tell REVU, ubuntu-motu@, and LucidFox :) | 05:44 |
| Fujitsu | persia: Was just wondering if you had any objections to its upload. | 05:44 |
| persia | Fujitsu: No. I'd like to see an updated FSF address, but that could also be a bugfix. | 05:45 |
| persia | (or you could update it when uploading) | 05:46 |
| LucidFox | Or I could fix it right now and you would re-approve it. | 05:46 |
| Fujitsu | LucidFox: I was wondering if you were around. | 05:46 |
| LucidFox | Yes, I am :) | 05:47 |
| Fujitsu | LucidFox: Do so, please :) | 05:47 |
| Hobbsee | imbrandon: another traitor, then | 05:47 |
| imbrandon | Fujitsu: despite the icons the apps are ( in order R to L ) : | 05:47 |
| imbrandon | epiphany , evolution, terminal , pidgin, frostwire, audacity, banshee, vmware console, photoshop ( wine ), and a trashcan | 05:47 |
| * persia suspects y'all are just gathering intel for a killer next release | 05:47 | |
| imbrandon | err L to R | 05:48 |
| imbrandon | heh | 05:48 |
| Fujitsu | persia: Heh. | 05:48 |
| imbrandon | persia: heh | 05:48 |
| Fujitsu | nixternal lost to Vista, and (Hobbsee, imbrandon) to GNOME. Tut tut. | 05:48 |
| imbrandon | yea i totaly plan to go back to KDE when hardy releases, 6 months of gnome is enough for me | 05:48 |
| imbrandon | but it has been a nice insight | 05:48 |
| persia | Now taking bids on the last candidate on REVU. Who wants it? | 05:49 |
| imbrandon | and i'll probably keep gnome in a VM , but i'm stickin with my KDE :) | 05:49 |
| imbrandon | i'm touching the awn one if thats what you mean persia | 05:49 |
| nixternal | me lost to Vista? are you insane? | 05:49 |
| wolfger | Happy New Year | 05:50 |
| persia | imbrandon: That one already got rejected, but testing will help it get in next time. | 05:50 |
| nixternal | right now I am using PCBSD | 05:50 |
| imbrandon | persia: k | 05:50 |
| LucidFox | Wait... 51 Franklin St. is the old address? | 05:50 |
| imbrandon | does gnome even compile on BSD ? /me ducks | 05:50 |
| LucidFox | Then what is the new one? | 05:50 |
| nixternal | imbrandon: bah gnome, but bah kde4 on bsd at times | 05:51 |
| * persia rebuilds to encourage lintian to divulge the secrets | 05:51 | |
| imbrandon | someday i need to get used to gimp so i can replace my Photoshop | 05:52 |
| imbrandon | heh | 05:52 |
| crimsun | LucidFox: 59 is the old one. | 05:52 |
| crimsun | (as are a bunch of others) | 05:52 |
| nixternal | Going into the new year, top KDE distro is: Fedora 8 in Linux and PCBSD in Unix, top Gnome Distro: Foresight (just check out Gnome's decision to choose Foresight for their developers), and the winner of best distribution overall goes to.....Kubuntu of course :p | 05:52 |
| persia | ls | 05:53 |
| * imbrandon see many gnome developers using ubunut too | 05:53 | |
| nixternal | imbrandon: you going to SCALE? | 05:54 |
| imbrandon | and kde devs split between SuSE and Kubuntu and Debian, very few in Fedora ( but i must admit they put it all togather nice ) | 05:54 |
| imbrandon | nixternal: i plan to | 05:54 |
| persia | LucidFox: 675 Mass Ave, Cambridge, MA 02139, USA is the old address that causes the complaint. | 05:54 |
| LucidFox | Ah. | 05:54 |
| imbrandon | nixternal: i submitted a talk for it this year | 05:54 |
| nixternal | groovy, I should hopefully be there as well | 05:55 |
| nixternal | working a booth though | 05:55 |
| LucidFox | reuploaded, should be on the way | 05:55 |
| imbrandon | err wait no it was UbuntuLive i have the talk at, not SCALE, but i do plan on going to SCALE | 05:55 |
| crimsun | I'll be sure to heckle both of you. | 05:55 |
| imbrandon | crimsun: hehe :) | 05:56 |
| nixternal | crimsun: I will be wearing 2 shirts, one bright green, and one black with a big K logo on the front :p | 05:56 |
| imbrandon | nixternal: you see i made jorge's 2008 list ? dunno how i managed that one :) | 05:56 |
| crimsun | I'll be wearing the "Rich <3 Vista" tee. | 05:56 |
| nixternal | haha | 05:56 |
| imbrandon | lol | 05:56 |
| imbrandon | i have pics of my wife in my kubuntu shirt i've been meaning to post online, but some i need to "filter" so they dont make it to flickr | 05:57 |
| nixternal | in february, I could be wearing another blue shirt too if all goes well | 05:57 |
| nixternal | I still don't have a *buntu shirt | 05:57 |
| imbrandon | i have one ubuntu and one kubuntu one | 05:57 |
| crimsun | (I don't have either) | 05:58 |
| imbrandon | my ubuntu one is the old old brown one though | 05:58 |
| nixternal | sounds like a pair of underwear to me | 05:58 |
| imbrandon | heh | 05:58 |
| imbrandon | somewhere online Rid*dell's S.O. has some pic's as "Kubuntu Girl" | 06:00 |
| imbrandon | i dont rember where they are | 06:00 |
| LucidFox | http://revu.ubuntuwire.com/details.py?package=inkblot <-- appeared | 06:01 |
| persia | LucidFox: Yes, but REVU is still trying to parse it :) | 06:01 |
| nixternal | imbrandon: happy new year | 06:01 |
| imbrandon | HAPPY NEW YEAR | 06:02 |
| imbrandon | :) | 06:02 |
| lifeless | nixternal: what decision? link? | 06:02 |
| jscinoz | ugh | 06:02 |
| nixternal | lifeless: what decision are you talking about? | 06:02 |
| Fujitsu | REVU doesn't seem to like debdiffing the last two inkblot uploads. | 06:02 |
| lifeless | "16:52 < nixternal> Going into the new year, top KDE distro is: Fedora 8 in Linux and PCBSD in Unix, top Gnome Distro: Foresight (just check out Gnome's decision to choose Foresight for their developers), and the | 06:02 |
| lifeless | winner of best distribution overall goes to.....Kubuntu of course :p | 06:02 |
| lifeless | " | 06:02 |
| jscinoz | im trying to run debuild -S -sa on my package but it complains about many binary files being changed, even fresh from an extract from the orig.tar.gz, any idea? | 06:02 |
| nixternal | lifeless: one sec, I will grab you either 1 link, or a million links, your choice :) | 06:03 |
| persia | LucidFox: I can't see any differences in the new upload... | 06:03 |
| nixternal | http://live.gnome.org/GnomeDeveloperKit | 06:04 |
| nixternal | lifeless: ^^ there is the gnome dev kit website | 06:04 |
| jscinoz | nevermidn fixed it :) | 06:04 |
| LucidFox | Oops. Uploaded the wrong one. | 06:05 |
| Fujitsu | Ah, so REVU isn't broken. | 06:05 |
| persia | nixternal: You want hardware-connected, don't you? | 06:05 |
| LucidFox | no, not REVU | 06:07 |
| LucidFox | it's my fault... reuploading again | 06:07 |
| emgent | happy new yar people! | 06:07 |
| emgent | s/yat/tux/ | 06:07 |
| lifeless | nixternal: thanks | 06:07 |
| emgent | s/yar/tux/ | 06:08 |
| LucidFox | persia> done | 06:11 |
| persia | LucidFox: readvocated | 06:13 |
| * Fujitsu signs. | 06:15 | |
| Fujitsu | Isn't ChangeLog installed as a changelog by default with CDBS, thus making DEB_INSTALL_CHANGELOGS_ALL = ChangeLog redundant? | 06:24 |
| persia | Fujitsu: Unfortunately not. "ChangeLog" isn't one of the strings dh_changelogs pulls by default. | 06:25 |
| persia | Err.. dh_installchangelogs | 06:25 |
| Fujitsu | http://lists.alioth.debian.org/pipermail/build-common-hackers/2007-November/004037.html says otherwise. | 06:25 |
| * Fujitsu looks for other references. | 06:25 | |
| persia | Fujitsu: Maybe. In several of the packages I reviewed today, linda complained about missing changelogs, and that fixed it (when there was an upstream "ChangeLog") | 06:26 |
| Fujitsu | Hm... | 06:26 |
| persia | Reading the dh_installchangelogs manpage, it appears it doesn't install anything without arguments, and DEB_INSTALL_CHANGELOGS_ALL seems to be set to "" if not otherwise defined in /usr/share/cdbs/1/rules/debhelper.mk | 06:29 |
| persia | s/anything/anything from upstream/ | 06:29 |
| Fujitsu | Right, I think we have an old debhelper.mk. | 06:30 |
| Fujitsu | Ours certainly has it empty, but that line in a patch I see from November last year is populated with various filenames, including ChangeLog. | 06:30 |
| persia | Fujitsu: Why? That patch was reported against 0.4.50, which is the version currently in sid, and the version from which we derive. We could maybe apply the patch... | 06:31 |
| Fujitsu | Look at the first hunk. | 06:31 |
| Fujitsu | It's different. | 06:31 |
| persia | Indeed it is. Interesting. | 06:33 |
| persia | Not referenced in the changelog as well. Perhaps it needs an update. | 06:33 |
| persia | Actually, be nice to s/dh_iconcache/dh_icons/ when updating as well. | 06:34 |
| * Fujitsu checks the real 0.4.50. | 06:34 | |
| persia | I suspect it got missed in the merge of the documentation symlink stuff. | 06:35 |
| Fujitsu | Probably, yes. | 06:35 |
| slytherin | A package has 2 debian directory, one in root and one inside contrib directory. Which directory should I use to make my changes? | 06:35 |
| * Fujitsu shall check the ubuntu diff shortly. | 06:35 | |
| persia | slytherin: New package, or update? | 06:36 |
| Fujitsu | slytherin: If you want your changes to do anything, the former. If you want them to be useless cruft, the latter. | 06:36 |
| slytherin | Fujitsu: thanks for the tip. :-) | 06:36 |
| slytherin | persia: update | 06:36 |
| persia | slytherin: Fujitsu is (as usual) correct, but it may be worth verifying that contrib/debian/ is in the upstream tarball, and if so, checking to see if there is already a bug in the BTS about it. It's generally good for the Debian maintainer to ask upstream to not include it (or us, if it's an Ubuntu local package). | 06:38 |
| Fujitsu | persia: Erk, it's deliberate that we exclude the changelogs. | 06:38 |
| persia | Fujitsu: Where does it say that? | 06:39 |
| Fujitsu | See first section of 0.4.49ubuntu3's changelog. | 06:39 |
| Fujitsu | That sounds wrong. | 06:39 |
| persia | That sounds very wrong. | 06:39 |
| Fujitsu | And why the heck wasn't it mentioned in the merge changelog entry? | 06:39 |
| Fujitsu | Too bad if $app looks for its changelog. | 06:40 |
| Fujitsu | I wonder how much space we actually save by not including them. | 06:41 |
| persia | Further, what about the user who is trying to understand a behaviour change and has just installed from the CD somewhere without net access. | 06:41 |
| * persia thinks gzip is good at text files | 06:41 | |
| Fujitsu | They should compress very well, yes. | 06:41 |
| Fujitsu | I recall this being discussed at some point recently. | 06:41 |
| * Fujitsu looks. | 06:41 | |
| jscinoz | hey guys, im going over packages that people left feedback on, i've addressed all the problems but one.. he mentions "close a bug with the initial release" is this suggesting a file a bug on launchpad regarding the creation of this package and close it? | 06:41 |
| persia | jscinoz: Exactly. | 06:42 |
| imbrandon | jscinoz: yes | 06:42 |
| jscinoz | could you link me a bug from someone else who's done the same thing just to see what i should say and such | 06:43 |
| persia | jscinoz: By "close it", include "(LP :#nnnnnn)" in the changelog after "Initial Release" | 06:43 |
| jscinoz | ah | 06:43 |
| imbrandon | (LP: #nnnnnnn) | 06:43 |
| imbrandon | ( small typo but important in the parsing i bet ) | 06:43 |
| Fujitsu | imbrandon: We've got a little way to go before that's necessary, thankfully. | 06:44 |
| persia | jscinoz: https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging is the official list of bugs of that class (that need closing) | 06:44 |
| Fujitsu | (ew, 7-digit bug numbers) | 06:44 |
| persia | imbrandon: You're probably correct. | 06:44 |
| imbrandon | persia: yea i'm the last to nitpick aobut typos hehe, except where a parser is concerned | 06:44 |
| imbrandon | :) | 06:44 |
| * imbrandon makes way too many himself | 06:45 | |
| imbrandon | Fujitsu: i dident count, i just pressed "n" untill it "looked about right" :P | 06:45 |
| imbrandon | one of those nights | 06:45 |
| imbrandon | :) | 06:45 |
| jscinoz | ugh firefox seg faulted >_< | 06:46 |
| jscinoz | again. | 06:46 |
| Fujitsu | persia: I'm sure I recall a discussion about it, but am unable to find it. | 06:46 |
| persia | jscinoz: You might be interested in epiphany, konqueror, or midori | 06:46 |
| imbrandon | epiphany is pretty nice, its growing on me | 06:46 |
| Fujitsu | Even so, it sounds wrong, and I'd like to see stats on how much space it saves. | 06:46 |
| persia | Fujitsu: There likely was one, probably in a Thursday meeting. I still don't like it, and complain about it to packagers. | 06:47 |
| jscinoz | its probably just related to having 200+ tabs open :P | 06:47 |
| persia | It's especially annoying as it only affects CDBS packages, which are a minority. | 06:47 |
| imbrandon | ?? i'm a bit lost | 06:48 |
| Fujitsu | jscinoz: Ah, so you're like me. I always used to end up with well over 250 after a long Firefox session, but since I moved to Epiphany months ago I don't see the counts... | 06:48 |
| imbrandon | what are we talking about ( persia Fujitsu ) | 06:48 |
| persia | imbrandon: cdbs (0.4.49ubuntu3) change to not include upstream changelogs | 06:48 |
| Fujitsu | imbrandon: pitti's upload of cdbs to disable installation of upstream changelogs by default. | 06:48 |
| imbrandon | wha!?! | 06:48 |
| imbrandon | ewww | 06:48 |
| imbrandon | that just sounds ummmm wrong | 06:49 |
| persia | imbrandon: Yes. Hence the discussion. Note that this deviation is not mentioned in the 0.4.50ubuntu1 changelog. | 06:49 |
| Fujitsu | Such a behaviour divergence from Debian sounds iffy, and changelogs are useful. And don't take up any significant amount of space, surely... | 06:49 |
| imbrandon | what about all the apps that put the changelog in the "about box" | 06:49 |
| nenolod | apps put changelog in aboutbox?? | 06:49 |
| persia | imbrandon: They can't use CDBS, or must use DEB_INSTALL_CHANGELOGS_ALL | 06:49 |
| Fujitsu | Thus making people digg excessively to find things. | 06:50 |
| persia | nenolod: Some, yes. | 06:50 |
| Fujitsu | nenolod: That's what I mentioned earlier. | 06:50 |
| imbrandon | nenolod: yea | 06:50 |
| nenolod | what apps? | 06:50 |
| === StevenK_ is now known as StevenK | ||
| nenolod | i've never seen any apps which put the changelog inside the app | 06:50 |
| Fujitsu | Hey StevenK. | 06:50 |
| imbrandon | nenolod: for one any ones i write, but i have seen quite a few | 06:50 |
| * StevenK waves | 06:50 | |
| imbrandon | heya stdin | 06:50 |
| imbrandon | err StevenK | 06:50 |
| imbrandon | damn tab complete | 06:50 |
| Fujitsu | Oh great StevenK, what is your opinion on the matter? | 06:51 |
| StevenK | I don't think it should be the default. | 06:51 |
| persia | StevenK: You're just in time for a historic moment! With your help, REVU can finally be cleared of candidates for the first time in the hardy cycle. http://revu.ubuntuwire.com/details.py?package=hardware-connected is the last awaiting comment | 06:51 |
| Fujitsu | StevenK: `it'? | 06:52 |
| StevenK | I think it should be simple to disable for large upstream changelogs, like Gimp, to save a little space on the CD | 06:52 |
| Fujitsu | Right. | 06:52 |
| jscinoz | persia what should i say for "in what package did you find this bug" | 06:55 |
| persia | jscinoz: Leave it blank | 06:55 |
| jscinoz | can i have just one bug for all 3 packages? | 06:55 |
| jscinoz | since they are just for different components of the same application | 06:55 |
| jscinoz | server, client and data | 06:56 |
| persia | jscinoz: Three packages? I thought you were down to two with the upstream collation of urbanterror and urbanterror-server (and yes) | 06:56 |
| Fujitsu | One bug per source package, and I hope you have but one source package. | 06:56 |
| persia | Fujitsu: No you don't. Game engines should be separate from game data, or everyone has to download 534MB every time a bug is fixed. | 06:57 |
| jscinoz | hmm | 06:57 |
| Fujitsu | persia: Oh, right, it's the abolutely gigantic one. | 06:57 |
| Fujitsu | Sorry. | 06:57 |
| jscinoz | im using the existing packages nexuiz and tremulous as reference, they have three packages, data, client and server | 06:57 |
| jscinoz | and its more than 534mb now :P | 06:58 |
| jscinoz | around 700 O_O | 06:58 |
| persia | jscinoz: Best to break your packages to match upstream (except that -data should be separate), rather than matching other upstreams. | 06:58 |
| jscinoz | hmm | 06:58 |
| persia | That is, break your source packages. You should further split your binary packages, likely into -client, -client-common, -common, -server, and -server-common. | 06:59 |
| jscinoz | also in the source packages for the client and server, i've managed to get get-orig-source to create the orig.tar.gz from the combined upstream and strip out the other one (ie. if server, strip out client and vice versa) | 06:59 |
| jscinoz | >_< | 06:59 |
| persia | jscinoz: Nice work, but don't do that. Use one source to compile both, and split five ways for installation. | 06:59 |
| jscinoz | gah | 06:59 |
| jscinoz | would it be any use to mention that even in the combined zip it still has distinct directories for server and client? | 07:00 |
| jscinoz | the upstream one. | 07:00 |
| persia | jscinoz: Not really. Each "source package" should match one "upstream distribution package". | 07:01 |
| jscinoz | fark.. | 07:01 |
| jscinoz | i have no idea how to do that >_< ie have one source package compile two binary packages. | 07:01 |
| persia | jscinoz: Take a look at the tremulous package: it splits one source into tremulous, tremulous-server, and tremulous-doc. | 07:02 |
| jscinoz | quick regexp question again | 07:09 |
| jscinoz | the data upstream package version is 4.1, but is labled 41 by the server, in my watch file how would i mangle this to add the dot? i tried s/[0-9][0-9/\1./ but that didnt seem to work. | 07:09 |
| StevenK | s/(\d)(\d)/$1.$2/ | 07:10 |
| StevenK | s/\(\d\)\(\d\)/\1.\2/ # for purists. Hi persia! | 07:11 |
| persia | :) | 07:11 |
| jscinoz | thanks | 07:11 |
| persia | Anyway, sed was complaining about \d in earlier testing. How about s/\\d/[0-9]/ | 07:11 |
| jscinoz | hmm the first one seems to work fine :) | 07:12 |
| * Fujitsu gets back to reviewing hardware-connected after the diversion. | 07:13 | |
| persia | Excellent. \d is definitely nicer looking | 07:13 |
| * persia cheers Fujitsu | 07:13 | |
| Fujitsu | I forgot that I'd already started looking at it, as I'd only got into the first hunk of the diff before getting confused. | 07:14 |
| Fujitsu | Aren't Vcs-* fields for packaging, not upstream? | 07:15 |
| persia | Yes. | 07:16 |
| * Fujitsu rejects hardware-connected. | 07:16 | |
| * persia points at http://gitweb.heh.fi/?p=ion/hardware-connected.git;a=tree;f=debian;h=448f9e311aff2b94598a225a78c2d2c5470856d6;hb=ubuntu from the Vcs lini in debian/control | 07:17 | |
| Fujitsu | I don't really like having packaging controlled in a private git repo. | 07:17 |
| persia | Makes sense. Private is a good reason for rejection. | 07:18 |
| persia | Hurrah! No REVU candidates waiting for feedback! | 07:20 |
| AlinuxOS | Happy New Year - C новым годом - გილოცავთ ახალ წელს - Felice Anno Nuovo | 07:20 |
| joejaxx | :) | 07:23 |
| * Fujitsu wonders if we can have packages expiring from REVU after a couple of months or so. | 07:40 | |
| Fujitsu | (those that need work, that is) | 07:40 |
| persia | Fujitsu: I've been archiving everything that hasn't had either an upload or a comment in three months. I suppose I could make that sooner, but didn't have a strong opinion. | 07:41 |
| Fujitsu | The period I picked was quite arbitrary. | 07:43 |
| * Fujitsu is impressed at the second-last email to launchpad-users. | 07:46 | |
| Hobbsee | Fujitsu: seems standard | 07:53 |
| * Hobbsee sighs at cheques, and how that requires actually going near banks | 07:54 | |
| persia | Hobbsee: It doesn't. Post the cheque to your bank, with a note providing the routing code of the account into which to deposit it. | 07:57 |
| StevenK | That sounds too complicated for an Australian bank, sadly. | 07:59 |
| Hobbsee | *far* too complicated. | 07:59 |
| * StevenK crowbars a rails installation onto a server | 07:59 | |
| StevenK | gem needs a better dependancy tracker | 08:01 |
| persia | StevenK: Just package all the gems you want :) | 08:01 |
| * Fujitsu doesn't really like gems, but finds Rails nice. | 08:01 | |
| * persia finds rails slow, annoying, and exceedingly limited, but quick for very simple things. | 08:01 | |
| StevenK | persia: Which has turned into like eight things. No thanks | 08:02 |
| StevenK | Although, I'm very curious why there's a gem called 'cgi_multipart_eof_fix' | 08:02 |
| persia | StevenK: Are you a haml convert yet? | 08:02 |
| StevenK | Considering I don't know what that is, no. :-) | 08:03 |
| persia | Because the rails default handler for multipart can't handle multiple files. | 08:03 |
| StevenK | ... then why not fix rails .... | 08:03 |
| StevenK | I have >200 DVDs, and of course, since I love over-engineering solutions, I had a database and web frontend | 08:04 |
| StevenK | The problem was the web frontend was done in Python by hand. It was messy, crufty and exceedingly fragile. | 08:05 |
| jscinoz | hey persia, i nearly have it done the wayyou said | 08:23 |
| jscinoz | with the one source package making two binary packages. | 08:23 |
| persia | jscinoz: Great! | 08:23 |
| jscinoz | *nearly* :P | 08:23 |
| slytherin | any java packaging experts here? facing a problem with ant and kaffe. | 08:29 |
| man-di | slytherin: I remember a problem | 08:34 |
| slytherin | man-di: which? | 08:34 |
| man-di | slytherin: but I dont remember the solution | 08:34 |
| man-di | slytherin: I think it was when I started using ant 1.7.0 | 08:35 |
| man-di | slytherin: packages started FTPFSing | 08:35 |
| slytherin | man-di: Can you tell your problem in detail? | 08:35 |
| man-di | slytherin: show me your error message and I can help you better | 08:35 |
| man-di | slytherin: it was long ago | 08:35 |
| man-di | slytherin: and its new years mornign... | 08:36 |
| slytherin | man-di: I am getting something like, 'Can not find Kaffe's native2ascii class' | 08:36 |
| man-di | slytherin: something like? | 08:36 |
| slytherin | man-di: I am doing some changes and trying to build again. will let you know in a minute | 08:37 |
| man-di | thats definitely not the problem I had | 08:37 |
| man-di | slytherin: which package is this? | 08:37 |
| man-di | I really wonder who uses native2ascii these days | 08:38 |
| slytherin | freeguide | 08:38 |
| man-di | which version? | 08:39 |
| slytherin | man-di: Here is the error, Couldn't load Kaffe's Native2Ascii class. ant-optional is already a build dependency. | 08:39 |
| slytherin | man-di: freeguide-0.10.6 | 08:39 |
| man-di | here in Debian 0.10.6-1 uses java-gcj-compat-dev for building | 08:40 |
| slytherin | man-di: Do you know the links for debian build logs? | 08:40 |
| man-di | and I remember kaffe had Native2Ascii impl but only the command line tools | 08:40 |
| man-di | slytherin: this is arch:all, buildds build only arch:any in debian | 08:41 |
| slytherin | Yes, kaffe has command line tool and ant-optional provides a wrapper. | 08:41 |
| man-di | what this is looking for is a special class inside the used JDK (kaffe in your case) | 08:42 |
| man-di | just use jav-gcj-compat-dev and be happy, should just work | 08:42 |
| man-di | kaffe should not be used anyway | 08:43 |
| slytherin | man-di: It is not working. That is why there is FTBFS in Ubuntu. :-) | 08:43 |
| man-di | with java-gcj-compat it FTBFSes too? error message? | 08:44 |
| slytherin | man-di: In that case, it tries to find Sun's native2ascii. Looks like ant supports only these two options. There is no support for gcj native2ascii | 08:45 |
| * man-di checks Debian's freeguide | 08:46 | |
| man-di | oh god... | 08:47 |
| man-di | that is the worst java pacaking work I have ever seen | 08:48 |
| man-di | slytherin: its probably best to use sun-java6-jdk or so as build-dependency | 08:50 |
| man-di | slytherin: and PLEASE set JAVA_HOME in debian/rules | 08:50 |
| man-di | I will file an FTPFS bug in debian later today | 08:50 |
| jscinoz | hey guys, i have both the client and server built from the same upstream zip file, however this results in client and server folder in my build directory, how can i modify my rules file to allow for this | 08:51 |
| porthose | Does anyone feel like doing a couple of sync's? If so please see bug #179275 and bug #179277, thank you :) | 08:51 |
| ubotu | Launchpad bug 179275 in ampache "Please sync ampache-3.3.3.5-dfsg1-1 from Debian sid main" [Undecided,New] https://launchpad.net/bugs/179275 | 08:51 |
| ubotu | Launchpad bug 179277 in ampache-themes "Pleas sync ampache-themes-3.3.3.5a-1 from Debian sid main" [Undecided,New] https://launchpad.net/bugs/179277 | 08:51 |
| persia | jscinoz: call dh_install, and read the dh_install man page about splitting the package. | 08:51 |
| slytherin | man-di: Yes, that works. I have already tried that. I just thought I would give a try to kaffe | 08:51 |
| man-di | slytherin: there are some deeper problems in that package | 08:52 |
| jscinoz | persia, having dh_install copy the files to the right locatoin isnt the problem, its the actual compilation | 08:52 |
| jscinoz | ie for server it needs to cd to serverdir, build, and for client it needs to cd to clientdir and build | 08:53 |
| persia | jscinoz: Right. Compilation mixes all the files together. dh_install allows you to pull it apart again. | 08:53 |
| jscinoz | argh | 08:53 |
| jscinoz | no | 08:53 |
| jscinoz | ok. | 08:53 |
| jscinoz | so since there are two binary packages being made | 08:54 |
| slytherin | man-di: How come that package is built in debian? | 08:54 |
| persia | jscinoz: Oh. I understand. Just call (cd server; $(MAKE)) and (cd client; $(MAKE)) | 08:54 |
| jscinoz | hmm.. ok i'll see if it works | 08:54 |
| jscinoz | i thought i tried something like that with no result | 08:54 |
| man-di | slytherin: the developer has SUN JDK installed and that is used on his system for building | 08:54 |
| man-di | slytherin: you can see it when you look at debian/rules | 08:55 |
| man-di | slytherin: no explicit JAVA_HOME set | 08:55 |
| Fujitsu | slytherin: In Debian, the uploader uploads binaries too, so arch: all is never built on buildds. | 08:55 |
| man-di | so the build uses /usr/bin/java... | 08:55 |
| slytherin | damn, this is bad | 08:55 |
| man-di | I know why I dont trust that special person maintaining that package | 08:55 |
| man-di | he is the azurues maintainer in Debian too | 08:56 |
| Fujitsu | Haha. | 08:56 |
| man-di | Fujitsu: I guess you followed that story a bit... ;-) | 08:57 |
| slytherin | what's the story? | 08:59 |
| jscinoz | just started pbuilder, hope it works :) | 08:59 |
| man-di | slytherin: endless problems | 09:00 |
| * man-di needs a biiiiig coffee | 09:00 | |
| jscinoz | this is so strange | 09:01 |
| jscinoz | the build of the data package fails because it cant find a file that ism | 09:01 |
| jscinoz | isn't even referenced in the rules | 09:01 |
| jscinoz | what the hell. its trying to copy a file that isnt mentioned ANYWHERE in debian/rules or anything. | 09:04 |
| slytherin | jscinoz: which package? | 09:04 |
| jscinoz | one im building | 09:05 |
| jscinoz | ah my mistake | 09:06 |
| jscinoz | on the dh_install line | 09:06 |
| jscinoz | it was going up a directory :P | 09:06 |
| slytherin | man-di: I have fixed the FTBFS, where do I upload the debdiff? Add to a bug? | 09:07 |
| persia | slytherin: Adding a debdiff to a bug (and subscribing sponsors) will get it uploaded. (and yes, the sponsors queue has been slow lately) | 09:08 |
| slytherin | persia: I think that was redundant question. :-) | 09:09 |
| slytherin | done | 09:17 |
| ion_ | fujitsu, persia: So, i should upload a version with the Vcs fields removed? (Of course, anyone could clone their own branch of the packaging and work on as an *alternative* to simply unpacking the source package and editing it directly. That would require the knowledge of the existence of the branch, though, thus i originally included the Vcs fields.) | 09:52 |
| persia | ion_: While I can't be sure, I think you'd make Fujitsu happy by having a branch accessible to ~ubuntu-dev on LP. | 09:53 |
| Fujitsu | ion_: One is not meant to edit a package that is maintained in a VCS without also performing the modifications in the VCS. | 09:54 |
| Fujitsu | Having a supposedly-authoritative VCS branch that is not in sync with the real world is a recipe for disaster. | 09:54 |
| ion_ | So... I’ll simply remove the Vcs fields and it’s okay? | 09:54 |
| Fujitsu | That should be OK, yes. | 09:55 |
| persia | Fujitsu: Do you have an opinion on stripping the VCS fields from all the -XubuntuY uploads? | 09:56 |
| persia | (that is, the alioth VCS fields) | 09:56 |
| Fujitsu | They're normally clearly Debian, but it is questionable. | 09:57 |
| persia | The hard part is the >10,000 packages that don't get modified. When using apt-get source, the VCS warning is often incorrect (not that it shouldn't go to alioth, but that updating alioth isn't the best path to updating the package). | 09:59 |
| * minghua hopes we don't end up with XSBC-Original-Vcs-*. | 10:03 | |
| * persia would prefer confirmed uncertainty with occasional mistakes of changes not getting into VCS to XSBC-Original-VCS-* | 10:06 | |
| * Fujitsu wonders why we use XSBC-* at all, and don't just modify Ubuntu dpkg to deal with it sanely. | 10:10 | |
| Fujitsu | That might mean it could be sorted sanely in the SBC, for example. | 10:11 |
| persia | Fujitsu: That was discussed, and rejected. It was considered less of a burden to use XSBC- Also note that the decision to use Original-Maintainer was taken about three weeks before anyone had a solution, and the solution started with people just uploading XSBC- rather than a patch. | 10:11 |
| StevenK | Actually with people uploading X- and '' as well | 10:12 |
| persia | And lots of other things, until geser set us all straight. | 10:12 |
| StevenK | Right | 10:12 |
| persia | Oh, Fujitsu, could you forward the NEW report for inkblot? | 10:20 |
| ion_ | persia, fujitsu: I released the previous snapshot as 0.0.1 and removed the Vcs fields: http://revu.tauware.de/details.py?package=apt-mark-sync, http://revu.tauware.de/details.py?package=hardware-connected | 10:20 |
| persia | ion_: apt-mark-sync is already NEW. It may not be modified until the archive-admins make a determination. | 10:21 |
| * persia archives again | 10:21 | |
| LucidFox | I'm going to prepare interdiff updates for three packages at once... gtk2-engines-qtcurve, kde-style-qtcurve and kde4-style-qtcurve | 10:21 |
| persia | LucidFox: Should they go in together to address the same issue? | 10:22 |
| LucidFox | No, they can be upgraded separately | 10:22 |
| Fujitsu | persia: Sure, I just hadn't seen that being done much lately. | 10:22 |
| persia | LucidFox: OK. Separate bugs then. | 10:22 |
| persia | Fujitsu: Not many things have made it past REVU recently. | 10:22 |
| persia | (and yes, not everyone is following the guidelines) | 10:23 |
| Fujitsu | I assumed it had dropped out of policy at some point, sorry. | 10:23 |
| persia | Fujitsu: No worries. I hadn't heard of it dropping out, but perhaps it wasn't well enough advertised for this cycle. | 10:25 |
| jscinoz | hmm using -X in dh_install excludes parital matches too correct? | 10:27 |
| jscinoz | ie -Xtmp would also exclude .tmp.XXXXXX | 10:28 |
| persia | jscinoz: Yes | 10:29 |
| jscinoz | cheers. | 10:30 |
| jscinoz | nearly done noe | 10:30 |
| jscinoz | now* | 10:30 |
| jscinoz | havnt rebooted my system in nearly 3 weeks now | 10:30 |
| jscinoz | whole thing is slowing down :P | 10:30 |
| jscinoz | with firefox segfaulting, and nautilus hanging | 10:30 |
| jscinoz | :P | 10:30 |
| slytherin | Does anyone apart from me thinks that gcjwebplugin is a redundant package considering existence of gcjwebplugin-4.1 and gcjwebplugin-4.2? | 10:34 |
| jscinoz | hey persia | 10:34 |
| jscinoz | are you emmet.hikory@gmail.com by any chance? | 10:34 |
| persia | slytherin: Consolidation is good. Check compatibility and reverse dependencies. | 10:35 |
| persia | jscinoz: Yes. | 10:35 |
| jscinoz | :D | 10:35 |
| jscinoz | on your coment on http://revu.tauware.de/details.py?package=urbanterror-server what did you mean to say for point 6 | 10:35 |
| jscinoz | it looks like the end of it is missing | 10:35 |
| persia | That is usually the beginning of my complaint about referencing specific versions of the GPL in debian/copyright rather than /usr/share/common-licenses/GPL. My apologies that I failed to complete the sentence. | 10:36 |
| jscinoz | ah | 10:36 |
| jscinoz | :P | 10:37 |
| jscinoz | you mention that again on point 9 too :P | 10:37 |
| jscinoz | so i got the message about linking to the common license file :P | 10:37 |
| persia | jscinoz: Sorry about that. Maybe I meant something else. I did too many reviews today... Don't worry about point 6. | 10:39 |
| jscinoz | alrighty | 10:39 |
| jscinoz | hmm | 10:39 |
| jscinoz | man this is gonna be a bitch to reupload this stuff | 10:40 |
| jscinoz | the upstream developers came out with a new release | 10:40 |
| jscinoz | so the ~500mb of data is now invalid >_< | 10:40 |
| jscinoz | so i get to upload the new 700mb data package >_< | 10:40 |
| persia | jscinoz: Don't feel bad. Two of us have to download it. | 10:41 |
| jscinoz | my isp's rated upload is only 128kbps >_< | 10:41 |
| jscinoz | and thats the max rated | 10:41 |
| man-di | 700mb data package? What insane software is that? | 10:41 |
| jscinoz | so its morelikely around 50kbit | 10:41 |
| jscinoz | urbanterror-data | 10:42 |
| jscinoz | awesome counterstrike like fps, based on ioquake3 | 10:42 |
| jscinoz | and you gotta love australia ISP's for only letting us have around 100gb bandwidth per month | 10:42 |
| * man-di cant see the need for such a package in any distro...well, I'm no gamer | 10:42 | |
| jscinoz | i could blow through that in a week >_< | 10:42 |
| jscinoz | look at tremulous-data and nexuiz-data and prettymuch anything-data | 10:43 |
| jscinoz | they're all huge | 10:43 |
| man-di | jscinoz: huge is okay, but 700mb is terrific | 10:43 |
| jscinoz | blame upstream :P | 10:43 |
| persia | man-di: The issue is that everything "safe" needs to be distributed by the distribution. We'll need to sort things someday, but for a while we're stuck installing everything. | 10:44 |
| Fujitsu | jscinoz: 100GB!? I get 12GB (Optus). | 10:44 |
| joejaxx | :) | 10:44 |
| joejaxx | why do they limit it? | 10:44 |
| jscinoz | im with iinet, on the highest plan | 10:44 |
| man-di | jscinoz: wouldnt a simple installer package have achieved the same goal? | 10:44 |
| jscinoz | telstra :P joejaxx | 10:44 |
| Fujitsu | joejaxx: Because they're Australian ISPs, and Telstra are useless #*(*@#@8NO CARRIER | 10:45 |
| joejaxx | lol | 10:45 |
| persia | joejaxx: International links are supposedly expensive. The more so when controlled by a monopoly. | 10:45 |
| jscinoz | telstra have a monoploy of the international link | 10:45 |
| joejaxx | persia: yeah | 10:45 |
| jscinoz | so they keep the whole country back | 10:45 |
| Fujitsu | Telstra have a monopoly of pretty much every bit of last-mile copper, as well. | 10:45 |
| Fujitsu | And they have been known to retail ADSL plans for less than they wholesale them. | 10:45 |
| jscinoz | the best you can get in aus atm is around 24mbit/1.5mbit, 160gb per month, for equiv of $100US per month | 10:45 |
| joejaxx | jscinoz: wow | 10:46 |
| joejaxx | that is ridiculous | 10:46 |
| jscinoz | north korea has something like 50mbit downstream for whats like $20 per month :P | 10:46 |
| * Fujitsu daren't imagine what persia has. | 10:46 | |
| jscinoz | although google is building a transpacific line to further their goal of world domination | 10:46 |
| * persia needs a new router, because the current one can't handle the bandwidth in the fiber | 10:46 | |
| Fujitsu | Mmmm... Fibre... | 10:47 |
| joejaxx | 15Mbps symmetrical is 55 usd | 10:47 |
| Fujitsu | Our high-speed Telstra fibre at school is 4Mbps symmetric. | 10:47 |
| Fujitsu | It was installed all of 24 months ago. | 10:47 |
| persia | joejaxx: You can't get it that slow here :) | 10:47 |
| joejaxx | persia: lol | 10:47 |
| joejaxx | persia: how much is server co-location there? | 10:48 |
| jscinoz | i hate you persia :P | 10:48 |
| joejaxx | jscinoz: lol! | 10:48 |
| jscinoz | GIVE ME YOUR INTERTUBES! | 10:48 |
| persia | joejaxx: Maybe 40,000 yen a month. | 10:48 |
| jscinoz | oh thats so lame | 10:48 |
| joejaxx | persia: ah ok | 10:48 |
| jscinoz | spent an hour building the packages and... | 10:48 |
| jscinoz | ran out of space on /home | 10:48 |
| jscinoz | gg | 10:48 |
| joejaxx | jscinoz: hey that is better than building Xorg or Open Office to fix a typo | 10:49 |
| jscinoz | :P | 10:50 |
| jscinoz | we need some kind of differential compile lol | 10:50 |
| jscinoz | blasphemy i hear the masses yell | 10:50 |
| Fujitsu | joejaxx: Xorg's not that bad. | 10:50 |
| joejaxx | Fujitsu: yeah | 10:50 |
| jscinoz | tremulous was pretty bad | 10:51 |
| joejaxx | lol | 10:51 |
| jscinoz | when i was messing around with it | 10:51 |
| jscinoz | WINE's not quick either | 10:51 |
| joejaxx | persia: is that for 1-2u? | 10:51 |
| jscinoz | imagine compiling on one of those new skulltrail mobo's | 10:51 |
| jscinoz | with dual quad-core cpuds | 10:51 |
| jscinoz | cpus* | 10:51 |
| jscinoz | and i think each core is 3.2ghz :P | 10:52 |
| joejaxx | LOL it is almost 6am | 10:52 |
| persia | joejaxx: Not sure. I haven't looked in a couple years. 1U I think. | 10:52 |
| joejaxx | ok | 10:52 |
| jscinoz | *compiles openoffice in 5mins* | 10:52 |
| jscinoz | *whips laptop* I command you to compile faster. | 10:55 |
| slytherin | persia: I am a bit confused, gcjwebplugin is present in debian while -4.1 & -4.2 packages are not. Are we deviating too mush from debian? | 10:55 |
| jscinoz | i'll tell you a package that is well overdue for update in the repos... Azureus :P | 10:56 |
| jscinoz | had the broken version since feisty >_< | 10:56 |
| Fujitsu | jscinoz: It is long fixed in Hardy. | 10:57 |
| jscinoz | joy | 10:57 |
| jscinoz | is it a 3.x version now? | 10:57 |
| jscinoz | or the latest 2.5x | 10:57 |
| * jscinoz discovered he had 35gb in ~/.Trash | 10:57 | |
| persia | slytherin: There's no "too much" deviation. It's best we try for the best (and easiest) user experience. The closer we can get to Debian while doing that, the better. | 10:57 |
| LucidFox | Uploaded interdiff for gtk2-engines-qtcurve | 10:58 |
| LucidFox | Since they all have the same upstream version number, may I track all three qtcurve packages in the same bug, or should I file a separate one for each? | 10:59 |
| man-di | slytherin: it got renamed to gappletviewer-4.X | 10:59 |
| slytherin | oh. | 11:00 |
| slytherin | man-di: One more thing. I may be wrong but it is possible that syncing latest java-gcj-compat* packages may fix the FTBFS of freeguide automatically. I will file sync requests with appropriate changelogs. | 11:03 |
| joejaxx | jcastro: haha | 11:03 |
| Fujitsu | jscinoz: It's 2.5.0.4, I believe. It was a deliberate decision. | 11:03 |
| man-di | slytherin: no, java-gcj-compat has nothing to do with the native2ascii implementation in gcj-4.2 | 11:04 |
| jscinoz | better than 2.5.0.1 | 11:07 |
| jscinoz | 2.5.0.1 would segfault on opening torrent details and randomly :P | 11:08 |
| slytherin | man-di: The reason I thought it will is this - http://packages.debian.org/changelogs/pool/main/j/java-gcj-compat/java-gcj-compat_1.0.77-2/changelog#versionversion1.0.76-5 | 11:13 |
| man-di | slytherin: that is the symlink for the binary, *not* the class ant is trying to load | 11:15 |
| man-di | slytherin: ant doesnt use the binary, it uses the direct implementation in the tools.jar of the JDK | 11:16 |
| minghua | Hmm, is there a tool to change Maintainer to XSBC-Original-Maintainer automatically? | 11:32 |
| persia | minghua: in ubuntu-dev-tools (although I find having the text available for X clip easier, personally) | 11:32 |
| minghua | persia: Thanks. | 11:33 |
| === persia changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com | ||
| Kmos | can someone look at this one, bug 179599 ? | 11:52 |
| ubotu | Launchpad bug 179599 in libparse-debianchangelog-perl "[FTBFS] libparse-debianchangelog-perl (1.1.1-1) fails to build in hardy" [Medium,Confirmed] https://launchpad.net/bugs/179599 | 11:52 |
| === [Supremus] is now known as Supremus | ||
| persia | Kmos: Looks reasonable. Why ask for review here? | 11:55 |
| Kmos | persia: daniel and norsetto are in holidays.. :( and where should I ask ? | 11:56 |
| Kmos | :) | 11:56 |
| persia | Kmos: Most people submit to the review queues when they are sure. On the other hand, given your special circumstances, I understand. Anyway, it looks OK, and I'll expect to see it in the reviewers queue once they return from holidays. | 11:57 |
| Kmos | persia: ok, so I'll wait for them.. | 11:57 |
| Kmos | Now, I'm working on gap package.. it also FTBFS because of bashism =( | 11:58 |
| persia | There's an awful lot of that: especially in arch:all packages. I'm becoming more and more of a fan of source-only uploads each day. | 11:58 |
| Kmos | persia: that's a problem.. but we'll fix them and report to debian. | 12:02 |
| persia | Kmos: Yep. Just be sure to test in Debian when reporting a bug in Debian, and demonstrate a Debian bug, rather than just referencing the Ubuntu bug (although the Ubuntu usertags is a good way to keep track). | 12:03 |
| Kmos | persia: I'll be sure.. for example, the maintainer of this one is in launchpad, so i'll subscribe him and he knows what to do =) | 12:04 |
| man-di | Kmos: dont count on that | 12:05 |
| man-di | I for one have a launchpad accont to but only look into launchpad stuff once a month if not less | 12:05 |
| persia | That sometimes works, but due to some early plans for massive Debian integration, all Debian maintainers are in launchpad, but they don't all pay attention, and some can be annoyed. Better to just fix the bug, and if it really affects Debian, open a bug in the BTS. | 12:05 |
| Kmos | man-di: he has an active account, let's have some faith =) hehe | 12:07 |
| man-di | Kmos: as said, mine is active too | 12:07 |
| Kmos | Michael Koch | 12:07 |
| Kmos | I see you somewhere | 12:07 |
| Kmos | :) | 12:08 |
| man-di | common name, we were two with the same name in one class in school | 12:08 |
| Kmos | Some Debian maintainers really don't like Ubuntu.. and don't care for the fixes we do here for their unstable stuff. | 12:08 |
| Kmos | man-di: I born in germany, but not lived their.. so isn't that :) | 12:08 |
| Kmos | hehe | 12:08 |
| man-di | Kmos: you should better care, it will make your merging/syncing work easier | 12:09 |
| man-di | Kmos: and helps everyone | 12:09 |
| Kmos | man-di: I care.. the Debian maintainer are the ones that don't care and answer sometimes really orrogant. | 12:09 |
| Kmos | *maintainers | 12:09 |
| minghua | Ugh. Apport even trackes crashed in pbuilder login (and after much deliberation, tells me the file that crashed is not in the package database...). | 12:35 |
| === nuu is now known as nu | ||
| === nu is now known as nuu | ||
| * minghua forgets -sa again. :-( | 12:57 | |
| zachy | hi, happy new year! | 13:08 |
| jussi01 | hmmm, is it possible to get to the uploads from the old revu? I had an old archived one but i cant seem to find it | 13:38 |
| * minghua thinks it has something to do with the compromise. | 13:43 | |
| persia | jussi01: They are gone. | 13:45 |
| jussi01 | :( | 13:45 |
| persia | jussi01: Which package? | 13:45 |
| * jussi01 cries | 13:45 | |
| jussi01 | persia: gsopcast | 13:45 |
| jussi01 | persia: It was one of my first, and never got through because of a small license issue. | 13:46 |
| jussi01 | brb | 13:47 |
| persia | jussi01: Unfortunately, it appears like I didn't review it. | 13:47 |
| jussi01 | persia: sad. Im going to have a look through my backups on my NAS again, perhaps it is there | 13:48 |
| jussi01 | aha!! | 13:50 |
| jussi01 | found it. now for the questions. | 13:50 |
| ion_ | persia: Would you perhaps consider advocating http://revu.tauware.de/details.py?package=hardware-connected, since http://revu.tauware.de/diff.py?upid1=1100&upid2=1125 are the only changes from the previous version you advocated? Thanks. :-) | 13:50 |
| persia | ion_: Not again today. I'll take another look tomorrow (I'm all reviewed out). | 13:51 |
| ion_ | Alright :-) | 13:51 |
| ion_ | Thanks for your work so far. | 13:51 |
| jussi01 | I have a binary engine file included. However it doesnt have any licensing attached. I have though, an email from the sopcast team that says I may distribute it. How do I go about doing this? | 13:51 |
| persia | jussi01: You really shouldn't. if you really, really, really want to do that, you need to package it perfectly, and wait and watch as people overlook your package in REVU and resubmit whenever people complain about the binary blob (even though there is licensing). Note that the archive-admins also reject based on blobs not built from source in some cases, so you might need several pushes, and external discussion. In short, you don't (or at lea | 13:54 |
| ion_ | don't (or at lea$ | 13:54 |
| jussi01 | persia: please give us the rest ;) | 13:55 |
| * persia dislikes buffers: "...don't (or at least it's very hard)," | 13:56 | |
| jussi01 | persia: go install irssi | 13:56 |
| * jussi01 goes and cries... | 13:56 | |
| geser | jussi01: so this package is i386-only? | 13:57 |
| * persia notes that irssi also has buffers | 13:57 | |
| ion_ | How are buffers related? | 13:57 |
| ion_ | That is, are we thinking of the same buffers? | 13:57 |
| jussi01 | geser: correct | 13:58 |
| persia | ion_: There's a character buffer that blocks undue flooding. Unfortunately, for those inclined to verbosity, these buffers are insufficient for discourse. | 13:59 |
| StevenK | Read as "persia talks an awful lot before pressing Enter, and he hits the IRC line length limit" | 14:00 |
| ion_ | Many clients can split the lines automatically. | 14:01 |
| geser | jussi01: what license does this software have? is it redistributable with the binary blob without source for it? | 14:01 |
| jussi01 | geser: the front end is gpl'd, however the backend is a binary that is freely redistributable, and I have an email saying I can distribute it (as extra verification) | 14:02 |
| ion_ | “You” as in you or as in everyone? | 14:02 |
| jussi01 | ion_: it reads like this. Yes, you can include sopcast software in the ubuntu repository. | 14:03 |
| jussi01 | and you can use this letter as an official authorization for | 14:03 |
| jussi01 | your distribution. Thank you. | 14:04 |
| persia | Isn't there some rule about distribution-specific allowances being considered non-free? | 14:05 |
| geser | persia: does it matter? because of the binary blob it has to go to multiverse nonetheless | 14:07 |
| geser | as long the whole is redistributable | 14:07 |
| minghua | persia: Yes, in DFSG. But also as geser said, it probably doesn't matter. | 14:08 |
| cyberix | persia: Fixed. Was there something else? | 14:11 |
| jussi01 | So it is possible to do? | 14:13 |
| geser | jussi01: the binary blob is inside the same tarball as the gpl code? | 14:16 |
| cyberix | I'm looking after first advocate for my package malbolge. I've fixed all problems that have been brought up. http://revu.tauware.de/details.py?package=malbolge | 14:16 |
| jussi01 | geser: no | 14:17 |
| jussi01 | geser: would I have to package them separately? | 14:18 |
| geser | I guess yes, but I'm no licensing expert | 14:18 |
| persia | cyberix: I'm not performing full reviews right now, but your changelog still doesn't close a bug. | 14:20 |
| cyberix | Oh | 14:22 |
| cyberix | I guess I didn't quite understand. | 14:22 |
| cyberix | I try to find an example | 14:24 |
| geser | cyberix: add "(LP: #xxx)" to your changelog entry (where xxx is the bugnumber) | 14:25 |
| persia | cyberix: http://revu.ubuntuwire.com/revu1-incoming/hardware-connected-0801011120/hardware-connected-0.0.1/debian/changelog | 14:25 |
| === Lure_ is now known as Lure | ||
| === wolfger__ is now known as wolfger | ||
| === Ubulette_ is now known as Ubulette | ||
| === asac_ is now known as asac | ||
| === apachelogger__ is now known as apachelogger | ||
| === DelayLama is now known as DreamThief | ||
| Ubulette | Happy New Year everyone | 15:32 |
| Ubulette | I've updated http://revu.tauware.de/details.py?package=mozilla-devscripts please have a look | 15:34 |
| Ubulette | about mozilla-devscripts, it's a build-dep for pkgs in main, i assume it has to be in main too, right ? | 15:52 |
| StevenK | Ubulette: Right | 15:58 |
| * StevenK ought to debug this 64-bit bug in mpg321 | 16:05 | |
| StevenK | Frame# 32090 [18446744073709529818], Time: 01:07.00 [03:21.85] | 16:05 |
| StevenK | I seriously doubt there is 18,446 trillion frames in my entire mp3 collection, let alone that one mp3 | 16:05 |
| Ubulette | lol | 16:08 |
| StevenK | cd | 16:16 |
| geser | permission denied | 16:23 |
| StevenK | :-P | 16:23 |
| Adri2000 | I'm going to request removal of bmp-alarm and bmp-musepack, as beep-media-player has been removed already. (there are replacements for these two plugins in audacious-plugins-extra for audacious anyway). unless anyone objects. | 16:36 |
| geser | Adri2000: do we have (need?) a transitional package for bmp? | 16:42 |
| Adri2000 | geser: no we don't, neither does Debian. they just removed it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422681 | 16:47 |
| ubotu | Debian bug 422681 in ftp.debian.org "RM: beep-media-player -- RoM; RoQA; abandoned upstream; superseded by bmpx and audacious" [Normal,Open] | 16:47 |
| minghua | If bmp was not installed by default (is it even in main), I'd say transitional package is not necessary. | 16:50 |
| minghua | And what would a transitional package be anyway? | 16:50 |
| txwikinger | transitional would depend on audacious in order to install that instead or something like that | 16:51 |
| minghua | So does audacious provide all features of BMP? And do you need transitional packages for each bmp plugin/extension package as well? | 16:53 |
| minghua | Sounds more trouble made than solved to me. | 16:54 |
| txwikinger | well the other alternative is questions and bug reports by users complaining :) | 16:56 |
| geser | minghua: without a transitional package users having bmp installed will keep it, an totally unmaintained package | 16:57 |
| minghua | geser: I understand that. I don't think there is a good solution other than saying "bmp is abandoned, please use another music player" in documents or release notes, though. | 16:59 |
| RainCT | if a package is in Ubuntu but is not build yet (I know it is because it's ubuntu/+source/x page on LP exists, but it's empty), how can I know what version it is? | 17:29 |
| man-di | RainCT: doesnt rmadison tell about its source version? | 17:31 |
| crimsun | if rmadison doesn't, you'll likely need to look at the NEW queue | 17:31 |
| RainCT | man-di: yes, but only it's version in Debian | 17:32 |
| RainCT | (or at least it says "unstable", so I guess it's Debian) | 17:32 |
| minghua | RainCT: rmadison -u ubuntu foo | 17:32 |
| minghua | (or use a more recent Ubuntu release :-) | 17:33 |
| RainCT | ah, thanks, I never used rmadison before :P. it gives no output though | 17:33 |
| geser | RainCT: did the package enter Ubuntu? | 17:35 |
| crimsun | i.e., if not, look here: https://edge.launchpad.net/ubuntu/hardy/+queue | 17:37 |
| crimsun | s/edge\.// if you're not a member of the LP beta team | 17:37 |
| * RainCT forgot to power on the speakers | 17:45 | |
| RainCT | geser: it isn't in any of the queues | 17:46 |
| RainCT | oh, now there's the changelog in Launchpad | 17:46 |
| Adri2000 | how can I mass-close bug reports on LP? mail? | 17:50 |
| geser | nixternal: Hi, you added libmotif-dev (multiverse) to build-depends for pdfedit (universe). That doesn't work, can it be build with lesstif? | 17:55 |
| RainCT | Adri2000: you could use python-launchpad-bugs, but afaik you still have to close each one individually | 18:03 |
| RainCT | geser: ah no, I entered the wrong URL :P, it's still not there.. https://edge.launchpad.net/ubuntu/+source/lightyears/ | 18:04 |
| geser | RainCT: was it uploaded to Ubuntu? | 18:09 |
| RainCT | geser: I only know that there's a empty LP page for it :/ | 18:10 |
| RainCT | if it wasn't in Ubuntu that URL should give a 404 page | 18:10 |
| geser | I'm not sure if uploads to PPA create those pages too | 18:11 |
| RainCT | ah | 18:11 |
| RainCT | that would explain it :P | 18:12 |
| RainCT | thanks | 18:12 |
| === asac__ is now known as asac | ||
| === jpatrick_ is now known as jpatrick | ||
| Ubulette | RainCT, i just answered your ff3 bug | 18:50 |
| RainCT | Ubulette: I've the latest one from hardy | 18:51 |
| RainCT | Ubulette: when will beta 2 be in hardy? | 18:52 |
| Ubulette | it is ready since nearly 2 weeks | 18:53 |
| Ubulette | once a "paid dev" is back at work, it should be in | 18:54 |
| RainCT | ok, thanks | 18:55 |
| ianm_ | I'm looking for someone to package https://launchpad.net/screen-ruler | 18:57 |
| RainCT | ianm_: I'll look at it :) | 18:58 |
| ianm_ | RainCT: that would be great. please let me know if you need anything | 18:59 |
| ianm_ | RainCT: it depends on these libgtk2-ruby libglade2-ruby libcairo-ruby libgconf2-ruby | 19:00 |
| Ubulette | persia, crimsun: could you please re-check http://revu.tauware.de/details.py?package=mozilla-devscripts ? | 19:14 |
| RainCT | ianm_: I PMed you | 19:18 |
| bddebian | Heya gang | 19:26 |
| geser | Hi bddebian | 19:28 |
| bddebian | Hi geser | 19:28 |
| === cassidy_ is now known as cassidy | ||
| erpo | The gpsd package is 3 versions out of date. Whose job is it to keep the package up to date? | 20:05 |
| imbrandon | erpo: in this case it looks like the debian maintainer hasent updated | 20:06 |
| imbrandon | erpo: depends on the package ( there is a Maintainer: field for questions like this ) | 20:06 |
| geser | erpo: we try to sync with Debian to keep our workload low but can move ahead of Debian if necessary (and someone willing to do the work) | 20:07 |
| erpo | imbrandon: The Maintainer: field says Ubuntu MOTU Developers. Is the "Original-Maintainer:" field always Debian's maintainer? | 20:07 |
| erpo | Also, rather than coming in here and asking each time I see an out-of-date package, how can I find out for myself the reason that the package hasn't been updated? How did you know that the debian maintainer hadn't updated in this case? | 20:08 |
| imbrandon | hrm looking at the package there is no ubunut changes, infact its a sync | 20:08 |
| imbrandon | http://packages.ubuntu.com/hardy/misc/gpsd | 20:09 |
| imbrandon | where are you seeing MOTU ? | 20:09 |
| erpo | apt-cache show gpsd|grep Maintainer | 20:10 |
| imbrandon | there hasent been a ubuntu specific version dapper | 20:10 |
| imbrandon | anyhow in this case since there is no ubuntu changes is how i knew it was because the debian dev hasent updated it, vs us lagging behind in a merge | 20:11 |
| erpo | So, you can tell whether or not it's a straight sync from debian or an ubuntu-specific version by looking at the filenames on the web page? | 20:11 |
| imbrandon | erpo: correct | 20:11 |
| imbrandon | erpo: version numbers tell alot, thats why things are versioned they way they are :) | 20:12 |
| erpo | When Ubuntu does a straight sync from Debian, where do the packages come from? Testing? Unstable? Experimental? | 20:12 |
| imbrandon | unstable | 20:12 |
| erpo | imbrandon: So if I want to get gpsd 2.36 into Ubuntu, I need to find out who maintains the package in Debian Unstable and get them to update. Then Ubuntu will automatically update. | 20:13 |
| geser | imbrandon: for binary packages Maintainer is always mangled | 20:14 |
| imbrandon | erpo that is one way to go about it yes | 20:14 |
| imbrandon | but this late in the cycle i would be looking at updating the ubuntu package directly also | 20:14 |
| pochu | erpo: Not automatically anymore, since we are past DebianImportFreeze | 20:14 |
| imbrandon | pochu: it will automaticly update, just not for hardy :) | 20:14 |
| erpo | pochu: That's a very descriptive term for what is going on. I'm beginning to get a feel for the way Ubuntu releases happen. | 20:15 |
| pochu | imbrandon: but I guess he wants it for Hardy, and not for Hardy+1 ;) | 20:15 |
| pochu | !schedule | 20:15 |
| ubotu | Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases | 20:15 |
| erpo | pochu: Actually, I want it now, but I'll settle for Hardy. | 20:15 |
| erpo | pochu: If I want it in gutsy, should I try to get it into gutsy-backports? Is that how it's done? | 20:16 |
| imbrandon | erpo: now isnt an option, you can get it updated for hardy then backpoerted possibly | 20:16 |
| imbrandon | right but it needs to be in hardy before it can be backported | 20:16 |
| erpo | imbrandon: Well, now is always an option if I build it myself ;) | 20:16 |
| erpo | imbrandon: Ok, that's very clear. | 20:17 |
| imbrandon | erpo: sure, but then you wouldent be here :) | 20:17 |
| erpo | heh | 20:17 |
| imbrandon | anyhow, if this was "my goal" i would do the following to ensure it happens this late in the cycle: get ahold of the debian maintainer , ask them to update, if they can get it into debian unstable before feb 1, great, if not then look at getting a MOTU to help you get it directly into hardy and then request a backport to gutsy after that | 20:18 |
| imbrandon | ( hopes it dident get cutoff ) | 20:18 |
| erpo | imbrandon: Nope, it didn't. ("...gutsy after that") | 20:20 |
| imbrandon | if tey do get it in debian then just request a sync | 20:20 |
| imbrandon | but Feature Freeze is feb 14 , so get this done prior to feb 1 | 20:21 |
| imbrandon | to be safe | 20:21 |
| erpo | It looks like hardy is already behind debian unstable. | 20:22 |
| erpo | They have 2.35 and we have 2.34. | 20:22 |
| imbrandon | when was .35 uploaded , likely after debian import freeze | 20:22 |
| erpo | Aha. | 20:23 |
| geser | erpo: quite possible as we stopped autosyncing from Debian during December | 20:23 |
| erpo | 2.36 with the 2008 bug fixed is in Experimental. | 20:23 |
| zorglu_ | q. i got a executable binary, but it is launched by a shell script. so i would like not to have it in the path in order not to confuse the user. any suggestion of where i should put it ? | 20:28 |
| erpo | zorglu_: You could do like firefox and call the binary firefox-bin while calling the shell script firefox. | 20:29 |
| imbrandon | or mono apps do /usr/lib/<app>/executable | 20:30 |
| zorglu_ | erpo: i could but it would still be 'visible' to the user | 20:30 |
| zorglu_ | imbrandon: ok i like this one | 20:30 |
| zorglu_ | thanks both of you :) | 20:30 |
| erpo | Does anyone happen to know how long it takes a package in debian experimental to trickle into debian unstable so that I can request a sync? | 20:32 |
| bddebian | You can request from experimental if you know it works | 20:34 |
| erpo | bddebian: Can I test that by downloading the experimental deb and installing it on my system? | 20:35 |
| erpo | I mean, if my current system uses an unmodified debian package, it stands to reason that the updated package won't need any special modifications. | 20:35 |
| bddebian | Aye but sometimes theres some weird shit in experimental :-) | 20:36 |
| erpo | But that's what I'm looking out for, right? It _should_ work. | 20:37 |
| bddebian | Aye | 20:38 |
| imbrandon | erpo: its best to download the epirmental package and rebuild it for your system ( ubuntu ) and then install it | 20:41 |
| imbrandon | debian is built with a diffrent toolchain etc | 20:42 |
| imbrandon | not a good idea to just install the binarys from there | 20:42 |
| imbrandon | food time brb | 20:42 |
| erpo | imbrandon: So I'll download the source package and build from that. | 20:42 |
| imbrandon | right | 20:42 |
| erpo | Ok, off to play. | 20:45 |
| erpo | Thanks all! | 20:45 |
| psusi | why in the world are init scripts treated as conffiles? | 21:03 |
| ion_ | Some people might want to edit them. | 21:03 |
| imbrandon | probably because they are conf files, and they are in /etc/ | 21:03 |
| psusi | that doesn't neccesarily make them conf files | 21:05 |
| imbrandon | wwwwwwwwwwwhat would you consider them then? they arent data generated by a program | 21:06 |
| psusi | you really aren't supposed to edit them since they are scripts provided by the package maintainer... heck, they very well could be binaries | 21:06 |
| imbrandon | err | 21:06 |
| geser | psusi: isn't e.g. change the boot order also a configuration? | 21:06 |
| psusi | that would be done by renaming the symlink, not editing the file | 21:06 |
| man-di | psusi: why make it complicated when it is simple? | 21:07 |
| psusi | it just seems really odd to still have a boot script around that is just supposed to start some daemon, but may still be there if the daemon is removed | 21:07 |
| psusi | so the script has to test for the existence of said daemon | 21:07 |
| man-di | psusi: when the package is purged the script goes away | 21:08 |
| imbrandon | psusi: purge | 21:08 |
| psusi | yea... but when it isn't... | 21:08 |
| psusi | you have a script laying around still trying to start a removed package | 21:08 |
| psusi | and it complicates the script because now it has to test for the existance of the package | 21:08 |
| psusi | don't want to get rid of any actual configuration files ;) | 21:08 |
| man-di | psusi: the script should check if the binary is avialabloe before trying to start it | 21:08 |
| psusi | that's what I'm talking about | 21:09 |
| man-di | psusi: testing is one line | 21:09 |
| psusi | that seems odd | 21:09 |
| imbrandon | psusi: one line is "complicated" ? | 21:09 |
| man-di | so what is complicated? | 21:09 |
| psusi | moreso than otherwise, yes | 21:09 |
| imbrandon | even if it wasent a conffile it would still be best practice to make sure something was avail before trying to run it | 21:10 |
| imbrandon | so not really | 21:10 |
| man-di | imbrandon: FULL ACK | 21:10 |
| geser | psusi: if you move the init-script to e.g. /lib/initscipts then you need to check if the symlink points to an file before executing it | 21:10 |
| ion_ | Wow. My brain initially parsed that as FU** ALL. :-D | 21:11 |
| psusi | not really... the package would be broken and thus the script SHOULD fail | 21:11 |
| psusi | geser: huh? | 21:11 |
| geser | if you initscripts is outside /etc and you have only the symlinks in /etc and then remove the package (and also the initscript) then you symlink points nowhere | 21:12 |
| psusi | this is so weird... I can not for the life of me figure out how dmraid is installing its init script | 21:12 |
| psusi | update-rc.d is called in postinst and told to remove the script | 21:13 |
| psusi | yet there it sits | 21:13 |
| man-di | psusi: this system was developed over 20 years now, it is okay how it is | 21:14 |
| psusi | ohh... SJR must have removed it... seems he's already modified it in hardy | 21:17 |
| geser | psusi: if I look into the postinst for dmraid 1.0.0.rc13-2ubuntu6, I see in the postinst a block starting with "# Automatically added by dh_installinit | 21:19 |
| geser | " right after the update-rc.d remove call | 21:19 |
| geser | where the symlinks are created | 21:20 |
| psusi | weird... I don't... I just see #DEBHELPER# after that | 21:21 |
| imbrandon | #DEBHELPER# is a subsitution | 21:21 |
| psusi | eh? | 21:21 |
| geser | ah, you look inside the source package, it's placed there by dh_installinit | 21:22 |
| imbrandon | e.g. #DEBHELPER# gets replaced by debhelper on build | 21:22 |
| psusi | ohh, in the binary package you mean that gets replaced? | 21:22 |
| geser | yes | 21:22 |
| psusi | ahhh... and it replaces it with code to install the init script? | 21:22 |
| man-di | psusi: yes | 21:22 |
| psusi | how does it know what priority it should be given? | 21:22 |
| man-di | look into debian/rules | 21:23 |
| geser | #DEBHELPER# inside the postinst (and the other scripts) is only a marker where the different dh_* scripts can put their code (if needed) | 21:23 |
| psusi | aha | 21:23 |
| psusi | I could not figure out how on earth that was being done | 21:24 |
| man-di | psusi: man dh_installinit | 21:25 |
| man-di | psusi: and man debhelper | 21:25 |
| man-di | they describe this | 21:25 |
| === apachelogger_ is now known as apachelogger | ||
| === Skiessl_ is now known as Skiessi | ||
| === nuu is now known as nu[year] | ||
| === nu[year] is now known as nuu | ||
| RainCT | good night | 22:37 |
| === asac_ is now known as asac | ||
| === asac_ is now known as asac | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
