[09:22] <tsdgeos> alf_: are you sure it's not mir leakign those fd's?
[09:22] <tsdgeos> action_queue.cpp creates an eventfd that i don't immediately see being closed
[09:22] <tsdgeos> same for threaded_dispatcher.cpp
[09:23] <alf_> tsdgeos: not 100%, but I ran similar tests with a pure mir server and clients and there were no such leaks
[09:25] <alf_> tsdgeos: @action_queue,threaded_dispatcher the fds are stored in a mir::Fd object which closes the fd on destruction
[09:27] <tsdgeos> k
[09:33] <ktatar156> Hello
[09:33] <ktatar156> According to https://lists.launchpad.net/ubuntu-phone/msg15527.html
[09:34] <ktatar156> could anyone help me asap? It's really important for me to get phone number that I mentioned in emails OTA-6 MX4 big problem
[09:38] <alf_> ktatar156: We are investigating what's going on, but this seems difficult to reproduce.
[09:38] <ktatar156> Ok, working again, after ~20 shutting off and on or restarting.
[09:38] <ktatar156> Is there any information that I can provide?
[09:39] <alf_> ktatar156: Some questions that would be helpful to answer: 1. when touch stops working, can you turn the screen on and off with the power button?
[09:39] <ktatar156> Yes
[09:40] <alf_> ktatar156: 2. When this happens, did you received any messages or other notifications just before?
[09:44] <ktatar156> Yes
[09:44] <ktatar156> But
[09:44] <ktatar156> after call I put my phone into pocket. Checked it after few minutes. Try to unblock phone (entered 3 digits) and after that it stopped working
[09:45] <ktatar156> WiFi off, BT off, GPS on all the time, mobile data off
[09:47] <ktatar156> F###, Again. I had conversation 2 minutes ago
[09:47] <ktatar156> and touch is blocked again
[09:49] <ktatar156> Because It happens so many times, when I will go back into home, I will record video with that and show as many information as can
[09:52] <guest42315> ktatar156, if you take a screenshot of Apps Scope (volume up + down) does the UI freezes for like 5-6 seconds?
[09:53] <ogra_> alf_, there are a lot more input probs on arale ... not as bad as the above, but i often have it that an app doesnt take input at all anymore and it starts working again after i minimally swiped in the spread from the right ... and then there is bug 1494770
[09:53] <ogra_> alf_, the one big difference on arale is the home button and the code to handle it ... i wonder if that causes Mir or unity input issues here
[09:57] <guest42315> ogra_, something weird happened to me yesterday, opened telegram and i got the spinning circle (but not spinning) and the UI froze. i thought it's apport acting silly so i let it finish for 15 minutes. in the first 5 minutes the home button led responded to touch, and i could feel the vibrations when touching the screen with UI still frozen. after 5 minutes the touch input stoped working and i finally rebooted the phone after 15 minutes
[09:58] <guest42315> mx4 stable
[09:59] <ogra_> guest42315, did you try other UI elements (expanding the panel or right swipe) ?
[09:59]  * guest42315 aw-food
[09:59] <guest42315> ogra_,  yes, nothing worked
[09:59] <guest42315> brb
[09:59] <guest42315> food :P
[09:59] <ogra_> enjoy
[10:04] <ktatar156> guest42315, yes.
[10:06] <guest42315> ogra_,  thanks :D grabbed some milk and cookies
[10:08] <guest42315> ktatar156, can you please confirm/mark as it also affects you here https://bugs.launchpad.net/canonical-devices-system-image/+bug/1494480 ?
[10:27] <ktatar156> alf_ do you need another information?
[10:28] <alf_> ktatar156: no, that's enough for now, thanks. A video showing the problem would be helpful if you can get it and attach it to the bug.
[13:40] <desrt> RAOF: don't suppose you're still awake :)
[14:03] <desrt> so... i got this problem from mir
[14:03] <desrt> terminate called after throwing an instance of 'std::out_of_range' what():  _Map_base::at
[14:03] <desrt> Aborted
[14:04] <desrt> and the backtrace is pretty much useless... the abort is on a thread and all i see is pthread calling libstdc++ code which is directly calling the throw/abort stuff
[14:04] <desrt> probably because something nested threw the exception....
[14:04] <desrt> and it got caught by the threading code and aborted from there
[14:04] <desrt> any help?
[14:06] <desrt> ahh... hello gdb "catch throw"


 sure, thanks (re @lubuntu_bot: (irc) <tomreyn> ciKRos: I bet there are books on Xorg, maybe also on openbox and lxqt. i'm not sure whether there is much about the combination of these.)
 is there any alarm apps for lubuntu, i missed that feature on old Windows
 You can use kalarm (re @ciKRos: is there any alarm apps for lubuntu, i missed that feature on old Windows)
[14:09] <dragon_> command list


[12:44] <superm1> cjwatson, sure i'd be glad to, how do i revert the revision?
[12:56] <CIA-18> ubiquity: superm1 * r2256 ubiquity/ (4 files in 4 dirs): revert non critical changes from r2255 until after beta
[08:57] <spam> hi there....
[09:01] <spam> i have using ubuntu installer ..and doing some study on this.Can anybody tell me how does it check internally the distribution name and version name so that if proper repository address has not given it shows error.."invalid repo link" or "release file missing'
[09:02] <spam> during mirror selection stage at the installation process
[09:09] <spam> is there anybody...
[09:36] <cjwatson> spam: could you tell me the exact message, please? Don't paraphrase
[09:36] <cjwatson> spam: at any rate, it looks in the Release file on the mirror
[09:37] <cjwatson> which has various metadata like that
[10:33] <spam> cjwatson..:"the specified ubuntu archive mirror is either not available,or doesnot have a valid Release file on it.Please try a different mirror"
[10:36] <spam> Cjwatson: r u there..? i was out of system....but i want to know what udeb does this checking during mirror selection stage.I checked one udeb is there"choose-mirror" is it the only mirror which checks the release file on the mirror?
[10:48] <cjwatson> spam: yes, choose-mirror (and choose-mirror-bin, which comes from the same source package) is the one you're looking for
[10:49] <cjwatson> spam: please don't do the "are you there" thing, by the way - I'm extremely busy this morning and it may take me a while to respond
[10:52] <spam> cjwatson:actually my problem is some what different. I have created one local repository and from there i am installting my softwares..no problem i am facing but i have given my version name."my-ver".So when installer is checking for version /code name the error is coming.
[10:54] <spam> so where i need to change exactly..as i changed the string name mentioned in "choose-mirror" pkg source code and after successful comilation i have included that one in the installer and compile it successfully,...no problem came but the same problem persist for choosing mirror.
[10:54] <cjwatson> do you have dists/*/Release files on your mirror?
[10:55] <spam> yah...and exactly in the same order.only the string is different
[10:55] <cjwatson> exactly where is your Release file? what directory?
[11:01] <spam> is it ok/
[11:02] <spam> /my-distro///dists//my-ver//Release
[11:02] <spam> same what debian repository follows...
[11:04] <spam> and when it fails i went to shell prompt and from there i tried to connect the specified location using wget ..and i got success
[11:04] <cjwatson> did you preseed mirror/suite=my-ver?
[11:04] <cjwatson> or otherwise change the installer's default suite to retrieve
[11:05] <cjwatson> (e.g. by changing /etc/lsb-release in the initrd)
[11:05] <spam> the first few line r like..
[11:05] <spam> Architectures: i386
[11:05] <spam> Codename: anant
[11:05] <spam> Components: main
[11:05] <spam> Date: Wed, 29 Aug 2007 10:24:05 UTC
[11:05] <spam> Description: BOSS Anant Repository
[11:05] <spam> Label: anant
[11:05] <spam> Origin: boss
[11:05] <spam> Suite: unstable
[11:05] <spam> Version: 2.0
[11:05] <spam> MD5Sum:
[11:05] <cjwatson> that Suite: is bogus
[11:05] <cjwatson> it should match the subdirectory of dists/
[11:06] <spam> that means in this case it should be anant ??
[11:06] <cjwatson> if that file is in dists/anant/Release, yes
[11:06] <cjwatson> you also need to change the installer to look there; it can't guess that it needs to retrieve dists/anant/Release by magic
[11:06] <cjwatson> changing /etc/lsb-release in the initrd is the easiest way
[11:07] <cjwatson> I suggest reverting whatever changes you made to choose-mirror, as that shouldn't be necessary
[11:07] <spam> yah..thats it..
[11:08] <spam> ok..but when i am choosing "enter manually.." option for mirror selection then also do i need to modify the d-i?
[11:09] <cjwatson> "enter information manually" lets you choose the hostname and directory, not usually the suite
[11:09] <cjwatson> you can avoid modifying the initrd by putting mirror/suite=anant on the kernel command line, if you prefer
[11:12] <spam> will it be ok for my case if other parameters are same as in debian in my local mirror?
[11:14] <spam> can i set "mirror/suite=anant" inside default file for PXE net booting installation/
[11:16] <spam> default file is in "ubuntu-installer/i386/pxelinux.cfg/default" which is the default configuration file...
[11:16] <spam> or i am missing something?
[11:16] <cjwatson> parameters> that's too general a question so I can't be sure. Try it :-)
[11:18] <cjwatson> yes, you can set it on the appropriate 'append' line in pxelinux.cfg
[11:18] <spam> yes .i got it.
[11:19] <spam> thanks..for your help.let me try this one
[11:29] <xivulon> cjwatson, evand, had little time this w/e and almost no internet connection, would like to catch up briefly on any progress you have made
[11:29] <xivulon> tonight I'll download and test the new image
[11:30] <cjwatson> aside from what I told you about Friday's work, I have almost entirely been panicking about other things
[11:32] <CIA-18> ubiquity: cjwatson * r2257 ubiquity/ (configure configure.ac): bump to 1.5.18
[11:35] <xivulon> cjwatson, is grub safe in loopinstallations?
[11:35] <xivulon> I'd like to start having more people involved in the testing process, it does not matter if they do not end up with ubuntu installed, but at least the should not find their MBR overwritten
[11:36] <xivulon> Did not go that far in the installation process myselef on friday, but noticed that "install grub in hd0" was selected when I got stack at the "ready to install" page
[11:40] <cjwatson> I haven't got that far in my testing
[11:41] <xivulon> np will give it another go tonight
[11:41] <cjwatson> oh, no, it isn't yet
[11:41] <cjwatson> it needs a wubi change
[11:41] <cjwatson> I'll commit that shortly
[11:41] <cjwatson> I added a preseeding facility which should make it safe, but wubi needs to use it
[11:42] <xivulon> are you goint to merge into wubi branch? I can only do that tonight
[11:42] <xivulon> To build wubi, remove the nsis fodler, and run "make clean; make prerequisites; make all"
[11:43] <xivulon> You only need "make all" once if plugins are cleaned/modified, to rebuild wubi itself, make is enough
[11:46] <xivulon> The other question which we left pending was whether Ubiquity can simply skip mounted devices/partitions (except when loopinstalling)
[11:46] <cjwatson> I've committed it straight to the wubi branch
[11:46] <xivulon> thanks
[11:47] <cjwatson> I'm not going to attempt to build it though, I'm not convinced enough that I can do that correctly
[11:47] <cjwatson> skip mounted devices/partitions> sorry, I don't know what you mean
[11:47] <xivulon> I assume that ubiquity at some stage prepares a list of partitions (and devices)...
[11:48] <xivulon> If some of those was already mounted, and we are not in a loopinstallation, would it be possible to skip it?
[11:49] <xivulon> I am not sure whether this is already current behaviour
[11:49] <cjwatson> I still don't quite understand what problem you're trying to solve
[11:50] <xivulon> The issue is to go around wubi read-only mode, but would also help when a LiveCD user had the windows partition mounted and then run Ubiquity targeting that partition
[11:50] <cjwatson> but what is the problem?
[11:51] <xivulon> If a partition is mounted it cannot be resized online
[11:51] <cjwatson> that is, what undesirable thing happens that you want not to happen?
[11:51] <cjwatson> oh, you mean in the manual partitioning UI?
[11:51] <xivulon> So for instance in read-only mode you have /isodevice mounted. I'd still want users to run ubiquity to be able to install on a different partition
[11:52] <cjwatson> I imagine the partitioner will simply not allow that. I don't think removing it from the manual partitioning UI is a good idea though; it would be very confusing to have only part of the disk listed
[11:52] <cjwatson> in any event, that's post-beta
[11:52] <xivulon> cjwatson "simply not allow that" is more than good enough
[11:53] <cjwatson> one problem is that it might allow resizing other partitions
[11:53] <cjwatson> on the same disk
[11:53] <cjwatson> or creating/deleting partitions
[11:53] <cjwatson> none of that will work if a partition is mounted
[11:54] <xivulon> Is modifying other partitions a problem? (change in partition table are not well digested maybe)?
[11:54] <cjwatson> it is not possible to make any changes to the partition table when the disk is locked, which will be the case if anything is mounted from that disk
[11:55] <cjwatson> well, you can change the partition table, but the kernel will refuse to reread it until you reboot
[11:56] <xivulon> Makes sense, even in this case though, Ubiquity has still a use though if the user pre-partitions the drives or already has a (non-mounted) partition to be overwritten.
[11:56] <xivulon> Or if the target partition is on a different device
[11:56] <CIA-18> ubiquity: cjwatson * r2258 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[11:56] <CIA-18> ubiquity: * GTK frontend:
[11:56] <CIA-18> ubiquity:  - Make release notes button work again (LP: #138365).
[11:56] <cjwatson> right, it isn't useless, but it does need to be made clear in the UI
[12:00] <xivulon> I'd do so that if a device is mounted the user can only pick free/space or an existing partition to install into
[12:00] <xivulon> Anyway don't what to distract you too much with that
[12:02] <cjwatson> free space won't work either
[12:02] <cjwatson> unless it's on another disk
[12:12] <xivulon> Just a list of available (non-mounted) partitions then (but I guess that splitting root and swap would be a problem).
[12:13] <xivulon> What about doing the partitioning and then forcing a reboot?
[12:20] <cjwatson> too horrible for words
[12:25] <xivulon> ahah
[12:25] <xivulon> I agree
[12:45] <xivulon> cjwatson, last try: partprobe
[12:45] <cjwatson> ?
[12:46] <xivulon> http://www.cyberciti.biz/tips/re-read-the-partition-table-without-rebooting-linux-system.html
[12:53] <cjwatson> xivulon: partprobe isn't magic; it's just a userspace program (and the same libparted calls are already made by the installer). That article is incomplete
[12:54] <cjwatson> xivulon: if the kernel refuses to reread the partition table because the disk is locked, no userspace program can possibly help
[12:59] <xivulon> makes sense
[01:08] <xivulon> http://lkml.org/lkml/2006/9/8/46 and http://www.gelato.unsw.edu.au/lxr/source/include/linux/blkpg.h
[01:08] <xivulon> could it be that there is some in-kernel support which is simply tapped by userspace toos?
[01:09] <cjwatson> not as far as I can see
[01:09] <cjwatson> I would rather you tried it than that you pasted URLs here :-)
[01:10] <xivulon> I wish, but have to use a windows machine during the day
[01:10] <cjwatson> it may be true that you can get away with BLKPG_ADD_PARTITION (which libparted already uses) if that specific partition isn't in use
[01:11] <cjwatson> it's risky for a partitioner to rely on the exact details though
[01:11] <cjwatson> particularly if any kind of resizing or insertion of partitions is involved
[03:12] <evand> weird, I could have sworn that the linkbutton issue was a GTK+ bug.
[03:13] <evand> but I suppose I was just not setting it up correctly.
[03:13] <cjwatson> I think the code fell out during the automation rearrangements; it was there originally
[03:13] <evand> yikes, sorry
[03:13] <cjwatson> no worries, caught it
[05:18] <superm1> yeah i had thought it was a GTK+ bug too, i had another pyGTK app that it randomly showed up in too.  i guess i'll have to take a look at your fix for it
[05:19] <cjwatson> you just need to do gtk.link_button_set_uri_hook(some_function)
[05:19] <cjwatson> gtk.LinkButton doesn't know how to launch a browser itself because that's pretty system-specific
[05:19] <superm1> so it doesn't by default call /usr/bin/sensible-browser then?
[05:19] <cjwatson> no
[05:20] <cjwatson> there's some argument that it should but then your application would still break on other systems ...
[05:27] <CIA-18> ubiquity: evand * r2259 ubiquity/ (debian/changelog ubiquity/osextras.py): * Fix typo in realpath_recurse (LP: #144460).
[05:28] <evand> Launchpad Janitor angers me.
[05:29] <evand> Though I suppose this can be fixed with a capital D
[05:45] <evand> cjwatson: now that we have ubiquity-dm, should we make that an option in isolinux in Hardy or document it as a kernel cmdline option?
[05:46] <cjwatson> something like that in hardy, yeah, though in that case it needs to not use --automatic
[05:46] <evand> indeed
[06:01] <evand> Is there some magic I can do to get past the partman crash with the latest daily cd and wubi?
[06:02] <cjwatson> which partman crash?
[06:03] <xivulon> ?
[06:03] <evand> reproducing...
[06:15] <xivulon> cjwatson, evand, if it may help with development, at this stage you can copy the ubuntu folder into a VM (ext3) drive and set the VM bootloader use the configfile in ubuntu/install
[06:19] <cjwatson> personally I don't have time to do anything other than get the standard installation flow working
[06:21] <evand> "The filesystem ntfs cannot be mounted on /, because it is not a fully-functional Unix file system."
[06:21] <evand> Clearly I must be doing something wrong
[06:21] <evand> that only started to appear after I canceled and ran ubiquity manually using -d and --automatic.
[06:21] <cjwatson> hmm
[06:22] <cjwatson> what build?
[06:22] <evand> wubi: the one from friday, ubiquity 1.5.17
[06:22] <cjwatson> hmm, that was supposed to be fixed in .17
[06:22] <cjwatson> why is it trying to mount an ntfs filesystem on / ?
[06:23] <cjwatson> oh, unless ...
[06:23] <cjwatson> evand: can you get ps ax output from when that happens and see if autopartition-loop is there?
[06:25] <evand> will do
[06:27] <evand> doesn't appear to be
[06:27] <cjwatson> hm
[06:27] <cjwatson> ok, not what I thought then
[06:28] <cjwatson> can you see what the innermost running partman script is?
[06:28] <cjwatson> ps axf may help
[06:30] <evand>  check.d/08mountpoint_fat
[06:31] <cjwatson> evand: ls /var/lib/partman/devices/*/*/mountpoint
[06:31] <cjwatson> err, maybe not quite that
[06:31] <cjwatson> grep -H '^/$' /var/lib/partman/devices/*/*/mountpoint
[06:32] <evand>  /
[06:32] <cjwatson> I'm looking for filenames under /var/lib/partman/devices
[06:32] <evand> well, /var/lib/partman/devices/=dev=sda/32256-17873533439/mountpoint;/
[06:33] <cjwatson> no others?
[06:33] <evand> nope
[06:33] <cjwatson> are you following what I'm looking for here? it may be easier for you to take it from here
[06:34] <evand> no, sorry I don't follow
[06:34] <cjwatson> partman-auto-loop 0ubuntu9 (included in ubiquity 1.5.17) added 'rm -f $partition_id/mountpoint' because the host NTFS filesystem shouldn't really be mounted on /
[06:35] <cjwatson> partman-auto-loop temporarily tells partman that that filesystem is mounted on / in order that it can use the mount.d scripts to mount it
[06:35] <cjwatson> but it's supposed to clean up after itself
[06:35] <cjwatson> the real / in a wubi install ought to be a loop-mounted filesystem
[06:35] <evand> I think this is my fault.
[06:35] <cjwatson> i.e. =dev=loop2 or something not =dev=sda
[06:35] <cjwatson> oh, it could be that you didn't clean up all the way after cancelling, maybe?
[06:35] <evand> I ran the install, partman crashed, and I hit cancel instead of continue.  This brought me back to the desktop.
[06:35] <evand> Exactly
[06:36] <cjwatson> (remember my comments from Friday where I was doing losetup and stuff)
[06:36] <evand> indeed, I just realized I should have ran that
[06:36] <evand> taking care of that now
[06:37] <evand> sorry for the false alarm
[06:37] <cjwatson> it's certainly harder to clean up than it ought to be
[06:37] <cjwatson> I think that is a bug, it's just awkward to fix
[06:42] <evand> cjwatson: have you gotten through a full install yet?
[06:50] <cjwatson> no :-(
[06:50] <CIA-18> ubiquity: cjwatson * r2260 ubiquity/ubiquity/osextras.py: fix realpath_root a bit more so that it really returns something prefixed with root
[06:50] <evand> I got close
[06:51] <evand> at least to the formatting stage
[06:51] <evand> but then it decided it had enough of life and hard locked
[06:51] <cjwatson> sigh
[06:51] <cjwatson> memory?
[06:51] <evand> are you asking how much I was giving it?  about 768MB
[06:52] <cjwatson> huh
[06:52] <evand> I'm going to try again with htop running in the background
[06:52] <cjwatson> I guess it's unionfs then
[06:52] <evand> ah
[06:52] <evand> any updates from pkl?
[06:52] <cjwatson> he's off ill
[06:52] <cjwatson> I've asked Ben to take over
[06:52] <evand> uh oh
[06:52] <evand> oh, ok
[06:53] <evand> I was unaware that ben knew the unionfs internals, but I suppose that doesn't matter when you're king kernel hacker
[06:53] <cjwatson> I don't think he does much
[06:53] <cjwatson> but pkl gave a relatively detailed description of what he was doing the other day
[06:54] <evand> ah, good
[07:09] <evand> ugh, I think you're right about the hard lock being unionfs
[08:05] <cjwatson> meh, wubi was broken by our CD designation switching from Alpha to Beta
[08:05] <cjwatson> how fragile
[08:10] <cjwatson> evand: when xivulon returns, would you ask him to rebuild wubi urgently, and when that's done rebuild the live CDs?
[08:10] <cjwatson> I've committed the relevant fix
[08:12] <cjwatson> I'm off for a few hours now
[08:13] <evand> cjwatson: will do
[08:13] <cjwatson> thanks
[08:13] <evand> no problem
[08:28] <evand> cjwatson: I'
[08:28] <evand> whoops
[08:29] <evand> cjwatson: I'm not a RM by any means, but at what point does the beta release get pushed back on account of these unionfs bugs
[08:29] <evand> or can we go down to the 11th hour on that one
[09:45] <evand> cjwatson: I have a fix for checking to see if we're running in automatic mode.  Basically, m-a.py sets a flag when it gets handed a question and if that flag is not set when it gets to the point where it would normally dive into the gtk loop, then it doesn't have any questions to ask, so it returns self.succeeded.
[09:45] <evand> It's pretty much the same thing as checking for automatic, but arguably slightly cleaner
[09:51] <evand> though that's basically duplicating what filteredcommand is doing, arr
[09:51] <evand> xivulon:
[09:51] <evand> 14:10:31 < cjwatson> evand: when xivulon returns, would you ask him to rebuild  wubi urgently, and when that's done rebuild the live CDs?
[09:52] <evand> 14:10:38 < cjwatson> I've committed the relevant fix
[09:53] <superm1_> evand, have you been seeing any weird oddities of the installer stopping at random places on the latest dailies (after the unionfs fix)?  I've had random stops at apt configuration, configuring hardware, and configuring packages that have gotten installed.  Nothing tangible in the logs though, so I was going to hold off reporting it until I found something in /var/log/syslog or /var/log/installer or dmesg
[09:53] <evand> superm1_: unionfs is still an issue
[09:53] <superm1_> evand, okay so that is likely where its sitting then
[09:54] <evand> most likely
[09:54] <evand> for some reason I wasn't experiencing it for a brief period of time
[09:54] <evand> but it's definitely back
[09:54] <evand> the kernel team is on it
[09:54] <superm1_> i'm almost wondering if they are better off rolling back to the older (functional) unionfs release rather than debug these issues with the beta looming so close
[09:54] <evand> they can't, though I do not recall why
[09:55] <superm1_> ah i see
[09:55] <xivulon> evand wubi rev 301 should be up
[09:55] <evand> xivulon: thanks!
[09:56] <xivulon> I'll explain how to rebuild yourself
[09:56] <xivulon> It's fairly straightforward
[09:56] <xivulon> 1 remove any nsis folder you may have
[09:56] <xivulon> 2 make clean
[09:56] <xivulon> 3 make prerequisites
[09:56] <xivulon> 4 make all
[09:57] <evand> <- 64-bit, no WINE atm.
[09:57] <xivulon> hmm
[09:57] <evand> but continue, I'll save it for reference
[09:57] <xivulon> that's it, if you then edit nsis you only need to run "make"
[09:57] <evand> neat, thanks
[09:57] <xivulon> make all also updates grub4dos, the plugins, and translations
[09:58] <xivulon> Which do not need to be rebuilt every time unless you change them or run make clean
[10:00] <evand> ok
[10:00] <xivulon> downloading the iso
[10:00] <evand> I haven't built a new one yet
[10:01] <evand> waiting to see if any other changes need to go in from elsewhere in the distro
[10:04] <xivulon> Hmm I am only interested in wubi/lupin relevant changes
[10:04] <xivulon> Are they in?
[10:21] <evand> xivulon: if I understand the release manager correctly, he wants to see ubiquity 1.5.18 on the next CD, so I'm uploading that, letting it build, then triggering a new CD build
[10:21] <evand> should be a few hours
[10:21] <xivulon> What is/isn't in there?
[10:23] <xivulon> It looks that rev 2258 are not in, anything relevant there?
[10:24] <evand> as far as wubi is concerned, no
[10:25] <xivulon> ok I am gonna test the iso I have. logging off now
[10:25] <evand> best of luck -- unionfs is still an issue, so beware
[10:25] <xivulon> I'll report back any issue
[10:25] <evand> thanks
[11:21] <michael_e_brown> cjwatson, ping
[11:48] <xivulon> cjwatson, I noticed that autopartition-loop does not include changes to make it skip mount.d scripts for mounted partitions
[11:49] <xivulon> You mentioned that a few days ago, so I am not really surprised, just pointing out
[11:54] <michael_e_brown> anybody here who can answer questions about ubiquity and preseed?
[11:54] <michael_e_brown> for gutsy?
[11:55] <xivulon> what question?
[11:57] <michael_e_brown> so... I am trying to automate gutsy install.
[11:57] <michael_e_brown> using live cd as the base.
[11:57] <michael_e_brown> and I dont see much documentation on it.
[11:57] <michael_e_brown> basically what I have is /dev/sda1 is a Dell Utility partition
[11:58] <michael_e_brown> /dev/sda2 has a copy of the live CD copied to it
[11:58] <michael_e_brown> and has grub installed to it is bootable
[11:58] <michael_e_brown> and that boots and works just fine.
[11:58] <michael_e_brown> I can go through the graphical installer and repartition the rest of the disk and everything is wonderful
[11:58] <michael_e_brown> but now, I need to totally automate that.
[11:58] <evand> michael_e_brown: yes
[11:59] <michael_e_brown> I tried starting with a preseed, but cant seem to make it do anything.
[11:59] <evand> the reason that it's not documented very well yet is that it was just developed in this release cycle.
[11:59] <evand> michael_e_brown: you want to run ubiquity with the --automatic flag
[11:59] <cjwatson> evand: unionfs> not sure yet, hoping not to have to decide
[11:59] <michael_e_brown> ok, how to pass that?
[11:59] <cjwatson> evand: m-a.py/automatic> let's stick with what we have for beta if it works, and roll that in afterwards
[11:59] <michael_e_brown> I have preseed=... on the kernel command line
[12:00] <cjwatson> superm1_: rolling back unionfs involves backing out lots of apparmor stuff too
[12:00] <evand> cjwatson: agreed, that's why it's not checked in
[12:00] <superm1_> cjwatson, ah that's a bit unfortunate
[12:00] <cjwatson> michael_e_brown: booting with automatic-ubiquity (and a very current image) should suffice
[12:00] <evand> I just bzr shelved it
[12:00] <cjwatson> (as in, 'automatic-ubiquity' on the command line)
[12:00] <michael_e_brown> I have daily gutsy from today
[12:01] <michael_e_brown> so, just add that to the kernel command line?
[12:01] <evand> cjwatson: the wubi.exe bug was not reproduceable.  Do you want me to trigger a CD build now or wait for ubiquity to make its way into the archive?
[12:02] <cjwatson> michael_e_brown: yeah
[12:02] <michael_e_brown> booting now..
[12:02] <xivulon> michael_e_brown if the preseed is on hard disk you can use find_preseed=/path/to/preseed
[12:02] <michael_e_brown> have that.
[12:02] <cjwatson> evand: which image were you using?
[12:02] <xivulon> cjwatson: rev231
[12:02] <michael_e_brown> I have preseed=/cdrom/preseed/dell.seed
[12:02] <cjwatson> michael_e_brown: use file=
[12:02] <xivulon> then you do not find_preseed
[12:03] <cjwatson> (or preseed/file=, equivalent)
[12:03] <michael_e_brown> sweet. Ok. 'automatic-ubiquity' worked. now?
[12:03] <xivulon> cjwatson, first time I run wubi I had a crush, but was not able to reproduce that again
[12:03] <cjwatson> xivulon: I meant which CD image version, not which wubi version
[12:03] <cjwatson> xivulon: I committed a fix to wubi to make it expect Beta rather than Alpha
[12:03] <michael_e_brown> Right now, I have 'preseed=/cdrom/preseed/dell.seed', I need "preseed/file=..." ?
[12:03] <cjwatson> that was the rebuild I wanted
[12:03] <xivulon> that went in fine
[12:04] <cjwatson> xivulon: you've told us several times how to rebuild wubi ourselves, which is great, but for beta I want to stick with the current build process
[12:04] <xivulon> I used the beta CD with wubi looking for beta
[12:04] <cjwatson> three days before beta is no time to be switching which machine is doing the build
[12:04] <xivulon> sure
[12:04] <evand> cjwatson: that went in fine, but pitti was in the process of building the CD and xivulon found that crash in wubi.exe so I held off on running the build, while at the same time pushing a new ubiquity out as it seemed like pitti wanted that asap
[12:05] <xivulon> cjwatson all other times I tried wubi went well, unfortunately I did not have --debug tracing the first time around
[12:06] <xivulon> I am writing from latest wubi boot indeed
[12:06] <evand> 1.5.18 is stuck waiting for approval
[12:06] <evand> should I just trigger a new cd build instead of waiting?
[12:07] <xivulon> evand can you quickly test wubi?
[12:07] <xivulon> I do not see any code change that could have triggered that though
[12:08] <evand> xivulon: yes, what am I looking for
[12:10] <xivulon> hmm any time I do tab completion in /var/log/ the shell freezes
[12:10] <michael_e_brown> ok, so ubiquity is coming up automatically, but doesnt appear to have read the preseed.
[12:10] <michael_e_brown> just a sec...
[12:12] <evand> xivulon: you seem to have broken CD rom detection


[02:48] <tico506> hi, I have a flashdrive that is working fine with a windows box and is coming up after fdisk -l but it is  not being automatically mounted
[02:49] <tico506> I can put data on it on the windows box and read said data. I formatted it to exFAT
[02:49] <tico506> NTFS format was not working
[02:49] <tico506> any idea what I can do to get my ubuntu box to recognize it properly or the channel I should go to with the question?
[04:42] <asterismo> hi people
[04:42] <asterismo> i wanted to talk about a personal project of an ubuntu remix that is in alpha version...
[04:43] <asterismo> is there any other irc channel in which i can talk about this and make some questions?
[07:35] <nlsthzn> silly question (I am trying my best to like and use tomboy notes)... is there a way of letting it autostart and be minimized to taskbar everytime?
[09:04] <s-fox> Hello.


[23:31] <Takyoji> Grah, why oh why did Canonical drop GNOME 2 in favor of Unity; now the distro is pretty much a joke in an enterprise sense. Right now there's something in the Faribault news of a 'technology committee' of working on city-wide updates on a budget.
[23:33] <Takyoji> I'd recommend Ubuntu, but Unity would be a joke, I'd recommend Debian but that by itself doesn't have commercial support, I'd recommend Linux Mint especially but it lacks commercial support and some redistribution legalities, I'd recommend Fedora, but I've had a poor experience with the quality of their packaging, etc


[00:02] <johanbr> still the same hard lockup
[00:02] <johanbr> no visible difference with nouveau.modeset=1
[00:03] <Sarvatt> yeah its not working here either http://sarvatt.com/downloads/gallium.txt
[00:03] <Sarvatt> gdm stuck on a garbled screen
[00:03] <Sarvatt> i'm trying with noagp=1 now too
[00:05] <Sarvatt> oh wait a sec, old xorg.conf... sheesh
[00:06] <RAOF> Sarvatt: Yeah, I broke xserver-xorg-video-nouveau in xorg-edgers; I was updating the archive package, and forgot that the PPA nouveau-kernel-source had dropped the linux-nouveau-modules Provides:
[00:10] <Sarvatt> Xorg.0.log looks fine but i'm stuck on a blinking cursor screen
[00:10] <Sarvatt> no errors in dmesg either
[00:12] <Sarvatt> http://sarvatt.com/downloads/nouveau.txt
[00:12] <johanbr> can you do anything at that point?
[00:12] <johanbr> switch tty etc?
[00:12] <RAOF> Does the console work?
[00:14] <Sarvatt> no go on vt's or anything, sysrq keys work
[00:14] <Sarvatt> networks up, i can ssh in fine
[00:14] <RAOF> Try rebooting, disabling boot splash?  I seem to recall running into strangeness where nouveau fights with usplash before.
[00:16] <Sarvatt> you know i had that problem too before on that livecd i made, didnt used to have usplash installed even back then
[00:16] <Sarvatt> that worked, removed quiet splash and now i'm in gnome
[00:17] <johanbr> it worked for me just a week ago, with the X server from karmic
[00:18] <johanbr> I upgraded the X server bits to get working xv, but everything stopped working instead
[00:18] <Sarvatt> galliums alot better now on nouveau too, nice
[00:18] <RAOF> johanbr: You could probably have got working xv by running the metacity compositor, too :)
[00:18] <johanbr> I know :)
[00:19] <johanbr> Sarvatt, you're saying the hang disappeared when you removed "quiet splash" ?
[00:19] <Sarvatt> yeah
[00:19] <Sarvatt> usplash definitely doesnt cooperate with nouveau
[00:20] <johanbr> weird... I removed splash, but not quiet, and still got the hang
[00:20] <johanbr> I don't even have usplash installed
[00:20] <RAOF> Actually, it plays nicely with my nv4b; it's obviously not quite so deterministic.
[00:20] <Sarvatt> you have nouveau.modeset=1 too? i have it in a /etc/modprobe.d/nouveau.conf too
[00:20] <Sarvatt> options nouveau modeset=1
[00:20] <Sarvatt> we have the same exact video card
[00:21] <johanbr> which kernel are you running?
[00:22] <RAOF> And which nouveau-kernel-source?  The latest nouveau-kernel-source should (a) enable kms by default, anb (b) add nouveau to the initramfs.
[00:22] <Sarvatt> yours is a dell and mine is a HP going by the subvendor though :D
[00:22] <Sarvatt> 2.6.32-6
[00:22] <Sarvatt> edgers
[00:22] <johanbr> I've mostly tried 2.6.32-7-generic (64-bit)
[00:23] <johanbr> and same n-k-s, 0.0.15+git20091204-0~10.04~ppa1
[00:23] <johanbr> anything special in xorg.conf ?
[00:23] <Sarvatt> phew darn thing is gonna catch on fire trying to play neverball :D
[00:23] <Sarvatt> Section "Device"
[00:23] <Sarvatt>         Identifier "nouveau"
[00:23] <Sarvatt>         Driver "nouveau"
[00:23] <Sarvatt> EndSection
[00:23] <Sarvatt> thats it
[00:24] <johanbr> that's a bit less than mine - I'll try that
[00:24] <Sarvatt> http://sarvatt.com/downloads/nouveau.txt
[00:25] <Sarvatt> thats the working logs
[00:26] <johanbr> alright, one more try...
[00:32] <Sarvatt> yeah nouveau gallium is still pretty much unusable, i915 is almost the same speed as classic mesa
[00:32] <johanbr> whaddayaknow, it works!
[00:33] <johanbr> I think it had issues with something in my old xorg.conf
[00:35] <johanbr> and xv works too :)
[00:35] <Sarvatt> if you want to play with gallium for some 3D ya can just check out mesa git and run ./autogen.sh then ./configure --enable-glx-tls --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests then run any 3D app with something like LD_LIBRARY_PATH="/opt/mesa/lib/" LIBGL_DRIVERS_PATH="/opt/mesa/lib/gallium" glxinfo
[00:35] <Sarvatt> i just made a bash alias for that called gallium so i run "gallium openarena"
[00:36] <RAOF> Sarvatt: How does nouveau gallium fare with, say, gnome-shell?  It's kinda-sorta-almost working on my nv4x.
[00:37] <Sarvatt> hmm cant start gnome shell
[00:37] <Sarvatt> Typelib filoe for namespace Clutter not found hmm
[00:38] <RAOF> Heh.
[00:38] <Sarvatt> can't run it in xephyr either, i think its screwed up in the repos
[00:39] <Sarvatt> or i need aiglx...
[00:39] <johanbr> can you run compiz?
[00:40] <Sarvatt> software rendering detected, falling back even though i ran it with the gallium env variables
[00:40] <Sarvatt> not trying to install gallium dri system wide to get it working :D
[00:44] <Sarvatt> seems exactly the same as it was 6 months ago at any rate, same bugs too.. lol
[00:46] <Sarvatt> maybe the plymouth thats coming in a few days will fix that though
[01:04] <Sarvatt> opened the lid 30 minutes later and its frozen with a blinking cursor again :D
[01:07] <johanbr> so the machine was suspended?
[01:09] <Sarvatt> guess i rebooted it after i shut it and forgot to remove quiet splash from /etc/default/grub
[01:09] <Sarvatt> ...and i forgot a / in my gallium env variables on that machine and was using swrast, no wonder it was slow
[01:11] <Sarvatt> thats more like it! OpenGL renderer string: Gallium 0.3 on NV86
[01:11] <Sarvatt> OpenGL version string: 2.1 Mesa 7.8-devel
[01:11] <Sarvatt> OpenGL shading language version string: 1.20
[01:13] <Sarvatt> compiz is working but slow
[01:18] <johanbr> cool :)
[01:18] <Sarvatt> openarena is great, over 100 fps at 1280x800
[01:21] <RAOF> How nicely is xorg-edgers playing on Lucid's intel right now?
[01:23] <Sarvatt> we really need to package gallium if we're going to use nouveau, this works great
[01:23] <Sarvatt> intel's got alot of problems on 2.6.32 for me
[01:24] <RAOF> Sarvatt: Feel free to --enable-gallium-nouveau on your next mesa upload to xorg-edgers :)
[01:24] <Sarvatt> if only it was that easy! lol
[01:26] <RAOF> It builds a totally different mesa? :)
[01:27] <Sarvatt> gonna have to have alternatives for the main libgl i guess
[01:29] <RAOF> Or just overwrite the existing libgl, and get people to not install it on !nouveau :)
[01:29] <Sarvatt> heck, I would probably stick to nouveau fulltime if gallium was packaged, this is fast enough
[01:33] <Sarvatt> glxgears caused a gpu freeze
[01:52] <Sarvatt> hmm guess i should be compiling in the mesa state tracker too?
[01:52] <RAOF> Probably a winner.
[01:53] <RAOF> I just pull in all the trackers.  Gets you bonus xvmc acceleration!
[02:00] <RAOF> Ok.  I think I've ballsed up xserver-xorg-video-nouveau git sufficiently that I can now re-do the pristine-tar stuff cleanly.
[02:19] <RAOF> Hm.  Darktama thinks that nouveau.ko should work with an unmodified drm from 2.6.32.  That would make nouveau inclusion substantially simpler!
[02:57] <RAOF> I think it's time to play "what happens if I drop drivers/gpu/drm/nouveau into lucid's kernel tree"
[03:00] <johanbr> hmm... X restarts when I resume from suspend
[03:00] <RAOF> Avec nouveau?
[03:01] <johanbr> oui
[03:01] <johanbr> actually, it restarts with the nvidia 195 driver too
[03:01] <johanbr> so it might not be nouveau-specific
[03:01] <RAOF> That seems like a safe call, yes.
[03:01] <johanbr> :)
[03:02] <johanbr> it did resume just fine in karmic
[03:02] <RAOF> Maybe it's an xserver 1.7 issue?
[03:05] <johanbr> could well be
[03:05] <johanbr> apparently X segfaults on resume: http://pastebin.com/f49fbee3c
[03:07] <RAOF> And it doesn't seem to be anywhere near nouveau; maybe it's a synaptics issue?
[03:09] <johanbr> quite possibly
[03:09] <johanbr> I'll try downgrading the synaptics package
[03:12] <johanbr> there was also libpthread in there... I just upgraded that
[03:16] <RAOF> Man, "git add -i" has to be one of the least intuitive interfaces in the whole of the git suite.
[03:22] <RAOF> ARGH!  "git add -p" -- it's like "bzr shelve" except _totally inscrutable_.
[03:39] <Sarvatt> you cant really downgrade synaptics, distro stuff wont work in xserver 1.7+
[03:39] <Sarvatt> wonder if it has anything to do with the new pm-utils 1.30rc that was just uploaded
[03:41] <Sarvatt> or is that just video quirks..
[03:41] <johanbr> yes, I noticed
[03:41] <Sarvatt> whats your /var/log/pm-suspend.log look like?
[03:42] <johanbr> http://pastebin.com/f238ce745
[03:43] <johanbr> don't see any problems there
[03:43] <RAOF> Ok.  Anyone know how to update the kernel configs?
[03:43] <johanbr> but this in the X log makes me wonder: "[    0.000666] (II) Cannot locate a core pointer device."
[03:44] <johanbr> RAOF, update kernel configs how?
[03:45] <RAOF> As in: take the ubuntu kernel, add drivers/gpu/drm/nouveau, and update the build config to enable the build.
[03:45] <RAOF> Never mind, it seems I've found the kernel team wiki.
[03:46] <johanbr> depends on whether nouveau drm is built in-tree or out-of-tree
[03:47] <RAOF> I'm building it in-tree.
[03:47] <RAOF> The idea is to work out whether or not we can just drop drivers/gpu/drm/nouveau into the current kernel build & expect it to work.
[03:47] <johanbr> in that case, I guess the nouveau drm patch itself should add a kernel Kconfig option
[03:47] <RAOF> Because _that_ would mean that it'd be actually possible to ship nouveau by default without killing the other drm drivers.
[03:48] <RAOF> johanbr: It does; I'm trying to find out how the kernel team runs "make silentoldconfig", because it's special.  It occurs to me that perhaps #ubuntu-kernel is going to be more helpful, though :)
[03:49] <johanbr> :)
[03:51] <johanbr> can't you just check out the kernel source package, patch with the nouveau patch, enable the nouveau Kconfig option and then build the deb as usual?
[03:51] <RAOF> No, because the kernel build system copies a stored kernel config on build.
[03:51] <johanbr> oh
[03:51] <RAOF> (Because it wants to build a hojilion different configs)
[04:08] <RAOF> Kernel build timer started: 3:06 pm
[04:11] <johanbr> are you building all the possible flavours?
[04:12] <RAOF> No.
[04:12] <RAOF> Kernel build timer stopped: Error at 3:12 pm :)
[04:12] <johanbr> oh :(
[04:12] <johanbr> well, at least it was quick :)
[04:13] <johanbr> in the nouveau part or somewhere else?
[04:13] <RAOF> In the nouveau part, where I forgot to copy over the i2c directory :(
[04:13] <RAOF> New start: 3:13 pm :)
[04:33] <Sarvatt> how long have you been using edgers on lucid johanbr? just wondering if you had that crash on resume before the switch from hal to udev around december 2nd or so
[04:33] <johanbr> that sounds about right for when the crash started appearing
[04:41] <RAOF> Balls.  Things build better when you include the include files.
[04:47] <johanbr> oh... another restart?
[04:47] <RAOF> Yup.  3:47pm
[04:47] <RAOF> :)
[04:47] <johanbr> :)
[04:47] <johanbr> updated a few things... off to see if resuming works better now
[05:09] <johanbr> hmm... no luck... X still restarts on resume
[05:35] <RAOF> 4:32pm - /home runs out of space :(
[05:39] <johanbr> just no end of troubles today
[09:51] <tjaalton> "Your branch is ahead of 'origin/ubuntu' by 3293 commits."
[09:51] <tjaalton> merging mesa is fun
[09:54] <jcristau> moving to 7.7?
[09:54] <tjaalton> nah, merging with unstable
[09:54] <jcristau> heh
[09:54] <tjaalton> but git was neglected for a number of months
[09:54] <jcristau> ok
[09:55] <tjaalton> it was actually quite easy, the diff is quite manageable
[10:06] <tjaalton> ok, maybe it's time to push all this crap to lucid ;)
[10:27] <RAOF> Cool.  nouveau actually builds against (very nearly) stock lucid drm.  Lets see how well it works.
[10:29] <tjaalton> RAOF: we need a new patch for libdrm 2.4.15
[10:29] <tjaalton> or .16
[10:40] <jcristau> tjaalton: lolz. even the diffstat is above the limit for commit mails.
[10:44] <RAOF> tjaalton: Yeah, that's right.  I was thinking of the kernel component; I was assuming libdrm 2.4.16 would be ambling into lucid sometime in the not-too-distant future.
[11:05] <tjaalton> jcristau: heh, so it seems
[11:05] <tjaalton> RAOF: it should yes
[11:38] <tjaalton> jcristau: there's a request to include the synaptics headers (bug 340340), fedora does it too. what should it be called, x-x-i-synaptics-dev?
[11:39] <jcristau> yeah probably
[11:41] <jcristau> are you uploading the new server today?
[11:41] <tjaalton> yes
[11:41] <tjaalton> though the build seems to have failed..
[11:42] <tjaalton> had to try it first
[11:42] <tjaalton> seems like patch 177 broke it
[11:42] <tjaalton> struct _DeviceIntRec has no member named 'isMaster'
[11:44] <tjaalton> well, should be fixed anyway
[11:44] <tormod> tjaalton, re mesa merge, do you remember I retro-pushed ubuntu releases to git (see ML)?
[11:45] <tjaalton> tormod: when was that?
[11:45] <tjaalton> ah, found it
[11:48] <tormod> so I guess that was wasted time
[11:48] <tjaalton> I was abroad when you sent that, sorry :)
[11:52] <tjaalton> but it's nice that all the changes are there as separate commits.. maybe it could be force-pushed
[11:52] <tjaalton> I'll check the script
[11:54] <tjaalton> you should apply for pkg-xorg :)
[11:55] <tjaalton> maybe the script could be used with synaptics..
[11:56] <tormod> well I think Bryce reviewed it half way but did not push it
[12:01] <tjaalton> though most of the changes between the previous git push and now were just added patches from upstream. the diff is almost identical
[12:05] <tjaalton> pushing your repo would also add the tags?
[12:10] <tormod> yes, I made tags also
[12:12] <tjaalton> we haven't tagged the releases from ubuntu branches, to avoid cluttering up the list. don't know if it matters much, but
[12:13] <tormod> isn't that useful, to easily git-diff between versions?
[12:13] <tjaalton> normally I just diff the head of ubuntu
[12:14] <tjaalton> but yes, it's useful to have the debian releases tagged ;)
[12:15] <tormod> I understand, the tag list is global, so we can not "hide" ubuntu tags, they will uglify the gitweb list
[12:16] <tjaalton> and tab-completion with zsh ;)
[12:17] <tormod> with bash also I think
[12:27] <tjaalton> tseliot: what's the status with synaptics? not maintained in git anymore it seems, but are you going to merge it or should I? (for xserver 1.7)
[12:27] <tseliot> tjaalton: in the debian git, do you mean?
[12:28] <tjaalton> yes
[12:28] <tseliot> aah
[12:29] <tseliot> tjaalton: feel free to merge it. I have a lot of things to deal with right now
[12:29] <tjaalton> ok
[12:29] <tseliot> and thanks
[12:29] <tseliot> :-)
[12:29] <tjaalton> np
[12:35] <tjaalton> xserver build failed again, now due to patch 135
[12:37] <jcristau> that patch seems to make the server do some things from the signal handler which i'm not sure are safe
[12:38] <tjaalton> error: 'signo' undeclared
[12:38] <tjaalton> well, apport isn't run anyway yet, so I'll just disable it for now
[12:48] <tjaalton> yes, built without it
[13:26] <tseliot> tjaalton: let me know if my patches for synaptics fail to apply and I'll adapt them for you
[13:28] <tjaalton> tseliot: ok, thanks. fixing the server one more time..
[13:28] <tseliot> :-)
[13:53] <tjaalton> sigh.. what to do with -ati..
[13:53] <tjaalton> the version is bigger than in debian, so can't be synced. maybe just a rebuild then
[13:53] <tjaalton> don't feel like pulling in a random snapshot
[13:56] <tseliot> a rebuild should be enough then
[14:02] <tjaalton> there, pitti synced these http://pastebin.ubuntu.com/336548/
[14:03] <tjaalton> apart from the xcb stuff which is in quilt3.0 format and soyuz can't handle it yet
[14:04] <jcristau> nothing needs it yet so that should be fine
[14:04] <tjaalton> yep, figured as much
[14:05] <jcristau> new intel will, but...
[14:46] <tjaalton> openchrome failed to build
[14:46] <tjaalton> http://launchpadlibrarian.net/36533009/buildlog_ubuntu-lucid-i386.xserver-xorg-video-openchrome_1%3A0.2.904%2Bsvn812-1_FAILEDTOBUILD.txt.gz
[14:46] <tjaalton> against the old server, but anyway
[14:50] <jcristau> old xserver + new proto
[14:50] <jcristau> that's expected to break
[14:50] <tjaalton> ah, ok
[14:50] <tjaalton> it should be the only driver without the bumped build-dep
[14:55] <tjaalton> looks like fedora has had fixes for ABI_INPUT_VERSION 7 for the drivers that haven't seen releases for 7.5
[14:55] <tjaalton> wonder why they haven't been pushed upstream
[14:56] <tjaalton> oops
[14:57] <tjaalton> correction, they are upstream but no release has been made
[14:58] <jcristau> oh, i guess i forgot those had been pushed
[15:00] <jcristau> maybe you can do the releases then :)
[15:01] <tjaalton> heh, maybe later :)
[15:03] <tjaalton> tseliot: the jumpy cursors patches don't work, since there will be no fdi file anymore
[15:04] <tjaalton> and I don't know how it works in the udev world. But I guess it can be disabled for now
[15:05] <tseliot> tjaalton: but the udev rule that pitti wrote makes use of it and it works
[15:05]  * jcristau would like to not put any options in the udev rules
[15:06] <tjaalton> tseliot: oh right, they are there
[15:07]  * tseliot would like to live in a world in which quirks are not required...
[15:07] <tjaalton> it's just a matter of where they should live..
[15:07] <jcristau> tseliot: if quirks are required, they should not live in udev rules.
[15:07] <tseliot> give me another sensible place for the quirks and I'll change my patch ;)
[15:07] <jcristau> your kernel
[15:08] <jcristau> or the X driver, maybe
[15:10] <tseliot> jcristau: I discussed this with whot but he doesn't seem to want it in the X driver and I'm not really sure about how I could translate my patch into a kernel patch (because of what it does)
[15:12] <jcristau> what it does is detect what machine it's running on and set different default values for some options?
[15:16] <tjaalton> tseliot: the first part of the jumpy patch fails to apply
[15:17] <tseliot> tjaalton: can you upload the synaptics source somewhere, please?
[15:17] <tjaalton> I'll push it to git, clone from there
[15:19] <tseliot> tjaalton: can you give me the link to the branch, please?
[15:21] <tjaalton> git clone git://git.debian.org/pkg-xorg/driver/xserver-xorg-input-synaptics.git
[15:21] <tjaalton> git checkout -b ubuntu origin/ubuntu
[15:23] <tjaalton> guess I have to drop wacom from input-all until it works
[15:30] <tseliot> tjaalton: ok, thanks I'll update the patch ASAP
[15:31] <Sarvatt> we need a 190.xx or newer nvidia blob to work with xserver 1.7 too
[15:32] <tjaalton> tseliot: thanks
[15:33] <tseliot> Sarvatt: right. It's on my TODO list
[15:33] <tseliot> tjaalton:  np
[15:35] <Sarvatt> openchrome should build against xserver 1.7, i pushed a patch for it upstream like 6 months ago
[15:35] <Sarvatt> oh sorry misread, old server new libs
[15:36] <tjaalton> yep
[16:01] <tjaalton> xserver failed to build on sparc, powerpc:
[16:01] <tjaalton> /xi2/eventconvert/XIDeviceChangedEvent: **
[16:01] <tjaalton> ERROR:../../../test/xi2/protocol-eventconvert.c:714:test_values_XIDeviceChangedEvent: assertion failed: (k->length == bytes_to_int32(sizeof(xXIKeyInfo)) + k->num_keycodes)
[16:01] <tjaalton> /bin/bash: line 5: 13949 Aborted                 ${dir}$tst
[16:01] <tjaalton> FAIL: protocol-eventconvert
[16:01] <jcristau> fun.
[16:02] <jcristau> endianness bug?
[16:05] <tjaalton> probably something like that..
[16:05] <tjaalton> shouldn't matter though
[16:05] <tjaalton> at least not for a1
[16:08] <tjaalton> mesa built fine.. I'll upload it and take a break
[16:19] <Sarvatt> where can you see the buildlogs for debian experimental powerpc xserver?
[16:21] <jcristau> you can't
[16:21] <jcristau> experimental autobuilding is fucked up atm
[16:22] <jcristau> http://lists.debian.org/debian-wb-team/2009/12/msg00002.html
[16:33] <Sarvatt> ahh darn
[16:35] <jcristau> looks like the sparc x tinderbox machine is b0rked as well.  yay.
[16:37] <Sarvatt> doesnt look like they're even building xserver on powerpc either
[16:37] <Sarvatt> oh sheesh i'm blind this morning
[16:38] <jcristau> yeah both are failing on libs earlier
[17:55] <ScislaC> I recall seeing discussion about HAL going away for 10.04, is that still planned?
[17:55] <jcristau> see https://lists.ubuntu.com/archives/lucid-changes/2009-December/001427.html
[17:56] <jcristau> and friends
[17:58] <ScislaC> jcristau: Thanks! Is it known yet if the udev stuff is playing nicely with drawing tablets?
[19:15] <tjaalton> ScislaC: 0.10.2 should work, but it's not packaged yet
[19:16] <tjaalton> so wacom on alpha1 doesn't work at all
[19:16] <ScislaC> tjaalton: excellent, I will hold off for now then
[19:28] <tjaalton> duh, somehow missed -ark, -apm, -neomagic when requested pitti to sync the drivers
[20:58] <tjaalton> ok, video drivers should be good now (apart from blobs)
[20:58] <jcristau> and sparc :)
[20:59] <tjaalton> obviously :)
[20:59] <tjaalton> I guess only i386 and amd64 matter at this point
[20:59] <tjaalton> and armel
[21:35] <johanbr> is 2:<IP_ADDRESS>~git20091207.fd867387-0ubuntu0sarvatt a real, existing version of xserver-common?
[21:35] <johanbr> xserver-common depends on that package
[21:35] <johanbr> sorry, I mean xserver-xephyr depends on that package
[21:36] <tjaalton> if you run xorg-edgers, yes
[21:36] <tjaalton> or should be anyway
[21:37] <johanbr> xorg-server - 2:<IP_ADDRESS>~git20091207.fd867387-0ubuntu0sarvatt exists as a source package
[21:37] <johanbr> but didn't produce an xserver-common package at all
[21:38] <johanbr> oh, maybe that's because the 386 build isn't finished yet
[22:16] <RAOF> Sweet.  With a simple patch to export a couple more ttm symbols, nouveau build & runs against lucid's kernel drm.
[22:20] <johanbr> cool
[22:20] <johanbr> you cleaned out your /home ? :)
[22:20] <RAOF> Indeed.
[22:21] <RAOF> Why are all the git defaults exactly backwards? :(
[22:28] <tormod> RAOF, I will keep on updating the -nouveau in xorg-edgers. was there something special about your upload?
[22:28] <tormod> apart the broken parts :p
[22:28] <RAOF> tormod: It was basiacally testing for an upload to Lucid; feel free to keep updating it in edgers.
[22:29] <tormod> RAOF, okdok
[22:29] <RAOF> That's also why it was broken; it was based on Karmic's package, which the PPA packages have diverged from :)
[22:54] <johanbr> hmmm... just did a complete dist-upgrade to Lucid, and X still segfaults on resume: http://pastebin.com/f48826e90
[23:22] <johanbr> apparently, it's probably this (just fixed) bug: https://bugs.freedesktop.org/show_bug.cgi?id=25339