[00:08] archive admins available? xserver-xorg-video-cyrix can be removed from the archive. it doesn't build against the latest xserver, and it's deprecated anyway. the geode driver will/does replace it [00:18] tjaalton: ah i guess you saw the issue already [00:19] gnomefreak: about cyrix? [00:19] via should also be synced [00:19] tjaalton: no about X in general it looks like xserver-xorg-core is broken [00:19] * RAOF thinks gnomefreak is talking about "the {video,input} ABI changed, so everything's uninstallable". [00:19] most likely respinning is all it is [00:20] ABI changed? [00:20] uninstallable hell it wants to remove everything [00:20] input and video ABI [00:20] don't force it [00:20] i dont [00:20] just wait until it allows an upgrade [00:20] Wait until the world's been rebuilt [00:20] dist-upgrade wanted to remove it [00:20] hm, it shouldn't upgrade [00:21] ok, well don't :) [00:21] i know [00:21] just wanted to make sure you were aware of it [00:21] of course [00:21] was just waiting that all the archs had the latest xorg-server [00:21] (and a bit occupied during the evening, but..) [00:22] no rush atleast for me [00:22] * gnomefreak has alot fo work i can do as long as i dont use dist-* ill be fine [00:25] * TheMuso thinks staying on hardy is a safer bet. :p [00:25] gnomefreak: Well, nouveau should now be installable, at least :) [00:26] TheMuso: stable is always safer just not so much fun ;) [00:42] does anyone know if there is a good debian/ubuntu mirroring program that acts as a proxy (that actually works) [00:43] * calc is considering writing one in his spare time [00:43] You mean an apt-proxy? [00:43] RAOF: i guess [00:43] RAOF: iirc i used apt-proxy before but maybe not [00:43] i know approx doesn't work very well [00:43] it seems to nuke the archive for unknown reasons [00:43] There are a couple; apt-proxy, apt-something-else, apt-zeroconf. But I'm using squid. [00:45] ok i'll have a look i have plenty of room for a full mirror but would rather it pull stuff as needed [00:46] but in the past the ones i have used seemed to not work correctly :\ [00:47] apt-zeroconf (when it works) is pretty cool at that. [00:47] what package is it in? i don't see it in hardy [00:47] It's not yet packaged, at least officially. [00:47] ah [00:48] hmm i think i have used apt-cacher and approx before [00:48] approx definitely didn't seem to work right [00:48] I've used apt-proxy; that seemed to work pretty well. [00:48] i'll give apt-proxy a try [00:49] apt-zeroconf, if you're interested: http://trac.phidev.org/trac/wiki/AptZeroconf [00:53] thanks for the tips :) [00:53] the desc on the apt-proxy page leads me to believe it should work well and also why i thought it didn't (i think i tried it last back when it was unstable) [00:54] apt-zeroconf would be cool, particularly for laptops, if it were a bit more stable. [00:55] * TheMuso uses apt-mirror, with a post mirror script to mirror other bits. [00:57] Since I mirror 3 architectures, and have several boxes that need to download updates every day. [01:00] Yow! Xorg flud! >) [01:01] TheMuso: As in "broken" or as in "every single Xorg package has been rebuilt"? :) [01:05] RAOF: The flood of xorg related packages on intrepid-changes. I know why, but still, thats a lot. [01:13] slangasek: ping [01:19] hi, I have renamed all the SCSI subsystem drivers (so Linux can't load them) and all the SCSI subsystem drivers are compiled as modules, but strangely the SG_GET_VERSION_NUM ioctl returns the sg driver version, how is that possible if the sg (and all the SCSI subsystem) driver was renamed and it is not loaded ?? [01:46] i see one minor issue with apt-proxy already, it uses the name you put in your sources.list for its cache dir [01:46] so if you have different names on different machines it won't all pull from the same place === asac_ is now known as asac [02:07] calc: Ouch. [02:47] slangasek, can you promote the mythbuntu alt disks to the right place now? [03:20] it appears apt-proxy doesn't handle versions kept properly for ubuntu 'distributions' [03:20] iow it deletes them once it reaches the limit number across distributions [03:31] gah apt-proxy has huge number of open bugs on b.d.o [03:31] it appears no partial mirror program works as i had found out before :\ === philwyett_ is now known as philwyett [04:00] calc: I think you might be better off investing time into debmirror or apt-mirror, however I'd recommend apt-mirror svn over the hardy package. === saivann_ is now known as saivann === foka_ is now known as foka [05:57] TheMuso: ok [05:57] calc: You don't have to, but thats what I think works better. [05:58] TheMuso: so is apt-mirror svn better than debmirror? [05:58] * calc wishes one of them would just work properly, grr [06:00] from what i recall i wrote one myself about 8 years ago but never actually uploaded it anywhere [06:01] apt-proxy is probably a good place to work to get a partial one going properly, but seems to need lots of work [06:01] calc: heh. I find apt-mirror from svn more flexible, as your configuration file is similar to sources.list. Debmirror has to be called multiple times if you need to pull from more than one source. For example, I would have to call debmirror twice, one for ports.ubuntu.com, and one for archive.ubuntu.com. [06:01] Apt-mirror on the other hand does it all at once. [06:01] However, apt-mirror doesn't yet support rsync. [06:03] oh ok [06:04] apt-proxy would really be ideal for me since i don't have much need for a full mirror but its too buggy :-\ [06:04] so i'll have to try out apt-mirror after i sleep :) [06:04] midnight here now, so about time for bed [06:08] good morning [06:10] Hey dholbach. [06:10] hi TheMuso [06:11] hey dholbach, TheMuso [06:11] Hey Hobbsee. [06:12] hi Hobbsee [07:01] Good morning [07:01] hi pitti [07:01] tjaalton: if you set proper build-deps, they will just dep-wait until it is built on ia64 [07:02] pitti: hi! [07:02] * pitti hugs dholbach [07:02] hey nxvl === ara_ is now known as ara [07:35] pitti: I noticed that it was built on ia64 after all, so went ahead and uploaded what I had [07:35] ah, finally [07:35] tjaalton: thanks! [07:35] and bryce did the rest :) [07:37] * bryce waves === doko__ is now known as doko [09:35] cjwatson: I've just sent you the email which I should have sent you yesterday. Thanks in advance :-) [09:36] hi, ubuntu uses the ide-scsi driver to load ATAP cd devices as SCSI devices ? [09:39] what would be the correct package for bug #245500 ? was reassigned from"jigdo-file" but the real issue is that 8.04.1 jigdo templates point to an older version of a package that is not what ships with hardy+1 [09:39] Launchpad bug 245500 in xserver-xorg-video-geode "Jigdo cannot build ubuntu-8.04.1-alternate-i386.iso: .jigdo file refers to missing package" [Undecided,Confirmed] https://launchpad.net/bugs/245500 [09:40] who's on archive admin duty today? I know it's not mon/wed/fri, but since alpha2 is about to release.. [09:44] tjaalton: Riddell usually [09:44] I did some small bits today and yesterday, but not a lot [09:44] tjaalton: http://wiki.ubuntu.com/ArchiveAdministration [09:44] Q-FUNK: no package, but it should be on the ubuntu-cdimage project [09:46] Q-FUNK: your diagnosis is incorrect though - I'll handle it [09:46] cjwatson, pitti: thanks, bookmarked [09:47] cjwatson: thanks [09:48] Q-FUNK: incorrect> because actually the jigdo files *do* point to the version in hardy.1 [09:48] cjwatson: so why does their build fail, I'm wondering? [09:49] Q-FUNK: because -updates has moved on from 8.04.1 [09:49] Q-FUNK: see my explanatory comment in the bug [09:49] ok [09:50] does ubuntu ever move packages from release-updates to release, after it's out? [09:50] no [09:50] if we did, that would solve this problem but create others === dholbach_ is now known as dholbach [09:50] ok [09:52] where might I find the edgy release? I need to look at a package in there but can't find it at http://archive.ubuntu.com/ubuntu/dists/ [09:56] amitk: There are images available from http://cdimages.ubuntu.com/releases/6.10/release/ [09:57] amitk: I don't expect that you'll find archives or updates in any sane place. [09:58] amitk: old-releases.ubuntu.com has both the archive and CD images [09:58] persia: ^ [09:58] pitti: Thanks! [09:58] pitti: aah great, thanks [09:58] don't rely on that cdimage URL - it's a bug that it's still there [09:59] Edgy is not the release you are looking for [10:40] any plans on backporting the newest openjdk/icetea? i hear it passes the TCK [10:44] jscinoz: see the discussion on ubuntu-devel [10:44] thanks cjwatson [10:57] apachelogger, could you add hardy tasks before closing all the kdeedu bugs with pointers to kde4 ? we dont ship it in hardy and there is still opportunity to fix them through SRUs ... [10:57] (in kde3.x) [10:58] ogra: well, I am done with kdeedu [10:58] hrm [10:58] * apachelogger hunts through it again [10:58] thanks :) [10:59] sorry for that, be we ship kdeedu3 in edubuntu so i dont wat to lose them ... [11:00] ogra: very reasonable, I didn't think about that, sorry :S [11:01] if we ever meet, remind me to pay you a beer :) [11:03] yay :) [11:15] blarg icedtea is a huge buil [11:15] build* [11:22] tjaalton,bryce: xserver-xorg-video-geode still seems to be built against xserver-xorg-video-2, despite the rebuild [11:22] looks like it's hardcoded in debian/control [11:22] cjwatson: yep, a new version on the way to debian-experimental [11:22] and we can sync that [11:22] please let me know when it's in and I'll do the sync - it's blocking live CD builds [11:23] cjwatson: yep, will do [11:23] I don't see it in incoming [11:24] but it'll be sufficient to have it uploaded, I don't have to wait for the Debian archive to process it [11:24] I could upload a fix if that's faster [11:25] it would be faster, certainly [11:25] same goes for xserver-xorg-video-imstt [11:25] imstt should be removed [11:25] like cyrix [11:25] oh, that failed to build [11:25] they shouldn't block anymore [11:25] magictouch too [11:25] ah, I was reading the wrong xserver-xorg-video-all control file [11:26] bug 246525 [11:26] Launchpad bug 246525 in xorg "Please remove from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/246525 [11:26] blink, what a confusing bug [11:26] heh [11:26] it should be filed on the individual source packages [11:26] I know, but too many.. [11:27] of those [11:27] I'll edit the title [11:27] how about xserver-xorg-video-via? [11:27] synced [11:27] *should be [11:28] bug 246454 [11:28] Launchpad bug 246454 in xserver-xorg-video-via "Please sync xserver-xorg-video-via 1:0.2.2-6 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/246454 [11:29] aha [11:30] tjaalton: via isn't pciaccessed [11:30] jcristau: oh right.. [11:30] so remove from the archive (yay!), openchrome is used by default anyway [11:30] err, I just synced it [11:30] hmm, maybe video-all needs adjusting too [11:31] hmm :) [11:31] shouldn't matter, it's the RHS of an |-dep [11:31] tjaalton: i changed -all to openchrome | via a while ago [11:31] jcristau: yeah, that's covered but I thought that | should matter in this case [11:31] it shouldn't [11:32] geode uploaded [11:33] is xserver-xorg-video-openchrome still needed on lpia? it has an outdated package there [11:33] probably not [11:33] right, the current version is only built on i386/amd64 [11:34] tseliot: related to that ^ discussion, the nvidia-glx-* packages need to be rebuilt against the new X, too [11:34] tseliot: current dist-upgrade wants to remove them [11:34] so the lpia version can be deleted [11:34] mm, looks intentional [11:35] tseliot: would be nice to test them in the PPA with the new X [11:35] pitti: tjaalton has suggested a way not to hardcode the server abi [11:35] one caveat with mesa/intel.. compiz doesn't work with it, so it should be blacklisted until the mesa driver is fixed.. [11:35] pitti: as, for example, the intel driver does [11:35] tseliot: hardcode in the source, or in the .debs? [11:35] tseliot: most of the -video packages were mere rebuilds, no source changes [11:35] pitti: in the source [11:36] right [11:36] mvo is on leave? [11:36] tjaalton: GUADEC [11:36] pitti: ah right [11:36] pitti: I have implemented this and all the other changes which you suggested. I'm about to reboot and try them in Intrepid 64bit [11:37] tseliot: yay you rock! [11:38] tseliot, tjaalton: WDYT, should we try to squeeze the new nvidia-glx-* into multiverse for alpha-2? it can hardly get much worse anyway :) [11:38] * tseliot reboots [11:38] mythtv still build-deps on libchromexvmc(pro)1 - I'll file a bug [11:38] * tseliot changes his mind on rebooting [11:38] pitti: does it mean that the packages should be ready today? [11:39] tseliot: we won't put them on the CDs, at least not for alpha2, so thursday would actually suffice [11:39] tseliot: I'm not trying to rush you, I'm just asking about what you feel what we should do :) [11:40] since they would make a nice paragraph in the alpha-2 release notes [11:40] heh [11:40] pitti: I'm ok with it [11:40] pitti: if so, then it's ok. I'm working full-time on this ;) [11:40] * Unfuck nvidia users, thanks to Alberto Milone [11:40] tjaalton: http://people.ubuntu.com/~ubuntu-archive/NBS/mesa-swx11-source says that vnc4 and xserver-xgl still build-dep on mesa-swx11-source - can you please either file bugs or fix them? [11:40] cjwatson: uh, ok. will do [11:41] ta [11:41] pitti: LOL [11:41] well, maybe with some slight editorial changes :-P [11:42] pitti: unless there's something else which you would like to tell me I'll reboot now [11:42] tseliot: good luck! [11:42] tjaalton: I think that's all the X-related archive actions done now [11:43] * tseliot finally reboots [11:43] cjwatson: yep, should be fine now [11:49] pitti: I see lrm-envy seems to have been uploaded. my desktop at the office is hungry for an nv->nvidia migration, if you let me know when it's appropriate to test jockey [11:49] tsk ... these GL addicts ... [11:49] mdz: is that hardy or intrepid? [11:50] mdz: jockey doesn't control l-r-m-envy, that's envy-ng in hardy [11:50] mdz: tseliot an I will unify envy-ng and jockey at some point, but it's not there yet in hardy :( [11:51] and in intrepid it's a large construction site ATM; nvidia-glx-* can be tested from PPA (they WFM), but no jockey integration yet [11:51] pitti: intrepid [11:51] pitti: would it be more useful to test what's in the PPA now or wait to test jockey integration? [11:52] mdz: I think testing the drivers now would be very useful -- https://launchpad.net/~lrm-intrepid/+archive [11:52] mdz: once they are in the archive, I'll have a go at modifying the jockey handlers appropriately [11:52] tjaalton: xserver-xorg-video-all and some of its dependencies were removed for me on upgrade to intrepid. are some of them still waiting to rebuild or something? [11:52] pitti: ok, I'll have a look tomorrow [11:52] ish [11:53] mdz: NB that they don't work with the very latest X.org yet, tseliot is currently testing the new version; should be uploaded today (to the PPA) [11:53] mdz: if you didn't dist-upgrade to all the new drivers and xorg yet, you can use them [11:53] mdz: yes, geode is still without the correct abiver [11:53] pitti: I'm at home today anyway, so don't have access to the machine atm [11:53] mdz: should be fixed RSN [11:54] mdz: I think for alpha-2 we should have working drivers in the archive, and shortly after that, a fixed jockey [11:54] tjaalton: for me it was -geode, -newport, -via, -imstt and -cyrix [11:54] (none of which I need, so I just let it upgrade anyway) [11:56] mdz: we were just dealing with that lot in scrollback [11:56] half an hour ago or so [11:56] mdz: hmm ok, I haven't tested dist-upgrade yet, but the latest video-all should not depend on cyrix, imstt, newport anymore [11:57] so maybe the archive was a bit behind [11:57] xserver-xorg-video-newport seems to have source but no binaries in the archive in intrepid, which is odd to say the least [11:57] tjaalton: the geode problem confused apt [11:57] ok.. [11:57] current dist-upgrade just wants to kill -cyrix and -via here [11:57] cjwatson: newport is Architecture: mips now [11:57] aha [11:57] ok, that makes sense, I'll just leave it there [11:57] removing -cyrix and -via is fine [11:58] I've demoted -via to universe to clarify [12:10] cjwatson: I think I asked you about this before, but I coulnd't find it in my logs: How would you feel about moving openssh's host key generation into the init script instead of postinst? [12:11] cjwatson: If we're building virtual appliances, it would be handy to be able to ship them without keys and just have them generated on first boot. [12:16] I'd accept a patch to make it generate host keys mentioned in the configuration file if they don't exist [12:16] I'd like to leave the existing configuration in the postinst though [12:16] i.e. copy not move [12:16] Oh? Why? [12:16] reason being that it's all bound up with configuration file generation and that belongs in the postinst [12:18] I'm not absolutely sure I can articulate it, I'm just more comfortable with it being in the postinst for most uses [12:18] Hmm.. Ok. That seems a bit pointless to me, though. The postinst starts the daemon anyway, so in the process of postinst'ing, they'll be generated anyway. [12:18] ok, but I have to maintain this so I'd like it to be something I'm comfortable with :) [12:18] *g* [12:18] Sure. Ok, I'll copy the code and send you a patch. [12:19] oh, one good reason - it wouldn't surprise me in the least if a number of people used entirely custom init scripts rather than the one we ship, e.g. for starting multiple sshds [12:19] soren: not really -- policy-rc.d :) [12:19] so I'd prefer the postinst to do all the configuration by default [12:20] pitti: I deliberately didn't mention that :) [12:20] I actually use that for chroots [12:20] pitti: I use it in ubuntu-vm-builder, too. [12:20] ...so it would actualy save me the trouble of having to have the postinst generate the key and then remove it afterwards. [12:20] *shrug* [12:21] Just another quirk to the pile. [12:24] morning [12:24] it's not [12:33] cjwatson: http://people.ubuntu.com/~soren/regen_host_keys.diff [12:33] cjwatson: Or would you rather have it in a bug report? [12:33] cjwatson: I don't know if the postinst changes are silly, though. [12:34] I left them out of the init script to not confuse regular users who wouldn't know what a postinst script is, but still would like to fiddle with the init script. [12:36] soren: bug report, please [12:36] soren: alternative would be to introduce /usr/share/ssh/config-library.sh or something [12:37] * mdz reboots another system into intrepid [12:40] cjwatson: Yeah, I thought about that. Hm.. Ok, I'll give it a shot. [12:59] any objections to xcb-util being promoted to main? new cairo needs libxcb-render-util, and it seems fairly unobjectionable [13:04] that did not go well at all [13:04] gdmgreeter is crashing, xfailsafedialog is crashing [13:04] nautilus and gnome-panel are crashing [13:04] but somehow gnome-terminal and xchat-gnome work [13:11] yay, x-x-video-all is now installable [13:11] ..again [13:14] tjaalton: do you think my mess is related to the X updates? [13:14] mdz: I doubt it, I've been using these for a week now [13:15] mdz: compiz at least doesn't work with intel with the newest mesa [13:15] tjaalton: (gnome-terminal:8546): Gdk-CRITICAL **: get_monitor: assertion `monitor_num < screen_x11->n_monitors' failed [13:15] looks incriminating [13:15] mdz: well, gdm doesn't work here so I can't get that far now, after a reboot :) [13:16] Mirv: running metacity here (which only barely runs) [13:16] yes, compiz should blacklist intel for now [13:16] my gdm is broken, but I think for the same reasons as everything else [13:16] tjaalton: I don't see cyrix, imstt, via hitting the archive yet? synaptic would like to remove -all:s and xorg because of those [13:17] Mirv: update.. [13:17] gnome-terminal segfaults after the above error; gnome-panel segfaults in panel_multiscreen_width [13:17] both behave as if they aren't getting what they expect from the X client libraries [13:17] gnome-terminal somehow manages to render its initial window, but clicking any menu segfaults it [13:17] likewise for metacity [13:18] this is running with vesa; -intel doesn't even get this far [13:18] tjaalton: yep, archive.ubuntu.com [13:18] Mirv: cyrix and imstt have been removed; via is broken but doesn't block xserver-xorg-video-all so you can let it be removed [13:18] Mirv: as of a few minutes ago -all is now fine for me [13:19] cjwatson: right. [13:22] looks like the rest is just a synaptic problem when not using smart method but marking the packages manually [13:22] tjaalton: with -intel, my X server crashes in libfb.so [13:24] but there is so much wrong at this point that I'm not sure where the fault is [13:26] mdz: yes, seems that intel fails here as well [13:26] I'll try the previous kernel [13:27] tjaalton: tried that, didn't help [13:27] I am getting some mtrr errors, don't know if they're related [13:27] [ 60.432466] mtrr: no MTRR for e0000000,770000 found [13:27] [ 63.459226] mtrr: base(0xe0000000) is not aligned on a size(0x770000) boundary [13:27] this is back on 2.6.24-19 [13:28] saw the same on 2.6.26 [13:33] tjaalton: what would I need to downgrade in order to try the old -intel? [13:33] mdz: quite a lot.. I'll try to rebuild something [13:35] good morning everyone! [13:38] tjaalton: doesn't build with the intrepid libdrm-dev [13:40] pitti: shall I make the nvidia driver conflict and replace nvidia-kernel-common now or shall I wait? [13:40] mdz: the old intel? no, it needs a fix in configure.ac [13:40] tjaalton: fixed that, it wants xf86mm.h [13:40] which was in the old libdrm-dev but not the new [13:40] tseliot: if you want to use n-k-c for the bits we discussed (config, debconf, modalias lists), and having the current package installed doesn't hurt, just leave it for now [13:41] it builds after downgrading libdrm [13:42] tjaalton: fails in the same way as before though [13:42] segfault in libfb.so [13:42] pitti: ok. BTW if your Intrepid X crashes, is because of the /etc/init.d/nvidia-glx-. I'll make sure that it's removed in the postinst, just in case [13:50] mdz: looks like EXA is broken [13:50] Option "AccelMethod" "XAA" seems to work [13:51] VT's are broken though [13:53] tjaalton: confirmed here [13:53] I'm not sure anymore, but the xserver I had running before was a vanilla debian one [13:53] let me see if that affects my segfault issues [13:53] so a patch of ours broke it [13:54] tjaalton: confirmed, I can login to GNOME with XAA [13:54] tjaalton: so my segfault issues seem somehow related to vesa [13:55] I'll try to confirm that [13:58] tjaalton: I wonder if it's the greedy patch, which is usually not endorsed/supported by upstream [13:59] Mirv: could be.. [14:00] a rebuild it is [14:07] pitti: another thing: which section should I set in the control files? multiverse/misc? [14:10] tjaalton: I've confirmed GTK clients segfaulting if I run with the vesa driver, which presumably doesn't use exa, so that seems to be a separate problem [14:10] mdz: yeah it's separate.. vesa was updated too (1.3.0 -> 2.0) [14:11] tjaalton: on which package should I file the bug about exa? -intel or -core? [14:11] mdz: core, but I'll rebuild the server to see if commenting out a single patch makes it work again [14:11] 15:53 < tjaalton> so a patch of ours broke it [14:11] (most likely) [14:13] vesa 2.0.0 + xserver 1.5 works under virtualbox for me. but I haven't yet tried all these on real hw. [14:17] tjaalton: filed as bug 246581 [14:17] Launchpad bug 246581 in xorg-server "X server crash in libfb.so when EXA is enabled" [Undecided,New] https://launchpad.net/bugs/246581 [14:17] cjwatson: I'm about to look into creating the infamous server seed, but I'm not sure where it belongs, really. Off the top of my head, I'm guessing just separate file in ubuntu.intrepid? [14:18] hm, it's not the greedy patch [14:19] soren: for now, it would be best as a separate file in ubuntu.intrepid, yes [14:19] soren: though I'd like it and the other *-server seeds to move out to a separate server.intrepid seed collection at some point [14:20] cjwatson: Right. The fact that each of {ubuntu,kubuntu,xubuntu,mobile}.intrepid have a server-ship is a bit confusing to me. [14:20] "seed collection"? Is the term "seed pot" now deprecated? (I'm hoping to hear "yes"). === effie is now known as keffie_jayx [14:21] now that's a cool name... [14:21] I think the suggestion was "seed pod", actually [14:21] That makes more sense :) [14:21] Ah. I misheard then. "seed pod" makes more sense. [14:21] I don't think I've bothered to settle on anything "officially", although I did use the term "collection" in germinate(1) recently [14:22] I'm willing to consider the documentation in germinate to be the official source of nomenclature for seed management. [14:22] soren: server-ship> I definitely regard that as a bug [14:22] but it's easier to fix when we can point to somewhere and say "look, this is the final home" [14:23] cjwatson: Indeed. [14:23] Mirv,tjaalton: vesa issue is bug 246585 [14:24] Launchpad bug 246585 in xserver-xorg-video-vesa "GTK applications crashing reproducibly when using vesa" [Undecided,New] https://launchpad.net/bugs/246585 [14:47] mount [14:47] nice [14:57] mdz: the intel bug was not on the server after all. it's the "force greedy exa" patch on intel [14:59] tjaalton: I've updated the bug accordingly [14:59] mdz: oh, thanks [15:11] hello there === thekorn_ is now known as thekorn [15:59] tseliot: how did the testin go? [16:02] pitti: I'm still testing. They seem to work well. I'll bump the release for my PPA but we'll have to remove it for Intrepid, so that it's ubuntu1 [16:03] tseliot: let me know when you uploaded, I'll test it here as well [16:03] pitti: sure [16:03] * tseliot logs out to try the new drivers [16:03] the first uploaded version can be 0ubuntu2.. [16:04] no need to change IMHO [16:04] tjaalton: ok, let me fix the changelog then [16:05] tseliot: oh you already did it, nevermind then [16:05] tjaalton: I haven't uploaded anything yet [16:06] pitti: have you an idea why many build logs have a line "sh: gcc: not found" in them? [16:07] ugh, no; infinity, do you? ^ [16:07] gcc is overrated ... write more scripts ! [16:08] it's harmless, whatever it is [16:08] tjaalton: hm, on my laptop I only have -intel installed, and purged all the other drivers; dist-upgrade now wants to install all of them again, and I don't seem to be able to keep just -intel; any idea what's wrong there? [16:08] tjaalton: i. e. is -all strictly depended on now? [16:08] by xorg, no ? [16:09] pitti: no, just "force" the upgrade of -intel [16:09] pitti: xserver-xorg depends on video-all [16:09] ah, its xserver-xorg ... [16:09] well, I can force it, of course, but ideally it would just work? [16:10] xserver-xorg Depends: xserver-xorg-video-all | xserver-xorg-video-2, xserver-xorg-input-all | xserver-xorg-input-2 [16:10] uh no, it should be enough to have just one driver which provides video-2.9 [16:10] those need to get bumped for the new ABI version [16:10] crap [16:10] ah, it's -2.9 now [16:10] hmm no, they are fine here [16:10]