[00:46] <gouki> Sorry about the offtopic, but .. what are the possible locations for a startup file to be? I've searched all the ones I know but can't find the script which is getting started at boot time (and I don't want him to).
[00:49] <TheMuso> gouki: /etc/init.d
[00:49] <TheMuso> gouki: You looked there?
[00:49] <gouki> Did a -R ls on all folders, TheMuso
[00:49] <TheMuso> WHats the package?
[00:50] <gouki> synergys
[00:52] <TheMuso> thats not in hardy...
[00:55] <gouki> !?
[00:55] <gouki> I don't get it. I'm not using Hardy
[00:55] <TheMuso> Well I don't easily have access to gutsy atm
[00:55] <TheMuso> so I can't check there
[00:56] <soren> There was never a package called synergys in Ubuntu.
[00:57] <soren> gouki: Are you using Ubuntu? :)
[00:57] <gouki> I know there isn't a package called synergys. I'm talking about a script, not a package.
[00:57] <gouki> The software is called Synergy
[00:58] <gouki> What I'm asking is, where could this script be listed to start at boot time...
[00:58] <TheMuso> gouki: dpkg -L syngergy will show you all files belonging to that package.
[00:58] <TheMuso> syngergy even
[00:58] <TheMuso> gah
[00:58] <TheMuso> you know what I mean
[00:58] <slangasek> TheMuso: but only if it's packaged, and he's suggested it isn't packaged
[00:59] <TheMuso> slangasek: Right.
[00:59] <TheMuso> Mind is sorta elsewhere, on other things.
[00:59] <gouki> TheMuso: I have already done that. Still, no indication of the script on a startup directory
[01:01] <gouki> BRB
[01:03] <soren> keescook: Hmm... "sponsoring trigger creation patch "? Who wrote it?
[01:03] <soren> keescook: ...and you forgot to add debian/grub.trigger
[01:03] <soren> :)
[01:18]  * keescook cries
[01:19] <keescook> soren: fixed.
[02:24] <calc> azeem: ping
[04:37] <sparr_> after i apt-get source a package, i can build it with configure/make, but how do i build the package?
[04:40] <LaserJock> sparr_: dpkg-buildpackage does that
[04:41] <LaserJock> sparr_: https://wiki.ubuntu.com/PackagingGuide/Complete might be some good reading
[05:56] <mgunes> was gthumb removed from the default install as part of hardy-reducing-duplication?
[05:56] <RAOF> I believe so, yes.
[07:07] <gnudles> hi
[07:08] <gnudles> where can I find nautilus team?
[07:09] <gnudles> I'm testing ubuntu alpha 4
[07:11] <pitti> Good morning
[07:11] <gnudles> yes, good morning...
[07:11] <pitti> tkamppeter_: you can just upload them, so that they will be in NEW
[07:13] <mvo> good morning pitti
[07:13] <pitti> hey mvo
[07:14] <gnudles> today is the feature freeze....
[07:16] <gnudles> I have a question
[07:16] <LaserJock> morning pitti and mvo
[07:16] <gnudles> with the new nautilus, why can't I copy a file to the same directory?
[07:17] <mvo> hey LaserJock
[07:17] <LaserJock> mvo: I took care of desktop-multiplier, btw
[07:17] <LaserJock> hopefully you won't be getting more emails about that ;-)
[07:19] <gnudles> right... keep ignoring me...
[07:19] <RAOF> gnudles: Have you checked out the nautilus bugs on launchpad?
[07:19] <LaserJock> gnudles: I doubt people are ignoring you, probably they just don't know the answer
[07:20] <RAOF> gnudles: This is possibly not the best place for such a question, either (#ubuntu-bugs or #ubuntu+1 are possibly better).
[07:22] <RAOF> gnudles: Also, it works for me.  Although the question seems somewhat odd: why would you want to copy something to the same place?
[07:22] <dholbach> good morning
[07:22] <RAOF> Howdie dholbach!
[07:23] <dholbach> heya RAOF
[07:25] <gnudles> RAOF: If I want to copy a source file template for example
[07:25] <RAOF> gnudles: Do you mean 'copying a file "foo" from mydir/ to mydir/ does not produce a file "copy of mydir"'?
[07:25] <gnudles> it shows me a dialog
[07:26] <RAOF> Of whether or not you want to overwrite the file with the same file, yes.
[07:26] <RAOF> This seems to be not-totally-unreasonable behaviour.
[07:26] <gnudles> "copy of foo" you mean...
[07:26] <RAOF> Yes.  Of course :)
[07:26] <gnudles> no
[07:26] <gnudles> once it was like this
[07:27] <RAOF> Ah.  So this is a regression from gnome-vfs.
[07:27] <RAOF> File a bug.
[07:27] <gnudles> today a dialog appears...
[07:27] <gnudles> another thing
[07:28] <gnudles> in the dialog, you can add option for renaming if a file with the same name already exists...
[07:28] <mvo> LaserJock: thanks!
[07:29] <RAOF> gnudles: A valid feature request.  Again, file a bug :)
[07:33] <gnudles> ok
[07:35] <gnudles> great! firefox 3 at last...
[07:35] <gnudles> :)
[07:37] <gnudles> crap!!!!!! all my bookmarks disappeared :,(
[07:45] <DktrKranz> Could a buildd-admin give-back hdf5 on lpia? Thanks.
[07:52] <pitti> DktrKranz: nothing to give-back, it's in depwait
[07:52] <pitti> mvo: should that worry me? "Fehl http://archive.ubuntu.com hardy Release"
[07:52] <pitti> mvo: at the end it complains about not being able to access the keyring
[07:53] <mvo> pitti: possible, can you paste me the exact error message?
[07:54] <DktrKranz> pitti: oh, indeed! I misread. Sorry.
[07:54] <pitti> mvo: http://paste.ubuntu.com/4582/
[07:55] <mvo> pitti: what does apt-key list say?
[07:55] <pitti> 'gpg: Schlüsselbund `/etc/apt/trusted.gpg' erstellt'
[07:55] <pitti> oh, I bet I know
[07:55] <mvo> meh
[07:55] <pitti> mvo: I ruined my file system yesterday (silly error)
[07:55] <pitti> and lost some files
[07:55] <mvo> *PPUUUHHH*
[07:56] <mvo> thanks
[07:56] <mvo> I was very worried for a moment :)
[07:56] <pitti> I should really reinstall this box
[07:56] <mvo> pitti: if you have the latest apt, please run "apt-key net-update"
[07:56] <mvo> just for the fun of it
[07:56] <pitti> right, but to get this I need apt-get working :)
[07:57] <mvo> heh :) ok, if you don't have a current one, then yes
[07:57] <mvo> "sudo apt-key update" may also help, depending on the damage on the FS
[07:58] <pitti> mvo: yep, that helped
[08:18] <mvo_> hey glatzor__
[08:19] <glatzor__> morning mvo!
[08:23] <tjaalton> pitti: hi, I uploaded a new nvidia-settings which enables the binary again (sigh :), but the old upload was already sitting in NEW, so should I do something special?
[08:23] <pitti> tjaalton: let me reject the old one then to avoid confusion
[08:24] <tjaalton> pitti: ok thanks!
[08:24] <pitti>  412897 | S- | nvidia-settings      | 1.0+20071221-0ubuntu | five days
[08:24] <pitti>          | * nvidia-settings/1.0+20071221-0ubuntu1 Component: multiverse Section
[08:24] <pitti> tjaalton: ^ so this should be killed?
[08:24] <tjaalton> yes
[08:24] <pitti> done
[08:24] <tjaalton> rock!
[08:26] <tjaalton> it turned out that the binary nvidia-settings shipped with the drivers is buggy, and the separate version can be patched so..
[08:26] <glatzor> mvo: I am currently turning apt-dbus into an extra backend, so that it can be merged in the main repository
[08:26] <tjaalton> this should be a win-win
[08:26] <glatzor> mvo: but the dbus backend infrastructure is still a moving target.
[08:28] <glatzor> mvo: is there a similar function to git log -p in bzr?
[08:34] <bryce> hi glatzor
[08:39] <tkamppeter_>  piiti, you mean I can directly dput them into Multiverse?
[08:40] <glatzor> servus bryce.
[08:40] <glatzor> how are you progressing?
[08:41] <bryce> glatzor: pretty well - http://bryceharrington.org/files/screenrez_a.png
[08:41] <glatzor> bryce: have you found any aspects in my user interface that you could reuse?
[08:42] <bryce> glatzor: definitely; I borrowed a lot of the layout and the icons
[08:42] <glatzor> takes some time ... I am currently participating in the worldwide I-have-got-the-slowest-internet-connection-contest :)
[08:43] <bryce> glatzor: mpt's mockup he did for you was also quite inspiring
[08:44] <glatzor> bryce: you had to skip the fancy widget part?
[08:44] <glatzor> bryce: has sørensen already started on the widget?
[08:44] <bryce> glatzor: yeah, I evaluated the time I had until FF and decided that was going to be too ambitious
[08:44] <glatzor> bryce: really cool
[08:44] <bryce> as it is I'm a couple days before
[08:45] <bryce> er, behind
[08:45] <glatzor> bryce: really nice
[08:46] <mvo_> bryce: have you heard anything from upstream yet? if they like it?
[08:46] <tjaalton> sandmann replied
[08:46] <bryce> I don't completely understand what sorensen's working on, but it looks quite different from our concepts.  I don't understand how it's implementing multi-screen
[08:46] <tjaalton> bryce: did you see soerens reply?
[08:47] <bryce> sorensen said it's all in there, but I guess I'd need to study it more to see how it does it
[08:47] <soren> pochu: I've not sent the extended key event stuff to Debian on purpose.
[08:47] <glatzor> tjaalton: bryce: have you seen any code of his planned x extension? he wanted to add fade effects
[08:47] <bryce> I tried compiling and running his code, but the only piece I could get to run didn't do anything
[08:47] <tjaalton> glatzor: nope.. sounds nice
[08:47] <soren> pochu: It's not completely finalised.
[08:48] <soren> pochu: In Ubuntu I have control over both ends of the wire.. In Debian, not so much.
[08:48] <glatzor> bryce: the actual monitor handling is now done by gnome-settings-daemon?
[08:48] <tjaalton> hum, the vmware-stuff in lrm is ancient
[08:49] <glatzor> bryce: does gdm now use the settings-daemon in ubuntu?
[08:49] <bryce> tjaalton: yeah I don't know what to think of the reply.
[08:49] <soren> tjaalton: There's vmware stuff in lrm?
[08:49] <tjaalton> soren: yes, player, server, tools
[08:49] <soren> tjaalton: Oh, that.
[08:49] <tjaalton> soren: not built in hardy
[08:49] <soren> tjaalton: Right, I remember now.
[08:49] <bryce> glatzor: I've not gotten to the gnome-settings-daemon part yet
[08:49] <ivoks> question for kde people; libqwt5-qt4-dev - any plans to move this in main?
[08:50] <glatzor> bryce: what are your plans for handling the new overriding nature of xorg.conf?
[08:50] <bryce> glatzor: redhat is developing a patch against gnome-settings-daemon to expand how it handles the monitor setup. I haven't looked at it though.  But it would seem most sensible to follow their design.
[08:50] <tjaalton> soren: do you know if we have the right to update those?
[08:51] <tjaalton> copyright doesn't mention anything
[08:51] <soren> tjaalton: No clue. Sorry.
[08:51] <bryce> glatzor: well, the work I'm doing is only for cases where xorg.conf does not need modification
[08:51] <tjaalton> soren: ok, no worries :)
[08:51] <bryce> glatzor: for situations where people do need to override things in xorg.conf, we'd need a different tool.
[08:52] <bryce> glatzor: there is also the case of bulletproof-x, which will need that kind of a tool as well
[08:52] <tjaalton> bryce: I'll bring back "Device" in the Screen-section, which should at least make aticonfig and nvidia-settings to work again
[08:53] <glatzor> bryce: how does pitti now deals the proprietary driver installation?
[08:53] <bryce> tjaalton: good idea
[08:54] <bryce> glatzor: sorry, don't understand the question?
[08:54] <glatzor> bryce: yeah, funny grammar
[08:54] <bryce> heya soren
[08:54] <soren> bryce: Hey.
[08:54] <glatzor> bryce: how does the restricted drivers tool change the driver in the xorg.conf now?
[08:54] <bryce> tjaalton, glatzor:  I've been having fun today screwing up my monitors by hitting Apply on this gui.  ;-)
[08:55] <tjaalton> hehe
[08:55] <bryce> glatzor: ahh - I gather that's what tjaalton was just referring to via aticonfig and nvidia-settings
[08:55] <tjaalton> not really
[08:55] <bryce> no?
[08:55] <tjaalton> jockey works right now, but aticonfig crashes
[08:55] <tjaalton> just like dc-gtk :)
[08:55] <bryce> heh
[08:56] <tjaalton> nvidia-settings fails to write the config, which actually is a blessing since it would write all sort of crack
[08:56] <mvo_> dosn't jockey use the displayconfig code for the modifications?
[08:57] <glatzor> mvo_: I haven't followed the jockey rewrite
[08:57] <bryce> mvo_: I knew that envy uses guidance-backends now, but didn't know that jockey did too
[08:58] <glatzor> bryce: the rate configuration won't be allowed in your tool? or just not yet implemented?
[08:58] <bryce> glatzor: it's there - but it's smart now; if you only have one rate available, it displays as a label rather than a dropdown
[08:59] <pitti> glatzor: jockey still uses guidance-backends nowadays
[08:59] <glatzor> bryce: doesn't this result in small flickering when changing screens?
[08:59] <glatzor> pitti: hello
[08:59] <pitti> hi glatzor!
[09:00] <glatzor> bryce: you could also disable the combo box.
[09:00] <bryce> glatzor: for LCD's (which is what I took the screenshot on) 60 Hz is fine
[09:01] <bryce> glatzor: true...
[09:01] <glatzor> bryce: flicking of the user interface, since it has to replace a widget when you select a different monitor in left chooser
[09:01] <bryce> glatzor: oh, no it's perfectly solid
[09:02] <bryce> I need to figure out how to do screencasts or something
[09:03] <glatzor> bryce: what is the primary status? does the applet move the panels to a different screen when it is set?
[09:04] <glatzor> bryce: I would be careful with the same-as position, since it requires that the screens have got the same resolution
[09:05] <glatzor> bryce: that is why I had three radio buttons (disable, extend, clone)
[09:05] <bryce> glatzor: the 'primary' is basically what I'm calling an output that other outputs are relative to
[09:05] <bryce> glatzor: however it's been proving ornery in the coding so I'm not sure having a 'primary' screen adds that much
[09:06] <bryce> glatzor: yes you're right about the same-as (aka clone or mirror).  It probably will take a lot of testing to get right.
[09:08] <glatzor> bryce: how do handle the virtual size issue?
[09:08] <bryce> glatzor: right, that's a remaining issue
[09:09] <bryce> glatzor: I decided to focus on only non-xorg.conf changing functionality
[09:09] <glatzor> bryce: the other parts can perhaps never be done right :)
[09:10] <bryce> glatzor: my thought is to use a script or something attached to an Advanced button or something to update Virtual, but I'm ignoring it for now
[09:10] <glatzor> advanced buttons are evil :)
[09:11] <bryce> yeah yeah
[09:11] <bryce> well ultimately (maybe xserver 1.5??) it'll become unnecessary to specify Virtual anyway
[09:12] <glatzor> bryce: perhaps a small check if the virtual size allows to display two displays could be added to the applet
[09:12] <bryce> glatzor: yup
[09:13] <bryce> also since increasing virtual often results in forcing DRI/Compiz to have to be turned off, I thought a popup dialog warning the user might be of value
[09:13] <glatzor> bryce: indeed
[09:13] <RAOF> bryce: Thinking of xrandr, do drivers other than nouveau suffer from http://bugs.freedesktop.org/show_bug.cgi?id=14394 ?
[09:13] <ubotu> Freedesktop bug 14394 in Driver/nouveau "[NV4B] Composite broken on 2nd head" [Normal,New]
[09:14] <RAOF> The fact that the patch is against the X server makes me think so, and it's a really curious bug to run into.
[09:15] <bryce> interesting
[09:15] <bryce> RAOF, for most typical multi-head systems (at least ones I've played with), compiz gets disabled entirely because you go beyond the Virtual limits
[09:15] <RAOF> bryce: But this kills metacity (& Kwin I think) too.
[09:15] <bryce> RAOF: hrm
[09:16] <RAOF> Metacity as of .8 uses the COW.
[09:17] <tjaalton> compiz 0.7 should have "multi-head support", but I'm not sure what it means here
[09:17] <bryce> RAOF, hmm, well this is a configuration I've not really tested myself much
[09:18] <bryce> RAOF, offhand it does sound driver-specific, but I don't really know; I've never run anything like this
[09:18] <tjaalton> RAOF: have you tried the patch yet?
[09:18] <stgraber> moin
[09:18] <RAOF> tjaalton: Not yet.  I mean to grab our X package and add the patch, but I haven't tried yet.
[09:19] <mvo_> tjaalton: this is really more about the window managment capabilities, those got improved a lot for multihead in compiz 0.7
[09:20] <RAOF> bryce: I don't have a non-nvidia card handy to test, but if you've got an intel cand or somesuch that bug should be easy to trigger, if it exists.
[09:21] <tjaalton> RAOF: hmm, I have an intel box next to me, and it could borrow the monitor from the Sunray terminal ;)
[09:30] <glatzor> mvo_: how can i see the diff of a commit after adding the "content" to the commit?
[09:30] <glatzor> mvo_: any git gurus around?
[09:31] <cjwatson> git diff --cached
[09:35] <glatzor> cjwatson: thanks a lot
[10:08]  * ogra would so love to not find a frozen laptop on his desk every morning ... *sigh*
[10:11] <Riddell> ivoks: no, why is it needed?
[10:13] <ivoks> Riddell: i'm asking cause this lib is needed for bacula's QT console
[10:13] <ivoks> since we are moving bacula to main, we'll have to drop qt console :(
[10:14] <ivoks> or build it for universe...
[10:14] <Riddell> ivoks: so write a MIR for libqwt5-qt4-dev
[10:14] <iRon> Riddell: ping
[10:14] <ivoks> Riddell: that crossed my mind too...
[10:14] <iRon> Riddell: could you please check your mail
[10:15] <Riddell> iRon: doing so
[10:59] <pitti> cjwatson: do I need to pay attention to something special when I'll change the seeds for e. g. slocate -> mlocate?
[11:00] <pitti> cjwatson: e. g. I guess I should add that to the platform.hardy branch?
[11:02] <cjwatson> pitti: platform.hardy/desktop-common has dlocate
[11:02] <cjwatson> err, slocate
[11:02] <cjwatson> so it makes sense to change that, along with ubuntu.hardy/server-ship
[11:02] <cjwatson> although as I said on ubuntu-devel I think it ought to be in platform.hardy/standard really
[11:02] <pitti> cjwatson: right; so changes in platform.hardy will be picked up by *-meta/running update, not by merging to the other *.hardy seeds?
[11:03] <pitti> cjwatson: I agree about standard (and removing it from desktop and server-ship)
[11:04] <pitti> cjwatson: hm, installing mlocate doesn't remove slocate
[11:04] <cjwatson> pitti: changes> right
[11:05] <cjwatson> pitti: yes, seems to be intentional to ease migration, although I see the problem you're raising
[11:05] <pitti> I don't see anything in /etc/cron.daily/slocate  that tests for mlocate presence
[11:05] <cjwatson> pitti: however, we could fix this by changing slocate's cron job not to run if mlocate is there
[11:06] <cjwatson> much like locate's cron job does
[11:06] <pitti> ah, it sets the /etc/alternatives/updatedb to mlocate
[11:06] <cjwatson> well, sort of does, it checks whether it's been diverted
[11:06] <cjwatson> [ -e /usr/bin/updatedb.findutils ] || exit 0
[11:07] <cjwatson> pitti: yes, though /etc/cron.daily/slocate runs slocate explicitly
[11:08] <cjwatson> so how about:
[11:08] <cjwatson> -if [ -x /usr/bin/slocate ]
[11:08] <cjwatson> +if [ -x /usr/bin/slocate ] && [ ! -x /usr/bin/mlocate ]
[11:09] <cjwatson> the only downside I can see is that it'll mean that running slocate explicitly won't work any more, but I'm not too concerned about that
[11:09] <pitti> why not simply add a Conflicts:/Replaces:?
[11:09] <cjwatson> update-manager can deal with encouraging people to remove it, rather than requiring a hard Conflicts
[11:09] <cjwatson> I don't like adding Conflicts arcs when we don't have to
[11:10] <pitti> it would mean to leave package cruft around
[11:10] <mvo_> sure, we can add it to the obsoleted packages
[11:10] <pitti> but right, I guess we'll demote slocate
[11:10] <mvo_> in update-manager
[11:10] <pitti> and then u-m will clean it up, right?
[11:10] <cjwatson> pitti: I think update-manager is good enough, yeah
[11:11] <pitti> ... checking rdepends ... right, slocate has no rdepends at all (except *-desktop)
[11:11] <cjwatson> uploaded slocate with the above diff
[11:11] <pitti> thanks
[11:12] <mvo_> cjwatson: I added slocate to the forced obsoletes, that means that for most people it will get removed (unless they object of course)
[11:12] <cjwatson> great, thanks
[11:12] <pitti> ok, mlocate MIR looks good, thanks for the great and detailled review
[11:12] <pitti> cjwatson: I'll do the seed changes, promotions, etc. now
[11:13] <cjwatson> hooray
[11:15] <pitti> cjwatson: I won't update *-meta yet, since the component changes need to get published first
[11:16] <xivulon> evand, heno, can you please apply the following patch to umenu? http://paste.ubuntu-nl.org/55953/
[11:16] <xivulon> cannot ssh from here
[11:17] <pitti> cjwatson, mvo_: hm, should mlocate in standard be a recommends or a strict depends? (I lean towards recommends)
[11:18] <pitti> server didn't depend on it so far either
[11:20] <cjwatson> pitti: recommends, IMO
[11:21] <cjwatson> I'm surprised it isn't already a recommends in desktop-common
[11:21] <pitti> just an oversight, I think
[12:12] <cjwatson> hmm, we could do with new language-support-* for the firefox upgrade
[12:14] <pitti> cjwatson: the split? that's on my list for today
[12:19] <cjwatson> I think actually it's that we need new mozilla-firefox-locale-*
[12:22] <pitti> ah, right
[12:33] <edwin_> does anyone prefer grid layout over embedding hboxes in vboxes and vice versa?
[12:40] <persia> Does anyone have a timestamp for start of FeatureFreeze?
[12:59] <pitti> cjwatson, mvo__: AFAIK the installer and gnome-language-selector will get along if a language does not have a language-support-XX package, right? I'd like to remove all the ones with an empty Depends: to remove some cruft
[12:59] <pitti> as a preparation to merging/using ArneGoetje's 'split support packages' branch
[12:59] <pochu> persia: the end of the day in the last timezone of the world oh please :)
[13:00] <cjwatson_> pitti: sure
[13:00] <cjwatson> pitti: oh, err
[13:00] <persia> pochu: Maybe.  Something like 12:00 or 24:00 UTC would work as well.  I just want guidance on when to stop accepting UUS stuff that hasn't been pushed for FFe.
[13:01] <cjwatson> pitti: the installer will warn and say that the CD doesn't contain full support for your language
[13:01] <pitti> persia: I don't think anyone will measure that precisely
[13:01] <persia> pitti: OK.  I won't fuss about it then, and just stop sponsoring when it stops being a reasonable "14th February" for me.  Thanks.
[13:01] <pitti> cjwatson: oh, even if there is a language-pack-XX in the archive, but not a -support one?
[13:02] <pitti> persia: sounds pragmatic and appropriate
[13:02] <pitti> cjwatson: well, I can leave them around for a while, they'll be practically orphaned
[13:03] <cjwatson> pitti: the check is for what's on the CD
[13:03] <cjwatson> pitti: in practice it'll always have fired for !en anyway
[13:04] <cjwatson> pitti: so it might well not matter; it only does that check for CD installs
[13:04] <pitti> right, we'll retain language-support-en anyway
[13:04] <cjwatson> I don't particularly mind if empty language-support-* go away
[13:04] <pitti> cjwatson: I meant the bits that try to install support and -pack from the network
[13:04] <pitti> ISTR reading the code and seeing that they are tried independently
[13:05] <cjwatson> they are, and it shouldn't care if they fail either
[13:06] <pitti> ok, great
[13:11] <zul> piti: for munin it should be running as a munin user not nobody correct?
[13:12] <pitti> zul: yes; doko indicated that it already does that, though
[13:12] <pitti> so it might just have been a misunderstanding
[13:12] <zul> ok
[13:13] <tkamppeter> pitti, hi
[13:13] <pitti> hi tkamppeter
[13:14] <tkamppeter> pitti, I have corrected the .changes file from s-c-p, was I typo in the old version number, can you upload it now?
[13:15] <pitti> tkamppeter: ok
[13:15] <tkamppeter> pitti, I have also all files of the Brother driver now, should I put them directly into Multiverse?
[13:15] <pitti> tkamppeter: if you think the packaging is ok now, then please just upload them, so that they'll land in NEW
[13:16] <zul> pitti: ill leave as it is then
[13:16] <pitti> tkamppeter: setting Section: multiverse/text would be good, yes
[13:16] <pitti> (but it's just a bonus)
[13:17] <tkamppeter> With the section, I will tell it to the packagers, that they can correct that in a later version.
[13:17] <pitti> tkamppeter: btw, you know that you don't normally need to use -v, right? just for merges
[13:18] <tkamppeter> So without -v it defaults to take simply one ChangeLog entry?
[13:18] <pitti> right
[13:18] <pitti> tkamppeter: nevermind about Section: we'll override it to multiverse in the NEW queue
[13:18] <persia> tkamppeter: Yes.  Note that it is always safe to use -v with an rmadison call to get the current version, even if you are just doing a standard update.
[13:19] <pitti> tkamppeter: scp uploaded
[13:19] <tkamppeter> pitti, thanks.
[13:25] <glatzor> mvo__: I would like to move the description formating done in UpdateManager/AppInstall and the changelog fetching method to python-apt
[13:27] <MacSlow> I need some MOTU-help
[13:28] <MacSlow> how do I make sure a file gets installed in /usr/share/compizconfig, which has been added via a debian/patch/02_some.patch?
[13:29] <MacSlow> obviously adding the usual bits to Makefile.am and creating a 99_autoreconf.patch does not seem to be enough
[13:29] <MacSlow> help greatly appreciated
[13:36] <persia> MacSlow: For MOTU-help, asking in #ubuntu-motu is a good idea.  You might find using debian/$(package).dirs to help, or debian/$(package).install, depending on the contents of your rules file.
[13:41] <mvo__> glatzor: sure, that sounds reasonable
[13:45] <frafu> doko: are you Matthias that reviewed the following MIR: https://bugs.edge.launchpad.net/ubuntu/+source/mousetweaks/+bug/190208
[13:45] <ubotu> Launchpad bug 190208 in mousetweaks "Main Inclusion Report for mousetweaks" [Undecided,Incomplete]
[14:37] <jdstrand> pitti, slangasek: thanks for your help with migrating a conffile from one package to another
[14:37] <jdstrand> pitti, slangasek: what I ended up implementing was slangasek's suggestion, with the addition of a versioned Conflicts
[14:38] <pitti> jdstrand: you're welcome
[14:38] <jdstrand> pitti, slangasek: you can see what I came up with at https://wiki.ubuntu.com/ApparmorProfileMigration
[14:39] <jdstrand> pitti: and I should also thank you for your apparmor/cupsys work-- as I used it as a template ;)
[14:39] <pitti> heh, good to hear if it was useful
[14:39] <jdstrand> totally
[14:47] <azeem> calc: pon
[14:47] <azeem> g
[15:13] <calc> azeem: hi
[15:13] <azeem> heya
[15:13] <calc> azeem: i heard you were going to be updating opensync in debian?
[15:13] <azeem> well
[15:14] <azeem> if the upgrade path is reasonably clear, I would, yeah
[15:15] <calc> azeem: going from 0.19 -> 0.2x isn't clear?
[15:16] <azeem> no, both the database and the configuration format has changed
[15:17] <calc> azeem: hmm
[15:17] <azeem> there's now a configuration updater for 0.3x, but I haven't tested it
[15:17] <calc> maybe put a debconf message saying its not backwards compat would work? 0.19 is 10 releases old
[15:17] <azeem> it should be possible to just wipe the database and do a slow-sync
[15:18] <azeem> that'd be the emergency cop-out maybe, yeah
[15:18] <calc> well it hasn't been updated in 16 months...
[15:19] <calc> perhaps its a the DD doesn't want to do the extra work cop-out instead?
[15:20]  * calc doesn't know the details of the work involved but 16 months is a relatively long time
[15:21] <asac> calc: in which binary package is the openoffice firefox/mozilla plugin btw? i installed openoffice.org but don't see anything ooo related in /usr/lib/firefox/plugins
[15:21] <calc> looks like not much else uses the libraries, etc except opensync itself so its not a really nasty conversion
[15:21] <azeem> calc: it's rather the DD hoped 0.40 would be ready in time for hardy cop-out
[15:21] <calc> azeem: ah i see :-)
[15:22] <calc> azeem: mozilla-openoffice.org
[15:22] <azeem> eh?
[15:22] <azeem> s/azeem/asac/ I assume
[15:23] <calc> azeem: oh yea
[15:23] <geser> pitti or Mithrandir: please give-back: bzr doxygen. Thanks.
[15:23] <calc> asac: mozilla-openoffice.org
[15:23] <calc> asac: its only available on i386/powerpc
[15:23] <calc> asac: its broken on the other archs aiui
[15:23] <Mithrandir> geser: given-back
[15:23] <azeem> calc: I can upgrade those packages in Debian (in fact, the only reason I consider it now is because of hardy, lenny should be fine for 0.40), but how much time do I have?
[15:23] <asac> calc: ah ... ok. that explains it
[15:23] <azeem> I got work to do now, and today is Valentine's day...
[15:23] <asac> calc: any progress?
[15:23] <pitti> geser: Mithrandir beat me to it
[15:24] <Mithrandir> pitti: and I didn't even use a script. :-P
[15:24]  * asac wonders how comes that its avail on powerpc ... strange
[15:24] <pitti> Mithrandir: I repaired mine, but it was too slow
[15:25] <calc> azeem: aiui part of it is holding up synce 0.11 upload, but i don't know the details (which was why i was asking about it)
[15:25] <Mithrandir> pitti: smart bookmarks in ff are quite fast ("us $packagename"), then one click to get to the latest build, then a click on a button per failed build.
[15:25] <calc> asac: i hope to have something by tomorrow, i have a few other patches to integrate as well
[15:25] <pitti> Mithrandir: I typed "giveback bzr doxygen"
[15:25] <Mithrandir> I wish LP had something like https://launchpad.net/distros/ubuntu/hardy/+source/glibc/latest
[15:26] <pitti> I haven't installed geasemonkey for ff 3.0 yet
[15:26] <asac> calc: ok ... great. if you have questions let me know. maybe do a testbuild so we know that this is really pending
[15:26] <azeem> calc: yeah right
[15:26] <azeem> calc: I was rather asking, "If I don't upload today (missing FF), will somebody be able to get those packages synced for hardy still?"
[15:33] <calc> azeem: heh i just notice opensync is actually in main, so you would have to ask slangasek about that i guess
[15:34] <calc> azeem: and/or follow the FF exception page on wiki
[15:34] <asac> carlos: any ETA on ffox 3 locales?
[15:34] <asac> carlos: we would need them asap i guess
[15:36] <Mithrandir> asac: what does Could not find compatible GRE between version 1.9b3pre and 1.9b3pre.
[15:36] <Mithrandir> mean?
[15:37] <asac> Mithrandir: which application? i means that an application cannot find the right xulrunner
[15:37] <asac> it looks in /etc/gre.d/
[15:37] <Mithrandir> asac: firefox-3.0
[15:38] <asac> thats strange ... did you hold back xulrunner-1.9?
[15:38] <Mithrandir> no
[15:38] <Mithrandir> but firefox-3.0 is held back
[15:39] <asac> Mithrandir: ok that explains it. what holds your firefox 3 back?
[15:39] <Mithrandir> locale stuff
[15:40] <Mithrandir> (yes, I saw you talked about it above)
[15:40] <asac> yeah ... ok i should have added a breaks as well
[15:40] <asac> Mithrandir: yeah ... you have to live without locales for a while. i want to get an ETA from carlos who promissed that we get locales from launchpad this time
[15:41] <asac> if its too long i will just package new upstream versions the old way i guess
[15:41] <Mithrandir> asac: a "Breaks" would have been useful.. so I wouldn't have upgraded xulrunner or whatever breaks firefox.
[15:42] <bddebian> Riddell: If/when you get around, do you want me to revive those sync requests for etw,qonk, etc now that they have hit unstable, or just let you know here?
[15:43] <asac> Mithrandir: can you still downgrade xulrunner-1.9?
[15:43] <Riddell> bddebian: what's the 'etc'? then I can just do it
[15:43] <asac> i will upload a new xulrunner with breaks asap then i guess
[15:43] <bddebian> Riddell: Sorry, etw, dd2, and qonk
[15:43] <Mithrandir> asac: yes, by hand.  If I can find a web browser so I can get to launchpad so I can fix my web browser..
[15:44] <Mithrandir> seems like 2.0 still works.
[15:44] <bddebian> Riddell: I don't think you marked the lordsawar one invalid right?  It should be there now also.
[15:44] <Riddell> hmm, someone is already doing syncs? pitti?
[15:44] <pitti> Riddell: no, I'm not
[15:45] <asac> Mithrandir: thats luck
[15:45] <Riddell> cjwatson: are you doing syncs?
[15:52] <cjwatson> Riddell: no, it's seb128
[15:53] <cjwatson> (I looked in ps and w earlier)
[15:55] <Riddell> ok, bit confusing of him
[15:57] <Riddell> maybe he's done his 35 hours for the week :)
[15:58] <Riddell> bddebian: I've set them up, I guess seb will come back at some point and flush them
[15:58] <bddebian> Riddell: Thanks
[16:07] <tkamppeter> pitti, I have uploaded the packages now. They should appear in the NEW queue now.
[16:07] <tkamppeter> pitti, what will happen with the packages now to get into Multiverse or Restricted?
[16:08] <pitti> multiverse
[16:39] <undertaker> all:
[16:42] <slytherin> Does anyone know why this bug is not actually fixed even though it says fix released - bug 178525 The service files are still missing.
[16:42] <ubotu> Launchpad bug 178525 in bluez-utils "no available bluetooth services" [Undecided,Fix released] https://launchpad.net/bugs/178525
[16:44] <slytherin> StevenK: ping
[16:44] <juliank> Any chance to get ndisgtk into main? - Bug #191860
[16:44] <ubotu> Launchpad bug 191860 in ndisgtk "Main Inclusion Report for ndisgtk" [Undecided,New] https://launchpad.net/bugs/191860
[16:45] <slytherin> StevenK: I believe you fixed that bug related to service files. But there are actually no service files installed.
[16:45] <neighborlee> is  it true  gthumb has been removed from hardy ?
[16:45] <neighborlee> if so why
[16:46] <pitti> neighborlee: just from the default install
[16:46] <ion_>     gthumb | 3:2.10.6-0ubuntu3 | http://archive.ubuntu.com hardy/main Packages
[16:46] <neighborlee> pitti, may I ask why
[16:46] <neighborlee> oh wait..cause fspot is enough ;)
[16:47] <pitti> neighborlee: we ship f-spot by default and taught it about a 'destination directory' for import, which was deemed sufficient
[16:47] <neighborlee> fspot has no animation support ..or so I h ear is that correct ? ( maybe this is wrong  venue to discuss this , but I wanted to verify)
[16:47] <neighborlee> and honetly I still think a patent discussion about mono is stil relevant isnt' it ?
[16:47] <neighborlee> or is that off limits
[16:48] <neighborlee> if so where should I discuss it ;)
[16:48] <pochu> On debian-legal? :P
[16:48] <neighborlee> LOL
[16:48] <pochu> It's in Debian Main.
[16:48] <pochu> And we trust Debian. We are even less strict...
[16:48] <neighborlee> im just saying im being forced to use something that has less features and take more disk space and has 'patent issues' ;)
[16:49] <pochu> Is this another "let's kill mono" thread?
[16:49] <neighborlee>  I dont feel good about that ;)
[16:49] <neighborlee> it is not.
[16:49] <neighborlee> its a legitimate question about linux future ;)
[16:49] <neighborlee> I dont know where else to h ave this discussion honestly :)
[16:49] <neighborlee> the forum is a joke, as it wont get anywhere.
[16:49] <neighborlee> devs hang here typically.
[16:50] <neighborlee> though I dont kn ow h ow many of you know about the patent issues..or if im just not aware of the entirety of it all
[16:50] <neighborlee> it sounds like a mess to me.
[16:50] <neighborlee> but I dont want to come across like a complainning bitch either ;)
[16:51] <pochu> neighborlee: regarding those /patent issues/, that's not up to the devs, but to the archive admins. And I tried once f-spot and it looked nice to me, except that it copied all my pictures, but that's fixed now I believe.
[16:51] <neighborlee> it is nice visually
[16:51] <neighborlee> but IF what im told is right..
[16:51] <neighborlee> it has no animation ability
[16:51] <neighborlee> gthumb does , or so in told.
[16:52] <neighborlee> but if they are going for 'visual' I guess I understand    ..but im still not sure about this patent crap it sounds very IFFY to me.
[16:52] <slytherin> neighborlee: By animation do you mean slideshow?
[16:52] <neighborlee> but I suppose this isn't quite the right venue :(
[16:52] <neighborlee> slytherin, no
[16:52] <neighborlee> im told it wil import animations , where suposedly fspot wont
[16:52] <neighborlee> or so im told.
[16:53] <ion_> Video support would be nice indeed.
[16:53] <neighborlee> yes indeed
[16:53] <slytherin> neighborlee: So you have based your discussion on what someone have told you, not what you have actually seen.
[16:53] <neighborlee> slytherin, I see no reason they would lie.
[16:53] <neighborlee> typically ubuntu users aren't liars.
[16:54] <pochu> neighborlee: I see no reason why the archive admins will include software with patent issues.
[16:54] <neighborlee> hmm let me try to verify
[16:54] <neighborlee> typicallly I would agree
[16:54] <neighborlee> one would think ;)
[16:54] <neighborlee> assuming they are aware of all the ramifications.
[16:54] <slytherin> neighborlee: No. What I am saying is that if you use f-spot and really feel that it is inferior to ghtumb, sure go ahead and file a bug with all the points. As far as I am concerned f-spot rocks
[16:55] <neighborlee> rocks is irrelevant
[16:55] <neighborlee> disk space,,memory consumptioin stabiloity and patent issues IMO loom largely
[16:55] <neighborlee> but as I say im not sure this is the RIGHT venue for that disucssion
[16:55] <neighborlee>  ;)
[16:56] <neighborlee> im not sure where the right place is honestly for it ;)
[16:56] <ion_> I have had no problems with disk space or memory consumption, it has been stable, and personally i couldn’t care less about patent trolls.
[16:56] <neighborlee> ion_, I hope your not calling me a troll ;)
[16:56] <ion_> Nope, unless you own stupid software patents.
[16:57] <neighborlee> I dont ;)
[16:57] <neighborlee> I defintely dont
[16:57] <slytherin> neighborlee: When I say rock, it includes everything you mentioned except I don't think there are patent problems. It is just FUD.
[16:57] <neighborlee> that is the claim yes ;)
[16:57]  * ScottK wonders if any of these patents have numbers?
[16:57] <neighborlee> im not so sure its right.
[17:00] <cjwatson> neighborlee: if there are *real* patent issues to discuss, then let's discuss them on a case-by-case basis. But we cannot have a conversation about imponderable speculation.
[17:00] <neighborlee> well in part  think I worry about stability of mono aps..I mean just look what happened to beagle ,,it got replaced by  someething else..makes you wonder about mono apps in general if you ask me..and its not like there aren't alternatives to fspot and  tomboy both, but then trouble is half agree, and slightly over half agree mono shoudl be gone..at least the forum shows those numbers anyway..but then I undersgtand ubunt is a meritoc
[17:00] <neighborlee> racy ;))
[17:01] <cjwatson> beagle's lead developer lost interest, AIUI; I don't think that necessarily says anything about the implementation language
[17:01] <neighborlee> cjwatson, ok what about the latest lawsuit against novel and redhat..is that legit or something  totally separate
[17:01] <neighborlee> cjwatson, possibly
[17:01] <cjwatson> which lawsuits?
[17:01] <neighborlee> you dont know about it???
[17:01] <neighborlee> o_0
[17:01] <cjwatson> there have, as I understand it, been a number of companies suing them at various times
[17:01] <pochu> emilio@pochu:~/dev/projects/revu/trunk$ apt-cache show f-spot gthumb | grep ^Size
[17:01] <pochu> Size: 1426538
[17:01] <pochu> Size: 1367408
[17:02] <pochu> ^-- disk space doesn't look like a very strong argument...
[17:02] <neighborlee> cjwatson, is the one where novel paid M$ 42billlion in damages
[17:02] <neighborlee> cjwatson, with no specifics as to why they did
[17:02] <ion_> neighborlee: It’s not fair to compare F-Spot to Beagle. Beagle feels bloated and resource-hungry. F-Spot does not.
[17:02] <cjwatson> neighborlee: reference, please
[17:02] <neighborlee> im jus saying they both use the same language...
[17:03] <neighborlee> cjwatson, let me find please hold
[17:03] <cjwatson> are you referring to http://www.groklaw.net/article.php?story=20071011205044141 ?
[17:04] <neighborlee> let me see
[17:04] <neighborlee> cjwatson, do you at least know about the forum discussion on ubuntu about removing mono ?
[17:04] <neighborlee> if not you shoudl read it..20 pages or so but if you read fast its no biggie ;)
[17:04] <neighborlee> its informative imo
[17:05] <neighborlee> cjwatson, im not sure if that is the one, but its one of them yes...
[17:05] <pochu> We have seen the threads in ubuntu-devel-discuss@ and they lead to nowhere IMHO.
[17:05] <slytherin> can someone take a look at debdiff attached to bug 178525. It should re-fix the bug and another bug 191704
[17:05] <ubotu> Launchpad bug 178525 in bluez-utils "no available bluetooth services" [Undecided,Confirmed] https://launchpad.net/bugs/178525
[17:05] <ubotu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [Undecided,Confirmed] https://launchpad.net/bugs/191704
[17:05] <cjwatson> neighborlee: given that Novell's revenue for the financial year 2007 is about $1 billion, I'm afraid I don't believe your "42billion in damages" claim, hence my request for a reference
[17:06] <ion_> neighborlee: If F-Spot or Mono infringe on some patents, feel free to point out the patent numbers.
[17:06] <neighborlee> pochu, http://ubuntuforums.org/showthread.php?t=594767 < ok sorry i should have offered url...it is tha tone
[17:06] <cjwatson> neighborlee: it is not the first such thread, and I have read previous ones
[17:06] <neighborlee> cjwatson, and whlie its not staggering.more want it gone than want it to stay ..
[17:06] <cjwatson> forum votes are interesting, but not binding on Ubuntu development
[17:07] <neighborlee> cjwatson, I agree
[17:07] <cjwatson> we have taken a decision on this before
[17:07] <cjwatson> the current archive reflects that decision
[17:07] <neighborlee> what about the wiki that was submitted about mono removal ?
[17:07] <\sh> 14th Feb -> FF means "last day to push new stuff in" or "after 13th 23:59:59" no new stuff,please?
[17:07] <neighborlee> did that even get discussed ?
[17:08] <cjwatson> at some point you have to stop endlessly revisiting decisions unless concrete new evidence regarding patents is brought forward
[17:08] <cjwatson> rather than vague claims
[17:08] <neighborlee> was it submitted by a team member or just a regular user
[17:08] <cjwatson> anyone can create a wiki page
[17:08] <cjwatson> frequently, anyone does
[17:08] <neighborlee> right , I was jus asking if 'anyone' did or a developer
[17:08] <cjwatson> to my knowledge that did not arise from the development community
[17:09] <cjwatson> but you could check for yourself; the wiki exposes revision history
[17:09] <neighborlee> I did check but could not find who did it to ask them
[17:09] <neighborlee> ill recheck
[17:09] <neighborlee> I mean I know who did it, but im not sure how to contact them, but let me verify that
[17:10] <cjwatson> if this is https://wiki.ubuntu.com/No-Mono-by-Default, none of the people involved in that are Ubuntu developers
[17:10] <neighborlee> yes  thats the one
[17:10] <cjwatson> and, with all due respect, Canonical would be the target for any patent infringement lawsuits and it's up to Canonical to decide whether it's a worthwhile risk
[17:10] <neighborlee> well it looked very professionally drawn up, so I kinda assumed it probably was ; (
[17:11] <neighborlee> and at the time I wasn't aware 'anyone' could create wikis there for such things
[17:11] <cjwatson> you know that now
[17:11] <neighborlee> it looked like a development wiki basically is what i meant
[17:11] <neighborlee> yes
[17:12] <cjwatson> it's trivially easy to create a page that looks like that, because there is a template for it
[17:12] <neighborlee> ah ic well that explains that
[17:12] <cjwatson> developer specifications usually include less advocacy, too
[17:13] <neighborlee> ok
[17:13] <slytherin> Can anyone look at my debdiff please and let me know if it need any refinements so that I can do those in next half hour.
[17:35] <pitti> ArneGoetje: I fixed the langpack-o-matic split branch sufficiently and merged it into trunk; building packages now
[17:39] <tjaalton> are there limitatons to what the package revision must be for a new package? I uploaded some plugins for vdr yesterday, but can't see them in the queue. They were based on packages that are not in debian, so I just added ubuntu1
[17:41] <tjaalton> bbl ->
[17:47] <pitti> ArneGoetje, cjwatson, mvo: FYI, split language-support packs all uploaded now; if I ever get back ssh, I'll NEW them
[17:48] <cjwatson> 16:30:09 ERROR   Unhandled exception from processing an upload
[17:48] <cjwatson>  -> http://launchpadlibrarian.net/11924746/vG8MMJpPVrrLkVUTSDwRmR4knlT.txt (Ubuntu MOTU Developers <ubuntu-motu at lists.ubuntu.com>: no @ found in email address part.)
[17:48] <cjwatson> tjaalton: ^-- probably that
[17:49] <juliank> Any chance to use aufs instead of unionfs as the default in Hardy? The only missing part is Bug #187259
[17:49] <ubotu> Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New] https://launchpad.net/bugs/187259
[17:49] <cjwatson> we can add support, but I doubt it will be the default
[17:50] <ogra> cjwatson, i belive we have the module in l-u-m already
[17:51] <ogra> the mythbuntu guys just wrote a ltsp kiosk client using aufs
[17:51] <cjwatson> right, I just don't think it's appropriate to change the unionfs implementation at this point in the cycle
[17:51] <ogra> /opt/ltsp/i386/lib/modules/2.6.24-7-generic/ubuntu/fs/aufs/aufs.ko yeah
[17:51] <juliank> cjwatson: AFAIK, aufs is faster and more stable than unionfs
[17:52] <ogra> right
[17:52] <cjwatson> juliank: I'm not arguing with that, but at least with unionfs we have a rough idea of where the bugs are
[17:52] <cjwatson> better the devil you know etc.
[17:52] <juliank> cjwatson: Also, the Debian Live project uses it, too.
[17:52] <cjwatson> Debian is further away from a release than we are
[17:53] <cjwatson> and TBH Debian's live CDs are an order of magnitude less heavily used than ours
[17:53] <juliank> cjwatson: Kanotix uses it with the same kernel we use.
[17:54] <cjwatson> same comments apply
[17:54] <cjwatson> I'm happy to merge it and people can try it out from there
[17:55] <cjwatson> but the default will still be unionfs
[17:57] <cjwatson> it's just not something I'm comfortable changing at feature freeze
[17:57] <juliank> cjwatson: So we won't complete https://blueprints.edge.launchpad.net/ubuntu/+spec/livecd-unionfs-alternatives (Priority: medium)
[17:58] <mjg59> juliank: The aim should be to have stuff implemented by feature-freeze, not push them in untested at the last second in the hope that it'll be stabalised by release
[17:59] <cjwatson> the first step with this sort of thing is always to make it available as non-default so that people can try it out
[17:59] <juliank> mjg59: Many distributions switched from UnionFS to aufs, because unionFS was to unstable. They are happier with aufs noew
[17:59] <cjwatson> if testing *in the context of Ubuntu* finds that it is performing better *for us* (NOTE EMPHASIS) then we can consider flipping the switch at that pooint
[17:59] <cjwatson> point
[17:59] <mjg59> juliank: Which makes it a wonderful thing to investigate and integrate, at some point less than 6 hours before feature freeze
[18:00] <cjwatson> I've merged your branch and changed the default to unionfs
[18:00] <cjwatson> uploaded
[18:02] <pitti> Riddell: FYI, I just uploaded a new jockey with mhb's -kde package \o/
[18:02] <juliank> cjwatson: thx
[18:05] <juliank> cjwatson: We could also add an aufs entry to isolinux, so people having problems with unionFS can find it.
[18:05] <cjwatson> ITYM gfxboot-theme-ubuntu
[18:05] <cjwatson> but yes, it's a possibility, although I shudder to think of how to present that in a reasonable UI
[18:06] <Mithrandir> add "unionfs=au" to the kernel command line and document it, IMO.
[18:06] <juliank> We could just add an entry 'Boot...Ubuntu (Alternative UnionFS)' to the list.
[18:06] <cjwatson> Mithrandir: (union=aufs, implemented by the casper change above)
[18:07] <Mithrandir> juliank: Boot Ubuntu (with Alternative gobbeligock) ?
[18:07] <cjwatson> juliank: no way, I just got rid of all the entries from the main menu that weren't sensible user-comprehensible options
[18:07] <Riddell> pitti: awooga
[18:07] <Mithrandir> seriously, most people won't have a clue whatsoever what unionfs is.
[18:07] <cjwatson> ogra: still around? could you have a look at the seed change in http://paste.ubuntu.com/4594/ ?
[18:08] <evand> stick it and safe graphics mode in a submenu?
[18:08] <Mithrandir> "Troubleshooting" "try one of those until it works".
[18:08] <cjwatson> the F6 menu has this kind of option now
[18:08] <cjwatson> evand: already done, safe graphics mode is on F4 now
[18:08] <cjwatson> F6 is a garbage-bag of random boot options at the moment
[18:09] <cjwatson> but I would like it to be verified to work in the context of Ubuntu before advertising it
[18:09] <ogra> cjwatson, looks fine apart from the fact that ltsp can go but i can clean up later
[18:09] <cjwatson> we have had some very subtle bugs in the past that would not necessarily show up on other distributions
[18:09] <cjwatson> ogra: yeah, I left it in because Ubuntu doesn't have it on all architectures at the moment
[18:09] <evand> ah, neat!
[18:10] <cjwatson> ogra: we should figure something out about bootability of these CDs
[18:10] <cjwatson> ogra: it would be nice to give people something better than this-disk-is-not-bootable-you-fool
[18:10] <ogra> bootability ?
[18:10] <ogra> hmm
[18:11] <ogra> but what would you give them ? selections ? reboot, minimal system etc ?
[18:11] <cjwatson> I'm not sure :)
[18:11] <cjwatson> probably can't even give them a minimal system
[18:11] <cjwatson> maybe a nice note that this is an add-on disk and they need to install Ubuntu first
[18:12] <ogra> usplash alike
[18:12] <cjwatson> or gfxboot
[18:12] <juliank> Other topic: I would really like to see ndisgtk in main (Bug #191860), it's a widely used frontend for ndiswrapper. It's there since dapper and has 21526 installations.
[18:12] <ubotu> Launchpad bug 191860 in ndisgtk "Main Inclusion Report for ndisgtk" [Undecided,New] https://launchpad.net/bugs/191860
[18:12] <ogra> hmm, yeah
[18:17] <_MMA_> juliank: What would being in Main do? Moving to Main for some things can mean more restrictions.
[18:18] <juliank> _MMA_: many users requested to have it installed by default. You should also see https://blueprints.edge.launchpad.net/ubuntu/+spec/easy-ndiswrapper
[18:19] <_MMA_> With the ability to pull from Universe, its not really necessary. Unless there is something in place that would stop Ubuntu from doing it.
[18:19] <juliank> It's also very stable and does not need to be updated very often.
[18:26] <TomaszD> hello, carlos told me to stop by, can someone from the dev team please include my Polish translation into a universe package paprefs? The upstream vendor doesn't respond. https://bugs.launchpad.net/ubuntu/+source/paprefs/+bug/191854
[18:26] <ubotu> Launchpad bug 191854 in paprefs "Translation template unavailable for paprefs" [Undecided,New]
[18:26] <TomaszD> the translation is attached to the bug report
[18:26] <juliank> _MMA_: Users would like to have it included on the CD, and AFAIK adding packages from universe is not possible. And its users need it configure their internet access, so they may not be able to get it from a mirror.
[18:27] <_MMA_> juliank: Adding packages from universe is now possible.
[18:27] <cjwatson> _MMA_: not for Ubuntu it isn't
[18:27] <_MMA_> I was about to add that. :P
[18:27] <cjwatson> I think that's sort of relevant ;)
[18:27] <_MMA_> I type slow.
[18:27] <cjwatson> sigh, I need yet another germinate change for this Edubuntu seed rearrangement
[18:28] <cjwatson> lamont: happy Christmas
[18:28] <_MMA_> Was gonna say I didnt know if you had it set up for Ubuntu or not.
[18:28] <cjwatson> intentionally not
[18:28] <_MMA_> I figured.
[18:29] <lamont> cjwatson: just tell me the number and I'll expedite it
[18:30] <juliank> cjwatson, _MMA_: Having ndisgtk on Hardy disks (amd64+i386) would be cool.
[18:30] <cjwatson> juliank: I agree with you, am just too flat out to do anything about it myself. you only filed the main inclusion report two hours ago :)
[18:31] <cjwatson> seriously, it's one thing core developers leaving things to the last minute (part of the nature of things), but when you need sponsorship and assistance from other people to make changes, turning up on feature freeze day is more optimistic than anything else
[18:32] <cjwatson> (I know you had the casper/aufs thing for a while but you only said the branch was ok to merge today)
[18:32] <cjwatson> lamont: I'll do a merge for you
[18:32]  * _MMA_ reminds himself to to work on his JACK MIR for Hardy+1.
[18:33] <lamont> cjwatson: thanks
[18:35] <luisbg> _MMA_, MIR?
[18:35] <cjwatson> lamont: chinstrap:~cjwatson/germinate/germinate_0.11ubuntu11*
[18:35] <cjwatson> lamont: will file an RT too
[18:36] <luisbg> _MMA_, why JACK in main?
[18:37] <_MMA_> So we can build in JACK support for packages in Main. PulseAudio for 1.
[18:38] <luisbg> _MMA_, that makes sense
[18:39] <lamont> cjwatson: is there a way to tell ssh (in ssh_config et al) if Host matches this pattern, then append $foo to it?
[18:39] <cjwatson> hmm
[18:40] <cjwatson> unfortunately I think not, there's no expansion syntax
[18:40] <lamont> because for my other christmas presents, I want that one, and an ssh client hack for control mastery that says "if the other end said ETOOMANY, then be master instead of slave, and uh DTRT wrt control file"
[18:41] <lamont> cjwatson: how fast you want that germinate?
[18:41] <cjwatson> lamont: well, I'd like to land the edubuntu-addon changes tonight if possible ...
[18:41] <cjwatson> although after telling somebody else off for being late I may not have a leg to stand on :)
[18:42] <lamont> it's a question of 60 min, or do I get out and push
[18:43] <cjwatson> 60 mins is fine
[18:44]  * cjwatson blinks. curl build-depends on openssh-server?
[18:44] <lamont> (play human cron)
[18:44]  * lamont wonders if there's an open bug against the dhcp server that if you stop networking and restart it, you need to restart the server...
[18:48] <lamont> hrm... syncing data to my laptop at 12MB/s on a 100Mbps lan kinda tanks everything else.
[18:51] <lamont> cjwatson: and yes, I prefer nice pretty-n-merged packages to "pull this from bzr, kthx" :-)
[18:51] <cjwatson> lamont: I am so looking forward to DC hosts running hardy
[18:52] <lamont> you and all of IS
[18:52] <tjaalton> cjwatson: sheesh, copy-paste bit me big time :)
[18:52] <cjwatson> tjaalton: heh
[18:53] <tjaalton> apparently I was a bit tired at the time, oh well
[19:03] <lamont> cjwatson: if you promise not to get used to it, germinate has landed
[19:04] <cjwatson> lamont: ooh. thanks
[19:04] <cjwatson> lamont: did I get lucky timing?
[19:04] <lamont> something like that..
[19:04] <lamont> cron.daily runs at :3 and :33
[19:04] <cjwatson> beer[lamont] += 1 then
[19:05] <lamont> so I happened to look at it around :52 ish, ran cron.daily, and then fat-fingered the 'look at the queues' a few minutes later and re-rean cron.daily... go me.
[19:05] <lamont> and that cron.daily caught the binary - that part was fortuitous timing
[19:27] <asac> carlos: ping
[19:59] <cjwatson> ogra: Edubuntu converted to an add-on CD, at least theoretically; I confess I haven't yet tested it and have no idea whether it'll work first time
[19:59] <cjwatson> ogra: but I'm far too exhausted now to take it any further
[20:00] <cjwatson> ogra: you probably ought to be able to fix it up from here in light of what I've done
[20:24] <asac> bryce: how can i figure the dpi that X detects for my monitor?
[20:26] <bryce> asac: xdpyinfo | grep resolution
[20:41] <bdmurray> Amaranth: Would tagging compiz bugs based off the plugin be helpful?
[20:43] <Amaranth> bdmurray: i don't think so
[20:44] <Amaranth> bdmurray: Well, it might help me decide what ones to ignore if launchpad gives me a way to search for "all bugs that don't have tag foo" :)
[21:07] <bdmurray> Amaranth: If the bug is about a specific plug should the package not be compiz but compiz-fusion-plugins-main or extra?
[21:07] <Amaranth> if that's what package the plugin is in, yes
[21:10] <bdmurray> And is the mapping between name in CCSM and the actual plugin pretty intuitive?  It looks like it to me.
[21:11] <bdmurray> Or is there something we could look at / point to that would show the mappings?
[21:12] <seb128> jamiemcc_: hi, do you plan to roll a new tracker tarball? the hardy feature freeze is now and we will likely review if we want to keep tracker enable for hardy, having a new version with svn bug fixes could be useful there
[21:13] <jamiemcc_> seb128: yeah I was planning for this weekend - can it wait that long?
[21:14] <jamiemcc_> seb128: its all bugfixes as there are no neew features at present
[21:16] <seb128> jamiemcc_: yes, we can always get freeze exceptions, no problem, having it next week would just be nice because we likely want to look at it soon
[21:16] <bdmurray> Amaranth: Is there something we could look at / point to that would show the mappings? or is just guessing based of the plugin name effective enough?
[21:16] <Amaranth> bdmurray: I just do dpkg -S libfoo.so
[21:16] <Amaranth> where foo is the plugin name
[21:16] <jamiemcc_> seb128: yeah i understand - but we have to lots of testing before doing a release to help rpevent regressions
[21:17] <seb128> jamiemcc_: the current concern is that it creates quite some cpu and io load and not used a lot by applications yet
[21:17] <mario_limonciell> seb128, did you look at the bug that pitti commented on today regarding gmyth?
[21:17] <seb128> mario_limonciell: yeah, we discussed it on IRC, neither of us knew exactly what it brings
[21:18] <bdmurray> Amaranth: right, my question is does the plugin name match up to what it is called in ccsm pretty well?
[21:18] <seb128> mario_limonciell: slomo pointed the gstreamer code doesn't work when using 0.7 or something I think?
[21:18] <mario_limonciell> seb128, it brings support to watch recordings via native protocol for myth
[21:18] <seb128> mario_limonciell: dunno what is myth, can you describe it from a newbie user point of view?
[21:18] <mario_limonciell> seb128, i've gotten things working at home doing a local build with gmyth integrated
[21:18] <jamiemcc_> seb128: we will try and tune things so its not noticeable by auto pausing when user is moving mouse or pressing keys
[21:19] <mario_limonciell> seb128, its a tv recording server
[21:19] <mario_limonciell> seb128, you schedule recordings, and then it does them for you
[21:19] <Amaranth> bdmurray: almost not at all, about half the time
[21:19] <mario_limonciell> seb128, there is a native viewer out there, but its a bit big.  so for casual usage on a secondary or tertiary machine, this is most ideal
[21:20] <Amaranth> bdmurray: i dunno how to map the two automatically, i just do it in my head
[21:20] <seb128> mario_limonciell: how responsive is upstream? will you look after totem bugs, etc for the next years? ;-)
[21:20] <mario_limonciell> seb128, for gmyth, very responsive.
[21:20] <seb128> mario_limonciell: because that looks like rather a small usecase and we have already lot to do, I don't want to maintain that for 3 years
[21:20] <bdmurray> Amaranth: it looks like it is in the xml files
[21:21] <Amaranth> bdmurray: well, yeah
[21:21] <mario_limonciell> seb128, well its a "plugin" and off by default
[21:21] <mario_limonciell> so shouldn't hurt the majority of people
[21:21] <Amaranth> bdmurray: the name of the xml file is the name of the plugin, then inside there is the name that ccsm shows
[21:21] <mario_limonciell> i'll be glad to get myself and the rest of ~ubuntu-mythtv to triage related bugs though
[21:21] <mario_limonciell> especially until gmyth is in debian (that's the eventual plan)
[21:21] <bdmurray> Amaranth: okay that might help people out then
[21:22] <seb128> pitti: ^
[21:23] <seb128> mario_limonciell: what about the gstreamer code and 0.7?
[21:23] <mario_limonciell> seb128, i've pulled the appropriate patches from the vcs already for gstreamer
[21:24] <mario_limonciell> and  they are part of gstreamer-0.10-plugins-bad now
[21:24] <mario_limonciell> well once gmyth clears NEW at least, and it can build against it - the source package is in depwait right now
[21:50] <seb128> thekorn: the retracer crashes on     raise ValueError, "Unsupported attachment-type '%s'" %type(attachments)
[21:50] <seb128> is that a known issue?
[21:50] <seb128> commentsbase.py", line 15, in __init__
[21:52] <thekorn> seb128, do you know the content-type of the file which should be added,
[21:53] <seb128> ValueError: Unsupported attachment-type '<type 'set'>'
[21:53] <seb128> hum
[21:53] <thekorn> och, that's bad
[21:53] <seb128> that was on bug #191065 apparently
[21:53] <ubotu> Bug 191065 on http://launchpad.net/bugs/191065 is private
[21:54] <thekorn> hmm, it's private :(
[21:54] <seb128> hum, I can view this one
[21:54] <seb128> can't
[21:54] <seb128> can't type neither ;-)
[21:55] <somerville32> I can't view that bug either
[21:56] <crevette> good night
[21:56] <thekorn> seb128, the retracer is running the code of the .main branch of py-lp-bugs, right?
[21:57] <seb128> thekorn: it's running the hardy package version
[21:57] <TheMuso> c/
[21:58] <TheMuso> gah
[21:58] <propagandist> anyone know of a package using cdbs that also creates a python debug package?
[21:58] <seb128> propagandist: gnome-menus
[21:59] <propagandist> seb128: :o} thank you!
[21:59] <seb128> propagandist: you are welcome
[22:02] <thekorn> seb128, just checked the code, that's definitely a unknown issue
[22:04] <seb128> thekorn: http://paste.ubuntu.com/4599/
[22:05] <thekorn> thanks, let me create a bugreport and ask someone from the bug team to remove the"private" attribute
[22:10] <thekorn> seb128, I created bug 191963 to track this issue
[22:10] <ubotu> Launchpad bug 191963 in python-launchpad-bugs "ValueError: Unsupported attachment-type '<type 'set'>' " [Undecided,In progress] https://launchpad.net/bugs/191963
[22:10] <seb128> thekorn: thanks
[22:23] <keescook> slangasek: I assume we should just simply _not_ merge pcre3 7.6 for Hardy.
[22:23] <slangasek> keescook: yes, I expect so
[22:24] <seb128> thekorn: seems to crash on bug #191627 now
[22:24] <ubotu> Launchpad bug 191627 in terminator "terminator crashed with GError in reconfigure_vte()" [Critical,Incomplete] https://launchpad.net/bugs/191627
[22:24] <Robi1> WINE is broken in hardy
[22:24] <Robi1> fix
[22:24] <Robi1> +how do I
[22:24] <thekorn> seb128, same error?
[22:24] <seb128> thekorn: yes
[22:25] <slangasek> keescook: not completely out of the question that it /could/ be merged, but standard freeze rules apply, offer not valid in all states, yada yada
[22:25] <thekorn> let me check, sound like a change in edge
[22:25] <Robin_> `23meg_
[22:25] <seb128> thekorn: hum, the retracer should not be using edge
[22:25] <keescook> slangasek: yeah.  I have no driving need to merge it.  :)  I like stability, thanks.
[22:26] <thekorn> seb128, right,
[22:27] <keescook> Robin_: best to file a bug report (and look for duplicates first) along with steps to reproduce
[22:27] <Robin_> Do I need to register a launchpad account
[22:27] <keescook> Robin_: and then check with #ubuntu-wine too  (LP account: yes)
[22:28] <yogi> when is hardy alpha 5 expected to roll of from the compiling farm?
[22:28] <keescook> yogi: https://wiki.ubuntu.com/HardyReleaseSchedule
[22:29] <Robin_> WINE seg faults... how can someone mend this package with the stream it's stupid :)
[22:29] <Robin_> anyway off to launchpad then
[22:29] <yogi> keescook: thanks!
[22:29] <yogi> are there any 'daily snapshot' cd images? (like debian has)?
[22:30] <yogi> I hate downloading 650MB of ISO + 300MB of updates ;)
[22:30] <LaserJock> yogi: cdimage.ubuntu.com
[22:30] <_MMA_> cdimage.ubuntu.com
[22:30] <_MMA_> :P
[22:30] <yogi> thanks a lot!
[22:31] <keescook> _MMA_: http://en.wikipedia.org/wiki/Jinx_%28children%27s_game%29
[22:32] <_MMA_> Yeah, I owe Jordan a Coke now. :P
[22:32] <LaserJock> hmm
[22:33] <LaserJock> 'cept I'll have to move to NC to collect
[22:33] <thekorn> seb128, I cant reproduce this error here, parsing of this bugreport works
[22:33] <_MMA_> LaserJock: ;P
[22:36] <seb128> thekorn: k, weird
[22:36] <thekorn> seb128, the retracer is running on dapper, right?
[22:36] <seb128> thekorn: yes
[22:38] <thekorn> seb128, ok, will check this error in a dapper vm tomorrow,
[22:39] <seb128> thekorn: thanks
[22:39] <thekorn> you are welcome
[22:44] <bryce> ogasawara: can you take a look at 187855?  trying to determine if it is a kernel bug or not
[22:45] <ogasawara> bryce: sure
[22:54] <ogasawara> bryce: hard to say if it's a kernel bug, but I'll post a comment to get more info.  do you know if timo has a reference he can point us to regarding upstream claiming it's a kernel issue?
[22:54] <bryce> great thanks; you might ask tjaalton about that on the bug (I was wondering the same thing)
[23:41] <_Angelus_> guys
[23:41] <_Angelus_> i wanted to know...
[23:41] <_Angelus_> do the developers know that the bootup splash doesnt work on 64bit computers?
[23:41] <_Angelus_> i mean...  on kubuntu 64bit
[23:43] <ion_> Is there a bug report? If not, please report it.
[23:43] <mjg59> There is, and it's not all 64 bit machines
[23:44] <_Angelus_> 90% the problem is that ubuntu uses vesafb-tng instead of vesafb, vesafb-tng is not compatable with most 64bit computers
[23:45] <_Angelus_> there never was a fix , the only fix i found is, to compile a custom kernel, which worked fine...
[23:47] <_Angelus_> so probably this issue would be solved if the kernel compiled by ubuntu for 64bit systems would use vesafb..
[23:48] <mjg59> _Angelus_: Uh. No.
[23:48] <mjg59> We don't use vesafb-tng, and usplash doesn't use vesafb.
[23:48] <mjg59> It does vesa directly.
[23:49] <_Angelus_> hmm
[23:49] <_Angelus_> im reading a post from some german comunity
[23:49] <mjg59> The issue is in x86emu
[23:49] <_Angelus_> which have a fix
[23:49] <mjg59> _Angelus_: Well, it's wrong (I wrote usplash and the vesa code it uses)
[23:49] <_Angelus_> http://ubuntuforums.org/showpost.php?p=4057740&postcount=3
[23:49] <_Angelus_> it says that gutsy by default doesnt load vesafb? :/
[23:49] <_Angelus_> and its blacklisted?
[23:49] <mjg59> Yes, we don't use a framebuffer by default
[23:50] <mjg59> By default, usplash only uses a framebuffer on ppc
[23:50] <_Angelus_> i see
[23:50] <mjg59> We can't make the default setup use vesafb
[23:50] <mjg59> It interacts poorly with some graphics drivers and suspend/resume support
[23:50] <faketang> anyone here familiar with the installer for server, as in /usr/bin/main-menu on the disk's initrd?
[23:50] <_Angelus_> well, i will try to enable vesafb and the other 2modules listed in this guide and see if it solved the problam
[23:51] <mjg59> It'll probably work around the problem, but it won't solve it
[23:51] <_Angelus_> why would the bootup splash need x86emu?
[23:51] <_Angelus_> cant the bootup splash be compiled for x86_64 ? :/
[23:53] <mjg59> No, because you can't run 16-bit code on a 64-bit kernel
[23:53] <mjg59> It's your video card BIOS code that's the problem
[23:55] <faketang> where would I be able to find the source code to /usr/bin/main-menu?
[23:55] <_Angelus_> mjg59: then why does gentoo for example can have a bootup splash on amd64 arch? :S
[23:56] <_Angelus_> and i heard gentoo and ubuntu use the same bootup splash system
[23:56] <mjg59> _Angelus_: We don't use the same bootup splash system
[23:56] <crimsun_> faketang: apt-get source main-menu.  See also http://d-i.alioth.debian.org/doc/talks/debconf6/paper/ .
[23:56] <mjg59> usplash works fine on many 64 bit systems
[23:56] <mjg59> It's just some recent ones where the video BIOS triggers bugs in x86emu
[23:57] <_Angelus_> i see
[23:57] <_Angelus_> mjg59: if this guide im trying works and solves the issue, is there somewhere where i can post it so people with the same problem find it with ease?
[23:59] <faketang> crimsun_: I have no main-menu in any my repos (main/restricted/universe/multiverse); I have seen that debconf paper, but it doesn't explain how to modify the installer
[23:59] <mjg59> _Angelus_: Not really. This will almost certainly be fixed by hardy release - I just haven't had time to write the appropriate debug code yet