| zyga | xnox: ping | 00:12 |
|---|---|---|
| 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:13 |
| zyga | xnox: using that db, we can build 100% reliable c-n-f and rebulild it against new packages without much difficulty | 00:15 |
| zyga | xnox: http://screencloud.net/v/7uOD | 00:31 |
| saiarcot895 | Before merging a branch into Ubuntu universe, do I need to sign an agreement with Canoical? | 02:08 |
| RAOF | saiarcot895: No, but the question probably betrays a misunderstanding off how uploading to Ubuntu works. | 02:09 |
| RAOF | Let's see if we can sort that out... | 02:10 |
| 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:11 |
| 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:12 |
| ion | /usr/share/doc/lightdm/copyright doesn’t seem to mention Canonical. | 02:13 |
| maslen | Can someone succinctly explain the relationship between existing open-source projects that are integrated into Ubuntu and Ubuntu itself? | 04:34 |
| === jono is now known as Guest52708 | ||
| dholbach | good morning | 06:35 |
| pitti | Good morning | 07:06 |
| === amitk is now known as amitk-afk | ||
| zyga | good morning | 07:33 |
| 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:56 |
| dholbach | Sweetshark, ^ maybe you know what's going on there? | 07:57 |
| cousteau | oh, Sweetshark is here... good | 07:58 |
| cousteau | (looks away though) | 07:58 |
| cousteau | although my question is more related to why (1:4.6.3-1ubuntu5 >= 1:4.1.1) is false | 07:59 |
| 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:00 |
| 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) | 08:01 |
| === tkamppeter_ is now known as tkamppeter | ||
| 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:05 | |
| 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:06 |
| 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:07 |
| cousteau | now it's complaining about a totally different pkg... why did it mention libgcc1 before? | 08:08 |
| mitya57 | because libreoffice-core is unpacked but has unmet dependency | 08:09 |
| cousteau | ok, why isn't libreoffice-common getting updated to 1:4.0.2? | 08:10 |
| 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:11 |
| geser | which PPA is that? | 08:12 |
| 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:14 |
| mitya57 | I see there are 14 not upgraded packages, can you run "apt-get dist-upgrade" and see what happens? | 08:17 |
| Sweetshark | dholbach, cousteau: Hmm, I dont understand the issue either. | 09:06 |
| Sweetshark | dholbach: Im not aware of other reports wrt -core -> libgcc deps .... strange. | 09:07 |
| geser | it would be nice to know if cousteau could resolve this | 09:08 |
| 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:14 |
| 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:15 |
| cousteau | geser, not yet | 09:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| Sweetshark | cousteau: should be fixed http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commit;h=cbb64e23f4023b16d449d33ac94c75f0c7933fce | 09:24 |
| 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:28 |
| 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:29 |
| 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:30 |
| cousteau | I remember that yesterday I had a problem with upgrades, but I think it was just the broken dependency thing | 09:31 |
| cousteau | I hope this didn't have to do with a pre/post install config | 09:32 |
| 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:33 |
| cousteau | (using xubuntu, if that's relevant, but I guess it isn't) | 09:35 |
| Sweetshark | ricotz: ping? could you update the precise/quantal backports? | 09:36 |
| Sweetshark | ah, not here. | 09:36 |
| 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:37 |
| cousteau | geser, how can I know that? is there an apt-get update history or something? | 09:40 |
| geser | in that case try updating the package lists and see if your problem is gone (amd64 and i386 are both build now) | 09:41 |
| cousteau | I opened the update manager at approx 19:45+0200 (i.e. 17:45 Z) | 09:42 |
| cousteau | geser, I tried that and it didn't. I fixed it by running `sudo apt-get install -f` | 09:43 |
| geser | good that it's fixed now, but I don't understand what went wrong in the first place | 09:44 |
| cousteau | me neither | 09:44 |
| === sraue_ is now known as sraue | ||
| === doko_ is now known as doko | ||
| 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:49 |
| 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. | 09:51 |
| === security is now known as megha | ||
| geser | apt usually takes care of that marks such packages on hold during an upgrade till the dependencies are available | 09:52 |
| 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] | 09:59 |
| geser | ah, that might explain the "apt-get -f install" call to let dpkg finish the configure of some packages | 10:02 |
| cousteau | I haven't tried to open LibreOffice; I wouldn't know | 10:12 |
| 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:13 |
| 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:17 |
| cousteau | i.e. not in the ubuntu installer, but in the thing that builds packages and distributes them to ubuntu users | 10:18 |
| 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:19 |
| cousteau | so DEBIAN/control was incorrectly generated, or incorrectly read by apt-get? | 10:20 |
| geser | correctly generated but with the wrong data (error of the package maintainer) | 10:21 |
| Sweetshark | cousteau: incorrectly generated | 10:21 |
| cousteau | so a server-side problem | 10:28 |
| cousteau | i.e. "an ubuntu bug" where "ubuntu" is the package build system, not the ubuntu installer | 10:30 |
| === amitk-afk is now known as amitk | ||
| zyga | xnox: hi | 10:55 |
| zyga | xnox: I've sent an email to ubuntu-devel last night | 10:55 |
| === MacSlow is now known as MacSlow|lunch | ||
| 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:08 |
| 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 | 12:09 |
| === MacSlow|lunch is now known as MacSlow | ||
| 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:20 |
| tvoss | pitti, ping | 12:26 |
| pitti | hello tvoss | 12:26 |
| 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:27 |
| 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 | 12:28 |
| === _salem is now known as salem_ | ||
| 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:46 |
| 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:48 |
| doko | smb, please wait until -23ubuntu2 is available | 12:50 |
| smb | doko, Ah ok. | 12:51 |
| pitti | doko: mass-rejecting the langpacks, FYI | 12:51 |
| 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:52 |
| 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:53 |
| doko | pitti, I assume policykit-desktop-privileges is targeted for raring? | 12:56 |
| pitti | yes | 12:56 |
| pitti | BigWhale pointed out that inconsistency | 12:56 |
| pitti | it doesn't change the default install behaviour, though | 12:57 |
| smb | doko, Hm, maybe dumb question -23ubuntu2 or *what*? | 12:57 |
| doko | smb, https://launchpad.net/ubuntu/+source/gcc-4.7/4.7.2-23ubuntu2 | 12:58 |
| smb | Ah ok. I was confused by the dependency gcc package version | 13:01 |
| smb | Daviey, ^ I try to remember we probably need to kick the build again later... maybe next week... :) | 13:04 |
| Daviey | smb: super | 13:07 |
| doko | smb, will be finished in 1h | 13:11 |
| smb | doko, okok, maybe this week still. ;) | 13:12 |
| 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 :) | 13:13 |
| === ckpringle_ is now known as ckpringle | ||
| seb128 | pitti, ^ | 13:13 |
| 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 | 13:14 |
| === Pricey is now known as PriceChild | ||
| === PriceChild is now known as Pricey | ||
| xnox | ogra_: système.de.service.seb128 | 13:20 |
| ogra_ | oh, indeed, i forgot ... french now | 13:21 |
| 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:46 |
| pitti | seb128: (excusez-moi, j'ai été à une réunion | 13:47 |
| seb128 | pitti, il n'y a pas de problème | 13:47 |
| === ckpringle_ is now known as ckpringle | ||
| pitti | seb128: AFAICS it only calls is_package_system_locked | 13:48 |
| 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:49 |
| 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:50 |
| 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 | 13:51 |
| xnox | kapat: raring suport at > #ubuntu+1 | 14:08 |
| === padv is now known as dsflms | ||
| 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:24 |
| smb | doko, Hm, ok. Apparently something only working on 64bit... But at least a more helpful failure | 14:25 |
| barry | doko: any feedback on my email from last night? | 14:28 |
| doko | barry, on the bug report | 14:28 |
| barry | doko: thanks | 14:28 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| doko | barry, the python builds are still configued with --enable-fpectl. I don't think that makes any difference | 14:53 |
| barry | doko: ack. i'm inclined to just apply the hack and be done with it | 14:59 |
| === ckpringle_ is now known as ckpringle | ||
| zyga | xnox: ping | 16:25 |
| xnox | zyga: hola. | 16:26 |
| zyga | xnox: I got some progress since yesterday | 16:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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 | 16:32 |
| === deryck is now known as deryck[lunch] | ||
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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 | 16:37 |
| === francisco is now known as Guest49443 | ||
| === tvoss is now known as tvoss|dinner | ||
| 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:06 |
| 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:08 |
| 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:12 |
| 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:26 |
| 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 | 17:27 |
| === salem_ is now known as _salem | ||
| pitti | awe: why? that's set by cfg80211, not by the hw driver | 17:27 |
| 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:28 |
| 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 | 17:29 |
| === _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 | ||
| 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:04 |
| jtaylor | raring currently has git20130321, only ~two weeks old | 18:06 |
| jtaylor | (and I got an ffe for that when it when in before you ask) | 18:07 |
| 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 | 18:14 |
| === _salem is now known as salem_ | ||
| jtaylor | CheezeMonkey: you have the installer hanging on the second screen issue? | 18:26 |
| CheezeMonkey | jtaylor: yep | 18:27 |
| jtaylor | CheezeMonkey: which link? have that issue too :( | 18:27 |
| 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:28 |
| 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:29 |
| 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 :) | 18:30 |
| === 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 | ||
| 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:30 |
| jtaylor | *armhf | 22:31 |
| Laney | keep watching the buildd's history and see if it builds subsequent stuff correctly | 22:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!