| billisnice | what programming language is mainly used in Ubuntu development? | 00:09 |
|---|---|---|
| TheMuso | billisnice: Python is used a fair bit. | 00:21 |
| cjwatson | also quite a bit of C (and too many other languages to list, at varying concentrations), and packaging requires make and shell | 00:23 |
| cjwatson | flexibility to pick up new languages quickly is more important than raw proficiency in any single language, IMO | 00:23 |
| TheMuso | Agreed. | 00:24 |
| hdon | cjwatson: yes, thanks, someone else already schooled me about those particular macros ;) | 00:49 |
| LlamaZorz | Hey guys,does anybody know when firefox forks for the flash plugin? | 00:59 |
| slangasek | james_w: debian/squeeze/egenix-mx-base also out of date | 01:16 |
| slangasek | james_w: in this case, debian/egenix-mx-base also appears to be out of date | 01:17 |
| === yofel_ is now known as yofel | ||
| * cody-somerville wonders why dbus-daemon would be eating up 30-50% cpu. | 01:57 | |
| fagan | cody-somerville: it depends on the traffic | 01:59 |
| fagan | its either that or its a bug | 01:59 |
| cody-somerville | strace shows it polling over and over and over and each time it says resource unavailable | 01:59 |
| fagan | weird | 01:59 |
| cody-somerville | I'm thinking its a bug in gnome-system-monitor since gnome-system-monitor is refusing to exit now | 01:59 |
| m4t | dbus-monitor show anything? | 02:00 |
| cody-somerville | oh yes | 02:00 |
| cody-somerville | just as I suspected | 02:00 |
| fagan | gnome-system-monitor is a hog anyway | 02:00 |
| m4t | hrm which monitors do you have enabled? | 02:00 |
| cody-somerville | I think its trying to get info about two loop back devices I have mounted | 02:01 |
| fagan | Are the devices properly mounted and recognised at the moment? | 02:01 |
| m4t | maybe i have 'gnome-system-monitor' confused with the system monitor panel applet | 02:03 |
| fagan | m4t: system>admin>system monitor | 02:03 |
| cody-somerville | ah | 02:03 |
| m4t | yea. /usr/bin/gnome-system-monitor | 02:03 |
| cody-somerville | it was actually the cd in my cdrom drive that was the problem | 02:03 |
| cody-somerville | after ejecting it, gnome-system-monitor quit and dbus is much quieter now. | 02:04 |
| * m4t uses htop for that sort of thing | 02:04 | |
| m4t | no pretty graphs though | 02:04 |
| * fagan doesnt use cds anymore | 02:04 | |
| * fagan loves the pretty graphs | 02:05 | |
| fagan | I cant wait for the UDS :) | 02:07 |
| chrisccoulson | cody-somerville - i've seen that issue with gnome-system-monitor as well (and there's a bug report for it too) | 02:09 |
| chrisccoulson | it actually seems like a loop in gvfs somewhere | 02:10 |
| fagan | cody-somerville: how do you force an upgrade to lucid? | 02:10 |
| * fagan got it, good google :) | 02:13 | |
| sconklin | I am obviously missing something - how can I change the date in karmic - I need to set it into the past to workaround a bug | 02:25 |
| sconklin | The admin applet changes it back, even though manual configuration is selected | 02:26 |
| mustakrakish | need help with PGP key for repo's http://paste.ubuntu.com/316517/ | 02:30 |
| mustakrakish | need help with *GPG key for repo's http://paste.ubuntu.com/316517/ | 02:32 |
| cjwatson | mustakrakish: #ubuntu, please | 02:33 |
| maxb | mustakrakish: That is not a development question, so is offtopic for this channel. Please see the general user support channel, which is #ubuntu . | 02:34 |
| === jtimbermo is now known as jtimberman | ||
| new_to_linux | hi | 02:57 |
| fagan | new_to_linux: hi | 02:57 |
| new_to_linux | please help, there is no install button in ubuntu software centre | 02:58 |
| mustakrakish | apply | 02:58 |
| new_to_linux | i just switched from windows | 02:58 |
| ScottK | new_to_linux: The best channel for getting questions like that answered in #ubuntu. | 02:58 |
| new_to_linux | ScottK: thanks | 02:58 |
| === asac_ is now known as asac | ||
| dholbach | good morning | 07:46 |
| smwn | morning | 07:46 |
| dholbach | hi smwn | 07:47 |
| smwn | can I hear a w00p | 07:50 |
| pitti | Good morning | 07:50 |
| dholbach | smwn: http://photos-c.ak.fbcdn.net/hphotos-ak-snc1/hs202.snc1/6935_251765935091_893075091_8788600_1697850_n.jpg | 07:50 |
| smwn | HAHA | 07:52 |
| \sh | moins | 08:19 |
| === dholbach_ is now known as dholbach | ||
| === dpm_ is now known as dpm | ||
| === tkamppeter_ is now known as tkamppeter | ||
| === highvolt1ge is now known as highvoltage | ||
| === highvolt1ge is now known as highvoltage | ||
| === evand is now known as ev | ||
| liw | tkamppeter, I got my Brother label printer to work yesterday; what's the best way to get that support included in Ubuntu (on the assumption that I don't want to maintain it myself)? should I file a bug and if so, against which package? | 11:08 |
| === akgraner_ is now known as akgraner | ||
| tkamppeter | liw, how did you get your printer to work? Did you download a driver? Is the driver free software? Is it from Brother | 11:50 |
| tkamppeter | pitti, hi | 11:51 |
| pitti | hi tkamppeter | 11:51 |
| * pitti fiddles with tzdata's 3.0 package format until it works with launchpad again | 11:52 | |
| tkamppeter | pitti, it is about the auto-downloadable drivers. Does Ubuntu ship any download keys for any hardware manufacturers, like NVidia or so? | 11:59 |
| Riddell | pitti: amichair is a new member of Team Kubuntu and has been fixing various bugs in Kubuntu apps recently. he's looking at jockey-kde today and may have some questions to get into the codebase | 12:00 |
| pitti | Riddell: oh, great | 12:01 |
| pitti | amichair: hello :) | 12:01 |
| pitti | tkamppeter: no, not right now | 12:01 |
| amichair | pitti: hey there | 12:01 |
| pitti | tkamppeter: ideally we wouldn't need to, and just download them on demand; that would require them to be signed by a key that we already trust, though | 12:02 |
| pitti | tkamppeter: (well, we need to trust the key either way) | 12:02 |
| amichair | pitti: first thing, I'm just looking through jokey-kde bug reports, and I can't quite distinguish between backend and gui bugs (most of them just say 'crash') - do u have more specific info on something I can start out with? | 12:04 |
| amichair | pitti: second, I notice there are a bunch of sys.exits around - is this normal? is there nothing requiring orderly shutdown in there? | 12:05 |
| pitti | amichair: I'm afraid you have to look at the stack trace; a d-bus error is a backend crash, while most of the rest (sigsegv, etc.) are most probably bugs in python-qt4 or python-kde4 | 12:05 |
| pitti | amichair: without calling sys.exit(), there are some remaining processes/threads which aren't autocleaned for some reason | 12:06 |
| amichair | pitti: hmmm... | 12:06 |
| pitti | amichair: bug 458662 is similar | 12:07 |
| ubottu | Launchpad bug 458662 in apport "apport-kde: "Invalid problem report: Package nonexistentarg does not exist" => OK => still "Collecting problem information" dialog" [Low,Fix released] https://launchpad.net/bugs/458662 | 12:07 |
| pitti | amichair: (please note that I didn't actually write most of jockey-kde) | 12:07 |
| amichair | pitti: (and I have no previous dev experience with linux, kubuntu, kde, qt or pythong... I think we'll make a great team! :-) ) | 12:08 |
| pitti | hah | 12:08 |
| tkamppeter | pitti, the concept is that manufacturers supply the keys and the distros include the keys from manufacturers which they trust. | 12:08 |
| pitti | tkamppeter: well, those are two different "trust" here | 12:08 |
| pitti | tkamppeter: we can decide which manufacturer we trust to build good packages -- those are the ones which we can offer | 12:08 |
| pitti | tkamppeter: but trusting a key is entirely different, it requires identity verification | 12:09 |
| tkamppeter | pitti, this way the distros have to trust the manufacturers and not the LF and only manufacturers and not the LF take responsibility. | 12:09 |
| liw | tkamppeter, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555892 has details | 12:09 |
| ubottu | Debian bug 555892 in wnpp "RFP: ptouch-driver -- CUPS/Foomatic driver for Brother P-touch label printers" [Normal,Open] | 12:09 |
| pitti | i. e. a trusted path through signatures to their key | 12:09 |
| pitti | tkamppeter: so, if the manufacturer's key is signed by someone who we trust, we can just download it on demand; but conversely, if we can't trust the manufacturer's key, then shipping the key by default doesn't increase the confidence in it by any way | 12:10 |
| pitti | (to the contrary, we would make ourselves untrustworthy with key handling) | 12:10 |
| tkamppeter | pitti, so what do I need to tell the manufacturers what they have to do with their keys so that their packages get auto-downloaded? Who must sign their keys so that all distros accept their keys? | 12:12 |
| directhex | are we not autosyncing new packages from squeeze? | 12:13 |
| ScottK | We are. | 12:14 |
| ScottK | Autosync is not, however, a continuous process | 12:14 |
| Keybuk | or, in fact, an automatic process ;) | 12:14 |
| ScottK | It's done periodically. | 12:14 |
| ScottK | That too | 12:15 |
| directhex | how periodic? the packages i'm noticing were all in squeeze when karmic shipped | 12:15 |
| pitti | tkamppeter: well, you know how key signing works? | 12:15 |
| ScottK | Well it's run once since then. | 12:15 |
| pitti | tkamppeter: either there's a central authority (like the LF) that generates a key and signs driver manufacturer keys, or we have to meet with them directly to sign them | 12:16 |
| pitti | tkamppeter: in the first case, all distros would sign the LF key, and the LF woudl sign all the manufacturer keys; in the second case, each distro has to sign each manufacturer key | 12:16 |
| slangasek | directhex: it's conceivable that there hasn't been a new package sync run yet, I know I didn't make it that far on archive day on account of spending my time updating the sync blacklist for existing packages instead | 12:19 |
| slangasek | Keybuk: have some time to talk about boot-time hdparm settings? | 12:19 |
| directhex | slangasek, oh, debian syncs still go into binary NEW don't they? let me check | 12:19 |
| tkamppeter | I know about keysigning session where people meet physically and sign the GPG keys of each other, is a physical meeting of a Ubuntu/Canonical representative with one representative of each manufacturer needed for this signing? Or is there a way by internet and phone to do this? | 12:19 |
| Keybuk | slangasek: sure | 12:20 |
| tkamppeter | pitti: ^^ | 12:20 |
| slangasek | Keybuk: so it's a no-brainer that the current behavior, which may cause multi-second delays at boot time, is wrong; but I think we still need to be setting the configured apm policy at boot time | 12:21 |
| Keybuk | slangasek: "still" ? | 12:21 |
| Keybuk | we don't set that right now | 12:21 |
| Keybuk | the hdparm udev rule comes from the days where we had to futz with DMA settings and stuff | 12:22 |
| slangasek | hmm, we do, actually... though perhaps we only set it via /etc/init.d/acpi-support | 12:22 |
| Keybuk | obviously since libata, that isn't used | 12:22 |
| Keybuk | slangasek: I just grepped through that, couldn't find anything about hdparm | 12:22 |
| Keybuk | wing-commander /etc% grep -r hdparm init init.d acpi power pm | 12:22 |
| Keybuk | init.d/bootlogd:# X-Start-Before: hostname keymap keyboard-setup procps pcmcia hwclock hwclockfirst hdparm hibernate-clean | 12:22 |
| pitti | tkamppeter: you can't do it by internet, since the purpose of this is to have physical evidence that the key creator is actually the one he pretends to be ("can't pull yourself out of the swamp") | 12:22 |
| Keybuk | -- | 12:22 |
| slangasek | Keybuk: /etc/init.d/acpi-support calls /etc/acpi/power.sh calls pm-powersave calls /usr/lib/pm-utils/power.d/95hdparm-apm | 12:23 |
| tkamppeter | liw, you tell in the Debian bug report that you have reported your problems upstream. Did you get any answer from the upstream author? | 12:23 |
| Keybuk | ahh | 12:23 |
| Keybuk | slangasek: got you | 12:23 |
| liw | tkamppeter, not yet | 12:23 |
| pitti | tkamppeter: phone is better, but not as trustworthy than seeing someone in an office, with a passport, etc. | 12:23 |
| directhex | slangasek, nope, doesn't look that way. remind me to check next time the sync run happens | 12:23 |
| Keybuk | slangasek: is that one of our scripts, or an upstream one? | 12:23 |
| slangasek | Keybuk: dunno offhand; can check | 12:24 |
| Keybuk | slangasek: you were thinking we should do that by calling out to hdparm on the drive in a udev rule instead? | 12:24 |
| slangasek | Keybuk: now as for the current udev script not doing apm settings... it applies any settings the user has configured in /etc/hdparm.conf, including apm and spindown, and nothing else does this by default | 12:25 |
| slangasek | (granted, that's not where we configure the system default apm settings, so yes, by default that part is a no-op) | 12:25 |
| tkamppeter | pitti: The problem with a key at the LF is that this could imply that the LF would take responsability on the manufacturer's driver packages. | 12:26 |
| pitti | tkamppeter: if the manufacturer has a working SSL certificate, they might also put the key and fingerprint on their web page (with https); that might actually work better | 12:27 |
| pitti | tkamppeter: as I said, trusting a key and trusting a package are completely independent | 12:27 |
| slangasek | Keybuk: the point I think we want to get to is that there's a single call to hdparm for each drive at the very end of the init sequence for any drives then available, and a udev rule that picks up any drives added after | 12:27 |
| pitti | tkamppeter: just because I am convinced that a key that says "Joe Sixpack" really belongs to a physical person "Joe Sixpack" does not mean that I trust any of his actions :) | 12:28 |
| tkamppeter | Working SSL certificate meas that their site is trusted by some certification authority? | 12:28 |
| liw | tkamppeter, I need to leave now; when you have time, if you can check the Debian bug I referred to for the ptouch-driver package, that would be most helpful, thanks | 12:28 |
| pitti | tkamppeter: yes | 12:28 |
| slangasek | that would mitigate the effects of hdparm on boot performance | 12:28 |
| pitti | the chain has to start somewhere with a physical identity proof | 12:28 |
| slangasek | (and if the udev rule itself is doing things that are inappropriate, we can fix that along the way) | 12:28 |
| tkamppeter | pitti, will that be enough to trust the manufacturer's keys when they come from this site with SSL certificate via https? | 12:29 |
| Keybuk | slangasek: it's not the effect of hdparm I care about | 12:29 |
| Keybuk | just the unconditional sync in the existing rule ;) | 12:29 |
| pitti | tkamppeter: well, "enough" is a matter of taste, but I think for these purposes yes | 12:30 |
| Keybuk | udev doesn'tre | 12:30 |
| pitti | tkamppeter: since otherwise people would download them directly from their web site, which involves the same trust (SSL cert) | 12:30 |
| Keybuk | udev doesn't really work in a "don't do it during boot but do it later" kind of way | 12:30 |
| Keybuk | frankly even upstart doesn't have a "very end of the init sequence" kinda thing | 12:30 |
| Keybuk | wouldn't it be better to do the hdparm calls for each drive from udev | 12:30 |
| slangasek | Keybuk: right; I don't understand why that unconditional sync is there, but the effect is obvious | 12:30 |
| Keybuk | including setting user settings and apm settings? | 12:30 |
| Keybuk | that way you get a single hdparm call per drive | 12:31 |
| Keybuk | which is called before the drive is actually used | 12:31 |
| slangasek | Keybuk: well, <cough> users with /usr on a separate partition aren't guaranteed to have the on_ac_power command available when the udev rule runs, so we would still have to re-apply the correct apm setting later | 12:32 |
| Keybuk | slangasek: is that the thing in /usr/bin that only looks in /proc and /sys ? :p | 12:32 |
| Keybuk | and is only in /usr because someone wrote it in awk | 12:32 |
| slangasek | heh | 12:32 |
| tkamppeter | pitti, so what I have to tell the manufacturers is to have an SSL certificate for their site from which the keys and packages should gget downloaded? | 12:33 |
| slangasek | it's also in /usr because it's not related to system recovery | 12:33 |
| Keybuk | would probably be better to fix *that* | 12:33 |
| Keybuk | since we already have the "can't call on_ac_power to decide whether to fsck /usr" thing :p | 12:33 |
| slangasek | yeah, that's a possibility | 12:33 |
| pitti | tkamppeter: well, either we need to sign their GPG key, or they must have an officially signed SSL cert and put the key/fingerprint on their website | 12:33 |
| tkamppeter | pitti, are there any requirements on where to place the keys relative to the packages so that the download tools find it? | 12:34 |
| slangasek | ok; so if we get on_ac_power in /bin where we can rely on it, then we can use the udev rule for all boot-time settings, and just arrange to make pm-powersave not call hdparm when invoked from init | 12:34 |
| pitti | tkamppeter: if the GPG keys have a proper signature, they should just be on the keyserver network | 12:34 |
| slangasek | and then remove that sync if we can confirm it's bogus | 12:34 |
| pitti | tkamppeter: if not, then we need to include them (in jockey or whereever) | 12:34 |
| slangasek | Keybuk: ^^ sound right? | 12:34 |
| Keybuk | slangasek: yup | 12:35 |
| slangasek | ok | 12:35 |
| slangasek | Keybuk: cheers :) | 12:35 |
| Keybuk | slangasek: the sync is almost certainly bogus in Ubuntu | 12:35 |
| Keybuk | I can imagine why it's there in Debian | 12:35 |
| Keybuk | (udev runs after things are mounted) | 12:35 |
| slangasek | hmm | 12:35 |
| Keybuk | I can't think of any way a udev rule could run on a mounted filesystem ;) | 12:36 |
| slangasek | why does udev run after things are mounted in Debian, either? | 12:36 |
| Keybuk | slangasek: I haven't looked at Debian in a while, but udev used to run very late | 12:36 |
| Keybuk | like after /usr was mounted | 12:37 |
| slangasek | /etc/rcS.d/S03udev | 12:37 |
| Keybuk | it wasn't always there though, right? | 12:37 |
| tkamppeter | pitti, what I now need to do is to put together some step-by-step instructions of generating keys, getting them signed or getting them onto an SSL-certified web site, what to provide to the download tools and where, ... Note for that that many manufacturers are not very Linux-aware. | 12:37 |
| Keybuk | the hdparm udev rule is old ;) | 12:37 |
| Keybuk | and converted from an even older init script | 12:37 |
| Keybuk | slangasek: ah | 12:38 |
| Keybuk | but S03udev just means udevd | 12:38 |
| slangasek | Keybuk: I don't see any record in the udev package of an init script migration | 12:38 |
| Keybuk | you could still have the block device appear later? even though it's already been mounted | 12:38 |
| Keybuk | slangasek: I'm only guessing :) | 12:39 |
| slangasek | hrm, how would it /get/ mounted in that case? static device node? | 12:39 |
| slangasek | S03udev includes udevadm trigger/settle calls | 12:39 |
| Keybuk | maybe | 12:40 |
| slangasek | let me dig through the hdparm package, to see why this rule /really/ does what it does | 12:40 |
| Keybuk | at least we absolutely guarantee that we don't mount things until udev is done with them :p | 12:40 |
| Keybuk | slangasek: oh, I think it's always been there | 12:40 |
| * Keybuk wrote that script | 12:40 | |
| slangasek | oh? :) | 12:40 |
| Keybuk | and it looks like I just copied that from the old init script | 12:40 |
| slangasek | odd, the changelog says thom wrote it | 12:40 |
| Keybuk | thom uploaded it | 12:41 |
| slangasek | ah | 12:41 |
| * Keybuk was on the Launchpad team at the time | 12:41 | |
| Keybuk | (technically :p) | 12:41 |
| Keybuk | ahh | 12:42 |
| Keybuk | Vibe | 12:42 |
| Keybuk | that was a good UDS | 12:42 |
| slangasek | yeah, this -q -f goes all the way back to warty | 12:44 |
| slangasek | ahwell | 12:44 |
| Keybuk | slangasek: hole in the ground, with water in it | 12:45 |
| yoshi765 | DAMN UBUNTU | 12:46 |
| Tm_T | !op | yoshi765 | 12:46 |
| ubottu | yoshi765: Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk | 12:46 |
| slangasek | yoshi765: not an appropriate use of this channel. | 12:46 |
| yoshi765 | stfu | 12:46 |
| Hobbsee | clearly going to have a lot to say... | 12:47 |
| Tm_T | Hobbsee: shame this is one of the few channels I don't have rights ): | 12:48 |
| Hobbsee | heh :) | 12:48 |
| * Tm_T doesn't like just watch when there's some cleaning to do | 12:49 | |
| === pedro__ is now known as pedro_ | ||
| === debfx_ is now known as debfx | ||
| amichair | pitti: when selecting to activate a driver in jockey, is there anything done that might take a long time? does it download anything? or it's supposed to be pretty much immediate? | 13:11 |
| pitti | amichair: sorry, was at lunch; yes, it will take a long time, which is why it spawns a progress dialog | 13:25 |
| pitti | it needs to download, unpack, install, etc. | 13:25 |
| amichair | pitti: ok, my test did a quick one so didn't see progress bar, and wondered if I should add one :-) | 13:26 |
| pitti | amichair: there should be one already; it works for me, anyway | 13:27 |
| amichair | pitti: ok, thanks | 13:29 |
| pitti | tkamppeter: instead of adding the "LogDebugHistory" to cupsd.conf in a patch, can you please just change the internal default? This will (1) keep the setting for admins who changed it, and (2) avoid a conffile change | 13:31 |
| pitti | tkamppeter: also, I think "2000" is a more reasonable limit than "999999" -- the latter would potentially result in a 100 MB log file | 13:32 |
| === chuck_ is now known as zul | ||
| === kklimond- is now known as kklimonda | ||
| tkamppeter | pitti, I would leave the big value, as this makes the logging more or less unlimited. There should not be that many "DEBUG:" messages in the filters. Up to now in user-supplied error_logs in bug reports such an excess never happened. | 13:42 |
| tkamppeter | pitti, it is worse if some lines are missing in a user-supplied error_log. | 13:42 |
| pitti | but if they do, it'd be more or like a DoS of hard disk and bug trackers | 13:42 |
| pitti | well, but a million lines? | 13:43 |
| pitti | if there's something logging more than 1000 lines about an incident, this is certianly of questionable utility? | 13:43 |
| tkamppeter | A million lines is never reached. 10000 will perhaps happen. | 13:43 |
| pitti | so, let's make it 10000 then? | 13:44 |
| slangasek | Keybuk: hmm, the awk stuff is only used for PMU and APM... could just ignore this :-P | 13:44 |
| slangasek | Keybuk: do you happen to know if non-apci systems shoul also have /sys/class/power_supply/? | 13:45 |
| Keybuk | slangasek: they should | 13:45 |
| Keybuk | whether they do yet or not ... | 13:45 |
| Keybuk | *cry* | 13:46 |
| Keybuk | why is gdb skipping the entire body of the function when I do "n" | 13:46 |
| * Keybuk blames kees | 13:46 | |
| slangasek | so I could move that block outside of the "if /sbin/acpi_available" check, and make the awk stuff Somebody Else's Problem | 13:46 |
| pitti | tkamppeter: FYI, I'm updating to 1.4.2 to grab the security fix | 13:47 |
| tkamppeter | pitti, I will add a fix to pdftopdf, got it from Otani-san today. | 13:47 |
| tkamppeter | pitti, you have reverted my last commit? | 13:49 |
| pitti | right | 13:49 |
| Keybuk | doko: around? | 13:53 |
| sladen | pitti: how should I poke apport to stop it reporting particular seahorse-agent crash dumps. There's a couple of thousand dups to bug #429322 (to the point that it has broken LP) and more stack-trace uploads probably aren't really necessary | 13:54 |
| ubottu | Launchpad bug 429322 in seahorse-plugins "seahorse-agent assert failure: ERROR:iop-profiles.c:606:IOP_generate_profiles: assertion failed: (obj && (obj->profile_list == NULL) && obj->orb)" [High,Confirmed] https://launchpad.net/bugs/429322 | 13:54 |
| pitti | slangasek: there is an apport bug pattern for it since Tuesday or so | 13:54 |
| pitti | so it shouldn't even be possible to report further dups | 13:54 |
| pitti | (and yay for the bug which kept apport enabled after stable release :-( ) | 13:55 |
| tkamppeter | pitti, pdftopdf fix from Otani-san is committed. | 13:56 |
| sladen | pitti: the dups are still arriving, or so that just the tracer catching up | 13:56 |
| doko | Keybuk: otp | 13:56 |
| pitti | sladen: retracers still have a huge backlog unfortunately | 13:57 |
| pitti | (for the same reason, swamped after final release) | 13:57 |
| Keybuk | doko: when you get back, gcc appears to have deleted the entire body of a function when compiling with -O0 ... how would I debug that ? ;p | 13:58 |
| maxb | james_w: Hi, are you around today? I was wondering if you could comment on bug 481097 | 14:06 |
| ubottu | Launchpad bug 481097 in udd "subversion 1.6.6dfsg-1 in Debian not imported to branch" [Undecided,New] https://launchpad.net/bugs/481097 | 14:06 |
| doko | Keybuk: hmm, do you have a test case? when did this "optimization" start? | 14:06 |
| pitti | tkamppeter: btw, I'm going to do an upload now, but I fully expect that I have to do another one next week or so (new poppler in Debian didn't build yet everywhere, and I need to test it on mips again for the PIE issue) | 14:13 |
| pitti | tkamppeter: so, if you have other pending fixes they don't need to wait long | 14:13 |
| tkamppeter | pitti, I have also done the LogDebugHistory fix now. | 14:13 |
| pitti | ah, thanks | 14:13 |
| tkamppeter | Simply bzr pull and you have it. | 14:13 |
| * pitti cancels build and builds again | 14:13 | |
| Keybuk | doko: s'ok, was a code error ;) | 14:20 |
| Keybuk | silly upsream | 14:20 |
| Keybuk | if (console->fd < 0); | 14:20 |
| Keybuk | return | 14:20 |
| doko | heh | 14:20 |
| === chuck_ is now known as zul | ||
| tkamppeter | pitti, can you help me on getting step-by-step instructions together for the manufacturers about generating keys, signing them or putting them on an SSL-certified site, signing the packages, so that users can easily get their drivers auto-downloaded? | 15:03 |
| === mbarnett` is now known as mbarnett | ||
| === Keybuk_ is now known as Keybuk | ||
| === dendro-afk is now known as dendrobates | ||
| === chuck_ is now known as zul | ||
| theclaw | hi | 15:47 |
| theclaw | everytime firefox gets updated, the "quick search" entries get replaced/updated | 15:48 |
| theclaw | is this behaviour wanted? | 15:48 |
| dholbach | pitti: do you have access to robert_ancell's seahorse fix? | 16:11 |
| dholbach | pitti: there's like 3000 subscribers on the bug already | 16:12 |
| dholbach | mostly due to duplicates | 16:12 |
| pitti | tkamppeter: there's plenty of tutorials already; let's sit down next week and write/link something | 16:47 |
| pitti | dholbach: it should already be in karmic-proposed | 16:47 |
| pitti | dholbach: what do you mean with "access"? | 16:47 |
| dholbach | pitti: the bug is timing out in LP - good to know the fix is on its way :) | 16:47 |
| pitti | dholbach: yeah, took me like ten times to get the page, too :-( | 16:48 |
| pitti | mail responses FTW | 16:48 |
| Riddell | seb128: where did you upload the fix for bug 462049 to, lubic or -proposed? | 17:00 |
| ubottu | Launchpad bug 462049 in libindicate "Plasma crashes unexpectedly" [High,Fix committed] https://launchpad.net/bugs/462049 | 17:00 |
| Riddell | ..lucid | 17:00 |
| jussi01 | Riddell: did you notice my comment about the links to kubuntu stuff on summit this morning? | 17:01 |
| Riddell | jussi01: nope, what was that? | 17:01 |
| seb128 | Riddell, proposed we pocket copy then | 17:03 |
| jdong | lubic :) | 17:03 |
| seb128 | Riddell, why? | 17:03 |
| jussi01 | Riddell: just that the links on the summit calendar pages go to non-existant wiki pages when they should go to the corresponding LP pages... | 17:03 |
| Riddell | seb128: I just didn't see it in the queue, but there it is now | 17:03 |
| jussi01 | Riddell: click on kubuntu lucid development here for instance: http://summit.ubuntu.com/uds-l/2009-11-16/ | 17:03 |
| Riddell | jussi01: I have complained about this but I don't know if I complained to the right person and I probably didn't complain in the right way | 17:04 |
| jussi01 | Riddell: ok, Ill go annoy jorge and jono about it | 17:04 |
| jussi01 | Riddell: Ill try make sure it happens | 17:05 |
| Riddell | pitti: mind if I accept the SRU for bug 462049 into -proposed? upstream are getting grumpy about it | 17:08 |
| ubottu | Launchpad bug 462049 in libindicate "Plasma crashes unexpectedly" [High,Fix committed] https://launchpad.net/bugs/462049 | 17:08 |
| mvo | do we have a wiki page that gives a step-by-step instruction how to do/trigger a fsck on the root fs? | 17:08 |
| * pitti adds "daily SRU round, take III" to his queue | 17:08 | |
| pitti | Riddell: will do | 17:08 |
| jdong | hahaha | 17:09 |
| pitti | mvo: wouldn't tune2fs -C 50 /dev/... do? | 17:09 |
| pitti | that's what I usually do for testing | 17:09 |
| jussi01 | !fsck | 17:09 |
| ubottu | fsck is the FileSystem ChecKer, which runs automatically when you boot if you didn't shutdown cleanly. Type "man fsck" for information on running it manually. The command "sudo shutdown -F -r now" will force a reboot and a filesystem check; "sudo touch /fastboot" will skip a filesystem check at next reboot | 17:09 |
| jussi01 | mvo: ^^ | 17:09 |
| mvo | pitti: this is similar to what I usually do, but I wonder if that is the way that we suggest to our users | 17:09 |
| pitti | mvo: well, I'd recommend -C 50; less dangerous to your data :) | 17:09 |
| pitti | mvo: oh, isn't it in friendly-recovery: | 17:10 |
| pitti | ? | 17:10 |
| mvo | jussi01: thanks | 17:10 |
| mvo | pitti: it used to until karmic, now its no longer possible to remount / in ro | 17:10 |
| jussi01 | mvo: no probs :) If anyone comes across stuff in factoids that is out of date, please lets us know though. | 17:11 |
| mvo | pitti: this has to do with upstart changes, I talked to scott about it before the release and he said its intentional | 17:11 |
| Keybuk | mvo: it isn't anything to do with upstart | 17:12 |
| mvo | Keybuk: right, let me re-phrase it "it used to work by chance, now it does no longer" - better ? | 17:13 |
| Keybuk | :) much | 17:13 |
| mvo | :) | 17:13 |
| tkamppeter | pitti, OK, can you schedule a private meeting for that? | 17:13 |
| pitti | tkamppeter: no need to be private; I'll add it | 17:14 |
| mvo | Keybuk: hm, shutdown -F is ignored in the upstart code, is there a different magic to force it on restart? | 17:16 |
| mvo | Keybuk: nevermind, I think I found it | 17:18 |
| * mvo tries touch /forcefsck | 17:18 | |
| === thekorn_ is now known as thekorn | ||
| tkamppeter | pitti, with private I meant an informal meeting, without Blueprint. | 17:25 |
| === chuck_ is now known as zul | ||
| === maco_ is now known as maco | ||
| === robbiew is now known as robbiew-afk | ||
| smoser | slangasek, ping. | 18:50 |
| === deryck is now known as deryck[lunch] | ||
| === dendrobates is now known as dendro-afk | ||
| Ademan | what should i do to find out about the new gdm/xsplash system? I haven't run into anything from the simple greeter or xsplash that has any documentation... | 19:14 |
| Ademan | also while i'm at it... the upstart script for gdm has a seemingly magical variable $CONFIG_FILE, I don't see where that's ever set, is it set by upstart? how? | 19:14 |
| lamont | pitti: around? your comment on bug 447919 is ref: lucid ,yes? | 19:45 |
| ubottu | Launchpad bug 447919 in launchpad-buildd "cups testsuite failures don't trigger a build failure" [Undecided,Confirmed] https://launchpad.net/bugs/447919 | 19:45 |
| === chuck_ is now known as zul | ||
| Ademan | does upstart set variables that are used in upstart scripts? for instance the gdm upstart script uses $CONFIG_FILE which isn't set anywhere in the script that i can see. | 19:55 |
| StevenK | Ademan: I'm guessing that's set by X, but I can't find anything to back that up | 19:59 |
| === dendro-afk is now known as dendrobates | ||
| Keybuk | cjwatson, StevenK: Remember that whole Cambridge, Plymouth, Dracut thing? | 20:21 |
| Keybuk | I have another one | 20:21 |
| Keybuk | Wayland | 20:21 |
| === robbiew-afk is now known as robbiew | ||
| sebner | Keybuk: wayland \o/ | 20:24 |
| StevenK | Keybuk: Haha | 20:25 |
| chrisccoulson | slangasek - i think i understand whats going on with your g-s-d crash now :) | 21:33 |
| chrisccoulson | and I think I can see why it regressed from jaunty too | 21:43 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| lhasbs | ubuntu 9.04 server 2.6.28 | 22:19 |
| lhasbs | massive group descriptor corruption :( | 22:19 |
| lhasbs | ext-4: group descriptors corrupted | 22:19 |
| lhasbs | Very strange and wierd here. | 22:19 |
| === cyphermo1 is now known as cyphermox | ||
| slangasek | smoser: pong | 23:00 |
| slangasek | chrisccoulson: oh? Do tell! | 23:00 |
| chrisccoulson | slangasek - the section of your xtrace log i quoted in the bug report is all triggered from a single press of Fn+F7. what happens when you press this button is that the screen info is refreshed from the server (because the screen config changed when you connected the monitor). when the screen config changes, a handler in g-s-d autoconfigures the new output. It then acts on the Fn+F7 keypress to reconfigure the output again, wit | 23:06 |
| chrisccoulson | h screen information which is now out of date | 23:06 |
| slangasek | nice | 23:06 |
| slangasek | :) | 23:06 |
| chrisccoulson | it didn't crash in jaunty because g-s-d had no handler for auto-configuring new outputs | 23:06 |
| chrisccoulson | how soon after connecting the monitor do you press Fn+F7? | 23:07 |
| slangasek | chrisccoulson: well, ideally within seconds, I don't go to the effort of plugging in a cable I'm not using :) | 23:07 |
| slangasek | but I haven't noticed the monitor ever being autoconfigured for output, without me pressing Fn+F7 | 23:08 |
| === mbiebl_ is now known as mbiebl | ||
| chrisccoulson | what i noticed from the xtrace log is that the Fn+F7 keypress arrives before the first RRScreenChangeNotify event, which should arrive when you connect the monitor | 23:09 |
| chrisccoulson | if you say that you've never seen the monitor being autoconfigured, then that would suggest that the RRScreenChangeNotify event doesn't arrive on it's own, and the xtrace log seems to support this | 23:10 |
| chrisccoulson | it only arrives after querying the configuration from the server :-/ | 23:10 |
| * slangasek nods | 23:10 | |
| chrisccoulson | and that is what seems to mess it up | 23:10 |
| chrisccoulson | so there might be a Xorg issue too | 23:11 |
| slangasek | sure | 23:11 |
| slangasek | though the g-s-d behavior seems to be racy per se | 23:11 |
| chrisccoulson | it does. normally the window of exposure should be small if the RRScreenChangeNotify event is delivered when you connect the monitor, but that doesn't seem to happen in your case | 23:12 |
| slangasek | yep | 23:13 |
| slangasek | (or in the case of other users who've reported this bug previously :) | 23:13 |
| chrisccoulson | is bryce around today? | 23:13 |
| chrisccoulson | ah, he's in #ubuntu-desktop | 23:14 |
| slangasek | right, he doesn't seem to really be around today though | 23:15 |
| chrisccoulson | slangasek - i'll add the rest of my thoughts to the bug shortly (so I don't forget them), and then try to get some input from bryce when he's around | 23:20 |
| chrisccoulson | slangasek - in the meantime, it might be good to run it through xtrace again, but watch the output in the console and see if you see the RRScreenChangeNotify event when you connect the monitor, or if it only appears after pressing Fn+F7 (just to confirm that I understand what is happening) | 23:22 |
| chrisccoulson | i don't know if you can make xtrace filter out specific messages or not | 23:22 |
| ebroder | MsMaco: ping? | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
