[12:00] <seb128> k
[12:01] <seb128> what UTC hour is that?
[12:01] <sivang> seb128: probably where piware.de is located :) germany somewhere
[12:01] <seb128> hum, k, I was already on IRC
[12:02] <sivang> seb128: this was created with make distcheck, as jamesh instructed
[12:03] <sivang> seb128: did you see my dead line extension email? (I mailed mdz, cc'd you) What do you think?
[12:04] <seb128> I'm fine with a 2-3 days delay but ask mdz
[12:04] <seb128> I keep patching other apps for the moment
[12:05] <sivang> seb128: ok, that's cool. I'll ping him as well, btw gedit as an example patch is here: http://muse.19inch.net/~sivan/lpint/01_lpint_bonobo_src.patch
[12:06] <seb128> I've read this one already 
[12:06] <seb128> you put it on the wiki no?
[12:06] <sivang> seb128: ah right :) I forgot
[12:06] <seb128> hum, no, that's from IRC probably
[12:06] <seb128> I don't get what you have listed on the wiki
[12:06] <seb128> by example bug-buddy !?
[12:07] <seb128> it has no menu
[12:08] <sivang> seb128: remove it then, sorry, I guess that's are leftovers from my "about" boxes list that was moved here
[12:08] <seb128> I've made a clear list, that's not a copy
[12:08] <seb128> you have listed it ... anyway I'll clear it
[12:08] <sivang> seb128: hmm, then maybe I added it, if I did I'm sorry. I really don't remember..:-/
[12:09] <seb128> and what about all the applets? they don't have a menu neither
[12:09] <seb128> you want to put that to the context menu?
[12:09] <sivang> seb128: context menu being the one opened when you right click an applet?
[12:09] <Burgundavia> mdz, thanks for the inkscape stuff. Sorry to be so nagging
[12:10] <sivang> mdz: ping, did you get my email re lpint due date postpone?
[12:10] <seb128> right
[12:10] <sivang> seb128: then yes, doesn't it feel reasonable?
[12:10] <mdz> sivang: yes, but what is the rationale?
[12:12] <sivang> mdz: bonobo apps which I'd like to have done (+ the listed applets) which without it won't be ready, unless seb128 does it alone and finishes till tommorow :)
[12:12] <seb128> there is not a lot of those, that's doable tomorrow
[12:13] <seb128> if the lib is ready and jamesh push it with lpi sources
[12:13] <sivang> okeydock, I don't mind at all. I just became too much busy at work this couple of days and that prevents me for helping out until next week :-(
[12:14] <sivang> (begining sunday at weekend)
[12:17] <sivang> seb128: actually are you sure you've seen http://muse.19inch.net/~sivan/lpint/01_lpint_bonobo_src.patch ? (it a new patch agains the lpint-bonobo lib)
[12:17] <sivang> seb128: (it's not in the wiki)
[12:17] <seb128> yeah
[12:17] <seb128> you pointed it to jamesh today on this chan
[12:18] <seb128> and I clicked on it
[12:18] <sivang> seb128: ah ok :) just making sure, sorry for repeating myself
[12:18] <seb128> np
[12:19] <seb128> sivang: hum, did you read what I wrote yesterday about using launchpad-integration and not making a new source package?
[12:20] <sivang> seb128: yes, ofcourse
[12:20] <seb128> because your tarball seems to be a new source
[12:20] <sivang> seb128: you mean use the same source for a couple of bin pakcages, make much sense 
[12:20] <seb128> not a patch for lpi
[12:22] <sivang> seb128: I thought that this sources can be included with the src pkg, and create several bin packages. also, why bonobo app need include the GTKUImanager stuff in the original lib? 
[12:22] <sivang> seb128: that way only the relevant part is included in an app , and I use the launching callbacks so no code duplication
[12:23] <sivang> seb128: (i.e. the code that lunches the browser at the right location)
[12:24] <paolo> I don't mean to interrupt, but why isn't libgmp3 a real package?
[12:24] <seb128> paolo: it has been rename to libgmp3c2 for the cpp transition
[12:25] <seb128> sivang: "why bonobo app need include the GTKUImanager stuff in the original lib? " .. what do you mean?
[12:25] <paolo> seb128, what could be done if a package relies on it, and doesn't install because of that?
[12:25] <seb128> rebuild the package for the transition
[12:26] <paolo> Aww, darcs take ages :-)  Thanks anyway.
[12:26] <seb128> that means that the app and the libs are not built with the same gcc version
[12:27] <Kamion> paolo: ping a MOTU and get them to rebuild it
[12:27] <ajmitch> darcs is a special case because of ghc6 issues
[12:28] <joefso> Did any of you guys ever ran ubuntu in UML?
[12:29] <Kamion> ajmitch: ah
[12:29] <mvo> Kamion: how do you feel about a upload of a update-notifier that uses libnotify too? pitti convinced me that it is a good way to get attention to the update
[12:29] <paolo> Kamion, I'll try :-)
[12:30] <seb128> mvo: gnome-applets uses it too now FYI :)
[12:30] <mvo> seb128: it's nice and the notifications certainly draw attention :)
[12:31] <Kamion> mvo: it sounds like an obvious thing for which to use libnotify, I'll admin
[12:31] <Kamion> er, admit
[12:32] <Kamion> discussion the other day indicated that update-notifier's icon often goes unnoticed, so I'd say yes, do it
[12:32] <mvo> Kamion: thanks!
[12:32] <Kamion> er, do we need notification-daemon in main?
[12:32] <sivang> seb128: with the seperation, a Gtk app (glade, UIManager) is using the lib with only the funcs it needs, and a bonobo  apps will use their lib. Acutally jamesh suggested to make it a seperate lib (if I understood him correctly) to be able to seperate between the two from the pkging point of view. Won't it be easier to drop bonobo support that way? (trying to guess that what jamesh had in mind suggesting that)
[12:32] <Kamion> shouldn't it be seeded or something?
[12:33] <paolo> Kamion, they can't because other packages need fixing before :-(  Thanks for the hint anyway.
[12:33] <seb128> sivang: I don't get what you say sorry
[12:33] <seb128> $ ls lib
[12:33] <seb128> callbacks.c  launchpad-integration.h  Makefile  Makefile.am  Makefile.in
[12:33] <seb128> sivang: that's the launchpad-integration source from jamesh
[12:33] <mvo> Kamion: pitti was taking care of it. IIRC he wanted to seed it and make it a recommend from ubuntu-desktop (so that people can remove it if they find it too anoying)
[12:34] <sivang> seb128: maybe you can ping jamesh about it , sorry that I can't explain myself any better..:-/
[12:34] <seb128> sivang: drop here a new callbacks-bonono.c instead of making a new source
[12:34] <seb128> sivang: I'll
[12:34] <sivang> seb128: it can be done, acutally with only modification of the .h file
[12:34] <seb128> sivang: he probably meant to do a liblaunchpad-integration-bonobo.so and a libbonobo-integration-gtk.so
[12:35] <Kamion> mvo: (a) that won't make the installer install it by default, because base-config deliberately runs aptitude --without-recommends; (b) I thought that was part of PackageSelection and deferred
[12:35] <seb128> sivang: but using launchpad-integration current source, not by doing a new one
[12:36] <mvo> Kamion: I don't know, sorry. but if gnome-applets use libnotify now too, it would make sense to have it in main, wouldn't it? 
[12:37] <Kamion> mvo: libnotify's in main, notification-daemon isn't
[12:37] <Kamion> I agree the latter probably should be
[12:37] <sivang> seb128: ok, it has no effect that I used a "new" source, it was just easier for me to work on it that way. my callbacks.c (which uses his callbacks.c) code can be dropped into callbacks-bonono.c. but how do you make to .so(s) and allow an app to use funcs from them with one .h file?
[12:37] <mvo> Kamion: let's discuss it again tomorrow when pitti is around, ok? 
[12:38] <seb128> Kamion, mvo: notification-daemon has been fixed by pitti/approved by main
[12:39] <seb128> it just need to be pulled any way ... maybe with the desktop ?
[12:39] <Kamion> seb128: 23:32 < Kamion> shouldn't it be seeded or something?
[12:40] <seb128> hum, k
[12:40] <Kamion> the notification spec is weird: "The image should never exceed 200x100, but this should be thought of as a maximum size."
[12:40] <Kamion> "Never do X. Furthermore, never do X."
[12:56] <sivang> Kamion: lol 
[01:00] <Kamion> infinity,lamont-away: about? I need a sessreg/amd64 build
[01:05] <sivang> night all
[01:09] <jasoncohen> mvo, hi, i was speaking with pitti earlier about adding a popup notification under the update-notifier icon telling users that there are security or bugfix updates available. Many users don't know that the red update-notifier icon means there are updates available and thus leave their system un-updated for long periods. pitti suggested I speak to you about this since you are the developer of update-manager & update-notif
[01:09] <jasoncohen> ier
[01:10] <mdz> lamont-away: have you made any changes to the livefs build scripts recently?
[01:10] <mdz> lamont-away: I'm getting 403 on /current/
[01:10] <jasoncohen> i was also thinking that the popup should only come up if the update is from hoary-security or hoary-updates. With the introduction of the official backports, it would be a nuisance to tell users to upgrade every time backports upped the version on a package
[01:11] <mvo> jasoncohen: thanks for this suggestion. I added support for libnotify to update-notifier and will upload it now
[01:11] <mdz> infinity: awake?
[01:11] <jasoncohen> mvo, sounds great
[01:12] <mvo> jasoncohen: the currently implemetation takes everything in the sources.list into account (and of course only stuff that is installed). so it will give a message if you have backports enabled and a package installed that could be upgraded. I understand that backports are not enabled by default so this should be ok?
[01:13] <jasoncohen> with cron-apt, one can simply use an alternate sources.list. regular upgrades could use security.sources.list for example and a distribution upgrade (is this going to be in breezy?) can use the full sources.list
[01:13] <jasoncohen> mvo, i'm seeing more and more users in #ubuntu with backports enabled
[01:13] <jasoncohen> fortunately, i haven't seen any problems with packages in the official backports
[01:14] <jasoncohen> i think it would be best to at recognize the high rate of backport usage and give users an option to "show only security and bug fix updates" - perhaps the default option - via an altnerate sources.list
[01:14] <mvo> jasoncohen: the dist-upgrade tool will not make it for breezy (unfortunately)
[01:16] <mvo> jasoncohen: let me check if I can't do some python-apt magic to figure about the available updates without using multiple sources.list
[01:16] <jasoncohen> ok
[01:18] <mdz> anyone else with buildd privileges on terranova?
[01:22] <elmo> eh?
[01:23] <paolo> Kamion, any news from the xorg/boot side?
[01:28] <mvo> jasoncohen: I'm going to bed now, basic libnotify support is in and upload, more may be impossible before the feature freeze
[01:28] <mvo> jasoncohen: thanks for your suggestions, I'm happy to talk to you again about it tomorrow/next days, just ping me
[01:30] <jasoncohen> mvo, will do
[01:31] <mvo> thanks
[01:32] <marcin> Kamion: ping
[01:32] <Kamion> paolo: nothing more I need to do that I'm aware of. the xorg upgrade issue's fixed, the sed unsupported command thing's fixed
[01:32] <Kamion> marcin: pong
[01:33] <paolo> Kamion, I wonder if it's possible to dig further in the "missing binaries issue", tough.
[01:33] <marcin> Kamion: sorry to bother you again but maybe you could tell me something more about maintaining
[01:33] <Kamion> paolo: nothing to dig, it's a known work in progress
[01:34] <marcin> Kamion: could you tell me how do you work on packages? I mean _practically_
[01:34] <marcin> Kamion: have you got single development tree? what tools do yo use?
[01:34] <Kamion> marcin: that's extremely vague and the answer would be very long
[01:34] <paolo> Kamion, OK.  I'm rather new to all this stuff - thank you for the useful information :-)
[01:34] <marcin> Kamion: or maybe you could point me to some kind of tutorial - but not maint-guide
[01:34] <Kamion> marcin: I have a bunch of unpacked source packages organised in whatever way seems appropriate to me; the details are not really interesting
[01:35] <Kamion> some of them are just stored on-disk as source packages, some are stored in one of various revision control systems
[01:35] <marcin> Kamion: so you work on these packages 'manually' and you don't have something like a well organized 'factory' ?
[01:36] <Kamion> eh?
[01:36] <marcin> Kamion: for example scripts that could build new packages automagically
[01:36] <Kamion> I use debuild to build source packages
[01:36] <marcin> Kamion: for example you got a kind of template and some scripts - you define url to source
[01:37] <Kamion> no, that would be pointless because the installer is far too varied for that, and that's what I spend most of my time on
[01:37] <Kamion> I spend most of my time hacking code, not packaging stuff
[01:37] <marcin> Kamion: and it could fetch and unpack and create development tree just with single command
[01:37] <Kamion> I've never felt the need for that, I'm afraid
[01:38] <marcin> Kamion: ok
[01:38] <marcin> Kamion: and you don't know if there is something that could work like I just described?
[01:38] <Kamion> if I need to create a new package, either I find the last roughly-similar one I did and borrow off it, or I just write it by hand - I've been a Debian developer for about four and a half years so it's kind of second nature
[01:39] <Kamion> there's dh_make, and people have written various things like that for specialised purposes
[01:39] <marcin> Kamion: mhmm
[01:39] <Kamion> it's a bit limited
[01:40] <marcin> Kamion: well then propably I'll develop 'yet another thing for specialized...'
[01:41] <Kamion> but in practice, I spend most of my time either (a) dealing with incoming bugs, thinking about why they're happening, debugging, and writing fixes, (b) writing code to implement new features, (c) testing CD images and netboot installs
[01:41] <Kamion> I don't spend very much time building development trees, so there's no need to optimise that process
[01:41] <Kamion> I usually find that the maintainers of the devscripts package do it for me if I leave them alone long enough ;-)
[01:42] <Kamion> (debcommit rocks my world)
[01:43] <marcin> Kamion: ok I understand
[01:43] <Kamion> and, I think if I *did* spend enormous amounts of time building factories for churning out packages, I'd be inclined to try to rearrange things so that there wasn't a need for so many packages
[01:43] <Kamion> but it would depend on the situation
[01:44] <Kamion> paolo: it's all daniels' baby, anyway; see http://wiki.ubuntu.com/XRoadmap
[01:44] <Kamion> (of course the dates on that roadmap ran out a couple of months ago)
[01:48] <marcin> Kamion: ok, thanks for help
[01:48] <marcin> Kamion: I hope that I'll be able to upload something soon
[01:48] <marcin> Kamion: so, back to work
[01:58] <paolo> OK, goodnight folks :-)
[02:38] <martinhj> the last breezy kernel upgrade left my machine unbootable.. could not detect my lvm partition on my hd.. what are the big differences?
[02:39] <martinhj> I ended up in a busybox shell
[02:43] <martinhj> the question is not for support, only want to find out if you know my problem - if I should file a bug or not
[02:43] <jasoncohen> who deleted breezy goals?
[02:43] <jasoncohen> https://wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
[02:43] <jasoncohen> it says the page no longer exists
[02:44] <sklp> https://wiki.ubuntu.com/BreezyGoals
[02:44] <sklp> is the new URL
[02:44] <jasoncohen> thanks sklp 
[02:48] <jasoncohen> will https://wiki.ubuntu.com/PackageDependencyManagement get done for breezy? specifically, will apt & synaptic remove the dependencies of a package you want to remove that were installed merely to satisfy dependencies
[02:49] <bob2> apt-get shouldn't care
[02:50] <bob2> aptitude already does
[02:50] <jasoncohen> i know aptitude does but why shouldn't apt-get support that feature as well?
[02:50] <jasoncohen> synaptic certainly should
[02:51] <bob2> afaik, apt-get was originally a test app for libapt
[02:51] <jasoncohen> "The apt package needs to be improved to provide support for the marking of automatic dependencies. This feature needs to be exported so that frontends like synaptic can make use of it too."
[03:11] <bob2> yay for suspend to disk not working
[03:11] <bob2> because firefox and X are consuming more ram than I have swap
[03:11] <lifeless> rotfl
[03:59] <Kamion> jasoncohen: we are *one day* from feature freeze; at this point you can probably expect that most features that haven't been making progress will slip
[04:00] <Kamion> jasoncohen: of the auto-mark work, mdz said in the last goals meeting that he didn't think it had had enough testing to slam into breezy at this late state
[04:00] <Kamion> s/state/stage/
[04:06] <jasoncohen> Kamion, darn, thangs for the update
[04:07] <jasoncohen> Kamion, when will we have a better idea what is going to be getting into breezy?
[04:07] <whiprush> check the status page, it's pretty much up to date
[04:08] <Burgundavia> jasoncohen, the decisions on deferring stuff is going to happen quite soon
[04:08] <Burgundavia> jasoncohen, at which point the BreezyGoals page will be updated
[04:08] <jasoncohen> how much time will high priority goals get past the feature freeze to complete their work?
[04:12] <Kamion> depends on their potential for breakage
[04:12] <Kamion> and user interface impact
[04:13] <Burgundavia> jasoncohen, the UI freeze is aug 25th
[04:13] <Kamion> the doc team need time to complete their work, which involves documenting the user interface, so they need something stable to work from
[04:13] <Burgundavia> if the developers break that, the doc team will hunt them down and kill them slowly
[04:13] <Kamion> I hope nobody's going to document oem-config at all really, otherwise I'm dead then. :)
[04:13] <ajmitch> Burgundavia: only for main, I assume?
[04:14] <Lathiat> heh
[04:14] <Kamion> (since its UI isn't finished, and I'm about to go on holiday for two weeks)
[04:14] <Burgundavia> ajmitch, UI is defautl desktop stuff
[04:14] <ajmitch> Burgundavia: ok, great :)
[04:14] <Burgundavia> ajmitch, we need time to get screenshots made
[04:14] <ajmitch> it'd be a nightmare trying to document universe as well
[04:14] <ajmitch> yes, I know
[04:14] <ajmitch> which is why there can't be a last minute theme change this time
[04:15] <Lathiat> heh
[04:15] <Kamion> (the developers didn't want that last time either)
[04:45] <mgalvin> ajmitch: ping
[04:48] <ajmitch> mgalvin: yes?
[04:50] <mgalvin> ajmitch: i committed those doc package updates, there is an email on the doc list about it as well, just so you know its there, any pointers are more than welcome
[04:50] <ajmitch> ok, it's in docteam svn?
[04:50] <mgalvin> yup
[04:51] <mgalvin> i modeled it after kubuntu-docs which already has weekly builds going into kubuntu main
[04:51] <jsgotangco> ubuntu-doc/gnome/debian?
[04:51] <mgalvin> yup
[04:52] <ajmitch> ok, checking out of svn
[04:52] <mgalvin> cool, thanks for taking a look at it
[04:52] <ajmitch> might take awhile :)
[04:52] <mgalvin> sure, np, i am off to bed now away, no rush
[04:53] <ajmitch> ok
[04:54] <mgalvin> if i'm not around just drop me a line on the doc list about it
[04:54] <mgalvin> thanks again :), g'night
[05:13] <nomed^> hi all .. does a dpkg recovery tools already exist? a script that can recreate a dpkg status file ..
[05:14] <bob2> "backups"
[05:14] <bob2> or a little shell script using /usr/share/doc/
[05:14] <Kamion> there are some automatic backups of status in /var/lib/dpkg/ and /var/backups/
[05:14] <Kamion> but status is a primary file, it's not in general generated from information available elsewhere
[05:15] <Kamion> it's the main dpkg working database
[05:24] <nomed^> i needed this info because i was just doing some experiments with unionfs and an ubuntu based live cd
[05:27] <nomed^> my idea was to use different layers ... and unify them .. add a new kernel or new packages would be really easy in this way .. but the status file is a big problem ..
[05:27] <nomed^> thanks anyway
[05:32] <Kamion> jbailey: wow, adding initramfs-tools to minimal adds like a megabyte to the debootstrapped set
[05:32] <Kamion> what with busybox, klibc-utils, lvm2, mdadm
[05:32] <jbailey> Kamion: Hmm.
[05:33] <jbailey> Kamion: That dependancy could be weakened by moving the initarmfs install script to those various packages.
[05:33] <jbailey> We just need to make sure then that a system  using md or lvm has the right packages installed.
[05:34] <jbailey> Kamion: Is it going to cause you grief in the meantime?
[05:35] <Kamion> oh, no, I was just noting the size increase
[05:35] <Burgundavia> Kamion, what is the status of the windows stuff on the live cd?
[05:35] <Kamion> base-installer actually already ensures to install mdadm and lvm2 before installing the kernel, I think because initrd-tools needed that
[05:36] <Kamion> Burgundavia: no idea, I just copy it
[05:36] <Kamion> I have no Windows systems on which I could look at it even if I wanted to
[05:36] <Burgundavia> Kamion, is there going to be enough space for the breezy release?
[05:36] <Kamion> Burgundavia: it may be reduced, depending on size constraints; we want to keep at least some of it there
[05:36] <Burgundavia> ok
[05:37] <Burgundavia> I am asking for our QuickTour marketing doc, that is all
[05:38] <jbailey> Kamion: Ah, that makes sense.  Part of it is also that an older lvm2 results in a non-bootable system with 2.6.12
[05:39] <jbailey> Kamion: I really want to see us work towards eliminating the option of doing your own kernel so that we can do proper dependancies with kernel packages and make promises based on it.
[05:39] <ajmitch> yes, it showed up all sorts of fun :)
[05:39] <Kamion> jbailey: is binutils-static really meant to depend on binutils?
[05:39] <jbailey> Kamion: But I'm expecting this to be an uphill battle.  Something to bribe people over at the Fall Canonical conference.
[05:40] <ajmitch> jbailey: users are always going to want to roll their own
[05:40] <Kamion> jbailey: elmo will murder you in your sleep
[05:40] <Kamion> (for no-homebrew-kernels)
[05:40] <jbailey> ajmitch: Yes, thanks for the testing last night.
[05:40] <ajmitch> no problem..
[05:40] <jbailey> Right, but the question is always *why* are users rolling their own?
[05:40] <jbailey> And can we eliminate the need for it.
[05:41] <ajmitch> at best, you could document what users need to have for things to work
[05:41] <ajmitch> because they're users, and they heard from a friend-of-a-friend..
[05:41] <Burgundavia> jbailey, why not ask on the forums and lists?
[05:41] <Kamion> the problem is that dependencies on kernel packages don't work even if nobody rolls their own kernels
[05:41] <jbailey> Watching #ubuntu, rolling your own kernel seems to be more of a "I heard that you need to do this on Linux" than people actually meeting a need.
[05:41] <ajmitch> sometimes people do it just to see what it's like
[05:41] <Kamion> because generally you want to express a dependency on the running kernel, not on whatever kernels dpkg happens to think are installed
[05:42] <jbailey> Burgundavia: Because I prefer to get flamed by friends before I go out and get flamed by strangers.  It's my style. =)
[05:42] <Burgundavia> jbailey, ok
[05:42] <Burgundavia> jbailey, I meant ask people about why they rolled their own kernels
[05:42] <jbailey> Kamion: re: binutils-static only provides ld_static at the moment.
[05:42] <Kamion> jbailey: (jessica wants to promote binutils to the debootstrapped set at the moment, which seems like crack)
[05:43] <Kamion> jbailey: yes, but that's all we need in base, surely
[05:43] <jbailey> Oh feh.
[05:43] <Kamion> hooray, InstallerStage2Progress works perfectly on today's CDs
[05:43] <jbailey> Next time someone sees our friendly dpkg maintainer can they poke him with a stick until he gives us the "Doesn't really depend on, but if it's installed, it needs to meet these constraints" header? =)
[05:44] <Burgundavia> jbailey, Kamion would it be useful for me to ask on the forums about why people roll their own?
[05:44] <Kamion> Conflicts: binutils (<< ${Source-Version}), binutils (>> ${Source-Version}) if you really must, but won't that make upgrades horrifically complicated?
[05:45] <jbailey> Kamion: Assuming I didn't do some crack with a symlink and /usr/share/doc/binutils-static, it's not a critical thing.  Just a way of keeping irreproducable bugs from showing up.
[05:45] <ajmitch> that does look a bit evil
[05:45] <Kamion> Burgundavia: I don't think so; we have enough experience within the team of that
[05:45] <Burgundavia> Kamion, ok
[05:45] <Kamion> jbailey: oh, if you aren't depending on binutils, you'll have to ship copyright and changelog in /usr/share/doc/binutils-static/ anyway
[05:45] <Kamion> so just drop the symlink?
[05:45] <jbailey> Burgundavia: Not yet.  I want to work out the idea of "If noone rolled their own, how would this work" before eliminating the need for peopel to roll their own.
[05:46] <Burgundavia> ok
[05:46] <jbailey> Kamion: Yup
[05:46] <Kamion> ah, I just reread your sentence and it makes more sense now
[05:46] <jbailey> Sorry, I'm a bit tired.
[06:44] <doko> good morning
[06:47] <ajmitch> hi doko 
[06:52] <doko> hi ajmitch 
[06:53] <doko> Mithrandir: the OOo2 bootstrap succeeded, please test the sunjavaplugin.so in my home on chinstrap
[07:17] <zwnj> i run "gucharmap --version". cvs gives me 1.4.2 but ubuntu's one gives 1.4.3.  what's the matter?
[07:27] <Mithrandir> doko: cool, I'll do that just after breakfast.
[07:33] <Lathiat> i wonder how freenode detectors TOR
[07:34] <bob2> there's only so many exit nodes
[07:35] <Lathiat> ah i thought it was like a p2p thing
[07:35] <bob2> no
[07:38] <Lathiat> ah, interesting
[08:08] <Lathiat> hrm nautilus still has (null) for trash
[08:09] <pef> hello
[08:32] <Mithrandir> elmo: one of the members of the archive.ubuntu.com (.151) is giving ECONNREFUSED on port 80.
[08:40] <tepsipakki> who should I bug about lrm-manager?
[08:40] <tepsipakki> it doesn't find ld, because PATH is not set
[08:41] <pitti> Good morning!
[08:41] <ajmitch> morning pitti 
[08:44] <ogra> pitti !
[08:45] <ajmitch> hi ogra :)
[08:45] <ogra> pitti, we have a small problem....
[08:46] <ajmitch> bbl..
[08:47] <ogra> pitti, obviously there is a new open CAN for nvu... according to Burgundavia there is also a new upstream version and our current one is ftbfs because of XPrint bindings....
[08:48] <ogra> so i think you can kip this one until we decided if we want the new upstream version... 
[08:48] <ogra> s/kip/skip
[08:48] <pitti> it's certainly justified in this case...
[08:48] <Burgundavia> pitti, the new upstream is merely the stable
[08:49] <Burgundavia> pitti, the current version is a half-asses unstable versin
[08:50] <pitti> I'm not opposed, you have to convince mdz or Kamion :-)
[08:50] <ogra> Burgundavia, whats wtong with "web development editor" in the tooltip ?
[08:50] <ogra> wrong even
[08:50] <ogra> :)
[08:50] <Burgundavia> ogra, nothing, but the name needs to say something only that nvu, because very few hyperactive kids are going to stick around long enough for a tooltip
[08:51] <Burgundavia> especially if we want to crack the Ritalin-addicted US market
[08:52] <ogra> the bug says: The current tooltip is not Higgy.
[08:52] <ogra> thats somewhat confusing :)
[08:52] <Burgundavia> oh, the tooltip needs to be a verb
[08:52] <Burgundavia> sorry, I forgot about that
[08:52] <Burgundavia> Edit webpages or something similar
[08:58] <ogra> Burgundavia, there is no indication you mean the text of the menu entry, it only talks about the tooltip... thats what i maent with confusing..
[08:58] <Burgundavia> ogra, ok, the tooltip and the menu item need to change
[08:59] <Burgundavia> ogra, made it more clear
[09:15] <Mithrandir> oh joy, strace segfaults.
[09:15] <Lathiat> haha
[09:16] <Mithrandir> (with -c)
[09:16] <Mithrandir> (when stracing 32 bit programs on amd64)
[09:35] <infinity> Kamion : amd64 sessreg and partman-base builds rescued for you.
[09:36] <seb128> daniels: around?
[09:36] <jdub> morning seb128 
[09:37] <seb128> hey hey jdub
[09:37] <jdub> seberino, full of healthy seb goodness!
[09:37] <seb128> ;)
[09:38] <jdub> dude
[09:38] <jdub> you are famous
[09:38] <jdub> i met an ubuntu user today who said he used sebuild
[09:38] <jdub> i am pleased to see that meme working its way around the world :)
[09:38] <seb128> ah ah
[09:40] <Treenaks> whoa.. the French even _laugh_ in reverse? :P
[09:41] <seb128> doing thing the same way has everybody else would be boring :p
[09:41] <Treenaks> seb128: that's a way of explaining it :)
[09:42] <seb128> s/has/as/
[09:42] <seb128> daniels, pitti: any reason to not ship /usr/bin/dbus-binding-tool and /usr/bin/dbus-viewer with dbus-utils?
[09:42] <tepsipakki> is the current nvidia-glx known to be broken? it tries to run my flat-panel on 75Hz while it should use 60
[09:43] <tepsipakki> worked on hoary
[09:43] <pitti> seb128: I don't know these tools, but they can certainly be shipped if you need then
[09:43] <pitti> them, even
[09:43] <seb128> pitti: totem wants the first one
[09:44] <pitti> seb128: uh, totem uses dbus now?
[09:46] <seb128> pitti: every cool kids use dbus nowadays
[09:46] <pitti> :-P
[09:46] <seb128> "          Use DBus for plugin<->helper communication, with nice function
[09:46] <seb128>           interfaces so it's all easy (no more totemMozillaObject::wait()),"
[09:46] <pitti> right, get rid of these damn cars, use the bus!
[09:47] <seb128> yeah, that's good for the planet :)
[09:48] <pitti> yay, security bug in evolution *sigh
[09:49] <daniels> seb128: sure, I'll fix that
[09:49] <seb128> pitti: oh, I'm doing a gaim sync with Debian, cf the changelog for security fixes
[09:49] <pitti> seb128: 1.5.0? thanks, I know the advisory
[09:49] <seb128> daniels: hey. I've uploaded a version with the .la for the lib, it was breaking GNOME again ...
[09:49] <daniels> seb?!?
[09:49] <daniels> insert a tab in there wher eappropriate
[09:49] <seb128> pitti: not yet, but they have patched 1.4.0
[09:50] <pitti> cool
[09:50] <daniels> how many libs was it in? i grepped over /usr/lib and didn't find one .la with it in
[09:50] <seb128> daniels: and a bunch of other .la mention libdbus.la which break everything using hal
[09:50] <seb128> daniels: libhal by example
[09:50] <seb128> which is already a good candidate for b0rkages
[09:50] <daniels> seb128: we could fix those ...
[09:50] <seb128> daniels: and mdz agreed the -dev should ship the .la
[09:51] <daniels> i'm trying not to ship *any* .la's
[09:51] <seb128> daniels: I agree with that, we should not ship any, but we should make it a policy
[09:52] <seb128> there is not point to change a few random package and breaking builds every time
Policy comes from common practice, not vice verse</parrot>
[09:52] <Mithrandir> infinity: nono, that is in debian.  We're ubuntu. :-P
[09:52] <seb128> daniels: 
[09:52] <seb128> $ grep dbus-1.la /usr/lib/*.la | sed 's/:.*//'
[09:52] <seb128> /usr/lib/libhal.la
[09:52] <seb128> /usr/lib/libhal-storage.la
[09:52] <seb128> /usr/lib/libnautilus-burn.la
[09:52] <seb128> 
[09:53] <seb128> daniels: I'm fine to rebuild both with the new dbus if that's the correct fix, but you were not arround and mdz said the -dev should ship the .la
[09:53] <seb128> daniels: drop them while doing the upload for /usr/bin/dbus-binding-tool and /usr/bin/dbus-viewer if you want, we rebuild hal and n-c-b then and we are fine
[09:54] <seb128> daniels: I was just trying to get GNOME building, if we want a colony CD this week ... :)
[09:56] <pitti> Hi mvo
[09:56] <seb128> hey mvo
[09:56] <mvo> hey pitti, seb128 !
[09:59] <seb128> infinity: could you kick rhythmbox build? It broke due to dbus .la drop yesterday and should build with current version
[10:00] <pitti> mvo: n-d is ftbfs, your patch doesn't apply...
[10:02] <infinity> seb128 : punted.
[10:02] <seb128> thanks
[10:06] <seb128> pitti: should I mention the CAN again with the Ubuntu changelog, or the previous entry from Debian is fine?
[10:06] <seb128> pitti: http://packages.qa.debian.org/g/gaim/news/1.html
[10:06] <pitti> seb128: if the CAN appears anywhere, that's fine
[10:06] <seb128> cool
[10:06] <pitti> thanks
[10:06] <seb128> np
[10:06] <pitti> cool,  so the patches are already split out
[10:07] <pitti> I was afraid that I had to pull them from cvs agaihn
[10:08] <seb128> :)
[10:09] <daniels> seb128: ok.  when are you around tonight/tomorrow?  i'll do the upload while we're both here so we can keep the disruption as small as possible.
[10:10] <seb128> I'm around for like ~12 hours from now
[10:10] <seb128> daniels: but I can do the upload now with the 2 binaries to dbus-utils and without the .la and then rebuild hal and n-c-b
[10:11] <seb128> so I can upload totem
[10:11] <seb128> as you want
[10:11] <daniels> seb128: want me to sort it?
[10:11] <seb128> that's a trivial change ... if you agree than the 2 binaries go to dbus-utils I can do it 
[10:11] <daniels> ok, sure
[10:12] <seb128> will do so, thanks
[10:12] <daniels> thank you :)
[10:13] <seb128> np ;)
[10:13] <Mithrandir> Riddell: I'm about to give up on getting kde to understand that it should look in /usr/lib32/kde3 for styles and such, you might want to pick it up.
[10:14] <daniels> seb128: anything else you need?  i'm going to do another xorg upload tonight
[10:14] <daniels> seb128: (if all goes to plan)
[10:14] <seb128> daniels: fix Xnest? :)
[10:15] <seb128> $ Xnest :1
[10:15] <seb128> Could not init font path element /usr/share/X11/fonts, removing from list!
[10:15] <seb128> Fatal server error:
[10:15] <seb128> could not open default font 'fixed';
[10:15] <seb128> 
[10:15] <seb128> do you know what is the issue here?
[10:16] <daniels> oh man I am so shit
[10:16] <daniels> yes
[10:16] <seb128> would be nice to fix that so sabayon can work ... :)
[10:17] <daniels> yeah, that's a one-liner
[10:17] <mdke> what is elmo's email addy?
[10:17] <daniels> mdke: james.troup@
[10:18] <daniels> seb128: unfortunately you need to *grow* the element, so you can't just edit the binary and pad the table with NULs
[10:18] <mdke> daniels, thanks
[10:18] <seb128> daniels: I can wait for next xorg upload, no hurry ... I local hack would not make a big difference, I want to upload a working version anyway :)
[10:32] <daniels> seb128: ln -s /usr/share/X11/fonts/misc /tmp/fonts, change /usr/share/X11/fonts in Xnest to /tmp/fonts, and pad it with NULs
[10:34] <seb128> k, thanks
[10:35] <seb128> infinity, lamont-away: do you know what's going on with evolution 2.2.1.1-0ubuntu4.1 build? That's a upload made some time ago for hoary-updates
[10:36] <infinity> ?
[10:36] <infinity> I see no evolution in hoary-updates at all.
[10:36] <infinity> Was it actually ACCEPTed?
[10:36] <seb128> no clue
[10:37] <seb128> "  to pool/main/e/evolution/evolution_2.2.1.1-0ubuntu4.1.dsc
[10:37] <seb128> Announcing to hoary-changes@lists.ubuntu.com"
[10:37] <seb128> yeah, I've an ACCEPTED mail
[10:38] <pitti> infinity: it's still in the accpeted queue, but without debs
[10:38] <infinity> Interesting.
[10:38] <seb128> jul 19
[10:38] <infinity> I see -0ubuntu4 in hoary, and nothing registered for hoary-updates or hoary-security.
[10:39] <seb128> has anybody used hoary-updates out of this upload? :)
[10:40] <infinity> Looks like a whopping 3 packages have successfully passed through hoary-updates.
[10:40] <seb128> k
[10:40] <infinity> xine-lib, kdenetwork, knetworkconf
[10:40] <seb128> so why does it hate me? :p
[10:40] <infinity> Not sure, but I'd whine to elmo.
[10:41] <infinity> If cron.daily isn't exporting the current state of the queues/archive to wanna-build, I can't do anything about it.
[10:41] <pitti> infinity: the source pkg is in accepted, but it didn't build
[10:41] <infinity> pitti : Yes, see above.
[10:41] <pitti> k
[10:41] <infinity> pitti : From my POV, the source package doesn't exist.
[10:41] <doko> ohh, is this the same case for dbus?
[10:41] <infinity> doko : There's a dbus in limbo in hoary-updates too?
[10:41] <infinity> If so, then yes.
[10:42] <infinity> Like I said, those three packages above are the only three registered in wanna-build at all (all in state:Installed)
[10:42] <chmj> pitti: ping
[10:42] <infinity> Anything else uploaded doesn't seem to exist.
[10:43] <infinity> elmo : Dude, cron.daily doesn't seem to be syncing the state of the hoary-updates archive with wanna-build.  There are complaints of ACCEPTED source packages that have never made it to w-b.
[10:43] <infinity> There, that's about all I can do about it. :/
[10:44] <infinity> (Well, if the source is actually sitting in the archive, I can force builds, but fixing the real problem is best..)
[10:45] <janimo> daniels, do you know of existing issues with libvgahw and screen blackout or should I file another bug on the subject (trident card on laptop)
[10:47] <daniels> janimo: it should be fixed via a gcc patch in -44 and above.  if not, file a bug on gcc because the fix was incomplete.
[10:48] <_d4v_d> play Aggro Berlin - Schlampen (Bushido, Sido & B-Tight).mp3
[11:12] <Mithrandir> Kamion: can you send me whatever code you have for MountingHDDFilesystems (or point me in the right direction at least)
[11:13] <Lathiat> hrm
[11:14] <Lathiat> apt doesnt fall back if a host has more than 1 ip
[11:14] <Lathiat> e.g. archive.ubuntu.com has connection refused on 1 ip but not the other
[11:14] <Lathiat> (and someone might wanna look at that)
[11:15] <Mithrandir> Lathiat: I've already told elmo here, might want to drop him a mail as well
[11:15] <Lathiat> Mithrandir: ok
[11:15] <Treenaks> that, and apt should be fixed :)
[11:15] <infinity> Both IPs work for me.
[11:16] <infinity> As for apt, it just does what the resolver tells it to do.
[11:16] <infinity> And the resolver will just pick a random IP from round-robin DNS.
[11:16] <Lathiat> ok i lied
[11:16] <Lathiat> *debmirror* doesnt fall back
[11:16] <infinity> apt doesn't know or care that there are multiple IPs.
[11:16] <ajmitch> the resolver can return a list of IPs, iirc
[11:16] <Lathiat> infinity: well getaddrinfo will return a list of all ips
[11:16] <Lathiat> and you can cycle through them
[11:16] <Lathiat> (if 1 fails)
[11:16] <Lathiat> like e.g., talnet
[11:17] <Lathiat> err, telnet
[11:17] <Lathiat> anyway i think its debmirror not apt, i wasnt thinking
[11:17] <Lathiat> apt seemed to update ok
[11:17] <Lathiat> also
[11:17] <Lathiat> it just
[11:17] <Lathiat>  fixed itself
[11:20] <Lathiat> hrm some maintence might be being done
[11:20] <Lathiat> cus the other one just went over now
[11:23] <janimo> mvo, will notification be usable for something like disk full warning?
[11:23] <seb128> jamesh: around?
[11:24] <mvo> janimo: yes, but there will need for a daemon that actually monitors for disk-full
[11:25] <infinity> A cronjob would probably be good enough.
[11:25] <infinity> OTOH, notification seems a bit goofy.
[11:25] <infinity> I keep getting wanred to reboot cause I installed a new kernel... Afetr I've rebooted (and not before)
[11:26] <infinity> Yay.
[11:26] <mvo> infinity: good point, there is this nice notify-send command
[11:26] <mvo> infinity: that sounds like a bug to me :)
[11:26] <infinity> Yeah, I think it may be "development release specific", though, so I haven't bothered to look into it.
[11:27] <pitti> mvo: beware that notify-send currently hangs on powerpc, I'm sorting this out wit upstream
[11:27] <infinity> (ie: it may have to do with update-notifier or gnome-panel being updated in the same apt run as the kernel, and so the applet doesn't fire until I log out and back in)
[11:27] <mvo> right
[11:27] <infinity> And in a stable release, the odds of yuu updating the panel stuff and the kenrel in the same go are slim.
[11:28] <infinity> pitti, mvo : Is there a way to set a "clear on reboot" flag on a notifier message?
[11:28] <infinity> It doesn't make sense to be told about a kernel upgrade after you've rebooted, for instance.
[11:28] <pitti> infinity: no, the current kernel notification is broken anyway in several ways
[11:29] <Lathiat> yeh thats annoyed me a few times
[11:32] <pitti> infinity, mvo: I think the notification should not be shipped with l-i, but created in the postinst, and some init script should remove it
[11:32] <mvo> that would be the easiest solution
[11:39] <infinity> Well, this notify-send you speak of may be the ticket there.
[11:39] <infinity> Assuming stuff sent by notify-send disappears into oblivion on reboot.
[11:42] <pitti> infinity: it does
[11:42] <pitti> infinity: the only problem is, package installation can' trigger it
[11:42] <pitti> infinity: since this is entirely user-session stuff
[11:43] <infinity> Hrm?
[11:43] <infinity> notify-send only works on a user-by-user basis, you can't send a "system notice"?
[11:43] <infinity> Then it wouldn't work for a diskspace cronjob either.
[11:43] <pitti> right
[11:43] <pitti> it's intended to be a desktop tool
[11:43] <pitti> and it listens to the session dbus
[11:44] <mdke> does anyone know if there are any bugs filed about the installer breaking laptop rescue partitions? I did a quick search and couldn't find any
[11:44] <infinity> So, what's the "correct" way to just "send a notice to any currently logged in session", or similar?
[11:44] <pitti> update-notifier, I think
[11:44] <infinity> mdke : Define "breaking".
[11:44] <pvanhoof> breezy problem
[11:44] <pvanhoof> The following packages have been kept back:
[11:44] <pvanhoof>   x-window-system-core
[11:44] <mdke> infinity, for any definition of it
[11:45] <pvanhoof> can it be fixed?
[11:45] <infinity> mdke : Is parted eating your partition table, or is the partition being wiped out, or it it being unhidden/renumbered, ec?
[11:45] <pvanhoof> startx does work :)
[11:45] <mdke> infinity, in my case, i can't access it via the hotkey from bios, and if I start it from the grub entry that was added, i get a BSOD
[11:45] <pvanhoof> but I'd prefer the package system to be correct
[11:45] <infinity> pvanhoof : Try a dist-upgrade.
[11:45] <pvanhoof> infinity, yeah I used that
[11:45] <infinity> pvanhoof : If that doesn't work, try "apt-get install x-window-system-core" on its own, and see why it's refusing to install it.
[11:46] <pvanhoof> -window-system-core: Depends: libgl1-xorg-dri but it is not going to be installed
[11:46] <pvanhoof>                         Depends: libgl1-xorg but it is not going to be installed
[11:46] <pvanhoof> hmm strange
[11:46] <mdke> infinity, so you know of bugs filed on that subject?
[11:47] <pvanhoof> it needs to remove some -dev packages, to get libgl1-xorg installed
[11:47] <infinity> mdke : Hrm.  Rescue partitions are usually marked "hidden", and as such shouldn't end up being auto-added to GRUB, or touched in any way.
[11:48] <seb128> jbailey: ping?
[11:48] <infinity> pvanhoof : Which packages?
[11:48] <Mithrandir> is there an easier way to test changes to the live cd than making a new one and burning a new disc?
[11:48] <infinity> pvanhoof : That would most certainly point at a bug in those.
[11:48] <pvanhoof> like .. libbonoboui2-dev libcairo1-dev libdbus-qt-1-dev libdevhelp-1-dev libeel2-dev libgail-dev libgail-gnome-dev libgal2.4-dev libgimp2.0-dev libglade2-de
[11:48] <pvanhoof> there's more
[11:49] <mdke> infinity, not this one I guess. It was added to grub as Windows 2000 and I can no longer access it by pressing the "Access IBM" button at the startup screen
[11:49] <infinity> pvanhoof : That doesn't seem right at all.
[11:50] <Mithrandir> mdke: that's because the MBR is overwritten.
[11:50] <daniels> uhm
[11:50] <infinity> mdke : Hrm.  If I hadn't wiped out the recovery partition on my Thinkpad, i could test this.
[11:50] <daniels> works for me?
[11:50] <Mithrandir> at least, afaik.
[11:50] <pvanhoof> infinity, idd, I'm going to leave it like that :)
[11:50] <pvanhoof> since I do need a development platform
[11:50] <infinity> mdke : But it sounds like you, at some point, turned on the BIOS option to "allow recovery partitoin to be used/recovered by the OS"
[11:51] <pitti> elmo: can I please have the evolution build-deps in concordia's warty and hoary dchroots?
[11:51] <pvanhoof> infinity, I think xlibmesa-dri is causing the problems
[11:51] <infinity> pvanhoof : Uhm, that's been removed from the archive.
[11:52] <pvanhoof> but I removed them (the devel packages) and am now reinstalling them. And suddenly the packaging system is cool about installing x-window-system-core
[11:52] <infinity> pvanhoof : Try 'apt-get --purge install libgl1-xorg-dri'
[11:52] <pvanhoof> ah but it's going to install it
[11:52] <pvanhoof> without any special rules
[11:53] <pvanhoof> I had a lot of warnings like this
[11:53] <pvanhoof> libgle3 depends on xlibmesa3-gl | libgl1; however:
[11:53] <pvanhoof>   Package xlibmesa3-gl is not installed.
[11:53] <pvanhoof>   Package libgl1 is not installed.
[11:53] <pvanhoof>   Package xlibmesa-gl which provides libgl1 is to be removed.
[11:53] <mdke> infinity, i received the laptop yesterday and haven't touched the BIOS
[11:53] <infinity> That's fine.
[11:54] <pvanhoof> dpkg: xlibmesa-gl: dependency problems, but removing anyway as you request:
[11:54] <infinity> mdke : Ahh, then it could be Mithrandir's guess about the MBR, though I don't recall "Access IBM" using thr MBR.
[11:54] <mdke> ok i'll report a separate bug and debug it with whoever is assigned to it
[11:54] <infinity> pvanhoof : Those warnings are fine.  It's just apt forcing dpkg to do things in one run that it would rather do in several.
[11:55] <pvanhoof> aha ok
[11:55] <mdke> thanks infinity, Mithrandir 
[11:55] <pvanhoof> almost downloaded all packages :). so installed will proceed in a few seconds
[11:55] <pvanhoof> s/installed/installing
[11:56] <Mithrandir> hmm, this shouldn't work:
[11:56] <Mithrandir> db_input casper-udeb/snapshot/cow-device || true
[11:56] <Mithrandir> I wonder why it does.
[11:56] <Mithrandir> or, it probably doesn't
[11:56] <pvanhoof> here we go
[11:57] <pvanhoof> no significant problems ... testing x11
[11:57] <pvanhoof> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[11:57] <pvanhoof> startx -- :2 worked
[11:58] <pvanhoof> going to reboot in a few minutes to test the new kernel. Has there been issues reported by somebody about the kernel?
[11:58] <pvanhoof> or is it safe to reboot?
[11:58] <pvanhoof> :p
[11:58] <pvanhoof> -- oh I like that question --
[11:58] <daniels> xlibmesa3-gl??
[11:58] <pvanhoof> daniels, yes, it's removal was a bit problematic
[11:59] <pvanhoof> it blocked the update of libgl1-xorg-dri .. and it forced me to remove +- 15 -dev packages first
[11:59] <daniels> is that an upgrade from debian?
[11:59] <pvanhoof> no well, hoary to breezy (5 weeks ago) and now a new upgrade
[11:59] <daniels> bong ... someone must've hardcoded xlibmesa3-gl.
[11:59] <pvanhoof> I managed to fix the fact that mkfontdir was missing a few weeks ago
[11:59] <daniels> in any case, that's apt's fault
[11:59] <daniels> mdz: is there anything we can do with apt to make upgrades like pvanhoof's above actually work?
[12:02] <infinity> pvanhoof : Kay, that's hilighted a bug or two in breezy that we'll poke at.  So, your upgrade problems aren't all for nothing. :)
[12:03] <pvanhoof> ok :)
[12:03] <pvanhoof> that is one of my reasons for running breezy
[12:03] <pvanhoof> so, great
[12:04] <pvanhoof> installing gnome-devel (it looks like some packages from that collection have been removed)
[12:11] <pvanhoof> libgnomemm2.0-dev: Depends: libgnomemm2.0-1c2 (= 2.0.1-2ubuntu3) but it is not going to be installed
[12:12] <Amaranth> why isn't it going to be installed?
[12:12] <pvanhoof> sec
[12:13] <pvanhoof> libgnomemm2.0-1c2: Depends: libgtkmm2.0-1 but it is not installable
[12:13] <pvanhoof>   libgtkmm2.0-1c2
[12:13] <pvanhoof> E: Package libgtkmm2.0-1 has no installation candidate
[12:13] <pvanhoof> so, a missing package
[12:13] <pvanhoof> or incorrect dependency
[12:14] <azeem> looks like libgnomemm got transitioned before libgtkmm?
[12:14] <azeem> so needs a rebuild I guess
[12:17] <pitti> infinity: btw, I just found another hanging hoary-updates package:  dbus (0.23.4-0ubuntu4)
[12:17] <doko> pitti: yes, that was the thing as was asking before ...
[12:18] <paolo> Are there channel logs?
[12:19] <daniels> paolo: http://people.ubuntu.com/~fabbione/irclogs/
[12:19] <daniels> hm
[12:19] <daniels> what happened to xorg 6.8.2-10.1?
[12:19] <daniels> speaking of things that just wandered out of hoary-updates
[12:22] <infinity> mdz : Your LiveCD builds on terranova should be okay now, I just did a test run of all of them.
[12:23] <pvanhoof> During the boot of my new kernel, I saw the message "Unable to find volume group "hda1"
[12:23] <pvanhoof> luckily it did boot
[12:23] <pvanhoof> :p
[12:23] <paolo> daniels, is it espectable to not have xfonts-terminus working on the latest xorg?
[12:23] <pvanhoof> this was, of course, a breezy kernel
[12:24] <pvanhoof> is
[12:24] <paolo> pvanhoof, it doesn't MAKEDEV hd[abcd]  for me too, but I boot from USB (/dev/sda)
[12:24] <daniels> daniels@ephemera:~/canonical/brainfreeze/xorg/monolith% interdiff -z old/xorg_6.8.2-48.diff.gz xorg_6.8.2-49.diff.gz | diffstat | tail -1
[12:25] <daniels>  56 files changed, 54 insertions(+), 15729 deletions(-)
[12:25] <daniels> paolo: yeah
[12:25] <pvanhoof> paolo, is it something that I can fix?
[12:25] <paolo> daniels, aww - too bad :-)
[12:25] <paolo> pvanhoof, unfortunately I don't know.
[12:25] <pvanhoof> or something that I shouldn't fix
[12:25] <pvanhoof> ok
[12:25] <pvanhoof> it does take long for the kernel to mount the volumne
[12:25] <paolo> pvanhoof, as a workaround you could create them by hand once it booted.
[12:25] <paolo> pvanhoof, but it will not reduce that delay - I think.
[12:26] <pvanhoof> ok
[12:26] <pvanhoof> the delay is not a big problem .. 
[12:26] <paolo> I wonder how can people code without a terminus-enabled Emacs! /me grins evilly
[12:27] <pvanhoof> ok. other than that kernel issue
[12:27] <pvanhoof> everything seems to work for me , breezy
[12:27] <mvo> seb128: so gamin changed the semantic of FAMEvent.filename? it does no longer include the path? do you know what that was good for?
[12:28] <seb128> mvo: API b0rkage?
[12:28] <pvanhoof> aha, and the keyboard layout thing now works
[12:28] <pvanhoof> cool
[12:28] <seb128> mvo: nop
[12:28] <paolo> daniels, could I help in any way for this font issue?
[12:28] <pvanhoof> Error activating XKB configuration.
[12:28] <pvanhoof> bleh :)
[12:28] <mvo> seb128: very bad indeed, old gamin gave me complete pathes for changes files, new gamin does no longer do that
[12:29] <seb128> mvo: bugzilla.gnome it please
[12:29] <pvanhoof> bleh, no french charactes for me then
[12:29] <mvo> seb128: is the new maintainer around on irc? I would like to have a word with him :)
[12:30] <pvanhoof> is there a way to switch to us_intl for the keyboard on a breezy?
[12:30] <pvanhoof> a way that works :)
[12:30] <seb128> mvo: not that I know of, but you can probably drop him a mail
[12:32] <seb128> what is the standard admin group ? adm or admin?
[12:33] <paolo> admin
[12:33] <seb128> grumpf, why does my user is to "adm" and /var/log files for adm too
[12:34] <paolo> Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.
[12:34] <paolo> seb128, It happened to me in this breezy install - it seems because I set a root password in the process.
[12:35] <seb128> is the stock user on a stock install a member of admin or adm ?
[12:35] <seb128> my /etc/group doesn't list "admin" as a group ...
[12:35] <paolo> If stock != expert, I can't say.
[12:35] <paolo> seb128, yes, you have to add the group and the line to /etc/sudoers, if you set a root password.
[12:36] <paolo> (and the user to the group, obviously)
[12:37] <omer> hello
[12:37] <omer> I have seriously problem
[12:37] <omer> I can't load the system
[12:37] <daniels> paolo: not really, sorry
[12:38] <omer> it a new install, on a new computer, amd 64
[12:38] <omer> and yesterday I can
[12:38] <omer> now, all I have is the grub command line
[12:38] <infinity> Unpacking gconf2 (from .../gconf2_2.11.90-0ubuntu3_i386.deb) ...
[12:38] <infinity> dpkg: error processing /var/cache/apt/archives/gconf2_2.11.90-0ubuntu3_i386.deb (--unpack):
[12:38] <infinity>  subprocess pre-installation script returned error exit status 1
[12:38] <infinity> Bah.
[12:38] <infinity>  /var/lib/dpkg/tmp.ci/preinst: line 7: return: can only `return' from a function or sourced script
[12:39] <paolo> daniels, no problem - I wish I could have ;-)
[12:39] <daniels> infinity: is gtk bug
[12:39] <pvanhoof> omer, doesn't sound like a big problem if you just installed it yesterday .. reinstall it? :)
[12:40] <pvanhoof> omer, if you didn't "upgrade" something, you might have a problem with your harddisk or hardware
[12:40] <omer> I just want to chwck out if there is another solotion
[12:40] <omer> I have two old harddisk, not serial ata
[12:41] <pvanhoof> omer, you can try booting with a livecd and see if the partition is still readable
[12:41] <pvanhoof> if it is
[12:41] <pvanhoof> mkdir /mnt/temp
[12:41] <Kamion> Mithrandir: everything I've done's in the archive
[12:41] <pvanhoof> mount /dev/hda1 /mnt/temp
[12:41] <pvanhoof> chroot /mnt/temp
[12:41] <pvanhoof> init 5
[12:41] <omer> In the start I have on the computer serial ata
[12:41] <Kamion> Mithrandir: it's in helper programs in partconf, mostly
[12:41] <omer> It will take time to download the live cd
[12:41] <omer> so, just to reinstall it?
[12:42] <pvanhoof> omer, yes well, with nothing you can't fix things 
[12:42] <pvanhoof> omer, that is the most easy solution for your problem, yes
[12:42] <seb128> infinity: jbailey broke that's and I uploaded a fixed version like 1 hour ago
[12:42] <omer> so I will reinstall it
[12:42] <infinity> seb128 : Ahh, I must have just missed getting the fix on my LiveCD build.
[12:42] <omer> There is a way to use my serial ata hardisk?
[12:42] <pvanhoof> omer, and download the livecd once reinstalled
[12:42] <omer> OK
[12:43] <omer> I have a serial ata that came with the computer
[12:43] <pvanhoof> omer, well, you can check whether the livecd finds your serial ata hd
[12:43] <pvanhoof> if it does .. the installed will most likely detect the controller/ata hd
[12:43] <omer> the installer don't recognize it
[12:44] <pvanhoof> and then it should be possible to select it as the target device to put your / on
[12:44] <omer> so I use in my old HD
[12:44] <Kamion> Mithrandir: see near the end of http://people.ubuntu.com/~fabbione/irclogs/archived/2005-06/ubuntu-devel-2005-06-01.html for the last important discussion about it
[12:44] <pvanhoof> omer, then it highly depends on your serial ata controller 
[12:44] <pvanhoof> omer, if you can find kernel modules/support for it at the manufactorer of the controller: perhaps
[12:44] <Kamion> Mithrandir: the thing about having a little script in partconf to extract the label which is then used by os-prober
[12:44] <jbailey> seb128: Thanks for catching that.  I thought return was the same as exit in regular shell.
[12:45] <omer> I have a disket with driver to windows
[12:45] <jbailey> seb128: But apparently it's not C. =)
[12:45] <pvanhoof> omer, you can also build a custom kernel and replace the one of the installer. Also note that you'll have to replace the final kernel with that one etcetera ... it's a lot of work
[12:45] <pvanhoof> omer, that driver will not work
[12:45] <infinity> jbailey : I've heard testing packages is a good idea.  <duck>
[12:45] <omer> I know
[12:45] <Kamion> Mithrandir: but anyway, as the IRC log indicates, colin.watson@canonical.com--2005/casper--automount--0 has the relevant live CD tweak; and I misspoke, that part isn't in the archive
[12:45] <pvanhoof> omer, so basically .. use your old harddrive
[12:45] <seb128> jbailey: hi, no problem :)
[12:46] <omer> so I will continue working with the old HD
[12:46] <omer> OK
[12:46] <omer> thanks
[12:46] <Kamion> Mithrandir: that's http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005
[12:46] <jbailey> infinity: Right, and I tested upgrades from a previous version, from the problem version, and from the newer version as well as downgrades.
[12:46] <jbailey> infinity: Forgot to --purge it. =)
[12:46] <infinity> Tsk. :)
[12:46] <infinity> I'll forgive you this once.
[12:46] <pvanhoof> omer, if you can get the serial one working once installed and upgraded .. you might try reinstalled with the very latest unstable release build of ubuntu
[12:46] <infinity> jbailey : I wouldn't care if it hadn't broken the LiveCD build. :)
[12:47] <pvanhoof> s/reinstalled/reinstalling
[12:47] <omer> It a bait dangerus to use unstable, not?
[12:48] <Kamion> speaking of broken builds, gnome-applets and gaim are my currently-painful missing builds
[12:48] <daniels> \o/ not xorg
[12:48] <pvanhoof> omer, you should ask such questions on #ubuntu. Those people can help you
[12:48] <pvanhoof> omer, but indeed, unstable is more dangerous than stable
[12:48] <Kamion> ow, gnome-applets dep-wait libhal-dev
[12:48] <omer> they send me here
[12:48] <pvanhoof> lol. I see
[12:49] <daniels> Kamion: libhal-dev should now be buildable again
[12:49] <omer> I have problem with installing
[12:49] <pvanhoof> omer, what the people here basically need to know is the manufactorer of your serial ata controller
[12:49] <Kamion> infinity: give-back libhal-dev, please?
[12:49] <Kamion> er, hal
[12:49] <pvanhoof> and the version/id/make etcetera
[12:49] <pvanhoof> and then they can tell you whether or not the device is supported
[12:50] <omer> I can tall you what was writen on the disket:
[12:50] <pvanhoof> sure
[12:51] <omer> Silicon Image SATA RAID Driver for ATI RS480
[12:51] <pvanhoof> you could try loading the module sata_sil
[12:51] <pitti> elmo: heartbeat sync, please
[12:51] <pvanhoof> during the installation
[12:52] <Lathiat> silican image raid is fake raid
[12:52] <Lathiat> fwiw
[12:52] <Lathiat> so youll get the disks but not the raid
[12:52] <Kamion> daniels: does that mean we know where that dpkg segfault came from?
[12:52] <omer> If you can explain me exactly what to do it help
[12:53] <infinity> Kamion : Done.
[12:53] <pvanhoof> omer, I forgot the installation procedure acutally :). But I do know you need (in some expert mode) need to load that module using some option
[12:54] <pvanhoof> Perhaps do the people on #ubuntu know how to do that.. or perhaps will somebody else answer it
[12:54] <infinity> Kamion : And no, we have no idea where the dpkg segv is coming from yet. :/
[12:54] <pvanhoof> basically .. if you can manage to load that module, it might work
[12:54] <omer> All right, so I go back to there
[12:54] <omer> thanks
[12:54] <pvanhoof> since the support for your device would be implemented in that module
[12:54] <infinity> Kamion : Other than the general cluster of packages that seems to tickle it, leading me to believe that if I just change enough control fields in the gl/glu clusterfuck, it'll magically go away.
[12:54] <pvanhoof> and the kernel will only find your device if that module is loaded
[12:54] <j^> whats the current plan for default audio output? alsa / polyp / esd?
[12:55] <pvanhoof> not sure if the version of your device is also supported by the module
[12:55] <Kamion> gaim was bitten by the gconf2 preinst thing
[12:55] <pvanhoof> you'll have that check that
[12:55] <Lathiat> hrm ive got 15 lines in my system tray again
[12:55] <pvanhoof> gtg now omer  :)
[12:55] <pvanhoof> hf
[12:55] <Lathiat> somethings messing with it, perhaps udpate notifier ?
[12:55] <Kamion> ok, so that should be most of the desktop problems
[12:55] <Lathiat> seems to be a recent problem
[12:55] <Robot101> gaim... gconf?
[12:55] <omer> I try to check what I can
[12:56] <Kamion> huh, no, imagemagick/amd64 too
[12:56] <Kamion> infinity: that's another dpkg segfault casualty
[12:56] <Kamion> infinity: yeah, that was my instinct too
[12:56] <jbailey> Hmm..  13365 says that lilo passes root= as a *numeric* device?
[12:56] <Kamion> shall I get working on that today? I can't really do significant more installer work before going on vacation; my main outstanding task is Colony 3
[12:56] <jbailey> Ugh.  I thought I had managed to escape all the crappy magic constants.
[12:57] <mvo> Lathiat: do you have a screenshot (if it is u-n faults, i would like to know :)
[12:58] <infinity> Kamion : daniels just went through xorg and tore out a bunch of obsolete conflicts/replaces which will make it in the next upload, and I'm going to mangle mesa beyond repair, so we may get it worked around.
[12:59] <infinity> Kamion : I'd rather, though, have someone attempt to debug the actual segv.
[12:59] <infinity> Kamion : Keybuk's not had the time/inclination to look at it, but someone really should.  I'm sure we're tickling something hairy in the depths of dpkg that really should not be broken like this.
[01:00] <infinity> Kamion : If you have the time to look at it, debugging dpkg would make me love you forever.  All I could get form it was an un-backtraceable smashed stack.
[01:01] <Kamion> ok, makes sense
[01:01] <Kamion> Mithrandir: I've NEWed ia32-libs-kde, guessing that'll make ooo2-amd64 entirely installable
[01:02] <mvo> Kamion: is gnome-app-install-data waiting in NEW too?
[01:03] <Kamion> Mithrandir: time to add it to the desktop seed?
[01:03] <Kamion> mvo: yeah, processing now
[01:03] <Kamion> mvo: why the split?
[01:04] <Kamion> infinity: what was the reproduction case again?
[01:04] <mvo> Kamion: it felt natural 
[01:05] <infinity> Kamion : Pick one from a build log, there are dozens.  But the one that works 100% for me is "new --variant=buildd chroot ; apt-ge install libqt3-mt-dev mesag-dev"
[01:06] <Kamion> mvo: it would have made sense if gnome-app-install were architecture: any, but it's architecture: all
[01:06] <infinity> Kamion : Take a note of which packages get installed, so you can repeated --purge them and reinstall while debugging, if you don't feel like debootstrapping a fresh chroot every time.
[01:06] <Kamion> infinity: oh, it works if you --purge? I'm sure that failed to reproduce for me before
[01:06] <Kamion> but maybe I just fumble-fingered it
[01:06] <mvo> Kamion: hm, right
[01:06] <infinity> Kamion : it works for me if I purge back to a clean chroot and reinstall libqt3-mt-dev/mesag-dev again.
[01:07] <infinity> Kamion : Same as the buildds, which I purge down to a clean chroot regularly.
[01:07] <pitti> infinity: my security uploads are not built by i386...
[01:07] <Kamion> infinity: ok
[01:07] <infinity> pitti : i386 is a bit backlogged.  Should clear up shortly.
[01:07] <pitti> ok, thanks
[01:08] <infinity> pitti : I have one buildd offline for bootstrapping biarch stuff and another was offline debugging LiveCD issues, that's all.
[01:08] <infinity> And.. I'm not actually sure what the other is up to.. <goes to check>
[01:08] <pitti> infinity: ok, that's fine, just wanted to point it out if it had been a serious problem :-)
[01:09] <infinity> Oh, building OpenOffice.  That'll kill anything.
[01:13] <Lathiat> heh
[01:14] <infinity> Kamion : Also, hal/amd64 died differently this time.
[01:14] <infinity> Kamion : Completely unrelated to dpkg.
[01:14] <Kamion> gar
[01:16] <Kamion> mvo: I've accepted it for now since FF's today, but I think you might want to consider merging those packages again
[01:16] <infinity> Kamion : I'll make someone else care about it.  I don't want to distract you from fixing my dpkg woes. ;)
[01:17] <mvo> Kamion: ok, sorry for that. I will have to do another upload today, should I just merge it then?
[01:17] <Kamion> mvo: that's fine, no problem
[01:18] <setite> anyoen have an evdo card
[01:18] <setite> im struggling to get mine to work on hoary
[01:19] <DanielN> does someone know about libiw27?
[01:19] <DanielN> it's broken i think
[01:19] <Kamion> in breezy, use libiw28
[01:19] <DanielN> ah
[01:19] <Kamion> libiw27 is gone
[01:20] <DanielN> then the debootstrap script mentioned in the wiki is wrong for breezy
[01:20] <DanielN> DebootstrapChroot
[01:20] <DanielN> but thanks Kamion 
[01:21] <DanielN> someone should fix that
[01:21] <Lathiat> DanielN: erm
[01:22] <Lathiat> i go debootstrap breezy dir/ file:///home/lathiat/ubuntu
[01:22] <Lathiat> and it works?
[01:22] <DanielN> which debootstrap version are you using?
[01:22] <setite> has anyone tested EVDO mobile modems under linux?
[01:23] <Lathiat> setite: There all different. This is not a user support channel, it is for discussion about development of ubuntu, Please see #ubuntu for user support, for that sorta thing you probably wanna ask google.
[01:23] <DanielN> argh
[01:23] <DanielN> there are several more errors in that damn script
[01:23] <Kamion> DanielN: no, there aren't
[01:23] <Kamion> DanielN: you just can't use it with hoary's debootstrap package
[01:23] <setite> i know where the support channel is.. i was just hoping there was someone in here who had one and could help.. thanks
[01:24] <DanielN> Kamion, i don't use this one
[01:24] <DanielN> i use the one told on wiki.ubuntu.com/DebootstrapChroot
[01:24] <pitti> grrrr, this crashing ffox drives me crazy
[01:24] <DanielN> will build an UML machine on a hoary server
[01:24] <Simira> what is claire's nickname?
[01:24] <Kamion> DanielN: oh that's kind of ancient, just build the version in breezy
[01:24] <Kamion> DanielN: you should always use the current version in breezy
[01:25] <DanielN> ok, so i run breezys debootstrap on hoary then?
[01:26] <Kamion> DanielN: rebuild breezy's debootstrap package for hoary
[01:26] <Kamion> actually, no, that's unnecessary now isn't it
[01:27] <Kamion> just grab the .deb from breezy
[01:27] <Kamion> I'll update the wiki to say that
[01:27] <DanielN> ok, do that
[01:27] <DanielN> and thanks for your hints ;)
[01:28] <Kamion> DanielN: wiki updated
[01:28] <DanielN> :)
[01:28] <Kamion> thanks
[01:28] <DanielN> np
[01:28] <DanielN> thanks to you
[01:41] <Amaranth> seb128: pyxdg 0.15 is out
[01:47] <omer> did anyone here understanding in BusyBox? (ash)?
[01:49] <seb128> Amaranth: cool, thanks
[01:50] <infinity> pitti : Those missing builds should be rolling in.
[01:50] <pitti> yay
[01:54] <pitti> ah, pizza appointment...
[02:05] <doko> carlos: ping
[02:05] <carlos> doko, in a meeting sorry
[02:09] <doko> Kamion, mdz: ok to upload a new l-r-m with updated avm modules for i386 and amd64?
[02:32] <Zomb> are there any jigdo files for the Hoary DVD images?
[02:34] <Zomb> eh, forget it, I found a DVD from the LinuxTag
[02:35] <Lathiat> hehe
[02:38] <elmo>         find /etc -name mediawiki.conf -exec rm -rf {} \; ;
[02:38] <elmo> classy
[02:38] <pitti> urgh
[02:39] <ogra> elmo, thats only tuned the apache config....
[02:39] <mbreit> elmo: could you sync bacula from debian unstable please? it fixes ftbfs and unmet dependency in breezy. thanks!
[02:40] <siretart> elmo: could you please sync pong2 from unstable? 
[02:40] <pitti> elmo: please sync heartbeat
[02:40] <siretart> elmo: and besides, do you any news of the linode vserver for revu?
[02:41] <pvanhoof> gnome-app-install-data wasn't installed after installing gnome-app-install
[02:41] <elmo> ogra: no, it's ANY FILE called mediawiki.conf in ALL OF /etc
[02:41] <pvanhoof> [breezy] 
[02:41] <pitti> ogra: and mind the merciless -rf
[02:41] <ogra> elmo, but mediawiki never installed such files... 
[02:41] <elmo> ogra: then why is mediawiki removing them?
[02:41] <ogra> it only stars with this package...
[02:42] <ogra> probably because duck had one that installed the file in /etc ... which is wrong...
[02:42] <ogra> starts to exist ... even
[02:43] <ogra> original medaiwiki only stores settings and configs in the www root....
[02:45] <ogra> elmo, would you feel better if i comment it out ? it does nothing anyway ...
[02:45] <elmo> ogra: dude, this isn't about me feeling better, that's quite obviously a bug
[02:45] <ogra> oki
[02:46] <ogra> i'll fix t then...
[02:50] <elmo> mbreit/siretart/pitti: done
[02:50] <pitti> thanks
[02:50] <pvanhoof> [breezy]  Problem: Most of the nautilus "Open with" settings are wrong
[02:50] <elmo> siretart: we're still waiting on availability from linode, I'm afraid
[02:50] <mbreit> elmo: thanks!
[02:51] <seb128> pvanhoof: what do you mean "wrong"?
[02:51] <pvanhoof> seb128, for example if I open with gedit, it doesn't open the file in gedit
[02:51] <pvanhoof> and the default has been set to Firefox for .txt files
[02:51] <pvanhoof> stuff like that
[02:51] <pvanhoof> some are correct ..
[02:52] <seb128> $ grep "text/plain" /etc/gnome/defaults.list
[02:52] <seb128> text/plain=gedit.desktop
[02:52] <pvanhoof> like pdf was correct
[02:52] <seb128> what do you mean?
[02:52] <seb128> "gedit file.txt" doesn't run gedit?
[02:52] <seb128> "<pvanhoof> seb128, for example if I open with gedit, it doesn't open the file in gedit"
[02:52] <pvanhoof> trying
[02:53] <pvanhoof> hmm ok, not it does work :)
[02:53] <pvanhoof> now
[02:53] <seb128> NOTABUG
[02:53] <ogra> elmo, any other things you spotted before i upload the new versiomn ?
[02:54] <elmo> ogra: no
[02:54] <ogra> yay
[02:54] <pvanhoof> :p
[02:54] <pvanhoof> indeed. now it's correct
[02:55] <pvanhoof> perhaps I just had to restart nautilus after some upgrade
[02:55] <pvanhoof> It was last session. So nautilus effectivly restarted since then
[02:56] <doko> elmo: please can you remove atlas, blas, lapack, lapack99 and sync ghemical ?
[02:58] <siretart> elmo: thanks for sync and update on linode.
[02:59] <pitti> bah, I can't work like this
[02:59] <janimo> elmo please sync ecosconfig,thanks
[03:01] <elmo> janimo: please read my email
[03:03] <madduck> jamesh: interesting blog entry. did you see mine (planet.debian.org)?
[03:03] <omer> Hello
[03:03] <omer> I have controller integrated by ATI SB400
[03:03] <madduck> jamesh: also http://blog.madduck.net/debian/2005.08.10-arch-packaging.html
[03:04] <omer> Which module shuld I load that it recognize by the installer?
[03:04] <jamesh> madduck: I don't read planet debian much.  Is that the URL of your entry?
[03:04] <madduck> one of the two. yes
[03:04] <madduck> jamesh: http://blog.madduck.net/debian/2005-08-11-rcs-uploads.html is the other
[03:05] <janimo> elmo, haven't got reply  but just got ACCEPTED from Katie. Thanks
[03:06] <elmo> janimo: the reply says, please: a) ask for/about source packages not binaries and b) specify the version you want
[03:07] <janimo> elmo, indeed I saw there are two versions of binaries on debian, but I thought a sync brings the newest source.
[03:07] <janimo> I am confused I admit,but that tool is only used on x86 anyway AFAIK
[03:08] <elmo> janimo: the point is sync works by source package; a) if you ask for a binary, I have to go and work out what source package to tell my tool [not much work, but it adds up across all sync requests] , b) if you ask for a binary, it's not obvious you know the other packages are being synced and have checked the implications of it
[03:09] <janimo> actually I thought that what I asked for was a regular sync, did not notice differences.(binary only package?)
[03:10] <janimo> just saw it has wxwidgets depends wrong and needed to correct that without an ubuntu1 or build1 patch
[03:11] <janimo> indeed now I see what you mean
[03:11] <janimo> I assumed the source has the same name, sorry bout that I'll be more careful next time
[03:11] <janimo> thanks for the trouble
[03:12] <pef> last upgrade render breezy unbootable (error on init :/)
[03:13] <pef> somebody has this problem ?
[03:14] <\sh> ok..hoary + portege r200 network card...== unusable
[03:15] <ogra> \sh, use breezy... thats what you got this baby for ;)
[03:15] <\sh> ogra: yes...this is easy now...pxeboot is working...
[03:15] <\sh> what about daily cd? installable or should i use last colony?
[03:18] <\sh> ok...trying colony 2
[03:21] <Lathiat> mjg59: why is suspend to ram off by default? doesnt work often?
[03:21] <ogra> Lathiat, i'd guess 80% .... 
[03:22] <Lathiat> ogra: and to disK?
[03:22] <ogra> 98 ? dunno, just guessing
[03:22] <Lathiat> hm ok
[03:24] <mvo> Kamion: permission for a update-notifier upload? it works correctly with the new gamin now (new gamin changed the meaning of a field in the FAMEvent structure under certain conditions and that breaks u-n)
[03:25] <bddebian> Morning
[03:26] <highvoltage> morning (good afternoon from +2GMT
[03:26] <bddebian> Heh
[03:26] <Lathiat> evening here :) +8
[03:26] <Lathiat> heh that looks like some kinda stupid smiley
[03:26] <bddebian> A goatee ? ;-)
[03:26] <mvo> Kamion: and a gnome-app-install upload that fixes some missing icons, the package split and adds some support for mimetype searching
[03:30] <omer> can you help me with kernek modules?
[03:31] <janimo> what are the criteria for a source package to be deletable from the archives?
[03:32] <omer> *kernel
[03:34] <paolo> Is it a problem if a package installs gcc-4 and another gcc-3?
[03:35] <Lathiat> no
[03:36] <paolo> OK, I tought mplayer needed some update because it want to install gcc-3.3-base.  Thanks.
[03:39] <\sh> hmmm
[03:40] <mbreit> btw: who is responsible for adding/deleting NFUs on the buildds?
[03:40] <\sh> to test if a dual install of ubuntu and windows xp is possible...well...toshiba delivered only a recovery dvd with it
[03:40] <\sh> so it will delete all stuff from the hd when it's installed
[03:41] <ogra> have fun partitioning :)
[03:41] <azeem> how did y'all install Ubuntu on you X40s without a CD-ROM?
[03:41] <\sh> is it possible to shrink ntfs partitions with the fdisk util?
[03:41] <\sh> https://wiki.ubuntu.com/Installation/LocalNet
[03:41] <\sh> mjg59: thx btw for this tip...
[03:41] <ogra> azeem, PXE magic :)
[03:41] <\sh> mjg59: but there is one mistake in the default config 
[03:41] <azeem> ogra: cool
[03:41] <ogra> :)
[03:41] <\sh> filename="pxelinux.0"; should be filename="ubuntu/install/netboot/pxelinux.0";
[03:42] <\sh> ok another try with breezy...rb
[03:42] <\sh> brb
[03:43] <infinity> mbreit : I am.
[03:44] <mbreit> infinity: i have fixed noteedit in breezy, but it's on NFU...
[03:45] <Robot101> Kamion: memdisk at http://syslinux.zytor.com/memdisk.php will let you load a grub floppy as an initrd
[03:46] <infinity> mbreit : So that means you've updated libtse3?
[03:46] <\sh> ok...default breezy colony 2 install is not possible...network device is not recognized
[03:47] <\sh> explanation is on http://glozer.net/dynabook/dynabook.html#ethernet
[03:47] <mbreit> infinity: no, i did not...? it builds fine in pbuilder on amd64...
[03:48] <mbreit> infinity: i fixed building with gcc4... i have not noticed any other problems..
[03:49] <\sh> where can I put an additional driver for the NICs into the install procedure? or do I have to change some seeds?
[03:49] <infinity> mbreit : It was waiting on libtse3 to go through the C++ ABI transition.  Apparently it did so, and no one informed me.
[03:49] <mjg59> mdz: That's correct - Jeff is working on that now
[03:49] <omer> there is chanel to kernel question?
[03:49] <mjg59> Lathiat: Yup
[03:49] <Lathiat> mjg59: ok
[03:50] <Lathiat> mjg59: be nice if there was an 'easier' way to enable it. :)
[03:50] <mjg59> Lathiat: There will be in Breezy
[03:50] <Lathiat> mjg59: and i can reported it workign on a HP nx6120 on hoary
[03:50] <Lathiat> mjg59: if thats of any use, friends got it working great on theirs. :)
[03:50] <\sh> infinity: did I touch it? 
[03:50] <mbreit> infinity: thanks for looking at it...
[03:50] <ogra> some even
[03:51] <infinity> \sh : Well, you've been my only point of contact to MOTU for the C++ transition, so I assumed you'd keep pinging me baout updates to frozenapps. :)
[03:51] <\sh> infinity:  -- Oliver Grawert <ogra@ubuntu.com>  Wed,  8 Jun 2005 13:35:55 +0200
[03:51] <ogra> infinity, the first libtse tranitione is ages ago... it was one of the firts packages of the abi transition
[03:51] <\sh> infinity: ogra is boss motu...so blame him...I gave u all infos i had ... adn I'm working on the rest like an idiot
[03:52] <\sh> *evilsmile*
[03:52] <ogra> infinity, we have lists on the wiki for the transition... why was tse3 frozen ?
[03:52] <infinity> mbreit : Anyhow, noteedit is unfrozen.  Should build soonish.
[03:52] <ogra> oh, and a lot of transition bugs in bugzilla
[03:53] <doko> infinity: please requeue OOo2 on i386, dpkg segfault ...
[03:53] <\sh> ogra: what's the best way to put a new driver into the d-i...just the case, I don't have a external cdrom or floppy drive
[03:53] <infinity> ogra : All C++ apps were frozen, and unfrozen as their depending libs became available.  It's a manual thing, though, so when people don't tell me, I don't always check.
[03:53] <infinity> doko : YAY.
[03:54] <ogra> infinity, ah... ok...
[03:55] <\sh> infinity: but I didn't see it on the frozenapps.txt..tse3 it should give me some hints..but nothing
[03:55] <ogra> i thought it was a general freeze that was dropped after the lib transition was done completely....
[03:55] <infinity> \sh : I just removed it.
[03:55] <infinity> ogra : The transition isn't done.
[03:55] <ogra> i know
[03:55] <\sh> infinity: no..I never saw it, when doko gave me once the url earlier on..i didn't see it on it..
[03:55] <mbreit> infinity: thanks
[03:56] <infinity> ogra : Still waiting on libace, libyehia, libxdb, libwaili and libcrypto__
[03:56] <omer> Does ubuntu kernel suprut ATI SB400?
[03:56] <infinity> \sh : Curious, it was on my list.  Oh well, no big deal.
[03:57] <ogra> i havent had the time to look recently...
[03:58] <infinity> doko, seb128, daniels : Apparently your packages not building on hoary-updates is a feature, not a bug.  They need manual approval by Kamion/mdz.
[03:59] <HiddenWolf> infinity: lol!
[03:59] <seb128> infinity: and they are not noticed on upload? it was waiting for like 3 weeks
[03:59] <infinity> doko : Also, OOo2 is already (re)building on i386.
[04:00] <infinity> seb128 : You may want to ping them.
[04:00] <seb128> I ping mdz by bugzilla, he accepted the patch and I commented saying I did the upload
[04:00] <seb128> k, next time I'll ping on IRC too :p
[04:00] <seb128> thanks infinity
[04:01] <seb128> s/ping/pinged/
[04:01] <Amaranth> seb128: what would you say to putting gnome-menus 2.11.91 in backports? :)
[04:02] <seb128> I don't use backports
[04:02] <Amaranth> surprisingly it built fine against hoary and ran
[04:02] <seb128> fcrozat made a patch to make it work with gnome-panel 2.10 for mandriva
[04:03] <seb128> so I guess there is some issues
 didn't work (odd) but the bugs in 2.10.1 were fixed and autoupdating worked (thanks to libgamin-dev build-dep)
[04:03] <Amaranth> where is this patch?
[04:03] <seb128> ask to him on #gnome-hackers
[04:03] <seb128> he keeps speaking about that
[04:05] <Mithrandir> Kamion: I thought it was in the desktop seed already?
[04:05] <\sh> ok...will have a look later on this bloody ethernet problem...now I'm going :)
[04:05] <Simira> Mithrandir : get home!
[04:06] <doko> infinity: mdz did approve it in 7292
[04:07] <infinity> doko : I believe it requires manual *intervention*, not just approval.
[04:12] <pitti> mvo: oh, so you already sent the n-d patch upstream?
[04:14] <mvo> pitti: only my patch about the arrow placement
[04:14] <pitti> mvo: yes, that's what I meant
[04:14] <pitti> mvo: my patches are already upstream, he prepares a 0.2.2 tarball, I tested it already
[04:14] <mvo> yes, I wonder if he will like it. it looks a bit crude to me and to get it right there will be a lot more needed
[04:15] <mvo> he hasn't answered me yet, may I scared him away :)
[04:15] <pitti> he didn't answer to my last mail either, probably just busy (he is very cooperative and answered to my other mails)
[04:16] <carlos> doko, ping
[04:16] <mvo> oh, ok. nice
[04:17] <pitti> Hi carlos 
[04:17] <carlos> pitti, hi
[04:19] <doko> carlos: pong
[04:19] <ogra> whats wrong with the archive... ? i cant pull any source file and the builds break seem to too...
[04:19] <carlos> doko, I'm ready to listen to you :-)
[04:19] <ogra> hmpf...
[04:20] <pitti> ogra: apt-get update seems to complain about wrong md5sums
[04:20] <ogra> yep
[04:21] <ogra> i also had 404s for the Package.gz files
[04:21] <doko> carlos: just wanted to know, where I can update the wiki, and when we can start the first tests ...
[04:21] <doko> pitti: where do you write the language data during a build?
[04:22] <pitti> doko: you mean where a package stores po and pot files? anywhere in the source dir
[04:24] <doko> pitti: where do you write them, when the package is built?
[04:25] <pitti> doko: pkgstriptranslations tars them up into ../package_version_translations.tar.gz
[04:25] <doko> pitti: in the parent dir?
[04:25] <pitti> yes, where the debs, dsc, changes, etc. land
[04:26] <doko> ok, and what does happen then?
[04:26] <carlos> doko, pitti https://wiki.launchpad.canonical.com/RosettaFirefoxAndOpenOfficeSupport
[04:26] <carlos> doko, pitti if you cannot edit it, tell me so I can ask extra permissions for you
[04:26] <doko> pitti: ?
[04:26] <ogra> debian/rules:11: /usr/share/cdbs/1/rules/simple-patchsys.mk: No such file or directory .... hmm... interesting
[04:27] <pitti> doko: the buildd moves them to rookery:~lamont/translations
[04:27] <carlos> doko, and Rosetta imports the .pot and .po files
[04:27] <pitti> doko: rosetta and my scripts collect the tarballs from there
[04:27] <pitti> ogra: missing cdbs b-dep?
[04:27] <pitti> carlos: thanks
[04:27] <ogra> pitti, haha
[04:27] <doko> is the buildd stuff a laminity thing?
[04:28] <pitti> doko: lamont set it up
[04:28] <carlos> laminity?
[04:28] <pitti> doko: why?
[04:28] <ogra> pitti, the package is from DUCK, you wont find even traces of debhelper in there ;)
[04:28] <pitti> carlos: lamont/infinity
[04:28] <doko> pitti: ???
[04:28] <carlos> oh!
[04:28] <doko> pitti: because I have to export the damsn GSI files?
[04:29] <pitti> doko: I mean, is there a bug in this process?
[04:29] <pitti> aha
[04:29] <carlos> doko, hmmm I thought we made clear we don't need to export the gsi files....
[04:29] <ogra> laminity ? 
[04:29] <ogra> a new description for buildd masters  
[04:29] <ogra> ?
[04:29] <doko> carlos: huh?
[04:29] <carlos> doko, that's what we talked about importing first release without getting Rosetta imports
[04:29] <pitti> doko: why isn't exporting the po files enough? (and pot)
[04:30] <carlos> and reupload a -2 version with the updates and generating the .gsi on build time....
[04:30] <doko> pitti: I DON'T HAVE ANY PO/POT FILES TO EXPORT
[04:30] <carlos> I think we are having here a misscomunication...
[04:30] <doko> carlos: did you read, why I did split the sources into two parts?
[04:30] <pitti> doko: I though that was the mere point of using pootle???
[04:31] <carlos> doko, dude, we agree on a way to prevent the .gsi export last week
[04:31] <carlos> and it's in the spec
[04:31] <carlos> and you agreed
[04:31] <doko> pitti: all the conversions are done outside the build process
[04:31] <carlos> what's the problem now? I mean, what am I missing?
[04:31] <carlos> doko, you do it by hand?
[04:31] <carlos> before the source upload?
[04:31] <pitti> doko: why can't you call pootle in debian/rules?
[04:32] <pitti> doko: (that was the idea actually)
[04:32] <pitti> carlos: the spec is heavily truncated
[04:32] <doko> pitti: you told me, that I have to include the imported language data in the diff. How do you do that from inside debian/rules ?
[04:32] <carlos> pitti, really?
[04:32] <carlos> hmm, let me check
[04:33] <pitti> doko: I think we have a gross misunderstanding here
[04:33] <pitti> doko: so again, the oo.o2 source package can call pootle in debian/rules to generate pot/po files, right?
[04:33] <pitti> doko: this will create po files in the source pkg build directory
[04:34] <pitti> doko: it is not necessary to include the po files in the package diff
[04:34] <carlos> pitti, fixed
[04:34] <pitti> doko: it is just necessary that they are present in the source build dir before dh_builddeb
[04:35] <pitti> ^ this will call pkgstriptranslations, which collects the po files in a tarball
[04:35] <doko> pitti: please don't include the conversion in the build process. we never did specify this. the extraction takes about 5min for each language on a fast machine
[04:36] <pitti> doko: uh, doing it on the buildd was at least my original idea
[04:36] <doko> pitti: I know, I don't need to include the po/pot files in the diff.
[04:36] <pitti> doing it manually before each upload won't save you time, right? and it's error prone
[04:37] <pitti> doko: we specified it: "#
[04:37] <pitti> New script that uses the oo2po script from pootle, it will be executed in the openoffice.org2-l10n tarball so it creates a po/ directory storing there the .pot and .sdf files and a .po file per language available on that sourcepackage. This script will be executed on build time, just before the extract_po script.
[04:37] <pitti> #
[04:37] <pitti> "
[04:37] <pitti> bah, silly ffox paste
[04:37] <doko> no, I don't want to do it manually. I'm building the ooo2-l10n source package automatically from the ooo2 source package and the data provided from rosetta
[04:38] <doko> carlos: thanks, the overview in the wiki is now more complete.
[04:38] <carlos> doko, the changes done after your update came from pitti
[04:39] <carlos> I didn't touch it yet ;-)
[04:40] <infinity> Hrm, am I going to have to add a nick hilight on "laminity" now?
[04:40] <Mithrandir> \lafty :-P
[04:41] <infinity> I don't recall a LaTeX code for that one, you lose.
[04:42] <doko> pitti: OOo2 doesn't work with pkgstriptranslations, there's nothing to strip besides some menu files
[04:42] <carlos> doko, pitti please, could you agree on a procedure to follow on your side for OO and update the wiki so it's well documented?
[04:43] <pitti> doko: that's why pottle is supposed to generate pot/po files on the buildd
[04:43] <pitti> doko: why isn't that possible?
[04:43] <pitti> we do it for all other packages
[04:44] <pitti> carlos: btw, could you already try ffox po extraction?
[04:45] <mjg59> Hm. So, on this machine, grub fails to work, X screws itself and the wireless does nothing
[04:45] <carlos> not done yet, I was finishing with the fixes we need to be able to export language packs
[04:45] <carlos> I will start with that today
[04:45] <pitti> carlos: oh, export works now?
[04:45] <infinity> mjg59 : Sounds like a success.
[04:46] <carlos> pitti, the code that will fix them is done
[04:46] <doko> pitti: it's a nightmare to debug, if something goes wrong. the conversion can be done offline. there's no reason not to do it offline
[04:46] <carlos> pitti, now it's running on our test system
[04:46] <carlos> but will take a while
[04:46] <rob^^^> anyone else having problems with today's liveCD?
[04:46] <carlos> so I think the data will be fixed on Sunday - Monday
[04:46] <dieman> fucking hell
[04:46] <dieman> i didn't know bazaar tracked inodes
[04:46] <pitti> doko: ok, then shipping the po files in the package diff.gz is fine, too
[04:46] <dieman> i moved to another disk
[04:46] <doko> pitti: no, no po files in the diff.
[04:46] <luis_> rob^^^: what kinds of problems?
[04:47] <infinity> dieman : Yes, it's irritating.  Can't relocate working copies to other computers either.
[04:47] <rob^^^> dunno, Buffer IO errors on virtual PC
[04:47] <pitti> doko: hm, but if they aren't in the package diff, nor generated at build, where do you want to generate and put them?
[04:48] <doko> on rookery, or somewhere else. where do you build the language packs?
[04:48] <dieman> infinity: heh
[04:48] <pitti> doko: I build them on rookery
[04:48] <carlos> pitti, doko do we have Ubuntu packages for pootle?
[04:48] <pitti> carlos: yes
[04:48] <doko> carlos: apt-get is your friend
[04:48] <dieman> infinity: well, anyhow, im just going to check it out, remerge the upstream im working with, and then copy back over the changes i was making to some conflicts
[04:49] <pitti> doko: so if you want to generate them on rookery, I can grab them from there, too
[04:49] <allee> siretart: ping 
[04:49] <doko> pitti: I think, rosetta needs to get them. why do _you_ need them?
[04:50] <pitti> doko: ok, right; I could directly import them into langpacks, but right, Rosetta needs them for import as well
[04:50] <allee> doko: ping  capi und PCMCIA.
[04:51] <rob^^^> first error is attempt to access beyond end of device
[04:51] <rob^^^> hdc: rw=0, want=1279776, limit 970096
[04:51] <allee> doko: I've got my B1 PCMCIA working but it's a bit hackish.  Do you have already any plans how to support PCMCIA?
[04:52] <doko> pitti: ok, so I have to ask lamont/infinity how to move the files I need to rookery?
[04:52] <doko> allee: later please
[04:52] <pitti> doko: which files do you need? you mean, install pootle on rookery?
[04:52] <allee> doko:'k
[04:53] <doko> pitti: the sdf files, as described in the summary
[04:53] <doko> s/summary/overview/
[04:54] <pitti> doko: if you really need build-time generated files for the extraction, this seems really, really hackish to automatically transfer them
[04:54] <pitti> doko: but yes, that would be laminity
[04:54] <doko> pitti: why is it more hackish than transferring the po files?
[04:55] <pitti> doko: not more, but would double the hack :-)
[04:55] <pitti> doko: in fact there is a spec to remove the existing hack
[04:55] <pitti> it's just not yet implemented
[04:55] <infinity> pitti : Can't you just special-case OOo2 in pkgstriptranslations so you can grab the files doko needs?
[04:55] <doko> pitti: and you propose to use your hack and add another one instead of doubling it ;-)
[04:56] <pitti> doko: another idea: why not build ooo on concordia and generate pos there?
[04:56] <infinity> pitti : If we're going to talk about hacks on hacks, I'd rather not be shipping even more out-of-band stuff if we can avoid it.
[04:56] <pitti> infinity: of course I could
[04:56] <infinity> (I'd really prefer is we were dumping this stuff in the .changes, but we're Not There Yet)
[04:56] <infinity> s/is/if/
[04:56] <pitti> infinity: we already talked about that spec, just ENOTIME, I guess
[04:56] <infinity> Yes.
[04:57] <infinity> Hence "Not There Yet."
[04:58] <doko> pitti: what do I win with building on concordia?
[04:58] <pitti> doko: I still don't understand why you don't want to call pootle on the buildd, but if there are reasons, I can change pkgstriptranslations to grab ooo files. So you need find -name "*.sdf"?
[04:58] <pitti> doko: conc has build chroots, rookery not :-)
[04:58] <carlos> doko, ok, thanks
[04:59] <pitti> doko: ok, if exporting *.sdf is your preferred solution, I'm going to change pkgstriptranslations
[04:59] <doko> pitti: how do I know, which languages should be built? You have to change the build code
[05:00] <doko> pitti: where do you expect these sdf files?
[05:00] <pitti> doko: anywhere, I'll just do a find -name "*.sdf" -exec cp ...
[05:00] <doko> pitti: even in the source?
[05:00] <pitti> (preserving the dir structure, of course)
[05:00] <dieman> heh
[05:00] <pitti> doko: yes
[05:01] <dieman> gnu diff and its millionths of a second resolution
[05:01] <doko> no, that's wrong
[05:01] <pitti> doko: please don't expect pkgstriptranslations to know about packaging details
[05:01] <doko> pitti: just search in debian, that's enough
[05:01] <pitti> doko: copying files into the tarbal is fine, but I can't analyze control files in it
[05:02] <pitti> doko: hm?
[05:02] <doko> copying files into the tarball?
[05:02] <doko> lets talk on the phone ...
[05:02] <pitti> ok
[05:02] <pitti> oh wait
[05:02] <pitti> phone is broken ATM
[05:02] <pitti> I call you
[05:02] <doko> :-))
[05:04] <Mithrandir> doko: is -10 uploaded?
[05:07] <Kamion> mvo: yes and yes
[05:07] <Kamion> Mithrandir: not for amd64 - but I'll take that as a "yes, please add it"
[05:07] <Mithrandir> Kamion: yes, please add it. :-)
[05:08] <Kamion> done
[05:08] <Mithrandir> thanks
[05:10] <ogra> heh, edubuntu-meta looks like the amd64 world imploded ...
[05:11] <Kamion> http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html doesn't show particular amd64 damage
[05:11] <mvo> Kamion: thanks
[05:13] <Kamion> argh, what's up with gnome-python-extras?
[05:13] <ogra> Kamion, see the changelog ... nearly all of minimal dissapeared... (i dont care for amd64 currently, so i dont mind to regenerate tomorrow..)
[05:14] <Kamion> it was probably just a transient error when you updated; you should have thrown that away and tried again
[05:15] <Amaranth> Kamion: gnome-python-extras needs to be rebuilt against libwnck18
[05:15] <Kamion> ogra: please fix it today rather than tomorrow, if possible
[05:16] <Amaranth> Kamion: same with serpentine
[05:17] <Amaranth> well, serpentine uses g-p-e
[05:17] <ogra> hmm
[05:17] <ogra> 207	Preparing to replace libglu1-mesa-dev 6.2.1-5ubuntu5 (using .../libglu1-mesa-dev_6.2.1-5ubuntu5_amd64.deb) ...
[05:17] <ogra> 208	Unpacking replacement libglu1-mesa-dev ...
[05:17] <ogra> 209	E: Sub-process /usr/bin/dpkgdpkg-deb: subprocess paste killed by signal (Broken pipe)
[05:17] <ogra> 210	received a segmentation fault.
[05:17] <Amaranth> yay!
[05:17] <ogra> thats how g-p-e looks in the amd64 buildlog
[05:19] <ogra> ppc for comparison:
[05:19] <ogra> 2063	grep: /usr/lib/libdbus-1.la: No such file or directory
[05:19] <ogra> 2064	/bin/sed: can't read /usr/lib/libdbus-1.la: No such file or directory
[05:19] <ogra> 2065	libtool: link: `/usr/lib/libdbus-1.la' is not a valid libtool archive
[05:19] <ogra> 2066	make[3] : *** [nautilusburn.la]  Error 1
[05:19] <Amaranth> *groan*
[05:19] <ogra> i thought that was fixed ysterday
[05:19] <Kamion> I'm looking into the dpkg segfault
[05:19] <ogra> at least on ia64 you have a fine build :)
[05:19] <Kamion> in my negative available time
[05:22] <ogra> hmm, dpkg: serious warning.... that doesnt sound good
[05:23] <infinity> libgl1-mesa contains no files?
[05:23] <infinity> "THE WORLD IS BROKEN BECAUSE I SEGFAULTED EARLIER AND NOW I'M VERY CONFUSED!"
[05:23] <infinity> ogra : That message?
[05:23] <ogra> yay, my next changelog will have the same size :) just inverted the added/removed part in front
[05:23] <ogra> 186	dpkg: serious warning: files list file for package `libglu1-mesa-dev' missing, assuming package has no files currently installed.
[05:23] <ogra> exactly ...
[05:24] <infinity> ogra : Which buildd?
[05:25] <infinity> Kamion : Oh dear god, please fix it now.  I'll buy you a pony.
[05:25] <ogra> 186	dpkg: serious warning: files list file for package `libglu1-mesa-dev' missing, assuming package has no files currently installed.
[05:25] <ogra> ergh
[05:25] <ogra> Automatic build of gnome-python-extras_2.11.4-0ubuntu2 on yellow by sbuild/amd64 1.170.5
[05:25] <ogra> ^^ yellow
[05:26] <mjg59> Hrm. I'm attempting to resize an NTFS partition in the installer. The partitioner keeps claiming it's the original size afterwards.
[05:29] <Lathiat> assumedly its resizing th entfs and not the partition then?
[05:29] <Kamion> infinity: it's in does_replace(), anyway
[05:30] <mjg59> It ought to do both
[05:30] <mjg59> But there's no DMA for the chipset in the installer
[05:30] <Kamion> D000040: does_replace new=libglu1-mesa-dev old=x11proto-gl-dev (0:1.4+cvs.20050524-3)
[05:30] <Kamion> D000040: does_replace ... no
[05:30] <Kamion> D000040: does_replace new=x11proto-gl-dev old=libglu1-mesa-dev (0:6.2.1-5ubuntu5)
[05:30] <Kamion> E: Sub-process /usr/bin/dpkg received a segmentation fault.
[05:30] <Kamion> I'm wondering if it's deeply confused by the two packages replacing each other
[05:31] <mjg59> Kamion: Any idea why ntfsresize would appear to fail?
[05:31] <Kamion> mjg59: not right at the moment I'm afraid
[05:31] <Kamion> I'm swamped
[05:32] <mjg59> Oh. Hitting "Finish partitioning and write changes to disk" does nothing. I think it's broken.
[05:32] <Kamion> /var/log/partman should help but unfortunately I don't have time to analyse it just now
[05:32] <mjg59> Ah. ntfsresize has spewed errors all over the place.
[05:32] <Kamion> possibly also /var/log/{syslog,messages}
[05:32] <pef> re
[05:33] <infinity> Kamion : That does sound deeply confusing indeed.
[05:33] <infinity> Kamion : And easily fixed, since I intend to remove the file overlaps in mesa in the next upload.
[05:33] <infinity> Kamion : You think that'll make it go away and stop hating me?
[05:34] <infinity> Kamion : (Obviously, remove the overlaps AND the Replaces control field, not just the former)
[05:34] <Kamion> infinity: I'm digging into it a bit more
[05:34] <infinity> Kamion : Still, it should probably issue an error or something in such confusing situations. :)
[05:34] <siretart> allee: pong
[05:34] <Kamion> infinity: actually they don't replace each other, I was just being stupid
[05:34] <infinity> Oh.
[05:34] <infinity> Well, so much for that.
[05:35] <allee> siretart: hi. I'm the one pestering you about revu today;)
[05:35] <infinity> I still intend to tear out half the overlaps and replaces.
[05:35] <infinity> Which will probably "fix" it.
[05:35] <infinity> Given the incestuous relationship between xorg and mesa, I assumed the bug would be in the Replaces handling.
[05:35] <allee> siretart: s/revu/revu reviewer/
[05:35] <siretart> allee: ah, hi. I'm just reading you email ;)
[05:35] <allee> siretart: sorry for the mess
[05:36] <siretart> allee: no matter
[05:42] <infinity> Argh.
[05:42] <infinity> Kamion : Do you have an apt cache directory full of the packages you need to reproduce this?
[05:43] <infinity> Kamion : I'm about to start mangling packages in an attempt to work around it in the archive, so...
[05:43] <Kamion> infinity: yes
[05:43] <Kamion> infinity: I'm just in the middle of a debugging build of dpkg now
[05:43] <Kamion> I also have a local mirror which won't update for a while
[05:44] <Kamion> if need be, I can make it not update tonight
[05:51] <doko> carlos: I did talk with pitti about the extraction at the phone. you'll get the strings into rosetta ...  Is there a way for you to import some strings, but not present them for translation? i.e. the OOo2 help cannot be built at the moment, and so it would be some waste of time to translate it
[05:53] <Amaranth> seb128: did you ever add smeg to the seeds?
[05:53] <HiddenWolf> seb128, is gnome network tools supposed to keep an accurate count of incoming and outgoing traffic?
[05:53] <BenC> any kernel-package maintainers here?
[05:53] <seb128> Amaranth: yep, to desktop, why ?
[05:53] <seb128> HiddenWolf: no clue
[05:53] <Amaranth> seb128: just checking :)
[05:54] <HiddenWolf> seb128: network tools has it's 'interface statistics' in the main window, that's why I ask.
[05:54] <Kamion> BenC: jbailey should be around in a bit, I think
[05:54] <seb128> HiddenWolf: that's probably the same as ifconfig
[05:55] <carlos> doko, I'm working on a patch to "hide" some potemplates that are useless, we could use that
[05:55] <infinity> HiddenWolf : Those counters wrap.
[05:55] <carlos> doko, so the import is done, but the user will not see them until you ask me to activate it
[05:55] <HiddenWolf> seb128: I figured. 
[05:55] <carlos> doko, is that enough?
[05:55] <infinity> BenC : kernel-package the package, or kernel-packaging in general.
[05:55] <doko> Kamion: is it ok to upload a new l-r-m with a new driver version of the avm isdn drivers (and new drivers for amd64)?
[05:55] <mjg59> Kamion: Ok, that was just caused by a corrupt filesystem
[05:55] <infinity> BenC : ?
[05:55] <HiddenWolf> infinity: one way or the other, it's off by a margin.
[05:55] <mjg59> The installer didn't seem to pick it up, though. I'll file a bug?
[05:56] <doko> carlos: sounds ok
[05:56] <infinity> BenC : Either way, you probably want to ping #ubuntu-kernel
[05:56] <infinity> HiddenWolf : Mine shows the same stats as ifconfig.
[05:57] <Kamion> (gdb) p dep->list->version
[05:57] <Kamion> $31 = {epoch = 268361688, version = 0x696e6520 <Address 0x696e6520 out of bounds>, revision = 0x58496e70 <Address 0x58496e70 out of bounds>}
[05:57] <infinity> HiddenWolf : Oh, actually, today it doesn't. It's off by a factor of 2.  Odd.
[05:57] <HiddenWolf> infinity: I know for a fact that I've downloaded a multitude of what ifconfig is reporting
[05:57] <Kamion> doko: what does that get us?
[05:57] <Kamion> mjg59: please
[05:58] <Treenaks> HiddenWolf: ifconfig wraps around I guess?
[05:58] <Kamion> infinity: ^-- point of segfault
[05:58] <[SemTeX] > HiddenWolf: 32-bit counters...
[05:58] <doko> avm support on amd64, more stable drivers on i386
[05:58] <[SemTeX] > once you're over ~4GB, it will reset...
[05:58] <Kamion> doko: ok, if you've tested it
[05:58] <doko> it only effects the avm drivers, nothing else.
[05:58] <HiddenWolf> I guess, that makes the statistics useless tho.
[05:58] <infinity> Kamion : Huzzah.
[05:58] <infinity> HiddenWolf : Those stats are generally useless, yes.
[05:59] <HiddenWolf> If they're useless, why are they there?
[05:59] <infinity> "Just cause"
[06:00] <carlos> doko, I suppose that my patch will be applied in a week and a half
[06:00] <carlos> doko, so perhaps it will appear for a couple of days
[06:00] <carlos> in the mean time I can put there a "deprecated, don't use" message
[06:00] <HiddenWolf> infinity: wouldn't it be a good idea to either make them useful or remove it from network tools?
[06:00] <infinity> HiddenWolf : Probably.
[06:01] <HiddenWolf> I'll go file a bug then.
[06:04] <carlos> doko, pitti can I play with hoary's firefox packages or are they too different from breezy? (about language packs)
[06:05] <doko> carlos: not my thing
[06:05] <pitti> carlos: hoary has exactly the same upstream version now
[06:05] <carlos> pitti, ok
[06:05] <carlos> thanks
[06:05] <Nafallo> hmm
[06:06] <pitti> doko:  pkgstriptranslations_14_source.changes ACCEPTED
[06:06] <Nafallo> pitti, carlos: then it might be good with those two translations to be synced automagically?
[06:07] <Nafallo> i.e. firefox and firefox :-P
[06:08] <pitti> this will - sort of - happen in the future
[06:08] <pef> elmo: hi
[06:08] <Nafallo> oki, kewl
[06:09] <pitti> mdz: so we'll have another breezygoals meeting tonight?
[06:11] <carlos> Nafallo, we are working now on that so it happens like with the other packages.
[06:11] <Nafallo> carlos: other packages?
[06:19] <ogra> hmm, amd64 buildd segfaults constantly, x86 seems completely gone now
[06:21] <infinity> ogra : Sheer luck.  Kamion's hunting the segv right now.
[06:21] <ogra> heh.... and hes standing on the x86 buildd to look into amd64 ?
[06:21] <ogra> s/hes/he's
[06:22] <Kamion> infinity: bingo. you owe me a pony.
[06:22] <ogra> heh
[06:22] <Kamion> Unpacking libglu1-mesa-dev (from .../libglu1-mesa-dev_6.2.1-5ubuntu5_powerpc.deb) ...
[06:22] <Kamion> Replaced by files in installed package x11proto-gl-dev ...
[06:23] <Kamion> straightforward uninitialised memory while copying the forward dependency chain during unpack
[06:24] <elmo> we should run a buildd under valgrind
[06:24] <Kamion> ironically, the segfault was triggered by a new debug message
[06:25] <Kamion> it would've been fine if the debug message hadn't been there, because everything else checked verrel != dvr_none before looking at version
[06:30] <infinity> Kamion : Your pony will be in the mail the moment a fixed dpkg builds.
[06:32] <infinity> Kamion : That also backs up my assertion that fixing the file overlaps between x11proto-gl-dev and libglu1-mesa-dev would have cleared it up, but I'm much happier to see the bug fixed.
[06:32] <Nafallo> infinity: you should have promised him a cow. those can be found in inflatable format :-).
[06:32] <Kamion> it was triggered by unversioned Replaces
[06:32] <Kamion> 'cos those never happen at all
[06:33] <infinity> Yeah, and that will be fixed in mesa/x11proto on my next upload.
[06:33] <infinity> Cause it looks very evil/wrong as it is now.
[06:33] <Kamion> probably only happened when hitting the new "don't break when installing a package that is replaced" code
[06:33] <infinity> Still, segv bad.  segv gone == good.
[06:33] <infinity> Kamion : Have you uploaded a fixed package already?
[06:34] <Kamion> just done
[06:34] <Kamion> well, doing
[06:34] <Kamion> wanna leave the mesa/x11proto uploads for a bit, just to make sure the problem goes away?
[06:35] <infinity> Kamion : Yup, I'm just fixing them up locally.
[06:35] <infinity> Kamion : They won't upload until tomorrowish.  I'll let the buildds chew on your changed dpkg overnight, with a mass give-back for good measure.
[06:35] <carlos> pitti, bad news, moz2po creates lots of .pot files, so we will need to hack the script a bit
[06:36] <carlos> like oo
[06:36] <pitti> carlos: just cat'ing them won't work?
[06:36] <carlos> pitti, to import them into Rosetta, yes
[06:36] <carlos> pitti, the problem is the return path
[06:37] <infinity> Hey, lookie there, the i385-amd64 biarch toolchain is finally done bootstrapping.
[06:37] <carlos> pitti, we don't know which messages come from which files
[06:37] <pitti> oh, po2moz needs split files, too?
[06:37] <infinity> Well, finally half done, anyway.
[06:37] <carlos> pitti, I think so 
[06:38] <pitti> carlos: can't you quickly convert ffox to gettext?
[06:39] <Amaranth> they don't use gettext?
[06:40] <carlos> pitti, :-P
[06:40] <carlos> pitti, don't think so ;-)
[06:41] <carlos> pitti, hmmm firefox needs also the original files to get the language pack rebuilt...
[06:42] <carlos> pitti, but it should not be a problem as the spec says that the same procedure applies to firefox
[06:43] <pitti> carlos: it should be possible to sort that out with msgmerge, I guess
[06:44] <pitti> carlos: i. e. generate the po files again and merge the relevant parts
[06:45] <carlos> pitti, hmm good idea
[06:45] <carlos> pitti, it's an easy and fast solution, yes
[06:45] <jdub> mdz: ping
[06:46] <carlos> pitti, I will play with the scripts a bit more and will dump my conclusions to the spec so you can review it tomorrow and see if it's doable on build time, ok?
[06:52] <mjg59> Hm. The ATIXP IDE driver has failed to bind to the IDE interface on this machine, and hence I am without DMA
[06:53] <mjg59> I think I need 2.6.12
[06:55] <aigarius> infinity, thank for the mail, eased my mind. I was getting a bit tense - considering today being the final deadline and such. OTOH it did help me write faster :)
[06:55] <Amaranth> wow i'm bored
[06:55] <Amaranth> i just did a search for 'doc' in synaptic, went through the entire list of results, and installed about 100 of them
[06:56] <jasoncohen> mvo, hi- so, update-notifier now has the ability to popup when an update is available? will you get a chance to allow it to differentiate between hoary-security/hoary-updates and backports?
[06:57] <pitti> jasoncohen: that was the idea
[06:57] <pitti> jasoncohen: I talked with mvo about this and we'll implement it that way
[06:57] <jasoncohen> great
[06:58] <jasoncohen> so the popup will only come up when it's security/bugfix or will it be an option?
[06:58] <pitti> I agreed to offer an option to disable it, mvo?
[06:59] <jasoncohen> yeah, does it have a close button so it can be easiy removed?
[07:00] <pitti> jasoncohen: by default these popups remove automatically after 7 seconds, but in any case they do when clicking on them
[07:00] <jasoncohen> ah, ok
[07:00] <jasoncohen> pitti, so, if the popup comes up when the user isn't at the computer, they'll never see it?
[07:01] <pitti> jasoncohen: I asked mvo to disable autotimeout for these security popups
[07:01] <jasoncohen> good
[07:01] <pitti> I think it makes sense in this case
[07:02] <jasoncohen> yeah, because update-notifier doesn't necessarily update the apt cache when you're at the computer so you might never see the updates. this way, you know the user sees the popup
[07:04] <mvo> pitti: I set the timeout to 60sec
[07:04] <pitti> mvo: maybe disabling it completely would be suitable in this case?
[07:04] <pitti> mvo: do you already offer to disable these?
[07:05] <mvo> it's easy enough to do (disable it). it can't currently distinguish between backports and other updates (because of limitations of python-apt)
[07:07] <paolo> note: on breezy the screensaver isn't "ubuntu-ed"
[07:07] <jasoncohen> mvo, are you speaking of disabling the timeout or the popups themselves?
[07:08] <mvo> jasoncohen: disabling the timeouts is very easy (but not done right now, only a big timeout is set). disabling the popups is implemented with a little blue action "Never show this message again"
[07:10] <jasoncohen> ok
[07:11] <mvo> isn't it already in the archive?
[07:12] <jasoncohen> don't know- i'm running hoary
[07:12] <mvo> I can add the needed support into pyton-apt, it's not too difficult, the problem is that today is feature freeze :)
[07:13] <jasoncohen> so, you would have to do it today? how strict are the deadlines?
[07:14] <mvo> yes, both the code for python-apt and update-notifier would have to be ready today (pretty much impossible). and I think we are pretty strict about deadline this time 
[07:14] <pef> bye !
[07:16] <jasoncohen> mvo, so, what can you get into breezy?
[07:17] <janimo> ping doko
[07:18] <mvo> jasoncohen: notifications are in (using libnotify), timeout can be removed without problem and "Never show this notification again" is in too. only the "show only security, but not backports" will not be ready
[07:18] <doko> janimo: pong
[07:18] <janimo> doko, pse didn't build I think it needs python-dev in BD
[07:18] <jasoncohen> mvo, well, the most important stuff is already in. 
[07:18] <janimo> spe
[07:18] <jasoncohen> mvo, i tried to contact you earlier but i didn't see you online
[07:19] <janimo> if it's in uni I can try fixing it
[07:20] <mvo> jasoncohen: well, we will get it for breezy+1 then 
[07:20] <doko> janimo: right, will fix it
[07:20] <jasoncohen> mvo, ok
[07:38] <mdz> morning
[07:38] <mdz> jdub: pong
[07:38] <mdz> pitti: hmm?
[07:39] <elvirolo> hi
[07:39] <jdub> mdz: don't remember, gotta run ;)
[07:39] <elvirolo> i was wondering about something...
[07:39] <mdz> seb128: yes, -updates uploads need manual approval, and I don't get any notification when they are waiting
[07:39] <pitti> mdz: ISTR that somebody told us "we will meet every week on Thursdays now", but I could be wrong
[07:39] <mdz> doko: updated avm modules = new upstream?
[07:40] <doko> mdz: yes, asked Kamion about it
[07:40] <pitti> mdz: Good morning :-)
[07:40] <pitti> mdz: now that we have libnotify in main, can I add notification-daemon to ubuntu-desktop seed?
[07:40] <seb128> mdz: hey mdz. Ok, next time I'll ping you on IRC when a package is waiting :)
[07:40] <doko> mdz: and fixed the pcmcia_cs linking
[07:40] <mdz> daniels: if there's a specific upgrade issue, send it to mvo for analysis
[07:40] <elvirolo> Ubuntu Hoary is way better than Kubuntu in means of integration and simplicity ... will Kubuntu Breezy try and develop its own configuration utilities, and, to a larger extent, deliver a more integrated environment ?
[07:41] <mdz> pitti: yes
[07:41] <mdz> doko: ok, sounds fine
[07:42] <mdz> doko: just don't break it ;-)
[07:42] <doko> mdz: you did approve dbus for hoary-updates in the bug report, but it's not yet accepted
[07:42] <doko> mdz: I'll let daniels do it if he updates the graphics stuff ;)
[07:43] <pitti> doko: well, dbus is in the accepted queue, but it doesn't build and doesn't go into the archive for some reason
[07:43] <infinity> pitti : ACCEPTED != INSTALLED.
[07:43] <doko> pitti: ouch, any way for me to look at the reason?
[07:43] <mdz> helena says these packages are waiting for approval:
[07:43] <mdz> glibc     | 2.3.2.ds1-20ubuntu14 | source | 1 month old
[07:43] <mdz> evolution | 2.2.1.1-0ubuntu4.1   | source | 3 weeks old
[07:43] <mdz> dbus      | 0.23.4-0ubuntu4      | source | 2 weeks old
[07:43] <mdz> kdelibs   | 4:3.4.0-0ubuntu3.4   | source | 2 days old
[07:44] <mdz> I remember approving glibc, dbus and kdelibs
[07:44] <seb128> you can drop the evolution one
[07:44] <mdz> I remember it now that I read .changes
[07:44] <seb128> pitti put the fix with today's upload
[07:44] <mdz>    * debian/patches/05_bugzilla.patch:
[07:44] <mdz>      - use the GNOME bugzilla to send bugs (Ubuntu: #12475).
[07:44] <mdz> is that no longer important?
[07:44] <pitti> mdz, seb128: I asked elmo to drop evolutio
[07:44] <pitti> mdz: I included it into today's security update, it's a trivial one-line change in .desktop
[07:45] <mdz> ah, ok
[07:45] <mdz> I approved the rest
[07:45] <mvo> mdz: a quick question about launchpad integration. do we want it for synaptic too? it means that the started ff (launched from the menu) is run as root
[07:46] <pitti> mdz: so you have to manually approve -updates uploads? I uploaded evolution to warty-updates to fix that version, too, and it went straight in
[07:46] <mdz> mvo: hmm, that's awkward
[07:46] <pitti> infinity: is the i386 buildd still busy? awstats | 6.3-1ubuntu0.1 | source | 1 hour old
[07:46] <mdz> mvo: can we enhance libl-i to drop privileges before launching the browser?
[07:46] <mdz> pitti: yes
[07:46] <mdz> pitti: when was that?
[07:47] <infinity> pitti : You'll get them back shortly. :)
[07:47] <mvo> mdz: I can certainly do that (if that's ok with seb128)
[07:47] <pitti> mdz: this morning, maybe 9 hours ago
[07:48] <mvo> seb128: is there a baz archive for liblaunchpad?
[07:48] <sm> hi all. bugzilla, forums, wiki, lists, #ubuntu all come up dry.. if anyone knows why a minority of hoary users can't get cupsd to respond to web browser or gnome-cups-manager, I would appreciate any clue
[07:48] <pitti> mdz: it appeared on warty-changes and everything
[07:48] <mdz> pitti: interesting; maybe approval is only set up for hoary?
[07:48] <elmo> nice
[07:48] <elmo> oo2, oo2-l10n, gcc-3.4, gcc-4.0 and glibc
[07:48] <elmo> concurrently
[07:48] <pitti> mdz: the difference apparently is that there already was an -updates version of evolution, but not for the packages in your helena
[07:48] <infinity> elmo : Yeah, "ouch". :)
[07:48] <mdz> sm: the web interface is intentionally disabled; gnome-cups-manager should work though
[07:49] <pitti> elmo: OMG, no wonder that I don't get a trivial arch-all perl package built...
[07:49] <sm> not for me
[07:49] <elmo> that's pretty much your worst case stress test scenario
[07:49] <sm> I had to replace Listen with Port in cupsd.conf to get it to start up, but still not responding
[07:49] <elmo> quick, someone upload xorg and a new kernel, and it'll be complete
[07:49] <mdz>   ubuntu-desktop: Depends: gnome-app-install but it is not going to be installedE: Broken packages
[07:49] <mdz> who broke it?
[07:49] <pitti> elmo: 200 langpacks in addition maybe?
[07:50] <elmo> pitti: langpacks are trivial for a buildd, even in bulk
[07:51] <robitaille> mdz: face that problem a few minute ago...had to do "apt-get install gnome-app-install-data" to get things properly installed
[07:51] <robitaille> s/face/faced
[07:51] <mdz> robitaille: that won't fix this problem
[07:51] <seb128> mvo: jamesh@ubuntu.com/launchpad-integration--devel--0
[07:51] <mdz>   python2.4-gnome2-extras: Depends: libwnck17 (>= 2.11.4) but it is not installable
[07:53] <mdz> mvo: please fix python-gnome2-extras
[07:53] <seb128> mdz: the buildd needs a retry
[07:53] <seb128> mdz: 
[07:53] <seb128> The following packages have unmet dependencies:
[07:53] <seb128>   libgksu1.2-dev: Depends: libgksu1.2-0 (= 1.3.1-1ubuntu1) but it is not going to be installed
[07:53] <seb128>   libgksuui1.0-dev: Depends: libgksuui1.0-0 (= 1.0.5-1ubuntu1) but it is not going to be installed
[07:53] <seb128> edd: Broken packages
[07:53] <seb128> 
[07:53] <seb128> according to the i386 build log
[07:53] <robitaille> mdz: humm...worked for me maybe 30 mins ago.  but didn't look into it in detail.
[07:53] <seb128> infinity: please give a retry to python-gnome2-extras build
[07:54] <infinity> seb128 : Will do when I get a buildd back.
[07:54] <mdz> yeah, those seem tob e intsallable now
[07:54] <infinity> (Or I could kill OOo2... <cough>)
[07:54] <mdz> I don't see a python-gnome2-extras upload on -changes
[07:54] <mdz> was it yesterday?
[07:55] <doko> infinity: Mithrandir will kill you ... he's waiting for it to build the amd64 package
[07:55] <infinity> Could have been.  Between biarch bootstrapping and dpkg segvs, the buildds have been unhappy.
[07:56] <seb128> mdz: 2 days ago I think
[07:56] <daniels> Kamion: no, we're just taking random stupid stabs in the dark
[07:56] <seb128> mdz: the package is gnome-python-extras
[07:57] <mdz> seb128: yeah, if it were 2 days ago I already read it and forgot about it ;-)
[07:57] <daniels> Kamion: thanks for finding the segfault, you rock
[07:58] <daniels> Kamion: your pony will arrive in the morrow
[07:58] <mdz> there was a window yesterday where the desktop was actually installable, and I missed it due to livefs build script breakage, grr
[07:59] <Kamion> mdz: I believe all the installability fixes are in progress; the dpkg segfault totally snarled up the buildds
[07:59] <infinity> mdz : No worries, I'll babysit that build and retry the livefs build as soon as it goes through.
[08:00] <infinity> I've been up/working too long to do anything that requires actual though anyway, and I have to sit up and babysit this biarch build, so it's not like I have anything better to do. :)
[08:00] <mdz> Kamion: dpkg segfault?
[08:00] <mdz> I missed that one
[08:01] <infinity> For the last month or more, builds have been breaking horribly and chroots getting broken due to dpkg segfaulting while isntalling gl/glu-related packages.
[08:01] <infinity> Turned out that dpkg segfaulted on an unversioned reverse-replaces corner case.  Kamion just uploaded a fix.
[08:02] <infinity> (reverse replaces, as in unpacking the replaced package after the replacing package)
[08:05] <pitti> infinity: uh, do we need to fix that in hoary, too?
[08:05] <infinity> "need"?  Dunno.  But we probably should.
[08:06] <infinity> It could make upgrades a bit sketchy.
[08:07] <pvanhoof> aspell-nl: Depends: libaspell15c2 (> 0.60) but it is not going to be installed
[08:07] <pvanhoof> yet libaspell15c2 is installed
[08:07] <doko> pvanhoof: yes, known issue
[08:07] <pitti> odd, I just got the same
[08:07] <pvanhoof> doko, can I fix it?
[08:08] <pvanhoof> temporarily
[08:08] <doko> pvanhoof: ah, a workaround? don't know
[08:12] <pvanhoof>  dpkg -i aspell-nl_0.1e-30_i386.deb
[08:15] <jasoncohen> mvo, when will we see the changes outlined in https://wiki.ubuntu.com/PackageDependencyManagement. i was told they're not going into breezy
[08:16] <mvo> jasoncohen: there is a bazaar apt branch that adds the needed support to apt. if you are curious, you can check it out and test it. it works pretty well for me, but it needs more real-life user testing
[08:16] <mvo> (apt--auto-mark--0 from my baz archive)
[08:16] <infinity> Is there a sane and rational explanation for why we appear to build openoffice.org2 twice, with two different source packages?
[08:17] <pitti> infinity: once for code, and once for language packs
[08:17] <jasoncohen> mvo, but it won't make it into breezy because of lack of testing?
[08:18] <infinity> pitti : It appears that the langpack build also builds the code too, that's why I was asking.
[08:18] <pitti> infinity: maybe doko can teach it to not build everything in vain?
[08:18] <mvo> jasoncohen: unfortunately yes. it's a feature that basicly affects every user and every package managment operation so we need to be carefull with it 
[08:20] <mvo> jasoncohen: I plan to make test packages available after the freeze for people that are curious 
[08:20] <jasoncohen> mvo, ok, sounds good
[08:20] <pvanhoof> doko, is somebody working on the aspell_nl issue?
[08:21] <pvanhoof> I can forcefully install the current package, but it's not enabled the dutch language :-(
[08:21] <doko> infinity: technically, you could try to uncouple the build system not to build code again, but it's currently not supported upstream. I think, that's the reason we do have compiler caches ;-)
[08:21] <pvanhoof> s/enabled/enabling
[08:21] <pvanhoof> regretfulyl I have no idea how aspell is to be configured
[08:22] <doko> pvanhoof: correct, a fix requires updating the package, it's on my list. see the aspell changelog for the changes which must be made
[08:22] <pvanhoof> ok
[08:23] <pvanhoof> of this one? aspell-nl_0.1e-35ubuntu1_i386.deb
[08:24] <infinity> doko : If the -l10n build ends up building all the code again anyway, then why have two source packages at all?
[08:25] <infinity> doko : Is it not feasible to build all the binaries and langpacks from the same sourcde?
[08:26] <doko> infinity: we do want to update the langpacks after the breezy release, without modifying the binaries
[08:26] <infinity> Ahh, but isn't that supposed to be done out-of-band via rosetta and langpacks?
[08:26] <infinity> (I guess that's a "down the road" thing, though)
[08:27] <doko> yes, but currently, there are no source packages for langpacks, IIRC.
[08:30] <mdz> pitti: dpkg in hoary didn't support that at all
[08:30] <mdz> pitti: we talked about it in the context of langpack replaces
[08:30] <infinity> Oh, good point.  That dpkg bug wasn't fixed until breezy (thus introducing the degv)
[08:30] <infinity> s/degv/segv/
[08:32] <pvanhoof>  cp /usr/lib/aspell-0.60/* /usr/lib/aspell/
[08:32] <pvanhoof> temporary fix, doko
[08:33] <Frafra> hi all
[08:33] <Frafra> in the currents build
[08:33] <Frafra> can i install nvidia proprietary drivers?
[08:33] <Frafra> i've read that in colony 3 will be supported
[08:34] <pvanhoof> doko, dictdir = $(libdir)/aspell-0.60 in the Makefile.am will install the dictionary files of aspell-nl in /usr/lib/aspell-0.60
[08:34] <pvanhoof> whereas all of them are simply in /usr/lib/aspell/
[08:34] <pvanhoof> oh and ..
[08:34] <pvanhoof> I'd do something like $(libdir)/aspell-$(VERSION)
[08:35] <pvanhoof> and I'd use targetdata = nl.multi nederlands.multi etcetera
[08:35] <pvanhoof> and targetdir = $(libdir)/aspell-$(VERSION)
[08:36] <pvanhoof> rather than this piece of junk Makefile.am
[08:36] <pvanhoof> it's asking for problems
[08:36] <pvanhoof> I guess that's an upstream problem ..
[08:37] <pvanhoof> it's even using "ln" which isn't platform neutral
[08:55] <pitti> mdz: IIRC Keybuk did a last minute fix to support Replaces properly?
[08:55] <mdz> pitti: oh, you may be right
[08:56] <pitti> mdz: http://changelogs.ubuntu.com/changelogs/pool/main/d/dpkg/dpkg_1.10.27ubuntu1/changelog
[08:56] <pitti> mdz: we did that because of the langpacks, it broke the preview, remember? :-)
[08:56] <mdz> it went into 1.10.27ubuntu1 and 1.13.2
[08:57] <mdz> pitti: send mail to Keybuk about it for when he returns
[08:57] <pitti> yes
[08:59] <madduck> doko: coming to #pkg-zope?
[09:11] <doko> carlos, pitti: updated RosettaFirefoxAndOpenOfficeSupport
[09:14] <mdz> doko: will the ooo2 binaries be uninstallable or anything if we kill the ooo2-l10n build?
[09:14] <doko> no, just some missing translations for the binary filters, not that important
[09:15] <doko> mdz: ^^^
[09:18] <mdz> the parallel ooo2/ooo2-l10n builds are blocking all the uninstallability fixes for the desktop
[09:22] <doko> no, just kill it, but keep the ooo2 build. Mithrandir needs the binaries for the amd64 package
[09:23] <infinity> Not going to bother killing it, it's almost done anyway. :/
[09:23] <infinity> If you had said "just kill it" 3 hours ago, I would have happily done so.
[09:28] <mdz> I was unconscious 3 hours ago
[09:28] <mdz> and dreaming of waking up to fresh livefs builds ;-)
[09:28] <infinity> Odd dreams.
[09:43] <infinity> Oh, that's right.  hal is actually FTBFS on amd64 without dpkg's help.
[09:43] <infinity> Bother.
[09:43] <infinity> Does anyone for whom it's not 6am in their timezone want to look into it?
[09:44] <pitti> infinity: ok
[09:45] <infinity> pitti ; http://people.ubuntu.com/~lamont/buildLogs/h/hal/0.5.3-0ubuntu2/hal_0.5.3-0ubuntu2_20050811-1154-amd64-failed.gz
[09:45] <pitti> infinity: "E: Sub-processdpkg-deb: subprocess paste killed by signal (Broken pipe)"
[09:45] <pitti> infinity: that doesn't look like a normal error...
[09:45] <infinity> pitti : Try the log above it (or the one below it when it rolls in)
[09:46] <pitti> checking for BLKGETSIZE64... no
[09:46] <pitti> configure: error: BLKGETSIZE64 is not defined
[09:46] <pitti> WTF is that???
[09:46] <infinity> That's the one.
[09:46] <infinity> WTF indeed.
[09:46] <pitti> *sigh*, booting to amd64, brb
[09:50] <infinity> pitti : You could always try blaming jbailey.
[09:50] <pitti> infinity: will it help?
[09:51] <infinity> pitti : BLKGETSIZE64 is an LFS64 ioctl whicn, on amd64, should probably be an lias for BLKGETSIZE, so maybe it's a linux-kernel-headers bug..
[09:52] <pitti> great to see that I'm supposed to fix things I don't understand :-)
[09:58] <ogra> /usr/bin/libtool: line 6545: exec: dbus-binding-tool: not found
[09:58] <ogra> GRRRR
[09:59] <ogra> why dont we build that ? dbus-binding-tool seems nonexistent
[09:59] <mdz> ogra: context?
[09:59] <ogra> gnome-power
[09:59] <pitti> infinity: no, it's one of these damn compiler "features":
[09:59] <pitti> /usr/include/asm-x86_64/types.h:23: error: conflicting types for 'int64_t'
[09:59] <pitti> /usr/include/sys/types.h:194: error: previous declaration of 'int64_t' was here
[10:00] <ogra> it took me ages to get all bits and pieces togehter to have the build-deps fulfilled... and now that... :(
[10:00] <seb128> ogra: sudo apt-get install dbus-utils
[10:00] <ogra> seb128, nope
[10:00] <seb128> how so "nope"?
[10:00] <ogra> at least thas not what dpkg --contents shows me
[10:01] <seb128> I've fixed this morning
[10:01] <seb128> what arch?
[10:01] <ogra> dbus-1-utils_0.35.2-0ubuntu2 ?
[10:01] <seb128> 0.35.2-0ubuntu3 has it
[10:02] <ogra> the buildd for x86 hasnt build since 15:00 GMT
[10:02] <seb128> thanks OO.o2
[10:02] <ogra> heh
[10:02] <seb128> dbus_0.35.2-0ubuntu3_20050811-1302-i386-successful.gz
[10:02] <ogra> i was worried it was mediawiki ;) it was the last one that builzt
[10:02] <seb128> Filename: pool/main/d/dbus/dbus-1-utils_0.35.2-0ubuntu3_i386.deb
[10:02] <ogra> strange
[10:02] <seb128> change your mirror
[10:03] <ogra> yup... just saw it... its not on de. yet
[10:03] <ogra> (i normally dont compile on that machine... but amd64 is to borked currently)
[10:10] <infinity> pitti : Looks like jbailey's fault to me.
[10:10] <paolo> what's the correct way to get java on breezy?
[10:10] <infinity> pitti : That first declaration is linux-kernel-headers, the second is libc6-dev, either way it's his breakage. :)
[10:10] <pitti> infinity: not necessarily, gimme some minutes
[10:10] <pitti> infinity: I'm digging into it
[10:11] <infinity> pitti : Although, conflicting types for int64_t sounds pretty painfully wrong.
[10:12] <pitti> infinity: in fact hal seems to screw up this on its own
[10:12] <pitti> ./config.h:#define __s64 int64_t
[10:12] <pitti> ^ __s64 is defined in l-k-h
[10:12] <pitti> and hal aliases it _and_ includes types.h
[10:12] <infinity> Fancy.
[10:13] <pitti> *grumpf*
[10:13] <infinity> Go hal.
[10:14] <pitti> it uses AC_CHECK_TYPE, and if that fails, it defines it on its own
[10:15] <mdz> pitti: is the new hal blocking desktop installability?
[10:15] <infinity> mdz : Yes.
[10:15] <mdz> gar
[10:15] <infinity> mdz : Only on amd64.  Due to this bug we were just discussing.
[10:15] <mdz> what's above it in the chain?
[10:16] <pitti> infinity: why doesn't amd64 use 0.5.2 then?
[10:16] <infinity> pitti : Depends on packages that no longer exist.
[10:16] <infinity> Or some such.
[10:16] <infinity> Or, rather, something else that is uninstallible is waiting on the new hal before it can build.  Or something.
[10:17] <infinity> It all made sense to me 30 minutes ago when I discovered hal was the bottleneck.
[10:18] <JanC> wtf, last kernel/initrd tries to use a non-existing volume group "hda6" instead of my /dev/hda6 partition ?
[10:18] <infinity> Funny, jbailey was just bragging about how he'd had no complaints about initramfs yet.
[10:19] <seb128> pitti: grah, g-v-m crashed again on update ... we should stop restarting dbus 
[10:19] <mdz> infinity: yeah, when it wasn't the default yet
[10:19] <mdz> and therefore about 5 people were using it
[10:19] <infinity> mdz : Nah, just 30 minutes ago, from whatever airport he was in, he'd mentioned his surprise at the lack of fallout from the switch. :)
[10:20] <mdz> it only landed yesterday; most of the world didn't upgrade until today
[10:20] <mdz> and still more haven't rebooted yet
[10:21] <mdz> amd64 is blocked by gnome-applets and gnome-app-install
[10:21] <infinity> I rebooted pretty well instantly, out of fear that I'd have to get involved in some messy recovery.
[10:21] <mdz> (at top level)
[10:21] <infinity> And, oddly, I didn't.
[10:22] <mdz> gnome-app-install I traced earlier to python-gnome2-extras, which just needed to be built
[10:22] <infinity> mdz : Yup, I tracked that one down, too.
[10:22] <infinity> The other direction is the hal problem.
[10:22] <mdz> it doesn't seem to have a recent attempt
[10:22] <mdz> http://people.ubuntu.com/~lamont/buildLogs/g/gnome-python-extras/2.11.4-0ubuntu2/
[10:23] <mdz> the last one was a dpkg segfault

[10:23] <infinity> Requeued already.
[10:30] <mvo> mdz: I have a apt upload pending (send you a mail about it some days ago, a small bugfix in the dpkg<->apt communication). can I do that now is it inconvenient now (because of the buildd situation)?
[10:31] <infinity> The buildd situation isn't much of a situation.  i386 will normalise in a few hours and it'll be like nothing happened.
[10:32] <infinity> (Until I wake up tomorrow and do a mass give-back to catch everything that may have been screwed by the dpkg segv...)
[10:33] <infinity> Right, that's why I need the new hal built.
[10:33] <mdz> mvo: gnome-app-install-data just failed to install on amd64 for me
[10:33] <mvo> mdz: yes, the fix is uploaded but not yet build
[10:34] <mvo> mdz: it fails only on a upgrade, right? not for a new install
[10:34] <infinity> mdz, pitti : The old hal refers to libdbus-1.la, so building against it fails, the new hal will be built against the new dbus and fix that.  gnome-python-extras won't build until we have it.
[10:34] <mdz> dpkg: error processing /var/cache/apt/archives/gnome-app-install-data_0+20050809_all.deb (--unpack):
[10:34] <mdz>  trying to overwrite `/usr/share/gnome-app-install/Mozilla.desktop', which is also in package gnome-app-install
[10:34] <mdz> dpkg-deb: subprocess paste killed by signal (Broken pipe)
[10:34] <mdz> mvo: ok
[10:35] <mvo> mdz: ok for g-a-i or ok for the apt upload? 
[10:35] <mdz> mvo: g-a-i
[10:36] <mdz> mvo: I cannot deal with apt or anything else until this situation is fixed
[10:37] <mdz> our priority at the moment is working CDs
[10:37] <{Seb}> i've got a few niggles with breezy and i don't know if they are known bugs
[10:38] <{Seb}> first - i had to remove /usr/bin/X11 and symlink it to /usr/bin to get X to start
[10:38] <mdz> pitti: I'm getting my amd64 upgraded so that I can look at hal; have you had any luck with it?
[10:38] <pitti> mdz: I'm on it
[10:38] <pitti> mdz: but its a bit tricky
[10:38] <mdz> what the hell
[10:38] <{Seb}> second - gnome-app-install is broken
[10:38] <mdz> locales is generating EVERY locale
[10:38] <pitti> needs some time, but I'll solve it
[10:39] <{Seb}> and i had to force install gnome-app-install-data
[10:39] <{Seb}> are these known bugs or should i file them in bugzilla?
[10:39] <mvo> mdz: well, the upload is ready. but if you want to have a look first it can certainly wait. it contains only small (but importent) fixes
[10:39] <mvo> {Seb}: it's a known bug, the fix is uploaded but not yet in the archive
[10:39] <{Seb}> which ones?
[10:39] <mdz> {Seb}: gnome-app-install is known; it has already been discussed here several times today
[10:39] <mdz> {Seb}: for X, search bugzilla and report only if it is not there already
[10:40] <{Seb}> also, my scroll wheel won't work
[10:40] <{Seb}> i'll search
[10:40] <{Seb}> breezy is look absoutly great
[10:40] <ogra> pitti, something about BLKGETSIZE64 ?
[10:40] <mdz> infinity: what's broken on the gnome-applets size?
[10:40] <pitti> ogra: no, something entirely different, it just appears to be so
[10:40] <mdz> s/size/side/
[10:40] <pitti> YAY, hal builds!!!
[10:40] <ogra> hooray...
[10:41] <pitti> with a 178 KB patch..
[10:41] <pitti> anyway, I'll throw it at the buildds to have something working, and I'll sort that out with upstream to find the real solution
[10:42] <mdz> pitti: 178kb?
[10:42] <pitti> mdz: upstream does weird things with datatypes, so I needed a find/sed to replace them all
[10:42] <pitti> mdz: and I need to regenerate configure
[10:42] <mdz> so 8k search/replace, 170k configure ;-)
[10:43] <pitti> mdz: no, about 120 KB search/replace
[10:43] <infinity> mdz : Out of date, waiting on new hal.
[10:43] <mdz> wow
[10:43] <infinity> mdz : So, both paths lead to hal.
[10:43] <pitti> mdz: it's not a good patch, and not the final one, but I'll test it on some arches now and upload to have a quick solutuon
[10:43] <mdz> pitti: ok
[10:46] <pitti> wow, hal even works
[11:00] <pitti> mdz, infinity: hal_0.5.3-0ubuntu3_source.changes ACCEPTED
[11:00] <mdz> pitti: good timing for :03
[11:00] <pitti> hehe :)
[11:04] <pitti> awstats   | 6.3-1ubuntu0.1     | source               | 4 hours old
[11:05] <mdz> pitti: is the firewall stuff landing or no?
[11:05] <mdz> I need to know whether I need to implement the contingency for ltsp
[11:06] <pitti> mdz: I asked carstenh about useful subsets, but most certainly not
[11:06] <mdz> damn
[11:06] <pitti> mdz: he doesn't even have packages yet
[11:06] <ogra> SoC started way to late
[11:06] <infinity> i386 buildds are coming back. One's here.
[11:06] <mdz> pitti: please set it to deferred
[11:06] <pitti> so not until tomorrow, but even this wouldn't yield much useful
[11:06] <pitti> mdz: ok
[11:07] <mdz> infinity: is hal building?
[11:07] <infinity> Still not registered in wanna-build.  Give cron.daily some breathing room.
[11:07] <pitti> mdz: oh, it's not even in the table yet
[11:08] <mdz> pitti: add it to the deferred table
[11:08] <mdz> seb128: how is launchpadintegration?
[11:09] <seb128> mdz: ~25/30 apps patched 
[11:10] <mdz> seb128: is there a list somewhere?
[11:10] <seb128> I'll update the wiki
[11:10] <seb128> a min
[11:11] <doko> one ooo2 build did finish ...
[11:11] <mdz> mvo: findingpackages is bust, I guess?
[11:12] <infinity> Oh, hey php4 finally got shoved to universe.
[11:12] <pitti>       php4 | 4:4.3.10-15ubuntu2 | http://archive.ubuntu.com breezy/universe Packages
[11:12] <pitti>       php4 | 4:4.3.10-15ubuntu2 | http://archive.ubuntu.com breezy/main Sources
[11:12] <pitti> well, almost...
[11:12] <mdz> Someone else saved this page while you were editing! Please review the page and save then. Do not save this page as it is! Have a look at the diff of BreezyGoals to see what has been changed. 
[11:12] <infinity> mdz : Can I sync php4 with Debian, and upload php-imap (which builds php4-imap and php5-imap) to universe?
[11:12] <mdz> who ignored my lock?
[11:12] <pitti> mdz: I just added Firewalls, but I didn't get a lock...
[11:13] <infinity> pitti : The binries all got shoved to universe...
[11:13] <mvo> mdz: FindingPackages gnome-app-install is in, but nautilus/mozilla integration is not done yet
[11:13] <mdz> pitti: I made several edits, so I'm clobbering your changes
[11:13] <pitti> mdz: I was told that I had the lock, sorry
[11:13] <infinity> pitti : Not sure why the source didn't move.
[11:14] <pitti> mdz: I fix it
[11:14] <mdz> pitti: thanks
[11:15] <mdz> infinity: packages moving between components is an entirely manual process
[11:15] <mdz> infinity: send me email with the details
[11:16] <mdz> (re: php)
[11:16] <pitti> mdz: odd, how can this happen? race condition?
[11:16] <seb128> mdz: https://wiki.ubuntu.com/LaunchpadIntegration
[11:16] <ogra> infinity, btw, edubuntu has only hp5 deps let, i git them all sorted, so php4 could go completely to universe
[11:16] <ogra> s/hp5/php5
[11:17] <mdz> pitti: it is easy to overlook the message; are you sure it did not warn you?
[11:17] <ogra> s/let/lefzt
[11:17] <ogra> grmpf
[11:17] <ajmitch> morning
[11:17] <infinity> ogra : Excellent.  If edubuntu needs any php5 extensions we don't have packaged, you need to let me know, and ask mdz for permission to let me upload them. :)
[11:18] <pitti> mdz: I remember having read the usual "you have locked 10 minutes" sign, but given my current mental state I could be wrong; nevermind for now
[11:19] <Kamion> mdz: the dpkg segfault does appear to be present in hoary too, looking at the code
[11:19] <ogra> infinity, oki... but i'm fine for now...
[11:20] <Kamion> mdz: however, it really is quite a corner case, so I'm not that worried about it; we only ran into it because of very odd packaging
[11:20] <pitti> Kamion: so it won't break the usual langpack use case?
[11:20] <Kamion> mdz: you need to have something doing an unversioned Replaces on a package that's still active in the distribution, which is not a usual thing to do
[11:21] <Kamion> pitti: hmm
[11:21] <Kamion> you do have an unversioned Replaces there ...
[11:21] <pitti> Kamion: I guess if the fix is easy we should update, but it's not super urgent, right?
[11:21] <pitti> Kamion: I can't update langpacks before rosetta export is working anyway
[11:21] <seb128> mdz: gnome-python-extras build failed again ... nautilus-cd-burner 0ubuntu2 needs to be built first and then gnome-python-extras
[11:21] <infinity> seb128 : On it already, don't worry.
[11:22] <seb128> mdz: due to dbus.la changes 
[11:22] <seb128> daniels insisted to drop them
[11:22] <Kamion> pitti: now you mention it, it looks to me as if it ought to break, but then I'm amazed it hasn't broken lots already
[11:22] <pitti> Kamion: we didn't actually update hoary langpacks yet (ENOROSETTA)
[11:23] <Kamion> pitti: yes, but that dpkg change happened some time before release
[11:23] <Kamion> and before the last language pack upload for hoary
[11:23] <Kamion> so, if it were going to happen I'd've thought we'd see it then
[11:23] <Kamion> perhaps the circular Depends and bidirectional Replaces manage to insulate us from it
[11:24] <Kamion> the fix is trivial, anyway, and I can probably prove that it doesn't break anything that wasn't already broken ;)
[11:25] <pitti> sounds like a "5 free minutes to fix it" case for hoary-updates, then?
[11:26] <pitti> haha, SuSE replaces mozilla in all stable releases to 1.7...
[11:27] <infinity> Vindication!
[11:28] <Kamion> pitti: probably, if the stress-test-by-buildd goes well
[11:28] <_d4vid> hi all
[11:31] <doko> Mithrandir: -10 is built on i386
[11:35] <pitti> infinity, mdz: hal built on amd64
[11:36] <infinity> pitti : I know, I've been babysitting it.
[11:42] <infinity> Argh, I hate my laptop crashing every day.
[11:47] <pitti> mdz: btw, I tried to get the ffox crash on i386 by incrementally upgrading everything to the latest version, no luck
[11:47] <Kamion> mdz: I assume removing l-r-m-2.6.10 from breezy is fine?
[11:54] <pitti> night everybody!
[11:55] <paolo> Goodnight pitti
[11:58] <doko> Kamion: something wrong with the new lrm upload?