[12:04] <Kamion> kbrooks: it's in multiverse because you generally can't actually use it without non-free ROMs, i.e. the same reason that it's in Debian contrib. See zsnes/debian/README.Debian.
[12:04] <kbrooks> Kamion, but its licensed under the GNU GPL
[12:05] <Kamion> yes, but main+universe is supposed to be closed under dependency; that is, if you can't use software there to any significant degree without requiring non-free software, it doesn't go in main/universe.
[12:06] <Kamion> Debian's contrib and non-free sections map to restricted/multiverse unless we explicitly override that due to differing licensing policies, and this isn't one of the areas where our licensing policy differs from Debian's. Sorry.
[12:07] <Kamion> See http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib, relevantly "free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution"
[12:10] <elmo> Kamion: got a sec?  I'm trying to figure out why breezy is uninstallable (sic); aptitude -o debug::pkgproblemresolver=true isn't being helpful - is there another magic switch for aptitude?
[12:11] <Kamion> that's the only one I know of ... let me see if I can zen it out
[12:12] <elmo> Kamion: the base cause is that libesd-alsa0 is now in ubuntu-desktop; it always should have been, but wasn't due to bugs in the dak setup
[12:13] <Kamion> huh, so there were bugs other than the cron.sync Task screwup? (which shouldn't have affected ubuntu-desktop)
[12:14] <elmo> Kamion: this particular bug was that I assumed apt-ftparchive would automatically concatenate multiple Task entries in the extra file - it doesn't tho
[12:14] <Kamion> oh, ok
[12:15] <elmo> Kamion: so stuff was never getting into multiple tasks, in breezy pre-my-changes, libesd-alsa0 was only in edubuntu-desktop
[12:15] <elmo> now it's in edubuntu-desktop _and_ ubuntu-desktop
[12:15] <Kamion> ugh, amazing netboot worked at all
[12:15] <elmo> Kamion: for ref ~jackass/katie/backup/pre-fixes/ might be useful
[12:16] <elmo> [err jackass:~katie/ obviously, but you knew that]
[12:16] <elmo> Kamion: yes :(
[12:16] <elmo> I don't think netboot did work in !server mode for much of anything
[12:16] <elmo> or I'm amazed if it did
[12:16] <Kamion> unless aptitude's just blatantly ignoring |-ed deps ...
[12:17] <Kamion> hmm, libasound2 isn't in ubuntu-desktop, wonder why
[12:18] <Kamion> oh, it's in minimal, ok
[12:20] <elmo> err, in breezy?
[12:20] <Kamion> yeah
[12:20] <elmo> oh, indirectly
[12:21] <\sh> grr..good morning...
[12:22] <Kamion> elmo: try -o Aptitude::CmdLine::Resolver-Debug=true
[12:22] <Kamion> aptitude has its own problem resolver, I think
[12:23] <elmo> hmm, no dice
[12:23] <elmo> using pkgproblemresolver does give me more info, justnot enough and not the usual apt spew
[12:24] <Kamion> ok, can I reproduce this with a debootstrap?
[12:24] <elmo> Kamion: yes, I did it in a --variant=buildd chroot
[12:25] <elmo> and then 'aptitude install "~tubuntu-standard|~tubuntu-desktop"'
[12:25] <elmo> (after installing aptitude)
[12:39] <kbrooks> When are the "beta" (e.g. flight) cds released? when the distro is stable
[12:39] <kbrooks> ?
[12:40] <Kamion> kbrooks: that plus when I have time to do it
[12:40] <kbrooks> Kamion, huh?
[12:40] <Kamion> (BTW, we're going to be calling the previously-so-called "Preview" release "Beta" from now on)
[12:40] <Kamion> ("alpha" is a better description of the Flight CD releases)
[12:40] <kbrooks> Kamion, ok, s/alpha/beta/
[12:40] <kbrooks> why are the cd releases named flight?
[12:41] <Kamion> kbrooks: Flight CD releases require manual QA and usually fixups from someone, and that someone is usually me
[12:41] <kbrooks> er, beta alpha
[12:41] <Kamion> kbrooks: collective noun for both dragons and ducks (i.e. Drake)
[12:41] <bmonty> elmo: please sync lmodern from debian unstable, overriding ubuntu changes is OK
[12:42] <kbrooks> what is "tubuntu"
[12:42] <kbrooks> ?
[12:42] <Kamion> nothing
[12:42] <Kamion> ~t is part of an aptitude pattern
[12:42] <kbrooks> ah
[12:45] <Kamion> elmo: ah, that aptitude option is new in dapper's aptitude, arse
[12:47] <kbrooks> arse?
[12:47] <kbrooks> :)
[12:47] <Kamion> kbrooks: ok, explaining everything I say to somebody else is getting kind of old now :)
[12:48] <Kamion> elmo: (BTW you want --without-recommends to match the installer, not that it makes any difference)
[12:49] <elmo> Kamion: ah, ok
[12:56] <Kamion> elmo: hmm, even more bizarrely, it seems to be quite happy for me to install the ubuntu-desktop task from the UI
[01:00] <elmo> ugh
[01:05] <elmo> oh, ok, so if I do:
[01:05] <Kamion> differences between what installing ubuntu-desktop wants to install and the list in Task: ubuntu-desktop:
[01:05] <Kamion> +apmd
[01:05] <elmo>  apt-get install $(apt-cache dumpavail | grep-dctrl -FTask -sPackage ubuntu-desktop | cut -d: -f 2)
[01:05] <Kamion> +laptop-mode
[01:05] <Kamion> +libqthreads-12
[01:05] <Kamion> -mysql-common-4.1
[01:05] <Kamion> +mysql-common
[01:06] <Kamion> not clear to me that any of that is relevant
[01:06] <Kamion> (dude, grep-dctrl -n)
[01:06] <daniels_mobile> mdz: don't happen to know if LAX has any wireless?
[01:07] <\sh> daniels_mobile: whereever .nu is...but give us back xvfb-run :)
[01:07] <daniels_mobile> Stuck here for another 7 hours but no frigging networks I can see.
[01:08] <Kamion> elmo: hmm, I guess the mysql-common thing isn't helping
[01:09] <elmo> daniels_mobile: http://www.jiwire.com/browse-hotspot-airport-united-states-us-california-ca-los-angeles-17239.htm
[01:09] <Kamion> elmo: ugh, look at the dependencies of libmysqlclient12 and libmysqlclient14
[01:10] <Kamion> I bet those are confusing matters something rotten
[01:10] <daniels_mobile> elmo: thanks. Any executive summary? Can't get big pages on my phone. In the Bradley international terminal, pre-security.
[01:11] <elmo> daniels_mobile: it claims there is one, but doesn't given any useful info, it looks like a bit of a lame site tho
[01:11] <daniels_mobile> Okay, thanks. I'll do some more wandering.
[01:11] <elmo> it's meant to be a "Boingo" network, and the map is useless
[01:12] <elmo> christ, these deps are a mess
[01:12] <Kamion> elmo: we explicitly seeded mysql-common in the breezy server seed to avoid a similar problem
[01:13] <Kamion> elmo: I'm wondering if LALALAYOUDIDN'THEARTHIS demoting mysql-common-4.1 to breezy/universe LALALA would help
[01:14] <elmo> I'm wondering if we shouldn't just put the old Packages files back
[01:14] <Kamion> I think it would, actually
[01:14] <elmo> and declare that gina/soyuz/lp doesn't get to generate the indices files for a released suite
[01:14] <Kamion> the old indices files *were* fucked in other ways though ...
[01:15] <elmo> well at least netboot for ubuntu worked with the old ones :P
[01:15] <elmo> but yeah, I guess
[01:15] <elmo> ugh
[01:15] <Kamion> how about tomorrow I set up a fake archive with my proposed change and see if it works?
[01:15] <elmo> this still doesn't explain libesd0 tho?
[01:16] <Kamion> I suspect aptitude may be running into the mysql thing and giving up
[01:16] <elmo> ah
[01:16] <Kamion> once stuff is broken apt* can be a lot less willing to fix other things
[01:16] <Kamion> worth noting that the released CD images include libesd-alsa0 and mysql-common, but not libesd0 or mysql-common-4.1
[01:17] <Kamion> which at least gives us a guide to what we're supposed to be installing
[01:17] <elmo> well, except kubuntu must have libesd0, but yeah
[01:17] <Kamion> right, yeah, sorry, just referring to Ubuntu here
[01:18] <Kamion> I note that Task: kubuntu-desktop in the new Packages files manages to include both mysql-common and mysql-common-4.1
[01:18] <elmo> *sob*
[01:19] <elmo> tho, if we demote mysql-common-4.1, that should stop that?
[01:19] <Kamion> should do ...
[01:19] <Kamion> I'd probably want to rerun germinate against faked-up Packages files and check out the differences
[01:20] <Kamion> explicit seeding would help kubuntu but I don't see how it could help ubuntu/edubuntu
[01:20] <Kamion> (of mysql-common)
[01:21] <Kamion> the other option I can think of is an updated ubuntu-desktop binary, but that's possibly even more horrible than a demotion
[01:21] <Kamion> since it would have to go in breezy, not breezy-updates, and VOMIT
[01:23] <elmo> breezy-updates is on by default tho, right?
[01:24] <elmo> or is it still too late?
[01:24] <Kamion> hm, you're right
[01:25] <Kamion> ok, that's theoretically an option
[01:26] <Kamion> hmm, removing mysql-common-4.1 from my local apt-cached Packages file doesn't fix the libesd0 thing
[01:27] <elmo> can you remove stuff from the Packages file in apt?
[01:27] <Kamion> oh, smeg, smeg, smeg
[01:28] <elmo> what about thebinary cache?
[01:28] <Kamion> you know, having our main distribution be a substring of our derivative distributions really wasn't a good idea
[01:28] <elmo> oh, you're kidding?
[01:28] <Kamion> (a) in your grep above, "ubuntu-desktop" matches "kubuntu-desktop" and "edubuntu-desktop"
[01:28] <Kamion> (b) in the aptitude pattern encoded into the breezy installer, the same applies
[01:29] <Kamion> headdesk
[01:29] <elmo> ARGH
[01:30] <elmo> yeah, confirmed
[01:31] <Kamion> (yes, it seems you can go in and edit the cached Packages file; I edited Release too for good measure, although it didn't seem to care that I hadn't changed Release.gpg - apparently it only validates that on update)
[01:31] <elmo> aptitude install "~t^ubuntu-desktop" works
[01:31] <Kamion> but that won't install the right thing, unless you arrange for "ubuntu-desktop" always to come first in the Task lines
[01:31] <elmo> oh, is that how the ~t thing works?  eww
[01:31] <elmo> 3 packages upgraded, 910 newly installed, 0 to remove and 0 not upgraded.
[01:31] <Kamion> although it'll probably be relatively close because the ubuntu-desktop binary is only in Task: ubuntu-desktop
[01:31] <elmo> doesn't look too far out?
[01:32] <Kamion> so that'll pull in the rest
[01:32] <elmo> ah
[01:32] <Kamion> oh, god, I have no clue how to solve this at 12:30 in the morning
[01:32] <elmo> don't worry about it, it's been broken for a while, there's no rush
[01:32] <Kamion> yes, reverting to the old Packages files seems like the only sane thing to do right now
[01:32] <elmo> (since Nov 23rd, to be exact)
[01:33] <daniels> christ, what a uselessly broken hotspot
[01:33] <Kamion> and maybe, if we have to, providing shadow Packages files somewhere unofficial where people can point Kubuntu or Edubuntu netboot installs
[01:33] <daniels> it's down in the checkin area, where the food and powerpoints aren't, and it's munted for seven minutes out of every ten
[01:33] <kbrooks> Is ubuntu *itself* licensed?
[01:33] <Kamion> although they'd have to be signed with the archive key which is, er, kinda awkward
[01:33] <daniels> \sh: you do know I've been on holiday all last week, right?
[01:34] <elmo> remind me why we don't just do apt-get install ubuntu-desktop for netboots?
[01:34] <kbrooks> Is ubuntu *itself* licensed?
[01:34] <elmo> kbrooks: your question is meaningless and repeating it, doesn't help
[01:35] <\sh> daniels: i'm just teasing you...don't take me too serious
[01:35] <kbrooks> elmo, meaningful question ... ok
[01:35] <Kamion> elmo: semi-historical reasons originally, partly that I found the metapackage broke more during development, and nowadays installing the metapackage doesn't clue aptitude in to the fact that it should consider all the dependencies of ubuntu-desktop individually manually installed
[01:36] <kbrooks> why is ubuntu apparently "open source" if ubuntu itself is not placed under a license?
[01:36] <Kamion> please don't troll #ubuntu-devel, thanks
[01:36] <elmo> Kamion: ugh, right, ok
[01:36] <kbrooks> I'm not trolling.
[01:36] <mjg59> kbrooks: You have permission to distribute modified or unmodified versions of everything in Ubuntu
[01:37] <mjg59> The CD packaging specifies that you have permission to distribute the CD, too
[01:37] <kbrooks> OK
[01:38] <Kamion> I suggest you consult a lawyer if you have specific concerns; most people here do not have legal training and are merely trying to do the best they can
[01:38] <daniels> or just ask debian-legal, they rock
[01:39] <kbrooks> heh, i'll look in there
[01:39] <kbrooks> ty
[01:39] <Kamion> (although between us we have fairly extensive experience with free software licences)
[01:39] <Kamion> (i.e. enough not to generally wildly cock it up, we hope)
[01:42] <Kamion> elmo: actually, you were right, apparently aptitude's ~t pattern matches task names individually
[01:43] <Kamion> so '~t^ubuntu-desktop$' should be a viable workaround
[01:44] <Kamion> but unfortunately there's no way to retrofit that into breezy without a base-config upload to breezy, and breezy-updates *wouldn't* cut it in that case
[01:44] <Kamion> I'll fix my local dapper trees now though
[01:44] <seth_k> kbrooks, zsnes updated to 1.420
[01:45] <kbrooks> seth_k, ok
[01:45] <seth_k> kbrooks, just hit archive so you should be able to apt-get it now
[01:45] <elmo> Kamion: ugh
[01:53] <Kamion> elmo: I'm off to bed, will look more in the morning
[01:53] <elmo> Kamion: ok, thanks a lot for looking at it
[03:45] <Toma-> is there any talk of including initng with dapper?
[03:49] <Amaranth> nothing major like that for dapper
[03:49] <Amaranth> but initng is a hack
[03:49] <Amaranth> i believe the ideal solution is porting sun's stuff
[03:50] <SEJeff> Amaranth: What did sun do?
[03:51] <Amaranth> i can't remember but it has real dependency handling and such
[03:51] <SEJeff> http://lists.debian.org/debian-lsb/2005/08/msg00013.html
[03:52] <Amaranth> what would be cool is to say "start GDM" and have the init system handle all the dependencies to make that happen
[03:52] <SEJeff> The new lsb has an example for paralell init script execution. That would be the easiest likely
[03:52] <SEJeff> Yes you're very right
[03:52] <Toma-> that would be nice
[03:52] <SEJeff> apt-start gdm would be cool
[03:53] <Amaranth> http://en.wikipedia.org/wiki/Service_Management_Facility
[03:53] <Amaranth> that's what solaris has
[03:55] <infinity> I don't really dig anything that tears out init scripts and starts from sratch.  Perhaps because I like being able to do a slow transition.
[03:55] <infinity> And I'm not sure I see the point, except to be hip and cool.
[03:56] <Toma-> everyone that tries linux says it starts so slow. alot of people like to turn their PC's off alot for some crazy reason
[03:56] <infinity> If we can achieve similar results through a dependency-based sysv-init behave-alike, it's less confusion for people upgrading and wondering WTF happened.
[03:56] <Toma-> yeh
[04:24] <wasabi> I really don't fancy having so many scripts sitting around in /etc. No technical reason though. I like Macs launchd or whatever. Just a simple description about what program to run, how to run it, and what to do if it doesn't run.
[04:39] <uenyioha> hey guys
[04:40] <uenyioha> anyone know assembly...?
[04:40] <uenyioha> im trying to increment the value of a register by 8
[04:40] <uenyioha> i was thinking thinking this was the proper memmonic with gas
[04:40] <daniels> o/~ this is how I represent over this here beat
[04:40] <uenyioha> mov 8(%ebp), %ecx
[04:41] <uenyioha> i think i'm a little off....since it appears to be "dereferencing" the register instead
[04:45] <desrt> uenyioha; what register?  ecx?
[04:45] <uenyioha> desrt: i think i found what i needed
[04:46] <desrt> addl $8, %ecx   ?
[04:46] <desrt>  mov 8(%ebp), %ecx  is    mov ecx, [ebp+8]
[04:46] <uenyioha> desrt: yeah...brain fuzz is a bitch
[04:47] <uenyioha> desrt: yeah....thanks a lot!
[05:54] <elmo> what's the usual solution to autoconf insisting on libxt-dev's header files to test for X?  just build-depend on it?
[05:56] <infinity> Least resistance is to build-dep on libxt-dev, "correct" solution is to re-autocrapify with a shiny new autoconf that gets it right.
[05:57] <elmo> how new?
[05:58] <elmo> like, newer than breezy?  because breezy still seems to reference Intrisic.h when you use AC_PATH_XTRA
[05:59] <elmo> ugh, holy crap
[06:00] <elmo> it appears the "solution" is a debian-specific patch that makes optional arguments to AC_PATH_XTRA so you can tell it to look for something other than libXt
[06:02] <infinity> Yeah, uhm.  Note I had "correct" in quotation marks above.
[06:02] <infinity> I don't think the upstream autotools guys have given a single thought to modular X yet.
[06:02] <infinity> Or, if they have, they're not letting us know what they've come up with.
[06:03] <infinity> I assume in the end, the old X-related macros will just become deprecated, and we'll get new ones for each library and wire protocol, or something.
[06:04] <elmo> well given debian is the de facto upstream for this package, I don't think adding debian specific stuff to configure.in is likely to win me any friends
[06:04] <elmo> oh well, bogus build-depends it is
[06:09] <elmo>   * Remove some ancient debian-specific patches
[06:09] <elmo>     - install no longer calls strip with special options
[06:09] <elmo> grr
[06:14] <fabbione> morning
[06:14] <infinity> coreutils has been making everyone happy lately, for different reasons.
[06:14] <fabbione> elmo: hey dude
[06:14] <fabbione> elmo: did rt got my mails?
[06:14] <fabbione> elmo: i had no ack back from it
[06:15] <elmo> fabbione: when/where did you send them?
[06:15] <fabbione> after i did wake you up on saturday
[06:15] <fabbione> :/
[06:15] <elmo> fabbione: I'll look later today, when I'm working
[06:15] <fabbione> oh ok
[06:15] <fabbione> sure
[06:15] <fabbione> i tought you were just shifting hours
[07:17] <pitti> Good morning
[07:20] <fabbione> morning pitti
[07:20] <pitti> Hi fabbione
[07:20] <zakame> hello pitti :)
[07:27] <pitti> daniels: here?
[07:40] <HiddenWolf> Mogge
[08:52] <doko> good morning
[08:52] <pitti> Hi doko
[08:53] <doko> seb128: dude, more libcairo fun. change the package name, if you remove symbols :-(
[08:53] <doko> hi pitti
[08:53] <doko> pitti: what are the names of the new locale packages?
[08:53] <pitti> doko: 'locales', just as before
[08:53] <pitti> doko: the source package is 'langpack-locales'
[08:54] <doko> hmm, and all locales are pregenerated?
[08:55] <doko> pitti: ^^^
[08:55] <pitti> doko: no, they aren't
[08:55] <pitti> doko: the langpacks itself ship the locales
[08:55] <pppoe_dude> q: is ubuntu sorta like debian unstable or is it better?
[08:55] <pitti> doko: and they generate the language-relevant loclaes on installation
[08:55] <pitti> pppoe_dude: #ubuntu, pleas
[08:55] <pitti> e
[08:55] <pppoe_dude> k bye :)
[08:56] <doko> pitti: look, at debian/locale-gen in the gcc-* sources, that currently is broken by the new locales package, and I certainly don't want to build-depend on 15 language packs
[08:57] <mvo> pitti: I just got a dpkg override problem error from langpack-zh-<something> on upgrade, known issue?
[08:57] <pitti> mvo: no, it's not; what is the conflict?
[08:58] <pitti> doko: uh, gcc needs to generate locales?
[08:58] <infinity> For the testsuite.
[08:58] <infinity> A few pckages generate locales during build.
[08:58] <infinity> (In the build directory, of course)
[08:59] <pitti> I had assumed that test suites would ship their own example locales, hmm
[08:59] <doko> pitti: every package which needs locales for the testsuite needs them
[08:59] <doko> pitti: but you didn't mention it in the spec ;-P
[09:00] <pitti> doko: no, I didn't even think about the possibility of that
[09:00] <doko> please fix it. kthxbye
[09:00] <pitti> 'every' can't be that many, though
[09:01] <pitti> ok, so should there be a locales-all package maybe?
[09:01] <pitti> doko: 'fix'? what's your suggestion?
[09:01] <doko> which depends on every langpack package?
[09:01] <pitti> either gcc could just copy the locale definitions, or we create an -all package
[09:01] <doko> how would this package look like?
[09:02] <pitti> doko: no, b-d on all langpacks would be a bit silly
[09:02] <pitti> doko: it could ship the locales in /usr/share/locales-all/, or whereever
[09:02] <doko> so the -all package would contain a copy, which is only used as a b-d?
[09:02] <pitti> doko: would be an option, yes. no idea whether it makes sense
[09:03] <pitti> if it's only gcc, then just copying the locales there would make more sense
[09:03] <pitti> then the test suite would be self-containing
[09:03] <doko> well, at least better than build-depending on language packs
[09:03] <mvo> pitti: hm, sorry. I can't reproduce it anymore. it was language-pack-gnome-zh and/or language-pack-gnome-zh-base during a upgrade
[09:04] <doko> pitti: I know locales are tested in gcc, bash, python (and maybe binutils as well).
[09:04] <pitti> mvo: well, -zh and -zh-base replace each other, so that can't be it
[09:04] <pitti> mvo: maybe a gnome package coflicted to a non-gnome one?
[09:04] <doko> the thing is, that we'll break things without knowing about it ...
[09:05] <pitti> doko: ok, since there seem to be more packages, then having an -all package would seem like a clean solution?
[09:05] <pitti> doko: I would build it from langpack-o-matic
[09:05] <pitti> since eventually we'll pull locales from rosetta
[09:06] <pitti> doko: can you tell the test suites where the definitions are? (path)
[09:06] <doko> pitti: please make it compatible with the previous implementation of localedef, so that script have not to be changed
[09:06] <pitti> doko: localedef did not change at all
[09:07] <pitti> doko: well, it got some belocs enhancements, but localedef only has a default path which wasn't changed
[09:07] <pitti> doko: ok, we can make the langpacks Replace: locales-all
[09:08] <pitti> but that requires another langpacks upload
[09:08] <doko> pitti: sent you the script
[09:08] <fabbione> dpkg-shlibdeps: warning: could not find any packages for /usr/lib/libncurses.so.5 (libncurses.so.5)
[09:08] <fabbione> dpkg-shlibdeps: warning: unable to find dependency information for shared library libncurses (soname 5, path /usr/lib/libncurses.so.5, dependency field Depends)
[09:08] <fabbione> hey guys
[09:08] <fabbione> any idea why i could get that error?
[09:08] <pitti> doko: script?
[09:08] <fabbione> libncurses5 is installed
[09:09] <fabbione> also -dev
[09:10] <doko> pitti: a script, which many packages use to generate the locales which they need for testing
[09:14] <pitti> doko: hm, the script already looks into `pwd`/locales
[09:14] <pitti> doko: so the locales just need to be there without changing the sript
[09:14] <doko> pitti ... the dir is empty ...
[09:15] <pitti> doko: right, but it means that a quickfix is just to copy the locales there; 12 locales or so are tiny
[09:15] <pitti> Hi seb128
[09:15] <seb128> hey pitti
[09:15] <doko> pitti: that's the wrong fix. touching N packages instead of one.
[09:16] <pitti> doko: it's a 'quickfix'
[09:16] <pitti> doko: building and uploading 300 new language packs is not a 5-minute fix
[09:16] <doko> some would call it crap ;-P
[09:16] <pitti> doko: I would call it 'self-contained test suite' :)
[09:17] <doko> pitti: wrong, I'm not supposed to test against my own data, but against the system's data. I don't include the libraries I use, as well.
[09:19] <dholbach> good morning
[09:19] <doko> seb128: dude, more libcairo fun. change the package name, if you remove symbols :-(
[09:20] <seb128> doko: I don't remove symbols
[09:20] <seb128> doko: Debian do, I've dropped the patch for Ubuntu
[09:21] <seb128> hi dholbach
[09:21] <dholbach> hey seb128 :)
[09:21] <doko> seb128: then maybe the shlibs dependency needs to be tighened? see siretart's posting on u-d
[09:21] <pitti> doko: well, if you truly want to test against what the system has, then b-dep'ing on the langpacks wouldn't even be completely wrong
[09:22] <seb128> doko: it lacks any detail to be useful
[09:22] <seb128> doko: imho this has nothing to do with cairo, that's the freetype ABI breakage itself
[09:22] <doko> pitti: it's not wrong to use the same mechanism to create these locales on build time.
[09:22] <seb128> freetype dropped symbols
[09:22] <sivang> morning all
[09:22] <pitti> doko: no, it's not, I didn't say that
[09:23] <doko> seb128: ok
[09:23] <doko> pitti: so did we agree that we will have a locales-all package?
[09:23] <pitti> doko: as I said, if you want I can create a locales-all package, but I'd prefer to ship the locale definitons in a different path
[09:23] <doko> pitti: it's ok for me as long as localedef finds this data
[09:24] <pitti> doko: you probably need to adapt the path in the script
[09:24] <pitti> i. e. change LOCDATA
[09:24] <pitti> erm, LOCPATH
[09:24] <doko> pitti: please no. this way we have to change every package.
[09:25] <pitti> doko: changing 3 packages seems easier than 300, no?
[09:25] <doko> pitti: a) you _know_ these 300 packages b) it's mechanical c) there are more than 3, and they are unknown
[09:26] <pitti> doko: ok, I'll talk with jbailey about changing localedef, it could look into an alternative path
[09:27] <doko> pitti: ok, I'll file a bug report to keep track of it
[09:27] <pitti> doko: that would be nice, yes
[09:35] <mvo> Riddell: in what package is the kdesu binary?
[09:37] <infinity> kdebase...
[09:37] <infinity> (kdebase-bin for the binary package, I think)
[09:39] <mvo> thanks
[09:42] <siretart> seb128: /usr/lib/libcairo.so.2: undefined
[09:42] <siretart> symbol: FT_GlyphSlot_Embolden
[09:43] <seb128> siretart: freetype symbol
[09:43] <seb128> freetype ABI change
[09:43] <seb128> cf bug I pointed
[09:46] <siretart> seb128: I really don't want to attack you, I just want to really understand whats about this soname magic and how to "bump soname"
[09:46] <seb128> siretart: who said you attack anybody?
[09:47] <seb128> siretart: if the ABI change it a non-compatible way you have to change the soname
[09:47] <dholbach> normally upstream does that :)
[09:47] <seb128> but upstream don't always do this actually
[09:48] <seb128> lu vuntz_
[09:48] <dholbach> lintian should check the list of exported symbols on a library upgrade :)
[09:48] <siretart> in this case: shouldn't debian do the soname bump?
[09:48] <siretart> and how can we do this in the most compatible way?
[09:48] <seb128> siretart: changing the soname over upstream is making you binary incompatible with the rest of the world
[09:49] <dholbach> siretart: the bug report and d-d@ has a discussion on this topic
[09:49] <seb128> ie: if upstream has .so.0 and ubuntu .so.1
[09:49] <seb128> let's say skype is built with .so.0
[09:49] <seb128> it'll not run on Ubuntu
[09:50] <seb128> out of this look on libfreetype6 rdepends
[09:50] <seb128> not an easy case
[09:50] <siretart> seb128: how about running dh_makeshlibs in libfreetype with '-V'?
[09:50] <seb128> that's bad
[09:50] <seb128> you should bump the shlibs only when the ABI/API change
[09:50] <seb128> not on every new version
[09:51] <seb128> because you force transitions when not required
[09:51] <siretart> I see
[09:51] <seb128> and transitionning hundreds of packages is not a piece of cake
[09:51] <siretart> the thing is, it IS required in this case
[09:51] <seb128> so you don't want to do it every single new version for nothing
[09:51] <seb128> right
[09:51] <seb128> soname should have been changed since symbols have been dropped
[09:51] <seb128> which breaks binary compatibily
[09:51] <seb128> the issue is that Debian screwed
[09:52] <siretart> so you suggest that freetype upstream and debian should fix this and we cannot do much about it, right?
[09:52] <seb128> and dholbach asked for a sync of the new version, so we are quite stucked too now
[09:52] <seb128> we don't want to do it differently from Debian
[09:52] <thoron> Hi!
[09:52] <seb128> imho we should just bump the shlibs and move on
[09:53] <seb128> dholbach: no need to be sorry, that happens to everybody :)
[09:53] <seb128> thoron: morning
[09:53] <thoron> Could I get somewhere the whole source of Ubuntu build system?
[09:53] <dholbach> that's quite a lot :)
[09:53] <HrdwrBoB> thoron: if you so desired
[09:54] <thoron> Not the packages, only the system that makes the binaries. So that I make my own Linux distribution. ;-)
[09:54] <sivang> isn't it like the debian build system?
[09:55] <HrdwrBoB> sivang: extremely complicated and takes many many hours to build?
[09:55] <thoron> Anything goes, is there some tarball available?
[09:55] <siretart> seb128: ok. what do we do about this freetype problem? wait for debian or bumb soname on our own?
[09:56] <HrdwrBoB> thoron: there is no giant source tarball
[09:56] <HrdwrBoB> thoron: you will have to grab each packages source individually
[09:56] <thoron> HrdwrBoB: No, I am not looking for source packages, I looking for build and release system.
[09:57] <seb128> siretart: my opinion is what I just said, bump the shlibs for now ... you may want to ask to Kamion/mdz
[09:57] <thoron> The tools that Ubuntu or XYZ disto makes it work for source packages to bootable installation ISO images.
[09:58] <thoron> Surely that is not something that is made by hand.
[09:58] <infinity> thoron : svn ls http://svn.cyberhqz.com/svn/wanna-build/
[09:58] <infinity> thoron : That's (more or less) what we use for building binaries from sources.
[09:59] <infinity> thoron : We use the debian-cd package for making CD images.
[09:59] <thoron> Now we are getting somewhere. ;) Thanks.
[09:59] <sivang> thoron: well, I guess that are many automated parts in it, however I wouldn't count on the assumption it would all go into a nice formatted ISO without some intervention :)
[09:59] <infinity> thoron : Both are heavily modified by us, but that's what's publically available.
[10:00] <thoron> well, I have lot to learn.
[10:00] <thoron> And I don't want to invent wheel again.
[10:01] <thoron> infinity: so why isn't everything public?
[10:03] <infinity> thoron : "Because it's not" is probably the best answer you'll get.  Most of our modifications are very specific to Ubuntu, so there's no point in pushing patches back out to the world at large.
[10:03] <thoron> Linux from scratch is interesting project too.
[10:04] <thoron> There is automation process going on but it's not ready yet.
[10:04] <thoron> And Red Hat will not release their build system if I have understood correctly.
[10:05] <thoron> Anyway, thanks for this part. I'll try to figure out how it works.
[10:22] <Tliug> hi guys
[10:22] <Tliug> I've added a LILO boot screen for Ubuntu ...
[10:22] <Tliug> http://guilt.bafsoft.net/stuff.php
[10:22] <Tliug> please check it out and let me know your opinion
[10:22] <Tliug> :)
[10:23] <Tliug> Anyone here?
[10:40] <pitti> Mithrandir: ping
[10:45] <pitti> ogra: argh, what happened to xscreensaver? it looks like the Debian version again
[10:47] <seb128> pitti: read the changelog?
[10:47] <seb128> pitti: it's moved to universe with Ubuntu hacks dropped
[10:47] <pitti> seb128: ah, ok, sorry
[10:47] <pitti> so g-s-s comes along?
[10:47] <seb128> yep
[10:48] <seb128> pitti: no need to be sorry, just pointing that's explained by the changelog :)
[10:54] <janimo> elmo, if it's you who can delete packages from the archive, please remove xffm4-icons, it is causing unnecessary user confusion and it is superseded (conflicts, replaces) by new xffm4. thank you
[11:57] <pitti> yay, that's the dapper way of printing - put a pdf on an USB stick and boot a breezy live CD *grumpf*
[11:58] <pitti> Keybuk: oh, you are here now? :) maybe we can try to chase down the printing breakage?
[11:58] <Keybuk> yeah, they attacked my line all day Friday and *still* haven't fixed it
[11:58] <Keybuk> grr
[11:59] <pitti> Keybuk: oh, you are still on modem?
[12:00] <pitti> Keybuk: I can feel your pain, I have to work though ISDN pretty ofen
[12:00] <pitti> often, even
[12:00] <Keybuk> no, on ADSL, but it barely works at night time
[12:06] <Keybuk> pitti: "printing breakage"?
[12:06] <Keybuk> do you mean that cups sulks and doesn't recognise USB printers?
[12:08] <pitti> Keybuk: oh, I found out a bit now
[12:09] <pitti> Keybuk: usb printers are now called /dev/lp0, not /dev/usblp0 any more
[12:09] <ogra> pitti, remove the old xscreensaver cruft, gnome-screensaver is the future ;) (will write the main inclusion reports today for you)
[12:09] <pitti> Keybuk: probably cupsys doesn't recognize that
[12:10] <pitti> Keybuk: oh, and linux-wlan-ng breaks as well - the prism2_usb module is not loaded automatically :(
[12:11] <pitti> bah, even cp -a lp0 usblp0 doesn't help - cupsys refuses to see the printer
[12:12] <fabbione> pitti: you probably want a symlink on /dev
[12:12] <pitti> fabbione: doesn't help
[12:12] <Keybuk> pitti: yeah, that one I know, I fixed it already locally
[12:12] <Keybuk> it's /dev/usb/lp0 ... extra /
[12:13] <pitti> ah
[12:13] <Keybuk> dunno why prism2_usb is not loaded ... easiest way to debug is to run "udevmonitor -e", then plug your adapter in
[12:13] <pitti> ok, I'll do that later
[12:13] <Keybuk> you'll get a [UEVENT]  and [UDEV]  block for it (often multiple)
[12:15] <pitti> hm, still no fun with /dev/usb/lp0
[12:15] <hunger> Keybuk: You noticed bluetooth breaking?
[12:15] <hunger> Keybuk: bluetooth module is there, so udev seems to do its magic, so this is probably nothing for you to worry about.
[12:16] <Keybuk> hunger: not yet
[12:16] <Keybuk> again, use udevmonitor to capture the device being inserted ... and mail me the output
[12:17] <pitti> Keybuk: cupsys checks for /dev/usblp0, /dev/usb/lp0, /dev/usb/usblp0; should not be a problem to teach it /dev/lp0; but for that it has to work with usblp0 first
[12:18] <hunger> Keybuk: The device is builtin... And I the key combo used to deactivate/activate does no longer work.
[12:19] <Keybuk> hunger: built-in, or mini-PCI?  on my laptop the wifi killswitch also kills the bluetooth.
[12:19] <Keybuk> pitti: nah, will fix the udev rules instead
[12:19] <pitti> Keybuk: k, but still a cp -a of the device should certainly work?
[12:19] <hunger> Keybuk: No idea how it is integrated.
[12:19] <pitti> since the kernel is only interested in the major/minor?
[12:20] <hunger> Keybuk: The wifi killswitch used to kill BT as well on mine. Unfortunately that no longer works since the kernel/udev upgrade.
[12:20] <Keybuk> pitti: yes, but cups may not be inotifying the /dev directory <g>  if it only looks when hal tells it about a new device ...
[12:21] <Keybuk> hunger: what wireless card is it?
[12:21] <hunger> Keybuk: BT is allways on now... but does not react to my mouse.
[12:21] <pitti> Keybuk: no, cupsys doesn't use hal - it just opens every usblp device it can find and issues some ioctls on it
[12:21] <hunger> Keybuk: Uses madwifi drivers... lspci lists it as Atheros AR5212.
[12:21] <pitti> Keybuk: (in list_devices)
[12:22] <Keybuk> hunger: is your wifi card working?  is it up?
[12:22] <Keybuk> pitti: when does it call that?
[12:22] <pitti> Keybuk: might very well be that the usblp driver was broken in a more recent kernel
[12:22] <pitti> Keybuk: whenever you ask for the device list
[12:22] <hunger> Keybuk: It is down at the moment.
[12:22] <pitti> Keybuk: but manually forcing usb:/dev/lp0 as a device doesn't work any more either
[12:22] <hunger> Keybuk: Wifi does work.
[12:22] <Keybuk> could be
[12:22] <pitti> Keybuk: I'll gdb this and dig a bit further
[12:23] <Keybuk> I think there's also a race if you have a real /dev/lp0
[12:23] <Keybuk> the kernel uses "lp0" to refer to both a real printer, and a usb printer
[12:23] <pitti> right, that's probably why the USB device detector doesn't check for /dev/lpX
[12:23] <Keybuk> and depending which one gets detected first, wins the name
[12:23] <Keybuk> yeah
[12:24] <pitti> Keybuk: oh, btw, with "yeah, that one I know, I fixed it already locally -- it's /dev/usb/lp0 ... extra /'
[12:24] <pitti> Keybuk: did you mean that it should be /dev/usblp0 right now?
[12:24] <Keybuk> what do you think it should be?
[12:24] <pitti> Keybuk: no, I mean, my current /dev/lp0 is probably my parallel port
[12:25] <pitti> Keybuk: so priting somethign to it is doomed to fail
[12:25] <Keybuk> right
[12:25] <pitti> so there is no device for my printer
[12:25] <Keybuk> yes
[12:25] <Keybuk> here's a good way to fix it
[12:26] <Keybuk> echo 'BUS=="usb", KERNEL=="lp[0-9] *", NAME="usb/%k"' > /etc/udev/rules.d/50-printer.rules
[12:26] <Keybuk> usbplug -Busb
[12:26] <pitti> ok, I have the udevmointor output for the printer
[12:27] <Keybuk> that should create /dev/usb/lp0 for you
[12:27] <Keybuk> sorry, udevplug
[12:30] <pitti> Keybuk: yay, that worked
[12:31] <Keybuk> should it be /dev/usblp0 or /dev/usb/lp0 ?
[12:31] <Keybuk> which one does the cupsys source seem to "prefer" ?
[12:32] <pitti> Keybuk: /dev/usblp0
[12:32] <pitti> Keybuk: but it doesn't really care
[12:32] <pitti> Keybuk: but the flat name seems more consistent nowadays
[12:32] <Keybuk> right
[12:32] <Keybuk> flat it is then
[12:33] <pitti> Keybuk: what I don't understand is: there already is a rule 'SUBSYSTEM=="usb", KERNEL="lp[0-9] *",     GROUP="lp"'
[12:34] <pitti> Keybuk: is SUBSYSTEM wrong?
[12:34] <pitti> it's obviously evaluated since the permissions are correct
[12:34] <pitti> so both rules match
[12:34] <pitti> but with only this rule I should have gotten a /dev/lp1
[12:34] <pitti> oh, wait, no
[12:35] <pitti> it seems that the kernel enumerates usb lp devices separately
[12:35] <Keybuk> exactlyu
[12:35] <Keybuk> kernel names them *both* lp0
[12:35] <Keybuk> and udev doesn't compensate by re-enumeration
[12:35] <pitti> that explains the race
[12:40] <pitti> Keybuk: shall I open a bug report with that rule? or is your todo list enough for that?
[12:46] <Keybuk> pitti: it's already done
[12:46] <Keybuk> pending, if you like
[12:46] <Keybuk> doing an update to 077 today, then will release it
[12:47] <pitti> ok, great; then a bug report doesn't make sense
[12:48] <pitti> Keybuk: l-wlan-ng is a kernel fault, btw
[12:48] <fabbione> pitti: how's that?
[12:49] <pitti> fabbione: well, not a bug in the kernel itself, just the prism2_usb driver needs updates for the new kernel
[12:49] <fabbione> ok..
[12:49] <pitti> fabbione: dmesg says 'driver is using old /proc/net/wireless support, please fix driver'
[12:49] <fabbione> ehehe
[12:50] <pitti> module is loaded, wlan0 appears in iwconfig, but with 'no wireless support'
[12:50] <fabbione> fix the driver ;)
[12:51] <pitti> and what do I do in the afternoon?
[12:51] <eruin> is "dlopen: /usr/lib/xorg/modules/libGLcore.so: undefined symbol: __glXLastContext" (Failed to load libGLcore.so) a candidate for a bug report? I saw a f-d mail about it ( https://www.redhat.com/archives/fedora-devel-list/2005-November/msg00558.html ) where someone had the issue with using the nv driver on the same xorg version as is in dapper, which leads me to believe it's not an issue with the fglrx I'm trying to use, but with xorg
[12:52] <eruin> if this stinks end-user-support, feel free to ignore ;)
[12:55] <mvo> eruin: do you use the "ati" driver?
[12:56] <eruin> currently trying to use fglrx
[01:34] <eruin> mvo, was that a rhetorical question? ;)
[01:35] <mvo> eruin: oh, no. it's just had the ati driver has the same problem, but apparently i810, nv work fine
[01:36] <eruin> mvo, hmm, according to the f-d list thread, nv has the same issue
[01:36] <eruin> though that might ofcourse not apply to dapper
[01:44] <pitti> Hi jbailey
[01:44] <djk_> doko: hi, why does the OOo package not include DicOOo and why does it not use the standard OOo buttons?
[01:45] <jbailey> g'm Martin (et al)
[01:45] <dholbach> djk_: do you have openoffice2-gnome installed?
[01:46] <djk_> dholbach: i use kubuntu and the 1.9.129 package
[01:47] <dholbach> i see, was just a quick guess
[01:48] <doko> djk_: remove openoffice.org2-kde
[01:49] <djk_> doko: it's not the buttons i actually care about, i just wonder why DicOOo wasn't included.
[01:49] <doko> license problems
[01:50] <djk_> doko: oh, i didn't know that file had a different license than the rest of OOo.
[01:52] <doko> it's worse. the licenses differ from dictionary to dictionary (language to language)
[01:54] <djk_> ah okay, that explains this of course. could one add a notice to the ubuntu releases regarding that?
[02:09] <doko> chmj: please build libxml-commons-resolver1.1-java without libxerces-java, which is not in main
[02:12] <chmj> doko: got it
[02:14] <doko> chmj: ok
[02:26] <Keybuk> pitti: typo in auto-generated libgphoto2 rules ... you have "Goto=" not "GOTO=" :p
[02:27] <pitti> Keybuk: oh, thanks; I'll file a Debian bug and fix that in our packages
[02:31] <pitti> jbailey: how difficult would it be to add another locales defintions path to localedef?
[02:31] <jbailey> pitti: What do you mean?
[02:31] <pitti> jbailey: we need a locales-all package since some packages need the locales in their test suites at build time (gcc, etc.)
[02:31] <pitti> jbailey: right now, localedef looks in /usr/share/i18n/locales
[02:32] <jsgotangco> hi
[02:32] <pitti> jbailey: can we have it additionally look into /usr/share/locales-all? (or sth. similar)
[02:32] <pitti> jbailey: to avoid a file conflict of locales-all with the langpacks
[02:33] <jbailey> Yes, that can be done, I think.
[02:34] <jbailey> Do you need glibc to look at those as well, though?
[02:34] <jbailey> I think you do.
[02:34] <pitti> jbailey: hm, I don't
[02:34] <pitti> jbailey: the only issue is the path of the definition sources
[02:34] <pitti> not the binary generated ones
[02:34] <pitti> jbailey: we only need to unbreak the test suites
[02:34] <jbailey> Ah, I see.
[02:35] <jbailey> So it's for an overall dump that can be just installed and generated as needed?
[02:37] <pitti> jbailey: right, it should just become a build dep of python, gcc, bash (and possibly a few others)
[02:37] <pitti> jbailey: pretty hackish, but I don't see another good solution; doko doesn't want gcc et al to b-dep on 10 langpacks
[02:38] <pitti> (understandably...)
[02:38] <jbailey> Lazy sod.
[02:38] <jbailey> =)
[02:38] <pitti> jbailey: so this -all package can just be generated from langpack-o-matic, which has the locale data
[02:39] <pitti> jbailey: alternatively, we change the structure again to just use this -all package in the langpacks and not ship the locales in the langpacks itself
[02:39] <pitti> jbailey: it doesn't sound too bad either
[02:39] <pitti> (and then -all is superfluous, it should just be locales)
[02:40] <doko> jbailey: get you coffee^Wtea first, so you become bearable ;-)
[02:40] <doko> pitti: yes, the proposal sounds good
[02:41] <pitti> well, having locales spread in langpacks is still a nice idea IMHO
[02:41] <pitti> e. g. the -all approach would force us to update locales-all whenever we update a locake in a langpack
[02:42] <pitti> so we can't do that after a release
[02:42] <jbailey> Having them spread throughout, I think, make for a more scalable installation as we penetrate to more communities.
[02:42] <pitti> (that's why b-deps on the langpacks are the only true way to get the locales that are actually used in the system)
[02:42] <jbailey> pitti: Is locales-all just intended for build-dep'ing?  Like for testsuites and whatnot?
[02:42] <jbailey> So there'd be no reason to update it after a reelase.
[02:42] <pitti> jbailey: right now, yes
[02:42] <jbailey> (And not much reason to update it ever, really...)
[02:43] <pitti> jbailey: if we don't update it, then it becomes senseless
[02:43] <pitti> then we can as well copy the locales into the sources itself
[02:43] <jbailey> Things that depend on localisations for their testsuites are (to some degree) broken, since there's no promises that the data won't change.  The glibc testsuite made a bunch of assumptions that the belocs locales had changed.
[02:43] <jbailey> Right.  That's part of what I'm wondering.
[02:44] <jbailey> Should the testsuites themselves just cache a version that they know to meet their needs that won't change?
[02:44] <doko> pitti, jbailey: why not ship the data in /usr/share/i18n/locales in the locales package?
[02:44] <pitti> jbailey: according to doko, the testsuites want the actually used locales in the system, which makes sense to me
[02:44] <pitti> doko: file conflict with langpacks
[02:44] <doko> pitti: that's solvable
[02:45] <jbailey> pitti: How does it make sense?  There's no promise about collation ordering, currencies, symbol names, etc.
[02:45] <jbailey> These things do slowly change.
[02:45] <pitti> jbailey: right, comparing string output doesn't make sense, but I don't know what the locale tests actually do. doko?
[02:45] <jbailey> I had to fix the glibc testsuite to work with the belocs data because its internal collation testing relied on ordering that had changed with belocs.
[02:46] <doko> pitti: is the data in /usr/share/i18n/locales managed by rosetta? if not, then there's no reason not to keep it in the locales package
[02:46] <jbailey> pitti: I'd assume everything.  Python / gcj would want to test date, ordering, currency, etc.
[02:46] <pitti> doko: it will be eventually
[02:46] <pitti> doko: that was part of the idea
[02:46] <jbailey> doko: The idea is that as new languages get added to the system, that rosetta can handle all of it.
[02:47] <jbailey> doko: So that you come along and decide to, say, get one of the North American native languages into Ubuntu.  Translators should be able to generally do all that work in rosetta and not bother the poor coders about it. =)
[02:47] <doko> well, why not have the same schema as we have with the language packs: have two locations, and if rosetta has an update, use that one
[02:48] <pitti> that's what the alternative path in localedef is about
[02:48] <pitti> doko: but still the question remains what gcc etc. actually test about a particular locale?
[02:49] <doko> pitti: yes, but packages can continue to b-d on locales, and don't have to be changed
[02:49] <jbailey> doko: That's what we'll do , assuming that it's the right thing.
[02:49] <jbailey> I'm not convinced that it's safe for a package to test based on  properties of a system locale.
[02:49] <doko> pitti: have a look, there are just 60000 test cases ;-)
[02:49] <jbailey> Because you're caching the results of that system locale in the testsuite.
[02:50] <jbailey> With no promise that the system locale is static.
[02:52] <Kamion> jbailey: I can see how you'd want to test against the current system locales, though
[02:52] <\sh> jbailey: Sure...I would like to see you doing some lectures on cdbs for the ubuntu motu school :) lets talk about date and time later
[02:53] <Kamion> as opposed to some artificial set of locales that don't actually correspond to what will be used
[02:53] <doko> jbailey: well, that's no change to the current approach. We do work with the system locale, so we should test with it as well
[02:53] <infinity> jbailey : By that argument, we shouldn't have testsuites, unless we're going to re-run them every time anything on the system changes.
[02:53] <jbailey> Kamion: It depends on what you're testing.
[02:53] <Kamion> glibc's a special case because it's shipping tools that manage the locales, but most other testsuites will want to test that they work *with* the system locales
[02:53] <pitti> Kamion: it depends on what you actually test for
[02:54] <jbailey> Most of the time I don't think they're actually interested in testing that "In german, collation comes out in this order".  That's a nonsensical test.
[02:55] <jbailey> What I suspect that they want is that a series of colation option DTRT.
[02:55] <jbailey> And that this is conveninently tested by looking at German, Chinese, and Khosa. =)
[02:55] <jbailey> \sh: Lovely. =)
[02:56] <pitti_> hrmpf network
 Kamion: an artificial locale is the right thing for checking correct collation, time formatting, etc., whereas the system locale is good for checking for - well - hmm, whether the time is formatted at all?
[02:56] <\sh> jbailey: Well, I have to thank you for raising this idea...I wanted to ask you anyways :)
[02:56] <doko> \sh: ask jbailey to talk about the finished cdbs2 implementation ;-P
[02:56] <jbailey> \sh: Now's not the best time, I'm split between two things already at once.
[02:57] <\sh> jbailey: well...the plan is to have at least every two weeks one lecture (from january on)
[02:57] <\sh> jbailey: I'm preparing some timetable now...and collecting the topics and the speakers :)
[02:57] <pitti> I thought cdbs2 would never see the light of the day, in favor of -3?
[02:58] <\sh> doko: well...I heard, you wanted to do a nice lecture about "ABI Transitions...how to find the right packages to transition!" topic...
[02:59] <doko> \sh: you're the expert ;-)
[03:00] <jbailey> infinity: Isn't the proposal at some point to separate the builds from the testsuites so that a test run can be done later?
[03:00] <\sh> doko: but you prepare this stuff...and I would like you to explain why it has to be done and how it's working...would be nice if you could do this in the near future...(february sometimes)
[03:00] <jbailey> infinity: I thought I heard someone suggesting that at UBZ.
[03:01] <jbailey> infinity: But mostly, I think it depends on what you're testing for.  I'd be curious in which cases programs are testing things which are actually best served by the actual results from the system locales.
[03:02] <infinity> jbailey : I don't recall anyone suggesting build/test separation, but I approve of the general idea.
[03:03] <jbailey> infinity: I'll try and come up with the who said it.
[03:03] <jbailey> infinity: It wouldn't be the first time I've dreamed of a coworker saying something and then implemented it as if it were fact.  *sigh*
[03:03] <jbailey> (Or gone to them and asked them if they were insane)
[03:04] <fabbione> doko: should i bother to try the new oo2 on sparc?
[03:04] <jbailey> fabbione: You were complaining yesterday that the buildd was idle ;)
[03:04] <fabbione> jbailey: i did a give back :)
[03:05] <doko> fabbione: it should not fail, but wait until the i386 build succeeds
[03:05] <fabbione> jbailey: and each doko upload means ~ 24 hours of work for my buildd
[03:05] <fabbione> doko: will do thanks dude
[03:05] <Keybuk> pitti: what's with the ENV{UDEVD_EVENT} and ENV{SEQNUM} checks in /etc/udev/rules.d/85-hal.rules ?
[03:06] <Keybuk> oh, and there's a typo in there too
[03:06] <Keybuk> I think that file should be just:
[03:06] <Keybuk> RUN+="socket:/org/freedesktop/hal/udev_event"
[03:06] <Keybuk> SUBSYSTEM=="block", ACTION=="remove", RUN+="/lib/udev/hal-unmount.sh"
[03:06] <Kamion> jbailey: build/test separation is part of AutomatedTesting, yes
[03:06] <Keybuk> (note ACTION== not ACTION=, and move the helper to /lib/udev if you like)
[03:07] <jbailey> Kamion: Oh good. =)
[03:07] <pitti> Keybuk: dunno, these SEQNUM and UDEVD_EVENT checks were there for ages, I didn't change them
[03:08] <Keybuk> pitti: they're a bit irrelevant now :p
[03:08] <pitti> Keybuk: ok, I'll clean it up
[03:10] <pitti> Keybuk: ok, fixed in my local package; I'll upload it when I fixed some more stuff
[03:16] <pitti> Hi BenC
[03:16] <BenC> hey pitti
[03:38] <seb128> doko: thanks for pinging me for the menus change before uploading openoffice.org2
[03:38] <Kamion> pitti: hmm, I just found my sysfsutils patch was slightly wrong
[03:39] <Kamion> pitti: could you please arrange for the udeb to remove the libsysfs.so.1 symlink and move libsysfs.so.1.0.3 to libsysfs.so.1?
[03:39] <pitti> Kamion: I can change it in Debian quickly (oh, we can sync, btw)
[03:39] <pitti> Kamion: sure, that's not a problem
[03:39] <doko> seb128: that won't be the only upload this week
[03:40] <Kamion> I'll just check that that really works, but d-i library reduction fails otherwise and I think that's why
[03:40] <pitti> Kamion: ah, there should be no library symlinks in udebs in general?
[03:41] <Kamion> it seems to break when there are library symlinks in /lib
[03:41] <Kamion> hmm, I may have an alternative solution though, one sec
[03:41] <seb128> doko: I'll do the patch now, please ship it with next one :)
[03:41] <Kamion> library symlinks are kinda pointless in udebs though :)
[03:42] <pitti> right
[03:48] <Kamion> pitti: ok, my workaround didn't work, but moving the library does work, so yes, please do that thanks :)
[03:48] <\sh> STRIKE
[03:48] <\sh> I just ordered a nice amd64
[03:48] <pitti> Kamion: ok, I'll upload it to Debian and then we sync from incoming in half an hour?
[03:48] <Kamion> works for me
[03:49] <ogra> \sh, WOW !!!
[03:49] <ogra> \sh, congrats
[03:49] <\sh> ogra: including everything 450,-  (shipping, etc.) but no monitor...
[03:50] <\sh> which means I need to install ubuntu via serial...
[03:50] <\sh> I hope this is possible
[03:50] <raphink> Ubuntu lacks a netinstall
[03:50] <jbailey> \sh: Works on sparc. =)
[03:50] <raphink> or I yet have to find it
[03:51] <raphink> if it exists
[03:51] <Kamion> raphink: http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/images/netboot/
[03:51] <\sh> raphink: no..netinstall works :)
[03:51] <Kamion> next time start out with a question rather than a statement :-P
[03:51] <raphink> oh good
[03:51] <ogra> heh
[03:51] <raphink> hehe
[03:51] <raphink> I missed it several times
[03:51] <raphink> it's not easy to find
[03:52] <Kamion> yeah, it should be documented better. it's referenced in the installation manual shipped on the CDs
[03:52] <raphink> hehe sorry Kamion ;)
[03:52] <zakame> Kamion: ooh netinstall! :D
[03:52] <ogra> a wikipage would suffice i guess ;)
[03:52] <raphink> zakame: you ignored there was one, too ? ;)
[03:52] <raphink> ogra : agreed
[03:52] <Kamion> ogra: no, not really, it needs to be linked from www.u.c/download/ and cdimage, probably
[03:52] <zakame> raphink: well I remembered Debian has it, so Ubuntu should have it too :)
[03:53] <raphink> zakame: that's what I thought at first, but lately I searched for it and couldn't find one, only threads about creating one
[03:53] <Kamion> ogra: I can tell that a wiki page doesn't suffice because there's already more than one
[03:53] <raphink> so i'm happy there's one :)
[03:53] <ogra> Kamion, yes, but for a start it would be nice to find the url by searching for netinstall
[03:53] <raphink> that's very useful
[03:53] <\sh> jbailey: on sparc I know that it works :) but do we have enabled serial output in our syslinux and kernel?
[03:53] <Kamion> (Installation/Netboot, Installation/LocalNet, etc.)
[03:53] <\sh> ogra: search for netinstall on the wiki
[03:53] <ogra> oh, yes
[03:54] <Kamion> ogra: netinstall means something else in a Debian context; netboot is usually close enough for most people, but it isn't the same
[03:54] <ogra> i searched for title ...
[03:54] <ogra> a conten search throws ot several pages
[03:54] <ogra> *content
[03:54] <Kamion> so I do not advertise the netboot images as netinstall (i.e. CD images containing the full installer and base system but requiring you to download the rest from the network)
[03:55] <\sh> Kamion: do you actually know if we enabled serial output in syslinux and the kernel?
[03:55] <ogra> damned i need a serial mouse ...
[03:55] <Kamion> \sh: not for certain, no, although I'd be surprised if it were disabled
[03:55] <raphink> there's https://wiki.ubuntu.com/Installation/Netboot?action=show&redirect=NetbootInstall
[03:55] <Kamion> Debian has it on and I certainly haven't turned it off in syslinux
[03:56] <\sh> Kamion: ok...I'll check it out on friday..when the computer is delivered :)
[03:57] <raphink> Kamion: yes I meant netinstall as a small (10 MB) CD that contains the installer and installs everything from network
[03:57] <zakame> er, I'm not sure if this is the right place, but I'm toying with the idea of a graphical first time guide, similar to what xp has (its in flash)...
[03:57] <ogra> \sh, do you have access to serial mice anywhere ? apparently the serial mouse patches to ltsp dont work and i cant even test it
[03:57] <sivang> \sh: bought a new machine ? :)
[03:57] <Kamion> raphink: "yes <contradiction>" ;-)
[03:57] <raphink> hehe ;)
[03:57] <raphink> well gtg
[03:57] <raphink> later
[03:57] <Kamion> raphink: the netboot images I pointed you to contain the core of the installer and enough to get more
[03:57] <\sh> ogra: sorry no...I only have access to a ps/2 mouse
[03:57] <zakame> bye raphink :)
[03:57] <\sh> sivang: finally
[03:58] <Kamion> and the image is less than 10MB, yes
[03:58] <sivang> \sh: I also want to get an amd64 machine, soon
[03:59] <ogra> i can only test liveCDs ... :/
[04:00] <\sh> ogra: pegasos
[04:00] <ogra> hmm, whats still making acpi-support and powermanagement-interface uninstallable ?
[04:00] <ogra> \sh, nah ... i want something commonly used
[04:00] <ogra> who uses *pegasos*
[04:00] <\sh> mac mini then :)
[04:02] <ogra> yes, but they are still expensive ... only for install tests ... i think i'll look for a cheapo used iMac or something ...
[04:05] <seb128> doko: there is just the debian/template.desktop.in to not ship (debian/rules to change for that), do you need a patch or could you make the few changes for that?
[04:06] <doko> seb128: that file isn't used
[04:07] <sivang> ogra: ebay should probably have enough offerings
[04:07] <ogra> i guess so
[04:07] <seb128> doko: ?
[04:07] <seb128> $ grep "desktop.in" rules
[04:07] <seb128>         sed 's/@VER@/$(VER)/g' debian/template.desktop.in \
[04:07] <seb128>         sed 's/@VER@/$(VER)/g' debian/template.desktop.in \
[04:07] <seb128> doko: that seems to be the menu entry we want to drop to me
[04:08] <seb128> (I've 1.9.129 source package)
[04:08] <doko> ahh, ok, for the "From Template ..." one
[04:09] <seb128> doko: yep
[04:13] <seb128> doko: so, do you want a patch or you just do the changes for that for the next upload?
[04:14] <doko> seb128: please send me a patch, you can use the file from 1.9.129. it's unchanged
[04:28] <ogra> hmm, 165 doesnt seem to much for an unsed iMac
[04:29] <ogra> *used
[04:32] <Amaranth> yeah, but new ones are faster than advertised, have more video ram than advertised, and have a faster HD
[04:33] <ogra> but what for ? i only need it for install tests i'll never work with it ...
[04:33] <ogra> or for ltsp client tests
[04:41] <pitti> Kamion: sysfsutils_1.3.0-5_i386.changes  is on incoming.d.o
[04:41] <pitti> Kamion: current Ubuntu changes can be overwritten, if you want to sync yourself
[04:44] <zakame> er, what's policy for java packages in ubuntu?  I'm trying to merge lucene, and I'm reconciling the b-d-i's...
[04:53] <Kamion> elmo: please sync sysfsutils from incoming, ok to overwrite; needed for d-i to build
[04:53] <Kamion> pitti: thanks
[05:34] <elmo> partman (68/74ubuntu2+1): in main - skipping.
[05:34] <elmo> Kamion: ok to remove or not?
[05:35] <Diziet> Hmm.  So I want to make a new project/package/thing for AutomatedTesting (got to the top of my list, yay).
[05:35] <Kamion> elmo: not - partman.udeb's been replaced by partman.deb
[05:35] <Diziet> What should I do about revision control ?  (a) cp -a   (b) CVS   (c) baz   (d) bzr  (e) hct  ?
[05:37] <mdke_> elmo, <insert daily ping about docteam commit access here>
[05:37] <jbailey> Diziet: I don't think (e) is far enough along yet to generally use the way you'll want, and is primarily targetted to packages.
[05:37] <Diziet> This won't be a complicated project.  Is bzr ready enough ?  How's its integration with the .dsc toolchains ?
[05:37] <Diziet> jbailey: Right.  This will be a package.
[05:37] <jbailey> Diziet: I use bzr for all my personal projects now.
[05:37] <jbailey> I haven't gotten around to writing bzr-buildpackage, although I keep meaning to.
[05:37] <jbailey> More interesting things keep coming up for spare time hacking like that.
[05:38] <Diziet> Right :-).  I'm not sure I want to get into that kind of yak-shaving either.  Presumably if you haven't done it yet it's not that essential.
[05:38] <mvo> I use bzr as well for all new stuff and it works very well for me
[05:38] <Diziet> I haven't used bzr at all.
[05:38] <jbailey> Diziet: Are you likely to be the main developer for this stuff?
[05:38] <Diziet> Yes, at least for now.
[05:38] <jbailey> Diziet: Here's all you need to know to start with:
[05:38] <Diziet> But I should learn bzr anyway so maybe this is a good place to start.
[05:39] <jbailey> Diziet: Put everything in a directory where you want it and are ready for the initial commit.  Then do: bzr init; bzr add .; bzr commit -m "Initial Commit"
[05:39] <jbailey> Diziet: Literally: Setup the repo, add all the files from the current directory down, actually do the commit.
[05:39] <Diziet> I'm very `commit early, commit often' whereever possible.  bzr's cheap branches seem likely to be good for that.
[05:39] <jbailey> Diziet: It requires no server.  It puts everything in a .bzr directory off the root of the tree.
[05:40] <Diziet> jb: And when you dpkg-buildpackage you end up shipping a copy of the repo too ?
[05:40] <jbailey> Diziet: I do a -I.bzr in my debuild.
[05:40] <Diziet> jbailey: Right.
[05:41] <mvo> Diziet: I have a arch-build in my debian/rules with  "tar cf - `bzr inventory` | (cd debian/arch-build/$(PKG)-$(DEBVER);tar xf -)
[05:41] <mvo> "
[05:41] <Diziet> Oh, debuild has been rewritten by someone-not-Christoph-Lameter.  Maybe I'll try it out some time :-).
[05:42] <Diziet> mvo: :-).
[05:43] <Diziet> Err, WDYM `arch' ?  Is this `bazaar is a brand so it doesn't mean anything, and bazaar is supposedly the successor to arch, so arch must be a brand too, so arch==bzr' ? :-)
[05:43] <jbailey> Diziet: I've done a ssh people.ubuntu.com mkdir -p public_html/bzrtree then after that "bzr push people.ubuntu.com:public_html/bzrtree/PACKAGE"
[05:43] <jbailey> Diziet: And then anyone else can branch from you trivially.  And then it's also someone else job to put it onto a tape backup. =)
[05:43] <Diziet> Is there a bzr reference manual ?  I like reference manuals much more than recipes and howtos.
[05:44] <Diziet> I have my own tape backup here :-P.
[05:44] <jbailey> I do too.  It's in a box somewhere.
[05:44] <jbailey> I don't know if I can still buy tapes for it. =)
[05:44] <Diziet> Right under the 4 obsolete CRTs and the Sun4c, right.
[05:44] <jbailey> Hey it's not that bad.
[05:44] <jbailey> It's a Mips 5000. =)
[05:45] <jbailey> Diziet: But basically after that, all you need is the occasional bzr add and frequent bzr commits, and end of day bzr push's.
[05:46] <jbailey> It caches the location of the last push, so just "bzr push" is enough after that.
[05:46] <Diziet> Like I say, I want a reference manual.
[05:46] <Diziet> Cool.
[05:46] <jbailey> There might even be one.  I
[05:46] <jbailey> 'll go looking when I decide to figure out how merges and cherrypicking works. =)
[05:47] <Kamion> jbailey: do you happen to know if there's any way to tell whether you're in an initrd or an initramfs?
[05:47] <Kamion> from the perspective of a random shell script running in either
[05:47] <Diziet> Hmm.  I can have   http://www.bazaar-ng.org/obsolete-docs/cmdref.html   which looks nice but out of date, or a wiki (doom).
[05:47] <Kamion> or 'bzr help commands'
[05:48] <jbailey> Kamion: Am I allowed to assume that the initramfs was created by initramfs-tools, or are you looking from the first point when you start up?
[05:48] <Diziet> That's not quite a reference manual :-).
[05:48] <Kamion> (although I realise you need an initial "how does it all go together" first
[05:48] <Kamion> jbailey: neither, because this is in the live CD
[05:49] <\sh> going home
[05:49] <Kamion> I can put a cue-file in if I *have* to, but I'd rather not
[05:49] <mdke_> elmo, thanks!
[05:49] <jbailey> Kamion: My best guess is that you might be able to check filesystem type.
[05:49] <jbailey> Kamion: initrd might be a read-only cramfs.
[05:49] <jbailey> initramfs is a RW cramfs.
[05:49] <jbailey> err.
[05:49] <jbailey> RW ramfs
[05:49] <jbailey> but that's a guess.
[05:50] <Kamion> in an initrd it's 'tmpfs on / type tmpfs (rw)'
[05:50] <Kamion> well, in *this* initrd
[05:50] <Kamion> jbailey: also, do you know if anyone's already porting klibc's run-init to busybox?
[05:52] <jbailey> Kamion: Oh hm.  you're using ext2 images aren't,you?
[05:52] <Kamion> that said I suppose run-init's trivial if you don't bother to remove the initramfs contents and if you assume that the new root filesystem has mount and chroot
[05:52] <Kamion> jbailey: varies by arch
[05:52] <Kamion> from 2.6.15 installer images onwards, at least in Ubuntu, it will be initramfs for everything; before that, it was ext2 on some and cramfs on others, depending on size restrictions and on what our beloved kernel team decided to provide ;)
[05:53] <Kamion> (gzipped ext2 was rather more size-efficient than cramfs last time I checked, but wasn't available everywhere)
[05:57] <Diziet> Urgh, James B consistently writes `independantly'.
[06:00] <lucas> I have a problem with a desktop system which hangs during shutdown/reboot. On which package should I report the bug on bugzilla ?
[06:01] <mdke> lucas, do the best you can. If you have no idea, try UNKNOWN, and it will get reassigned appropriately.
[06:02] <mdke> Diziet, is that on the wiki? maybe we can correct it
[06:02] <ogra> lucas, look for it in bugzilla, i'm sure there are bugs already ...
[06:02] <lucas> well, I was hoping to skip one step by asking here :)
[06:02] <Diziet> mdke: No, it's on his blog.
[06:02] <mdke> ah :(
[06:31] <elmo> doko!
[06:31] <elmo> WTH is this oo.o -experimental crap?!
[06:32] <doko> elmo: native amd64 packages, as discussed on the last meeting
[06:32] <elmo> which meeting?
[06:32] <ogra> elmo, the weekly meeting
[06:33] <ogra> dapper dev
[06:33] <doko> yep
[06:33] <doko> elmo: these will go away before dapper is released
[06:34] <ogra> its only for the flight 2 CD for now ...
[06:34] <doko> ogra: no way!
[06:34] <ogra> doko, ??
[06:34] <ogra> did you say you build them to make flight 2 possible ? or did i get that wrong ?
[06:35] <doko> yes, you're wrong, we'll use the ia32 binaries
[06:35] <ogra> ah, k
[06:35] <ogra> so ignore me then :)
[06:40] <elmo> dear lazychannel, where are the logs for this meeting? kthx
[06:44] <doko> OOo build with -j3 was not a good idea ...
[06:49] <elmo> ok, so I found the last meeting can't see any refernce to this, seriously, someone pls give me a useful keyword to search on, I've tried the obvious ones (oo.o, amd64, experimental)
[06:50] <doko> Mithrandir doko: are you doing the ooo-amd64 stuff as well?  It's a fairly easy change, I'd imagine?
[06:50] <Riddell> _mvo_: kdebase-bin I think
[06:50] <doko> elmo: ^^^
[06:50] <_mvo_> Riddell: thanks
[06:51] <pitti> mvo: move it :)
[06:58] <elmo> doko: pfft
[07:02] <LaserJock> Amaranth: ping?
[07:11] <thierry_> seb128_ : does the .desktop file get translated by default or we need to set something special for it? (like a happy maintainer that adds translation directly in the .desktop file?)
[07:13] <doko> elmo: as the OOo build failed, I need another upload. so what does the "pfft" mean? ;-)
[07:13] <seb128_> thierry_: that's why one the reason why desktop files should go upstream
[07:14] <thierry_> seb128_ : ok but when upstream, do they go in the translations files?
[07:14] <elmo> doko: there's no actual discussion in that meeting or justification
[07:14] <elmo> doko: do these packages work?
[07:14] <elmo> doko: if not, why build them?  if they do, why not just ship them as the default?
[07:14] <elmo> doko: are we going to ship with these in dapper?
[07:14] <elmo> etc.
[07:15] <seb128_> thierry_: the strings are listed by the pot file if that's the question
[07:15] <thierry_> k thanks
[07:15] <thierry_> seb128 : well in fact I wanted to know if they are listed automatically, or someone needs to add them?
[07:16] <doko> elmo: not shipping in dapper, testing, the build, they work until they crash. ok, I'll let Mithrand1r sort this out, it's not my task anyway.
[07:17] <seb128> thierry_: you need to make a desktop.in and to list in with po/POTFILES*
[07:17] <thierry_> seb128 : and how do I do that?
[07:18] <thierry_> seb128 : what's the difference between a .desktop and a .desktop.in
[07:19] <seb128> thierry_: the first has the translation and is generated from the second
[07:20] <seb128> thierry_: look on whatever source package, the .desktop.in has _Name=, _Description=. The .desktop is made from this one using the po translations for those
[07:22] <thierry_> seb128 : ok but if I sent a .desktop addition to upstream, will they create the .desktop.in or is my job to do so?
[07:23] <seb128> thierry_: better to do it, but they will probably do it other way
[07:24] <thierry_> seb128 : ok cool, but how do I do it? where do I put this file? in debian directory?
[07:26] <seb128> look on other package sources
[07:26] <seb128> usually data/
[07:27] <seb128> you need to list the Makefile.am
[07:27] <seb128> s/list/change/
[07:28] <LaserJock> elmo: can I request a sync of ghemical? I have verified that the Debian unstable source builds in a dapper pbuilder and the previous Ubuntu changes are no longer neccessary.
[07:28] <thierry_> seb128 : and is "cp src/pixmaps/sine.xpm debian/geg/usr/share/pixmaps" a good way to copy the icon in /usr/share/pixmaps ?
[07:29] <seb128> for a package that's a way, for upstream no
[07:29] <thierry_> seb128 : why not for upstream??
[07:30] <ogra> because upstream doesnt use the debian dir and might want to integrate with his .po files
[07:30] <thierry_> ogra : k but what do I do if I want to sent my patch upstream?
[07:31] <elmo> LaserJock: are you a motu?
[07:31] <seb128> thierry_: learn?
[07:31] <ogra> ask upstream how he wants it first ?
[07:31] <ogra> he/shce might telly you what to do
[07:31] <seb128> thierry_: you need to change the Makefile.am to get the file shipped
[07:32] <ogra> elmo, not yet
[07:32] <LaserJock> elmo: no, not yet, but the Debian maintainer is azeem. He can verify
[07:32] <thierry_> seb128 : mmm any wiki or guide for that?
[07:32] <azeem> I am not a motu, either
[07:32] <elmo> LaserJock: get a motu to verify and I'll sync.  what's your preferred email?
[07:32] <LaserJock> elmo<EMAIL_ADDRESS>[07:33] <seb128> thierry_: nop, just look at some package as example
[07:34] <elmo> LaserJock: ok, whitelisted you - lemme know when you've got a MOTU to sign off
[07:34] <LaserJock> elmo: ok, thanks
[07:55] <Amaranth> LaserJock: pong
[07:55] <LaserJock> Amaranth: I have a menu question
[07:56] <Amaranth> I'm psychic. ;)
[07:56] <LaserJock> Amaranth: Is it ok to put Categories=Application;Science; in a .desktop?
[07:56] <LaserJock> lol
[07:57] <LaserJock> I mean there isn't a Science menu but there really should be one, I think
[07:57] <Amaranth> I don't see why not.
[07:57] <Amaranth> It's a valid category according to the spec.
[07:57] <Amaranth> But GNOME's applications.menu doesn't have any sorting for it.
[07:58] <LaserJock> Amaranth: right so what will happen to it?
[07:58] <Amaranth> It'll go into Other.
[07:58] <LaserJock> Amaranth: that stinks
[07:58] <LaserJock> so is that a Gnome problem?
[07:58] <Amaranth> Define "problem".
[07:59] <Amaranth> I'm sure it'll get flagged NOTABUG.
[07:59] <\sh> god bless daniels...he gave me back xvfb-run :)
[07:59] <LaserJock> well, it should go in Science not other
[07:59] <\sh> daniels: thx
[08:00] <Amaranth> LaserJock: Science doesn't exist in the GNOME menu and they'll say it's too specialist to include.
[08:00] <Amaranth> I believe someone already tried to get it.
[08:00] <\sh> daniels: but you broke it :( or gtk is broken
[08:00] <Amaranth> blame gtk
[08:00] <Amaranth> :)
[08:00] <\sh> ** ERROR **: Failed to init GTK+
[08:00] <\sh> aborting...
[08:00] <LaserJock> Amaranth: that's irritating, so there isn't anything we can do about it>
[08:00] <\sh> /usr/bin/xvfb-run: line 153:  5102 Trace/breakpoint trap   DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@" 2>&1
[08:00] <thierry_> LaserJock : I just installed a rebuilt package with a new .desktop file with the science menu as category, and I get nothing in the menu, not even others
[08:00] <\sh> /usr/bin/xvfb-run: line 158: kill: (5100) - No such process
[08:00] <Amaranth> LaserJock: You can put it in more than one menu.
[08:00] <Amaranth> thierry_: Then your .desktop file isn't valid.
[08:01] <Amaranth> thierry_: If my dapper vmware image worked I'd tell you the command to run to check it.
[08:01] <thierry_> Amaranth : thierry@modemcable050:~/dev/geg-1.0.2/debian$ desktop-file-validate geg.desktop
[08:01] <thierry_> thierry@modemcable050:~/dev/geg-1.0.2/debian$
[08:01] <LaserJock> Amaranth: what do you mean but "put it in more than one menu", like a different category?
[08:02] <LaserJock> s/but/by/
[08:02] <Amaranth> LaserJock: Yeah, you can do Categories=Applications;Science;Education; or something.
[08:03] <LaserJock> Amaranth: yeah, well I guess that will have to do. I was trying to avoid putting non educational things in Education.
[08:03] <Amaranth> science apps are always educational :)
[08:04] <Amaranth> they teach you about your level of patience :D
[08:04] <thierry_> Amaranth LaserJock : maybe we could retry sending a bug to gnome since it doesn't make very professional putting science stuff in education menu, wich doesn't even have an icon!
[08:05] <LaserJock> Amaranth: but seriously, many of them are real research tools. oh well
[08:05] <thierry_> it's ugly looking and not very well triaged...
[08:05] <Amaranth> http://bugzilla.gnome.org/show_bug.cgi?id=140900
[08:07] <Amaranth> LaserJock, thierry_: Poke that bug, see if someone responds.
[08:07] <\sh> grmpf
[08:08] <LaserJock> yeah, ok thanks for your help Amaranth. I don't want to keep you any longer from your other important work ;-)
[08:08] <Amaranth> hehe, these little breaks are fun though
[08:13] <thierry_> Amaranth : just added a comment about how much it was sooooo important that this get fixed :)
[08:26] <fabbione> dear ftpmaster, I really appreciate the sync you have to NEW daily d-i and me running rsync. please shift to normal working hours. kthxbye
[08:27] <elmo> fabbione: -EITAGLISH
[08:27] <fabbione> elmo: ehhe
[08:28] <elmo> fabbione: seriously, I don't parse?
[08:28] <elmo> speaking of daily d-i
[08:28] <elmo> lamont/infinity/kamion: only ia64 is being built ATM
[08:28] <fabbione> elmo: each time you NEW daily d-i, i start rsync and find this nice 300MB of stuff to download :/
[08:28] <Kamion> elmo: sysfsutils upload fixed it, I byhanded amd64 and i386 earlier, when the powerpc buildd gets off its arse and builds sysfsutils it should work too
[08:29] <elmo> Kamion: ah, ok
[08:29] <Kamion> s/upload/sync/
[08:29] <fabbione> shifting 12 hours would let me sync while i am sleeping ;)
[08:29] <Kamion> ah, sysfsutils_powerpc in accepted, woo
[08:29] <Kamion> fabbione: was me doing the byhands, and I'm sorry but I needed to do it fairly urgently
[08:30] <fabbione> Kamion: i will survive :)
[08:30] <Kamion> because I can't do any CD testing at all until that blockage is shifted
[08:30] <fabbione> i love you guys too much to be upset
[08:30] <Kamion> (oh, just on a semantic note, daily d-i doesn't get newed, it gets byhanded ...)
[08:30] <fabbione> right
[08:31] <Kamion> just be glad you aren't mirroring cdimage right now
[08:31] <\sh> Topic No. 8 : "The Ubuntu Vocabulary" -> Host: Kamion
[08:31] <fabbione> Kamion: i do
[08:31] <Kamion> \sh: no :)
[08:31] <fabbione> Kamion: but only once a day in the morning
[08:32] <\sh> Kamion: hehehe
[08:32] <Kamion> fabbione: whoa, insane person
[08:32] <Kamion> what, really cdimage, not releases?
[08:32] <Kamion> oh, iirc you only mirror {daily,daily-live,dvd}/current/ or something, that's not so bad
[08:33] <fabbione> yeah
[08:33] <fabbione> only daily
[08:33] <\sh> elmo: please sync ghemical from unstable, ok to override, thx
[08:33] <fabbione> Kamion: what's up with cdimage?
[08:33] <fabbione> did you decide to re-release warty/hoary and breey in one go?
[08:33] <Kamion> fabbione: no, just doing a fair few builds today that's all
[08:34] <fabbione> eeheh
[08:35] <fabbione> Kamion: do you think we can schedule to start building -server cd's after flight-2 ?
[08:35] <fabbione> speaking of which.. i need to setup the mailing list
[08:35] <Kamion> fabbione: cdimage is already trying to build them
[08:36] <fabbione> Kamion: ah nice.. reports at the usual url?
[08:36] <Kamion> today's build apparently succeeded in fact
[08:36] <Kamion> yeah
[08:36] <fabbione> server rocks!
[08:36] <Kamion> and previous builds have succeeded (from before I turned cdimage off for five days during the kernel madness)
[08:36] <fabbione> ok
[08:36] <fabbione> the 2 problems are known and soon to be addressed
[08:37] <fabbione> as soon as Ben will upload 7.9 i will have to book 20 minutes of your time
[08:37] <fabbione> because we should get the first cut of server kernels
[08:38] <Kamion> meh, that's probably a bit more than 20 minutes
[08:38] <Kamion> hope you don't want them in d-i
[08:38] <fabbione> Kamion: that's what i wanted to talk with you about.. best approach to it
[08:38] <Kamion> 'cos that would be PAIN and SUFFERING
[08:38] <fabbione> i love pain and suffering :)
[08:38] <Kamion> I prefer inflicting pain and suffering on people who overcomplicate the installer build system ;)
[08:38] <trevilor> hi guys
[08:39] <fabbione> Kamion: we can avoid to do that.. really.. ideally we can install with 386 and install by default the 686-server kernel
[08:39] <fabbione> Kamion: optional a 686-superhighendclassservernoyoucantrunthisathomebecauseyoucanteffordthehw
[08:40] <fabbione> but well
[08:40] <fabbione> you tell me when
[08:40] <\sh> ogra: please remind me, if fabbione and kamion are visiting cologne, that I have to go somewhere else...too much SM here
[08:40] <ogra> lol
[08:41] <\sh> love pain and suffering vs. inflict pain and suffering...that's too much stiefelknecht
[08:41] <Kamion> fabbione: right, that sort of thing is only P&S in base-installer, which is not so bad
[08:41] <fabbione> ogra: you should probably show HellRaiser to \sh
[08:41] <Kamion> (it's already a bit of a mess)
[08:41] <fabbione> Kamion: ok :)
[08:41] <ogra> fabbione, i bet he knows it ... (actually i never asked him)
[08:42] <\sh> fabbione: the movie?
[08:42] <\sh> part 1/2/3?
[08:42] <fabbione> \sh: movies
[08:42] <ogra> \sh, ever seen/read hellraiser ?#
[08:42] <fabbione> from 1 to 6 ?
[08:42] <ogra> \sh, all
[08:42] <\sh> i missed 4/5/6
[08:43] <\sh> the guy with the nails in his head, right? actually I don't like b-movies ,)
[08:44] <ogra> \sh, its not a movie, its philosophy :)
[08:45] <tseng> massochism?
[08:45] <fabbione> tseng: no
[08:45] <fabbione> not really
[08:46] <\sh> ogra: hmmm....torrent url? ,-)
[08:47] <\sh> oh no...no space left on home....deleting sources now
[08:47] <fabbione> \sh: time to get a bigger hd
[08:48] <\sh> fabbione: the new machine will be delivered thursday or friday...
[08:48] <ogra> \sh, aldi sells 250 GIG USB HDs for 140
[08:48] <\sh> ogra: I just bought a stupid sempron64
[08:48] <tseng> \sh: ugh
[08:49] <backports-r-us> I need some quick GNOME C help... would this be a good place to ask? (please?)
[08:49] <backports-r-us> It's related to a Universe package :)
[08:50] <rob^^^> ogra: that's wayy too mcuh
[08:50] <\sh> tseng: no ugh...the only thing I could buy for my money :)
[08:50] <tseng> you can get a "free" sun ultra20 :P
[08:50] <backports-r-us> what's the GNOME function for getting the filename of the wallpaper?
[08:51] <ogra> rob^^^, really ?
[08:51] <rob^^^> ogra: indeed. in the US you can regularly get them for about $80 after rebates
[08:51] <ogra> with case and all ?
[08:51] <\sh> rob^^^: and when you import them .. you have to pay customs like hell...
[08:51] <rob^^^> ogra: or external?
[08:52] <rob^^^> err oh
[08:52] <ogra> yes, uUSB HD
[08:52] <rob^^^> hrmmm didn't notice hte uSB in there but you can get those for $30 here
[08:52] <ogra> -u
[08:52] <ogra> so i'm at 110 + wire ...
[08:53] <ogra> might come up to 120 ...
[08:53] <\sh> rob^^^: calculating the customs plus the hw prices ... the result will be the same price like here..or even more expensive
[08:53] <ogra> and i pay 20 for not having to assemble it ;)
[08:53] <rob^^^> man, how do yall make ends meet over there
[08:54] <rob^^^> I'd definately buy a lot less than half the amount of computer junk if it cost twice as much
[08:56] <rob^^^> ogra: is that 160 tax inclusive?
[08:56] <ogra> 140 all inclusive
[08:56] <rob^^^> oh 140
[08:57] <rob^^^> yeah that's ok I guess
[08:58] <\sh> ogra: btw...did you buy this mac now?
[08:58] <ogra> \sh, still waiting for an answer, i mailed them
[08:58] <ogra> but i will, they have plenty others for the same price ...
[08:58] <rob^^^> We just got an Aldi here, I still haven't been
[08:58] <ogra> and i can pick it up in pulheim
[08:59] <\sh> ogra: did you hit the "buy now" button?
[08:59] <rob^^^> what Mac are you buying?
[08:59] <ogra> i have no ebay account ... and wont create one ...
[09:00] <ogra> http://cgi.ebay.de/Apple-iMac-G3-blue-PowerPC-B_W0QQitemZ8728930419QQcategoryZ4603QQrdZ1QQcmdZViewItem
[09:00] <\sh> ogra: I have one...
[09:01] <rob^^^> those are quite slow these days
[09:01] <ogra> its enough... i need one for install CD and live CD testing ... i dont develop on it
[09:01] <rob^^^> ogra: it will definately be faster than PEARPC ;)
[09:02] <ogra> its cheap ...
[09:02] <rob^^^> not having firewire ports is kinda a downer though for real use
[09:02] <ogra> thats all i need ... and i can use it as thin client for ppc tests too
[09:02] <rob^^^> what's a MINI run over there?
[09:03] <rob^^^> having a 128 meg machine for thin-client could be an asset I suppose
[09:03] <ogra> between 4and 500
[09:05] <rob^^^> ogra: probably the only PPC mac that will ever pass through your fingers eh?
[09:06] <ogra> nope, my GF has a grey G4 and i had a iMac flowerpower before i gave away ...
[09:06] <ogra> but my GF does her work on hers, i cant play with install CDs on it
[09:06] <rob^^^> oh
[09:06] <Amaranth> ppc is dead
[09:06] <ogra> thast why i have to care for it for ltsp ...
[09:06] <rob^^^> ogra: is it sawtooth or silverdoor?
[09:06] <xhaker> users ppc computers are not
[09:06] <ogra> they will get cheap ...
[09:07] <ogra> rob^^^, no idea, its grey :)
[09:07] <rob^^^> the silverdoors have silver reflective doors
[09:07] <rob^^^> they go all the way up to like dual 1.25 I believe
[09:23] <\sh> ogra: http://cgi.ebay.de/apple-Mac-Mini-1-25-Ghz-512-40-COMBO_W0QQitemZ8731815198QQcategoryZ99526QQrdZ1QQcmdZViewItem
[09:24] <ogra> \sh, yes, will be around 700~1000 in the end ...
[09:25] <ogra> i'd bet
[09:26] <\sh> ogra: i'll have it on my viewlist
[09:27] <Hieronymus> My webcam crashes Gnomemeeting, and takes the system with it. What info should I put in a bugreport
[09:28] <ogra> Hieronymus, http://wiki.ubuntu.com/HelpingWithBugs
[09:29] <Hieronymus> ogra: well, I know how to file bugs.. but the webcam crashes my system...
[09:31] <mdke_> Hieronymus, saying that would be a good start.
[09:33] <ogra> Hieronymus, https://wiki.ubuntu.com/HelpingWithBugs?action=fullsearch&context=180&value=debug&titlesearch=Titel
[09:34] <ogra> Hieronymus, sorry i had the impression these pages were linked from the HelpingWithBugs page
[09:37] <stockholm> ogra: ping
[09:37] <ogra> stockholm, pong :)
[09:37] <stockholm> ogra: what about dec 17?
[09:38] <stockholm> ogra: could you come to nrnberg? travel could be payed, i think
[09:38] <ogra> hmm...
[09:38] <stockholm> ogra: not by me but by the organizers.
[09:38] <ogra> lol, i guessed so
[09:38] <stockholm> ogra: are you familiar with arktur etc?
[09:39] <ogra> nope
[09:39] <stockholm> and the dramas involved?
[09:39] <stockholm> i am not deeply initiated either.
[09:40] <ogra> ah, i remember the guy from essen
[09:40] <ogra> he's somewhat strange ...
[09:40] <stockholm> but i think it could be a good start to cooperation on this front. not just arktur, but others, too
[09:40] <ogra> and i heard him tell people that edubuntu wasnt for them, they should use his distro
[09:40] <stockholm> ah, right.
[09:41] <ogra> as well as skole wasnt for them
[09:41] <stockholm> and he really is compentent. (c:
[09:41] <ogra> heh
[09:41] <stockholm> they came to our mailinglist for some time and tried to diss us (c:
[09:41] <ogra> i'm not sure if i really want to donate my sparetime to him
[09:42] <stockholm> is he an old ugly guy? then it is Helmut Hullen and he wont be there.
[09:42] <ogra> note that my company wont pay for it so it will be in my private time ...
[09:42] <ogra> yes...
[09:42] <stockholm> yes, he wont come.
[09:42] <stockholm> he does not have many friends, for some reason.
[09:42] <ogra> understandable
[09:43] <ogra> how is the skole relationship to Arktur ?
[09:43] <ogra> except him dissing you
[09:43] <azeem> ugh, Helmut Hullen
[09:43] <ogra> lol
[09:44] <ogra> he seems to be well known in the german community *g*
[09:44] <stockholm> they dont like us because kurt garmlich (know him?) make a great job in marketing and debian-edu is better known then arktur in germany, despite arktur being really old
[09:44] <stockholm> ogra: there are three forks in arktur, helmut hullen does one of them. the oldest and most broken one
[09:44] <ogra> i heard his name, but i dont know him
[09:45] <stockholm> the other two forks will attend.
[09:45] <ogra> is it woody based ?
[09:45] <stockholm> no, it is a mixture of redhat, suse and slackware
[09:46] <stockholm> i dont know how it works in detail
[09:46] <ogra> ouch
[09:46] <ogra> sounds greatly upgradeable and stable :P
[09:46] <stockholm> yes, very ouch. no security support. and you have to recompile everything or it wont fit in
[09:46] <ogra> edugentoo ?
[09:47] <stockholm> it is a nightmare.
[09:47] <ogra> sounds like
[09:47] <stockholm> but ct supports it
[09:47] <stockholm> or distributes it
[09:47] <mdz> mjg59: have you talked with anyone about getting radeontool and smartdimmer into main?
[09:47] <ogra> give me some days to think about, i'm not sure if i can make some free time ...
[09:47] <stockholm> ok
[09:47] <mdz> mjg59: they're tiny; if they're sanely packaged and don't introduce any security concerns it should be straightforward
[09:48] <ogra> stockholm, why do they do that ?
[09:48] <ogra> stockholm, do they get money for promoting it ?
[09:48] <stockholm> ogra: historic reasons, i guess.
[09:48] <ogra> i'd expect more from ct
[09:49] <michele> I have this problem (solved) where I always get an error when unmountin the ipod shuffle because hal wants to eject it
[09:49] <stockholm> it used to be the first think like this
[09:49] <stockholm> ogra: it has quite an install base in germany. 5000 schools or so
[09:49] <ogra> phew
[09:50] <michele> I fixed it by setting storage.requires_eject to false in 10-storage-policy.fdi
[09:50] <michele> it's related to https://bugzilla.ubuntulinux.org/show_bug.cgi?id=2134
[09:50] <ogra> that'd be worth going ... but i also have ot make mdz happy and finish my work ;)
[09:50] <michele> I don't know if I should reopen that bug, report something else, or...
[09:50] <ogra> and i regulary do the stuff thats left from the week on saturdays
[09:51] <stockholm> ogra: in my oppinion mdz should make time for that. it is directly work related
[09:51] <stockholm> mdz: ?
[09:51] <mjg59> mdz: Uhm. I was under the impression that the process was automatic.
[09:51] <ogra> stockholm, it isnt, my focus is ltsp development and i have deadlines
[09:51] <stockholm> hrm.
[09:51] <dholbach> have a nice evening
[09:51] <ogra> edubuntu wont see much further improvements this release
[09:52] <ogra> except community contributed stuff but thats just starting slowly
[09:52] <mjg59> mdz: The packaging looks sane
[09:52] <stockholm> i dont know how you work. i think it is import enough for me to travel for a few days.
[09:53] <stockholm> so obviously i would expect mdz to think similarly
[09:53] <ogra> stockholm, mdz is and thinks like a CTO, not like a merketing guy ;) (which is important)
[09:53] <mdz> mjg59: it has never been automatic; http://wiki.ubuntu.com/UbuntuMainInclusionQueue
[09:54] <stockholm> i dont go there for marketing reasons at all. it is a developer meeting.
[09:54] <ogra> hmm
[09:54] <mjg59> mdz: Ah, right
[09:54] <stockholm> they explicitly DIDnt want kurt garmlich there, eventhough he is intimatly familiar with the german scene.
[09:55] <stockholm> because he is not a developer but marketing person
[09:55] <ogra> stockholm, as i said, give me some time to think about it ... its before christmas and time is short
[09:55] <stockholm> sure.
[10:09] <stockholm> ogra: what was your email? i just got an info mail about the meeting
[10:09] <ogra><EMAIL_ADDRESS>[10:10] <stockholm> *surprise*
[10:10] <stockholm> (c:
[10:10] <ogra> heh
[10:11] <jelkner> is this an ok place to ask a question about what appears to be a network bug?
[10:12] <lifeless> jelkner: if you are not asking for *help* with it, but rather how to *help us fix it* - sure ;)
[10:12] <lifeless> thats the difference between support and development ;)
[10:13] <jelkner> lifeless: yes, but i somewhere in the middle
[10:13] <jelkner> i need to ask for help first, to be sure i have a bug to report
[10:13] <jelkner> (i'm pretty sure i do)
[10:13] <jelkner> and then i need to figure out which package to file it on
[10:14] <jelkner> problem: networking does not work after a breezy install on a toshiba satellite m45-s269
[10:15] <jelkner> the devices (both ethernet and wireless) appear to be recognized, but no connections are possible from either one
[10:17] <mdz> jelkner: seems a bit fishy that they both fail to work in the same way; I'd look for an external problem first
[10:18] <jelkner> such as?
[10:18] <jelkner> i have several other machines on the same network
[10:18] <jelkner> including a laptop using wireless
[10:18] <jelkner> the other machines can connect without problem
[10:18] <jelkner> the toshiba can not
[10:18] <stockholm> jelkner: some security thing perhaps?
[10:18] <jelkner> i feel confident it is a problem with the toshiba
[10:19] <jelkner> nope, *all* security has been turned off
[10:19] <jelkner> i brought another laptop which i know works to test
[10:19] <stockholm> jelkner: does it work with other software?
[10:19] <jelkner> don't know, i guess i could try knoppix
[10:19] <jelkner> let me do that
[10:34] <ProN00b> i need to make a 280gig file as fast as i can, the space doesn't need to be allocated and its contents do not matter, any idea ?
[10:37] <Kamion> ProN00b: dd if=/dev/null of=bigfile count=$((1024*1024*1024)) skip=280
[10:37] <Kamion> er
[10:37] <Kamion> ProN00b: dd if=/dev/null of=bigfile bs=1 seek=$((280*1024*1024*1024)) count=0
[10:37] <Kamion> ignore the first, didn't mean to paste that
[10:37] <Kamion> (#ubuntu in future though ...)
[10:38] <feugan3333> Hi all. What is the easiest way to learn how to create kernel modules. On a stock build kernel or on default ubuntu kernel?
[10:39] <ProN00b> Kamion, count=0 really true ?
[10:40] <Kamion> ProN00b: yes
[10:40] <Kamion> I mean, count=1 if you prefer, but count=0 worked for me
[10:44] <lifeless> so is xpdf meant to be installable with ubuntu-desktop ?
[10:45] <elmo> you're meant to use evince now
[10:45] <lifeless> oh. Whats that ?
[10:45] <elmo> shiny new PDF/PS reader
[10:45] <lifeless> I've been holding up updates for a week now trying to keep pdf
[10:45] <lifeless> xpdf I mean
[10:45] <elmo> but xpdf should install with ubuntu-desktop, FWIW
[10:45] <lifeless> because all hte other readers I've seen blow donkeys
[10:45] <elmo> does here anyway - assuming you mean breezy
[10:45] <elmo> evince is much better than xpdf
[10:45] <elmo> IMO
[10:46] <azeem> lifeless: try evince, it is love
[10:46] <azeem> GNOME love
[10:46] <ogra> elmo++
[10:46] <mdke> evince is quite nice
[10:46] <lifeless> okk, it is installed
[10:46] <lifeless> I shall give it a whirl
[10:46] <lifeless> but yes, xpdf seems to depend on pre c++ transition or something funky
[10:46] <mdke> the text tends to disappear if you click on it
[10:46] <mdke> otherwise its peachy
[10:47] <lifeless> it and devhelp
[10:47] <lifeless> they both try to go away when ever I 'mark all upgrades'
[10:47] <lifeless> mvo: is there a 'why is this being removed' button in synaptic ?
[10:48] <mvo> lifeless: no, but you can set "Debug::pkgProblemResolver=true" and see what it outputs. it's not very friendly though
[10:48] <lifeless> garh
[10:48] <lifeless> would such a button make sense ?
[10:49] <mvo> lifeless: it's something that libapt dosn't provide now. smart will be better in the future
[10:49] <mvo> lifeless: under Settings/Set internal option
[10:50] <mvo> set variable to "Debug::pkgProblemResolver" and value to "true"
[10:50] <mvo> it will give some (more or less) usefull output to clog then
[10:51] <mvo> if you put it into a pastebin I'll have a look
[11:01] <Kamion> mdz: it would be nice if the head entry of debian/changelog in your casper/main branch had some informative contents - it doesn't describe unionfs at all
[11:01] <Kamion> mdz: are you planning to release that to dapper? I know we're replacing a lot of it, but it would be nice to know which one I'm supposed to branch off for trivial changes
[11:01] <Kamion> (which one> main or breezy that is)
[11:02] <ogra> Kamion, always main
[11:02] <ogra> i asked the same about ltsp ;)
[11:05] <Kamion> well, casper probably needs an upload soon to get the live CD working again for Flight CD 2, and I don't want to suck in the unionfs code if it's insufficiently tested yet
[11:06] <ogra> well, yur decision, i was told breezy is done and the branch is there for historical reasons but unmaintained, might be different with casper
[11:07] <Kamion> it's mdz's decision, that's why I'm asking him :)
[11:08] <ogra> indeed :)
[11:12] <Kamion> mdz: speaking of, please merge http://people.ubuntu.com/~cjwatson/bzr/casper/fixes, just a small tweak
[11:20] <lamont__> infinity/elmo: anyone look at daily-di yet?
[11:21] <elmo> lamont: see kamion's response
[11:21] <elmo> lamont: (i.e. he has)
[11:21] <lamont__> good
[11:48] <\sh> grmpf
[11:58] <mdz> Kamion: hmm, yes, I forgot to update changelog when merging Tollef's branch. done now
[11:59] <Kamion> ta
[12:00] <Kamion> heh, current live CD fails at nic-restricted-modules - d'oh
[12:01] <mdz> Kamion: /fixes merged also, pushing now