[12:31] <BenC> anyone else getting double mouse-click events with latest gutsy?
[12:35] <otavio> Is Tollef online?
[12:35] <Hobbsee> otavio: likely asleep - but my Mithrandir
[12:35] <mjg59> Hobbsee: Your Mithrandir?
[12:35] <Hobbsee> er, s/my/by/
[12:36] <otavio> Hobbsee: thanks a lot. I'll send him a privmsg ... thank you
[12:36] <otavio> mjg59: hey. :-D
[12:36] <otavio> mjg59: how are you doing? :-)
[12:51] <Hobbsee> mjg59: i should really be more careful with what i type, yes..
[01:29] <calc> doko: hi :)
[01:29] <Hobbsee> hiya calc
[01:50] <calc> Hobbsee: hi
[03:01] <jcole> is there a hack around the "javascript menus behind flash" bug yet?
[03:02] <jcole> for example, try to use the adobe menus -> http://www.adobe.com/
[03:45] <StevenK> Mithrandir: Can you give-back espeak on amd64 and powerpc? Thanks.
[05:45] <holycow> hey guys
[05:45] <holycow> where can i find out information on intel wireless drivers?
[05:45] <holycow> i was under the impression that they were open sourced but i keep on reading that they are binary and closed source
[05:46] <Burgundavia> holycow: they require binary firmware
[05:46] <holycow> in the u.s. i think they haveto be closed source by law but just curious in general about intel particapation in the community
[05:46] <holycow> hey Burgundavia
[05:46] <Burgundavia> intel is busy rewriting their driver right now
[05:46] <Burgundavia> new driver is called iwl, I think
[05:47] <holycow> the goal is to provide open source drivers with a firmware blob perhpas?
[05:47] <holycow> if that can be considered open source
[05:47] <Burgundavia> that is already there
[05:47] <holycow> aha! okay a bit clearer now
[05:48] <Burgundavia> http://kerneltrap.org/node/7704
[05:50] <holycow> oh! *bookmark*
[05:50] <holycow> thanks for the linkage Burgundavia, thats great
[06:24] <fabbione> morning
[06:25] <Mithrandir> StevenK: given-back
[06:25] <Mithrandir> slomo: given-back
[06:25] <StevenK> Mithrandir: Thanks!
[06:26] <StevenK> Current default timezone: 'Africa/Abidjan'
[06:36] <ajmitch> ah, forums users
[06:37] <ajmitch> has anyone else seen issues upgrading tzdata? it worked just fine for me when I updated the merge
[06:41] <crimsun> fine here, too.
[06:44] <ajmitch> I guess I can start to care iff people file bugs
[08:10] <Mithrandir> ouch
[08:11] <slomo> Mithrandir: thanks :) btw, the last mono upload will probably make you happy... it will free a few mb on the live cds
[08:11] <Mithrandir> slomo: nice
[08:12] <ajmitch> slomo: useful, what did you drop?
[08:13] <slomo> ajmitch: nothing, all the .mdb debug files are in another package now
[08:13] <ajmitch> ok
[08:14] <Mithrandir> LongPointyStick: in general, there's no point in filing bugs about removal of binary packages no longer built; we catch those automatically.
[08:14] <Mithrandir> or, semi-automatically, anyway.
[08:15] <LongPointyStick> Mithrandir: he'd have to go a long way...
[08:15] <LongPointyStick> and be a god swimmer
[08:15] <LongPointyStick> Mithrandir: ah, gotcha
[08:15] <LongPointyStick> s/god/good/
[08:16] <Mithrandir> hmm, ENOTENOUGHFOOD.
[08:16] <slomo> fabbione: could you take a look at mono on sparc? might be necessary to disable the sigaltstack stuff on sparc or there might be an easy fix ;) http://librarian.launchpad.net/7732341/buildlog_ubuntu-gutsy-sparc.mono_1.2.4-0ubuntu2_FAILEDTOBUILD.txt.gz
[08:16] <LongPointyStick> no food for you!
[08:17] <fabbione> slomo: fix mono
[08:18] <fabbione> slomo: i can't believe mono breaks on sparc on each and every single upload
[08:19] <slomo> fabbione: it's simply not supported upstream... they only care about solaris/sparc
[08:19] <persia> Mithrandir: Does the automatic catch for no longer built binaries include universe now?
[08:19] <fabbione> slomo: make them care
[08:21] <Mithrandir> persia: yes, it's always done so.
[08:21] <fabbione> slomo: there are at least 3 distros that have sparc stuff... ubuntu, aurora (FC) and gentoo
[08:21] <fabbione> slomo: i don't see why they can't consider it as part of their normal work at least not to break it
[08:23] <persia> Mithrandir: Always?  I don't understand my experience with bug #32460 then.  Is it architecture specific?
[08:23] <ubotu> Launchpad bug 32460 in supercollider "Please remove stale AMD64 supercollider binaries." [Medium,Fix released]  https://launchpad.net/bugs/32460
[08:24] <Mithrandir> persia: there, a package stopped building for a particular arch.  That's different.
[08:24] <persia> Mithrandir: I understand now.  Thanks for the explanation.
[08:25] <slomo> fabbione: let me try something... and maybe i'll talk to them later about linux/sparc but i can already tell you that they will just tell me that it is not supported *shrug*
[08:37] <slomo> fabbione: /*  * Can't use sigaction on sparc/linux, since it doesn't support SA_SIGINFO. Instead, we * have to use the obsolete sigcontext parameter: * http://www.ussg.iu.edu/hypermail/linux/kernel/0110.3/1531.html. */
[08:37] <slomo> fabbione: that's the reason why it fails
[08:37] <slomo> is this still valid today?
[08:39] <fabbione> arch/sparc/kernel/signal.c:             if (ka->sa.sa_flags & SA_SIGINFO)
[08:39] <fabbione> arch/sparc64/kernel/signal.c:                  (ka->sa.sa_flags & SA_SIGINFO) ? info : NULL);
[08:39] <fabbione> arch/sparc64/kernel/signal32.c:         if (ka->sa.sa_flags & SA_SIGINFO)
[08:39] <fabbione> same kind of catch all over the other arches, so i assume it is supported
[08:39] <fabbione> and that mail is from 2001
[08:39] <fabbione> 6 years ago
[08:39] <slomo> fabbione: ok, i'll try another thing then...
[09:04] <pygi> hi folks
[09:13] <doko> Mithrandir: it appears that packages with versions like '-1build1' are not synced anymore (doxygen)
[09:16] <Mithrandir> doko: current in gutsy is 1.5.2-2, same as unstable.
[09:16] <StevenK> It FTBFS on i386.
[09:17] <Mithrandir> well, that's hardly a sync problem. :-P
[09:17] <doko> hrm, didn't see any sync email
[09:17] <StevenK> Indeed, but it may explain why doko couldn't see it.
[09:17] <StevenK> It failed to build due to LaTeX fun.
[09:18] <Mithrandir> why would you see any?  It probably got caught by the automatic syncer.
[09:38] <jack_deltrino> How do I do what dpkg-scanpackages . /dev/null | gzip -9 > Packages.gz does with apt-ftparchive?
[09:41] <StevenK> Note to self. A package will probably build if I take the conflict markers *out* of configure.
[09:42] <jack_deltrino> Hehe.
[09:43] <dholbach> good morning
[09:43] <TheMuso> dholbach: Morning.
[09:43] <dholbach> hey TheMuso
[09:43] <TheMuso> dholbach: Mind if I take the gnome-speech merge?
[09:44] <dholbach> TheMuso: not at all
[09:44] <dholbach> thank you
[09:44] <TheMuso> dholbach: Looks like its going to temporarily break some stuff relying on it however.
[09:44] <TheMuso> dholbach: Which I'm willing to fix.
[09:44] <TheMuso> Due to soname change.
[09:44] <dholbach> ok, if you need any help, let me know
[09:44] <TheMuso> dholbach: Thanks.
[09:44] <dholbach> oh ok - you take care of adding a new binary package and all that?
[09:44] <TheMuso> Well that change was made in Debian.
[09:45] <TheMuso> Now libgnome-speech7
[09:45] <TheMuso> So the changes are a lot smaller, mainly only build/dependency differences.
[09:46] <dholbach> ok
[10:35] <pitti> Good morning
[10:39] <Fujitsu> Hi pitti.
[10:49] <fabbione> Keybuk: whatever changes you do to udev/lvm/etc.. please keep in mind multipath-tools :P
[10:50] <Hobbsee> hey all
[10:50] <Keybuk> fabbione: how would that be affected?
[10:50] <fabbione> Keybuk: multipath-tools uses some udev rules including dm-* stuff :)
[10:51] <Keybuk> *nods*
[10:51] <cjwatson> lvm-common was there when both lvm1 and lvm2 were in place to support clean upgrades. it's probably largely pointless now but it would be gratuitous merge pain in future to remove it
[10:51] <Keybuk> there might need to be an improvement to your udev rules, but nothing more
[10:51] <Keybuk> cjwatson: the problem is there are bugs that seem to go away if you remove it
[10:52] <fabbione> Keybuk: i am all up for improvements...
[10:52] <cjwatson> what, like "lvm is present"?
[10:52] <cjwatson> lvm2 Depends: lvm-common
[10:52] <Keybuk> cjwatson: lol
[10:52] <Keybuk> cjwatson: the init script seems to break several setups working with our lvm-from-udev approach
[10:53] <cjwatson> ah, so that's more "nuke lvm-common's init script" than "remove lvm-common"
[10:53] <dholbach> does anybody know what is causing bug 114509?
[10:53] <ubotu> Launchpad bug 114509 in udev "linux-image-2.6.22-1-generic + udevd = breakage" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114509
[10:53] <Keybuk> yeah, but there's nothing else *in* lvm-common, other than a cron script :p
[10:53] <cjwatson> it provides stuff like lvmiopversion
[10:53] <Keybuk> I can't find anywhere else that's used other than in its own init script
[10:53] <fabbione> iirc it's used in the installer too
[10:53] <tepsipakki> a quick gallup: do we want the split & reorganized xbase-clients/xutils to also Conflict with our current xfoo-packages? That would force removing those on upgrade instead of just replacing
[10:53] <Keybuk> dholbach: yes, I saw that lots and lots and lots yesterday
[10:54] <Keybuk> it has nothing to do with udev
[10:54] <Keybuk> it's a kernel change to the behaviour of devicemapper
[10:54] <cjwatson> fabbione: it is not
[10:54] <fabbione> cjwatson: ok cool
[10:56] <Fujitsu> Hobbsee: GNOME.
[10:57] <tepsipakki> hmm, no opinions? I'll add the Conflicts, then
[10:57] <Hobbsee> Fujitsu: ewww.  no
[10:57] <pitti> hi Hobbsee
[10:58] <Hobbsee> heya pitti!
[11:04] <pitti> Hobbsee: curious, why is that a problem?
[11:04] <Hobbsee> pitti: just slow
[11:04] <Hobbsee> pitti: although i think the link to au is where the slowness is
[11:05] <pitti> Hobbsee: ah, ok; heh, I'm used to it, being on WiFi all my time :-/
[11:05] <Hobbsee> ahh
[11:10] <seb128> pitti: yes
[11:10] <seb128> pitti: works for me on my laptop and desktop and we got no bug about it afaik
[11:10] <persia> pitti: Works for me.
[11:10] <pitti> hm, thanks
[11:10] <seb128> pitti: what error do you get?
[11:11] <seb128> try pidgin -d on a command line
[11:11] <pitti> seb128: it just doesn't want to connect
[11:11] <seb128> might lack some nss depends or something
[11:11] <pitti> oh, now it's actually connected, but i don't see any users
[11:11] <pitti> I cannot belive that suddenly all jabber contacts have been offline for a week
[11:12] <seb128> what is your jabber ID?
[11:12] <pitti> ah, it just disconnected again
[11:12] <pitti> it usually says 'XML is not well-formed'
[11:12] <pitti> seb128<EMAIL_ADDRESS>[11:12] <seb128> hum
[11:13] <seb128> maybe try the -d run to see if there is anything useful there
[11:13] <Chipzz> tepsipakki: btw, either of xserver-xorg or xserver-xorg-core depends on xbase-clients, so having it split up (as much as I like it split up) currently has little value until that dependency is removed :S
[11:13] <tepsipakki> Chipzz: yep, known
[11:13] <tepsipakki> xorg needs to be changed as well
[11:14] <tepsipakki> I just did an upgrade and it went well
[11:14] <pitti> seb128: same: jabber: Recv (ssl)(111): <stream:error><xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>
[11:14] <pitti> account: Disconnecting account 0x746cd0
[11:14] <Chipzz> currently still on feisty
[11:14] <tepsipakki> Chipzz: well, these are not even in gutsy yet ;)
[11:15] <Chipzz> and the -intel driver is broken in gutsy last I heard, so not upgrading just yet ;)
[11:15] <tepsipakki> broken how?
[11:15] <Chipzz> not working, but that was last week; may be fixed now
[11:15] <Chipzz> (the -intel driver in universe btw)
[11:16] <pochu> Chipzz: because the 1.3 xserver, you have to upgrade to -intel 2.0
[11:16] <pochu> Though yesterday night it wasn't in the archives yet, I downloaded from LP :)
[11:16] <tepsipakki> 2.0.0 was uploaded yesterday..
[11:18] <Fujitsu> Does our xserver do randr 1.2 nowadays?
[11:18] <Keybuk> we have xserver 1.3, yes
[11:19] <pitti> seb128: apparently pidgin's data dir is ~/.purple? I'll try moving this away and reconfigure my accounts
[11:19] <seb128> pitti: weird error, open a bug on launchpad, upstream read them (though they reply on some only)
[11:19] <seb128> pitti: yes
[11:19] <pitti> seb128: thanks, will do that after I digged some more
[11:20] <jmg_> dug ;)
[11:20] <pitti> jmg_: noted, thanks ;)
[11:20] <tepsipakki> xrandr the tool is old
[11:21] <tepsipakki> but when the split packaging is in experimental we can sync them
[11:48] <pitti> Mithrandir: can you please give-back libtunepimp? (dpatch breakage yesterday)
[11:50] <StevenK> Woot. My ShipIt order arrived today.
[11:58] <cjwatson> pitti: I'm thinking of starting to build the graphical installer (partly for giggles, partly because we've got the hardest of the dependencies available now and so it doesn't cost much, partly because it makes the d-i merge a good deal simpler)
[11:58] <cjwatson> pitti: but it does need a few extra bits in main
[11:58] <cjwatson> this is the alternate installer with the graphical frontend, as in Debian. I'm not wild about its UI, but a number of people seem interested in at least trying it
[11:58] <pitti> cjwatson: you mean for lvm/cryptsetup support?
[11:58] <pitti> ah, I see
[11:59] <pitti> cjwatson: the return of the gtk framebuffer stuff? :)
[11:59] <pitti> I tried it a few days ago, and while I don't see a major advantage of it, it certainly looks a bit friendlier
[11:59] <cjwatson> specifically, it needs rootskel-gtk, ttf-farsiweb, ttf-cjk-compact, ttf-tmuni, and ttf-khmeros source promotions, cdebconf-gtk-udeb binary promotion, and various binary font promotions
[12:00] <cjwatson> I don't really propose to have it be the default on the alternate CD; I think it's still too clunky
[12:00] <cjwatson> I wasn't even proposing to have them on the alternate CD ;-)
[12:00] <cjwatson> it can be netboot only for the people who want to try it
[12:00] <pitti> ah, that sounds fine
[12:01] <cjwatson> but I wanted to see what you thought; I can still disable it again if you (or others) would prefer
[12:01] <pitti> ttf-* sounds harmless, binary promotions as well (I still need to look at bugs etc.), I don't know about rootskel-gtk
[12:09] <cjwatson> pitti: I can make ttf-* optional, though rootskel-gtk and cdebconf-gtk-udeb would be required to make it work
[12:12] <pitti> grrr, the apport retraces go out as "Martin Pitt" *again*; I already fixed the cookie twice
[12:12] <pitti> seems Launchpad now keeps the cookie value and just updates the name if I log out as apport and back in as pitti
[12:13] <Hobbsee> pitti: yes, i was going to whine about that
[12:13] <pitti> indeed, it does that *tsk*
[12:14] <slomo> fabbione: ok, i give up... i'll just disable that for now until someone with access to a sparc machine fixes it
[12:14] <slomo> fabbione: http://bugzilla.ximian.com/show_bug.cgi?id=81702 if you're interested...
[12:14] <fabbione> slomo: you could also try to contact David Miller as mono/packager/upstream
[12:14] <ubotu> Ximian bug 81702 in generics "[Linux/sparc]  Fails to build with --with-sigaltstack=yes" [Unknown,New]
[12:15] <fabbione> slomo: because when you come to me with mono stuff, i just bounce it to him
[12:15] <fabbione> and it's really no point for me to proxy all the requests
[12:16] <jovans> ist there a security bugfix for  the FreeType-Bibliothek on feisty availib.
[12:17] <slomo> fabbione: later
[12:19] <shawarma> slomo: You know you have access to a sparc machine, right?
[12:25] <dholbach> where can I find out about the reason why a package's source has been removed from Ubuntu (if there's no bug filed for the removal)?
[12:25] <pitti> jovans: what do you mean any details?
[12:25] <pitti> dholbach: there's a log for it, a minute
[12:25] <pitti> dholbach: http://people.ubuntu.com/~ubuntu-archive/removals.txt
[12:26] <dholbach> thanks a lot, pitti!
[12:27] <jovans> http://lists.gnu.org/archive/html/freetype-devel/2007-04/msg00041.html
[12:27] <jovans> http://cvs.savannah.nongnu.org/viewvc/freetype2/src/truetype/ttgload.c?root=freetype&r1=1.177&r2=1.178
[12:28] <jovans> so i am going bye
[12:32] <illovae> hello
[12:34] <slomo> shawarma: no i wasn't aware of that ;)
[12:34] <pitti> keescook: jovan's message above ^, that's CVE-2007-2754; I guess it's on your radar then?
[12:34] <shawarma> slomo: ssh<EMAIL_ADDRESS>[12:34] <shawarma> slomo: Have fun! :)
[12:35] <slomo> shawarma: thanks :)
[12:35] <shawarma> slomo: np
[12:35] <shawarma> slomo: Thank imbrandon, by the way. I'm just the messenger.
[12:41] <StevenK> I'm doing the same at pycairo. The patch on patches.u.c is just under half a meg.
[12:42] <Hobbsee> mvo_: dont bother.  kde 3.5.7?
[12:42] <seb128> mvo_: what else do you expect from something starting with kde? ;)
[12:42] <StevenK> Muahaha
[12:42] <seb128> heh
[12:42] <seb128> StevenK: yeah, those python-dbg changes are no fun
[12:42] <pitti> Hobbsee: if you kick seb, I won't look for the next two minutes :)
[12:42] <StevenK> Bwahaha
[12:43] <Hobbsee> haha
[12:43] <Riddell> Hobbsee: kdebluetooth isn't in kde mainline
[12:43] <mvo_> Hobbsee: no, just regular debian merge
[12:43] <Hobbsee> ahh
[12:43] <Riddell> mvo_: what's up?
[12:43] <mvo_> Riddell: nothing special, its just *huge* and the delta seems to be 99% cruft
[12:44] <StevenK> seb128: Tell me about it. This merge also includes such fun as editing m4 macros for autoconf and re-running autoconf.
[12:44] <mvo_> Riddell: you want to have it ;)
[12:44] <pitti> seb128: oh, just for the KDE bashing; nevermind
[12:45] <Riddell> mvo_: if you leave it then I'll get to it eventually, or another kubuntu type will
[12:45] <seb128> pitti: yeah, I got it, I was just expecting from security to step and protect me from those KDE guys instead of looking somewhere else ;)
[12:45] <Riddell> although at the moment there's about three kde releases to take care of
[12:45] <mvo_> Riddell: ok, I take a closer look then
[12:46] <StevenK> Riddell: 3.5.6, 3.5.7 and 3.80?
[12:46] <imbrandon> StevenK, 3.80.x :)
[12:47] <Riddell> StevenK: 3.5.7, 3.90.1 and koffice something
[12:47] <StevenK> Fun.
[12:50] <allee> mvo, Riddell, Hobbsee: I've a pkg of kdebluetooth-dbus-integration ready.  I've pinged dgollub about some bugs that need fixing.
[12:50] <pitti> tepsipakki: hm, I'm TIL for xserver-xorg-video-voodoo; do you happen to know whether we still need the debian/ modifications?
[12:53] <pitti> tepsipakki: oh, we still need the Conflicts/Replaces: xserver-xorg-driver-voodoo until the next LTS, so no sync; I can merge this unless you want to?
[12:55] <Riddell> allee: great, actually tonio's a better dude for kdebluetooth than me
[12:55] <allee> Riddell: your on the list just because you mentioned kdebluetooth too  :)
[12:56] <pitti> tepsipakki: ah, nice, that's even in Debian
[01:00] <allee> mvo_: relax.  I take care of kdebluetooth
[01:01] <Riddell> allee: do you remember if we had a spec registered for bluetooth in kubuntu?
[01:01] <Riddell> I can't see it now
[01:02] <allee> Riddell: tonio wanted to write it.  I've seen him working on it last day at UDS
[01:02] <imbrandon> Riddell, i think i rember seeing one, but i cant be sure
[01:10] <StevenK> Mithrandir: Can you look at/voluntell someone to poke at the ia64 buildds. Both of the AUTO are showing as IDLE, and builds are piling up.
[01:11] <pitti> doko, Mithrandir: does any of you feel a particular urge to merge ia32-libs? if not, I'll see to that now
[01:11] <pitti> doko, Mithrandir: we only need it as a build dep of mbr now, so I'm not too afraid of breaking the world
[01:12] <\sh> pitti, please leave it functional, so I can try to build wine32 on x86_64 ;)
[01:12] <pitti> well, I didn't propose to upload something untested :)
[01:12] <doko> pitti: an update should be enough, never merged that. maybe have a look, which additional packages debian includes
[01:12] <pitti> I just meant that we don't need it any more for OO.o, so I'll test-build mbr and check it with vmware
[01:12] <pitti> doko: we also need to drop some binary packages
[01:13] <pitti> doko: and debian has quite a lot of fixes and updates, too, and we didn't merge any more since breezy
[01:15] <pitti> Keybuk: it's not yet enough for OO.o ;)
[01:15] <Keybuk> talking of S&M ... time to merge lvm2
[01:15] <Hobbsee> you poor people
[01:18] <StevenK> Hobbsee: Yes. Look what you have to look forward to - main merges.
[01:18] <StevenK> Oh, wait.
[01:18] <Keybuk> heh
[01:18] <Keybuk> so, you know how earlier, I was trying to work out what lvm-common actually did
[01:18] <Keybuk> turns out it's obsoleted by the new Debian lvm2
[01:18] <Lure> Riddell: https://blueprints.launchpad.net/ubuntu/+spec/kubuntu-bluetooth
[01:19] <Hobbsee> heh
[01:22] <Company> asac: i have some comments about "easy codec install" in FreeFlash - should i bloat the wiki or do you wanna discuss it here?
[01:23] <asac> Company: if your comments are well thought ... add it to wiki ... if you want to discuss it first ... lets discuss :)
[01:23] <asac> improvements always welcome
[01:23] <Company> asac: i think hooking into a playing flash file for the easy codec stuff is a bad idea
[01:24] <Company> asac: 1) it's not as simple as in the wiki, since sound can be in lots of places
[01:25] <Company> asac: 2) flash files are expected to be self-contained and it would break that model
[01:25] <Company> asac: since it is well known which codecs are needed, why don't you do codec-install them upon package install or first start of the flash player?
[01:27] <asac> Company: looking at gnash code it appears that flash actually gives up if the codec isn't found.
[01:27] <asac> which is the place where to hook in codec install
[01:28] <Company> "gives up" as in stops playback?
[01:28] <asac> imo doesn't matter ... the codec install will be asynchronous ... so even it it goes ahead ... it doesn't matter
[01:29] <asac> Company: its just not there for the current flash movie ... next one will discover it ... or maybe after restart
[01:29] <Company> hrm yeah, that's weird
[01:30] <asac> Company: my solution looks pretty easy to realize ... tricky things are in "outstanding issues"
[01:30] <Company> i'd prefer if it happened upon install or when instantiating the flash plugin the first time
[01:30] <asac> actually i would like to find a way to start easy codec install for swfdec as well
[01:30] <asac> so we have the option to switch
[01:30] <Company> yeah, that's where i'm coming from ;)
[01:31] <asac> i know :)
[01:32] <Company> asac: you wouldn't catch the mp3 playback (or other audio codecs) with hooking into netstream
[01:32] <asac> Company: in a perfect world we could hook in the easy code install to the gui code
[01:33] <pitti> erk, ia32-libs merge is an utter mess
[01:33] <Company> i would hook (in swfdec) the easy codec stuff into the mozilla plugin and upon plugin_init or plugin_new_instance do the check for the required formats
[01:34] <Company> unless it's possible to do as a package post-install hook
[01:34] <Company> in which case i'd run it there
[01:35] <Company> but i'm not a packager, so no clue about that possibility
[01:35] <Company> the difference between ie totem and flash is that totem plays anything, while flash needs 3 formats, so it doesn't make a lot of sense to defer installing codecs until later (imo)
[01:40] <asac> Company: how should mozill introspect flash movies to see a missing codec?
[01:40] <asac> i don't think that is feasible
[01:40] <Company> mozilla shouldn't
[01:40] <Company> the plugin should
[01:41] <Company> swfdec's or gnash's moz plugin
[01:41] <Company> just check if the 3 required codecs exist and if not, launch codec install
[01:41] <asac> point is you cannot touch mozilla plugin code without risking severe breakage all over the universe :)
[01:42] <asac> Company: its important for us that codecs that are not shipped in main get installed lazily
[01:42] <asac> e.g. just if you need them
[01:42] <fabbione> or make a big fat plugin wrapper
[01:43] <fabbione> but that's like adding a can of worms
[01:43] <Company> i don't want to touch moz code at all
[01:43] <Company> i want to touch swfdec-mozilla code
[01:43] <asac> ah ok
[01:43] <Company> or make you do it :p
[01:43] <asac> now i get your point
[01:43] <asac> gnash has a standalone player as well
[01:43] <asac> i want it to work for that one as well
[01:44] <asac> swfdec might have a standalone player at some point ... right?
[01:44] <Company> right
[01:44] <Company> in gnash you could hook into the standalone player
[01:44] <asac> ... so adding that to mozilla plugin code is not really a solution
[01:44] <Company> since the plugin just launches that one using XEmbed
[01:44] <pitti> doko: does ia64 now have a native oo.o, or do we still need the lib32z1/lib32stdc++6 packages from ia32-libs on ia64?
[01:45] <Company> if you want the xid you'll have to do it anyway
[01:45] <Company> since swfdec doesn't know about X
[01:45] <asac> but gtk knows :) ... at least conditionally
[01:46] <Company> right
[01:46] <Company> but swfdec soesn't know about gtk either :p
[01:46] <asac> so where do you get the window you draw upon from?
[01:47] <Company> swfdec uses cairo
[01:47] <Company> so the apps create a cairo context and pass that one to swfdec
[01:47] <asac> ok ... i see ... for swfdec we might need to add that plugin install to wrapping application (e.g. mozilla-plugin + maybe standalong player)
[01:48] <asac> anyway ... we need some detailed feedback from swfdec api about missing codecs
[01:48] <asac> same goes for gnash of course ... which is the outstanding issue: extend backend/server contract to notify UI about missing codecs
[01:49] <Company> yeah, that's the other point
[01:50] <Company> why can't you just check all required codecs no matter if you need them for the current flash files or not?
[01:50] <asac> because we don't want to encourage people to install things that they don't need
[01:51] <asac> especially if those things are not in main
[01:51] <asac> or have patents etc.
[01:51] <tepsipakki> pitti: yes, I should've mentioned that the changes are in debian now..
[01:51] <tepsipakki> pitti: did you notice the others too?
[01:51] <pitti> doko: oh, ia64 doesn't have any OO.o any more in the first place; so we dont' actually need to care any more
[01:51] <Company> so you want to delay install until the last possible second?
[01:51] <pitti> tepsipakki: I just synced it
[01:51] <pitti> tepsipakki: 'the others'?
[01:51] <asac> Company: right
[01:52] <Company> hrm
[01:52] <tepsipakki> pitti: in the bug, -mga, -suncg6, -via
[01:53] <Company> it's not that it's hard to export functionality to detect missing plugins
[01:53] <tepsipakki> oh, and discover-data
[01:53] <pitti> tepsipakki: I just looked at the merge, and didn't see a sync request bug for -voodoo; I didn't look at any other bugs
[01:53] <Keybuk> Will remove the following packages from gutsy:
[01:53] <Keybuk> lvm-common | 1.5.20ubuntu4 | hppa
[01:53] <Keybuk> lvm-common | 1.5.20ubuntu12 | amd64, ia64, powerpc
[01:53] <Keybuk> lvm-common | 1.5.20ubuntu14 | source, i386, sparc
[01:53] <asac> Company: you use gstreamer as well, right?
[01:53] <Company> it's just that it's a lot of work and would probably look ugly
[01:53] <Company> asac: yes
[01:53] <tepsipakki> pitti: ok :) bug 115963
[01:53] <ubotu> Launchpad bug 115963 in Ubuntu "Please sync from Debian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115963
[01:53] <asac> ok ... actually its just a notify signal
[01:53] <asac> Company: what would be ugly about that?
[01:53] <pitti> Keybuk: -m '(Keybuk) Those suck and we do not like them any more'  ?
[01:54] <pitti> tepsipakki: ah, I see
[01:54] <Keybuk> pitti: conflict/replace'd by lvm2
[01:54] <Company> asac: getting the notify signal from inside swfdec out to the application runing it
[01:54] <asac> yes ... might be an implementation issue ... but for the general swfdec api contract it won't do any harm
[01:54] <doko> pitti: correct
[01:54] <asac> even more so if you don't depend on swfdec users to actually deal with that notification
[01:55] <Company> swfdec doesn't expose the multimedia codes in its api
[01:55] <pitti> doko: thanks; this will make the delta much smaller
[01:55] <Company> they're buried very well deep inside the code :)
[01:55] <fabbione> Keybuk: so i can sign with blood my machines won't boot anymore? :)
[01:55] <asac> Company: right ... its just a codec name afaik
[01:55] <tepsipakki> pitti: sorry, I thought you were doing archive-admin duties :)
[01:55] <pitti> tepsipakki: no, just reviewing my merges; my archive day is Friday
[01:55] <asac> e.g. like an error detail
[01:55] <Company> and you want to stop playback of the flash file until the codec installation is done
[01:55] <Keybuk> fabbione: you mean they booted now? :p
[01:55] <Company> and then continue with the codec
[01:56] <fabbione> Keybuk: well sometimes...
[01:56] <Company> which is something that the app would need to know about
[01:56] <asac> Company: would be nice to restart after codece install is finished ... but its not necessary to stop it ... as its not getting worth then before i guess :)
[01:56] <asac> Company: yes ... the app should deal with that ... we agree
[01:56] <Company> would be weird if you get sound but no video
[01:56] <asac> but its the case atm, right?
[01:57] <asac> anyway ... app can do everything ... e.g. stop
[01:57] <asac> continue
[01:57] <Company> yes
[01:57] <asac> its not in the realm of lib to decide that
[01:57] <asac> just allow app to deal with that by singaling a missing codec
[01:57] <Company> yeah, i'd somehow need to get that info out there
[01:58] <asac> Company: if we can find a way to do that, we can do the app/plugin stuff after that.
[01:58] <asac> ... which is actually the thing i want to do with gnash as well :) ... but i am not sure if gnash devs will understand me :)
[01:58] <Company> i still think doing a dialog like "You just installed Flash. Flash might need proprietary codecs. [Install now]  [Ignore] " on first run would be better
[01:59] <Company> in particular for my api ;)
[01:59] <Company> anyway, i'll think about it some more
[01:59] <Company> gtg now
[01:59] <asac> yes ... but thats not the vision
[01:59] <asac> Company: just provide info what codec is missing
[01:59] <asac> :)
[01:59] <asac> for now
[01:59] <asac> that is a good base to everything we want.
[02:00] <asac> ok ... me lunch
[02:59] <slomo> hm, what happened to the ia64 buildds? they're all idle although stuff needs building
[03:00] <Mithrandir> slomo: we're already investigating
[03:00] <slomo> ok
[03:38] <glatzor_> mvo: what  is zour problem? I have got several machines with luksformat
[03:39] <mvo> glatzor_: luksformat /dev/sdb1 does not work for me
[03:39] <mvo> strace says it tries to access something in /dev/mapper/temp-crypsetup etc  - then it times out and it stops
[03:42] <glatzor_> mvo: you could try if loading the aes and sha256 modules helps
[03:43] <glatzor_> your command was: cryptsetup luksFormat /dev/sdb1
[03:43] <mvo> glatzor_: tries that without success on a stock feisty system
[03:46] <mvo> glatzor_: joy! if I luksformat the beast on a different system (e.g. a debian one) then mounting works fine. just creating the thing in the first place is broken it seems
[03:46] <glatzor_> mvo: I haven't formatted any new disk using Ubuntu for some time.
[03:47] <glatzor_> mvo: oh, I just figured out that mounting is also broken in GNOME :)
[03:47] <glatzor_> mvo: oh, I just figured out that mounting is also broken in GNOME :)
[03:47] <mvo> works for me
[03:47] <mvo> (fiesty)
[03:48] <glatzor_> perhaps I should use a smaller key
[03:48] <glatzor_> and try again
[03:49] <glatzor_> oh my god, the first after my move to the new flat, that I drive to recycling park.
[03:55] <Keybuk> Seveas: ping?
[03:55] <Seveas> Keybuk, pong
[03:55] <Hobbsee> Keybuk: he went mad, so we shot him.
[03:55] <Keybuk> ah, excellent
[03:57] <Hobbsee> i dont htink he had any objections
[04:08] <Keybuk> mathiaz: welcome ;)
[04:10] <cypherbios> mvo: have you had a change to take a look over this bug https://bugs.launchpad.net/ubuntu/+source/apt/+bug/115536 ?
[04:10] <ubotu> Launchpad bug 115536 in synaptic "apt-cdrom add fails to mount the medium" [Undecided,Unconfirmed]
[04:10] <mvo> cypherbios: checking
[04:11] <cypherbios> mvo: apt tries to mount /cdrom/, but in ubuntu's default fstab the mounting point is /cdrom (without the slash) then I got the error
[04:14] <cypherbios> mvo: if I manually change the fstab adding the slash, everything works fine
[04:14] <mvo> cypherbios: I anwer in the bugreport. I haven't reproduced it yet, but I can give you a workaround
[04:17] <pitti> \sh: btw, the current Debian package talks about 'wine symlinks'
[04:17] <pitti> \sh: do you happen to know how they need to look like? and where?
[04:17] <pitti> \sh: Debian package creates SONAME-less symlinks in /emul/ia32-linux/usr/lib
[04:29] <vijay2000> hi all
[04:29] <vijay2000> i am new to this community
[04:29] <vijay2000> i need somebody to mentor me
[04:30] <vijay2000> i want to get involved in ubuntu community activities
[04:30] <Keybuk> vijay2000: welcome; the best way into the ubuntu development community is through the Masters Of The Universe team -- on #ubuntu-motu
[04:30] <pitti> vijay2000: depends on what you actually want to do; if you want to help out with software development, then as Keybuk says
[04:31] <vijay2000> keybuk: i have posted request to MOTU. i am yet to get a reply
[04:31] <cypherbios> mvo: yes, If I use apt-cdrom add --cdrom /cdrom/ or --no-mount it works well but will not automount the media (which is the cool thing of apt-cdrom)
[04:31] <vijay2000> i feel i can also do documentation
[04:32] <vijay2000> i would like to know wat will b the next step after getting a mentor
[04:32] <mvo> cypherbios: if you tell me what you need exactly, I'm pretty sure I can help you. synaptic has all the stuff in place to add a cdrom with graphical progress etc
[04:33] <mvo> cypherbios: and you can give it a lot of options so that it will look into different mount points, not mount/umount etc
[04:33] <mvo> cypherbios: check the bug, I added some notes there
[04:33] <pitti> vijay2000: https://wiki.ubuntu.com/UbuntuDevelopment has detailled descriptions of the processes and starting points; do you know this already?
[04:34] <cjwatson> I also referred vijay2000 to https://wiki.ubuntu.com/ContributeToUbuntu on another channel
[04:34] <pitti> vijay2000: https://wiki.ubuntu.com/DocumentationTeam as well
[04:34] <cjwatson> this answers his question above, so I guess he hasn't read it yet ..
[04:34] <pitti> cjwatson: thanks for that link, will use it in the future
[04:36] <vijay2000> i have read the links that are given by watson and pitti
[04:37] <vijay2000> i have also joined the mailing list
[04:37] <Hobbsee> vijay2000: now pick something you're interested in, and work on it?
[04:39] <vijay2000> i am interested in software development .. but my knowledge in C is not tat good .. i have been working on microsoft technologies all these years... can i still get into software development
[04:39] <vijay2000> i am good in the concepts though
[04:40] <cjwatson> there are lots of pieces of software in Ubuntu written in languages other than C
[04:40] <cjwatson> it really does depend on your own specific interests though; the best free software developers often start out by finding something that bothers them personally
[04:42] <vijay2000> i wanted to get involved in developing software which can be used by people across geographies
[04:44] <vijay2000> can i get involved in kernel development
[04:44] <vijay2000> i am very much interested in it
[04:45] <pitti> vijay2000: do you already have some experience with it?
[04:46] <vijay2000> no i dont have experience in it
[04:46] <vijay2000> i am a new bie to linux
[04:47] <pitti> vijay2000: let's do this in /msg
[04:49] <cypherbios> mvo: sorry, I was not clearly in the bug description: In a fresh install of Ubuntu in my notebook when I open Synaptic and select 'Add CDROM...' I get an error: 'E: Failed to mount the cdrom.' and nothing happens
[04:50] <cypherbios> mvo: I think this happens because Synaptic (apt) tries to mount a mounting poing (/cdrom/) different on the fstab's one (/cdrom)
[04:58] <\sh> pitti, don't bother about wine symlinks...the debian package for wine32 on x86_64 is more then evil...
[04:59] <pitti> \sh: right, I just disabled them for now until we know what we need
[05:00] <\sh> pitti, actually when we could provide an easy to use 32bit libs for 64bit archs for the need to be used wine libs (it's really evil, because we need to -m32 some xorg libs) that would be cool...but I'm not a fan of this hack of debian
[05:04] <dholbach> so now that I got past the dm-*/evms hurdle with 2.6.22-5, my wireless does not work at all with my x40 - is anybody else having similar problems?
[05:08] <mvo> dholbach: oh, how did you fix the dm-* fun? my amd64 does not boot  with the same messages
[05:08] <dholbach> mvo: sudo dpkg -P evms{-ncurses,} "fixed" it for me
[05:09] <mvo> dholbach: thanks, I will try that
[05:10] <dholbach> anytime
[05:14] <dholbach> seb128: booting the old kernel still worked
[05:15] <seb128> dholbach: didn't upgrade that neither ;)
[05:15] <dholbach> right
[05:16] <seb128> my catching up with desktop bugs starts being good, I might upgrade later ;)
[05:16] <seb128> 46 unread bug mails and it was over 400 one week ago
[05:17] <coleb> Has anyone seen this error when doing a cvs login? cvs: ldap-nss.c:1374: do_init: Assertion `cfg->ldc_uris[__session.ls_current_uri]  != ((void *)0)' failed.
[05:30] <Riddell> pitti: was it apport that has code to test for the current desktop?  (KDE/gnome etc)?
[05:30] <pitti> Riddell: /usr/bin/ubuntu-bug
[05:30] <Riddell> thanks
[05:40] <pitti> mjg59: do you have time to merge laptop-mode-tools?
[06:00] <ssam> i am not sure if there is anything that can or should be done, but there is talk on the internet of a worm targeting openoffice http://www.sophos.com/virusinfo/analyses/sbbadbunnya.html
[06:02] <ssam> i can't see any information about whether it is exploiting an oo bug, or just doing standard macro stuff
[06:12] <cjwatson> mvo: has there been a discussion about the URI syntax proposed in https://wiki.ubuntu.com/AptFirefoxFileHandler? I have some comments
[06:13] <mvo> cjwatson: only a discussion in the BOF. I'm very happy about feedback for the syntax
[06:14] <cjwatson> mvo: firstly, it seems that for a single package (even with options) the syntax ought to be non-hierarchical, so apt:unrar rather than apt://unrar
[06:14] <tkamppeter> pitti, Mithrandir, I have now made available a merged Ghostscript where http://bugs.ghostscript.com/show_bug.cgi?id=689237 is worked around, so it has no regression against gs-gpl-8.56.
[06:14] <ubotu> bugs.ghostscript.com bug 689237 in PDF Interpreter "gv, kghostview, and pdf2ps hang with GPL GS 8.57 or newer, both trunk and gs-esp-gpl-merger" [Critical,New]
[06:14] <tkamppeter> I think this we can upload into Gutsy.
[06:14] <mvo> cjwatson: that synatax was selected to stay compatible with guadalinex, they have deployed a similar system since some time already
[06:15] <pitti> tkamppeter: yay
[06:15] <pitti> tkamppeter: are there any remaining differences to Debian now?
[06:15] <pitti> tkamppeter: i. e. what will go into Debian, not what's in it currently
[06:15] <cjwatson> mvo: secondly, the deb%20http://blah syntax is very obscure; could I suggest simply apt+http://blah instead? there are other schemes that do that sort of thing (svn, bzr)
[06:16] <tkamppeter> No, I have overtaken everything which the Debian maintainer suggested, so I think it will go into Debian the same way.
[06:16] <cjwatson> mvo: I'm not sure that should be an overriding concern, since it isn't standardised
[06:16] <keescook> pitti: CVE-2007-2754> yup, on the radar just behind the pending php and samba updates
[06:16] <cjwatson> mvo: we could support apt://unrar but recommend apt:unrar
[06:17] <tkamppeter> pitti, you are CCed on all my e-mails concerning this.
[06:17] <pitti> tkamppeter: right, that looked promising
[06:17] <cjwatson> mvo: I'm also not sure I see the use for apt://multiverse?add-component - shouldn't apt: use a temporary sources.list that overrides your usual configuration while installing from the browser?
[06:17] <pitti> tkamppeter: I'll upload this in a bit and care for the removals of the other gs'es
[06:18] <tkamppeter> Thanks, pitti.
[06:18] <cjwatson> mvo: I think it would be a lot clearer if apt: URIs always caused a package to be installed, rather than mixing it up with sources.list maintenance
[06:19] <mvo> cjwatson: the idea behind add-component and add-repository was that the repositories are added permanently - but I see the value in having it enabled only temporarely
[06:19] <cjwatson> mvo: my suggestion would be something like apt+http://launchpad.net/~mvo/ppa/test:ppa-key:mvos-new-package
[06:19] <mvo> cjwatson: hm, maybe not. the good thing about adding repositories permanently is that we can automatically ship updates this way
[06:20] <cjwatson> though I'm not sure I entirely like that either - but it's better than %20 sprinkled through the URI
[06:20] <cjwatson> mvo: I don't think we should conflate too much into this. URI syntax ought to be simple, not a fully-functional language
[06:20] <cjwatson> a URI is supposed to describe a single accessible resource, not an arbitrary set of actions to be performed on your system
[06:21] <mvo> cjwatson: the alternative to this would be a control file thing to add repositories. some mechanism for this would be good to have for PPAs
[06:21] <cjwatson> as I said, I think we could ship apt: URIs that install packages from PPAs without having to add the repository permanently to sources.list
[06:22] <mvo> cjwatson: that would mean that the user does not get automatic updates from it. if that is something we can life with, I'm fine with that
[06:22] <cjwatson> but I do think adding repositories using the same syntax is a really bad idea - the UI ought to be quite different
[06:22] <cjwatson> that's true - can I suggest using a different URI scheme then?
[06:22] <mvo> cjwatson: sure
[06:22] <cjwatson> apt-repository: or something if you want to do that
[06:23] <cjwatson> the URI scheme as written just seems really easy to get wrong
[06:24] <mvo> cjwatson: ok, that sounds good. this way the whole thing gets a lot easier/clearer
[06:24] <cjwatson> actually, it would kind of make sense if it always pointed to a package, even if it added a repository along the way
[06:24] <mvo> cjwatson: do you think we should still support apt+http:// handlers?
[06:25] <mvo> cjwatson: which one should always point to a package? the apt-repository: link? or apt: link?
[06:25] <pitti> tkamppeter: http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/gs-gpl/ still has the version from May 17th; this doesn't have the workaround you mentioned yet?
[06:25] <cjwatson> how about apt+http://launchpad.net/~mvo/ppa/test/?mvos-new-package ?
[06:26] <cjwatson> and have a db in /usr/share/app-install/ that can map the pre-? portion of that to a key
[06:26] <cjwatson> that fits the generic URI syntax
[06:27] <bddebian> Heya
[06:28] <cjwatson> or apt+http://launchpad.net/~mvo/ppa/test/?component=multiverse?package=mvos-new-package
[06:28] <mvo> cjwatson: I like the later better
[06:28] <cjwatson> with that sort of thing you could also embed versioning if need be
[06:29] <cjwatson> and the UI can notice if the repository isn't in sources.list and ask you whether you want to add it permanently in order to get updates, or just use it for this one install, or cancel
[06:29] <cjwatson> does that sound good?
[06:29] <mvo> cjwatson: yes, that sound pretty good. this waywe eliminate the need for a second protokol type as well
[06:30] <cjwatson> I'm not sure how to do multiple packages; it doesn't really seem idiomatic for URIs to point to multiple resources
[06:30] <cjwatson> but I wonder whether that is necessary - if it's very common to install multiple packages at once, one can always build a metapackage
[06:30] <mvo> cjwatson: we could allow packages=one,two,three or simply multiple package= statements
[06:30] <cjwatson> sorry, I know I'm coming in late and kind of blowing the spec out of the water :-/
[06:31] <cjwatson> I only just saw it due to a reference from elsewhere
[06:31] <mvo> cjwatson: that fine. I'm happy as long as it makes the spec better
[06:32] <cjwatson> I'm guessing it should be no more difficult to make firefox support apt+http and apt+ftp as well as apt
[06:32] <mvo> cjwatson: I haven't looked at the bits required in ff yet, but I suspect it would not
[06:33] <mvo> cjwatson: how about I merge our discussion and your suggestions into the spec tomorrow morning and you have a additional look at this then?
[06:33] <cjwatson> that leaves the question of what apt: alone should do - presumably apt:foobar?minversion=1.0 is a shorthand for ?package=foobar?minversion=1.0 and can only be used for packages in the standard Ubuntu repositories
[06:33] <cjwatson> mvo: sure, sounds good, thanks
[06:34] <mvo> cjwatson: exaclty
[06:36] <ion_> Looks like a nice URI scheme.
[06:42] <pitti> I cannot believe it -- echo -e is broken
[06:43] <pitti> doko: it seems that bash's internal echo now doesn't evaluate escapes correctly any more: echo -ne '\007' works, but echo -ne '\125' doesn't
[06:45] <pitti> doko: it does work with /bin/echo
[06:46] <pitti> doko: and it works with etch's bash (3.1dfsg-8)
[06:47] <ion_> pitti: printf ftw. :-)
[06:47] <pitti> ion_: yes, that's what I am using as a workaround
[06:48] <pitti> ion_: but it means another delta to Debian
[06:54] <pitti> doko: I filed this as bug 116226
[06:54] <ubotu> Launchpad bug 116226 in bash "echo does not handle escapes any more" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116226
[06:55] <cjwatson> pitti: 'help echo' says:
[06:55] <cjwatson>         \0nnn   the character whose ASCII code is NNN (octal).  NNN can be
[06:55] <cjwatson>                 0 to 3 octal digits
[06:55] <cjwatson> pitti: I think you need to make it begin with 0 (\0125). This is consistent with C
[06:56] <pitti> cjwatson: hm, that would be four digits then, and it's inconsistent with what /bin/echo and printf do
[06:56] <cjwatson> I note that etch's 'help echo' says:
[06:56] <cjwatson>         \num    the character whose ASCII code is NUM (octal).
[06:56] <cjwatson> pitti: the NNN part is three digits
[06:56] <pitti> ah, right
[06:57] <cjwatson> c.  The `echo' builtin now accepts \0xxx (zero to three octal digits following the `0') in addition to \xxx (one to three octal digits) for SUSv3/XPG6/ POSIX.1-2001 compliance.
[06:57] <pitti> well, ok, it's an Ubuntu delta in either case, so it doesn't actually matter much
[06:57] <cjwatson> upstream change in bash 2.05b-beta1
[06:57] <pitti> cjwatson: \125 still works in bash 3.1 (etch and edgy)
[06:58] <pitti> apparently they now dropped the old behaviour
[06:58] <cjwatson> mm, I don't see that in CHANGES
[06:58] <cjwatson> probably worth chucking at upstream
[06:59] <cjwatson> mvo: one other query I have is whether minversion (or >= or whatever) is necessary - it only seems useful for dependencies, in which case you can just put it in a Depends: line
[07:00] <cjwatson> (we don't support 'apt-get install foo (>= 1.0)', after all, although once in a blue moon I find a use for that in the installer)
[07:01] <cjwatson> mvo: also dependencies between PPAs are probably worth considering - maybe ?extrarepository=http://blah ?
[07:01] <cjwatson> though I realise that risks building back up to the complexity of the original :)
[07:02] <mvo> cjwatson: good point. the use-case I had in mind was something like "the new gaim support the $foo protocol. install it now: apt://gamin?minversion=$version-that-supports-foo". but it should be fine to leave it for later
[07:02] <cjwatson> interesting
[07:03] <cjwatson> I see what you mean - maybe mention that in the spec?
[07:03] <mvo> cjwatson: interdependencies between repositories is something I would like to keep away from for now. the good thing about the uri-schema is that it is easily extensable. lets see how people use the PPAs. I wonder how many will "stack" them in a way that we need this feature
[07:03] <mvo> cjwatson: ok
[07:04] <cjwatson> mvo: *nod*
[07:04] <cjwatson> I sort of assumed that was why you had the sequence-of-commands thing in that design
[07:05] <cjwatson> and of course you can always just have multiple links in the documentation ..
[07:05] <cjwatson> I do like asac's suggestion of using this to integrate plugin installation
[07:05] <mvo> cjwatson: yes, that is a good use-case for tihs too
[07:06] <mvo> cjwatson: we can build some funky c-n-r thing with it too
[07:09] <pitti> tkamppeter: ah, found it at http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/ghostscript/
[07:11] <ion_> It would be interesting to add quickly indexed I support... metadata to packages, such as: mime:video/x-matroska mime:video/mpeg;fourcc=xvid,XviD,XVID protocol:client/xmpp hw:usb:v*p*d*dc*dsc*dp*ic03isc*ip*
[07:18] <tkamppeter> pitti, did you not see the link in my e-mails? Sounds like you needed to search for my packages.
[07:18] <asac> cjwatson: what suggestions do you need?
[07:18] <pitti> tkamppeter: yup, saw it too late
[07:19] <cjwatson> asac: read my sentence again :-)
[07:19] <cjwatson> asac: I meant I liked your existing plan
[07:19] <elmo> More than one copy of package bzr has been unpacked in this run !  Only configuring it once.
[07:19] <elmo> Setting up bzr (0.8.2-1ubuntu3) ...
[07:19] <elmo> except I installed bzr 0.8 and bzr 0.16 - surely configuring the later one would have been more useful?
[07:20] <cjwatson> probably depends what order they got unpacked in ...
[07:20] <asac> cjwatson: ah ... i have no special requirements on the apt: protocol handler ... it should just allow specific packages to be installed :)
[07:20] <cjwatson> which might just have been command-line order?
[07:20] <elmo> cjwatson: yeah, they were unpacked in 0.16 0.8 order due to shell glob expansion
[07:20] <asac> maybe i need kind of "from which repo" ... if there are multiple versions found
[07:20] <cjwatson> right, so it couldn't configure 0.16 because it wasn't there any more :)
[07:21] <cjwatson> might be nice if it sorted multiple unpacks though
[07:21] <elmo> oh, err, right
[07:38] <pitti> tkamppeter: btw, I never got an email pointing to the updated URL with the 'ghostscript' package. Maybe you just forgot to CC: me, but if not, then can you please send this to the Debian upstream?
[07:48] <tkamppeter> pitti, I have sent it, at 3:54pm german time. You are CCed. Also Masayuki from Debian should have gotten it. Perhaps it was caught by your spam filter.
[07:54] <pitti> tkamppeter: will you also upload a fixed hpijs? (it has a versioned depends on the various gs-* variants)
[07:54] <pitti> tkamppeter: not that urgent, but would be nice to not instlal the transitional packages by default
[07:55] <tkamppeter> pitti, will correct this soon. I did not know that there were explicit dependencies on gs-*.
[07:56] <tkamppeter> pitt, but as ghostscripts has a "Provides: gs-*" the transitional packages do not need to stay installed.
[07:57] <pitti> tkamppeter: the problem is if a package like hpijs depends on 'gs-eps (>= 7)' (similar)
[07:57] <pitti> tkamppeter: since Provides: does not support versions
[07:58] <pitti> tkamppeter: i. e. a Provides: gs-eps will never fulfill a Depends: gs-eps (>= anything)
[08:02] <pitti> tkamppeter: uploaded and replied
[08:04] <tkamppeter> So for what is "Provides:" then good for?
[08:06] <tkamppeter> And also important to know, as "Provides:" in an RPM fulfills dependencies. So then I know not to use "Provides:" in distribution-independent RPMS for printer drivers, to avoid problems with thealien-generated Debian package.
[08:06] <pitti> tkamppeter: it works well for unversioned dependencies
[08:06] <tkamppeter> pitt, is this a bug or a feature?
[08:06] <pitti> tkamppeter: it's not a bug, it's just a missing feature
[08:08] <siretart> I've written down some lines about managing packages with version control systems like bzr: http://wiki.tauware.de/misc:vcs-packaging - please feel free to give me feedback about this
[08:09] <pitti> hi siretart
[08:09] <pitti> siretart: anything that could be put onto BzrMaintainerHowto?
[08:10] <siretart> pitti: I think we should focus on the mode 3 I'm proposing. However, I don't have the impression we have a consensus about that
[08:10] <siretart> pitti: if we can agree on a mode I propose, I indeed think we should add mode 3 to BzrMaintainerHowto
[08:10] <pitti> siretart: mode 3 == 'import upstream releases only'?
[08:10] <siretart> right
[08:11] <pitti> I agree, that makes most sense
[08:11] <siretart> I think I have an idea how to extend bzr-builddeb on how to implement the loom concept based on that mode. It however needs some more thought and a proof of concept implementation
[08:12] <seb128> pitti: that pages lacks a "why maintaining packages in bzr" ;)
[08:12] <bhale> seb128: ack
[08:45] <siretart> seb128: err, 'because it helps merging with debian and updating to new upstreams'?
[08:45] <siretart> perhaps I should work out that part
[08:48] <pitti> and because it makes collaboration of several maintainers much easier
[08:52] <bdmurray> Bug 27281 had a recent comment in it and it came to my attention.  However, I am not sure what package would bring up that message.  Does anybody have an idea?
[08:52] <ubotu> Launchpad bug 27281 in Ubuntu "incorrect/misleading error message says home folder should have 644 permissions instead of 755" [Medium,Confirmed]  https://launchpad.net/bugs/27281
[08:54] <mjg59> Keybuk: Is TB 20:00 UTC or BST?
[09:09] <siretart> mjg59: according to topic of #ubuntu-meeting, it is 2000 UTC
[09:17] <kylem> siretart, ping
[09:18] <seb128> pitti, siretart: it's not for me, and I don't think it makes merging, updating to new upstream and collaboration easier at the moment
[09:18] <siretart> kylem: pong
[09:18] <kylem> siretart, i've got the mailman pw for you, which email do you want it bounced to?
[09:19] <siretart> seb128: for packages using patch systems like dpatch, I agree. If used properly, I do think it can help a lot
[09:19] <siretart> kylem: the @debian.org please
[09:19] <kylem> oh, you finished NM? congrats!
[09:20] <siretart> yeah :)
[09:20] <seb128> siretart: I'm happy to be proved wrong but for me it's only extra work
[09:20] <seb128> siretart: makes sense for packages where you queue work before uploading
[09:20] <seb128> otherwise it's easier to do your change and upload
[09:21] <siretart> seb128: I see your point
[09:22] <seb128> when you want to modify a package using bzr you don't work on usually, you have to look for the bzr location first, checkout, modify, commit, figure how to build from bzr and then upload
[09:22] <seb128> when in the non bzr case you apt-get source, modify, upload
[09:24] <siretart> seb128: we discussed in Sevilla with mvo about extending apt to parse the XS-Bzr-Source field of packages to checkout that branch location. this addresses one part of your argument
[09:24] <mvo> seb128: IIRC pitti filed a bug about that already
[09:25] <mvo> ETOOMANYBUGS
[09:25] <mvo> #
[09:25] <mvo> #115959
[09:25] <seb128> good, a first step ;)
[09:25] <mvo> :)
[09:25] <seb128> you still need to have commit right, commit, figure how to build from bzr ;)
[09:26] <seb128> but that's getting better
[09:26] <mvo> we could add somem friendly message about bzr-buildpackage into the apt-get source thing
[09:26] <Keybuk> mjg59: UTC
[09:27] <seb128> I think it'll make sense the day we upload from bzr
[09:27] <mvo> seb128: more tomorrow, I need leave for the evening
[09:27] <seb128> if we still have to maintain a source package and keep it in sync with bzr it still doesn't make sense for lot of things
[09:27] <seb128> mvo: enjoy your evening, see you tomorrow
[09:48] <mjg59> Keybuk: Might be a minute or two late
[10:07] <ajmitch> morning
[10:09] <pitti> evening, ajmitch!
[10:33] <tkamppeter> pitti, I am currently re-uploading the Ghostscript packages to my site, when merging the Ubuntu/Debian packages I forgot a configure option which made the build on the Ubuntu cluster fail.
[10:33] <pitti> tkamppeter: NB that you need a new version number now
[10:33] <pitti> tkamppeter: since -0ubuntu1 is already in gutsy
[10:33] <tkamppeter> pitt, the corrected source packages are up now,
[10:35] <pitti> tkamppeter: weird though, it built fine for me locally, but failed on all buildds
[10:35] <pitti> tkamppeter: I don't see a -0ubuntu2, please upload it there with a debdiff against 0ubuntu1
[10:36] <pitti> tkamppeter: another question: why does ghostscript still need to handle alternatives? Can't this all go away, now that we have One True Ghostscript?
[10:37] <pitti> tkamppeter: ah, forgotten build-dependency on libgtk+2.0-dev?
[10:40] <tkamppeter> pitti, forgotten to overtake "--disable-gtk" from the gs-esp ./configure.
[10:40] <pitti> quite amazing that ghostscript now supports gtk
[10:40] <tkamppeter> I left the update-alternatives in for the case there would be a fork in the future.
[10:40] <pitti> tkamppeter: what would that give us? and how much would it cost us in terms of disk space?
[10:41] <pitti> tkamppeter: TBH I'd remove the alternatives stuff now and reintroduce it when necessary
[10:41] <tkamppeter> pitti, I can take out the update-alternatives.
[10:41] <pitti> that's not really urgent, though, the FTBFS is more important
[10:42] <pitti> tkamppeter: so it's 'add gtk build dep' vs. 'disable gtk'?
[10:42] <tkamppeter> pitti, The GTK support is as follows:
[10:43] <tkamppeter> There is libgs and there are two executables replacing the monolithic GS, two tini executables linking to libgs.
[10:43] <tkamppeter> One of them, gsc gives the Ghostscript we know from monolithic times.
[10:44] <tkamppeter> The other, gsx, has an additional output device named "display" which is the X device but with a GTK-based window.
[10:44] <pitti> ah, I see
[10:45] <pitti> tkamppeter: well, I doubt that it is much useful, since we already have good gs frontends for Gnome; so I agree to just disable it
[10:45] <tkamppeter> Ghostscript had this feature for longer, but neither in Debian nor in Ubuntu it was made use of it. gs-gpl was compiled monolithically all the time, and gs-esp was compiled with --disable-gtk, so only gsc got built. And this gsc was renamed into gs-esp and update-alternatived to gs.
[10:46] <tkamppeter> Yes, with evince the new GS works perfectly ...
[10:49] <pitti> tkamppeter: ok, thanks for the heads-up; I'll look at the new gs package tomorrow, if you do it tonight still
[10:49] <pitti> good night everyone


[14:02] <Baurin> hi
[14:49] <Dreaman> why source of the repos sey error
[14:49] <Dreaman> update but
[14:51] <Dreaman> http://prikachi.com/images.php?images/423/8933423z.png
[14:51] <Dreaman> in bulgaria say check the internet connection
[14:52] <Dreaman> not connect the repos
[14:53] <k1l_> Dreaman: what do you mean?
[14:54] <Dreaman> not update repos sey but after is update
[14:54] <Dreaman> why
[14:54] <k1l_> Dreaman: try with apt on cli. they provide better output
[14:55] <Dreaman> ok
[15:01] <Dreaman> k1l_  1 repo and del him
[15:01] <Dreaman> and work
[15:06] <Dreaman> https://paste.ubuntu.com/23318351/
[15:06] <Dreaman> :)
[15:24] <pandaadb> Hi - i have a Dell Precission with an Optimus card. This is listed as a known issue to be causing tearing when using the nvidia chip. I was wondering, does that count as "working" with ubuntu?
[15:24] <pandaadb> Because I am having a hard time with dell arguing that this does not work and i have to disable nvidia to make the laptop useable. They argue it's not their problem
[15:27] <nacc> pandaadb: you probably want #ubuntu
[15:28] <pandaadb> yep, i just realised that :) Thanks
[20:05] <quidnunc> Why does "do-release-upgrade -d" return "No new release found"
[20:05] <quidnunc> ?
[20:06] <nacc> quidnunc: mirrors may be updating?
[20:08] <dax> quidnunc: what release are you attempting to upgrade from?
[20:08] <quidnunc> nacc: 16.05
[20:08] <quidnunc> 05
[20:08] <quidnunc> 04
[20:08] <dax> !ltsupgrade
[20:08] <dax> erm, not that one
[20:08] <dax> !upgradelts
[20:08] <dax> !upgradeofflts
[20:09] <quidnunc> dax: Thanks. Is that new?
[20:09] <dax> ubottu: upgradelts is <alias> upgradeofflts
[20:09] <dax> quidnunc: no
[20:09] <quidnunc> dax: I never had to do that before
[20:10] <quidnunc> What was last lts? 14.04?
[20:10] <k1l_> dont use -d if you dont want to use development releases.
[20:11] <k1l_> on 16.04 the upgrade-path is set to LTS-only. iirc it was the same on 14.04 back then.
[20:12] <quidnunc> k1l_: Thanks
[20:12] <quidnunc> k1l_: Yakkety is a  development release as of today, correct?
[20:12] <k1l_> quidnunc: no
[20:13] <quidnunc> k1l_: okay, thanks
[20:13] <k1l_> yakkety is a final release as of today. so if you set your release-prompt to look for all relases, it will show you the available upgrade to 16.10
[20:13] <quidnunc> great, thanks
[21:01] <Baurin> bye


[13:39] <pavlushka> What happened actually? File descriptor 3 (pipe:[62849]) leaked on vgs invocation. Parent PID 7532: grub-install
[15:18] <tomreyn> pavlushka: that's a long standing minor / cosmetic issue according to ubuntu bug 1313784 and https://bugs.debian.org/466138
[15:19] <pavlushka> tomreyn: ty
[15:20] <tomreyn> yw
[16:51] <itsonlybinary> https://packages.ubuntu.com/cosmic/lxd  <-- does this mean in the next LTS that lxd will be in snap not apt?
[16:58] <nacc> itsonlybinary: stephane announced that last august
[16:58] <nacc> although what is in the next lts is a ways off still
[16:59] <itsonlybinary> dont really have a clue what snap is tbh, im just wanting to run a newer version of lxd on 18.04
[17:00] <teward> itsonlybinary: sudo snap install lxd
[17:00] <teward> but 18.04 questions're for #ubuntu ;)
[17:01] <itsonlybinary> yeh i get that, have also installed via snap but seems the snap stores all its configuration in different places than normal lxd package
[17:01] <itsonlybinary> so trying to understand how its going to be in the future so i dont break upgradability
[17:02] <nacc> itsonlybinary: the snap transitions the data
[17:02] <itsonlybinary> i guess thats in theory, because it didnt
[17:04] <nacc> itsonlybinary: you probably should be asking lxd specific questions in #lxcontainers
[17:05] <itsonlybinary> they where more snap/ubuntu future questions but ok
[17:30] <nacc> itsonlybinary: 'ubuntu future' isn't a support question (so this is the wrong channel for that) and snaps are supported in #snappy or the upstream that owns a particular snap
[17:34] <itsonlybinary> ive done with my questions, relax have a cookie or something
[18:07] <WoC> Any suggestion on how to get OpenCL (if possible) to with with a AMD GPU (APU) (A10-9620P) R5 class GPU ?
[18:07] <WoC> s/with with/work with/
[18:09] <WoC> nVidia gpu's are usually set up in 5 mins or less, amd... been working on it for about 2 weeks now
[18:09] <WoC> Recommendations/suggestions welcome
[18:12] <WoC> Also, any suggestions on how to prevent the screen to be rotated 90 degree counter clockwise every o often would be great ;P
[18:16] <lordcirth__> WoC, it rotates spontaneously?
[18:21] <WoC> yes
[18:21] <WoC> and only 90 degree ccw
[18:22] <WoC> have a background job; every 15 seconds it does xrandr --output eDP --rotate normal to minimize the neck pain... as work around
[18:23] <lordcirth__> LOL
[18:23] <lordcirth__> That's bizzare, I'm sorry I have no idea
[18:23] <WoC> also have in grub; GRUB_CMDLINE_LINUX_DEFAULT="quiet splash net.ifnames=0 biosdevnames=0 radeon.cik_support=0 radeon.si_support=0 amdgpu.dc=0 amdgpu.cik_support=1 amdgpu.si_support=1 amdgpu.dpm=0 "
[18:24] <WoC> Seems like there is a amdgpupro to replace amdgpu with, but i can't find that one, which may have working OpenCL
[18:25] <lordcirth__> That's a lot of tweaks
[18:25] <WoC> figured it was normal for amd
[18:25] <lordcirth__> Wouldn't know, I haven't had one since fglrx days
[18:26] <WoC> I can see why you wouldnt have a amd ;P
[18:26] <WoC> Maybe it just doesnt work in Linux
[18:28] <WoC> Which i find odd, since all the amd tools are for linux
[18:29] <WoC> Specs looks good though... (imho) https://www.notebookcheck.net/AMD-A10-9620P-SoC-Benchmarks-and-Specs.234384.0.html
[19:27] <tomreyn> WoC: have you tried a mainline kernel? or bionic or cosmic with the padoka ppa?
[19:34] <tomreyn> oh that's actually a 2016 one. ignore me.


[00:03] <balloons> veebers, uitk datepickers seem happy
[00:08] <veebers> balloons: interesting, I wonder why this test (which should be similar to what's happening in the uitk tests) is failing.
[00:08] <veebers> balloons: oh wait, I should run the tests here too to be certain :-)
[00:08] <veebers> balloons: are you running them on your desktop or phone?
[00:08] <balloons> veebers, I did both. But on the phone I removed the min and max in the qml inside test_date_picker.py
[00:09] <balloons> I can confirm it doesn't blow up even after removed, which was the original bug :-)
[00:10] <veebers> heh :-)
[00:11] <veebers> balloons: to make it easy for me (because I'm lazy) which branch are you testing, I'll test it here on my desktop
[00:12] <balloons> veebers, I pulled lp:ubuntuuitoolkit
[00:12] <balloons> there's a ton in there.
[00:12] <veebers> ah right
[00:13] <balloons> the calendar tests don't use the datepicker directly, but I suspect that's the other best thing to try
[00:13] <balloons> the uitk is fine, I wouldn't worry, since it was mostly about the datepicker being correct
[00:15] <balloons> calendar app is lp:ubuntu-calendar-app
[00:17] <balloons> I don't suspect we'll see any errors
[00:20] <balloons> ^^ I was wrong
[00:31] <balloons> veebers, so calendar fails and has some problems
[00:31] <balloons> I'm just running on the desktop and running the tests in trunk
[00:31] <balloons> reading the local datetime from the qml property doesn't mess with datetime.now anymore
[00:34] <veebers> balloons: :-\ I don't understand your last comment there, 'dpesn
[00:34] <veebers> d'oh "doesn't mess with datetime.now"?
[00:35] <balloons> yea.. just pointing out they fail. .. ohh the datetime from qml property doesn't mesh with datetime.now.. in other words, the date is wrong
[00:35] <balloons> *mess=mesh
[00:35] <balloons> hehe
[00:35] <balloons> for me; local 2014-09-07 23:00:00-04:00, today 2014-09-08 20:32:55.012863
[00:36] <balloons> you can see it's about 21 hours off
[00:37] <veebers> balloons: hmm, i'm not sure off the top of my head how to attack that sorry. I also need to pop out to run some errands.  If I swap to UTC, everyting passes under the new code and it mirrors the old
[02:06] <veebers> balloons: sorry errands took longer than expected. That's interesting, I would have to take a look at the code in libautopilot-qt to see what it's sending down the line re: dates
[02:07] <balloons> veebers, yea, you could compare before and after to see if it's the same.
[02:08] <veebers> balloons: I can't really do that right now though as I have a couple of other things to handle :-\
[02:08] <veebers> balloons: it must be getting late for you too, right?
[02:11] <balloons> veebers, I'll play with the prints another time.


[09:33] <zejzl> HENLO ALL
[09:33] <zejzl> CAN I HAS OP
[09:33] <zejzl> SRY MA CAPS LOCK IS STUCK KEY