[12:12] its not relevant [12:12] to my issue [12:12] ah [12:13] well, if you've searched and can't find a similar bug you can always file one if you think there is indeed a bug [12:18] cjwatson: does/can a sync from Debian overwrite and existing .orig.tar.gz? [12:18] *an [12:19] not one with the same name, no [12:19] we've got a situation where Ubuntu had an .orig.tar.gz before Debian [12:19] the only thing you can do in that circumstance is a "fake sync" using the Ubuntu .orig.tar.gz but producing a result equivalent to the Debian package [12:20] same version, files are the same, just different creation times on the tarball so the md5sums don't match [12:20] normally using the Debian diff, but check that the Debian and Ubuntu .orig.tar.gzs produce basically the same content [12:20] right, so Ubuntu .orig.tar.gz, Debian .diff.gz, new debian/changelog entry with "build1" on the end, upload [12:20] that's what I was thinking, excellent [12:21] thanks [12:21] would the next sync work after that? [12:21] or you are stuck until new upstream [12:21] stuck until new upstream I guess [12:21] thought so [12:21] this has happened more then once I think [12:22] it would be nice if we could just replace the Ubuntu .orig.tar.gz with the Debian one [12:22] LaserJock: The problem is the old .dsc files that still contain the old md5. [12:22] LaserJock: and they're all stored in the same placed and signed and everything. [12:23] bhale: as LaserJock said [12:23] LaserJock: breaks mirrors, no can do [12:24] LaserJock: well [12:24] shawarma: also that mirrors would have to use rsync --checksum rather than just relying on filenames, which is a big fat extra load [12:24] LaserJock: it is often known what cases it will happen in [12:24] LaserJock: a heads up to the Debian maintainer usually makes it a non-issue in my experience [12:24] cjwatson: Oh, i thought they did that already. [12:24] cjwatson: But of course, that'd be silly since we never change any existing files. [12:25] cjwatson: ..apart from Packages.gz and such. [12:26] cjwatson: Are Release, Sources, and Packages rsynced on the side then? [12:26] filenames are unique in the archive; this is an invariant [12:26] sure [12:26] they're often done in a separate [12:26] er [12:26] dists/ is different [12:26] in fact I think it's just pool/ that has the uniqueness constraint - it's the biggest bit by far [12:26] whoever recommended dd_rhelp to me the other day [12:26] you are a LEGEND [12:27] it is closing up dead holes on my disk image really well [12:27] shawarma: I believe so [12:27] see e.g. http://www.debian.org/mirror/anonftpsync [12:28] cjwatson: if we upload as build1 will it cause problems for the Feisty+1 syncing (i.e. normally build1 packages are automatically synced)? [12:29] cjwatson: I see. That would explain why Packages sometimes referes to files that are no more. [12:30] LaserJock: no; at worst those syncs will harmlessly fail and will have to be merged [12:30] (this isn't a new problem - we have a fair bit of experience with this :-)) [12:30] heh [12:30] ok, thanks [12:30] np [12:30] cjwatson: So the complete version would be what? Debian is 1.27-2, so we'd make 1.27-2ubuntu0build1 ? [12:30] shawarma: right [12:30] no, 1.27-2build1 [12:31] the effect of "ubuntu" in a version is precisely to suppress automatic syncing [12:31] cjwatson: ...which we want? [12:31] in this case you don't want to do that - either there's no new upstream and the sync will fail harmlessly, or there's a new upstream and you want to autosync [12:31] cjwatson: ..since manual intervention is needed anyhow. [12:31] only if there's no new upstream [12:32] we don't want to overload people doing merges, so if the worst thing that happens is that a sync fails, big deal, we ignore that [12:32] cjwatson: Ah... Yes, now I get it. [12:32] it's better to try to autosync where possible [12:32] cjwatson: Indeed. Makes sense. Thanks. === o_cee [n=oscar@c83-249-96-144.bredband.comhem.se] has joined #ubuntu-devel === mat [n=mat@igoan/mat] has joined #ubuntu-devel === rmjb [n=richard@cuscon22147.tstt.net.tt] has joined #ubuntu-devel [12:48] bug 54684, it apparently approved for edgy-updates but it hasn't been moved from proposed yet [12:48] Malone bug 54684 in nautilus "High CPU usage" [Unknown,Fix released] http://launchpad.net/bugs/54684 [12:48] excuse my ignorance abourt SRU's [12:51] Stuff isn't moved from -proposed to -updates, it requres a second upload currently. [12:51] Oh, and the second upload happened. [12:52] hi guys === geser [n=michael@dialin104091.justdsl.de] has joined #ubuntu-devel [12:53] anyone here good at packaging? i was curious if i could get someone to compile and package these drivers: http://doc.gwos.org/index.php/Nvidia_nForce_SoundStorm [12:53] i'd just like to have the .deb around for the future, i won't be buying this damned chipset anymore [12:55] holycow: Try #ubuntu-motu [12:55] danke [12:55] (If you want it packaged in multiverse) [12:55] It's certainly never going to be in restricted, since nvidia doesn't support the driver anymore. [12:55] not a bad idea, never thought of it [12:55] nforce is no longer supported? [12:56] No, the driver isn't supported. nvidia tells people to use the open source drivers instead. [12:56] for nforce? [12:56] (One would assume they're contributing to the open source drivers sucking less, slowly) [12:56] For nforce sound, yes. [12:56] odd [12:56] well they do provide source files for the chipset, the chipset controls a bunch of things [12:57] is the gpg bug set to be pushed out soon? [12:57] nforce sound eh? would you know anything about nforce network card or vid support? [12:58] i presuve nv drivers supports video [12:58] maybe then just getting a newer kernel might workie [12:58] They're all supported with open drivers [12:59] okay, in that case, it must be just that dapper doesn't have the latest builds of those, cool thats awesome to know [12:59] i didn't manage to google that up === jonh_wendell [n=wendell@40-88-199-200.vcnet.com.br] has joined #ubuntu-devel [12:59] did nvidia open source the drivers or did they just give up when someone reverse engineered them? [01:00] the later, roughly [01:00] heh [01:00] holycow: more a matter of poking the hardware and seeing how it jumps [01:01] aha okay. [01:01] keescook: I've working packages for gnupg2 2.0.1 [01:02] geser: great, do you have a URL for them? [01:03] what exactly should I upload? is the diff.gz enough? [01:03] would it be fair to say that the best supported chipset these days are intel chipsets? [01:03] Yes [01:03] then its time to switch i think [01:04] thank you for the info guys, greatly appreciate that [01:06] keescook: is the diff.gz enough? === lotusleaf [n=lotuslea@kernel-panic/member/carne.asada.burrito] has joined #ubuntu-devel [01:09] geser: generally debdiffs are nicer :-) [01:09] also for new upstream versions? [01:10] hmm, I think I'd rather have the whole package in that case [01:10] topic [01:10] infinity: thanks for taking care of the gnome-vfs2 thing :) [01:11] geser: can you get me the URL for the orig too? [01:11] http://pastebin.ca/270015 [01:11] ideas? === jonh_wendell [n=wendell@40-88-199-200.vcnet.com.br] has left #ubuntu-devel ["Bye"] [01:13] keescook: I will upload my used orig.tar.gz to some webspace (ftp.gnupg.org has only tar.bz2) [01:13] geser: okay, thanks. === Arrogance [n=aks@ottawa-hs-64-26-148-159.d-ip.magma.ca] has joined #ubuntu-devel === bronson [n=bronson@66.160.177.201] has joined #ubuntu-devel === anibal [n=anibal@debian/developer/anibal] has joined #ubuntu-devel [01:15] heh, iptables is a LOT more bothersome when it plays music [01:15] guess that must be why nobody else does it :D [01:16] keescook: I also added libcurl3-gnutls-dev to build-depends as this fixes bug 62864 for me (it also happens with gnupg2). is that ok? [01:16] Malone bug 62864 in gnupg "[Edgy] Refreshing my keyring stops after some keys (keyserver time out)" [Undecided,Unconfirmed] http://launchpad.net/bugs/62864 [01:16] jmg: pvscan doesn't take a device name, for a start. Try vgscan? [01:17] geser: I assume so; I've got a path fix for it too, so I'll probably apply that to yours before I upload it [01:18] (or, at least, it didn't take a device name in the sarge system with lvm I have handy. hmm) === bddebian [n=bdefrees@c-71-224-172-103.hsd1.pa.comcast.net] has joined #ubuntu-devel [01:19] jdong: it does not take on on my edgy server [01:19] cjwatson: ^s/on/&e/ [01:19] jdong: sorry, wrong nick [01:20] cjwatson: no, pvscan doesn't take device names on dapper or edgy [01:21] jmg: ^^ [01:21] keescook: http://members.ping.de/~mb/gnupg2/ [01:21] cjwatson: pvscan/pvdisplay both have null output [01:22] geser: thanks, snagging now [01:22] jmg: you sure you've fdisked your partition to have linux LVM type? [01:22] jdong: yes [01:22] er [01:22] though that isnt required [01:22] it needs to be made a pv first [01:22] partition type is not enough [01:23] pvcreate [01:23] HrdwrBoB: see pastebin [01:23] jmg: IIRC it is required for PV's to be picked up automatically [01:23] http://pastebin.ca/270022 [01:23] jdong negative [01:23] I have no partitions on my array, works fine [01:24] jdong: and anyway [01:24] /dev/sda3 : start= 12578895, size=475813170, Id=8e [01:25] jmg: does pvdisplay show anything? [01:25] in the strace of pvscan i can see it reading the lvm tag off the partition, yet it doesnt work [01:25] jdong: null [01:25] hmm [01:25] jdong: if i do it on console it shows "File descriptor 6 left open" [01:26] note that this box has been dist-upgraded from dapper to edgy [01:29] strange [01:29] very [01:29] should I be breathing a sigh of relief that I didn't dist-upgrade my LVM server to edgy? [01:29] perhaps [01:29] I haven't upgraded any servers to edgy [01:29] i wanted to try chuck's xen packages [01:32] hello, anyone knows what a driver should build-depend on? I have kernel-package in there, but pbuilder complains about not finding the /lib/modules/2.6.17-10-generic/build directory [01:33] rmjb: some sort of linux-headers? [01:33] rmjb: I guess look at how linux-restricted-modules is done [01:34] there's no generic headers then... [01:34] no generic headers? [01:34] I mean one that's not specific to an arch [01:34] l-r-m builds against all [01:35] a control.in.in generates it [01:35] I think === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-devel === chuck_ [n=bob@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-devel [01:36] I am definitely in way over my head === chuck_ [n=bob@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-devel === TomB_ [n=tomb@host81-152-42-42.range81-152.btcentralplus.com] has joined #ubuntu-devel [01:42] ok [01:42] i downgraded lvm2 to the package from dapper [01:43] http://pastebin.ca/270037 [01:43] hmm [01:43] evms... === minghua [n=minghua@ubuntu/member/minghua] has joined #ubuntu-devel [01:51] heh === fernando [n=fernando@unaffiliated/musb] has joined #ubuntu-devel === jack_wyt [n=jack@211.154.174.45] has joined #ubuntu-devel === oyzi [n=oyzi@c-ac42e255.434-1-64736c11.cust.bredbandsbolaget.se] has joined #ubuntu-devel === jack_wyt [n=jack@211.154.174.45] has joined #ubuntu-devel === oyzi [n=oyzi@c-ac42e255.434-1-64736c11.cust.bredbandsbolaget.se] has left #ubuntu-devel ["Ex-Chat"] === sevrin [n=sevrin@202.75.186.154] has joined #ubuntu-devel [02:24] jdong, are you around? [02:25] i have a question about the possibility of backporting nforce drivers to dapper [02:25] holycow: yes I am [02:25] hi btw [02:25] what nforce drivers? [02:25] the open source drivers that i understand are in the kernel [02:26] in the kernel? [02:26] I don't handle that. --> #ubuntu-kernel [02:26] well i don't know if they are modules or built in, i presume modules [02:26] oh okay at least i get closer [02:26] thanks jdong [02:26] holycow: np, good luck :) [02:26] :) === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #ubuntu-devel [02:29] does anyone know if i can safely mount a disk image (read-only) that is actively being written to? [02:30] alex-weej: no [02:31] is that a "i know, and the answer is no" [02:31] or a "no i don't know"? === fnordus [n=dnall@24.85.128.203] has joined #ubuntu-devel [02:31] (1) read-only is not always taken so literally. ext3 actually does a JOURNAL PLAYBACK when you mount it ro :) [02:31] o_0 [02:31] o.O [02:31] (2) If significant structures change while you're reading, you'll get a kernel panic or oops [02:31] I have experienced both [02:31] heh [02:31] ok [02:31] I am the authority on doing crackful things [02:31] :) [02:32] jdong: most drivers will rework it and remount ro or just umount [02:32] for file system being ass [02:32] bluefoxicy: in theory :) [02:32] dd_rhelp is really struggling on the last few MB of this disk [02:32] yes [02:32] that theory is "Faulty hardware means we try to back off safely" [02:32] bluefoxicy: I've panicked ext3 with -o errors=remount-ro before [02:32] I'm aware the reality can be "Let's do a BSOD" [02:32] bluefoxicy: that's from xen and my system both mounting a disk [02:33] XD [02:33] so alex-weej, either momentarily stop dd-rhelp or wait on mounting :) [02:33] and make sure you mount a COPY [02:33] not the original backup image [02:33] because as I've said, a simple ro mount can change the image [02:33] yeah i'm gonna [02:33] copying a 108 GB image is going to take a while [02:34] :) [02:34] the sweet sound of hard disk failure === jdong knows that sound too well === alex-weej too now [02:34] from that first click-click-click to the spindown :) [02:34] lol [02:34] it's done pretty well tbh [02:34] - Biggest hole size : 800 k - total holes : 4656.0k [02:34] - xferd(succ/err) : 116161327.5k(116161195.5k/132.0k) [02:34] Sure wish OCFS2's module was in the -generic kernel. =/ [02:35] so i could play with it [02:35] alex-weej: that's very good [02:35] alex-weej: a helluva lot better than I've ever done [02:35] taken me 6 hours [02:35] alex-weej: you caught that failure early [02:35] or you're just lucky [02:36] oop it's off again [02:36] - Biggest hole size : 736 k - total holes : 4212.0k [02:36] - xferd(succ/err) : 116161771.5k(116161635.5k/136.0k) [02:36] :D [02:36] still lost 4k though :( [02:36] do you know if that "err" bit is totally dead disk? [02:37] i might leave it going overnight see how well it is when i wake up [02:37] alex-weej: the err is how many blocks dd_rescue (not dd_rhelp!) stumbled on [02:37] alex-weej: when dd_rescue stumbles, dd_rhelp helps dd_rescue fast-forward a bit [02:37] alex-weej: so in reality succ/err is pretty nonsensical [02:37] alex-weej: it's the hole sizes that you need to worry about :) [02:37] alex-weej: I hope that's ext2/3, btw [02:38] yeah, why? [02:38] alex-weej: for the recovery ;-) [02:38] you think i should make a copy then fsck it? [02:38] alex-weej: a lot of the other filesystems have a good deal of "magic metadata" that if lost means a good chunk of the structure disappears (!) [02:38] alex-weej: you should absolutely make a copy of it [02:38] fscking it is a good start [02:38] uh oh [02:39] don't like the sound of it being a "good start" [02:39] i've put like a whole evening into this already lol [02:39] well [02:39] fsck isn't always failproof [02:39] it can either [02:39] (1) Die / core-dump in the middle of repairing [02:39] (2) Give up and start slashing inode entries until you're left with 2 files [02:39] and then call it "clean" :D [02:40] :| [02:40] just hope that neither happens :) [02:40] btw [02:40] if i just mount a copy [02:40] without fsking === _TomB [n=ownthebo@host81-152-42-42.range81-152.btcentralplus.com] has joined #ubuntu-devel [02:40] sure, you can try that [02:40] if i try and copy files off will i get potentially corrupt files or is there some sort of checksumming in effect? [02:40] though there's a possibility a good chunk of directories are not available [02:41] i.e. you get an IO Error or Operation Not Permitted trying to enter a directory [02:41] hmm [02:41] i'm curious [02:41] depends on whether or not any of that 4000K is filesystem metadata [02:41] which I'm betting at least a bit of it is :-/ [02:41] you can try it [02:41] hence the point of the "copy" :) [02:41] reckon i can hot copy the image that is being written to? [02:42] it's not easy to pause this thing [02:42] it's blocking like a bitch [02:42] and it's uninterruptable [02:44] yeah, IO Errors block :) === Gman [i=gman@nat/sun/x-ca54aa4907f8b2e7] has joined #ubuntu-devel [02:44] look who didn't build a preemptible kernel [02:44] (j/k :D) [02:45] what would that have done? [02:45] given you a much better chance of interrupting the process :) [02:46] blaeh === WaterSevenUb [n=WaterSev@c-65-96-188-198.hsd1.ma.comcast.net] has joined #ubuntu-devel === esaym [n=esaym@cpe-24-162-149-45.hot.res.rr.com] has joined #ubuntu-devel [03:02] seriously i ctrl+c'd this process about 5 minutes ago [03:02] damnit === dilinger [n=dilinger@24.128.243.228] has joined #ubuntu-devel === stefg [n=chatzill@dslb-088-072-215-076.pools.arcor-ip.net] has joined #ubuntu-devel === j_ack [n=rudi@p508DA117.dip0.t-ipconnect.de] has joined #ubuntu-devel === zenrox [n=zenrox@pool-71-115-219-183.spknwa.dsl-w.verizon.net] has joined #ubuntu-devel === cr3 [n=marc@pdpc/supporter/bronze/cr3] has joined #ubuntu-devel === spacey [n=herman@ubuntu/member/spacey] has joined #ubuntu-devel === shenki_ [n=shenki@150.101.72.85] has joined #ubuntu-devel === doko_ [n=doko@dslb-088-073-097-055.pools.arcor-ip.net] has joined #ubuntu-devel === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-devel === tonyyserver [n=anthony@d235-240-148.home1.cgocable.net] has joined #ubuntu-devel === tonyyserver [n=anthony@d235-240-148.home1.cgocable.net] has joined #ubuntu-devel === tonyyserver [n=anthony@d235-240-148.home1.cgocable.net] has joined #ubuntu-devel === dous_ [n=dous@124.104.0.197] has joined #ubuntu-devel === dous_ [n=dous@124.104.0.197] has joined #ubuntu-devel === hunger_ [n=tobias@p54A7258E.dip0.t-ipconnect.de] has joined #ubuntu-devel === abattoir [n=abattoir@cm57.omega18.maxonline.com.sg] has joined #ubuntu-devel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-devel === mneptok [n=mneptok@montreal.canonical.com] has joined #ubuntu-devel === cr3 [n=marc@pdpc/supporter/bronze/cr3] has joined #ubuntu-devel === bronson [n=bronson@adsl-75-36-147-248.dsl.pltn13.sbcglobal.net] has joined #ubuntu-devel === nags [n=nags@125.16.129.16] has joined #ubuntu-devel === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #ubuntu-devel === abattoir [n=abattoir@cm57.omega18.maxonline.com.sg] has joined #ubuntu-devel === stub [n=stub@ppp-58.8.7.203.revip2.asianet.co.th] has joined #ubuntu-devel === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #ubuntu-devel === fnordus [n=dnall@24.85.128.203] has joined #ubuntu-devel === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #ubuntu-devel === seaLne [n=seaLne@ubuntu/member/sealne] has joined #ubuntu-devel === stub [n=stub@ppp-58.8.7.203.revip2.asianet.co.th] has joined #ubuntu-devel === jdong_ [n=jdong@d192-24-18-234.col.wideopenwest.com] has joined #ubuntu-devel === Catshrimp [n=blfisher@64.108.5.134] has joined #ubuntu-devel === Catshrimp [n=blfisher@64.108.5.134] has left #ubuntu-devel [] === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-devel === jack_wyt [n=jack@211.154.174.45] has joined #ubuntu-devel [06:27] oh hell yes [06:28] libFLAC 1.1.3 is out, and no GNU_STACK [06:28] I submitted the changes for that a while back <3 [06:29] (well it's there on PPC but not on IA-32) === stub [n=stub@ppp-58.8.7.203.revip2.asianet.co.th] has joined #ubuntu-devel === lguerra [n=lguerra@201.244.24.223] has joined #ubuntu-devel === stub [n=stub@ppp-58.8.7.203.revip2.asianet.co.th] has joined #ubuntu-devel [06:37] I wish to file a wishlist bug against the USN (Ubuntu Security Notice) process. What is the name of the pseudopackage? [06:38] twb: what's the bug? :) [06:38] http://twb.ath.cx/tmp/tmp.txt [06:39] Treenaks: DSEs have a little summary header like that at the top of each message. [06:39] I'd like USNs to do likewise. === j_ack_ [n=rudi@p508D897F.dip0.t-ipconnect.de] has joined #ubuntu-devel [06:40] For example if it says "Problem type: remote", I upgrade *immediately* and then read the rest of the message. If it says "Problem type: local", I don't rush so much. === didymo [n=ashley@61.9.197.223] has joined #ubuntu-devel [06:41] I just always run upgrade-cluster.sh :) [06:42] not that it's really a cluster.. but it upgrades all machines I'm a sysadmin for === stub [n=stub@ppp-58.8.7.203.revip2.asianet.co.th] has joined #ubuntu-devel [06:49] twb: I've been thinking about adding something like that. However, I worry about serious issues getting ignored due to those classifications, though. for example, the tar USN would have "local", but there are plenty of websites that automatically process tar files, so really it's remote vuln for them... === haggai [n=halls@credativ.bcnadsl.com] has joined #ubuntu-devel [06:53] keescook: I suppose... [06:54] twb: but, I agree: it'd be nice to have a little something more. :) [06:55] keescook: see what secunia puts out. Is quite good [06:55] they also rate the vuln, which is fairly useful, if a little arbitrary [06:55] Any rating between "minor" and "critical" is pretty useless, IMO. [06:55] yeah, I like secunia's stuff. :) [06:56] hey infinity! :) [06:56] "This is something only a pedant will care about" versus "Jumping Judas, update your system yesterday." [06:56] heh [06:56] Any in between is so arbitrary that it's worthless, which makes the whole system of ratings somewhat worthless. [06:57] "Well, this could be sort of bad, on a Tuesday, if you're downloading porn." [06:57] however, there are vulns which are worse than others [06:58] There are. remote/local, root/not, should be enough for most people to decide on their own. [06:58] Too many factors on the local machine to say beyond that what's "bad" and what's not. [06:58] I may be some SELinux freak who doesn't even care about privilege escalation, or I may be a bank behind 4000 firewalls who doesn't care about remote vulns, etc. [06:59] Or, other considerations, like things that rely on poor user habits would be "no big deal" to me, but a huge deal to a corporation full of "regular users". [06:59] yep [06:59] And on it goes. [07:02] Now, we *could* rate vulns based on the potential for humour. [07:02] "If your friends are caught by this one, you can TOTALLY point and laugh." [07:03] humour value: 4.3 (likely to be activating while browsing goat porn) [07:06] Bah. I use wget for all my goat porn. [07:06] I'd like to see someone manage a js exploit in that! [07:07] hmm, I saw a wget exploit awhile back === nixternal [n=nixterna@ubuntu/member/nixternal] has joined #ubuntu-devel === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #ubuntu-devel === robitaille [n=daniel@ubuntu/member/robitaille] has joined #ubuntu-devel === timfrost [n=timfrost@125-238-33-97.broadband-telecom.global-gateway.net.nz] has joined #ubuntu-devel === Amaranth [n=travis@ubuntu/member/amaranth] has joined #ubuntu-devel === jack_wyt [n=jack@211.154.174.45] has joined #ubuntu-devel === lucas [n=lucas@ubuntu/member/lucas] has joined #ubuntu-devel === marilize [n=marilize@196.36.161.235] has joined #ubuntu-devel === ArwynH [n=arwyn@PPPf184.saitama-ip.dti.ne.jp] has joined #ubuntu-devel === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-devel === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-devel [08:06] Good morning === dade` [n=dade@nectarine/admin/dade] has joined #ubuntu-devel [08:11] infinity: apache2 and subversion syncs (subversion is assigned to me, but I would need apache2 first) [08:11] doko: apache2 is on my list of "things I'm going to be careful about, but I promise to get it done this week before I go on VAC" [08:12] doko: You can either leave SVN to me (which should be simple enough), or do it after I get apache2 happy. [08:12] Part of "making apache2 happy" includes a mess of "getting modules happy", I suspect, so perhaps best to leave SVN to me too. [08:12] ok === astopy [n=adam@taurus.moosoft.net] has joined #ubuntu-devel === tsmithe` [n=bip@82-70-109-22.dsl.in-addr.zen.co.uk] has joined #ubuntu-devel === human_blip [n=mike@220.157.65.29] has joined #ubuntu-devel === stub [n=stub@ppp-58.8.7.203.revip2.asianet.co.th] has joined #ubuntu-devel === bronson [n=bronson@adsl-75-36-147-248.dsl.pltn13.sbcglobal.net] has joined #ubuntu-devel === Lure [n=lure@external-7.hermes.si] has joined #ubuntu-devel [08:36] Uhm, since when is python marked Essential: yes [08:36] ? [08:36] doko: Do you know about the above? [08:38] hmm, not for me... [08:38] only -minimal [08:38] Which is also pretty sketchy. [08:38] But here, it's Essential. [08:39] but wasn't -minimal specifically introduced to become an essential package? [08:39] No [08:39] ('yay for writing postinst scripts in python' or so?) [08:39] minimal has all sorts of stuff in it that doesn't qualify as "Essential", as far as Debian policy would define it. [08:40] Oh, we're talking about two different "minimals" :) [08:40] Well, Ubuntu doesn't stick to the Debian policy. [08:40] python-minimal is also not Essential, however. [08:40] twb: Name one are where we don't. === minghua [n=minghua@ubuntu/member/minghua] has joined #ubuntu-devel [08:40] s/are/area/ [08:41] infinity: invariant sections of GFDL docs? [08:41] twb: That's not Policy, that's DFSG. [08:41] Well, I assumed policy said something like `only DFSG in main'. [08:41] Debian Policy is about packaging, not politics. [08:42] And we adhere to it as best we can, or the world explodes. [08:42] infinity: hmm, yes, looking at it; the essential attribute was dropped in my last update [08:42] pitti: python-minimal is Priority: Required, python somehow ended up Essential: yes recently. [08:42] infinity: ok, my package index is from yesterday still [08:42] doko: As in, one you just uploaded, or one you're about to? === pitti is at ISDN ATM, network broken once again [08:43] Section 2.2.1, "Every package in _main_ must comply with the DFSG (Debian Free Software Guidelines)." [08:43] infinity: 2.4.4-1ubuntu1 [08:43] Ubuntu concretely does not follow that part of the policy w.r.t. tar-doc, which has invariant sections. [08:43] twb: Okay, fine, we don't adhere to 2.2.1 (or, you could argue that we read the DFSG differently from Debian) [08:44] twb: Point taken, though. We don't adhere to Policy 100%. That doesn't mean we ignore it. [08:44] I'm not implying that Ubuntu not sticking to Debian policy is a *bad* thing; merely that it is *a* thing. [08:44] (base)adconrad@cthulhu:~$ apt-cache show python | egrep "^Version|^Essential" [08:44] Essential: yes [08:44] doko: ^^^ [08:44] Version: 2.4.4-1ubuntu1 [08:45] doko: Source agrees with me too. [08:46] infinity: fyi, this is shorter [08:46] grep-available -s Package,Essential,Version -X -P python [08:47] twb: You're assuming I have dctrl-tools available on that machine. [08:47] Sure. [08:48] (Also, I know) [08:48] Good-o. [08:48] infinity: apt-cache show python-minimal|grep Ess [08:48] doko: python. Not minimal. [08:48] python shouldn't be essential [08:48] doko: I agree. :) [08:49] doko: The source does not. === dholbach [n=daniel@i59F71381.versanet.de] has joined #ubuntu-devel === infinity wonders if this is the point where he stops talking and just uploads. [08:52] infinity: Thanks for punting wlassistant to -updates. [08:52] StevenK: Cheers. [08:52] good morning [08:52] <_ion> Hi dholbach [08:53] heya _ion [08:53] doko: Are we talking past each other, or did you just have another look at python-defaults' debian/control and realise what I'm talking about? :) === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-devel [08:54] <_ion> dholbach: Please take a look at bug 74698. [08:54] Malone bug 74698 in ubuntu-artwork "Wrong gconf defaults for wallpaper" [Undecided,Unconfirmed] http://launchpad.net/bugs/74698 === dade` [n=dade@nectarine/admin/dade] has joined #ubuntu-devel [08:54] _ion: thanks [08:55] twb: As for the Policy discussion, except for very rare political exceptions (like the DFSG thing, for instance), we *do* stick to Debian Policy, and not doing so would very much be a bad thing. === seb128_ [n=seb128@ANancy-151-1-103-133.w90-13.abo.wanadoo.fr] has joined #ubuntu-devel [08:55] Granted. [08:55] twb: And if you feel like discussing it further, you're welcome to take me to Blue Fire Grill and convince me further. [08:55] PS: I'm hungry. [08:55] infinity: ? the source never was essential afaik === twb just had vindaloo [08:56] Feed your archive admin, lest he become cranky. [08:56] hey seb128, hey doko, hey infinity :) [08:56] hi dholbach [08:56] doko: From the current python-defaults debian/control: [08:56] Package: python [08:56] Architecture: all [08:56] Essential: yes [08:56] Priority: required [08:57] infinity: yes, that's the binary === mvo [n=egon@i59F71381.versanet.de] has joined #ubuntu-devel [08:57] Err, yes. Yes it is. [08:57] I meant "check the source, it's not fixed" [08:58] You claimed "python" was no longer marked Essential in that version. [08:58] Or, as I suspect, we're talking past each other. === slomo [n=slomo@ubuntu/member/slomo] has joined #ubuntu-devel === ompaul [n=ompaul@gnewsense/friend/ompaul] has joined #ubuntu-devel === Gman [i=gman@nat/sun/x-930f83943f4d6900] has joined #ubuntu-devel [09:03] I want to create patches for `casper' in a way that is easiest for the Ubuntu maintainer to integrate. I suspect this means branching the bzr trunk (and registering the branch with launchpad?) Is there a tutorial document to walk me through this process? === hunger_ [n=tobias@pd95b0676.dip0.t-ipconnect.de] has joined #ubuntu-devel === viviersf [n=cain@196.44.1.98] has joined #ubuntu-devel === hunger_ [n=tobias@pd95b0676.dip0.t-ipconnect.de] has joined #ubuntu-devel === Eons [n=Eons@host-84-221-208-136.cust-adsl.tiscali.it] has joined #ubuntu-devel === ivoks [n=ivoks@161.53.50.54] has joined #ubuntu-devel === apokryphos [n=apokryph@87-194-86-227.bethere.co.uk] has joined #ubuntu-devel === dade` [n=dade@nectarine/admin/dade] has left #ubuntu-devel [] === dade` [n=dade@nectarine/admin/dade] has joined #ubuntu-devel [09:16] twb: https://wiki.ubuntu.com/BzrContributorHowto [09:16] Thanks. === raphink [n=raphink@ubuntu/member/raphink] has joined #ubuntu-devel [09:17] twb: actually, what would be easiest for me is if you take the Ubuntu branch and merge each debian feature on its own branch so I can pick & choose. [09:17] On its own branch, eh? [09:18] yeah, so since you're interested in the NFS support and such, just merge the bits relevant to that. [09:18]