=== asac_ is now known as asac
=== tkamppeter_ is now known as tkamppeter
[08:19] <hyperair> cyphermox: ping.
[08:20] <hyperair> cyphermox: it looks like networkmanager's somehow screwing up wpa adhoc connections.
[08:21] <hyperair> cyphermox: using ifupdown, the same configuration (based on what networkmanager says in syslog) provided in a wpa_supplicant.conf works.
[08:22] <hyperair> judging by iwlist output, it looks like networkmanager's slapping on an extra wep key.
[08:23] <hyperair> removing the wepkey on the machines suddenly allow them to connect, but iwlist wlan2 scan seems to show an unencrypted adhoc connection available.
[08:28]  * ejat pokes hyperair 
[08:28] <ejat> hyperair : in natty ? oneiric ?
[08:28] <ejat> or the latest built …
[08:28] <hyperair> ejat: natty.
[08:29] <hyperair> ejat: does it work for you?
[08:29] <hyperair> ejat: it seems that wpa on adhoc is a rather strange beast.
[08:29] <ejat> havent try adhoc wpa yet
[08:29] <hyperair> yeah well wpa for everything else appears to work, just not wpa adhoc.
[08:43] <ejat> owh .. file the bugs already ?
[08:48] <hyperair> ejat: there seem to be some bugs lying around
[08:48] <hyperair> without much attention paid to it
[08:49] <ejat> u mean .. got related bugs with it
[08:51] <hyperair> yeah
[08:51] <hyperair> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/322902 like this one
[08:51] <ubottu> Ubuntu bug 322902 in network-manager (Ubuntu) "incorrect encryption detected when logging on to WPA ad-hoc wireless network" [Medium,Confirmed]
[08:52] <hyperair> i think i'll file a new bug.
[08:52] <hyperair> and maybe test with oneiric's networkmanager
[10:51] <debfx> slangasek: the multiarch Qt causes some fallout
[10:52] <debfx> many projects use the QT_INSTALL_LIBS and QT_INSTALL_PLUGINS qmake variables
[10:54] <debfx> so now they use multiarch paths but the packages don't expect that so they FTBFS
[10:55] <debfx> KDE's FindQt4 script expects all Qt modules to live in the same path
[14:59] <sveinse> Can I override (replace) a faulty file from another package with update-alternatives?
[15:01] <sveinse> The /usr/share/initramfs-tools/hooks/plymouth on natty misbehaves, it needs files which are not present and the package doesn't depend on them. Nor do I want them, so I'd rather replace this file with my own for now
[15:03] <infinity> sveinse: dpkg-divert is what you want to replace random files and not have them updated on upgrade.
[15:03] <sveinse> infinity: Yes of course. Thanks
=== ArcadeDawg is now known as Arcademan
=== Arcademan is now known as ArcadeDawg
[17:05] <micahg> Laney: or directhex  bug 824858 could use sponsoring (mono upgrade broke)
[17:05] <ubottu> Launchpad bug 824858 in mono (Ubuntu) "package libmono-webbrowser4.0-cil (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/mono/4.0/Mono.WebBrowser.dll', which is also in package libmono-webbrowser0.5-cil 2.10.1-4ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/824858
=== berlinlogger is now known as ulmlogger
[17:06] <directhex> micahg, it's a known issue, fixed in 2.10.4-2 which was being tested by Laney last i checked
[17:07] <micahg> directhex: ah, I saw that version in Debian, but it seemed to be on the wrong package according to the changelog
[17:26] <Laney> micahg: it is on both
[17:27] <micahg> Laney: ah ,ok
[17:27] <Laney> 2.0 for upgrades from 2.6 releases, 4.0 for 2.10 ones
[17:30] <Laney> but cheers for the patch
[17:31] <Laney> you could dupe that bug to my sync request
[17:32] <Laney> infact /me does that
[17:38] <Laney> so, if someone has time to sync -2 from exp ;-) (#826226)
[17:58] <hyperair> syncpackage!
[17:59] <micahg> hyperair: that's frowned upon by the archive admins
[17:59] <hyperair> o noes.
[17:59] <micahg> unless it's a fakesync
[18:00] <hyperair> what were the issues?
[18:03] <micahg> I can't seem to find anything except e-mails about hard freezes, ISTR general usage frowned upon
[18:37] <slangasek> debfx: qt multiarch ftbfses - ok.  How do you think we should deal with this?  My preference would certainly be to push forward, converting all the reverse-dependencies to build for the multiarch path; have you quantified the set of affected packages?
[18:47] <debfx> slangasek: it's hard to identify the affected packages. I suspect most libraries that use qmake ftbfs
[19:03] <tumbleweed> hyperair, micahg: We documented it in the manpage. An archive-admin (can't remember who) told me on IRC that they didn't approve of it because the procedure was not idential to their tool, and in general they didn't think we should do round-trips through developer's machines for syncs.
[19:04] <tumbleweed> also, the sync button is due any day now ™
[19:13] <debfx> slangasek: are you aware that cmake stores absolute paths of the linked libraries in configs, e.g. /usr/share/qzeitgeist/cmake/QZeitgeistExport-noconfig.cmake from libqzeitgeist-dev?
[19:14] <slangasek> debfx: <sigh> is that "cmake stores", or "some libraries that use cmake store"?
[19:17] <debfx> slangasek: it seems to be a cmake feature that libraries can use
[19:19] <slangasek> well, it's not a feature that distro packages /should/ be using... just like they shouldn't be shipping .la files with hard-coded references to files from other -dev packages
[19:22] <slangasek> debfx: if there is a consensus among the Kubuntu team that qt4 multiarch support should be reverted, I'll go along with that; but I'm also willing to put in effort to fix these packages up, and much prefer that as an outcome
[19:34] <directhex> tumbleweed, it does a round-trip through my machine anyway, since generally i syncpackage things i dput to debian myself
[19:37] <slangasek> debfx: I count only 22 candidate packages which build-depend on qt4-qmake and ship files in /usr/lib; that seems manageable
[19:37] <slangasek> debfx: what was the package you ran into this on? (so I can confirm it's in my list)
[19:37] <tumbleweed> directhex: I know. I don't completly agree with their argument, but I understand the viewpoint, and respect their wishes
[19:39] <tumbleweed> directhex: syncpackage also doesn't modify any tarball / diff contents, unless it's fakesyncing
[19:42] <debfx> slangasek: that cmake feature generally is useful as it allows something like pkgconfig for cmake. though I'm not sure why it needs to save the absolute path of linked libs
[19:43] <slangasek> debfx: yeah, it's not like pkgconfig *because* it's hard-coding paths to unrelated libraries
[19:43] <debfx> slangasek: libqt4-dev depends on qt4-qmake so most packages won't explicitly depend on qt4-qmake
[19:43] <slangasek> debfx: ok, will check libqt4-dev also
[19:44] <slangasek> yeah, that's a little longer list
[19:45] <debfx> I know that these need to be converted: qtwebkit-source, qt-assistant-compat and qscintilla2
[19:59] <SpamapS> slangasek: are you familiar with the perl transition that went on earlier this cycle, or was that all cjwatson? collectd is FTBFS because it can't find libperl..
=== EyesIsMine is now known as Supernova
=== Supernova is now known as EyesIsMine
[20:00] <SpamapS> bug 796571
[20:01] <ubottu> Launchpad bug 796571 in collectd (Ubuntu) "ftbfs in oneiric (can't find libperl)" [High,Confirmed] https://launchpad.net/bugs/796571
[20:02] <debfx> slangasek: I guess the only way to identify the affected packages is to test build them
[20:07] <slangasek> debfx: libqt4-dev|qt4-qmake looks to give a bit over 300 candidates, but many of these are definitely false-positives (including the first package I picked from the list and tried to build, appmenu-qt).  So that's too many candidates for me to try to go through by hand, but I'm confident that the number of resulting build failures should still be manageable for the cycle and think we should just work them via the archive rebuild tests
[20:07] <slangasek> SpamapS: sorry, don't know anything about the perl transition details
[20:08] <debfx> slangasek: is there one scheduled soon?
[20:08] <slangasek> debfx: yes, doko is planning on starting it ASAP
[20:09] <slangasek> debfx: and there hasn't been any runtime breakage reported, right?
[20:10] <debfx> there is some runtime breakage but I think it can be fixed by rebuilding pykde4
[20:10] <slangasek> oh, what's broken there?
[20:11] <slangasek> akonadi also builds fine; so there are my first two test cases
[20:13] <debfx> bug #826321
[20:13] <ubottu> Launchpad bug 826321 in pykde4 (Ubuntu) "[Oneiric] the PyQt4.QtCore module is version 1 but the PyKDE4.kdeui module requires version -1" [Undecided,Confirmed] https://launchpad.net/bugs/826321
[20:13] <SpamapS> slangasek: alright I'll ping cjwatson about it
[20:14] <debfx> I'm not 100% sure it's caused by the multiarch Qt, the error message is somewhat obscure
[20:16] <debfx> appmenu-qt probably works fine because it doesn't have an install file (single binary package)
=== yofel_ is now known as yofel
[21:41] <slangasek> debfx: ah, amarok FTBFS, because the build system gets confused and tries to link against -lQt4::QtWebKit; maybe fixable by rebuilding qtwebkit-source?
[21:46] <debfx> slangasek: yeah, that's the next package that needs to be converted for multiarch since it's a main Qt module anyway
[21:48]  * slangasek nods
=== ximion2 is now known as ximion
=== ximion is now known as ximion2