=== Ursinha is now known as Ursinha-afk === thumper is now known as thumper-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === thumper-afk is now known as thumper === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === m_conley is now known as m_conley_away === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [05:48] Good morning [05:48] bonjour pitti [05:48] bonjour didrocks === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [06:30] * didrocks reboots === geser_ is now known as geser [06:40] good morning === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [07:17] * xnox ponders if I ever wake up as early as pitti does.... [07:18] xnox: I was really late today :) [07:18] * xnox has no chance [07:18] pitti: well, german time is one hour ahead, but still.... [07:19] xnox: unless you plan on waking up at 4am your time, you have no chance ;) [07:19] hey stgraber! [07:20] hey didrocks [07:20] stgraber: quick question ;) [07:20] https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1163358 [07:20] Launchpad bug 1163358 in ust (Ubuntu) "Missing liblttng-ust-ctl.so.0" [Undecided,Fix released] [07:20] I synced ust to get the fix from debian to reship the .so file we were missing [07:21] but lttng (in lttng-tools package) is looking for liblttng-ust-ctl.so.0 and not liblttng-ust-ctl.so.1 [07:21] as it seems upstream broke the soname with the version we ship [07:21] stgraber: I tried a rebuild and it FTBFS, some missing API… [07:21] stgraber: I wonder if we shouldn't sync lttng-tools from debian, but I saw you did some ubuntu modification [07:21] so maybe you want to have a look first? [07:21] stgraber: i'ts easier to stay up until 4am for me ;-) [07:21] (upstart job and so on…) [07:22] stgraber: eh =) you are back on the other side of the ocean ;-) [07:22] didrocks: yeah, I'll take a quick look at lttng-tools. Technically it's one of those cases where I did the packaging in Ubuntu and it then got sync to Debian, so we shouldn't actually have a very large delta ;) [07:23] xnox: yep [07:23] stgraber: oh good news, thanks! [07:23] :) [07:23] xnox: the "right" side you mean, but all means ;-) [07:25] didrocks: oh, that's going to be fun... I didn't realise Jon had used the old source package name for the new lttng-tools... will make things a bit more complicated [07:26] (the upstream source is lttng-tools, our source is lttng-tools but Debian uses ltt-control as the source name) [07:27] stgraber: oh indeed, I didn't notice that debian PTS did the redirection :) [07:30] didrocks: so as far as I can tell, we don't have any actual delta between our lttng-tools and Debian's ltt-control. So I think it should be safe to sync [07:31] it's a rather big version bump though, but we already have the 2.1 version of the modules and ust, so it'd make sense to have that bump as the current stack is broken [07:31] stgraber: ok, so syncing and removing the old source? [07:31] yep [07:31] stgraber: yeah, as it's still broken, I think nobody can argue against bumping the version :) [07:31] stgraber: taking care of that? you can reuse the same bug report if you want :) [07:32] didrocks: yeah, I'll do that. I need to check whether I had ltt-control blacklisted when I landed lttng 2.0 and if so, unblacklist it [07:33] stgraber: excellent! [07:33] yep ;) [07:33] for unblacklisting [07:34] stgraber: I don't find it [07:35] yeah, apparently it's not on the blacklist, so I'm a bit confused as to why we didn't auto-import that source [07:35] yeah, there is only an Oneiric one… === Ursinha-afk is now known as Ursinha [07:37] the changelog on the debian side doesn't seem to have anything weird… [07:38] didrocks: updated the bug report to become an FFe for a sync+removal. I now just need to wait for the first Europe-based release team member to come online and we should be able to sort that one out [07:38] * didrocks invokes Laney [07:38] (I could actually have asked you to update the report then do the approval myself, but oh well, we can probably wait an hour ;)) [07:38] stgraber: yeah ;) [07:39] hum, my invocation magic is broken it seems [07:39] * didrocks opens a bug ;) === VD is now known as Guest69275 [07:41] seb128: wow. you wake up so late. [07:41] good morning :) [07:41] desrt: he's quite early actually compared to other times :p [07:41] desrt: good morning! :) [07:41] desrt, hey, had a good flight? [07:41] pfft. and he calls himself german [07:41] well, I'm up for an hour [07:42] desrt: a shame, isn't it? [07:42] bonjour seb128 [07:42] ça va desrt [07:42] seb128: it sucked a bit (united is cramped) but it was OK [07:42] but I don't start IRC before being done with breakfast and emails [07:42] jetlag is already gone though [07:42] pitti, guten tag! [07:43] desrt: ah, also made the trip from Canada to somewhere in Europe this week? (I arrived in Switzerland on Tuesday) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [08:04] hello! === Ursinha is now known as Ursinha-afk [08:05] Laney, good morning [08:05] hey Laney ;) [08:05] * Laney runs [08:05] Laney: quick quick, stgraber wants to buy you a beer ;) [08:06] bug #1163358 [08:06] Launchpad bug 1163358 in ust (Ubuntu) "[FFe] Sync ltt-control and remove lttng-tools to fix broken lttng in 13.04" [Undecided,Triaged] https://launchpad.net/bugs/1163358 === Ursinha-afk is now known as Ursinha [08:07] so it says that the old one is broken, but not that anybody has tried the new one?! [08:08] Laney, while we are at beers for the release team, I'm sure Sweetshark will pay you one if you let libreoffice in ;-) [08:08] doing reviews shortly, no worries [08:08] stgraber: fixing your bug tasks btw ;) [08:09] didrocks: thanks [08:11] Laney: so the llttng stack is released as a set, with inter-dependencies, us having something that's over one major release behind clearly won't work and explain the current failure. If we sync from Debian, we'll get the exact same set of packages as Debian, which I assume will work. [08:11] Laney: if that fails too, I'll fix whatever the problem ends up being, but in any case, we want the new upstream version, so the sync will be the first step whether ti works or not [08:11] Sure, I just don't know why we need to assume when we could verify beforehand [08:12] even just to catch obvious fixable breakage without wasting one upload [08:20] fine, doing a copy-package to a PPA, one sec ;) === Ursinha is now known as Ursinha-afk [08:22] :) [08:23] not copying to a native PPA though because then it really wouldn't buy us anything vs copying straight to the archive ;) [08:28] Laney: built fine on amd64, still waiting for i386 === Ursinha-afk is now known as Ursinha [08:29] cool; an upgrade/smoke test would be enough for me === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [09:15] morning pitti. This cycle I've had virtually no time for translations, and I didn't keep up with the langpack schedule. I see there are some exports on https://translations.launchpad.net/ubuntu/raring/+language-packs so I assume you set them up while I was away (if so, thanks!). I'd like to update https://dev.launchpad.net/Translations/LanguagePackSchedule - if it was you who set it up, what times did you choose for the exports on the Launchpad side? [09:15] dpm: seb128, wgrant, and I coordinated that some weeks ago; the cronjobs on macquarie match now [09:16] dpm, hey [09:16] dpm, pitti: it would be nice if you guys could document what was needed to get the langpack exports to start [09:16] dpm: I think it's now Monday (precise), Wednesday (quantal), and Tue/Thu (raring) for the exports [09:16] it took 3 days of pinging random people to get it done and I'm not sure how it was done at the end [09:17] just that wgrant knew the magic === Ursinha-afk is now known as Ursinha [09:18] pitti, excellent. seb128, ok, will do it now. Basically the process was that I update https://dev.launchpad.net/Translations/LanguagePackSchedule and then I ping the Launchpad folks to update the cron job on their side. I'm more than happy to document that on that page, but I'm concerned that while the info will be there, it might not be too discoverable. Do you have any suggestions about where I could link that page to so that next time it's easier t [09:18] o find out that info? [09:19] dpm, I guess the issue was "finding who in the launchpad team knew what to dot" [09:19] only wgrant knew and it took some days to get down to find that he was the one knowing [09:19] the launchpad team shrinked over time... [09:20] dpm, do we really need them? could we document what they exactly so next team we just need #is to run the command or whatever [09:21] seb128, yeah, I know :/ We just really need someone with permissions to modify that cron job file pointed at the bottom of the wiki page. If someone at IS has got the permissions to update it (it's an internal LP branch, IIRC) and they can do it in a timely way, then I think that should be the way to go [09:23] seb128, pitti, I think setting up the langpack exports should be part of the process of opening up a new distro, so that it's not a disconnected task. What do you guys think? [09:23] +1 [09:23] dpm: that sounds good to me, yes [09:31] pitti, seb128, ok, I'll talk to the LP guys to make sure that's included. pitti, I've blocked today to catch up on translations: what's the current status of the raring langpacks? I see that they are enabled in http://macquarie.canonical.com/~langpack/crontab - are they being published every Wednesday, or are we in freeze? [09:32] dpm: we got an upload yesterday, and accepted it [09:32] dpm, question for you, while you are around ... is that normal that https://translations.launchpad.net/ubuntu/raring/+source/nautilus/+imports?field.filter_status=all&field.filter_extension=all is all empty? should the .po imported from normal uploads show there? [09:32] dpm: the idea is to keep them getting uploaded, and do a manual full export close to the release [09:33] pitti, yeah, that sounds good. I've just approved a bunch of new gnome-{mahjongg,calculator,mines} templates that will need a full export to appear on the langpacks. [09:33] seb128, let me have a look... [09:33] dpm, I'm trying to figure out why https://translations.launchpad.net/ubuntu/raring/+source/nautilus/+pots/nautilus/fr/869/+translate is not translated in launchpad where it's translated in the fr.po from the nautilus source we are uploading [09:34] dpm, I've some other strings in nautilus that are in the same case [09:35] let me investigate, that the imports queue is empty is weird indeed [09:35] dpm, thanks [09:35] dpm, build log is https://launchpadlibrarian.net/136270806/buildlog_ubuntu-raring-i386.nautilus_1%3A3.6.3-0ubuntu14_UPLOADING.txt.gz [09:35] if that's useful [09:36] yes, thanks [09:36] "pkgstriptranslations: preparing translation tarball nautilus_3.6.3-0ubuntu14_i386_translations.tar.gz...dpkg-distaddfile: warning: File::FcntlLock not available; using flock which is not NFS-safe [09:36] done" [09:37] I guess the warning is harmless [09:38] seb128, looking at https://translations.launchpad.net/ubuntu/raring/+source/nautilus tells me that the PO files are being imported from the vcs imports branch ("This source package is sharing translations with Nautilus main series. "). Do you if that imports branch is up to date? [09:38] * dpm looks at https://translations.launchpad.net/nautilus/main [09:38] dpm, I've no idea, let me check [09:38] https://code.launchpad.net/~vcs-imports/nautilus/master-git [09:39] dpm, shrug [09:39] that's wrong [09:39] we are not on GNOME 3.8 [09:39] but on 3.6 [09:39] tracking trunk is a recipe for fail there :-( [09:39] is that common practice for GNOME sources? [09:40] seems to be :-( [09:40] seb128, I think the issue was that LP only allowed importing trunk from git, not individual branches. I'm not sure if that limitation is still there [09:40] it is [09:41] we did that to have translations directly imported from upstream git, right? [09:41] yeah, so that they did not need to be imported through package uploads, and get sucked from the bzr imports instead [09:41] k [09:42] but if that does not work, I guess I'll need to disable it for nautilus and go back to package uploads for translation imports [09:42] the assumption is less true since we stopped tracking GNOME [09:42] dpm, that's going to be an issue for other components as well [09:42] we are on 3.8 for none of GNOME [09:43] bummer, more manual tracking :/ [09:43] it means that if any GNOME component changed strings in 3.6 to 3.8 we loose translations [09:43] fortunately, it does not seem to be much of an issue yet. I don't see many untranslated strings on my desktop [09:44] right, we got lucky [09:44] dpm, can you change nautilus ... and then do you need a new upload to import the po files? [09:45] seb128, let me check for how many templates we're tracking trunk first. We can disable message sharing for nautilus for a start. Do you have any nautilus upload queued up so that we can see if it imports the translations? [09:45] so yeah, we were thinking the same :) [09:45] dpm, I will do a nautilus upload, let me check what was pending for it [09:45] can you change the setting meanwhile? [09:45] dpm, thanks ;-) [09:46] seb128, sure, I'll need 5 minutes, and I'll ping you when done [09:53] seb128, ok, message sharing with nautilus trunk disabled. There doesn't seem to be too many gnome components we've got upstream sharing activated for, but I'll need some more time to look at the rest in more detail. For now, it should be good to go ahead with the nautilus upload so that we can see if the template and translations are imported in the queue [09:53] dpm, ok, thanks [09:54] I just ran out of disk space while trying to debdiff libreoffice [09:54] /o\ [09:56] :-( === Ursinha is now known as Ursinha-afk [09:56] the curse of SSDs [09:56] just pick goffice next time :P [09:56] probably don't need oneiric chroots any more === Ursinha-afk is now known as Ursinha === tkamppeter_ is now known as tkamppeter === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [10:28] pitti, btw, I think we can turn apport off for raring at this point [10:31] seb128: errors.u.c. is enough, or no more interesting crashes? [10:32] pitti, both, I think we got the "interesting" issues reported in launchpad and that we are not getting a lot of new/useful one, and e.u.c is good enough for most of the work [10:33] seb128: let's ask foundations and server guys [10:33] right; I should have asked on #ubuntu-devel (or release), sorry === Ursinha is now known as Ursinha-afk [10:38] * Laney accepts libeoffice [10:41] lol, http://www.independent.co.uk/news/world/middle-east/iranian-scientist-claims-to-have-invented-time-machine-that-can-predict-the-future-8568147.html === Ursinha-afk is now known as Ursinha [10:49] Laney, thanks [10:56] seb128: Woohoo! RB, notifications, indicator all have album art after removing the .local/share/rhythmbox folder, now a quick reboot and see if they appear in the dash too === MacSlow is now known as MacSlow|lunch [11:03] seb128: tantalisingly close, only the dash isn't displaying now, http://ubuntuone.com/6nkR0SFquDU4sSisvuO5h2 [11:04] oh and nautilus [11:05] though that might be a removed feature maybe [11:17] davmor2, hey, dunno about the dash, check with mhr3 maybe [11:17] nautilus got a bug reported this morning [11:18] seb128: awesome. It nice to see it in the notifications and rhythmbox at least :) [11:20] seb128, davmor2, regarding the Rhythmbox Dash scope, album art will appear after Rbox updates its xml db file. Which happens... when closing it. This is AFAIK the only way to connect a track to its album art with Rbox. === Ursinha is now known as Ursinha-afk [11:20] davidcalle: That could be an issue then [11:21] (the only way : when using Rbox XML db file as a source) [11:25] davidcalle: right I've just gone through all the albums and ensured their art displayed. I've now close RB and am rebooting for the dash to cache the changes [11:26] Yay now I have album art in the dash woohoo [11:27] seb128: so it looks like RB db only gets the art when a track is played so the dash now has album art too :) [11:32] davmor2, ok, that used to be this way === greyback is now known as greyback|lunch === MacSlow|lunch is now known as MacSlow [12:31] Hey all, I'm trying to add my own icons to a custom indicator. This is supposedly possible by using the icon-theme-path property. However, I only want to add 5 icons, not create a whole theme... I tried creating a theme that "Inherits" from another theme, but failed... Can anyone point me to some docs about this? === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [12:43] marga, hey, can't you just ship your icons in /usr/share/custom_indicator/hicolors/... and add that dir to the icondirs? [12:45] probably, I'm just working blindly here, since the docs I've found up to now aren't very helpful. [12:45] What do you mean by "add that dir to the icondirs"? === greyback|lunch is now known as greyback [12:54] marga, https://developer.gnome.org/gtk3/stable/GtkIconTheme.html#gtk-icon-theme-set-search-path [12:55] seb128, tnx === Ursinha-afk is now known as Ursinha [12:59] Seems to be working now, I'm not sure what I changed... [12:59] Anyway, I've noticed that under Unity, the icons are quite small, whereas under cinnamon the are too big... Is there any way I can control that? [13:12] oh wow [13:12] nss-myhostname is in main now? [13:12] awesomeness [13:13] is there really user changing their hostname? [13:13] * seb128 never did that to a machine [13:13] everyone i know names their laptop :) [13:14] anyway... i just talked to lennart and he agreed to add a feature to nss-myhostname that will make it actually useful: [13:14] resolving localhost <=> 127.0.0.1 [13:14] because now we can erase /etc/hosts [13:17] desrt: you mean localhost <=> ::1, 127.0.0.1 right? [13:18] yes. of course. [13:18] otherwise you're going to seriously break stuff on my laptop ;) [13:18] every time we delete a file in /etc i get very happy [13:18] desrt: you are insane, you know that, right? :) [13:20] desrt, hum, I named my laptop at installation, never felt the need to change the name after that [13:20] desrt: however if you want to kill /etc/hosts you'll need a bit more than localhost in nss-myhostname [13:20] desrt, most people I know don't even know their machine has a name I think [13:21] stgraber: what else? [13:21] stgraber: note: i only want to kill /etc/hosts in the default install [13:21] if people want to have their own /etc/hosts then we must still support this [13:21] seb128: apart from "that f***ing machine which breaks so often"? :-) [13:21] pitti, indeed ;-) [13:21] * desrt has no problem with files being in /etc -- they should just not be there in the default install [13:22] desrt: there are a bunch of ipv6 aliases you're supposed to have though we haven't been terribly consistent in putting those in /etc/hosts (I can't remember which of ubiquity or d-i do, but I believe one of the two is missed up) [13:22] desrt: http://paste.ubuntu.com/5698437/ [13:22] desrt: so you think NSS should have some sane defaults that include /etc/hostname? [13:22] pitti: yes. absolutely. [13:23] a laudable goal; it never really occurred to me why one needs to explicitly configure "localhost" to be ::1/127.0.0.1 [13:23] I figure a lot of things would break very badly if you change that [13:23] ya... [13:23] well [13:23] you can change it to 127.anything [13:23] on mine I even have *two* entries for ::1 [13:23] which is kinda neat [13:23] using 127.0.0.2 as your hostname IP is probably the sanest thing to do on any kind of machine like a laptop [13:24] or 127.0.1.1 or however various people like to do it [13:24] desrt: the stuff I copy-pasted is part of what netcfg writes when it creates /etc/hosts. I guess we have other things that create /etc/hosts and so causes the inconsistency... [13:24] ubiquity configured it as "127.0.1.1donald" here [13:24] ya [13:24] this is totally sane [13:24] pitti: you're supposed to. localhost and ip6-localhost === Ursinha is now known as Ursinha-afk [13:25] not that I've seen the ip6-* stuff used all that much [13:25] the other alternative is to update /etc/hosts every time you get a new dhcp lease... [13:25] which is kinda insane [13:25] although... nss-myhostname could probably do this [13:25] * desrt bugs lennart some more [13:26] isn't it redhat that does the whole hostname+/etc/hosts update whenever you get a DHCP lease? I remember seeing some systems doing that and really disliked it [13:26] as in, why would I let the network admin rename my machine? :) [13:30] stgraber: lennart says that if those things are supposed to be standardly available then he'll add them [13:31] and also: nss-myhostname already takes a local IP address as the IP for the hostname [13:31] and only uses 127.0.0.2 if nothing else is available [13:32] so.... win! [13:41] cyphermox: do you know an upstream compatible way (i. e. aside from adding to /e/n/i) to tell NM "don't touch this interface"? [13:41] pitti: nah [13:41] cyphermox: I was debugging why NM doesn't connect, and I think it's because NM shuts down the interface which has the AP [13:41] someone brought this up in a bug before [13:41] actually, YES! [13:41] in /etc/NetworkManager/NetworkManager.conf: [13:42] https://live.gnome.org/NetworkManager/SystemSettings has "unmanaged-devices" [13:42] ooh, wait [13:42] --config=/path/to/config.file [13:42] that's exactly what I need [13:42] I don't want to change the actual file in /etc/ [13:43] desrt (would ping jbicha but he's not around): can you point me to the FFe for libnss-myhostname? I just had a quick look and can find an MIR but not a matching FFe and that kind of last minute change definitely needs a FFe [13:45] seb128: ^ (are you aware of any FFe for libnss-myhostname?) [13:45] Laney: you too as you seem to like desktopy thing ;) === Ursinha-afk is now known as Ursinha [13:45] stgraber, bug #1162478 [13:45] Launchpad bug 1162478 in libnss-myhostname (Ubuntu) "[FFe] [MIR] libnss-myhostname" [Undecided,Fix released] https://launchpad.net/bugs/1162478 [13:45] stgraber, see the title [13:45] seb128: damn, I saw the report and missed the [FFe] bit [13:46] [FFe] [MIR] [13:46] seb128: right, so nobody approved it [13:46] seb128: I don't see a release team ack in there [13:46] indeed [13:46] ok, I'll give it a release team nack then [13:47] haha [13:47] stgraber, you think it's risky? [13:47] but I'm fine with that [13:47] it's a bit late to introduce features [13:48] seb128: yes, adding a default nss module to the desktop install two weeks before release is risky [13:48] seb128: especially if it potentially messes with what IP additional services may end up listening on [13:49] stgraber, ack, let me revert that upload (note that I'm not the one who did the upload) [13:49] (I'm not against myhostname but I want us to very carefully look at the impact before turning it on, and it's too late to do that now) [13:49] e.g I'm fixing it but I don't take the blame :p [13:49] seb128: sure, I wanted to ping jbicha but he's not around. Can you make sure to close LP:#1162478 in the upload? I'll deal with it when it reaches the queue [13:59] pitti: yeah, so you want the no-auto-default= line in your config file [13:59] cyphermox: ah, what does that do? I used this now: [13:59] f.write('[main]\nplugins=keyfile\n[keyfile]\nunmanaged-devices=mac:%s\n' % self.mac_ap) [14:00] well, that would work too [14:00] Laney: got the card. now the kernel is in my way... the crystalhd driver only registrers with the older hardware. probably just a one-liner to fix... === Ursinha is now known as Ursinha-afk [14:01] one-liner and figure out how to build that kernel driver without having to build 15 kernels on my netbook :-P [14:01] pitti: the other one is to avoid creating default automatic connections; you could use * to avoid NM enabling any new connected devices [14:01] cyphermox: it doesn't really say in the log, but it seems to work; at least it connects [14:01] great [14:01] cyphermox: ah, is that for connections or devices? [14:01] I think it only really says it when you start NM [14:02] no-auto-default is for devices, to not automatically make a DHCP connection for the device when it's detected [14:02] cyphermox: I did notice that my test still fails because it now immediately gets an active connection, even before I call self.nmclient.add_and_activate_connection() [14:02] unmanaged-devices will go one step further and avoid the device showing up, I think [14:02] cyphermox: i. e. it seems to immediately auto-connect to the AP [14:02] ok [14:03] cyphermox: I thought it would only do that for SSIDs it already saw before? [14:03] wifi should never be autoconnecting though, unless you already set up a connection for that AP before [14:03] cyphermox: right, that just made me wonder [14:03] it *has* to know the SSID already, with a connection file in /etc/NetworkManager/system-connections [14:03] right, but it doesn't [14:03] I explicitly remove them all in tearDown() [14:04] well, I'll have a closer look [14:05] hm, and it still logs stuff about the AP wlan interface, but it seems it ignores it enough to not interfere with hostapd === Ursinha-afk is now known as Ursinha [14:07] cyphermox: or perhaps I misunderstand the concept of NMActiveConnection [14:08] cyphermox: it seems I get one even if it didn't actually connect to that wifi yet? [14:08] it's impossible, there has to be a prior connection from somewhere [14:08] $ ls /etc/NetworkManager/system-connections/ [14:08] wifi *cannot* come up by itself [14:08] $ [14:08] hmm [14:08] cyphermox: oh, it does'nt [14:09] I believe you, just there has to be something else [14:09] cyphermox: but it creates an NMActiveConnection object and returns that in get_active_connections( [14:09] after setting up that conn, I get a second object there [14:09] stgraber: can you get me an RFC reference for those ip6- names? [14:09] which makes me believe the first one might be a "never connected" placeholder? [14:09] * pitti looks for some textual dump method [14:09] when i google those names i mostly find people having pasted their /etc/hosts file from ubuntu :) [14:10] pitti: I don't know [14:11] desrt: let me see if I can find some reference in the netcfg git [14:13] cyphermox: indeed: http://paste.ubuntu.com/5698574/ [14:13] cyphermox: "adding" means add_and_activate_connection() [14:13] didrocks: https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/1085169 <- could you forward this one to the appindicator guys, as it seems to be a regression against quantal on their part? [14:13] Launchpad bug 1085169 in indicator-appmenu (Ubuntu) "LibreOffice Menus Stop Working even with libreoffice>=1:3.6.2~rc2-0ubuntu4 and indicator-appmenu>=12.10.3-0ubuntu2.1" [Undecided,Confirmed] [14:14] pitti: ok [14:14] cyphermox: so the dummy one has nm_active_connection_get_specific_object () == NULL [14:14] pitti: sorry, I don't really understand what's going on there, and I'm very busy with hud atm [14:14] cyphermox: ok, sorry [14:14] I wish I could reach dcbw, he hasn't been on IRC for days and hasn't answered my mail [14:17] didrocks: whops wrong bug [14:18] desrt: tracked down the commit to http://anonscm.debian.org/gitweb/?p=d-i/netcfg.git;a=commitdiff;h=457c418d576957e6f2ba5f87612986455b18cf93 [14:21] didrocks: I was talking about this one: bug 1153350 [14:21] Launchpad bug 1153350 in indicator-appmenu (Ubuntu) "LibreOffice4 Global Menu Items Do Not Highlight on Mouse Hover" [High,Confirmed] https://launchpad.net/bugs/1153350 [14:22] cyphermox: mind poking the indicators team about it? ^ [14:22] stgraber: looks pretty arbitrary [14:23] stgraber: what's your opinion on localhost <=> ::1 [14:24] having ip6-localhost for ::1 seems very stupid imho [14:24] fwiw, fedora does something equally stupid and calls it localhost6 [14:25] lol [14:25] they actually have localhost6.localdomain6 [14:25] you know, just to be extra-sure [14:26] cyphermox: just one thing, could I ask you to add ubuntu-core-dev to ~network-manager? [14:27] desrt: localhost should always resolve to ::1 and 127.0.0.1. ip6-* should just be there as a convenience, I'm not sure anything actually relies on that but I'm still digging for the exact history [14:27] desrt: it was added to ifupdown to match a much older change in netbase so I'm trying to track down the reason for the netbase one ;) [14:28] so on my ubuntu machine now, localhost doesn't give ::1 [14:28] i have to ask for ip6-localhost for that [14:28] does v6 allow similar aliasing as we do with 127.0.1.1 ? [14:28] ogra_: no. it doesn't. [14:28] ah [14:28] * ogra_ is v6 ignorant up to now [14:28] you can't do ::2 for example [14:28] that's why nss-myhostname tries very hard _not_ to hand out a loopback address for the local hostname [14:29] ogra_: Telekom has handed out IPv6 addresses for quite a while now :) [14:29] yep [14:29] pitti, they broke landlines on the way I've been told :p [14:29] pitti, got yours fixed btw? ;-) [14:29] pitti, i know ... but i plan to move on from my 2M SDSL soon :) so i wont bother to set anything up just now ;) [14:29] seb128: yeah, by completely resetting the router [14:30] seb128: the technician gave up as well, he couldn't find any error on his side [14:30] seb128: so, strange sw hiccup in the router [14:30] good old times when those machines were only wired logic [14:31] * ogra_ still uses an ubuntu router :) i usually insist to only get a modem [14:31] yeah, there's an infinite combination of setting up telephony (redirecting, etc.) on their web UI, IP telephony and device assignment in the router, spreading these out over classic analog, ISDN (S0 bus), SIP, and wifi, and configuring your numbers in the actual handset === dednick is now known as dednick|lunch [14:32] first world problems :) [14:32] oh, right, i also dont have a landline ... only network [14:34] desrt: oh, interesting, so I guess it's my DNS server that's making "getent hosts localhost" return ::1 then... [14:36] stgraber: FWIW, I get "127.0.0.1 localhost.localdomain localhost" from that [14:36] stgraber: my /etc/hosts/ doesn't map ::1 to localhost [14:37] should it? [14:37] # The following lines are desirable for IPv6 capable hosts [14:37] ::1 ip6-localhost ip6-loopback [14:37] http://paste.ubuntu.com/5698637/ [14:37] you should have that in /etc/hosts [14:38] I do [14:38] but ip6-localhost != localhost [14:38] yeah [14:38] ask debian :) [14:38] i think that one is just inherited [14:42] davmor2, ok, fixed totem uploaded for the nautilus thumbnail issue === francisco is now known as Guest35830 [14:44] seb128: Cool I'm just filing some bugs currently, after I finish that I'll see if it has landed and try it out [14:50] pitti: right, so it's probably my dns server returning the ::1 then [14:51] hello all! can you help me? [14:52] after wubi extracted all info on hard disk it reboot computer but after reload and choosing "ubuntu" it stuck [14:53] after one more reload it loads grub . and nothing happens [14:53] ubuntu631, hi, try #ubuntu for user questions === dednick|lunch is now known as dednick [15:13] pitti: yeah, doing now [15:14] pitti: done [15:14] cyphermox: splendid, thanks [15:14] yeah, that's going to make some of the work easier [15:30] ricotz, hey [15:32] for the vala-0.18 packaging, i can't seem to get it to regenerate the gio-2.0.vapi properly from the corresponding gir which is in /usr/share/gir-1.0 [15:32] is there something special that needs to be done? [15:32] attente, hi, you can't just simply generate it from the gir [15:33] there are a lot of fixing (metadata) needed for it [15:33] i would recommend to use vala 0.20.x if you need an up2date gio binding [15:34] if i simply replace the vapi though, won't i get uncommitted source errors when packaging? [15:35] attente, what are you trying to do? === jhodapp is now known as jhodapp|lunch [15:37] the bindings are not built in vala build process, there are generated upstream occasionally [15:37] i'm trying to update /usr/share/vala-0.18/vapi/gio-2.0.vapi to add definitions from /usr/share/gir-1.0/Gio-2.0.gir which is provided by libgirepository1.0-dev [15:37] ricotz, so is the correct thing to do to add a debian/patches patch for this? [15:39] attente, kind of, yes [15:39] but vala 0.20 is the matching version for glib 2.36 [15:40] ricotz, thanks [15:41] vala 0.20.1 is in raring NEW btw [15:41] just need an archive admin to review it [15:43] seb128, good, this is better way to get up2date bindings ;) [15:43] attente, ^ [15:43] cyphermox: FYI, I solved the mystery -- that ActiveConnection object was for eth0 (which kvm sets up) [15:44] seb128, hi, is the valencia gedit plugin working for you? [15:46] ricotz, not sure, I don't do lot of vala and don't know how the plugin is supposed to work [15:47] ricotz, I tried before upload with shotwell, I opened a source, selected a method, pressed f12 and it did display a progress bar and opened a tab where the method was defined [15:47] that's the only basic testing I did [15:47] seb128, ok, i gave it a try and it fails to load in gedit 3.8 [15:48] seb128, ok [15:48] ah [15:48] works in 3.6 [15:48] nautilus 3.8 seems to be really unstable btw [15:48]