[12:07] <Keybuk> Kamion: ok, all given back
[12:08] <Keybuk> Evaso2: the basic problem with the VPN plugins is that there's no way to handle DNS for them
[12:09] <Evaso2> Keybuk: take a look here: http://www.flickr.com/photos/onlymee/161934943/
[12:09] <Keybuk> because they don't use DHCP, you'd have to spam over resolv.conf, and make sure it gets put back, etc.  and n-m has no infrastructure to do that
[12:09] <Keybuk> *shrug* that's a screenshot
[12:09] <Keybuk> not proof of any working code
[12:10] <Evaso2> There is the code to keep dns from the peers or not
[12:10] <Keybuk> you're just not listening, are you?
[12:10] <Keybuk> it's not the plugins that's the problem
[12:10] <Keybuk> or what they support
[12:10] <Keybuk> it's the fact that it breaks the _system_
[12:11] <Kamion> with a brick attached
[12:11] <Evaso2> but the actual version 0.6.2 how gets dns?
[12:11] <Keybuk> we talked a bit about n-m in Paris, and we came up with the idea that it might be the right thing to do to have network-manager Conflict with things like ifupdown and the gnome-system-tools
[12:11] <Keybuk> so if you install network-manager, you just don't have the "traditional" system configuration there
[12:11] <Keybuk> that way we don't have to worry about it
[12:11] <Keybuk> Evaso2: 0.6.2 doesn't support VPN
[12:12] <Keybuk> for normal connections, it calls dhclient which sets up the DNS based on DHCP responses
[12:12] <Keybuk> there's no dhclient involved in VPN
[12:12] <Evaso2> How the dns is offered by the vpn peers?
[12:14] <Keybuk> Evaso2: aiui it's part of whatever VPN protocol is being talked
[12:15] <Burgwork> Keybuk, conflicting with gnome-system-tools means you would rip out ubuntu-desktop at the same time, no?
[12:16] <Keybuk> Burgwork: conflicting with netbase would mean you had to rip out EVERYTHING :p
[12:16] <Keybuk> so, as a plan, it needs work
[12:16] <Keybuk> edgy+1, definitely
[12:16] <Keybuk> our edgy n-m plan is just "sync with Debian and largely ignore it"
[12:16] <Evaso2> Keybuk: but userpeerdns is only an option of pppd
[12:16] <Burgwork> Keybuk, the nm people also have no plans for static address setting
[12:18] <Evaso2> Keybuk: and i think that the pptp vpn plugin use this pppd option to keep dns peers on point to point
[12:18] <Evaso2> Keybuk: why you not disable also this pppd feature?
[12:19] <Keybuk> Burgwork: if you install n-m, you don't care about static dns
[12:19] <Keybuk> Evaso2: because ppp works correctly out of the box
[12:19] <mdz> Kamion: sftp updates of the checkout that I keep locally take forever, even if there are few revisions to update
[12:19] <Keybuk> Evaso2: I haven't yet looked at the evolution ppp vpn plugin in detail recently, if it now just calls ppp and doesn't futz about, then it might be ok
[12:20] <Evaso2> Keybuk: are u on dapper now?
[12:20] <Keybuk> Evaso2: dapper and edgy
[12:20] <Evaso2> Keybuk : i'm on debian, can u try this  man pppd | grep usepeerdns
[12:21] <Keybuk> Evaso2: why would I check that?
[12:21] <Keybuk> we're not talking about pppd
[12:21] <Keybuk> we're talking about network manager
[12:22] <Evaso2> Because the pptp vpn plugin and other software already in ubuntu like (kvpnc) use this option of pppd to keep pptp peer dns
[12:22] <Kamion> mdz: really? they're very quick for me
[12:23] <Kamion> a couple of seconds at worst
[12:23] <mdz> Kamion: I'm using bound branches, you/
[12:23] <mdz> ?
[12:23] <mdz> bzr update  0.57s user 0.07s system 4% cpu 13.702 total
[12:23] <mdz> that's typical for ~1 revision
[12:24] <Kamion> hmm, it does seem to be a bit longer now you mention it
[12:24] <Kamion> real    0m17.621s
[12:24] <Kamion> user    0m2.048s
[12:24] <Kamion> sys     0m0.400s
[12:24] <Kamion> but still doesn't seem worth stressing about
[12:25] <mdz> it's long enough that I can't wait for it, and go off to do something else
[12:25] <Evaso2> Keybuk: from the pptp vpn source code
[12:25] <Evaso2> Actually there is one exception... Many distros have an ip-up script which imple ments usepeerdns functionality thus replacing resolve.conf... This conflicts wit h NetworkManager's actions so may need to be removed. Sadly there appears to be no way to tell pppd NOT to execute /etc/ppp/ip-up if it exists!
[12:26] <Evaso2> so this is a problem about ip-up and pppd about the usepeerdns pppd option
[12:26] <Keybuk> Evaso2: interesting how you start to see the problems when you read the code, isn't it :p
[12:26] <Keybuk> all of the vpn plugins suffer similar problems
[12:27] <Evaso2> but also pppd connection in general that use usepeerdns option
[12:27] <Surak> I just took a quick look to gnome-system-tools, and as far as I can see, it communicates with some perl backends, right?
[12:27] <Keybuk> Evaso2: the fundamental problem is that if we have to support network-manager, we want it to behave correctly and interoperate with the rest of the system
[12:28] <Keybuk> Evaso2: we can therefore choose to either disable those parts that cause problems, or we can choose to not support it at all
[12:28] <Keybuk> where not support ~= put it in universe
[12:28] <Evaso2> Keybuk: ok... like Kvpnc
[12:29] <Evaso2> because kvpnc in dapper use the usepeerdns option
[12:29] <Keybuk> at the moment we have an amount of legacy crud in the system to support networking
[12:29] <Keybuk> ifupdown, netbase, etc. upwards
[12:29] <Keybuk> all of which are pretty bad, but at least have the virtue of working and being understood
[12:29] <Evaso2> Keybuk: the problem is about coordinate static and dynamic network
[12:30] <Keybuk> n-m breaks them all, which is fine if all you want is n-m, but people come up with creative ways of having problems by trying to use n-m *and* static networks, etc.
[12:30] <Keybuk> and we'd rather have that impossible, than get the bugs
[12:31] <mdz> Kamion: the supported seed is a joy now with Extra-Include
[12:31] <Evaso2> Keybuk: yes of course but imho is a profile use problem
[12:31] <Kamion> mdz: I am much happier with it
[12:31] <Kamion> doing it found a few seed bugs too (as expected)
[12:31] <Evaso2> if an user choiche dynamic network could not use static and vice-versa
[12:32] <mdz> Kamion: have you ever seen this?
[12:32] <mdz> W: http://archive.ubuntu.com/ubuntu/dists/edgy/main/binary-amd64/Packages.gz was corrupt
[12:32] <mdz> I got it on sparc as well
[12:32] <mdz> I've made three attempts and at least one architecture has failed in that way each time
[12:32] <Keybuk> Evaso2: at some point in the future, we'll want to have a replacment networking stack that all just works
[12:32] <Keybuk> Evaso2: and I strongly suspect that n-m will be that replacement stack, once it's mature enough
[12:33] <Kamion> mdz: yes, I get it occasionally, but retrying usually clears it up. Perhaps you're behind a transparent proxy?
[12:33] <mdz> Kamion: I'm behind a non-transparent proxy, but even when I disable that, it happens
[12:34] <mdz> has debootstrap always checked md5sum against the Release file?
[12:35] <mdz> Kamion: the annoying thing is that it doesn't fail, so I don't notice until everything is finished and I have to start over
[12:35] <Evaso2> Keybuk: what are the interaction of /etc/ppp/ip-up.d/0000usepeerdns with the pptp vpn plugin?
[12:35] <Kamion> mdz: that should be fixable ...
[12:35] <Kamion> dunno about always but it's been there for a long time
[12:36] <mdz> I've never had this happen when I don't use my local proxy
[12:36] <sladen> pitti: I think upstream took the patch to fix the paths, so maybe a sync, I haven't checked yet.
[12:36] <mdz> until now
[12:39] <mdz> err
[12:39] <mdz> Added pbbuttonsd to desktop-i386
[12:39] <mdz> oh, I guess that's sensible no
[12:39] <mdz> w
[12:39] <Surak> I'm asking this because gnome cvs now uses liboobs, which is not in ubuntu yet. So I just quite didn't get the exact point where the G-S-T communicates with that perl backends
[12:41] <ogra> ogra@edubuntu:/mnt/devel/packages/gnome-power-manager-2.15.4$ apt-cache madison liboobs
[12:41] <ogra>    liboobs | 0.1.0-0ubuntu1 | http://archive.ubuntu.com edgy/main Sources
[12:41] <ogra> its there ...
[12:41] <ogra> just no binary yet
[12:42] <mdz> https://launchpad.net/+builds/+build/223659
[12:42] <Surak> hm, dapper here. was taking a look at bug #14774
[12:42] <Ubugtu> Malone bug 14774 in gst "Shared folders requires a login" [Unknown,Unconfirmed]  http://launchpad.net/bugs/14774
[12:46] <mdz> Kamion: binaries which aren't built anymore are producing a lot of noise in anastacia; does germinate already have enough information on hand to trivially exclude those?
[12:46] <mdz> er, I guess it'd be anastacia and not germinate
[12:46] <mdz> and anastacia wouldn't
[12:47] <Surak> creating a sub{} to call smbpasswd in /usr/share/setup-tool-backends/scripts/share.pl and a user/password field for it in the G-S-T in the 'general windows sharings settings' would fix this bug.
[12:47] <Kamion> mdz: archive-cruft-check reports on those; I'll do a removal pass at some point soon
[12:48] <Kamion> mdz: I don't really want to deal with them somewhere else as well
[12:48] <Kamion> mdz: pbbuttonsd can be made [powerpc]  if we don't want it on i386; it was added for MacBooks though
[12:48] <LaserJock> is the ubuntu-archive team interested in packages in the wrong section or wrong component?
[12:49] <Kamion> LaserJock: wrong component we have a report on (anastacia)
[12:49] <mdz> Kamion: for some reason, gnutls11 is showing up for promotion to main in anastacia
[12:49] <Kamion> LaserJock: wrong section, sure, if you like
[12:49] <mdz> maybe something to do with gnutls-bin moving around
[12:49] <Kamion> ship.build-depends:libgnutls11                | gnutls11            | libxmlsec1-gnutls                  | Matthias Urlichs<EMAIL_ADDRESS>                                  |          407344 |            1204
[12:49] <Evaso2> Keybuk: so actually pptp n-m plugin seems to rely on pppd so there is any addictive problem then simply creating a manually pppd connection
[12:50] <Kamion> ship.build-depends:libxmlsec1-gnutls          | xmlsec1             | libxmlsec1-dev                     | John V. Belmonte<EMAIL_ADDRESS>                              |           41416 |             164
[12:50] <Kamion> supported+build-depends:libxmlsec1-dev                      | xmlsec1                         | openoffice.org (Build-Depend)                | John V. Belmonte<EMAIL_ADDRESS>                                             |         1074206 |            6300
[12:50] <pygi> Kamion, !!! :P
[12:50] <mdz> urgh
[12:51] <Kamion> or http://people.ubuntu.com/~cjwatson/germinate-output/edgy/rdepends/ALL/libgnutls11 for that matter
[12:52] <mdz> it build-depends on libgnutls-dev though, which is gnutls13
[12:54] <Kamion> Package: libxmlsec1-gnutls
[12:54] <Kamion> Version: 1.2.9-1ubuntu1
[12:54] <Kamion> Depends: libc6 (>= 2.3.4-1), libgnutls12 (>= 1.2.5), libxml2 (>= 2.4.24), libxmlsec1 (>= 1.2.9), libxslt1.1 (>= 1.0.20), zlib1g (>= 1:1.2.1)
[12:54] <Kamion> Package: libxmlsec1-gnutls
[12:54] <Kamion> Version: 1.2.9-3ubuntu1
[12:54] <Kamion> Depends: libc6 (>= 2.4-1), libgnutls11 (>= 1.0.0), libxml2 (>= 2.6.12), libxmlsec1 (>= 1.2.9), libxslt1.1 (>= 1.0.20), zlib1g (>= 1:1.2.1)
[12:54] <Kamion> it appears to have regressed lately
[12:55] <Kamion> mdz: libgnutls-dev isn't the relevant arc in the graph
[12:55] <bluefoxicy> o.o my screan is full of noise
[12:56] <mdz> Kamion: http://librarian.launchpad.net/3309974/buildlog_ubuntu-edgy-i386.xmlsec1_1.2.9-3ubuntu1_FULLYBUILT.txt.gz clearly shows libgnutls13 being installed, then ending up with a gnutls11 dependency anyway
[12:56] <mdz> and the library is in fact linked with libgnutls.so.13
[12:56] <anibal> Kamion, could you please review busybox 1.1.3-2ubuntu1, bug #52706
[12:56] <Ubugtu> Malone bug 52706 in busybox "please merge busybox 1.1.3-2ubuntu1" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52706
[12:56] <mdz> debian/shlibs.local:libgnutls 13 libgnutls11 (>= 1.0.0)
[12:56] <mdz> O.M.G.
[12:57] <mdz> I have got to see the changelog for that one
[12:57] <mdz> oh I bet it's this
[12:57] <mdz> "  * Adjust gnutls dependency (Closes: #335771)"
[12:58] <Kamion> anibal: ok, in the morning
[12:58] <Kamion> (for the record, I usually find that reviewing merges is about as time-consuming as just doing them ;-))
[12:58] <Kamion> but thanks
[12:58] <anibal> Kamion, it's 08:57, Wed morning already :)
[12:58] <Kamion> for you maybe ...
[01:00] <sladen> anibal: ...and now it's Wednesday morning for Kamion too
[01:00] <anibal> Kamion, what process should I go through to upload them directly?
[01:00] <Kamion> anibal: you would need to be approved for ubuntu-core-dev
[01:00] <Kamion> (I'd really prefer non-installer people didn't upload busybox though - it's very core and sometimes needs to be coordinated carefully)
[01:01] <Kamion> (though if you were doing installer hacking, it would be fine)
[01:01] <mdz> anibal: http://www.ubuntu.com/community/processes/newdev
[01:02] <anibal> Kamion, during debconf6, frans show us how easy is to do d-i hacking
[01:02] <Kamion> anibal: for the record please don't subscribe ubuntu-archive to merge bugs
[01:02] <anibal> mdz, thanks
[01:02] <Kamion> ubuntu-archive only needs to know about syncs
[01:02] <anibal> Kamion, okay
[01:02] <Kamion> (i.e. unmodified sync)
[01:03] <mdz> Kamion: I was thinking, is there even any reason for ubuntu-archive to be involved in syncs, where the requestor has upload privileges for the relevant component?
[01:04] <mdz> I suppose it's convenient with larger packages not to have to download and upload again, but in general it would be quicker and more convenient
[01:04] <Kamion> mdz: when soyuz can make it happen by letting you press a button, there will be no reason
[01:04] <Kamion> and that is the eventual plan
[01:04] <Kamion> in the meantime, the current sync policy removes a lot of human error possibility
[01:05] <Kamion> it's very easy to accidentally upload the wrong thing, or think that it's ok to download the package and re-dpkg-buildpackage, or whatever
[01:05] <Kamion> this way, we know that we're getting what it says on the tin and don't have to double-check
[01:06] <mdz> Kamion: we have a tool for it, and there's no particular reason why that tool needs to be run by the archive admins rather than any developer
[01:06] <mdz> it shouldn't be any more error-prone
[01:07] <Kamion> I'm not sure I agree - "ask somebody experienced to do it for you" has a much lower error rate than "download random script, upload the result"
[01:07] <Kamion> especially if we discover bugs in that script
[01:08] <Kamion> and it seems valuable to have the manual-sync process be essentially the same as the auto-sync process
[01:08] <mdz> it would be more like "run script that you already have installed with dpkg-dev" or similar, not random
[01:08] <mdz> and the upload would be part of the script, it would be a one-step process
[01:08] <Kamion> it gives me the shivers
[01:08] <mdz> I see no reason for it to be a "run this tool to spit out something, then deal with it" process
[01:09] <mdz> why?
[01:09] <mdz> what's the failure case you have in mind?
[01:09] <Kamion> because syncs are an extremely cast-iron process at the moment
[01:09] <Kamion> we are very sure indeed about their results, precisely because they're centralised
[01:10] <Kamion> I don't really see the value of losing that useful guarantee that when we think we've synced to Debian, we really have
[01:10] <Kamion> otherwise we have to have something run around checking that 1.0-1 here == 1.0-1 Debian
[01:12] <mdz> Riddell: gnokii looks ancient; is it really something we want to use in kdepim?
[01:12] <Kamion> and additionally once soyuz learns to sync directly from Debian by copying publishing records around, a process involving dpkg-dev would become obsolete anyway
[01:12] <mdz> Kamion: I don't see how it makes any difference in our certainty
[01:12] <mdz> the soyuz-based process definitely would
[01:12] <mdz> but you running the tool vs. doko running the tool doesn't
[01:13] <Riddell> mdz: I've had a couple of requests but it's not a major feature so I'll leave it out
[01:13] <Kamion> how about me running the tool vs. inexperienced MOTU running the tool (and perhaps thinking that it's ok to stop it in the middle and fiddle)?
[01:14] <LaserJock> iwj: ping?
[01:15] <Kamion> now, if the tool were something that checked lp auth in the relevant team and somehow asked drescher to run the sync-source backend, that would be ok; that's effectively just the existing sync process with ubuntu-archive out of the loop
[01:16] <Kamion> (apart from *meep* security concerns with having stuff being able to request that code be run on drescher as lp_archive)
[01:17] <Kamion> but to preserve the certainty of syncs I do think it's valuable to have the packages all stay on the archive machine rather than being shunted out to a developer machine and then shunted back again after who-knows-what-modifications
[01:17] <Kamion> not to mention the upload time concerns for big packages, as you alluded to earlier
[01:41] <jdub> hooooly crap, upgrade-o-rama this morning
[01:41] <mdz> Kamion: the tool wouldn't let them do anything they couldn't do by hand, and in fact, it would discourage doing so through automation
[01:42] <mdz> Kamion: I really don't see the concern for who-knows-what modifications; these are folks who have upload privileges
[01:42] <mdz> it's no different than apt-get source
[01:44] <Kamion> I guess I just don't see the urgent reasons why it must change
[01:47] <mdz> Riddell: oh, I hadn't even looked at the main inclusion review; I just saw it in anastacia and took a look
[01:48] <jdub> hrm, xephyr/xnest don't do alternatives
[01:48] <mdz> Riddell: noticed it because it was pulling in an ancient postgresql
[01:48] <Riddell> mdz: I've uploaded a new kdepim without gnokii
[01:48] <mdz> Riddell: noticed, that's where I saw your comment about main inclusion
[01:49] <mdz> was there a report for it?
[01:49] <mdz> Kamion: it's not urgent
[01:49] <mdz> but it would reduce overhead significantly
[01:49] <Riddell> mdz: https://wiki.kubuntu.org/MainInclusionReportGnokii
[01:49] <Riddell> mdz: pitti rejected it earlier
[01:50] <mdz> oh
[01:50] <mdz> my gut agreed with pitti then
[01:51] <jdub> Kamion: do we still require dselect? :)
[01:51] <jdub> Kamion: could it be removed from u-s? :)
[01:59] <mdz> Riddell: what change has resulted in amarok-engines wanting to go into main?  seems like the sort of thing which would have been there in the first place
[02:00] <Kamion> jdub: whatEVAH

[02:00] <jdub> heh
[02:00] <Kamion> ok, is c++ exception handling buggered in edgy?
[02:00] <jdub> Kamion: i just care about the little people, y'know?
[02:01] <Burgwork> jdub, is the dcc alliance dead?
[02:02] <Kamion> $ cat t.cpp
[02:02] <Kamion> #include <iostream>
[02:02] <Kamion> int main() { try { throw "foo"; } catch (...) { std::cout << "test" << std::endl; } }
[02:02] <Riddell> mdz: looks like the Depends have changed on amarok to have amarok-engines | amarok-engine not amarok-xine | amarok-engines
[02:02] <Kamion> $ g++ -g -Wall -o t t.cpp
[02:02] <Kamion> $ ./t
[02:02] <Kamion> test
[02:02] <Riddell> mdz: amarok-engines is all the obscure backends aren't used.  I'll fix that
[02:02] <Kamion> but in edgy, that gives SIGSEGV
[02:03] <jdub> Burgwork: no, not at all
[02:03] <mdz> Riddell: ok, so we don't need/want amarok-engines?
[02:03] <jdub> Burgwork: it's obviously not dead
[02:03] <Riddell> mdz: no
[02:03] <jdub> Burgwork: it's... pining
[02:03] <mdz> ok
[02:03] <Kamion> Riddell: have you noticed exception handling problems like the above?
[02:03] <jdub> for the fjords.
[02:03] <crimsun> Kamion: with g++ 4.1.1-8ubuntu1?
[02:03] <mdz> jdub: I was just looking at that the other day actually
[02:03] <mdz> it ought to move out to supported, under "elmo"
[02:04] <Riddell> Kamion: no, but KDE uses very little exception handling
[02:04] <jdub> mdz: dselect, or dcca? :)
[02:04] <mdz> jdub: dselect
[02:04] <mdz> I don't think elmo is interested in official support for the dcca
[02:04] <Kamion> crimsun: 4.1.1-2ubuntu5
[02:04] <jdub> though it would be fun to give it to him, and see what he does with it
[02:05] <Kamion> newest version on powerpc at present
[02:05] <Burgwork> jdub, right. But for amusement: http://lists.dccalliance.org/pipermail/dcc-devel/2006-June/000704.html
[02:05] <crimsun> that sounds an awful lot like the segfault on exception handling on ppc issue that slomo/tseng were seeing
[02:06] <jsgotangco> lol
[02:07] <jdub> it's actually really lame that they're just letting it hang on for grim life like that
[02:07] <jdub> kinda like userlinux
[02:08] <Kamion> crimsun: is that fixed in -8ubuntu1? if so I'll ignore it for now and upgrade tomorrow
[02:08] <crimsun> Kamion: can't confirm, no ppc hardware
[02:09] <tseng> crimsun: doko says he cant reproduce
[02:09] <tseng> er, @ Kamion
[02:09] <Kamion> tseng: is there a bug number?
[02:09] <tseng> last i heard from slomo_ gcc wasnt built there in the archive
[02:09] <tseng> Kamion: yes, moment
[02:09] <tseng> https://launchpad.net/bugs/52465
[02:09] <Ubugtu> Malone bug 52465 in gcc-4.1 "[libgcc1]  segfault on ppc when unwinding stack (c++ exceptions, mono exceptions)" [Critical,Confirmed]
[02:09] <Kamion> yeah, just found it
[02:10] <tseng> pitti and doko spoke about it earlier today
[02:10] <tseng> here.
[02:10] <Kamion> ah, he says he can't reproduce with -8ubuntu1 so I'll try that tomorrow
[02:10] <tseng> or was it yesterday?
[02:29] <bddebian> Howdy
[02:30] <Riddell> mdz: could you move libqt4-debug-dev to main?
[02:32] <mdz> Riddell: it should be pulled in automatically as part of Kamion's new germinate magic
[02:33] <mdz> or does something depend on it?
[02:33] <Riddell> mdz: speedcrunch build-deps on it
[02:35] <mdz> Riddell: ok, done
[02:35] <Kamion> Riddell: you need to undo the KDE-specific Extra-Excludes in supported for your seeds
[02:36] <Kamion>  * Extra-Exclude: libqt4-debug-dev
[02:36] <Kamion> for one
[02:36] <Kamion> you may need GNOME-specific Extra-Excludes, conversely - although it's not a huge deal
[02:37] <Riddell> right
[02:37] <Kamion> those excludes are just there because Ubuntu build-deps on stuff like doxygen and I didn't want to pull in effectively all of KDE into Ubuntu supported
[02:39] <bddebian> Heya imbrandon
[02:39] <imbrandon> heya bddebian
[02:40] <Riddell> Kamion: why does doxygen end up pulling in KDE?
[02:41] <Keybuk> mdz: my concern with giving random joes the sync tool is that nothing stops them modifying the source before they upload it
[02:42] <Keybuk> they have to sign it anyway, so there's actually an incentive for them to fix whatever bug they had, and forget to do the ubuntuX on it
[02:42] <bddebian> Oh, can I have it? :-)
[02:42] <Kamion> Riddell: hmm, may not have been doxygen actually
[02:42] <Keybuk> in fact, I suspect they have to not only sign it, but change the changelog to be able to upload it
[02:43] <Keybuk> (right now, we have a special hammer to slam them into the archive)
[02:43] <Kamion> Riddell: I think it was debconf Build-Depends-Indep: libqt-perl Build-Depends: libsmokeqt-dev which comes from the kdebindings source which Build-Depends: kdelibs4-dev
[02:43] <Kamion> there was probably something else too, I remember kdebase-dev being extra-included
[02:44] <bddebian> Damn, who knew cutting out paper doll clothes could be so freakin' time-consuming :-(
[02:45] <Kamion> basically I went through the before->after germinate output diff and made sure I could justify every addition to all
[02:45] <Kamion> you might not want to go that far - I did it because I also needed to ensure that my germinate changes were correct
[02:46] <mdz> Keybuk: nothing stops them from modifying source they get from apt-get source either
[02:46] <Kamion> but if they upload that, it'll be with a different version, generally
[02:47] <mdz> Keybuk:  the tool would be a one-shot deal; we wouldn't give them the opportunity to modify the source
[02:47] <Kamion> and if they don't upload that, who cares
[02:47] <mdz> Kamion: why in one case and not the other?
[02:47] <Kamion> because psychologically, they're doing a sync
[02:47] <Keybuk> mdz: that involves tool development time ... I don't see the point in spending the effort developing a "sync and upload" tool
[02:47] <Kamion> it would be very tempting to "just clean it up a little"
[02:48] <mdz> I don't see the difference between "they might modify without changing the version number after getting source with the sync tool and interrupting it partway through" and "they might modify without changing the version number after downloading source with apt-get source"
[02:48] <mdz> Keybuk: I'll add the debsign && dput to the end myself ;-)
[02:48] <Keybuk> mdz: they can't upload the source they get with apt-get source without changing the version number
[02:48] <mdz> Keybuk: what stops them?
[02:48] <Keybuk> mdz: will you also remove sync-source's dependencies on launchpad's code, and direct database access
[02:48] <Keybuk> mdz: or will you give everybody a copy of launchpad and open the database to all?
[02:48] <Keybuk> mdz: the fact the source already exists in the archive with that version, and the basic upload checks go "version must be greater" ?
[02:48] <Kamion> mdz: what stops them> you can't upload something with a version that's already in the archive
[02:49] <mdz> Keybuk: I thought that it was changed to use Packages files as part of the porting process
[02:49] <Keybuk> mdz: HAHAHAHA
[02:49] <mdz> Kamion: we're talking about source obtained from Debian
[02:49] <Kamion> no, it was ported to LP properly
[02:49] <Kamion> mdz: oh that's not apt-get source on Ubuntu :-P
[02:49] <mdz> Kamion: I get source from Debian with apt-get source on Ubuntu all the time
[02:49] <Keybuk> mdz: I would bet that there are maybe two people in all of Ubuntu who have Debian deb-src lines in their sources.list
[02:49] <Keybuk> mdz: probably you and Kamion
[02:49] <mdz> in fact it's usually the default, because Debian is newer
[02:49] <jdub> i added one recently 8)
[02:50] <Keybuk> and yes, nothing does stop them doing that
[02:50] <Kamion> there was a period when people were uploading fake-syncs got that way, when the sync tool was nonfunctional
[02:50] <bddebian> other than the wrath of core-devs :-)
[02:50] <Kamion> I never did get round to going through and verifying all of the syncs thus uploaded
[02:51] <Keybuk> mdz: seriously, if freeing up the half an hour a day ubuntu-archive spend doing syncs is important ... please hassle the LP team to make clicky-syncs a reality
[02:51] <mdz> the fact that the sync tool would need de-LP-ifying is a better argument
[02:52] <Kamion> we won't get any development time from the LP team to de-LP-ify things either - whereas at present we do at least theoretically get support from them
[02:52] <Keybuk> most of my "sync time" is actually spent working out why the sync tool is refusing to do its job, and rearranging the archive appropriately
[02:52] <mdz> Keybuk: it will be a long time before launchpad does everything we want in the ideal way; that won't stop us from having interim solutions where it makes sense
[02:52] <mdz> the current sync tool is an example of such a situation
[02:53] <Keybuk> what's wrong with the current sync tool?
[02:53] <Keybuk> you have a serious hate for it, yet don't use it that often
[02:53] <Keybuk> it works just fine
[02:55] <mdz> Keybuk: you and Kamion are blowing this way out of proportion
[02:55] <mdz> read the beginning of the conversation where I started musing
[02:55] <bddebian> I have to admit that with Keybuk AND Kamion doing syncs, it has been very expeditious
[02:56] <mdz> I'm not criticising either of you in the work you are doing on syncs
[02:57] <Kamion> actually that wasn't my concern; I had (and remember espousing) the same opinion when it was elmo doing all the syncs
[02:57] <Keybuk> I didn't believe you were
[02:58] <Keybuk> I'm just raising my concern that we'll lose a lot of confidence in a sync if everybody does them by hand
[02:59] <Keybuk> also the by-hand syncs annoy the hell out of mom
[02:59] <Keybuk> I had to code around that this time round
[02:59] <Keybuk> because by-hand syncs need the top changelog entry modified to say "edgy" and an author in ubuntu-{core-,}dev
[03:00] <Keybuk> whereas those ubuntu-archive do can be injected into the queue after the signature checking, so have the same top changelog as Debian
[03:01] <Kamion> actually, that's not a real restriction; you just need to hack up a new .changes file
[03:01] <Keybuk> Kamion: does LP not reject them now?
[03:01] <Kamion> by-hand syncs are often like that because people don't know how to or (quite reasonably) don't want to hack the .changes
[03:02] <Keybuk> I thought Soyuz got upset somewhere in the mailing when changelog and changes disagreed
[03:02] <Kamion> oh, it might do I *suppose*, katie never used to
[03:02] <Keybuk> (where reject = throw an exception)
[03:02] <Kamion> seems like an odd check to add
[03:02] <Keybuk> it's not a check, but a bug, I think ... worth trying again at some point
[03:02] <Kamion> the reason why we inject syncs into the queue after the sig check is that we didn't want to have a sync signing key on drescher
[03:02] <Kamion> katie's syncs used to be signed
[03:03] <Keybuk> there'd definitely be a temptation to fiddle with the sync though
[03:03] <Keybuk> "here's a source package to upload" => try and build it => fix a bug => upload
[03:03] <Keybuk> and then there's the packages which, when built, rewrite their source package
[03:03] <Keybuk> hell, I've been tempted to fiddle with a sync before
[03:03] <Keybuk> in fact, as recently as today
[03:04] <Kamion> mm, I take mdz's point that it would just upload for you, but the tool would have to have a debug mode so that you could see what it was going to do, and the best way to implement that debug mode would be to have it spit out the package so you could check it
[03:04] <Keybuk> Kamion: upload using which tool?  what about ftp proxies?  etc.
[03:04] <Kamion> and at that point I know I'd be seriously tempted to always use the debug mode :-)
[03:04] <mdz> what is there to check?  it's just downloading a source package and re-uploading it verbatim
[03:04] <Keybuk> e.g. I don't use dput
[03:05] <Keybuk> and where would it get the gpg configuration from?
[03:05] <Kamion> right, same reason basically that I have -uc -us set in my debuild configuration
[03:06] <Kamion> I want to do the signing *after* I've diffed, tested, etc.
[03:06] <Keybuk> mdz: download, unpack, generate changes file, sign changes and dsc, upload again
[03:06] <Kamion> I would be scared to sign something that a random tool spat out for me and didn't let me check
[03:06] <Keybuk> at each point, making sure to honour the user's apt choices, signing key choices, correct e-mail address, upload procedure, etc.
[03:06] <mdz> there is nothing random about the tool
[03:07] <Kamion> mdz: every package I sign, I diff against the last version, and generally eyeball the whole diff
[03:07] <mdz> Keybuk: that's what debsign is for
[03:07] <Keybuk> mdz: so if I gave you a tool that asked to sign something as part of its operation, you'd happily enter your GPG key? :p
[03:07] <Kamion> you're proposing I sign something that I'm not allowed to look at
[03:07] <Keybuk> mdz: debsign still needs arguments/options
[03:07] <Kamion> because it won't spit it out anywhere
[03:07] <mdz> Kamion: I'm not; I expect you would continue to use sync-source.py
[03:07] <Kamion> mdz: let's pretend ...
[03:08] <mdz> Kamion: my point is that yours is not a typical use case
[03:08] <Kamion> mdz: I don't think that reasonable paranoia implies member of ubuntu-archive
[03:08] <Keybuk> mdz: actually, I think it is -- we've instilled a sufficient sense of professionalism into our community that most of them will feel unhappy about signing their name to something they haven't at least _checked_
[03:09] <mdz> Keybuk: people are not reading the entire diff when requesting a sync
[03:09] <mdz> we implicitly trust Debian
[03:09] <mdz> we import things from them without looking at them all the time
[03:09] <Keybuk> mdz: I do
[03:09] <Kamion> why not? mom gives it to them to check
[03:09] <Keybuk> every sync I've ever processed, I've read the diff
[03:09] <Keybuk> and most sync requests come from people who've just been reading the mom output
[03:09] <Kamion> they should at least be eyeballing it to ensure it contains the Ubuntu changes
[03:09] <Keybuk> (manual sync, anyway -- I don't read the "every day" ones)
[03:10] <Hobbsee> morning all
[03:10] <bddebian> Hi Hobbsee
[03:10] <mdz> Kamion: I often just look at the ubuntu changes and check that they're present without reading the rest of the diff
[03:10] <mdz> especially if it's a new upstream
[03:11] <Kamion> if there's a trust path back to somebody's GPG key for a sync, I expect that they have at minimum checked that the md5sums are the same as the source package in Debian
[03:11] <Kamion> at present we know this because we trust drescher
[03:12] <mdz> apt checks that when it downloads the source
[03:12] <Kamion> I don't trust developer's machines not to have a subtly trojaned sync tool; I do trust them not to be trojaned in such an AI-complete way that diff produces reassuring output even on trojaned uploads
[03:12] <mdz> Kamion: dude, they already have upload privileges
[03:13] <Kamion> yes, and they'd better be using diff when they upload
[03:13] <mdz> Kamion: that is no defense
[03:13] <Kamion> it raises the bar to a casual hacker a hell of a lot
[03:13] <mdz> in fact my first choice if I were writing a trojan targeting Ubuntu developers would be dupload and dput
[03:14] <Keybuk> mine would be apt ;)
[03:14] <Kamion> (surely debsign)
[03:14] <Keybuk> give them the wrong source in the first place
[03:14] <mdz> devscripts, dpkg-dev...
[03:14] <mdz> debdiff!
[03:14] <Kamion> my point is, if you're being halfway diligent about reading the damn changes you're uploading, it's very hard to convince you to sign the wrong thing
[03:14] <Keybuk> oh, I trojan'd dpkg-dev a long time ago ;)
[03:14] <mdz> show them a correct diff and then modify it ;-)
[03:15] <Keybuk> dupload/dput wouldn't be very useful, because they get run after the signing
[03:15] <Kamion> how does the hacker know what "correct" is (if you diff the package *after* signing it too, which I randomly often do)?
[03:15] <Kamion> I suppose you could stash an unmodified diff somewhere before your evil modifications to the package
[03:16] <Kamion> starting to sound increasingly detectable at that point though
[03:16] <mdz> Kamion: this is silly; if you're that concerned about whether people review the changes, then have the tool run debdiff for them
[03:16] <mdz> I think that's completely orthogonal
[03:16] <Keybuk> mdz: and then, at that point, you increase the incentive for them to fix problems before they upload
[03:16] <Keybuk> which leads us to having syncs that don't match Debian
[03:16] <mdz> that is such an invented problem
[03:17] <Kamion> sorry to sound really anal but I don't think good checking practices are silly considering how many production machines run Ubuntu
[03:17] <Keybuk> mdz: dude, _I've_ been tempted to fix syncs before that I know are going to be broken
[03:17] <mdz> the developer would have to try very hard to browbeat the tool into letting them upload a modified package
[03:17] <mdz> it would be easier for them to use apt and dput
[03:17] <Keybuk> I can't believe other developers will resist that temptation
[03:17] <Kamion> I realise we trust Debian and that there's more coming through than we can in practice review, but I don't think that's a reason not to review things when we can
[03:17] <Keybuk> mdz: yeah, they'd have to edit it and stick sys.exit(0) in the right place ...
[03:18] <mdz> Keybuk: which is more typing than apt-get source
[03:18] <mdz> which is what they'd be crippling the tool into
[03:18] <Kamion> so in practice folks will end up using apt-get source. doesn't seem like an improvement ;)
[03:18] <mdz> except that they won't
[03:18] <Kamion> (actually, it's apt-get source plus .changes mangling)
[03:18] <Keybuk> also I'm vaguely worried about pushing Debian deb-src onto every developer's machine ... we'll end up with all manner of random versions being uploaded by accident
[03:18] <mdz> they'd do exactly what they're doing today, only with a command line which does the sync instead of a command line which files a bug report
[03:19] <Keybuk> if "apt-get source foo" always gives our developers the Debian source, not the Ubuntu source, that's a bad thing
[03:19] <mdz> Keybuk: I wasn't suggesting modifying their sources.list at all
[03:19] <Keybuk> if the tool reads Debian's Sources.gz by hand, then it _is_ doing something different for them
[03:19] <Keybuk> and thus is "more than apt-get source"
[03:19] <Kamion> as bddebian says, a lot of people aren't just doing "command line which files a bug report", they're downloading the package and test-building it first
[03:19] <Kamion> which seems like something we want to encourage
[03:20] <bddebian> Oh, you actually "heard" me? :-)
[03:20] <mdz> Kamion: the part of the process where they download and test it is *exactly the same* regardless of the sync partof the process
[03:20] <Kamion> given that many people won't want to download the same thing twice, they'll want to pick the package out of the sync tool's output
[03:20] <mdz> it makes no difference
[03:20] <Kamion> it does, see immediately above
[03:20] <mdz> I think people are lazier than you give them credit for
[03:20] <Kamion> it makes perfect sense for people to want to go "sync, except don't upload yet while I test it"
[03:21] <Kamion> I don't think that's lazy, seems sensible to me
[03:21] <bddebian> May I make comments?
[03:21] <mdz> I re-download things all the time
[03:21] <Kamion> saving bandwidth is often the opposite of lazy ;)
[03:21] <Keybuk> bddebian: of course
[03:21] <mdz> I use squid
[03:21] <mdz> I routinely blow away the output of apt-get source and run it again to ensure that I have what I think I have
[03:21] <mdz> squid deals
[03:22] <bddebian> I have had a couple of packages so far where the ubuntu changes could be dropped but the package still FTBFSs so I personally think a test build is required/recommended when synced a previously merged package
[03:22] <mdz> bddebian: I agree with you one hundred percent
[03:22] <Kamion> perhaps we should take a straw poll of how many developers have a local squid ... I suspect it's not huge outside perhaps core-dev
[03:22] <mdz> bddebian: but that is one hundred percent irrelevant to how syncs are processed
[03:22] <Keybuk> Kamion: proxies are evil
[03:23] <mdz> I expect most folks are behind a cache whether they know it or not
[03:23] <Kamion> actually that's a good point, I have a local squid but I often turn it off to avoid some problem or other and forget to turn it back on
[03:23] <Keybuk> mdz: varies depending on the ISP ... certainly in the UK "proper" ISPs actually list "no transparent proxy" as a feature
[03:23] <mdz> Kamion: I expect more developers have caches than diff their packages again after signing ;-)
[03:23] <Kamion> so the bits generally have to come down my ADSL which is the slow bit
[03:23] <mdz> Kamion: and don't you have a local mirror anyway?
[03:23] <bddebian> mdz: My only point was, if I could just sync, maybe I would just synck, let the buildd do the work, then if it fails re-pull it and "fix" it?
[03:23] <Kamion> mdz: not of universe
[03:24] <Kamion> but yes, I do
[03:24] <mdz> bddebian: why?
[03:24] <Keybuk> must get around to setting a local mirror up at some point
[03:24] <bddebian> I wouldn't but I am saying if I'm "lazy"
[03:24] <Keybuk> though I'd suspect I'd still use archive.ubuntu.com to ensure it's up to date :)
[03:25] <Kamion> mdz: having to ask a person to do the work means that people feel guilted into testing it first rather than afterwards :-)
[03:25] <mdz> Kamion: now that I buy
[03:25] <bddebian> Kamion: Exactly :-)
[03:25] <Kamion> the effect is really noticeable
[03:25] <Hobbsee> really, why *wouldnt* they test that something is buildable and installable before they sync it?  besides laziness, of course
[03:26] <mdz> "having to request a sync from an archive admin puts the fear into them" is a stronger argument than "they might modify a local sync tool to do bad things"
[03:26] <Kamion> compare syncs where people test-build in pbuilder and the works before they request them, to ordinary uploads where people throw six in a row at the buildd until one sticks
[03:27] <Kamion> it's interesting, and sort of depends on the tools you use on a regular basis
[03:27] <Keybuk> mdz: s/bad/good/
[03:28] <Kamion> for instance I have to do a lot of weird things with translations
[03:28] <Keybuk> six in a row?  that few?
[03:28] <Kamion> so I often have locally-modified versions of the gettext and po-debconf toolset kicking around
[03:28] <Hobbsee> Keybuk: you mean people really do that?  intentionally?  ouch!
[03:28] <Kamion> after a while, you sort of get inured to having to hack things locally until they work, and you don't always necessarily get around to pushing things back to the distro
[03:29] <Kamion> anyone who disputes this gets to show off the contents of their ~/bin/ :-)
[03:29] <jdub> moreutils!
[03:29] <Kamion> $ ls bin | wc -l
[03:29] <Kamion> 129
[03:29] <Keybuk> Hobbsee: well, not so much intentionnally.  People do upload things they think should work, and then fix them, and then fix them harder, and then go and fix them even harder still, etc.
[03:30] <Kamion> "this time it'll work for sure, I see the problem, don't need to test that"
[03:30] <Keybuk> Kamion: amusingly, my bin contains a modified debsign, a modified dupload, a modified dch, etc. :p
[03:30] <Kamion> etc.
[03:30] <Hobbsee> Keybuk: ah.  right.  which for the most part could still be avoided by testing in a pbuilder.
[03:30] <Hobbsee> bleh, okay.
[03:31] <Kamion> Hobbsee: right, it's a trade-off between definitely spending the effort now and maybe spending the effort later
[03:31] <Kamion> I can understand why it happens
[03:31] <Keybuk> and then there's those people that are allergic to pbuilder
[03:31] <Hobbsee> Kamion: yeah, fair enough
[03:31] <Kamion> not saying it's good practice, but I can understand it
[03:31] <Hobbsee> yeah
[03:31] <Hobbsee> Keybuk: now they do need to be trained better.  actually, more people seem to be allergic to the MOM.
[03:32] <Keybuk> Hobbsee: I think most people didn't *know* about MoM
[03:32] <Kamion> I have to say I don't really trust MOM to merge some of my weirder packages :-)
[03:32] <jdub> well, MOM just tells you to clean your room (packages)
[03:32] <Hobbsee> Keybuk: there are still a fair few people who refuse to use it
[03:32] <Keybuk> well, no, if you know a package intimately, the chances are you can do a far better job than MoM
[03:32] <Kamion> this is no particular reflection on MOM - debian-installer is kind of a corner case for instance
[03:33] <Keybuk> Hobbsee: meh, I've just never really got pbuilder to work without feeling sick
[03:33] <Hobbsee> Keybuk: really?
[03:33] <Keybuk> really
[03:33] <Hobbsee> Keybuk: you're one of those chroot people, i guess (ack)
[03:33] <Keybuk> nah
[03:33] <Keybuk> I just build it on my usual machine
[03:33] <Keybuk> and every month or so, go round and purge all the accumulated build-deps
[03:34] <Kamion> Hobbsee: if you usually work down near the bottom of the software stack, it's a lot easier
[03:34] <Hobbsee> hehe.  does that end up working, or do you get packages thrown back?
[03:34] <mdz> that's what I do too
[03:34] <Hobbsee> Kamion: that is true
[03:34] <Kamion> GNOME upload du jour doesn't make a lot of difference to whether udev works
[03:34] <Keybuk> Hobbsee: I have an almost 100% build rate <g>
[03:34] <Hobbsee> Keybuk: ah right :P
[03:34] <Keybuk> Kamion: though, sadly, the same cannot be said the other way around <g>
[03:34] <mdz> Keybuk: we should collect stats on that
[03:34] <Keybuk> mdz: LP does
[03:34] <mdz> Keybuk: really? where?
[03:34] <mdz> I mean actually cook them and display them
[03:34] <mdz> LP has the data
[03:34] <Keybuk> it doesn't graph them
[03:35] <Keybuk> they're supposed to affect your karma though
[03:35] <Hobbsee> mdz: in a locked filing cabinet in the disused lavitory with a big sign on it sayign "beware of the leoppard"  :P
[03:35] <Hobbsee> so you could get reverse karma that way, hmmm...
[03:35] <mdz> Keybuk: no need for a graph; stats for the current release would be good enough
[03:35] <Kamion> Keybuk: I was particularly impressed to see the proposal in the soyuz-karma spec that archive admins should get lots of karma for processing NEW ;-)
[03:36] <mdz> I have no idea where my karma comes from
[03:36] <mdz> I don't do that much in LP
[03:36] <Kamion> spec tracking is grossly weighted upwards
[03:37] <Kamion> indeed, /people/mdz/+karma says you have 143545 points from spec tracking
[03:38] <Kamion> it's probably nearly all from the pre-UDS spec juggling
[03:39] <Keybuk> Kamion: also, more pointedly, it's not really possible to test sysvinit changes in a chroot
[03:41] <Keybuk> that's the main thing that annoyed me about pbuilder, actually
[03:41] <Keybuk> it was harder than I'd prefer to keep the chroot around so you can actually run what you just built
[03:41] <Kamion> there's an obvious difference between core-dev and dev on this; if a core-dev runs edgy, and their system blows up, chances are they can probably fix it and get the fix in the archive post-haste, unless it's something requiring really specialist knowledge like the kernel
[03:41] <Keybuk> and it didn't do the most obvious test of "build a new version while the old version is already installed" which an amazing number of source packages used to (and probably still do) fail on
[03:42] <Kamion> the same is not necessarily true (and shouldn't have to be true) of developers working in more specialised less core areas
[03:43] <mdz> rodarvus: xserver-xorg-input-elographics is in main but not depended upon by anything or seeded
[03:43] <mdz> Kamion: interesting, I didn't know about /+karma
[03:44] <mdz> though it's apparently important enough to be the very first thing in the navigation portlet
[03:44] <zul> meh...karma..
[03:44] <Keybuk> Kamion: the shiniest part of LP always tends to give the most karma points
[03:44] <mdz> but not important enough for the karma display to have a hyperlink
[03:44] <Keybuk> usually whichever bit Mark touched last
[03:44] <zul> it would be nice if uploads were counted
[03:44] <Keybuk> then an LP dev goes around and decreases it all
[03:45] <mdz> they aren't?
[03:45] <mdz> hmm, apparently not
[03:46] <zul> nope
[03:46] <Keybuk> soyuz doesn't do karma, there's a spec for it
[03:46] <bddebian> zul: Aye
[03:49] <Kamion> "soyuz-karma" in fact
[03:50] <Keybuk> Kamion: at least it's not "edward"
[04:00] <Keybuk> \o/  25 merges left, and over 24 hours to do them in
[04:01] <Hobbsee> Keybuk: get going then :P
[04:01] <Keybuk> tomorrow I have dhcdbdbdbdbdbdbdbdbdb and n-m
[04:01] <Hobbsee> ah, n-m should be fun
[04:02] <Keybuk> Hobbsee: meh, not especially;  today I did courier, that was fun
[04:02] <Kamion> tomorrow I have more debian-installer and more gparted
[04:02] <Keybuk> in a soul-destroying kind of way
[04:02] <Hobbsee> hehe
[04:02] <jdub> Keybuk: courier -> universe! yay!
[04:02] <Kamion> both of which are soul-eating monsters although at least I have debian-installer done bar the shouting
[04:02] <Keybuk> I suspect I'll need to beat BenC up a little more to do kernel-wedge and kernel-package
[04:03] <zul> Keybuk: yeah you might
[04:04] <Kamion> elmo: at this point it would be really convenient to have some way to get packages from the master archive as opposed to ftp.acc.umu.se :-/
[04:04] <BenC> Keybuk: almost ready to upload both
[04:04] <Keybuk> BenC: oh, well done that man
[04:05] <bddebian> Keybuk: Anything I can help with?
[04:05] <Kamion> might get installation-guide done tomorrow if I'm very lucky
[04:05] <Keybuk> bddebian: I'm so sorely tempted to say "ia32-libs" ... but I wouldn't wish that on my worst enemy
[04:06] <Kamion> hopefully Mithrandir will get xfonts-utils done tomorrow
[04:06] <Keybuk> there's about a dozen X things outstanding still
[04:07] <bddebian> I started to do some X stuff but by the time I woke up when you all woke up, they were uploaded :-(
[04:07] <Kamion> Keybuk: how come xfonts-utils isn't in main-manual.html?
[04:08] <bddebian> s/all woke up/all were awake/
[04:08] <bddebian> Well my offer stands if I can do anything for anyone
[04:10] <Kamion> Keybuk: maybe a public page with the blacklisted packages would be good ...
[04:10] <Keybuk> Kamion: because it's not a source package?
[04:10] <Keybuk> Kamion: mom doesn't have a blacklist
[04:10] <Kamion> Keybuk: it is in Debian
[04:11] <Keybuk> though I agree the sync blacklist should be public, though I've yet to get that pushed further (I put it in bzr)
[04:11] <Keybuk> Kamion: right ... but not in Ubuntu
[04:11] <Kamion> yeah, a list of those cases would be good
[04:11] <Keybuk> so it's not something MoM can even see
[04:11] <Kamion> the sync blacklist is public
[04:11] <Keybuk> it is now?
[04:11] <Kamion> I did that in Paris
[04:11] <Kamion> http://people.ubuntu.com/~cjwatson/sync-blacklist.txt
[04:11] <Keybuk> oh, cool
[04:12] <Keybuk> I'll have to remember to be not rude in that file now :p
[04:12] <Kamion> I de-rude-d the existing contents before publishing :-)
[04:12] <Keybuk> Kamion: I don't know how we'd define those cases ... MoM only deals with source packages
[04:12] <Kamion> it has the list of source packages in Debian though, doesn't it?
[04:13] <Keybuk> aww, I'm sure Marco and Branden wouldn't have minded <g>
[04:13] <Keybuk> Kamion: yes
[04:13] <Keybuk> but I'm not sure how that helps?
[04:13] <Keybuk> those generally need syncs, not merges
[04:13] <Kamion> actually there are sort of two cases - "never sync ever again" and "don't autosync just yet"
[04:13] <Kamion> xfonts-utils is an example of the latter, and needs a merge
[04:13] <Keybuk> right, those are the things at the top of the sync-blacklist
[04:13] <Kamion> yeah
[04:14] <Keybuk> the very top is "keybuk hasn't yet drunk enough coffee to understand these"
[04:14] <Kamion> (Debian - Ubuntu) - "never sync ever again" is approximately what we want
[04:14] <Keybuk> the middle is "other people are dealing with them"
[04:14] <Keybuk> and the bottom is "never sync" :p
[04:14] <bddebian> hehe
[04:15] <Keybuk> if we split sync-blacklist into a temporary and permanent blacklist
[04:15] <Keybuk> then we could easily generate the list on drescher
[04:15] <Kamion> anyway, why am I still awake ... night all
[04:15] <Keybuk> it's output of "new-source"
[04:15] <bddebian> gnight Kamion
[04:16] <Hobbsee> night Kamion
[04:16] <Keybuk> heh, indeed, night all also
[04:16] <bddebian> Bums ;-P  Gnight Keybuk
[04:17] <bddebian> fsck'n a skippy, maxima built
[04:34] <sbalneav> Evening all
[04:34] <Hobbsee> hi sbalneav
[04:35] <sbalneav> Have some unsigned packages made it into the dapper archive, or is ca.archive.ubuntu.com having problems?
[04:38] <bddebian> Is mesa on the blacklist?
[04:40] <bddebian> Oh, NM, it's on the main merges page
[06:31] <bluefoxicy> meh.  I wish I knew more about apt internals.
[06:31] <bluefoxicy> a mirror system like gentoo had would be great
[06:32] <bddebian> reprepro
[06:32] <bddebian> rsync
[06:32] <bluefoxicy> bddebian: ?
[06:32] <bddebian> apt-cache show reprepro
[06:33] <bluefoxicy> bddebian:  no not emerge sync; I mean how it would use mirror://gentoo which would use a mirror list, which you updated with a script that pinged every known mirror and picked the 3-5 closest ones, then it'd round robin through those to distribute load... looking at reprepo
[06:33] <bddebian> Ahh
[06:35] <bluefoxicy> reprepro looks nice, I was thinking about how to get a local repository for a network (i.e. enterprise network, 1 gazillion machines, do you want to hear a story about an idiot that scheduled an ENTIRE school district to update to WinXP SP2 directly from windowsupdate or can you guess what happened?)
[06:35] <bluefoxicy> but I'm currently more concerned that practically everyone who installs Ubuntu is pointing at us.archive.ubuntu.com
[06:35] <bddebian> Oh I can guess, I maintain Windows servers at work
[06:36] <bluefoxicy> yes see smart people sync windowsupdate down to some kind of MFPSomething server I can't remember what it's called and then push patches that way ;)
[06:36] <bluefoxicy> because 3 days without internet sucks.
[06:36] <bddebian> I think it's SPS now but it keeps changing
[06:36] <bluefoxicy> bddebian:  What kind of load DOES us.archive.ubuntu.com experience anyway?
[06:36] <bluefoxicy> more importantly
[06:37] <bluefoxicy> what happens if tomorrow we have 90% market share and MS is dead?
[06:37] <bluefoxicy> update-manager runs apt-get update every day
[06:37] <bluefoxicy> it downloads but doesn't install packages in the background, security packages can be auto-installed........
[06:37] <sharms> well us.archive.ubuntu.com isn't just one server right
[06:38] <sharms> it should be multiple servers using round-robin dns?
[06:38] <bluefoxicy> sharms:  us. seems to imply a specific subset of servers
[06:38] <bluefoxicy> but yes it should, lemme ping it a bunch of times.
[06:38] <bluefoxicy> yes it is.
[06:38] <sharms> just because it is a subset of servers doesn't mean there are not a bunch of them :)
[06:39] <sharms> and you have to remember dns caching will prevent you from hitting all of them via ping
[06:39] <bluefoxicy> yeah, aren't there also canadian and europe and korean servers though?
[06:39] <elmo> sigh
[06:39] <bluefoxicy> PING us.archive.ubuntu.com (<IP_ADDRESS>) PING us.archive.ubuntu.com (<IP_ADDRESS>)
[06:40] <elmo> $cc.archive.ubuntu.com => $cc == country code
[06:40] <elmo> so not "practically everyone" who installs ubuntu will get us.archive.ubuntu.com, just people with a US locale
[06:40] <bluefoxicy> hmm.  It automatically picks based on locale?
[06:40] <elmo> and the load on those servers is fine.  and we're not going to get a 90% market share tomorrow
[06:40] <bluefoxicy> I only speak english so I never tried chinese ;)
[06:40] <elmo> you'd get a better response from people if you didn't invent insane and unrealistic hypotheticals like that
[06:40] <sharms> actually he does have a point though
[06:40] <jsgotangco> try it out
[06:41] <bluefoxicy> elmo:  I'm a security guy, I'm thinking in terms of business continuity now or something.
[06:41] <sharms> security isn't regionally set is it elmo?
[06:41] <elmo> security isn't, no
[06:41] <sharms> right
[06:41] <elmo> and the load on that server isn't a problem either
[06:41] <bluefoxicy> no, but the "What do we do if load spikes by 300 times" scenario is a business continuity thing.
[06:41] <sharms> elmo: it was today for almost an hour
[06:41] <sharms> or atleast the dns
[06:41] <sharms> and we are at .00001% marketshare
[06:41] <bluefoxicy> in security classes they teach you about what you need to do to make sure you can keep a business going if the building it's in burns down.
[06:41] <elmo> sharms: no, it wasn't
[06:42] <sharms> elmo: it was functional and online all day today?
[06:42] <elmo> I took it offline for a very deliberate reason, it wasn't down due to load
[06:42] <elmo> so please, stop with the FUD already
[06:42] <sharms> done :)
[06:42] <bluefoxicy> sharms, elmo:  That brings me to an odd question.  why is it on some days I can get 100K/s from there and on others I get like 800k/s  o_O
[06:44] <bluefoxicy> it's not my end, when my net seems slow I try mozilla, sourceforge, and ubuntu CD image download mirrors to see if I can get over 300k/s from any of them
[06:44] <bluefoxicy> I'd assumed it was load
[06:45] <bluefoxicy> eh.  I guess that's a mystery that'll never be solved.
[06:52] <bddebian> I'd blame elmo if I were you :-)
[06:52] <bddebian> And with that, I will say adeu.  Gnight folks
[06:53] <sharms> same here, take it easy
[08:08] <bluefoxicy> does anyone on edgy know if man 2 open is correct?
[08:09] <bluefoxicy>        int open(const char *pathname, int flags);
[08:09] <bluefoxicy>        int open(const char *pathname, int flags, mode_t mode);
[08:09] <bluefoxicy> this part inparticular.
[08:15] <bluefoxicy> looks like it is.  Thought that was a C++ thing.
[08:19] <fabbione> it is correct.
[08:21] <dholbach> good morning
[08:23] <siretart> Riddell: thanks for handling xine!
[08:25] <fabbione> siretart, slomo_ : ping?
[08:25] <siretart> fabbione: yes?
[08:26] <fabbione> siretart: is it just me or some audio codecs in mplayer are bad?
[08:26] <siretart> fabbione: which ones? I didn't notice regressions yet
[08:26] <fabbione> i need to check..
[08:26] <fabbione> one sec
[08:28] <fabbione> oh meh.. go find the url again..
[08:29] <fabbione> siretart:
[08:30] <fabbione> Opening audio decoder: [mp3lib]  MPEG layer-2, layer-3
[08:30] <fabbione> AUDIO: 22050 Hz, 2 ch, s16le, 40.0 kbit/5.67% (ratio: 5000->88200)
[08:30] <fabbione> Selected audio codec: [mp3]  afm: mp3lib (mp3lib MPEG layer-2, layer-3)
[08:30] <fabbione> '
[08:31] <fabbione> siretart: getting a sample for you
[08:34] <fabbione> siretart: see /msg
[08:36] <dholbach> can somebody please promote libnet-dbus-perl to main?
[08:49] <siretart> dl'ding..
[08:50] <siretart> fabbione: I don't have problems playing that file
[08:50] <fabbione> i do
[08:50] <siretart> I'm on dapper, but I'm using mplayer_0.99+1.0pre8-0ubuntu0, which is a local prerelease of whats in edgy
[08:50] <fabbione> siretart: i assume you are on latest edgy
[08:50] <fabbione> nah
[08:50] <fabbione> it could be anything else like a shared lib
[08:51] <siretart> I prepared the ubuntu1 upload, there are no code changes to ubuntu1
[08:51] <siretart> thats not unlikely, that some linked lib does foo
[08:51] <siretart> MPEG-PS file format detected.
[08:51] <siretart> VIDEO:  MPEG1  176x112  (aspect 12)  29.970 fps  200.0 kbps (25.0 kbyte/s)
[08:51] <siretart> hm. nothing spectacular though..
[08:52] <siretart> Opening video decoder: [libmpeg2]  MPEG 1/2 Video decoder libmpeg2-v0.4.0b
[08:52] <siretart> Selected video codec: [mpeg12]  vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2))
[08:52] <fabbione> looks about the same here
[08:52] <siretart> doesn't mplayer use an internal libmpeg2?
[08:52] <fabbione> you are the maintainer and should know..
[08:53] <fabbione> it's only the audio that's crippled
[08:53] <fabbione> the video is good
[08:53] <fabbione> it's like a lot of static noise
[08:53] <siretart> aha?
[08:53] <siretart> I also maintain xine, which I concentrated the last days more
[08:53] <siretart> and xine does have an internal copy.
[08:54] <siretart> but I keep on mixing the 2, they are both a mess to maintain :/
[08:54] <siretart> audio codec is Selected audio codec: [mp3]  afm: mp3lib (mp3lib MPEG layer-2, layer-3)
[08:54] <fabbione> siretart: audio with xine is good
[08:56] <siretart> fabbione: you mean, you get sound, but it is only a lot of noise?
[08:57] <fabbione> siretart: video 100% good
[08:57] <fabbione> audio in xine is good
[08:57] <fabbione> audio in mplayer a lot of noise
[08:57] <fabbione> so yes i get audio but it's bad
[09:01] <siretart> fabbione: can you perhaps try an other audio backend, like, say, oss instead of alsa and vice versa?
[09:02] <fabbione> siretart: i did try to use -ao oss or -ao alsa or -ao esd
[09:02] <fabbione> no changes
[09:02] <siretart> interesting
[09:03] <siretart> the audio stream seem to me to be plain mp3
[09:03] <siretart> you get this as well?
[09:03] <siretart> Selected audio codec: [mp3]  afm: mp3lib (mp3lib MPEG layer-2, layer-3)
[09:03] <siretart> so it does use the same codec for you?
[09:03] <fabbione> Selected audio codec: [mp3]  afm: mp3lib (mp3lib MPEG layer-2, layer-3)
[09:03] <fabbione> yeps
[09:14] <jdub> is there any info on building custom kernels pre-edgy? (i konw it's scary and bad, but i'd like an answer for people who demand it)
[09:14] <Burgundavia> jdub: there might be something in the help wiki
[09:14] <siretart> fabbione: do you have a chance to try on another machine? I suspect problems in your sound card driver
[09:15] <fabbione> siretart: it did work with the last kernel and stuff right before the last update of mplayer
[09:15] <fabbione> that means the sound card driver is good
[09:15] <Burgundavia> jdub: all of that should now be on the help wiki
[09:16] <jdub> Burgundavia: 'that' -> dude, there is mountains of stuff on the real wiki
[09:16] <siretart> fabbione: so downgrading to dapper's mplayer does fix things for you?
[09:16] <Burgundavia> jdub: yes, but if it was documentation, it should have moved
[09:16] <Burgundavia> jdub: if it didn't, please tell us
[09:16] <jdub> Burgundavia: what *isn't* documentation on the real wiki?
[09:17] <jdub> edgy stuff: https://wiki.ubuntu.com/KernelCustomBuild
[09:17] <fabbione> siretart: i didn't check that yet. I did watch movies 2 days ago or so.. it was good... yesterday upgrade no good.. so i assume a downgrade will do.
[09:17] <fabbione> siretart: gimme 2 minutes to try it
[09:17] <jdub> Burgundavia: two wikis is a terrible hassle
[09:17] <Burgundavia> jdub: so was one wiki
[09:17] <sivang> morning
[09:17] <jdub> Burgundavia: two is worse
[09:17] <mdke> jdub: it's a bit late for this. You had 9 months to comment on the spec for splitting them.
[09:18] <jdub> mdke: it's not really something for me to contribute to directly, but now that it's happened (and given my comments about exactly this in the distant past), i'm seeing problems
[09:19] <mdke> jdub: it's 3 wikis we have
[09:19] <mdke> don't forget www.ubuntu.com
[09:20] <mdke> if you look at them as websites with different functions, it works.
[09:20] <Burgundavia> mdke: that is not really a wiki, perse
[09:20] <jsgotangco> its not like the public has access to the website
[09:20] <jdub> mdke: i don't regard that as a wiki (but the content seepage between all three (plus docs.u.c) isn't helpful
[09:20] <mdke> my point is not to get hung up on the "wiki" thing
[09:20] <jdub> i'm not hung up on the wiki thing
[09:20] <mdke> you need to see that there is a documentation website, and it is separate from the community development place for a good reason
[09:21] <jdub> i wish i could see it that way
[09:21] <mdke> It's really working well, I think
[09:21] <fabbione> siretart: yes, downgrading works fine
[09:21] <jdub> but you've got plenty of inertia to battle
[09:22] <Burgundavia> jdub: I notice since the move we have been getting lots of new people helping out
[09:22] <jdub> and wuc is easier to contribute to
[09:22] <mdke> no
[09:22] <mdke> people hated contributing to the old wiki, simply because of the confusion and the fact it was terrible to get help on
[09:22] <jdub> Burgundavia: i am not convinced that could not have been done with a clear editorial team on wuc (who could provide some actual content management)
[09:23] <Burgundavia> jdub: we were drowning in non-doc stuff
[09:23] <siretart> fabbione: hm. damn. can you perhaps file a bug, mentioning the codec in question and you audio hardware and driver?
[09:23] <siretart> fabbione: I need to find some hours to trace the code changes since the last release (and there are a lot of changes!!)
[09:23] <jdub> mdke: it has been split now, but i do think that the same goals could have been achieved by managing the existing wiki
[09:24] <mdke> jdub: they couldn't.
[09:24] <jdub> mdke: huc seems a bit like picking up the shovel and bucket and making a new sand castle :-)
[09:24] <jdub> mdke: it seems we strongly disagree on that point, then ;-)
[09:24] <mdke> dunno about strongly
[09:25] <mdke> it's a documentation website. All documentation is now in the same place, hardly a new sand castle
[09:25] <mdke> reinforcing the old one, more like
[09:25] <jdub> mdke: what happens if i link JeffWaugh on huc?
[09:26] <pitti> Good morning
[09:26] <Burgundavia> jdub: that is an issue we have not yet resolved, but can be fairly easily (we can link names to the old wiki)
[09:26] <mdke> jdub: it links to JeffWaugh
[09:27] <jdub> (categories are a good way to layer structure on top of an existing moin wiki - you can limit searches to them, etc.)
[09:27] <jdub> mdke: but JeffWaugh doesn't live in that sand castle ;)
[09:27] <mdke> true
[09:27] <mdke> is it likely that your name will be used in documentation?
[09:27] <jdub> i hope so
[09:27] <jsgotangco> lol
[09:27] <jdub> i would like to be famous some day
[09:27] <Burgundavia> jdub: but then what do you have default search as? what about the in-svn documentation?
[09:27] <fabbione> siretart: meh i just gave you all the info, but it's not a hw/kernel issue
[09:28] <mdke> jdub: use "wiki:Ubuntu/JeffWaugh"
[09:28] <jdub> mdke: hopefully you get my point :)
[09:28] <Burgundavia> jdub: moving the help wiki was not really like creating a new site, it was merely moving the help wiki stuff to the same place that the in-svn stuff was
[09:28] <mdke> it's a non-point, for me
[09:28] <Burgundavia> like mdke, reinforcing, not creating
[09:28] <jdub> Burgundavia: heh, "not really like creating a new site", although you happened to be... creating... a... new... site...? :)
[09:28] <mdke> jdub: nope, it was there already
[09:29] <Burgundavia> indeed
[09:29] <mdke> it had the docs from the distro on it
[09:29] <mdke> now it has all docs
[09:29] <jdub> it was there already, but it wasn't a separate wiki
[09:30] <mdke> here you go again with the wiki thing
[09:30] <jdub> considering that it is a wiki, i don't think that's an obscene idea to muse upon :)
[09:31] <Burgundavia> jdub: like the main ubuntu webpage, the help website is a help website, helped along by the wiki, rather than a wiki first
[09:31] <jdub> Burgundavia: i understand the theory
[09:32] <fabbione> siretart: 52279 for you
[09:34] <siretart> Ubugtu: bug #52279
[09:34] <Ubugtu> Malone bug 52279 in gnome-games "AisleRiot crash by select other game variants" [Unknown,Fix released]  http://launchpad.net/bugs/52279
[09:34] <fabbione> ehm
[09:34] <fabbione> 52729
[09:35] <siretart> Ubugtu: bug #52729
[09:35] <Ubugtu> Malone bug 52729 in mplayer "[EDGY]  Regression: broken audio playing certain movies" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52729
[09:35] <fabbione> siretart: if you need more speak now :)
[09:36] <siretart> fabbione: may I attach the file you gave me?
[09:36] <fabbione> siretart: you should check the copyright before you do so
[09:36] <fabbione> siretart: i don't remmeber the origin of it
[09:36] <fabbione> it was on some funny web site
[09:37] <fabbione> siretart: people can ask me for the file
[09:37] <fabbione> it's not an issue
[09:37] <siretart> ah ok
[09:38] <siretart> I'm checking on my edgy laptop
[09:38] <fabbione> edgy with dapper mplayer is good
[09:38] <chmj> elmo: ping
[09:38] <fabbione> i wonder if it might be due to miscompilation
[09:39] <siretart> fabbione: I'm trying now with 0.99+1.0pre8-ubuntu3 on recent edgy
[09:39] <siretart> fabbione: sound driver: i810 internal on thinkpad r50e, no problems :(
[09:41] <fabbione> it happens reliably here and i can ensure you it's not a kernel issue
[09:41] <fabbione> otherwise the dapper version wouldn't work at all
[09:42] <siretart> what sound hardware do you use?
[09:42] <siretart> fabbione: and can you perhaps check/compare your /etc/mplayer/* against the versions in the package?
[09:43] <siretart> I suspect codecs.conf
[09:43] <fabbione> i didn't customize it
[09:43] <fabbione> Setting up mplayer (0.99+1.0pre7try2+cvs20060117-0ubuntu8) ...
[09:43] <fabbione> Installing new version of config file /etc/mplayer/mplayer.conf ...
[09:43] <fabbione> Installing new version of config file /etc/mplayer/codecs.conf ...
[09:43] <fabbione> Installing new version of config file /etc/mplayer/input.conf ...
[09:43] <fabbione> Installing new version of config file /etc/mplayer/menu.conf ...
[09:43] <fabbione> downgrading/upgrading
[09:43] <fabbione> so i am using the defaults
[09:44] <siretart> 66d11846722498ed54bf5ddc766a95ab  /etc/mplayer/codecs.conf
[09:44] <siretart> 32924d4067d6307a107393834015fa9a  /etc/mplayer/input.conf
[09:44] <siretart> md5sums on my machine.. for you as well?
[09:45] <fabbione> new or old ones?
[09:48] <siretart> the new ones
[09:49] <pitti> slomo_: can you please check the new hal revision into bzr?
[09:52] <fabbione> 66d11846722498ed54bf5ddc766a95ab  codecs.conf
[09:52] <fabbione> 32924d4067d6307a107393834015fa9a  input.conf
[09:52] <fabbione> yeah they match
[09:53] <bluefoxicy> hi pitti
[09:53] <pitti> hi bluefoxicy
[09:57] <bluefoxicy> pitti: mail me a gcc hacker
[09:58] <pitti> bluefoxicy: I always have difficulties squeezing them through the ethernet cable
[09:59] <bluefoxicy> pitti:  ;)
[09:59] <bluefoxicy> pitti:  Did you see my post on -devel?
[09:59] <pitti> bluefoxicy: yes, I saw it, but I didn't have time yet to answer
[10:03] <pitti> Kamion: I want to fix some stuff in anastacia (just did redland-bindings for php4 and will do backuppc for wwwconfig-common), but there are some things I don't understand
[10:04] <pitti> Kamion: do you have an idea why python-jabber wants python2.2?
[10:04] <slomo_> fabbione: pong?
[10:04] <slomo_> pitti: sure, one moment... sorry
[10:04] <siretart> slomo_: see bug #52729
[10:04] <Ubugtu> Malone bug 52729 in mplayer "[EDGY]  Regression: broken audio playing certain movies" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52729
[10:06] <dholbach> can somebody please promote libnet-dbus-perl to main? :)
[10:06] <pitti> dholbach: not without ssh logins
[10:06] <dholbach> pitti: urg, true
[10:07] <pitti> darn, I can't even upload
[10:07] <mdz> pitti: maybe because of this
[10:07] <mdz> pyversions: missing XS-Python-Version in control file, fall back to debian/pyversions
[10:07] <mdz> pyversions: missing debian/pyversions file, fall back to supported versions
[10:07] <pitti> oh, hi mdz
[10:07] <pitti> mdz: hm, I'd expect it to fall back to 2.4.., I'll check that
[10:08] <mdz> my @python_allversions = ('1.5','2.1','2.2','2.3','2.4','2.5');
[10:08] <pitti> mdz: it builds fine here locally, and uses 2.4
[10:08] <mdz> pitti: my local build gets the 2.2 dependency from python:Depends
[10:09] <pitti> ah, right
[10:09] <mdz> pitti: what's wrong with ssh logins?
[10:10] <mdz> dholbach: I'll promote libnet-dbus-perl once cron.daily finishes
[10:10] <fabbione> mdz: known issue at the DC
[10:10] <dholbach> mdz: "chinstrap (-> all DC) logins down - known problem, no ETA currently"
[10:10] <dholbach> mdz: merci beaucoup
[10:11] <siretart> slomo_: fabbione: i just upgraded my edgy laptop, still no problems. I'm off for uni now, cu later!
[10:11] <fabbione> siretart: later
[10:11] <mdz> dholbach: I have a shell open which seems to work fine; I'll try to remember not to logout ;-)
[10:12] <dholbach> mdz: hehe :)
[10:12] <slomo_> siretart: everything i tested with the new mplayer worked fine here too
[10:13] <fabbione> slomo_: do you want the file i have issues with?
[10:13] <slomo_> fabbione: sure
[10:13] <crimsun> fabbione: which arch?
[10:13] <fabbione> crimsun: i386
[10:13] <crimsun> k
[10:14] <mdz> pitti,dholbach: has anyone looked at libcairo-perl yet (MIR)?
[10:14] <fabbione> slomo_: /msg
[10:15] <slomo_> fabbione: thanks
[10:15] <fabbione> slomo_: np
[10:16] <slomo_> fabbione: woohoo... sounds nice ;) weird...
[10:16] <slomo_> and works fine in totem... hm
[10:16] <fabbione> it works in xine too
[10:16] <fabbione> and it works with dapper mplayer
[10:16] <fabbione> it doesn't work with edgy mplayer
[10:17] <fabbione> so that's why i am pretty sure it's mplayer regression
[10:18] <slomo_> ok, noted on my todo list...
[10:20] <crimsun> slomo_: http://svn.mplayerhq.hu/mplayer/trunk/mp3lib/dct64_3dnow.c?r1=18837&r2=18946
[10:21] <slomo_> crimsun: good catch :) thanks, i'll test it
[10:21] <fabbione> crimsun: to add or to revert?
[10:21] <slomo_> add
[10:22] <fabbione> sladen: i can test it locally...
[10:22] <fabbione> slomo_: ^^
[10:22] <slomo_> fabbione: ok, feel free to upload mplayer with that patch if it works :)
[10:22] <pitti> doko: bah, I have no idea how to teach jabber.py to not create a dependency on python2.2; do you have any idea? I added debian/pyversions and played with the build deps, but no luck
[10:22] <fabbione> slomo_: no :) i will tell you if it works..
[10:22] <crimsun> slomo_: fabbione: I haven't eyeballed the diff history further back, so it may require additional the mmx changes
[10:23] <crimsun> the additional ^
[10:23] <fabbione> slomo_: i am not going to adopt mplayer ;)
[10:23] <fabbione> crimsun: ok thanks don't worry :)
[10:24] <fabbione> crimsun: 3d now?
[10:24] <fabbione> might be
[10:25] <fabbione> this is an amd64 cpu running i386
[10:25] <pitti> doko: ah, got it; nevermind
[10:25] <pitti> doko:  one shipped example used #!/usr/bin/python2.2
[10:26] <fabbione> slomo_: you need to get a new cvs snapshot probably.. that patch doesn't apply
[10:28] <mdz> pitti: aha
[10:29] <pitti> mdz: I'll upload a fix as soon as ssh works again and send the patch to debian bug 377813
[10:29] <Ubugtu> Debian bug 377813 in python-jabber "Subject: Uninstallable due to unmet dep on python2.2" [Serious,Open]  http://bugs.debian.org/377813
[10:29] <mdz> pitti: you shouldn't need ssh to upload it
[10:29] <pitti> mdz: I do, I can't ftp from here
[10:29] <mdz> pitti: yuck, why not?
[10:29] <pitti> mdz: so my upload script scp's to chinstap and calls ssh dput
[10:29] <pitti> mdz: braindead configuration of my ISP
[10:30] <pitti> mdz: bah, I'll just do a Debian NMU
[10:32] <\sh> moins
[10:34] <mdz> do we really want cyrus21 in the server seed?
[10:35] <fabbione> mdz: wasn't common agreement to kill it?
[10:35] <seb128> mdz: "gnome-applets is next uploaded and rebuilt" ?
[10:35] <pitti> mdz: if we want cyrus, then 2.2
[10:35] <seb128> mdz: why "new uploaded"?
[10:35] <pitti> (I'd say)
[10:35] <mdz> dunno about that, but it is an old version
[10:35] <seb128> s#new#next
[10:35] <mdz> seb128: "new uploaded"?
[10:36] <ogra> dholbach, g-p-m will still take a while ... the codebase for Kinnison's most important patches that enable suspend doesnt exist anymore and i found out why the icons didnt work, they are all renamed and 24x24 doesnt exist anymore as size (and there are twice as much icons now)
[10:36] <fabbione> mdz: kill it, kill it!
[10:36] <mdz> I thought we already had a cyrus imapd in main
[10:36] <pitti> mdz: but as long as we don't receive requests to include it, we can maybe drop it alltogether
[10:36] <pitti> mdz: we kicked it out of dapper
[10:36] <seb128> mdz: ups, I said nothing, it got stucked because of the gnome-python-desktop borkage and I forgot to upload it then ...
[10:36] <seb128> mdz: thank you for the reminder, fixing that now ;)
[10:36] <dholbach> ogra: then please drop the icon patch - i'm going to fix it up once it's in the archive - that's nothing to be blocked on
[10:37] <mdz> pitti: I don't see it in breezy though
[10:37] <pitti> cyrus21-imapd | 2.1.18-1ubuntu1 | http://archive.ubuntu.com breezy/main Sources
[10:37] <mdz> never mind,there it is
[10:37] <mdz> heh
[10:37] <ogra> dholbach, i know, i didnt say i was blocked :) but there is a lot of icon work on the hirizon for you
[10:37] <mdz> dholbach: promoted libnet-dbus-perl and friends just in time
[10:37] <pitti> mdz: oh, the binary is in universe
[10:37] <ogra> *horizon
[10:37] <dholbach> mdz: rock on!
[10:37] <mdz> dholbach: Connection to chinstrap.ubuntu.com closed by remote host.
[10:37] <dholbach> urg :(
[10:38] <dholbach> ogra: i can't wait for it...
[10:38] <dholbach> :-)
[10:38] <mdz> pitti: ok, I've committed it to my local seeds
[10:38] <ogra> haha
[10:38] <mdz> oh, I should be able to still ssh to the supermirror probably
[10:38] <pitti> mdz: jabber.py NMUed to Debian, so we'll get it this evening
[10:39] <pitti> doko, Kamion: ^ so please don't bother fixing it in Edgy
[10:39] <pitti> oh, tomorrow evening rather
[10:39] <Kamion> you might need to request a special sync for that, UVF being tomorrow and all
[10:39] <pitti> oh, true
[10:40] <pitti> Kamion: ok, I'll ask Keybuk to sync from incoming then
[10:40] <fabbione> what's the official time for UVF to start?
[10:41] <mdz> when we sleep
[10:41] <fabbione> that means never...
[10:41] <ogra> heh
[10:41] <pitti> fabbione: if 'we' == mdz and Europe :)
[10:44] <pitti> mdz: I'm confused why libxmlsec1-gnutls wants to pull in gnutls11 - the package is in universe and depends on libgnutls13
[10:45] <mdz> pitti: I uploaded a fix
[10:45] <mdz> probably anastacia is out of date
[10:45] <pitti> ah
[10:45] <pitti> ok, I uploaded redland-bindings
[10:46] <pitti> that should solve apache and php4
[10:47] <pitti> mdz: dictionaries-common b-deps on links, but that's provided by elinks; the buildds manage to resolve that
[10:47] <pitti> mdz: nevertheless, I'll upload a fix for that, we modified the package anyway
[10:58] <Kamion> infinity: when you're bringing up hppa, could you make sure to build newt before cdebconf? thanks
[11:04] <fabbione> bootstrapping hppa is going to be real fun
[11:04] <fabbione> glibc/kernel/kernel-headers/gcc in an endless loop for ssp
[11:04] <fabbione> and then all the rest of the world
[11:06] <ogra> ogra@edubuntu:/mnt/devel/seeds$ bzr checkout<EMAIL_ADDRESS>[11:06] <ogra> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[11:06] <ogra> meh, LP doesnt like me today :(
[11:11] <pitti> ogra: ssh to chinstrap is broken
[11:11] <ogra> ooh
[11:12] <ogra> but that must have happened between tzhe two checkouts
[11:12] <ogra> i checked out the edubuntu seeds a second before i first tried the ubuntu ones
[11:13] <Kamion> ssh to bazaar.launchpad.net doesn't normally go through chinstrap, so ...
[11:14] <ogra> ah, k, hmm ...
[11:14] <elmo> it's been taken down too, I'm working on it
[11:17] <Hobbsee> ogra: it's not being kind?  doesnt leave me much hope for the kde side then...
[11:17] <elmo> ogra: should work now then
[11:17] <elmo> s/then//
[11:17] <ogra> Hobbsee, the merge is evil
[11:18] <Hobbsee> ogra: :(
[11:18] <ogra> elmo, not yet
[11:18] <elmo> ogra: what error?
[11:18] <ogra> elmo, ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[11:18] <elmo> oh, blah
[11:19] <ogra> (with a paramiko backtrace afterwards indeed)
[11:20] <ogra> Hobbsee, three way megre of the special kind ... we have an old package, debian has one and the upstream source changed completely (not to mention our package has 13 patches included that need merging)
[11:20] <Hobbsee> ogra: *ouch*
[11:20] <Hobbsee> that's nasty
[11:21] <ogra> i could drop 4 of them though and have only 3 left ... but these three are huge and there is no upstream code anymore for them to apply to
[11:21] <ogra> sadly they are the ones that make everything work :)
[11:22] <sivang> anybody else lost some panel functionality and applets after dist-upgrading today?
[11:24] <Zdra> sivang: me too
[11:24] <sivang> Zdra: thanks, /me goes to see if I can fix it
[11:25] <Zdra> :)
[11:36] <janimo> dholbach: hello, FYI latest xfce has ctrl-esc for menu that you missed
[11:37] <dholbach> janimo: ahhhh nice
[11:37] <dholbach> hey janimo - good to see you back :)
[11:37] <sivang> hey janimo
[11:37] <pitti> hi janimo, how's it going?
[11:37] <janimo> pitti, sivang hi guys
[11:37] <dholbach> janimo: i'm used to use alt-f1, but ctrl-esc is better than nothing ;-p
[11:37] <janimo> I am egtting busy agains since xfce just released a new beta
[11:37] <janimo> dholbach: it is settable :)
[11:37] <iwj> LaserJock: pong
[11:37] <dholbach> doko: if you have no objections, I'm going to drop CxxLibraryList, FinishedUniverseLibraries ,CxxLibraryResync, UniverseCxxTransition?
[11:38] <dholbach> doko: ... from the wiki
[11:38] <doko> dholbach: fine
[11:38] <dholbach> doko: thanks
[11:41] <Gloubiboulga> janimo, hi, I have some issues with the mcs manager on edgy
[11:41] <crimsun> janimo: are we proceeding with xfmedia>gxine? If so I'll prioritise the merge today for UVF.
[11:42] <dholbach> Riddell: safe to drop KubuntuCXXtransition from the wiki?
[11:42] <Gloubiboulga> janimo, it can't load the modules which hasn't been built against the last mcs version
[11:42] <janimo> crimsun: I agree with going gxine
[11:42] <janimo> Gloubiboulga: I'll have a look, do you have the latest mcs-manager and mcs-plugins?
[11:43] <janimo> Gloubiboulga: I remember upstream did that to prevent duplicates showing up
[11:43] <Gloubiboulga> janimo, yes, updated a few hours ago. A rebuild fixes everything (I've rebuilt exo, orage, xfce4-session, xfdesktop and xfwm4)
[11:44] <janimo> latest session has not yet been uploaded as we have a big HAL patch
[11:44] <janimo> the rest I'll do uploads again, thanks for noticing
[11:44] <janimo> due to broken debuild I worked from dapper and only now started testing the built stuff in edgy
[11:47] <seb128> janimo: are you doing syncs with Debian for xfce?
[11:47] <Mithrandir> is merges.ubuntu.com down?
[11:47] <janimo> seb128: nope
[11:47] <seb128> janimo: why not?
[11:47] <seb128> Mithrandir: connection refused
[11:48] <janimo> seb128: several reasons
[11:48] <seb128> janimo: everybody else is doing his merges and a stack of xfce are listed on the merge list for main
[11:48] <janimo> seb128: our packages are diverged
[11:48] <seb128> janimo: and they have to be done for tomorrow
[11:48] <janimo> seb128: a stack? (you mean 3 packages)?
[11:48] <pitti> Mithrandir: doesn't work for me either
[11:48] <seb128> janimo: dunno, the list is down atm :p
[11:48] <seb128> janimo: but things like xarchiver are listed iirc
[11:49] <janimo> seb128: oh by merges you mean not necessarily sync from debian, but just get newer versions so the merges do not show up?
[11:49] <seb128> janimo: one of the goal for those merges is to be near of Debian ...
[11:49] <janimo> in this case yes I have been 'merging'
[11:49] <janimo> seb128: could you talk to debian xfce maintainers?
[11:49] <seb128> janimo: no, I mean doing an update based on the Debian package
[11:49] <Kamion> you should be merging packaging from Debian as appropriate too
[11:49] <pitti> janimo: you should use the Debian packaging as long as possible
[11:49] <Kamion> this means that the Ubuntu packages are not just dependent on a single guru who knows how they all work
[11:50] <seb128> janimo: like taking the Debian package, updating for the new version and reapplying Ubuntu changes you need over Debian
[11:50] <janimo> guysm I know this. However xfce deb mainatiners are 'not friendly' to put it mildly, and they have not much time keeping xfce up to date in debian
[11:51] <elmo> ogra: fixed, really.
[11:51] <seb128> janimo: that's not a matter of "uptodate"
[11:51] <seb128> janimo: that's having packaging near of the Debian one
[11:51] <janimo> seb128: they're mostly uptodate now, but not the same as in debian
[11:52] <seb128> the goal of merging is to be near of Debian
[11:52] <seb128> not to be uptodate :)
[11:52] <ogra> elmo, confirmed :)
[11:52] <seb128> is there any reason than the Debian packaging can't be use for Ubuntu?
[11:52] <janimo> seb128: really? tell that to gnome/kde/X/kernel maintainers in ubuntu :)
[11:52] <seb128> janimo: we did merge almost the whole GNOME from Debian since previous week
[11:52] <Kamion> janimo: the Ubuntu X folks have been spending the last week or two merging packaging from Debian, so I'd pick a better example if I were you
[11:52] <sivang> janimo: we could also do it like we do for GNOME , merge debian changes, and then import new upstream.
[11:52] <janimo> seb128: yes, they do not use cdbs all over - I am sure this convinced you ;)
[11:53] <seb128> janimo: even when they use debhelper, we don't have any reason to change the packaging system over them
[11:53] <Kamion> janimo: there are cases for individual divergence, but the default is to do what Debian does
[11:53] <mdz> seb128: gaim seems to honor GNOME proxy settings now, but I am not sure this is a good idea
[11:53] <seb128> we have some GNOME package using debhelper
[11:53] <slomo_> doko: what's the status of the gcc/libgcc breakage on ppc?
[11:53] <seb128> mdz: why not?
[11:53] <janimo> Kamion:, seb128: that is nice. There are 5 debian xfce packagers I ahve repeatedly approached them about friendly merging and sharing
[11:53] <mdz> seb128: it uses CONNECT, and squid by default doesn't allow that for arbitrary ports
[11:54] <doko> slomo_: needs infinity for bootstrapping
[11:54] <Kamion> janimo: we're just saying that the Ubuntu XFCE packages should be incorporating packaging bugfixes from Debian
[11:54] <Kamion> janimo: not that you must be in exact sync with Debian
[11:55] <Kamion> the standard way to indicate that you have incorporated packaging bug fixes is to do a normal merge
[11:55] <Kamion> even if that merge then includes an update to a new upstream or whatever
[11:55] <seb128> mdz: the account preference have a "use the global parameter", you can set it to something else
[11:55] <slomo_> doko: ok... was there a real fix now or only disabling ssp in libgcc on ppc?
[11:55] <janimo> Kamion: I am watching their packages and pick up stuff that is worth it. They don;t do the opposite though
[11:55] <mdz> seb128: oh good
[11:55] <seb128> mdz: do you think we should change the default value to "none"?
[11:55] <Kamion> janimo: ok, but that's unrelated to the point of this merge session
[11:55] <mdz> seb128: I think so; I imagine most proxies do not allow this by default
[11:56] <mdz> seb128: where is that preference? I don't see it under network
[11:56] <seb128> mdz: ok, I'll do speak with upstream about it and change it with the next upload ... could you open a bug on launchpad about it? :)
[11:56] <Kamion> janimo: we have plenty of packages elsewhere in Ubuntu whose Debian maintainers are hostile to us, but we merge from them anyway
[11:56] <janimo> Kamion: I have done a few uploads yetsreday. Even if they no longer show up in the merges list, the fact they still have deltas means it's not as good as it should be right?
[11:56] <seb128> mdz: pick the account you want, edit it, the advanced tab
[11:56] <mdz> seb128: I can tomorrow; it's almost 0300
[11:56] <mdz> seb128: oh, it's per-account
[11:56] <seb128> ok, thank you
[11:56] <tseng> anything with XubuntuY is a "delta"
[11:57] <seb128> some upstream are subscribed to launchpad for gaim
[11:57] <tseng> you should just try to keep it as small as possible
[11:57] <seb128> so we can have the discussion on launchpad :)
[11:57] <Kamion> janimo: sure, but we don't care right now - the point of the merge session is to ensure that we have merged everything from Debian at least once since the dapper release, where possible
[11:57] <Kamion> janimo: still having a delta does not mean the merge session was useless
[11:57] <janimo> Kamion: sure I work on that as well
[11:57] <Kamion> lots of us still have deltas to packages
[11:58] <janimo> Kamion: what I was saying is that beacuse I want near 0 delta, and I know how to get it, I cannot do it w/o debian and they are not interested, hence the divagations
[11:58] <mdz> seb128: more importantly, when I open a conversation, the input box is black on black
[11:59] <mdz> I'll make a note to file thatt one tomorrow also
[11:59] <Kamion> janimo: ok, but as I said, that's orthogonal to what seb is asking for
[11:59] <ogra> wow, seed merges are so much fun ... 6 files 6 conflicts .... sigh
[11:59] <seb128> mdz: ah, I had that issue when I updated to gaim2.0 beta1 some time ago I think, I bugged upstream but didn't reproduce it later
[11:59] <janimo> which channel is heno most likely to be found?
[11:59] <seb128> (I tried to remove my .gaim, install gaim 1.2 again and upgrade)
[11:59] <seb128> mdz: I'll ping upstream about that again then, you can change the colors to the preferences dialog
[12:00] <heno> janimo: hi
[12:00] <mdz> ogra: there was a major seed reorganization during and after the sprint
[12:01] <ogra> mdz, i know :) i'm just in ranting mode, you know ... (i'm merging g-p-m since yesterday morning ... that needs a valave ;) )
[12:01] <janimo> heno, hi the latest xfce has the accessibiliy keyboard dialog
[12:01] <ogra> *valve
[12:01] <janimo> heno: I have not tried it yet though
[12:01] <heno> jamesh: yep I saw the changelog on OSnews or somewhere. Cool!
[12:02] <heno> janimo: is 4.4 on track for edgy inclusion?
[12:02] <heno> or will it be too late?
[12:02] <janimo> heno, it was for dapper too :) but upstream is not in a hurry. we now have 4.4beta2 hopefully we'll have final by edgy
[12:02] <heno> I guess we are at UVF now (!)
[12:02] <janimo> depends on when we freeze
[12:03] <doko> dholbach: ssp is pitti's pit
[12:03] <StevenK> steven@jaded:~% TZ=UTC date
[12:03] <StevenK> Wed Jul 12 10:03:08 UTC 2006
[12:03] <janimo> heno: yes but I think xfce is in the same category as gnome, or at least it was excepted semi-offically for dapper
[12:03] <doko> s/pit/pet/ ;-P
[12:03] <heno> ok, cool
[12:03] <dholbach> doko: ok, good to know :)
[12:03] <StevenK> Not for another 14 hours, it looks like.
[12:03] <pitti> dholbach: re ssp, what's up?
[12:03] <janimo> as xfce is only going towards RC and release I think it is reaosnable to have post UVF  uploads
[12:04] <heno> janimo: right
[12:04] <janimo> pitti: do you know if ivoks or anyone else had a look at the RH printing tool?
[12:04] <pitti> janimo: ivoks had, but it's difficult to adopt, since it uses a lot of RH-specific libs
[12:04] <dholbach> pitti: sealne had a problem with it on #ubuntu-motu (afflib, something he wants to package)
[12:04] <heno> janimo: I see new themes appearing too. Have you seen any high contrast ones?
[12:04] <janimo> pitti: so gnome-cups-manager is staying?
[12:05] <pitti> janimo: ivoks is currently working on a replacement
[12:05] <janimo> heno: no but I was going to ask you this as well. If there are good high contrast themes I'll add them to xubuntu-desktop
[12:05] <pitti> janimo: but g-c-m will remain the default until we have a suitable replacement
[12:05] <janimo> pitti: is it targetted for edgy?
[12:05] <pitti> janimo: might not make it
[12:05] <janimo> pitti: I'll need to talk to ivoks to keep in mind gtk only stuff
[12:06] <heno> janimo: the art team has started on updating the high viz icon set. I'm sure that can be used in xfce as well
[12:06] <janimo> heno, yes, anyting that is a gtk-theme can be  used, so anything from gnome
[12:06] <janimo> bbl
[12:08] <StevenK> Or gnome-cups-icon, anyway.
[12:17] <monomaniacpat> does ubuntu support 1360x768? I have it specified in my xorg.conf
[12:22] <Riddell> dholbach: sure
[12:33] <seb128> I've just uploaded a new control-center which builds a gnome-control-center-dev, it's required by the new gnome-session to build so if somebody could accept and promote it later that would be nice :)
[12:33] <seb128> anyway, lunch time for now, bbl
[12:39] <heno> seb128: I was just looking at the code for that. I'd like to discuss some possible changes to the accessibility config window in the next few days. I'll send you an email with an overview
[12:42] <Kamion> [ Uploading job debian-installer_20060711ubuntu1_source
[12:42] <Kamion> woo
[12:44] <StevenK> I bet that's a fun merge.
[12:45] <ogra> fear my changelog ....
[12:46] <Kamion> StevenK: oh yes
[12:49] <fabbione> Kamion: SCORE!!!!!!!
[12:49] <fabbione> new installer
[12:51] <Kamion> fabbione: save the kneeling for if it builds first time
[12:52] <fabbione> Kamion: i am sure it will everywhere != sparc :P
[12:52] <StevenK> So we should know by this time tomorrow.
[12:52] <Kamion> I've only tested on powerpc
[12:54] <Kamion> sigh, gcc-4.1 FTBFS on powerpc
[12:57] <elmo> LP is going down in 13 minutes, ETD is 10 mins
[01:09] <fabbione> Kamion: gcc on ppc needs bootstrapping
[01:16] <elmo> LP's back
[01:20] <sladen> pitti: I think there was a slightly different patch that debian may have taken for 'linda' that achieves the same aim as the current Ubuntu patch (teaching it about our langpack locations)
[01:21] <StevenK> Yes.
[01:22] <StevenK> sladen: I didn't agree with your patch, and I had already been bugged about localepurge killing Linda's ability to speak.
[01:23] <rodarvus> wow, #ubuntu-devel had gigantic talk this evening
[01:24] <rodarvus> it seems fabbione is feeling better today, given the amount of times he talked :P
[01:24] <dholbach> grmbl help-ubuntu wiki two wikis fullsearch() does not work grmbl
[01:24] <sladen> StevenK: did the other patch that somebody else sent to you (make linda just use gettext rather than trying to do its own thing) make it anywhere?
[01:25] <sladen> StevenK: since that one avoids the need to patch in the extra patch as the lower-level C libraries are already twiddled for Debian
[01:25] <StevenK> Oh, the mygettext thing.
[01:25] <sladen> s/Debian$/Ubuntu$/
[01:26] <StevenK> I was waiting for Debian to hit Python 2.4
[01:26] <StevenK> Since I moved .mo files, I don't think the twiddle in mygettext is needed.
[01:36] <elmo> *.ubuntu.com, launchpad.net etc. are disappearing for a couple of minutes for some essential maintenance
[01:36] <pitti> sladen: I saw the sync; thanks
[01:37] <fabbione> rodarvus: ahaha
[02:05] <doko> slomo_: Debian's 4.1.1-8 didn't show the failure with -fstack-protector, so maybe a problem fixed already upstream; but libgcc now is built with -fno-stack-protector by default
[02:06] <slomo_> doko: ok... i could do some tests with a ssp enabled libgcc in the next week to see if we could enable it again
[02:13] <zul> hey
[02:38] <Riddell> Kamion: could you move libqt4-debug to main?
[02:41] <janimo> how can I find out what's keeping a package in 'needs building' ?
[02:41] <janimo> ex: https://launchpad.net/distros/ubuntu/+source/thunar-archive-plugin/0.2.0-0ubuntu2
[02:42] <pitti> janimo: it just says what it says, the buildds need to catch up
[02:42] <pitti> janimo: oops, https://launchpad.net/+builds looks like if there's a problem
[02:42] <janimo> pitti:  I uploaded last night, I thought it got stuck on something else
[02:43] <pitti> Keybuk: https://launchpad.net/+builds looks bad
[02:43] <gnomefreak> what product would the man page mount.smbfs be? im thinking samba?
[02:44] <pitti> gnomefreak: smbfs package AFAIK
[02:44] <gnomefreak> i tried that
[02:45] <gnomefreak> it wouldnt accept it
[02:45] <pitti> oh, product - well, that would be samba
[02:45] <gnomefreak> i was afraid of that ty
[02:45] <Keybuk> pitti: I think elmo rebooted all of the data centre last night
[02:46] <Keybuk> or even is doing so today
[02:46] <janimo> what's the best place to check what changed between various debian policy versions? i.e from 3.6 to 3.7
[02:46] <janimo> the policy manual does not seem to have a history or changelog
[02:47] <Keybuk> janimo: changelog.gz and upgrading-checklist.txt.gz in the debian-policy package
[02:47] <janimo> Keybuk: ok. I looked at the changelog but missed the other, thanks
[02:49] <Mithrandir> Keybuk: can you give-back totem on amd64, please?
[02:49] <Keybuk> Mithrandir: also given back on sparc and ia64
[02:49] <Mithrandir> Keybuk: cheers
[02:50] <Kamion> Riddell: done
[02:50] <Riddell> thanks
[03:16] <Keybuk> ltsp-manager |    0.0.1-1 |          edgy | source
[03:16] <Keybuk> the source is in main
[03:17] <Kamion> ltsp-manager |    0.0.1-1 |          edgy | source
[03:17] <Kamion> ltsp-manager |    0.0.1-1 | edgy/universe | all
[03:17] <Kamion> oh Keybuk already said that
[03:17] <Kamion> ogra: anastacia doesn't get confused in that kind of way
[03:17] <ogra> thats intresting ...
[03:17] <Kamion> BTW see https://launchpad.net/distros/ubuntu/+source/ltsp-manager, "Component: main"
[03:17] <ogra> how did that end up there ... i never promoted it
[03:18] <Kamion> the person NEWing it probably just thought "oh it's ogra, he's going to want it in main eventually anyway"
[03:18] <Kamion> it should be demoted for now
[03:18] <ogra> yep
[03:18] <sivang> anyone knows who  Michael T. Richter  is ?
[03:18] <ogra> its not ready and the spec wasnt finished or approved since its a pet project of mine
[03:18] <ogra> so it may slowly move to main over time with added features :)
[03:19] <Hobbsee> sivang: https://launchpad.net/people/ttmrichter
[03:19] <Keybuk> Kamion: it was me, I think
[03:20] <Keybuk> and I'm reasonably sure ogra _asked_ me to NEW it into main at the time
[03:20] <Kamion> heh
[03:20] <ogra> Keybuk, dont worry, it will end up in main at some point ... but since the spec wasnt handled at all univers is the right place for now ...
[03:21] <ogra> hmm, i cant remember asking explicitly for main
[03:21] <sivang> Hobbsee: interesting, he's even an Ubuntu member so LP says
[03:21] <ogra> especially since i fear the wrath of pitti :)
[03:21] <pitti> ogra: hm?
[03:21] <Hobbsee> sivang: very
[03:21] <ogra> pitti, for movig stuff to main past your back ;)
[03:21] <pitti> ogra: oh, ltsp-manager ;) (well, that doesn't sound particularly fearsome)
[03:22] <pitti> oh, well, that :)
[03:22] <ogra> it isnt ...
[03:22] <ogra> only a gui to existing scripts that are in main already
[03:22] <pitti> but it should have a certain level of quality for main
[03:22] <ogra> yep
[03:22] <rodarvus> ltsp-manager has a rootkit - or so ogra told me in private :D
[03:22] <Kamion> iwj: you should be able to do that gsfonts-x11 merge RSN
[03:22] <ogra> and its still in development ...
[03:22] <rodarvus> oh, I was not supposed to say this in public :P
[03:22] <ogra> rodarvus, shhh
[03:23] <ogra> damn ...
[03:23] <Keybuk> rodarvus: bit of luck nobody uses edubuntu anyway
[03:23] <ivoks> :)
[03:23] <ogra> Keybuk, hey, we're place 58 (or so) on distrowatch !
[03:23] <zul> heh...ogra owns you
[03:23] <rodarvus> world domination is coming!
[03:23] <sivang> Keybuk: if you have 5 minutes and have something I can bribe you with, I'd really really appriciate it if you went over SysteCleanUpTool and see if you have any more commments, or otherwise promote it to pending approval :-)
[03:24] <ogra> yay
[03:24] <ogra> Keybuk, and dont forget X is in edubuntu hands now :P
[03:24] <Keybuk> ogra: which puts you below "Pentoo", "SLAX", "Puppy", "GeeXboX", "VideoLinux", etc.
[03:24] <ogra> as all the important projects (like ltsp and tuxmath)
[03:24] <Keybuk> though, amusingly, above Novell ... so rock on
[03:25] <tseng> I know some novell employees who would start frothing at the mouth if you mentioned that
[03:26] <tseng> and start pointing at reviews claiming their upcoming release is "even better than ubuntu"
[03:26] <Keybuk> tseng: and in various areas, they're probably right
[03:26] <sivang> Hobbsee: you know him ?
[03:26] <tseng> Keybuk: there are alot of good things to be sure
[03:27] <Keybuk> they've spent a huge amount of money on software development for NLD
[03:27] <tseng> usability testing
[03:27] <zul> tseng: so ubuntu is the touchstone for novell now? pretty sweet ;)
[03:27] <Keybuk> and I don't think that's a bad thing
[03:28] <tseng> while we pave new usability frontiers by breaking gnome in interesting ways
[03:28] <tseng> and Launchpad
[03:28] <Keybuk> heh
[03:29] <ivoks> i find it funny that someone spends lots of many and then came up with "start button", something others allready discovered before then :)
[03:29] <ivoks> them
[03:29] <Keybuk> it's something I've talked to jdub about a lot -- the fact that we don't _want_ to seriously dent Novell or RHEL's market yet ... because we don't spend any money on software development, and they spend HUGE amounts
[03:29] <janimo> Kamion, with the seeds kept in bazaar.lp.net what's their relation to the seeds in ~cjwatson? And is there still a need to mirror my local xubuntu seeds there? I see the cronjob is getting every 15 minutes still
[03:29] <tseng> ivoks: its quite a bit more elegant than "a start button"
[03:29] <iwj> Kamion: Aha.  RSN != now ?  I have it sitting around here I think.  Err, unless I cleaned it up.  Anyway, it was easy.
[03:29] <Keybuk> if we made them disinterested in their Linux distros, we'd lose a lot of our upstreams (like gcc, glibc, most of GNOME, etc.)
[03:29] <mjg59> Keybuk: Right. In a lot of ways, we're as dependent on Novell and RH as we are on Debian
[03:29] <Kamion> janimo: ~cjwatson is a pulled copy of bazaar.lp.net now, for convenience
[03:29] <ivoks> tseng: at least something :)
[03:30] <tseng> Keybuk: totally.
[03:30] <Kamion> janimo: a need to mirror your local xubuntu seeds where?
[03:30] <mjg59> Keybuk: Interestingly, this is something that Sun claim as well
[03:30] <tseng> ivoks: its in the same spot and it launches programs is about the only similarity
[03:30] <ogra> lol
[03:30] <Keybuk> mjg59: in which sense?
[03:30] <sivang> mjg59: they do have some code in GNOME no ?
[03:30] <janimo> Kamion: you had a script which still seems to be running to mirror my local xubuntu seeds on people.u.com (since I did not commit there)
[03:30] <mjg59> That is, their aim is to ensure a thriving market that they can happily live in rather than to utterly dominate it
[03:30] <ivoks> tseng: and what else should it do? :)
[03:30] <ogra> pitti, wwwconfig-common is listed fro main inclusion ?
[03:30] <tseng> ivoks: try it.
[03:31] <mjg59> (At least, this is what certain people in Sun claim)
[03:31] <pitti> ogra: no, I fixed backuppc
[03:31] <Kamion> janimo: it's pulling from bazaar.lp.net, like the others
[03:31] <pitti> ogra: anastacia is just lagging behind
[03:31] <tseng> ivoks: it borrows from ideas from Gimmie
[03:31] <ogra> pitti, ah, cool :)
[03:31] <Kamion> janimo: it's just for convenience - you can ignore it if you like
[03:31] <Keybuk> mjg59: *nods*  I think that's the right thing for Ubuntu -- be the lead of the community distros, and let RHEL and NLD take the corporates ... but certain people would disagree, I'm sure
[03:31] <Kamion> (since bazaar.lp.net doesn't give a web-viewable working copy)
[03:31] <tseng> ivoks: and ties in beagle
[03:31] <mjg59> Ubuntu has done wonders in bringing Linux to people who'd never consider RHEL or SLED
[03:32] <ivoks> tseng: i don't see how beagle is good, but that could be only me :)
[03:32] <tseng> ...
[03:32] <tseng> ivoks: go sit in the corner :)
[03:32] <mjg59> There's absolutely no requirement for us to try to bring Linux to people who are already using Linux
[03:33] <janimo> Kamion: but can I remove my branch on the local server which is mirrored to rookery every 15 minutes? since seeds are on LP now
[03:33] <ivoks> mjg59: yet
[03:33] <mjg59> ivoks: Ever
[03:33] <Kamion> janimo: that was only for dapper - I've just changed the branch there to pull from bazaar.launchpad.net rather than from startx.ro
[03:33] <tseng> ivoks: ever?
[03:33] <jjesse> mjg59:  there is a group in the documentation team that is trying to help out with a switching from windows to *ubuntu guide
[03:33] <pitti> funny, http://security.ubuntu.com/ubuntu has a star trek favicon now :)
[03:33] <Kamion> janimo: so yes, you can remove it now
[03:33] <janimo> Kamion: ok, thanks
[03:33] <mjg59> jjesse: That sounds absolutely excellent
[03:34] <ivoks> mjg59: oh, i have misread you :)
[03:34] <tseng> so I worked with a guy at work about building an ubuntu server in another data center
[03:34] <tseng> as a result he installed kubuntu at home and loves it
[03:34] <jdub> mjg59, Keybuk: grmmmphrrm
[03:35] <tseng> and is totally excited about putting xubuntu on old hardware
[03:35] <tseng> and it being useful.
[03:36] <mjg59> jdub: I'm a pretty firm believer that it's better to get free software to as many people as possible, rather than worry about whice specific free software they're going to use
[03:36] <mjg59> Obviously I have preferences about which free software they should be using, but...
[03:37] <zul> we are converting our servers at work from redhat to ubuntu
[03:37] <tseng> zul: thats taking me forever
[03:37] <Kamion> iwj: when xfonts-utils is up. Mithrandir seemed to think it would just be a sync; were there other local changes?
[03:38] <zul> tseng we only have like 10 servers though
[03:38] <ivoks> i allready did that :)
[03:38] <tseng> yeah, lucky you
[03:38] <ivoks> + i have left the company that didn't want to do that :)
[03:38] <janimo> ivoks: hey, I heard you're working on a printer config tool? is it pygtk based?
[03:39] <ivoks> janimo: yes, pygtk, but atm i'm occupied with my exams, so i'll continue the work trough summer
[03:39] <iwj> Kamion: I don't remember.  I'll look at it tomorrow; I've got a head full of dpkg dependency tangle today.
[03:39] <jdub> mjg59: you'll be pleased with me - there is now a PlasticAnalFlamingDeath page on the gnome wiki
[03:40] <janimo> ivoks: I am interested in such a tool for xubuntu, so just wanted to make sure you try using no gnome libs :)
[03:40] <Kamion> iwj: UVF is *start* of Thursday I believe, so perhaps we can go with Mithrandir's opinion that it can be synced.
[03:40] <dholbach> jdub: i can only find http://live.gnome.org/GiveMeUtf8OrGiveMeDeath on the wiki :-p
[03:40] <pitti> Keybuk: can you please sync jabber.py_0.5.0-1.3.dsc from Debian incoming to clean up some anastacia mess?
[03:40] <ivoks> janimo: no gnome libs... plain simple pygtk
[03:41] <iwj> *start* of Thursday> Oh, bugger.
[03:41] <janimo> ivoks: and gtk2.10 printing stuff instead of libgnomeprint?
[03:41] <iwj> I'll go and read it now.
[03:41] <Keybuk> pitti: in the middle of a daily sync atm
[03:41] <Mithrandir> iwj: gsfonts-x11 is syncable so unless you have something apart from the merge bits of it, I'll ask for a sync.
[03:41] <pitti> Keybuk: want a bug report instead?
[03:41] <Keybuk> pitti: please
[03:42] <ivoks> janimo: i just want the tool that will add/remove/config printers, nothing else
[03:42] <Riddell> tseng: cool stuff
[03:43] <iwj> Mithrandir: There's one change that gets dropped if you just sync.  http://merges.ubuntu.com/g/gsfonts-x11/gsfonts-x11_0.17ubuntu4.patch search for remove_old_fontpath, the change to the value of XF86CONFIG.
[03:43] <Mithrandir> iwj: hm, indeed.  Is that filed in the Debian BTS?
[03:44] <Mithrandir> iwj: also, AIEE at changing xorg.conf/XF86Config with grep.
[03:45] <sivang> ivoks: you said you wanted to talk about backup stuff?
[03:45] <iwj> I don't think it's reported in the BTS.  But it wasn't clear to me whether we want to keep it since it's probably messing about with things that were only relevant in old config files.
[03:45] <ivoks> sivang: hm...? could you remind me?
[03:46] <Mithrandir> iwj: I think so, and so dropping that change should be fine.  IMO, at least.
[03:46] <iwj> Yes, and editing it is a bit grim.
[03:46] <sivang> ivoks: no idea, you just wante to talk about it , and I had to go :-/ I guess youve forgotten
[03:46] <Mithrandir> iwj: ok, so you're fine with me asking for a sync, then?
[03:46] <iwj> Right.  I thought it wasn't needed but I wasn't sure so my upload was going to keep the change but if you also agree it should be dropped then we should sync it.
[03:46] <iwj> Yes.
[03:46] <ivoks> sivang: heh, i really don't remeber :/
[03:46] <Mithrandir> iwj: great, sync requested, thanks.
[03:47] <pygi> sivang, ^_^
[03:47] <iwj> Mithrandir, Kamion: Thanks.
[03:47] <mjg59> jdub: Shame I'm not allowed to read it
[03:47] <jdub> mjg59: sorry.
[03:48] <Kamion> swap you for gparted
[03:48] <iwj> Kamion: No way :-).
[03:48] <Kamion> hate hate hate random whitespace changes *all the time*
[03:49] <Kamion> it would be ok if the result were something sane rather than a different horrible mish-mash each time round
[03:49] <maswan> pitti: http://security.ubuntu.com/conspiracy/ ;)
[03:50] <pitti> maswan: :) I saw the redirection to your mirror, I just found it funny
[03:50] <Lathiat> haha
[03:50] <Hobbsee> hehe
[03:51] <ivoks> it would be nice to see python-lcms
[03:52] <maswan> pitti: security updates is almost as taxing as releases, we've been bumping into our 2Gbit/s networking limit several times, http://www.acc.umu.se/technical/statistics/ftp/monitordata/
[03:53] <jdub> maswan: ooh.
[03:54] <jdub> hooray for the swedish conspiracy infecting ubuntu as well :-)
[03:54] <maswan> :)
[03:57] <jsgotangco> hahaha
[03:57] <Lathiat> maswan: they ubuntu security updates?
[03:58] <maswan> Lathiat: We're hosting security.u.c a while, that's where all the bandwidth use comes from
[03:58] <Lathiat> ah right, you dont usually host it?
[03:59] <maswan> Nope
[03:59] <Lathiat> ah right
[03:59] <Lathiat> damn thats a lot of traffic
[03:59] <Lathiat> perhaps from the kernel update?
[03:59] <maswan> Normally we just host the se.* stuff, but we step in and help out with a few other DNS names now and then.
[03:59] <Lathiat> theyd be quite large
[03:59] <maswan> ooffice is no light-weight either
[04:00] <Lathiat> when did that come out?
[04:00] <maswan> USN-313-1
[04:00] <maswan> Date: Wed, 12 Jul 2006 15:09:24 +0200
[04:00] <Lathiat> oh id gone past it
[04:00] <Lathiat> heh
[04:00] <Lathiat> righto
[04:00] <doko> Kamion, Mithrandir: can anybody else than infinity hand-build a package on a buildd?
[04:01] <Mithrandir> doko: ttbomk, no.
[04:03] <janimo> TheMuso: hi
[04:03] <ogra> janimo, have you seen the changes to the edubuntu-xfce spec ?
[04:03] <fabbione> doko: probably cprov can.
[04:03] <janimo> TheMuso: do you know if orca is planned for edgy (it's in universe now)
[04:04] <janimo> ogra: I am subscribed to it
[04:04] <ogra> oki
[04:04] <janimo> ogra: but do not remember details, are you thinking about anything in particular ?
[04:04] <ogra> janimo, it will cause some extra work on your side the way it was finalized
[04:04] <Keybuk> Kamion: what's the netdev group on Debian for?
[04:04] <janimo> ogra: it's not yet decided how to make metapackages and seeds right?
[04:04] <ogra> janimo, its approved
[04:05] <janimo> ogra: ok, I'll take a look now
[04:05] <ogra> take your time ... i just wanted to notify you
[04:05] <ogra> (we wont be able to jump on it right away anyway)
[04:09] <janimo> ogra I would have preferred gnome-desktop-core + edubuntu-packages instead of splitting xubuntu-desktop but should have commented earlier :)
[04:09] <janimo> as there is an xfce metapcakge already which could be a drop-in for gnome-desktop metapackage
[04:09] <ogra> janimo, its based on mdz's suggestions as it is now
[04:10] <janimo> so are you planning abiword/gnumeric as well or other apps besdies xfce core?
[04:10] <ogra> we'll have a common base and either of us has a toplevel package
[04:10] <janimo> I thought OOo was a requirement for certification exams so should stay in edubuntu
[04:10] <ogra> which gets you into the situation that you have to maintain two seeds indeed ...
[04:11] <ogra> yep
[04:11] <seb128> Keybuk: any idea of why the control-center gnome-applets gnome-session uploads made some hours ago are not published?
[04:11] <ogra> thats what we'll solve in the toplevel package in edubuntu
[04:11] <janimo> so you only need xfce desktop no other additional apps?
[04:11] <ogra> yep
[04:12] <ogra> we'll ship thunar only idf there is space on the CD for example
[04:12] <janimo> and adjusting the existing xfce metapackage (it's close already) and getting that on the edubntu CD without doing anything with seeds is not possible?
[04:12] <Keybuk> seb128: probably stranded or lost
[04:12] <janimo> and split edubuntu-desktop in gnome desktop +edubuntu specific
[04:12] <ogra> we'll need a topleven package that adds the missing bits ... but the xfce package should be our common base
[04:12] <ogra> *toplevel
[04:12] <janimo> right
[04:13] <ogra> edubuntu-desktop will stay as is
[04:13] <Keybuk> seb128: will investigate in a minute
[04:13] <ogra> we'll add a edubuntu-xfce-desktop package that depends on xfce-desktop and adds the missing pieces
[04:14] <seb128> Keybuk: thank you
[04:14] <janimo> so you can just have a new edubuntu-xfce-desktop which is xfce4 plus missing pieces (which overlap edubuntu desktop a lot)
[04:14] <ogra> yep
[04:14] <janimo> but in this case nothing xubuntu needs to change as I see it
[04:15] <janimo> you just use the existing xfce metapckage and build a new edubntu around it
[04:15] <ogra> if the xfce package has the suffuicient bits no...
[04:15] <ogra> anyway, its up to rodarvus to implement it :)
[04:16] <janimo> cool, as xfce4 is not used by xubuntu (it's the old debian xfce all-in-one desktop) and we specify every dep explicitely in xubuntu-desktop I think we're fine
[04:16] <ogra> janimo, then ewe cant use it
[04:16] <ogra> janimo, what we want is the base of xubuntu
[04:16] <ogra> i thought you use the xfce4 package
[04:16] <janimo> but the base of xubuntu is xfce core (which is in xfce4) + non-xfce apps which you said you wont use
[04:16] <Kamion> doko: lamont mind be able to
[04:16] <Kamion> s/mind/might/
[04:17] <janimo> ogra, more or less overlap but don;t use it directly, it's in universe
[04:17] <janimo> but yes we can make a common core to make sure we do not diverge or have other surprises
[04:17] <ogra> janimo, yeah
[04:17] <janimo> I just wanted to be sure  I don't need to split or add extra stuff to xubuntufor this, as a metapackage would do
[04:17] <Kamion> Keybuk: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352713
[04:17] <Ubugtu> Debian bug 352713 in base-passwd "Subject: base-passwd: Please add netdev and powerdev groups" [Wishlist,Closed]
[04:18] <ogra> and to make sure that we dont duplicate meta packages .i.e pulling xfce4 to main would be silly
[04:18] <gnomefreak> tomorrow it he last day for accepting new versions of programs right?
[04:18] <gnomefreak> s/he/the
[04:18] <Kamion> Keybuk: I was planning to ignore that user-setup change for edgy unless told otherwise
[04:18] <janimo> ogra so now xubuntu-desktop directly depends on each xfce component and non-xfce app. xfce4 metapackage depends on xfce components and is in universe
[04:19] <janimo> any xfce meta package that brings xfce core components to edubuntu is fine with me
[04:19] <janimo> and does not need xubuntu seed changes
[04:20] <ogra> janimo, the point of the spec is that you maintain the corfe package and we maintain the add-on package
[04:20] <ogra> *core
[04:20] <janimo> I am happy to help with any other xfce issue though :) if some gnome-like bits are missing or anything that need coding
[04:20] <ogra> since xfce is your domain
[04:20] <janimo> ogra, ok sure I maintain that, only not via seeds. Ok?
[04:20] <janimo> so I keep an uptodate metapackage of xfce core
[04:20] <gnomefreak> atm xubuntu-desktop depends on a gnome app that isnt around yet
[04:20] <ogra> no, i think mdz will object if you dont do it via seeds
[04:21] <doko> lamont: ping ^^^
[04:21] <Keybuk> Kamion: yeah, I just encoutered netdev via dhcdbd
[04:21] <janimo> hmm, will have to see why then. Is it needed for the CD boot menu?
[04:21] <Keybuk> Kamion: we can always add them later if we want
[04:21] <gnomefreak> nvm looks like it was fixed
[04:21] <ogra> janimo, but lets wait until rodarvus and mdz are around ... i'm not the guy who will implement that spec
[04:22] <ogra> (i'll likely maintain the seeds on the edubuntu side, but thats all=
[04:22] <ogra> )
[04:22] <Keybuk> seb128: dude, you'll have to be more specific
[04:22] <Keybuk> WHICH builds are missing?
[04:23] <Keybuk> or are sources missing?
[04:23] <seb128> Keybuk: not builds, but new versions listed
[04:23] <seb128> Accepted gnome-session 2.15.4-0ubuntu1 (source)
[04:23] <seb128> Accepted gnome-applets <IP_ADDRESS>-0ubuntu1 (source)
[04:23] <seb128> Accepted control-center 1:2.15.4-0ubuntu1 (source)
[04:23] <seb128> https://launchpad.net/distros/ubuntu/edgy/+source/gnome-applets by example list
[04:23] <seb128> 2.14.1-0ubuntu3
[04:23] <Keybuk> seb128: they're not missing?
[04:24] <seb128> not <IP_ADDRESS>-0ubuntu1
[04:24] <seb128> hum
[04:24] <Keybuk> see, this is why you need to be more specific <g>
[04:24] <seb128> k
[04:24] <seb128> the example I just gave is clear? :)
[04:24] <seb128> https://launchpad.net/distros/ubuntu/edgy/+source/gnome-applets claims "Current version:  2.14.1-0ubuntu3"
[04:24] <Keybuk> <IP_ADDRESS>-0ubuntu1 has not yet been published, likewise the others
[04:24] <zul> Keybuk: cam you see if vmware-player i did for security actually went to security yesterday?
[04:24] <Keybuk> zul: no, ask pitti
[04:24] <seb128> Keybuk: ok, any idea of why? ;)
[04:24] <zul> pitti: ping
[04:24] <pitti> hi zul
[04:25] <Keybuk> seb128: what time did you upload them?
[04:25] <seb128> Keybuk: around 3-4 hours ago
[04:25] <zul> hi pitti can you check vmware-player for me?
[04:25] <pitti> zul: I released it some time ago, but security updates seem to have trouble trickling trough the mirrors
[04:25] <zul> ah ok...thanks
[04:25] <pitti> zul: I'll wait after next cron.daily and check again
[04:25] <ogra> zul, dont forget about the modules package :)
[04:25] <Keybuk> -rw-r--r--  1 lp_upload lp_upload 2402 Jul 12 11:25 ../ubuntu-queue/accepted/upload-20060712-113230-000626/control-center_2.15.4-0ubuntu1.dsc
[04:25] <Keybuk> that's the one?
[04:25] <zul> ogra: it is the modules package :)
[04:25] <seb128> yep
[04:25] <seb128> one of them
[04:25] <ogra> zul, heh, ok :)
[04:26] <seb128> gnome-session and gnome-applets around the same time too
[04:26] <seb128> I uploaded them before lunch
[04:26] <Keybuk>    70490 | S- | control-center       | 1:2.15.4-0ubuntu1    | 3 hours 50 minutes
[04:26] <Keybuk>          | * control-center/1:2.15.4-0ubuntu1 Component: main Section: x11
[04:26] <Keybuk> it's in accepted
[04:26] <ogra> the buildds are slacking :P
[04:26] <seb128> so that's just the launchpad UI lagging?
[04:26] <Keybuk>    70498 | S- | gnome-applets        | <IP_ADDRESS>-0ubuntu1    | 3 hours 40 minutes
[04:26] <Keybuk>          | * gnome-applets/<IP_ADDRESS>-0ubuntu1 Component: main Section: gnome
[04:26] <seb128> good too
[04:27] <Keybuk>    70500 | S- | gnome-session        | 2.15.4-0ubuntu1      | 3 hours 30 minutes
[04:27] <Keybuk>          | * gnome-session/2.15.4-0ubuntu1 Component: main Section: gnome
[04:27] <Keybuk> those three?
[04:27] <seb128> yep
[04:27] <Keybuk> publisher is dead
[04:27] <ogra> there were many reboots in the DC today ...
[04:28] <Keybuk> yeah
[04:28] <seb128> Keybuk: which would explain why they have not been published :p
[04:28] <Keybuk> LP never comes back from a reboot
[04:28] <sivang> oh dear...
[04:28] <sivang> that sounds nasty
[04:28] <seb128> I'm sure you can get it back to life, thank you :)
[04:28] <sivang> :)
[04:28] <seb128> ;)
[04:28] <ogra> i cant bear seeing Keybuk doing that
[04:30] <Petaris> Is there a doc that will tell me how to compile glibc-2.3.4 for ubuntu?
[04:30] <Petaris> I have searched the wiki at www.ubuntu.com but found nothing
[04:31] <Petaris> Lathiat: I need glibc-2.3.4 to satisfy a pesky app, I want to compile and install it in /opt/lib
[04:31] <Keybuk> why won't the app work with 2.3.6 ?
[04:31] <Petaris> so the system can use 2.3.6 but I can LD_PRELOAD that app with 2.3.4
[04:31] <Keybuk> Petaris: you'd be better off reading the glibc docs
[04:31] <Petaris> Keybuk: I don't know, tech support didn't elaborate
[04:32] <Keybuk> it's pretty much ./configure --prefix=/opt/lib && make && sudo make install
[04:32] <Keybuk> with a couple of days of waiting in the middle
[04:32] <Petaris> Keybuk: Yeah, I have been, but I didn't know if there was anything speacial that had to be done for ubuntu
[04:32] <Keybuk> Petaris: only if you want an Ubuntu glibc package ... which clearly you don't
[04:32] <Petaris> oh, ok
[04:33] <Petaris> also it complains that I am trying to build in the source directory
[04:33] <Keybuk> then don't build in the source directory -- see the glibc docs
[04:34] <Petaris> seems to want to be built in a seperate build directory but I'm not sure how I should move the object files
[04:34] <Petaris> is it as simple as just coping them?
[04:34] <Keybuk> mkdir build && cd build && ../configure --prefix=/opt/lib && make && sudo make install
[04:34] <Keybuk> quite frankly though, if you don't know how to do this, you really shouldn't be doing it ;)
[04:34] <Keybuk> seb128: right, so that's the buildd slave and queue resurrected
[04:35] <sivang> be back later
[04:35] <Petaris> Keybuk: Last time I built glibc I was using Gentoo, and I've never had anything complain about being built in a source dir before
[04:36] <Keybuk> that's a glibc thing, I'm sure
[04:36] <Petaris> oh
[04:36] <seb128> Keybuk: thank you ;)
[04:36] <Keybuk> seb128: still got to resurrect the publisher yet :-/
[04:38] <pitti> Keybuk: that sounds like my security updates could eventually appear, too
[04:39] <Keybuk> 14:39:14 INFO    After paring out any builds for which we lack source, 2443 NEEDSBUILD
[04:39] <Keybuk> right
[04:42] <cpercy> Is jeff bailey here ?
[04:54] <iwj> Well, I haven't changed a line of code yet and I've already found three bugs so far ...
[04:54] <Keybuk> iwj: dpkg?
[04:54] <iwj> Yes.
[04:54] <Amaranth> ...
[04:54] <iwj> Admittedly I think two of these bugs are from the same patch.
[04:55] <iwj> But I'm not doing archaeology now to find out.
[04:55] <iwj> Oh, they're generally too complicated and obscure to bother explaining.
[04:55] <iwj> The best one is that if A conflicts with B and you say dpkg --install A.deb B.deb with neither installed it works.
[05:06] <Kamion> Keybuk,iwj: which reminds me, did I point you guys to http://kitenet.net/~joey/blog/entry/rpm_hell.html ?
[05:06] <Keybuk> yeah you've mentioned that before
[05:06] <Kamion> "RPM uses a "best effort" algorithm when doing upgrades. What actually happened here is that the previous versions were removed as part of the upgrade process, and the newer versions were installed. At least as much as possible. :-) As many files as could be removed from the old install were, and that install was removed from the RPM DB. As much of the new stuff as could be installed was, but the install of some items f
[05:07] <thom> yeah, that bug is really special
[05:07] <Keybuk> RPM famously doesn't bother to check the return value of syscalls
[05:07] <msw> oh that
[05:07] <msw> Keybuk: at least most of the exit() calls in librpm are gone now
[05:07] <msw> (yes, but not all)
[05:07] <Keybuk> their reasoning was that RPM implements a "verify" function, which is more reliable
[05:08] <msw> wow, that bug is _still_ getting comments?
[05:09] <Evaso2> Keybuk: hi, i have talked with tony the n-m pptp plugin developer
[05:10] <fabbione> doko: ping?
[05:11] <Evaso2> Keybuk: the problem is The default installation of pppd on most
[05:11] <Evaso2> distros however, provides an ip-up script which is called by pppd directly
[05:11] <Evaso2> when an IP connection is established
[05:12] <Keybuk> right, making n-m's VPN plugins work properly involves breaking our default installation
[05:13] <Keybuk> n-m works at the cost of "no n-m" working
[05:13] <Evaso2> keybuk: i see that the /etc/ppp/ip-up/ip-up.d/000-usepeerdns use an env variable [ "$USEPEERDNS" ]  || exit 0
[05:14] <Evaso2> Keybuk: we can workaround nm-plugin controlling this env variable so ip-up doesn't modify resolv.conf
[05:15] <Keybuk> Hobbsee: we just sync'd that, why?
[05:15] <fabbione> sfllaw: ping?
[05:15] <Keybuk> Evaso2: feel free, if you can get a working NM VPN setup which doesn't break the system working without NM, we'll gladly accept the patches
[05:15] <Keybuk> fabbione: sick today
[05:15] <fabbione> oh right
[05:16] <Hobbsee> Keybuk: i havent checked the debian version, but the wpa_supplicant parameter for ndiswrapper changed to be wext, instead of ndiswrapper.
[05:16] <Hobbsee> i'm assuming debian version picked it up
[05:17] <Evaso2> Keybuk: ok i talk with the upstream author if it would integrate this feature so all ip-up distro could work around this resolv.conf issue
[05:17] <Hobbsee> because i cant seem to force my ndiswrapper card to use the wpa encryption via knetworkmanager in dapper, and we probably dont want to have that problem in edgy too.
[05:17] <Hobbsee> bleh.  my brain died.  feel free to ignore that.
[05:17] <fabbione> Hobbsee: do you feel like doing 2 merges in main? i will sponsor them
[05:18] <Hobbsee> fabbione: which ones?
[05:18] <fabbione> Hobbsee: wvdial and wvstreams please.
[05:18] <fabbione> Hobbsee: sfllaw is sick so if somebody can take care of those it would be lovely
[05:20] <fabbione> Hobbsee: ok i recall the changes to wmdial to pretty simple. dunno about wvstreams
[05:20] <Kamion> er, I thought I synced xfonts-utils - what happened to it?
[05:21] <Kamion> oh, no, Mithrandir uploaded it
[05:21] <Kamion> Mithrandir: still here?
[05:21] <siretart> Hobbsee: all wifi drivers should be forced to work with wext
[05:21] <Hobbsee> siretart: right...
[05:22] <Kamion> Mithrandir: you forgot to use -sa
[05:22] <Kamion> oh, he's gone - I'll fudge together the upload
[05:22] <fabbione> Kamion: can you get the diff.gz and dsc out of the queue?
[05:22] <fabbione> yeah exactly
[05:23] <Kamion> yup
[05:23] <doko> fabbione: pong
[05:25] <Hobbsee> fabbione: in all honesty, i dont think my brain will get around those merges well enough tonight.  it's about 1.30am at the moment
[05:26] <Hobbsee> fabbione: if i merged it now, i'd be guessing, without a clue of what i was doing - and i dont think that's what you want
[05:26] <fabbione> Hobbsee: ok thanks. Fair enough
[05:27] <Hobbsee> fabbione: usually, i'd say yes.  or give it a shot at least.  but i think tonight, my brain's a bit far gone :P
[05:27] <fabbione> Hobbsee: no problem
[05:28] <pitti> fabbione: I can look at wvdial, I think I roughly know what we changed
[05:29] <Hobbsee> pitti: probably a good idea - i dont see anyone else volunteering for it
[05:29] <fabbione> pitti: ok
[05:29] <Hobbsee> ah ha - this one looks doable (i think)
[05:29] <fabbione> pitti: you can also drop the sparc bit
[05:29] <Keybuk> pitti: you still have mesa on your list, no?
[05:30] <fabbione> pitti: it was wrong
[05:30] <fabbione> Keybuk: mesa -> Robot101
[05:30] <pitti> Keybuk: yes, but no clue about it
[05:30] <fabbione> hem
[05:30] <fabbione> Keybuk: mesa -> rodarvus
[05:30] <Keybuk> ok
[05:30] <Kamion> WTF
[05:30] <fabbione> Keybuk: he is already looking at it
[05:30] <Kamion> STUPID XSF BUILD SYSTEM
[05:30] <Keybuk> Kamion: ?
[05:30] <Kamion>         rm -f debian/*.config \
[05:30] <Kamion>               debian/*.postinst \
[05:30] <Kamion> ...
[05:30] <fabbione> Kamion: you need to call it postinst.in and add a call to genscripts in debian/rules
[05:30] <pitti> fabbione: wvdial? sparc? hmm?
[05:30] <fabbione> note that the postinst needs some special stuff in it
[05:31] <fabbione> Kamion: let me find a snippet for you
[05:31] <Hobbsee> fabbione: tackling wvstreams
[05:31] <fabbione> Hobbsee: good :)
[05:31] <Kamion> fabbione: an example package would be fine
[05:31] <fabbione> Kamion: xorg-server has one very simple postinst.in and one call to genscript
[05:31] <fabbione> Kamion: i was digging it from there
[05:32] <Kamion> thanks
[05:32] <fabbione> Kamion: all the keywords at the beginning are mandatory
[05:33] <Mithrandir> Kamion: bah, sorry.  Also, thanks.
[05:34] <Hobbsee> fabbione: yep, i can do this one.  MoM's weirded out again - saying that a section of debian/rules that look the same to me are, in fact, different.  besides that, in both versoins, they're commented out.  heh.
[05:34] <thom> Robot101: that's some pretty unfortunate delegation right there
[05:34] <fabbione> Hobbsee: perfect.. let me know when you are done and i will upload for you
[05:35] <Hobbsee> fabbione: got a quick place to build it, by any chance?  my machines already building kopete...
[05:35] <fabbione> Hobbsee: yeah send the source here
[05:35] <fabbione> Hobbsee: can you upload to main?
[05:35] <fabbione> f not just send it here
[05:35] <Hobbsee> fabbione: i'm going for MOTU at the next meeting, actually
[05:35] <zul> Hobbsee: yay!
[05:35] <Kamion> fabbione: only if you're using shell-lib ;)
[05:36] <fabbione> Hobbsee: cool
[05:36] <Hobbsee> fabbione: assuming i wake up.
[05:36] <fabbione> Kamion: yes, but it's a good idea to keep it consistent.. really...