=== freeflying is now known as freeflying_away === sam113101 is now known as sam113101_afk === sam113101_afk is now known as sam113101 === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [09:33] i just installed kubuntu 13.10, and I can't connect to any network device: network manager applet fails with "IP configuration was unavailable" === tkamppeter__ is now known as tkamppeter [11:57] cyphermox: ^^^ didn't you just update that? === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away [15:10] Can someone quickly confirm that /etc/network/if-post-down.d/avahi-daemon is a symbolic link to `../if-up.d/avahi-daemon' in 13.04 current version? [15:10] https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1230056 [15:10] Ubuntu bug 1230056 in avahi (Ubuntu) "/etc/network/if-post-down.d/avahi-daemon is a symbolic link to `../if-up.d/avahi-daemon'" [Undecided,New] [15:13] leaving now, feel free to confirm the bug on LP [15:30] infinity: udev/hw patch> yeah, me too; see my concerns on the bug, but it seems we don't have a better solution ATM :/ [15:31] infinity: also, that's for guests, not the hypervisor [15:31] infinity: I built and tested final langpacks FYI; uploading now, recruited another amd64 builder to help out [15:32] pitti: Lovely, thanks. [15:33] infinity: uh, didn't actually expect you to be online at this time .. [15:33] pitti: I'm in London. [15:33] ah, release sprint, I take it [15:34] Of a sort. [15:35] ev, slangasek: I'm still not entirely sure how to work with /etc/ on phablet; my gut feeling is that we should declare /userdata the new /etc there, and store the flag file there (and have the upstart job or whoopsie check both /etc/ and /userdata) [15:35] ogra, stgraber: ^ would that be reasonable? [15:36] pitti: You should treat /etc the same way you should on a proper UNIX system. It's for root's configuration. [15:37] s/root/global/ (in the sense of "not per-user") [15:37] pitti: And since we have a readonly root, and no root configuration, whatever you're doing is either runtime configs (/var or some approximation) or user configs (/home or some approximation), both of which probably map to "userdata" in an Android layout. [15:37] but as we made it readonly, it doesn't really do that any more [15:38] infinity: /var is r/o as well, though (modulo some explicit exceptions) [15:38] pitti: No, /etc isn't for "global" configs even, as readonly root is perfectly valid at runtime on any UNIX system. Not sure when people decided this wasn't true. [15:38] i. e. /not-quite-var [15:38] pitti: So, any time someone says "we're storing runtime configs in /etc and now we can't", the real question here is "why were you?" [15:39] pitti: Pretty much only the packaging system should touch /etc (or root at a console, by hand), but never a runtime configuration thingee, in an ideal world. [15:39] infinity: I think especially files in /etc/default/ have a very good justification; how else would an admin change some behaviour on a global scope? (default keyboard, locale, whether or not to upload crash reports, timezone, whatnot) [15:39] (I realise we violate this all over the place) [15:40] I heavily disagree, but oh well, it's Sunday evening and I'm about to AFK again .. [15:40] there needs to be some place to put this kind of config, and that has been /etc/ in the past few decades [15:41] we now apparently want that to be something else, but the whole archive won't magically adjust to that :) [15:41] People faught hard in Debian for readonly /etc, even coming up with strange things like resolvconf (which we now ship by default). [15:42] Arguing that it should be readonly, except not when you want to write to it, doesn't quite work. :) [15:42] I'm not arguing that it should be r/o in the first place :) [15:42] True. But most of it is happily r/o-capable. [15:42] we shoudl eliminate all the crap in /etc/ which isn't configuration [15:43] infinity: that's just because a lot of stuff in there should never be there [15:43] Perhaps /etc/default should itself just be bindmounted elsewhere in an r/o-/etc config. [15:43] /etc/init.d, /etc/init/, /etc/hosts, and what not [15:44] or almost all of /etc/dbus-1/ [15:45] anyway, langpacks uploaded and all accepted, builders are busy [15:45] I'll move allspice back to amd64 duty tomorrow morning [15:45] good evening everyone! [15:49] i386 can have roseapple too unless any amd64 builds materialise. [15:50] * cjwatson prefers nice short queues === CyclicFlux is now known as Guest98116 === and`_ is now known as and` [18:14] hello, a question regarding multiarch. on my build server running 12.04.3 I try to build a package of a game with a precompiled i386 executable for ubuntu 13.10 (using a schroot). sbuild fails however: sbuild: warning: can't parse dependency libogg0:i386 . I have set multiarch-support as Pre-Depends. what am I doing wrong here? (sbuild version: 0.62.6-1ubuntu2) [18:32] hi all - http://ipv6.torrent.ubuntu.com/ the IPv6-only tracker for ubuntu seems to be broken, all of the torrent links yield 403/forbidden [18:32] who is the right person to report that to? [18:33] said more concisely: who maintains the official ubuntu torrents/trackers? [18:42] FliesLikeABrick: You probably want #canonical-sysadmin, though I wouldn't count on much activity there until Monday. [18:42] thanks infinity, will head over there tomorrow [20:34] c_korn: dependencies on *specific* foreign architectures aren't permitted by the multiarch spec (https://wiki.ubuntu.com/MultiarchSpec). You probably want to just build the package as a normal _i386.deb with plain libogg0 etc. dependencies (preferably generated by shlibdeps), and let users install it using multiarch [20:42] Hi all. I upgraded today from 13.04 to 13.10 and ran into the following issue: I have a simple opengl + freeglut3 program that compiles just fine, but at runtime yields: Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! [20:43] can anybody help me out with this please? it seems to be triggered by having glut linked [20:43] here's the output of strace: http://hq.scene.ro/strace.txt [20:43] and here's output from LD_DEBUG=all http://hq.scene.ro/ld_debug.txt [20:43] same program was running ok on 13.04. any clues on what can I do to fix this? [20:47] cjwatson: ok, so I change the Architecture from any to i386? or just let it fail to compile on amd64? do I need to set Multi-Arch ? [20:50] c_korn: If it's i386-only, Architecture: i386 is fine. I wouldn't set Multi-Arch [20:51] c_korn: Alternatively, you might look at how skype is packaged in partner [20:54] cjwatson: the skype package just has "Architecture: i386 amd64" and depends on skype-bin which has "Architecture: i386" and "Multi-Arch: foreign" [20:55] Right, that's the alternative approach [20:55] The i386-only executable bit is in skype-bin [20:55] I think that was mainly in order to support upgrades from pre-multiarch versions [20:56] so the (empty) skype package exists so you can just sudo apt-get install skype on amd64 without having to specify :i386 because it pulls skype-bin from i386 because of Multi-Arch: foreign? [20:56] apt-get install skype-bin would work without :i386 anyway, since it doesn't exist on amd64. [20:57] That layout was purely to support upgrades from series' where there used to be a skype:amd64 package. [20:57] hum, so just one i386 package without setting multi-arch should be enough for 13.10 ? [20:57] ah, ok [20:57] If you don't have to do that, then I think you can just have a single package with Architecture: i386 and you don't need to bother with M-A (unless you're expecting dependencies from other-arch packages on yours) [20:58] hum, I cannot imagine that another package has a dependency on a game [20:58] Though Multi-Arch: foreign isn't wrong as long as it exports only architecture-independent *interfaces* [20:59] (execing a binary counts as such, generally) [20:59] ah, so M-A: foreign is wrong for a library which has specific i386 and amd64 symbol files? [21:00] Libraries should be packaged to be MA:same or not MA at all. [21:00] hum, ok [21:00] And binaries where the expected result differs per arch can't be foreign. [21:00] https://wiki.debian.org/Multiarch/Implementation [21:01] infinity: Right, hence "generally" :) [21:01] But you're right to call out that case [21:01] Basically Architecture is about the implementation and Multi-Arch is about the interface [21:01] to oversimplify [21:03] thanks, bookmarked that site. [21:03] Anyhow, in the case of a game that builds on a single arch, foreign would be quite appropriate, on the off chance that someone else wanted to make a "all-the-cool-games" package that depended on it. [21:04] But if that seems unlikely to happen, no MA is fine too. :P [21:04] I'm all for the whole archive ending up multiarch-tagged at some point [21:04] * infinity nods. [21:08] btw, is it /usr/lib/${DEB_HOST_MULTIARCH}/games now ? [21:11] /usr/lib/${DEB_HOST_MULTIARCH}/games/ seems like an odd path. Aren't the executables normally in /usr/bin/games/ (which hasn't changed with multiarch)? [21:13] the executable needs to be in the same dir as its game data. so I cannot put it in /usr/games but place it in /usr/lib/... and make a symlink into /usr/share/games . then there is a script in /usr/games which just starts the exe (via symlink) in /usr/share [21:15] c_korn: Are you sure that you can't just get away with the cwd being the data dir? [21:16] hum, I can give it a try. but assuming it does not work. where should I put the binary ? [21:16] ie: have your /usr/games/bin/foogame wrapper do "cd /usr/share/games/foogame && /usr/bin/games/foogame.real" [21:16] If they have to live together, then /usr/lib/foogame seems reasonable for both data and game binary. [21:17] And then the wrapper that calls it. [21:17] Anyway: things that aren't Multi-Arch: same don't need to have $DEB_HOST_MULTIARCH in their paths, generally. [21:17] Since they by definition don't need to be coinstallable. [21:17] c_korn: I'm assumiing this is a binary blob you don't have source for? Cause if you have source, the answer is "fix it to look for its data in /usr/share". [21:18] yeah, if I had the source I would fix it like that [21:33] infinity, cjwatson: thanks for your help. the whole M-A is more clear to me know. I will read the spec. [22:26] Hi all! I am having a issue on a new install of 12.04 server x64 trying to mount a NFS mount from another 12.04 server x64. The mount in fstab mounts with no errors, but when I try to copy data onto it it freezes?? I know the nfs-server is running fine because I have a mount in ESXi5 for ISO and caqn copy a 700MB 12.04 iso to that datastore in 10 sec. Any thought on howto troubleshoot? [22:28] it doesn't crash te whole machine cause I can ssh into the box but can not run df, ls or du [22:44] here is the syslog error... http://pastebin.com/upF3TCHd [22:44] 3.2.0-54-generic x64 [23:17] ev: can I build whoopsie without valgrind? === freeflying_away is now known as freeflying