[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 <smurf@debian.org>                                    |          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 <jbelmonte@debian.org>                                |           41416 |             164
[12:50] <Kamion> supported+build-depends:libxmlsec1-dev                      | xmlsec1                         | openoffice.org (Build-Depend)                | John V. Belmonte <jbelmonte@debian.org>                                               |         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 (82.211.81.182) PING us.archive.ubuntu.com (82.211.81.151) 
[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 sftp://ogra@bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.edgy
[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 2.15.1.1-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 2.15.1.1-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> 2.15.1.1-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        | 2.15.1.1-0ubuntu1    | 3 hours 40 minutes
[04:26] <Keybuk>          | * gnome-applets/2.15.1.1-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...
[05:36] <Robot101> thom: :)
[05:36] <Hobbsee> fabbione: grabbing a debdiff for you now 
[05:36] <fabbione> Hobbsee: thanks
[05:36] <Kamion> I guess
[05:37] <Kamion> seems like massive overkill for this postinst, but ok
[05:37] <Hobbsee> fabbione: brain freeze - debdiff would be the new version versus the old ubuntu version?  or the current debian?
[05:37] <fabbione> Hobbsee: debdiff oldversion newversion
[05:37] <fabbione> | mail -s'debdiff' fabbione@ubuntu.com
[05:38] <fabbione> Hobbsee: one of the good things about unix.. it's always $command $from $to
[05:38] <fabbione> or at least should be...
[05:38] <Hobbsee> fabbione: i'm more asking which the "oldversion" would be - the old ubuntu, or the old debian?
[05:38] <Hobbsee> i'm assuming the old ubuntu
[05:38] <fabbione> old ubuntu
[05:38] <pitti> fabbione: bah, merging was easy, but Debian's package doesn't build on current edgy (some obscure C++ error); I'm afraid we need to merge wvstreams first
[05:39] <Mithrandir> Hobbsee: that depends on whether you want a reverse diff or not. :-P
[05:39] <Hobbsee> Mithrandir: heh
[05:39] <fabbione> pitti: getting therre...
[05:40] <pitti> maswan: ping
[05:40] <maswan> pitti: pong
[05:40] <pitti> maswan: http://archive.ubuntu.com/ubuntu/pool/main/s/shadow/ now has shadow_4.0.13-7ubuntu3.2.dsc, but security.u.c doesn't yet have it
[05:40] <pitti> maswan: is that a problem on our or your end?
[05:41] <Hobbsee> fabbione: sent
[05:41] <fabbione> Hobbsee: got it thanks
[05:41] <Hobbsee> fabbione: :)
[05:42] <maswan> pitti: We sync hourly, apparenlty it wasn't there at :13 this hour. I can send off a new sync though, if you want.
[05:42] <pitti> maswan: it's a fairly 'OMG the sky is falling' update, I just need it fairly quickly since i have to leave soon
[05:42] <Keybuk> Hobbsee: usually they're different in whitespace
[05:43] <Keybuk> I'd be using -w everywhere, if it wasn't for Python
[05:43] <Hobbsee> Keybuk: yeah, good point
[05:43] <maswan> pitti: Ok, working on getting it here ASAP.
[05:43] <Keybuk> maswan: the archive system wasn't working 30 minutes ago <g>
[05:43] <Keybuk> if you sync now, it will be there
[05:43] <Hobbsee> Keybuk: who's on the tech board meeting this week, approving people?  you?
[05:43] <Keybuk> Hobbsee: there is no tech-board meeting this week
[05:44] <Hobbsee> Keybuk: s/this/next
[05:44] <Hobbsee> i'm glad there isnt, otherwise i'd have to live in the past.
[05:44] <Keybuk> Hobbsee: I'm not sure I understand the question
[05:44] <maswan> Waiting for the rsync, donig a quickie so Packages* will be outdated until pool/ updates (normally we do the two-stage thingie)
[05:44] <Keybuk> I actually won't be present for next week's TB meeting
[05:44] <Hobbsee> Keybuk: right, that answers half of it.  the other half is "who will be?
[05:45] <Keybuk> Hobbsee: I cannot answer for who will be
[05:45] <Hobbsee> Keybuk: okay
[05:45] <Keybuk> why?
[05:45] <Keybuk> the TB is mdz, mjg59, sabdfl and I
[05:45] <Keybuk> sabdfl rarely turns up
[05:45] <Hobbsee> true
[05:50] <Hobbsee> Keybuk: actually, i probably should tell you - applying for upload rights to universe, and was wondering who id' be up against
[05:50] <imbrandon> BenC, ping 
[05:50] <BenC> imbrandon: pong
[05:52] <pitti> maswan: oh, cool, then I can release the other two USNs as well :)
[05:52] <imbrandon> BenC, i got a quickie question about the linux-source-* packaging, specificly is there a reson it dosent show as an upgrade when a new one is avail , like when the kernel is updated ? ( this is a problem for those of us that use non included nic drivers like nvidia nforce )
[05:52] <BenC> imbrandon: it's because you don't have the meta package installed, I would guess
[05:53] <imbrandon> just wondering if there was a specific reason its not upgraded with dist-upgraed also i guess is my question )
[05:53] <BenC> imbrandon: sudo apt-get install linux-686, or linux-386, or whatever flavour it is you use
[05:53] <BenC> same reason
[05:53] <imbrandon> ahh right i do that but also install linux-source-*
[05:53] <BenC> the meta package is the only thing that will keep you up-to-date
[05:53] <imbrandon> right but the kernel does update just not the source
[05:53] <BenC> ah, ok, so there's no linux-meta package for the source
[05:53] <BenC> hmm
[05:53] <BenC> why do you need the source?
[05:53] <imbrandon> right right
[05:54] <BenC> why not use the linux-headers packages, which do have meta-packages?
[05:54] <imbrandon> me specificly i have to recompile my nic drivers against it every update ( but vmware server and other things need it too )
[05:54] <imbrandon> hrm
[05:54] <BenC> the headers provide exactly that
[05:54] <maswan> pitti: pool/main/s/shadow/shadow_4.0.13-7ubuntu3.2.dsc
[05:54] <imbrandon> hrm yea , is there a meta for the headers so they get updated ?
[05:54] <BenC> the source isn't meant for compiling modules
[05:54] <maswan> pitti: can you verify everything got there properly?
[05:54] <pitti> maswan: thanks a lot!
[05:55] <Mithrandir> maswan: my apt seems happy at least.
[05:55] <iwj> Four.
[05:55] <BenC> linux-headers-$flavour
[05:55] <fabbione> pitti: new wvstreams is up
[05:55] <BenC> same as the linux-image metapackage
[05:55] <imbrandon> ahh nice BenC , ok thanks sorry to bother you for something so trivial i'm sure you got lots of wrok to do ;)
[05:55] <pitti> fabbione: yay; I looked at the debian diff, that was the reason for the build failure; however, I'll still test before I upload
[05:55] <fabbione> pitti: ok
[05:55] <elmo> does busybox not have job control or something?
[05:56] <Kamion> ogra: mind if I take care of xfonts-terminus? I think it can be synced
[05:56] <Kamion> elmo: depends on the config
[05:56] <imbrandon> s/wrok/work
[05:56] <BenC> imbrandon: no, but in the future, questions like this belong in #ubuntu, or if it's kernel specific, you can try #ubuntu-kernel
[05:56] <BenC> s/no/np/
[05:56] <ogra> Kamion, fine with me ... i still have a long night ahead with g-p-m
[05:56] <imbrandon> sure thing
[05:56] <imbrandon> ;)
[05:56] <Keybuk> ok
[05:57] <Keybuk> MoM output should be up to date again now
[05:58] <maswan> Mithrandir: well, if you needed samba stuff from universe, it wouldn't be getting happy until about now
[05:58] <Kamion> Keybuk: please unblacklist xfonts-scalable; you have it open
[05:58] <Kamion> it => sync-blacklist
[06:00] <Keybuk> Kamion: ok
[06:00] <Petaris> Keybuk: Would it be detramental to downgrade binutils?
[06:00] <Keybuk> Petaris: dude, you're so going to fuck your system :p
[06:00] <Keybuk> is the rogue app *really* worth it? :p
[06:01] <Petaris> Keybuk: Wouldn't be the first time
[06:01] <Petaris> Keybuk: Orginiztions backup system
[06:01] <Petaris> :/
[06:01] <Keybuk> why not just run breezy instead?
[06:02] <Petaris> Its also an ltsp server and was recomended that I run dapper
[06:03] <Petaris> it seems that this version of binutils issues
[06:03] <Petaris> http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/e0661bd5e211edf4/46305f3dd0c2266a%2346305f3dd0c2266a
[06:04] <Petaris> But I don't know what about it is causing the issue
[06:04] <Petaris> so I guess I can't say for sure that it is a binutils issue
[06:05] <Keybuk> anyone doing speech-tools ?
[06:06] <Keybuk> ok, done it myself (easy -- just a sync)
[06:07] <Kamion> iwj: can I take ttf-freefont from you?
[06:07] <Kamion> I believe it's a sync - the optional-priority business doesn't actually matter because that's overridden anyway
[06:07] <Hobbsee> sigh.  horrid connection tonight, laptop isnt behaving.
[06:08] <Kamion> and honestly, who cares whether a udeb is optional or extra
[06:08] <Keybuk> Hobbsee: probably mdz and mjg59, though you'd have my blessing too
[06:08] <Hobbsee> Keybuk: okay.  i'd have your blessing?
[06:09] <Keybuk> Hobbsee: for ubuntu-dev
[06:09] <Hobbsee> Keybuk: ah :)
[06:09] <Hobbsee> Keybuk: wish you could have an impromtu meeting so i wouldnt have to wake up early for the proper one.
[06:10] <Hobbsee> and be mostly incoheratnt
[06:11] <bluefoxicy> If it's before noon, Hobbsee isn't really awake.  Typing, yes, but not awake.  :)
[06:11] <Hobbsee> bluefoxicy: at 6am though?  
[06:11] <Hobbsee> heh
[06:11] <bluefoxicy> .... ouch.
[06:11] <Hobbsee> very ouch
[06:12] <Keybuk> Hobbsee: you're in .au?  the problem there is when you're awake, the TB are all asleep <g>
[06:12] <Hobbsee> Keybuk: yes, exactly
[06:12] <Hobbsee> Keybuk: currently it's 2am - i'm a night person, not a morning person
[06:12] <Hobbsee> Riddell can testify to that
[06:13] <bluefoxicy> hold the meetings at 3am on a saturday, that way it'll be like 11pm there for hobsee and nobody will really care because we all stay up ungodly late anyway
[06:13] <Hobbsee> haha
[06:14] <Hobbsee> 11pm is 1300UTC - it's not bad.  that's when our kubuntu meetings are now
[06:14] <bluefoxicy> (you may laugh, but I know like 6 people on another network, in the same channel, that are all in my city, that are all still up at 4am x_x)
[06:14] <Keybuk> Hobbsee: which is 6am for mdz
[06:14] <Hobbsee> Keybuk: yeah, ouch.  there's nothing that suits everyone, i know
[06:14] <bluefoxicy> can't you move the meetings around?
[06:15] <bluefoxicy> some people will miss this month's, some will miss next months, but at least you won't torture the same people over and over or lose them off the comittee
[06:15] <Hobbsee> bluefoxicy: could do.  not that many people absolutely must attend - quorums only 3 people, iirc.
[06:15] <Kamion> 2
[06:16] <Hobbsee> Kamion: 3 for kcc.
[06:16] <imbrandon> bluefoxicy, and as small as the kcc is one missing is sometimes a pita
[06:16] <Hobbsee> out of 6 people
[06:16] <Kamion> Hobbsee: oh right, I thought you meant TB
[06:16] <Keybuk> the problem we have with the TB is that 3 of the board are in the same timezone, and soon, all 4 will be
[06:16] <Hobbsee> Kamion: ah, well, i could be, but as far as i know, i'm not suddenly on the TB, making it mandatory for me to be at all meetings :P
[06:16] <Keybuk> which means if we rotate the meeting, then you have meetings without Q
[06:16] <imbrandon> Keybuk, and thats a problem ?
[06:16] <iwj> Kamion: Yes, do.
[06:17] <iwj> I think they took my patch, yes.
[06:17] <Hobbsee> Keybuk: yeah, that's the problem we face too
[06:17] <Keybuk> imbrandon: it's a problem if the meeting time is rotated
[06:17] <iwj> I reported it and they said they would, anyway.
[06:17] <imbrandon> Keybuk, ahh yea
[06:17] <iwj> Kamion: (^ all re ttf-freefont)
[06:17] <bluefoxicy> split meetings
[06:17] <iwj> Must go and catch train to go climbing now.  Talk to you tomorrow morning :-).
[06:17] <imbrandon> bluefoxicy, those suck
[06:17] <Hobbsee> iwj: enjoy!
[06:17] <bluefoxicy> imbrandon:  heh, don't want to hold half this morning and half this afternoon?  :P
[06:18] <Hobbsee> bluefoxicy: urgh, no thanks.
[06:18] <Kamion> iwj: yeah, the Georgian thing was taken AFAICS
[06:18] <bluefoxicy> at least then the people who are still around from the morning can relay things, or in the afternoon there are meeting logs everyone can review
[06:18] <Hobbsee> bluefoxicy: they did that once.  it was very pointless.
[06:19] <bluefoxicy> Hobbsee:  the people that needed to talk with eachother weren't on at the same time?
[06:19] <Hobbsee> bluefoxicy: no, more that they decided everything on the first meeting, and the second was just a rehash of the first
[06:19] <Hobbsee> besides, with people applying for things, it's a bit nasty to leave them hanging for half a day.
[06:19] <Hobbsee> bluefoxicy: you'll understand that, once you go up for membership or something.  they're big and scary :P
[06:19] <bluefoxicy> Hobbsee:  ever applied for a driver's license?
[06:20] <Hobbsee> bluefoxicy: yeah, twice.
[06:20] <bluefoxicy> "Please take this number and wait in this chair.  We'll call you... in about 18 hours."
[06:21] <Hobbsee> bluefoxicy: nah, licencing here is better than that.  and i think i made the guy laugh too hard to pay much attention to my driving for the practical test :P
[06:21] <Keybuk> ok, bluez-utils done
[06:24] <Hobbsee> bluefoxicy: hah.  /me got told she did one of the best parallel parks he'd seen all day.  and then i havent had to do one since.  anyway, this is kinda offtopic
[06:24] <bluefoxicy> yes I was waiting for the topic to go back to normal
[06:25] <Hobbsee> heh
[06:25] <Hobbsee> there is such a thing as normal?
[06:25] <Hobbsee> and why am i still up?
[06:25] <bluefoxicy> because you aren't asleep
[06:25] <Hobbsee> i should be though.  
[06:26] <bluefoxicy> drink some catnip tea?
[06:26] <Hobbsee> night all.
[06:26] <Hobbsee> nah, mroe that i'd just get yelled at a lot.  nothing major.
[06:26] <bluefoxicy> heh no I mean it's a nerve relaxant in humans, it makes you sleep.
[06:27] <bluefoxicy> anyway what were we talking about, meetings... udebs.... 
[06:27] <Hobbsee> yes, meetings
[06:27] <bluefoxicy> yes but you were talking about meetings and you're about to pass out
[06:27] <bluefoxicy> so that topic is kind of dead.
[06:28] <Hobbsee> no, not about to pass out - not too dizzy yet.
[06:29] <pitti> fabbione: can you put the wvstreams diff.gz/dsc somewhere for me to download?
[06:29] <Hobbsee> pitti: did you want me to send you the debdiff?
[06:29] <pitti> Hobbsee: between current Debian and your merged version would be nice, yes
[06:30] <Hobbsee> pitti: you're pitti@ubuntu.com?
[06:30] <pitti> Hobbsee: yes
[06:31] <Hobbsee> what the...that doesnt look right
[06:32] <dholbach> Kamion: you merged gparted! woohooo! :-)
[06:32] <Kamion> aye, god knows whether it'll work
[06:32] <Hobbsee> pitti: http://rafb.net/paste/results/ABpbzC62.html
[06:32] <Kamion> I started it up and played a bit, though not in installer mode
[06:32] <Hobbsee> hey dholbach 
[06:32] <dholbach> hey Hobbsee
[06:33] <pitti> Hobbsee: that's base to current ubuntu; I need current Debian to your merged version :)
[06:33] <Hobbsee> ah crud, i knew something had screwed up there!
[06:35] <Petaris> hrm, maybe I can run it on my Gentoo box instead
[06:35] <Petaris> I'll need to add the drivers of course
[06:36] <Kamion> dholbach: wasn't so much a merge as a recreate-from-scratch, btw
[06:36] <Hobbsee> pitti: that look better?  http://rafb.net/paste/results/QLEbtu85.html
[06:36] <fabbione> pitti: 4.2.2-1ubuntu2 	4.2.2-2.1 	4.2.2-1 <- wvstream.. same upstream version
[06:37] <dholbach> Kamion: i noticed - i hope it wasn't too painful
[06:38] <fabbione> pitti: if the patch doesn't do i have the diff and the dsc
[06:38] <Hobbsee> hehe, thanks fabbione 
[06:38] <pitti> Hobbsee: it'll do, thanks
[06:38] <Hobbsee> or would be if i was awake
[06:39] <Hobbsee> night all!
[06:42] <Kamion> dholbach: could have been worse ...
[06:42] <Kamion> $ zcat gparted_0.1-0ubuntu9.diff.gz | wc -l
[06:42] <Kamion> 1927
[06:42] <Kamion> $ dscdiff gparted_0.2.5-1.1.dsc gparted_0.2.5-1.1ubuntu1.dsc | wc -l
[06:42] <Kamion> 904
[06:43] <ogra> you dropped the 1000 lines that made it work ?  :)
[06:43] <fabbione> seb128: are you still editing the DistroMeeting page?
[06:44] <seb128> fabbione: I've clicked on that page like 10 secondes ago, so yep, let me time to commit the change
[06:44] <fabbione> seb128: sure :)
[06:44] <seb128> people are wiki addict, that's incredible
[06:44] <seb128> I edit a wiki page like once a month
[06:44] <fabbione> seb128: that's my first edit in AGEEES on that wiki
[06:44] <seb128> and every time after 10 seconds somebody ping me to know if I'm still working on it :p
[06:44] <seb128> me too :)
[06:44] <seb128> fabbione: done
[06:45] <sivang> re
[06:45] <fabbione> seb128: thanks :)
[06:45] <seb128> np ;)
[06:47] <jdub> seb128: !!!!!!!!!!!!11111111111
[06:49] <seb128> jdub: gnome-vfs on dbus now? ;)
[06:50] <jdub> :-)
[06:51] <seb128> jdub: lot of dbus love this week, between gnome-vfs, gnome-settings-daemon, gnome-session ;)
[06:51] <jdub> :)
[06:51] <pitti> fabbione: bah, Hobbsee's patch is still broken; can you put diff.gz/dsc somewhere? I don't have time any more to wait for the next cron.daily
[06:52] <fabbione> scp wvstreams_4.2.2-2.1ubuntu1.d* chinstrap:.
[06:52] <fabbione> pitti: they are there
[06:53] <sivang> seb128: could this love have anything to od with unloaidng applets, ALT-TAB broken, CTRL-ALT + arrows broken etc? :)
[06:53] <sivang> (or lack, there of ;-) )
[06:54] <pitti> fabbione: merci
[06:54] <seb128> sivang: no, applets have nothing to do with gnome-session or gnome-settings-daemon and the new gnome-vfs has just been uploaded
[06:54] <seb128> neither with keyboard
[06:58] <ogra> sivang, the applets are 2.14 ... wait for the updated ones :)
[06:59] <sivang> ogra: or I'll grab the src pkg from ftp and build myself until it's built on LP, I am so used to ALT-F2 :)
[06:59] <ogra> ALT-F2 are surely not the applets :)
[07:00] <ogra> thats either gnome-panel or gnome-menus
[07:00] <dholbach> gnome-panel
[07:00] <ogra> Amaranth, haha, i just checked out the latest revisions for willowng 
[07:01] <ogra> "almost look like a real project" is a nice changelog entry :)
[07:01] <Amaranth> :D
[07:02] <Amaranth> it has an installer
[07:02] <Amaranth> although if you install it it probably won't run, i don't have path stuff setup
[07:02] <ogra> and a .desktop file, wohoo
[07:03] <ogra> doesnt matter, lets see that we get a package in asap 
[07:03] <ogra> i.e. tomorrow is UVF ...
[07:03] <Keybuk> which means upload must happen today
[07:03] <Amaranth> so if i release a new version a week from now it doesn't get in?
[07:04] <Keybuk> it doesn't get in without an exception, no
[07:04] <ogra> Amaranth, no, since its developed for us 
[07:04] <ogra> but the initial package should be in the archive before UVF
[07:04] <Amaranth> ok
[07:05] <Amaranth> well, i don't know how to package a daemon so... :)
[07:05] <ogra> i prepared some package stuff already, just havent pushed it up, wait a sec
[07:05] <Amaranth> ok
[07:05] <ogra> thats all stuff we can solve later ... for now it should just be there :)
[07:14] <ogra> Amaranth, http://people.ubuntu.com/~ogra/bzr-archive/willowng/ merge that ...
[07:14] <ogra> should have basic packaging stuff
[07:24] <Keybuk> ok, I've switched MoM's status reporting to UVF mode now
[07:24] <Keybuk> so any new merges that show up with the next cron.daily are obvious, and we can easily decide whether to consider them outstanding or not
[07:25] <Amaranth> ogra: that's a stock dh_make run :P
[07:26] <Amaranth> i can make a cdbs package
[07:27] <ogra> bah
[07:27] <ogra> but as you like
[07:27] <ogra> Amaranth, its your project, i'm only helping :)
[07:27] <Amaranth> heh
[07:27] <Amaranth> the only thing i need help with is the init script and /etc/defaults stuff
[07:27] <ogra> so make your decision sinc you will maintina it 
[07:27] <Amaranth> and iptables
[07:28] <ogra> god, i should learn to type
[07:28] <ogra> iptables is for later 
[07:29] <ogra> make it cdbs then :)=
[07:34] <bddebian> Heya folks
[07:35] <jjesse> hiya bddebian
[07:35] <bddebian> Hi jjesse
[07:35] <bddebian> Sorr for the OT question but any PKI experts around I could talk to offline?
[07:37] <Burgwork> bddebian, PKI as in gpg keys?
[07:37] <bddebian> Well digital signatures, yes
[07:38] <Burgwork> hmm, maybe Kinnison?
[07:46] <bddebian> BTW, hi Burgwork
[08:09] <rodarvus> mdz: how many hours do we have before UVF?
[08:09] <mdz> rodarvus: unspecified
[08:09] <rodarvus> *nods*
[08:09] <mdz> rodarvus: roughy end of the day tomorrow
[08:09] <mdz> roughly
[08:09] <rodarvus> ahn, plenty of time, then
[08:09] <Keybuk> mdz: let's not make it end of day tomorrow
[08:10] <rodarvus> i'm build-testing mesa right now, but was worried that UVF was in practice by midnight today
[08:10] <Keybuk> let's make it 0000UTC
[08:10] <Keybuk> end-of-day-tomorrow means we'll take in two more debian days
[08:10] <rodarvus> Keybuk: thats what I'm afraid of :D
[08:11] <janimo> rodarvus, mdz :  I have talked to ogra earlier about edubuntu-xfce. Does it necessarily need new seeds, is a simple metapackage to cover xfce core apps not enough?
[08:12] <mdz> Keybuk: we can shut off the sync prior to UVF
[08:12] <mdz> I assumed rodarvus wanted to know how much time he had to get merges and new versions in
[08:12] <hunger> Is it known that gsfonts-x11 and xfonts-intl-european are broken in edgy right now?
[08:13] <rodarvus> mdz: right
[08:13] <rodarvus> mesa just finished building, I'll finish tests now
[08:13] <Keybuk> mdz: we can't shut off the mom merge sync though
[08:13] <rodarvus> so hopefully even midnight today won't be a problem
[08:14] <Keybuk> we're in the best situation _now_ merge and sync wise
[08:14] <Keybuk> I'd rather we looked at what comes in from Debian in an hour's time, and make a judgement call then whether to declare us frozen or take the new day
[08:14] <fabbione> hunger: yes. all X fonts are broken atm
[08:15] <mdz> Keybuk: sure
[08:15] <gnomefreak> they are?
[08:15] <mdz> but I'm happy for rodarvus to merge mesa tomorrow morning
[08:15] <gnomefreak> ah i see the new updates nvm
[08:15] <mdz> to upload it, that is
[08:15] <mdz> fabbione: upgrading considered harmful?
[08:16] <fabbione> gnomefreak: no, but given that nobody either read topic or understand what is happening, it doesn't really make any different if they are not
[08:16] <janimo> is bumping our version to match debian's even though we have different packages considered a good thing, just to get the packages off the list?
[08:16] <fabbione> mdz: no X upgrade is safe.
[08:16] <gnomefreak> fabbione: true
[08:16] <Keybuk> mdz: yup, it doesn't seem sensible to declare that any outstanding merges have missed the boat
[08:16] <fabbione> mdz: only fonts will be holded-back.
[08:16] <mdz> fabbione: "no, it is safe to upgrade X" or "no X upgrade is ever safe"?
[08:16] <Keybuk> however it does seem sensible to draw the line between outstanding merges and "new stuff"
[08:16] <fabbione> mdz: the former.
[08:16] <mdz> ok
[08:16] <Keybuk> today is good because Debian is conveniently rather switched off <g>
[08:17] <fabbione> Keybuk: mind to check if the fonts stuff Kamion/Mith uploaded are building or need a kick?
[08:17] <Keybuk> fabbione: latest by-hand publisher run just finished
[08:17] <Keybuk> about to kick the build sequencer
[08:17] <fabbione> mdz: the -driver -> -video transition is completed
[08:17] <fabbione> mdz: all stuff except secondary apps have been merged. 
[08:18] <fabbione> mdz: the list was just too long for 2 weeks of work..
[08:18] <Keybuk> https://launchpad.net/+builds/+build/227834
[08:18] <Keybuk> fabbione: ^ built
[08:18] <fabbione> mdz: and fonts are sorting themselves out in these cron.keybuk
[08:19] <Keybuk> https://merges.ubuntu.com/main.html
[08:19] <Keybuk> ^ that is now accurate
[08:22] <mdz> nice
[08:22] <gnomefreak> edgy is gonna have ff 1.5.0.4 as final?
[08:23] <Keybuk> Colin's asked for a UVF exception for installation-guide given it's doc only
[08:23] <Keybuk> jbailey is doing initramfs-tools at the moment, and should be uploaded today
[08:23] <Keybuk> rodarvus is doing mesa right now
[08:24] <Keybuk> I'm going to do n-m in a bit
[08:24] <Keybuk> g-p-m is allegedly "tricky" and involves an upstream version update
[08:24] <Keybuk> mvo is on holiday, and the only person who knows gdebi well enough
[08:25] <Keybuk> enigmail was a messy one, and really needs someone who knows Mozilla stuff
[08:25] <Keybuk> xfce4-* no idea, ask janimo :)
[08:26] <janimo> working on it now
[08:26] <janimo> just asked a few lines above if it's ok to bump the version no to match debian's even though we are not that much in sync
[08:26] <sivang> Keybuk: there's also gdebi and enigmail
[08:27] <Keybuk> sivang: I mentioned those above
[08:27] <Keybuk> janimo: I've tended not to (cf. bootchart) ... it's enough to know we're not keeping in sync
[08:28] <mdz> seb128: gnome-applets ftbfs
[08:28] <mdz> http://librarian.launchpad.net/3387554/buildlog_ubuntu-edgy-i386.gnome-applets_2.15.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[08:30] <fabbione> mdz: i will also need an exception for the redhat cluster suite as i noted also for the meeting update
[08:30] <fabbione> mdz: the stuff is changed too much upstream
[08:31] <sivang> Keybuk: oh right, scary merges...
[08:31] <Keybuk> fabbione: source package name changed in Debian?
[08:32] <fabbione> Keybuk: it doesn't exist in Debian
[08:32] <fabbione> Keybuk: they have some (unmaintained) bits in Debian
[08:33] <Keybuk> hmm?
[08:33] <Keybuk> there's a redhat-cluster package in Debian
[08:33] <Keybuk> which has roughly the same set of binaries as our redhat-cluster-suite
[08:33] <fabbione> the what?
[08:34] <Keybuk> http://packages.debian.org/src:redhat-cluster
[08:34] <Keybuk> even the package descriptions roughly match ours
[08:35] <fabbione> Keybuk: i am ready to bet it's a package that Debian stole from me and forked
[08:35] <fabbione> without even telling me
[08:35] <fabbione> it's not the first or the last time i see that happening on these kind of stuff
[08:35] <Keybuk> might be worth comparing them
[08:35] <jdub> haha
[08:36] <fabbione> Keybuk: already did
[08:36] <fabbione> it's the old -stable suite we had in dapper
[08:36] <fabbione> and highly buggy btw
[08:36] <Keybuk> so it should stay blacklisted?
[08:37] <fabbione> waldi didn't add a lot of the fixes i did with upstream
[08:37] <fabbione> yes please
[08:37] <Keybuk> should we not change our source/binary package names to match, so it has the potential to be sync'd later?
[08:37] <Keybuk> and just keep our version > ?
[08:38] <fabbione> Keybuk: i won't bother.. their package is trash
[08:40] <Keybuk> *nods*
[08:40] <Keybuk> right, gonna get some food, bbiab
[08:40] <ogra> Keybuk, i'm on g-p-m (since yesterday already
[08:40] <ogra> )
[08:40] <ogra> so dont bother
[08:40] <fabbione> Keybuk: clearly that package was never tested at all :) i can tell you from some stuff in there ;)
[08:46] <janimo> jdub: hi, did you manage to get any info on the GnomeClient API future at guadec?
[08:49] <rodarvus> merged mesa is available at -> http://people.ubuntu.com/~rodarvus/mesa/ - it would be nice if someone could review this merge before I upload it
[08:49] <rodarvus> debdiff from debian is http://people.ubuntu.com/~rodarvus/mesa/mesa_6.4.1-0ubuntu8-to-mesa_6.4.2-1ubuntu1.patch.gz
[08:50] <rodarvus> debdiff from ubuntu is http://people.ubuntu.com/~rodarvus/mesa/mesa_6.4.2-1-to-mesa_6.4.2-1ubuntu1.patch.gz
[08:50] <rodarvus> (second one is rather large, though, as its a different upstream version)
[08:54] <seb128> mdz: thank you, I will fix that
[08:56] <mdz> seb128: is there any information I should file with my gaim bugs?
[09:01] <seb128> mdz: I don' think so, if upstreams need something I'm sure they will ask
[09:05] <rodarvus> fabbione reviewed mesa (there was one Conflicts/Replaces/Provides missing for mesa-swrast-source -> mesa-swx11-source)
[09:05] <rodarvus> fabbione: thanks!
[09:05] <rodarvus> I'll upload mesa *now*
[09:05] <rodarvus> :)
[09:07] <profoX`> good day
[09:08] <profoX`> where can I find the stuff for the on screen display when I press the volume up/down button on my laptop ? I need to change something there for IBM laptops (because they have hardwaredriven volume adjustment)
[09:10] <xpotato> i have a thinkpad at home, but i've never fiddled with the volume control buttons with ubuntu
[09:10] <fabbione> rodarvus: nice...
[09:11] <fabbione> ok i call this a day
[09:11] <xpotato> profoX`: try http://ibm-acpi.sourceforge.net/
[09:11] <fabbione> good night
[09:11] <rodarvus> fabbione: good night
[09:11] <sivang> night fabbione 
[09:12] <profoX`> xpotato: i have that, by default, but that doesn't take care of things on the ubuntu side, in acpi everything works perfectly, but i want it to work like it has to in ubuntu so i'd like to create a patch, but i don't know where to find the thing that drives the on screen display for the volume etc. (and i will also add one for brightness for IBM)
[09:13] <xpotato> profoX`: oh...well you're farther along than I thought you were
[09:14] <xpotato> does anyone know the status on the development of the apache 2.2.x packages for debian?
[09:14] <Keybuk> the GNOME bit is just gnome-settings-daemon somewhere
[09:14] <Keybuk> it responds to key press events
[09:14] <xpotato> or ubuntu*
[09:14] <ogra> xfonts-scalable postinst warning: update-fonts-scale --x11r7-layout Type1 failed; font directory data may not be up to date
[09:14] <ogra> usage error: unrecognized option
[09:14] <ogra> Usage: update-fonts-alias DIRECTORY ...
[09:14] <ogra>        update-fonts-alias { -h | --help }
[09:14] <sivang> ogra: I got that today for gsfonts-x11
[09:14] <profoX`> xpotato: yea... i guess no one knows where i would need to look ?
[09:15] <ogra> shouldnt that depend on the right version to have --x11r7-layout ?
[09:15] <rodarvus> ogra: all font packages are failing right now
[09:15] <msw> Keybuk: the volume/brightness bits on thinkpad aren't keysyms
[09:15] <rodarvus> Mithrandir already uploaded xfonts-utils
[09:15] <rodarvus> which should take care of this
[09:15] <rodarvus> but its not in the archive
[09:15] <ogra> rodarvus, why ? i thought that why we waited with the fonts
[09:15] <ogra> ah, k
[09:16] <rodarvus> ogra: font packages triggered this before than expected, due to dh_xinstallfonts (or someting like this, I forgot now)
[09:16] <ogra> dh_installxfonts, yep
[09:17] <xpotato> profoX`: which thinkpad do you have?
[09:18] <profoX`> xpotato: T40
[09:19] <rodarvus> Keybuk: most of my xserver-xorg-input-* builds are not completed in sparc|powerpc|ia64 - and they have been uploaded ~24 hours ago
[09:20] <rodarvus> are xserver-xorg-input-* so low priority to build, or anything happened to the build daemons?
[09:21] <xpotato> profoX`: you may have already seen this, but here's some more information on the T40 https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadT40
[09:21] <xpotato> profoX`: if I was at home, I might be able to help you out a little more
[09:23] <xpotato> does anyone have any idea on the status of the apache 2.2.x packages?
[09:23] <xpotato> or if there are going to be any packages?
[09:24] <profoX`> xpotato: they didnt even make a note about the hardware volume
[09:24] <profoX`> I just want to improve ubuntu so that it works like it actually should when edgy is here ;)
[09:25] <profoX`> (yea, it is starting to annoy me on my laptop :X)
[09:25] <rodarvus> oh, btw - the mesa upload has some (four, I think) new packages
[09:25] <xpotato> profoX`: about a quarter of the way down the page: Hardware volume switch - Tested OK
[09:25] <rodarvus> I suppose they'll go through NEW, right?
[09:28] <Keybuk> rodarvus: yeah, they will
[09:29] <mdz> I thought pitti fixed python-jabber
[09:30] <profoX`> xpotato: that doesn't mean anything, yes, the "buttons" do work, but ubuntu doesn't handle it like it should, most volume switches just send a command to raise or lower volume to the software, but in IBM Thinkpad it changes volume itself (from 0 to 15) so sometimes I see volume: 0 in alsa and I still hear sound, and stuff like that, in this case alsa volume and hardware volume should be seperated
[09:31] <mdz> profoX`: bug 46230
[09:31] <Ubugtu> Malone bug 46230 in hotkey-setup "ThinkPad T42 mute button does double duty" [Low,Rejected]  http://launchpad.net/bugs/46230
[09:32] <xpotato> profoX`: sorry, I just realized what you were looking for; I had that same problem in Mac OS X when I tried it out on my thinkpad (volume could be set to 0 and I'd still hear sound, hardware keys did not bring up the OSD like it should)
[09:32] <profoX`> lol rejected so i can work on it anyway
[09:33] <profoX`> mdz: like i said, the hardware should be seperated from the software, that causes this issue too
[09:34] <mdz> profoX`: you'll notice that I reported the bug and said the same thing
[09:34] <profoX`> I just have to patch the code that brings up the OSD to read in the volume from /proc/acpi/ibm/volume if its there
[09:34] <mdz> profoX`: and now you know who to talk to about it, and where to follow up
[09:34] <profoX`> mdz: yes thanks i'll read it in a second, it's in my next vdesktop :)
[09:35] <mdz> rodarvus: it looks like x11proto-print needs review for main
[09:36] <mdz> rodarvus: unless we can move libxp to universe, which would be better
[09:36] <Kamion> ogra: xfonts-utils didn't make it through quite as quickly as I expected it to, due to the soyuz breakage
[09:36] <Kamion> but never mind, it'll clear up
[09:36] <mdz> I think it's deprecated upstream
[09:36] <Kamion> mdz: libxp is explicitly seeded for third-party apps IIRC
[09:36] <ogra> Kamion, ta ... g-p-m will keep me busy enough :)
[09:36] <Kamion> also a few stray dependencies elsewhere
[09:36] <mdz> Kamion: yeah, Java I think
[09:36] <Kamion> ogra: a versioned depend would be correct, I agree
[09:37] <ogra> yeps, but now we have the breakage anyway :)
[09:37] <mdz> I think it's only java, and we do have a better answer for that these days
[09:37] <mdz> well, for sun
[09:37] <mdz> not IBM
[09:38] <Kamion> ogra: the new xfonts-utils is in the archive now
[09:39] <rodarvus> mdz: x11proto-print was not done by me, but I can take a look at this issue later today
[09:39] <rodarvus> (in a few minutes, actually)
[09:39] <mdz> rodarvus: libxp depends on it now
[09:45] <mdz> Keybuk: what are 'new merges'?
[09:45] <Keybuk> mdz: ok, so this is the "post-UVF mode"
[09:45] <rodarvus> mdz: I'll take a look at it now
[09:45] <Keybuk> updated is as before, packages which have had an upload to edgy and where the Debian version is still higher
[09:46] <Keybuk> new are packages which have not been uploaded to edgy yet, and where the Debian version is higher
[09:46] <rodarvus> Keybuk: do you know if is there any problem with the upload queue? I haven't received any email feedback from my mesa upload (and it happened ~40 minutes ago)
[09:46] <Keybuk> (where uploaded to edgy does not include syncs, btw)
[09:46] <mdz> ok, that makes sense except for the bit where UVF hasn't actually started yet ;-)
[09:46] <rodarvus> not even a rejection email
[09:46] <Keybuk> and outstanding merges is as new, except driven by a text file list
[09:46] <Keybuk> right, see ^^
[09:46] <slomo_> rodarvus: uploaded with "unstable" as distribution by accident maybe? at least i never got a rejection mail for that in the past ;)
[09:47] <Keybuk> I switched on the mode early so it's obvious which things turn up when Debian's cron.daily runs
[09:47] <mdz> rodarvus: it failed
[09:47] <Keybuk> and then we can decide whether to take them or not
[09:47] <Kamion> slomo_ is correct
[09:47] <Kamion> http://librarian.launchpad.net/3390302/goyJX0fqm6A5LxH4KXYqEEUNKsJ.txt
[09:47] <mdz> rodarvus: Distribution: unstable
[09:48] <Keybuk> new merges show up under "new", and if we decide that we want it for UVF, I'll just add it to outstanding-merges.txt
[09:48] <rodarvus> mdz: thanks
[09:48] <mdz> is there a bug open about the fact that soyuz doesn't send mail in that case?
[09:48] <mdz> slomo_: ^?
[09:48] <sivang> mdz: I'm checking
[09:48] <Kamion> mdz: yes
[09:48] <Kamion> I whined about it ages ago
[09:49] <Kamion> https://launchpad.net/products/qprocd/+bug/35965
[09:49] <Keybuk> there did used to be a mail
[09:49] <Ubugtu> Malone bug 35965 in qprocd "exceptions in process-upload not communicated to uploader" [Medium,Confirmed]  
[09:49] <Keybuk> but then they got rid of it
[09:49] <Keybuk> you used to get an "upload made it out of main loop" mail
[09:49] <Kamion> Keybuk: really? AFAIK Soyuz has never mailed for that since it went into production
[09:49] <Kamion> interesting
[09:50] <Keybuk> they disabled them because they contained python exception tracebacks or something
[09:50] <Keybuk> or maybe it was because they didn't contain any useful exception traceback
[09:52] <pygi> sivang, poke? :P
[09:53] <rodarvus> Keybuk: any info on the xserver-xorg-input-* issue I mentioned above?
[09:53] <Keybuk> rodarvus: could you be more specific?
[09:53] <givre> hi guys, i have an urgent request to ask, i don't know how to put so i just ask it there. It's could be great if you could change the description of the server install CD
[09:53] <Keybuk> ie. give me a proper source package name, for a start ;)
[09:54] <givre> many people are confuse by the description:Server install CDThe server install CD allows you to install Ubuntu permanently on a computer.
[09:54] <Kamion> Keybuk: for the record I'd like new mdcfg + partman-lvm + partman-md from this Debian cron.daily
[09:54] <rodarvus> sure
[09:54] <Kamion> givre: file a bug on launchpad.net/products/ubuntu-cdimage/+filebug
[09:54] <Kamion> givre: also explain why this is urgent
[09:54] <Keybuk> Kamion: *nods*
[09:54] <rodarvus> https://launchpad.net/distros/ubuntu/edgy/+source/xserver-xorg-input-spaceorb/1:1.0.0.5-2ubuntu1 , https://launchpad.net/distros/ubuntu/edgy/+source/xserver-xorg-input-summa/1:1.0.0.5-2ubuntu1 and https://launchpad.net/distros/ubuntu/edgy/+source/xserver-xorg-input-tek4957/1:1.0.0.5-2ubuntu1 , for instance
[09:54] <Keybuk> right :)
[09:54] <Keybuk> I picked -mouse and that was up to date
[09:55] <Keybuk> *shrug*
[09:55] <Keybuk> it's just not built on the three slowest buildds
[09:55] <rodarvus> -mouse was done by Mithrandir two days ago :)
[09:55] <Keybuk> and they have relatively low priorities
[09:55] <rodarvus> right, that was my question :)
[09:55] <Kamion> aww, 4/5 successfully built for debian-installer
[09:55] <Keybuk> urgently needed?
[09:55] <Kamion> close but no cigar
[09:55] <givre> and so lot's of people come in the forum why they don't have a gui after the install
[09:55] <rodarvus> all xserver-xorg-input-* appear to have incredibly slow priority :)
[09:55] <Kamion> not bad considering I only tested 1/5
[09:55] <rodarvus> Keybuk: no, not really
[09:55] <givre> *asking
[09:56] <Keybuk> rodarvus: that's probably why they have a low priority then <g>
[09:56] <Kamion> givre: ok, file a bug and I can change that
[09:56] <Keybuk> sparc is about the slowest buildd (even slower than ia64)
[09:56] <rodarvus> heh
[09:56] <Keybuk> and also those three were the ones that were down longest during the kernel updates
[09:56] <givre> ok, thanks  you
[09:56] <givre> and thank you for all, you are doing a great job ;)
[09:57] <Keybuk> rodarvus: in general, as long as the build is "Needs building" (and not "No build info recorded") and https://launchpad.net/+builds doesn't show any errors for the buildd, it's in the queue somewhere
[09:57] <rodarvus> *nods*
[09:57] <Keybuk> https://launchpad.net/distros/ubuntu/edgy/+builds?build_state=pending
[09:57] <rodarvus> sparc currently has 631 packages on the queue
[09:57] <Keybuk> ^ top priority in that list is 1055
[09:58] <Keybuk> those have priority of 355  (meaning no real dependencies on them)
[09:59] <rodarvus> mesa upload was accepted directly into Accepted
[10:00] <rodarvus> shouldn't it go into NEW, due to the new packages it builds?
[10:00] <Kamion> rodarvus: source was, binaries will hit NEW
[10:00] <rodarvus> oh, good
[10:00] <rodarvus> Kamion: and I suppose the other binaries are held until these packages in NEW are accepted?
[10:01] <Kamion> rodarvus: nope
[10:01] <Kamion> each upload is independent
[10:01] <rodarvus> right
[10:01] <Kamion> as in, each .changes file
[10:02] <Kamion> the test is "does this .changes file contain components not currently in the overrides?"
[10:04] <rodarvus> the reason I was wondering is because subpackages inside the same source can depend on packages still on NEW
[10:04] <Keybuk> right
[10:04] <rodarvus> (and thus leave the archive in an inconsistent state for awhile)
[10:04] <Keybuk> those will just dep-wait on the buildds
[10:04] <Keybuk> (assuming build-dep)
[10:04] <Kamion> or be uninstallable for a bit, depending
[10:04] <Keybuk> or as you say, leave the archive uninstallable
[10:04] <Keybuk> but that's ok
[10:04] <rodarvus> yup
[10:05] <rodarvus> one feature I'd like to see, in the future, is the ability to "automagically rebuild" packages that depend, or build-depend on another package (such as a library) - on request, of course
[10:05] <Keybuk> in practice, this isn't much of a problem
[10:06] <Keybuk> rodarvus: 9/10 they need more than just a rebuild
[10:06] <rodarvus> say, I uploaded a new, incompatible version of mesa, and when it is uploaded and built, go to some launchpad page, and instruct the packages to rebuild themselves
[10:06] <rodarvus> Keybuk: I don't think its 9/10, but still, you have a valid point
[10:06] <Keybuk> in particular, it's usually wise to add/increment version in the build-depend line to make sure you hit dep-wait or build against the thing you actually meant
[10:07] <Keybuk> and, in true honesty, if the package doesn't work just as well with the new as well as the old, the chances are there's a code change required
[10:07] <Keybuk> we used to do "meta-builds" at Demon for this kind of thing, and in the end abandoned it because they were nearly always useless
[10:08] <rodarvus> heh :)
[10:08] <Keybuk> if the library doesn't change soname, the packages don't need to rebuilt
[10:09] <Keybuk> if the library does change soname, the packages almost always need code changed ... after all, there was a reason the soname changed
[10:09] <Keybuk> bbiab - asda trip
[10:09] <rodarvus> Keybuk: tell that to freetype developers :)
[10:09] <msw> (and tons of other people who don't manage their DSO ABIs)
[10:09] <rodarvus> but in general, I agree with you
[10:09] <rodarvus> msw: right
[10:10] <msw> which is one reason our (rpath) standard build mode is to build everything from scratch -- a full bootstrap build
[10:39] <FunnyLookinHat> mdz, You around?  Was hoping you could tell me how to find a contact address for Christian Marillat?  his launchpad account profiles are a bit empty  ^_^;;
[10:40] <jdub> marillat@debian.org
[10:40] <FunnyLookinHat> jdub, thanks!
[10:45] <seb128> FunnyLookinHat: what do you want to mail him?
[10:47] <FunnyLookinHat> seb128, it's concerning rebuilding the packages for MythTV.  mdz passed his name along in a chain of comments today on a bug related to the issue.
[10:48] <seb128> ok, because he doesn't work on Ubuntu afaik
[10:48] <FunnyLookinHat> seb128, that's what I thought  ^_^;;   But I figured mdz knew more than me
[10:48] <seb128> and he's not always nice about bugs or by mail ... just so you know
[10:48] <jdub> take a kevlar vest
[10:48] <jdub> and maybe some rations
[10:49] <FunnyLookinHat> lol
[10:51] <seb128> FunnyLookinHat: good luck ;)
[10:51] <FunnyLookinHat> Lol he just replied
[10:51] <FunnyLookinHat> "
[10:51] <FunnyLookinHat> I'm sorry but I'm not the responsible for Ubuntu packages, even if my
[10:51] <FunnyLookinHat> name is in the Maintainer field."
[10:51] <seb128> you will need some :p
[10:51] <FunnyLookinHat> Looks like I'm on my own, w00t.
[10:51] <seb128> ah, he has been nice ;)
[10:51] <crimsun> FunnyLookinHat: coordinate with the motu-media team
[10:52] <Keybuk> msw: you don't have mirrors :)
[10:52] <jdub> yeah man, you got out lucky
[10:52] <Keybuk> a full rebuild to us is (in the worlds of the great elmo) "HERE'S JOHNNY!"
[10:52] <jdub> last time i mailed marillat it was like apocalypse now
[10:52] <msw> Keybuk: sure we do!
[10:52] <jdub> but they were *MY* ears he was wearing
[10:52] <FunnyLookinHat> crimsun, motu-media...   ok, sounds good.  I have to still officially try to join the team.
[10:52] <msw> Keybuk: ;-)
[10:52] <Keybuk> msw: how do you cope with the full rebuild pumping gigabytes a day in their direction?
[10:52] <msw> Keybuk: one sec
[10:53] <seb128> jdub: did you mail him about GNOME, Debian, and GNOME Team? :)
[10:54] <msw> Keybuk: the mirror process goes through the same changeset process that clients use to apply relative updates
[10:54] <msw> Keybuk: so, when we do a rebuild of the same software, generally very very little changes.
[10:54] <Keybuk> msw: it's still got to be a large churn though, no?
[10:54] <jdub> seb128: yeah, back then ;)
[10:54] <Keybuk> msw: a library change like libc6 is going to affect change binary on the system
[10:54] <msw> Keybuk: we've done a rebuild and had, oh, maybe 300 MiB of new contents to push out
[10:54] <seb128> he sent some really non-friendly mails around that time
[10:54] <msw> Keybuk: true, true
[10:57] <seb128> Keybuk: could you get control-center out of NEW? It adds a gnome-control-center-dev new binary package which is required by gnome-session to build
[10:57] <Keybuk> seb128: it's only NEW for i386?
[10:58] <seb128> Keybuk: the -dev is arch: all (it's only a .h and a .pc)
[10:59] <Keybuk> yeah
[10:59] <seb128> Keybuk: dunno if that class it as NEW on i386 only
[10:59] <Keybuk> it does
[10:59] <Keybuk> Soyuz doesn't know about _all, it thinks they're i386
[10:59] <ogra_> seb128, what was the command to clear out gconf user settings ? gconftool-2 --recursive-unset /apps/gnome-power-manager seems not to suffice
[11:00] <seb128> ogra_: it should ...
[11:00] <ogra_> hmm
[11:00] <seb128> ogra_: rm -rf .gconf/apps/gnome-power-manager and send a SIGHUP to gconfd-2 then
[11:00] <ogra_> then i probably have cruft in the schema ...
[11:01] <seb128> ogra_: that's easy other way, use gconf-editor, go on the key and unset it .. unset == revert to system default
[11:02] <ogra_> yes, but it seems theer are some keys without owner in the g-p-m settings for me ... 
[11:02] <ogra_> urgh
[11:02] <seb128> what?
[11:02] <ogra_> intrestingly they work, even they are not assigned to g-p-m
[11:03] <ogra_> i just dimmed my display to 0
[11:03] <seb128> a key doesn't need to be "assigned" to work
[11:03] <seb128> everybody is authorized to read a gconf key
[11:03] <seb128> it's not only the app owning the key
[11:04] <ogra_> yes, but usually the keys from a schema are assigned to an app
[11:04] <seb128> yeah, if the schemas is correctly done
[11:04] <ogra_> (key owner field that is)
[11:04] <seb128> that's declared by the schemas itself
[11:04] <seb128> $ xvfb-run echo
[11:04] <seb128> kill: 158: No such process
[11:04] <seb128> bouh
[11:04] <ogra_> ok, then i'm fine, i was suspecting old keys lying around
[11:05] <seb128> xvfb-run breaks pygobject build
[11:05] <ogra_> but it seems they are valid just the schema is buggy
[11:05] <seb128> ogra_: look to the schemas file:
[11:05] <seb128>     <schema>
[11:05] <seb128>       <key>/schemas/apps/gedit-2/preferences/editor/font/use_default_font</key>
[11:05] <seb128>       <applyto>/apps/gedit-2/preferences/editor/font/use_default_font</applyto>
[11:05] <seb128>       <owner>gedit</owner>
[11:05] <seb128> by example
[11:06] <seb128> do they use <owner>  for it ?
[11:07] <Keybuk> seb128: random question you may know the answer to
[11:07] <Keybuk> does Debian's hal daemon run as a different user to ours?
[11:08] <seb128> Keybuk: no idea, would be a question for pitti
[11:08] <seb128> changelog mentions "Rename system user 'hal' to 'haldaemon' to be compatible with upstream"
[11:08] <seb128> and apparently the Debian changelog has no such change
[11:09] <seb128> looks like they are different yep
[11:10] <Keybuk> right
[11:10] <Keybuk> just thought you might more familar than me
[11:11] <seb128> not really no, pitti does a good job for it so I didn't have to look to hal for a while now ;)
[11:11] <seb128> s/for it/with it
[11:12] <Keybuk> given I officially no longer care about n-m, I'm almost completely reverting to the Debian packaging
[11:12] <Keybuk> which is made somewhat easy by the fact they've almost completely stolen our changes anyway :)
[11:12] <Keybuk> just needed to work around the whole netdev/hal/haldaemon thing
[11:13] <seb128> ok :)
[11:13] <jdub> Keybuk: because you think it's cock, or you don't want to deal with it?
[11:14] <Keybuk> jdub: because I think it's cock at the moment
[11:14] <jdub> heh
[11:14] <Keybuk> right now it's cock that's covered in cheese
[11:15] <Keybuk> but once it's cleaned up, and had some time to grow, it'll be good cock
[11:15] <Keybuk> my general n-m feeling is "it doesn't work yet, but one day will be the one true network stack"
[11:15] <mdz> implying that cheese-covered cock is bad cock?
[11:17] <jdub> Keybuk: i guess that using 'cock' as an adjective can be ambiguous in certain contexts... ;)
[11:18] <ogra_> pitti, do we plan to support polkitd in hal ? 
[11:18] <jdub> fabbione: I WANT UBUNTU ON THUMPER!!!111 :-)
[11:19] <jdub> fabbione: only i also want zfs on ubuntu :-(
[11:19] <ogra_> (for edgy that is=
[11:19] <ogra_> )
[11:19] <pygi> jdub, do it !!! :P
[11:20] <ogra_> zfs ? 
[11:20] <ogra_> zoom filesystem - for extremly small files ? 
[11:20] <jdub> ogra_: http://www.google.com.au/search?q=zfs+filetype%3Apdf
[11:20] <jdub> read that
[11:20] <pygi> ogra_, Solaris ^_^
[11:21] <jdub> (but read the pdf, not google's html)
[11:22] <ogra_> hmm, snapshots with rollback builtin ...
[11:23] <jdub> Keybuk: so n-m in edgy should suck less on b0rky atheros (with rml's patch)?
[11:24] <pitti> ogra_: this policy kit seems utterly crackful to me, and there is still some upstream discussion about it
[11:24] <mjg59> edgy's going with madwifi-ng anyway
[11:24] <Keybuk> jdub: hmm?  we always had rml's patch
[11:24] <pitti> ogra_: I would like to postpone it to edgy+1
[11:25] <Keybuk> that's why it doesn't use teeth when it sucks on dapper
[11:25] <jdub> hrm, i thought rml did some funky "don't scan when associated" foo
[11:25] <Keybuk> it scans about once a minute
[11:25] <Keybuk> rather than every 10s
[11:25] <jdub> pitti: oh?
[11:25] <ogra_> pitti, seems new g-p-m somewhat relies on its existence 
[11:25] <Keybuk> what's polkitd?
[11:26] <jdub> davidz's policy kit
[11:26] <ogra_> enbles hal to do evil things
[11:26] <jdub> for better google words
[11:26] <mjg59> Provides a framework for providing fine-grained access to hal objects and so on
[11:26] <seb128> gnome-system-tools is going to use it too
[11:26] <ogra_> oh, really ? 
[11:26] <mjg59> Also deals with the problem of keeping status when no user is logged in
[11:26] <ogra_> in edgy already ? 
[11:27] <seb128> might be
[11:27] <seb128> carlos showed some code during GUADEC using it
[11:27] <gnomefreak> what version ill let you know if it in edgy
[11:27] <mjg59> We probably want it in edgy, otherwise the divergence to FC6 is going to be irritating
[11:28] <pitti> seb128, ogra_: <rant> why do these things rely on features which aren't even in a stable hal release yet???</rant>
[11:28] <ogra_> mjg59, it would make a painful g-p-m merge delightful
[11:28] <Keybuk> pitti: "shiny"
[11:28] <ogra_> pitti, i didnt make the decision
[11:28] <pitti> ogra_: packaging and auditing policy kit daemon and all the crack in it, and packaging hal cvs head is not a simple task either
[11:28] <seb128> pitti: because they are not stable versions neither?: p
[11:28] <jdub> pitti: upstream sets the agenda :)
[11:29] <mjg59> pitti: hal should be releasing in the next few days
[11:29] <ogra_> +and i'm sure i could work around it by getting Kinnisons patch in, but that means i'll have to revert parts of the code to the former version
[11:29] <pitti> well, if we need it, and you want me to, I'll package it
[11:29] <pitti> but so far noone told me that it's necessary, so I didn't :)
[11:29] <seb128> pitti: by the time GNOME 2.16 is available a new hal will probably be too
[11:31] <jdub> The following NEW packages will be installed: pbbuttonsd
[11:31] <pitti> jdub: for apple intel
[11:31] <jdub> pitti: oh! of course. BONG!
[11:31] <ogra_> well, that would leave us not much time for testing
[11:31] <ogra_> jdub, yeah, for your macbook :P
[11:31] <ogra_> (which you dont own yet, but we install in advance :P )
[11:32] <jdub> i hope pbbuttonsd is a no-op on my machine tho ;)
[11:32] <jdub> yay gnome-vfs packages
[11:34] <mjg59> pbbuttonsd is needed for apple intels?
[11:34] <mjg59> Really?
[11:34] <mjg59> How does that work?
[11:37] <ogra_> it was included because of them ...
[11:37] <ogra_> (no idea if its needed :) )
[11:37] <ogra_> (in the i386 seed that is)
[11:38] <mjg59> Doesn't it only interface with /dev/pmu?
[11:38] <ogra> i think so 
[11:38] <mjg59> Who asked for it to be added to the seed?
[11:38] <ogra> do macbooks have that ? 
[11:38] <mjg59> No
[11:38] <ogra> heh
[11:39] <ogra> no idea who asked for it ... i think Kamion added it
[11:39] <mjg59> There's a completely different interface to the hardware
[11:39] <mjg59> Kamion: ^?
[11:41] <ogra> intrestingly there is no changelog entry in the seeds
[11:44] <Kamion> mjg59: we didn't explicitly add it; we just never made it architecture-dependent
[11:44] <ogra> mdz, oh, wow, thanks for adding mknbi to supported :)
[11:44] <Kamion> so when pbbuttonsd started to be built on i386, it automatically appeared
[11:45] <jdub> heh
[11:45] <Kamion> mjg59: if you think it shouldn't be there (though perhaps investigating the code first would be a good plan?), feel free to make a seed commit to change ' * pbbuttonsd' to ' * pbbuttonsd [powerpc] '
[11:46] <mdz> Kamion: surely it should be Architecture: powerpc if it can't work with macbooks
[11:46] <Kamion> mdz: it was, but was then deliberately made Architecture: powerpc i386 by the Debian maintainer
[11:46] <mdz> ogra: I didn't want it to be forgotten, since it didn't get a spec
[11:46] <mdz> ogra: please get someone to test it
[11:46] <Kamion> I assumed he vaguely knew what he was doing and haven't yet got round to investigating
[11:47] <Kamion> there was a changelog comment about it
[11:47] <Kamion> ogra: I did not add it, for the record
[11:47] <mdz> there was no human involvement
[11:47] <Kamion> except insofar as I probably added the original seed entry
[11:47] <Kamion> but that was before germinate had architecture-specific seed entries anyway
[11:47] <ogra> Kamion, yes, i see that now
[11:50] <mdz> Kamion: how far out of sync is it possible for anastacia and your germinate-output to be?
[11:50] <mdz> when did ndiswrapper-utils move from main to universe?
[11:51] <ogra> mdz, our mknbi is broken currently but jammcq and me are on it
[11:52] <ogra> mdz, when Keybuk demoted it because of security ambiguity (as he said)
[11:52] <mdz> Keybuk: ?
[11:53] <mdz> rodarvus: what's to be done about xserver-xorg-input-elographics? it still wants to move to universe; presumably some -all package should depend on it
[11:54] <Keybuk> mdz: it's an entirely new version
[11:54] <Keybuk> so needs MIRing again
[11:55] <Keybuk> comes from a different source package too
[11:57] <Keybuk> what we used to have is ndiswrapper-1.8 or something
[11:58] <Keybuk> like I said when I did it, I haven't had chance to actually figure out what's going on
[11:58] <Keybuk> so I NEW'd it all to universe