[09:33] <rohan> i just installed kubuntu 13.10, and I can't connect to any network device: network manager applet fails with "IP configuration was unavailable"
[11:57] <ScottK> cyphermox: ^^^ didn't you just update that?
[15:10] <int_ua> 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] <int_ua> https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1230056
[15:13] <int_ua> leaving now, feel free to confirm the bug on LP
[15:30] <pitti> 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] <pitti> infinity: also, that's for guests, not the hypervisor
[15:31] <pitti> infinity: I built and tested final langpacks FYI; uploading now, recruited another amd64 builder to help out
[15:32] <infinity> pitti: Lovely, thanks.
[15:33] <pitti> infinity: uh, didn't actually expect you to be online at this time ..
[15:33] <infinity> pitti: I'm in London.
[15:33] <pitti> ah, release sprint, I take it
[15:34] <infinity> Of a sort.
[15:35] <pitti> 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] <pitti> ogra, stgraber: ^ would that be reasonable?
[15:36] <infinity> pitti: You should treat /etc the same way you should on a proper UNIX system.  It's for root's configuration.
[15:37] <pitti> s/root/global/ (in the sense of "not per-user")
[15:37] <infinity> 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] <pitti> but as we made it readonly, it doesn't really do that any more
[15:38] <pitti> infinity: /var is r/o as well, though (modulo some explicit exceptions)
[15:38] <infinity> 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] <pitti> i. e. /not-quite-var
[15:38] <infinity> 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] <infinity> 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] <pitti> 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] <infinity> (I realise we violate this all over the place)
[15:40] <pitti> I heavily disagree, but oh well, it's Sunday evening and I'm about to AFK again ..
[15:40] <pitti> there needs to be some place to put this kind of config, and that has been /etc/ in the past few decades
[15:41] <pitti> we now apparently want that to be something else, but the whole archive won't magically adjust to that :)
[15:41] <infinity> People faught hard in Debian for readonly /etc, even coming up with strange things like resolvconf (which we now ship by default).
[15:42] <infinity> Arguing that it should be readonly, except not when you want to write to it, doesn't quite work. :)
[15:42] <pitti> I'm not arguing that it should be r/o in the first place :)
[15:42] <infinity> True.  But most of it is happily r/o-capable.
[15:42] <pitti> we shoudl eliminate all the crap in /etc/ which isn't configuration
[15:43] <pitti> infinity: that's just because a lot of stuff in there should never be there
[15:43] <infinity> Perhaps /etc/default should itself just be bindmounted elsewhere in an r/o-/etc config.
[15:43] <pitti> /etc/init.d, /etc/init/, /etc/hosts, and what not
[15:44] <pitti> or almost all of /etc/dbus-1/
[15:45] <pitti> anyway, langpacks uploaded and all accepted, builders are busy
[15:45] <pitti> I'll move allspice back to amd64 duty tomorrow morning
[15:45] <pitti> good evening everyone!
[15:49] <cjwatson> i386 can have roseapple too unless any amd64 builds materialise.
[15:50]  * cjwatson prefers nice short queues
[18:14] <c_korn> 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] <FliesLikeABrick> 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] <FliesLikeABrick> who is the right person to report that to?
[18:33] <FliesLikeABrick> said more concisely: who maintains the official ubuntu torrents/trackers?
[18:42] <infinity> FliesLikeABrick: You probably want #canonical-sysadmin, though I wouldn't count on much activity there until Monday.
[18:42] <FliesLikeABrick> thanks infinity, will head over there tomorrow
[20:34] <cjwatson> 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] <benishor> 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] <benishor> can anybody help me out with this please? it seems to be triggered by having glut linked
[20:43] <benishor> here's the output of strace: http://hq.scene.ro/strace.txt
[20:43] <benishor> and here's output from LD_DEBUG=all http://hq.scene.ro/ld_debug.txt
[20:43] <benishor> same program was running ok on 13.04. any clues on what can I do to fix this?
[20:47] <c_korn> 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] <cjwatson> c_korn: If it's i386-only, Architecture: i386 is fine.  I wouldn't set Multi-Arch
[20:51] <cjwatson> c_korn: Alternatively, you might look at how skype is packaged in partner
[20:54] <c_korn> cjwatson: the skype package just has "Architecture: i386 amd64" and depends on skype-bin which has "Architecture: i386" and "Multi-Arch: foreign"
[20:55] <cjwatson> Right, that's the alternative approach
[20:55] <cjwatson> The i386-only executable bit is in skype-bin
[20:55] <cjwatson> I think that was mainly in order to support upgrades from pre-multiarch versions
[20:56] <c_korn> 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] <infinity> apt-get install skype-bin would work without :i386 anyway, since it doesn't exist on amd64.
[20:57] <infinity> That layout was purely to support upgrades from series' where there used to be a skype:amd64 package.
[20:57] <c_korn> hum, so just one i386 package without setting multi-arch should be enough for 13.10 ?
[20:57] <c_korn> ah, ok
[20:57] <cjwatson> 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] <c_korn> hum, I cannot imagine that another package has a dependency on a game
[20:58] <cjwatson> Though Multi-Arch: foreign isn't wrong as long as it exports only architecture-independent *interfaces*
[20:59] <cjwatson> (execing a binary counts as such, generally)
[20:59] <c_korn> ah, so M-A: foreign is wrong for a library which has specific i386 and amd64 symbol files?
[21:00] <infinity> Libraries should be packaged to be MA:same or not MA at all.
[21:00] <c_korn> hum, ok
[21:00] <infinity> And binaries where the expected result differs per arch can't be foreign.
[21:00] <cjwatson> https://wiki.debian.org/Multiarch/Implementation
[21:01] <cjwatson> infinity: Right, hence "generally" :)
[21:01] <cjwatson> But you're right to call out that case
[21:01] <cjwatson> Basically Architecture is about the implementation and Multi-Arch is about the interface
[21:01] <cjwatson> to oversimplify
[21:03] <c_korn> thanks, bookmarked that site.
[21:03] <infinity> 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] <infinity> But if that seems unlikely to happen, no MA is fine too. :P
[21:04] <cjwatson> I'm all for the whole archive ending up multiarch-tagged at some point
[21:04]  * infinity nods.
[21:08] <c_korn> btw, is it /usr/lib/${DEB_HOST_MULTIARCH}/games now ?
[21:11] <cjwatson> /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] <c_korn> 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] <infinity> c_korn: Are you sure that you can't just get away with the cwd being the data dir?
[21:16] <c_korn> hum, I can give it a try. but assuming it does not work. where should I put the binary ?
[21:16] <infinity> ie: have your /usr/games/bin/foogame wrapper do "cd /usr/share/games/foogame && /usr/bin/games/foogame.real"
[21:16] <infinity> If they have to live together, then /usr/lib/foogame seems reasonable for both data and game binary.
[21:17] <infinity> And then the wrapper that calls it.
[21:17] <cjwatson> Anyway: things that aren't Multi-Arch: same don't need to have $DEB_HOST_MULTIARCH in their paths, generally.
[21:17] <cjwatson> Since they by definition don't need to be coinstallable.
[21:17] <infinity> 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] <c_korn> yeah, if I had the source I would fix it like that
[21:33] <c_korn> infinity, cjwatson: thanks for your help. the whole M-A is more clear to me know. I will read the spec.
[22:26] <noobster> 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] <noobster> it doesn't crash te whole machine cause I can ssh into the box but can not run df, ls or du
[22:44] <noobster> here is the syslog error... http://pastebin.com/upF3TCHd
[22:44] <noobster> 3.2.0-54-generic x64
[23:17] <xnox> ev: can I build whoopsie without valgrind?