[00:07] <kees> hm, should openldap2.3 be removed from the archive to avoid confusion?
[00:26] <ogra> alex-weej, so, here i am ... what do you want to discuss ?
[00:31] <ogra> (i think michael r. head explained the filtering very well already ... and youself pointed out the broken threading on the webpage ... so i dont actually see any point on going on to discuss it, but i'm available if you want to)
[04:12] <jdong> pitti: poor you with rm --one-file-system.... I had the same problem a few months ago zapping a temp home dir, not knowing ~/.gvfs mounted a samba share I viewed
[04:17] <LaserJock> jdong: yeah, I'm a bit leary of the .gvfs stuff
[04:21] <jdong> LaserJock: particularly since I was unaware of the .gvfs automounting behavior.... boy that should really get some release note red warnings!
[04:25] <LaserJock> jdong: yeah, I almost did some stupid stuff because of it
[06:41] <cjwatson> nxvl: dude. include a payload with your pings. :)
[06:44] <Chipzz> cjwatson: feeling better? :)
[06:45] <pitti> Good morning
[06:49] <StevenK> Morning pitti
[06:51] <nxvl> cjwatson: yes, sorry i just ping you and then realiza that you were sleep
[06:51] <nxvl> cjwatson: i didn't take the tz in account, so i just left there
[06:51] <nxvl> :D
[06:54] <cjwatson> Chipzz: not really
[06:54] <cjwatson> I wouldn't be up before 7 if I were feeling well
[07:53] <NCommander> I'm stumped
[08:08] <pitti> tkamppeter_: ping
[08:08]  * thorwil waves to sabdfl 
[08:09] <sabdfl> hey thorwil
[08:10] <thorwil> sabdfl, i'm wondering whether you got my mails?
[08:39] <stgraber> moin
[08:42] <AlexCONRAD> hi, I installed the glfrx-control to tweak my ATI card via the control panel. But settings I set in here, where are they stored ?
[08:57] <stgraber> cjwatson: did you file a bug on LP about that bug when doing a manual install with encrypted LVM ?
[08:58] <stgraber> cjwatson: It complains of unsafe swap space :( (it's in the encrypted LVM so shouldn't)
[09:23] <slangasek> bryce: could you have a look at bug #251059 when you're up?
[09:40] <AlexCONRAD> ah, a new ATI driver came out
[09:41] <AlexCONRAD> it says it introduces product support for Ubuntu 8.04 production support...
[09:41] <AlexCONRAD> im not sure what that means
[09:41] <AlexCONRAD> and it supports new cards
[10:08] <Keybuk> cjwatson: so, I've had some time to look at your auto tools problem
[10:10] <seb128> hey Keybuk!
[10:11] <seb128> Keybuk: I've some libtool2 issues
[10:11] <pitti> good morning Keybuk
[10:12] <Keybuk> seb128: what are your issues?
[10:13] <seb128> Keybuk: sec, getting the details again, I fought with that yesterday
[10:17] <pitti> asac: ah, sorry, my fault; I didn't copy epy to -updates yet
[10:20] <seb128> Keybuk: in fact that's gtk which seems to do something stupid, I'm wondering why that works when using libtool1.5, http://people.ubuntu.com/~seb128/configure.in has "deplibs_check_method=`(./libtool --config; echo 'eval echo $deplibs_check_method')" or there is no "libtool" in the gtk source so the ./libtool call fails
[10:20] <Keybuk> yeah, that won't work until after libtool has run ?
[10:21] <Keybuk> it may be that the different versions generate the script at different times, of course
[10:21] <seb128> well, that doesn't work when relibtoolizing using libtool2
[10:21] <seb128> but that works when using libtool1.5
[10:21] <seb128> I'm trying to figure why now
[10:21] <tseliot> ﻿AlexCONRAD: I'll add that driver ASAP
[10:22] <AlexCONRAD> tseliot: FYI, when I install the restricted drivers, I don't have antialiasing in flash. But when I install the ATI drivers (from their web site), I do have antialiasing enabled, after a reboot, I have nothing to do.
[10:23] <AlexCONRAD> enabled in *flash*
[10:23] <AlexCONRAD> I'm still trying to figure out what's the difference bewteen the settings you set in "amdcccle" and the onces you set using aticonfig
[10:24] <AlexCONRAD> and the ones*
[10:24] <asac> pitti: all fine then - nothing to be sorry ;) (especially now that it turned out to be a none issue)
[10:25] <pitti> asac: btw, what about nspr and nss? AFAIR there was something still not 100% clear?
[10:26] <asac> pitti: sorry, have to run to doctor ... will be back in 30 minutes or so.
[10:26] <AlexCONRAD> tseliot: nevertheless, I still have "SGI" set as the "client glx vendor string" via glxinfo
[10:26] <Keybuk> seb128: this exact case is covered in the libtool doc
[10:26] <pitti> asac: no problem; good luck!
[10:27] <Keybuk> seb128: if you simply delete that line, everything works
[10:27] <Keybuk> $deplibs_check_method is available to any configure code after LT_INIT / AC_PROG_LIBTOOL
[10:27] <seb128> Keybuk: ok, thanks
[10:28] <seb128> that was working when using libtool 1.5 because something copied "libtool" in the build directory apparently
[10:28] <Keybuk> yes
[10:28] <seb128> which is not the case in the current version and expose the bug
[10:29] <Keybuk> libtool was generated at the point inside configure where AC_PROG_LIBTOOL happened
[10:29] <Keybuk> and all the variables were lost to configure
[10:29] <Keybuk> it's now generated by config.status
[10:29] <NCommander> hey seb128!
[10:29] <Keybuk> which means the variables are all available, and can even be changed by other configure bits
[10:29] <seb128> hello NCommander, sorry I've been busy working on the new GNOME updates and didn't reply to your mail yet
[10:30] <NCommander> seb128, it's fine. Anything I can do to help with those updates?
[10:30] <seb128> Keybuk: ok
[10:30] <seb128> NCommander: help is always welcome ;-) But the remaining updates are mostly non trivial ones
[10:30] <NCommander> THat's fine
[10:31] <NCommander> I've packaged a few non-trival apps before
[10:31] <NCommander> About the only thing I haven't done in that respect is a kernel module
[10:31] <pitti> gcalctool should be trivial, and is needing an update to meet the SRU policy :)
[10:31] <seb128> NCommander: want to have a look at updating evince to 2.23? it'll require a main inclusion report for libspectre which is used now to display .ps in the new version
[10:31] <pitti> that might be a good target
[10:31] <seb128> pitti: huats did both stable and unstable one yesterday
[10:31] <pitti> ah
[10:32] <pitti> not yet uploaded then, it seems
[10:32] <seb128> pitti: bug #250766
[10:32] <pitti> cool
[10:32] <seb128> pitti: no, I've been too busy to do sponsoring yesterday, thanks for sponsoring the hardy update btw ;-)
[10:32] <pitti> de rien
[10:33] <seb128> new GNOME is quite a challenge this week
[10:33] <seb128> gnome-keyring has a new lib, seahorse has been splitted and the tarball drop all the addons for gedit, epiphany-browser etc which are in a new source
[10:33] <NCommander> seb128, SUre, no problem
[10:33] <seb128> gnome-desktop changed soname (not updated yet due to CD build)
[10:34] <seb128> evolution-data-server has sonames changes too and they switch to on disk sqlite storage for mail indexes
[10:34] <seb128> the new gnome-session dbus code should land soon
[10:34] <seb128> epiphany-browser has a webkit backend only now
[10:34] <seb128> etc etc ;-)
[10:35] <seb128> NCommander: cool, let me know if you have any question on the update, or feel free to ask here or on the #ubuntu-desktop channel
[10:37] <seb128> pitti: where is the MIR guide again? There is a zillion MainInclusionReport* pages in the wiki and I never remember how to find the guide one in the list
[10:37] <pitti> seb128: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[10:38] <seb128> thanks
[10:38] <pitti> seb128: https://wiki.ubuntu.com/MainInclusionProcess is the policy
[10:38] <seb128> NCommander: ^ to read if you didn't yet
[10:38] <pitti> since it links to both the Requirements and the template, it's a better page to bookmark, I think
[10:38] <seb128> right
[10:39] <NCommander> seb128, yup, I saw that
[10:39] <Keybuk> pitti: on --one-file-system
[10:39] <Keybuk> you know that if you bind-mount from the same filesystem, that doesn't work, right? :)
[10:40] <pitti> Keybuk: I know, yes
[10:40]  * NCommander doesn't get the autoreconf patch ...
[10:40] <pitti> it's not perfect, but helps a lot already
[10:41] <Keybuk> NCommander: ?
[10:41] <NCommander> In evience, the old version has an autoreconf patch, but it doesn't appear to be necessary
[10:41]  * liw wants "rm --keep-the-important-stuff", but settles for kvm running a bunch of virtual machines for experimentation
[10:41] <seb128> NCommander: oh, if you have interest in C++ the g*mm bindings also need to be updated and maybe somebody looking after the bugs
[10:41] <NCommander> (evience is still building though the new version, so it may not have exploded (yet))
[10:42] <seb128> NCommander: autoconf update is required due to the lpi changes, they add launchpad-integration to the configure.in
[10:42] <NCommander> Oh
[10:42] <NCommander> Thanks, I didn't catch a new file was added
[10:42] <seb128> NCommander: and the other autotools are required because the hildon patch change the Makefile.am
[10:43] <NCommander> Why not just add it properly it, and then call the autotools scripts to rebuild on the fly?
[10:43] <NCommander> I always found patching configure directly will make updates harder
[10:43] <seb128> NCommander: "add it properly"? that's what 01_launchpad.patch does
[10:43] <seb128> NCommander: we just run autoreconf in a patch rather than a build time
[10:43] <NCommander> Ok, I can understand that
[10:44] <seb128> that's something which might be discussed and different people have different opinion
[10:44] <seb128> there is pro and con for both way
[10:44] <NCommander> I perfer calling autoreconf to do it, but if you perfer I do it as a patch
[10:44] <NCommander> you are my mentor thus I shall follow your lead :-)
[10:44] <seb128> well that's what we do for desktop packages
[10:45] <seb128> and at least the result is constant
[10:45] <seb128> which is not the case when you call whatever automake version is installed at build time
[10:45] <NCommander> Makes sense
[10:45] <NCommander> I'm running cdbs-edit-patch now
[10:46] <seb128> to update the patch just remove the previous version, it'll not apply cleanly anyway
[10:47] <seb128> cdbs-edit-patch 99_autoreconf
[10:47] <NCommander> Yeah, I know
[10:47] <NCommander> ;-)
[10:47]  * NCommander has working with autohell before
[10:47] <seb128> autoreconf -v -f && rm -rf autom4te.cache
[10:47] <seb128> ok, good
[10:47] <Keybuk> seb128:  + -i
[10:48] <seb128> Keybuk: usually -f works for me but right
[10:48] <NCommander> at least autoreconf works
[10:49] <NCommander> It always ticks me off on packages which it breaks miserably on because of missing aclocal macros
[10:49] <Keybuk> seb128: without -i, it'll fail to update one half of libtool if ltmain.sh already exists in that directory
[10:49] <Keybuk> it's a bug imo, colin found it yesterday
[10:50]  * NCommander rm's the patch and redoes it with +i
[10:50] <tseliot> ﻿AlexCONRAD: antialiasing can be set through amdcccle and - if I'm not wrong - is not stored in the xorg.conf (AMD uses its own configuration file). When you install the driver from either EnvyNG or Jockey amdcccle is not used. I don't know what happens when you use aticonfig.
[10:50] <seb128> Keybuk: ok
[10:50] <AlexCONRAD> tseliot: I'm doing some tests right now...
[10:51] <NCommander> ok, now its building
[10:51] <AlexCONRAD> tseliot: OpenGL screensavers seem to be affected by the amdcccle (from the ati drivers)
[10:52] <seb128> Keybuk: btw if a program has C and C++ sources, should AC_PROG_CC and AC_PROG_CXX be used or is CXX enough?
[10:52] <seb128> Keybuk: that's for gnome-system-monitor
[10:52] <NCommander> seb128, I've used both, but you could probably get away with AC_PROG_CXX
[10:52] <Keybuk> seb128: both
[10:52] <Keybuk> you need CC for the C sources, CXX for the C++ sources
[10:52] <seb128> ok, that's what I did yesterday but I was not sure, building using CXX only seems to be working too
[10:53] <Keybuk> you'd even need to use CC if g++ could compile C code, since it needs to be set in CC
[10:53] <Keybuk> oh, it might *work*
[10:53] <Keybuk> the check for a C compiler is pretty much required by everything
[10:53] <Keybuk> but it might stop working one day ;)
[10:53] <tseliot> AlexCONRAD: just FYI AMD's configuration file is ﻿/etc/ati/amdpcsb
[10:53] <AlexCONRAD> tseliot: I see that things are stored in /etc/ati/amdpcsb
[10:53] <AlexCONRAD> tseliot: :)
[10:54] <seb128> Keybuk: alright, thanks ;-)
[10:54] <NCommander> seb128, ok, its building now
[10:54] <NCommander> seb128, (this machine for some reason takes forever to run autotools, but builds very quickly)
[10:54] <AlexCONRAD> tseliot: Im having a hardtime to figure out which or amdcccle or aticonfig (xorg.conf) takes over
[10:55] <seb128> NCommander: ok
[10:55] <zyga> mvo: hello :-)
[10:56] <AlexCONRAD> tseliot: also, what does "sudo dpkg-reconfigure -phigh xserver-xorg" does really ?
[10:56] <zyga> mvo: I'd likte to patch a command-not-found bug, could you tell me where are the current ubuntu sources for that package? (as in bzr tree, not apt-source sources)
[10:57] <zyga> mvo: I think I finally understand the cause of all the locale issues that pop up since c-n-f was introduced and I know how to fix that
[10:57] <tseliot> ﻿AlexCONRAD: don't do it unless you really need it. It reconfigure your xorg.conf without asking questions.
[10:59] <seb128> NCommander: some other desktop updates if you are looking for other things to do after this one: gucharmap (the new version adds python binding and might have changed the soname), glibmm and gtkmm if you have interest in C++ bindings
[10:59] <NCommander> seb128, I assume you want me to add the libspectre support to this package instead of just having it use the existing gs code
[10:59] <seb128> NCommander: what tarball did you get?
[10:59] <NCommander> 2.23.5
[10:59] <NCommander> WHich was the latest on the ftp.gnome.org site
[10:59] <seb128> NCommander: the upstream NEWS mentionned that they dropped the gs support
[10:59] <seb128> but yes, we want to use libspectre now
[10:59] <NCommander> The README says optional
[11:00] <AlexCONRAD> tseliot: well, things are pretty clear now: aticonfig --fsaa=on/off and all antialiasing options are no longer available in the latest ATI drivers
[11:00] <NCommander> ATM, its FTBFS because it can't find the launchpad support library
[11:00] <NCommander> undefined reference to `launchpad_integration_add_ui'
[11:00] <AlexCONRAD> tseliot: sounds like you can only do it through amdcccle
[11:00] <seb128> NCommander: did you apply 01_launchpad before doing the autoreconf?
[11:00] <NCommander> I thought I did
[11:01] <seb128> NCommander: 01_launchpad should add launchpad-integration to the configure.in and the autoreconf should apply that to the configure
[11:01] <seb128> NCommander: maybe look if the configure lists it correctly?
[11:01] <mvo> zyga: hello! nice to see you :) the current bzr tree is at http://bazaar.launchpad.net/~ubuntu-core-dev/command-not-found/ubuntu
[11:01] <NCommander> I don't see it in configure ...
[11:01] <NCommander> Argh, if I had to bet, cdbs-edit-patch unapplied it when I ran edit-patch
[11:02] <seb128> it should apply in order
[11:02] <seb128> ie, cdbs-edit-patch 99_autoreconf apply 01_launchpad normally
[11:02] <NCommander> I'm checking now to see what went wrong
[11:02] <NCommander> No, it did end up in the right place
[11:03] <zyga> mvo: thanks, I'll work on a fix and give you a branch back when I'm finished!
[11:05] <seb128> NCommander: maybe they restructured the code and the launchpad-integration pkg-config check should be moved somewhere else in the configure.in
[11:05] <NCommander> I'm checking now
[11:05] <NCommander> This is personally why I don't like autoreconf in patches
[11:05] <NCommander> I find its easier just to patch configure.ac, and then let autoreconf run at build time
[11:06] <seb128> well, autoreconf at build time would not have produced a better result
[11:06] <seb128> but right, you wouldn't have to update the patch again and again ;-)
[11:06] <seb128> well, you just have to run autoconf in this case
[11:06] <NCommander> yeah
[11:06] <seb128> which is quick enough usually
[11:07] <NCommander> Neat, libtool is now tossing a nice warning about AC_CONFIG_MARCO_DIR which it didn't before
[11:07] <mvo> zyga: excellent, thanks a lot
[11:08] <seb128> NCommander: right, I noticed that too, not sure if really makes a difference to use that though
[11:08] <NCommander> seb128, I usually ignore autotool warnings cause then tend to be a tad paranoid
[11:08] <seb128> I was pondering sending upstream patches for that on the packages I updated yesterday
[11:08] <NCommander> Most upstreams don't touch the configure script once its done
[11:09] <NCommander> We still have quite a few packages that build with 1.4 version of said tools
[11:10]  * NCommander also works now on clearing the lintian warnings
[11:11] <NCommander> seb128, since your an archive admin, can you help me resolve an issue with my package which got rejected?
[11:14] <seb128_> re
[11:14] <seb128_> hum, got disconnected
[11:14] <seb128_> yeah, most upstream tend to copy configure from an another project, do some changes to get it working and don't touch it when that's not really required
[11:15] <NCommander> seb128_, yeah, well as an added bonus, this doesn't properly list a build-dep on ghostscript, it just FTBFS looking for -lgs ...
[11:15] <NCommander> I'm suprised it built on the buildds
[11:17] <seb128_> well, gs is optional no? it probably built not using this option
[11:18] <NCommander> /usr/bin/ld: cannot find -lgs
[11:18] <NCommander> It seems it isn't
[11:20] <NCommander> It needs ghostscript if you want postscript viewing enabled
[11:22] <NCommander> seb128,_ anyway, I was hoping you could resolve a license ambiginity with regards to the copyright file, which lead to codeblocks being rejected
[11:22] <seb128_> NCommander: there is no lgs mention in the evince source and the 2.22 configure is using the gs command to check if gs is available
[11:23] <NCommander> I have the command available, but I didn't have the development library headers installed
[11:23] <seb128_> ok
[11:23] <NCommander> I just added the dependency on libgs-dev; its already a core package
[11:23] <seb128_> NCommander: I've read the codeblocks rejection
[11:24] <seb128_> ok, cool
[11:24] <NCommander> I also think having postscript rendering isa  good thing
[11:24] <NCommander> THe archive admin says the package is LGPL
[11:24] <NCommander> But that's only true for the SDK
[11:24] <seb128_> Riddell: ^
[11:24] <seb128_> NCommander: Riddell is the archive admin who rejected the upload
[11:24] <NCommander> YEah
[11:25] <NCommander> I emailed him asking how I should clarify copyright
[11:25] <NCommander> I assume I need to add LGPL for the files under that specifically
[11:25] <NCommander> (in the copyright)
[11:25] <seb128_> right, if you have sources under the LGPL the LGPL licence text should be distributed in the tarball and the debian/copyright should list those
[11:26] <NCommander> the COPYING file only has the GPL3
[11:26] <seb128_> right, you need to add A COPYING.LGPL for example then
[11:26] <seb128_> or COPYING.LIB
[11:26] <seb128_> which has the LGPL text
[11:26] <NCommander> Can I simply add it as a patch, or do I actually need to repack the upstream?
[11:26] <seb128_> I know some archive admin want it in the upstream tarball
[11:27] <seb128_> otherwise the tarball is not re-distribuable
[11:27] <NCommander> I was under the impression if something was shipping as GPL3, the collective work was GPL3, expect for the files that are LGPL, which can be used under the LGPL by themselves if they are removed from the package
[11:27]  * NCommander recalls his time as a FSF Savannah admin
[11:28] <seb128> not sure about that
[11:28] <seb128> cjwatson or pitti might know better
[11:28] <NCommander> Yeah
[11:28] <seb128> but if you have LGPL sources you should have the LGPL text in the tarball
[11:28] <NCommander> The LGPL says that it can be replaced with the GPL
[11:28] <NCommander> So by having the later, you can meet the requires of the former
[11:28] <Riddell> it is, but it's a separate issue.  if the code is under a licence, the licence text should be included so we know the full terms of the licence
[11:29] <NCommander> Does that alone warrent repacking the source to add a COPYING.LGPL file, or should it simply be added via a patch (and in the copyright file of course)
[11:30] <pitti> NCommander: addding license documents via a patch is always wrong IMHO
[11:30] <Riddell> it's upstream who would need to add the file since they're the ones licencing it
[11:30] <pitti> either you don't need it at all(because of some GPL implies LGPL situation), or it needs to be in the orig.tar.gz
[11:30] <NCommander> I'll ask upstream to add the file (I already had to file a bug with them over a rendering bug in wxWidgets)
[11:31] <NCommander> I assume if I want it to go them, I need to repack the source, right?
[11:33] <seb128> NCommander: yes
[11:33] <NCommander> ok
[11:33] <NCommander> That makes sense
[11:33] <seb128> NCommander: or get upstream to fix the issue and roll a new version ;-)
[11:34] <Riddell> NCommander: I expect my e-mails to you are in your spam box, gmail doesn't like my server sometimes
[11:34] <NCommander> code::blocks already stinks when it comes stable releases
[11:34] <NCommander> seb128, http://paste.ubuntu.com/29569/ - evidence seems to hate me :-P
[11:34]  * NCommander looks up the extension he needs to add to the mime file
[11:35] <seb128> I'm not convinced that's authorized
[11:35] <tyfon> hmm if i make a new package with some changes (libqt4-sql-psql) since the default one does not support postgres 8.3 that ships with ubuntu, how can i make it not want to download a "updated" package from the standard repo?
[11:35] <NCommander> I found the fix on their bugzilla
[11:35]  * NCommander adds the patch
[11:36] <tyfon> do i need to bump the version somehow?
[11:36] <seb128> NCommander: good, don't forget to add those to debian/evince.mime too
[11:37] <NCommander> no, its a typo in the desktop file thats causing that
[11:38] <seb128> NCommander: application/x-cb7 seems to be new and should be added to debian/evince.mime no?
[11:38] <NCommander> I'm checking
[11:38] <NCommander> yeah
[11:38] <NCommander> Its new
[11:38] <NCommander> But I can't figure out what extension is x-cb-7
[11:39] <NCommander> According to the source, its some sorta comic book format
[11:40] <seb128> NCommander: http://bugzilla.gnome.org/show_bug.cgi?id=532312 indicates cb7
[11:40] <NCommander> thanks :-)
[11:42] <NCommander> ok, new mime type in place, autoreconf patch updated again, now to see if it will build
[11:48] <NCommander> seb128,  internet trouble?
[11:48] <seb128> NCommander: no, restarting session to try updates sometimes
[11:49] <seb128> I should configure an IRC proxy or something
[11:53]  * NCommander edits the changelog
[11:56] <seb128> ok, it's lunch time, see you in a bit
[11:56] <NCommander> I should be more or less done by then seb128 ;-)
[11:56] <seb128> NCommander: I'm away for lunch, I'll read the backlog when I'm back
[11:56] <seb128> ok, cool
[11:56] <seb128> it must be late for you, there is no hurry for the update, feel free to continue tomorrow
[12:00] <seb128> late or early
[12:00] <seb128> anyway lunch time, bbl
[12:14] <NCommander> seb128, its all built, but it has a bunch of lintian warnings like debian-copyright-line-too-long, but no errors
[12:26] <NCommander> seb128, uploaded to PPA sonicmctails on LP
[12:30] <zyga> mvo: is there any sane way to make bug repots from python that will identify ubuntu version?
[12:31] <zyga> mvo: (so that the "report this bug" URL will point to correct ubuntu release, not the generic package
[12:31] <zyga> mvo: I was thinking about optionally reading /etc/issue
[12:31] <broonie> zyga: lsb_release?
[12:31] <zyga> or using lsb
[12:31] <zyga> right
[12:32] <broonie> /etc/issue is commonly customised by users so you can't rely on it.
[12:32] <zyga> lsb_release looks as a sane way to do that
[12:32] <zyga> now just for a simple way to tie that to launchpad
[12:33] <zyga> thanks I think calling subprocess.call("lsb-release", "-a") is enough for bug maintainer to re-assign the bug as needed
[12:36] <Pici> I was under the impression (and correct me if I'm wrong) that the current Ubuntu bug workflow was to assign bugs to the 'generic' package and not to the release specific version.  Unless of course you're talking about reworking that workflow.
[12:36] <zyga> I wasn't aware of that
[12:36] <zyga> I was just looking for a way to get default bug reports more meaningful than before
[12:36] <Pici> see https://bugs.edge.launchpad.net/ubuntu/+source/pidgin vs https://bugs.edge.launchpad.net/ubuntu/hardy/+source/pidgin
[12:53] <mdz> that was exciting...I just installed the latest intrepid daily desktop
[12:54] <pitti> mdz: and it actually worked?
[12:54] <mdz> pitti: almost
[12:55] <mdz> lots of problems
[13:03] <sistpoty|work> mdz: out of interest: did you get read errors from the cd? (I got that with testing the last two daily images from faumachine... just curious if that's a faumachine bug or a bug in the live cd)
[13:05] <mdz> sistpoty|work: no
[13:05] <sistpoty|work> ok, thanks
[13:28] <zyga> mvo should I add something to debian/control when I want to use lsb_release?
[13:28] <zyga> (like lsb-release package)
[13:29] <mvo> zyga: yes, a depends on the lsb-release package
[13:29] <zyga> ok, done
[13:32] <DktrKranz> lamont: do you have any clue about this FTBFS on hppa? http://launchpadlibrarian.net/16253078/buildlog_ubuntu-intrepid-hppa.gnustep-base_1.16.1-2ubuntu1_FAILEDTOBUILD.txt.gz
[13:33] <lamont> "iz feature" :-<
[13:33] <DktrKranz> gah!
[13:34] <lamont> I wouldn't worry too much about it
[13:34] <lamont> once hppa catches back up (is it??) I expect that infinity will throw everything that failed back against the wall to see what sticks
[13:35] <lamont> that looks like one of the standard "that threads bug" (it isn't actually, but it is...) failure modes
[13:35] <zyga> mvo: http://suxx.pl/~zyga/command-not-found--locale-issues-fix/
[13:35] <DktrKranz> ok, I'll leave it alone for now, thanks
[13:36] <zyga> mvo: I didn't test it with python 2.4 though
[13:36] <mvo> zyga: thanks, I will merge and review now
[13:36] <zyga> mvo: I did one more change that is not in the changelog
[13:37] <zyga> I replaced /usr/bin/env python with /usr/bin/python -S
[13:37] <zyga> -S omits import site that often got to crash reports
[13:37] <zyga> hmm, doesn't work with 2.4
[13:38] <zyga> if that's a problem I can work around it but I think it needed 2.5 before (try/except/finally)
[13:38] <seb128> NCommander: ok cool, I'll have a look in a bit and comment here or by mail
[13:38] <NCommander> seb128, cool
[14:26] <ogra> geez, intrepid daily doesnt even survive unpacking the kernel in my vbox
[14:27] <ion_> ogra: Is it perhaps running compcache?
[14:27] <ogra> ion_, nah, just the alternate CD, no fancy stuff
[14:28] <ogra> th eodd part is that the oops scrolls indeed out of sight
[14:28] <ogra> we should really do something that it doesnt get bigger thn a standard terminal at some point ... or put the intresting stuff at the bottom
[14:28] <ogra> BenC, ^^^
[14:29] <superm1> ogra, perhaps can you set up a "serial" console easily on a VM, and then capture using minicom or similar?
[14:30] <ogra> hmm, thats way more work than i planned to get an intrepid VM quickly :)
[14:31] <sistpoty|work> ogra: what are you using? kvm? or s.th. else?
[14:32] <ogra> virtualbox on hardy
[14:32] <ogra> and the current daily alternate
[14:32]  * sistpoty|work tries hardy kvm atm with the current daily desktop *g*
[14:32] <ogra> uuuh, desktop is like gambling i bet :)
[14:32] <tkamppeter_> pitti, hi
[14:33] <ogra> i just need a working env. for ltsp stuff (going to the ltsp hackfest today)
[14:33] <pitti> tkamppeter: could you please update system-config-printer to a recent snapshot? I need it for the jockey printer bits
[14:33] <tkamppeter> pitti, OK
[14:33] <superm1> sistpoty|work, i had just read some bugmail that indicated the current daily desktop has a few bugs in ubiquity
[14:33] <pitti> it seems you need to run some autoconf stuff in order to produce an orig.tar.gz from git?
[14:33] <pitti> tkamppeter: ^
[14:33] <pitti> tkamppeter: ok, thank you!
[14:33] <tkamppeter> (The Intrepid version is hopelessly outdated ...)
[14:34] <superm1> but if you make it to the desktop, you are in better shape than virtualbox right now
[14:34] <superm1> sistpoty|work, as in bugs preventing install due to errors
[14:34] <ogra> but it would be really helpful (not right now but in general) to have oppses printed out in reverse order ... usually only the first lines re the intresting ones and they always scroll off the visible area
[14:34] <sistpoty|work> superm1: I kind of made it to the desktop :)
[14:35] <tkamppeter> pitti, yes. You must do (in the main directory):
[14:35] <tkamppeter> ./bootstrap
[14:35] <tkamppeter> rm -rf autom4te.cache
[14:36] <tkamppeter> Then you must create a tarball with --exclude=.git
[14:36] <ogra> hmm, not even the CD selftest will run ...
[14:36] <ogra> must be a serious kernel issue (or isolinux)
[14:36] <superm1> ogra, well i dont know that i entirely agree.  perhaps having a kernel parameter to "allow" then to be printed in reverse order would be better
[14:37] <superm1> especially in the case of entirely reproducible oopsses
[14:37] <ogra> superm1, that would be fine too, but its a thing that bothered me often already
[14:38] <ogra> if your keyboard doesnt work after the crash there is simply no easy way to reach the wanted info
[14:39] <ogra> and things like vprintk or show_fault_oops dont really tell me something ...
[14:40] <ogra> geez ... dropping quiet from teh bootopts gets me funny colored squares on the screen
[14:43] <BenC> ogra: there's ways to scroll back to the oops
[14:44] <ogra> not in my vm it seems
[14:44] <ogra> what was the command to disable tickless ? noticks=on ?
[14:45] <ogra> i saw somethng about ticks in the last round
[14:45] <BenC> dynticks=off
[14:45] <ogra> thanks
[14:45] <BenC> oops
[14:45] <BenC> ogra: no, it's nohz or nohz=1
[14:45] <ogra> heh, ok
[14:45] <seb128> NCommander: ok, I'm looking at your evince update, first note: you did use the upstream tarball and a diff.gz, that's wrong ;-) you need to rename the tarball evince_2.23.5.orig.tar.gz so it's used and the debian changes are stored in a diff.gz
[14:46] <seb128> NCommander: the ppa upload didn't build on lpia, seems that the hildon patch needs some changes
[14:46] <NCommander> argh
[14:46] <NCommander> The former was just stupid error
[14:46] <NCommander> (I went away after uploading to my ppa, I didn't even check to see if I made a native version of not)
[14:46] <NCommander> As for the second, look closer at the lpia log
[14:46] <ogra> but dynticks=off seems to change something as well ... now it hangs without any oops
[14:46] <NCommander> Its one of the dependencies failing to configure
[14:47] <seb128> NCommander: looking
[14:47] <NCommander> seb128, it fails before it even tried to build
[14:48] <seb128> NCommander: otherwise you added .debhelper.log files in the debian directory, those should probably not be in the source
[14:48] <seb128> NCommander: hum, no
[14:48] <ogra> ah, nohz gets me the same result ... hangs at ACPI: XSDT ....
[14:49] <NCommander> er, your right
[14:49] <seb128> NCommander: the log I'm reading has lot of undefined reference to gtk function which indicates a -lgtk-x11-2.0 is missing somewhere
[14:49] <NCommander> WTF was I on ...
[14:49] <NCommander> Yeah
[14:49] <NCommander> I see that
[14:49] <NCommander> I've got an lpia chroot
[14:49] <NCommander> I'll see if I can run that down
[14:50] <seb128> you should be able to use --enable-hildon on i386 too
[14:50] <NCommander> I did have an orig tarball, I just had an - instead of a _
[14:50]  * ogra grins ... nohz=1 and acpi=off gets me "BUG: Unable to handle kernel <1>"
[14:50] <seb128> just change the rules
[14:50] <ogra> about 100 times repeated and then it stops
[14:51] <seb128> NCommander: the build-depends on list in the changelog I not there, I suspect you changed the control rather than the control.in
[14:51] <seb128> ups, can't write
[14:51] <NCommander> Yeah, I did
[14:51] <seb128> NCommander: the build-depends you listed in the changelog are not there, I suspect you changed the control rather than the control.in
[14:51] <persia> Best to change both, generally
[14:51] <NCommander> d'oh * 2
[14:52]  * NCommander has not encountered a control.in file before
[14:52] <seb128> persia: why bothering? just run the clean target
[14:52] <NCommander> I'm not off to a very good start as showing you my mentee skills
[14:52] <seb128> faster than typing everything twice
[14:52] <ogra> but less educating :)
[14:52] <persia> seb128: Some packages don't do control.in -> control in clean.  I just tend to be careful to avoid confusion.
[14:52] <seb128> NCommander: don't worry, you clearly know what you are doing, those are just small mistakes due to different workflows
[14:53] <NCommander> I must worry, I once managed to tick off the Debian archive admin ...
[14:53] <NCommander> YOu can guess how that played out
[14:53] <NCommander> Ok, I changed the control.in file
[14:54] <NCommander> ok, I modified the control.in file
[14:54] <NCommander> Er
[14:54] <NCommander> wow
[14:54] <NCommander> I'm duplicating myself
[14:54]  * NCommander drinks coffee
[14:54] <seb128> how did you manager to get those .debhelper.log in the source? I'm just curious ;-)
[14:54] <NCommander> I dunno, it tends to happen to me when I build CDBS packages ...
[14:55] <NCommander> No clean rule is usually why
[14:55] <NCommander> I explicately add rm debian/*.log to my clean rules
[14:55] <seb128> what is creating those log?
[14:55] <seb128> that's the first time I see some of those
[14:55] <NCommander> seb128, I see them all the time ...
[14:55] <persia> NCommander: You might want to check your build environment: it oughtn't do that.
[14:55] <NCommander> Both on sid and intrepid
[14:55] <seb128> something in your config I would say
[14:55] <NCommander> Maybe its time to rm -r the chroot and do it again
[14:55] <NCommander> Probably
[14:56] <NCommander> I use dpkg-buildpackage over debuild
[14:56] <NCommander> Maybe that's what's doing it
[14:56] <seb128> I do use debuild too
[14:56] <NCommander> er, I don't use debuild
[14:56] <tkamppeter> Riddell, have you already seen bug 251111?
[14:56]  * NCommander should probably alias debuild to dpkg-buildpackage
[14:57]  * ogra uses dpkg-buildpackage but doesnt see any logs 
[14:57] <NCommander> seb128, how was my changelog? I didn't list the upstream changes yet, but I did list what I did to the package
[14:58] <seb128> NCommander: the changelog is correct, we usually list NEWS item for desktop packages but that's not required, I just know some users like to read those on the change lists
[14:58] <NCommander> sweet
[14:59] <NCommander> THere are some lintian warnings
[14:59] <NCommander> I'm not sure if you want me to clear them though (all of them but one involve the copyright file)
[14:59] <seb128> they were already there before
[14:59] <persia> Fixing copyright is usually a good thing though.
[14:59] <seb128> well, we try to no divert from debian when not required
[14:59] <seb128> but if you do clean and send the patch to the bts that's good ;-)
[14:59] <NCommander> Yeah
[15:00] <NCommander> Ok, everything is resolved expect the lpia issue
[15:00] <seb128> dh_clean is supposed to remove those debhelper.log, weird that it doesn't for you
[15:01] <seb128> and that's "dh" which seems to create those
[15:01] <seb128> but we don't use "dh" yet, especially not in cdbs packages
[15:01] <NCommander> if I run debian/rules clean manually, it disappears
[15:01] <NCommander> er, the logs go away
[15:02] <seb128> that's expected, the clean target call dh_clean
[15:02] <NCommander> yeah
[15:02] <seb128> do you have some magic to use the new "dh" in some way?
[15:02] <NCommander> I avoid CDBS like the plague
[15:02] <NCommander> SO no ;-)
[15:02] <seb128> dh is not cdbs
[15:02] <NCommander> I thought you wanted to use dh with cdbs
[15:02] <seb128> it's debhelper 7
[15:02] <seb128> no, I say that cdbs doesn't use dh
[15:02] <seb128> so that's weird that you get those logs
[15:03] <seb128> since they seem to be create when using dh
[15:03] <NCommander> seb128, I thought CDBS used dh internally
[15:03] <seb128> no, cdbs is way older than dh
[15:04] <broonie> cdbs does use debhelper by default
[15:04] <broonie> But not the new version 7
[15:05] <NCommander> I've seen those logs on the old versions as well
[15:05] <seb128> ok, I just greped quickly in /usr/bin/dh*
[15:05] <seb128> and they seem to be a "dh" thing
[15:05] <seb128> and I've never seen those before
[15:05] <broonie> debhelper
[15:05] <NCommander> I'm working in an intrepid chroot
[15:05] <NCommander> Dunno if it would make the difference but
[15:06] <NCommander> I kicked the mostly fixed evince onto my PPA
[15:06] <NCommander> I'm now waiting for apt-get update to finish destorying my lpia chroot
[15:06] <seb128> ok, good
[15:09] <NCommander> seb128, I'm probably going to guess its going to need some autoconf love
[15:10] <seb128> NCommander: I guess something lacks a gtk+-2.0 in the configure.ac
[15:10] <NCommander> Well, its easy to localize the problem ;-)
[15:12] <NCommander> Is lpia still on ports?
[15:12] <seb128> no, it's an official architecture
[15:12] <seb128> see https://edge.launchpad.net/ubuntu/intrepid
[15:13] <NCommander> hrm
[15:13] <NCommander> weird
[15:13] <NCommander> It was erroring out
[15:13] <NCommander> but now its not
[15:14] <seb128> maybe different build sequence when using gs
[15:14] <seb128> ?
[15:14] <NCommander> Err http://archive.ubuntu.com intrepid/main Packages
[15:14] <NCommander>   404 Not Found [IP: 91.189.88.46 80]
[15:14] <NCommander> No
[15:14] <NCommander> getting apt to be happy
[15:14] <seb128> urg
[15:15] <NCommander> yeah
[15:15] <NCommander> I can't get apt to work with this
[15:15] <NCommander> Which means my dreams of fixing lpia packages just died :-P
[15:15] <seb128> well, as said before using --enable-hildon should work on i386
[15:16] <NCommander> Ok, i got it
[15:16] <seb128> no?
[15:16] <NCommander> ITs still on ports.ubuntu.com/ubuntu-ports
[15:16] <NCommander> I perfer just testing in a real environemnt
[15:16] <persia> lpia is still on ports.
[15:16] <NCommander> Because other packages may be configured differently
[15:16] <seb128> right
[15:17] <persia> Also, where possible, reorganising packages that have special --enable-hildon for lpia to instead do something architecture neutral (e.g. detect hildon at build time, produce additional binary packages, etc.) is appreciated.
[15:17] <pitti> tseliot: do you have a minute to test the new jockey with the new nvidia handlers?
[15:20] <NCommander> seb128, lpia fixes are a pain :-P
[15:20] <seb128> right ;-)
[15:20]  * NCommander looks at his checklist
[15:20] <NCommander> Fix lpia stupidity
[15:20] <superm1> pitti, do you have binary packages ready, or a bzr branch?
[15:20] <NCommander> Fix OpenID-REVU stupidity
[15:20] <NCommander> Fix C::B Stupidity
[15:20] <NCommander> I think I need a new noun
[15:20] <pitti> superm1: bzr get lp:~ubuntu-core-dev/jockey/ubuntu/ , then debuild
[15:20] <pitti> superm1: I didn't upload it yet
[15:21] <pitti> I tested it with a fake modalias entry, but that only gets me that far...
[15:21] <superm1> pitti, okay, i can take a shot in an hour or so if no one else gets a chance to take a look
[15:21] <pitti> superm1: thanks
[15:21] <pitti> if anyone else with an nvidia card is eager to help with testing the new jockey, please speak up
[15:22] <Riddell> tkamppeter: yes, fixing system-config-printer-kde is quite high on my priority, but so far I've not found time
[15:23] <superm1> pitti, are you sure that you've uploaded the full set of changes?  according to https://code.edge.launchpad.net/~ubuntu-core-dev/jockey/ubuntu the last revision is about a week old?
[15:23] <pitti> superm1: ugh, it should be about 3 minutes old...
[15:24] <superm1> were you referring to trunk perhaps?
[15:24] <pitti> superm1: loggerhead (http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/changes) does have the latest
[15:24] <pitti> so maybe the LP UI is just slow
[15:24] <superm1> ah okay
[15:24] <pitti> superm1: trunk is recent, too, but rather useless (or difficult) for nvidia testing
[15:24] <superm1> ok
[15:24] <NCommander> seb128, ok, its building, if it doesn't FTBFS, I'm going to break down and starting smacking my head on my desk
[15:26] <Riddell> evand: kde ubiquity doesn't want to get past the partitioning stage, no errors produced, don't suppose you've any ideas?
[15:26] <evand> Riddell: hrm, let me pull down a Kubuntu image and take a look.
[15:27] <Riddell> evand: needs fixes in ubiquity from bzr
[15:28] <evand> ok, noted
[15:30] <pitti> superm1: I don't know how sane it works if you have the old nvidia-glx packages installed (or whether that still works at all in intrepid, I guess not); so maybe start with just 'nv'
[15:30] <NCommander> seb128, ping?
[15:31] <seb128> NCommander: the package built correctly?
[15:31] <NCommander> seb128, nope
[15:31] <NCommander> Found the issue
[15:31] <seb128> ah ;-)
[15:31] <seb128> what is it?
[15:31] <NCommander> The hildon pkgconfig files don't list libgtk-x11 as a dependency
[15:31] <NCommander> so autoconf doesn't suck it in
[15:32] <seb128> the log is a bit weird, the line before the error seems to have the correct -llibgtk-*
[15:32] <seb128> hum
[15:32] <NCommander> (hildon is added via PKG_CHECK_MODULES, which if I remember my autotools, loads the pkg files from /usr/lib/pkgconfig, right?
[15:32] <seb128> pkg-config --cflags --libs hildon
[15:33] <seb128> or whatever the .pc is named
[15:33] <NCommander> -lgdk-x11-2.0
[15:33] <NCommander> Nope, its there
[15:33] <NCommander> Ok
[15:33] <NCommander> So much for that theory
[15:33] <seb128> gdk != gtk
[15:34] <NCommander> Oh
[15:34] <NCommander> Wait
[15:34] <NCommander> ...
[15:34] <NCommander> d'oh
[15:34] <NCommander> ok
[15:34] <NCommander> I know I need more caffiene at this point
[15:34] <seb128> did you find the issue? ;-)
[15:35] <NCommander> nope
[15:35] <NCommander> I just copy and pasted the wrong entry
[15:35] <NCommander> (gtk was right next to gdk)
[15:35] <seb128> oh, I know
[15:35] <seb128> that's going to be my fault
[15:35] <NCommander> why?
[15:35] <seb128> I need to talk to the mobile guys about that
[15:35] <NCommander> The soname of gtk-x11 is just plain weird
[15:36] <NCommander> http://paste.ubuntu.com/29608/
[15:36] <seb128> gtk was patched to expose private fileselectors apis in hardy
[15:36] <tseliot> ﻿pitti: sure. What shall I do?
[15:36] <seb128> but the fileselector has been rewritten to use gio this cycle
[15:36] <seb128> and I didn't port all the gtk changes or at least didn't try those
[15:36] <pitti> tseliot: bzr get bazaar.launchpad.net/%7Eubuntu-core-dev/jockey/ubuntu/ jockey-ubuntu ; cd jockey-ubuntu; debuild -us -uc -b
[15:36]  * NCommander debates whacking his mentor, but htings better of it
[15:36] <seb128> so it's likely libhildon needs to be updated for the gtk changes
[15:37] <seb128> lol
[15:37] <pitti> tseliot: I'd like you to use the branch, so that you can test fixes from my side quickly
[15:37] <NCommander> seb128, upload the debdiff once I reupload to PPA, and then bug the mobile guys
[15:37] <pitti> tseliot: then install the .debs, run jockey-gtk (from the menu or shell, not sudo!), and check whether it detects your nvidia card
[15:37] <pitti> tseliot: and if you can install the correct driver with it
[15:38] <tseliot> pitti: ok
[15:38] <seb128> lool, persia, ogra: somebody will need to port hildon to gtk 2.13 in intrepid, the fileselector has basically been rewritten and libhildon used to access private datas there which changed
[15:39] <NCommander> seb128, uploading to PPA (since it seems my chroot seems broken)
[15:39] <NCommander> where is upstream for hildon?
[15:39] <seb128> I'm too busy and don't know how to test those changes and what you guys need so somebody in your team will need to do that
[15:39] <pitti> tseliot: thanks muchly
[15:39] <persia> seb128: So hildon is broken entirely for intrepid?
[15:39] <seb128> NCommander: nokia? in ubuntu #ubuntu-mobile usually work on those
[15:39]  * persia celebrates
[15:39] <NCommander> All we got to do is break dak, and suddenly life would be much nicer :-P
[15:39] <seb128> persia: no, only the custom fileselector thing I guess
[15:40]  * NCommander has a personal hatred of dak
[15:40] <persia> Oh well.  That's small enough that someone might fix it.
[15:42] <NCommander> seb128, so other then the fact that hildon is broken, is my update good enough for you?
[15:42] <tseliot> ﻿pitti: no problem ;). I'll have to boot into Intrepid now
[15:42]  * tseliot reboots
[15:42] <seb128> NCommander: yes, it you fixed the things I pointed before
[15:42] <ogra> seb128, i'm not sure how intrested we are in hildon in intrepid :)
[15:43] <NCommander> what is hildon more specifically?
[15:43] <NCommander> seb128, it won't let me upload to my PPA, it keeps rejecting
[15:43] <seb128> NCommander: why does it reject it?
[15:44] <seb128> NCommander: did you update the revision number?
[15:44] <persia> NCommander: hildon is a UI framework that embeds GTK applications within a common address space and provides a unified UI (hildon-desktop is the Parent window for all windows, dialogs, etc.)
[15:44] <NCommander> no
[15:44] <seb128> NCommander: the ppa will not accepted to publish again an already published version
[15:44] <NCommander> I deleted the old one
[15:45] <persia> Deletion does not remove the history of publication, only direct access from ppa.launchpadnet
[15:46] <NCommander> seb128, want me to just upload it to the PPA with ~ppa0 on LP, or should I shove it someplace like REVU where you won't have to rebuild the source package
[15:47] <seb128> NCommander: I'm not sure that the ppa will let you downgrade the revision number, maybe just copy the debdiff on http://paste.ubuntu.com? it should be small enough
[15:47] <NCommander> its the original source file I was more worried about
[15:47] <seb128> which one? the tarball? I can get it from the GNOME server
[15:47] <NCommander> oh
[15:47] <NCommander> cool
[15:47]  * NCommander just wanted to save you work
[15:48] <NCommander> And the debdiff is 122985 lines ...
[15:48] <NCommander> O_O;
[15:48] <NCommander> oh
[15:48] <NCommander> For the love of - it included the source package changes
[15:48]  * persia recommends attaching the new diff.gz to a bug, as packages are fairly easy to regenerate from a diff.gz
[15:49] <seb128> NCommander: right, other option is to open an evince bug and attach the diff.gz and .dsc
[15:49] <NCommander> That's how I do all my FTBFS fixes
[15:49] <NCommander> (replacing diff.gz with debdiff)
[15:49] <persia> seb128: Why the .dsc?
[15:49] <seb128> bonus point if you use open the bug first, then modify the source to add "lp: #nnnnn" to the changelog and then attach the diff.gz ;-)
[15:50] <NCommander> I was doing that
[15:50] <seb128> persia: because I'm lazy and prefer to run dpkg-source than gunzip && patch, and that also gives you the md5sum for the orig tarball which has been used
[15:51] <persia> seb128: Ah, right.  The diff.gz -> package script went missing.
[15:52] <tseliot> pitti: I had already installed the driver. Jockey now says that the driver is in use however the checkbox in the "Enabled" column is not toggled
[15:53] <pitti> tseliot: so the nvidia module is loaded, but perhaps xorg.conf doesn't have "nvidia" driver?
[15:54] <tseliot> pitti: what you're saying is (currently) not possible
[15:54] <tkamppeter> pitti, system-config-printer_1.0.2+git20080723-0ubuntu1 uploaded.
[15:54] <pitti> tkamppeter: thanks muchly!
[15:55] <tseliot> pitti: if there's no "nvidia" driver specified in the xorg.conf the driver won't be loaded
[15:55] <pitti> tseliot: ok, so let's debug this
[15:55] <pitti> tseliot: -> /msg, to avoid too much noise here
[15:55] <superm1> pitti, are these handler changes right now nvidia specific, or should I be able to test at least the "detection" on fglrx too?
[15:56] <superm1> assuming modaliases are installed etc
[15:56] <pitti> superm1: I didn't update the fglrx handler for the new structure yet, sorry
[15:56] <superm1> pitti, no problem.  just wasnt sure how generic the solution was
[15:56] <pitti> superm1: I'll do that as soon as I get nvidia working (currently figuring out with tseliot)
[15:56] <superm1> pitti, okay
[15:56] <ogra> mm, no way to make intrepid boot in vbox it seems ...
[15:57]  * ogra just tried a hardy upgrade 
[15:57] <pitti> superm1: shouldn't take much time to get it fully right, probably two lines of code changed, or so; the solution is very generic now
[15:57] <superm1> pitti, ah
[15:57] <NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/evince/+bug/251172
[15:57] <NCommander> You've got debdiffs
[15:57] <NCommander> er, diff.gzs
[15:57] <superm1> ogra, this the sort of things you are seeing too: http://ubuntuforums.org/showthread.php?t=847425 ?
[15:58] <superm1> ogra, they posted a (possible) solution there
[15:59] <ogra> you mean the videobuffer ?
[15:59] <ogra> hmm
[15:59] <superm1> yeah
[15:59] <ogra> i deliberately set it to 2M
[15:59] <ogra> (to get 800x600 by default without fiddling)
[15:59]  * ogra tries
[16:00] <seb128> NCommander: the md5sum for the orig you used doesn't match the upstream one, did you download the .bz2 and repackaged it or something?
[16:00] <NCommander> no, I just grabbed the .gz
[16:00] <seb128> weird
[16:00] <ogra> superm1, still ooopsing
[16:00] <NCommander> hold on
[16:00] <superm1> ogra, oh well :(
[16:00] <seb128> I just gunziped the diff.gz and applied to that's alright
[16:00] <NCommander> Let me redownload, and remake the dsc
[16:00] <seb128> no that's ok, no need for that
[16:00] <NCommander> Or that
[16:01] <ogra> superm1, but thanks, was at least worth a try
[16:01]  * NCommander is used to bowing down for the archive admins and doing everything but signing the upload :-P
[16:01]  * NCommander is used to then getting the signed changes back and then uploading :-P
[16:01]  * persia advocates working get-orig-source rules
[16:02]  * NCommander would put it in if it wasn't a CDBS package
[16:04] <seb128> NCommander: note the "-include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk" in the rules ;-)
[16:04]  * NCommander waits for seb128 
[16:04] <NCommander> like I said
[16:04] <NCommander> CDBS is evil ;-)
[16:04] <NCommander> *shot*
[16:04] <persia> No reason not to add it there as well.  CDBS allows adding additional targets.  While I don't recommend going to the extent of sendmail, some are certainly OK.
[16:04] <seb128> persia: it's already there
[16:04] <NCommander> persia, should I download the sendmail package and take a look?
[16:04] <persia> seb128: Yep.  My backscroll reading isn't keeping up with my slow typing :)
[16:05] <seb128> NCommander: the update looks good, I'll upload, libspectre will need to be promoted before it can build though so it's time to start on the main inclusion report ;-)
[16:05] <persia> NCommander: Only if you want a counter-example
[16:05] <NCommander> seb128, want help?
[16:05] <seb128> NCommander: if you could write the mir for it that would be nice
[16:06]  * NCommander copies the template to a new wiki page and begins working on it
[16:07] <seb128> NCommander: no need to copy the template, if you create MainInclusionReportComponent page the wiki lists the templates matching the name that you can use and you just have to click on the one to use ;-)
[16:08] <NCommander> er
[16:08] <NCommander> too late
[16:08] <Riddell> BenC: linux-restricted-modules isn't on the CD currently, do you know what brought it in before?
[16:09] <seb128> NCommander: that's for the next one ;-)
[16:15] <BenC> Riddell: linux-image?
[16:16] <BenC> Riddell: I mean "linux" meta package, or maybe "linux-generic" meta package
[16:16] <ogra> mdz, hmm, i think discover was just deliberately demoted to universe in intrepid ... i'm not sure what to do about hotkey-setup now
[16:17] <Riddell> BenC: that brings in linux-restricted-modules-2.6.26-4-generic but not l-r-m-common
[16:17] <ogra> (i did the merge so feel kind of responsible for the breakage)
[16:17] <mdz> ogra: fix it to stop using discover?  it's doing the wrong thing anyway
[16:17] <BenC> Riddell: ah, missing dep on my part then
[16:18] <ogra> ah, k, i'll look into that
[16:18] <mdz> ogra: it wants to know which driver X is using
[16:18] <mdz> ogra: and if it can't find out from xorg.conf, it tries discover
[16:18] <BenC> Riddell: I can upload a new lrm quickly, or you can get lrm-common added to the cd manually to get things moving
[16:18] <ogra> i wonder anyway if we stll need it with hal-input
[16:18] <mdz> discover isn't actually very good at that
[16:18] <mdz> I assume it got harder because xorg.conf is emptier
[16:18] <Riddell> BenC: I think a quick l-r-m upload would work
[16:18] <ogra> yeah
[16:19] <mdz> maybe bryce has an idea
[16:19] <ogra> but looking at all the fdi commits hal saw the last months, the IBM situation might already be handled there anyway
[16:19] <mdz> yeah, hal fdi is a better place for all this anyway
[16:19] <ogra> not sure about other stuff hotkey-setup is used for
[16:20] <ogra> i'll look into that if i'm home next week and see if we can drop it completely ... that goes actually hand in hand with some plans persia and i discussed for certain special input devices anyway
[16:21] <mdz> ideally I think hotkey-setup should go away
[16:21] <ogra> right, but to unbreak the CD i'll just coment out the dicover call for now
[16:21] <ogra> thats something i can do immediately
[16:22] <ogra> (not sure how useful it is without that though :) )
[16:22]  * ogra lives with the curse to have a laptop where everything works :)
[16:22] <BenC> If someone tells me how to get hal to do what hotkeys-setup does, I'm willing to convert it
[16:22] <persia> ogra: Do you anticipate we'll get enough input changes for intrepid?  I had the impression it was more an intrepid+1 goal.
[16:23] <ogra> persia, but we have to start at some point
[16:23] <ogra> and there was the plan to switch all of X input to hal-input anyway at UDS
[16:23] <persia> Ah.  Good.  I missed that UDS session.  If that's already planned, I'm less worried.
[16:23] <ogra> so at least the basics will be covered i assume
[16:24] <ogra> i think that was one of the sessions where tons of notes were taken that got lost in the depths of gobby
[16:24] <ogra> Keybuk, was there irc
[16:24] <ogra> *iirc
[16:25] <ogra> and cjwatson ... i entered only at the end of the session since i was hogged in another one
[16:25] <persia> Wasn't there a backup gobby store somewhere from which to recover the lost text?
[16:25] <ogra> yes, but not all was recovered
[16:25] <persia> Oh :(
[16:26] <ogra> anyway, hal-info should have tons of fdi files to cover the most input things we need already
[16:27]  * ogra mumbles and decides to set up his intrepid vm with the hardy kernel for now ...
[16:28] <NCommander> seb128, A page with the name 'MainInclusionReportlibspectre' already exists. Try a different name.
[16:28] <NCommander> I can't win
[16:28] <seb128> NCommander: weird
[16:29] <seb128> https://wiki.ubuntu.com/MainInclusionReportlibspectre gives a "This page does not exist yet. You can create a new empty page, or use one of the page templates. Before creating the page, please check if a similar page already exists. "
[16:29] <alex-weej> damnit
[16:29] <NCommander> yeah
[16:29] <NCommander> THe wiki not having fun
[16:29] <seb128> hum, https://wiki.ubuntu.com/MainInclusionReportLibspectre
[16:29] <alex-weej> can someone tell me off hand... does ubiquity ask you for your keyboard model?
[16:29] <alex-weej> or just the layout?
[16:30] <seb128> NCommander: sorry about that, looks like somebody already did the case and the case is different
[16:30] <NCommander> seb128, oh geeze
[16:30] <NCommander> I can't get a break today
[16:30] <seb128> note for next time "check for existing reports before starting writting one" ;-)
[16:31] <NCommander> I thought you did check, hence why saying one had to be done
[16:31] <seb128> and it has been accepted and promoted according to https://bugs.edge.launchpad.net/ubuntu/+source/libspectre/+bug/236111
[16:31] <NCommander> http://paste.ubuntu.com/29627/ - care you look it over, since its still a learning expierence
[16:31] <BenC> Riddell: uploading
[16:32] <cody-somerville> slangasek, Do you know why Xubuntu isn't on the ISO tracker?
[16:32] <seb128> NCommander: yeah, I looked at it on the wiki already, looks good, sorry about the work duplication
[16:32] <NCommander> its fine
[16:32] <NCommander> Its a learning experience
[16:32] <BenC> slangasek: new lrm uploaded to get proper lrm-common deps for lrm-flav packages
[16:32] <seb128> NCommander: on the good side I'm about to upload the new evince version, thanks for your work ;-)
[16:33] <NCommander> Any MOTU should have a full set of skills
[16:33] <seb128> right
[16:33] <NCommander> I already have experience hating dak ;-)
[16:33] <slangasek> cody-somerville: because it has livefs build failures that point to a problem which is likely to also make the alternates uninstallable
[16:33] <slangasek> cody-somerville: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/xubuntu/20080722/livecd-20080722-i386.out
[16:33] <ogra> NCommander, but most MOTUs simply start with a subset of skills, you cant know everthing in the beginnig :)
[16:33] <slangasek> BenC: uploaded to where?  hardy, intrepid?
[16:34] <ogra> debian :P
[16:34] <BenC> slangasek: intrepid, sorry :)
[16:34] <alex-weej> ogra: i was gonna say last night, looking at pipermail, it doesn't seem to indent more than 4 levels... ever...
[16:34] <NCommander> ogra, it helps I created and ran an unoffical debian testing for m68k
[16:34] <NCommander> Hence why I have run dak
[16:34] <NCommander> Hence why I got sick of trying to remember which women did what
[16:35] <ogra> alex-weej, hmm, you are right, sorry then :)
[16:36] <ogra> (that doesn fix the filtering though ... )
[16:36] <alex-weej> ogra: are you using Evo?
[16:36] <ogra> yes
[16:36]  * NCommander can only remember what britney and madison did
[16:36] <alex-weej> i used to use Evo up until a few months ago and i always used "Reply to All" even then
[16:37] <ogra> but i know TB users with reply to list extension and kmail users have the same prob
[16:37] <alex-weej> and i don't remember it breaking any of my filters
[16:37] <alex-weej> i was using vFolders to filter on "list"
[16:37] <alex-weej> let me see...
[16:37] <ogra> the way you do it simply wipes the X-Mailing-List from the headers
[16:37] <alex-weej> that's probably a bug in gmail then. damnit.
[16:37] <seb128> alex-weej: ubiquity ask you for the layout, not the model
[16:38] <alex-weej> seb128: thanks for the confirmation, as i suspected
[16:38] <alex-weej> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/251187
[16:38] <ogra> likely, gmail is bad with lists anyway ... (unless you are using google lists i bet :) )
[16:38] <seb128> most people will not care about keyboard modeles or don't know what to put there
[16:39] <NCommander> seb128, says you and your QWERTY keyboard, I'm quite happy being DVOARK
[16:39] <NCommander> ;-)
[16:39] <alex-weej> ogra: i guess pipermail gets it right because it has In-Reply-To: <1216748124.17165.121.camel@osiris>
[16:39] <NCommander> (actually, the dvorak users outnumber the QWERTY users in our local LUGS)
[16:39] <seb128> NCommander: I'm using azerty not qwerty :-p and dvorak is a layout no?
[16:39] <ogra> yeah, it sorts by msg id
[16:39] <NCommander> seb128, d'oh. If I didn't just shoot myself in the foot
[16:44] <alex-weej> anyone know what's going on with the logout dialogue stuff in Intrepid
[16:44] <alex-weej> has the patch just been dropped inadvertently or are we going back to upstream?
[16:44] <alex-weej> and if so, they have bugs to be fixed.
[16:45] <cody-somerville> slangasek, was there some sort of e-mail or notification sent out?
[16:46] <slangasek> BenC: so is this lrm-common upload something I need to roll into the alpha-3 images?  I don't know what problem you're fixing, though I've seen comments that lrm is missing from some CDs
[16:47] <slangasek> cody-somerville: not by me; and the automated emails only report failed CD builds, they don't tell you when a CD build is using a stale livefs
[16:47] <zyga> mvo: is the code okay or should I work on something more?
[16:48] <BenC> slangasek: yes...the dep was required to pull everything in
[16:48] <slangasek> BenC: ok, thanks
[16:49] <BenC> slangasek: lrm modules are there, but without lrm-common, there are no firmware blobs and no linked lrm modules
[16:50] <slangasek> cody-somerville: do you or someone else have time to look into this livefs failure today?  And is there a role address you would like me to send mail to about such issues if I notice them and you're not aroud?
[16:51] <alex-weej> mvo: in the synaptic source, we have tango icons for everything yet they're not used... bug or just ENOTIMPLEMENTED?
[16:52] <cody-somerville> slangasek, My e-mail is forwarded to my blackberry so if you mail xubuntu-devel@lists.ubuntu.com then I'll get it
[16:52] <slangasek> ok
[16:52] <cody-somerville> slangasek, If you need to get in contact quickly, I have a second e-mail which is priority delivered to my blackberry.
[16:53] <cody-somerville> slangasek, I've sent you that e-mail address in a private query.
[16:54] <mvo> zyga: looks good to me, I'm not sure if we really need the custom crash handler now that apport is availabe, but it should be fine
[16:55] <mvo> alex-weej: not implemented
[16:56] <zyga> mvo: the crash handler is the same, the only difference is lsb_release information
[16:56] <zyga> (and moving it to util.py
[16:56] <alex-weej> mvo: ok
[16:56] <zyga> hmm, how does apport help?
[16:56] <zyga> (technically python never crashes)
[16:57] <mvo> zyga: I know, while looking at it, I was wondering if we should keep it, but I'm fine with having it
[16:57] <mvo> zyga: I merged it into the ubuntu branch, many thanks!
[16:57] <zyga> thank you :-)
[16:58] <NCommander> seb128, anything else for me to do?
[16:58] <zyga> mvo: one thing makes me curious though... is there any support for apport-like system for python crashes?
[16:58] <seb128> NCommander: easy or hard tasks? ;-)
[16:58] <NCommander> seb128, whatever it takes to prove my skills ;-)
[16:59] <mvo> zyga: yes and its enabled by default on the devel release, it installs a system-wide crash handler as part of the apport package
[16:59] <seb128> NCommander: as said before there is gucharmap to update to 2.23, I think they changed the soname again (not sure now about this one) and they added python bindings which should be some packaging fun (adding a new python-gucharmap, using python-central or python-support, etc)
[17:00] <seb128> NCommander: otherwise g*mm need to be updated which is probably easier if you don't dislike c++ bindings ;-)
[17:00] <NCommander> Python or C++ ...
[17:00] <NCommander> Got any pure ASM ;-)
[17:01] <sabdfl> thorwil: yes, am travelling at the moment
[17:01] <seb128> NCommander: on the "would be nice to do but not trivial list" there is also the new epiphany-browser 2.23.5, it has a webkit backend only but we likely want to keep epiphany-gecko too for a while, so that will likely require packaging the new version as a different source
[17:02] <NCommander> seb128, I assume webkit would probably need a main inclusion request?
[17:02] <NCommander> and http://gucharmap.sourceforge.net/ - gucharmap seems to not have been updated in quite awhile
[17:02] <seb128> NCommander: no, that has been done some days ago, epiphany-browser builds epiphany-webkit at the moment in intrepid
[17:02] <seb128> NCommander: http://download.gnome.org/sources/gucharmap/2.23/gucharmap-2.23.4.tar.gz
[17:03] <seb128> most GNOME projects have no updated websites
[17:03] <seb128> they tend to just code, use bugzilla and upload tarballs ;-)
[17:03] <NCommander> lol
[17:04] <NCommander> ok, lets see here
[17:04] <NCommander> Well, this hsouldn't be too bad ...
[17:04] <stgraber> BenC: something looks buggy in 2.6.26-4 framebuffer handling
[17:04] <stgraber> BenC: booting an intrepid system gives you no usplash but a black screen instead (no boot messages)
[17:04] <seb128> NCommander: probably not too difficult no, and a good occassion to look at the python policy if you didn't yet ;-)
[17:05] <stgraber> BenC: loading with vga=791 and no "splash" gives you a black 1024x768 screen
[17:05] <NCommander> Those binding look fun
[17:05] <mvo> cjwatson: does ubiquity write the proxy information only to /etc/apt/apt.conf? or does it also write it to a place in /etc/default (or /etc/environment) or something similar?
[17:05] <stgraber> BenC: I get that in kvm but mdz and davmor2 seem to have the same on real HW
[17:06] <slangasek> BenC: ^^ this is me getting out of the middle of the conversation between you and stgraber :)
[17:08] <NCommander> seb128, care to explain the ltmain_as-needed.patch? seems like a clunky way to pass a linker flag ...
[17:08] <NCommander> seb128, upstream has a nice shiny new libtool ltmain.sh
[17:08] <seb128> NCommander: that comes from debian, apparently reordering is required to get --as-needed to do its job
[17:09] <NCommander> Whats that do?
[17:09]  * NCommander loves how these patches have no comments attached to them
[17:09] <seb128> that limits inflated depends
[17:10] <seb128> man ld and search for --as-needed
[17:10] <NCommander> seb128, I see
[17:10] <seb128> NCommander: I think the corresponding bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
[17:10]  * NCommander sees if LDFLAGS work now since libtool got updated
[17:12] <BenC> stgraber: does it stay black (never shows text console)?
[17:12] <seb128> NCommander: speaking about comments, https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines, something we don't do enough but that we should try to do, documenting the changes ;-)
[17:13] <NCommander> I am always very good at filling out dpatch ehaders :-P
[17:15] <NCommander> seb128, I can't figure out if its fixed in libtool 1.5.28-0ubuntu1
[17:16] <NCommander> Off hand, I'm going to say no though
[17:16] <seb128> NCommander: I don't think that's fixed no, you can try to drop the change, build the package and see the depends difference between the current version and the new one
[17:16] <seb128> or try to apply the patch, do a build using it and one not using it and debdiff those
[17:17] <NCommander> its never easil :-P
[17:17] <NCommander> seb128, it doesn't apply cleanly
[17:17] <NCommander> Nor does the lp intergration patch
[17:17] <seb128> right, but it's easy enough to update
[17:17] <NCommander> the lt one, or the lp one :-P
[17:17] <seb128> that's just 2 code blocks to copy to the similar context
[17:17] <seb128> both
[17:17] <NCommander> meh
[17:17] <NCommander> I'm too tired to work on this right now
[17:17] <NCommander> I'll attack it when I'm slightly more work
[17:17] <NCommander> ... awake
[17:18] <NCommander> Haw, proving my point!
[17:18] <seb128> alright ;-)
[17:18] <seb128> you already did quite some work today
[17:18] <NCommander> seb128, well, yeah, I implemented openid logins for REVU (and became a REVU hacker ;-))
[17:18] <NCommander> seb128, I also added a PPA importer, and apt-get source support to revu
[17:18] <NCommander> or, almost got the last one
[17:18] <calc> seb128: so should i be changing the %U to %f for OOo (remember we talked about this the other day?)
[17:19] <calc> seb128: one of you mentioned it might be better to do some stuff to nautilus instead?
[17:19] <seb128> waouh, lot of revu changes ;-)
[17:19] <NCommander> seb128, http://nemesisnetworks.com/revu-openid
[17:19] <NCommander> ;-)
[17:19] <seb128> calc: maybe mail ubuntu-desktop list about that just to get comments before doing it
[17:19] <calc> ok
[17:20] <calc> seb128: is it a lowercase or uppercase f?
[17:20] <seb128> depends of what you want
[17:21] <calc> ah, probably should look at the specs ;-)
[17:21] <seb128> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html
[17:21] <calc> thanks for the url :)
[17:21] <seb128> %f is one file, %F a list of files
[17:21] <seb128> probably %F if you had %U before
[17:22] <calc> yes it looks like %F is the correct one, thanks for the help :)
[17:23]  * calc sending an email to the list now
[18:11] <seb128> slangasek: the session change is not really a "bug"
[18:12] <slangasek> seb128: ok; do you have a better place to track it other than a bug report, such that the rest of the team knows it's an outstanding issue? ;)
[18:12] <seb128> not really, though I don't really consider it as an issue ;-)
[18:12] <seb128> but point, we should have a bug milestoned about "what to do to the session dialog"
[18:12] <slangasek> heh, ok
[18:12]  * slangasek nods
[18:13] <seb128> I'll open one and reply on the list
[18:13] <slangasek> cheecs
[18:13] <slangasek> cheers, too
[18:14] <stgraber> BenC: sorry I was away, when starting with vga=791 I get nothing until X starts. Without vga=791 and using usplash I just get a shell cursor at the top right corner, not even blinking IIRC and that's it. No text displayed until X starts.
[18:15] <calc> any big breakage in intrepid for a i945 laptop? i'm considering upgrading my dev machine to intrepid but don't want it to fall apart on me
[18:15] <calc> it has intel graphics
[18:15] <seb128> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/251211
[18:21] <BenC> stgraber: but does switching to the console after X starts give you a login prompt?
[18:21] <pitti> superm1: I just commited an 1-line fix for jockey's fglrx handler which (I think) is everything it takes to make it work in intrepid
[18:22] <stgraber> BenC: well, I have no idea how I can do ctrl+alt+f1 in kvm without doing that on the host system.
[18:22] <stgraber> davmor2: can you try that on real HW after the QA meeting ^^
[18:22] <BenC> stgraber: keyboard grab should isolate it (or can kvm synthesize the key strokes somehow?(
[18:23] <pitti> superm1: would you be up for a quick test?
[18:23] <davmor2> stgraber: on what sorry?
[18:24] <mvo> stgraber: you can do "ctrl-alt-2" to enter a monitor mode
[18:25] <mvo> stgraber: then run "sendkey ctrl-alt-f1"
[18:25] <mvo> that should work
[18:29] <BenC> stgraber: you could also try "splash quiet single" on the command line to avoid going into X
[18:30] <stgraber> ctrl+alt+f1 doesn't seem to work, keyboard stop working but I still see the X server, that's a bit weird
[18:31] <slangasek> seb128: thanks :)
[18:33] <davmor2> BenC: stgraber: is this to sort out the issue with usplash?
[18:33] <slangasek> yes
[18:34] <davmor2> when do I hit ctrl+alt+f1 as soon as grub finishes?
[18:34] <davmor2> cursor does flash just slowly
[18:35] <stgraber> so during the whole boot process you don't see anything other than a cursor (doesn't blink here) ?
[18:35] <stgraber> then when you get to gdm/kdm, can you switch to tty1 (ctrl+alt+F1) ?
[18:37] <davmor2> right I hit it on hw with a Kubuntu install (same issue) and I get a message that says there is no suitable usplash image found for 640x480
[18:38] <kelemengabor1> mvo: hi, i'd like to ask some questions about ddtp-ubuntu
[18:38] <stgraber> davmor2: ah ? so you can switch to tty1, that's good :)
[18:38] <kelemengabor1> particularly, i'm interested in the code that generates the po files
[18:38] <stgraber> oh yes, I can also reproduce using a livecd image
[18:38] <stgraber> "usplash: No usable theme found for 640x480"
[18:38] <kelemengabor1> I fount this: http://people.ubuntu.com/~mvo/bzr/apt-ddtp-tools--main/  - is this it?
[18:38] <stgraber> so that's usplash bug it seems
[18:39] <mvo> kelemengabor1: yes, that is the code
[18:39] <kelemengabor1> great :)
[18:39] <mvo> kelemengabor1: there is a file "UbuntuChecklist" that explains the steps that are needed and what tools are used
[18:40] <mvo> kelemengabor1: what do you plan to do with it :) ?
[18:40] <BenC> davmor2: if the message is usplash doesn't have a suitable image, that's a usplash bug
[18:40] <kelemengabor1> well, we want to add package name information to the po file
[18:40] <stgraber> pitti: ^
[18:40] <kelemengabor1> to make easier the cooperation between other distros
[18:40] <mvo> kelemengabor1: aha, good idea!
[18:40] <BenC> stgraber, slangasek: The message davmor2 reported is a usplash bug and sounds like no theme is installed (or the theme is messed up somehow)
[18:41] <pitti> hi stgraber
[18:41] <kelemengabor1> mvo: we faced a problem, that ddtp is huge
[18:41] <mvo> kelemengabor1: let me know if you have anything for me to merge, I had some other ideas, but launchpad is not that flexible
[18:41] <stgraber> BenC: I checked, the theme is installed (so is it on my lappy)
[18:41] <slangasek> BenC: ok, progress \o/
[18:41] <stgraber> pitti: "usplash: No usable theme found for 640x480"
[18:41] <mvo> kelemengabor1: I would love to see the strings split per package instead of this giant table
[18:41] <BenC> stgraber: must dig deaper into usplash then
[18:41] <pitti> stgraber: uh..
[18:41] <kelemengabor1> and we want to simply reuse existing translations from fedora and suse
[18:41] <stgraber> pitti: that's with usplash and usplash-theme-ubuntu installed
[18:42] <mvo> kelemengabor1: do you know about http://ddtp.debian.net/ddtss/index.cgi/xx ?
[18:42] <kelemengabor1> mvo: what? 5k small po files instead of one huge with 15k strings?
[18:42] <pitti> usplash: can't get console font: Invalid argument
[18:42] <pitti> usplash: No usable theme found for 1024x768
[18:42] <kelemengabor1> no
[18:42] <pitti> stgraber: I get that for sudo ./usplash-test.sh -v
[18:42] <mvo> kelemengabor1: afaik the code for this is available
[18:43] <kelemengabor1> will see
[18:43] <pitti> stgraber: hm, lemme try something
[18:44] <stgraber> pitti: we then just get a black screen instead of usplash causing things like entering the passphrase for encrypted LVM to fail :(
[18:44] <mvo> kelemengabor1: for ubuntu having it as a extra po file in launchpad/rosetta for each source package would be great because we have the po files there anyway, that would give people a easier time to translate the descriptions along the way when they transate the app itself
[18:44] <pitti> right, I'm currently running without "splash" in  intrepid, since it's totally broken for me as well
[18:45] <pitti> stgraber: can you try a no-change rebuild of usplash-theme-ubuntu?
[18:45] <pitti>   * usplash-theme.h: Add a "void* private" pointer to the theme, so that
[18:45] <kelemengabor1> mvo: if i had a team with lots of people...
[18:45] <pitti>     themes have an easy way of storing some custom data. Bump THEME_VERSION to
[18:45] <pitti>     3 to reflect the ABI change. Thanks to David Härdeman for the patch!
[18:45] <BenC> stgraber: that sounds like a bug in itself...lvm password shouldn't fail if usplash fails
[18:45] <pitti> ^ I tested that usplash still worked without rebuilding -theme-ubuntu after that patch, and it did work at the time; but maybe it stopped
[18:45] <mvo> kelemengabor1: indeed, keep me updated :)
[18:45] <pitti> stgraber: without "splash" I get text-mode prompt for luks passphrase
[18:46] <stgraber> BenC: indeed, it should bring you back to standard text-mode boot and in this case you get prompted for the passphrase (that's how I do on my lappy)
[18:46] <BenC> pitti: was that private pointer added to the end of the struct?
[18:46] <stgraber> pitti: me too
[18:46] <pitti> BenC: yes (deliberately)
[18:46] <kelemengabor1> but currently, what we do is organize IRL translation weekends, and assign work to volunteers, adding 400 packages to this equation would be overcomplicated
[18:47] <pitti> oh, hm, I'm currently running on 2.6.24, so usplash should actually work
[18:47] <BenC> pitti: guess check for NULL on older ones didn't work though
[18:47] <BenC> pitti: does usplash have a check for which ABI the theme was compiled against?
[18:47] <kelemengabor1> so i think splitting it is not that good idea
[18:47] <pitti> BenC: (after some hours my computer gets unbearably slow with 2.6.26-4)
[18:47] <kelemengabor1> perhaps the suse way, by splitting it alphabetically
[18:47] <pitti> BenC: since it worked at at that time, I guess it's only a compile-time check
[18:48] <kelemengabor1> is somewhat more manageable
[18:48] <slangasek> pitti: blink, is the 2.6.26-4 kernel built without CONFIG_FEED_THE_HAMSTERS?
[18:49] <pitti> BenC, stgraber: looks like a rebuild fixes it, uploading
[18:49] <slangasek> pitti: did you get the bug # for that one?
[18:49] <kelemengabor1> but lots of small units to handle would make me crazy
[18:49] <pitti> slangasek: :/ I wasn't able to track it down; the load is < 1, no particular CPU usage
[18:49] <pitti> slangasek: bug# for usplash? haven't looked yet
[18:49] <pitti> stgraber: ^ got a bug #?
[18:49] <stgraber> pitti: cool, I just pushed the theme to my build server so I can test here (without waiting > an hour)
[18:50] <kelemengabor1> anyway, another question: how often are the ddtp po files updated, and translations pushed to production?
[18:50] <stgraber> pitti: sort of: bug 249037 (the user may have mixed two different problems though)
[18:51] <stgraber> is X seems to be broken as well but the boot part sounds like that usplash bug
[18:52] <pitti> hm, I think I just upload it without a bug # now; I searched the usplash and usplash-theme-ubuntu bugs, nothing really 100% matching
[18:52] <kelemengabor1> mvo: where is that UbuntuChecklist file you mentioned?
[18:52] <slangasek> ok
[18:53] <pitti> btw, what happened to seahorse? I don't get an agent...
[18:53] <pitti> oh, PEBCAK
[18:53] <mvo> kelemengabor1: isn't it in the toplevel of the checkout?
[18:53] <kelemengabor1> well, i did not checked it out
[18:53] <kelemengabor1> yet
[18:54] <kelemengabor1> but can't see it on the web
[18:54] <mvo> kelemengabor1: yeah, you need to checkout
[18:55] <mvo> kelemengabor1: or get / pull
[18:55] <pitti> anyone here with an Ati card (fglrx) who is willing to test a new jockey on intrepid?
[18:55] <pitti> slangasek: ^ FYI, I'd like to get that test before I upload
[18:56] <pitti> slangasek: as usual, things took a little longer to get everything in shape; nvidia reasonably works now
[18:56] <slangasek> I have no such hardware, alas
[18:56] <stgraber> pitti: fglrx is broken in Intrepid due to the new X server
[18:56] <pitti> slangasek: lucky you :)
[18:56] <pitti> stgraber: oh, ok; so nothing to test ATM?
[18:56] <slangasek> lucky, or picky about my hardware :)
[18:56] <kelemengabor1> mvo: got it, thanks
[18:57] <stgraber> pitti: well, I can try it if you want but that will give me a xorg module I can't load anyway
[18:57] <pitti> so I guess I can just as well upload now, to at least make the nvidia users happy
[18:57] <pitti> stgraber: if it doesn't work anyway, we can test it later, too, I think
[18:57] <slangasek> cody-somerville: not sure if I saw an answer from you about whether you're in a position to work on the livefs build failures today?
[18:57] <stgraber> pitti: indeed, next ATI module should be in a bit less than a month
[18:58] <stgraber> so until that I have to use the good old radeon driver :)
[18:58] <slangasek> mdz: did you find that the kernel lockup was reproducible/debuggable?
[18:59] <cody-somerville> slangasek, I will be able to this evening.
[18:59] <slangasek> cody-somerville: ok, cheers
[18:59] <cody-somerville> :)
[18:59] <slangasek> soren: ubuntu server images disabled for respin, due to the pervasive usplash problem
[18:59]  * cody-somerville pokes mr_pouit and gpocentek to see if they can help in the mean time.
[18:59] <mdz> slangasek: yes, I just posted to -devel@ about it
[19:00] <mdz> slangasek: and targeted the bug for intrepid
[19:00] <slangasek> pitti: so you said you have splash off in intrepid; is whatever bug is preventing you from using it targetted to intrepid?
[19:00] <slangasek> mdz: ah, thanks; mail hasn't arrived yet
[19:01] <pitti> slangasek: last time I disabled it was when it caused X to crash
[19:01] <stgraber> pitti: confirmed, usplash works again after a nochange rebuild
[19:01] <pitti> slangasek: I just enabled it again, and will do a test-boot in some minutes
[19:01] <slangasek> pitti: thanks
[19:02] <mdz> slangasek: I just filed bug 251227 about my usplash issue on the desktop CD
[19:02] <slangasek> mdz: darn, pitti just uploaded the fix for that without a bug reference ;)
[19:03] <pitti> mdz: nice race condition; right before I uploaded, I didn't find a matchign bug :/
[19:03] <mdz> slangasek: I also have/had an issue with screen corruption when it does run
[19:03] <pitti> yeah, me too, but I still think that this is a kernel problem, since it works fine with 2.6.24
[19:04] <slangasek> mdz: does "have/had" mean it's confirmed to be ongoing?  I know we had a bug report about that for alpha-2, but I don't see it open anymore
[19:05] <slangasek> Riddell: ^^ bug #251223 for mdz's kernel crash which might be the same one you're seeing
[19:05] <stgraber> slangasek: we don't have working usplash at the moment so hard to reproduce :)
[19:05] <slangasek> well, yes.
[19:05] <stgraber> slangasek: I didn't notice any screen corruption in the kvm I booted a minute ago with the fixed usplash but I may just be lucky ...
[19:09] <mdz> kudos to the reporter of bug 243682 for attaching a video clip demonstrating the problem
[19:09] <mdz> but it's not the same bug as mine
[19:10] <mdz> oh, actually, the shutdown video clip is very similar
[19:10] <mdz> to what I see at startup
[19:17] <tyfon> hmm on the mini.iso and netboot via pxe in a kvm the dhcp client gets a new address every second or so .. during the install
[19:20] <tyfon> ls
[19:23] <BenC> tyfon: could that be a misconfigured dhcp server?
[19:23] <tyfon> i don't think so, it works fine on all my other computers and hardy running in kvm
[19:23] <slangasek> if you somehow have two dhcp clients running on the same interface, that could explain it
[19:24] <tyfon> well the br0 interface in the hardy host is configured as dhcp, but the kvm guest has a very diffrent mac and gets a diffrent ip
[19:26] <slangasek> right, I meant two dhcp clients running within the guest itself
[19:26] <tyfon> nope, ps aux | grep dhclient only reports one..
[19:26] <slangasek> a buggy dhcp server would also certainly account for it, if for some reason it sets a low lease for particular macs
[19:26] <tyfon> kind of strange though, i will see if it continues when the guest is installed
[19:29] <pitti> hmm, no luck
[19:29] <pitti> I tried new usplash-theme-ubuntu after update-initramfs -k all -u
[19:30] <pitti> works perfectly on hardy kernel, but on current intrpeid kernel I just get red-white stripes in text mode, and no usplash at all
[19:30] <pitti> hm, I still have uvesafb blacklisted, maybe that's it
[19:31] <pitti> BenC: do we install v86d now? last time, I tried all possible combinations of uvesafb and v86d, but that was the time when usplash still worked (although only corrupted)
[19:32] <pitti> so, "uvesafb blacklisted" and "no v86d" -> usplash corrupts screen for me
[19:32] <pitti> (dell latitude, intel945GM)
[19:40] <tyfon> hmm i think this might be a clock issue in the kvm thing :p.. i get "Login timed out after 60 seconds" about 0.5 sec after i type inn the username in the console
[19:45] <emgent> http://blogs.gnome.org/dcbw/2007/10/15/networkmanager-07-is-the-new-chuck-norris/
[19:45] <emgent> big lol!
[19:46] <mario_limonciell> pitti, sure i'll take a look
[19:47] <pitti> mario_limonciell: stgraber told me that the current fglrx driver is broken ATM?
[19:47] <mario_limonciell> pitti, well with the current xorg yeah doesnt boot fully to X
[19:47] <mario_limonciell> was wanting to make sure detection worked, and booting with the old X server until fglrx is rev'ed for the new x server
[19:49] <pitti> mario_limonciell: that would be useful indeed
[19:50] <BenC> pitti: then that sounds less like a kernel bug and more like a usplash issue to me
[20:08] <slangasek> mathiaz: where can I find the ServerGuide, to review the samba section?
[20:08] <mathiaz> slangasek: http://doc.ubuntu.com/ubuntu/serverguide/C/
[20:08] <mathiaz> slangasek: doc.ubuntu.com has the latest version of all the work from the documentation team
[20:08] <slangasek> ok
[20:11] <pitti> BenC: so I did some experiments: uvesafb+no v86d -> I get the kernel complaints about "v86d not found blabla", text mode; uvesafb+v86d -> "cannot detect vga mode" and usplash wants to start up as 320x200 (fails, no theme); howver, it works fine in all configurations when I start usplash out of the running system; so maybe something is missing in the initramfs?
[20:12] <pitti> I'm still unsure what role uvesafb and v86d have; they primarily seem to affect initramfs booting; since hardy's kernel works all the time (even with intrepid-generated initramfs), I guess .26 moved some important bits into userspace?
[20:12] <pitti> does usplash work for anyone else in intrepid?
[20:12] <tyfon> does not work in my kvm intrepid
[20:13] <tyfon> but anyway 2.6.26 seems to have major timer issues running under kvm
[20:14] <DktrKranz> pitti, FYI, it doesn't work with 2.6.24 kernels on intrepid
[20:14] <DktrKranz> as much as 2.6.26
[20:16] <pitti> DktrKranz: "no usable theme found"?
[20:16] <DktrKranz> pitti, yes, and I see also "no resolution available" or similar
[20:16] <pitti> DktrKranz: that's fixed in the latest usplash-theme-ubuntu
[20:20] <slangasek> mathiaz: ok, where do I send bugs about grammar errors? :-)
[20:20] <mathiaz> slangasek: it seems that doc.ubuntu.com is not up-to-date
[20:21] <slangasek> oh :-)
[20:21] <mathiaz> sommer: ^^
[20:21] <mathiaz> sommer: I'd submit the bzr branch to LP
[20:21] <mathiaz> slangasek: we (me and sommer) are discussing the most efficient way to get reviews on the server guide done
[20:21] <slangasek> ok
[20:22] <sommer> mathiaz: gotcha, but I think some folks would be more likely to give reviews if they didn't have to involve bzr (or any commands other than a browser)
[20:22] <tseliot> ﻿pitti: about --debug mode, maybe there's a problem with policyKit. The non-debug mode worked as if it didn't have the authorisation to install the packages. Maybe you should let Jockey display a dialog if policyKit fails. Just a thought.
[20:22] <mathiaz> slangasek: grammar errors -> fix them in the bzr branch and submit it
[20:22] <slangasek> sommer: well, I'm more likely to give you a *useful* review if I don't have to touch my stinking browser and can just commit patches ;)
[20:22] <slangasek> where's the bzr branch then?
[20:23] <mathiaz> slangasek: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid
[20:23] <mathiaz> slangasek: you'll get all of the ubuntu documentation
[20:23] <slangasek> ok
[20:23] <slangasek> right
[20:23] <slangasek> which ISTR is painful :P
[20:24] <mathiaz> slangasek: I'm looking into splitting the server guide into it's own branch
[20:24] <mathiaz> slangasek: things have improved since intrepid - it doesn't take as much time as it used to
[20:24] <slangasek> mathiaz: does the branch still include autogenerated files?
[20:24] <mathiaz> slangasek: a lot of the history hasn't been dropped IIRC
[20:24] <sommer> mathiaz: correct
[20:25] <sommer> should only take a couple of min
[20:25] <pitti> tseliot: the frontend should just crash if you don't get the authorization
[20:25] <mathiaz> slangasek: I don't know - the branch is 87M now
[20:26] <mathiaz> slangasek: instead of the 400/500 M it used to be for hardy
[20:26] <slangasek> heh
[20:26] <tseliot> ﻿pitti: really? Aren't you using something like "if authorised:"
[20:27] <pitti> tseliot: I just try, and if I get a PermissionDenied dbus error, I do ObtainAuthorization and try again; but I don't intercept errors from the second attempt
[20:27] <tseliot> ﻿pitti: ah, ok
[20:34] <sommer> mathiaz, slangasek: another issue with reviewing the docs from bzr is that you need to view them in yelp, and some peeps don't like gnome shtuff
[20:35] <mathiaz> sommer: is yelp really needed ?
[20:35] <slangasek> sommer: well, /I/ don't have to, I'm happy to view and edit raw xml ;)
[20:35] <mathiaz> sommer: using yelp is to make sure that they look good in yelp
[20:35] <sommer> that's true too
[20:36] <sommer> mathiaz: it also lets you focus on the content
[20:36] <mathiaz> sommer: I'd rather focus on reviewing the *content*, rather than the *look*
[20:36] <sommer> mathiaz: right, I was just thinking that sometimes the xml gets distracting
[20:37] <sommer> either way... I'm not really even sure how many reviews have been done using the doc.u.c anyway :-)
[20:37] <mathiaz> sommer: hm - which tools are you using to edit the xml ?
[20:38] <mathiaz> sommer: may be we should advise reviewer to use a tool that focuses mainly on the content
[20:38] <sommer> mathiaz: I used vi during hardy, but for whatever reason the spell checking didn't work so I've switched to gedit
[20:38] <sommer> mathiaz: I guess I like the idea of having the development content available from multiple sources
[20:40] <slangasek> sommer, mathiaz: so whose idea was it to suggest the use of security=share here...?
[20:41] <sommer> slangasek: mine, as there was a couple of bugs about it
[20:41] <slangasek> sommer: ok, well security=share is crap
[20:41] <sommer> slangasek: it is stated that it's not secure, and there's a whole section on security... but that was kind of an iffy thing
[20:42] <sommer> slangasek: the use case I was thinking of was home user situation
[20:42] <slangasek> anything you want to achieve using security=share can also be done with securty=user, and then you don't have to completely reconfigure your security model to switch between use cases
[20:43] <sommer> slangasek: so with multiple users using multiple workstations you wouldn't have to setup a username for each user on the server?  or I guess they could all use the same username
[20:43] <sommer> slangasek: but if they're all using the same username, why have a username?
[20:43] <sommer> slangasek: least that was my thinking
[20:44] <mathiaz> sommer: couldn't anonymous share be used to achieve the same ?
[20:44] <slangasek> sommer: guest ok = yes; map to guest = Bad User; force user = user-to-access-as (the last part only if there's a reason not to use 'nobody')
[20:45] <sommer> ooooohhhh, gotcha
[20:45] <sommer> okay, well I can re-write that
[20:46] <sommer> so why is security=share even there?  I guess I've totally missed the plot on that one
[20:47] <slangasek> sommer: security=share is the way Win9x did it; and samba is old, so it also supports the Old Way. :)
[20:48] <slangasek> but I think you can't even configure XP/Vista to use the share-based security model if you wanted to
[20:48] <sommer> slangasek: I see, ya that's about the time I was first learning it
[20:50] <sommer> slangasek: I'll fix those sections... does the "no-login", then security, samba as domain controller format work?
[20:51] <slangasek> I don't think I've gotten to that yet
[20:51] <sommer> okay, well if you find any other issues please let me know
[20:51] <sommer> slangasek: thanks for reviewing it :)
[20:52] <slangasek> sure
[20:53] <slangasek> sommer: oh, chmod 777?  That's not a good thing either; that's definitely a security hole if there are any untrusted local users
[20:54] <sommer> slangasek: will the "guest ok = yes; map to guest = Bad User; force user = user-to-access-as" take care of the need for that?
[20:54] <slangasek> yes
[20:54] <sommer> cool
[20:55] <slangasek> then it just needs to be owned by user-to-access-as
[20:59] <mario_limonciell> pitti, oooh, jockey has policykit support now? cool :)  well it detected fglrx correctly, but didn't install it for me.
[21:00] <mario_limonciell> pitti, is there a debug mode to activate in jockey?  i didn't see one in jockey-gtk --help anymore
[21:01] <kees> why did ffmpeg get split into ffmpeg-free and ffmpeg-debian?
[21:03] <kees> oh, nm, just soyuz confusion.
[21:12] <mario_limonciell> pitti, tseliot what was the plan for the metapackage that will grab the modaliases packages (nvidia-*-modaliases and fglrx-modaliases)?  perhaps lrm-common?
[21:14] <mario_limonciell> pitti, tseliot oh nvm it looks like jockey recommends nvidia-common which depends on all the modaliases stuff
[21:14] <mario_limonciell> pitti, so perhaps can you add a recommends to fglrx-modaliases too then to jockey-common?
[21:14] <geser> slangasek: I assume the gnupg merge has to wait for alpha-3?
[21:15] <persia> gnupg is definitely on the CD :)
[21:15] <slangasek> geser: yes
[21:17] <geser> slangasek: are there any issues with the merge or does it just need till the archive is open again?
[21:17] <slangasek> geser: I'm not aware of any other issues
[21:17] <slangasek> but then, I haven't looked too closely yet
[21:17] <geser> ok
[21:21] <tseliot> ﻿mario_﻿limonciell: nvidia-common is a real package and contains a program which makes the transition to the new name schemes easier
[21:23] <mario_limonciell> tseliot, ah didn't realize
[21:23] <mario_limonciell> but nonetheless, that's how the modaliases are installed by default
[21:23] <mario_limonciell> from that dependency
[21:24] <tseliot> ﻿mario_limonciell: right, and nvidia-common would fail otherwise
[21:24] <mario_limonciell> tseliot, okay.  did you get to test out if installation via jockey worked properly, or only if it detected correctly after already installed?
[21:26] <tseliot> ﻿mario_limonciell: Jockey works well in debug mode in both cases. There must be something that prevents it from installing the driver in normal mode.
[21:26] <mario_limonciell> tseliot, how do you activate debug mode?
[21:26] <tseliot> ﻿mario_limonciell: --debug
[21:27] <mario_limonciell> yeah i tried that, but it said no such option: --debug
[21:27] <tseliot> ﻿mario_limonciell: the backend has that option
[21:27] <mario_limonciell> tseliot, well how do you pass that to the backend then?
[21:28] <tseliot> ﻿mario_limonciell:kill any instance of jockey and type:
[21:28] <tseliot> sudo /usr/share/jockey/jockey-backend --debug 2>&1 | tee /tmp/debug.txt
[21:29] <mario_limonciell> tseliot, ah.  well and it appears to be working when i did it that way too in debug mode
[21:29] <tseliot> then run jockey-gtk in another shell
[21:29] <mario_limonciell> the progress bar isn't exactly accurate
[21:29] <mario_limonciell> but it worked
[21:30] <tseliot> the progress bar is WIP
[21:30] <mario_limonciell> ah
[21:32] <mario_limonciell> pitti, well as a summary to the above, fglrx detection and installation works properly in jockey debug mode, but in regular mode only detection works
[21:35] <mario_limonciell> tseliot, did you make sure that nvidia-177-kernel-source was removed after you "deactivated" the driver?
[21:35] <mario_limonciell> it looks like for me just xorg-driver-fglrx was, but the kernel source remained
[21:36] <tseliot> ﻿mario_limonciell: I reported the problem to pitti and he told me that he would deal with it
[21:36] <mario_limonciell> tseliot, okay
[21:38] <slangasek> sommer: I believe the 'acl' option is something that can be set on the ext3 filesystem itself rather than as a mount option, which seems preferable
[21:39] <slangasek> sommer: (tune2fs -O acl)
[21:45] <sommer> slangasek: ah thanks, that's simpler
[21:58] <pitti> mario_limonciell: I didn't add the recommends yet, since fglrx is still in multiverse; you said I should keep it there for the time being?
[22:00] <pitti> mario_limonciell: hm, weird; I have no real idea why it doesn't work in non-debug mode; I tried it with some small packages like pmount, and they install well
[22:02] <mario_limonciell> pitti, yeah keep it there for the time being still
[22:02] <mario_limonciell> i'm waiting for another soyuz bug to be fixed before i ask the tech board to have an acl for it
[22:03] <mario_limonciell> and there's not a point to have it activated anyhow until it is compatible w/ xorg 1.5
[22:04] <mario_limonciell> pitti, ah well in non debug mode i just got it to work, but only when i started the jockey-backend manually first
[22:04] <mario_limonciell> the frontend didn't spawn it it appears
[22:05] <pitti> now, that's curious
[22:05] <pitti> mario_limonciell: if you run "jockey-gtk --list", you don't get a driver list, but an error?
[22:06] <mario_limonciell> pitti, let me clear the jockey cache, all the fglrx stuff, and do a fresh boot to make sure there is nothing stale sitting around
[22:12]  * pitti jumps for joy
[22:12] <pitti> apport retracers are back!
[22:13] <laga> yay!
[22:14] <mario_limonciell> pitti, jockey-gtk --list worked correctly, but installing still didn't work.  i manually restarted jockey-backend myself (without debug this time) and it works
[22:14] <mario_limonciell> so its just the spawned jockey-backend process that isn't working right
[22:15] <pitti> mario_limonciell: how did the "didn't work" manifest? did you get a correct display of drivers in the UI? a progress bar for package installation?
[22:15] <mario_limonciell> pitti, yes
[22:15] <mario_limonciell> i got both, but the bar jumped by really quick without error
[22:16] <mario_limonciell> and i checked installed packages, and they weren't installed
[22:20] <pitti> mario_limonciell: did you get the PK auth both times?
[22:20] <mario_limonciell> hm, i didn't pay attention
[22:20] <mario_limonciell> i'll start again and see
[22:20] <pitti> mario_limonciell: hang on
[22:20] <pitti> mario_limonciell: I can reproduce it
[22:21] <slangasek> sommer: I would also argue that netlogon belongs under /var/lib/samba, not in /srv
[22:21] <mario_limonciell> pitti, ah okay good :)
[22:28] <slangasek> sommer: does this scp-based BDC actually work?  I thought samba resets file permissions on its tdb files
[22:28] <slangasek> sommer: also, I think this clobbers secrets.tdb, which is where the PDC/BDC trust is stored..
[22:30] <pitti> dpkg: dpkg - error: PATH is not set.
[22:30] <pitti> tseliot, mario_limonciell: ^ argh, I get that...
[22:30] <pitti> so, that shouldn't be too hard
[22:31] <tseliot> ﻿pitti: great :-)
[22:31] <pitti> ugh, seems dbus-spawned processes have a VERY limited initial environment...
[22:32] <mario_limonciell> pitti, why aren't you using a gdebi like method for doing the install?
[22:33] <pitti> mario_limonciell: the system dbus spawned program doesn't have any desktop access
[22:33] <pitti> mario_limonciell: previous versions just called synaptic
[22:33] <pitti> but that doesn't fit well into the unprivileged client <- dbus -> privileged backend model
[22:33] <mario_limonciell> pitti, i thought gdebi used python-apt though (hence not really needing a gui)?
[22:33] <pitti> right, using python-apt directly would be better, and it's on my list
[22:33] <mario_limonciell> oh okay :)
[22:34] <pitti> mario_limonciell: well, *actually* I want to make it work with PackageKit :)
[22:34] <pitti> but I need to find a workaround for the dbus-glib bug which currently breaks that
[22:34] <pitti> (I have a packagekit branch already)
[22:35] <pitti> mario_limonciell: using apt-get was just a quick hack to get something for alpha-3
[22:35] <laga> pitti: are you aiming for distribution independence by using PackageKit?
[22:35] <mario_limonciell> pitti, yeah that makes sense
[22:35] <pitti> laga: that's the plan; it's an upstream project now, and RedHat and OpenSuSE plan to adopt it
[22:36] <pitti> mario_limonciell: there, fixed; thanks for pointing out!
[22:36]  * pitti commits and uploads
[22:36] <mario_limonciell> pitti, great, so it looks like that's the last piece to converting to this style of restricted drivers then  :)
[22:37] <pitti> \o/
[22:37] <pitti> mario_limonciell: astonishing that fgrlx just worked, I didn't test it at all
[22:37] <tseliot> :-)
[22:37] <tseliot> ﻿pitti: having only 1 driver helps
[22:38] <mario_limonciell> pitti, well i'm sure little things will pop up here and there, especially when the driver is functional with the rest of the ecosystem here
[22:38] <pitti> mario_limonciell: oh, absolutely; also, there's still a ton of things on my TODO list already
[22:38] <pitti> mario_limonciell: the current progress bar, as well as apt-get calling is horrible, and there are quite a lot of other bugs
[22:38] <pitti> my aim today was to get *something* working for a3
[22:39] <tseliot> ﻿mario_limonciell: we can't complain since your driver and 2 out of 4 drivers of mine don't work ;)
[22:41] <mario_limonciell> tseliot, well the nice thing about the way this is architected though; in the event that nvidia doesn't rev their driver by the time intrepid goes live (which would be very unfortunate), then these can easily be added into intrepid-updates via an SRU
[22:41] <mario_limonciell> would just need to zero out the modaliases file for release, and then the SRU'ed one would contain valid modaliases
[22:42] <pitti> uploadedkthxgoodnight!
[22:43] <tseliot> ﻿mario_limonciell: that wouldn't be necessary since those 2 drivers are legacy drivers and I doubt that their lists of pci-ids will change anytime soon
[22:43] <tseliot> an SRU would be enough
[22:43] <mario_limonciell> tseliot, yeah but you don't want to have a broken driver offered in the first place
[22:43] <mario_limonciell> so that's why you would want those modaliases zero'ed out until it was fixed
[22:44] <tseliot> ﻿mario_limonciell: ah, I misread your message
[22:44] <mario_limonciell> tseliot, and same thing goes for fglrx too
[22:45] <tseliot> ﻿mario_limonciell: let's wait and see. There's still time
[22:45] <tseliot> good night everybody
[22:46] <mario_limonciell> night tseliot
[22:46] <tseliot> it's 23:46 here
[22:46] <tseliot> night
[22:52] <soren> slangasek: What is "the pervasive usplash problem" actually? I haven't really followed that.
[22:52] <slangasek> soren: usplash was pervasively broken because of a theme incompatibility, now it's not
[22:52] <soren> Oh.
[22:52] <slangasek> (it may still be broken for other reasons, We Shall See)
[22:54] <soren> Oh, so "disabled for respin" just means that spinning them was(/is) deferred for a bit and not completely cancelled for this alpha release then?
[22:59] <jdstrand> hmm... php5 in intrepid won't build in my intrepid schroot
[22:59] <slangasek> ok, who broke language-support-writing-en / myspell-en-au?
[23:00] <jdstrand> configure: error: cannot run /bin/bash ../config.sub
[23:00] <slangasek> sommer: https://code.launchpad.net/~vorlon/ubuntu-doc/ubuntu-intrepid for a few minor mergeable fixes
[23:03] <jdstrand> kees: would you mind doing a quick build of php5 in an intrepid schroot? ^^
[23:04] <slangasek> ArneGoetje: was there a milestone-critical reason for revving language-support-writing-en the day before during the freeze?  It's now uninstallable because myspell-en-au is in universe...
[23:06] <ArneGoetje> slangasek: pitti did that...
[23:06] <slangasek> pitti: gar
[23:06] <slangasek> pitti: you were asking me about shoving in jockey, when you should've been asking me about this :)
[23:07] <slangasek> well, it's just an override
[23:07] <slangasek> so, fixed in the next pulse :/
[23:07] <slangasek> (assuming it doesn't conflict with something else \o/)
[23:07] <kees> jdstrand: giving it a shot, one sec
[23:08] <jdstrand> kees: thanks-- if it actually starts compiling stuff, you can kill it
[23:08] <kees> jdstrand: oh, does it fail out immediately?
[23:09] <jdstrand> kees: early in the configure phase, yeah
[23:09] <jdstrand> fakeroot debian/rules configure
[23:09] <jdstrand> kees: that's enough ^^
[23:11] <kees> hrm, my schroot is slightly behind, one sec
[23:11] <jdstrand> kees: that might be a good thing!
[23:11] <kirkland> mario_limonciell: hi, are you there?
[23:11] <mario_limonciell> hi kirkland
[23:11] <mario_limonciell> yup
[23:12] <kirkland> mario_limonciell: bluez-utils question for ya
[23:12] <kirkland>     - debian/rules:
[23:12] <kirkland>       * Turn off hidd, dund, and pand to try the plugins again.
[23:12] <kirkland>         If bug #191704 or #192043 crop up again, feel free to re-enable
[23:12] <kirkland>         these.
[23:12]  * jdstrand wonders if it's the recent autoconf update
[23:12] <kirkland> mario_limonciell: no more dund in Intrepid...  what are these plugins you speak of?
[23:13] <mario_limonciell> well that wasn't me that did that was it?
[23:13] <mario_limonciell> i had done a more recent merge however
[23:13] <kirkland> mario_limonciell: well, that's a not in your last merge
[23:13] <kirkland> mario_limonciell: perhaps you copied it from elsewhere
[23:13] <mario_limonciell> kirkland, let me check something.
[23:13] <kirkland> mario_limonciell: k
[23:13] <mario_limonciell> are you having trouble without the existance of dund then i take it right now?
[23:14] <mario_limonciell> kirkland, ah yeah i remember now.  so the deal was that upstream wanted to migrate people to the new plugin interface
[23:15] <mario_limonciell> so you are looking for the bluez-network package
[23:15]  * kirkland goes check
[23:17] <kirkland> mario_limonciell: okay, i've got that, but the only binary in that is /usr/lib/bluetooth/plugins/libnetwork.so
[23:17] <kirkland> mario_limonciell: what provides the dund functionality now?
[23:17] <kirkland> the documentation on this is sadly lacking
[23:17] <mario_limonciell> kirkland, so when you install that package, you should get a plugin interface from the bluez applet
[23:19] <kees> jdstrand: configure: error: cannot run /bin/bash ../config.sub
[23:19] <jdstrand> kees: ok, I'll try to track that down later-- thanks for confirming
[23:20] <kees> np
[23:21] <mario_limonciell> kirkland, let me see if i've got any intrepid boxen sitting around with bluetooth that i can see myself
[23:24] <kirkland> mario_limonciell: on completely a different note, we just got hit with a band of the hurricane winds/rains at my house :-)
[23:25] <mario_limonciell> kirkland, oh no.  no damage i hope right?
[23:25] <mario_limonciell> i didnt expect much effects  this far up north
[23:25] <kirkland> mario_limonciell: nah, nothing like that...  the sky just turned black :-)
[23:25] <kirkland> mario_limonciell: not hurricane force winds
[23:25] <mario_limonciell> ah okay good
[23:26] <kirkland> mario_limonciell: i suspect the bluetooth thing is probably just a matter of documenting the new methods
[23:27] <kirkland> mario_limonciell: there's a number of Ubuntu wiki (and 3rd party) webpages that give instructions on tethering and syncing and surfing the internet over bluetooth devices, all of which talk about dund/pand/hidd
[23:28] <mario_limonciell> kirkland, oh i can teach you how to do that on sprint without dund via bluetooth
[23:28] <mario_limonciell> but i think there is a genuine Bug here, because i installed bluez-network and don't see it in the list of services on my intrepid box with bluetooth
[23:29] <kirkland> mario_limonciell: nice... i'd like to know.  i've been using dund over sprint and several Treos since FC3 and Dapper
[23:29] <mario_limonciell> oh there we go, had to restart the bluetooth service
[23:29] <mario_limonciell> its now in my services
[23:29] <mario_limonciell> kirkland, -> /msg
[23:40] <pwnguin> can we just put a bounty on thunderbird and evolution to fix up text analysis and quoting to handle threading either way?
[23:41] <pwnguin> beacuse im a bit tired of the threads about the subject when there really isnt a community consensus