| === Mez|OnAir is now known as Mez | ||
| persia | RAOF: Maybe, but sort the remainder normally, but always before the precedent (but not before anything that would otherwise sort before the precedent) isn't as obvious to some people as it perhaps is to you. | 00:01 |
|---|---|---|
| RAOF | Or maybe I use an imprecise but useful rule of thumb of "anything after & including the ~ is less than any other string, including nothing". | 00:04 |
| persia | RAOF: That could be it, but I'm still not sure "less than nothing" is obvious to non-mathematicians (where "mathematicians" includes lightly dabbling amateurs) | 00:05 |
| * Fujitsu goes by '~' < '', which is I believe the proper rule. | 00:05 | |
| persia | Fujitsu: Yes, it is. | 00:06 |
| norsetto | yes, I think its bed time | 00:21 |
| norsetto | g'night all | 00:21 |
| zul | evening | 00:28 |
| pwnguin | StevenK: your blog is fired. | 00:39 |
| pgquiles | how do I invoke a shell and run a command before "make build" in a CDBS+autotools.mk package? (this is the debian/rules: http://pastebin.ca/811562). I've tried "makebuilddir/packagename::" but it does not work :-/ | 01:10 |
| StevenK | pwnguin: I don't have a blog. | 01:14 |
| LaserJock | but you should | 01:14 |
| LaserJock | so you can get ponies | 01:15 |
| slangasek | fired ponies? | 01:17 |
| zul | blogs are overrated | 01:17 |
| LaserJock | zul: really? they are email 2.0 | 01:18 |
| LaserJock | ;-) | 01:18 |
| zul | meh | 01:18 |
| zul | since when? ;) | 01:18 |
| bddebian | pgquiles: First, stop using CDBS ;-P | 01:19 |
| LaserJock | zul: since like Y2k or something | 01:20 |
| pgquiles | bddebian: annoying, I know. I didn't package it in the first place and I'd like to build a CVS version of the software but CVS version require to run command in a shell before ./configure is invoked :-/ | 01:21 |
| azeem | pgquiles: you could just run that command manually and add the outcome in the .diff.g | 01:21 |
| azeem | z | 01:22 |
| pgquiles | azeem: no, because there are symlinks | 01:22 |
| azeem | like? | 01:23 |
| persia | pgquiles: put it in a makebuilddir/foo:: rule. This runs between unpack and configure: | 01:23 |
| pgquiles | persia: it's not executed, I don't know why | 01:24 |
| bddebian | persia: He said he tried that and it didn't work | 01:24 |
| pgquiles | azeem: like install-sh -> /usr/share/automake-1.9/install-sh | 01:24 |
| azeem | pgquiles: are you running autoreconf? | 01:24 |
| bddebian | Bah, that's dumb | 01:24 |
| azeem | or autogen.sh or something | 01:24 |
| pgquiles | azeem: autogen.sh, yes | 01:24 |
| azeem | there's an option to force a copy instead of a symlink | 01:24 |
| azeem | pgquiles: you might have to change the auto* invocations inside autogen.sh then | 01:25 |
| azeem | if it's not just running autoreconf anyway | 01:25 |
| pgquiles | azeem: I've tried AUTO_UPDATE_ACLOCAL, etc but it fails because of not included .m4 but I don't know how to pass parameters to ACLOCAL with AUTO_UPDATE | 01:25 |
| azeem | isn't AUTO_UPDATE_ACLOCAL deprecated | 01:25 |
| pgquiles | azeem: what do you mean with "you might have to change the auto* invocations inside autogen.sh then"? | 01:26 |
| azeem | pgquiles: what *is* inside autogen.sh? | 01:26 |
| azeem | I can't look into it for you | 01:27 |
| pgquiles | azeem: autopoint --force; shell libtoolize --copy --force; aclocal -I m4 -I gnulib/m4; shell autoheader; automake --add-missing; autoconf | 01:27 |
| azeem | huh, autopoint? | 01:27 |
| pgquiles | from gettext | 01:27 |
| azeem | ah | 01:27 |
| cdm10 | I need some help using dch | 01:27 |
| azeem | well, there's a bunch of programs being run starting with "auto", aren't there? | 01:28 |
| cdm10 | dch -U isn't adding a new release, just a new bulletpoint under my existing one | 01:28 |
| pgquiles | I've tried with the makebuilddir/foo:: and $(shell thecommands) but it didn't work | 01:28 |
| azeem | pgquiles: apparently your trouble is with automake, so see how to invoke automake to copy the missing files rather than generating symlinks | 01:28 |
| pgquiles | azeem: probably, but every single one I found already has ./configure in | 01:28 |
| RAOF_ | pgquiles: | 01:29 |
| azeem | pgquiles: ...being run *by autogen.sh* | 01:29 |
| RAOF_ | pgquiles: Ah, you're trying to generate the (autotools) buildsystem in debian/rules? | 01:29 |
| cdm10 | oh, never mind, got it :) | 01:29 |
| pgquiles | RAOF_: yes, that's it | 01:29 |
| RAOF_ | pgquiles: That's generally not a fun thing to do. | 01:29 |
| azeem | if you use CDBS | 01:29 |
| pgquiles | that's the problem, CDBS | 01:30 |
| pgquiles | my debian/rules usually are only bash scripts which allow me to do everything I want | 01:30 |
| pgquiles | :-/ | 01:30 |
| * persia is certain makebuilddir:: is the solution, and would like to see a build log | 01:30 | |
| azeem | pgquiles: in any case "didn't work" isn't enough information | 01:30 |
| azeem | pgquiles: bash scripts? | 01:30 |
| persia | pgquiles: debian/rules isn't a bash script! 1) it's not bash, 2) it's not shell | 01:30 |
| cdm10 | Ugh, I'm having another problem: (WARNING: Failed to sign .dsc and .changes file) | 01:31 |
| pgquiles | azeem: "didn't work" meaning it's not run. I guess the makebuilddir/foo:: rule I'm adding is queued after the existing rule with the same name. | 01:31 |
| persia | cdm10: You need the identity on your GPG key to exactly match the identify in the last debian changelog entry. | 01:31 |
| cdm10 | It works fine when I build it the first time, but when I increment the version with dch and dpkg-buildpackage it again, it doesn't sign. | 01:31 |
| cdm10 | persia: oh, lemme doublecheck that... | 01:31 |
| azeem | pgquiles: where did you add it in debian/rules? | 01:31 |
| persia | pgquiles: Just to make sure, you7re replacing "foo" with the name of your package, right? | 01:32 |
| pgquiles | azeem: I've tried at the beginning and at the end, but both fail | 01:32 |
| pgquiles | persia: yes :-) | 01:32 |
| cdm10 | persia: ha, it put in caleb@caleb-comp rather than my email address. | 01:32 |
| joejaxx | cdm10: :) | 01:32 |
| persia | azeem: Location in debian/rules doesn't matter. make isn't sequential | 01:32 |
| RAOF__ | Hm. Dear internet: stop sucking. | 01:33 |
| RAOF__ | pgquiles: So, you presumably need to do the autogen stuff because you're packaging a development snapshot, right? | 01:33 |
| LaserJock | cdm10: putting DEBFULLNAME and DEBEMAIL in ~/.bashrc helps with that | 01:34 |
| pgquiles | RAOF__: exactly | 01:34 |
| cdm10 | LaserJock: thanks | 01:34 |
| pgquiles | gotcha! | 01:58 |
| pgquiles | I needed to add a debian/stamp-autotools-maintregen-arch:: cd $(DEB_BUILDDIR); sh ./autogen.sh to get makebuilddir/foo:: to work, holy shit | 01:59 |
| persia | Very odd. For most packages, it seems to work without that (although perhaps it's related to autotools magic) | 02:01 |
| pgquiles | and configure and build are run twice :-? | 02:01 |
| pgquiles | autohell might be more accurate :-) | 02:01 |
| RAOF | Hm. Now that telstra's finished poking around at the exchange, maybe the internet will stay up for a few minutes at a time... | 02:11 |
| RAOF | pgquiles: Did you get your autotools working? | 02:11 |
| pgquiles | RAOF: yes, but I needed to add a weird rule | 02:12 |
| RAOF | pgquiles: A better plan may have been to not do the autotools on build. Rather, autotoolise the original tarball. | 02:12 |
| pwnguin | StevenK: ah. ive mistaken you for steven kemp | 02:25 |
| pwnguin | who is on planet debian | 02:25 |
| pwnguin | 12 times | 02:25 |
| azeem | it's Steve Kemp IIRC | 02:30 |
| === tonyy is now known as tonyyarusso | ||
| === tonyy is now known as tonyyarusso | ||
| joejaxx | LaserJock: are you around? :D | 03:51 |
| LaserJock | sure am | 03:52 |
| joejaxx | have time for a pm ? :) | 03:52 |
| LaserJock | sure | 03:52 |
| === asac_ is now known as asac | ||
| LaserJock | it's amazing how much compiling depends on hard drive speed | 04:59 |
| StevenK | No it isn't, of course parts of it will be I/O bound. | 05:00 |
| LaserJock | hmm, I don't get why my laptop would be so slow then | 05:01 |
| LaserJock | my AMD 1800+ compiles I think around twice as fast as my Celeron 2.6GHz laptop | 05:02 |
| StevenK | The Celeron has much less on-die cache | 05:02 |
| persia | LaserJock: RAM size? Cache? | 05:02 |
| RAOF | That's not one of those old celerons with *no* L2 cache? | 05:02 |
| StevenK | It's late P4 if it's 2.6GHz | 05:03 |
| LaserJock | it's 2.8Ghz actually | 05:03 |
| LaserJock | AMD Athlon(tm) XP 1800+ cache size : 256 KB | 05:03 |
| LaserJock | Intel(R) Celeron(R) CPU 2.80GHz cache size : 128 KB | 05:04 |
| LaserJock | the AMD has 1GB of RAM and the Intel 512MB of RAM | 05:05 |
| persia | Those two factors explain most of it. With more RAM you get pagecache advantages, and with more local cache, you've a higher chance of keeping the processor fed. | 05:06 |
| LaserJock | hmm | 05:06 |
| RAOF | And what sort of code? If you go crazy with the templates it shouldn't be too hard to get g++ to thrash in 512mb. | 05:06 |
| LaserJock | that seems crazy to me | 05:06 |
| persia | Especially if you've already loaded 200-300MB with a healthy bit of OS stuff. | 05:07 |
| LaserJock | it doesn't seem to be using up all the RAM most of the time | 05:07 |
| persia | LaserJock: If you're not using all your RAM, your pagecache settings aren't agressive enough. | 05:08 |
| LaserJock | I seem to generally have 150-200MB of RAM free still | 05:09 |
| * RAOF 's laptop with 2GB of ram rarely uses < 95% of the ram | 05:11 | |
| LaserJock | ? | 05:12 |
| StevenK | My amd64 desktop is the same | 05:12 |
| LaserJock | - buffers/cache? | 05:12 |
| * persia takes ~2 hours to reach 2GB in pagecache | 05:12 | |
| RAOF | So unless that free ram count doesn't include the various caches, I'm not sure how you get 200MB unused ram. | 05:12 |
| LaserJock | oh, I thought you were talking about -buffers/cache | 05:12 |
| * TheMuso only has 1GB of ram in his P4, but only ever starts using swap if he is 1) using GNOME+Speech, and 2) is doing a lot of package building, particularly with big packages. | 05:13 | |
| RAOF | Oh, no. | 05:13 |
| LaserJock | I have 50-100MB free if I include cache | 05:13 |
| persia | LaserJock: It's the buffers & cache that make it faster. Without loading the pagecache, you need to read the pages from disk again. For common operations, it's better to have the binaries, libraries, etc. already in RAM. | 05:13 |
| * persia notes that for package building, it's ideal to have enough ram for base system + base cache + simulated build environment + build space | 05:14 | |
| TheMuso | persia: Yeah very true. | 05:14 |
| LaserJock | I"m not using pbuilder | 05:15 |
| LaserJock | just compiling some stuff from svn | 05:15 |
| persia | LaserJock: In that case, you can probably get by with 2-3GB before you start dropping pages, either to swap or clean pages from the disk. | 05:15 |
| LaserJock | I just can't believe my laptop is so slow | 05:15 |
| persia | LaserJock: It's your choice of benchmark. Compare the two systems when encoding video or something. | 05:17 |
| LaserJock | heh, like I ever do that | 05:18 |
| LaserJock | I need to find a test for that, it might be interesting | 05:18 |
| imbrando1 | ... | 05:30 |
| === imbrando1 is now known as imbrandon | ||
| imbrandon | that sucked | 05:32 |
| imbrandon | ice storm + internet + power brownouts == no love for imbrandon | 05:32 |
| LaserJock | bummer | 05:32 |
| imbrandon | yea ... | 05:32 |
| imbrandon | internet all day has sucked and it dont look like its getting better | 05:33 |
| LaserJock | ok, I just did a benchmark with the *small* app I'm building from source: | 05:33 |
| imbrandon | in the next 48 hours | 05:33 |
| LaserJock | AMD 1800+ | 05:33 |
| LaserJock | real 6m7.545s | 05:33 |
| LaserJock | user 5m13.436s | 05:33 |
| LaserJock | sys 0m36.406s | 05:33 |
| LaserJock | Celeron 2.8GHz | 05:33 |
| LaserJock | real 16m12.889s | 05:34 |
| LaserJock | user 12m19.662s | 05:34 |
| LaserJock | sys 0m57.780s | 05:34 |
| LaserJock | so even more than twice as slow :( | 05:34 |
| Fujitsu | This is why we don't eat celery. | 05:34 |
| lifeless | celerons are P4 though; they are borked by design :) | 05:34 |
| Fujitsu | Heh. | 05:34 |
| RAOF | Nice branchy compile code for the huge pipeline! | 05:34 |
| imbrandon | ok i have a small OT question to ask yall, since i love you all so much, i'm setting up a blog ( self hosted wordpress ) for my wife to get her away from myspace hehe, anyhow i dont have the $$ for a domain name so i'm gonna use a no-ip.com domain but i want something semi witty, ideas ? | 05:35 |
| RAOF | lifeless: As long as your code guarantees it will never branch the P4s can be quite fast :P | 05:35 |
| imbrandon | so far we have liked *.isasecret.com *bounceme.net and ummm yea | 05:35 |
| LaserJock | imbrandon: why not wordpress.com | 05:35 |
| imbrandon | LaserJock: so i can install my custom rolled themes and plugins | 05:36 |
| LaserJock | imbrandon: how about imnotbrandon.com | 05:36 |
| imbrandon | lol | 05:36 |
| lifeless | RAOF: yahuh. branch. Lets see. Thats what. IF ?!!!!! | 05:36 |
| imbrandon | LaserJock: hehe yea but i'm trying to work with the free no-ip domains here hehe | 05:36 |
| RAOF | lifeless: You're smart. I'm sure you can write some useful program that has no conditionals :) | 05:36 |
| imbrandon | since i dont have the cash to reg a new domain right now | 05:36 |
| LaserJock | imbrandon: you can't do mrs.imbrandon.com ? :-) | 05:37 |
| imbrandon | ahh nice, lemme ask if she likes that | 05:37 |
| imbrandon | good idea | 05:37 |
| imbrandon | hrm nope ;( | 05:38 |
| LaserJock | slightly egotistically and selfcentered perhaps, but it's funny | 05:38 |
| imbrandon | heh thats what she said, just before "no" heh | 05:38 |
| lifeless | RAOF: I can yes, problem is the software stack. 1) Fix the kernel. 2) Profit. | 05:38 |
| LaserJock | imbrandon: how about thepantswearer.imbrandon.com? | 05:39 |
| imbrandon | seems like all the good *.isasecret.com domains are taken , like life. love. | 05:39 |
| imbrandon | she dont want "brandon" | 05:39 |
| imbrandon | heh | 05:39 |
| mdomsch | stupid question, but, in debian/changelog, what's the field 'gutsy', 'hardy' etc. actually used for? | 05:39 |
| LaserJock | yeah ... I wouldn't either ;-) | 05:39 |
| mdomsch | and does apt ever care? | 05:39 |
| StevenK | imbrandon: kernelbug.isasecret.com | 05:40 |
| imbrandon | mdomsch: the release its built and installed to | 05:40 |
| LaserJock | lol | 05:40 |
| mdomsch | and installed into... | 05:40 |
| imbrandon | apt dont, some buildd env's do | 05:40 |
| mdomsch | ah, that's the key - apt doesn't care | 05:40 |
| LaserJock | I think it's useful more on the developer end than the user end | 05:40 |
| imbrandon | basicly if its not built via soyuz or dak then it dont matter | 05:41 |
| persia | mdomsch: Some of the archive acceptance tools use that to select the build and deployment environment. | 05:41 |
| mdomsch | so that's not my constantly-reinstalls-the-same-package bug | 05:41 |
| imbrandon | correct | 05:41 |
| LaserJock | mdomsch: ahhh | 05:41 |
| LaserJock | mdomsch: is that from a PPA? | 05:41 |
| mdomsch | LaserJock, no, linux.dell.com/repo/dists/cross-distro/dell-firmware/ | 05:41 |
| imbrandon | mdomsch: more likely a depend/confict/replace bug | 05:41 |
| LaserJock | perhaps | 05:42 |
| LaserJock | PPA has a known bug that makes packages with PreDepends or some similar fields to constantly reinstall | 05:42 |
| mdomsch | imbrandon, no conflict/replace | 05:42 |
| mdomsch | and depends looks like: | 05:42 |
| mdomsch | Depends: firmware-addon-dell (>= 0:1.1), firmware-tools (>= 0:1.1) | 05:42 |
| persia | mdomsch: Do you have Provides: ? | 05:43 |
| mdomsch | which I think is sane | 05:43 |
| imbrandon | hrm, can you pastebin the control file ? | 05:43 |
| StevenK | mdomsch: Why a epoch of 0? | 05:43 |
| imbrandon | epoch are evil hehe | 05:43 |
| mdomsch | http://pastebin.domsch.com/18 | 05:43 |
| mdomsch | re epoch: good question, it's unnecessary | 05:44 |
| mdomsch | those packages don't define epochs, so it's safe to remove | 05:44 |
| * persia suspects the epoch is stuck now, if the package is being distributed, as'0' > '' | 05:44 | |
| Fujitsu | Isn't no epoch equal to 0? | 05:44 |
| mdomsch | neither firmware-addon-dell nor firmware-tools define an epoch, so, ok | 05:45 |
| mdomsch | but it's not failing due to missing deps | 05:45 |
| mdomsch | apt/aptitude/synaptic just keep thinking the installed package system-bios-... isn't up-to-date | 05:45 |
| mdomsch | when it clearly is | 05:45 |
| imbrandon | could it be because the epoch is 0 ? e.g is that a legal value ? | 05:46 |
| mdomsch | persia, yes, it can have a Provides line, but it fails both when it does and when it does not | 05:46 |
| persia | mdomsch: Just to make sure, that control file goes through an expansion parser before becoming source, so you're not redefining the set of generated packages at build time, right? | 05:46 |
| persia | mdomsch: No, you likely don't want Provides:, but Provides isn't versioned, which might have been a source of confusion (but isn't) | 05:47 |
| mdomsch | persia, right | 05:47 |
| mdomsch | I _do_ want a provides for some packages | 05:47 |
| mdomsch | packages have binary packages in two forms | 05:47 |
| LaserJock | mdomsch: what does apt-cache policy <package> give? | 05:47 |
| mdomsch | system-bios-ven-0x1028-dev-0xabcd | 05:47 |
| persia | Sure, but if you're not providing either firmware-addon-dell or firmware-tools, that wouldn't be the issue. | 05:48 |
| mdomsch | LaserJock, http://pastebin.domsch.com/19 | 05:48 |
| mdomsch | the other form is system-bios-poweredge-2950, which Provides: system-bios-ven-0x1028-dev-0xabcd | 05:49 |
| mdomsch | which is so I can have packages with pretty names, but programatically look up the package via aptitude install system-bios-ven-0x1028-dev-0xabcd | 05:49 |
| Fujitsu | It's the epoch. | 05:50 |
| LaserJock | mdomsch: I think it's the epoch | 05:50 |
| LaserJock | darn, Fujitsu beat me too it | 05:50 |
| persia | mdomsch: That's it. The candidate apparently has an epoch, but the source isn't defining an epoch. | 05:50 |
| * mdomsch rebuilds w/o the epochs | 05:50 | |
| mdomsch | if that's it, I'm kicking myself | 05:50 |
| Fujitsu | As an empty epoch is equal to 0, so apt's local lists don't have it. | 05:50 |
| imbrandon | i beat you both to it , hehe | 05:51 |
| imbrandon | although i wasent sure and it was a question :) | 05:51 |
| LaserJock | pffft | 05:52 |
| LaserJock | guessing doesn't count ;-) | 05:52 |
| imbrandon | lol | 05:52 |
| Fujitsu | imbrandon: I brought that up first :P | 05:52 |
| LaserJock | I thought it first so there :p | 05:52 |
| imbrandon | hahaha | 05:53 |
| * GoldenPony crushes LaserJock. | 05:54 | |
| * LaserJock expires ... leaving the Golden Ponies unfinished | 05:55 | |
| GoldenPony | Objection! | 05:55 |
| persia | How can something unfinished act in a crushing manner. I suspect GoldenPony just wants more playmates. | 05:55 |
| * GoldenPony grumbles. | 05:56 | |
| * LaserJock notices GoldenPony is limping and decides he has to put'er down :( | 05:58 | |
| mdomsch | LaserJock, Fujitsu, persia, imbrandon you folks are geniuses | 06:05 |
| mdomsch | that was it | 06:05 |
| LaserJock | mdomsch: awesome, easy fix :-) | 06:05 |
| imbrandon | geniuses i doubt ( leaste in my case ) but experince in weirdness with dpkg/apt/etc is a plus :) | 06:06 |
| persia | mdomsch: Don't forget to close your bug :) | 06:06 |
| mdomsch | doing so now :-) | 06:07 |
| * TheMuso has just managed to get Ubuntu's cdimage building system working locally, or least I think so. Still waiting on seeing whether it builds a gutsy i386 image first. | 06:59 | |
| LaserJock | wow, really? | 07:01 |
| TheMuso | LaserJock: Yeah. | 07:01 |
| TheMuso | Its building the image now, but it still may fail, but things are looking good. | 07:01 |
| TheMuso | Once I get hardy i386 mirrored, I'll be able to build my own hardy disks, which will be rather handy. | 07:02 |
| TheMuso | With the exception of the live disks, but thats my next project. | 07:02 |
| === SWAT__ is now known as SWAT | ||
| warp10 | Hi all! | 07:24 |
| superm1 | the live disks are the fun ones though :) | 07:24 |
| sakhi | warp10: hi | 07:27 |
| warp10 | sakhi: hi :) | 07:27 |
| imbrandon | TheMuso: wow, mind sharing how to do that ? | 07:37 |
| imbrandon | i would love to be able to roll my own | 07:37 |
| LaserJock | me too but I think I'm gonna cheat and use Reconstructor or some such on a Desktop CD | 07:38 |
| * imbrandon thinks TheMuso should blog about it | 07:39 | |
| superm1 | imbrandon, as discussed at uds, the plan is to expand the cdimage script to make it more usable for derivatives | 07:41 |
| superm1 | imbrandon, so joejaxx and TheMuso are both working with it | 07:41 |
| imbrandon | nice | 07:42 |
| imbrandon | i'd love to help too, i'd probably not be able to dedicate much time to it, but a bit here and there | 07:42 |
| superm1 | until its ready for general consumption, if you want to see how the mythbuntu disks were rolled for 7.10, i can point you at a bzr tree for that | 07:42 |
| superm1 | it was a custom script that I wrote | 07:42 |
| imbrandon | sure | 07:43 |
| superm1 | https://code.edge.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-livedisk | 07:43 |
| imbrandon | cool thanks | 07:44 |
| imbrandon | bash? | 07:44 |
| superm1 | yeah | 07:44 |
| TheMuso | imbrandon: I'm just playing with it atm, but once I've confirmed that it works properly for hardy as well as gutsy, I'll be starting a fresh, and I'll document everything. | 07:58 |
| TheMuso | imbrandon: And I also have to test-build a live filesystem. | 08:00 |
| dholbach | good morning | 08:07 |
| === greeneggsnospam is now known as jsgotangco | ||
| RAOF | Man, *awesome*. It's possible to trick Rhythmbox's gapless playback engine into playing two songs at once :) | 08:09 |
| soren | How so? Setting the overlap time extremely high? | 08:09 |
| dholbach | hey soren | 08:10 |
| soren | Hi, dholbach! | 08:10 |
| superm1 | imbrandon, next time you file an update to mplayer (even for a rebuild), can you please remember to update the bzr branch | 08:11 |
| Gunner_Sr | persia: I am working on bug #145074 and I see to encountered an error that is similar but different to the bug raised in the first place. | 08:18 |
| ubotu | Launchpad bug 145074 in xgalaga "xgalaga-hyperspace crashed with SIGSEGV" [Medium,In progress] https://launchpad.net/bugs/145074 | 08:18 |
| imbrandon | superm1: i tried but it never fully checked out | 08:23 |
| superm1 | imbrandon, its a huge branch (especially the way its organized now) | 08:24 |
| imbrandon | superm1: is there a good reason the packing isnt kept in a seperate branch like most packing stored on LP ? | 08:29 |
| imbrandon | that would help tremendusly | 08:29 |
| superm1 | imbrandon, yes there is | 08:29 |
| superm1 | the way that its organized, the rc2 upstream version is in its own branch | 08:29 |
| superm1 | and then each release branches from the upstream version | 08:29 |
| superm1 | and adds in the debian/ directory via patches | 08:29 |
| superm1 | directly in bzr patches that is | 08:30 |
| persia | Gunner_Sr: Firstly, you'll likely get better assistance for asking a question generally to the channel. Secondly, if you7ve dicovered a different bug, and can fix that as well, it's better. | 08:30 |
| persia | Err.. And if you wait around, I have a chance to answer. | 08:30 |
| superm1 | imbrandon, this way when there is a new release, the upstream version branch is updated, and then the different release branches merge from it | 08:31 |
| superm1 | and add/remove appropriate patches | 08:31 |
| imbrandon | hrm still seems excessive, no worries, i just wont touch it again, if i cant grab the source in less than 1 hour no need for me to mess with it | 08:32 |
| imbrandon | imho | 08:32 |
| persia | Does it really take that long to checkout the mplayer sources? | 08:34 |
| imbrandon | thats when i cancled it both times i tried to check it out | 08:34 |
| persia | That's no useful then. Is there some tool that allows cleanup of a bzr branch? Otherwise there's no point. | 08:35 |
| imbrandon | well really if the vcs control field is used it should be for the packaing , not the unpacked orig | 08:36 |
| imbrandon | imho | 08:36 |
| persia | Actually, I kinda like having the unpacked orig in the VCS (and think pristine-tar is really cool), but not at that cost in updates. it's not worth an hour. | 08:36 |
| superm1 | imbrandon, siretart can go into an depth discussion about the different "modes" of storing packaging and the advantages of them | 08:37 |
| superm1 | he described them to me at UDS | 08:37 |
| superm1 | s/depth/in\ depth/ | 08:37 |
| imbrandon | eg bzr get http://bazaar.launchpad.net/~kubuntu-members/amarok/debian | 08:37 |
| superm1 | imbrandon, were you using bzr+ssh? | 08:37 |
| superm1 | or http? | 08:37 |
| superm1 | or sftp | 08:37 |
| imbrandon | http branch | 08:37 |
| imbrandon | and ssh_bzr | 08:38 |
| imbrandon | both | 08:38 |
| superm1 | imbrandon, bzr+ssh is significantly faster. | 08:38 |
| superm1 | ok | 08:38 |
| superm1 | i dont recall it taking an hour to checkout though | 08:38 |
| imbrandon | point is the vcs control field is for packing not upstream sources, i;m not saying dont keep them arround in bzr but .... | 08:38 |
| imbrandon | just like svn on alioth | 08:39 |
| superm1 | well the thing is packaging is in that url though too | 08:39 |
| imbrandon | can i co and commit only the packing ? | 08:39 |
| persia | imbrandon: There's different schools of thought on that (and in svn in alioth). Both have strong arguments. | 08:39 |
| superm1 | imbrandon, no you can't, because the patches applied in the ubuntu bzr tree require you to have all the source there still | 08:40 |
| imbrandon | superm1: huh ? | 08:40 |
| === \sh_away is now known as \sh | ||
| imbrandon | the patches are applied to the source in bzr already ? | 08:41 |
| superm1 | imbrandon, there are source changes to things outside the debian directory. traditionally those would be handled by packaging patches in debian/patches | 08:41 |
| superm1 | but the way things are implemented here, they are directly applied | 08:41 |
| imbrandon | eww ok, even more reason not to touch the package again, ok | 08:41 |
| imbrandon | how is one supose to work with whats in the archive and whats in bzr and upstrem and keep i streight from the "outside" ? | 08:42 |
| superm1 | well the idea is to be using feature branches | 08:43 |
| superm1 | so you've got your upstream bzr branch, and the ubuntu package is considered a "feature branch" of the upstream branch | 08:43 |
| superm1 | now say you've got a patch for gnome-screensaver | 08:43 |
| superm1 | you go and branch off the ubuntu feature branch | 08:43 |
| superm1 | apply your patches, test | 08:43 |
| imbrandon | right but that totaly screws regular group maintainers like me, if i had known the source was ptached and repackd i wouldent have touched it | 08:43 |
| superm1 | see how its working | 08:43 |
| superm1 | once you are ready, you merge the two branches back into the ubuntu feature branch | 08:44 |
| imbrandon | sounds like a good project branch on LP, but NOT a good vcs control branch | 08:44 |
| superm1 | well you didn't necessarily need to know exactly how this branch worked for what you were doing, it was just a matter of letting that checkout finish, commit your update and carry on | 08:44 |
| imbrandon | well really it does, i dont want to be uploading code i dont know where came from thats not in the org tarbal | 08:45 |
| imbrandon | so it does matter to me | 08:45 |
| superm1 | well when you did this, did you not see all the code changes in the .diff.gz and wonder what was going on before uploading then? | 08:46 |
| \sh | Fujitsu, do I see it right, that -security stuff is being announce again on -changes? | 08:46 |
| superm1 | not to mention, all of the changes are indeed in the bzr history. you can see who made what changes exactly when and even look at the history of each file | 08:47 |
| imbrandon | superm1: right but i dont care about the source, i wasent updating the source, i was updating the packing | 08:48 |
| imbrandon | its kinda the same thought as to why upstream shouldent include debian/ in the tarbals | 08:48 |
| Fujitsu | \sh: yes, yes, yes, yes, yes, yes_1-1ubuntu1 | 08:48 |
| Fujitsu | \sh: The fix must have been cherrypicked, or Kees has been doing things differently.. | 08:49 |
| persia | superm1: imbrandon has a good point about orig.tar.gz. Look into pristine-tar: if you can't recreate the upstream distributed file, your repo is inherently untrustworthy. | 08:50 |
| superm1 | well if the speed of this process was (is) the issue, i'd say have a checkout of this branch sitting around. i committed your changelog entry just now, it took less then 5 seconds to push up, so things are much faster once you've got that checkout there (not to mention the ease of bzr update versus finding the dsc and dget) | 08:50 |
| superm1 | persia, well you can though | 08:50 |
| superm1 | persia, the repo for the orig.tar.gz is the other bzr tree | 08:50 |
| superm1 | that this branched from | 08:50 |
| persia | superm1: Do the md5sums match? | 08:51 |
| superm1 | persia, the get-orig-source in mplayer's debian/rules was used to build the upstream branch. it was committed as is from that rule | 08:52 |
| imbrandon | superm1: haveing a bzr checkout of every package in ubuntu localy isnt an option | 08:52 |
| superm1 | so you could do an export of the upstream branch, tar it up and do it an md5sum comparison and they should both match | 08:53 |
| imbrandon | atleaste not for most | 08:53 |
| persia | superm1: Right (which is nice), but get-orig-source only gets run on package update, not on applying a patch or a rebuild (note that I like VCS packaging, I'm just pointing out possible issues). | 08:53 |
| persia | superm1: They won't because of timestamps, etc. | 08:53 |
| superm1 | imbrandon, that's why it makes more sense for folks in motu-media (generally) to be working on packages like this rather than the general MOTU consensus | 08:53 |
| superm1 | persia, i see your point. I might visit adjusting how that get-orig-source rule is done for that reason at some point. | 08:54 |
| superm1 | so that it instead grabs from the bzr tree to build the .orig.tar.gz | 08:54 |
| superm1 | the upstream bzr tree that is | 08:55 |
| Fujitsu | superm1: Upstream has a debian/. | 08:55 |
| persia | superm1: Take a look at pristine-tar. 99% of my stuff is patches to things already in the repos rather than maintenance, but from the docs it looks like it should do the right thing. | 08:55 |
| superm1 | Fujitsu, yeah, so currently that has to be moved to debian_upstream at some point | 08:55 |
| superm1 | its a matter of where that should occur though | 08:56 |
| imbrando1 | ugh | 08:56 |
| imbrando1 | damn connection | 08:56 |
| superm1 | persia, looks interesting. | 08:57 |
| persia | superm1: If I'm reading the docs right, it should mean you can get all the benefits of upstream-code-in-VCS, and still have reliable checksums for verification. | 08:57 |
| imbrando1 | persia: mind reposting the link, i got dissconnected | 09:00 |
| === imbrando1 is now known as imbrandon | ||
| persia | imbrando1: No link: pristine-tar package in hardy | 09:00 |
| imbrandon | ahh ok | 09:00 |
| === Sikon is now known as LucidFox | ||
| imbrandon | superm1: in anycase, thanks for doing the commit for me :) | 09:04 |
| superm1 | no prob. it's a good excuse for me to nab a few more of the mplayer bugs i've been meaning to grab at the same time | 09:04 |
| imbrandon | :) | 09:04 |
| superm1 | well at least in the morning that is. bed for now. night all | 09:05 |
| imbrandon | gnight | 09:05 |
| \sh | moins jonp | 09:15 |
| \sh | jono | 09:15 |
| \sh | i mean | 09:15 |
| jono | heya \sh | 09:15 |
| geser | Hi \sh, jono | 09:16 |
| \sh | jono, are there any recordings of the jam session from UDS? I want to listen to a singing ogra | 09:16 |
| jono | hey geser | 09:16 |
| jono | \sh: not sure | 09:17 |
| \sh | jono, that would be a cool thing...good news everyone, please cheer to the almighty Canonical Allstars Band with their song "Do you know it's Christmas" DeathMetalStyle ,-) | 09:19 |
| jono | haha | 09:19 |
| jono | :) | 09:19 |
| \sh | jono, TBH, you should think about it doing it next time during LinuxTag on Stage...imho this would be something new for the LinuxTag ;) | 09:21 |
| jono | \sh: a gig? | 09:21 |
| \sh | jono, yeah :) | 09:21 |
| jono | \sh: that would be cool :) | 09:22 |
| \sh | jono, wasn't it LUGRadio who thought about the "Ubuntu Song"? "Dum Dum Dum Dee Ubuntu" or something? there was something | 09:23 |
| jono | \sh: Ubuntu, Ubuntu, They Drink It In The Jungle :) | 09:24 |
| \sh | jono, hmm...what about "Welcome To Ubuntu...Get it 'cause it's free" (music from guns'n'roses "Welcome To The Jungle") | 09:26 |
| jono | haha | 09:26 |
| jono | nice : | 09:26 |
| jono | :) | 09:26 |
| jono | brb | 09:26 |
| \sh | hmmm.... | 09:40 |
| huats | morning everyone | 09:44 |
| \sh | "Take Me Down To The Ubuntu City, where the ground is brown and the community is pretty" | 09:44 |
| Kmos | \sh: hehe | 09:46 |
| Kmos | dh_icons doesn't work for .xpm right | 09:57 |
| Kmos | ? | 09:57 |
| Kmos | dholbach: dh_icons doesn't work for .xpm right | 10:00 |
| Kmos | ? | 10:00 |
| dholbach | Kmos: gtk-update-icon-cache does not work on .xpm files - it's just for icons that are installed into /usr/share/icons | 10:01 |
| Kmos | dholbach: but if they're installed at /usr/share/icons as xpm doesn't work either.. ? | 10:04 |
| dholbach | I'm not sure that GTK's icon cache will return an .xpm file if you ask it for let's say "gtk-dialog-error", size 48 | 10:05 |
| dholbach | you can ask in #ubuntu-desktop | 10:05 |
| dholbach | but I don't believe it makes sense to 1) install .xpm files in /usr/share/icons, 2) invoke dh_icons in the packaging just for that | 10:06 |
| Kmos | dholbach: i'm asking it, because a debian package does exactly that | 10:07 |
| dholbach | Kmos: you can try asking in #ubuntu-desktop | 10:07 |
| Kmos | debian+ubuntu change.. in ubuntu luca falavigna added a dh_icons on it | 10:07 |
| dholbach | especially people like seb128 and lool should know | 10:07 |
| Kmos | thanks | 10:07 |
| dholbach | please check if there aren't any other icons shipped by the package | 10:08 |
| dholbach | if it's only the .xpm in usr/share/icons, it's probably not necessary | 10:08 |
| Kmos | yeah, it's only xpm | 10:08 |
| Kmos | i talked with author also | 10:08 |
| dholbach | best to ask in #ubuntu-desktop then | 10:09 |
| Kmos | :) | 10:09 |
| Kmos | already done | 10:09 |
| Kmos | thanks for help | 10:09 |
| dholbach | no problem | 10:09 |
| Kmos | bug 175508 | 10:09 |
| ubotu | Launchpad bug 175508 in reportbug-ng "reportbug-ng reports bugs to Debian instead of Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/175508 | 10:09 |
| * \sh is bored... | 10:09 | |
| Kmos | that's an interesting one | 10:09 |
| \sh | Kmos, why don't you ask bastian venthur about adding LP support to it? :) | 10:13 |
| pkh | is this the right place to ask questions about getting updated device drivers into the ubuntu kernel, or do I need to go somewhere else? | 10:13 |
| \sh | Kmos, he is in need of devs...read http://blog.venthur.de/2007/12/08/want-to-get-money-for-nothing-and-chicks-for-free-too/ | 10:13 |
| dholbach | pkh: #ubuntu-kernel might be a better place | 10:13 |
| pkh | of course... cheers :) | 10:13 |
| Kmos | \sh: hehe.. everyone needs $$$ :-( | 10:14 |
| Kmos | \sh: that will be cool to have LP support =) | 10:14 |
| \sh | Kmos, go for it | 10:14 |
| SWAT | I need to create a few database tables for a package. When I use mysql in debian/rules it whines about mysql connection errors. Any tips? (I'm using pbuilder/cowbuilder) | 10:17 |
| Fujitsu | SWAT: Why are they needed during build, and not at runtime? | 10:18 |
| SWAT | they're not, they're only needed at runtime, but I want to install them together with the package | 10:20 |
| Fujitsu | debian/rules is only executed during build. You probably want to look into dbconfig-common. | 10:21 |
| SWAT | I will, thanks | 10:22 |
| geser | Hi Hobbsee | 10:34 |
| Hobbsee | hey geser | 10:35 |
| jonnymind | hi | 11:20 |
| === LucidFox is now known as Sikon_Japanese | ||
| === huats is now known as huats_ | ||
| dholbach | hey huats_ | 11:33 |
| huats_ | dholbach: hey | 11:33 |
| huats_ | dholbach: got to go for lunch.... talk to you this afternoon | 11:33 |
| dholbach | huats_: enjoy it! :) | 11:34 |
| persia | Could someone please direct me to an appropriate support forum for issues with dbus in hardy? #ubuntu+1 doesn't seem to exist yet. | 11:34 |
| Fujitsu | persia: #ubuntu+1 has been there for severeal weeks. | 11:35 |
| persia | Fujitsu: Hmm. I guess I had a typo in my first /join. Thanks :) | 11:36 |
| Hobbsee | #ubuntu+1 has existed for several releases. | 11:37 |
| persia | Hobbsee: Yes, it just tends to disappear shortly after the release, and I apparently can't spell, so I got a "No such channel" warning. All sorted now :) | 11:38 |
| Hobbsee | this is true | 11:38 |
| Fujitsu | It is closed until the archive opens. | 11:39 |
| persia | Fujitsu: Thanks. I didn't realise it was tied to such a trackable external event. | 11:39 |
| Hobbsee | Fujitsu: or until it's vaguely usable, anyway | 11:42 |
| === dholbach_ is now known as dholbach | ||
| Fujitsu | It used to be archive opening, at least. | 11:42 |
| mruiz | hi dholbach ... I received a reply from jazzva (he understood the situation and I gave him some tips to continue) | 11:55 |
| mruiz | hi all ! | 11:55 |
| dholbach | mruiz: great | 11:55 |
| dholbach | great you two are working it out | 11:56 |
| mruiz | dholbach, I finished with hardware-monitor conflicts... I have to modify the changelog with the remaining changes | 11:57 |
| dholbach | super | 11:57 |
| === persia changed the topic of #ubuntu-motu to: Ubuntu Masters of the Universe: https://wiki.ubuntu.com/MOTU | Hardy Heron is in active development. | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Go Merging! http://dad.dunnewind.net/universe.php | QA resources from http://qa.ubuntuwire.com | ||
| \sh | Fujitsu, would you like to deal with bug #174133? :) I can't find the time right now to work on it | 11:58 |
| ubotu | Launchpad bug 174133 in rsync "[CVE-2007-6199 and CVE-2007-6200] rsync is vulnerable" [Undecided,Confirmed] https://launchpad.net/bugs/174133 | 11:58 |
| mruiz | dholbach, I'm filling a merge bug against the source-package... wait me a moment | 12:05 |
| dholbach | mruiz: take your time :) | 12:05 |
| mruiz | ups... dholbach I found the merge bug assigned to someone, but the solution isn't correct. I'll add my work there | 12:10 |
| mruiz | dholbach, do you think that we have to recommend the use of DaD to avoid situations like this one? | 12:12 |
| dholbach | mruiz: sure we can advertise it, but I still feel that cases like this will happen again | 12:13 |
| dholbach | it's too easy to miss | 12:13 |
| mruiz | sure... new contributors don't understand the use of some tools | 12:15 |
| slicer | Anyone have time to do a review update of http://revu.tauware.de/details.py?package=mumble ? | 12:17 |
| DaveMorris | slicer: you noticed the lintian and linda errors? | 12:21 |
| * persia encourages everyone to always check the bugs when looking at a merge: in many cases there are a couple easy bugs that can be fixed at the same time, and it allows one to easily see if someone else has made a claim, or provided a (possibly partial) solution. | 12:22 | |
| slicer | DaveMorris: It complains that I use 3.7.3 for standards, which I was told to use. | 12:22 |
| DaveMorris | yeah I jsut noticed that | 12:22 |
| DaveMorris | I was told to use 3.7.2.2 for my package which just got accepted | 12:22 |
| mruiz | thanks persia ;-) | 12:23 |
| slicer | DaveMorris: Well, persia is the one who told me, and he is here.. :) | 12:23 |
| DaveMorris | yeah MOTU's never agree on things ;) | 12:23 |
| persia | slicer: Unfortunately my browser is dead currently. What am I defending? | 12:23 |
| slicer | persia: Using standards: 3.7.3 isntead of 3.7.2.2 | 12:24 |
| DaveMorris | since linda complains that it's too new | 12:24 |
| persia | DaveMorris: We're all likely wrong, and tend to be good at one or two things. By listening to our disputes, it is hoped you will develop an opinion that is based on technical merits :) | 12:24 |
| === \sh is now known as \sh_away | ||
| DaveMorris | W: mumble; 3.7.3 is a newer Standards-Version. This package appears to conform to a newer Standards-Version that has been released. One of us is incorrect. | 12:25 |
| DaveMorris | ^^ is the linda warning | 12:25 |
| StevenK | Linda is | 12:25 |
| persia | slicer: Yep. Debian-policy in hardy is 3.7.3.0, and the fourth digit isn't meaningful. Both lintian and linda need updates on REVU: lintian is ready, but linda will probably be another couple weeks. | 12:25 |
| DaveMorris | persia: is this info documented somewhere? | 12:26 |
| slicer | Ok, then we're all in agreement :) | 12:26 |
| persia | DaveMorris: `rmadison debian-policy` | 12:26 |
| DaveMorris | thnaks | 12:26 |
| persia | DaveMorris: For further information on tracking how linda and lintian compare with standards, it is worth looking at their bug entries on LP and in the Debian BTS. Not all the bugs are correct, but it's often the best guide to see if the tools are mistaken. | 12:28 |
| DaveMorris | slicer: I think you may need to change "is licensed under the GPL, " to "is licensed under the GPL2, " | 12:28 |
| DaveMorris | in debain/copyright | 12:28 |
| DaveMorris | for your packaging licence | 12:30 |
| persia | DaveMorris: Why? GPLv2 and GPLv3 are compatible licenses. | 12:30 |
| DaveMorris | I was informed that I should specify the version of the licence | 12:31 |
| broonie | persia: They're compatible with each other but may not be compatible with other things. | 12:32 |
| persia | broonie: True. I can't see, but I don't remember mumble having issues with GPLv3 connections (although I could be mistaken). | 12:33 |
| broonie | And in any case the thing is to get the licensing information for the package. | 12:33 |
| broonie | Sure, but someone might want to link it with a new library or something. | 12:33 |
| persia | broonie: "packaging license", as in "the Debian packaging is copyright 2007 <packager> and is released under the terms of the GPL" | 12:34 |
| slicer | BTW. Currently, the system-user for murmur is called Murmur (with a capital M) to avoid username clashes. However, this is incompatible with policy for most other distributions, meaning any scripts which reference the user name have to be changed. How bad would it be to simply call the user (and group) "murmur"? | 12:34 |
| persia | slicer: It'd be better to use "murmur", rather than "Murmur". | 12:34 |
| broonie | Ah, right - in that case you at least want to exclude GPL1. | 12:34 |
| persia | broonie: Do you need to specify if you point to /usr/share/common-licenses/GPL? Don't you just get the current newest GPL by default? | 12:35 |
| slicer | persia: Is that "officially" ok? Because I chose Murmur after reading a document somewhere.. hold on. | 12:35 |
| persia | slicer: I won't be able to see the results of the link you're about to post: ask someone else. | 12:35 |
| slicer | persia: No lynx? No telnet? ;) | 12:36 |
| slicer | BTW, about the licensing, the current text is: | 12:37 |
| slicer | The Debian packaging is (C) 2007, Thorvald Natvig <slicer@sourceforge.net> and | 12:37 |
| slicer | is licensed under the GPL, see `/usr/share/common-licenses/GPL-2'. | 12:37 |
| slicer | .. Which, in my mind, seems to clearly indicate GPL-2. But I can change it as I'll change that username anyway :) | 12:37 |
| persia | slicer: My system is fairly broken right now. I'm sorting it, but I'd trust a policy doc over my memory, and don't have my bookmarks to find the counter-example. | 12:37 |
| slicer | persia: The webpage basically says that there is no policy; there should be one, and until there is, here's what everybody else has done. | 12:38 |
| persia | slicer: Ah. That makes sense :) | 12:38 |
| slicer | Is the name GPL2 or GPL-2? | 12:39 |
| broonie | persia: persia I'd say so, if only to ensure clarity (it's clear if the work can be reused under an older version or not just after a new one is released). | 12:40 |
| persia | broonie: OK. Makes sense. | 12:40 |
| persia | slicer: Based on that, you might want to follow DaveMorris' advice. I'd suggest "GPLv2" | 12:41 |
| gpocentek | hello! | 12:49 |
| gpocentek | I'm a bit confused by the freeze for hardy universe, is there a wiki page about that? | 12:50 |
| persia | gpocentek: Which freeze? | 12:51 |
| gpocentek | persia: sorry, "freezes" | 12:52 |
| mruiz | persia, Debian Import freeze | 12:52 |
| gpocentek | it's more general for me | 12:52 |
| gpocentek | I don't remember if we decided to have a NEW freeze sooner than usual for instance | 12:53 |
| persia | gpocentek: Ah. There should be links from HardyReleaseSchedule, but my memory is that we have DIF (which is like it was in the past), FF, which now includes UVF and NPUF, Beta Freeze, and RC Freeze (both of which are like in the past) | 12:53 |
| sakhi_ | kbye | 12:53 |
| persia | So, we hit DIF on the 14th, and need to more carefully evaluate anything brought in from Debian. We hit FF on 14th February, and should just be in bugfix mode (and need UVFe where appropriate). For NPUF, we should try for uploads by end-January to allow the archive-admins time to do NEW processing. | 12:55 |
| frafu | dholbach: FYI: a new version (0.2.8-0ubuntu2) of mousetweaks is in revu (upid 947); please ignore upid 946 as it contained an error in debian/changelog. I have also posted a comment with the changes compared to version 0.2.8-0ubuntu1. http://revu.tauware.de/details.py?upid=947 | 12:55 |
| persia | After Beta, only RC bugs should get fixed, and after RC, all bugfixes should be peer-reviewed and be for RC issues. | 12:55 |
| gpocentek | persia: thanks! this is clearer now :) | 12:55 |
| === Hobbsee_ is now known as Hobbsee | ||
| persia | gpocentek: Sure. There's some email in the archives from pitti explaining the rationale for the change: basically an expanded "we have too many freezes, and should simplify). | 12:56 |
| persia | frafu: Consider urls of the form http://revu.ubuntuwire.com/details.py?package=mousetweaks . These should always point at the latest upload. | 12:57 |
| lionel | persia: the mail on ubuntu-devel-announce was a bit confusing this morning. | 12:59 |
| lionel | but thanks for the explanation :) | 12:59 |
| persia | lionel: I know. Complain to slangasek: he's used to having a single freeze policy for the entire archive (and still does when moonlighting). | 12:59 |
| frafu | persia: thanks for the indication; I will bookmark the url | 13:00 |
| persia | frafu: Test it first: I'm only guessing :) | 13:00 |
| lionel | persia: hehe :). There is a nice sun here ;) | 13:00 |
| frafu | persia: tested and bookmarked :-) | 13:01 |
| huats_ | persia: lionel I can confirm there is a nice sun here also | 13:03 |
| === huats_ is now known as huats | ||
| lionel | hey huats :) | 13:03 |
| huats | hello lionel :) | 13:03 |
| mruiz | dholbach, I need your opinion about the changelog: http://paste.ubuntu-nl.org/47824/ | 13:04 |
| * persia notes that dholbach is often busy, and that mruiz may do well to also ask others for advice | 13:05 | |
| mruiz | persia, sure! I have to interact with the team... ;-) | 13:05 |
| mruiz | then, someone can review the following merge changelog http://paste.ubuntu-nl.org/47824/ ? | 13:06 |
| ScottK | dholbach: What is in your proposal about Kmos that hasn't already been tried? | 13:07 |
| zul | ScottK: string him up lashed and quartered? | 13:09 |
| ScottK | zul: That wasn't dholbach's proposal. | 13:09 |
| zul | oh | 13:10 |
| persia | Ubulette: Would LP work as a prism app? | 13:10 |
| Ubulette | well, sure but my attempts were not convincing as I use LP with tons of tabs (in firefox) and I often use the backward and forward buttons.. which a webapp is not supposed to do. So depends on the way you navigate the website. You can still try, it's as easy as creating a bookmark. | 13:14 |
| persia | Ubulette: So I'd just stick the LP URL in the prism definition dialog? Good point though: LP doesn't work very well without back/forward. Maybe I need to find a better way to work around my issue then. Thanks. | 13:15 |
| Ubulette | persia, yes, url + name, and you get a desktop launcher | 13:16 |
| Ubulette | persia, as I said, some sites are better suited than others to be webapps. LP is not :( Gmail, Greaders, .. are | 13:17 |
| persia | Ubulette: Yep. LP is not. I'm browserless right now, and hoped prism could reduce my pain, but not very much :) Thanks for the explanations though: it's certainly good in cases where it does work. | 13:18 |
| Ubulette | I wish someone will create a css file to make google reader and gmail look like gnome apps :) | 13:19 |
| Ubulette | persia, browserless ? why ? | 13:20 |
| mruiz | persia, can you give me a comment, please? http://paste.ubuntu-nl.org/47827/ | 13:20 |
| persia | Ubulette: Firefox ate my (rather complex) session too many times due to poor support for seamless upgrades. Epiphany is dead due to some dbus confusion (which I'm tracking). Should be sorted in the next few hours, but there's too many reasons to hit LP to not have something open. | 13:21 |
| Ubulette | persia, try firefox3, session support is very good | 13:22 |
| ScottK | persia: Konqueror. | 13:22 |
| Ubulette | or try seamonkey :) | 13:22 |
| Ubulette | or kazehakase | 13:23 |
| persia | Ubulette: That would require me digging out my old session so as not to wipe it. My firefox2 session is precious to me, as I have hopes of getting it back. | 13:23 |
| persia | ScottK: I'm much more likely to go with midori than konqueror, but I may end up down that road... | 13:23 |
| === ember_ is now known as ember | ||
| Ubulette | persia, ff3 uses a different profile. it will just import your existing ff2, but it will not touch it | 13:23 |
| * ScottK doesn't even know what midori is, but likes Konqueror more and more the more he uses it. | 13:24 | |
| persia | Ubulette: "import" != "not touch". | 13:24 |
| persia | ScottK: webkit + bits from konqueror + GTK. | 13:24 |
| ScottK | Hmmmm | 13:24 |
| Ubulette | persia, i wrote that part so i'm sure :) | 13:24 |
| Fujitsu | That sounds like a nasty hybrid... | 13:24 |
| ScottK | I guess you consider GTK a feature, so makes sense. | 13:24 |
| persia | ScottK As time passes, this is becoming less true :) | 13:25 |
| === apachelogger__ is now known as apachelogger | ||
| persia | Fujitsu: It's supposed to be light and sweet, and doesn't have any KDE stuff: just leveraged some Konqueror wrapping stuff to make it clean. | 13:25 |
| ScottK | Ah. Seeing the light. | 13:26 |
| persia | ScottK: It's largely that I have apps that require GNOME, but none that require KDE. I use QT a lot though (and QT exclusively on my laptop). On the other hand, my previous experience with KDE was negative enough to drive me to enlightenment, so there's a high barrier to return (although I understand the last couple major revisions have improved things a bit). | 13:28 |
| apachelogger | persia: libksquirrel updated | 13:28 |
| persia | mruiz: I really don't think "new upstream release" is a correct remaining change for -1ubuntu1. | 13:28 |
| persia | apachelogger: Cool (but 150 minutes late). | 13:29 |
| mruiz | persia, ok... | 13:29 |
| * mruiz fixing an error | 13:29 | |
| apachelogger | meh | 13:29 |
| persia | mruiz: You likely also don't need the rebuild comment, since a merge forces a rebuild. | 13:29 |
| apachelogger | persia: I forgot to upload before I went to bed ;-) | 13:29 |
| Ubulette | persia, comments have been resurrected on revu (for seamonkey) ? | 13:29 |
| mruiz | persia, what's about "Build-Depends: dropped Debian reference to libgtkmm-2.4-dev (>= 2.6.0) due all Ubuntu versions are greater that this value." ? | 13:30 |
| persia | Ubulette: I'm not sure what you mean. If it was archived, an upload unarchives. In either case, I think you've gotten enough review, and would do well to send it to the sponsors queue (as it's just an update). | 13:30 |
| persia | mruiz: Is that change part of the variation from the Debian package? I'm just reviewing the changelog: you'll need to verify that everything mentioned in the changelog also appears in the debdiff against the Debian package, and further, that each of those patches is useful. | 13:31 |
| Ubulette | persia, through a new upgrade bug + debdiff ? | 13:31 |
| persia | Ubulette: I like interdiff better than debdiff, but debdiff works if your get-orig-source doesn't. | 13:32 |
| persia | (interdiff due to new upstream) | 13:32 |
| mruiz | persia, yes... this is a variation between Debian and Ubuntu. | 13:32 |
| persia | mruiz: Then it belongs in the changelog, whereas "new upstream release" and "rebuild" don't show in the debdiff, so they don't belong in the changelog. | 13:33 |
| Ubulette | persia, no new upstream here, I just fixed your stuff, that's why I reposted to REVU. | 13:33 |
| === Sikon_Japanese is now known as LucidFox | ||
| Ubulette | isn't debdiff using interdiff now ? | 13:35 |
| Ubulette | reading the sources, it does | 13:36 |
| persia | Ubulette: Yes, debdiff uses interdiff when it can, but the way it uses interdiff means that it doesn't work when dealing with new upstream versions with new or changed binary blobs. | 13:36 |
| slicer | Er. If there's a package my package doesn't depend on, but which gives enhanced functionality, what's the correct header? | 13:37 |
| broonie | Recommends or Suggests depending on how likely it is that someone would use the enhanced functionality. | 13:38 |
| slicer | Thanks :) | 13:38 |
| ikonia | imbrandon: are you currently awake | 13:39 |
| persia | slicer: Just to expand, use Recommends if it's normal that the other package would be installed, and Suggests if it's useful, but not expected in the typical case. | 13:42 |
| guest22 | Could someone give some advice on choosing between Build-Depends-Indep and Depends in a case not described in the packaging documentation? I'm working on a package which has a number of dependencies which are checked by the source configure script, but are only required at runtime. Are the configure script warnings sufficient justification for making these Build-Depends-Indep, or is Depends okay because the source will build wit | 13:49 |
| guest22 | hout them? | 13:49 |
| guest22 | That seems to have been truncated - the initial part was "Could someone give some advice on choosing between Build-Depends-Indep ..." | 13:49 |
| slicer | persia: I found the relevant policy document. It's definitely a "Suggests". Basically, I need festival for text-to-speech support, but it's not something people will miss. | 13:50 |
| === doko_ is now known as doko | ||
| persia | guest22: If they are just warnings, you can safely ignore them. If configure spits an error, and make dies, you need the b-d-i to get it built. | 13:51 |
| persia | slicer: festival recently got downgraded, in favour of espeak. I don't suppose your app can work with espeak, can it? | 13:52 |
| guest22 | persia: Okay, Depends it is. Thanks. | 13:52 |
| slicer | espeak? I'll check. | 13:52 |
| slicer | First I've heard of it :) | 13:52 |
| slicer | persia: Yes, from what I can see, I should probably switch to espeak, and will do so for 1.1.2. That will be a 10-20 line diff though, so it probably doesn't belong in the packaging for 1.1.1? | 13:54 |
| persia | slicer: Your call. I tend to add patches in packaging with abandon, if that helps distribution integration. When I've a candidate that integrates well, I review the patches, and send some or all of them upstream, generally bundled in manageable feature-specific chunks. | 13:56 |
| slicer | persia: I am the upstream, so I'd be applying this to current SVN (which already has quite a few other differences from 1.1.1) and then copy those files into my mumble-1.1.1 tree which I maintain for this packaging. | 13:57 |
| mruiz | MOTUs, I was building a merged package and I used: debuild -S -sa -v1.4-1ubuntu1 (as the documentation says). I got "parsechangelog/debian: error: -v<since> option specifies most recent version" | 13:57 |
| * persia 's record for lines of patch in the interest of integration is 1584 | 13:57 | |
| persia | mruiz: You want -v$(previous version uploaded to ubuntu) | 13:58 |
| slicer | persia: I thought it was "good form" to keep the .diff.gz as small as possible? If I can, I have a few fixes that will be included in 1.1.2 that I'd like to add to the 1.1.1 package. They're not showstoppers, but they fix minor bugs. | 13:58 |
| persia | slicer: As a long-term goal, there should be no patches to the upstream code (regardless of diff.gz size). As a short-term goal, the package should integrate seamlessly with the distribution. As with many things, there are multiple schools of thought as to how best manage this. | 14:00 |
| ScottK | slicer: I'd suggest that you don't add features, just bug fix cleanup/integration related changes. | 14:00 |
| slicer | Is there an easy way to check a binary or library and see which symbols it imports from the libraries it links to? In gutsy, libQtCore imports libfreetype and libfontconfig, and there's absolutely no need to. | 14:01 |
| persia | ScottK: Does using the Ubuntu default text-to-speech engine rather than the previous one count as "integration" for 10-20 lines in your book? | 14:01 |
| ScottK | persia: Absolutely. | 14:01 |
| * persia concurs with ScottK's analysis of what to patch | 14:02 | |
| slicer | Okidoki, back to work then. | 14:03 |
| mruiz | thanks persia ;-) | 14:03 |
| persia | mruiz: No problem. Merges are tricky. Personally, I find it easier to do from scratch, rather than relying on MoM or DaD, as it's easier to get the changelog right (because you need to manually investigate all the changes). On the other hand, my method takes longer. | 14:04 |
| mruiz | :) | 14:05 |
| dfiloni | persia: any news about wxwidgets2.8? | 14:10 |
| persia | dfiloni: I haven't seen any bug traffic. Based on the latest state, it should get picked up by a sponsor before too long. I can't personally build it without adjusting my build system, or I'd upload the candidate. | 14:12 |
| dfiloni | persia: ok thanks | 14:12 |
| * persia encourages someone with the ability to build large sources to sponsor bug #133888 | 14:13 | |
| ubotu | Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the 2.8.4.2 release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888 | 14:13 |
| persia | dfiloni: Seeing that, you might want to adjust the title to match the version you've actually submitted :) | 14:13 |
| === _czessi is now known as Czessi | ||
| dholbach | ScottK: what's new about my idea is that Kmos would be under an official surveillance and won't disrupt anybody - my main point is trying to solve the problem generally | 14:13 |
| dholbach | ScottK: it's not a decision as I hopefully made clear, but the proposal I'd like to add to the discussion | 14:14 |
| ScottK | dholbach: From my perspective you aren't asking for things that he's already been asked to do and not done. | 14:14 |
| persia | dholbach: I don't think it's "official surveillance" when you start it not wearing your MC hat (but that's a nitpick) | 14:14 |
| ScottK | dholbach: I understand. That's why I'm here discussing. | 14:14 |
| === apachelogger is now known as apachelogger_ | ||
| dfiloni | persia: done :) | 14:15 |
| dholbach | persia: sorry, maybe I should have been more clear in my email and I'll respond to yours: I'm wearing my MC hat, but I was not presenting a decision with my email | 14:15 |
| dholbach | persia: does that make sense? | 14:15 |
| persia | dholbach: Ah. That makes sense (but wasn't clear to me from the email). | 14:15 |
| dholbach | persia: ok, I'll reply in a sec | 14:15 |
| dholbach | ScottK: I'm not sure I understand your last sentence. What am I asking or not asking for? | 14:16 |
| ScottK | dholbach: When you, who are the Ubuntu CC rep for MOTU, asked him to not do anything without checking with you first and he ignored that after several days, how was that not official. | 14:16 |
| Hobbsee | ScottK: it's not official, as dholbach did not say "and i hearby will smite you with lightning bolts if you do not obey" | 14:16 |
| ScottK | dholbach: I meant to say I understand that there is no decision yet and so I am trying to discuss. | 14:16 |
| persia | dholbach: Essentially I just want to see an official result (pending internal MC deliberation). | 14:17 |
| ScottK | Hobbsee: Yes and I didn't say mother may I either. | 14:17 |
| dholbach | ScottK: to me official is an announced decision by a governance body | 14:17 |
| ScottK | dholbach: OK. I don't see that as any different, but I understand. | 14:17 |
| * persia encourages dholbach to practice the powers of Thor and Zeus in preparation for that possible eventuality | 14:18 | |
| dholbach | persia: scottK urged me to get more input on the whole issue, that's why I thought it prudent to present my view, let others weigh in and then vote on it | 14:18 |
| ScottK | dholbach: I will tell you up front that I will not personally be satisfied with anything that doesn't depend just on his ability and willingness to follow instructions. | 14:18 |
| dholbach | persia: and I think it makes sense to hear other opinions on it as it's not just a "fire and forget" decision, but much more important than that | 14:18 |
| ScottK | persia: Which I did because I don't want this to be me versus Kmos. I think it's something that's negatively impacted the whole community. | 14:19 |
| persia | dholbach: Sure. I agree with that as well: I guess it's a language thing: when I see "not as MC, but personal statement" I assume it's "hats off". I'm basically happy with your email, but didn't see it as an official statement of policy. | 14:19 |
| ScottK | dholbach: From my perspective anything that depends on Kmos doing what he's told/agreed is essentially doing nothing. | 14:19 |
| Hobbsee | FWIW, i feel out of touch, and unsure i want to participate in it anyway, so am withholidng comment. | 14:20 |
| persia | ScottK: Agreed, and thanks for raising it to MC. I'm not sure we have all the structures in place to handle it well, but I'm hoping for the establishment of useful precedents, and would be very pleased by a result that allowed Kmos to contribute positively to the community. | 14:20 |
| Hobbsee | if having people like kmos repeatedly causing trouble is acceptable, then he drags MOTU down to his level...and i'm not sure that i want any part in that. | 14:21 |
| ScottK | persia: I generally agree, but have concluded that that last bit just isn't possible. | 14:21 |
| persia | dfiloni: Just got the bugmail. Thanks. | 14:21 |
| ScottK | Hobbsee: I think that's be a useful comment to the MC ML thread. | 14:21 |
| persia | ScottK: I'm reserving final judgement for now, but that doesn't mean I disagree with you. | 14:21 |
| Hobbsee | ScottK: this requires elloquence not required on irc. | 14:21 |
| ScottK | Hobbsee: True. | 14:21 |
| dholbach | ScottK: I understood that, when I first read your email. What's different is that it's a council decision. "xyz won't listen to the MC anyway." expresses mistrust in the MC's ability to deal with that even before a decision was made. | 14:22 |
| ScottK | Hobbsee: I just want to make sure it's in the record. | 14:22 |
| Hobbsee | ScottK: ah right | 14:22 |
| soren | There's just something really special about misspelling "eloquence" :) | 14:22 |
| DaveMorris | persia: how large is large? I can build it for you and chuck the output to a http server for you if you want | 14:22 |
| === cprov is now known as cprov-lunch | ||
| Hobbsee | soren: yeah, i thought i'd misspelt it. thanks. | 14:22 |
| ScottK | dholbach: That's not my perspective. My perspective is that he has a very well established track record of agreeing to do/not do stuff and then doing the opposite shortly thereafter. | 14:22 |
| soren | Hobbsee: Oh, any time! :) | 14:23 |
| Hobbsee | soren: single l. damn. | 14:23 |
| Hobbsee | soren: you were my personal dict :) | 14:23 |
| persia | DaveMorris: sponsors are supposed to build before uploading, so that doesn't help me. I know it builds (there's a buildlog in the bug), and I know it works, but I won't upload without building it personally. Thanks anyway. | 14:23 |
| ScottK | dholbach: It's nothing specific to the MC. | 14:23 |
| DaveMorris | oh, ok | 14:23 |
| warp10 | Hi all! | 14:23 |
| ScottK | dholbach: I would also ask you to consider that so far the lesson I'm learning from this is that I don't complain enough. | 14:23 |
| dfiloni | hi warp10 :) | 14:24 |
| warp10 | dfiloni: yo! ;) | 14:24 |
| persia | ScottK: You complain plenty. You just didn't complain to MC early enough (not that we had MC in a dispute resolution role when the issues began) | 14:24 |
| dholbach | ScottK: I see this as the precedent for the MC to deal with conflict, that's why I aim for a general solution that adresses the specific concerns. | 14:24 |
| ScottK | dholbach: Additionally, that trying to resolve things in private is pointless. | 14:24 |
| ScottK | persia: Right. | 14:25 |
| ScottK | persia: So no more trying to quietly work things out in private. Everything an official complaint to the MC. | 14:25 |
| dholbach | ScottK: I agreed with you a number of times already: this had been dealt with much earlier - that's why it has gut so ugly now. | 14:25 |
| ScottK | dholbach: Yes. So please do something other than nothing (which is how I read your proposal). | 14:25 |
| dholbach | ... | 14:25 |
| persia | ScottK: I'd suggest addressing things to the individuals concerned in private first, and only escalating to MC if that does not lead to a resolution. No need to push everything to MC. | 14:26 |
| dholbach | ScottK: I won't take your last point. | 14:26 |
| ScottK | dholbach: You're choice. I'm telling you how I see it. | 14:27 |
| persia | ScottK, dholbach: Please wait for me to type something... | 14:27 |
| * ScottK waits. | 14:27 | |
| * Hobbsee demolishes the world. | 14:28 | |
| * soren hands the CoC to Hobbsee | 14:28 | |
| soren | I'm quite sure the CoC doesn't allow planet demolition. | 14:29 |
| persia | Essentially, the current non-official statement of oversight is proposed. When MC comes to a resolution (2 days left in 12), a final decision will be taken. For the current proposal to be acceptable, it should include some indication of what happens if oversight is not sufficient. It's not worth disputing whether oversight is something: "official oversight" is new, if there are consequences. | 14:29 |
| Hobbsee | soren: on the contrary. i'm quite sure it doesn't explicitly forbid it. | 14:29 |
| Fujitsu | Hobbsee: Damn, I wish mako had thought of that. We're doomed! | 14:30 |
| soren | Hobbsee: "If you really want to go a different way, then we encourage you to make a derivative | 14:31 |
| soren | " | 14:31 |
| soren | Hobbsee: You're supposed to fork the world and demolish *that*. | 14:31 |
| mruiz | MOTUs, is a good idea to include the pbuilder log in a merge bug? | 14:31 |
| ScottK | mruiz: Not needed. It's good to say that you built it. | 14:31 |
| mruiz | thanks ScottK | 14:31 |
| persia | mruiz: It's only useful if there is a new change that fixes a FTBFS in a non-obvious way. | 14:31 |
| mruiz | what's about diffstats ? | 14:32 |
| Hobbsee | soren: heh | 14:32 |
| ScottK | persia: I still see that as not resolving things. | 14:32 |
| persia | mruiz: Completely useless. That's possibly useful for new upstreams, when requesting a UVFe, but that's not required until after feature freeze. | 14:33 |
| persia | ScottK: Even with consequences? | 14:33 |
| ScottK | persia: I specifically asked for action to be taken due to past abuse. That essentially says "All is forgiven. Don't mess up again." | 14:33 |
| ScottK | persia: I'm way past that. | 14:33 |
| persia | ScottK: Further, if MC provides "official oversight", and manages the problem so it doesn't affect you, should you care? | 14:33 |
| joejaxx | Good Morning All | 14:34 |
| ScottK | persia: As long as the negative inputs continue, it's a distraction for all of us and hurts Ubuntu. I care. | 14:34 |
| persia | ScottK: Ah. Different philosophy. I'm happy with non-participation or no further mistakes. If you're looking for punishment, I can't debate it. | 14:34 |
| ScottK | Good morning joejaxx. | 14:34 |
| joejaxx | ScottK: :) | 14:34 |
| ScottK | persia: I just don't see there being any realistic chance of the contribution turning positive, so why kick the can down the road. | 14:35 |
| ScottK | persia: It's not a matter of punishment. It's a matter of stopping things. | 14:35 |
| persia | ScottK: You don't need to do so. If MC chooses the proposal as a solution, it's MC's responsibility to ensure no negative impact. If MC is successful, you shouldn't see it. | 14:36 |
| dholbach | ScottK: What I want to address in my proposal is 1) no disruption for others (that was one of your main concerns), 2) have a general solution for cases like this, 3) having surveillance and control over what's going on. | 14:36 |
| ScottK | persia: IMO a sufficient number of "Please do ..." or "Please don't ..." have been ignored that anything that requires voluntary compliance is nothing. | 14:36 |
| * persia agrees with dholbach's ideas, although sistpoty's point about what to do in case of failure is also useful | 14:36 | |
| dholbach | persia: right, that's a topic we should discuss in the thread | 14:37 |
| ScottK | dholbach: As long as he can file bugs, point 1 is not met. | 14:37 |
| Hobbsee | persia: but does ScottK have the confidence in the MC to do their said responsibility? | 14:37 |
| dholbach | ScottK: they will go through the hands of those executing that surveillance | 14:37 |
| persia | ScottK: For lack of confidence in the solution, I can understand that. But to assume that MC will fail before MC starts is unfair to MC. If MC doesn't remove the problem (whether through education or other means), I'll likely be as unhappy as you. | 14:37 |
| ScottK | dholbach: How can you ensure that? | 14:38 |
| persia | Hobbsee: Maybe not, but as it's the first time MC will have done this, I think that's unfair. | 14:38 |
| ScottK | persia: I've presented the problem and am asking them to remove it. | 14:38 |
| ScottK | Hobbsee: My confidence in the MC is not the issue. My confidence in Kmos doing anything he says he will do is the issue. | 14:39 |
| persia | ScottK; I claim the problem is the timesink of trying to see if there is value in any given bug comment, and trying to find them all, rather than the individual involved. I liked your solution, but I'm willing to give MC a chance (but not for an extended duration). | 14:39 |
| * ScottK just doesn't see any point in redoing stuff that's already been tried. | 14:40 | |
| ScottK | And I don't see any difference worth mentioning between dholbach himself asking for stuff and the MC asking for stuff. Unreliable is unreliable no matter who asks. | 14:41 |
| ScottK | If he's only reliable when there is official surveillance on, then as soon as the probation period ends, it'll be back to the same old problem. | 14:42 |
| * persia expects an official MC statement to carry enforceable weight, whereas any given developer is only a developer | 14:42 | |
| ScottK | dholbach: I would like to have a date certain when the MC plans to reach a decision on this so I can be ready to go to the CC. | 14:42 |
| dholbach | ScottK: Whatever will be decided will be an official decision by the governance body and he will have to abide by it. | 14:43 |
| dholbach | ScottK: we can discuss the timeline on the mailing list | 14:43 |
| * persia thought the 12-day rule applies | 14:43 | |
| ScottK | dholbach: I guess the difference is that you're willing to accept the pain of whatever happens when he doesn't. I don't think that's reasonable. | 14:43 |
| ScottK | dholbach: ML is find for schedule. | 14:44 |
| dholbach | no, I'm not accepting anything - can you please calm down | 14:44 |
| ScottK | dholbach: I'm actually pretty calm. | 14:45 |
| dholbach | ScottK: Why don't you reply with all your specific complaints about my proposal to the mailing list, so everybody can read them and reply to them. | 14:45 |
| ScottK | dholbach: OK. I understand you don't want to discuss this further. | 14:46 |
| dholbach | that'll help in the decision process and maybe we can come up with a different solution together | 14:46 |
| dholbach | ScottK: no, I just don't think it makes sense to discuss it here, where 1) other people have no chance to follow up on it, 2) you're accusing me of being responsible for general pain in the project just because I propose something else than you do, 3) also you're accusing me of doing nothing | 14:49 |
| dholbach | That doesn't really help with a solution, does it? | 14:49 |
| persia | dholbach: I don't see #2 in ScottK's comments. | 14:49 |
| ScottK | dholbach: OK. I think you're the one that needs to calm down. | 14:49 |
| ScottK | dholbach: I understand that you think your proposal amounts to doing something. I disagree. | 14:50 |
| dholbach | I spent a lot of time thinking about the problem and talking to various people about it | 14:50 |
| dholbach | OK | 14:50 |
| ScottK | dholbach: I don't doubt your sincerity in trying to solve the problem or the effort you've put into it. I just don't like your proposal. | 14:52 |
| === iceman_ is now known as iceman | ||
| mruiz | MOTUs, I finished with a merge... I added the related debdiffs to the bug and the build with pbuilder was successful. Where do I have to put the packages: REVU or PPA ? | 15:01 |
| ScottK2 | mruiz: Put the debdiff in a bug and subscribe UUS. | 15:03 |
| mruiz | ok | 15:04 |
| mruiz | ScottK2, done | 15:04 |
| persia | mruiz: Just to expand on that, if you submit a debdiff (or an interdiff for an upgrade) the sponsors will be able to reconstruct the package, so you don't need to put the package anywhere. | 15:05 |
| mruiz | :) | 15:05 |
| * pochu didn't know DIF means no more merges... | 15:08 | |
| persia | pochu: It doesn't exactly, it just means that all future merges need a rationale, as in "contains fool feature foo" or "fixes bug bar", and that we should take care to avoid any more transitions. | 15:10 |
| * persia considers sending email to ubuntu-motu@ clarifying the "Freeze" situation for universe | 15:10 | |
| pochu | persia: thanks for the explanation. | 15:10 |
| Hobbsee | hum. do i have any universe merges that i care about, then? | 15:11 |
| Hobbsee | bug #120789 | 15:12 |
| ubotu | Launchpad bug 120789 in libgdal-grass "dependency broken: can't install" [Undecided,Fix released] https://launchpad.net/bugs/120789 | 15:12 |
| mruiz | persia, +1 with the clarification | 15:14 |
| slicer | persia: Do you know if the espeak in hardy is fixed so it doesn't just open /dev/dsp? | 15:16 |
| slicer | persia: Because under gutsy, espeak can't be used concurrently with any other audio program. | 15:16 |
| persia | slicer: No idea. Check with either the audio team or the accessibility team (the latter is more likely to know). | 15:16 |
| slicer | persia: Do they have a #ubuntu-something? | 15:17 |
| persia | slicer: Again, you're asking questions to which I don't have an answer :) | 15:17 |
| slicer | persia: A fool can ask.. ;) | 15:18 |
| pfeels | hey people | 15:19 |
| persia | (and is right to do so, although not prefacing an individual may result in more answers) | 15:19 |
| * slicer found it, it's #ubuntu-accessbility .. Who'd have guessed? ;) | 15:20 | |
| geser | Hobbsee: I guess I can't persuade you to sponsor bug 157668? | 15:20 |
| ubotu | Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20071203-1ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/157668 | 15:20 |
| slicer | persia: I think I'll hold off using espeak by default until I've got that answered. As it is, espeak hogs the audio device, meaning mumble doesn't work. Which is "not good" :) | 15:22 |
| persia | slicer: Right. festival is still in universe, but thanks for trying. | 15:22 |
| slicer | persia: The code is done and in SVN, so it's just to add -DTTS_ESPEAK to switch when/if it gets fixed. | 15:23 |
| persia | slicer: Excellent :) | 15:23 |
| mruiz | how the UUS queue work? | 15:30 |
| geser | mruiz: you subscribe ubuntu-universe-sponsors to your bug and wait for a comment or an upload | 15:30 |
| geser | it gets usually processed in less than a day | 15:30 |
| persia | mruiz: People subscribe bugs to it, and the sponsors look at it, and either comment or upload. The process is explained from a link from the page https://wiki.ubuntu.com/MOTU/Contributing (my apologies I don't remember the exact URL) | 15:30 |
| mruiz | thanks geser and persia :-) | 15:31 |
| * persia notes that UUS seems to be running around 3 days just now, but may be speeding up again once the DIF passes, and sponsors aren't chasing the last merges | 15:32 | |
| slicer | Ok, as the espeak issue is postponed... I've renamed the user Murmur->murmur, added a murmur.defaults and cleaned up the scripts a bit. Does anyone have time to do a review update of http://revu.tauware.de/details.py?package=mumble ? | 15:42 |
| === cprov-lunch is now known as cprov | ||
| bddebian | Heya gang | 15:49 |
| geser | Hi bddebian | 15:49 |
| bddebian | Hi geser | 15:49 |
| jdstrand | \sh_away: I closed bug #173646 based on your comments, but wanted to follow up. I believe that dapper-feisty are not vulnerable as they are 1.2, but did you verify that gutsy isn't (1.3.6)? | 15:52 |
| ubotu | Launchpad bug 173646 in acidbase "[CVE-2007-6156] cross site scripting vulnerability" [Undecided,Fix released] https://launchpad.net/bugs/173646 | 15:52 |
| ScottK | slicer: I'd suggest you pull the new lintian from Hardy and run both source and binary (.deb) against it to see if it notices anything. | 15:53 |
| LucidFox | slomo, are you here? | 15:55 |
| * ScottK cheers Bug 130220 reaching "Fix Committed" status. | 16:01 | |
| ubotu | Launchpad bug 130220 in malone "LP marks bugs fix released multiple times and sends multiple mails when a bug number appears in more than one .changes file" [High,Fix committed] https://launchpad.net/bugs/130220 | 16:01 |
| DaveMorris | Can someone do a revu of my package http://revu.tauware.de/details.py?package=libserial please | 16:04 |
| jeromeg | jdong: hello; are you there ? | 16:06 |
| === \sh_away is now known as \sh | ||
| slicer | ScottK: I'll install hardy in a vm, will help me more easily test. | 16:09 |
| ScottK | slicer: That's good too. The lintian binary should work just fine on Gutsy. | 16:10 |
| persia | ScottK: have you started the backport for .41 yet? | 16:11 |
| ScottK | persia: I requested it yesterday. | 16:11 |
| ScottK | persia: I subscribed you on the but since I knew of your interest. | 16:11 |
| persia | ScottK: I must have been confused then. I saw the sync, but not the backport. Perhaps I missed a message. Thanks. | 16:12 |
| ScottK | persia: It needs someone with Feisty to do a test. | 16:12 |
| ScottK | Maybe it's me that's confused. | 16:12 |
| ScottK | persia: It's Bug 175366 in any case. | 16:13 |
| ubotu | Launchpad bug 175366 in gutsy-backports "Please backport lintian (1.23.41) from Hardy to Gutsy and Feisty" [Undecided,In progress] https://launchpad.net/bugs/175366 | 16:13 |
| * persia doesn't expect many packagers to be using feisty by default. | 16:13 | |
| ScottK | persia: The previous one was backported to Feisty, so ... | 16:14 |
| ScottK | If no one tests is, it won't get done. | 16:14 |
| ScottK | is/it | 16:14 |
| ian_brasil | does anyone know if ftp can mangle the checksum on a dsc file | 16:15 |
| persia | ScottK: Makes sense. feisty only has 3.7.2.2 though, which meant the last one actually applied to feisty. .41 has a new policy level, and I only support the backport to gutsy because not all packagers have upgraded yet (the ride is rough pre-DIF) | 16:15 |
| persia | ian_brasil: Shouldn't do: it's ascii. | 16:15 |
| jeromeg | ScottK: i will test it in a minute | 16:15 |
| persia | ScottK: I am subscribed. My mistake. Thanks. | 16:16 |
| ScottK | jeromeg: Please comment in the bug and mark the Feisty task confirmed after you do. | 16:17 |
| jeromeg | ScottK: yep | 16:17 |
| ian_brasil | Mmm...must be something else then ;)..on an unrelated topic i requested a motu blog some weeks back and i have not heard anything yet (or i have heard back and lost the e-mail) | 16:18 |
| * ian_brasil wonders who to poke | 16:18 | |
| Kopfgeldjaeger | hi. could someone have a look at the newest avidemux package in REVU? the current version is very very very.... very old | 16:20 |
| jonnymind | Hello. I think I have everything streamlined in bug #174470. Can please someone check if there is anything else needed? | 16:26 |
| ubotu | Launchpad bug 174470 in ubuntu "Package for the Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470 | 16:26 |
| jeromeg | ScottK: done, comment added | 16:29 |
| ScottK | jeromeg: Thanks. | 16:29 |
| jeromeg | ScottK: np | 16:30 |
| === \sh is now known as \sh_away | ||
| geser | persia: need we merge till DIF only "Outstanding Merges" or also "Updated Merges"? | 16:37 |
| persia | geser: "Outstanding" definitely, "Updated" by preference. | 16:37 |
| geser | was this similar handled during the dapper cycle? | 16:39 |
| persia | geser: Haven't you been doing this one more release than I anyway :) | 16:39 |
| persia | geser: I think for Dapper, it was a bit more chaotic. My vague recollection was that MoM was first introduced then, and turned off at DIF. | 16:40 |
| persia | I wasn't very involved in Edgy, but for Feisty, we kept chasing merges post DIF as we were really far behind. | 16:40 |
| geser | persia: your first sponsored upload was for dapper while mine for edgy | 16:40 |
| jonnymind | ... later. | 16:40 |
| persia | For gutsy, we did a reasonable job, but there were still a couple "Outstanding Merges" about a month before UVF. | 16:41 |
| persia | This time, I'm hoping we can get all the "Outstanding" merges done in 2007, and actually focus on bugfixing and integration up to feature freeze. | 16:41 |
| * persia notes that Dapper had a couple extra months added to the development cycle, which skewed things oddly | 16:42 | |
| geser | persia: yes, that's what I wanted to ask. During gutsy merges were allowed till UVF, I did expect the same for hardy so I didn't pushed that much doing merges | 16:42 |
| geser | persia: how does this merge "stop" affect new upstream versions? are they allowed to be merged before FF? | 16:42 |
| persia | geser: Please do as many as you can as soon as you can. We really want to get NBS clean in the next few weeks, or it becomes hard to evaluate stability. | 16:42 |
| persia | geser: Sure, if you can convince a member of ~ubuntu-dev (including yourself) that it provides some useful feature for hardy, or fixes some useful bug for hardy. | 16:43 |
| geser | persia: will do, in the last week I tried to get the number of FTBFS down and neglected my merges | 16:43 |
| slicer | Hm. The hardy installer is too large to fit inside the X11 dekstop it starts :) | 16:43 |
| persia | geser: No worries. Your efforts with FTBFS have been great, and are more useful than merges in many cases :) | 16:44 |
| geser | persia: does the same also apply for new upstream syncs after DIF? | 16:44 |
| persia | geser: I don't see any difference between a sync and a merge, except for who does it. I've been watching syncs since Dapper, and as long as I had a sensible Rationale (cool feature, annoying bug), I've never had an archive-admin turn down a universe sync request between DIF and FF (except once, when the "must be ACK'd by a member of ~ubuntu-dev policy came into effect) | 16:45 |
| DaveMorris | hmm someone has just pushed a ppa verison of rhythmbox to revu | 16:45 |
| persia | DaveMorris: That's not right, but at least it gets pushed down the the bottom where it can be safely ignored :) | 16:46 |
| DaveMorris | yeah they prop didn't specify a taregt with dput | 16:46 |
| DaveMorris | I think revu is the default isn't it | 16:46 |
| geser | persia: so we are in a small UVF already? | 16:47 |
| persia | geser: More, that there are no automatic systems flushing in new upstream versions: it requires a member of ~ubuntu-dev to do it manually. | 16:47 |
| persia | It doesn't require approval of the UVF team, or an RC bug, or a diffstat, or any of that. | 16:48 |
| persia | (or rather, will once DIF hits) | 16:48 |
| geser | persia: yes, but during gutsy there wasn't a need for a rationale between DIF and UVF/FF | 16:49 |
| persia | geser: Speaking personally, I wouldn't sponsor anyone's requests unless they explained why it was good, and I provided a rationale to the archive-admins for all the syncs I requested. I would expect other sponsors to also encourage non-members of ~ubuntu-dev to explain themselves, and I would expect members of ~ubuntu-dev to have a reason other than "I was bored". | 16:51 |
| persia | geser: Just to make sure I'm clear, as you're a member of ~ubuntu-dev, any new upstream you want, you should upload. | 16:52 |
| persia | (but if it causes a transition, you get to fix it) | 16:52 |
| persia | Also, for the many Ubuntu-only packages, I'd accept a rationale of "Hasn't been updated for hardy yet" for at least the next while. | 16:53 |
| geser | persia: have we a locking method for the open merges, so that work doesn't get done twice? DaD? | 16:54 |
| persia | geser: No, we're still broken. We've DaD comments, and a few "Please don't merge" bugs. | 16:55 |
| geser | ok, I'll announce then here on with merge I'm working | 16:56 |
| persia | geser: sounds sane. We really need to figure out a sensible locking policy for hardy +1: with both parents + mdt + manual merges + lpbugs.py having transformed completely, it's no longer easy to keep track. | 16:58 |
| ScottK | persia: Check with the last person that touched it really solves the problem almost completely. | 16:58 |
| DarkSun88 | Hi all | 16:59 |
| persia | ScottK: Not at all. Lots of people aren't around, and lots of people don't care. | 16:59 |
| ScottK | persia: Merges aren't emergencies. One can ask and wait a bit. | 16:59 |
| ScottK | persia: My almost are the 'don't care/don't respond' ones. | 17:00 |
| persia | ScottK: Sure, but why bother, especially when someone's MIA. | 17:00 |
| ScottK | persia: What's the Ubuntu definition of MIA? | 17:00 |
| persia | My thought is that if someone cares, they'll either merge or block the merge somehow. We should get them all done before DIF, and anything that causes a wait delays that. If we merge to UVF, when do we bugfix? | 17:01 |
| ScottK | I think using the comments on DaD is the simplest thing where there's doubt. | 17:01 |
| ScottK | How do UVF and bug fixing relate? | 17:01 |
| persia | ScottK: Not active, and perhaps not responding to email. | 17:01 |
| === lakin_ is now known as lakin | ||
| ScottK | So wait a few days and then comment on DaD. | 17:02 |
| geser | ScottK: if we had much time, I'd agree with you, but if we really want to get the most done before DIF, do we really have time to wait till someone reads his mails or joins here? | 17:02 |
| persia | ScottK: I'd agree with that, except many people don't use DaD for various reasons. | 17:02 |
| ScottK | persia: Sure, and I wouldn't enforce using it's merge tools, but using the status page isn't onerous. | 17:02 |
| blueyed | ATTENTION: http://dad.dunnewind.net/grab-merge.sh always deletes all files in your current directory! - there's missing a "|| exit" (or "set -e")! | 17:02 |
| blueyed | Lutin: ^^ can you fix that? | 17:03 |
| persia | ScottK: Also, if it's your package: set yourself as the maintainer. If it's a MOTU package, any Contributor (including MOTU) should feel free to hit it: it's only the rare complicated or poorly documented merge that matters. | 17:03 |
| Lutin | blueyed: no, I can't, there's a clear warning about that. it's not a bug | 17:04 |
| === _neversfelde is now known as neversfelde | ||
| persia | ScottK: Depends. I tend to use mdt and look at LP bugs for merges. Going to DaD is one more step. On the other hand, I'd argue that anyone doing a merge without checking LP for easy bugs to close along the way is not doing the merge properly. | 17:04 |
| lionel | blueyed: it's the same with grab-merge.sh from MoM | 17:04 |
| ScottK | persia: This is a fundamental point of disagreement. I think team maintenance means we work together as a team and not anyone in the team should do whatever strikes their fancy. | 17:04 |
| blueyed | Lutin, lionel: no. MoM's has "set -e"!! | 17:05 |
| persia | ScottK: Yep. It's likely the core point of many of our disagreements. I don't think we can resolve that anytime soon. | 17:05 |
| blueyed | Lutin: which warning? Why then ask in the first place?? You can only stop it with ctrl-c. answering "n" deletes also all files!! | 17:05 |
| blueyed | luckily this was "only" /tmp for me.. | 17:05 |
| ScottK | persia: Ideally we'd get the MoM U/I updated and it's all be good, but as long as we have multiple tools, someone is going to be inconvenienced. | 17:06 |
| Lutin | blueyed: what's the relationship with set -e ? | 17:06 |
| ScottK | persia: I think filing a bug that says "don't merge" is an abuse of LP. It's not a bug. | 17:06 |
| blueyed | Lutin: "[ $ANSWER = y ]" will exit then. But not without "set -e". Please add "|| exit" there. | 17:07 |
| persia | ScottK: That I can agree with. I don't like to use MoM myself, but it's the documented official way, so I can accept needing to check it. | 17:07 |
| persia | ScottK: Perhaps. I think of LP as both a bug database and a workflow system. | 17:07 |
| ScottK | persia: It is, but asking to NOT have something brought in from Debian is clearly not a bug of any kind. | 17:08 |
| persia | ScottK: Right. That'd be workflow. | 17:08 |
| ScottK | Then find something other than a bug to call it. | 17:09 |
| Lutin | blueyed: hum true, not sure why set -e got lost. dont have access to the server though | 17:09 |
| blueyed | Lutin: who has? | 17:09 |
| Lutin | Adri2000: | 17:09 |
| Adri2000 | blueyed: I'll fix that, thanks. dunno why nobody detected that earlier though | 17:09 |
| mruiz | hi all. I want to work on the bug #160965. I'm waiting for some comments related to changes introduced by Debian. I sent an email to the DD, but I don't have a reply until now... how is the procedure for these cases? | 17:09 |
| ubotu | Launchpad bug 160965 in fetchyahoo "Please sync fetchyahoo 2.10.8-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/160965 | 17:09 |
| blueyed | Thanks, Adri2000. Maybe because those who had reported it, lost there $HOME? ;( | 17:10 |
| persia | ScottK: Let's table this. We can at least agree that a MoM update is the right solution, and data sharing between MoM and DaD would be a benefit. | 17:10 |
| ScottK | OK. | 17:10 |
| ScottK | Agreed. | 17:10 |
| persia | ScottK: Separately, once we hit UVF, let's make a lot of noise about the issue, and try to get a real solution for the next release :) | 17:11 |
| ScottK | Sure. | 17:12 |
| === jpatrick_ is now known as jpatrick | ||
| slomo | LucidFox: now i am | 17:19 |
| alex-weej | i've downloaded a source package, used cdbs-edit-patch to edit a patch, now how do i make a "debdiff"? | 17:19 |
| bddebian | debdiff foo_old.dsc foo_new.dsc | 17:20 |
| alex-weej | bddebian: i only see one .dsc | 17:20 |
| alex-weej | notification-daemon_0.3.7-1ubuntu9.dsc | 17:20 |
| bddebian | alex-weej: Ah, did you not bump the changelog version? :) | 17:21 |
| alex-weej | bddebian: no | 17:21 |
| alex-weej | debian/ChangeLog? | 17:21 |
| bddebian | aye | 17:21 |
| alex-weej | better tool than gedit for adding a changelog entry? | 17:22 |
| bddebian | dch | 17:22 |
| bddebian | dch -i will insert a new entry | 17:22 |
| alex-weej | ok it's trying to insert crap into the current version | 17:22 |
| alex-weej | i guess i need to update control too? | 17:22 |
| bddebian | Shouldn't need to | 17:22 |
| alex-weej | it's trying to put my changelog entry under the last one for the current version | 17:23 |
| alex-weej | ah, dch -i | 17:23 |
| alex-weej | ok it thinks my email address is alex@flash | 17:23 |
| Adri2000 | blueyed: fix committed, should be online at :30 | 17:23 |
| bddebian | alex-weej: You can either fix that manually or export DEBEMAIL=<my email addr> | 17:24 |
| alex-weej | bddebian: so i've updated the changelog, how do i make these 2 dsc's? | 17:26 |
| mruiz | norsetto, Hi. I want to work on the bug #160965. I'm waiting for some comments related to changes introduced by Debian. I sent an email to the DD, but I don't have a reply until now... how is the procedure for these cases? | 17:26 |
| ubotu | Launchpad bug 160965 in fetchyahoo "Please sync fetchyahoo 2.10.8-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/160965 | 17:26 |
| norsetto | mruiz: well, you were asking the DD why he did these changes or why he didn't mention them in the changelog or? | 17:27 |
| mruiz | norsetto, both | 17:28 |
| alex-weej | help! when i debuild'd my package again it failed | 17:28 |
| alex-weej | can i only do it once? | 17:28 |
| norsetto | mruiz: what is the relevance of this to the sync/merge? | 17:29 |
| alex-weej | bddebian: i tried to debuild again with my changelog updated and it just fails now :( | 17:29 |
| mruiz | norsetto, I understood that it is important -> https://bugs.launchpad.net/ubuntu/+source/fetchyahoo/+bug/160965/comments/1 | 17:30 |
| ubotu | Launchpad bug 160965 in fetchyahoo "Please sync fetchyahoo 2.10.8-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] | 17:30 |
| bddebian | alex-weej: Did you start from scratch? | 17:30 |
| alex-weej | bddebian: no | 17:30 |
| alex-weej | i didn't want to write my patch again | 17:30 |
| norsetto | mruiz: yes, but I don't have in my memory all the 100s of bugs I have commented about, can you summarise it briefly? | 17:31 |
| mruiz | hahaha | 17:31 |
| bddebian | alex-weej: Copy your patch out of the way, re-extract the original source package copy your patch back in, update the changelog, and rebuild | 17:31 |
| alex-weej | bddebian: ok, did i do something wrong? | 17:31 |
| alex-weej | can i actually only build it once? | 17:31 |
| bddebian | Oh, you'll need to re-pull the source package | 17:31 |
| mruiz | norsetto, you asked about dropped ubuntu changes | 17:31 |
| alex-weej | i struggle to understand how my workflow is supposed to be when working with debian packages | 17:31 |
| afflux | hi! I merged briquolo some time ago. It got changed again in debian, but the only debian change was orphaning the package. Is this worth a merge? | 17:32 |
| bddebian | alex-weej: No, you just over-wrote the original source package since you didn't bump the debian version | 17:32 |
| norsetto | mruiz: right, we would loose those if we sync | 17:32 |
| alex-weej | bddebian: i see! | 17:32 |
| bddebian | afflux: I would say no personally | 17:32 |
| alex-weej | bddebian: i just copied the .patch and the changelog over to the newly pulled source package | 17:34 |
| alex-weej | should that be enough? | 17:34 |
| alex-weej | can i just debuild now? | 17:34 |
| blueyed | Adri2000: thanks. but it's not online yet. | 17:35 |
| afflux | bddebian: okay, I'll Ieave it | 17:36 |
| afflux | *leave | 17:36 |
| Adri2000 | blueyed: it is now | 17:38 |
| norsetto | mruiz: can you check the new package from debian? They are at 2.11.2-1, so, this might be obsolete | 17:39 |
| bddebian | alex-weej: "should" be, try it ;-P | 17:41 |
| alex-weej | bddebian: seemed to work. i made my debdiff but it is very strange | 17:41 |
| bddebian | how so? | 17:42 |
| mruiz | norsetto, great... a new version ;-) | 17:42 |
| alex-weej | bddebian: i see these diff.gz things | 17:42 |
| alex-weej | bddebian: are they useful? | 17:43 |
| alex-weej | bddebian: http://launchpadlibrarian.net/10846061/diff that look OK? | 17:47 |
| alex-weej | bddebian: i don't understand why there are changes to stuff that i haven't changed though :( | 17:47 |
| alex-weej | -SUBDIRS = standard | 17:48 |
| alex-weej | -DIST_SUBDIRS = $(SUBDIRS) bubble | 17:48 |
| alex-weej | +SUBDIRS = standard ubuntu | 17:48 |
| alex-weej | +DIST_SUBDIRS = $(SUBDIRS) bubble ubuntu | 17:48 |
| alex-weej | i didn't change that! | 17:48 |
| afflux | alex-weej: that line looks like it is from the patch file which is beeing diff'ed. | 17:49 |
| alex-weej | oh yeah | 17:50 |
| alex-weej | man, diffs of diffs | 17:50 |
| afflux | alex-weej: I love that too :) | 17:51 |
| bddebian | Yeah, ouch :-( | 17:52 |
| === RainCT is now known as UbuCat | ||
| === UbuCat is now known as RainCT | ||
| === cprov is now known as cprov-away | ||
| === norsetto is now known as norsetto_limbo | ||
| blueyed | Is a watch file update worth a merge? I have it ready, but need to get it sponsored.. | 18:03 |
| === rpereira_ is now known as rpereira | ||
| ScottK | blueyed: Does the old watch file work? | 18:07 |
| blueyed | ScottK: no, it does not - therefor it has been changed I guess.. ;) I've now also fixed two lintian issues (additional to merging), so it appears to be good IMHO. | 18:14 |
| mruiz | bye all | 18:14 |
| ScottK | blueyed: Sounds good. | 18:15 |
| LaserJock | hmm, what's this Freeze stuff all about | 18:21 |
| LaserJock | ? | 18:21 |
| LaserJock | seems like we're consistently making it harder on ourselves | 18:22 |
| ScottK | LaserJock: I agree. | 18:29 |
| LaserJock | well, I guess if we get all the merges done by tomorrow it won't really matter much | 18:30 |
| * ScottK doesn't see the sense in saying "Let's have all the by hand work done by the automatic import cut off" | 18:30 | |
| LaserJock | yeah | 18:30 |
| LaserJock | if we don't merge then we'll release stuff that's not just 6 months old, but perhaps 1 year old | 18:31 |
| LaserJock | for some packages we'll be very much behind Debian | 18:31 |
| LaserJock | including probably bug fixes | 18:32 |
| LaserJock | it makes sense to only pull in useful merges *if* you have the ability to actually do that | 18:32 |
| ScottK | Maybe we should just file sync bugs on everything to keep up. I think that may actually be encouraged now. | 18:32 |
| LaserJock | but I dont' think we currently have the ability to actively know what needs to be brought in | 18:32 |
| ScottK | Right, so let's just have them all. | 18:32 |
| ScottK | </sarcasm> | 18:33 |
| LaserJock | well, if we trust Debian then it should be straightforward to pull from there as long as possible | 18:33 |
| ScottK | Personally, I think we've done reasonably well in the past without this new unannounced (not until now AFAICT) deadline. | 18:34 |
| geser | yes, it would be good to know such a deadline a little bit earlier than two days before | 18:35 |
| DaveMorris | btw http://revu.tauware.de/details.py?package=rhythmbox needs to be nuked, it was upload by mistake (should of gone to ppa) I emailed the uploader and he confirmed it. I can forward it on if you wish | 18:36 |
| mruiz | ScottK, then the task for today and tomorrow is to work hard on merges? | 18:42 |
| ScottK | I guess that's the theory. I already did what I was going to do. | 18:42 |
| * geser is currently merging lynkeos.app and multisync0.90 | 18:48 | |
| LaserJock | ScottK: we've had such announcements before, but it was pretty much "you're losing automatic syncing so you probably want to do as much as you can" | 18:50 |
| LaserJock | for Universe | 18:50 |
| ScottK | Sounds about right. | 18:50 |
| === jpatrick_ is now known as jpatrick | ||
| slicer | ScottK: Ok, it took some time to get a working hardy install, but it compiles and verifies mumble with lintian/linda. | 18:56 |
| ScottK | slicer: Both on the source and binary packages? | 18:57 |
| asac | RAOF: there? | 18:57 |
| slicer | ScottK: *nod* | 18:58 |
| slicer | ScottK: As in, 'debuild' and 'debuild -S -sa' both ran lintian and linda and didn't complain. | 18:59 |
| slicer | Well.. lintian said that it had ignored 1 warning and 1 error, which are the ones I've specified in the lintian override. | 18:59 |
| ScottK | slicer: That's on the source package. | 18:59 |
| Ubulette | why don't I (everyone?) have access to .changes i REVU ? not even mine | 19:00 |
| ScottK | slicer: Also run lintian packagename.deb (using the actual name of the .deb) too. | 19:00 |
| slicer | But.. I.. Argh, I just shut down the VM. Aight, I'll boot it again. | 19:01 |
| ScottK | Ubulette: Because if you had upload rights someone could take that file and use it to upload to an actual repository. | 19:01 |
| ScottK | slicer: If you've added over-rides, be sure to carefully document the rationale (if you haven't). | 19:01 |
| slicer | ScottK: It's documented on the REVU page. Do I need anything more? | 19:02 |
| Ubulette | ScottK, hmm, ok. Fair enough, it should not be clickable then | 19:02 |
| ScottK | slicer: I would also document it in the package so when someone else looks at it next year they understand why. | 19:02 |
| ScottK | Ubulette: Dunno why they did it the exact way they did it. | 19:02 |
| slicer | ScottK: Er. Are #comment legal in lintian override? | 19:03 |
| ScottK | slicer: Dunno. Never had to do one. | 19:03 |
| jpatrick | I have seen some | 19:03 |
| * RainCT wonders how a .desktop file can have "Version=1.1" XD | 19:04 | |
| === nuu is now known as nu | ||
| === nu is now known as nuu | ||
| === pochu_ is now known as pochu | ||
| nixternal | doko: have you figured a work around at all with the Java issue in Hardy (java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed)? | 19:57 |
| nixternal | ahh, but I just did | 20:02 |
| nixternal | export LIBXCB_ALLOW_SLOPPY_LOCK=true | 20:02 |
| cdm10 | Hey, I've signed my packages, and added my public key to System>Admin>Software Sources - Authentication tab, but when I install from my PPA i still get the "not authenticated" error. | 20:08 |
| === norsetto_limbo is now known as norsetto | ||
| geser | cdm10: are PPA signed now? afaik they aren't | 20:10 |
| geser | cdm10: for that PPA would need your private key | 20:10 |
| afflux | cdm10: you signed only the source packages, the binaries aren't as they are built automatically. | 20:10 |
| slicer | ScottK: Ok, .debs, .changes, everything verifies with lintian. I added comments to the lintian override file. | 20:11 |
| ScottK | Good. That'll all make your review smoother. | 20:11 |
| cdm10 | geser, afflux: shoot, I didn't think of that... stupid me. Anyway, thanks. | 20:12 |
| slicer | ScottK: It already verified, the only difference I've done is add the comments. | 20:22 |
| ScottK | slicer: That's good. The new lintian matches for the new standards version. | 20:43 |
| muuluu | hi | 21:25 |
| muuluu | need help pls? | 21:25 |
| muuluu | hello anyone | 21:26 |
| DktrKranz | muuluu, expose your problem :) | 21:26 |
| muuluu | all type of linux random time freezing | 21:26 |
| ScottK | muuluu: This is not a support channel. Try #ubuntu. | 21:27 |
| muuluu | i have Asus MB Core 2 Duo 6600, Geforce 7300 GS 400 watt power supply | 21:27 |
| muuluu | i asked them many time times but there is no answer for me | 21:27 |
| muuluu | i tried #linux same Suse same where can i go now :-( | 21:29 |
| muuluu | ok thanks for ur responce anyway bye now | 21:30 |
| nixternal | imbrando1: pingerz | 22:09 |
| === jpatrick_ is now known as jpatrick | ||
| Lutin | does a core-dev have a minute to have a look at bug #173717 ? :) | 22:42 |
| ubotu | Launchpad bug 173717 in grub "Grub has a build-depends-indep against a multiverse package" [High,New] https://launchpad.net/bugs/173717 | 22:42 |
| Lutin | apachelogger: ping ? about the filelight merge/sync | 22:57 |
| RainC1 | good night | 23:11 |
| blueyed | ScottK: any chance you're using postfix-policyd? (or somebody else?) | 23:14 |
| blueyed | bug 175731 | 23:15 |
| ubotu | Launchpad bug 175731 in postfix-policyd "postfix-policyd hangs at "connecting to mysql database:"" [Undecided,New] https://launchpad.net/bugs/175731 | 23:15 |
| ScottK | blueyed: No. I'm familiar with it, but don't use it. | 23:19 |
| blueyed | ScottK: the changelog from 1.82 seems "promising": http://sourceforge.net/project/shownotes.php?group_id=133598&release_id=533414 | 23:33 |
| blueyed | Debian has still 1.82 though. I guess the best is to create an (inline) patch for this in Ubuntu, isn't it? | 23:34 |
| * ScottK looks | 23:35 | |
| blueyed | I can recommend the program in general: it's great for a mailserver. | 23:35 |
| blueyed | (if it does not hang that is) | 23:35 |
| ScottK | Yes. It's generally well thought of, it just doesn't fill a particular need I have. | 23:35 |
| ScottK | blueyed: It looks like the Debian maintainer hasn't been keeping particularly current. You might want to just prepare a 1.82 package for Hardy. | 23:37 |
| ScottK | Once we have that you can ask about an SRU for your bug. | 23:37 |
| LaserJock | who's in charge of DaD these days? | 23:46 |
| ScottK | LaserJock: Adri2000 and Lutin. | 23:46 |
| ScottK | IIRC only Adri2000 has server access. | 23:47 |
| ScottK | blueyed: Looking at it some more, I'd say prep an upgrade for Hardy to 1.82. I doubt Debian will do it soon. | 23:47 |
| LaserJock | Lutin: still around? | 23:47 |
| Lutin | indeed. (I have bzr access though, and the code is auto-synced from there) | 23:48 |
| LaserJock | ah, there you are | 23:48 |
| Lutin | LaserJock: sort of :) | 23:48 |
| LaserJock | I was wondering if it is possible to get a PTS link next to the LP link | 23:48 |
| blueyed | ScottK: Ok. I'll file a bug about it and then look into it tomorrow. | 23:49 |
| LaserJock | IMO, PTS is the most important resource for merging | 23:49 |
| Lutin | LaserJock: should be possible, yep. (although I really wonder if I'm even able to write that) | 23:49 |
| Lutin | LaserJock: I really don't know anything about php, so if you can tell me how to do it, I'll commit it :) (or wait tomorrow for Adri2000 to do it) | 23:57 |
| joejaxx | where is my multiline irssi window notification plugin when i need it :P | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!