[01:04] <ebroder> Can somebody give me a hand triaging bug #330766? It should be marked as Fix Released for Karmic, but New for Jaunty
[03:53] <tripzeroooo> anyone have experience with getting pulseaudio to work from a debbootstrapped livecd?
[04:17] <ebroder> Anybody around who could milestone bug #330766 for me? It should be marked as Fix Released in Karmic and Confirmed in Jaunty
[04:23] <dtchen> no, it should be Triaged for Jaunty
[04:24] <ebroder> Oh, right - sorry
[04:24] <ebroder> I always get those mixed up for some reason
[04:33] <maco> ebroder: id guess something to do with how some wiki pages said (say?) confirmed means enough data for a dev to start working
[04:33] <ebroder> Yeah, I know what they mean, I just keep trying to mark bugs as Confirmed for some reason
[04:39] <ebroder> Thanks, dtchen
[05:50] <dholbach> good morning
[05:56] <twb> packages.ubuntu.com:80 won't respond to me.  Is this a known issue, and if so is there an ETA on resolution?
[05:56]  * wgrant wonders why people use packages.ubuntu.com rather than Launchpad.
[05:57] <wgrant> Apart from file search.
[05:57] <ebroder> wgrant: It's harder to get some forms of information directly from Launchpad
[05:57] <twb> wgrant: because I hate launchpad.
[05:57] <wgrant> ebroder: Like?
[05:57] <ebroder> Especially if you don't know the source package off the top of your head
[05:57] <wgrant> twb: Why?
[05:57] <twb> Because it looks awful in w3m.
[05:57] <ebroder> launchpad.net/ubuntu/+source/SOURCE is amazingly helpful, but there's no equivalent of that page if you only know a binary package name
[05:58] <wgrant> ebroder: try the search box on /ubuntu.
[05:58] <wgrant> That searches binary names./
[05:58] <wgrant> See also launchpad.net/ubuntu/karmic/+package/BINARY
[05:58] <ebroder> That's one more high-latency round-trip to get the information I want
[05:59] <ebroder> I actually find launchpad.net/ubuntu/karmic/+package/BINARY to be even more useless, because it takes me 3-4 round-trips to get back the the actual useful source information page
[05:59] <ebroder> Whereas if I was using packages.ubuntu.com, the information I care about shows up on the first page load
[05:59] <twb> The other obvious problem is that it means I need to use a different workflow for Ubuntu to what I use for Debian.
[05:59] <wgrant> Have you filed bugs?
[05:59] <ScottK> p.u.c is a lot faster than an LP page.
[05:59] <wgrant> All this is being redesigned right now.
[05:59] <twb> Where they're the same, I only need to remember one workflow.
[05:59] <ebroder> wgrant: I only have time to work through so many bugs. LP bugs tend to be low on my priority queue
[06:00] <ebroder> Ugh. How did the fix for bug #251242 actually make it through SRU review? Did it ever occur that people might have /intentionally/ turned kexec on, /and you just forcibly turned it off/?
[06:01] <ojwb> it also works the same as packages.d.o
[06:01] <ScottK> ojwb: It's the same code base.
[06:02] <ScottK> ebroder: There's a process for reporting bad SRUs.  It involves writing the tech board.
[06:02] <ojwb> ScottK: yeah, I realise that
[06:02] <ScottK> OK.
[06:03] <ebroder> ScottK: Ugh. That sounds time consuming. Although right now I might be ticked enough
[06:03] <ScottK> ebroder: If no one complains, nothing gets fixed.
[06:03] <ojwb> but if you work with packages in both, it's much simpler to have a common UI
[06:03] <ojwb> that was my poiny
[06:03] <ebroder> ScottK: Point taken. I was just going to rant on the bug
[06:03] <ojwb> point
[06:03]  * wgrant points out that LP works for Debian too.
[06:03] <wgrant> Largely.
[06:03] <ScottK> wgrant: So I can wait longer for Debian stuff too?
[06:04]  * ScottK would like it if Ubuntu's rmadison service were as fast as Debian's.
[06:04] <wgrant> ScottK: I find Launchpad's distribution source package view to be significantly more useful than packages.qa.d.o.
[06:04] <wgrant> And I too find Ubuntu rmadison to be horrifyingly slow.
[06:05] <ebroder> ScottK: Re-reading the SRU policy, I'm not actually sure there's a useful followup change to make, since the SRU scribbled over user settings
[06:05] <ebroder> I may still write up a complaint, though
[06:06]  * wgrant relocates.
[06:06] <ScottK> I generally find p.qa.d.o to be within one click of whatever I want and to get there quickly.  While I agree there's more generally useful information on the LP page, it's harder to get to other stuff.
[06:06] <ScottK> ebroder: If it scribbled over user settings you should.
[06:07] <ebroder> Hmm...actually, I wonder if you can use the seen flag in debconf to recover...
[06:07] <ScottK> ebroder: If if we can't directly fix it, the process needs the feedback.
[06:07] <ebroder> Yeah, I agree. I'm filing a bug with my team that one of us should write it up "at some point"
[06:37] <dholbach> wow... there's meeeellions of sponsoring items on here: http://people.canonical.com/~dholbach/sponsoring/
[06:37] <dholbach> please let's all dive into it and reduce the number!
[06:46] <LaserJock> dholbach: have you thought about separating out process bugs (mostly syncs and merges)
[06:48] <dholbach> LaserJock: do you think that would help with anything? those bugs needs "sponsoring" too
[06:48] <dholbach> also there's no reliable way to say if a bug is a sync or merge bug (AFAIK we don't require a tag or something, but rely on the bug title)
[06:49] <LaserJock> dholbach: well, I thought maybe some people would focus on those to get rid of some low-hanging fruit
[06:50] <LaserJock> bug title should be good enough, but it's not a big deal, it just struck me that they're sort of different classes of bugs
[06:51] <dholbach> how would you like to see the "splitting out" on the page?
[06:51] <dholbach> colours? different sections?
[06:51] <LaserJock> sections I guess
[06:52] <dholbach> I'll add it to my TODO list and see what I can do
[06:52] <dholbach> but as I just got back and have thousands of emails in front of me, it might take a while :)
[06:52] <LaserJock> like "Process Bugs" and something like "Code Bugs"
[06:52] <LaserJock> of course, it'd be very much wishlist
[06:53] <dholbach> you still have to review stuff and check if it works and take a look at the code
[06:53] <dholbach> that's my only hesitation
[06:53] <dholbach> I wouldn't want to give people the impression that they need to be less careful because it's not a "code bug"
[06:56] <LaserJock> that is true
[06:56] <dholbach> but organising it a bit differently on the page should probably be fine
[06:56] <dholbach> I'll see what I can do
[06:56] <LaserJock> seems like usually process bugs require less specific knowledge
[06:57] <LaserJock> especially syncs
[07:19] <ebroder> Any backporters who can ACK bug #216761?
[07:42] <nikolam> hi.
[07:42] <nikolam> What could be done that packages.ubuntu.com don`t die that often?
[08:18] <cjwatson> nikolam: it's not maintained by anyone here; try #canonical-sysadmin
[08:38] <nikolam> 10x cjwatson :)
[09:06] <liw> hrmph, synergy and kvm don't play well together
[09:08] <soren> What's synergy?
[09:08] <soren> Oh, it's like x2x.
[09:15] <liw> possibly it's kvm and kvm not playing well together (one kvm is the software, one is the device for sharing keyboard and mouse between machines)
[09:15] <liw> (and then synergy allows me to not use the hardware kvm all the time, just for bios)
[09:16] <liw> the symptom is that the mouse in the kvm guest gets stuck in the lower right korner
[09:16] <liw> (kvm host is jaunty)
[09:19] <liw> is there a way to tell apt that a package should be marked as autoremove?
[09:22] <soren> liw: apt-mark
[09:22] <soren> liw: sudo apt-mark markauto <packagename>
[09:22] <liw> soren, thanks
[09:22] <liw> (synaptic seems to be able to do that, too)
[09:22] <soren> :)
[09:22] <soren> np
[09:37] <ogra> seb128, since yesterdays upgrade my evo only shows a blank window, any idea whats up with that ?
[09:37] <ogra> no UI elements at all
[09:37] <ogra> but also not marked unresponsive by compiz
[09:38] <seb128> ogra, no, there was an update yesterday? people were traveling, weird
[09:38] <ogra> seb128, well, i didnt upgrade since wed. or so
[09:38] <ogra> *i* upgraded yesterday :)
[09:38] <seb128> dunno, works here and we got no bug about that
[09:39] <seb128> maybe it's another of those cases were it rebuilds the index and takes a while
[09:39] <seb128> ie let it 15 minutes and see if it comes back
[09:39] <ogra> ok
[09:40] <ogra> no disk activity though
[09:44] <seb128> does anybody knows if "advocated" on REVU means "uploaded"?
[09:45] <cjwatson> could somebody review partman-iscsi in source NEW for me please?
[09:45] <cjwatson> I have an alpha-4 spec blocked on that
[09:45] <seb128> cjwatson, looking
[09:45] <cjwatson> thanks
[09:46] <cjwatson> hmm, and I'd better start writing the MIR too :-/
[09:49] <seb128> cjwatson, looks good, accepted
[09:49] <ogra> seb128, i think advocated means only read to upload
[09:50] <ogra> there is no actual indication for "uploaded" afaik
[09:50] <seb128> ogra, who does upload?
[09:50] <ogra> sponsors ?
[09:50] <ogra> i usually do an upload for people that cant if i'm the last reviewer that advocates
[09:51] <seb128> are those automatically listed on the sponsor queue?
[09:51] <ogra> but afaik there is no rule that enforces it
[09:51] <seb128> ok
[09:51] <seb128> I just don't know the workflow there
[09:53] <cjwatson> seb128: great, thanks!
[09:53] <seb128> you're welcome
[10:03] <ogra> seb128, will kill evo now, no change
[10:04] <cjwatson> seb128: ... and binaries (partman-iscsi)
[10:04] <ogra> ah, on restart it pops up a keyring question
[10:04] <cjwatson> sorry, in a rush :)
[10:04] <ogra> and UI is back
[10:05] <ogra> was probably hung in accessing the keyring ... i'll keep an eye on that
[10:05] <seb128> cjwatson, accepted
[10:05] <seb128> ogra, ok
[10:05] <cjwatson> seb128: cheers
[10:22] <soren> Can anyone think of any ill effects caused by not having a hostname set before dhcp is run? It would be rather nice if EC2 instances accepted the hostname given to them by EC2, and the easiest way to do that is to not have an /etc/hostname in the image, which causes dhclient (actually dhclient-script) to set it to whatever the dhcp server suggests.
[10:22] <soren> Alternatively, I can keep it set to the current "ubuntu" until the ec2-init thing runs and set it based on what's in the EC2 meta-data service.
[10:22] <soren> So I guess the question is: Which will cause most headache: Not having a hostname set until dhcp runs, or having one set and then changing it half way through the boot process?
[10:23] <liw> syslog wants to know the hostname, at least
[10:23] <ogra> doesnt gethostbyname() peoperly return "(none)" if the file doesnt exists ?
[10:24] <soren> ogra: Yes.
[10:24] <ogra> liw, even with rsyslogd now ?
[10:24] <liw> but syslog should work even if there is not hostname, or if it changes (not doing so is a bug, imho)
[10:24] <ogra> i thought that should fix such probs
[10:24] <liw> ogra, I'm talking about the abstract service, not the specific implementation
[10:24] <cjwatson> soren: don't suppose you know this axis2 thing that eucalyptus uses?
[10:24] <ogra> syslog used to use the ip if it couldnt find a hostname in the past
[10:25] <soren> cjwatson: For some values of, yes.
[10:25] <cjwatson> soren: I'm trying to figure out where to hook in to make it publish an avahi service on startup - is it axis2_svc_skel_EucalyptusCC_create or axis2_svc_skel_EucalyptusCC_init or somewhere else?
[10:25] <soren> cjwatson: I've got an update for it pending. They fixed a whole bunch of the problems I had with it, but not all. Some of it, they just broke in new and interesting ways, so it's a bit tricky.
[10:25] <cjwatson> I think I need to know the port number
[10:25] <soren> cjwatson: Oh.
[10:26] <soren> cjwatson: I don't know about that. I thought you were just going to use something like avahi-publish :)
[10:26] <cjwatson> well, I could, but you're only supposed to publish the service for as long as the service is actually running
[10:26] <cjwatson> so while avahi-publish is a viable fallback, it would be better to use the C avahi-client interface
[10:27] <soren> Right. upstart would be helpful there.
[10:27] <soren> Sure, sure.
[10:27] <cjwatson> I was just going to add an --enable-avahi configure option so that it doesn't become a mandatory source dep
[10:32] <mat_t> cjwatson: morning
[10:35] <mat_t> cjwatson: are we currently planning (is it possible) to hide text messages that appear during shutdown/logout?
[10:37] <cjwatson> which messages exactly?
[10:52] <mat_t> cjwatson: the console messages that appear for brief moment
[10:52] <directhex> mat_t, you mean before usplash is started?
[10:53] <mat_t> directhex: precisely (in the shutdown/restart case)
[10:54] <directhex> a bigger question is "does shutdown still take 2 minutes if you have a cifs mount in /etc/fstab?" - i meant to work on that at UDS, but other things got in the way
[10:59] <cjwatson> mat_t: not sure, they're certainly bugs; some of the work to make boot smoother might help shutdown too as a side-effect
[11:04] <ogra> can i get an archive admin to look at linux-fsl-imx51 in source NEW ?
[11:05] <ogra> preferably someone who knoes what d-i expects from the naming scheme ?
[11:05] <ogra> *knows
[11:11] <mat_t> cjwatson: I see, so they should not appear when the bugs are fixed
[11:37] <lool> cjwatson: This is the new control file http://paste.ubuntu.com/250765/
[11:37] <lool> amitk: Any reason why the new linux-image are named -babbage instead of -mx51?
[11:37] <lool> amitk: I was hoping for Lange 5.1/5.2 compat, and perhaps other devices
[11:38] <ogra> lool, i guess lange will need extra binary packages
[11:38] <lool> ogra: Which means multiple passes
[11:38] <ogra> lool, i rather doubt the choice of -fsl- in the source
[11:39] <lool> I raised this already; I don't really care about the source package name though
[11:39] <ogra> you likely need multiple passes to apply the patches at buildtime
[11:39] <lool> It's just weird to have it in half of the binary packages
[11:39] <ogra> they might break babbage binaries
[11:39] <lool> ogra: I don't see a good reason for maintaining two imx51 trees
[11:39] <lool> Or linux-images
[11:40] <ogra> well, all lange patches i saw yet apply on top of the babbage patches
[11:40] <lool> Yes, that's my point
[11:40] <ogra> but might change babbage drivers
[11:40] <ogra> which would make them not work on babbage anymore
[11:40] <lool> ogra: Might or do?
[11:41] <ogra> might
[11:41] <lool> That's very hypothetical because they dont so far
[11:41] <lool> FSL is releasing a single linux binary for multiple mx51 boards; I think we should do the same
[11:41] <ogra> right, but only fo babbage
[11:42] <lool> No,for multiple boards
[11:42] <ogra> fsl isnt releasing lange binaries to my knowledge
[11:42] <lool> That is 3stack and babbage 1, 2, and 2.5
[11:42] <ogra> right
[11:42] <lool> I don't see why we wouldn't do the same for other mx51 hardware such as langes
[11:43] <ogra> because of what i said above :)
[11:43] <lool> It's not like the patch stack for lange was huge so far
[11:43] <lool> ogra: This is hypothetical
[11:43] <ogra> you dont know if the patches will touch driver code
[11:43] <lool> And has no reason of happening
[11:44] <ogra> heh, there is so much things that have no reason of happening :) but happen anyway .... imho it would be good to be prepared for them still
[11:45] <ogra> though indeed an -imx51 binary could just grow a -imx51-lange suffix or something if thats actually needed
[11:49] <lool> I still believe we want a single kernel image for everything mx51 and I'm also worried about jaunty upgrades
[11:50] <ogra> upgrades only get painful if the meta packagename changes
[11:50] <ogra> hmm, which it does apparently, looking at the config
[11:50] <ogra> at least according to the description
[12:04] <cjwatson> lool: that's technically OK for d-i
[12:04] <lool> k thanks
[12:04] <cjwatson> lool: though it's not clear from the control file alone what the udebs will look like
[12:04] <lool> cjwatson: Not sure whether you're tempted to NEW that
[12:04] <cjwatson> I'm assuming that they will follow the usual naming scheme since it'd take special effort for them not to
[12:04] <damo22> can someone help me, i installed dbus and hal from a GIT repository and it broke my system, how do i force a reinstall the ubuntu dbus and hal?
[12:04] <lool> I have some objections but nothing which we can't live with for A4
[12:05] <lool> damo22: Look for reinstall in the apt-get man page; please move your questions to #ubutnu
[12:05] <lool> #ubuntu sorry
[12:06] <cjwatson> lool: the d-i part of it is fine; if you're happy with the rest of it then go ahead
[12:06] <lool> cjwatson: I'm happy with the rest for A4
[12:07] <lool> It's no good for upgrades and IMO we don't want per board spins but it can't be fixed for A4 and we want an image
[12:07] <lool> cjwatson: thanks!
[12:28] <amitk> lool: there is no guarantee that lange 5.x, 3stack and babbage will work from a single binary. Is there written evidence of that (guarantee) from freescale?
[12:34] <sladen> cjwatson: mvo: what's the equivalent of apt-mark to *list* a packages autoremove status?
[12:35] <sladen> cjwatson: apt-mark only appears to allow changing, not observing
[12:36] <soren> I have an upstream project that consists of a bunch of python scripts. I'm using distutils to install it (it sets the scripts kwarg to a list of all the scripts). When I put this into a .deb, I want the .py extensions to be stripped (as the scripts will be in /usr/bin).
[12:36] <soren> Is there a magic rune to pass to disutils to make it do that?
[12:36] <soren> Or should I rename them post-install from debian/rules?
[12:38] <sladen> grep -A1 packagename /var/lib/apt/extended_states...
[12:39] <sladen> soren: post-install specifcally the binaries you want included in /usr/bin since then you keep control over what goes where
[12:40] <soren> sladen: I want all of them in usr/bin. I happen to be upstream, so the project is (reasonably) well-behaved in the respect :)
[12:40] <sladen> soren: or a find debian/tmp/usr/bin -name \*.py | awk ... | xargs mv
[12:40] <lool> amitk: Do you have reasons to believe they wont?  FSL releasing a single image for all mx51 kernels is a good indication that it's possible for 3stack and babbage
[12:41] <lool> amitk: I also asked FSL explicitely about this and while they couldn't commit for the Lange boards obviously, they did say they saw no reason it couldn't be done
[12:42] <lool> s/all mx51 kernels/all FSL mx51 boards
[12:44] <cjwatson> sladen: I know of no such interface, although apt-mark is just a python-apt script and it looks like it'd be trivial to add
[12:44] <cjwatson> sladen: or /var/lib/apt/extended_states is pretty much human-readable and you could even use grep-dctrl
[12:45] <cjwatson> $ grep-dctrl -nsAuto-Installed -PX libc6-dev /var/lib/apt/extended_states
[12:45] <cjwatson> 1
[12:45] <cjwatson> though no idea if the format is guaranteed
[12:45] <sladen> yeah, just filed  bug #411369
[12:50] <gp_will_be_back> can some body pl  tell me why ubuntu default theme is god damn ugly
[12:52] <sladen> gp_will_be_back: Perhaps you could file a bug with some suggestions for improvements
[12:52] <gp_will_be_back> on lauch pad ?
[12:53] <sladen> gp_will_be_back: https://bugs.launchpad.net/ubuntu/+source/human-theme/+filebug
[12:57] <liw> gp_will_be_back, it would, however, be more productive to be polite
[13:01] <gp_will_be_back> oks
[13:01] <gp_will_be_back> filed a bug report
[13:03] <ogra> gp_will_be_back, you filed bug 411374 ? where are the suggestions for improvements ?
[13:03] <cjwatson> mat_t: FYI, I've managed to get grub to come up in graphics mode and transition smoothly to the kernel without a mode switch, but unfortunately there are some technical difficulties that mean that if anything goes wrong in early boot you'll just be left with a completely blank screen, so I don't plan to turn this on as yet. See https://lists.ubuntu.com/archives/kernel-team/2009-August/006773.html for the gory details
[13:07] <gp_will_be_back> i am trying to build ubuntu based koisk based on xul runner  ....should boot less that 5 to 10 secs ...what wm i should use ... i need minimum enviorment where firefox can show full screen ?
[13:08] <gp_will_be_back> bug 411374 ->> .please use better anti aliased fonts and icons .....please try to follow apple's HIG ...
[13:09] <sladen> gp_will_be_back: that's an interesting project, but sounds rather more like a question... please could you write it up at  https://answers.launchpad.net/ubuntu/+addquestion  with a few more details to help those who might answer it
[13:10] <cjwatson> the existing bug could be converted to a question
[13:10] <cjwatson> anything including "sucks" is unlikely to be a valid, fixable bug
[13:10] <sladen> gp_will_be_back: (the second link is for your kiosk query)
[13:10] <cjwatson> oh, right
[13:10] <gp_will_be_back> thanks
[13:12] <sladen> gp_will_be_back: but yes, for bug #411374, can you try to include some exact details.  For instance, here's a UI themeing issue I filed recently, including an annotated screenshot highlighting the issue  bug #404955
[13:13] <sladen> gp_will_be_back: if you can include that level of detail, it should be easy to fix whatever has caught your eye
[13:14] <amitk> lool: fsl might, their ODMs might not. And Lange code comes from the ODMs
[13:14] <gp_will_be_back> sladen: its general suggestion , i cant say that current theme is bug .....................but its just a feedback .....and easy to fix by downlaoding a using a new theme
[13:18] <sladen> gp_will_be_back: you should be able to select a different theme for your computer by System->Preferences->Appearance .  Or if you'd like more, by visiting http://art.gnome.org/themes .  If you find one that you think would benefit the millions of Ubuntu users, you should mention exactly which one, and why you like it and think it would be benefical
[13:19] <mat_t> cjwatson: great, thanks!
[13:20] <gp_will_be_back> sladen: i think best is conduct a pole among users (not developers ) so that they can  vote fav theme
[13:21] <gp_will_be_back> btw i heard connaical hired some UI folks ...i think they should put hiim to work ;-)
[13:22] <sladen> gp_will_be_back: then you should list (exactly) which themes should be on the pole, and where the poll would be held to attract the maximum feedback
[13:23] <sladen> gp_will_be_back: I'd like world peace too, but it's a very general wish---and do get there I need to be more specific with my desires, and cut the problem up into tiny, describle pieces
[13:23] <cjwatson> gp_will_be_back: if you want people to pay attention, my advice to you would be to avoid implying that they are lazy slackers
[13:23] <cjwatson> I don't find that to be generally a productive attitude to take
[13:23]  * ogra points out that there is no new artwork at all yet in karmic, https://wiki.ubuntu.com/KarmicReleaseSchedule will show that the first drop only lands on august 27th
[13:23] <gp_will_be_back> sladen : can ubuntu copy look and feel from apple ? is it legal with few modication
[13:24] <ogra> s/wil show/does show/
[13:25] <gp_will_be_back> copy (inspired) and extend
[13:26] <sladen> gp_will_be_back: the secret with Free Software is not just to copy;  but to fork, experiment, tweak, try things out;  and then if they work, to offer the changes back for the benefit of everyone
[13:28] <sladen> gp_will_be_back: the Human theme has survived surprisingly well---it is non-intrustive when starring at it for 90 hours a week and uses natural colours that the eye is used to dealing with (eg. not in-your-face).  Attempts at changing the theme slightly get made before every release, and sometimes they get rolled back because they didn't provide the percieved benefit
[13:29] <gp_will_be_back> yeah its forced choice on users
[13:31] <sladen> gp_will_be_back: nothing is forced;  there are other themes shipped;  there are other distributions available, and---as you've noted---there are other operating systems available (although not all of them focus on Freedom)
[13:35] <gp_will_be_back> yeah true only the default configurations can be forced if user wants he can tweak himself
[13:38] <sladen> yup, and with a Free (as in Freedom) operating system, such as Ubuntu, you have the Freedom to tweak anything because you have all of the source code, and the permissions to modify it.  I would encourage you to try and help out by making and testing changes (patches) that you think would help improve Ubuntu
[13:39] <ogra> sladen, though telling people that the work they did up to now "sucks" and is "ugly" wont help much to make you get heard
[13:42] <gp_will_be_back> please feel free to ignore this feedback , but since ubuntu tries to focus working out the box even for novice users ...i thought this may be use full ...i will try to compile list of themes which be alternative default theme on karmic kola
[13:46] <cjwatson> soren: so looking through avahi I think what I actually want to do is to udebify avahi-core, which is the stack designed for embedding - I think that'd probably be better than importing hand-written mDNS code from elsewhere
[13:47] <soren> cjwatson: Oh, sure.
[13:47] <cjwatson> soren: avahi-core doesn't depend on d-bus or glib or anything funky like that
[13:47] <cjwatson> and more to the point perhaps doesn't require an avahi daemon to be running ...
[13:48]  * sladen blinks at ogra
[13:48] <soren> cjwatson: To be honest, I only really pointed out that other thing to demonstrate that in terms of space, adding service discovery to the installer didn't have to be a big deal.
[13:48] <soren> cjwatson: I'm glad avahi provides the stuff we need.
[13:48] <ogra> sladen, i was referring to the bugtitle
[13:49] <sladen> ogra: yeah, we can work on that.
[13:49] <cjwatson> soren: it occurred to me after saying that that of course we only need to bring avahi up after network configuration and so it can be after downloading installer components - doesn't have to be initrd bloat
[13:49] <cjwatson> which was what I was really afraid of
[13:50] <sladen> gp_will_be_back: ogra and cjwatson have a very valid point;  can you try to find a word that isn't subjective and change the bug title (you can click the tiny yellow dot after the title to edit the subject line)
[13:52] <ojwb> point
[13:52]  * ojwb blinks
[13:52] <rtg> slangasek, can you process linux-fsl-imx51 ?
[13:58] <ogra> rtg, i think cjwatson was taking a look
[13:58] <cjwatson> lool already did, I thought
[13:58] <cjwatson> I just nodded in the direction of the d-i bits
[13:59] <rtg> cjwatson, I couldn't find any status on it in Launchpad, https://launchpad.net/ubuntu/+source/linux-fsl-imx51
[13:59] <cjwatson> lool: hmm, did you get distracted midway through, or did we misunderstand each other about who was processing it?
[14:05] <ogra> cjwatson, i think you did, lool is no archive admin and he mentioned in the mobile channel you would do a review
[14:05] <cjwatson> oh, hah, I forgot that
[14:05] <cjwatson> done
[14:05]  * ogra thought there was some PM going on else i would have asked again :)
[14:06] <cjwatson> BTW is linux-fsl-imx51-libc-dev really necessary? I wouldn't expect any userspace package to use that
[14:08] <rtg> cjwatson, I don't know, but I figured since the kernel sources were substantially different that it wouldn't hurt.
[14:09] <cjwatson> I processed it anyway, but I'm a bit worried people might use it ;-)
[14:10] <rtg> cjwatson, shall I remove it for the next upload? I'm sure thare will be one :)
[14:10] <rtg> there*
[14:10] <cjwatson> rtg: I think it'd be best, though no rush
[14:11] <rtg> I'd best take care of it now lest I forget.
[14:14] <lool> cjwatson: Sorry, I probably said something which lead you to think I'd process it; I'm no archive admin (albeit a surprising number of people assumed this today   :)
[14:14] <ogra> heh
[14:14] <cjwatson> no worries
[14:15] <lool> amitk: I can understand that it's heavy to bit various patch stacks for differing SoCs into sanity, but I have a harder time understanding why we'd come to a similar amount of work with various boards from the same soc
[14:19] <lool> *beat doh
[14:19] <lool> My brain's not there
[14:20] <ogra> jetlag, eh ? :)
[14:20] <lool> Yeah it's the terrible climatic difference
[14:20] <ogra> is france so hot and himid as well ?
[14:20] <ogra> *humid
[14:20] <lool> Yeah
[14:20]  * ogra felt like being struck by a hammer when leaving the plane
[14:32] <Ng> --help
[14:40] <slytherin> Can someone please give back nautilus-sendto on powerpc?
[14:43] <seb128> slytherin, are the powerpc builds fixed now?
[14:43] <ogra> ftbfs list looks like it
[14:44] <slytherin> seb128: yes they are. And this one looks like a transitional error (-dev package present, but not the corresponding version of the library).
[14:44] <seb128> right but no point to rebuild if that's going to fail on the libc errors
[14:44] <cjwatson> libc was fixed
[14:44] <seb128> tried a rebuild let's see if those are really fixed
[14:44] <cjwatson> well, worked around
[14:44] <slytherin> libc is fixed.
[14:53] <Laney> how often do failed builds get automatically given back
[14:53] <Laney> ?
[14:54] <Laney> I don't fancy manually supervising ghc6 transition on ppc
[14:56] <Laney> . o O ( edos-debcheck integration would make this super slick )
[15:02] <superm1> cjwatson, ping. i notice in karmic we've got germinate 1.17, but for 1.3 in debian you submitted a patch to adjust the behavior of following recommends if an extra clause is added to a seed or structure.  since this is already in platform.karmic, what are the effects of running an older version of germinate that doesn't support it?
[15:04] <Hobbsee> Laney: ftbfs ones?  every once in a blue moon
[15:05] <Laney> Hobbsee: seems like the ppc ones are being done more often, from the mails i'm getting
[15:06] <Hobbsee> Laney: sometimes a whole stack get given back on an arch, but it's from someone triggering it, rather than LP being automatic
[15:07] <Hobbsee> Laney: unless it's chroot wait
[15:08] <Laney> Then my question is whether this is going to continue to happen for ppc
[15:10] <cjwatson> superm1: the effect will be that Recommends are silently skipped
[15:10] <Hobbsee> i don't have the powers to do mass automated builds, and don't know
[15:11] <tkamppeter> seb128, it is about Poppler 0.11.2
[15:11] <cjwatson> Laney: is it just that the builds need to be retried in the right order or something?
[15:11] <Laney> cjwatson: right
[15:11] <seb128> tkamppeter, hi
[15:11] <tkamppeter> You have uploaded it and you have removed an important fix which I have applied.
[15:11] <cjwatson> Laney: will they misbuild if they happen in the wrong order?
[15:12] <Laney> cjwatson: they should just fail
[15:12] <Laney> due to uninstallable build-deps
[15:12] <superm1> cjwatson, so the machine that normally runs the builds of the livefs, does it have an updated germinate already, or will it be getting one before karmic is released?
[15:12] <cjwatson> superm1: karmic livefs images are built inside a karmic chroot
[15:12] <cjwatson> i.e. the livefs itself is constructed as chroot-within-chroot
[15:13] <cjwatson> superm1: IOW yes
[15:14] <cjwatson> Laney: how many times would it require throwing them all against the wall until they stick, do you think? :)
[15:14] <seb128> tkamppeter, which one?
[15:14] <superm1> cjwatson, ah okay, just a matter of time until it's pulled in then from debian
[15:14] <tkamppeter> seb128, I have done 0.11.0-0ubunu2, 0ubuntu3, and 0ubuntu4, the latter 2 are three patches which are accepted upstream, but 0ubuntu2 is a packaging fix which you have reverted with 0.11.2. I need it to build CUPS  ASAP for Alpha4.
[15:14] <cjwatson> superm1: one of us is confused
[15:15] <cjwatson> superm1: 1.3 was last year, it's been in the livefs build chroots for several release cycles
[15:15] <superm1> cjwatson, oh... so what i'm mixing up is 1.17 > 1.3.  yeah i was reading that as 1.03, my mistake
[15:15] <cjwatson> 1.17 > 1.03 too :-)
[15:16] <seb128> tkamppeter, I'm looking at that now
[15:16] <tkamppeter> seb128, your changelog looks like that you have based your 0.11.2 upload on your 0.11.0-0ubuntu1 upload and not on the newest version from the archives.
[15:16] <cjwatson> yeah, Debian and Ubuntu have the same version of germinate; I usually just upload it to both for simplicity
[15:16] <superm1> cjwatson, okay that makes much more sense
[15:16] <seb128> tkamppeter, right I didn't notice that somebody did changes to poppler while I was working on it
[15:16] <seb128> tkamppeter, fixing that now
[15:17] <superm1> cjwatson, okay so then the next question is, how would i explicitly stop the recommends from coming in for only a particular set of packages?
[15:17] <cjwatson> superm1: as far as germinate is concerned, you'd need to put them in a separate seed that doesn't have follow-recommends set
[15:17] <cjwatson> superm1: BUT
[15:17] <cjwatson> superm1: thinking about this in terms of seeds is wrong
[15:18] <cjwatson> superm1: the reason I added this feature in germinate was purely and simply to track apt's behaviour
[15:18] <cjwatson> superm1: and you can't make apt do different things for different seeds - it doesn't know about them
[15:18] <cjwatson> superm1: you need to find a different approach, where the correct behaviour is actually in the packages
[15:19] <cjwatson> superm1: while you might be able to make something work in seeds alone, it'll be fragile and you'll probably regret it later - it'll behave differently for different installation methods, etc.
[15:19] <superm1> cjwatson, i see.  particularly because you would have a different result from a built livefs, versus an alternate image, versus installing a meta or task from a debootstrapped env
[15:20] <cjwatson> right
[15:20] <cjwatson> livefs builds don't set any apt options, so they'll follow recommends for everything outside debootstrap
[15:21] <cjwatson> we do support " * Feature: no-follow-recommends" in seeds, but that's only supposed to be for the required seed, because debootstrap doesn't follow Recommends
[15:21] <superm1> ah
[15:21] <superm1> cjwatson, well then maybe you can advise what the best approach to fix the problem i'm hitting then.  mythbuntu-desktop is pulling in gdm, which recommends gnome-settings-daemon which recommends pulseaudio.  gdm recommends either gnome-settings-daemon or xfconf, but for some reason *both* gnome-settings-daemon and xfconf get pulled in
[15:22] <cjwatson> have you already tried explicitly seeding xfconf?
[15:22] <superm1> that's what i'm currently trying right now
[15:22] <superm1> i just uploaded a new meta to the archive with that change
[15:22] <cjwatson> that ought to work - if it doesn't, I think it's a germinate bug
[15:22] <cjwatson> shouldn't even need a meta, just seeding it ought to be enough
[15:23] <seb128> tkamppeter, uploaded a fixed version now
[15:23] <cjwatson> germinate is supposed to scan everything that's explicitly seeded before trying to resolve dependencies
[15:23] <superm1> well until bug 409578 gets released, i dont think i can fully trust results anyway though
[15:23] <superm1> (at least with the tasks)
[15:23] <tkamppeter> seb128, thank you.
[15:23] <cjwatson> mm, but xfconf isn't in multiverse; you should at least be able to test-run it
[15:24] <seb128> tkamppeter, no problem, sorry for dropping your changes
[15:24] <seb128> tkamppeter, do you have details on the poppler abi change btw?
[15:24] <superm1> oh right it's not.
[15:25] <superm1> then i'll give it a run with that change with it explicitly seeded and see if that's any better
[15:25] <tkamppeter> No, only thing is that Koji Otani, author of pdftopdf, told me that a changeless rebuild of CUPS fixed bug 409962
[15:26] <tkamppeter> seb128: ^^^
[15:26] <cjwatson> superm1: it's independently weird that both get pulled in, but perhaps there's some other dependency/recommendation on xfconf elsewhere
[15:26] <cjwatson> superm1: germinate will normally just pick the first one, assuming that it's satisfiable
[15:27] <seb128> tkamppeter, ok thanks
[15:27] <cjwatson> so it probably goes "gdm needs gnome-settings-daemon or xfconf, ok, gnome-settings-daemon works so I'll use that. oh, xffoo needs xfconf, so I'll use that." it doesn't know how to backtrack and optimise
[15:27] <Laney> cjwatson: (sorry, got a phone call). From http://cs.nott.ac.uk/~ial/graph.pdf (ignore the colours, they are about i386) it looks to be 7 or 8 rounds to get up to speed
[15:28] <superm1> cjwatson, yeah i think that's the scenario
[15:28] <Laney> but a lot of those are probably done
[15:28] <superm1> cjwatson, since xfce4 does depend on xfconf
[15:28] <superm1> what really throws me off is that xubuntu's builds work out fine without needing to explicitly seed xfconf
[15:29] <cjwatson> Laney: hmm, that's useful. Do you have the input file for that graph? I could cross-reference it against the out-of-date list for powerpc
[15:30] <cjwatson> superm1: I imagine that they happen to pull in xfconf somewhere before having to resolve gdm dependencies
[15:30] <cjwatson> superm1: the germinate output log probably includes a note about it
[15:31] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/mythbuntu.karmic/_germinate_output says "* Chose gnome-settings-daemon to satisfy gdm"
[15:32] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.karmic/_germinate_output has no "... to satisfy gdm" line
[15:32] <cjwatson> which implies that the alternative recommendation was already satisfied somewhere by the time that germinate got to it
[15:32] <tkamppeter> seb128, you have uploaded the new Poppler as 0.11.2-0ubuntu2?
[15:32] <seb128> tkamppeter, yes
[15:32] <Laney> cjwatson: It's pretty much grep-dctrl -FDepends -r ghc6 (but generated by a hacky script instead)
[15:33] <tkamppeter> seb128, it does not appear in Launchpad
[15:33] <seb128> tkamppeter, be patient, I got the accepted email it should be there soon
[15:34] <superm1> cjwatson, yeah from what it looks the xubuntu seed defines xfwm4 much higher, which pulls in a few things that get xfconf in the mix, and gdm is near the bottom
[15:34] <cjwatson> Laney: mm, I was hoping for one with the graph arcs already set so I don't have to redo that :-)
[15:34] <Laney> oh, right
[15:35] <cjwatson> don't you need build-depends anyway?
[15:35] <Laney> runtime depends is what we need to check for the transition
[15:35] <cjwatson> la la la. ok
[15:36]  * Laney generates the dot
[15:38] <Laney> cjwatson: http://cs.nott.ac.uk/~ial/graph.txt - is this what you're after?
[15:39] <Laney> excuse the node names...
[15:40] <cjwatson> Laney: that looks like it should be OK with a bit of postprocessing
[15:40] <Laney> I pipe it through tred | unflatten to get the output to be somewhat nice
[15:44] <cjwatson> while x="$(grep '^[0-9-].*label=' haskell-graph | head -n1 | sed 's/ \[label="/ /; s/".*//')" && [ "$x" ]; do id="${x%% *}"; name="${x#* }"; sed -i "s/$id/$name/g" haskell-graph; done
[15:44] <cjwatson> (you may vomit)
[16:02] <superm1> cjwatson, it would appear that the combination of explicitly seeding xfconf and referring to it later in the seed has done the trick.  thanks :)
[16:03] <superm1> (referring to gdm later in the seed that is)
[16:04] <tkamppeter> seb128, I have uploaded a new CUPS package now, to fix bug 409962
[16:04] <seb128> tkamppeter, thanks
[16:04] <cjwatson> superm1: cool
[16:24] <cjwatson> Laney: I've retried haskell-pcre-light as a first step although I'm not convinced that its build failure was due to prior powerpc breakage
[16:24] <cjwatson> but I guess we'll find out
[16:25] <Laney> cjwatson: The failure will be due to uninstallable deps if it's transition related
[16:25] <cjwatson> so not that
[16:25] <Laney> bah the build log is gone now
[16:25] <Laney> I guess I'll get the failure mail if it ftbfs again
[16:26] <cjwatson> mm, sorry
[16:26] <Laney> no matter
[16:27] <cjwatson> Laney: oh boy, what's the ghc6/ia64 build failure about? that causes some knock-on weirdness
[16:27] <cjwatson> cabal-bin: ghc version >=6.4 is required but the version of
[16:27] <cjwatson> /build/buildd/ghc6-6.10.4/ghc/stage2-inplace/ghc could not be determined.
[16:28] <Laney> not sure, kaol is looking into that on the Debian side
[16:28] <Laney> probably won't be fixed for 6.10.4 though
[16:28]  * directhex argues with meebey for a whopping 200k saving
[16:29] <directhex> our mono packages are anorexic, but that doesn't mean we can't slice off the occasional finger for the benefit of the weighing scales
[16:30] <Laney> beauty is happiness
[16:31]  * cjwatson nukes libghc6-harp-dev on everything but ia64 to tidy up the outdate report
[16:31] <cjwatson> retrying haskell-regex-base
[16:32] <cjwatson> (that's everything down to row 5 on the graph)
[16:41] <evand> big hugs to whomever got pixma support in sane working.
[16:41] <cjwatson> Laney: there are only 29 left out of that set you gave me. I'm just going to throw them at the wall.
[16:42] <Laney> That approach has probably got the majority of them built thus far, so sounds sane
[16:42] <ogra> heh, package pong :)
[16:45] <cjwatson> Laney: done. FYI that retried ftphs gtk2hs haskell-alut haskell-cgi haskell-configfile haskell-curl haskell-hgl haskell-hsh haskell-http haskell-irc haskell-network haskell-parsec haskell-quickcheck haskell-regex-compat haskell-regex-posix haskell-tagsoup haskell-vty haskell-x11-xft hdbc-odbc hdbc-postgresql hdbc-sqlite3 highlighting-kate hslogger kaya missingh pandoc washngo xmonad xmonad-contrib
[16:46] <Laney> excellent. Thanks very much
[16:47] <Laney> cjwatson: While you're in a haskell mood, could you process the removal of haskell-edison? bug 408569
[16:47] <Laney> also there is some stuff in binary NEW but that can wait more
[17:19] <bankix> Hi. I need some help with building packages and not breaking dependencies.
[17:19] <bankix> I've done some changes to casper to build an own live cd.
[17:21] <bankix> I could create a new, derived package (let's say: casper-1.173bankix1) with my changes, but when casper 1.174 is released, my package would be overwritten. Which I of course don't want to happen.
[17:22] <bankix> So I renamed casper to seppel, and inserted "Provides: casper" into the control file. This will create a seppel package, which provides casper.
[17:22] <bankix> If I understood right, I should be able to remove casper now and install seppel instead.
[17:24] <bankix> But when I force-removed casper (to avoid removing all depending packages) and installed seppel, lupin-casper keeps telling me he's depending on casper >= 0.98, allthough seppel 1.173 is installed and providing casper.
[17:24] <bankix> Where's my big mistake?
[17:24] <bankix> I'm working with Ubuntu 9.04 as base.
[17:26] <cjwatson> Laney: are the same binary names going to return?
[17:27] <Laney> actually I don't know
[17:27] <Laney> let me check
[17:27] <bankix> To cut it short: How do I create a derived package, containing a patched version, and avoid that it will be overwritten next time the original package is updated, and keep all the depending packages happy?
[17:27] <cjwatson> bankix: Provides can't satisfy versioned dependencies (e.g. "casper (>= 0.98)"); this is an extremely long-standing deficiency in the packaging system
[17:27] <cjwatson> bankix: you'll have to create your own version of lupin-casper too
[17:27] <Laney> cjwatson: yes, and more
[17:28] <cjwatson> Laney: would it be possible to upload the split packages first, then?
[17:28] <Laney> if that's easier
[17:28] <bankix> cjwatson: Uh.
[17:28] <cjwatson> Laney: that would save them from having to go through binary NEW, breaking builds in the meantime, etc.
[17:28] <Laney> it will have to binary NEW anyway
[17:28] <cjwatson> well, OK, but it will still be simpler :)
[17:28] <Laney> but I see what you mean
[17:28] <cjwatson> if they're just syncs, can you point me to the bugs in question?
[17:28] <Laney> haven't requested them yet
[17:28] <Laney> but haskell-edison-core, haskell-edison-api
[17:28] <bankix> cjwatson: Is there perhaps a different approach I could follow?
[17:29] <cjwatson> bankix: you might want to reexamine your comment that your package would be overwritten
[17:30] <cjwatson> bankix: when we branch Ubuntu packages from Debian, we just add "ubuntu1" etc., we don't feel we have to rename all the packages ...
[17:30] <cjwatson> bankix: you could use apt pinning (see apt_preferences(5)) to force apt to prefer the version of casper in your repository, perhaps?
[17:30] <cjwatson> bankix: that might be easier
[17:31] <bankix> Interesting point with adding "ubuntu1".
[17:31] <bankix> Will a "bankix1" prevent apt from installing casper-2.0?
[17:31] <cjwatson> bankix: of course, Ubuntu has its own archive, which makes things a bit different; we don't point apt at the Debian archive at all
[17:31] <cjwatson> bankix: if your archive is just an overlay over ours, then apt pinning is probably the only approach that doesn't involve renaming
[17:32] <cjwatson> bankix: no, the only technical effect of "ubuntu1" in our case is that it's a hint to the tools we use to autosync stuff from Debian
[17:32] <cjwatson> it doesn't affect apt
[17:33] <bankix> Okay, then my investigations regarding the suffixes were right.
[17:34] <bankix> I'm not too familiar with pinning, but would a "casper-2.0" in the ubuntu repository not overwrite the installed "casper-1.174-bankix1" although the version 1.174 is the latest in my repository?
[17:35] <cjwatson> bankix: overriding that is sort of the point of pinning.
[17:36] <bankix> Thanks.
[17:36] <bankix> I'll keep this in mind as alternative.
[17:36] <cjwatson> by default, yes, apt will behave as you describe if you have both archives present in sources.list with no additional configuration.
[17:37] <bankix> But due lupin-casper seems not to be reverenced by other packages, I'll try renaming it as well.
[17:37] <cjwatson> but it might be reasonable to use pinning to force it always to prefer versions in your overlay archive if available.
[17:37] <cjwatson> certainly what I'd do if I weren't doing a full-archive snapshot
[17:38] <bankix> BTW: How do I find out which packages have dependencies to let's say casper? Maybe I overlooked an option of dpkg-query.
[17:41] <cjwatson> bankix: you probably want the tools in the dctrl-tools package
[17:41] <cjwatson> dpkg-query can't do it
[17:41] <bankix> I'll have a look, thanks.
[17:41] <cjwatson> (apt-cache rdepends can do it, but its output is sometimes confusing. dctrl-tools is IME more useful in practice.)
[17:47] <cjwatson> could an archive admin process the new avahi binaries in the queue?
[17:47] <seb128> cjwatson, looking
[17:48] <cjwatson> I added two udebs
[17:50] <Riddell> cjwatson: are you able to tell me what I've done wrong with the kubuntu seeds?  I moved desktop/netbook common packages into a kubuntu-common seed but now germinate moans with http://paste.ubuntu.com/250920/
[17:51] <seb128> cjwatson, binaries accepted to main now (I guess you need those for the installer)
[17:55] <cjwatson> seb128: ultimately, yeah - thanks
[17:56] <cjwatson> seb128: (it's for eucalyptus which isn't yet in main)
[17:56] <ttx> slangasek: bug 385475 is now fixed, you can drop that from alpha4 release notes
[17:56] <cjwatson> Riddell: you forgot to put a line beginning with "kubuntu-common: " in STRUCTURE
[17:56] <cjwatson> Riddell: I assume it ought to depend on desktop-common
[17:57] <Riddell> cjwatson: let me try
[18:01] <bankix> cjwatson: Thanks a lot, worked fine. I just had to repack lupin-casper as well, now the package database is clean again.
[18:03] <sladen> cjwatson: -mozilla are interested in LZMA .orig source uploads;  are they still disallowed by policy (they were the last time I checked with you)
[18:04] <ogra> eeek
[18:04]  * ogra begs to not switch all the world to lzma
[18:04]  * ScottK thinks they are dissallowed by not implemented in soyuz
[18:04] <ogra> we have enough probs on armel with KDE already
[18:04] <cjwatson> sladen: yes.
[18:05] <maco> ogra: does lzma not work on arm?
[18:05] <ogra> maco, its very slow
[18:05] <maco> well it's very cpu intensive
[18:05]  * ogra points maco to http://qa.ubuntuwire.com/ftbfs/
[18:05] <ScottK> ogra: Do we need a longer timeout still then (qt4-x11 is still dead)
[18:05] <ogra> ... scroll down to "k"
[18:06] <ogra> ScottK, it is at 300 minutes already
[18:06] <ScottK> ogra: I think most of it would build if we could get Qt fixed.
[18:06] <ogra> yeah
[18:06] <jono> is anyone else having laggy OO.o problems? https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/411542
[18:06] <ogra> NCommander, was supposed to care for that
[18:06] <bankix> Ah, before I forget: Is there some sort of list which packages contain the ubuntu logos? Due to the trademark policy, I think I should better replace them.
[18:06] <ScottK> Someone should get out their stick and poke him.
[18:06] <jono> bankix, you should ask the Tech Board for that
[18:06] <ogra> he did tons of local buulds but didnt do anything to the package yet
[18:07] <bankix> jono: Hm, where do I reach them?
[18:07] <ogra> ro to the builders
[18:07] <ogra> *or
[18:07] <ogra> ScottK, if the pointy end of my stick would know where to point to in the world i would do that :P no idea wheer he is atm
[18:07] <cjwatson> err, I'm not sure why the TB is the right body to ask for a list of packages
[18:07] <jono> bankix, https://wiki.ubuntu.com/TechnicalBoardAgenda
[18:07] <bankix> Thanks.
[18:07] <ScottK> Smart of him.
[18:07] <cjwatson> jono: this doesn't need the TB surely
[18:08] <jono> cjwatson, I mean, I would think the TB should provide a list
[18:08] <cjwatson> why?
[18:08] <cjwatson> why should it be the TB *first*?
[18:08] <jono> cjwatson, who would you suggest to do it?
[18:08] <cjwatson> I'm all for one being provided, and I'm all for us doing more with the TB, but it was never a body of *first* resort!
[18:08] <ogra> cjwatson, because then jono doesnt have to :)
[18:08] <cjwatson> ask on ubuntu-devel?
[18:09] <jono> I think that trademarks in Ubuntu is generally seen over by the TB, and it could be useful for the TB to maintain a list of packages based around Trademarks
[18:09] <jono> cjwatson, fine, I don't either way who does it :)
[18:09]  * ogra finds that a tricky statement, in the end the trademark is owned by canonical, not by the TB
[18:10] <jono> ogra, good point
[18:10] <jono> so maybe trademarks@ubuntu.com could be another option
[18:10] <ogra> definately
[18:10] <ogra> that should be the first address
[18:11] <bankix> Hmmm, that adress was mentioned for questions obtaining a license or permission.
[18:11] <Riddell> cjwatson: no, that doesn't work (with the seeds)
[18:11] <cjwatson> trademarks@ will probably have no clue where it's being used in Ubuntu right now though. I suspect you're going to end up asking on ubuntu-devel for a volunteer to assemble a list anyway
[18:11] <cjwatson> Riddell: I'm just about to finish for the day; send me a mail with a reproduction recipe?
[18:11] <bankix> I see, I have to go through the files myself.
[18:11] <ogra> right, but for a user who wants to do derivetive work its the right place to ask
[18:12] <Riddell> cjwatson: ok
[18:12] <ogra> *derivative
[18:12] <ogra> (sigh, why do always i typo the long words)
[18:13] <bankix> ogra: As I understood, I need permissions only if I want to include the original trademarks, and that I won't have any chance to get such a permission when I do changes to the kernel.
[18:13] <bankix> Due I have a single line changed, I'm pretty sure not to get any permission at all.
[18:14] <ogra> might be, what changes are that ?
[18:14] <sladen> jono: if you were keeping up with the whole Ubuntu One naming incident, you may recall that of all the bodies named in relation to tradenames... it actually the CC
[18:14] <bankix> So I take the safe action and try to remove the trademarks.
[18:14] <ogra> if you add a module you might be able to rather add a dkms'ified package and not touch it at all for example
[18:14] <bankix> ogra: The patch makes built-in harddrives inaccessible to the kernel.
[18:15] <bankix> No, it's a patch to libata.
[18:16] <ogra> another possibility would be to discuss your patch on the kernel ML and eventually get it included so you could switch it on as kernel cmdline option
[18:16] <jono> sladen, ahhh yes, you are right
[18:16] <bankix> ogra: No, I don't think there is general use for this patch. And it wouldn't help me for 9.04.
[18:16] <ogra> indeed
[19:20] <debfx> is the /usr/share/xserver-xorg/pci/*.ids video driver auto-detection disabled in karmic?
[19:27] <tjaalton> debfx: yes
[19:29] <debfx> tjaalton: is it going to stay that way / should I remove the .ids file from the virtualbox package?
[19:31] <tjaalton> debfx: yes it is. does it autoload the correct driver without the .ids?
[19:32] <tjaalton> doesn't look like it would
[19:32] <debfx> tjaalton: no it doesn't load it with or without that file
[19:32] <tjaalton> check how it's done in hw/xfree86/common/xf86AutoConfig.c and file a bug with a patch :)
[19:32] <debfx> patch from fedora fixes that: http://cvs.fedoraproject.org/viewvc/F-11/xorg-x11-server/xserver-1.6.2-vboxvideo.patch?revision=1.1&view=markup
[19:32] <tjaalton> ah, good
[19:33] <tjaalton> file a bug against xorg-server and it'll be fixed before too long
[19:33] <tjaalton> debfx: are you maintaining vbox?
[19:34] <tjaalton> er, updating
[19:34] <debfx> i'm collab maintaining it at debian and have done some sponsored uploads in ubuntu
[19:36] <debfx> yeah i'm removing it with the v3.0.4 merge
[19:36] <tjaalton> ok, there are some issues with it making x crash when the vbox driver is first installed, and triggering apport to file bugs
[19:36] <tjaalton> maybe if you had a clue about those..
[19:41] <debfx> tjaalton: is it possible to also trigger the virtualbox apport hook when the vboxvideo driver is used?
[20:36] <tjaalton> debfx: I guess, don't know how that works
[20:42] <seb128> is there any arch where uint are not 32bits?
[20:44] <cjwatson> seb128: not in Ubuntu (or Debian), but the C standard certainly permits it
[20:44] <seb128> ok, because pango upstream changed a guint32 to guint in a public structure
[20:45] <seb128> I'm pondering whether that should be considered as an abi breakage
[20:45] <seb128> they seem to know about it and have decided it should not be an issue
[20:46] <cjwatson> not for us, at least
[20:47] <seb128> ok thanks
[20:51] <sebner> cjwatson: grub2 ftw! :)
[21:06] <tkamppeter> superm1, hi
[21:06] <superm1> hi tkamppeter
[21:06] <tkamppeter> superm1: I have fixed a bug in Bluez, bug 411610
[21:07] <tkamppeter> Bluetooth printer setup did not work for years, I have fixed it now.
[21:08] <superm1> tkamppeter, awesome :)  Would you mind submitting that patch to the core code to linux-bluetooth@vger.kernel.org, and once they ack it, i'll upload the debdiff?
[21:08] <tkamppeter> Can you apply my debdiff and upload the package (I have now upload rights for bluez, I have only per-package upload rights for the printing stack).
[21:09] <tkamppeter> superm1, it would be great if you upload it already, so Alpha 4 users will already have a great Bluetooth experience.
[21:09] <superm1> tkamppeter, yeah it looks harmless enough I suppose.  can you at least submit it upstream in parallel then?
[21:10] <tkamppeter> As it is 100% upstream problems (no packaging or so) I will submit it upstream in parallel.
[21:10] <superm1> great thanks :)
[21:17] <chrisccoulson> hey cjwatson - are you still experiencing bug 391559?
[21:19] <cjwatson> chrisccoulson: I don't know, it's not exactly something I encounter in my daily work - did you never manage to reproduce it using the recipe I gave?
[21:19] <chrisccoulson> cjwatson - i didn't. were you using metacity or compiz though?
[21:20] <chrisccoulson> if it's metacity, then i have a likely idea what's causing it
[21:20] <cjwatson> chrisccoulson: metacity, IIRC
[21:20] <cjwatson> chrisccoulson: simply installing from the live CD in a VM and watching closely towards the end ought to provoke it, although it takes a while
[21:20] <cjwatson> I'm fairly sure I was just using kvm
[21:21] <chrisccoulson> metacity pops up a dialog on shutdown in recent versions, notifying of any windows that don't properly support  session saving
[21:21] <cjwatson> although I also tested it with just a terminal and python
[21:22] <chrisccoulson> and it still appeared?
[21:29] <cjwatson> chrisccoulson: yep
[21:36] <dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 <- could some dev look @ this ? its kinda annoying bug
[21:38] <chrisccoulson> cjwatson - do you remember what terminal that was with (eg, gnome-terminal or xterm)? or if any other windows were open?
[21:41] <cjwatson> chrisccoulson: gnome-terminal, nothing else open
[21:42] <chrisccoulson> thanks - so it probably isn't the metacity issue i was thinking about, as gnome-terminal shouldn't be affected by that
[21:42] <chrisccoulson> at least that is one thing ruled out now
[21:49] <cjwatson> chrisccoulson: that's my memory, anyway. It was a while ago
[21:50] <chrisccoulson> thats ok, thanks. i'll try and trigger it again sometime when i get the chance
[21:53] <spotter> seb128, in popping into #poppler it seems they are against their dev versions being used in a distribution, they don't make any claims of compatibility/abi stability within a dev version
[21:53] <seb128> spotter, thanks
[21:57] <seb128> spotter, who commented about that and was that recently?
[21:57] <spotter> this morning
[21:58] <spotter> logs show pinotree
[21:58] <seb128> ok thanks, morning is a fuzzy concept with timezones ;-)
[21:58] <spotter> 7 hours ago or so?
[21:58] <seb128> ok
[21:58] <spotter> maybe 5-6?
[21:59] <seb128> in any case cups got rebuilt
[21:59] <seb128> which workaround the bug
[21:59] <spotter> works around what bug?
[21:59] <spotter> probably doesn't help my pdflatex bug?
[21:59] <seb128> pdflatex is probably in the same case
[21:59] <seb128> needs a rebuild because poppler changed soname
[22:00] <spotter> though after today i wont care for a couple of weeks, just have a paper due today
[22:00] <seb128> I would do it if latex was not takes ages to download
[22:00] <spotter> :)
[22:00] <seb128> or build
[22:00] <spotter> I'm just using old version right now to build
[22:00] <spotter> though can't print reliably (unsure why, even from acroread, generated ps files just fine)
[22:00] <Lure> asac: firefox 3.5 again pulls lot's of gnome packages if installed on kubuntu - I thought this was fixed properly for 3.0, but somehow dropped for 3.5
[22:01] <tkamppeter> superm1, thanks for the bluez upload.
[22:01] <spotter> but can manage well enough to get paper submitted
[22:01] <Lure> asac: --no-install-recommends is a workaround, but probably not perfect
[22:01] <Ampelbein> spotter: seb128, maybe this is solved by sponsoring bug 410242
[22:02] <seb128> Ampelbein, could be but as stated before my bandwith suck and this pages takes ages to download
[22:02] <seb128> so I will let somebody with fast internet do that
[22:03] <Ampelbein> spotter: can you try texlive-bin version in https://edge.launchpad.net/~amoog/+archive/amoog-devel ?
[22:03] <superm1> tjaalton, np
[22:03] <spotter> Ampelbein, tomororw :)
[22:03] <spotter> not messing w/ my tex w/ 3 hours to deadline
[22:03] <Ampelbein> spotter: sure, no problem
[22:03] <Ampelbein> ;-)
[22:06] <spotter> though if you guys come to debconf10 you can see my research, as it appears we are hosting it
[22:06] <spotter> though I will hopefully no longer be there
[22:08] <spotter> anyways, back to work
[23:13] <hdon> hi all. i am fighting audio latency in Jaunty. i have read a few experiences of people with similar problems, but the proposals for solutions, and the blame for the latency, are anything but clearer.
[23:15] <hdon> i've noticed that sometimes my programs notify me on stdout/stderr of a buffer underrun. i'm thinking, alsa, or pulseaudio (i'm not really sure what the architecture is like, exactly) is increasing the buffer size automatically when an application doesn't fill the audio stream fast enough.
[23:15] <hdon> does anyone have any experience to guide me on my quest for low audio latency?
[23:27]  * cjwatson writes the necessary bits to be able to reduce *-meta/debian/rules to '%:\n\tdh --with germinate $@'
[23:29] <cjwatson> hopefully will eliminate some sources for error - there was a bit of duplicate configuration required in *-meta/debian/rules until now
[23:32] <Ampelbein> hey there. can some core-dev take a look at bug 410242? The rebuild is also needed to fix some FTBFS, notably octave3.2.
[23:36]  * TheMuso waves
[23:37]  * chrisccoulson waves at TheMuso
[23:45] <slangasek> rtg: looks like someone took care of linux-fsl-imx51 already, yes?
[23:46] <slangasek> ttx: could you edit https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview to remove the reference to bug #385475 then, please?