[12:37] <zerwas> What do you think about having the option to install the package ubuntu-restricted-extras? nearly every user will want to have the programs in it
[12:37] <zerwas> i mean, having the option at the installation of Ubuntu
[01:48] <sbalneav> Any core devs around who're willing to sponsor a debdiff for me, related to bug #134572
[01:48] <ubotu> Launchpad bug 134572 in nbd "Segfault" [Undecided,Fix committed]  https://launchpad.net/bugs/134572
[03:55] <xtknight> sbalneav, what debdiff do you mean?  this would be job of MOTUs/helpers but i dont see patch here?
[05:39] <fabbione> morning
[05:43] <sbalneav> Morning fabbione
[08:41] <siretart> moin
[08:42] <Hobbsee>  hiya siretart
[08:42] <siretart> asac: okay, I've now built an wpasupplicant 0.5.8 package (latest stable release), and it is working for me okay
[08:42] <siretart> asac: i.e. I see no regressions over 0.6.0, whereas I've uploaded a regression fix for that to unstable
[08:43] <siretart> huhu Hobbsee
[09:24] <kkkklee> hi,all
[09:29] <saispo> hi
[09:29] <saispo> BenC: ping ?
[10:13] <asac> siretart: ok wanna push to ppa?
[10:14] <asac> siretart: or let me know where i can fetch it ... so i can ask forum users to test if there are improvements/regressions over 0.6
[10:28] <siretart> asac: however you prefer
[10:28] <asac> siretart: you can decide ;)
[10:29] <seb128> siretart: hi, is somebody working actively on emacs22?
[10:30] <siretart> asac: http://siretart.tauware.de/upload-queue/
[10:30] <siretart> seb128: mwolson and me as backup/reviewer/sponsor. or do you mean at upstream?
[10:31] <seb128> siretart: ubuntu, I was wondering if bug #134308 is a packaging issue and if somebody is working on it
[10:31] <ubotu> Launchpad bug 134308 in emacs22 "python-mode does not work" [Undecided,New]  https://launchpad.net/bugs/134308
[10:32] <siretart> seb128: hmm. works for me
[10:32] <seb128> siretart: "call-interactively: Cannot open load file: python-mode"
[10:33] <siretart> seb128: do you have the package 'python-mode' installed?
[10:34] <seb128> siretart: no, it wants to install emacs21
[10:34] <seb128> "Depends: emacs21 | xemacs21-bin | emacs-snapshot, pymacs (>= 0.22-6)
[10:34] <seb128> "
[10:34] <siretart> ah, then it seems that python-mode needs to be adapted for emacs22
[10:34] <siretart> strange why it works for me, though.. hmm
[10:35] <seb128> siretart: do you have a local update you didn't upload? ;)
[10:35] <coNP> I guess emacs22 finds and installs it. Maybe you have emacs21 | emacs-snapshot installed as well
[10:35] <siretart> seb128: no, it seems that emacs22 hat its own python-mode builtin now. see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424973
[10:35] <ubotu> Debian bug 424973 in python-mode "python-mode: please support emacs22" [Normal,Open] 
[10:36] <siretart> and this sb-info error is something I've already had on my emacs21 installation at university. it is a bug somewhere else
[10:37] <siretart> it seems to me that it doesn't make sense to port the python-mode package to emacs22 if it has its own version of 'python-mode.el' builtin
[10:37] <seb128> ok
[10:37] <seb128> I had python-mode still configured
[10:37] <seb128> which means /etc/emacs/site-start.d/50python-mode.el installed
[10:37] <siretart> I wonder why you get then the error message 'call-interactively: Cannot open load file: python-mode'
[10:37] <seb128> without it the emacs22 version works
[10:38] <siretart> oh yummi. It doesn't check if it has been removed but not purged. *sigh*
[10:38] <siretart> seb128: do you actively use emacs for development? I thought you're rather a vim guy
[10:39] <seb128> urg, no I don't use vim, I use nano and emacs
[10:39] <seb128> and sometimes gedit ;)
[10:40] <siretart> ah :)
[10:40] <seb128> coNP: heh ;)
[10:44] <seb128> siretart: confirmed, if you remove python-mode and let it configured it breaks emacs22
[10:45] <siretart> seb128: ah, what I've expected. do you want to handle that or shall I do it later this week?
[10:45] <seb128> siretart: would be nice if you do
[10:45] <seb128> thanks
[10:47] <siretart> okay, I'm updating the bug
[10:49] <siretart> asac: as I mentioned before, there is a nasty regression in our 0.6.0-1 package, which has been fixed in 0.6.0-3. It is very likely to cause some of the problems we currently have in lp
[10:50] <asac> siretart: which ones?
[10:50] <siretart> asac: I'd suggest that we sync wpasupplicant_0.6.3-3 in any case, and can still decide if we want to downgrade to 0.5.8
[10:50] <asac> siretart: sure ... but what regressions?
[10:50] <siretart> asac: the regression is if you have zero lenght essid in your wpasupplicant config. this is usually used in roaming situations (like nm does)
[10:51] <asac> due to our patches? ... or does -3 contain prepatches?
[10:51] <siretart> wpasupplicant won't associate to any AP if you don't explicitly say which ESSID it should connect to. this is a clear regression to the 0.5 branch
[10:51] <siretart> asac: yes, as I said before, this regression has been fixed in 0.6.0-3, which I've uploaded to unstable yesterday
[10:52] <siretart> we currently don't have any patches in the ubuntu wpasupplicant. I'd prefer to keep it that way if possible
[10:52] <asac> is that only a problem for config file scenario?
[10:53] <siretart> it is a problem if you use zero length ssids for roaming
[10:53] <asac> siretart: you mean we don't have a patchsystem ... or do you mean we don't have more patches than debian has?
[10:53] <siretart> I'm not exactly sure if nm uses wpasupplicant this way
[10:54] <siretart> asac: I'm talking about this patch: http://svn.debian.org/wsvn/pkg-wpa/wpasupplicant/trunk/debian/patches/10_fix_non_wpa_zero_len_ssid.dpatch?op=file&rev=0&sc=0
[10:54] <asac> siretart: nm uses wpasupplicant through socket ... interface ... e.g. without configuration file
[10:54] <siretart> (included only in -3)
[10:56] <siretart> asac: again. depending on if nm is using this zero length essid roaming feature of wpasupplicant (which I think is likely), it might (or might not) explain some of the bugs we have
[10:57] <asac> siretart: whatelse is in upstream svn that we might want to cherry-pick?
[10:57] <asac> (or upstream git .. or whatever) :)
[10:57] <siretart> upstream has changed to git for the 0.6.x series
[10:58] <siretart> TBH, no idea. I didn't follow the commit mails lately.
[10:58] <asac> siretart: it definitly doesn't use zeor length ssid if you click on the network in applet ... but it might use it if you manually configure your network ... i would have to check that.
[10:58] <siretart> you can nowadays 'manually configure wpa'?!
[10:59] <asac> i think so
[10:59] <siretart> since when? I thought that button just disabled NM and brings gnome-system-tools back to live (which doesn't support wpa at all)
[11:00] <seb128> siretart: it should in gutsy
[11:00] <asac> siretart: just tested ... manual configuration allows to select wpa ...
[11:01] <siretart> ah. great news!
[11:01] <asac> siretart: probably not nm itself as you said
[11:01] <siretart> again, I'd suggest that we sync -3 in any case now, and continue deciding about downgrading to 0.5.8
[11:02] <asac> siretart: however for normal nm mode it doesn't use roaming without explicit ssid, unless you have never been connected maybe.
[11:02] <asac> siretart: sure ... you have upload rights?
[11:02] <siretart> err, yes. but this goes anyway via the archive admins, since it is a sync
[11:02] <siretart> read, via seb128 :)
[11:03] <asac> seb128: can you please sync?
[11:03] <siretart> asac: because there is still no gui in launchpad for syncs
[11:03] <asac> siretart: ... well but why not just upload :)
[11:03] <seb128> asac: what cases?
[11:03] <soren> siretart: No, but we could do it manually.
[11:03] <asac> seb128: wpasupplicant ... in case the auto-sync is disabled
[11:04] <asac> seb128: like now ... where is the difference from just me uploading the debian version ?
[11:04] <soren> siretart: Grab the version from Debian, generate a changes file with the proper distribution set, and upload. voila.
[11:04] <seb128> right, auto-sync are disabled during the freeze
[11:04] <siretart> soren: we could, but were will be beaten with a large stick by Mithrandir if we would do that
[11:04] <seb128> asac: you can't, the distro target is unstable and it'll not be accepted in gutsy
[11:04] <asac> seb128: oh right.
[11:04] <soren> siretart: Yes, because that's what the policy says now. I agree with asac that it's a bit silly.
[11:05] <siretart> seb128: you can change the target distribution using changestool(1) (found in the reprepro package)
[11:05] <seb128> starting messing by hand with .changes is a good way to screw something
[11:05] <soren> seb128: It's not really all that difficult to change. "dpkg-genchanges -Ddistribution=gutsy [...] "
[11:05] <asac> seb128: yeah ... can you push the button for wpasupplicant? or do you want a bug?
[11:05] <seb128> asac: will do the sync now
[11:05] <asac> seb128: thanks a lot :)
[11:05] <soren> seb128: We could even wrap it up in a nice script that does the right thing.
[11:06] <soren> seb128: Isn't that what the sync script does anyway?
[11:06] <soren> seb128: The one you (the archive admins) use?
[11:06] <siretart> soren: there is a nice script for that, but only available for the archive admins. I think there is little point to argue about this issue, since there spec for that is nowadays called 'NativeSourceSync'
[11:07] <seb128> soren: well, I would not like having everybody starting to modify .changes
[11:07] <soren> seb128: Right, hence the script. :)
[11:07] <siretart> the spec was there since the beginning of launchpad, and has changed name several times so far, AFAIK
[11:07] <seb128> with script or not
[11:07] <soren> siretart: link?
[11:08] <asac> seb128: well ... its you who gets the load ... even if its neglectable it still causes an interrupt in your current workflow :)
[11:08] <siretart> soren: https://blueprints.launchpad.net/soyuz/+spec/native-source-syncing
[11:08] <seb128> soren: the correct way would be to have a "sync this package" button on launchpad than anybody in the correct team could use
[11:08] <asac> seb128: if you say you like it then there is really no point to argue ;)
[11:08] <asac> seb128: well, but why not trust the people in the correct team to be able to use a script?
[11:09] <seb128> asac: you can't restrict the script usage to a team
[11:09] <asac> seb128: yes, but the upload would die in the upload queue if some motu uploads to main for example
[11:09] <siretart> this effectively limits the script usage to the correct persons
[11:09] <asac> seb128: or do you want more fine grained access-control?
[11:10] <seb128> no, people with upload rights would be ok I think
[11:10] <siretart> asac: nah, you could just put it to the devscripts package and let people use their own gpg keys for restricting uploads
[11:10] <seb128> well, nobody stop you to hack the .changes nowadays
[11:10] <asac> seb128: then all should be fine ... give use the script ;)
[11:10] <seb128> I've no strong opinion about it
[11:11] <asac> seb128: right ... but it appears that today it would be kind of technical high-jacking ;)
[11:11] <seb128> asac: I can't, the archive admin script needs connects to soyuz
[11:11] <asac> seb128: anyway :) ... as long as archive-admins can cope with sync requests its fine for me.
[11:11] <seb128> it does verification to know if there is Ubuntu changes, on the version, etc
[11:12] <asac> seb128: ok i see ... so it gives you a warning and asks you to confirm that you want to drop ubuntu changes when pressing sync button?
[11:12] <seb128> yes
[11:14] <seb128> asac: anyway, wpasupplicant synced
[11:16] <siretart> asac: how do you want to proceed with testing the 0.5.8 package? - use ppas? - call for testing on u-d@l.u.c?
[11:17] <Amaranth> if you go the PPA route wait until tomorrow so you can use the real one
[11:17] <asac> siretart: yes i want to ask people in forums as well ... there is already a thread about network-manager
[11:18] <asac> Amaranth: is it for sure that tomorrow things get for real?
[11:18] <Amaranth> no
[11:18] <Amaranth> it's a hope
[11:18] <asac> hehe
[11:19] <siretart> asac: cprov mentioned on the launchpad-users mailing list that he works on it to move it today
[11:19] <asac> siretart: ok cool ... maybe i will bug him later to confirm. better wait for real ppa if at all possible imo.
[11:20] <siretart> asac: in which team do we want to publish the package?
[11:20] <asac> siretart: in the meantime we can ping people with roaming issues in malone to see if things improved for them with new wpa
[11:20] <asac> siretart: no idea ... i thought about private archive ... either yours or mine
[11:20] <asac> siretart: unless we want to start a network-managerandfriends team :)
[11:21] <siretart> I haven't activated my ppa yet, and wanted to delay that as long as possible. I've noticed that I'm hitting my quota very fast otherwise
[11:21] <siretart> I thought about using the desktop-teams ppa (but I'm not an admin nor a member there)
[11:22] <siretart> or the ubuntu-core-dev's teams ppa
[12:11] <Tonio_> seb128: ping ?
[12:12] <Tonio_> hi there ;)
[12:12] <seb128> Tonio_: hi
[12:12] <Tonio_> seb128: hey, little question...
[12:12] <seb128> Tonio_: ping with context = better ;)
[12:12] <seb128> sure
[12:12] <Tonio_> seb128: how to you perform a "buildprep" equivalent when not using cdbs on a gnome package ?
[12:13] <Tonio_> seb128: and having a patch that touches makefile.am files
[12:13] <seb128> what do you call "buildprep"?
[12:13] <Tonio_> seb128: we use that with kde to apply patches, generate makefiles.in and unapply patches
[12:13] <Tonio_> instead of regenerating them during the build
[12:13] <seb128> hum?
[12:14] <Tonio_> seb128: do you have an equivalent for gnome or not ?
[12:14] <seb128> I'm not sure to understand what you want to do
[12:14] <Tonio_> seb128: I have a gnome app and a patch that touches a makfile.am file, and I'd like the makefile.in file to be generated according to the patched makefile.am
[12:15] <Tonio_> seb128: I wondered what is the good way to do that with gnome in your (for example) packages
[12:15] <Tonio_> seb128: we have a cdbs "buildprep" rule to do that for kde apps, which patches, regenerate files and unapply patches
[12:20] <Amaranth> you run automake and diff the two
[12:22] <seb128> as I replied in query we usually do an autotools patch
[12:24] <Tonio_> oki thanks ;)
[01:10] <sheskar> Why does the restricted-manager install firmware to /lib/firmware/$KERNELVERSION by default? I have a Broadcom 4311 wireless and after a kernel upgrade the connetion was always gone. bcm43xx-fwcutter installs the firmware to /lib/firmware and it always works with upgrades (now I don't use restriced-manager anymore).
[01:11] <sheskar> Wouldn't it be better if the restricted-manager just installed the firmware to /lib/firmware and leave it there for all kernels?
[01:22] <ion_> sheskar: ubuntu-bug -p restricted-manager
[03:42] <herzi> seb128: https://bugs.launchpad.net/ubuntu/+source/vte/+bug/89660
[03:42] <ubotu> Launchpad bug 89660 in vte "control-cursor-key regression in vim" [Low,Confirmed] 
[03:56] <soren> mathiaz: You already discussed https://bugs.launchpad.net/ubuntu/+source/samba/+bug/128548 a bit, right?
[03:56] <ubotu> Launchpad bug 128548 in samba "Enable net usershare?" [Wishlist,In progress] 
[03:56] <soren> mathiaz: What was the conclusion?
[03:57] <mathiaz> soren: we discussed that with seb128 and infinity a couple of days ago
[03:57] <mathiaz> soren: the first step was to enable it in samba
[03:57] <soren> Sure.
[03:57] <soren> And in user-setup, probably.
[03:57] <mathiaz> soren: and the second step was to add a new permission/role to the user and group management application
[03:57] <soren> mathiaz: Which would map to a group membership, surely?
[03:58] <mathiaz> soren: yes
[03:58] <soren> I'm not too hot on the smbshare group idea, actually.
[03:58] <mathiaz> soren: why ?
[03:59] <soren> Well, I think the nicest thing to do would be to provide this option to users without any furhter configuration.
[03:59] <soren> This requires adding a group to base-config (and user-setup).
[03:59] <soren> ...but it's not very nice to have a package specific group in there (smbshare is Samba-specific)
[03:59] <soren> ...so I'd rather have a "fileshare" group or something like that.
[04:00] <soren> I also think it's likely that the set of users you'd allow to use samba to share files is the same set of users you'd allow to share files with other protocols (webdav, http, whatever).
[04:00] <mathiaz> soren: I think we discussed that, and cjwatson_ said that adding more groups to base-config is not such a good idea
[04:01] <mathiaz> soren: ok. So you'd just change the name of the group.
[04:01] <soren> mathiaz: And I agree with that. That's why I want to avoid having to do it next time a new appliaction comes along that allows pretty much the same thing only with a different protocol or something.
[04:02] <soren> mathiaz: Naming it generically helps avoid that.
[04:03] <soren> We could go even further and add the missing "users" groups.
[04:03] <mathiaz> soren: we could. I think this should be discussed on ubuntu-devel.
[04:03] <soren> There's a bunch of different things we want to provide to all *actual* users, but not to all system users (not www-data, for instance).
[04:04] <soren> mathiaz: Agreed. I just wanted to know what the status of the discussion was.
[04:04] <mathiaz> soren: well IIRC, it was not a good idea to add more system groups
[04:04] <mathiaz> soren: as we're running out of space for them
[04:04] <mathiaz> soren: cjwatson was not too keen on adding another group.
[04:05] <soren> mathiaz: Ah, yes.
[04:05] <mathiaz> soren: that was the argument against adding a group to base-config.
[04:05] <soren> mathiaz: Debian has already added it.. Hm..
[04:06] <mathiaz> soren: are you talking about the users group or smbshare/fileshare group ?
[04:07] <soren> Hmm.... We *have* the users group. We just don't add users to it.
[04:07] <soren> Hm... That makes it a lot easier.
[04:07] <soren> mathiaz: Well, both, actually.
[04:07] <soren> mathiaz: I was contemplating allowing this to all users (human users, that is).
[04:08] <soren> mathiaz: ...so using the "users" group for the net usershare stuff.
[04:08] <mathiaz> soren: hum... users may be too general
[04:08] <soren> mathiaz: Possibly.
[04:09] <mathiaz> soren: if we follow your users idea, why not add all the privileges/roles from the user and group management applet to the users group ?
[04:10] <mathiaz> soren: we're adding the users to a couple of groups anyway by default
[04:10] <soren> Indeed.
[04:11] <soren> Well, in most cases, the only distinction you really need is "admin user"/"regular user"/"system user".
[04:11] <realist> root/wheel/luser - you mean?
[04:11] <soren> No.
[04:12] <soren> We don't use the root user for anything.
[04:12] <soren> ...and don't have a wheel group.
[04:12] <realist> Was an example
[04:12] <mathiaz> soren: well - there is no real difference between an admin user and regular user
[04:12] <soren> "user with sudo privileges (i.e. member of admin)"/"regular users"/"system users like nntp, bin, www-data, etc."
[04:12] <mathiaz> soren: an admin user is just an regular user that has a entry in the sudoers file.
[04:12] <realist> mathiaz: one's in sudoers - one isn't?
[04:13] <mjg59> No
[04:13] <soren> mathiaz: Sure there is. My girlfriend^Wwife has an account on my laptop, but she sure has heck can't sudo on it.
[04:13] <mathiaz> soren: from a user/group point of view I mean
[04:13] <mjg59> We don't add users to the sudoers file
[04:13] <mjg59> We add the admin group
[04:13] <xtknight> what's the status of this bug?  Bug 42321
[04:13] <ubotu> Launchpad bug 42321 in xrandr "xrandr reports invalid refresh rates for MergedFB setup" [Medium,Confirmed]  https://launchpad.net/bugs/42321
[04:14] <realist> mjg59: equivalent to wheel elsewhere
[04:14] <soren> Most of the groups we have are there to either limit what system daemons can fiddle with or to limit which sort of hardware you can fiddle with.
[04:14] <mjg59> realist: If there's weird some part of the world that puts the wheel group in sudoers, yes
[04:15] <realist> mjg59: plenty of people do
[04:15] <mjg59> But it's not the traditional meaning of wheel
[04:15] <realist> mjg59: which is?
[04:15] <mathiaz> soren: well. That's what I meant - which is that an admin user is just a regular user that is part of the admin group
[04:15] <mjg59> su was only executable by people in the wheel group
[04:16] <mathiaz> soren: it's just another role - the same way as a user would be allowed to share files or not.
[04:17] <soren> mathiaz: Well, yes. My point was more that (in this context) there are three kinds of users on the system: "users who should be able to break it"/"the other human users"/"the system users".
[04:17] <mathiaz> soren: ok. So what would you suggest ?
[04:18] <mathiaz> soren: we add a new group, fileshare ?
[04:18] <realist> mjg59: also root files had wheel gid
[04:18] <mathiaz> soren: how would this work for nfs sharing for example ?
[04:18] <soren> mathiaz: With regard to this particular samba issue, yes.
[04:18] <soren> mathiaz: It doesn't right now.
[04:18] <soren> mathiaz: A few months ago, it didn't work with Samba either :)
[04:19] <mathiaz> soren: could we use this group to implement the same kind of access control for nfs sharing ?
[04:19] <soren> mathiaz: At some point, someone might create a method for certain users to share stuff via nfs. At that point, we already have a group for that purpose.
[04:19] <mathiaz> soren: If we want to add a new group to the base-config, we'd better come up with some scenario about it.
[04:20] <mathiaz> soren: for nfs, which groups owns /etc/exports ?
[04:20] <soren> mathiaz: root, probably.
[04:21] <mathiaz> soren: so we could change the group of /etc/exports to fileshare ?
[04:21] <mathiaz> soren: and make it group-writable also
[04:22] <mathiaz> soren: can I standard user call exportfs to reload the shares ?
[04:22] <soren> mathiaz: Don't think so.
[04:23] <soren> mathiaz: I also don't like changing the group of /etc/exports.
[04:23] <mathiaz> soren: so how could the fileshare group be used to implement an access control to nfs sharing ?
[04:24] <soren> mathiaz: I don't know. NFS sharing was just an example.
[04:24] <soren> mathiaz: My point is this:
[04:25] <soren> mathiaz: Rather than adding a group that "is allowed to share files with samba by way of calling net usershare", I'd rather have a group that "is allowed to share files over the network in various ways".
[04:25] <soren> mathiaz: The point is: If there was a mechanism for nfs similar to "net usershare" for samba, I can't imagine you'd provide said option to a different set of users.
[04:26] <realist> Is a unix group really necessary for this though?
[04:26] <mathiaz> soren: ok. And you'd like to add this group to base-config ?
[04:26] <soren> realist: Yes.
[04:26] <soren> :)
[04:26] <mathiaz> realist: for samba - yes.
[04:26] <mathiaz> realist: that's how it's implemented in samba.
[04:26] <soren> mathiaz: Possibly, yes.
[04:27] <realist> It is? Since which version?
[04:27] <soren> mathiaz: I dislike forcing the user to mess about with group memberships directly.
[04:27] <soren> mathiaz: A possible solution is to have the first user added to this group by default. To do that, it needs to be added to base-passwd.
[04:28] <mathiaz> soren: yeah. That's why there is the 'user privilege' tab in the user and group management application.
[04:28] <soren> mathiaz: Another solution is to make use of the "users" group, since that actually is the most common level of granularity needed.
[04:28] <soren> mathiaz: Yes, I'd also like to avoid that. :) I just want this to work out of the box.
[04:29] <mathiaz> soren: seb128 said there is way to automatically do that. But I don't know how.
[04:30] <soren> mathiaz: Do what?
[04:31] <mathiaz> soren: add new users to groups
[04:31] <mathiaz> soren: or when a new user is created, he has a set of default privileges.
[04:33] <soren> Hmm...
[04:33] <soren> Dunno.
[04:34] <soren> adduser doesn't do it.
[04:36] <realist> I always get adduser and useradd confused, but one of them should have a -g switch
[04:36] <realist> Not sure about the default group settings though
[04:52] <soren> mathiaz: Will you write something clever to discuss this on the mailing list?
[04:53] <mathiaz> soren: I could. The other issue is that we're passed FF.
[04:53] <mathiaz> soren: So I'm not sure we could get it included anyway.
[04:55] <soren> mathiaz: Possibly not, but that gives us a lot of time to discuss it. :)
[04:56] <mathiaz> soren: we could register a spec for UDS and discuss it there.
[04:56] <soren> mathiaz: Sounds sensible.
[05:38] <tkamppeter> doko, Riddell, I have packaged a new s-c-p, see your mail.
[05:40] <doko> tkamppeter: will upload it today
[05:47] <tkamppeter> doko, thanks
[05:59] <phoenix7> i'm customizing ubuntu-usplash-theme package, is it neccessary to change usplash-theme-ubuntu.c especially Palette indexes section in the code?
[06:00] <phoenix7> ubuntu usplash theme is mix of nearly red,yellow,green colors and kubuntu is blue but i have lots of light green.
[06:01] <phoenix7> sorry, ubuntu-> red,yellow,orange
[06:02] <phoenix7> now my logo and text disappear well but progress baar is very ugly
[06:03] <saispo> BenC: ping ?
[06:06] <phoenix7> i have a light green usplash theme, how can i calculate values of section palette indexes in the usplash-theme-ubuntu-c file?
[06:07] <BenC> saispo: pong
[06:33] <saispo> BenC: can you say how can i fix the rate on my wifi card ?
[06:34] <saispo> i use bcm43xxxx but under gutsy it's 24mbits and not 54 mbits
[06:44] <pygi> goedson, goedson :)
[06:45] <goedson> Hi, pygi.
[06:45] <pygi> goedson, we need to talk :D
[06:53] <asac> siretart: what do you mean by nm doesn't detect you iwl driven interface?
[06:53] <asac> siretart: can you see/use it with iwconfig and friends?
[06:54] <saispo> no sound on gutsy tribe 5 :/
[06:55] <saispo> https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/131368
[06:55] <ubotu> Launchpad bug 131368 in linux-ubuntu-modules-2.6.22 "Dell 1420n audio not supported under Gutsy" [High,Triaged] 
[06:55] <saispo> will be fixed ?
[06:57] <siretart> asac: after I sent my post, I noticed that the device was named 'wlan0_renamed'..
[06:58] <asac> ouch
[06:58] <asac> hmmm ... but would it matter?
[06:58] <siretart> hm. iwlist says my 'wlan0_rename  No scan results
[06:58] <asac> i guess you run iwlist as root?
[06:58] <siretart> aah, as root I see networks
[06:59] <asac> yeah
[06:59] <asac> iwlist not as root doesn't scan ... just dumps the cache
[06:59] <siretart> this is strange, because with ipw3945, I didn't need priviledges
[06:59] <asac> well ... thats a driver issue then... afaik its official that it only actively scans when run as root
[06:59] <siretart> aha?
[06:59] <asac> siretart: though it might be that your running wpa/nm scans in background
[06:59] <siretart> thats... interesting
[06:59] <asac> so your cache is filled
[07:00] <siretart> no, no wpasupplicant running
[07:00] <siretart> and nm doesn't detect the card anyway
[07:00] <asac> siretart: look at man iwlist
[07:00] <siretart> anyway, need to leave now, will continue to investigate tomorrow
[07:00] <asac> its there :"Triggering scanning is a privileged operation (root only) and  normal  users  can  only  read left-over  scan  results ..."
[07:00] <infinity> siretart: He means that on ipw3945, your cache may have been filled, hence why you didn't think you needed root to scan.
[07:01] <siretart> infinity: this doesn't explain why iwlist as user doesn't show the cache contents with iwl, whereas ipw did
[07:01] <asac> siretart: i would like to fix that nm detects the card ... maybe it will just work ;) ... compared to ipw3945 which causes so much pain
[07:01] <infinity> siretart: because you have no cache contents, because nothing's been doing background scanning.
[07:01] <siretart> asac: kelmo also said that they closed a lot of bugs by switching to iwl
[07:01] <infinity> siretart: Which could be because NM doesn't detect your card, for instance.
[07:02] <asac> siretart: yeah ... all my hope is now on iwl ;)
[07:02] <asac> siretart: if you get wpasupplicant going chances are high that nm can do it too :)
[07:02] <siretart> hm. will continue research tomorrow. Cu tomorrow, guys!
[07:03] <asac> siretart: cu
[07:04] <mantiena-baltix> hi developers :)
[07:16] <mantiena-baltix> who is responsible for linux-restricted-modules ? there is very big memory usage because of mountiing restricted modules into RAM (tmpfs)
[07:17] <ogra> mantiena-baltix, you are not forced to install them :)
[07:17] <ion_> I dont like it either, but due to license reasons, i hear thats the only way to go. They do get swapped out when the memory is needed, though, so its not as if theyre there eating your RAM all the time.
[07:17] <ogra> (we dont install them by default in ltsp for example to save the 15M the volatile fs eats)
[07:17] <ogra> ion_, they eati it on boot
[07:17] <ogra> *eat
[07:17] <ion_> ogra: Yes.
[07:56] <mantiena-baltix> ogra, ion_ : lots of users can't boot from feisty LiveCD, because volatile modules eats about 34 MB RAM
[07:57] <mantiena-baltix> why we can't do mount --bind instead of mounting into tmpfs ?
[07:58] <mjg59> mantiena-baltix: --bind from where?
[07:59] <mjg59> You realise the volatile stuff is built on bootup, right?
[08:00] <mantiena-baltix> mjg59, yes, --bind can be used with symlinks too
[08:00] <mjg59> mantiena-baltix: I'm sorry, I don't understand. What do you want to be bind mounted?
[08:01] <mjg59> mantiena-baltix: The files in volatile simply don't exist before the system has booted
[08:03] <danimo> BenC_: hi! any idea what changes in 22-9 or 22-10 totally changed (and rendered useless) the alsa driver for my Intel HDA card (82801FB/FBM/FR/FW/FRW (ICH6 Family))?
[08:03] <BenC_> danimo: yes, and it should be fixed in lum today
[08:03] <mjg59> danimo: Known issue. Will be fixed in the next upload.
[08:04] <zul> maybe it should be added to the /topic not that anyone reads that anyways ;)
[08:05] <danimo> ok, cool :)
[08:05] <mantiena-baltix> mjg59, yea, it seems or you really don't understand me, or vice versa...  volatile modules are installed into /lib/linux-restricted-modules/2.6.xxx/ , right ?
[08:05] <bhale> zul: /topic should support <blink>
[08:05] <mjg59> mantiena-baltix: No, they're *built* in there
[08:05] <mjg59> Before they're built, they don't exist
[08:05] <zul> bhale: that would be annoying
[08:07] <ion_> You could make chanserv send a notice about reading the topic to people on join.
[08:08] <mantiena-baltix> mjg59, could you explain me  what means *built* in ?
[08:08] <mantiena-baltix> look at http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=linux-restricted-modules-2.6.22-10-386&version=gutsy&arch=i386&page=3&number=50
[08:08] <mjg59> mantiena-baltix: The files that end in .ko do not exist on the CD.
[08:09] <mantiena-baltix> AFAIK restricted modules are *installed* into /lib/linux-restricted-modules/2.6.xxx/
[08:09] <mjg59> mantiena-baltix: The .o files that are provided on the CD are passed to gcc and turned into a .ko
[08:09] <mantiena-baltix> oh
[08:09] <mjg59> The .ko is saved in the volatile directory
[08:10] <mantiena-baltix> ohhh
[08:10] <mantiena-baltix> and this is done during bootup, right ?
[08:10] <mantiena-baltix> I thought, that .ko are simply renamed .o files :)
[08:11] <mjg59> This is done during bootup, yes
[08:14] <mantiena-baltix> mjg59, so, why linux-restricted-modules-2.6.xxx packages can't provide .ko files ?
[08:14] <mjg59> Licensing issues
[08:14] <mantiena-baltix> fuck
[08:15] <mjg59> We tend not to do stupid things without having a reason to do so :)
[08:15] <mantiena-baltix> hehe
[08:16] <mantiena-baltix> I think we can always find better solution - as I see gutsy restricted modules eats more than 40 megabytes RAM and this cause not working LiveCD on systems with 256 RAM :(
[08:17] <ScottK> Gutsy live cd works fine for me a 256mb system that does not need lrm except for wireless and modem (i.e. not for video).
[08:17] <mjg59> Well, we could (a) not provide restricted-modules, (b) get the source code to them released, (c) relicense Linux to something that isn't under the GPL
[08:17] <mjg59> Actually, that's not entirely fair. We could (in most cases) only build the drivers if the hardware is present
[08:18] <mjg59> Which would break hotplugging, but that's only an issue for a minority of the modules
[08:18] <ion_> It wouldnt break hotplugging, if done right.
[08:21] <ion_> Something like this might work: read modalias lists from the .o files, write them to /etc/modprobe.d/aliases.lrm, add a hack that links the .ko file on demand when modprobing given module.
[08:23] <ion_> install nvidia /sbin/lrm-foobar build nvidia && /sbin/modprobe --ignore-install nvidia
[08:23] <ion_> Or something like that
[08:24] <mjg59> ion_: Sweet. You get to implement it :)
[08:25] <ion_> The fact that it takes like two hours to build l-r-m on this box somewhat discourages me from doing stuff with it. :-\
[08:27] <gicmo> ok, something is totally broken regarding tex on my system
[08:27] <gicmo> ;-(
[08:31] <mantiena-baltix> ScottK, maybe you are using  Gutsy on system, which has non-integrated video ?
[08:33] <mantiena-baltix> mjg59, I also think, that best solution is to build only these restricted .ko modules, which are really needed for real computer
[08:33] <ScottK> It's an old laptop with an old ati video module that's well supported with free drivers.
[08:33] <mathiaz> kylem: what's the status of the unison patch for apparmor ?
[08:34] <ScottK> mantiena-baltix: It's a Dell Latitude L400.
[08:36] <mantiena-baltix> hehe, try LiveCD on system with intel integrated video
[08:37] <superm1> Riddell, you here?
[08:37] <ScottK> mantiena-baltix: I've done that on a Intel 865 series motherboard and it worked fine.  Of course it had way more than 256mb ram.
[08:37] <ScottK> Gotta run.  Good luck.
[08:39] <gicmo> ok, is this gutsy's fault or what the heck do I do wrong when an example (moderncv) doesn't compile on a very much clean gutsy install ;-/
[08:44] <Riddell> superm1: yes
[08:45] <superm1> Riddell, the SRU procedures for motu were a bit vague, but i believe i followed them as expected from the wiki page earlier this past weekend.  I was hoping to get an archive admin to ack the SRUs sooner than later though because there is a time deadline upon the ones I uploaded
[08:45] <superm1> bugs 134726 and 134801
[08:45] <ubotu> Launchpad bug 134726 in mythtv "MythTV 0.20.2 SRU " [High,In progress]  https://launchpad.net/bugs/134726
[08:45] <ubotu> Launchpad bug 134801 in mythplugins "Mythplugins 0.20.2 SRU " [High,New]  https://launchpad.net/bugs/134801
[08:59] <Riddell> superm1: can you not backport the fix?
[08:59] <superm1> Riddell, unfortunately not.  There is an ABI change
[08:59] <superm1> involved with it
[09:02] <Riddell> superm1: why does there need to be an ABI change?
[09:02] <superm1> Riddell, the data is stored differently in the database
[09:02] <superm1> at least the guide data is.
[09:04] <Riddell> superm1: but a database change shouldn't cause an ABI change?
[09:05] <superm1> Riddell, other machines (frontend or backend) need to all be at that same ABI when reading from the database is my understanding.
[09:08] <Riddell> superm1: I'm not convinced it passes the SRU rules for minimal necessary changes, however it's ubuntu-sru you need to convince
[09:09] <superm1> Riddell, i already mailed the TB about that.  Let me grab a link to that post
[09:10] <superm1> Oh technical-board isn't a public mailing list is it.  Well i'll pastebin his email back to me then at least
[09:10] <superm1> http://paste.ubuntu-nl.org/35286/
[09:12] <Riddell> superm1: ok, but that's not an approval
[09:12] <saispo> can you say how can i fix the rate on my wifi card ?
[09:12] <superm1> Riddell, right.  So at this point, what should I do then?
[09:14] <Riddell> superm1: e-mail back tech board and ask for an approval of those bugs
[09:15] <Riddell> or pitti
[09:15] <superm1> Riddell, okay will do
[09:26] <wasabi> Hmm. What's the status of our amd64 32-bit compatibility stuff? What's it take to get something added to that? Would there be many complaints if I made the 64 bit version of Winbind include 32 bit pam libraries?
[09:28] <wasabi> Hmm. Interesting. I had thought we had some of pam 32 anyways... seems I was wrong.
[09:32] <keescook> Riddell: doesn't it need to pass motu-sru, not ubuntu-sru?
[09:33] <keescook> superm1: and the tech board request is for future exception, isn't it?
[09:34] <Riddell> keescook: right, yes
[09:35] <superm1> motu-sru isn't discussed anywhere on that wiki page though.
[09:35] <superm1> https://wiki.ubuntu.com/MOTU/SRU
[09:51] <keescook> Riddell: sounds like you just need to verify the SRU bug information and version details (since it's motu)
[10:25] <wasabi> So why do we use a tmpfs for restricted kernel modules?
[10:28] <ion_> wasabi: Distributing proprietary modules linked with Linux is a violation of the GPL. Thus, the .ko files cant be distributed. Apparently even having a postinst script build them and save them to a non-volatile media could be considered to be distribution. Or something like that.
[10:31] <wasabi> I'd find it amazing if a common Joe (Judge Joe) would find that to be in different in any fashion
[10:31] <wasabi> .
[10:32] <LaserJock> so the modules get linked when you boot? I don't quite get what actually happens
[10:36] <wasabi> Seems so.
[10:38] <davmor2> Dear devs I have noticed something strange with firefox.  I have installed firstly gnash but now flash, on my 64bit machine but firefox is still reporting that there is a plugin missing.  Flash is the missing plugin.  I have restarted the machine thinking it may of been a glitch but no.  still the same.  What info do you need or is this a known bug?
[11:00] <mneptok> davmor2: this is not a support channel. try "/join #ubuntu"
[11:04] <davmor2> mneptok: This is an issue with gutsy.  I was after info to make the bug I write as informative as possible.  But is now sorted thanks to pygi and galternatives.
[11:07] <agoliveira> davmor2: When you joined this channel there was a message like this: "Development of Ubuntu (not support, even with gutsy...)" So, it does not matter if it's related to gusty, this is for development only, sorry.
[11:10] <davmor2> understood.  But wasn't actually after support,  Just what info you needed in a bug report on the issue.
[11:13] <davmor2> I don't like to just put this doesn't work.
[12:30] <highvoltage> if jsgotangco pops up, remember to wish him happy birthday
[12:30] <highvoltage> (goodnigh)