=== 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 | ||
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" | 09:33 |
---|---|---|
=== tkamppeter__ is now known as tkamppeter | ||
ScottK | cyphermox: ^^^ didn't you just update that? | 11:57 |
=== freeflying_away is now known as freeflying | ||
=== freeflying is now known as freeflying_away | ||
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:10 |
ubottu | 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:10 |
int_ua | leaving now, feel free to confirm the bug on LP | 15:13 |
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:30 |
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:31 |
infinity | pitti: Lovely, thanks. | 15:32 |
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:33 |
infinity | Of a sort. | 15:34 |
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:35 |
infinity | pitti: You should treat /etc the same way you should on a proper UNIX system. It's for root's configuration. | 15:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
pitti | or almost all of /etc/dbus-1/ | 15:44 |
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:45 |
cjwatson | i386 can have roseapple too unless any amd64 builds materialise. | 15:49 |
* cjwatson prefers nice short queues | 15:50 | |
=== CyclicFlux is now known as Guest98116 | ||
=== and`_ is now known as and` | ||
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:14 |
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:32 |
FliesLikeABrick | said more concisely: who maintains the official ubuntu torrents/trackers? | 18:33 |
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 | 18:42 |
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:34 |
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:42 |
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:43 |
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:47 |
cjwatson | c_korn: If it's i386-only, Architecture: i386 is fine. I wouldn't set Multi-Arch | 20:50 |
cjwatson | c_korn: Alternatively, you might look at how skype is packaged in partner | 20:51 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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? | 20:59 |
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:00 |
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:01 |
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:03 |
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:04 | |
c_korn | btw, is it /usr/lib/${DEB_HOST_MULTIARCH}/games now ? | 21:08 |
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:11 |
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:13 |
infinity | c_korn: Are you sure that you can't just get away with the cwd being the data dir? | 21:15 |
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:16 |
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:17 |
c_korn | yeah, if I had the source I would fix it like that | 21:18 |
c_korn | infinity, cjwatson: thanks for your help. the whole M-A is more clear to me know. I will read the spec. | 21:33 |
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:26 |
noobster | it doesn't crash te whole machine cause I can ssh into the box but can not run df, ls or du | 22:28 |
noobster | here is the syslog error... http://pastebin.com/upF3TCHd | 22:44 |
noobster | 3.2.0-54-generic x64 | 22:44 |
xnox | ev: can I build whoopsie without valgrind? | 23:17 |
=== freeflying_away is now known as freeflying |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!