[12:37] <Kopfgeldjaeger> Good night and bye
[01:37] <wasabi> Anybody around to discuss the initramfs lvm/md logic? I'm writing down how it "should" work, and would like input from somebody invested.
[01:39] <wasabi> This recent conversion to use udev... is interesting... but I wonder if it's self-defeating, and adds nothing of value.
[01:40] <ion_> I havent really read the code, either the earlier implementation or the udev implementation.
[01:40] <ion_> But using udev sounds right to me. :-)
[01:40] <wasabi> Sure, except udev is inherently disconnected from the actual init scripts that require wait conditions.
[01:41] <wasabi> Which makes it awkward to do what's expected. Wait 30 seconds for non-degraded vols, then start assembly degraded vols.
[01:41] <ion_> Well, yeah, we should migrate to Upstart. :-P
[01:42] <wasabi> I'm not sure if upstart makes this much better... and certainly not easier.
[01:42] <wasabi> The initramfs is by it's very nature sequential. You have to WAIT for the root device before moving on.
[01:46] <wasabi> Makes me wonder though if the process wouldn't be more robust if it was more straightforward... like root=md/md_device_uuid:lvm-vg/lvm_vg_uuid:lvm-lv/lvm_lv_uuid:fs/filesystem_uuid
[01:47] <wasabi> And just a simple dispatch to a set of scripts that are in charge of waiting for each component until a set timeout, and then mounting said component degraded.
[01:50] <wasabi> Hmm. maybe udev would be fine, as long as it never actually activated degraded volumes of any sort... but something else did after the timeout.
[08:27] <wolfe> :)
[08:28] <wolfe> nice, tracker is in C, unlike Beagle which is based on crap slow and buggy mono
[08:50] <Amaranth> wolfe: *cough*
[08:51] <wolfe> Amaranth: cover your mouth when you cough ;)
[08:52] <Amaranth> wolfe: mono is just fine
[08:52] <Amaranth> probably not appropriate for a long running daemon but...
[08:55] <wolfe> I haven't tried it in a year. I tried it 2 years ago, 1.5 years ago, and 1 year ago. The overall experience was terrible. Many APIs marked "completed" were incomplete(threw "Not Implemented," or were terible implemntations)
[08:55] <ion_> I dont find mono especially slow or buggy either. The language of choice probably isnt the most significant one of the things that make tracker better than beagle. :-)
[08:55] <wolfe> I didn't say language of choice, I said mono
[08:55] <wolfe> mono is just the VM
[08:56] <wolfe> now, oh boy, if you want to discuss all the flws in Mono's crapp C# implementation
[08:56] <ion_> There isnt much choice of the VM if your language of choice is C# and you want it to run on Linux.
[08:57] <wolfe> ion_: right, but for those of us who are cross platform programmers, Mono and Mono/C# is a hunk o junk
[08:57] <wolfe> which is why I use Python + wxWidgets
[08:58] <wolfe> ion_: Mono's purpose is to run windows apps on linux, pulling developers more towards linux. That isn't happening, the original purpose of mono is non existant
[08:58] <wolfe> they've complete .NET 1.1 support(supposedly, though it is probably non conforming like always), they're working on 2.0 support.. while WinFX(3.0) has been out for a really long time
[09:00] <wolfe> ion_: long as tracker is nice a fast.. and doesn't use 100+MB of memory running idle, I'm happy.
[09:01] <ion_> I dont even notice tracker, and this box isnt exactly high-end. (P3 500MHz, 384 MiB RAM)
[09:01] <wolfe> ion_: what about when it runs ;)
[09:01] <wolfe> people are complaining about when tracker does its thing, it is noticable.
[09:02] <wolfe> though when it is idle again, everything is fine.
[09:02] <ion_> Well, its extracting metadata from a video just now and i wouldnt have known it without taking a look at the process list.
[09:02] <wolfe> guess the people who complain have 500GB in porn ;)
[09:03] <ion_> (I do have indexing speed: 20 (slower) and minimize memory usage (slower indexing) set in Tracker preferences.)
[09:04] <wolfe> o
[09:04] <wolfe> well that would do it I guess :)
[09:04] <wolfe> ion_: say..
[09:04] <wolfe> ion_: do you notice any tools to join Ubuntu to a windows network?
[09:04] <wolfe> there was supposed to be a tool someone is working on.
[09:05] <wolfe> ubuntu specific, can't remember who it was.
[09:05] <ion_> This discussion is very offtopic, it probably should be continued on another channel. Its been years since i used samba.
[09:05] <wolfe> this discussion is devel related ;)
[09:05] <wolfe> the person said it was going to be included /maybe/ in this coming release.
[09:20] <Tonio_> hi
[09:45] <saispo> BenC: ping ? :)
[09:45] <saispo> hi seb128
[09:47] <seb128> lu saispo
[10:16] <seb128> ogra: new gnome-screensaver available
[10:18] <Hobbsee> good morning seb128
[10:18] <ogra> *yawn*
[10:18] <ogra> morning
[10:18] <ogra> seb128, thanks
[10:18] <seb128> hey Hobbsee
[10:19] <Hobbsee> hi ogra
[10:29] <tepsipakki> does someone know what's up with ubuntu.com-services (lp.net et al)?
[10:30] <elmo> tepsipakki: works for me - what's the problem you're seeing?
[10:30] <ogra> LP works fine here
[10:30] <tepsipakki> elmo: either they fail to open completely or partially
[10:30] <tepsipakki> connecting from hut.fi
[10:31] <tepsipakki> could be something here, too..
[10:31] <tepsipakki> rest of the world seems to work though :)
[10:31] <elmo> tepsipakki: try mtr-ing to launchpad.net and lithium.canonical.com, if you can still reproduce it
[10:31] <elmo> tepsipakki: if there's anything interesting in the first, pastebin both of them
[10:33] <tepsipakki> traceroute to l.c.c gets stuck after byrd.canonical.com
[10:36] <elmo> tepsipakki: k, that doesn't really matter
[10:37] <tepsipakki> now lp.net works again
[10:37] <tepsipakki> mtr/traceroute always got through
[10:38] <tepsipakki> maybe some db backend is busy?
[10:38] <maswan> elmo: we're getting errors to security.u.c (connection timed out)
[10:42] <Nicke> tepsipakki: I get connection timeouts now and then to LP too, fwiw
[10:43] <maswan> elmo: never mind, back again
[10:46] <elmo> seems like it might be telia
[10:46] <elmo> or telia vs. l3 anyway
[10:57] <maswan> elmo: telia might have had a power glitch in some parts, some machines we have in a telia hosting facility in denmark rebooted spontaneously. I guess if they have some routers/foo in there too, it might cause issues.
[10:57] <maswan> (wild guessing)
[10:58] <Nicke> (my traceroutes to lp seems to have problems with level 3 and Adapt Services.. not going through Telia at all)
[10:59] <maswan> well, we get transit from telia, so we'd be hit by that anyway. :)
[11:00] <Nicke> ah, true
[11:15] <maswan> elmo: hm. I'm getting issues to s.u.c/82.211.81.138 again now
[12:03] <soren> How does it make sense to have a package listed as both Replaces and Recommends?
[12:03] <Hobbsee> uh....
[12:04] <elmo> soren: assuming the replaces is unversioned, it doesn't
[12:04] <elmo> maswan: yeah, I still can't see anything concrete unfortunately
[12:04] <soren> elmo: It is.
[12:04] <soren> elmo: Alright, just as I thought, then. Thanks.
[12:04] <elmo> err, well, that's not actually strictly true
[12:05] <elmo> soren: sorry, it's actually fine, I can replace *some* files in 'foo' (requires Replaces),  and still Recommend it
[12:06] <elmo> (s/strictly//, s/$/ at all/)
[12:06] <StevenK> s/strictly\( true\)$/\1 at all/ :-P
[12:13] <Kmos> bz-gtk 0.90 is out at debian =)
[12:13] <Kmos> ubuntu gutsy has 0.18.0
[12:13] <Kmos> lol
[12:14] <StevenK> And we are in UVF.
[12:14] <seb128> Kmos: what is funny?
[12:16] <Kmos> *bzr-gtk
[12:17] <Kmos> seb128: nothing.. just UVF is ending, i've some requests there and nothing was done yet, so I won't file another sync request for it
[12:18] <Hobbsee> uvf *isnt* ending for gutsy.  it will never end.  i told you this before, and you said you understood that.
[12:19] <Hobbsee> and your sync requests lately have been contradicting themselves, so in the interest of getting things done, they've been getting ignored.
[12:19] <Kmos> Hobbsee: but I won't file bug reports
[12:19] <Kmos> :)
[12:19] <Hobbsee> good.
[12:19] <Hobbsee> then i wont have to work out WTF to say.
[12:19] <Kmos> Hobbsee: only ddclient, and i've already explained.. and the others? =)
[12:19] <Hobbsee> you explained once, then contradicted yourself again.
[12:19] <Hobbsee> i gave up, at that point.
[12:20] <Kmos> ok, the problem is for ubuntu, isn't mine.. i published it at getdeb.net and people are downloading =)
[12:20] <Kmos> I'm credible for one things, but not for others
[12:20] <Kmos> that's the point.
[12:22] <Kmos> Hobbsee: that's your point of view =) I respect.
[12:22] <Hobbsee> i would have expected any repository maintainer to know what they were doing with their packages, before uploading them.
[12:23] <Hobbsee> if they prove that they dont, then clearly the quality of their packages is debatable.
[12:23] <seb128> Kmos: shipping non official packages is usually not a good idea
[12:23] <Hobbsee> seb128: ship?  who said anything about shipping?
[12:23] <RAOF> How exactly can you ship non-official packages anyway :)
[12:23] <Kmos> seb128: it's the only way I found to publish my ddclient package, that's i'm part of uptream
[12:23] <Hobbsee> seb128: this is about a sync/merge request of ddclient, whihc kmos contradicted himself in twice, so he turned to getdeb because it didnt get accepted.
[12:24] <Kmos> Hobbsee: I know the owner of getdeb, it's also from Portugal :)
[12:24] <Hobbsee> Kmos: if you're part of upstream, you should know WTF you're doing, including w.r.t syncs and merges, and not contradict yourself in bug reports about the package.
[12:24] <Kmos> Hobbsee: i've done an typo "is" - "isn't"
[12:25] <Hobbsee> yet you never corrected that in the bug report - or at least not when we read it.
[12:25] <Kmos> Hobbsee: I don't know what i'm doing.. you know =)
[12:25] <Hobbsee> which was a few days ago
[12:25] <Kmos> Hobbsee: check it again
[12:25] <seb128> Hobbsee: I probably didn't understand what getdeb.net is
[12:25] <Hobbsee> Kmos: i have better things to do with my time than read a sync or merge request which probably now contradicts itself a third time.
[12:26] <seb128> Hobbsee: I though somebody uploaded packages there
[12:26] <Hobbsee> seb128: ahhh
[12:26] <Kmos> bug 132694
[12:26] <ubotu> Launchpad bug 132694 in ddclient "Please merge ddclient (3.7.3-2) from Debian unstable" [Undecided,Incomplete]  https://launchpad.net/bugs/132694
[12:27] <Kmos> Hobbsee: i like to change comments and do typos and I can't :(
[12:27] <Kmos> *when
[12:28] <Kmos> I like to change comments when I do typos and I can't :(
[12:28] <seb128> Kmos: you should spend some time writting your bugs to include required informations
[12:29] <seb128> Kmos: that merge bug goes on pages and you still didn't describe what are the Ubuntu changes and why you think they can be dropped
[12:29] <Hobbsee> Kmos: what really worries me here is that you've had 2 blocks of contradictions in that bug report already, and you dont quickly change them to be right
[12:29] <seb128> "upstream don't apply it" is not a reason
[12:29] <Hobbsee> therefore, i've got absolutly NO confidence that the rest of your changes are right, as you clearly either a) dont have a clue WTF you're doing with the package or b) dont care enough to actually file a decent report with the required information, which you've been told about before.
[12:30] <Kmos> seb128: i've explained it.. upstream didn't apply it, because dyndns.com as talked to upstream to change it. only mention dyndns.com when we talk about the service, not about the core functions. like members.dyndns.org is the valid to update IP, and not dyndns.com
[12:30] <Kmos> this talk happen after my last ddclient package releases
[12:30] <Kmos> and before i enter to upstream as a member
[12:30] <Hobbsee> so, i cant, nor any in the MOTU-UVF team, in good conscience, approve that bug, because we know that it's likely wrong, and that we dont trust the filer to have gotten it right.
[12:30] <seb128> Kmos: well, your bug still doesn't list the changes with the rational, what you just explained is not clear
[12:30] <Kmos> so debian hadn't updated their package for long time
[12:31] <Hobbsee> it's as simple as that.
[12:31] <Kmos> Hobbsee: and you trust my other syncs? my last ddclient packages i've done
[12:31] <Kmos> that's contradiction
[12:31] <Kmos> lol
[12:31] <Kmos> so that's why I won't file bug syncs again
[12:31] <seb128> Kmos: what about "checked_ssl_load"?
[12:31] <Kmos> seb128: that's applied upstream
[12:32] <Kmos> and it's on v3.7.3
[12:32] <Kmos> everything is correct with the package, the only thing I need someone to check is the changelog, because that's merged
[12:32] <Kmos> I've also sent a lot of fixes to debian maintainer
[12:32] <Kmos> in hope he updates the package, that don't happened these weeks
[12:32] <seb128> Kmos: you should try to make a clear description directlu
[12:32] <seb128> directly
[12:33] <seb128> the issue with this bug is that the comments go on pages
[12:33] <Kmos> seb128: check last comment
[12:34] <Kmos> i took my debian/changelog
[12:35] <seb128> Kmos: so the package should be synced on debian or merged?
[12:36] <Kmos> merged from debian
[12:36] <Kmos> i've changed the title of the bug
[12:36] <Kmos> I think the debian maintainer has applied all of my changes, but not :(
[12:36] <Kmos> that's why I made it wrong first time
[12:37] <Kmos> but after changed to merge
[12:38] <Kmos> http://changelogs.ubuntu.com/changelogs/pool/universe/d/ddclient/ddclient_3.7.1-0ubuntu3/changelog
[12:38] <Kmos> as you can see here, I've done two packages of it
[12:39] <Kmos> * Added a patch to change dyndns.org to dyndns.com (LP: #106753)
[12:39] <Kmos> this was refused from dyndns.com service, we talked to them
[12:39] <Kmos>   * Re-add debian/patches/checked_ssl_load.diff which got dropped accidently in
[12:39] <Kmos>     last upload.
[12:39] <Kmos> this one is applied upstream
[12:39] <Kmos> like most of them
[12:40] <seb128> hum
[12:40] <seb128> merged = ubuntu changes need to applied
[12:40] <seb128> synced = use the debian version
[12:40] <Kmos> exactly
[12:40] <seb128> are we sure it needs to be merged?
[12:40] <seb128> which means you take the debian package
[12:40] <seb128> and what needs to be changed then?
[12:40] <Kmos> and applied the ubuntu changes
[12:40] <Kmos> * debian/rules: call dh_installinit with -u multiuser (Teardown spec)
[12:40] <Kmos> this one
[12:41] <Kmos> for example
[12:41] <Kmos> and ubuntu maintainer hadn't changed dyndns.com when talking about the service, inside debian/
[12:41] <Kmos> i've already mailed with, but with no answer until today
[12:41] <seb128> you should attach the debdiff of the merge to the bug then
[12:42] <Kmos> so I do the debdiff from debian unstable and my changed one
[12:43] <seb128> yes
[12:43] <Kmos> i'll do it now
[12:43] <Kmos> thanks
[12:44] <Kmos> seb128: it's attached to the bug
[01:13] <tuxcrafte1> how can i disable the new aiglx in gusty its causing errors on my system
[01:13] <thom> tuxcrafte1: #ubuntu for help
[01:14] <tuxcrafte1> thom: also for testing of gusty?
[01:15] <thom> #ubuntu+1 alternatively
[01:23] <Hobbsee> Kmos: lets put it this way - i gave you the benefit of the doubt in most cases, because i didnt know you were this bad at sync requests.  and i also checked the changes, to check that the ubuntu changes really were all gone.  however, now we're later in the cycle, and i've got other stuff i want to do.
[01:23] <Hobbsee> Kmos: so it either needs to be right, or not happen.
[01:24] <Hobbsee> seb128: if you could deal with that bug, that'd be appreciated.  i'd not want to put it up for the sponsorship review queue / motu-uvf queue again - we've already tried to figure it multiple times, adn given up.
[01:25] <seb128> Hobbsee: will do
[01:25] <Hobbsee> seb128: thanks
[01:27] <Kmos> Hobbsee: benefit of the doubt.. lol.. Ok
[01:27] <Hobbsee> Kmos: as in, trusting that the changes you listed that were also listed in debian were actually correct, that there werent any silently dropped, that werent in the original changelogs.
[01:27] <Kmos> Hobbsee: and the powertop sync I've request, you acked it.. it's the benefit of doubt
[01:28] <Kmos> and the others
[01:28] <Kmos> ok
[01:28] <Hobbsee> Kmos: yeah, but i have a clue about powertop.
[01:28] <Kmos> so what's wrong with it ?
[01:29] <Hobbsee> Kmos: but for stuff that i dont know a lot about, it's a different story, it's confusing, and i dont have the motivation, time, or possibly skill to go thru every fine-toothed change.
[01:29] <Hobbsee> also, i dont recall powertop having any ubuntu changes
[01:30] <Kmos> Hobbsee: exactly, so you can't say "i didnt know you were this bad at sync requests"
[01:30] <Hobbsee> sure i can.  i knew that some of them were right, but i didnt know that some of them were that badly, and that confusingly wrong.
[01:31] <Kmos> ok
[01:31] <Kmos> that's your opinion, but a lot of them are synced and working fine
[01:31] <Kmos> sabdfl: hi =)
[01:31] <Hobbsee> previously, i'd known that some of yours were right, and some were wrong - but i didnt know they were that badly wrong.
[01:31] <Hobbsee> greetings, sabdfl
[01:31] <sabdfl> hey Kmos
[01:31] <sabdfl> Hobbsee: :-)
[01:32] <Kmos> Hobbsee: so, you're good, i'm not.. lol
[01:32] <Kmos> that's ok =)
[01:32] <Hobbsee> Kmos: i never said quite that.
[01:33] <Kmos> Hobbsee: i need to work, conversation won't take us to any side.
[01:33] <Hobbsee> ok
[01:33] <Hobbsee> enjoy
[01:35] <cromo> hi. I have some problems with qc-usb-messenger kernel module compilation. For some reason it segfaults (gcc: Internal error: Segmentation fault (program cc1)). Using feisty here and I am wonderign what's wrong. I tried compiling this module on other machine (archlinux, gcc 4.2.1) and it worked just fine.
[01:35] <cromo> so I wonder if something is broken in feisty's gcc?
[01:36] <cromo> basically, it's enough to download http://home.mag.cx/messenger/source/qc-usb-messenger-1.6.tar.gz package, untar it and exec a typical 'make all' in the directory
[01:37] <cromo> anyone can please confirm that he gets the error?
[02:55] <_StefanS_> infinity: hey, can you please re-upload kdesdk for lpia ? It compiles without changes now.
[02:55] <Riddell> _StefanS_: it's called "give back" since nothing needs to be uploaded
[02:55] <_StefanS_> right gotcha.
[03:18] <asac> our fontconfig adds FC_ANY_METRICS to fontconfig.h (while debian doesn't) ... who might know about this patch?
[03:18] <asac> doko_: ^^^
[03:20] <doko_> asac: iwj did write that. we have to make sure that we don't use DejaVu as a substitute font for missing fonts for documents becuase it is not metrics compatible
[03:20] <asac> doko_: so debian never had it?
[03:20] <doko_> asac: no
[03:21] <asac> thats interesting because the patch for firefox i have has a debian bug ... let me see
[03:59] <Mirv> mjg59: do you happen to have any chance to put any input to bug #86666 ? in March, you said that "I'll see if I can determine a test case for this that will give us some more feedback", and there's now both manufacturer-supplied and copied from /sys/ BIOS ROM you asked for.
[03:59] <ubotu> Launchpad bug 86666 in usplash "Feisty crashes after grub, before boot process, if usplash is enabled (amd64)" [High,Triaged]  https://launchpad.net/bugs/86666
[04:00] <Mirv> not that I'd need the fix (vga=792 works just fine), but it seems to affect quite a lot Radeon X800 users (with an occasional mention about possible similar problems with some NVIDIAs)
[04:20] <mjg59> Mirv: I've added an update
[04:29] <\sh> jono, ping...very important matters arised
[04:30] <\sh> jono, please in private or jabber (jid: sh@linux-server.org)
[05:10] <bddebian> Heya
[05:24] <tkamppeter> Hi, I need some help
[05:24] <tkamppeter> I am packaging CUPS with an alternative USB backend, trying to surround kernel (or hardware) bugs
[05:25] <tkamppeter> The alternative backend includes /opt/lsb-buildenv-ia32/usr/include/linux/usb_ch9.h
[05:25] <tkamppeter> Sorry, i cannot grab other than the wrong thing, let me search
[05:25] <tkamppeter> It needs /usr/src/linux-headers-2.6.17-10/include/linux/usb_ch9.h
[05:25] <mjg59> That's weird. Where have my font and desktop effect preferences gone?
[05:26] <tkamppeter> On my Gutsy linux-headers-2.6.17-10 is installed, and simply requiring linux-headers pulls linux-headers-2.6.22-10 which does not contain mentioned file. What do I have to do?
[05:27] <mjg59> tkamppeter: If it needs to include anything from /usr/src, it's broken
[05:27] <mjg59> Try /usr/include/linux/usb/ch9.h
[05:28] <tkamppeter> In reality it only includes linux/usb_ch9.h, but on my system I have found this file only in /usr/src.
[05:28] <mjg59> Oh. Change it to linux/usb/ch_9.h
[05:29] <tkamppeter> Thank you, will try it.
[05:29] <mjg59> seb128: Any idea why gnome-control-center doesn't seem to be building the font preferences?
[05:29] <tkamppeter> File is in linux-libc-dev
[05:29] <mjg59> tkamppeter: Yes
[05:30] <seb128> mjg59: what do you mean? it's a tab in the appearance capplet now
[05:30] <mjg59> seb128: Ah!
[05:30] <mjg59> seb128: That's not especially obvious :)
[05:30] <seb128> right ;)
[05:31] <mjg59> seb128: It also seems to have lost the DPI setting
[05:31] <seb128> no, details
[05:31] <mjg59> Ah, yes, I'm blind
[05:32] <mjg59> Hm. We really need to fix X's DPI handling.
[05:34] <iwj> doko_: Would you be able to help me with some pointers in the glibc build system ?  I'm trying to wrap ldconfig with a script but my rules fragment isn't being executed.
[05:34] <lamont> seb128: please don't do like shared-mime-info 0.22-2 did and break ia64, mk?
[05:34] <iwj> doko_: I was hoping you would be able to tell me where it should go - since it takes about 4h to run the build system even with a fully primed ccache.
[05:46] <tkamppeter> jg59, thank you very much. Now I succeeded also to build it under pbuilder. The contributor of the code is probably not much experienced with packaging for distros.
[06:34] <iwj> Scary.  I've just taught autopkgtest how to file bugs in LP and turned it on.
[06:40] <mjg59> jamiemcc: Any joy with the tracker issue?
[06:40] <mjg59> I've just pulled a kernel source tree into an otherwise entirely empty home directory, and tracker is eating all my disk i/o
[06:40] <jamiemcc> mjg: yeah we are working on tuning it
[06:40] <calc> who processes MIRs right now?
[06:41] <calc> iwj: iirc i hear you were doing them?
[06:41] <mjg59> jamiemcc: It's really not in a releasable state right now :(
[06:41] <jamiemcc> mjg59: we will do index merging as updating a massive index is very painful
[06:41] <mjg59> jamiemcc: Ok, sounds promising
[06:41] <jamiemcc> mjg59: should be fixed for tribe 6
[06:41] <mjg59> Cool
[06:41] <jamiemcc> there may be corner cases but hopefully that will crop up in testing
[06:43] <jamiemcc> mjg59: we recommend setting source dirs to be crawled instead of watched
[06:43] <jamiemcc> that way it wont slow down check outs or compiling
[06:44] <mjg59> jamiemcc: Hm.
[06:44] <mjg59> jamiemcc: That's a pretty negative user experience.
[06:44] <jamiemcc> yeah but only for devs
[06:44] <jamiemcc> its why we adding the crawl directory setting to tracker
[06:44] <mjg59> Who are a major part of our userbase
[06:44] <jamiemcc> yeah I know
[06:44] <iwj> calc: Yep.
[06:45] <jamiemcc> mjg59: the best we can do is make it less slow in devs
[06:45] <jamiemcc> we cant make it as fast as
[06:45] <mjg59> jamiemcc: The alternative is to heuristically mark directories as source directories
[06:45] <iwj> calc: If you have packages you'd particularly like approved do feel free to mention them.
[06:45] <mjg59> Rather than asking people to do it manually
[06:45] <calc> iwj: have you had a chance to look at libvigraimpex and libsvg
[06:45] <iwj> I mean, to mention them now.
[06:45] <calc> iwj: ok
[06:46] <jamiemcc> mjg59: we will be using idle disk priority which will help a lot too
[06:46] <iwj> calc: They don't seem to be mentioned on https://wiki.ubuntu.com/UbuntuMainInclusionQueue
[06:46] <jamiemcc> idle mode waits for a grace period of no disk access before allowing tracker to use disk
[06:47] <iwj> calc: Ought they be ?  I can review them and add them if you like.
[06:47] <iwj> I see MainInclusionReportLibsvg and presumably a similar page for the other.
[06:47] <calc> iwj: doh, i forgot to add them there i guess :\ yea please do
[06:47] <jamiemcc> mjg59: you can set idle to trackerd using ionice to see if it makes a difference in your case?
[06:47] <iwj> calc: NP.
[06:48] <iwj> calc: When would you like a response by ?
[06:48] <calc> end of the week if possible, i want to do the next ooo build with them which i expect to probably do around that time
[06:48] <mjg59> jamiemcc: I'll give it a go next time I trigger it
[06:48] <calc> iwj: between approval and promotion doesn't take long does it?
[06:49] <mjg59> (I just killed it for the moment - I only have a few minutes to get this patch finished)
[06:49] <jamiemcc> mjg59: ok next version will try and set idle automatically
[06:49] <calc> iwj: assuming the packages are ok to be included i would like them to be in main (if possible) by the end of the week
[06:49] <iwj> calc: Not hugely but it depends on someone having an archive day.
[06:49] <calc> iwj: oh ok
[06:49] <iwj> OK.  I should look at them soon then./
[06:49] <iwj> Thanks.
[06:50] <calc> thank you 8)
[06:52] <alex-weej> asac: you got time for some VPN lovin'?
[07:02] <calc> iwj: did you put them under approved or did i somehow put them there by mistake? (on the wiki)
[07:03] <calc> iwj: i thought i added them to the area to be reviewed but it showed up under approved section, lol
[07:04] <zyga> anyone on gutsy around?
[07:04] <iwj> I haven't touched them yet ...
[07:04] <calc> iwj: ok i screwed up where i stuck it then, i just fixed it
[07:04] <zyga> could someone confirm that /usr/share/command-not-found/programs.d still exists?
[07:05] <zyga> (with up-to-date command-not-found and command-not-found-data packages)
[07:15] <infinity> calc, iwj: If any promotions are time sensitive, don't be afraid to ping me to have an "archive moment", rather than waiting for someone to take an archive day.
[07:21] <iwj> infinity: Noted.
[07:22] <asac> alex-weej: nope
[07:26] <alex-weej> asac: ok. can you consider making the bugs critical for gutsy release?
[07:27] <asac> alex-weej: yes give me bug id
[07:27] <alex-weej> asac: https://bugs.launchpad.net/bugs/134547
[07:27] <ubotu> Launchpad bug 134547 in network-manager-pptp "NetworkManager PPTP VPN does not work; bad pptp plugin" [Undecided,New] 
[07:27] <alex-weej> asac: and, to a lesser extent, the bad DNS = crash one: https://bugs.launchpad.net/bugs/134544
[07:27] <ubotu> Launchpad bug 134544 in network-manager "NetworkManager aborts when attempting to connect to PPTP VPN server with bogus host name" [Undecided,New] 
[07:28] <asac> alex-weej: bug 134544 must be a duplicate
[07:28] <alex-weej> asac: how so?
[07:28] <asac> ah sorry :)
[07:28] <asac> lost the context
[07:29] <alex-weej> (i split the old bug up into two new ones, the vpnc problem seemed to disappear)
[07:31] <asac> right
[07:46] <iwj> calc: Why does oo.o want a computer vision library ?
[07:50] <iwj> calc: Hmm.  Looks like it's just using it for image processing.
[07:56] <iwj> calc: Both approved.
[08:28] <calc> iwj: thanks :)
[08:38] <iwj> calc: NP.  Goodnight :-).
[08:49] <geser> Riddell: Hi, are you responsible for UVF exceptions for packages in main?
[08:52] <Riddell> geser: yes
[08:54] <geser> what's your opinion on bug #134684? the link list of fixed upstream problems looks interesting but on the other side boost has some rdepends which would need rebuilding.
[08:54] <ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,New]  https://launchpad.net/bugs/134684
[08:56] <Riddell> geser: seems like a good idea if someone wants to test all the rdepends
[09:00] <geser> Riddell: ok, will test in my PPA if upgrading boost is possible
[10:12] <Riddell> geser: that's a good idea
[10:12] <soren> MikeDK: /win 10
[10:12] <soren> Whoops
[10:13] <Riddell> infinity: do you have any opinion on having opensync 0.30 packaged?
[10:15] <infinity> Riddell: None whatsoever...
[10:20] <Riddell> oh jings, why do I always mix you two up on irc
[10:20] <Riddell> lifeless: do you have any opinion on having opensync 0.30 packaged?
[10:27] <moquist> Any postgresql-savvy folks in here? I'm working on the Moodle package and could use some advice about best practices.
[10:33] <mathiaz> moquist: pitti is the man to talk to. But he's on vacation for two weeks.
[10:33] <lifeless> Riddell: yes
[10:34] <lifeless> Riddell: I think its a great idea; its on my todo list as upstream have apparently unbroken the soname issue.
[10:34] <lifeless> Riddell: if someone wants to throw a patch my way I'd be extremely happy.
[10:36] <Riddell> lifeless: what was the soname issue?
[10:37] <azeem> using scons
[10:37] <azeem> lifeless: though note that upstream discourages any use and packaging of opensync before 0.40 apparently
[10:37] <lifeless> IIRC - its a year back now - they broke the ABI comprehensively; didn't bump the soname, and plugins were hardcoded back. Or something. azeem was dealing directly with it.
[10:37] <azeem> it's really messed up there
[10:38] <lifeless> azeem: more and more I get the impression they don't want users.
[10:38] <azeem> apparently opensuse 10.3 (or whatever is next) won't ship it
[10:39] <azeem> or well, will ship 0.2x or something
[10:39] <azeem> but OTOH, maybe 0.32 is already heaps better than what is in the ubuntu/debian archive now
[10:39] <moquist> mathiaz: thx
[10:39] <bddebian> scons... Ugh
[10:40] <azeem> they switched to scons and had no clue that a library should have a soname - neither had scons
[10:40] <lifeless> I'm hearing that 0.3x is significantly better that 0.19
[10:41] <azeem> lifeless: I'm not sure they guarentee not breaking the file/archive format till 0.40 though
[10:41] <azeem> Riddell/lifeless: is this for gutsy, or just in general?
[10:41] <lifeless> gutsy IVF is tomorrow I think
[10:42] <lifeless> s/I/U/
[10:42] <lifeless> IVF would be rather different ;) ;)
[10:42] <Riddell> azeem: for gutsy
[10:42] <azeem> ok
[10:42] <lifeless> azeem: this is nuts; bzr has migrated file format several times, lossless upgrades. It's a solved problem.
[10:42] <Riddell> azeem: fancy packaging it?
[10:43] <Riddell> bddebian: it was
[10:43] <lifeless> bddebian: perhaps I'm thinking universe ?
[10:43] <bddebian> Us too
[10:43] <Riddell> new package deadline is thursday
[10:43] <bddebian> Aye
[10:43] <azeem> well, there's exceptions
[10:43] <azeem> no?
[10:43] <bddebian> Yes
[10:43] <lifeless> Riddell: meep; time for the UVF exception to roll out then -bzr 0.90 releases today
[10:44] <azeem> lifeless: alternatively, we could roll it out in debian experimental, get minimal testing, and then ask for UVFe sync
[10:44] <Riddell> lifeless: whoever is packaging it need to get me the changelog and convince me it's stable
[10:44] <Riddell> or more stable than what went before
[10:44] <azeem> 22:36 < azeem> lifeless: though note that upstream discourages any use and packaging of opensync before 0.40 apparently
[10:44] <azeem> Riddell: heh
[10:45] <lifeless> Riddell: of bzr, or of opensync ?
[10:45] <lifeless> Riddell: cause bzr is one of the most stable things I've ever seen.
[10:45] <Riddell> lifeless: both I guess.  bzr is a work of genius so I don't expect any problems
[10:46] <azeem> maybe we should check on the plugin state, last I checked about only the file-sync plugin was ported to 0.3x
[10:46] <azeem> s/state/status/
[10:48] <lifeless> http://svn.opensync.org/tags/plugins-0.32/
[10:48] <lifeless> looks promising; assuming its realistic
[10:49] <Riddell> danimo: any information on that?
[10:50] <danimo> Riddell: yes, it seems the enterprise branch guys changed the API without bumping the interface version
[10:50] <danimo> Riddell: till will look into it asap
[10:50] <azeem> lifeless: well, better than http://svn.opensync.org/tags/plugins-0.31/
[10:50] <danimo> Riddell: so it seems another repackaging (and relinking of all dependant packages) is due in one or two days
[10:50] <danimo> Riddell: sorry
[10:51] <Riddell> danimo: I was asking about opensync plugins
[10:51] <danimo> Riddell: oh, no, all I know is that 0.30 is not s/c
[10:51] <danimo> Riddell: tokoe knows mor
[10:51] <danimo> e
[10:51] <danimo> Riddell: suse already has new packages via OSBS
[10:55] <azeem> lifeless: 22:50 < abtronic> azeem: I don't think all of those are working yet
[10:55] <lifeless> I guess its a case of suck it up and see
[10:56] <azeem> btw, is there any indication how many users current opensync has on ubuntu?
[10:56] <lifeless> popcon
[10:56] <lifeless> http://popcon.ubuntu.com/
[10:56] <azeem> I have the feeling we're going annoy quite some of them if we'd ship 0.32 in gutsy
[10:57] <lifeless> http://popcon.ubuntu.com/by_vote
[10:57] <lifeless> meh sorry
[10:57] <lifeless> 270
[10:58] <lifeless> 75811 would seem to be the number of popcon users, or thereabouts
[10:58] <azeem> ok
[10:58] <lifeless> so we know there are millions of users
[10:59] <lifeless> millions / 100000 ~= some multiple of 10's expansion
[10:59] <lifeless> so say a few thousand opensync users.
[10:59] <lifeless> hows that for rough and ready stats
[11:01] <ion_> Im going to use opensync as soon as i get around to purchasing a data cable for my phone. :-)
[11:01] <lifeless> not if they never release a version with the plugins working again
[11:04] <azeem> get this: Apparently Sun put one of their engineers on the task of writing yet another gtk opensync frontend
[11:04] <lifeless> oh yay
[11:23] <ion_> iwj: Removing linux-ubuntu-modules-2.6.22-9-generic ..., update-initramfs: Generating /boot/initrd.img-2.6.22-9-generic, Purging configuration files for linux-ubuntu-modules-2.6.22-9-generic ..., update-initramfs: Generating /boot/initrd.img-2.6.22-9-generic
[11:23] <ion_> iwj: Could triggers be used to prevent this, too?
[11:25] <ion_> iwj: Perhaps make each linux-image-$REL package provide the trigger for initrd.img-$REL or something like that...
[12:08] <superm1_> Riddell, after the update cleared the buildds in -proposed yesterday, I received some info regarding a few reports of issues with the migration, and cherry picked a few patches from svn that take care of them.  Could you release the two updates (edgy and feisty -proposed) again?
[12:16] <superm1_> or infinity cjwatson mdz Keybuk ^