[00:12] <zyga> xnox: ping
[00:13] <zyga> xnox: I think I solved update-alternatives pretty much once and for all https://github.com/zyga/command-not-found/commit/2ee281a9750c1240c33af99b9ea4f3b84d6b44f1
[00:13] <zyga> xnox: I have a large database, I'll find a new home for it soon
[00:15] <zyga> xnox: using that db, we can build 100% reliable c-n-f and rebulild it against new packages without much difficulty
[00:31] <zyga> xnox: http://screencloud.net/v/7uOD
[02:08] <saiarcot895> Before merging a branch into Ubuntu universe, do I need to sign an agreement with Canoical?
[02:09] <RAOF> saiarcot895: No, but the question probably betrays a misunderstanding off how uploading to Ubuntu works.
[02:10] <RAOF> Let's see if we can sort that out...
[02:11] <RAOF> saiarcot895: Canonical requires a CLA for non-trivial patches to Canonical projects - these being things like Upstart, Unity, LightDM, etc.
[02:11] <RAOF> saiarcot895: Ubuntu is not a Canonical project :)
[02:11] <saiarcot895> ok
[02:12] <saiarcot895> I saw that link in a Ubuntu doc and worried if I was missing something
[02:12] <ion> Huh, LightDM is a Canonical project? Didn’t know that.
[02:12] <RAOF> ion: Yeah, it got adopted around... Precise?
[02:12] <RAOF> More generally, Ubuntu is quite a different thing to Upstart, LightDM, etc; Ubuntu is largely an aggregation of other projects, so it doesn't really make sense to ask for a contributor agreement.
[02:13] <ion> /usr/share/doc/lightdm/copyright doesn’t seem to mention Canonical.
[04:34] <maslen> Can someone succinctly explain the relationship between existing open-source projects that are integrated into Ubuntu and Ubuntu itself?
=== jono is now known as Guest52708
[06:35] <dholbach> good morning
[07:06] <pitti> Good morning
=== amitk is now known as amitk-afk
[07:33] <zyga> good morning
[07:56] <cousteau> I'm getting this error on update-manager due to a LibreOffice PPA:  libreoffice-core: Depends: libgcc1 (>= 1:4.1.1) but 1:4.6.3-1ubuntu5 is installed
[07:56] <cousteau> question:  isn't 1:4.6.3-1ubuntu5 >= 1:4.1.1 ?
[07:57] <dholbach> Sweetshark, ^ maybe you know what's going on there?
[07:58] <cousteau> oh, Sweetshark is here...  good
[07:58] <cousteau> (looks away though)
[07:59] <cousteau> although my question is more related to why (1:4.6.3-1ubuntu5 >= 1:4.1.1) is false
[08:00] <ogra_> is that a release upgrade ?
[08:00] <cousteau> a precise -> quantal?  no
[08:00] <ogra_> i.e. from one release to the next
[08:00] <ogra_> ah. k
[08:00] <cousteau> just regular automatic updates
[08:00] <cousteau> (from a PPA)
[08:01] <ogra_> i know we once had a function that kept PPAs at lower prio in such cases ... shouldnt happen in regular updates (and i dont think its still there anyway)
=== tkamppeter_ is now known as tkamppeter
[08:05] <geser> cousteau: does it happen too when you try to upgrade with apt-get?
[08:05]  * zyga updated his update-alternatives scan to 25% of the archive https://github.com/zyga/ubuntu-update-alternatives-data/blob/master/update-alternatives-db.ini
[08:06] <cousteau> apt-get -s install -f didn't say anything weird...  let me try apt-get upgrade
[08:06] <cousteau> (it's apt-get upgrade, right?)
[08:07] <geser> yes
[08:07] <cousteau> apt-get -s upgrade -> You might want to run 'apt-get -f install' to correct these.  The following packages have unmet dependencies:  libreoffice-core : Depends:  libreoffice-common (> 1:4.0.2~rc1) but 1:4.0.1~rc2-0ubuntu1~precise1~ppa1 is installed
[08:08] <cousteau> now it's complaining about a totally different pkg...  why did it mention libgcc1 before?
[08:09] <mitya57> because libreoffice-core is unpacked but has unmet dependency
[08:10] <cousteau> ok, why isn't libreoffice-common getting updated to 1:4.0.2?
[08:11] <geser> try if "apt-get install libreoffice-core libreoffice-common" gives a better hint (might have to repeat it with additional packages till you see the final error)
[08:11] <mitya57> what does "apt-get install libreoffice-common" say for you?
[08:11] <cousteau> hmm, it's update-manager the one that doesn't let me install libreoffice-common...  let me see
[08:12] <geser> which PPA is that?
[08:14] <cousteau> apt-get -s install libreoffice-common  ->  [...] The following packages will be upgraded:  libreoffice-common   1 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.  12 not fully installed or removed.   Inst libreoffice-common [1:4.0.1~rc2-0ubuntu1~precise1~ppa1] (1:4.0.2~rc1-0ubuntu1~precise2 LibreOffice PPA:12.04/precise [all])  [...]
[08:17] <mitya57> I see there are 14 not upgraded packages, can you run "apt-get dist-upgrade" and see what happens?
[09:06] <Sweetshark> dholbach, cousteau: Hmm, I dont understand the issue either.
[09:07] <Sweetshark> dholbach: Im not aware of other reports wrt -core -> libgcc deps .... strange.
[09:08] <geser> it would be nice to know if cousteau could resolve this
[09:14] <Sweetshark> geser: yes, as seen on https://plus.google.com/u/0/101094190333184858950/posts/byfaUDmpYCn there is clearly demand for that update to be in raring.
[09:15] <Sweetshark> dholbach: ahh, thats in the precise ppa!
[09:15] <dholbach> I have no idea - I just thought I'd bring the two of you in touch :)
[09:17] <cousteau> geser, not yet
[09:18] <cousteau> maybe just installing libreoffice-common fixes the issue
[09:18] <cousteau> (and then marking it as auto installed...  how is that done in apt-get?)
[09:19] <geser> with "apt-mark"
[09:19] <ogra_> did you try dist-upgrade ?
[09:19] <cousteau> yup, apt-mark
[09:19] <ogra_> it should tell you about adding/removing
[09:19] <cousteau> I don't want to try anything that fixes the system until I find out the problem...  how would I be contributing if I just fix my system?
[09:19] <cousteau> (or am I the only one affected by this problem?)
[09:20] <ogra_> dist-upgrade will have a y/n question
[09:20] <ogra_> it never does anything automatically if it actually adds or removes
[09:20] <Sweetshark> dholbach, cousteau: precise is still at 4.0.2~rc1, which needed a dist-upgrade -- the 4.0.2~rc2 release in raring should have that fixed, backports for quantal/precise with hopefully show up soon ...
[09:21] <cousteau> apt-get -s dist-upgrade   ->  The following packages have unmet dependencies:   libreoffice-core : Depends: libreoffice-common (> 1:4.0.2~rc1) but 1:4.0.1~rc2-0ubuntu1~precise1~ppa1 is installed   libreoffice-emailmerge : Depends: libreoffice-common (>= 1:4.0.2~rc1) but 1:4.0.1~rc2-0ubuntu1~precise1~ppa1 is installed   You might want to run 'apt-get -f install' to correct these.
[09:22] <ogra_> theer you go
[09:22] <Sweetshark> cousteau: yep, should be fixed
[09:22] <cousteau> (on an unrelated note, I'm actually getting "You might want to run 'apt-get -f install' to correct these" BEFORE the list of packages to be fixed)
[09:22] <geser> did you try to install a deb with dpkg? I'm wondering why apt suggests to run "apt-get -f install"
[09:24] <Sweetshark> cousteau: should be fixed http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commit;h=cbb64e23f4023b16d449d33ac94c75f0c7933fce
[09:28] <cousteau> The problem seems to be that, for some reason, libreoffice-core 1:4.0.2 has been installed but libreoffice-common hasn't (still at 1:4.0.1).  This has broken apt-get, which will refuse to install libreoffice-common 4.0.2 because there are unmet dependencies in the system.
[09:29] <cousteau> Silly apt-get doesn't realize that the solution is precisely to install this package it refuses to install.  I guess I'll have to -f
[09:30] <geser> how did you manage to install this version and not the other packages from libreoffice as they get all build from the same source package
[09:30] <cousteau> ok, running `sudo apt-get install -f`; I guess that'll fix the problem.  (running it with -s said it would install/upgrade libreoffice-common)
[09:30] <cousteau> geser, no idea.  Aliens?
[09:31] <cousteau> I remember that yesterday I had a problem with upgrades, but I think it was just the broken dependency thing
[09:32] <cousteau> I hope this didn't have to do with a pre/post install config
[09:33] <geser> cousteau: which arch are you using? i386 or amd64? and which PPA is that?
[09:33] <cousteau> ok, apt-get install -f seems to have fixed the problem
[09:33] <cousteau> amd64,  http://ppa.launchpad.net/libreoffice/ppa/ubuntu precise main
[09:35] <cousteau> (using xubuntu, if that's relevant, but I guess it isn't)
[09:36] <Sweetshark> ricotz: ping? could you update the precise/quantal backports?
[09:36] <Sweetshark> ah, not here.
[09:37] <geser> cousteau: when did you last run "apt-get update"? you might have updated the Packages files in the time window where amd64 was finished building but not i386 (incl libreoffice-common)
[09:37] <geser> this would explain why you could update some libreoffice packages but not all
[09:40] <cousteau> geser, how can I know that?  is there an apt-get update history or something?
[09:41] <geser> in that case try updating the package lists and see if your problem is gone (amd64 and i386 are both build now)
[09:42] <cousteau> I opened the update manager at approx 19:45+0200 (i.e. 17:45 Z)
[09:43] <cousteau> geser, I tried that and it didn't.  I fixed it by running `sudo apt-get install -f`
[09:44] <geser> good that it's fixed now, but I don't understand what went wrong in the first place
[09:44] <cousteau> me neither
=== sraue_ is now known as sraue
=== doko_ is now known as doko
[09:49] <cousteau> geser, probably what you said.  -core 4.0.2 was updated before -common 4.0.2 was available, and installing -core 4.0.2 broke apt-get, so when -common was available it couldn't be installed
[09:49] <cousteau> or maybe -core 4.0.2 and -common 4.0.2 were made available at the same time but -core was installed before -common and that immediately broke -core
[09:51] <cousteau> libreoffice-core depends libreoffice-common (> 1:4.0.2~rc1), but libreoffice-common doesn't depend on libreoffice-core.  So none of this mess would have happened if the update for -core had been held until -common were available.
=== security is now known as megha
[09:52] <geser> apt usually takes care of that marks such packages on hold during an upgrade till the dependencies are available
[09:59] <Sweetshark> cousteau: i would assume you hit https://bugs.freedesktop.org/show_bug.cgi?id=62972 and did not notice
[09:59] <ubottu> Freedesktop bug 62972 in Libreoffice "Cannot upgrade from Ubuntu 12.04.2" [Major,Resolved: notourbug]
[10:02] <geser> ah, that might explain the "apt-get -f install" call to let dpkg finish the configure of some packages
[10:12] <cousteau> I haven't tried to open LibreOffice; I wouldn't know
[10:13] <cousteau> so, ubuntu bug or LO bug?
[10:13] <cousteau> actually, why do I care?  it's already fixed
[10:13] <cousteau> ...well, there's always the curiosity thing
[10:17] <geser> if you got hit by this bug then it's a packaging bug in the LO package (don't know if you count this as ubuntu bug or LO bug)
[10:17] <Sweetshark> cousteau: it was a ubuntu bug (well, actually a debian bug that we merged in ;) ) -- the contents of the mailmerge package got move to -core and making sure that the old -mailmerge and the new -core package are not installed at the same time was fumbled.
[10:17] <dbarth> xnox: ping? is there a problem with the package upload for thin client? can i do something to help?
[10:17] <cousteau> so it was a bug in the ubuntu build system?
[10:18] <cousteau> i.e. not in the ubuntu installer, but in the thing that builds packages and distributes them to ubuntu users
[10:19] <xnox> dbarth: no problems. the archive is frozen and it's pending review & accept.
[10:19] <dbarth> ah ok
[10:19] <Sweetshark> cousteau: not in the build system, in the package description -- the debian/control file to be exact: http://www.debian.org/doc/debian-policy/ch-controlfields.html
[10:19] <xnox> dbarth: we just have to wait =)
[10:20] <cousteau> so DEBIAN/control was incorrectly generated, or incorrectly read by apt-get?
[10:21] <geser> correctly generated but with the wrong data (error of the package maintainer)
[10:21] <Sweetshark> cousteau: incorrectly generated
[10:28] <cousteau> so a server-side problem
[10:30] <cousteau> i.e. "an ubuntu bug" where "ubuntu" is the package build system, not the ubuntu installer
=== amitk-afk is now known as amitk
[10:55] <zyga> xnox: hi
[10:55] <zyga> xnox: I've sent an email to ubuntu-devel last night
=== MacSlow is now known as MacSlow|lunch
[12:08] <doko> pitti, would it be ok to discard/hold the language pack uploads? the test rebuild should finish first, and afaiu, these will be re-uploaded next week anyway?
[12:09] <seb128> doko, it would be useful for translators to have those so they can verify what translations are incomplete or buggy
[12:09] <seb128> so they can fix things for the update next week
=== MacSlow|lunch is now known as MacSlow
[12:20] <pitti> doko: no problem from my side, Monday will be the next cronjob anyway
[12:20] <pitti> doko: but I thought infinity already mass-rejected them
[12:26] <tvoss> pitti, ping
[12:26] <pitti> hello tvoss
[12:27] <tvoss> hey pitti :) I'm looking into fanotify right now. Does it work in 13.04/12.10?
[12:27] <pitti> tvoss: I haven't used it in ages, but I don't see why it shouldn't work
[12:28] <tvoss> pitti, cool :) I was just curious and wanted to check it out, if file moving/renaming is delivered to userspace in its current version or not
=== _salem is now known as salem_
[12:46] <rbasak> distutils.sysconfig.get_python_lib(True, True) gives me /usr/lib/python2.7 in raring. But libpython2.7.a is in /usr/lib/python2.7/config-x86_64-linux-gnu. What's the general way of getting this latter path? I know python-config --ldflags will give me the right thing, but this particular acinclude.m4 isn't using it and I think it would be a more trivial patch if I could extract just the right path where libpython2.7.a can be found.
[12:48] <smb> doko, https://launchpad.net/ubuntu/+source/xen/4.2.1-0ubuntu2/+build/4469971 <-- Internal compiler error. I am currently trying a local sbuild so I could pull things off...
[12:50] <doko> smb, please wait until -23ubuntu2 is available
[12:51] <smb> doko, Ah ok.
[12:51] <pitti> doko: mass-rejecting the langpacks, FYI
[12:52] <doko> pitti, thanks!
[12:52] <pitti> doko: however, with the projected 8 days of ETA there will be new cronned uploads
[12:52] <doko> I know ...
[12:53] <pitti> if only we had some way of temporarily spawning more servers in the internet out there to help with mass rebuilds...
[12:53] <pitti> we could call this "sky"
[12:56] <doko> pitti, I assume policykit-desktop-privileges is targeted for raring?
[12:56] <pitti> yes
[12:56] <pitti> BigWhale pointed out that inconsistency
[12:57] <pitti> it doesn't change the default install behaviour, though
[12:57] <smb> doko, Hm, maybe dumb question -23ubuntu2 or *what*?
[12:58] <doko> smb, https://launchpad.net/ubuntu/+source/gcc-4.7/4.7.2-23ubuntu2
[13:01] <smb> Ah ok. I was confused by the dependency gcc package version
[13:04] <smb> Daviey, ^ I try to remember we probably need to kick the build again later... maybe next week... :)
[13:07] <Daviey> smb: super
[13:11] <doko> smb, will be finished in 1h
[13:12] <smb> doko, okok, maybe this week still. ;)
[13:13] <jdstrand> seb128: fyi, http://people.canonical.com/~jamie/archive-grep/seb128-com.ubuntu.SystemService.log
[13:13] <seb128> jdstrand, hey, happy friday!
[13:13] <seb128> jdstrand, thanks
[13:13] <jdstrand> seb128: hi! you too and you're welcome :)
=== ckpringle_ is now known as ckpringle
[13:13] <seb128> pitti, ^
[13:14] <ogra_> oh, do we rename the system service to be seb128.system.service ?
[13:14] <ogra_> cool !
[13:14] <seb128> lol
[13:14] <ogra_> :)
[13:14] <seb128> ogra_, with french strings included by default ;-)
[13:14] <ogra_> haha
[13:14] <seb128> pitti, so it seems it's only update-notifier to fix
=== Pricey is now known as PriceChild
=== PriceChild is now known as Pricey
[13:20] <xnox> ogra_: système.de.service.seb128
[13:21] <ogra_> oh, indeed, i forgot ... french now
[13:46] <rbasak> distutils.sysconfig.get_python_lib(True, True) gives me /usr/lib/python2.7 in raring. But libpython2.7.a is in /usr/lib/python2.7/config-x86_64-linux-gnu. What's the general way of getting this latter path? I know python-config --ldflags will give me the right thing, but this particular acinclude.m4 isn't using it and I think it would be a more trivial patch if I could extract just the right path where libpython2.7.a can be found.
[13:46] <pitti> seb128: alors qui semble très facile
[13:47] <pitti> seb128: (excusez-moi, j'ai été à une réunion
[13:47] <seb128> pitti, il n'y a pas de problème
=== ckpringle_ is now known as ckpringle
[13:48] <pitti> seb128: AFAICS it only calls is_package_system_locked
[13:49] <kapat> Hello, just upgraded to raring beta and X won't start. Ideas? where (and how) should I submit bug reports?
[13:49] <pitti> which is basically a set of lock file existence tests
[13:49] <seb128> pitti, should be easy to replace
[13:49] <pitti> so we should completely drop that and just test for those locks
[13:49] <seb128> right
[13:49] <pitti> and then, python daemons -= 1
[13:49] <seb128> the proxy thing is still annoying
[13:50] <seb128> I need to talk to cyphermox to see if there is a plan to get that done in nm
[13:50] <cyphermox> proxy?
[13:51] <cyphermox> upstream wants to integrate it, I had a WI but since it's not priority... and there has been some interest from someone to do the work on the ML
[14:08] <xnox> kapat: raring suport at > #ubuntu+1
=== padv is now known as dsflms
[14:24] <doko> smb: xen fails now correctly ;-p with:
[14:24] <doko> intr.c: In function 'vmx_intr_assist':
[14:24] <doko> intr.c:305:17: error: request for member 'arch' in something not a structure or union
[14:24] <doko> intr.c:306:17: error: request for member 'arch' in something not a structure or union
[14:24] <doko> intr.c:307:17: error: request for member 'arch' in something not a structure or union
[14:24] <doko> intr.c:308:17: error: request for member 'arch' in something not a structure or union
[14:24] <doko> make[8]: *** [intr.o] Error 1
[14:25] <smb> doko, Hm, ok. Apparently something only working on 64bit... But at least a more helpful failure
[14:28] <barry> doko: any feedback on my email from last night?
[14:28] <doko> barry, on the bug report
[14:28] <barry> doko: thanks
=== salem_ is now known as _salem
=== _salem is now known as salem_
[14:53] <doko> barry, the python builds are still configued with --enable-fpectl. I don't think that makes any difference
[14:59] <barry> doko: ack.  i'm inclined to just apply the hack and be done with it
=== ckpringle_ is now known as ckpringle
[16:25] <zyga> xnox: ping
[16:26] <xnox> zyga: hola.
[16:27] <zyga> xnox: I got some progress since yesterday
[16:28] <zyga> xnox: first, I solved the problem with flaky update-alternatives data, it's now almost perfect and the small percentage of mistakes are tagged and can be corrected (so far I have < 200 cases but after fixing one the system learns and can cascade the solution to similar packages)
[16:28] <zyga> xnox: I've also mirrored half of the archive and rewrote/improved the scanning tools
[16:28] <zyga> xnox: by Monday I should have a new, pratically perfect database for precise, quantal and raring
[16:29] <zyga> xnox: then we can issue an update to the source package with the new database
[16:29] <zyga> xnox: does that sound okay?
[16:29] <pitti> awe: hey Tony, how are you?
[16:30] <zyga> xnox: I've tweeted about the progress, there is a new project that holds the database and I've sent an email to ubuntu-devel
[16:30] <zyga> xnox: (sadly no response so far)
[16:30] <pitti> awe: I'm currently writing network tests, and stumbled over a CRDA problem that you might know about
[16:31] <xnox> zyga: yes. I can upload the updates to raring/quantal/precise.
[16:31] <zyga> xnox: great
[16:31] <zyga> xnox: the data is text and I can also produce some diffs so that we can do some level of validation
[16:31] <awe> pitti, hey
[16:31] <awe> tests are good
[16:32] <awe> as for crda, be ready for a world of confusion... ;)-
[16:32] <awe> what's troubling you right now?
[16:32] <awe> maybe do a quick mumble?
[16:32] <pitti> awe: so, b/g test cases work fine; for A I chose channel 36, as it shoudl be available in most parts of the world
[16:32] <awe> ok
=== deryck is now known as deryck[lunch]
[16:33] <pitti> awe: if I run my tests locally, they always work; but if I run them in a fresh KVM instance, they fail with "channel [0] (36) is disabled for use in AP mode, flags: 0x57"
[16:33] <pitti> awe: so my question is: do you know how we set the domain for devices? I know of /lib/udev/rules.d/40-crda.rules which is supposed to set it through that helper
[16:33] <awe> why are you running in a container?
[16:34] <pitti> awe: but /etc/default/crda has nothing set on my workstation either, so I suppose it uses something else to determine the domain?
[16:34] <awe> pitti, we actually don't set the domain for devices
[16:34] <pitti> awe: we want this as autopkgtest, don't we?
[16:34] <awe> the drivers handle it
[16:34] <pitti> awe: so I'm trying to understand why it works on my workstation but not in kvm
[16:34] <pitti> awe: I actually got it to work in kvm if I add a country_code=EU to hostapd's config
[16:34] <awe> pitti, I'm not that familiar with the autopkgtest framework....  but I do know that networking inside containers/vms is not trivial
[16:34] <pitti> but apparently that only works teh second time, so there's something async going on
[16:34] <awe> especially when you need to work with wifi drivers
[16:35] <pitti> awe: no worries, I got those parts covered
[16:35] <awe> pitti, ubuntu doesn't set a default regdomain
[16:35] <pitti> awe: I now have A/B/G networks, open and wpa2, and IPv4/6 coverage
[16:35] <awe> pitti, are you running against real drivers, or using the passthru code?
[16:35] <awe> ( ie. driver passthru )
[16:35] <pitti> awe: just mac80211_hwsim
[16:35] <awe> right
[16:36] <pitti> so real driver, but no real hw
[16:36] <awe> well, some might take issue with "real" driver
[16:36] <pitti> awe: but with the same hwsim driver it works on my workstation
[16:36] <awe> ie. real being non-sim
[16:37] <pitti> awe: ok, I guess I'll have to dissect that a little further then
[16:37] <pitti> awe: I just thought you might have some idea how that can happen
[16:37] <awe> can we do a quick mumble?
[16:37] <pitti> sure
=== francisco is now known as Guest49443
=== tvoss is now known as tvoss|dinner
[17:06] <pitti> awe: ok, apparently hwsim doesn't support setting crda; "sudo COUNTRY=DE crda" works on my workstation, but fails in kwm; I guess that depends on the loaded drivers
[17:08] <doko> pitti, seb128, didrocks: could somebody of you look at the rhythmbox ftbfs? https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4443117 all archs
[17:12] <seb128> doko, it's on my list, sorry I didn't go to it today, I might still manage to do that before calling it a day, otherwise will do on monday
[17:12] <doko> np
[17:26] <pitti> awe: ah, so "sudo iw reg get" and "sudo iw reg set EU" are the magic commands; http://wireless.kernel.org/en/users/Documentation/iw#Updating_your_regulatory_domain and http://wireless.kernel.org/en/developers/Regulatory are quite helpful
[17:27] <pitti> awe: that works very well now
[17:27] <pitti> awe: I'll also change the tests to look at "iw" instead of "iwconfig" to verify connection, etc. :)
[17:27] <pitti> so, good night everyone, enjoy your weekend
[17:27] <awe> yes, although they're only magic, when the driver supports the incantation!  ;D
=== salem_ is now known as _salem
[17:27] <pitti> awe: why? that's set by cfg80211, not by the hw driver
[17:28] <pitti> awe: or you mean it won't work for drivers which don't use the cfg80211 framework?
[17:28] <awe> yes, but cfg80211 has to talk to the driver at some point
[17:28] <awe> it's just the messenger
[17:28] <awe> ack
[17:28] <awe> ( re: drivers that don't use cfg80211 )
[17:28] <pitti> awe: I think what happens here is that hostapd asks the wireless stack (i. e. the equivalent of iw reg get) about the country
[17:29] <pitti> awe: I guess the hwsim kmod doesn't care, as it doesn't actually emit anything
[17:29] <awe> yea, definitely... wpa_suppl has similar code
[17:29] <pitti> anyway, seems I have all pieces together now \o/
[17:29] <awe> cool
[17:29] <awe> glad I could help
=== _salem is now known as salem_
=== mitya57 is now known as mitya57_
=== security is now known as megha
=== achernya_ is now known as achernya
=== deryck[lunch] is now known as deryck
=== salem_ is now known as _salem
[18:04] <doko> jtaylor, is there a FFe for scilab?
[18:04] <jtaylor> doko: its essentially translation update
[18:04] <jtaylor> the diff is only large as its a normal dist tarball instead of git archive
[18:04] <jtaylor> if you drop translations and the missing makefiles the diff is almost zero
[18:06] <jtaylor> raring currently has git20130321, only ~two weeks old
[18:07] <jtaylor> (and I got an ffe for that when it when in before you ask)
[18:14] <CheezeMonkey> Just to let you guys know, ubuntu finally installed after i unplugged two of my three harddrives, probably had something to do with the many partitions i have
[18:14] <CheezeMonkey> thanks for your help, especially xnox for the link
=== _salem is now known as salem_
[18:26] <jtaylor> CheezeMonkey: you have the installer hanging on the second screen issue?
[18:27] <CheezeMonkey> jtaylor: yep
[18:27] <jtaylor> CheezeMonkey: which link? have that issue too :(
[18:28] <jtaylor> did you unplug internal disks?
[18:28] <jtaylor> I tried unplugging my external ones with no success
[18:28] <CheezeMonkey> jtaylor: https://launchpad.net/bugs/1080701
[18:28] <ubottu> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed]
[18:29] <CheezeMonkey> For me, i have three internal harddrives. Two of them are used, with quite a few (probably excessive) partitioning.
[18:29] <jtaylor> I have many many partitions too
[18:29] <jtaylor> seems to be the common factor in this bug
[18:30] <CheezeMonkey> I took those out, and left the third smaller one inside, which had only two partitions (one being a swap partition for linux).
[18:30] <CheezeMonkey> then i tried the installer again, and it worked like a charm :)
=== Ursinha_ is now known as Ursinha
=== hallyn_ is now known as hallyn
=== superm1_ is now known as superm1
=== salem_ is now known as _salem
=== bschaefer_ is now known as bschaefer
[22:30] <jtaylor> hm there is something weird on the arm builders
[22:30] <jtaylor> scilab failed with a "stray \38" in a source file, the file is fine
[22:30] <jtaylor> I just retried it and it worked
[22:30] <jtaylor> how can that happen?
[22:31] <jtaylor> *armhf
[22:32] <Laney> keep watching the buildd's history and see if it builds subsequent stuff correctly