=== jtechidna is now known as JontheEchidna === xfg is now known as zul [04:27] lifeless: hi, would you know why http://package-import.ubuntu.com/status shows 8 jobs running since Sunday, and 926 pending? [04:29] no I don't [04:29] but I can try to find out [04:29] I suspect they're all borked. [04:30] actually, this is ops, time to agitate a little ;) [04:30] losa ping [04:34] lifeless: I have no idea what system that even is. I shall investigate. [04:34] spm: ahha :) [04:34] spm: so, I do; I think I even have a login to debug things [04:34] but I think really, that we should be productising it, not fiddling. So I'd like to get whatever the failure is turned into a losa-filed-bug on udd [04:34] ah. coolio. hints appreciated :-) [04:35] spm: what was the first db server, ever :) [04:36] Oh I see. right. wonder if I still have a login there.... [04:37] ew. that looks *badly* hung [04:37] ok [04:37] so issues:\ [04:37] - no alert to tell you that it was in trouble [04:38] - no docs telling you where to go [04:38] - and the hang itself [04:38] anything else you can think of? should we do an actual incident report here [I don't think so, its overkill, I think] [04:38] heh. no privs to do anything about fixing it. this is in one of those greyish areas of ownership I'd suggest. [04:38] - no privs [04:38] ok [04:39] was it tungsten ? no. [04:39] darn, I've forgotten the actual machine name myself [04:39] jubany [04:39] thats right [04:40] istr this is a james_w special, but I'll ask paul to have a look. he may be able to see enough to effect a fix [04:40] actually, emperor was the first db server, FWIW [04:40] *I think* [04:41] haha. yes. james_w. "...please email James Westby." [04:41] right [04:41] except thats now stale [04:42] the handover-to-production step isn't complete though [04:43] odd [04:43] I can log into chinstrap, but logging in jubany is appearing to time out [04:44] spm: you logged in ok ? [04:47] spm: ok, so look up [04:47] do you agree with the list of issues [04:48] there's an implicit root cause we can think about later [04:48] in general terms? yeah. issues around who should have ownership may superceed some of that; but that's just usual politics. :-) [04:49] I know james_w wants more folk to help out [04:49] thats why I have a login [04:49] it doesn't make sense to me for losas not to, though [04:49] so I'll file some bugs [04:49] and raise some questions, and what comes out, comes out [04:51] what should I do, to these bugs, to say 'losa should care about how/when resolved' ? [04:52] just add us as subscribers, or point me at 'em and I'll do it [04:52] lifeless: Wasn't it discussed at UDS about transitioning the UDD stuff to be more 'production' and IIRC losa supported? [04:53] ScottK: I didn't get to all the udd sessions [04:53] ScottK: but meh, just doing it:) [04:53] its clearly the right thing to do [04:53] lifeless: slacker!! [04:53] bug 524173 [04:53] Launchpad bug 524173 in Ubuntu Distributed Development "package-import uses james_w credentials" [Critical,Triaged] https://launchpad.net/bugs/524173 [04:53] spm: hey, bzr sprint concurrent, balance in all things [04:53] Right, well I think it was actually agreed that this would happen, so you're DTRT... [04:54] I can't seem to strace any process right now [04:54] james_w: shouldn't you be in bed!?!? :-) [04:54] james_w: if you're trying 29087 I'm stracing it [04:54] james_w: go sleep, I'll track this down and so on [04:54] lifeless: (bzr sprint concurrent) and here I was thinking you're a demi-god; turns out you're merely superhuman. shame. [04:54] james_w: in particular, please don't unbreak it. [04:55] james_w: because I want to get solid diagnostics and may end up roping in a gsa to install debug python stuff if needed. [04:56] right, it can be got to work again by just killing all the import_package.py processes that are currently running and it should pick up again [04:56] but if you can work out what socket it is hanging on that would be great [04:58] james_w: sure, will do my best [04:59] spm: bug 589521 [04:59] Launchpad bug 589521 in Ubuntu Distributed Development "nagios monitoring of package imports needed" [Critical,Triaged] https://launchpad.net/bugs/589521 [04:59] james_w: where did you say your docs where ? [04:59] subbed to 'em both [04:59] [if you haven't gone to bed yet :P] [04:59] https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood/Importer/Operational [05:00] fwiw there's an open RT for the last one [05:00] losa privs ? [05:00] whats the rt # [05:00] (those docs can be found from following links from https://wiki.ubuntu.com/DistributedDevelopment) [05:01] spm: can you look at them and decide if you want them there, or a copy in your losa wiki area, or a pointer or whatever ?\ [05:02] hmm, can't find it, there's already a nagios script there for hooking up, and I'm sure I put it in an rt [05:02] anyway, night [05:02] gnight [05:11] spm: bug 589523 - for when looking at hung jobs, to come along and say 'still happening' [05:11] Launchpad bug 589523 in Ubuntu Distributed Development "mass importer doesn't handle hung-inactive processes" [Critical,Triaged] https://launchpad.net/bugs/589523 [05:15] spm: rt 39615 [05:20] spm: but the other rt i filed seems to have gone awol - no reply from rt [05:20] spm: the other one was for bug 589521 [05:20] Launchpad bug 589521 in Ubuntu Distributed Development "nagios monitoring of package imports needed" [Critical,Triaged] https://launchpad.net/bugs/589521 === oubiwann is now known as oubiwann_ [05:50] lifeless: (sorry was at lunch) given the docs are already wiki'd, it makes sense (to me, anyway) to leave 'em in place for now. with pointers from our collection to same, if we generate stuff that shouldn't be there, that can be dealt with if'n when it arrises [05:55] spm: right, I'm just saying, I'm not going to file a bug 'please document for losas' [05:56] as you know where it is right now, you can capture that now :) [05:56] heh [06:26] spm: and bug 589534 [06:26] Launchpad bug 589534 in Ubuntu Distributed Development "imports can hang when talking to free.hands.com" [Critical,Triaged] https://launchpad.net/bugs/589534 [06:27] kk [06:27] spm: and bug 589532 [06:27] Launchpad bug 589532 in Ubuntu Distributed Development "imports hang from time to time when talking to the mass importer" [Critical,Triaged] https://launchpad.net/bugs/589532 [06:27] ah. is that root cause? [06:30] My theory is this [06:30] free.hands.com locks up some imports [06:30] a bug in the control daemon causes it to stop handling stderr from other imports (fd 2) [06:30] then all the other imports lock up on progress bars or similar output [06:31] I've killed all the imports that were there and hung and its going again [06:36] coolio, sounds reasonable as a starter. === Amto`Off is now known as Amto_res [07:56] good morning === almaisan-away is now known as al-maisan === hrw|gone is now known as hrw === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [08:45] Sorry about that. It seems this channel would be more suited for my question. [08:46] I've been discussing a script for automatically optimising XML, SVG and PNG files on the Ubuntu LiveCD (and by extension, K/Xubuntu as well). Someone recommended that I code 3 debhelper scripts to perform these optimisations. I don't know Perl, and the dh_*'s in /usr/bin are made in Perl. What should I do? [08:47] Whoops. I've been discussing... on the ubuntu-devel-discuss list* And scripts to perform these optimisations... on all packages* [08:50] yay, kvm works again with the new kernel! === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [09:06] (Repeat from 20 min ago) I've been discussing, on ubuntu-devel-discuss, a script for automatically optimising XML, SVG and PNG files on the Ubuntu LiveCD (and by extension, K/Xubuntu as well). Someone recommended that I code 3 debhelper scripts to perform these optimisations on packages. I don't know Perl, and the dh_*'s in /usr/bin are made in Perl. What should I do? [09:06] some 9 people joined since that repeat, sorry if that's too soon for repeating [09:09] Cynthia, hi there [09:09] that sounds useful [09:09] Hi :) [09:09] what languages do you know? [09:09] I already have proof-of-concept code as a Bash script on the discuss list [09:09] ok [09:09] I know my way around Bash, Python, Java and uh... pretty much those [09:09] so i don't know a lot about the internals of this but i would think that if you have code in bashe [09:09] (bash [09:09] *bash [09:10] it would be pretty simple for somebody to add a line or two of perl to call them [09:10] or are people specifically asking you to rewrite it? [09:10] The problem is that the script I wrote acts on the LiveCD's iso, not packages [09:11] And someone on -discuss said that the code would be better rewritten as dh_*'s so upstreams (Debian, etc.) could use them [09:11] huh [09:11] would i be right in thinking you can run "optimize_stuff *jpg *png" and it works? [09:11] or is it more complicated? [09:11] The second option was to "add this to package-mangler run by soyuz", which I'm unfamiliar with [09:12] not really, poolie, because OptiPNG, Scour.py (for SVG) and xmllint each have their own calling conventions and the file types are completely different [09:13] Plus, *.glade, *.ui and some more files also have an XML format, so dh_xmlopt would need to handle those with some debian/ file or command-line arguments [09:13] ok but basically it takes in a file and spits out a smaller equivalent file? [09:13] Yeah [09:13] That's the gist of it [09:14] so [09:14] during debian packaging, there'll be a build directory containing the files that are about to be packaged [09:14] this is controlled by some complicated machinery inside debian/ [09:14] what _I_ would try next if i was doing this is just patching those tools in to debian/rules [09:14] Aye, I gathered this from the dh_* scripts already on my machine :) I can read Perl, just not write it :( [09:15] to get the files squashed before the package is assembled [09:15] hm [09:15] and then put it into the dh_ scripts [09:15] btw does it make much of a difference to the size of the iso? [09:15] It trims 11.x MB [09:15] out of 600-800MB? [09:16] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-May/011504.html Here's a thread from the archives if you'd like to skim what I've done so far [09:16] 699 MB [09:16] so my ISO is 687.x MB right now [09:18] I'll actually download a source package before continuing about this, because I have no idea really what debian/rules is made of [09:18] mm [09:18] i think you should branch the source for some package you think is both reasonably simple, and likely to be helped by this [09:18] without being broken [09:19] and have a look at http://www.debian.org/doc/maint-guide/ [09:19] which explains how it works, but not necessarily in the most obvious way [09:22] Oh... debian/rules is just a makefile! Guess I could just write 'find . -name "*.png" -print0 | xargs -P 2 optipng -o7' or something, right? [09:22] as a first step [09:22] it's not exactly right but it would get you going [09:22] But the preferred way would be to code a dh_ [09:23] or perhaps to patch it into an existing dh used to install these files [09:23] there's typically one per distinct class of thing to be installed [09:23] roughly [09:23] that will also give you a framework to say that some images can't be compressed [09:24] Well, obviously I wouldn't optimise lossy files like jpegs, because that would look very ugly :) [09:25] well, there may be some cases where the program doesn't like your changes [09:26] I'll see what I can do. And I'll read the debian maintainer guide (your link) to get started. But I can't guarantee anything for a Perl dh_. Someone would need to pick up where I left off for that. [09:27] I already know of some programs that don't like their XMLs stripped of whitespace, like gBrainy and gnome's theme thingy [09:27] but PNGs pose no problem [09:27] Thanks for the pointers :) [09:34] Oh yeah, there was something else in that LiveCD optimisations thread. Basically, seeking to different files on a CD is very costly, so I reordered the files within the CD with `mkisofs`'s sort file option. What would be my best bet to have *that* included in the LiveCD? [09:53] Cynthia: seems like the sort of thing that could perhaps reasonably be done as a patch to dh_compress [09:54] Cynthia: file a bug on the debhelper package in Debian with a pseudocode description of what you want done, and the upstream author will probably be able to offer useful advice [09:55] cjwatson: debhelper package... in Debian? does Debian use Launchpad, or would I need to post to a mailing list? [09:55] http://www.debian.org/Bugs/Reporting [09:55] thanks :) [09:55] (you'll probably need to use the e-mail method - but it isn't a mailing list as such) [09:56] basically mail submit@bugs.debian.org with "Package: debhelper" as the very first line of the message body [09:57] Would you also happen to know how I would get my sort file for mkisofs included in the ISO build process for Ubuntu, and perhaps Debian? [09:57] That's not a deb-packaging issue per se, but it's still a packaging issue... kinda :) [10:01] Even better would be to 'readahead' the LiveCD and put all the files in sequence, but what I have is just '/bin at the end of the CD' and stuff. === ara_ is now known as ara [10:10] * hunger grumbles that maverick alpha1 does not boot here:-( [10:15] Cynthia: is it a dynamically generated sort file? if so how do you go about it? [10:15] Cynthia: we actually already do some sorting [10:15] Cynthia: um, but surely this wouldn't be for mkisofs, but rather for mksquashfs? [10:16] Oh, that's nice then :D But my sort file is actually two, one for mksquashfs and one for mkisofs [10:16] Sorry for the confusion [10:16] Cynthia: in the latter case, we have the stub for sorting in place but it's never really been used [10:16] I'll paste them on ubuntu's pastebin [10:16] it really absolutely has to be generated on the fly somehow though - a hand-crafted sort file will just get out of date [10:16] that's the tricky bit [10:17] what mkisofs sorting are you doing? [10:17] our handling at the moment only really deals with udebs and debs [10:17] it would probably be worthwhile putting the live filesystem in front of that [10:17] Yeah, I thought about using 'readahead' for this. But mine's just hand-crafted based on broad assumptions about the general directories that files are accessed from on-boot [10:18] http://paste.ubuntu.com/444502/ Sort file for mksquashfs [10:18] right, we can't do hand-crafting I'm afraid - if you can figure out some way to express it programmatically given having the live filesystem to hand, we could look at incorporating that into livecd-rootfs [10:18] http://paste.ubuntu.com/444503/ Sort file for mkisofs [10:19] Cynthia: for the mksquashfs bit, could you file a bug on the livecd-rootfs package in Ubuntu? [10:19] Ok [10:20] so, wait, I don't get it, why force all that stuff to the end of the media with huge negative weights? [10:20] I thought that closer to the centre was generally fastere [10:21] *faster [10:21] On hard disks perhaps [10:21] doko__: have a minute? I found why gcc-4.5 failed for cross build for me [10:21] CDs are different [10:21] About using readahead though, this couldn't really be automated unless you have a VM to run the ISO on, on your ISO build daemon [10:21] I'm not considering hard disks [10:22] hrw: sure [10:22] doko__: http://paste.ubuntu.com/444508/ is ugly patch which solved problem for me. The reason for it is that gcc_cv_objdump is OBJDUMP_FOR_TARGET so it is ARM one but rdynamic check build host binary and then uses objdump to check for rdynamic support [10:23] cjwatson: the testing I've done reveals that my ISO boots about 10 seconds faster, and all applications start faster than on the "vanilla" 10.04 CD. This is wall-clock time [10:23] hard disks have higher throughout further away from the centre due to constant angular velocity - precisely the opposite of what I said above [10:24] perhaps the pressed CD made by Canonical is made with constant angular velocity then - but my burner does constant linear velocity [10:24] so when I burn it, it does a lot of noise at the start (centre) but then goes much quieter as it goes to the edge [10:24] actually, with CDs, isn't the important bit really locality? [10:24] minimise head movement and minimise the need to crank the velocity up and down [10:25] yes, because seeks are very expensive [10:25] hrw: hmm, would using using the binutils-multiarch binary help? [10:26] so locality first, and putting things to the end of the media for CLV burners or to the start of it for CAV burners. right? I'll bring that up in my bug report [10:26] ok, so moving the squashfs outwards tends to help because that means that it occupies less radial distance? [10:26] yeah [10:27] CAV => red herring I thin [10:27] k [10:27] it's not the burner that matters anyway, it's the reader :) [10:27] doko__: I have to check [10:28] so stuff like .disk and dists is probably not that relevant [10:28] .disk is read by casper at boot [10:28] I know [10:28] but it'll be near where it's reading directory entries, which are in the centre, right? [10:29] yes, the TOC is at the centre [10:29] so I think it would be better to keep .disk and probably the kernel and such weighted high [10:29] near the TOC [10:29] with .disk's *files* far away from isolinux, though, I could see the "ISOLINUX DEBIAN" screen for like 20 seconds with lots of seeks [10:29] that could work yeah [10:29] certainly close to isolinux [10:30] I agree it makes sense to try to cluster all the stuff together [10:30] dists shouldn't be used until much later [10:30] oh, wait, we run apt-cdrom during boot don't we [10:30] that's a bit unfortunate [10:30] That's the thing that creates the cdrom:[] entry for sources.list, right? [10:31] right [10:31] it's not in the live filesystem because we don't necessarily want it in the installed system [10:31] yes I see logs for it in /var/log from the live CD [10:33] ok, so this is the code that's dealing with mkisofs sorting right now: http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/annotate/head%3A/tools/sorting_weights [10:34] the kernel/initrd, .disk, and dists should automatically wind up right next to isolinux because the default weight is zero [10:34] but possibly right now the squashfs sneaks in first because it's weighted zero too [10:34] that's entirely possible [10:34] so how about I change that to weight the squashfs dead last, and see what effect that has? [10:34] be my guest :) [10:35] Is there a script for the mksquashfs sort file as well? [10:35] Cynthia: are you the poster of https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-June/011579.html? I'd like to credit properly [10:35] Yes [10:35] Cynthia: apt-get source livecd-rootfs, livecd.sh would be where it needs to go [10:36] at the moment, anyway [10:36] but it's just a stub right now [10:36] apt-get says something about bzr, should I get the very last version from bzr? [10:39] probably won't make lots of difference in this case, but sure - lp:~ubuntu-core-dev/livecd-rootfs/trunk [10:40] ok, so the next daily build should sort the squashfs last [10:41] hrw: which stage is this? [10:41] I know how to use Bazaar from my bout with Scour (Cleaning SVG Files), so maybe I could create a branch and edit the code. How about that? :) I'll file the bug and link the branch if I make code changes [10:41] Cynthia: are you in a position to compare timings between the last daily build and the next one? it would be nice to check the performance difference due to just that change [10:41] doko__: it was first, but looks like binutils-multiarch helped (I am during build now) [10:42] cjwatson: I have a CD-Rewritable I can use, and a stopwatch [10:42] * cjwatson remembers to re-enable daily builds after alpha-1 [10:42] I'll download today's build right now, seeing as it might disappear tomorrow. [10:42] doko__: if this one will finish then I will recheck without binutils-multiarch [10:43] yeah, it might be old enough to get auto-purged, so good plan [10:43] although today's build is just alpha-1, so you can get it from the URLs in the announcement, and that will stay around for a while [10:43] oh :) [10:43] hrw: yes, works around the problem. CC and gcc_cv_objdump have to match, maybe using CC_FOR_TARGET is the correct fix (but this doesn't exist in stage1). [10:44] hrw: and there are two objdump calls [10:45] Cynthia: thanks for looking at this, it's a tricky problem but worth solving [10:46] cjwatson: You know that some banks allegedly give out Ubuntu LiveCDs to customers so they can bank safely online? I think that users will be glad to boot in the LiveCD faster, for such uses [10:46] Plus, I think having 5 MB extra data in .pngs all over the CD is a waste :) [10:47] doko__: CC in this test is gcc and in this moment it has to be host one [10:50] hrw: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847 [10:50] gcc.gnu.org bug 43847 in bootstrap "test for plugin is using wrong objdump for host != target" [Normal,New] [10:53] hx [10:54] doko__: thx, forgot to check gcc bugtracker [11:00] Cynthia: oh, you don't need to persuade me of the usefulness of making it faster. lucid should be really quite a lot faster than karmic due to the use-of-debconf optimisation work we did in casper, for one thing [11:02] speaking of, I don't actually remember how fast or slow Karmic's CD was to boot [11:11] shit [11:11] sorry [11:31] Cynthia: I forget what the speed improvement was - Jamie Bennett might remember. IIRC we shaved off a third of the runtime or something like that [11:32] awesome :D [11:32] Oh btw the daily build for today is done downloading [11:42] cjwatson, can you fix the PT timezone ? [11:43] please [11:52] cjwatson: Regarding our discussion of CAV versus CLV CD-ROM drives, you would be right. The burner doesn't matter, it's the reader that spins faster or slower at the centre. However, yes, locality of reference is still important. I'm filing that bug now. [12:09] bug 589629 [12:09] Launchpad bug 589629 in livecd-rootfs (Ubuntu) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629 [12:09] you might have a laugh at my poorly-drawn CD layout [12:09] but it illustrates the point === al-maisan is now known as almaisan-away [12:10] <\sh> slangasek, would it be a big act to update the examples in ifupdown on karmic and do an SRU for that? and to update the release-nots on lucid for ifenslave-2.6 (bonding interfaces) because they are wrong now === MacSlow is now known as MacSlow|lunch === amitk is now known as amitk-afk [12:49] cjwatson: repeat from an hour ago, bug 589629 [12:49] Launchpad bug 589629 in livecd-rootfs (Ubuntu) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629 [12:49] am I actually allowed to make a branch in the debian-cd and livecd-rootfs packages? [12:52] Cynthia: you can always make personal branches - the bit straight after ~ should be your LP username [12:52] (I'm not going to be able to look at that bug straight away, sorry, but that's what a bug tracking system is for, to make sure things don't get lost) [12:52] cool, I just thought creating branches in those packages was restricted to ubuntu core devs [12:52] mk, no worries [12:53] the naming scheme is ~OWNER/PROJECT/BRANCHNAME - you can set a different OWNER freely [12:53] I know how to create branches, I just didn't know if I had permissions to :D [12:53] Thanks though [13:08] hi, any known issues with networkmanager after the update from karmic to lucid? it keep sayng that it is not running and that the networking is disabled... [13:08] Notch-1: lucid support is in #ubuntu === MacSlow|lunch is now known as MacSlow [13:18] one thing which I need to remember when I work on ubuntu packages - edit configure/makefile.in not configure.ac/makefile.am like it was with OpenEmbedded [13:19] er! [13:19] goodness me no [13:19] you should edit the original files and re-autogenerate [13:19] it's a real pain when it turns out that somebody has edited only the autogenerated files [13:19] you do need to be careful about timestamps to avoid autoconf getting rerun during the build and banjaxing everything (or else build-depend on autoconf etc.) [13:20] and yes it can be a bit fiddly, but editing only the autogenerated files is definitely the wrong solution to the problem [13:20] cjwatson: in patches I include changes to both of them [13:20] yes, that's reasonable [13:21] cjwatson: debian/ubuntu do not run whole autotools-please-regenerate-all-files by default [13:21] that depends on the package. the core build system doesn't do it, no. [13:21] but debian/rules can do whatever it likes [13:22] cjwatson: I know that debian/rules can do anything. using debian since previous century [13:22] didn't mean to offend [13:23] I know, sorry for that [13:24] ~curse debian/patches/hrw-make-debug-dir-before-copying.diff [13:26] btw - packaging imports into launchpad are automated? [13:26] yes [13:27] https://wiki.ubuntu.com/DistributedDevelopment [13:28] thx [13:39] gcc-4.5 4.5.0-5ubuntu1 cross built === mathiaz_ is now known as mathiaz === amitk-afk is now known as amitk [14:35] doko__: http://paste.ubuntu.com/444614/ was needed on my system to get gcc 4.5 cross built. multiarch binutils did not helped [14:47] ~curse LP webfront devs for lack of id in divs [14:47] how long does it usually take for a new debian package to be synced to ubuntu (automatically)? === sconklin-gone is now known as sconklin [14:52] variable. what package(s) are you interested in? [14:53] bugs 588812, 588813 - mdds and mythes [14:53] Launchpad bug 588812 in Ubuntu "Sync mdds 0.3.0-2 (universe) from Debian sid (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/588812 [14:53] Launchpad bug 588813 in Ubuntu "Sync mythes 2:1.2.0-4 (universe) from Debian sid (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/588813 [14:55] E: libmythes-dev is in main but its source (mythes) is not. [14:55] currently in openoffice.org; is it OK to overwrite that package with the one from mythes? [14:55] (that's why that one hadn't been done already) [14:56] and is that just a straightforward split-out of the code already in the openoffice.org source package? [14:57] same question for mdds, is it just a straight split-out of code already in ooo or is it new? === DrPepperKid is now known as MacSlow [15:02] cjwatson, yea mythes should be replacing the version in OOo [15:02] cjwatson, i think mdds is new, but is used by new OOo as well [15:03] ccheney: mdds will need an MIR then; we can waive that for mythes since it's just a split-out [15:03] ok [15:04] yea i have 3 MIR to do for the new version of OOo, was waiting to write them up until I uploaded OOo and had those packages synced from Debian [15:06] both done now [15:06] modulo waiting for binaries [15:07] thanks :) === xomas_ is now known as xomas === bjf[afk] is now known as bjf === Hrww is now known as hrw === jtechidna is now known as JontheEchidna [15:50] is there a port of xf-video-nouveau somewhere on the powerpc? [15:51] hey [15:51] hey world! [16:19] * jdstrand grumbles about launchpadlib and bug #344878 [16:19] Launchpad bug 344878 in ecryptfs-utils (Ubuntu) "file name to long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry)" [High,Triaged] https://launchpad.net/bugs/344878 [16:25] doko__: ping === amitk is now known as amitk-afk === hrw is now known as hrw|gone [17:06] ahem, after quite a bit of groundwork, operation cleansweep is finally kicked off http://justanothertriager.wordpress.com/2010/06/04/operation-cleansweep-launched/ :) === yofel_ is now known as yofel [17:15] yay! [17:16] * JFo celebrates Operation Cleansweep! [17:49] \sh: "the examples in ifupdown" - do you mean the examples in ifenslave-2.6? I don't see any examples in ifupdown that talk about bonding [17:49] jdstrand, could you move the jasper-initramfs package through NEW ? [17:49] \sh: I think an SRU for ifenslave-2.6 to fix the examples in karmic is probably overkill; lucid is far and away the better release if you want a stable boot [17:49] ogra: ok [17:49] thanks :) === cking_ is now known as cking === cking is now known as cking-afk [18:48] slangasek: if you get a chance, could you have a look at my cdrom-detect uploads to karmic-proposed and lucid-proposed? they're customer support escalations === cking-afk is now known as cking [18:55] ari-tczew: where is the fakesync policy documented? [18:59] james_w: not yet done [19:00] ari-tczew: has the work been done to make it work? [19:01] james_w: the general fakesync procedures were decided on #ubuntu-motu in February. I see that nobody want to do fakesync policy on wiki. I'll do it. [19:02] ari-tczew: yes, but were the necessary code changes done so that it doesn't break things? [19:04] james_w: I don't understand your question, sorry [19:04] package is the same like in Debian, just changed debian/changelog and debian/control by update-maintainer [19:05] if tarballs were the same, I'll process the sync [19:05] ari-tczew: there was a discussion on the mailing list about this policy, and several code changes were identified that would mean that it would work the way it is supposed to. If those have not been done then using the policy will cause problems for others. [19:06] james_w: I don't know about problems with fakesync. [19:06] ari-tczew: did you read the mailing list discussion? [19:06] james_w: no [19:06] didn't [19:07] http://thread.gmane.org/gmane.linux.ubuntu.devel/30305 [19:09] oh, I'll read it, but later [19:09] thanks for link james_w [19:09] see in particular Colin's response [19:10] hi aganice [19:12] hey, james_w [19:13] how's it going? [19:16] just ok. these first couple of weeks have been slow going (flu, unanticipated difficulty with fixing the problem in sample apps, and difficulty getting the hang of working from home) but i think i'm on the right track now === tkamppeter_ is now known as tkamppeter === bjf is now known as bjf[afk] [19:42] cjwatson: looking [19:53] Hy everybody [19:54] Can someone link me something explaining what are 'reverse dependencies'? thanks [19:58] cjwatson: not sure how cdrom-detect SRU is going to be verified in karmic when we have no more ISOs building there? But, accepted === dendrobates is now known as destro === destro is now known as dendrobates === apachelogger is now known as pinkrobotking [20:45] what's hot? === shtylman is now known as pinkrobot0003 === JontheEchidna is now known as pinkrobot_t800 === pinkrobot_t800 is now known as JontheEchidna === pinkrobot0003 is now known as shtylman [20:53] slangasek: good question, if need be I don't mind doing a one-off daily [20:54] slangasek: I kicked the importer for you after gathering data [20:54] slangasek: please continue pinging like that [20:55] cjwatson: ok [20:55] lifeless: alrighty - are you taking point on this alone, or are there others I should ping in other timezones as appropriate? [20:56] (I myself was proxying for jcrigby at the time) [20:56] so, there is now an rt asking for losa access to do it [20:56] cjwatson: can you refresh my memory on what you did to plymouth bzr to make the .pc directory be all happy? [20:56] cjwatson: I have another package in a similar situation [20:56] goodness, not sure I remember [20:57] I'd suggest pinging losa first, and if they can't, then any of james_w, me, poolie, spiv, jam should be able to help, in principle. [20:57] I think I blogged a while back something that included that information though [20:57] whats wrong with the .pc dir ? [20:57] or rather, how I did it in a package I was running myself [20:57] I generally put .pc in .bzrignore [20:58] lifeless: ack, thanks [20:58] openssh is a fairly complex example of how I currently prefer to manage 3.0 (quilt) plus bzr [20:59] lifeless: well, I have an actively maintained bzr packaging branch; the .pc directory from 3.0 (quilt) doesn't end up in bzr by any usual means, but the importer will want to add it [20:59] .bzrignore helps there, doesn't it? [21:00] not for the package importer [21:00]