[00:00] <Seveas> keisangi, this channel is for development *of* ubuntu, not *on* ubuntu
[00:00] <keisangi> i tryed other distro, like zenwalk-linux (slackware based distro) and everything seems works
[00:01] <keisangi> Seveas, yes, but i wont get any help on #ubuntu channel about this particular problem ..
[00:01] <Seveas> keisangi, that doesn't make this a support channel
[00:01] <keisangi> i don't know where to ask
[00:02] <Seveas> !support | keisangi
[00:02] <ubotu> keisangi: the official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
[00:02] <keisangi> Seveas, ok, could you point me to a support channel where i could discuss eclipse , java and ubuntu ?
[00:02] <Seveas> #eclipse and #ubuntu come to mind :)
[00:02] <keisangi> they will tell me to go to #lwjgl
[00:03] <keisangi> #Eclipse will tell me to see with #ubuntu
[00:03] <keisangi> everyone try to dodge the stinky problem ;)
[00:03] <Seveas> well, #ubuntu it is then :)
[00:04] <keisangi> i said two line earlier that #ubuntu ppl are likely to tell me to go to #lwjgl or #eclipse
[00:04] <crimsun> (there's #ubuntu-java)
[00:04] <keisangi> crimsun, ah nice
[00:04] <keisangi> i try this one
[00:04] <keisangi> thanks
[00:04] <jdong> crimsun: ooh you appeared! Could I bug you to sponsor another new transmission?
[00:05] <crimsun> url?
[00:05] <jdong> bug #185292,
[00:05] <ubotu> Launchpad bug 185292 in transmission "Please update to 1.02" [Wishlist,Confirmed] https://launchpad.net/bugs/185292
[00:11] <crimsun> jdong: ACKed.
[00:13] <jdong> crimsun: thanks :)
[00:14] <BlackDiamonds> if it's in main, it's supported by offical devs right ?
[00:14] <jdong> what are "official devs"?
[00:15] <BlackDiamonds> people with an @ubuntu.com address
[00:15] <jdong> All Ubuntu members have an @ubuntu.com address; developers are a small subset of this group
[00:16] <BlackDiamonds> oh what ?
[00:16] <BlackDiamonds> what is an ubuntu member then ?
[00:16] <jdong> BlackDiamonds: http://www.ubuntu.com/community/ubuntustory/components should answer your question about main vs universe
[00:17] <jdong> And http://www.ubuntu.com/community/processes/ about members, developers, etc
[00:30] <lamby> Why is the ubuntu-devel mailing list moderated?
[00:31] <elmo> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
[00:36] <lamby> Well, that does not help to explain why my post was discarded, dispite it seeming to match the criteria.
[00:37] <lamby> I will repost to -discuss.
[00:38] <LaserJock> lamby: I doubt it was discarded, probably just stuck in the moderation queue
[00:39] <lamby> I will repost anyway, I don't have the time to watch the archives to see whether it's accepted or not.
[00:41] <LaserJock> that reminds me ...
[00:42]  * LaserJock wanders off to look at the latest fun on -discuss
[00:59] <nxvl_work> does the Developer Sprint is taking place?
[00:59] <nxvl_work> or this development circle there was no one?
[03:56] <yo> can someone help me with ver 7.1?
[04:00] <jdong> Can someone confirm/explain why sudo seems to forget environment variables?
[05:19] <gQuigs> can I confirm my own needs-packaging bug (185804) or does it need something else?
[05:20] <gQuigs> https://bugs.launchpad.net/ubuntu/+bug/185804
[05:20] <ubotu> Launchpad bug 185804 in ubuntu "[needs-packaging] BadRAM Linux Kernel Patch" [Undecided,New]
[05:28] <ScottK2> gQuigs: Packaging questions in #ubuntu-motu
[05:29] <gQuigs> oh..oops
[08:47] <pitti> Good morning
[08:50] <gaspa> 'morning -.-
[08:50] <pitti> \sh_away: that looks like a gnome-vfs message, not sure where it comes from; maybe check with seb128?
[09:25] <\sh> seb128, the problem from yesterday was a result of nautilius -> preferences -> media_automount_open = True (gconf setting) this happens with all devices which are just mounted but not handled as special devices...
[09:26] <seb128> you told me that this key was set to wrong yesterday?
[09:27] <pitti> mathiaz: your patch in bug 52866 looks ok; can you please upload?
[09:27] <ubotu> Launchpad bug 52866 in php5 "SOAP response for associative array is different on ubuntu 6.06" [Undecided,In progress] https://launchpad.net/bugs/52866
[09:27] <\sh> seb128, nope...I never said this...I was thinking something strange happens...and I tracked it down to this setting...set this key to False everything is fine...and only the symbols are on the desktop (despite the fact that some of them are staying on the desktop after unmount)
[09:28] <seb128> I told you to change the key in the preferences and you said you already did that and that didn't change anything
[09:29] <\sh> seb128, this was the setting in System -> Preferences -> Removable Media which I disabled...but this didn't help...I think the preferences dialog comes from gnome-volume-manager or whatever we use, but not from nautilus
[09:30] <\sh> seb128, the real solution is to set the nautilus gconf key to false...
[09:31] <lool> slomo: Thanks!
[09:32] <\sh> seb128, as far as I could track down the problem (reading gnome-volume-manager source and nautilus-application.c) those two are involved when mounting devices. gvm handles special devices like usb/ipod/cd/dvds but not e.g. /dev/sdb3 when it's mounted manually...
[09:33] <seb128> \sh: the key you describe is the one I told you to change yesterday
[09:33] <seb128> \sh: it's the browse media when inserted in the nautilus preferences, media tab dialog
[09:34] <seb128> \sh: I just verified it does change the gconf key
[09:34] <\sh> seb128, well then I didn't understand you correctly...I meant the global preferences for media
[09:34] <seb128> alright
[09:35] <seb128> but I wrote that it was the nautilus dialog
[09:36] <\sh> seb128, then I didn't see "nautilus" ... after so many windows popping up
[10:02] <pitti> dholbach: Alter!
[10:03] <dholbach> pitti: ALTER!
[10:03] <pitti> dholbach: do you know what p-lp-bugs does when a bug has multiple source packages?
[10:03] <pitti> dholbach: i. e. bug.sourcepackage
[10:04] <dholbach> pitti: I find it more accurate to look at all bug tasks and see what their bug status, source packages, etc are
[10:04] <dholbach> pitti: bug.infotable
[10:04] <pitti> dholbach: right; can I iterate over all of them?
[10:04] <pitti> aah
[10:04] <dholbach> pitti: for task in bug.infotable
[10:04] <pitti> rock'nroll
[10:05] <dholbach> pitti: you can branch http://people.ubuntu.com/~dholbach/sponsoring/ for an example
[10:05] <pitti> cool, looking at it right now
[10:35] <pitti> dholbach: rock, it works, I just wrote a pitti-o-matic-sync-bug-bitch script
[10:40] <dholbach> pitti: party on
[10:41] <emgent> moin
[10:41] <davmor2> pitti:  would gvfs cause gnome-mount to have issues?
[10:42] <seb128> davmor2: why should it?
[10:42] <pitti> davmor2: unknown ATM, but it worked fine for me yesterday
[10:42] <pitti> davmor2: --verbose?
[10:42] <seb128> davmor2: gnome-mount doesn't use gvfs yet
[10:42] <davmor2> I've updated my main system to hardy as I no longer need a stable system so I can play
[10:44] <davmor2> I was putting my favourite cd's back into rhythmbox and gnome mount kept giving me errors bug 185748
[10:44] <ubotu> Launchpad bug 185748 in gnome-mount "gvfs/gnome mount issues with stability" [Undecided,New] https://launchpad.net/bugs/185748
[10:44] <davmor2> I took a screenshot it's on there
[10:45] <davmor2> also the cd would lock up about 3 cd's in
[10:46] <seb128> davmor2: how a cd can lock up 3 cds?
[10:46] <seb128> I'm not sure I understand what you describe
[10:46] <davmor2> sorry the thirdish cd would lock up
[10:47] <seb128> no idea about that
[10:47] <seb128> is that data or audio CDs?
[10:47] <davmor2> rhythmbox converts the cds to ogg on the thirdish cd it would just stop at some point I would have to restart the system to free up the disc again
[10:48] <seb128> davmor2: doesn't seem to be a gnome-mount issue, rather a nautilus one
[10:50] <davmor2> seb128:  It also happens with my usb pen.  so much of the data copied across fine then it just stopped.  This didn't happen on my test system when gnome-vfs was inplace.
[10:51] <davmor2> locking up that is (sorry not clear again)
[10:51] <seb128> looks like a gvfs or nautilus bug
[10:51] <seb128> do you get the issue using gvfs-copy ?
[10:52] <davmor2> I had no issues using sftp in nautilus to copy the files I wanted off my other machine rather than trying from the usb
[10:58] <davmor2> seb128:  How and I'll try it?
[10:59] <TheMuso> I'm triaging casper bugs, and I have found one that referrs to xforcevesa. This doesn't appear anywhere in casper, so what package takes note of this kernel command-line flag?
[11:00] <seb128> davmor2: dunno what you are copying, but it's basically "gvfs-copy source destination"
[11:00] <davmor2> seb128: np will try now
[11:17] <pitti> \sh: please use standard requestsync in the future, and be more accurate about the source (dcc isn't in unstable, etc.)
[11:18] <\sh> pitti, ah well, you commented on it, that it was moved in the past
[11:19] <davmor2> seb128: gvfs-copy command not found ?
[11:19] <\sh> pitti, and that you wanted to move it into multiverse
[11:19] <seb128> davmor2: sudo apt-get install gvfs-bin
[11:20] <warp10> dialign-t-doc is in Debian non-free because documentation is missing source. It must be synced in multiverse, right?
[11:21] <pitti> \sh: done that, and synced
[11:21] <Kmos> warp10: if section on control is non-free, it automatically goes to multiverse :)
[11:21] <\sh> pitti, thx :)
[11:21] <davmor2> seb128: right installed but it can't recursively copy a directory
[11:21] <pitti> Kmos: ('automatically' is not quite true...)
[11:22] <pitti> warp10: that doesn't sound quite right
[11:22] <pitti> warp10: it would be in non-free because the doc has a non-free license
[11:22] <pitti> warp10: if it was gpl with no source, then it is unredistributable and can't go to non-free/multiverse either
[11:23] <Kmos> pitti: the sync script doesn't check for non-free and contrib ? i think it did =)
[11:23] <warp10> pitti: well, according to debian/copyright it is released under LGPL, but source is not available. I check it with debian maintainer too, his answer was: "dialign-t-doc is in non-free because it is missing sources"
[11:24] <pitti> warp10: that's wrong then, and it should be removed from Debian
[11:24] <davmor2> seb128: I'm trying the individual tar.gz file it seems to lock up on instead
[11:25] <seb128> what do you mean?
[11:25] <warp10> pitti: wow, too bad! Well, I'll avoid to request a sync in Ubuntu, therefore
[11:25] <persia> pitti: pdfedit works too :)
[11:26] <pitti> persia: not the prefered form of modification
[11:26] <persia> pitti: I disagree that that is always the case, having used pdfedit to generate new files in the past, but suspect you are correct in this case (and the vast majority of others).
[11:27] <davmor2> seb128: I have a folder full of tar.gz files that I backed up (evolution etc)  I can't copy the folder so I'm coping the file where it seems to lock up.
[11:29] <seb128> davmor2: "lock up" = hang?
[11:30] <davmor2> yes sorry
[11:30] <seb128> use the --progress option maybe to know if it's copying
[11:31] <davmor2> seb128: It's hanging again and I can't access the pen drive now
[11:31] <seb128> looks like a gvfs bug then
[11:32] <davmor2> is there any wat I can help find out what?
[11:32] <seb128> ps ax | grep gvfs ?
[11:32] <ion_> UUOps ;-)
[11:33] <ion_> pgrep -l gvfs
[11:33] <seb128> ion_: ?
[11:33] <seb128> ion_: what is your point there?
[11:34] <ion_> Nothing serious. Just repeating the popular UUO* meme.
[11:34] <davmor2> 10823 ?        D      0:00 gvfs-copy /media/disk/docs-backup.tar.gz /home/davmor2
[11:34] <seb128> what is UUO?
 cat foo | wc -l  <bar> UUOC! wc -l foo   (Useless Use Of Cat)
[11:35] <davmor2> seb128:  If I reboot and try the --progress will that tell me where the hold up is?
[11:36] <ion_> http://www.catb.org/jargon/html/U/UUOC.html
[11:36] <seb128> ion_: ah, didn't know about that, learning every day ;-)
[11:37] <davmor2> seb128:  I noticed too that the trash applet isn't showing trash any more either it is in the folder
[11:37] <seb128> davmor2: not really, no need to reboot, you can likely kill gvfsd
[11:37] <seb128> davmor2: known issue, will be fixed with the new gnome-applets tarball
[11:38] <davmor2> okay thought it would be
[11:39] <seb128> the trash location changed, gio is using the freedesktop one
[11:42] <davmor2> seb128: Just tried killing 10823 nothing happened.
[11:42] <ion_> Would it be possible to move /lib/udev/watershed to some directory typically in PATH? watershed is useful for many other things than just udev. For instance, i have /lib/udev/watershed a-podcast-fetcher in my crontab.
[11:42] <seb128> davmor2: try using -9?
[11:43] <davmor2> seb128: no
[11:45] <davmor2> seb128:  I just checked system-monitor it says it's uninterruptible
[11:47] <Mez> who maintains PHP in ubuntu?
[11:47] <pitti> Mez: server team (soren, dendrobates, keescook, some others)
[11:48] <pitti> Mez: mathiaz, too
[11:48] <Mez> ah, well, we've found an issue here :D
[11:48] <Mez> broken functionality :D
[11:48] <Mez> definately worth a patch for LTS, and hopefully for SRU too :D
[11:49] <aquo> can anybody tell me what /var/lib/dpkg/available is used for?
[11:50] <mathiaz> Mez: did you file a bug in LP ?
[11:50] <Mez> mathiaz, not yet -
[11:50] <Mez> we're getting it into upstream first (I work with one of the main PHP devs - he's fixing it atm)
[11:51] <mathiaz> Mez: excellent !
[11:51] <Mez> mathiaz, :D It's a one line fix - but he's testing it
[11:51] <mathiaz> Mez: please file a bug in LP, and put a link to the upstream php bug and patch.
[11:51] <Mez> mathiaz, I will do :D though whether he creates a bug ...
[11:52] <pitti> BenC: can you please send me your hal debdiff, so that I can check it into bzr?
[11:53] <Mez> mathiaz - it's pretty rare, and has been there for 2 years at least
[11:55] <lool> asac_the_2nd: Hmm NM just prompted me for a password it should have known about; perhaps because it couldn't associate and thought this might be because of a password mismtach
[12:03] <davmor2> seb128:  right rebooted so I can use my system again.  How do you want me to file the bug and what against?
[12:04] <seb128> davmor2: open it against gvfs but I doubt we have enough informations to make anything useful from it at right now
[12:07] <aquo> is apt-get update; apitude safe-upgrade the same as aptitude update; apt-get upgrade?
[12:09] <davmor2> seb128: no problem
[12:09] <persia> aquo: No.
[12:10] <aquo> persia: uhhh. that is not good.
[12:10] <aquo> if i want to use aptitude for package management this interferes with the apt-get that is used in periodic scripts ...
[12:10] <aquo> (unattended-updates, cronjobs)
[12:13] <persia> aquo: The difference isn't with "update", but with "upgrade".  For details, check the source, or search for some of the early documentation on why aptitude.  This isn't really the forum for longer discussion of the differences.
[12:14] <aquo> persia: so apt-get update and aptitude update produce the same system state?
[12:15] <aquo> i know that there are differences with the recommends on so on with aptitude ...
[12:15] <persia> aquo: SImilar enough to not be worth discussion.  I don't remember if it is the same.
[12:15] <aquo> i am just curious if the use of apt-get update in cronjobs needs to be replaced by aptitude update if i want to use aptitude.
[12:16] <unop> aquo, in my opinion it is you can use anything you like apt-get, aptitude, dselect, dpkg, synaptic -- they all work on top of APT, and it shouldnt matter what you use
[12:16] <aquo> in apt: /etc/cron.daily/apt
[12:16] <davmor2> seb128: bug 185904 is there any thing else you want adding to it?
[12:16] <ubotu> Launchpad bug 185904 in gvfs "GVFS:  Unable to copy tar.gz backed up data from pen drive" [Undecided,New] https://launchpad.net/bugs/185904
[12:17] <aquo> so apt-get update; aptitude safe-upgrade is the same to aptitude update; aptitude safe-upgrade?
[12:18] <aquo> dpkg doesn't work on top of apt in my opinion
[12:18] <seb128> davmor2: having backtraces of gvfsd and gvfs-copy would be nice
[12:19] <unop> aquo, safe-upgrade does not remove packages when situations warrant removing certain packages to upgrade others -- the aptitude manpage has more
[12:19] <davmor2> seb128: how or wher do I get them?
[12:20] <aquo> un_op: i am not asking about the upgrade process, i am interrested in the update progress?
[12:20] <seb128> davmor2: https://wiki.ubuntu.com/DebuggingProgramCrash
[12:20] <aquo> unop: i know that
[12:20] <unop> aquo> so apt-get update; aptitude safe-upgrade is the same to aptitude update; aptitude safe-upgrade?
[12:20] <unop> aquo, ^^ no
[12:20] <unop> oops
[12:21] <unop> sorry misread
[12:21] <unop> aquo, i'm inclined to say yes here
[12:23] <davmor2> seb128: ta
[12:23] <seb128> you are welcome
[12:25] <mvo> unop: yes, apt-get update/aptitude update behave the same
[12:25] <aquo> unop: no problem, i am just curious on how package management works
[12:26] <aquo> mvo: so they are interchangeable, and i don't have to run aptitude update if i have the cronjobs that are included in apt
[12:27] <unop> aquo, well, i used to think aptitude was a better apt-get (atleast when i was with debian) but with ubuntu, the line that seperates the two is somewhat different, essentially they serve the same purpose and are quite interchangeable
[12:27] <mvo> aquo: yes
[12:28] <mvo> unop: the only real difference left is that aptitude has a nice ui, a different problem resolver (and in ubuntu that it installs recommends-by-default)
[12:30] <aquo> thank you for that information.
[12:32] <unop> mvo, yes, and autoremoves unneeded depenencies when a package is removed (something like apt-get autoremove ..)
[12:32] <pitti> ScottK2: stepic> hm, what's the purpose of this when the changes are machine detectable? isn't the purpose of steganography to hide data repudiatably?
[12:36] <pitti> thekorn: AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type' (https://launchpad.net/bugs/122396)
[12:36] <ubotu> Launchpad bug 122396 in poppler "[apport] evince-thumbnailer crashed with SIGSEGV in CairoFont::create()" [Medium,Confirmed]
[12:36] <pitti> any idea?
[12:37] <thekorn> pitti, not right now, but will check in a moment
[12:37] <pitti> thekorn: thanks a lot
[12:37] <mvo> unop: right, but the auto-remove information is unified
[12:38] <pitti> thekorn: ah, seb128 just mentioned that this happens with bugs which have an upstream task
[12:38] <asac_the_2nd> mbiebl: hi, did you find some time to take a look at my nm 0.7 eni branch yet?
[12:38] <asac_the_2nd> mbiebl: https://code.edg.launchpad.net/~asac/network-manager/main.eni
[12:38] <asac_the_2nd> ups
[12:38] <asac_the_2nd> ;)
[12:38] <mbiebl> hi, asac_the_2nd
[12:38] <asac_the_2nd> i think you figure
[12:39] <thekorn> pitti, ok, then it might be fixed in the .main branch
[12:39] <mbiebl> The current checkout doesn't compile...
[12:39] <mbiebl> I had a missinge eni-private.h something...
[12:39] <asac_the_2nd> hmm ... let me see
[12:39] <asac_the_2nd> which revision?
[12:39] <mbiebl> 2757
[12:40] <mbiebl> eniplugin-internal.h that is
[12:41] <asac_the_2nd> mbiebl: ok ... let me push the revision I used to build the preview package (i didn't include the system settings daemon yet)
[12:42] <thekorn> pitti, it is bug 184594
[12:42] <ubotu> Launchpad bug 184594 in python-launchpad-bugs "AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type'" [Undecided,Fix committed] https://launchpad.net/bugs/184594
[12:42] <mbiebl> Have you read my email, about getting the Debian and Ubuntu closer in sync again?
[12:42] <asac_the_2nd> mbiebl:  damn ... now i remember why i haven't pushed yet. that branch is locked for 68 hours. apparently that doesn't go away automatically
[12:43] <pitti> thekorn: ah, thanks
[12:43] <asac_the_2nd> mbiebl: i am currently in uk and my alicedsl connection went down 30 minutes after i left my house ... can read it earliest this weekend
[12:43] <asac_the_2nd> mbiebl: but yes, i am all for it ... i hope we can submit most patches we need for 0.7 upstream so we should be more in sync
[12:43] <mbiebl> asac_the_2nd: would be great.
[12:43] <pitti> thekorn: subscribed; I'll roll it out to the retracers once it's fixed in hardy
[12:44] <mbiebl> especially the sysv init related stuff is already in the Debian NM 0.6 package.
[12:44] <asac_the_2nd> mbiebl: and we could review what we have and why you don't need it ... if you are interested.
[12:44] <mbiebl> Yeah, would be cool if we could discuss this.
[12:44] <asac_the_2nd> mbiebl: https://edge.launchpad.net/~asac/+archive ... there is the 0.7 package we currently use to evaluate it
[12:45] <mbiebl> asac_the_2nd: Well, as people requested it, I had built 0.7 packages for Debian also, some time ago.
[12:45] <mbiebl> http://debs.michaelbiebl.de/networ-manager
[12:46] <asac_the_2nd> mbiebl: https://code.edge.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.7 ... thats the packaging branch we have
[12:46] <mbiebl> I'll start this weekend to push this version to the pkg-utopia svn in the experimental branch.
[12:47] <mbiebl> asac_the_2nd: while at it, we had a short discussion on #pkg-utopia, about starting dbus earlier and stopping it later.
[12:47] <mbiebl> Something around S10/K90.
[12:47] <asac_the_2nd> i have no problem with that ... we start nm at 26 or something for now ...
[12:47] <mbiebl> This would make it also possible to stop NM later during shutdown.
[12:48] <asac_the_2nd> mbiebl: you need to bump soname
[12:48] <asac_the_2nd> mbiebl: hmm ... now that i think about it ... do we need to stop it at all?
[12:49] <mbiebl> Well, think for the scripts in if-*.d/
[12:50] <mbiebl> They wouldn't be run otherwise.
[12:51] <mbiebl> Another problem, that is currently nagging me, is how to handle network-manager upgrades.
[12:51] <aquo> mbiebl: will the new NM include features for running user-independent?
[12:51] <asac_the_2nd> aquo: when its finished ... yes.
[12:51] <asac_the_2nd> mbiebl: in which regards? restarting the applet?
[12:52] <mbiebl> No, the problem that the internet connection is dropped when you restart NM.
[12:52] <asac_the_2nd> mbiebl: yes ... that will change once we have system connection support
[12:52] <mbiebl> Is a bit unfortunate if you upgrade a system via SSH ;-)
[12:52] <mbiebl> asac_the_2nd: don't think so.
[12:53] <mbiebl> NM will still tear down the connection on stop afaik.
[12:54] <asac_the_2nd> mbiebl: hmm ... i haven't looked into lately, but we should really take care that this is not done anymore for system configured connections ... same for "tearing down at startup"
[12:54] <asac_the_2nd> mbiebl: have you asked dan williams about his vision for this? fedora must have the same issue
[12:54] <mbiebl> What do you mean by that?
[12:55] <mbiebl> asac_the_2nd: fedora never restarts daemons on package upgrades ;-)
[12:55] <asac_the_2nd> mbiebl: network manager does not only not stop interfaces if you stop it ... it also brings them down and up again if you start it.
[12:56] <mbiebl> You mean it tears down a connection configured via ifupdown?
[12:57] <asac_the_2nd> mbiebl: yes it would ... but we don't manage those through nm in ubuntu (to workaround  this issue)
[12:58] <mbiebl> So, you want to have ifupdown establish a connection and then hand it over seamlessly to NM or what?
[12:58] <asac_the_2nd> mbiebl: but thats independent from ifupdown ... it will always bring all interfaces down it wants to manage on startup. to fix that it should introspect the route and interface state and if that matches the system connnection setting do not bring it down ... anyway, i somehow have the feeling that the multiple device support will make this go away.
[12:59] <asac_the_2nd> mbiebl: no ... i want ifupdown to conflict network manager ... once it supports multiple devices
[12:59] <asac_the_2nd> for now its just a workaround so people can still roam even though they have configured their wired connection through /etc/network/interfaces.
[13:00] <mbiebl> Hm, ok.
[13:00] <asac_the_2nd> mbiebl: but the problem you want to fix (not down interfaces when stopping) is tightly coupled with the problem that it tears down interfaces at startup
[13:00] <aquo> asac_the_2nd: do you have use cases that describe the update of NM?
[13:00] <mbiebl> But if you want to conflict with ifupdown anyway, why use the rather hard to manage /e/n/i format for configuring the system-settings daemon?
[13:01] <asac_the_2nd> mbiebl: for legacy reasons
[13:01] <asac_the_2nd> people should just seamlessly use their old configuration
[13:01] <mbiebl> One problem I see is, that the ifupdown format is quite flexible.
[13:01] <asac_the_2nd> and because its "the debian way" to configure things ... why to chage that?
[13:02] <mbiebl> aliased interfaces
[13:02] <mbiebl> pre/post up/down actions.
[13:02] <asac_the_2nd> mbiebl: yes ... we won't be able to have a perfect mapping ... but covering 90% of the use-cases in the begginning should be enough imo.
[13:02] <mbiebl> How do you want to map that information to NM?
[13:02] <asac_the_2nd> he rest is unlikely to use nm anyway
[13:03] <asac_the_2nd> mbiebl: which information?
[13:03] <asac_the_2nd> the actions you refered to above?
[13:03] <mbiebl> Well, just see the proposed configuration for wpa_supplicant roaming?
[13:03] <mbiebl> which uses virtual devices names.
[13:04] <mbiebl> and id_str in wpa_supplicant.conf
[13:05] <mbiebl> or mappings in /e/n/i
[13:05] <mbiebl> stuff like.
[13:05] <asac_the_2nd> mbiebl: did you take a look at the eniplugin.c file? ... thats a pretty basic approach still, but we can improve that. you have example config for that use-case?
[13:06] <mbiebl> asac_the_2nd: here is an example http://pastebin.ca/871988
[13:06] <asac_the_2nd> mbiebl: ok i am pushing the latest now to a different branch ... given that the other is still locked
[13:06]  * asac_the_2nd looking
[13:07] <asac_the_2nd> mbiebl: do you have the wpasupplicant file as well?
[13:07] <mbiebl> wpa_supplicant.conf contains different configurations which have an id_str, which matches the virtual device name.
[13:08] <asac_the_2nd> mbiebl: is that a debian specific thing?
[13:08] <asac_the_2nd> or upstream wpasupp?
[13:08] <mbiebl> http://pastebin.ca/871992
[13:09] <mbiebl> /usr/share/doc/wpasupplicant/README.modes.gz
[13:09] <mbiebl> Read roaming mode
[13:09] <asac_the_2nd> hmmm ... afaict it should map pretty well to the new configuration framework in nm
[13:09] <mbiebl> Not Debian specific.
[13:10] <asac_the_2nd> the parse for that probably should be distribution independent though
[13:11] <mbiebl> asac_the_2nd: lemme check the sources, if id_str is really upstream or a Debian/Ubuntu specific patch
[13:11] <asac_the_2nd> mbiebl: maybe we should write down the open points somewhere?
[13:11] <mbiebl> Agreed.
[13:12] <asac_the_2nd> good
[13:13] <mbiebl> wpa_supplicant/config_ssid.h
[13:13] <mbiebl> id_str seems to be upstream supported. I'm not sure if other distros use a similar mechanism though to implement a roaming mode.
[13:14] <asac_the_2nd> so the name in the iface line in interfaces has to mach that id_str right?
[13:14] <mbiebl> That's how it's implemented in Debian, yes.
[13:16] <asac_the_2nd> sorry ... need to eat ... bbl
[13:16] <mbiebl> Ok, I'll write an email to you this weekend, with all the different points I have in mind.
[13:17] <mbiebl> Together with your input, we then should add this info to a wiki or something.
[13:23] <ScottK2> pitti: It's an extreme form of security by obscurity.
[13:24] <ScottK2> pitti: (stepic)
[13:24] <ScottK2> I think it's an interesting concept.
[13:25] <ScottK2> pitti: While you're doing archive stuff (hope you still are), I'd appreciate it if you would binary new libetpan in dapper-backports.
[13:26] <ScottK2> That's the last manual step in the clamav-0.92 transition in backports for dapper.
[13:26] <pitti> ScottK2: ah, looking
[13:27] <ScottK2> pitti: Thanks.  The rdepens for it are already sitting in depwait for it, so there's no further rebuilding.
[13:27] <ScottK2> rdepens/rdepends
[13:32] <articpenguin3800> what version kernel does hardy use
[13:32] <zul> 2.6.24
[13:33] <articpenguin3800> the rc based of 2.6.24 or the stable one that got released yeterday
[13:33] <zul> right now its rc8 but its being rebased to 2.6.24
[13:35] <articpenguin3800> does that mean hardy fiesty edgy and dapper will get 2.6.24 or are there kernels frozen
[13:35] <articpenguin3800> i meant gutsy not hardy
[13:35] <amitk_> articpenguin3800: Only Hardy gets a 2.6.24 kernel
[13:35] <articpenguin3800> ok
[13:36] <asac_the_2nd> mbiebl: great .... then lets get things going :)
[13:37] <Kmos> zul: rc8 is over.. it's now 2.6.24 final :)
[13:37] <mbiebl> asac_the_2nd: nice talking to you!
[13:37] <asac_the_2nd> mbiebl: i pushed the latest: https://code.edge.launchpad.net/~asac/network-manager/main.eni1
[13:37] <mbiebl> asac_the_2nd: about the soname bump: this should be done upstream imho.
[13:38] <asac_the_2nd> yes ... thats why i committed it to that branch
[13:38] <mbiebl> asac_the_2nd: will you contact dcbw about that?
[13:38] <Hobbsee> Kmos: dude, learn to read please.
[13:39] <asac_the_2nd> yes ... i will send it upstream. we just needed it now to package it decently
[13:39] <asac_the_2nd> i think this weekend or latest on monday
[13:39] <Hobbsee> Kmos: if you'd actually read the changelog, and read what zul said, you'd know that ubuntu's kernel is currently at rc8.
[13:39] <mbiebl> asac_the_2nd: great
[13:40] <ScottK2> pitti: Thank you.
[13:40] <Kmos> Hobbsee: i found it :)
[13:40] <Kmos> Hobbsee: lagged.. 30 secs
[13:40]  * Kmos jesus!
[13:43] <Hobbsee> Kmos: how is your lag relevant?  you clearly responded to zul said, and the new linux metapackage was published hours ago.
[13:48]  * Hobbsee checks the email about Kmos
[13:50]  * Hobbsee notes that adding stuff in here is classed as contributing to ubuntu development, which is one of the things that kmos has been asked not to do.
[13:50]  * Hobbsee therefore will prohibit him from doing so.
[13:52] <mbiebl> asac_the_2nd: The debian/ directory in 0.7 still contains a lot of 0.6 cruft (nm-vpn-properties, which is no longer in NM, outdated copyright files) etc.
[13:52] <mbiebl> asac_the_2nd: I'll work on the debian/ directory during this weekend and will do a thorough cleanup.
[13:53] <asac_the_2nd> mbiebl: are you talking about the ubuntu package?
[13:53] <mbiebl> yeah.
[13:54] <ogra> Hobbsee, is that really necessary ?
[13:54] <mbiebl> What I wanted to propose is, that I'll look after debian/ and you can concentrate on the eni plugin.
[13:54] <asac_the_2nd> mbiebl: yes, there might be cruft left. it was an initial release for evaluation here
[13:55] <mbiebl> I'd like to get the contents in debian/ in sync again as best as possible.
[13:55] <asac_the_2nd> mbiebl: great .... i have two more commits here
[13:55] <Hobbsee> ogra: as far as i know, not contributing to ubuntu development actually meant just that
[13:55] <Hobbsee> which includes talking crap in channel
[13:56]  * ogra heavily disagrees
[13:56] <asac_the_2nd> mbiebl: i am fine with sharing workload that way.
[13:56] <Hobbsee> ogra: i can quiet him if you wish
[13:56] <ogra> Hobbsee, obviously you manage to ignore other people that talk crap ...
[13:57] <mbiebl> asac_the_2nd: are you fine to name the init script /etc/init.d/network-manager and /etc/init.d/network-manager-dispatcher?
[13:57] <pitti> Hobbsee: just relax a little...
[13:57] <ScottK2> ogra: Other people haven't been told by MOTU Council to desist.
[13:57] <mbiebl> That's how I had already called them in the Debian 0.6.5-1 package?
[13:58] <Hobbsee> ogra: true, but they don't talk crap for months, and they don't get a mandate from the MOTU council to stop contributing to ubuntu development.
[13:58] <ogra> ScottK, thats not relevant here
[13:58] <Hobbsee> ogra: how is it not relevant?
[13:58] <Hobbsee> ogra: it's entirely based off that decision
[13:58] <ogra> being rude and kicking people *is* relevant though
[13:59] <asac_the_2nd> mbiebl: i would be fine with that ... however the upstream tree ships NetworkManager (no Dispatcher though) ... anyway, whatever we do, we should submit it upstream
[13:59] <Hobbsee> ogra: sorry, i'm not seeing where i'm being rude - i'm seeing where i'm saying a statement of fact.
[13:59] <mbiebl> Well, init scripts is a thing I usually don't submit upstream.
[13:59] <mbiebl> As every distros uses their own anyways.
[14:00] <asac_the_2nd> yeah .... then we should ask for removal :)
[14:00] <mbiebl> asac_the_2nd: ;-)
[14:01] <dholbach> that kernel comment was probably not right, but it was definitely ignorable
[14:02] <Hobbsee> dholbach: am i wrong in thinking that "being asked not to contribute" and contributing, correctly or not, still should be forbidden?
[14:02] <lifeless> we've kicked diots from the channel before
[14:02] <ScottK2> dholbach: Sure.  It's all ignorable, but if the MC decision isn't going to be enforced, what value does it have.
[14:03] <Hobbsee> dholbach: last i checked, doing what you say is actually a good thing
[14:03] <dholbach> it's not all black and white, is it?
[14:03] <dholbach> he did not file a sync request or anything, just offered a comment to a discussion
[14:04] <ScottK2> dholbach: The MC's decision seemed to draw a pretty clear line.  On this channel you are either contributing to Ubuntu development or off topic.
[14:04] <lifeless> dholbach: because its not on malone its not disruptive?  That seems to be what you are saying
[14:04] <dholbach> sorry, clicked on the wrong button
[14:04] <Hobbsee> [01:03] <dholbach> it's not all black and white, is it?
[14:04] <Hobbsee> [01:03] <dholbach> he did not file a sync request or anything, just offered a comment to a discussion
[14:04] <Hobbsee> [01:04] <ScottK2> dholbach: The MC's decision seemed to draw a pretty clear line.  On this channel you are either contributing to Ubuntu development or off topic.
[14:04] <Hobbsee> [01:04] <lifeless> dholbach: because its not on malone its not disruptive?  That seems to be what you are saying
[14:05] <Hobbsee> dholbach: being asked not to contribute to ubuntu development, then talking on an ubuntu development, giving incorrect info, even worse...i'm not sure how that *isn't* black and white
[14:06] <Chipzz> ScottK2: I would disagree with that assertment... I'm not an ubuntu developer, I just lurk here, sometimes commenting when something interesting passes or if I have an opinion I want to add
[14:06] <ScottK2> Chipzz: And those comments are part of ubuntu development and welcome.
[14:07] <Hobbsee> dholbach: btw, i would have thought that filing bugs was also ubuntu development - is this not the case?  kmos doesn't appear to think so.
[14:07] <dholbach> lifeless: no that's not what I said - IRC behaviour can be very disruptive
[14:07] <dholbach> lifeless: I just thought that his comment did not warrant to ban him from the channel - and so thought 5 people who directly informed me of what happened (I wasn't around when it happened
[14:08] <Chipzz> Hobbsee: I would say that depends; for example, sync requests, which kmos has fucked up repeatedly in the past, may be considered development, whereas reporting a bug may not?
[14:08] <Hobbsee> Chipzz: i would have thought any triaging other people's bugs definetly classed as development.
[14:08] <Chipzz> dholbach: except it wasn't just that comment; the ban was an accumulation of frustration over Kmos during the last couple of months
[14:08] <lifeless> it seems to me that either:
[14:09]  * calc stopped going to #ubuntu after seeing what qualifies for a ban there
[14:09] <lifeless> kmos should be banned from this channel permanently (because we have banned him by MOTU council fiat)
[14:09] <lifeless> OR
[14:10] <Hobbsee> calc: yeah.  strict rules, for a 1200 person channel, i'm afraid :(
[14:10] <Hobbsee> calc: there's no real other way to do it, apart from a channel split
[14:10] <lifeless> kmos should be kicked anytime he diverts discussion (with a note that "you are being distruptive").
[14:11] <lifeless> I think that Hobbsee's kick was a little odd because the specific behaviour wasn't noted (but thats why a permanent ban makes sense to me)
[14:11] <TheMuso> lifeless: IMO the latter is probably more appropriate.
[14:11] <ScottK2> Either way the question is about if he should be let back on, not if the kick was correct.
[14:11] <lifeless> I'll note that there is an ongoing cost with kicking every time kmos is out of line: its his persistent behaviour of being out of line that lead to the ban
[14:11] <Hobbsee> lifeless: true - it was only in the statements directly above, not in the kick message.
[14:12] <Hobbsee> which was partially due to lazyness
[14:12] <ScottK2> And the MC decision was made after he was given chances to reform.
[14:12] <lifeless> Hobbsee: well, it can be percieved as hostility/rudeness
[14:12] <lifeless> Hobbsee: not saying I percieved it that way though
[14:12] <Hobbsee> lifeless: so, for the next time, i'll remember to set a ban, then to use /remove.
[14:14] <Hobbsee> lifeless: kmos has, unfortunately, proved that he will not reform.  repeatedly.  i don't see the second option as being viable, based on how many ops there are in channel
[14:14] <lifeless> Hobbsee: I suggest mailing the list and suggesting that the appropriate follow through on the motu council decision is to set bans across ubuntu-dev*
[14:14] <Chipzz> Hobbsee: while I agree with banning kmos, I think lazyness can be excused at times; for example when something is being discussed, and just asking would not break the flow of the conversation (ie the person having to look it up not being to participate in the discussion)
[14:14] <lifeless> and kick and ban from the lists
[14:15]  * persia advocates muting over banning, as channel and list archives are public anyway: no reason to limit realtime vs. delayed access
[14:16] <Hobbsee> lifeless: i asked if that should happen if he violated his conditions, and got no reply.  at some point, you need to take action if no one else will.
[14:16] <Hobbsee> FWIW, it's now a mute, not a ban
[14:16] <lifeless> Hobbsee: well, in which case send a mail to the relevant list saying its been done :)
[14:16] <lifeless> silence is permission as they say
[14:17] <Hobbsee> lifeless: oh, sure, i'll be doing that.  but i figured that it might be worth dealing with the fires from here first.
[14:17] <lifeless> ;)
[14:19]  * Hobbsee helps put out a spot fire in #ubuntu
[14:19] <lifeless> Hobbsee: oh, also - for your piece of mind, do what I did to sven many months go: '/ignore' :)
[14:19] <Hobbsee> lifeless: forbidden for irc operators, i'm afraid :(
[14:19] <Hobbsee> lifeless: by policy
[14:20] <lifeless> Hobbsee: thats a good reason not to be op:)
[14:20] <Hobbsee> lifeless: well, i avoided getting on the council :)
[14:21] <Hobbsee> Chipzz: true
[14:21] <aquo> what are you guys doing here? is this discussion development related?
[14:21] <Hobbsee> aquo: ish.  discussing the handling of the issue of one of the people being forbidden from doing ubuntu development anymore.
[14:22] <aquo> 30 minutes time spent for kmoz, i think you could do things that are more fun to you in this time ...
[14:23] <lifeless> yup
[14:38] <soc> hi
[14:39] <soc> will landscape ever be released or will it only be available for canonical's subscribers?
[15:03] <slangasek> geser: is there a xulrunner MIR pending that I don't know about, or does mono-tools need fixed up to use mozilla instead?
[15:06] <calc> slangasek: doesn't firefox 3 use xulrunner?
[15:06] <calc> slangasek: so probably no MIR yet but maybe will be soon?
[15:06] <ion_> firefox-3.0 Depends: xulrunner-1.9
[15:06]  * persia thought xulrunner != xulrunner1.9
[15:06] <calc> oh nm then, i don't know the difference
[15:06] <slangasek> ah, then I guess mono-tools needs to use xulrunner-1.9-dev instead of libxul-dev?
[15:07] <ogra> slangasek, asac_the_2nd would know
[15:07] <persia> slangasek: If it works, but there were a few packages in universe that couldn't port easily.
[15:07] <calc> asac_the_2nd: ping ^
[15:07] <ogra> calc, he's in a discussion atm
[15:07] <calc> ogra: ah ok
[15:07] <StevenK> xulrunner-1.9 was already in main, wasn't it?
[15:08] <calc> StevenK: yea its in main
[15:08] <calc> ff3 isn't yet
[15:08] <ogra> ff3 isnt yet afaik
[15:08] <ogra> heh, snap
[15:08] <calc> hehe
[15:08] <slangasek> StevenK: right, I just haven't followed at all so had no idea what the right fix was for the mono-tools dep-wait
[15:09] <StevenK> Ahh
[15:12] <jkt|> afternoon, folks
[15:12] <jkt|> could you please tell me what sources are used for the http://packages.ubuntu.com/hardy/utils/kphotoalbum-kde4 package?
[15:13] <jkt|> I'm wondering because we haven't released the kde4 version yet
[15:13] <calc> jkt|: i don't know myself but kde packagers typically get packages before other people, at least they did when i was the maintainer for Debian
[15:14] <james_w> jkt|,  https://launchpad.net/ubuntu/hardy/+source/kphotoalbum-kde4/4.0.0-0ubuntu1
[15:14] <calc> jkt|: if you aren't already on it you may want to get someone to add you to the kde packagers list (assuming you package for gentoo)
[15:15] <jkt|> let me rephrase it -- we do have code in svn, but it isn't of production quality and we haven't asked packagers to package it
[15:15] <jkt|> I'm one of upstream devs in kphotoalbum
[15:15] <calc> jkt|: oh that is interesting then :) /me points at Riddell
[15:15] <calc> jkt|: he might know
[15:15] <jkt|> calc: thanks, I'll ask him
[15:16] <calc> hmm actually nixternal uploaded it from the changelog so he would know more than Riddell
[15:16] <james_w> jkt|, it is nixternal's name in the package
[15:16] <jkt|> nixternal: could you please clarify how you managed to release kphotoalbum-4.0.0 while we (its upstream) haven't tagged it yet? :)
[15:16] <calc> jkt|: Riddell does most of the kde stuff but in this particular case nixternal uploaded the package
[15:17] <james_w> jkt|, it is not unusual to package svn snapshots, however it is unusual to package it as a version that hasn't been released.
[15:17] <jkt|> james_w: yep, if it was marked as a snapshot, I wouldn't be here :)
[15:17] <jkt|> thanks for you help, let's wait for him
[15:18] <calc> yea it was packaged as 4.0.0-0ubuntu1 which would imply it was final instead of something like 4.0.0~betaFoo-0ubuntu1
[15:20] <jpatrick> jkt|: you can atch the rest of us at #kubuntu-devel :)
[15:23] <exarkun> According to gdb, the Python 2.5 source package in Hardy does not quite match up with the python executable from the Python 2.5 package.
[15:23] <exarkun> A backtrace includes source lines which are blank and in between function definitions.
[15:24] <exarkun> Should I not expect to be able to use the source package to get source lines from gdb like this?  Or is there a bug in one of these packages?
[15:31] <StevenK> exarkun: Perhaps the Python 2.5 source package has patches applied before building, listed in debian/patches?
[15:33] <exarkun> Hmm.  There's a bunch of files in that directory, yea.  I'm not extremely familiar with how patches work inside Ubuntu packages.  I applied the .diff that came with "apt-get source ...".  Some hunks of it applied, others didn't.  I didn't think to look for patches elsewhere, too.
[15:38] <asac_the_2nd> slangasek: yes ... mono gecko binding is the only thing left in main that i have to create a patch for to use xulrunner-1.9-dev
[15:38] <StevenK> asac_the_2nd: What about liferea? :-)
[15:38] <asac_the_2nd> i have a patch for that iirc
[15:38] <StevenK> asac_the_2nd: If you have a patch for Liferea, throw it at me ...
[15:39] <asac_the_2nd> StevenK: so that i don't confuse ... liferea is C(++)?
[15:39] <StevenK> asac_the_2nd: Liferea is C, the Mozilla bindings are (the only file) in C++
[15:39] <asac_the_2nd> then i have a patch ... yes.
[15:40] <StevenK> asac_the_2nd: Mail it my canonical address, and I'll look it over during my flight
[15:40] <asac_the_2nd> but i couldn't access my machine at home for the whole week. will send as soon as i am home again (given my machine didn't burn down)
[15:40] <StevenK> Oh, fair enough, then I'll look during the week
[15:41] <asac_the_2nd> StevenK: yeah ... will arrive home tomorrow in the evening ... so probably you get it on sunday
[15:41] <StevenK> asac_the_2nd: Sounds great. :-)
[15:42] <asac_the_2nd> StevenK: did you try those in my xulrunner-porting branch?
[15:42] <asac_the_2nd> http://codebrowse.launchpad.net/~mozillateam/xulrunner/xulrunner-porting/files/asac%40jwsdot.com-20080116133320-ut6kwdkzc7eunmmv?file_id=liferea-20071214201407-8w8sqpz3ygwfopay-1
[15:42] <Riddell> jkt|: ping
[15:42] <StevenK> asac_the_2nd: I didn't, since I didn't know it existed. :-)
[15:43] <jkt|> Riddell: pong
[15:43] <Riddell> jkt|: you need to talk to toma, kphotoalbum is released with extragear (ftp://ftp.kde.org/pub/kde/stable/4.0.0/src/extragear)
[15:43] <asac_the_2nd> StevenK: please try ... as i am not sure if they work against xulrunner package we have in the archive atm
[15:43] <asac_the_2nd> if they don't let me know ... i will fix them up
[15:43] <Riddell> jkt|: he has a list of extragear packages who have agreed to be relased at the same time as KDE and kphotoalbum is inluced
[15:44] <jkt|> Riddell: wow, ok, probably we screwed communication to kde release folks, then
[15:44] <StevenK> asac_the_2nd: Sure, I've made a note, I'll have a poke.
[15:44] <asac_the_2nd> great
[15:44] <jkt|> Riddell: I recall the question, but I thought it was opt-in, not opt-out
[15:44] <jkt|> Riddell: thanks
[15:47] <Riddell> jkt|: http://techbase.kde.org/index.php?title=Projects/extragearReleases
[15:48] <slangasek> asac_the_2nd: ok, thanks. :)
[15:57] <jkt|> nixternal: unping
[15:58] <goodhabit> Hello. I have some trouble. I am linux newbie, also ubuntu newbie. I have found some software, and with helps of manuals, google, brain I have compiled some software. But, as I understood,"make install" is wrong-way. And I need making deb file. I am started googling forward and found some manuals for it (#ubuntu also). But there are some issues I cannot solve. But as I told allready I need that package. Maybe someone could help me with packaging?
[15:59] <slangasek> tjaalton: no news on bug #133192?
[15:59] <ubotu> Launchpad bug 133192 in xserver-xorg-video-ati "Blank screen or distorted image because of wrong default AGPMode value" [High,Confirmed] https://launchpad.net/bugs/133192
[16:00] <slangasek> goodhabit: for beginner packaging help (if you plan for the package to eventually go into Ubuntu), #ubuntu-motu is better
[16:08]  * Hobbsee snorts at the MOTU ML
[16:08] <Hobbsee> ScottK2: neat.  thanks.
[16:08] <Hobbsee> ScottK2: i prefer not to have to react to that thread myself.
[16:09] <\sh> can someone deal with the ubuntu-devel@lists.ubuntu.com ML to have sh@sourcecode.de whitelisted as being a ubuntu-dev again? :)
[16:10] <pochu> Same for pochu@ubuntu.com pretty please
[16:11] <Hobbsee> \sh: pochu done
[16:11] <\sh> Hobbsee, thx
[16:11]  * Hobbsee assumes it's supposed to be added manually
[16:11] <pochu> Thanks Hobbsee :)
[16:12] <slangasek> Hobbsee: I think I'm not whitelisted on there either?  steve.langasek@ubuntu.com or such
[16:12] <pochu> Hobbsee: possibly, since I'm a motu for 2+ weeks...
[16:12] <Hobbsee> slangasek: *sigh*
[16:13] <slangasek> sorry, I had no idea what the process was so I was not dealing with it until the opportunity suddenly presented itself ;)
[16:13] <\sh> hehe
[16:13] <Hobbsee> slangasek: done
[16:14] <slangasek> Hobbsee: cheers
[16:18] <pitti> ArneGoetje: https://translations.edge.launchpad.net/ubuntu/gutsy/+language-packs
[16:22] <pochu> pitti: do you have a clue why apport didn't retrace bug 178101? Will it do it if I add a needs-i386-retrace tag?
[16:22] <ubotu> Launchpad bug 178101 in vinagre "vinagre crashed with SIGSEGV in setcontext()" [Medium,Incomplete] https://launchpad.net/bugs/178101
[16:23] <pitti> pochu: it was broken for quite a while
[16:24] <slangasek> and at this point it won't because the ddebs are probably no longer available
[16:25] <pochu> Hmm, right.
[16:27] <Ng> slangasek: so if I have a segfault from the new package from today I should let apport do its magic to a new bug?
[16:28] <slangasek> pitti or bdmurray probably have more useful opinions in that regard
[16:28] <pochu> Ng: there has been one, and the retrace failed.
[16:28] <Ng> ah
[16:28] <pochu> https://bugs.edge.launchpad.net/ubuntu/+source/vinagre/+bug/185047
[16:29] <pitti> yeah, seb128 and I just found a pretty weird bug
[16:29] <pitti> ddebs are disappearing from the Package indexes
[16:29] <pochu> weird, indeed
[16:42] <pitti> ArneGoetje: script pushed to the main branch
[16:42] <pitti> ArneGoetje: please do bzr merge bzr+ssh://bazaar.launchpad.net/%7Epitti/langpack-o-matic/main/
[16:43] <pitti> ArneGoetje: ah, s/bzr+ssh/http/
[16:59] <pitti> ArneGoetje: bzr merge lp:langpack-o-matic
[16:59] <bddebian> pitti: Oh, have a sec about plr?
[16:59] <\sh> pitti, ping bug #185959, when I finished the list, can we work together on this transition, regarding syncs from debian ?
[17:00] <ubotu> Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed] https://launchpad.net/bugs/185959
[17:02] <pitti> \sh: yeah, that's ok
[17:02] <pitti> \sh: for this kind you can just give me a list in IRC
[17:02] <pitti> bddebian: one sec, yes (pretty busy here); just ask, I'll answer eventually
[17:02] <\sh> pitti, that's what I though we do :) if this is finished, we can get rid of octave2.1 and octave2.9 :)
[17:03] <bddebian> pitti: Well apparently upstream has a new one for 8.3 but it's beta so I'm still unsure what to do with it.  Package the beta for 8.3 or leave 8.2 and try to fix it somehow.
[17:04] <pitti> bddebian: you can upload the one with 8.3beta to experimental
[17:05] <bddebian> Hmm, OK, I'll check on that, thanks
[17:16] <tjaalton> slangasek: I need to check if upstream has reverted to the previous default values
[17:17] <geser> asac_the_2nd: re mono-tools: when I filed the bug I tested that it builds in a pbuilder with xulrunner1.9-dev.
[17:19] <slangasek> tjaalton: ok.  might be nice to have that fix included in alpha4, since it was release-noted for 3
[17:19] <geser> slangasek: re mono-tools: I was waiting on asac's feedback or sponsoring on bug #183895
[17:19] <ubotu> Launchpad bug 183895 in mono-tools "[hardy] Replace build-dependency on libxul-dev with xulrunner-1.9-dev" [Undecided,New] https://launchpad.net/bugs/183895
[17:21] <slangasek> geser: yep, asac_the_2nd clarified later, thanks
[17:22] <geser> pitti: what's the status on bug #184545?
[17:22] <ubotu> Launchpad bug 184545 in debhelper "[Merge] debhelper (6.0.2ubuntu1)" [Undecided,New] https://launchpad.net/bugs/184545
[17:22] <tjaalton> slangasek: indeed
[17:23] <pitti> geser: no time during the sprint, sorry; next week, I think
[17:23] <geser> ok
[17:23] <mbiebl> asac_the_2nd: tested the main.eni1 branch
[17:25] <mbiebl> the plugin crashes: http://pastebin.ca/872251
[17:45] <nixternal> jkt|: kphotoalbum was a sync, I didn't upload it
[17:47] <Hobbsee> nixternal: you'll get blamed anyway
[17:47] <nixternal> so that means that Debian had it first and all I did was request for it to be sync'd
[17:47] <nixternal> I know :p
[17:47] <nixternal> I have it tattooed on my forhead
[17:48] <\sh> nixternal, lol
[17:49] <\sh> nixternal, didn't you know, even when you are the one who requested a sync, you are the one to blame...;)
[17:50] <nixternal> nah, it is a valid question...but I do remember seeing kphotoalbum-kde4 in ktown after tagging
[17:52] <nixternal> jkt|: kphotoalbum is still in ktown stable/4.0.0/src/extragear with a modification date of 2008-01-04
[18:06] <snikker> when i run "ps2pdf file.ps file.pdf", i've got this error: "Bus error". this appen only from today. can you help me?
[18:10] <\sh> snikker, the last update was from the 23rd of Jan...
[18:11] <\sh> snikker, try this: apt-get --reinstall ghostscript
[18:12] <\sh> snikker, it works for me here...as mhb told you in #kubuntu-devel, thx :)
[18:13] <Riddell> nixternal: I've discussed this with him
[18:13] <Riddell> nixternal: it was a mis-communication with extragear admins
[18:13] <nixternal> roger dodger, that is what I figured
[18:15] <nixternal> actually I was wrong about the sync, I was thinking that because I just did the kphotoalbum sync of 3.1.0...got nervous for a second thinking I blasted the KDE 3 version with the KDE 4 version
[18:26] <snikker> \sh: i've reinstalled ghostscript but i've got the same error... what could be the problem?
[18:26] <\sh> dunno...please file a bug with strace ps2pdf <.ps> <.pdf> on launchpad :)
[18:27] <snikker> \sh: ok thanks :)
[18:37] <snikker> \sh: solved with strace. i've reinstalled "libgs8" and now it work again! thank you! :-)
[18:39] <\sh> snikker, so that's what I thought...you hit by something during the install (mostly your hd cache had a hickup or so...)I had it once in a while, when I was compiling heavy stuff with a lot of swapping and trying to install new packages at the same time :)
[18:44] <marcin_ant> hi all so called "developers"
[18:45] <marcin_ant> I know that this what I am going to tell will be rude and you can ban me
[18:46] <\sh> hmm? what'll come now?
[18:46] <marcin_ant> but I just need to tell you guys that because of your *&^*&^*&^*&^ (put some ugly words here)
[18:46] <thom> i'm hoping this is good. it's taking long enough
[18:46] <marcin_ant> ugly upgrade procedure - from feisty to gutsy I have to go to my car and drive 120km
[18:47] <marcin_ant> only because after upgrade eth0 in my server is now eth2 and I need to go there because I have no remote access
[18:47] <marcin_ant> thank you guys, thank you very much :(
[18:47] <Chipzz> not as good as I expected :P
[18:48] <robertj> meh, does suck though
[18:48] <thom> well, that sounds like you killed your iftab which is written by the installer to avoid exactly this issue
[18:48] <Chipzz> marcin_ant: try not using networkmanager on a server?
[18:48] <\sh> marcin_ant, well...the problem is not the upgrade...the problem is not having an Remote Insight Board like ilO or eRIC
[18:48] <marcin_ant> not to mention that aliases in /network/interfaces are broken too
[18:48] <BenderUnit22> Running a server without remote access, how did you manage to upgrade it from Feisty to Gutsy?
[18:48] <BenderUnit22> I must be overlooking something obvious. :/
[18:48] <marcin_ant> Chipzz: I don't use network manager
[18:48] <Chipzz> BenderUnit22: he means "remote hands"
[18:49] <Chipzz> BenderUnit22: which is another word for "someone to go push the reset-button" :P
[18:49] <BenderUnit22> If he has that, surely he wouldn't have to drive there to have it fixed?
[18:50] <marcin_ant> Chipzz: I had pretty nice /etc/network/interfaces but now after reboot eth0 is eth2 and I my ssh session is lost
[18:50] <Chipzz> marcin_ant: you should never have done a kernel upgrade from remote location anyway
[18:51] <\sh> marcin_ant, you should think about a cheap remote insight board, or a little cyclades terminal switch where you can attach your serial port for accessing grub during bootup to rename your eth2 to eth0 ,-)
[18:52] <marcin_ant> sure but maybe you guys could think about fixing udev (am I right that it's udev fault?) ???
[18:52] <Chipzz> marcin_ant: upgrading a kernel (certainly between versions, ie not minor ubuntu versions) should always be done at the console
[18:52] <Chipzz> marcin_ant: if you don't know that... no offence, but then you're a crappy sysadmin
[18:52] <thom> marcin_ant: see earlier. the installer creates a file to ensure this doesn't happen
[18:53] <thom>  /etc/udev/rules.d/70-persistent-net.rules
[18:54] <marcin_ant> and what guys about this: SIOCSIFFLAGS: Cannot assign requested address
[18:54] <marcin_ant> SIOCADDRT: No such process
[18:54] <marcin_ant> Failed to bring up eth2:1. ?
[18:55] <elmo> Chipzz: err, I'm not sure that's a helpful attitude
[18:55] <thom> this is way offtopic for here anyway
[18:55] <elmo> Chipzz: I've done hundreds of remote kernel upgrades; sometimes there's no choice.  and I don't think it makes me a crappy sysadmin
[18:56] <elmo> but thom's right too, this is offtopic
[18:56] <marcin_ant> Chipzz: do you think that I always have time to ride from place to place just to push some buttons?
[18:57] <marcin_ant> Chipzz: I thought this is why someone invented ssh and other network tools
[18:57] <thom> guys
[18:57] <marcin_ant> thom: toght
[18:57] <marcin_ant> thom: right
[18:58] <marcin_ant> thom: I'm sorry - I use ubuntu from it's beginning and I really appreciate your work
[18:59] <marcin_ant> but things like this really _shouldn't_ happen in ubuntu _server_
[19:00] <marcin_ant> call me crappy admin - but all I have to say at the moment is that I'm maybe crappy sysadmin - but propably because sys that I admin is crappy
[19:00] <Chipzz> elmo: I think that as a sysadmin, you should be aware that things can go wrong when doing certain things - like upgrading the kernel
[19:00] <marcin_ant> and now plonk/ban/kill me - I need to go and ride... :[
[19:01] <marcin_ant> Chipzz: I'm aware but I'm still annoyed
[19:02]  * thom notes he's done about 20 edgy->gutsy upgrades in the last month remotely without issue *shrug*
[19:03] <marcin_ant> thom: I upgraded from dapper to feisty without issues too but now.. no luck unfortunately
[19:04] <ScottK> marcin_ant: You did a dapper direct to feisty upgrade on this box before?
[19:06] <marcin_ant> ScottK: yes!
[19:06] <ScottK> marcin_ant: Gut feel tells me that's why.
[19:06] <marcin_ant> ScottK: ?
[19:07] <ScottK> The sysv init to upstart transition happened in Edgy and so the odds of something weird happening if you skip that step on non-zero.
[19:07] <ScottK> Also the switch to UUID based device numbering was in Edgy too.
[19:07] <ScottK> Dapper -> Feisty is unsupported and untested.
[19:08] <ScottK> I know from my own experimentation that there can be TTY troubles (there's a bug on that somewhere).
[19:08] <marcin_ant> ScottK: so are you going to tell me that I should install gutsy from cd and it should resolve some problems?
[19:09] <ScottK> That's what I would do since you've upgraded through an untested and unsupported path.  We know from the Dapper -> Hardy upgrade testing that's going on now that there are issues.
[19:09] <ScottK> We certainly don't know what they all are.
[19:10] <ScottK> I'd suggest you've got your system into an unknown state and there's no good way back.  It might be fine, but if it's a long drive, you probably don't want to take that risk.
[19:10] <marcin_ant> ScottK: well I have to go there anyway... So I could do some clean installation
[19:11] <ScottK> Better one longer complete trip than having to go back in a week when something else weird happens.
[19:11] <marcin_ant> ScottK: well that's right - because problem with eth0->eth2 is one thing
[19:11] <marcin_ant> ScottK: but I also had this: SIOCSIFFLAGS: Cannot assign requested address
[19:11] <marcin_ant> SIOCADDRT: No such process
[19:11] <marcin_ant> Failed to bring up eth2:1.
[19:11] <ScottK> Who knows what else is hiding so far.
[19:11] <ScottK> Just nuke it and start over.
[19:14] <marcin_ant> ScottK: ehhhh clean installation + shorewall + dansguardian + squid + etc etc... guys - call me crappy sysadmin but how could you name distro "ubuntu-server" while it has such ugly network issues after upgrade?
[19:15] <ScottK> marcin_ant: I've upgraded a lot of machines and never had such problems.  I think the problem is that you took a non-standard/untested path.
[19:15] <marcin_ant> it should be "ubuntu-beta-notready-hazardous-server" :[
[19:15] <marcin_ant> ScottK: ??? I just upgrade from release to release... you call this non-standard?
[19:16] <ScottK> marcin_ant: Maybe I misunderstood you then.
[19:16] <ScottK> marcin_ant: I thought you said you upgraded direct from Dapper to Feisty, skipping Edgy.
[19:17] <marcin_ant> ScottK: I installed Edgy on this machine - then upgraded to Feisty without issue - and now from Feisty to Gutsy
[19:18] <ScottK> marcin_ant: OK.  Then I take it back.  I completely misunderstood.
[19:18] <ScottK> I've done a bunch of Feisty/Gutsy upgrades, so I've no idea exactly what would be your problem.  Sorry for leaning on you about the wrong thing.
[19:19] <marcin_ant> ScottK: problem is that I don't know how to solve this too... :(
[19:20] <marcin_ant> ScottK: because I know that I don't have ssh connection now because of mess with eth[x]
[19:20] <marcin_ant> ScottK: but another thing is that I had virtual network interfaces that are broken now too
[19:21] <marcin_ant> ScottK: and I know how to fix problem with messed eth interfaces - but don't know why I cannot bring up eth2:1 and eth2:2
[19:21] <ScottK> Once you have local access you ought to be able to put it back to eth0.
[19:21] <ScottK> Dunno what to tell you on that.
[19:24] <marcin_ant> ok guys I have to go
[19:24] <marcin_ant> I know that you hate people like me... and I... almost understand ;)
[19:25] <marcin_ant> but sometimes it's good to have some "feedback" from real life users/sysadmins ;)
[19:25] <marcin_ant> need to go... to this crappy server.. maybe I will switch to gentoo/fedora/whatever...
[19:26] <jablko> there is a package in the debian repositories which i'd like available in ubuntu
[19:26] <jablko> is there something like filing an RFP on WNPP in ubuntu?
[19:27] <elmo> https://wiki.ubuntu.com/SeedManagement <-- could use some serious  love by someone who actually knows current practice (i.e. not me)
[19:29] <marcin_ant> oh... before I go: Bug #148929 in udev (Ubuntu)
[19:29] <ubotu> Launchpad bug 148929 in udev "Gutsy beta renumbers ethernet interfaces after boot (dup-of: 145382)" [Undecided,Confirmed] https://launchpad.net/bugs/148929
[19:30] <ubotu> Launchpad bug 145382 in busybox "[Gutsy] broken 70-persistent-net.rules" [Undecided,Fix released] https://launchpad.net/bugs/145382
[19:34] <\sh> jablko, which package?
[19:35] <marcin_ant> mhmm and I'm not alone with my second problem: Bug #123773
[19:35] <ubotu> Launchpad bug 123773 in ifupdown "'SIOCSIFFLAGS: Cannot assign requested address' when setting up ip alias" [Undecided,Confirmed] https://launchpad.net/bugs/123773
[19:37] <\sh> marcin_ant, btw..I just did a remove dist-upgrade session on a customers server..from dapper-server to gutsy... no problem at all
[19:37] <\sh> s/remove/remote/
[19:38] <jablko> \sh: solr-tomcat5.5
[19:38] <\sh> jablko, source package please?
[19:39] <geser> \sh: solr
[19:41] <\sh> hmm..java crap ;)
[19:43] <geser> \sh, jablko: blocked on the FTBFS of lucene2
[19:43] <\sh> geser, the source package looks strange: binary-dep on sun-java5-jre | sun-java6-jre but b-d on sun-java5-sdk only
[19:43] <\sh> s/sdk/jdk/
[19:45] <geser> \sh: the sun-java6-jre can execute the code compiled with sun-java5, so it looks ok
[19:45] <geser> at least I was told so
[19:48] <\sh> geser, sure...that's not the problem...I'm asking me why they are not building the code with java6..but well it's java nothing for me
[19:50] <robertj> ooh hardy upgrade went very smooth, the system crashed fairly hard at the end but a reboot and retry and things are good
[19:50] <geser> \sh: I'm not yet deep enough in java packaging to understand it. I just looked at some java packages FTBFS in the past.
[19:50] <robertj> lots of bugs fixed
[19:52] <ScottK> marcin_ant: I just noticed which channel this is.  Support is OT on this channel.  You might have more luck on #ubuntu-server
[19:57] <jablko> geser: sorry, i searched launchpad for a solr bug, how did you determine it was blocked?
[19:58] <jablko> oh, launchpad bug 185917?
[19:58] <ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
[19:59] <geser> jablko: I looked at the build-dependencies of solr and saw that liblucene2-java isn't available yet
[20:00] <jablko> geser: how did you then find lucene2 FTBFS?
[20:02] <geser> jablko: I remember seeing it on http://qa.ubuntuwire.com/ftbfs/
[20:02] <geser> jablko: else I would check which source package builds liblucene2-java, check it is in hardy and check then the build status
[20:03] <robertj> bwahhaaha, ssh:// read-write in gedit at last!
[20:03] <jablko> geser: ok, thanks much!
[20:03] <robertj> this really brings an insane gleam to my eye
[21:24] <juacom99> hi just one simple question
[21:25] <juacom99> i'm trying to program a chat server for ares P2p that works on linx
[21:25] <juacom99> is there something i shuld know before i satrt developing?
[21:27] <juacom99> sorry i just tead the topic
[21:27] <juacom99> nm
[22:55] <Pelo> evening folks
[22:56] <Pelo> I was wondering , is there a link to view the "official" hardy desktop theme ?
[22:56] <Pelo> or the latest version of it
[23:01] <LaserJock> Pelo: it probably changes enough that people aren't putting up many "snapshots"
[23:02] <Pelo> LaserJock,  I was just wondering about the general direction of it , some of the alternatives are quite nice ( most are hideous) , I just tried to look up the "real" one but I couldn'T find it , so I wondered
[23:18] <tlacuache> question about a package I got off of packages.ubuntu.com... i wanted to look at the ubuntu patches to the original source for a package. so i went to http://packages.ubuntu.com/gutsy/net/dsniff and downloaded [dsniff_2.4b1+debian.orig.tar.gz] and [dsniff_2.4b1+debian-15ubuntu1.diff.gz]. the first .gz contains the original source. the second .gz contains a .diff file, but it's not like a regular .diff file i'm used to using with patch
[23:18] <tlacuache> when i try to apply it with patch, i see files created like debian/patches/06_urlsnarf_zeropad.dpatch
[23:18] <tlacuache> i really just want to apply the patch to the source code correctly
[23:18] <tlacuache> any pointers?
[23:19] <crimsun> dpatches can be applied using patch just as "ordinary" unified diffs.
[23:20] <crimsun> the specific patch maintenance system is called dpatch.
[23:24] <tlacuache> ah, sweet
[23:24] <tlacuache> ok i get it
[23:24] <tlacuache> i apply the patch
[23:25] <tlacuache> then i do dpatch apply-all
[23:25] <tlacuache> and it actually modifies the source code
[23:25] <tlacuache> thanks
[23:25] <crimsun> yw.
[23:26] <emgent> keescook, ping
[23:27] <emgent> someone remove " xorg-server security update blocked, fix in progress" in the topic :P
[23:27] <crimsun> emgent: you can; it's not locked.
[23:28] <emgent> oh true
[23:28] <emgent> :D
[23:48] <Kopfgeldjaeger> good night