[00:51] hello, how may I ask to, for reporting a problem on a canonical server ? [00:51] err. [00:51] who may ask to ? === Zic_ is now known as Zic === eldalion is now known as eldawlion [02:38] Why do the lpia PPAs always build faster? [02:40] tedg: Probably because they are not loaded down with arch all packages. [02:41] TheMuso: Ah, okay. Thanks. === pgraner_ is now known as pgraner [04:33] o/c [06:17] Good morning [06:17] * StevenK waves to pitti [06:18] hi pitti [06:21] kirkland: if you keep 'user=kirkland' in mtab, then umount works as user? I. e. it doesn't need an fstab entry? nice! the "mount as root" part was ok, AFAIR, right? [06:21] kirkland: ecrypts_private_owner=kirkland? that's not something umount currently understands; so you do want to patch mount after all? [06:22] kirkland: sync> will do [06:23] slangasek: "I can live with that"> If we disable LANMAN by default in intrepid, to put an end to it, and reenable it in hardy-updates, if you think that a gvfs patch to display a proper error message is too complicated for an SRU [06:24] slangasek: around? [06:24] pitti: I don't think it's too complicated for an SRU; I do think it would take too long to include in 8.04.1. [06:24] nxvl: vaguely [06:25] slangasek: i was wondering about the delay on alpha1 [06:25] slangasek: is there some page or something with a list of what's needed? [06:25] slangasek: that was because of the insufficient error reporting API in libsmbclient, so it takes some hacks to get the actual error cause? [06:27] nxvl: the short list is "debian-installer needs to be merged" [06:27] pitti: yes, the libsmbclient is POSIX-like, so detecting the right error would require some kludging to get out-of-band info [06:28] no smberrno or so? [06:29] kirkland: hm, I just did a "sync all" run, but ecryptfs wasn't amongst it; apparently it's not on ftp.uk.d.o yet? [06:33] slangasek: look like a looong and hard merge [06:34] nxvl: yes, it's in progress; merges are, of course, not very parallelizable [06:34] yup [06:35] but we can still have a bzr branch to work on it [06:35] well, that would be a strange way to handle merge conflicts, IMHO [06:36] mmm [06:36] yep, it could be [06:36] well [06:36] now i need to sleep [06:36] see you [06:36] slangasek: if you need some help on anything please ping me [06:36] :D [06:36] slangasek: actually its a common feature request for large-scale vcs's [06:37] slangasek: to be able to save and restore conflict state and collaborate on such things [06:37] lifeless: hmm, feels dirty to me, but ok. :) [06:37] nxvl: sure :) [06:38] slangasek: consider a merge with 2K conflicts [06:38] slangasek: parallelising that would save a lot of time off the process, if you could [06:38] lifeless: I would prefer to never have to consider one of those if I can help it ;) [06:38] slangasek: or even, imagine if debian and ubuntu were single vcs trees [06:39] mom is basically doing this by splitting the conflict set by package, but there are conflicts that are cross-package - they are artificially partitioned by our tool chain but need to be treated as a unit === persia_ is now known as persia [06:42] good morning [06:43] Hey guys just looking for the bugs channel and how to get involved with helping out a little... see it in the banner, see you around! [07:17] Yikes... People are using the [[FullSearch()]] macro on wiki.ubuntu.com in their personal pages to list all pages with their wiki name in instead of using links. That might be stressing the server doing many searches. :-/ [07:20] philwyett: if so, then its a bug in the wiki [07:20] Indeed [07:23] Going by the limited docs, it's usage is not restricted and is doing the correct thing and listing pages containing the calling pages title string which is the users wiki name. Where would I file something like this do you think? === tkamppeter_ is now known as tkamppeter [07:25] If it slows down the wiki, probably whereever one is supposed to file bugs agains the wiki engine in question. [07:27] I will dig further and see if can be corrected at the server now or it should be file at MoinMoin. === LucidFox is now known as LucidFox_away [07:56] * philwyett laughs. Well [[FullSearch()]] is not a bug it's a feature. Listed No.1 in the performance cpu and I/O usage hit parade on the MoinMoin site. Educating users is suggested. :-) === LucidFox_away is now known as StargateFox [08:08] philwyett: Fixing MoinMoin is suggested. :-) [08:13] ion_: I will put in an RFE with MoinMoin, but also mail the Ubuntu webmaster and discuss. There are 432 instances of it's use on the wiki, so only a medium large job to correct the bad usages. :-) [08:17] s/correct the bad usages/workaround the wiki bug/ [08:18] :-) === freeflyi1g is now known as freeflying [09:01] macslow: Hi [09:01] macslow: Btw, the keyboard layout indicator in gnome-screensaver’s unlock dialog doesn’t share the background gradient. [09:01] greetings ion_ [09:01] ion_, that's "fixed"... [09:02] Alright :-) [09:02] ion_, in the way that there is no more gradient as it was decided against the gradient [09:02] Oh, ok. I kind of agree with that. [09:02] ion_, but otherwise it would have been fixed too by now :) [09:03] ion_, sadly there are still a couple of issues with some widgets and RGBA-colormaps [09:03] ion_, but if we don't stress it, issues don't turn up and we don't know that we need to fix them [09:04] Yeah === StargateFox is now known as LucidFox [09:19] is there a "common" way to specify dns server for static interface definitions in /etc/network/interfaces ? [09:24] asac: Hi! Any news about language-pack-es-base bug #240028? [09:24] Launchpad bug 240028 in language-pack-es-base "Problem in language-pack-es-base order installation makes Firefox translations lost" [Undecided,Confirmed] https://launchpad.net/bugs/240028 [09:30] when running dpkg-buildpackage on a project i get "dpkg-shlibdeps: failure: no dependency information found for" - anyone know where this is fixed ? i have a depends line in my debian/rules file. === RAOF_ is now known as RAOF [09:32] asac, RicardoPerez: ah, we figured it out (bug updated); I'll fix it [09:33] Doris: Better to ask packaging questions on #ubuntu-motu. Also, you generally want the dependencies in debian/control, rather than debian/rules. [09:33] pitti: oh, great! [09:48] sorry i did mean the control file [09:48] ill try motu though, thanks :) [09:49] cjwatson: *phew*, dhcp3 merge finally done and uploaded (adopting our patches and sending them all upstreamwards took a while) [09:54] pitti: I can do all the testing you want, if you need it... [09:55] RicardoPerez: I at it already [09:55] RicardoPerez: I'd upload them to hardy-proposed, then you test, and if it's confirmed to work, I'll copy them to -updates [09:55] RicardoPerez: works for you? [09:56] pitti: great, of course! [09:56] pitti: you only need to notify me when the updates are in hardy-proposed, in order to test them [09:56] RicardoPerez: will do; thanks! [09:57] pitti: thanks to you :) === asac_ is now known as asac [10:05] mvo: bug 222000 still has issues. If you want, I can look at it myself. [10:05] Launchpad bug 222000 in axyl-lucene "Update from Gibbon to Heron failed" [High,Confirmed] https://launchpad.net/bugs/222000 [10:06] pitti: woo, thanks; if that turns out to be enough to build d-i (unfortunately it's hard to tell in advance), I'll upload it [10:07] cjwatson: still needs to pass NEW (new -ldap package), I'll watch it [10:10] what package should I use for filing a bug on the absence of sound if I don't have the first idea about what the cause is? [10:11] DktrKranz: that would be nice, I looked at this and fixed some bits, but there are other issue left I think [10:12] mvo: thanks, I'll look at it more deeply. [10:12] thanks [10:14] mdke: what sounds? [10:15] seb128: all [10:16] since asking the question I've found some info on the debug page on the wiki [10:16] I'll follow those instructions, sorry for the noise [10:17] mdke: I guess trying aplay first is a good idea [10:17] pitti: there's a delay in the hardy-proposed packages to be updated, isn't it? [10:17] RicardoPerez: yes, they need to build now, and then publish, I'll shepherd that [10:18] RicardoPerez: they should hit archive.u.c. at 1100 UTC [10:18] seb128: ok, I'll try that too, thanks [10:18] pitti: ok, great, i'll wait then :) [10:45] pitti: dhcp3-server-ldap is in NEW now for all but hppa [10:47] pitti: indi is compiled now for that MIR, I realise the reason it wasn't uploading before is it used to be part of kdeedu (and so the version number was too low), so maybe it doesn't need a MIR? [10:48] oh, doko is on the conference [10:48] Riddell: I'll have a look soon [10:48] Riddell: right, I just poked indi to build so far, so that it can actually be reviewed === devfil_ is now known as devfil === LucidFox is now known as JapaneseFox === Traxer|off is now known as Traxer [11:25] guys, when i tried to chroot on ubuntu from sabayon , i successfuly chrooted but i wanna run a gui application from ubuntu, i got "Error: cannot open display: :0.0" , i export the DISPLAY variable, and used xhost , but i got the same error [11:25] http://pastebin.ca/1048997 [11:25] details [11:26] any idea [11:31] I use things like http://people.ubuntu.com/~cjwatson/tmp/chroot-enter (see also chroot-setup and chroot-teardown) to deal with that sort of thing [11:31] don't use xhost [11:31] the reason it can't resolve your DISPLAY is that you haven't bind-mounted /tmp/.X11-unix so it can't find the socket [11:32] xhost is fine if you use xhost +SI:localuser:foo, though. [11:32] but you still need that bind-mount, yes. [11:35] thanks , i'll try that [11:40] pitti: dhcp3-server-ldap in main or universe? [11:40] Riddell: main should be fine, I think; the server guys should be happy about it [11:42] pitti: shouldn't it conflict with dhcp3-server since they both contain /usr/sbin/dhcpd3 ? [11:42] Riddell: no, it diverts dhcpd [11:42] Riddell: thus -ldap even depends: on dhcp3-server, for reusing the init script, config files, and other infrastructure [11:42] right [12:04] pitti: I've noticed that only language-pack-es & language-pack-es-base has been updated. Is it right? [12:31] RicardoPerez: no, also -pt and -zh [12:31] RicardoPerez: or what do you mean? [12:41] Riddell: hm, libsbigudrv-dev doesn't ship any header files? [12:42] Riddell: also, indi seems to deal with quite special hardware; do we have any of this for supporting this? [12:43] pitti: right, the header files are duplicated in kdeedu [12:43] pitti: no, can't say I have any telescopes [12:45] Riddell: so, not having it in main would entirely disable that part of kdeedu instead of just having it in universe (which would be ideal), right? [12:46] * ogra_cmpc fears thats kstars [12:46] pitti: yes [12:46] ogra_cmpc: yes [12:47] Riddell: ok, then I guess you want to have it in main [12:47] pitti, if Riddell doesnt, i do [12:47] ok [12:48] so, promoted [12:48] unkless you have any equivalent to kstars i could take :) [12:48] Riddell: the -dev package still looks broken, though [12:48] pitti: how so? [12:48] RicardoPerez: the langpacks are on archive.u.c. now, ready for testing [12:48] Riddell: no header files [12:55] Riddell: qca2 doesn't contain any crypto functions on its own, right? [12:56] pitti: I'm afraid I don't know [12:56] ok, I'll have a look [12:59] hey guys, just a short question: i looked at #156204, checked it and wrote a six line patch for pidgin-otr to enable creation of files with 0600 instead of 0644. [13:00] morning [13:00] no my question is if i should mail this patch to the debian maintainer, attach it to the bug report [13:00] or... whatever === JapaneseFox is now known as LucidFox === pedro__ is now known as pedro_ [13:07] ccm: hi, so the bug is in the pidgin-otr package, and not pidgin? [13:07] pitti: I'm working on it :) [13:07] james_w: yes. but i got already two answers instructing me how to proceed [13:12] pitti: I'll do a fresh install, then an update, to be really sure the fix works [13:14] infinity: do you know why openhackware hasn't built? I'm not sure what to do with bug 217432 [13:14] Launchpad bug 217432 in openhackware "Please build openhackware 0.4.1-3" [Undecided,Fix committed] https://launchpad.net/bugs/217432 [13:30] Riddell: see I it correctly that openhackware 0.4.1-3 has no build records? neither for hardy nor intrepid [13:31] geser: It has to be manually built. [13:32] IIRC, openhackware is/has an arch all package that can't be built on i386 (sic) - soyuz doesn't support that [13:32] right, it's in Pas: %openhackware: powerpc # per Guillem Jover [13:47] mvo: motu-sru don't like your proposal for bug 231098 [13:47] Launchpad bug 231098 in ubuntu-restricted-extras "Please add sun-java6-jre and sun-java6-plugin to *ubuntu-restricted-extras" [Wishlist,Fix committed] https://launchpad.net/bugs/231098 [13:50] Riddell: thanks, I'm answering now [13:52] Riddell: don't think he is in motu-sru [13:52] norsetto: hmm? [13:52] norsetto: I asked Riddell to respond to his comment. [13:53] * ScottK is in motu-sru [13:53] ScottK: ah ok [13:53] * mvo answered now [13:54] Riddell: I'm not MOTU SRU. I'm just an opinionated MOTU. [13:56] anyone know where is "doko" ? [13:57] Coren`: This is the right place to ask, but providing context will often generate a more full response. [13:57] oi [13:58] I notice ia32-libs in ubuntu includes alsa plugins. [13:59] likely for flash [13:59] we'd love to provide this in lib32asound-plugins, but we really don't grok biarch, I wonder if someone from the ubuntu core team would be able to tackle that [13:59] persia: ok, I will give more context [14:00] persia: he has forgotten to add a file into ooo-build svn [14:00] nothing really serious, but I am pretty confident that he is the only one which has the file available [14:01] Coren`: Ah. Put that next to his name, and there's a chance that he'll see it in backscroll, and add the file. [14:01] persia: good idea [14:01] mmh .. he can see irc logs even if he is not connected ... [14:02] who's the biarch dude? doko? [14:02] well, whatever, doko, please addd writer-default-font.diff to ooo-build svn whenever you can, thanks [14:04] doko? [14:07] Coren`: you want to talk to calc about OO.o patching [14:07] pitti! [14:07] hey jordidude! how are you? [14:07] pitti: besides doko, any others who I could mail regarding biarch matters' [14:08] pitti: all is well. dude, I saw pics of you, lots, from UDSS [14:08] -S [14:08] nice beard :) [14:08] pitti: thanks, but calc cannot help me on this one [14:08] jordi: *scratching head* look how lib32readline5 or lib32z1 are built? [14:08] jordi: thanks [14:08] (as far as i know) [14:09] pitti: see above; we need help to create a biarch alsa plugins package [14:09] we already build lib32asound [14:09] people want lib32asound-plugins [14:09] Ubuntu actually sticks the plugins in ia32-libs, but that's ugly, of course [14:14] jordi: yes, absolutely [14:14] Coren`: people rarely read IRC logs from when they aren't connected; please send e-mail [14:15] jordi: ia32-libs should ideally disappear; it's a PITA and a hack [14:15] jordi: in an ideal world you could just apt-get install the _i386.deb on amd64, and we'd avoid all the multibuild stuff and ia32-libs *dream* [14:16] cjwatson: he has an email @ubuntu.com ? [14:16] Coren`: yes [14:17] ok, thanks cjwatson [14:18] mvo and Riddell: I acked the SRU for bug 231098 conditional on adding amd64. [14:18] Launchpad bug 231098 in ubuntu-restricted-extras "Please add sun-java6-jre and sun-java6-plugin to *ubuntu-restricted-extras" [Wishlist,Fix committed] https://launchpad.net/bugs/231098 [14:19] * norsetto wonders why java packages are arch dependent [14:23] I have send it, thanks again cjwatson, pitti and bye everyone [14:24] bdmurray: any chance that you can generate the DB queries on https://devpad.canonical.com/~brian/ with "psql -At"? this will suppress the table header and footer, and the leading whitespace [14:28] norsetto: sun-java6-plugin doesn't work properly on amd64, I believe; 64-bit support was pushed out to JDK 7 [14:29] * ogra_cmpc wonders what's the reason for gpg stealing his terminal if a passphrase was mistyped three times or a passphrase input was canceled [14:30] i mean, if i have to execute reset anyway, gpg could do that for me as well on exit [14:31] cjwatson: I was just curios in a general way as why a java package was arch dependant (don't know what that particular one does) [14:31] ogra_cmpc: usually just a bug in terms of forgetting to turn the echo flag back on in some code paths [14:31] ah [14:32] terminal settings are per-terminal rather than process-specific, so the process has to take care to restore them [14:32] right, wso i should file that against gpg i guess [14:32] and if it forgets (often due to being interrupted by a signal that it doesn't handle properly, but not always) then you can end up with echo left off [14:33] yes [14:33] right, thats what i see (actually since ages, but it didnt bother me enough yet) [14:38] pitti: hiya [14:39] pitti: http://packages.qa.debian.org/e/ecryptfs-utils.html shows 48-1 is in unstable [14:39] hi kirkland, how's it going? [14:39] pitti: good, i made some good progress yesterday with help from slangasek and kees [14:39] pitti: i created a C program for umount.ecryptfs, setuid [14:39] kirkland: hm, looks like it's on ftp.uk.d.o now, too [14:39] * pitti runs a sync [14:40] kirkland: FWIW you don't normally need to ask for syncs of unmodified-in-Ubuntu packages until DebianImportFreeze (26 June) [14:41] cjwatson: by that you mean they happen automatically? [14:41] semi-automatically [14:41] as in, an archive admin runs some stuff roughly daily which slurps everything in, in bulk [14:41] cjwatson: right, but if I want it to happen "now", i was told to ask pitti.... [14:41] if you're desperate for it to happen in sub-day timeframes, yes :) [14:41] right, I tried this morning, but ftp.uk.d.o. seems to be pretty behind [14:42] hm, sorry, ftp.uk's Package lists still seem old [14:42] still not autosynced [14:43] you could always just switch ~lp_archive/bin/update-sources over to some other mirror [14:43] wouldn't be the first time :) [14:44] ah, we can still do that? [14:44] I thought it'd all be buried in LP code now [14:44] syncorigins.py downloads from ftp.d.o anyway ;-) [14:44] update-sources isn't [14:44] ah [14:44] syncorigins.py *ought* to be under our control but isn't [14:46] pitti: you mentioned force-syncing *just* ecryptfs-utils last week.... is it possible for me to use those scripts and do that, pushing to my PPA instead of the real Intrepid archive? [14:46] (that assumes PPA have started building Intrepid binaries, which it wasn't last I checked) [14:46] you can't use the LP scripts, but you can always upload the same thing manually to a PPA [14:47] just need to construct a suitable .changes file ... [14:48] kirkland: anyway, I see (from happening to have a shell there) that pitti is in the process of syncing ecryptfs-utils now, so don't worry about it [14:48] cjwatson: or, if the deb is completely unchanged, I should in theory be able to use the Debian .deb, right? [14:48] kirkland: not 'force', but 'fake'; yes [14:48] kirkland: yes, I switched to ftp.debian.org, which seems to be better ATM; sync coming in [14:48] pitti: cool, thanks [14:48] it is often possible to use Debian .debs with some care [14:48] cjwatson: not "deb completely unchanged", but "package unmodified" [14:49] kirkland: http://people.ubuntu.com/~pitti/scripts/syncpackage is the script I am using [14:49] ah, right, different tool chain..... [14:49] kirkland: like I say :) [14:49] pitti: thanks, i'll take a look [14:49] kirkland: it constructs a suitable source.changes from a .dsc [14:49] or why not just download the source and build it yourself if you're in a rush to test with it [14:49] kirkland: but use it with a grain of salt, and only after proofreading that the .changes has the correct changelogs [14:49] cjwatson: that's what I've been doing [14:49] cjwatson: i've been working from the upstream's git [14:49] perfectly reasonable for local testing [14:50] cjwatson: testing/building/running that [14:50] cjwatson: patching against that, sending upstream [14:50] cjwatson: when the upstream maintainer takes them, he'll do a version bump [14:50] * ogra_cmpc scratches head why the cmpc kernel doesnt show up in the PPA [14:50] cjwatson: if the debian packager doesn't pick up the change within a week or so, i'll ask him to bump up the unstable version [14:51] cjwatson: he's been very kind and responsive [14:51] once it's built in debian, i pull that dsc and build and test locally on Ubuntu [14:51] cjwatson: then i usually ask pitti for a sync, if it hasn't happened [14:52] cjwatson: how does that workflow sound to you? [14:52] there, all synced and uploaded [14:52] pitti: big thanks ;-) [14:53] * ogra_cmpc sighs and actually gives the right option to dput ... [14:55] Would there be any problem with me doing the merge/sync for boost? It's blocking at least two merges in Universe atm. [14:56] pitti: unfortunately we're not in that ideal world yet ;) [14:59] Laney, i doubt anyone would complain if you do the work, but contact the former uploader/maintainer (see http://merges.ubuntu.com) and have him review it or so [14:59] ogra_cmpc: Yeah, I've just not done one for main before so thought I'd check in here ;) [14:59] boost is in main, so you will need a main sponsor anyway [15:00] jdstrand: You were the last uploader of boost. Do you mind if I work on the sync/merge? [15:00] ogra_cmpc: :) [15:00] Laney: you'll want to ask zul-- he asked me if he could do it [15:00] (and I said yes) [15:00] jdstrand: Ah, right. [15:00] Laney: go ahead [15:01] zul: Thanks. Will do now. [15:02] jordi: so, I haven't done multiarch building myself either, so I'm sorry that I cannot give you hints for that [15:03] pitti: oh, i just saw another post from you to me at Jun 17 00:21:37 ... [15:03] kirkland: if you keep 'user=kirkland' in mtab, then umount works as user? I. e. it doesn't need an fstab entry? nice! [15:03] pitti: that would seem the case from the umount manpage, but in practice that's not what's happening.... [15:04] pitti: i haven't inspected umount's code yet (on today's todo list), but empirically, umount checks existence in /etc/fstab FIRST, and errors out if there's no entry [15:04] kirkland: I wonder whether it would be too evil to modify mount itself to (alternatively) accept user= in mtab [15:05] user Allow an ordinary user to mount the file system. The [15:05] name of the mounting user is written to mtab so that he [15:05] can unmount the file system again. [15:06] pitti: well, either the code or the manpage needs updating, i agree with that [15:06] kirkland: ^ the manpage seems to indicate that it's meant to be like that [15:06] pitti: slangasek's objection to changing the code was mainly that that cannot be done haphazardly..... [15:06] so umount should continue to check fstab for the people who have /etc/mtab -> /proc/mounts [15:07] pitti: yep, your reading and my reading of the manpage agree [15:07] of course people who do have that won't be able to use your ecryptfs-umount either then [15:07] pitti: however, my test case looks like.... [15:07] pitti: any reason that new versions srus don't move to hardy-updates? ie tomboy is a new tarball upstream specially rolled to fix one bug and has been uploaded 18 days ago [15:08] pitti: 1) add fstab entry allowing user=dustin to mount a filesystem, 2) have user=dustin mount the filesystem, 3) become root and comment out that fstab entry, 4) have user dustin umount, and umount fails saying entry is not in fstab [15:12] re [15:12] argh, that was the dumbest action ever [15:12] I dropped a piece of chocolate, and it flew straight to the power plug, hitting the switch [15:13] seb128: usually the reason is that nobody gave testing feedback on the SRU bug [15:13] kirkland: last thing I got from you was "however, my test case looks like...." [15:13] pitti: 1) add fstab entry allowing user=dustin to mount a filesystem, 2) have user=dustin mount the filesystem, 3) become root and comment out that fstab entry, 4) have user dustin umount, and umount fails saying entry is not in fstab [15:13] pitti: weird that got dropped [15:14] pitti, a "piece" ? [15:14] ogra: half of an Easter bunny :) [15:14] * ogra looks at his switched powerplug ... it would need at least two bars of chocolate to switch [15:14] evidently germans have large pieces of chocolate! [15:14] pitti: well, for new versions bug we could say that the no feedback is a good sign ;-) [15:14] kirkland, we're not swiss ... we'Re the ones with the big sausages ;) [15:15] seb128: are you using tomboy, and the actual hardy-proposed .debs? [15:15] ;-) [15:15] well, with 80 cm of acceleration, even a small piece evidently has enough impulse to flip the switch... [15:15] pitti: yes [15:16] seb128: can you please say so in the SRU bug then? that's the kind of feedback I want to hear :) [15:16] seb128: (and yes, we should push for verifying all the currently pending stuff and get it to -updates ASAP) === pgraner_ is now known as pgraner [15:21] asac: re. gnome-mplayer, I just sent a patch upstream to fix some license/copyright issues for translations. We therefore have some time since I would like to upload the newer version (to avoid being rejected) [15:29] norsetto: oh ok. thanks for looking into it [15:29] let me know when the bits are ready to go up ;) [15:29] asac: sure [15:42] asac: did you hear any regressions with ffox/xulrunner rc2? 7 days in -proposed have elapsed [15:49] c [15:49] Ups [15:54] ogra: I'm a bit worried about the ltsp verification; none of the bugs got any feedback so far :( [15:55] ogra: once we get a couple of "I have used that updated version for a few days in my production environment", I'm happy, but we didn't [15:59] kirkland: workflow> sounds normal and reasonable [15:59] cjwatson: thx [16:06] ooh, looks like d-i roughly builds now [16:08] cjwatson, I thought you fixed the PPC build failures for Xubuntu. [16:08] cjwatson, I'm still getting notifications of failures. [16:08] you thought wrong ;-) [16:08] I just suggested a possibility for fixing it [16:09] and put some provision in place to make fixing it possible [16:46] pitti: no they are fine. we should wait till 10:00 PDT and release them [16:46] thats 1900 our time i think === thekorn_ is now known as thekorn [17:36] pitti: ok i am off now for 1h ... if you are around, please push xulrunner-1.9 and firefox-3.0 at 19:00 our time (or slightly in advance). thanks [17:36] (to -updates) [17:45] cjwatson, okay :) === qense is now known as qense|dinner [18:39] pitti, well, as i predicted, ltsp users are reluctant to upgrading their chroots (thats why its important for me to get it on the 8.04.1 CD) ... all i can say is that i verfied all of the fixes and am running ltsp here with them successfully since without problems ... afaik stgraber verified two of them as well [18:40] ogra: yep I did, I'll try to verify the lts.conf ones (X parameters) too [18:40] that would be great [18:51] slangasek: do you happen to know what is currently holding OOo out of updates? [18:51] or is it just a time thing? [18:52] calc: the SRU policy, which states there's a 7-day waiting period barring exceptional circumstances? :) [18:52] slangasek: ah ok === qense|dinner is now known as qense [18:58] Is there a good reason that I have to do "(cd mypackage; debuild)" instead of "debuild mypackage"? [18:58] It's mighty annoying that debuild and dput have to be done in different directories. [19:00] any one familiar with script? I want to erase all the first characters "+" of each lines in the diff file, how to do it? [19:01] tedg: I'm going to take it as assumed that any reason given would not be accepted as a good reason. :) But you could write "tedbuild" which wraps debuild... :) [19:01] fqh: why would you want to do that? If you do that, what you have is no longer a patch... [19:05] slangasek: Actually, it is a completely new c source file. so all line starts with "+". after erasing "+", my tool will be able to parse that source file [19:05] fqh: sed -e's/^\+//' [19:06] slangasek: I'd rather patch debuild to do it right :) [19:06] slangasek: thanks very much [19:07] tedg: I think any syntax you would come up with would be less optimized for the common case than just running "dput ../foo.changes" ? [19:07] since typically, one edits a package before building it [19:08] * ScottK agrees with slangasek. [19:09] and all the output of dpkg-buildpackage/debuild usually has the ../ if you are in the source dir [19:09] * ogra finds that very convenient for copy/paste [19:10] I don't ever edit the package before building it. I'm always editing the debian directory in the VCS and then copying it over. [19:11] So it's something more like "tar -xvzf mypackage ; cp -a vcs/debian mypackage ; cd mypackage ; debuild ; cd .. ; dput mypackage" [19:11] oh, well, keeping only the debian directory in the VCS is its own kind of breakage ;) [19:11] * mvo raises a eyebrow [19:12] putting the whole source package in vcs makes sense to me. whether it's feasible today's another story [19:21] * tedg is going to laugh when slangasek gets hit with the bazaar packaging dunk tank :) [19:22] like the grub package that I put into bzr myself for maintenance? [19:29] Where are you putting the bazaar branches for the packages? I put them under "~ted-gould//ubuntu-packaging" -- I didn't know if they should go under /ubuntu/ or something different. [19:32] stgraber, ogra: fine; can you please say so in one of the bug reports? [19:33] asac: ok; I guess we can move them now then? [19:34] asac: ok, seems slangasek beat me to it [19:38] tedg: for grub, it's https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu (i.e., a shared branch committable by all of core-dev) [19:38] one can obviously have other personal branches too [19:38] hey cody-somerville! what environment does xfce set when it runs? something like XFCE_SESSION or XFCE_SESSION_ID or something like this? [19:39] to detect if a session is running [19:39] tedg, but its not necessarily , you have to make a LP project for that part of the branch name [19:39] slangasek: Hmm, that'd imply that I'm core-dev ;) [19:40] tedg: well, if it's a package in main, the official packaging branch (and the one represented in the Vcs-Bzr field) ought to be one that core-dev can commit to... :) [19:40] tedg, so in the case for the mythbuntu project, we have about 15 branches out there, so we push them to ~mythbuntu/mythbuntu/ for sanity [19:40] or the subset of core-dev that maintains the package in practice, I guess, such as ubuntu-desktop [19:41] mario_limonciell: Ah, but I usually have "ubuntu-packaging" and "debian-packaging" -- so I guess they'd become "-..." [19:41] tedg, all the more reason to make shoe packaging the same :) [19:41] shoe=those [19:41] slangasek: Well, having a branch that core-dev can commit to does me no good, as I'm not core-dev. But ubuntu-desktop would be interesting. [19:42] pwnguin, it's perfectly feasibly to have the entire source for a package in a bzr branch (been there, done that...) [19:42] it just gets a wii bit slow when you have a very large source package and need to do a full checkout somewhere [19:43] tedg: the commit rights on the "official" packaging branch should match the commit rights in the archive; that's certainly the game plan for the eventual everything-in-bazaar scheme. You would just prod someone to merge your branch (&& upload), rather than prodding to upload [19:43] pitti, ok, commented on all of them, the NBD_PORT one actually got some more feedback :) [19:44] slangasek: While I see what you're saying, that'd be very annoying for me personally. [19:44] ogra: thanks! hm, I wonder why I didn't get mail about it; is ubuntu-sru sub'ed? [19:44] ogra: anyway, I have the bug list here, I'll look at that [19:44] thanks [19:45] yep, "SRU Verification" on all of them [19:45] are there any packages still in debian/ubuntu that require explicit distribution as patches? [19:46] I receive mail notification only for one of them (so far), maybe LP is a bit slow with bugmail [19:46]