[00:00] (other than a question of the distribution of developer time) [00:04] slangasek, there have been a number of failures (not reported to the tracker though) [00:04] slangasek, i'm attempting to see how difficult fixing some of them are. if it's not doable today, then we'll be skipping A4 [00:04] superm1: ok [00:05] slangasek: ok. then the sooner it's in debian unstable and synced to jaunty the better. when do you think it could be uploaded to debian? [00:06] Adri2000: I don't know, not having looked at it at all yet. Maybe within the week if left up to me; I can't speak for any of the comaintainers [00:07] ok [00:17] is there a way to pad a number in shell, eg seq 000 150 and have the numbers show as 001, etc ? [00:18] yes [00:18] -w [00:18] thx! [00:18] jms@destiny:~$ seq -w 99 100 [00:18] 099 [00:18] 100 [00:19] and so to bed [01:59] Hi, I need some help with mdadm and update-initramfs, can anybody point me to a channel [on another server if necessary] that can help? my dpkg is completely crippled because it thinks a raid device is missing === bluesmoke is now known as Amaranth [04:35] hi i'm not 100% sure of the current status of reporting bugs in launchpad. but last time my friend had an issue he had to login to launchpad to report it (8.10), is this the case and if so would it not be possible to send bugs for users without a launchpad id to another place, like a mailing list ? [04:39] d-b: I think the ubuntu-users list has been used for that in the past. I'm not sure though if that's the current recommended process [04:40] LaserJock: ok. but can a user report bugs there atm via the gui bug reporting interface ? [04:41] d-b: I don't think so [04:41] LaserJock: do i add this as a wishlist item ? [04:41] and if so where should i best do this [04:41] I'm not sure [04:42] I think generally we discourage people from using the mailing list [04:42] it should be more of a last resort I'd think [04:42] still where should i propose this ? [04:43] you should start with a discussion, perhaps on the forums, or the ubuntu development mailing lists [04:44] either MOTU or -devel, probably -devel though the topic lines are a bit grey [04:44] -devel would be the most general [04:44] *if* you get a consensus forming filing a bug on launchpad is appropriate, but honestly, I don't think this is percieved as a problem by the community. [04:44] Its pretty nice not having spam come in as new bug reports on packages, and knowing you can contact the users that filed reports. [04:45] lifeless: right but there is a group of users who do have a launchpad account and might not want to sign up for one. [04:45] its just the extra effort that they might not want to go to after gnumeric or oo.o crashes with their work... [04:46] d-b: sure, but generally those bugs aren't going to be very useful [04:46] I don't thin kthere is a problem with a dearth of bug reports. [04:46] d-b: you are asserting that this group is sufficiently large to generate unique bug reports, and that they will go to the effort of filing the report and working with devs to get it fixed [04:47] d-b: this is an unsubstantiated claim; the barrier to entry to get an lp account is nearly zero (have an email address, receive one email at it, click on a link). [04:47] lifeless: i do not. i assume that if the bug is not already reported and enough information is able to be reported then it might be worth receiving a bug report. [04:47] sure if it is not going to contain info then .. its pointless. [04:47] d-b: arguing that this barrier is higher than the barrier to file and work through a bug report in the first place is pretty doubtful as an assertion [04:48] lifeless: right. but ok so lets consider the alternative platform... i dont' need a microsoft account to file a bug when that crashes. [04:48] and does anything happen to those bug reports, most of the time? [04:48] i'm suggesting these bugs could be used differently. [04:48] d-b: actually, last time I filed a bug with MS I needed a credit card with AUD 280 on it [04:48] Hobbsee: nothing ^^ [04:49] (the MS bug reports, i meant) [04:49] Hobbsee: i have no idea. all i know is the software doesn't get much better. [04:49] d-b: Mailing lists make very poor bug trackers. [04:49] redhat uses bugzilla, same as lp vis-a-vis accounts [04:50] novell, same [04:50] gentoo I haven't filed bugs on [04:50] gnome use bugzilla, needs an account too [04:50] Same with KDE. [04:50] all of sourceforge need accounts [04:50] savannah needs accounts [04:50] lifeless: sourceforge doesn't need an account to file [04:50] ScottK: it was just a suggestion... i agree that the use of an account is useful but perhaps if you submit a bug report and then they click on a validation email it could work better / if the gui allowed the user to sign up quickly for launchpad ? [04:50] LaserJock: it doesn't? [04:51] lifeless: no, you can file as "anonymous" [04:51] like i'm just trying to suggest making it easier for new users to submit bugs... [04:51] LaserJock: oh, eep, my bad [04:51] d-b: Also, in comparison to every attempt at a bug report I ever made to Microsoft got zero repsonse. Here stuff actually gets fixed sometimes. [04:51] ScottK: sometimes ;-) [04:51] ScottK: totally agree. [04:51] d-b: if we were lacking bug reports I can understand wanting to make it easier [04:52] d-b: I've said my bit; talk to the larger community, get consensus. I think you'll get a resounding 'not a big issue'. We have lots of bugs [04:52] d-b: If you have suggestions on improving the Launchpad signup process, you should probably discuss it with Launchpad developers in #launchpad. We've really got no control over that here. [04:52] There isn't a perception that we are missing out on important r-c bugs [04:52] lifeless: yeah mostly likely these would be small fidly bugs. sure. [04:52] (with the number of beta users we get, that do file bugs, missing an rc bug would be a surprise) [04:53] lifeless: It does seem to me that fewer people are reporting bugs. I do think there is a problem, but not that LP accounts are too hard to get. [04:53] d-b: the problem I see with adding an "anonymous" button is that people will just be lazy and hit that generally [04:54] Won't help the currenlty not to bad spam situation either. [04:54] d-b: if it actually were a "use only if you absolutely can't do a Launchpad" account I could maybe agree [04:54] LaserJock: well i meant like "email here" then you could have them click something in their email...(which could be used to spam people ) [04:54] ScottK: I think we have a bunch of issues in bug reporting and management; as I raised in the MOTU/community sessions at UDS [04:54] Agreed. [04:54] I just don't think this is one of them. [04:54] d-b: ok, but that's essentially the same thing as getting a Launchpad account, and an account is much more useful [04:54] ScottK: but adding anonymous accounts is rather orthogonal; and adding unverified email access is just a 'please be a spam multiplier' request [04:54] Yep. [04:55] ok. i don't think that bug sure. i agree its not that important. [04:55] *remove bug [04:57] considering that we're currently at over 43k open bugs I'm not all that eager to add anonymous bug filing :-) [04:58] why not? Then one could make bug stew ;) [04:58] over 47k [04:58] hmm, and 40k of them are unassigned [04:59] LaserJock: and of those 7k out of interested how many are reported upstream if required... [04:59] that I have no idea [05:00] I think a decent number get upstream, probably more than are assigned if I had to guess [05:00] LaserJock: speaking of bugs, we want to invite you down to NM to speak to the LoCo. Maybe we can have a bug jam. [05:01] tritium: ok, have your people call my people and set something up ;-) [05:01] LaserJock: roger that ;) [05:02] tritium: where is Ubuntu NM HQ? [05:03] LaserJock: Albuquerque is where most of our members are located [05:03] nice [05:03] Home of the MITS Altair. You might say birthplace of the PC, really. [05:04] I won't mention that Microsoft was first headquartered here too. Well, I guess I just did. ;) [05:21] tritium: well, I'm glad you guys managed to kick them out [05:48] LaserJock: ;) [06:33] good morning [06:34] ing [06:35] hi ion_ [06:35] What’s up? [06:36] getting up, sipping my coffee and triaging my inbox - and it's snowing again Berlin [06:36] how are you doing? [06:36] Quite okay, thanks [06:37] About to go to sleep. :-P [06:37] :) === tkamppeter_ is now known as tkamppeter [07:19] Good morning [07:20] cjwatson: glib pkgstriptranslations> I didn't fix it, I could never reproduce it [07:21] cjwatson: so I'll have another look [07:23] morning [07:23] hey slangasek [07:25] pitti: I'm working on shuffling invocation of the hotkey-setup code into modprobe.d, as we discussed; but how should this be future-proofed against the module being compiled into the kernel, or against the module being included in an initramfs? [07:26] slangasek: it'll still have an init script, right? maybe postinst could test whether modinfo thinkpad_acpi exists, and if not, call update-rc.d? [07:26] (just a hack, though) [07:26] hmm, eew :) [07:27] there's no way to get udev to trigger it for us? :) [07:27] slangasek: I think there is [07:27] slangasek: but I'd rather have Keybuk's advice for that [07:27] * slangasek nods [07:28] that seems the more reliable way, though - "do this when the hardware is seen by the kernel" rather than "do this when the module is loaded" [07:28] slangasek: if you have a corresponding device in /sys, you can still call something on that [07:28] slangasek: maybe it's in fact better to write this as an udev rule in the first place, rather than a modprobe.d script [07:29] since that's what we actually want (based on device, not based on module) [07:29] slangasek: and since it gets autoloaded, it must have something in /sys that triggers it (see modinfo thinkpad_acpi|grep ^alias) [07:30] sure, seen that previously :) [07:48] cjwatson: glib> one possible reason is that glib defines DEB_BUILD_OPTIONS_PARALLEL [07:49] cjwatson: and sets MAKEFLAGS; wouldn't MAKEFLAGS apply to debian/rules itself, too? [07:51] it has two dh_testdir etc. as well [08:00] * pitti asks soyuz guys [08:08] cjwatson: ok, now I'm pretty sure that the buildds define DEB_BUILD_OPTIONS="parallel=2" or something similar [08:09] however, why does this only happen for glib2.0, and not for any other package, ever? [08:10] ah, because it sets MAKEFLAGS [08:17] * scizzo- thinks that someone tried to talk to him in this channel a few days ago but irssi does not have it in backlog.... :( [08:22] scizzo-: mis-tab-completion [08:22] o...right... [08:22] now I feel unimportant... :P [08:22] sorry :) [08:55] cjwatson: ok, fixed pkgbinarymangler uploaded (with locking) [08:59] pitti: autosyncing from testing grabs us 104 updates; do you want to look them over at all before I commit? [09:00] slangasek: I'll do some random samples, but in theory all of them should be RC fixes [09:00] * slangasek nods [09:01] slangasek: I read the changelogs from a to m, they all look sane to me [09:01] so thumbs up from me [09:01] ack, flushing [09:02] slangasek: for the "eliminate/minimize acpi-support/powernowd/acpid" spec Robbie asked me to contribue to, is there already an existing blueprint? [09:03] good question [09:03] doesn't look like it [09:03] (wiki says BLUEPRINT: TBD) [09:03] ok [09:04] slangasek: btw, HotkeyArchitectureSpec's release note says "removed acpi-support"; I don't think that's feasible, I'll update that [09:04] right [09:07] pitti: yay, thanks. I suspect we'll have to delete that broken binary somehow [09:08] cjwatson: as soon as the new pkgbinarymangler is in the buildd chroots, I'll upload a no-change glib2.0, but I don't know how automatic/manual the buildd chroot upgrade is [09:08] I asked in soyuz, but nobody is really awake yet [09:09] cjwatson: how was it worked around last time? [09:09] SQL DELETE [09:09] \o/ [09:09] Julian should know [09:09] buildd chroot upgrade> I don't know offhand either, ask #is maybe [09:09] cjwatson: we can't just reject the binaries from accepted? [09:09] but they'll probably recommend waiting for Adam to wake up [09:09] I tried that, it refuses [09:10] cjwatson: hm, just worked for me [09:14] curious [09:14] oh, maybe I forgot to say -Q accepted, duh [09:14] I just bumped the build prio of pkgbinarymangler [09:14] although it seems that there is a more general problem with buildds [09:15] none of the i386 ones grab any [09:29] siretart: hum, who is Fabian Greffrath? [09:33] seb128: Hi, saw your comment. I really wanted to do it but I haven't had time ( and I still need an account for bugzilla ) [09:34] gaspa: hi, what comment? I do comment on hundred of bugs every week [09:34] lol, sorry... [09:34] bug #327003 [09:34] Launchpad bug 327003 in gnome-panel "add transparency to panel run dialog." [Wishlist,Confirmed] https://launchpad.net/bugs/327003 [09:34] he's a busy bunny is seb128 [09:35] ah ok, thanks for the work on it, the screen looks good ;-) [09:35] but normally seb128 remembers all the bug numbers [09:35] seems like he's getting old :) [09:35] haha [09:35] directhex: I will look at your sync requests today if nobody else is quicker [09:35] cool, thanks [09:35] seb128: in the meantime, do you think it can be included? Or it needs review? [09:35] dholbach: don't worry I just got a cold, I should be back to normal in a few days ;-) [09:36] * directhex is a little concerned @ debian NEW delays right now. seems the ftp-master team is busy with other things [09:36] * dholbach hugs seb128 [09:36] gaspa: I would prefer having comments from somebody who has a clue about all that, would it work for people who have no compositor? [09:36] * seb128 hugs dholbach [09:36] seb128: it works for me, without compositor. [09:36] * directhex checks seb128's lp account, ensures he's in the dholbach-huggers group [09:41] jelmer: bzr-svn 0.5.0-1 build-depends on python-subvertpy, not in the archive (Debian or Ubuntu)? [09:42] slangasek, subvertpy is in NEW atm [09:42] ok [09:42] slangasek, there's a package in the bzr PPA [09:42] slangasek, I was just talking about dholbach about the best way to get it into jaunty [09:42] one that I can sync into Ubuntu, so I can sync bzr-svn? :) [09:42] ok [09:42] jelmer, oh, the joys of uploading apps when their deps are in NEW for a few months :) [09:42] jelmer, we've got that problem for finishing off the mono 2.0 transition \o/ [09:43] jelmer: just add the link to the PPA on the bug report [09:43] dholbach, will do [09:43] super [09:45] jelmer: and how about bzr* uploads to Debian unstable? :) [09:54] jelmer: the version of python-subvertpy in Debian NEW is less than the one in the ppa; what do you think about getting 0.6.1-1 uploaded to Debian NEW, and then fakesyncing it into Ubuntu? [09:55] slangasek, problem is if he doesn't wait for the current one to clear NEW, then it's to the back of the queue with the new version [09:56] that's not my understanding of the Debian NEW queue ordering [09:56] slangasek, it's my experience. [10:00] seb128: eh? it's my archive day and I'm in ~/syncs :) [10:01] slangasek: I did ssh, ls, noticed and closed my ssh ... ie if somebody is hijacking your syncs that's somebody else ;-) [10:01] hrm [10:02] * pitti is innocent [10:02] well, at least wrt. to cluttering syncs ATM :) [10:02] we have 3 new people who have ssh access now, maybe we need to start being carreful with locks [10:02] seb128: https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/325930/comments/3 - token collision or something? [10:02] Ubuntu bug 325930 in bzr-svn "Please sync bzr-svn 0.5.0-1 (universe) from Debian experimental (main)." [Undecided,Fix released] [10:02] seb128: I was addressing you because yours was the name in the email :) [10:02] urg [10:03] how did that happened? [10:03] good question [10:03] james_w: hello? [10:06] slangasek: did you run syncbugbot at all today? [10:06] seb128: yes, that's what I've been using [10:07] I just don't understand why I'm getting your cookie [10:07] slangasek: it seems you are using my launchpadid for some reason? === thekorn_ is now known as thekorn [10:37] slangasek: a very nice and active contributor to pkg-multimedia. [10:37] slangasek: why do you ask? [10:37] siretart: I guess because of his debian-devel@ post [10:37] hello seb128 [10:38] siretart: what lool said; a curious post citing ffmpeg as an example [10:39] ah, right, ffmpeg is a delicate example. we (lool, fabian and I) have been discussing 'weak' build dependencies last week and I suggested that we should raise that topic on debian-devel [10:39] ah [10:39] then I repeat here what I said on debian-devel: opportunistic build dependencies are a terrible idea :) [10:39] wouldn't hold your breath even if it were a good idea, that idea has been floating around for approximately a decade [10:40] "weak" build deps? [10:40] however the mess with alsa not being available on non linux arch makes the build depends line look horrible as well [10:40] as in build-suggests? [10:40] "install this build-dependency if it's available, but don't complain if it isn't" [10:40] build-recommends! [10:40] i like it. make it so, number one! [10:41] siretart: my recommendation would be to take the approach used by debian-installer [10:41] I didn't know about the control fields proposal and all [10:41] well, in effect that is what ffmpeg needs. In multiverse there are additional libraries ffmpeg can make use of [10:41] siretart: build-deps written out line-by-line in debian/control, debian/genbuilddeps can be run manually to sync this into the actual Build-Depends line [10:41] (I share the concerns raised on debian-devel@, but saved myself the time to word them properly since others did) [10:42] siretart: so when merging you can throw away any changes to the Build-Depends line itself and just run debian/genbuilddeps after resolving all the other conflicts [10:42] cjwatson, siretart: Right, we have something like this in gstreamer packages [10:42] this makes it a lot easier to deal with complex build-deps [10:42] lool, OOo writes its own buil-deps too [10:42] And we allow end users to add some features by rebuilding the packages with some flags [10:42] hm. debian/control is already generated in ffmpeg... [10:43] cjwatson: But I guess you need to run that and upload a different source to ubuntu though [10:43] lool: yes, I don't regard that as a major problem though [10:43] It's not, but one of the goals is to have the same source package in Debian and Ubuntu; I don't think I would mind libfaad-dev | ubuntu-minimal though [10:44] * slangasek chuckles [10:45] * lool already has some hacks for backports, I think Ubuntu could be supported here as well [10:45] aesthetically horrible but probably functional [10:45] cjwatson, it's a delightfully elegant hack, no? [10:46] Let's call it pragmatic! :-P [10:46] directhex: your notion of elegance and mine are clearly different :) [10:46] hacks which make you groan & go "that's horrible!" are the best kind! [10:46] * slangasek wails and gnashes his teeth at the elegance [10:47] well, not as good as the ones that make you got "oh, that's just..." at a loss for words to convey the beauty of it [10:48] my notion of elegance is closely associated with generality [10:54] evand, ping [10:55] apw: pong [10:55] evand, just looking at usb-creator and i see symlinks say "need to fix this" [10:56] wondering if you have any context on why its not enabled, security perhaps/ [10:56] ? [10:56] vfat doesn't support symlinks, AIUI [10:56] ahhh, its a vfat fs we make [10:56] yeah that would break it [10:58] the "need to fix this" comment is poorly written :). It should say something to the effect of "does this subtly break anything?" [10:58] well that answer to that is yes :) it breaks the alternate installer [10:58] specificlaly the cd upgrade part, but its probabally easier to fix the way it works [10:59] hooray [10:59] thekorn: good morning [10:59] thekorn: do you know how to entirely disable cookie caching in ~/.python-launchpad-bugs.conf? [11:00] indeed; we're in a bit of a bind from the usb-creator perspective as we want to stick with vfat to ensure compatibility with already formatted by Windows USB disks. [11:00] evand, yeah, not sure its sensible to try and fix it, the link thats missing is to a directory too [11:00] so the chances of representing it are low [11:01] ah, ok [11:09] pitti, hi, I don't think there is a switch for this (yet), let me look at the code to be sure [11:10] thekorn: ok, thanks [11:13] cjwatson: https://code.launchpad.net/~james-w/ubuntu-seeds/platform.jaunty.apt-transport-https for you to review at your convenience. [11:13] cjwatson: it adds it as Recommends on standard [11:14] pitti, hmm, no, no such option and no easy way to not write the cookies to thiss file [11:16] seb128, if i delete mail in my inbox my evo reliably crashes, is that known already ? [11:17] jaunty? [11:18] yep [11:18] there is a crasher which is known an seems to be triggered when deleting mails which have images if you have the option to load those [11:18] though i didnt try the delete icon in the toolbar yet ... i'm used to use the del key [11:19] seb128, hmm, doesnt happen with the toolbar icon [11:19] should not make a difference [11:20] it might depends of the emails [11:20] but it was spam that got through which included the last two times at least [11:20] *included pics [11:20] right, that's a known issue [11:20] it tries to load the image and you deleted those before it was done [11:20] ah, k [11:21] ah, it doesnt seem to happen if i'm fast enough (before it starts the download) [11:21] only if the download process actually runs [11:21] right [11:21] known issue no need to open a new bug [11:21] great :) [11:28] apw: we should probably just remove our reliance on that symlink. Is it just cdromupgrade? I reassigned that bug to update-manager rather than closing it ... [11:28] james_w: merged, thanks [11:29] thanks cjwatson [11:29] cjwatson, yeah its still there, i was looking at fixing usb-creator, but thats not going to happen now i know the underlying reason [11:29] will look at fixing the script instead [11:29] the dists/stable and dists/unstable symlinks are definitely legacy [11:30] i assume those refer to the debian aliases for their releases [11:35] cjwatson, is /build/config/armel/ixp4xx/netboot.cfg originally coming from debian like that (despite your recent changeds indeed) ? [11:35] (in d-i) [11:37] ogra: yeah [11:37] apw: right [11:38] weird, someone on the debian-arm ML pointed out their ernel is armeb so wouldnt need endianess swapping [11:38] *kernel [11:39] * ogra tries to find out why ours doesnt boot at all [11:39] ogra: http://bazaar.launchpad.net/~kamion/debian-installer/main/annotate/head%3A/build/config/armel/ixp4xx/netboot.cfg (though that branch needs an update) [11:40] right, both call devio ... strange ... [11:42] i can boot the kernel standalone but not from di-nslu2.bin [11:43] is it normal for a package to require you have python-distutils-extra installed for a source build and not tell you? [11:44] should be in the build-deps either by itself or through a dep of something there [11:46] slangasek: sorry, was away [11:47] slangasek: I was waiting until squeeze before uploading to sid again, although new RC-bugs would be very unusual at this point [11:49] directhex: I was under that impression as well, though I've never tried it in fear that my uploads would end up at the tail of the queue [11:49] * directhex REJECTs jelmer [11:53] mvo, seems you own update-manager, is that a direct debian sync? [11:53] heh [11:53] is u-m in debian ? [11:54] dunno hard to tell, its one of those things where the normal" version number tell you everthing" rule falls down [11:55] to restate things, i have a patch for it, what do i do with it [11:55] it behaves oddly as it claims to have a real maintainer, unlike most packages [11:55] it's maintained in Ubuntu [11:55] right [11:56] (in the absence of mvo telling you otherwise) either attach the patch to a bug report; or create a branch (since it's in bzr), commit your patch there, and send a merge request [11:57] apw, the control file should tell you about the original bzr branch [11:58] debcheckout update-manager; cd update-manager; fiddle; bzr push lp:~apw/update-manager/name-of-your-branch [11:58] pfft, always these advanced tools [11:58] ahh missed the "its in bxr" whine, its simply not loud enough [12:02] * slangasek fixes apt to depend on figlet [12:14] slangasek, figlet is non-free. try toilet [12:16] apw: hello, what is the issue with update-manager? [12:16] oh, thank you - would've been terribly embarrassing to get the wrong banner printer pulled into the base system ;) [12:17] mvo, an issue with cdromupdate when converted to a usbstick. symlinks get lost, it doesn't work. simplest solution to avoid using the links. am just pushing a bzr branch with a proposed fix [12:18] apw: aha, cool. just give me branch location when the push is finished [12:18] mvo will do, its a trivial change [12:18] slangasek, well, putting apt into restricted would be awesome, but... [12:19] will evolution come with the libmapi plugin in 9.04? [12:20] slavik: evolution-mapi will be available, not sure if it will be in the default installation or universe though [12:20] evolution-mapi is the non-OWA exchange thing, yes? [12:20] yes [12:20] neato [12:20] it's supposed to be part of gnome 2.26 [12:20] that's the new version using openchange [12:20] but it also depends on samba4 [12:20] hence me asking [12:20] it's waiting for review right now [12:21] slavik: it will be in universe for sure [12:21] seb128: k, thanks ... I tried building it myself, but couldn't get it to work [12:21] awesome [12:21] there is a package available in a ppa, look to the need-packaging bug on launchpad [12:22] looking, heh [12:25] found it [12:29] mvo, branch should be here, hopefully I handled the changelog right, let me know if you need me to change it or have any commentslp:~apw/update-manager/cdromupgrade-avoid-links [12:30] apw: thanks, merging now [12:31] apw: thanks, looks good [12:32] mvo, cool [12:48] cjwatson: can you help me understand why adding '* Extra-Exclude: libjtidy-java-doc' to ubunt.jaunty/supported doesn't appear to have affected component-mismatches? [12:50] woo, m-a 0.4 [12:51] synced? [12:51] m-a ? who is using that in times of dkms [12:51] mono-addins not module-assistant [12:51] haha [12:52] yay for abbreviations [12:52] slangasek: my guess would be that it needs to be done in kubuntu.jaunty etc. [12:52] Laney: yes, I did the sync now [12:53] :D [12:53] and now we can sync f-spot [12:53] Laney, which means you can become the proud owner of an f-spot sync if you like [12:53] later [12:53] Laney: are you sure? [12:53] actually it might FTBFS, there was some weird problem [12:53] yes [12:54] Laney: http://launchpadlibrarian.net/22054264/debdiff [12:54] is that the one from chriscoulson? [12:54] Laney: that's a pending sponsoring request [12:54] (my internet isn't working) [12:54] Laney: yes [12:54] right, well I've put that into Debian SVN [12:54] so it'll be in -2 [12:54] Laney: there is ar4545_locales-import change listed there [12:54] ok so we can't sync yet [12:55] it updates the build-depends too [12:55] grr [12:55] Laney: have you looked at the other suggested changes for notebooks, etc? [12:55] * Laney mutters about having been told sooner [12:55] no [12:55] Laney: told what? we can sync but that's as cheap to upload this debdiff for now and sync -2 when it will be uploaded to debian [12:56] being is sync in nice but should not stop bug fixes to be uploaded to ubuntu [12:57] there could always be the next patch [12:57] which leaves us constantly chasing the sync but never getting there [12:58] well, I would sync if the build-depends was correct [12:58] but if we sync f-spot now it will not got to dep-wait for the new version but ftbfs directly [12:58] if you can get that fixed in debian we can sync [12:58] that's in ther etoo ;) [12:59] there being svn or experimental? [12:59] svn [12:59] we can't use that for syncs ... [12:59] anyway let's upload to debian can be synced [12:59] thanks for you work there ;-) [12:59] let's -> nex [12:59] next [13:00] cjwatson: strange; I can't seem to find jtidy anywhere in germinate-output/{ed,k,}ubuntu/all [13:01]