[03:36] <Andphe> Hi, anyone can help?, I'm upgrading PHP 5.2 to 5.2.13 for myself and as an excercise
[03:37] <Andphe> launchpad build the amd64 but not the i386 package
[03:37] <Andphe> http://launchpadlibrarian.net/51213960/buildlog_ubuntu-lucid-i386.php5_5.2.13.dfsg.1-0ubuntu0~andpheppa1_FAILEDTOBUILD.txt.gz
[03:38] <Andphe> configure: error: recode extension can not be configured together with: mysql
[03:38] <Andphe> this is the error message ↑↑
[03:38] <Andphe> for what I've research, it's because the config file gets rebuild and the patches are loose
[03:39] <micahg> Andphe: please try #ubuntu-packaging
[03:39] <Andphe> micahg:oh, ok, sorry
[03:39] <micahg> Andphe: np
[04:19] <un214> you have managed to annoy people [no not just me] pretty thoroughly with plymouth
[04:19] <un214> I'm trying to take some drastic action to get rid of it -- in my mind there can be no justification for it
[04:20] <un214> but you managed to wire mountall to plymouth pretty thoroughly so mountall must go as well
[04:20] <un214> and brings a good chunk of /etc/init with it
[04:21] <RAOF> Something like plymouth is fundamentally necessary for parallel init to work properly.  You don't have to have the splash enabled.
[04:21] <un214> I'm about to prove that wrong
[04:22] <RAOF> For the special-case of not having more than one thing ask for input during boot, I presume.
[04:22] <un214> what's the second thing that asks during early boot?
[04:23] <RAOF> fsck, 1 passphrase input per encrypted device, etc.
[04:24] <un214> easy fix for that one -- attach all encrypted devices before fsck of nonroot
[04:24] <RAOF> fsck of multiple drives running in parallel?
[04:25] <un214> my old slackware system handled that pretty darn good
[04:25] <un214> [in the rare case where fsck needed to ask something it reran it in serial mode]
[04:26] <RAOF> I guess it comes down to: are you going to enumerate all the things which could possibly ask for input before login, and work around each of them separately?
[04:26] <un214> I'm actually going to say there should not be any more for any reason
[04:27] <un214> by the time anything has to ask a boot question except for efs you have a sick system
[04:28] <un214> and if you want to ask at boot time then it cannot be fixed remotely anymore
[04:28] <RAOF> (Unless you extend something like plymouth ;))
[04:29] <un214> it is my judgement the better move is to try to bring up console login, networking, and sshd and wait unless you can't even go multiuser
[04:30] <un214> [can't mount /usr = fatal]
[04:31] <RAOF> Yeah, but wouldn't it be cool if it was fatal in a remotely-resolvable fashion? :)
[04:31] <un214> well if you moved sshd off /usr it would be
[04:32] <un214> I retooled a system I was using for development once so it could start sshd even if it couldn't remount / rw.
[04:32] <RAOF> Anyway, you're welcome to work at removing Plymouth from the startup sequence.  I don't think it's a huge issue, though.
[04:32] <un214> I like your attitude.
[04:32] <RAOF> And it's solving real problems, so you'll need to re-implement solutions for them.
[04:33] <un214> it just managed to wrankle a lot of people because for most people it doesn't solve anything interesting
[04:34] <RAOF> I'm not sure about “a lot”, but for many people it won't be solving anything interesting, no.  From a distro point of view, though, we need to care about the more general cases.
[04:35] <un214> I actually worked this problem years ago, and cut about a third off of boot time by bolting a parallel init system on top of inittab
[04:35] <un214> everything after mount -a can be done in parallel no problem, everything before is not really parallelizable anyway
[04:37] <RAOF> Except that's not true - it's entirely possible to parallelise things before mount -a (although some of this is in the kernel), and there's dependencies after mount -a.
[04:40] <un214> I'm really curious how plymouth would handle /dev/console -> /dev/ttyS1
[04:44] <un214> You see, I'm really concerned as neither plymouth nor mountall have demonstrated the rock solidness I've come to expect from Linux systems.
[06:52] <dholbach> good morning
[07:04] <pitti> Good morning
[07:04] <dholbach> hey pitti
[07:04] <pitti> ccheney: oh, please don't worry, your wife is much more important :)
[07:04] <pitti> hey dholbach
[08:37] <tkamppeter> Can someone tell me which is the default scanning tool in Kubuntu?
[08:38] <raphink> tkamppeter: I think that would be skanlite
[08:43] <pitti> tkamppeter: simple-scan
[08:50] <tkamppeter> pitti, is simple-scan not a GTK application?
[08:50] <pitti> tkamppeter: argh, sorry, misread
[08:50] <pitti> tkamppeter: trust raphink, not me :)
[08:50] <pitti> tkamppeter: (unlucky line break just before "in Kubuntu" in my IRC client :) )
[08:52] <tkamppeter> pitti, raphink, thanks. I have put xsane | simple-scan | skanlite instead of xsane into the Recommends of hplip-gui now, should avoid unneeded GTK installation for Kubuntu users.
[08:53] <pitti> tkamppeter: shouldn't that be a suggests rather?
[08:53] <pitti> tkamppeter: oh, and as for bug 600504, should python-notify be a dependency of hplip-gui then, instead of hplip itself?
[08:54] <tkamppeter> pitti, xsane was already in Recommends:, so I added the other there.
[08:55] <pitti> tkamppeter: hmkay
[08:56] <tkamppeter> pitti, one would need to check whether hplip-gui works without python-notify. Now I have python-notify also in the Recommends: of hplip-gui.
[08:57] <pitti> tkamppeter: hplip-gui is fine; the problem was that hplip itself pulled in python-notify, which caused half the desktop to appear in the server isos
[09:00] <tkamppeter> pitti, this I understand. There were tons of small changes done by the Debian maintainer, he was probably not aware of hplip being used on servers or python-notify pulling so many GUI libraries. Therefore I have introduced hplip-gui earlier.
[09:28] <Iraqi> Who know APT line for ubuntu please? thanks:)
[09:29] <Iraqi> and i invite you all to new channel #ubuntu-iq is support all things  :)
[12:38] <seb128> didrocks, let's move there
[12:38] <seb128> so current maverick CDs have notify-osd and notification-daemon installed
[12:38] <seb128> does anybody has a clue why notification-daemon get installed?
[12:39] <seb128> knowing that notify-osd provides notification-daemon
[12:39] <didrocks> notify-osd is providing notification-daemon and only notify-osd is in the seeds
[12:39] <seb128> I've no found any versioned depends on it either that would explain it being pulled in
[12:45] <smb> pitti, Would you be able to rescue ddebs from the last update? ddebs.ubuntu.com is again stripped of any Lucid
[12:54] <pitti> smb: I rescued everything yesterday, and fixed the problem of disappearing amd64 ddebs
[12:54] <smb> pitti, Hm, was I blind this morning then?...
[12:54] <pitti> no, you aren't
[12:55] <pitti> smb: the maverick ddebs are back
[12:55] <pitti> but the lucid ones not
[12:55] <pitti> smb: but the lucid ones were built ealier than a week ago, so there's nothing to rescue
[12:55] <pitti> but something on them must be wrong still, since they keep disappearing
[12:56] <smb> pitti, Right. I feared that would be related to the build time of proposed
[12:56] <smb> pitti, So I should get together with you right after the next proposed upload to Lucid
[12:57] <pitti> well, we need to find out why they disappear in the first place; currently RTFS
[12:57] <pitti> smb: ah, I still have the "-image-debug" hack in place
[12:57] <pitti> smb: which I should remove now, since the lucid/maverick ones are properly named now?
[12:58] <smb> Right they are
[12:58] <pitti> done
[12:58] <pitti> so the maverick ones should stay now
[12:58] <pitti> and the next lucid round as well
[12:58] <smb> Hm, one would hope the hack would be a either or hack and not a one xor the other. :)
[12:58] <pitti> hm, but now the karmic ones will disappear..
[12:59] <seb128> cjwatson, pitti: do you have any clue about notification-daemon?
[12:59] <pitti> seb128: what about it?
[12:59] <seb128> cjwatson, pitti: or rather about why it's on the current iso, cf backlog half an hour ago or so
[12:59] <pitti> seb128: will look in a bit, still messing with ddebs
[12:59] <seb128> pitti, thanks
[13:00] <smb> pitti, Depends on whether the rebuild of debian would get accepted. ;-) But then this would still leave hardy and jaunty out. Not to mention dapper, though I cannot remember anyone asking for _those_
[13:01] <pitti> smb: the one-liner to rename the packages certainly would :)
[13:01] <smb> pitti, I guess I cannot win against that argument. :)
[13:01] <pitti> so as for the "or" hack, I could change the hack to never clean linux ddebs at all
[13:01] <cjwatson> seb128: looking
[13:01] <pitti> but they'd pile up quickly
[13:02] <seb128> cjwatson, thanks
[13:02] <smb> Yeah, I think that would soon make is the sworn enemy of IS
[13:02]  * pitti ponders
[13:02] <cjwatson> seb128: recommends from libnotify1
[13:03] <smb> pitti, I would have guessed the hack would be something like if packagename modufied from old way has a matching package in archive or moified the new way has one, then it can stay
[13:03] <cjwatson> which comes in from python-notify and gnome-settings-daemon (at least)
[13:03] <seb128> cjwatson, but it's not versioned?
[13:03] <smb> pitti, But I might think in a too simple way
[13:03] <seb128> cjwatson, and notify-osd provides notification-daemon
[13:04] <seb128> cjwatson, that worked in lucid, I don't see what changed...
[13:04] <cjwatson> "not versioned"?
[13:04] <cjwatson> oh
[13:05] <seb128> cjwatson, well the provides should work if the depends is not versioned
[13:05] <cjwatson> I'll look in more detail
[13:05] <seb128> thanks
[13:05] <cjwatson> ah yes, I see
[13:05] <pitti> smb: ah, I'll just special-case the versions < 2.32
[13:05] <cjwatson> the thing is, libnotify1 is coming in through a package in the desktop-common seed (python-notify)
[13:05] <smb> pitti, That sounds simple and reasonable
[13:05] <cjwatson> notify-osd is seeded in desktop, not desktop-common
[13:06] <cjwatson> so when germinate is processing desktop-common, it doesn't yet know that notify-osd is to be preferred
[13:06] <cjwatson> (or, put another way, what handles notification-daemon in flavours other than Ubuntu?)
[13:06] <smb> pitti, And if we ever get Karmic to the other side, we can lower that barrier
[13:07] <cjwatson> changing the ddeb names for karmic is a much smaller proposition than rewriting the whole packaging, and does not depend on the latter in any way
[13:07] <cjwatson> I would have no problem with changing the ddeb names being part of an SRU
[13:07] <cjwatson> that change on its own would be effectively reviewable
[13:07]  * smb covers
[13:08] <smb> I don't want to start over on that thread. I am awaiting whatever comes from above
[13:09] <seb128> cjwatson, hum ok, thanks, what would be the best way to solve that then? having notify-osd in desktop-common could be an issue for other desktops?
[13:09] <seb128> didrocks, ^
[13:09] <cjwatson> seb128: maybe avoid using python-notify in stuff that's in desktop-common
[13:10] <didrocks> seb128: thanks, saw that, so it's an install order issue as we inferred. thanks cjwatson :)
[13:10] <cjwatson> so either rip the python-notify dep out of hplip, or move hplip to the various desktop seeds rather than having it in desktop-common
[13:10] <seb128> I think I've read pitti talking about that earlier today
[13:10]  * seb128 reads backlog
[13:10] <cjwatson> because effectively, this is happening because desktop-common isn't sufficiently self-contained
[13:11] <pitti> I'm on the phone, but I dealt with that this morning
[13:11] <pitti> brb
[13:11] <seb128> juil. 01 09:57:43 <pitti>	tkamppeter: hplip-gui is fine; the problem was that hplip itself pulled in python-notify, which caused half the desktop to appear in the server isos
[13:11] <seb128> ok, so another case of pitti fixing the bug before having it reported ;-)
[13:11] <seb128> cjwatson, thanks a lot
[13:12] <seb128> "hplip (3.10.5-3ubuntu2) maverick; urgency=low
[13:12] <seb128>   * debian/control: Drop python-notify to suggests, it's pulling half of
[13:12] <seb128>     the desktop into server images."
[13:12] <seb128> didrocks, ^ that's fixing it for the record
[13:12] <didrocks> oh nice :-)
[13:13] <tkamppeter> pitti, why did you set bug 600504 to "Fix Committed" when you have uploaded the fix already hours ago?
[13:13] <pitti> re
[13:13] <pitti> tkamppeter: since it wasn't quite correct; adding the recommends to -gui is better
[13:13] <pitti> tkamppeter: and you said that you committed that to debian/bzr
[13:13] <seb128> pitti, just for the record that breaks notify-osd on une
[13:14] <seb128> well broke
[13:14] <pitti> seb128: hplip? hardly..
[13:14] <seb128> but the bug is in alpha2 une isos
[13:14] <pitti> seb128: oh, I see what you mean
[13:14] <pitti> seb128: because hplip only got that dependency yesterday
[13:14] <seb128> pitti, it does, it brings notification-daemon in which is prefered to notify-osd
[13:14] <pitti> seb128: ok, understood; thanks for figuring out
[13:14] <tkamppeter> pitti, I have both currently both Recommends: of hplip-gui and Suggests: of hplip. I did not upload it to Ubuntu yet.
[13:15] <pitti> seb128: so this is essentially "fix committed", the next daily will have it
[13:15] <didrocks> (I have added une session to notify-osd dbus service startup so that even if it does reproduce, we won't have that later on)
[13:15] <pitti> tkamppeter: sounds fine; thanks!
[13:15] <seb128> pitti, right, and didrocks fixed notify-osd to include "une" in the list of sessions which prefer notify-osd over notification-daemon
[13:15] <pitti> splendid
[13:15] <tkamppeter> pitti, should I upload the current version into Ubuntu, so that this gets the one of a2?
[13:16] <pitti> tkamppeter: no hurry; it won't get into a2 any more anyway
[13:16] <pitti> tkamppeter: the server ISOs got respun, and their size is fine again
[13:16] <pitti> tkamppeter: and it's not a real issue for desktops, just a minor inconvenience for UNE; but it's only alpha-2
[13:17] <pitti> smb: ddeb-retriever h4ck adapted; should DTRT for jaunty/karmic/lucid/maverick now
[13:18] <smb> pitti, PHP (probably help paying) :)
[13:18] <pitti> smb: :)
[13:19] <smb> (should have meant probably helps praying, but i seem too weak to hit the keys)
[13:19] <pitti> smb: Freudian typo, eh?
[13:20] <smb> pitti, Heh, maybe. Who knows.
[13:20] <smb> Doesn't help to switch between two keyboards
[13:21] <pitti> smb: you got a new shiny ergonomic one?
[13:21] <smb> pitti, Nah, just the other one and the Thinkpad on which irc is running
[16:30] <apw> pitti, when do you do your magic for a milestone 'start' for a-3 ?
[16:30] <pitti> apw: I don't have to
[16:30] <pitti> apw: it's built into the code
[16:30] <pitti> as soon as the previous milestone ended, it's considered the start of the current one
[16:31] <pitti> so tomorrow all charts will be "clean" and trend line will be correct
[16:31] <apw> pitti, oh so it will happen automatically then, the 'clear out' for the later milestones
[16:31] <apw> awsome ...
[16:31] <pitti> this works well as long as you do the planning before the milestone starts
[16:31] <apw> pitti, yep indeed
[16:31] <pitti> apw: yes, it rewards planning which happens on time :-P
[16:37] <directhex> so when does main unfreeze?
[16:37] <directhex> i want to finish one last test-build of mono 2.6.3-3 before sending it to experimental, and merging from that
[16:38] <pitti> directhex: go ahead
[16:39] <directhex> pitti, few hours left of my test-build on agricola before it's an issue, I just wanted to check
[16:39] <directhex> ARM test-builds are slow
[17:01] <chrisccoulson> doko - do you know what creates /usr/lib/jvm/java-6-sun-1.6.0.20/jre/plugin/i386/ns7/libjavaplugin_oji.so as an alternative for mozilla-javaplugin.so on hardy? i don't see it created on my machine with all the sun-java6 packages installed
[17:02] <chrisccoulson> but some users have that selected as an alternative, which is causing some problems
[17:04] <doko> chrisccoulson: I think this is the old sun plugin, maybe we need to remove the old alternative on upgrade
[17:04] <doko> but I'm afk now
[17:06] <chrisccoulson> doko - yeah, that's what i'm thinking. do you think we should do a sun-java6 upload to remove the old alternative, and increase the priority of the libnpjp2.so plugin?
[17:07] <chrisccoulson> that's the one they should be using really
[17:07] <chrisccoulson> anyway, thanks
[18:52]  * ogra grumbles about weird cups udev rules 
[18:53] <ogra> it forcefully loads parport and lp on my ARM board
[18:58] <pitti> ogra: that's in the init script now
[18:58] <pitti> it's not really how it's meant to work indeed
[18:58] <pitti> parport_pc and parport ought to be loaded automatically via modaliases
[18:59] <ogra> pitti, well, it produces oopses on my beagleboard
[18:59] <ogra> and its pretty unlikely you will ever find a parport on arm HW :(
[18:59] <ogra> err
[18:59] <ogra> :)
[19:54] <Daenyth|Work> Hi. I'm trying to split one of the packages I maintain and the docs are a little bit confusing because they expect a handrolled debian/rules file where I have one using cdbs. I have more details posted here: http://superuser.com/questions/158689/how-to-create-a-debian-split-package-when-using-debhelper
[19:54] <Daenyth|Work> How do I need to change my rules file to get both packages built?
[20:13] <Daenyth|Work> Are there any examples of packages that are split and use cdbs like that?
[20:53] <cnd> I see that the xorg-server source package bzr branch hasn't been auto-updating right: https://launchpad.net/ubuntu/+source/xorg-server
[20:53] <cnd> does anyone know who handles these issues?
[20:56] <pitti> cnd: james_w mostly
[20:56] <cnd> pitti: ok, thanks
[21:17] <ricotz> pitti, hello
[21:17] <pitti> hello ricotz
[21:18] <ricotz> pitti, i just want to kindly remind you of docky, perhaps you can let is pass despite the lack of verifications
[21:18] <pitti> for an update of this size we should get more than just one or two "works for me"
[21:19] <ricotz> i release the new upstream version today which will be in debian/maverick soon
[21:20] <ricotz> there are a least a verfication which isnt noticed for the most serious bug https://bugs.edge.launchpad.net/docky/+bug/555562
[21:21] <pitti> ricotz: do you know some folks who are using docky and can confirm that the proposed version still works for them?
[21:22] <Laney> Me!
[21:22] <Laney> Did I verify it already?
[21:22] <Kano> hi, when will the webfrontend give results for maverick
[21:23] <Kano> i really need that info
[21:23] <ricotz> pitti, most people we are in contact with using the development or stable ppa
[21:23] <pitti> Laney: seems not
[21:23] <Laney> pitti: which is the master bug?
[21:24] <pitti> Laney: see http://people.canonical.com/~ubuntu-archive/pending-sru.html, pick one :)
[21:24] <Laney> ok then
[21:24]  * Laney blinks, that's a lot
[21:25] <ricotz> pitti, if there are regressions i think they are overweighted by bugfixes multiple times
[21:25] <pitti> small regressions perhaps, but if it stops working for someone else, it's worse
[21:25] <pitti> known bugs are better then breaking existing functionality
[21:26] <ricotz> yes, for now the keyring bug is stopping 2.0.2 from working very often
[21:26] <Kano> also could you update libdrm to 2.6.21, thats critical for libva
[21:26] <pitti> mathiaz: are you usually sponsoring landscape-client? There are two versions in -proposed, and it would be good if you could upload the current one with -v to include both changelog records; or alternatively condense them into one record
[21:27] <Kano> no git version needed, just tested the debian experimental release
[21:28] <ricotz> a
[21:28] <pitti> good night
[21:28] <ricotz> pitti, good night
[21:29] <ricotz> Laney, the next sru proposal will have 24 connected bugs
[21:30] <Laney> this is a lot of work for SRU verification
[21:30] <Laney> it'd be good if you could organise testing
[21:33] <ricotz> Laney, it is unlikely to verify all of them in a normal timeframe
[21:34] <Laney> it's not really on to subjugate the process though
[21:35] <Laney> I verified a few of the bugs
[21:36] <shadeslayer> Laney: hi
[21:36] <Laney> hello
[21:37] <shadeslayer> Laney: can you do a SRU
[21:37] <shadeslayer> https://bugs.launchpad.net/ubuntu/+source/desktopcouch/+bug/565376
[21:37] <shadeslayer> patch is attached
[21:37] <Laney> I can't upload that package :(
[21:37] <shadeslayer> :(
[21:38] <Laney> that's not a properly formatted SRU anyway
[21:38] <ricotz> Laney, of course i could through these bugs myself but this wont be real testing this should be done by real users ;-)
[21:38] <Laney> your diff should be targetted to lucid-proposed and the version should be ...3.1
[21:38] <Laney> and you need a test case
[21:38] <shadeslayer> Laney: ahh
[21:38] <ricotz> Laney, thanks for testing some of these bugs
[21:39] <Laney> ricotz: You just need to get a couple of users to test the bugs for you
[21:39] <Laney> If you call for this then I'm sure you'd get it
[21:40] <Laney> it's easier if the bugs have decent steps to reproduce in the description
[21:41] <ricotz> yeah, but i like to invest my spare time in really developing docky ;-)
[21:42] <ricotz> Laney, who is supposed to change the tag to verfication-done?
[21:43] <Laney> I'm actually not sure
[21:44] <sebner> ricotz: I've seen normal users and/or archive admin doing this
[21:44] <ricotz> ScottK, hello, can you answer this question about sru bugs? ^
[21:46] <ricotz> sebner, yeah, i have seen this, but i thought there might be a rule
[21:46] <sebner> ricotz: first come first serve maybe? ^_^
[21:48] <ricotz> Laney, sebner, i will change the tag myself for the verified ones
[21:49] <Laney> I don't know if more than one verification should happen
[21:49]  * sebner agrees with Laney 
[21:52] <ricotz> Laney, https://bugs.edge.launchpad.net/docky/+bug/582212
[21:53] <Laney> ok then
[22:33] <jdong> Hmph does Ubiquity ignore the http mirror hostname preseeded?
[22:33] <jdong> It seems to remember the directory on the server but look on CC.archive.u.c
[22:57] <jdong> hmmmm *scratches head* so what do I have to preseed to manually set the mirror?
[23:10] <dupondje> https://launchpad.net/ubuntu/+archivemirrors => who maintains this list ? there seems to be an small error in it :)
[23:37] <jdong> cjwatson: maybe dumb question, but does ubiquity not support preseeding mirror/http/hostname? It seems to always set it back to CC.archive.ubuntu.com...
[23:48] <cjwatson> jdong: you'll at least need mirror/country set to "manual" as well, but it should support it
[23:48]  * cjwatson -> bed
[23:48] <jdong> cjwatson: hmm I've got d-i mirror/country string manual set
[23:48] <jdong> and d-i mirror/http/hostname string my_host...
[23:49] <jdong> it seems to ignore mirror/http/hostname, but accept mirror/http/directory
[23:49] <jdong> (10.04)