| TheMuso | 00000000/c | 00:11 |
|---|---|---|
| ccheney | jdong: seems it couldn't even do ~ 6mbps for me | 00:26 |
| ccheney | jdong: but if they hit the limit at 15mbps then i might need a better one, assuming the newer ones work better? i have a wrt54g | 00:26 |
| persia | ccheney: Some of the newer consumer routers can handle ~250Mbps, but some are still limited to very low speeds. It's worth looking for some user reports on specific models and usages before buying if you're currently feeling limited (alternately, wait a bit more, and get one with an Atom or ARMv7 proc that lets you reinstall with Ubuntu and run quagga) | 00:30 |
| bluefoxicy | hmm | 00:33 |
| bluefoxicy | crappy pseudo-security mechanism crashes. | 00:33 |
| * bluefoxicy ponders the security implications of password-protected screen savers and implementations. | 00:34 | |
| jdong | bluefoxicy: you mean how plugging in an external monitor made the screensaver segfault? XD | 00:35 |
| bluefoxicy | jdong: nope. gnome-screensaver-gl-helper crashed and I got an unlocked desktop | 00:35 |
| jdong | lol niiiice | 00:35 |
| jdong | I still like the way Windows does their screensaver locking. | 00:35 |
| persia | bluefoxicy: There's a number of good rants out there about how screensavers that use complex libraries are pointless (and why xscreensaver is the only real screensaver, but all screensavers are inherently bad) | 00:35 |
| jdong | the terminal services redirector unplugs the monitor and keyboard away from your session | 00:36 |
| bluefoxicy | persia: see jdong | 00:36 |
| jdong | and you get re-plugged into a kernel-owned winlogon dialog | 00:36 |
| jdong | kinda like if we chvt'ed and didn't let the user chvt back | 00:36 |
| persia | bluefoxicy: Hrm? | 00:36 |
| bluefoxicy | persia: it's possible to move a window on top the screen saver by some magic; or to move keyboard focus;etc. | 00:37 |
| slangasek | bluefoxicy: gnome-screensaver-gl-helper crashing doesn't unlock the desktop. That's why it's a separate helper. | 00:37 |
| bluefoxicy | slangasek: yet, I got a box telling me i had an application error, and nothing asked me for my password... | 00:37 |
| slangasek | then something else is going on besides gl-helper crashing | 00:38 |
| ccheney | persia: there are some routers that will be able run Ubuntu? i thought they all were using the older arm like the new marvell plug 3.0 | 00:38 |
| bluefoxicy | jdong: I've actually had my keyboard focus wind up in another window too | 00:39 |
| jdong | bluefoxicy: if you use compiz, there's some interesting exploits too | 00:39 |
| bluefoxicy | I ctrl+alt+F1'd and logged in, then killed gnome-screensaver | 00:39 |
| bluefoxicy | that got me back to my desktop XD | 00:39 |
| jdong | ebroder demonstrated a zephyr popup based glitch to me before | 00:39 |
| persia | ccheney: I don't know of any current consumer routers than can run Ubuntu. I saw some Atom consumer NAS boxes a few weeks ago, and I hear persistent rumours about new ARM devices. I imagine it won't be too long. | 00:39 |
| jdong | where alert boxes can pop up *over* the screensaver | 00:40 |
| * persia is waiting for such a router as well | 00:40 | |
| bluefoxicy | jdong: nods. | 00:40 |
| ccheney | persia: ok | 00:40 |
| jdong | I kinda wish for a chvt-based solution. | 00:40 |
| ebroder | jdong: That wasn't quite it. It was actually *another* window that would pop above the screensaver, not the popup itself | 00:40 |
| jdong | ebroder: lol even worse then | 00:40 |
| ccheney | persia: do you happen to know if weird fluctuations could be due to using a DOCSIS 2.0 instead of 3.0? I am seeing the weird spikes even connected directly to my modem with my laptop | 00:41 |
| bluefoxicy | ebroder: now can you pick which window? | 00:41 |
| ebroder | jdong: That's why Athena disabled Compiz - we didn't want to get in trouble when a browser with somebody's grades popped up over the screensaver | 00:41 |
| ebroder | bluefoxicy: I think it was pretty consistently the window that had focus before the screensaver activated | 00:41 |
| * ccheney is considering getting a Motorola SB6120 at the store and seeing if it helps any | 00:41 | |
| ebroder | bluefoxicy: Let me see if I can track down the bug... | 00:41 |
| bluefoxicy | ebroder: ahh. Damn. My cologne has better hacking power than that. | 00:41 |
| persia | ccheney: No idea. | 00:42 |
| ebroder | bluefoxicy: bug #336932 | 00:42 |
| ubottu | Launchpad bug 336932 in compiz "New windows cause panels to be raised above fullscreen applications (e.g. screensaver)" [Low,Triaged] https://launchpad.net/bugs/336932 | 00:42 |
| bluefoxicy | ebroder: lol. | 00:42 |
| persia | ccheney: I've had persistent issues with network in lucid being slow (compared to karmic), but I don't think changing my router affects that, as I get the same going between two local machines (both lucid). | 00:42 |
| bluefoxicy | ebroder: panel -> run -> killall gnome-screensaver -> unlocked. | 00:42 |
| jdong | yikes, it's any creation of new windows? | 00:42 |
| ccheney | persia: i'm getting a range from ~ 800kbps to 28000kbps with my line speed supposedly being 12000kbps | 00:42 |
| ccheney | persia: and overall a large transfer it ends up an average of 12000kbps | 00:43 |
| ccheney | but with that big of a range it makes QoS pretty much useless even if it were to work on my router | 00:43 |
| persia | ccheney: What's your uplink implementation? That sounds like transit issues rather than the local router. | 00:43 |
| ccheney | persia: its a cable modem with docsis 2.0 support connected to Comcast | 00:44 |
| bluefoxicy | ccheney: why would QoS ever work? | 00:44 |
| ccheney | bluefoxicy: well it worked ok in the past when the speed was consistent | 00:44 |
| bluefoxicy | huh. | 00:44 |
| bluefoxicy | ccheney: a more recent RFC deprecates QoS entirely | 00:44 |
| bluefoxicy | not that anyone cares | 00:44 |
| persia | ccheney: In that case, I expect you have an overprovisioned link and a governor to maintain an average speed of 12M, and you're seeing QoS hiccups from your provider's QoS. | 00:44 |
| ccheney | bluefoxicy: i meant QoS at the router level throttling lower priority traffic, perhaps the routers concept of QoS isn't the same as TCP's | 00:45 |
| bluefoxicy | ah, okay. | 00:45 |
| ccheney | bluefoxicy: but with the router needing to know your link speed for that to work when it ranges from 800kbps to 28000kbps its useless | 00:45 |
| persia | bluefoxicy: QoS is undeprecatable: that said, specific implementations (e.g. 802.16) are likely to be replaced by newer imple,entations quite regularly. | 00:45 |
| ccheney | persia: yea probably so :-\ | 00:45 |
| persia | ccheney: When I was at an ISP, we used to sell 1.5Mbps and provision 10Mbps, just to be able to flood it to mask transient issues and keep the clients happy. Mind you, this was a long time ago, when that was actually fast. | 00:46 |
| ccheney | yea | 00:47 |
| ccheney | persia: that seems to be what they are doing, before going to the new speeds they didn't over provision the speed by 2-3x like it appears is happening now | 00:47 |
| micahg | is there a reason why libiw30 doesn't replace libiw29? | 00:48 |
| ccheney | i just remembered something i saw a while back, is there a reason that checkmarks in human theme are white on menus? | 00:49 |
| ccheney | i thought they used to be black | 00:49 |
| slangasek | micahg: is there a reason it should? | 00:49 |
| persia | overprovisioning local link is best practice for ISPs as they typically underprovision uplink, and need to reschedule packets to maintain SLA. The only way I know to get out of such an arrangement is to provision a 1Gpbs local link, but that exposes you to uplink throttling directly. | 00:49 |
| micahg | slangasek: get rid of an old package | 00:49 |
| slangasek | micahg: that's not what Replaces does | 00:49 |
| ccheney | persia: yea | 00:49 |
| micahg | slangasek: doesn't it do the same thing? | 00:50 |
| micahg | slangasek: the package I mean | 00:50 |
| slangasek | micahg: that's irrelevant. That's not what the *Replaces field* means | 00:50 |
| * micahg goes to read the policy manual again | 00:50 | |
| slangasek | Replaces means "files previously belonging to that package have moved to this package" | 00:50 |
| micahg | slangasek: I see, so do we have a way to remove old packages? is that update-manager? | 00:51 |
| slangasek | micahg: update-manager; or 'apt-get autoremove'? | 00:52 |
| slangasek | ccheney: what in the world are these new OOo-l10n binaries for? | 00:52 |
| ccheney | persia: yea thats true, i also may be getting more bursty nature now since i don't have docsis 3.0 so can't use those channels | 00:52 |
| ccheney | slangasek: smooth upgrade from hardy/karmic to lucid | 00:52 |
| ccheney | slangasek: they mention that in the package desc | 00:53 |
| micahg | slangasek: I mean in an automated fashion, not by user input, I know how to remove it myself :) | 00:53 |
| persia | micahg: The right way to remove old libraries is to have them be marked as installed automatically, and be automatically uninstalled when nothing depends on them (which should be the case for an upgrade). This is implemented in apt, and used by update-manager as well as other things. | 00:54 |
| persia | For non-libraries it's a bit trickier, but that's not the situation in this case. | 00:55 |
| slangasek | micahg: well, packages don't upgrade themselves automatically either - you're either using update-manager, which gives you the option to remove packages it knows are obsolete; or if you're not using update-manager, 'apt-get autoremove' is the low-level interface | 00:55 |
| slangasek | ccheney: hrm, were those leaf packages in hardy? | 00:55 |
| slangasek | ccheney: if they should only have been pulled in as dependencies of, say, language-support-gu, then an upgrade should Just Work? | 00:56 |
| slangasek | ccheney: ah; we don't have language-support-translations-* anymore either, ok | 00:59 |
| ccheney | slangasek: they should only get used if the user already had eg openoffice.org-l10n-as-in installed to make sure they get openoffice.org-l10n-as now | 00:59 |
| slangasek | ccheney: yes, I understand that - the question was why we need transition packages for something that was normally auto-installed | 00:59 |
| ccheney | oh hmm, well would it automatically upgrade ok for a user who had the old version installed previously? | 01:00 |
| ccheney | i'm not sure how our lang support does that during an upgrade process | 01:00 |
| slangasek | no, because language-support-translations-* have gone away in lucid | 01:00 |
| ccheney | but does language-support somehow handle that for upgrades now instead? | 01:01 |
| ccheney | language-support the app i mean | 01:01 |
| ccheney | if not then i think we would need this transition packages, right? | 01:02 |
| slangasek | yes, I've accepted the transition packages | 01:02 |
| ccheney | ok | 01:02 |
| ccheney | also how does language-support app know which packages to install, is there something in there i need to have updated not to use the transition packages for new installs? | 01:02 |
| slangasek | I don't believe anything needs updated there; I'm sure language-support uses a whitelist | 01:03 |
| ccheney | ok | 01:03 |
| slangasek | and isn't going to randomly install packages with similar names | 01:03 |
| ccheney | well the whitelist might be out of date for those indic languages, but we should have gotten bugs about that by now i would think | 01:04 |
| persia | ccheney: Don't be confident about that: we typically have very poor translations for quite a while during development, and lots of users don't test in local languages. | 01:11 |
| ccheney | ok | 01:11 |
| ccheney | persia: do you know if the whitelist is in the language support app package itself, if so i can check it for accuracy | 01:12 |
| persia | I don't. Arne should be around in an hour or so, and would know. | 01:12 |
| ccheney | persia: ok | 01:13 |
| jdstrand | bluefoxicy: fyi, in an effort to detangle these screenlocking issues, mdeslaur created https://wiki.ubuntu.com/DebuggingScreenLocking. It might be worthwhile to look there and file a bug | 01:46 |
| bluefoxicy | haha | 01:50 |
| bluefoxicy | everybody knows this is broken,huh? | 01:50 |
| jdstrand | it is far too complicated... :( | 01:50 |
| jdstrand | the security team got scores of these bugs, so we (mostly mdeslaur) talked to people and tried to figure it all out | 01:51 |
| * ccheney got a new cable modem, i hope it helps :-\ | 02:49 | |
| TheMuso | ccheney: Connection problems? | 02:50 |
| ccheney | TheMuso: weird sinewave download speed pattern, got a docsis 3.0 modem to see if it hels | 02:51 |
| ccheney | er helps | 02:51 |
| TheMuso | Is the cable network you are on using DOCSIS 3? | 02:51 |
| ccheney | yes my old modem is 2.0 though | 02:52 |
| TheMuso | ah ok | 02:52 |
| ccheney | ok bbiab calling them to update my mac and replace the modem with the new one | 02:53 |
| raof | Man I hate trying to do anything slightly complicated with CDBS | 03:00 |
| TheMuso | raof: Heh | 03:02 |
| raof | Ok. What's the magic incantation for getting CDBS to call some stuff *after* dh_makeshilbs for one package and *before* calling dh_installdeb :/ | 03:06 |
| ajmitch | raof: because the source is the only decent documentation for it? | 03:06 |
| raof | ajmitch: And because the source is *labarynthine* and the control flow saunters through various underground tunnels. | 03:06 |
| ajmitch | there's the binary-fixup rule, not sure if that's useful | 03:07 |
| raof | Actually, I think I did this already for... launchpad-integration? | 03:08 |
| raof | Let me check. | 03:08 |
| ajmitch | raof: did you find the required incantations? | 03:24 |
| raof | Yeah. | 03:25 |
| raof | I'd done them before in my quest to make liblaunchpad-integration CLI-policy compliant. | 03:26 |
| raof | I'll need to do the same for indicator-application for Maverick; it's a bit of a mess. | 03:27 |
| un214 | grrr I just hit another nasty bug | 03:31 |
| un214 | basically nothing running under dpkg should ever assume that upstart or any other services are running | 03:32 |
| un214 | was running apt-get dist-upgrade in emergency mode | 03:32 |
| un214 | kbuntu-desktop depends on mysql-server ?!? | 03:44 |
| raof | Yes, of course kubuntu-desktop depends on mysql-server. Amarok needs a serious SQL server for your music library :P | 03:50 |
| imbrandon | raof: it does for mine :) ( 30k+ mp3's ) | 03:51 |
| * micahg thought amarok used an embedded mysql | 03:51 | |
| Dracari | has any work on PPC ATI Rage pro Drivers been made? i'd be willing to test a si have two Fruitie iMacs (G4 700MHZ and a G3 400MHZ) | 03:52 |
| imbrandon | it can , but its crap | 03:52 |
| raof | Does sqlite really not scale up to a mere 30k mp3s? | 03:53 |
| * raof sckeptates. | 03:54 | |
| imbrandon | raof: no it dosent, not well atleast | 03:54 |
| * raof lunches | 03:57 | |
| lamont | feeling lazy, I freely admit. if I have a root password, how the hell do I get all the gnome auth dialogs to use sudo instead of wanting the root password? | 05:41 |
| raof | That sounds quite poetic :) | 05:44 |
| === raof is now known as RAOF | ||
| RAOF | What's the process for pushing and upload through the freeze these days? Is it still https://wiki.ubuntu.com/FreezeExceptionProcess ? I'd like to get bug #564351 through. | 06:29 |
| ubottu | Launchpad bug 564351 in indicator-application "Fails to install library to GAC" [High,Confirmed] https://launchpad.net/bugs/564351 | 06:29 |
| mdke | RAOF: you can always check https://wiki.ubuntu.com/LucidReleaseSchedule for that sort of thing. It's currently https://wiki.ubuntu.com/FinalFreeze | 06:37 |
| RAOF | Right. So, first I need to convince someone that the library package being totally broken is RC and then...? It was the “and then” that I was after :) | 06:47 |
| mdke | RAOF: my understanding is that you need release team approval to the debdiff which you attach to the bug report | 06:52 |
| mdke | RAOF: as to the way to attract the release team's attention, I think it's either to upload directly (but I'm not 100% sure that is acceptable), to grab someone or irc or perhaps to subscribe them to the bug | 06:53 |
| RAOF | I don't have upload priviledges for indicator-application, so I can't just upload. ubuntu-archive are subscribed to the bug, though. | 06:54 |
| snow_ru | hi | 06:54 |
| mdke | RAOF: ok, although i think it's ~ubuntu-main-sponsors that needs to be subscribed | 06:57 |
| mdke | RAOF: also try and attract the attention of whoever tends to care for that package with upload privileges | 06:57 |
| === radoe_ is now known as radoe | ||
| pitti | Good morning | 07:35 |
| RAOF | “[ 5912.463012] This should not happen!! Data will be lost” is not a friendly dmesg | 07:36 |
| OdyX | Hi. I'm the Debian maintainer for usb-modeswitch{,-data} and just got a report on Launchpad for a version bump for Lucid (#564353). I guess it's too late already or is it worth to file a syncrequest | 07:42 |
| OdyX | (of course… usb-modeswitch and -data have to come together, both from Squeeze) | 07:43 |
| OdyX | oh… final-freeze… I guess that's a no then… | 07:53 |
| joaopinto | freeze = developers vacations :P | 08:14 |
| ttx | joaopinto: I wish. | 08:15 |
| dholbach | good morning | 08:19 |
| joaopinto | morning | 08:19 |
| hunger | Why are there more and more "Don't show this message again" buttons appearing in the notification? First there was one, then two, now I am up to 4 of them in the same notification. | 08:21 |
| joaopinto | hunger, are you refering to the crash reports ? | 08:23 |
| hunger | joaopinto: No, I see this when connecting/disconnecting from networks mostly. | 08:24 |
| joaopinto | ah, ok, no idea | 08:24 |
| hunger | joaopinto: But that are the only notifications I regularly see:-) | 08:24 |
| ScottK | OdyX: It's not necessarily too late. Depends on what it would bring. | 08:27 |
| === Amaranth_ is now known as Amaranth | ||
| joaopinto | I am trying to upgrade a server hardy->lucid | 09:00 |
| joaopinto | I am having problems to upgrade from jaunty | 09:01 |
| joaopinto | Error during update | 09:01 |
| joaopinto | A problem occurred during the update. This is usually some sort of | 09:01 |
| joaopinto | network problem, please check your network connection and retry. | 09:01 |
| joaopinto | what should I check ? | 09:01 |
| Tm_T | your network connection | 09:01 |
| Tm_T | or does that come all the time? | 09:01 |
| mvo | joaopinto: what does /var/log/dist-ugrade/main.log contain? | 09:01 |
| joaopinto | it comes all the time, it's a server , I am sure it's connected :P | 09:02 |
| joaopinto | mvo, there is no such dir | 09:02 |
| mvo | joaopinto: sorry, type "upgrade" instead of ugrade | 09:02 |
| joaopinto | 2010-04-16 08:59:52,657 WARNING updateStatus: dlFailed on 'http://localhost:3142//de.archive.ubuntu.com/ubuntu/dists/karmic-security/Release' | 09:03 |
| joaopinto | 2010-04-16 08:59:52,830 ERROR IOError/SystemError in cache.update(): 'The server may be overloaded'. Retrying (currentRetry: 2) | 09:03 |
| joaopinto | ok, that explains :) | 09:03 |
| joaopinto | tks | 09:03 |
| dholbach | ttx: do you think it makes sense to raise the importance of bug 552360 and fix it for lucid? | 09:03 |
| ubottu | Launchpad bug 552360 in squid "package squid 2.7.STABLE7-1ubuntu11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Low,Confirmed] https://launchpad.net/bugs/552360 | 09:03 |
| joaopinto | I was using an apt-cacher-ng proxy which must be failing after the upgrade | 09:03 |
| joaopinto | mvo, it would be nice to have a "Please check logfile blahblah" ;) | 09:04 |
| Tm_T | joaopinto: I agree | 09:04 |
| joaopinto | much more helpful than "The server may be overloaded " :P | 09:04 |
| ttx | dholbach: looking | 09:04 |
| * ttx struggles to send mails to the MLs, apparently something blocks them | 09:05 | |
| mvo | joaopinto: agreed, the message is not ideal | 09:06 |
| joaopinto | I am feeling confident, upgrading a server to lucid :) | 09:06 |
| ttx | dholbach: yes, dunno why I set it to Low. | 09:07 |
| * dholbach hugs ttx | 09:07 | |
| dholbach | fantastico | 09:07 |
| ttx | will look into that | 09:07 |
| ttx | targeting to Lucid + High | 09:08 |
| ttx | dholbach: am I the only one reporting trouble sending mails to the MLs ? I've been trying to send meeting minutes to ubuntu-devel and ubuntu-server since yesterday, without success or error messages | 09:09 |
| dholbach | weird | 09:10 |
| dholbach | no idea | 09:10 |
| ttx | sounds like I fall into a spamblocker /dev/null or something | 09:10 |
| ttx | I even tried resubscribing, fwiw | 09:11 |
| joaopinto | btw, I had an issue during development upgrades which can lead to failures on clean installs that can't be detected on upgrades | 09:17 |
| slangasek | ogra_cmpc: flash-kernel> why should the package depend on uboot-envtools? the udeb already apt-installs that package based on subarch, and the only place you've added fw_setenv calls is in the udeb | 09:17 |
| joaopinto | I have a working package which depends on another package which was removed from the repository during development | 09:18 |
| ScottK | joaopinto: Why was it removed? | 09:18 |
| joaopinto | ScottK, because it failed to build, it is fixed now, but the point is that I would never find out unless I did a clean install | 09:18 |
| joaopinto | I just noticed the problem because someone else with a clean install was not able to use the app | 09:19 |
| cjwatson | that's why we have automatic dependency analysis tools | 09:19 |
| joaopinto | I mean, to install | 09:19 |
| ScottK | There was a list published of the intended removals and warning was given. | 09:19 |
| cjwatson | although I don't think we have an equivalent of lucid_probs.html for universe | 09:19 |
| joaopinto | cjohnston, well, I got no warning that a package on my system was not re-installable due to a change on the repositories :P | 09:19 |
| cjwatson | "cjwatson" | 09:20 |
| cjwatson | no, you wouldn't | 09:20 |
| ScottK | I think apt-cache unmet -i would cover it. | 09:20 |
| cjwatson | ogra_cmpc: I agree with slangasek, there's no need for that dep | 09:20 |
| joaopinto | ScottK, I am referring to a proactive technical validation | 09:20 |
| cjwatson | unfortunately our efforts to run a full dependency-correctness analysis of the archive have failed in the past | 09:21 |
| ScottK | joaopinto: I think what you are inadvertently arguing is that we were inusufficiently aggressive with our removals. | 09:21 |
| cjwatson | simply took far too long | 09:21 |
| cjwatson | I thought the removals had been rdepends-analysed, though? | 09:21 |
| joaopinto | ScottK, no, I am just describing that I have was unable to detect a critical change during development, which has technical means to be validated | 09:22 |
| ScottK | I think we looked at reverse build-depends. | 09:22 |
| joaopinto | I am arguing that eventually it should be done automatically at some stage | 09:22 |
| cjwatson | normally it is | 09:22 |
| cjwatson | as in, normally removals are prefaced by the archive administrator who does the removals running checkrdepends | 09:23 |
| cjwatson | I think it's an anomaly that that wasn't done here | 09:23 |
| cjwatson | unless you're talking about a local package with the dependency, not one in the Ubuntu archive | 09:23 |
| * Dracari sighs | 09:23 | |
| Dracari | "why does it seem liek USB Support is broken for Dell laptops again?" | 09:23 |
| joaopinto | I am talking about an Ubuntu archive package, it was libuser1, which builds now | 09:23 |
| ScottK | cjwatson: I have run into cases before when we were following Debian removals where it appeared that wasn't done too. | 09:23 |
| ScottK | joaopinto: Yes and we should have (but apparently didn't) removed the packages that required it too. | 09:24 |
| joaopinto | right | 09:24 |
| joaopinto | uff, 9.10 done, one more upgrade to go | 09:27 |
| Tm_T | joaopinto: I upgraded directly from Intrepid to Lucid (: | 09:28 |
| Tm_T | was bit of a mess here and there | 09:28 |
| joaopinto | well, I expect some mess at the end, but custom config related, if the server boots I am happy :) | 09:29 |
| joaopinto | LTS2LTS is a long way :) | 09:29 |
| joaopinto | Error during commit | 09:30 |
| joaopinto | 'E:Internal Error, Could not perform immediate configuration (2) on | 09:30 |
| joaopinto | mountall' | 09:30 |
| joaopinto | Restoring original system state | 09:30 |
| joaopinto | ok, let me check the log this time :P | 09:30 |
| joaopinto | I hate cryptic errors :P | 09:30 |
| mvo | joaopinto: that is a know bug, I'm working on it. | 09:32 |
| slangasek | joaopinto: that's a known bug which kirkland and mvo are working ... yeah, what he said :) | 09:33 |
| mvo | bug 559582 | 09:33 |
| ubottu | Launchpad bug 559582 in mountall "Upgrade from karmic to lucid failes with Internal Error, Could not perform immediate configuration (2) on mountall" [Undecided,Confirmed] https://launchpad.net/bugs/559582 | 09:33 |
| joaopinto | ah ok :\ | 09:33 |
| lifeless | mvo: Cron <conflictchecker@macaroni> user=conflictchecker cd $HOME/findconflicts && PYTHONPATH=. bin/findconflicts > ../public_html/possible-conflicts.txt | 09:33 |
| lifeless | 09:33 | |
| lifeless | mvo: that blew up without warning - check your mail. | 09:33 |
| lifeless | mvo: any thoughts? | 09:33 |
| joaopinto | mvo, do you need more data ? | 09:34 |
| joaopinto | mountall is quite popular on bugs | 09:35 |
| vish | mvo: hi.. any news regarding this branch > https://code.launchpad.net/~mvo/synaptic/ubuntu-ui-changes has it been merged to main? | 09:35 |
| joaopinto | otherwise I will just continue with the workaround | 09:36 |
| mvo | lifeless: no and I'm deep in lucid tasks, maybe sbeattie can help? otherwise I can try to look at it later today (its not in my mail yet for some reason) | 09:36 |
| lifeless | mvo: probably filtered out | 09:37 |
| lifeless | you are listed in the to: clause | 09:37 |
| mvo | vish: hi, not merged to main yet, I was focusing on the lcuid branch | 09:37 |
| lifeless | mvo: perhaps you can poke sbeattie when he arises | 09:37 |
| mvo | lifeless: can do | 09:37 |
| vish | mvo: any chance of that landing for Lucid? | 09:38 |
| mvo | vish: no, because of the UI freeze | 09:38 |
| lifeless | mvo: thanks! | 09:38 |
| vish | mvo: ah ok.. thought you were getting a UIFe for that branch.. i guess it is too late now ;) | 09:38 |
| mvo | vish: yeah, sorry. early maverick it can land | 09:39 |
| vish | np.. | 09:39 |
| vish | thanks :) | 09:39 |
| mvo | np | 09:40 |
| joaopinto | mvo, is the workaround suggested on the bug safe, or do you suggest to wait for a fix ? | 09:40 |
| slangasek | ogra_cmpc: rejected the flash-kernel upload for the abovementioned issue; everything else looks ok, so please reupload once fixed | 09:41 |
| mvo | joaopinto: depends on your needs I guess, if you don't mind waiting another day I would wait for the fix | 09:41 |
| mvo | joaopinto: otherwise you can just do ahead | 09:41 |
| joaopinto | hum, vmware server without access to the console, I think I will wait | 09:45 |
| slangasek | mvo: is bug #522225 on your radar for final release? I don't know how hard it is to add that to u-m; if it's not likely to be fixed for final, we can just push it to SRU | 09:48 |
| ubottu | Launchpad bug 522225 in mysql-dfsg-5.1 "permissions incorrect on libmysqlclient16_7.0.9-1_amd64.deb" [High,Fix released] https://launchpad.net/bugs/522225 | 09:48 |
| snow_ru | hi | 09:49 |
| mvo | slangasek: its on my radar, but not with very high priority as it affects lucid->lucid only, right? this is a bit more tricky because on same-dist -> same-dist upgrades no quirks handlers are usually run | 09:52 |
| slangasek | mvo: correct - if you tell me it's too tricky even for SRU, then we should just wontfix it; we've already warned people on u-d-a and in the release notes, so if we aren't able to automatically solve this for users on upgrade, it's not critica | 09:54 |
| slangasek | l | 09:54 |
| mvo | slangasek: I haven't put that much thought into it, I don't think its too tricky | 09:55 |
| mvo | slangasek: its just not trivial as it would be on release -> next-release | 09:56 |
| * slangasek nods | 09:56 | |
| slangasek | chrisccoulson: have you been able to verify whether gtk_show_uri() works in isolation? | 10:03 |
| snow_ru | ls | 10:04 |
| chrisccoulson | slangasek - not yet, but it is used for launching help from a lot of other gnome apps already | 10:04 |
| chrisccoulson | it's blocking on a gconf call, which is weird :-/ | 10:04 |
| slangasek | chrisccoulson: oh, didn't realize that | 10:04 |
| chrisccoulson | there is a gvfs module which uses gconf to find the handler for the URI, and that's where it blocks | 10:05 |
| * slangasek nods | 10:05 | |
| chrisccoulson | i tried stepping through it in gdb, and confirmed that the orbit code is taking a recursive lock | 10:05 |
| chrisccoulson | but i don't know orbit enough to figure out why just yet | 10:06 |
| jibel | mvo, hey, can you review fix for bug 564320 ? 'mark for upgrade' in synaptic is currently broken. | 10:07 |
| ubottu | Launchpad bug 564320 in synaptic "'Mark for upgrade' does not work for upgradable packages" [High,Fix committed] https://launchpad.net/bugs/564320 | 10:07 |
| mvo | jibel: yes | 10:07 |
| jibel | mvo, thanks. | 10:07 |
| seb128 | slangasek, did people say if other distros not having the issue are building with gio too? | 10:08 |
| slangasek | seb128: I don't know | 10:08 |
| slangasek | I didn't see anything about that in the bug | 10:08 |
| slangasek | dpm: I need your input on bug #539676; I think there was some miscommunication about this, the string was *not* changed previously but is now sitting in the unapproved queue | 10:13 |
| ubottu | Launchpad bug 539676 in ubuntuone-client "[Freeze Exception] Add instructional text to Ubuntu One Preferences application" [Medium,In progress] https://launchpad.net/bugs/539676 | 10:13 |
| slangasek | dpm: I think the right thing to do here is to ask them to roll back that change and reupload; what do you think? | 10:13 |
| dpm | hi slangasek, sorry for the delay. I agree. It is quite late and the translations imports queue is really slow at the moment. I'm not sure whether there'd be time to import the new template. | 10:14 |
| slangasek | dpm: ok - I'll review for other issues, reject and ask for the revert, thanks | 10:15 |
| dpm | thanks | 10:17 |
| OdyX | bug 564353 | 10:17 |
| ubottu | Launchpad bug 564353 in usb-modeswitch "usb_modeswitch crashes with Sony adapters" [Undecided,Fix committed] https://launchpad.net/bugs/564353 | 10:17 |
| OdyX | ^any external opinion on this ? | 10:17 |
| OdyX | it works in squeeze and has no bugs so far… so the sync doesn't seem risky to me. But just IMHO | 10:18 |
| ogra | geez | 10:20 |
| ogra | so my laptop just OOM'ed .... with 4G of RAM ! | 10:21 |
| tjaalton | ScottK: I've prepared sssd-1.0.5 which fixes all three bugs filed against it, one being rather serious. note that this is the last release from 1.0.x bugfix series, and not the more featureful 1.1.x ;) | 10:21 |
| ScottK | tjaalton: And 1.0.2 to 1.0.5 is all bug fixes? | 10:22 |
| tjaalton | ScottK: yes, let me grab the changelog.. | 10:22 |
| ScottK | tjaalton: It's fine then, just upload it and it'll get reviewed. | 10:22 |
| tjaalton | ScottK: ok, thanks (there was no changelog..) | 10:22 |
| ogra | mdz, did you track doen the evolituon issue you had yesterday ? i suspect i was just hit by it | 10:23 |
| ogra | *down | 10:23 |
| ogra | sigh and apport doesnt want to report because i didnt upgrade since yesterday | 10:24 |
| * ogra upgrades | 10:24 | |
| ttx | ogra: I see little progress on the RC-level bug 532733 -- could you help providing some of the information Dustin requested ? | 10:25 |
| ubottu | Launchpad bug 532733 in qemu-kvm "apt/dpkg in qemu-system-arm hangs if a big task is installed" [High,Incomplete] https://launchpad.net/bugs/532733 | 10:25 |
| slangasek | ogra: hi, did you happen to see my comments about flash-kernel (directed at ogra_cmpc)? | 10:25 |
| ogra | ttx, i uploaded rootstock with the -disk change but the archive was out of sync until today so there was no way to verify yet | 10:25 |
| ttx | ogra: ok, keep us posted :) | 10:25 |
| ogra | slangasek, nope | 10:25 |
| ogra | ttx, i had a build running when my machine crashed | 10:26 |
| mdz | ogra, yes, I mentioned the relevant bug reports in the channel | 10:26 |
| mdz | ogra, well, "track down" as in cross-reference and report. I didn't isolate the root cause, but think I found a workaround | 10:26 |
| * ogra goes to the other laptop to look for slangasek's comments | 10:27 | |
| slangasek | ogra: I don't see any reason for flash-kernel to depend on uboot-envtools, the only call you added to fw_setenv was in the udeb - and cjwatson confirms; I've rejected that upload, please reupload without the dep or explain why it's needed | 10:27 |
| ogra | slangasek, well, i didnt want to explicitly seed it, there is no other straight dep to get it into the image | 10:28 |
| ogra | but indeed i can just seed and drop the dependency | 10:29 |
| persia | ogra: Why not seed it? It only belongs on the image: running systems don't need it. | 10:29 |
| ogra | persia, well, its for changing the uboot config from a running system | 10:29 |
| slangasek | persia: running systems don't need it> well, they get it /anyway/ because this uses apt-install | 10:29 |
| ogra | you surely want it on installed systems | 10:29 |
| slangasek | ogra: but the difference is that making it a dep puts it on *all* systems, regardless of subarch | 10:29 |
| cjwatson | seeding it is appropriate | 10:30 |
| ogra | right, the only reason for seeding it was to have it in the image | 10:30 |
| slangasek | so seeding it is the right answer | 10:30 |
| cjwatson | it belongs in the d-i-requirements seed | 10:30 |
| ogra | right, no prob ... was out of lazyness to fiddle with seeds and metapackages | 10:30 |
| cjwatson | just like uboot-mkimage | 10:30 |
| cjwatson | there is no reason to treat this package differently from uboot-mkimage | 10:30 |
| * ogra fixes | 10:30 | |
| ogra | well, i oriented myself on redboot-tools | 10:31 |
| slangasek | it's not a metapackage issue | 10:31 |
| ogra | that should be changed accordingly | 10:31 |
| doko__ | Riddell: could you check #555868 on kubuntu? | 10:31 |
| persia | slangasek: Only a small subset of systems in one subarch. | 10:31 |
| ogra | lool made that a dep of flash-kernel back when we enabled imx51 ... i'll bump it down to a suggests too | 10:31 |
| slangasek | persia: having it as a dep of flash-kernel, which is what's being disputed, means it'll be installed anywhere flash-kernel is; and flash-kernel certainly appears to be used on more than one subarch | 10:33 |
| persia | slangasek: RIght. I'm agreeing that it shouldn't be a dep :) | 10:33 |
| slangasek | ogra: no, please don't change redboot-tools at this stage - it's almost certainly wrong, but I don't want the possibility of extra churn trying to get it right | 10:34 |
| ogra | ok | 10:34 |
| lool | slangasek, ogra: Right, I don't remember why I added the dep since I remember I went through the extra effort of ensuring it got installed on end systems via d-i | 10:34 |
| slangasek | ogra: seeding redboot-tools in d-i-requirements is ok - but don't drop the dep | 10:34 |
| ogra | will do | 10:34 |
| lool | I mean via anna-install | 10:34 |
| lool | and apt-install | 10:34 |
| lool | slangasek: agreed, let's defer fixing this to maverick | 10:35 |
| doko__ | chrisccoulson: does the private nss3/nspr4 copy stay in firefox for lucid? | 10:38 |
| chrisccoulson | doko__, it does, i'm afraid. is that still an issue for you? you had a workaround didn't you? | 10:39 |
| doko__ | chrisccoulson: the workaround is in place. just curious, why it has to stay? | 10:40 |
| ogra | slangasek, uploaded newly and d-i-requirements changed and pushed | 10:41 |
| chrisccoulson | doko__, we've deliberately minimised the dependencies of firefox as per https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model | 10:41 |
| ogra | (i guess that needs a published run or something to pick up the seed change) | 10:41 |
| ogra | *publisher | 10:42 |
| persia | 2 of them | 10:42 |
| ogra | yeah, i guess there is enough in the queues to make that automatic :) | 10:42 |
| james_w | bdrung: how's the audacious transition going? | 10:44 |
| slangasek | ogra: it's a seed change, not a task change | 10:44 |
| slangasek | all it needs is a new ISO build | 10:45 |
| ogra | great | 10:45 |
| persia | slangasek: Aren't the ISOs built off the tasks based on the seeds? | 10:45 |
| ogra | not everything | 10:45 |
| persia | Or is this special because it's not actually installed in the livefs? | 10:46 |
| bdrung | james_w: one of five packages are done. remaining: bug #564087, #564088, #564091, #564092 | 10:46 |
| ubottu | Launchpad bug 564087 in g15daemon-audacious "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564087 | 10:46 |
| ubottu | Launchpad bug 564088 in imms "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564088 | 10:46 |
| ubottu | Launchpad bug 564091 in upse "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564091 | 10:46 |
| ubottu | Launchpad bug 564092 in xmp "FTBFS against audacious 2.3" [Undecided,New] https://launchpad.net/bugs/564092 | 10:46 |
| slangasek | persia: liveCDs are built from tasks; the archives that sit on the iso9660 fs are built from seeds | 10:46 |
| slangasek | ogra: accepted | 10:46 |
| ogra | \o/ | 10:46 |
| persia | That makes sense. OK. | 10:46 |
| ogra | we have omap ! | 10:46 |
| james_w | do we have rmadison for ports? | 10:47 |
| cjwatson | persia: or, putting it a different way, not all seeds generate tasks | 10:47 |
| persia | james_w: Unfortunately not. | 10:47 |
| james_w | damn | 10:47 |
| james_w | can lp tell us about binary publishing status? | 10:47 |
| cjwatson | james_w: this obviously doesn't help everyone, but you're an archive admin, you can run madison-lite on cocoplum | 10:48 |
| james_w | ah! | 10:48 |
| james_w | of course | 10:48 |
| james_w | thanks | 10:48 |
| ogra | persia, on the livefs there is also Recommends: .... uboot-envtools [armel] .... in ubiquity which makes livecd-rootfs pull it into the images | 10:49 |
| james_w | doko__: is it worth keeping the packages from http://people.canonical.com/~ubuntu-archive/NBS/zope2.11 around? they seem to be zope2 only | 10:49 |
| slangasek | ogra: that also looks wrong to me... surely it should be seeded in the same place as the kernel, so that it's only pulled into the omap livefs instead of into the livefs for all subarchs? | 10:50 |
| ogra | slangasek, thsta what we do on all subarches ... i only followed cjwatson's suggestion here | 10:51 |
| ogra | *thats | 10:51 |
| slangasek | alrighty | 10:51 |
| ogra | uboot-mkimage as well as redboot-tools are in that line too | 10:51 |
| ogra | what we really miss though is support for [$arch+$subarch] | 10:52 |
| ogra | in the deps | 10:52 |
| ogra | lool, might it make sense to have a BOF for that at UDS ^^^ ? | 10:52 |
| persia | Ooh. madison-lite is nifty (even if it does have an implicit dependency on a heap of disk space) | 10:53 |
| doko__ | james_w: no, zope2.12 isn't ready either, one of the zope-pkg maintainers did leave the team to have more time for general python ranting | 10:54 |
| james_w | heh | 10:54 |
| james_w | doko__: zope-common too? | 10:55 |
| doko__ | james_w: still in testing; it doesn't hurt | 10:56 |
| lool | cjwatson: Do you think you could update debootstrap for maverick upstream and copy it to lucid? That would be excellent | 10:56 |
| james_w | doko__: ok, I'll just remove the ones that depend on zope2.11 then? | 10:56 |
| slangasek | persia: just needs Packages/Sources - a mere 180MB :) | 10:56 |
| doko__ | james_w: yes | 10:56 |
| james_w | ok, doing, thanks | 10:57 |
| lool | slangasek: Note that ogra mentions the ship and ship-live seeds here | 10:57 |
| lool | slangasek: not e.g. the desktop seed | 10:57 |
| lool | I think it's right to have the livefs relatively generic with some packages which can be installed when installing the target system (via anna-install IIUC) | 10:58 |
| slangasek | lool: hrm? he was talking about ubiquity recommends | 10:58 |
| lool | slangasek: He mentionned seeds though | 10:58 |
| ogra | i meantioned seeds (wrt d-i-reqs) and recommends for ubiquity | 10:58 |
| lool | Right I see it's in the recommends as well, not sure why | 10:58 |
| lool | Again something we'd better not touch, but which is probably not needed | 10:59 |
| lool | Ah apparently this relates to network access | 10:59 |
| ogra | Recommends: grub-pc [any-amd64 any-i386 any-lpia] | grub [any-amd64 any-i386 any-lpia], flash-kernel [armel], uboot-mkimage [armel], uboot-envtools [armel], redboot-tools [armel], yaboot [powerpc], hfsutils [powerpc], silo [sparc], dmraid | 10:59 |
| ogra | thats what ubiquity has | 10:59 |
| lool | http://paste.ubuntu.com/415455/ | 10:59 |
| cjwatson | lool: I already updated it upstream in svn | 11:00 |
| lool | cjwatson: You think we should just change it in Ubuntu right now with a new symlink and better not wait for a Debian upload + sync? | 11:00 |
| cjwatson | I can probably upload that to Debian | 11:00 |
| cjwatson | slangasek: debootstrap upload OK? ^- | 11:00 |
| cjwatson | er, sync that is | 11:00 |
| slangasek | cjwatson: yes, go ahead | 11:01 |
| cjwatson | hmm, lucid only has .20, and the changes since are extensve | 11:01 |
| cjwatson | +i | 11:01 |
| slangasek | oh | 11:01 |
| cjwatson | so I think I'll just change it directly in lucid | 11:01 |
| slangasek | ok | 11:01 |
| lool | cjwatson: thanks | 11:01 |
| lool | bug #537007 | 11:01 |
| ubottu | Launchpad bug 537007 in ubiquity "flash-kernel fails hard when network access fails" [High,Fix released] https://launchpad.net/bugs/537007 | 11:01 |
| ogra | lool, so do you think discussion dpkg support for [$arch+$subarch] would make sense at UDS ? | 11:01 |
| lool | ogra: I don't think dpkg should support that | 11:02 |
| cjwatson | I doubt there would be any point unless there are dpkg hackers present, anyway | 11:02 |
| lool | but perhaps I'm wrong | 11:02 |
| ogra | i think that would make our life a lot easier wrt ARM | 11:02 |
| cjwatson | I tend to agree with lool on this | 11:02 |
| slangasek | dpkg doesn't even support [$arch] the way you mean | 11:02 |
| cjwatson | but that's kind of beside the point - we don't have anyone who could reasonably be assigned to implement that right now, even if the consensus were that it is a good idea | 11:02 |
| lool | Ack | 11:03 |
| ogra | well, we often end up with a lot of unneeded packages due to missing finer grained subarch support in the packaging system | 11:03 |
| cjwatson | there's no point having UDS discussions for things that are infeasible to implement | 11:03 |
| lool | ogra: We have xserver-xorg-video-* on all intel systems | 11:03 |
| cjwatson | instead, I suggest you take it up with debian-dpkg@ | 11:03 |
| slangasek | I think you end up with unneeded packages because of not using the seeds the way they should be | 11:03 |
| slangasek | (seeds and kernel package recommends) | 11:04 |
| ogra | (ther live images conatin all armel linux-headers packages for example) (which is a bug i plan to fix in livecd-rootfs, but a finer dependency system would solve that better imho) | 11:04 |
| lool | Right, we should have a beagle or omap seed instead of pushing down to the desktop / netbook seeds | 11:04 |
| lool | I think I discussed a beagleboard task with someone recently, but I don't remember who it was | 11:04 |
| lool | I wondered whether we can build the list of tasks dynamically | 11:05 |
| ogra | so more fine grained seeds instead of finer grained dependency system ? | 11:05 |
| ogra | i think we shuld have both | 11:05 |
| persia | Why not just add subarch support to the various tools that use seeds? Splitting seeds on a per-arch or per-subarch basis sounds like a recipe for merge pain. | 11:07 |
| cjwatson | adding subarch support to germinate is kind of useless unless apt understands subarches, which is why I have never done so | 11:08 |
| ogra | right | 11:08 |
| mvo | jibel: uploaded, many thanks | 11:08 |
| cjwatson | or at least only useful in very constrained circumstances | 11:08 |
| ogra | the package system needs to understand it at some level | 11:08 |
| cjwatson | honestly, the number of packages involved is sufficiently small that I don't think it's worth massive extensions to the package manager | 11:09 |
| ogra | if it would be a massive extension i agree ... | 11:09 |
| lool | Frankly, our definition of subarches would only cover a subset of the use cases | 11:09 |
| ogra | i dont know whats involved to make it work ... i only see the user side and where we suffer | 11:09 |
| cjwatson | it would be pretty substantial, yes | 11:09 |
| lool | That is, you might be able to express a couple of dependencies usefully for a SoC, but you'll face the same issue again when trying to address packages for different boards for instance | 11:10 |
| cjwatson | syntactic changes to run-time dep expansion, teaching dpkg and apt to understand subarches at all, potentially changing every tool that parses Packages | 11:10 |
| ogra | and i fear that if we support ten or more armel subarches it can get painful | 11:10 |
| lool | We're talking about ridiculously small packages anyway | 11:11 |
| ogra | linux-headers isnt so small | 11:11 |
| ogra | but yes, the rest is | 11:11 |
| lool | ogra: Perhaps the kernel packaging can be improved to share more headers then? | 11:12 |
| lool | Across subarches, and even across upstream versions, the difference is probably very small | 11:12 |
| ogra | there are other areas we need to touch ... i.e. livecd-rootfs | 11:13 |
| bdrung | james_w: help for fixing these bug would be appreciated | 11:13 |
| lool | ogra: We're not reusing livefses, so we could apt-get install ubuntu-netbook^ beagle-board-support^ or omap3-specific^ | 11:13 |
| slangasek | lool: the linux-headers packages exist specifically to enable building modules against that kernel; you can't know a priori which headers are shareable across subarchs / upstream versions | 11:13 |
| ogra | lool, we will go on using it in ubuntu | 11:14 |
| ogra | slangasek, well, the kernel team tried to solve that by adding different subarch names to the package naming (and introducing several different ABI numbering systems) ... which apparently didnt work out | 11:15 |
| slangasek | ogra: which was designed to do the *opposite* of what lool suggested | 11:15 |
| slangasek | i.e., it was designed to ensure no header files were shared between any subarchs | 11:16 |
| ScottK | ogra: re your rootstock upload: How is "merge patch from Robert Nelson <robertcnelson@gmail.com> to generate initramfs from external kernel debs" not a new feature? | 11:16 |
| lool | slangasek: Yeah, trying to think how it would work I can only think of hackish way to share the headers | 11:16 |
| ogra | slangasek, designed to vs working reality :) | 11:16 |
| lool | Are these actually installed by default? | 11:16 |
| slangasek | lool: step 1) get all subarchs using the same kernel version | 11:16 |
| lool | We could also keep them compressed most of the time given we're using them for a heavy build anyway | 11:16 |
| slangasek | s/version/tree/ | 11:16 |
| amitk | lool: every arm kernel is on a different version, how are you going to share headers? | 11:17 |
| lool | slangasek: That's crazy, who would want to use the same kernel tree to support multiple SoCs or architectures!! Debian?? ;-) | 11:17 |
| ogra | ScottK, i just dont have a bug report for that, robert uses rootstock to build rootfses for arches we dont have kernels for, it was always considered a bug that he doesnt use initramfses, that patch fixes it ... we are discussing it via IRC though, not through bugs | 11:17 |
| slangasek | amitk: see step 1 :) | 11:17 |
| lool | lol | 11:17 |
| ogra | hehe | 11:18 |
| amitk | slangasek: see you after 2 years | 11:18 |
| slangasek | ack | 11:18 |
| lool | So just thinking "sky is the limit", if we were to upload a single kernel source package with a base tree + extra tarballs / patches for all subarches, we could have this single package build output a consistent set of headers | 11:19 |
| ogra | ScottK, do you want a FFe bug for it to have proper paperwork (i dont want to drop it it took me long enough to convince him to do it that way) | 11:19 |
| slangasek | ogra: looks like bug #562888 was meant to be closed in the flash-kernel upload? | 11:19 |
| ubottu | Launchpad bug 562888 in ubiquity "omap installation failed with unrecoverable error" [Medium,Invalid] https://launchpad.net/bugs/562888 | 11:19 |
| lool | That is, we could have a source package creation step from a single git repo with multiple branches which outputs a single source package | 11:19 |
| ogra | slangasek, no, i duped it to the ubiquity bug | 11:19 |
| ogra | slangasek, next ubiquity upload will close it | 11:20 |
| slangasek | ogra: no it won't, the open task is on flash-kernel | 11:20 |
| lool | That would be unpractical to work with in terms of debdiff and apt-get source, but it would be able to ship binary headers package sharing headers safely | 11:20 |
| ogra | slangasek, ugh ... i would have expected duplicating closes all tasks ... i'll go and close it | 11:20 |
| amitk | lool: single source tree? How? we have 2.6.31, 32 and 33 version right now for fsl, mvl and ti respectively | 11:22 |
| ogra | oh, i was thinking of a different bug :P | 11:22 |
| lool | amitk: Single source package | 11:23 |
| ScottK | ogra: Since the queue is frozen at this point, it probably doesn't matter much. | 11:23 |
| lool | amitk: Well we could tar up .31, the .31 -> .32 diff, the .31 -> .33 diff etc. | 11:23 |
| ogra | ScottK, ok | 11:23 |
| lool | amitk: I dont think this would be practical to work with, but it would be technically feasible; perhaps we can research a saner approach which allows sharing headers | 11:23 |
| * ScottK will probably leave it to someone more familiar to review though. | 11:24 | |
| amitk | lool: so you get 'base' headers that don't change across kernel versions. What about the headers that do change? | 11:25 |
| lool | amitk: I don't understand | 11:26 |
| persia | lool: Consider the case where you have *different* kernel headers for different patches being applied for different flavours. | 11:27 |
| lool | amitk: I guess there are multiple options to shipping, depending on the complexity we can tolerate and the gains we're looking for | 11:27 |
| amitk | lool: how many header packages would you generate? 3? or 1? | 11:28 |
| lool | persia: Yes, so you could have symlink farms for most files and overrides for the modified headers, or you could patch a copy of the installed headers | 11:28 |
| lool | amitk: Doesn't really matter | 11:28 |
| lool | probably one per subarch | 11:29 |
| persia | lool: We already have issues with per-flavour kernel headers differing, which makes dkms messy. I'm not sure extending that is best. | 11:29 |
| lool | I find the first idea I throwed bad enough that it should be getting the critics! | 11:29 |
| james_w | ok, looks like just sugar and audacious left for NBS | 11:29 |
| lool | persia: I agree it's a risk/gain tradeoff, yes; trying to come up with a way to avoid losing space | 11:30 |
| === MacSlow is now known as MacSlow|lunch | ||
| ScottK | lool: It looks like in your u-d-t upload there are changes in get-branches done by soren, but not in debian/changelog. Would you mind having a look at documenting them. | 11:49 |
| slangasek | mvo: is your WI for foundations-lucid-non-applications-in-software-center still in progress? | 11:50 |
| slangasek | mvo: ("test that on a fresh install, a-x-i db and apt lists are created/updated") | 11:51 |
| mvo | slangasek: it is, late but sitll on my list | 11:53 |
| ogra | amitk, you also forgot the buglink in the omap upload for Bug 561424 (slangasek just moved it to updates) | 11:53 |
| ubottu | Launchpad bug 561424 in linux-ti-omap "console switching does not work with ti-omap " [High,Triaged] https://launchpad.net/bugs/561424 | 11:53 |
| slangasek | mvo: ok - I'll move the milestone, so it stays on the radar | 11:53 |
| mvo | thanks | 11:54 |
| lool | ScottK: Sure, how shall we proceed, do you want a reupload? | 11:55 |
| lool | ScottK: Or I could upload a new version fixing the changelog | 11:55 |
| ScottK | lool: Please fix and upload. There was one post-upload commit to the branch you may want to consider. | 11:56 |
| lool | ScottK: Updated 0.98 pushed | 11:59 |
| ScottK | Lookng | 12:00 |
| ScottK | ..i.. | 12:00 |
| doko__ | james_w: while you are at removals, can you remove gnat-4.3? doesn't build using the gnat pointing to gnat-4.4 | 12:01 |
| ScottK | lool: Accepted. Thanks. | 12:02 |
| james_w | doko__: done | 12:12 |
| Riddell | ev: did you get anywhere with kubuntu oem? | 12:14 |
| cjwatson | slangasek: I recently changed grub2 to single-quote menuentry titles, as part of fixing bug 552921 | 12:14 |
| ubottu | Launchpad bug 552921 in grub2 "An apostrophe translation in the line "echo Loading Linux 2.6..." of Grub breaks the boot menu from this entry included in Grub (in Ubuntu 10.04)" [Undecided,Fix released] https://launchpad.net/bugs/552921 | 12:14 |
| ev | Riddell: indeed, I fixed it | 12:14 |
| cjwatson | slangasek: I've just noticed that os-prober fails to handle this, and I've committed a fix upstream - would it be OK to sync that into lucid? | 12:15 |
| ev | it called into question my understanding of python's scoping and garbage collection rules though | 12:15 |
| ev | Riddell: r4081 | 12:15 |
| Riddell | ev: you're my hero | 12:17 |
| ev | :) | 12:17 |
| slangasek | cjwatson: yes, go ahead | 12:17 |
| ev | Riddell: we still seem to have issues with the advanced partitioning page in Kubuntu. I've asked Roman to look at that, as it appears to be specific to the KDE frontend. | 12:17 |
| Riddell | ev: what sort of issues? | 12:18 |
| ev | Riddell: bug 563309 | 12:18 |
| ubottu | Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [Undecided,Incomplete] https://launchpad.net/bugs/563309 | 12:18 |
| ev | and the interface in the KDE frontend is still slow, but not nearly as bad as before | 12:22 |
| Riddell | cjwatson: gfxsplash colours should probably be changed, selection background to match the blue background and black text I think | 12:24 |
| Riddell | cjwatson: should I look into that or is it easier if you just do it? | 12:24 |
| cjwatson | Riddell: if you could give me hex colour codes that should be used, I can take care of applying them | 12:25 |
| cjwatson | some of the syntax is a bit nonintuitive | 12:25 |
| Riddell | cjwatson: background 00507f and text 000000 | 12:26 |
| === _silentAssassin is now known as _silentAssassin| | ||
| === _silentAssassin| is now known as _silentAssassin | ||
| cjwatson | Riddell: hmm, doesn't seem to be a perfect match | 12:31 |
| Riddell | cjwatson: how about 005082 | 12:33 |
| cjwatson | Riddell: http://people.canonical.com/~cjwatson/tmp/kubuntu-boot-screen-2.png - slight visible bar across the "Install Kubuntu" line | 12:33 |
| cjwatson | the white/black thing OK there? | 12:33 |
| cjwatson | ah yes, that's better thank | 12:34 |
| cjwatson | s | 12:34 |
| slangasek | doko__: when do you plan to upload eglibc for these milestoned fixes, and are there any others pending besides the three I see on https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.milestone=21439 ? | 12:36 |
| doko__ | slangasek: I hope soonish/today, but I get different feedback on the networking bug | 12:37 |
| doko__ | currently talking with pitti | 12:37 |
| slangasek | ok, cool | 12:37 |
| cjwatson | Riddell: applied | 12:38 |
| doko__ | slangasek: but the networking stuff really isn't my core knowledge ... | 12:38 |
| squirrelpimp | i just tried installing lucid with full disk encryption using lvm inside luks on sda2. However the boot drops out at "root device /dev... does not exist. dropping to a shell". Is there some new specialty about the boot process in lucid? i found the page where all configurations should have been testet for plymouth, but it looks quit unfinished. | 12:50 |
| squirrelpimp | is there any page describing the interaction between cryptsetup and plymouth, so i can pick some thread up to fix my boot? | 12:51 |
| cjwatson | I thought that mode was tested and passed in beta-2 | 12:51 |
| cjwatson | does this happen every time? | 12:51 |
| squirrelpimp | yes... i tried thrice without success. The system was installed using the live cd, while manually setting up the crypted disk and lvm. This has worked on previous versions before. | 12:53 |
| squirrelpimp | right now i boot into the livecd again to double check the initramfs steps | 12:54 |
| cjwatson | oh, well, full-disk-encryption installs using the live CD are unsupported, so successes are essentially down to luck | 12:56 |
| cjwatson | why not use the alternate CD, where this mode is actually supported? | 12:56 |
| squirrelpimp | i always used this mode as it gave me the feeling of full control over the result. however usually it also worked | 12:58 |
| squirrelpimp | :) | 12:58 |
| squirrelpimp | sometimes i wish myself back to the old days when all was init.d scripts | 13:01 |
| squirrelpimp | well, now i get another symptom (after recreating initramfs): | 13:01 |
| squirrelpimp | plymouth halts with "cryptsetup: lvm device name (/dev/disk/by-uuid/"ad9f...7d7") does not begin with /dev/mapper | 13:02 |
| james_w | bdrung: two done, there's a partial patch for xmp http://xmp.git.sourceforge.net/git/gitweb.cgi?p=xmp/xmp;a=history;f=src/plugin/audacious.c;h=9a3b7cb2725c65cc2ad40fb04d5f08eed1f004d7;hb=HEAD but it's not complete | 13:03 |
| cjwatson | init.d scripts aren't relevant to mounting the root filesystem anyway, and never were | 13:04 |
| squirrelpimp | weren't they? ok then... | 13:04 |
| squirrelpimp | is the alternate installer capable of reusing an already existing lvm inside luks? | 13:07 |
| squirrelpimp | as my /home is in there and i'd like to keep it (though i have a backup of course) | 13:07 |
| cjwatson | I don't remember for sure, I'm afraid | 13:09 |
| persia | It is, but you have to drop to a shell to unlock it before running partman. | 13:10 |
| persia | (or it was for jaunty: I haven't tested that use case since then) | 13:10 |
| squirrelpimp | is there a way around the "does not start with /dev/mapper" issue... as this would render me with a usable system much quicker | 13:12 |
| squirrelpimp | and i'd learn something about plymouth | 13:12 |
| squirrelpimp | :) | 13:12 |
| persia | squirrelpimp: Which architecture? | 13:12 |
| squirrelpimp | x86_64 | 13:12 |
| persia | Hrm. Dunno. Works for me on that arch with LVM-inside-luks | 13:13 |
| squirrelpimp | can you give the entry from your crypttab? | 13:14 |
| persia | data /dev/disk/by-uuid/78a09fa1-31e2-4ef2-bcc6-93bef9f2efc5 none luks | 13:15 |
| squirrelpimp | mine s | 13:16 |
| squirrelpimp | sry... lvm UUID="ad9f4b...c7d7" none luks | 13:16 |
| squirrelpimp | i'll try to make it more similar to yours | 13:16 |
| squirrelpimp | maybe it doesn't like the UUID="..." syntax with the " around | 13:18 |
| squirrelpimp | next try | 13:18 |
| === Tonio__ is now known as Tonio_ | ||
| squirrelpimp | great... it works now | 13:19 |
| === Dracari is now known as Dracari|sleepin | ||
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | "seb128@ubuntu.com has 299 fixes" | 13:32 |
| pitti | go, seb128, go! | 13:32 |
| pitti | kirkland: oh, we are on par again *hug* | 13:32 |
| cjwatson | gar, plymouthd really doesn't like being straced | 13:36 |
| tseliot | pitti: where do you see that kind of information? | 13:37 |
| * sladen hits the mountall fsck fail business | 13:38 | |
| tseliot | cjwatson: either halfline or brejc8 might have some ideas in #plymouth (if you need help) | 13:39 |
| Riddell | ev: I take it you managed a complete OEM install on kubuntu after your fix? so we can confirm that bug 540922 is gone? | 13:40 |
| ubottu | Launchpad bug 540922 in ubiquity "apt error when running oem-config-kde" [Undecided,New] https://launchpad.net/bugs/540922 | 13:40 |
| ev | Riddell: that's a duplicate of bug 539710. I've marked it as such. | 13:41 |
| ubottu | Launchpad bug 539710 in ubiquity "OEM Lucid installation - configuring system for a new user - error occurring installing new packages" [High,Fix released] https://launchpad.net/bugs/539710 | 13:41 |
| ev | but yes, I did complete a full run of oem-config in kde | 13:41 |
| seb128 | tseliot, number of bug fixed you mean as information? | 13:43 |
| seb128 | tseliot, http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html | 13:43 |
| seb128 | pitti, http://qa.ubuntu.com/reports/bug-fixing/canonical-desktop-team-lucid-fixes-report.html has slightly different counts | 13:43 |
| Riddell | ev: I can't recreate bug 563309, at least not on a virtual machine, will try on real hardware in a bit | 13:45 |
| ubottu | Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [Undecided,Incomplete] https://launchpad.net/bugs/563309 | 13:45 |
| === fbond_ is now known as fbond | ||
| ev | Riddell: okay, thanks | 13:45 |
| tseliot | seb128: ah, thanks a lot | 13:46 |
| pitti | seb128: right, that seems slightly more recent | 13:55 |
| pitti | seb128: congrats for breaking the 300 mark! | 13:55 |
| seb128 | pitti, thanks ;-) | 13:55 |
| ogra | seb128, wrt our fsck discussion last night: https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/563618/comments/14 | 14:04 |
| ubottu | Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] | 14:04 |
| ogra | :) | 14:04 |
| squirrelpimp | fglrx broke kms, as it doesn't support it of course. is there an easy way to disable the graphical part and return to text mode? | 14:14 |
| squirrelpimp | right now i get the plymouth boot screen, but in huge dimensions almost not fitting on the monitor and with large pixels | 14:15 |
| dmart | ogra, do you think it would make sense to turn off all the system time releated checks and fixes if broken_system_clock = true ? The more I think about this, the more sense it seems to make | 14:16 |
| cjwatson | add the 'nomodeset' kernel parameter, assuming that you have xserver-xorg-video-radeon either at the very latest version or else not installed at all | 14:17 |
| ogra | dmart, well, currently broken_system_clock auto-fixes the timestamp which results in a reboot ... after which the timestamp is wrong again ... but yes, enhancing it might make sense, but probably by introducing another parameter | 14:18 |
| squirrelpimp | i have it installed at the latest version and before installing fglrx, plymouth looked very nice. i already tried adding nomodeset without success | 14:19 |
| squirrelpimp | still the boot screen and password prompt looks to big and broken | 14:19 |
| dmart | ogra: The way I look at it, broken_system_clock informs e2fsck that the system time is random rubbish with respect to the last boot. So there is nothing sensible to set the clock _to_ | 14:19 |
| ogra | yeah | 14:19 |
| dmart | All e2fsck can do is set the fs mount time to, er, rubbish | 14:19 |
| ogra | which it does atm | 14:20 |
| thebishop | hello! | 14:20 |
| dmart | Better to treat the fs as clean if this is the only error, and not change anything imho | 14:20 |
| thebishop | is the Power Management config app an Ubuntu project, or Gnome? | 14:20 |
| ogra | right, though i'm not sure how the journal will end up in this case | 14:20 |
| ogra | it might get confused which in turn will give you an inconsistent fs | 14:21 |
| ogra | because once your network is up your clock is set again | 14:21 |
| dmart | I think the journalling uses a serial number system, in which case dates and times only exist at a higher level of abstraction. (I could be totally wrong about that one though... 2 mins reading jbd.h != wisdom) | 14:21 |
| dmart | NTP already warps the clock if the network time isn't the same as the system time (questionable whether is should... but it's handy) | 14:22 |
| ogra | well, i didnt look at code at all yet, relying on Keybuk here who told me timestamps are used in the journal | 14:23 |
| squirrelpimp | thebishop, there are several available but usually the are provided by your deskop environment (KDE, Gnome, XFCE) | 14:23 |
| dmart | ogra: could be right... I should do more homework | 14:23 |
| thebishop | squirrelpimp, i see. So I should ask #gnome@irc.gimp.org to submit modifications to that piece? | 14:23 |
| squirrelpimp | well, if you're using gnome, then "yes" :) | 14:24 |
| dmart | ogra, mind you, the journal is recovered _before_ e2fsck gets to run, so if it really does rely on timestamps, you've already lost by this stage | 14:24 |
| ogra | yeah, which is why i focused on the clock with my workarounds | 14:25 |
| thebishop | squirrelpimp, got it, thanks | 14:25 |
| ogra | (guessing you have seen my script on the bug) | 14:25 |
| dmart | yep, vary sneaky ;) | 14:26 |
| DktrKranz | pitti: I created a branch to be eventually merge syncpackage script into ubuntu-dev-tools. your version didn't have any copyright notice, I temporarily used GPLv3 pending your comment. Is it fine for you, or do you prefer something else? | 14:29 |
| pitti | DktrKranz: fine for me | 14:30 |
| DktrKranz | ok, thanks! | 14:31 |
| OdyX | Okay. I filed bug 564353 and bug 564695. Ball's on your side now. | 14:46 |
| ubottu | Launchpad bug 564353 in usb-modeswitch "usb_modeswitch crashes with Sony adapters" [Undecided,Fix committed] https://launchpad.net/bugs/564353 | 14:46 |
| ubottu | Launchpad bug 564695 in usb-modeswitch-data "Sync usb-modeswitch-data 20100322-2 (universe) from Debian squeeze (main)" [Wishlist,New] https://launchpad.net/bugs/564695 | 14:46 |
| seb128 | doko__, chrisccoulson: is bug #561124 fixed now or does it still require firefox changes? | 14:58 |
| ubottu | Launchpad bug 561124 in openjdk-6 "firefox sets LD_LIBRARY_PATH which breaks the icedtea6-plugin" [High,Fix released] https://launchpad.net/bugs/561124 | 14:58 |
| doko__ | seb128: I have a workaround for the plugin, but IMO other plugins could be affected as well. so maybe remove the milestone, but keep the report open | 14:59 |
| seb128 | doko__, ok, I was checking for the r-t meeting today, thanks | 14:59 |
| joaopinto | mvo, ping, new bug on upgrade | 15:06 |
| mvo | joaopinto: ok | 15:07 |
| mvo | joaopinto: on the phone, but I will read backlog | 15:07 |
| joaopinto | E:Unable to correct problems, you have held broken packages. | 15:08 |
| joaopinto | I don't have broken packages afaik | 15:11 |
| mvo | joaopinto: amd64? | 15:13 |
| joaopinto | yes | 15:14 |
| joaopinto | Package plymouth has broken Depends on udev | 15:14 |
| joaopinto | Considering udev 23 as a solution to plymouth 10011 | 15:14 |
| joaopinto | Reinst Failed because of initramfs-tools | 15:14 |
| joaopinto | Try to Re-Instate udev | 15:14 |
| mvo | ok. sort of known | 15:14 |
| joaopinto | not sure if this helps, tail from apt.log | 15:14 |
| mvo | transient | 15:14 |
| joaopinto | need to way for something to be built ? | 15:14 |
| joaopinto | wait | 15:15 |
| persia | Essentially, yes. | 15:19 |
| persia | Or be published, or be mirrored, etc. | 15:19 |
| joaopinto | ok thanks | 15:27 |
| * kirkland high fives pitti | 15:35 | |
| kirkland | pitti: i do everything i can to keep up with you :-) | 15:35 |
| kirkland | pitti: but you're just a friggin machine! | 15:35 |
| pitti | kirkland: I was just going to say the same about you! | 15:36 |
| === mathiaz_ is now known as mathiaz | ||
| nigelb | ccheney, do you have any more thoughts for bug 512395? there is a new patch for it | 15:43 |
| ubottu | Launchpad bug 512395 in openoffice.org "Openoffice.org's .desktop files do not contain translation domain info" [Undecided,New] https://launchpad.net/bugs/512395 | 15:43 |
| * ccheney sees if he can get OOo working for hardy now | 15:53 | |
| === dendro-afk is now known as dendrobates | ||
| === dholbach_ is now known as dholbach | ||
| soreau | Hello. I'm having trouble figuring out which package provides the files in /usr/local/lib/python2.5/site-packages/ccm/* on karmic. I tried apt-file and packages.ubuntu.com but I can't seem to figure it out | 16:08 |
| Daviey | pitti: Have you spoken to superm1 about bug 563053 - mythtv? | 16:31 |
| ubottu | Launchpad bug 563053 in mythplugins "Please remove Mysql 5.0 from the archive for lucid." [Undecided,In progress] https://launchpad.net/bugs/563053 | 16:31 |
| nailor | git-svn does not seem to work with the latest git. there no git-svn binary seems to be in the path at all. can somebody confirm this? | 16:31 |
| pitti | Daviey: not on IRC yet, just on the bug | 16:31 |
| Daviey | pitti: Okay, i know he's busy with a few things at the moment - so if you want to reassign that to me, that would be great. | 16:32 |
| pitti | Daviey: oh, great; please feel free to just assign to you yourself | 16:33 |
| pitti | Daviey: I should probably have assigned it to mythbuntu-dev, right? | 16:33 |
| Daviey | done | 16:33 |
| Daviey | pitti: yeah, that would be good i guess for future :) | 16:33 |
| pitti | but I didn't want to break mythtv behind your back by removing it now | 16:33 |
| pitti | but we really should remove 5.0 from lucid | 16:33 |
| pitti | Daviey: noted for the next time | 16:33 |
| Daviey | full agree :) | 16:34 |
| Daviey | +y | 16:34 |
| Daviey | Doing a local build now, will push it if it works. :) | 16:34 |
| joaopinto | mvo, the upgrade to lucid was now successful, thanks for the quick fix | 16:35 |
| mvo | joaopinto: cool | 16:37 |
| mvo | thanks for verifying | 16:37 |
| micahg | jdstrand: can I poke you about 2 archive syncs? | 16:39 |
| jdstrand | micahg: sure, what? | 16:40 |
| micahg | jdstrand: phpmyadmin and libnetx-java, I'll grab the bug #s | 16:40 |
| micahg | bug 563549 | 16:41 |
| ubottu | Launchpad bug 563549 in phpmyadmin "Please sync phpmyadmin 4:3.3.2-1 (universe) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/563549 | 16:41 |
| micahg | bug 563745 | 16:41 |
| ubottu | Launchpad bug 563745 in karl3 "Show syslog entries in batches" [Low,New] https://launchpad.net/bugs/563745 | 16:41 |
| micahg | oops | 16:41 |
| micahg | bug 563745 | 16:41 |
| micahg | ah | 16:41 |
| micahg | bug 562745 | 16:41 |
| ubottu | Launchpad bug 562745 in libnetx-java "Sync libnetx-java 0.5-2 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/562745 | 16:41 |
| jdstrand | micahg: phpmyadmin is bugfix only? | 16:45 |
| nailor | my bad. it is not supposed to work that way any longer... | 16:45 |
| micahg | jdstrand: looks like it from upstream changelog, it also fixes and install issue | 16:45 |
| micahg | jdstrand: thanks | 16:58 |
| jdstrand | micahg: sure | 16:58 |
| pitti | zul: "Rebuild with libmysqlclient15-dev."? that's the one we are trying to get rid of :) | 16:59 |
| zul | pitti: meh :) | 16:59 |
| zul | pitti: can you reject it so I can fix the changelog | 17:00 |
| pitti | zul: (btw, I recommend adding LP: #xxx to the changelog, to avoid having to manually chase down the task closing) | 17:00 |
| pitti | zul: rejected; thanks | 17:00 |
| zul | pitti: fixed the changelog now | 17:01 |
| Keybuk | ogra: I have talked to Ted for you | 17:03 |
| ogra | Keybuk, what did he say ? | 17:03 |
| Keybuk | he sympathised, and suggested that maybe broken_system_clock should *ignore* clock errors | 17:03 |
| Keybuk | rather than fix them | 17:03 |
| ogra | ++ | 17:03 |
| ogra | Keybuk, thats what dmart suggested too today :) | 17:04 |
| ogra | Keybuk, beyond that i'm fiddling with a workaround initramfs script for now (in case you saw my bug comments) | 17:04 |
| Keybuk | so consider the bug upstreamed | 17:04 |
| ogra | thanks so much ! | 17:04 |
| cjwatson | Keybuk: bug 534743, I noticed that psusi's branch still just removes "change" which you objected to in comment 4 - did the mentioned discussion he had with you on IRC clarify that at all, and does your objection stand? | 17:06 |
| ubottu | Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [High,Triaged] https://launchpad.net/bugs/534743 | 17:06 |
| Keybuk | cjwatson: I don't have the context for that | 17:06 |
| Keybuk | but I have a vague feeling I may have decided not to care about dmraid being broken ;) | 17:06 |
| Keybuk | so if psusi wants to patch it, he can <g> | 17:06 |
| cjwatson | I'll talk with him about it when he next shows up, then | 17:07 |
| didrocks | slangasek: you assigned me bug #522858, didn't you see my comment at https://bugs.edge.launchpad.net/ubuntu/+source/maximus/+bug/522858/comments/7 ? | 17:08 |
| ubottu | Launchpad bug 522858 in maximus "Sometimes app windows come up undecorated, unselectable, and not full screen" [High,New] https://launchpad.net/bugs/522858 | 17:08 |
| ubottu | Launchpad bug 522858 in maximus "Sometimes app windows come up undecorated, unselectable, and not full screen" [High,New] | 17:08 |
| === deryck is now known as deryck[lunch] | ||
| didrocks | asac: who can I reassign it in your team? (bug #522857 and #522858). The efl launcher should be in cause there as I don't have this behavior on the 3D one and not sure I currently have time to invest on efl launcher :) | 17:20 |
| ubottu | Launchpad bug 522857 in cwiid "X crash" [Undecided,New] https://launchpad.net/bugs/522857 | 17:20 |
| ubottu | Launchpad bug 522858 in maximus "Sometimes app windows come up undecorated, unselectable, and not full screen" [High,New] https://launchpad.net/bugs/522858 | 17:20 |
| asac | didrocks: i think the undecorated is bug soemthing we can take back. assign it to JamieBennett | 17:22 |
| nxvl | slangasek: can you please take a look at Bug #564190 if you have time | 17:22 |
| ubottu | Launchpad bug 564190 in terminator "Update Terminator to 0.93" [Undecided,New] https://launchpad.net/bugs/564190 | 17:22 |
| asac | didrocks: the focus thing i would really love to get your idea on | 17:22 |
| didrocks | asac: thanks :) | 17:22 |
| didrocks | asac: I can try next Monday to get some trace on maximus | 17:23 |
| didrocks | (maybe the two things are related) | 17:23 |
| asac | could be yeah. | 17:32 |
| sistpoty|work | nxvl: does terminator build, install and work fine? | 17:33 |
| nxvl | sistpoty|work: yup | 17:33 |
| nxvl | sistpoty|work: in my chroot works fine | 17:33 |
| nxvl | sistpoty|work: want me to upload to my ppa first? | 17:34 |
| sistpoty|work | nxvl: only in case you haven't done a test-build yet ;) | 17:34 |
| nxvl | heh | 17:34 |
| nxvl | :P | 17:34 |
| nxvl | i've | 17:34 |
| nxvl | and it's on the prosess to get sponsored to debian already | 17:35 |
| sistpoty|work | nxvl: approved then, go ahead | 17:35 |
| sistpoty|work | excellent! | 17:35 |
| nxvl | \o/ | 17:36 |
| nxvl | Ng: ^^ | 17:36 |
| Ng | \o/ | 17:36 |
| Ng | thanks very much folks | 17:36 |
| Ng | as much as I like cutting a juicy bugfixing release, I hope that's about it for bugs for now ;) | 17:37 |
| nxvl | :D | 17:38 |
| nxvl | we all hope | 17:38 |
| * persia takes that as an invitation to hunt and file more | 17:38 | |
| * sistpoty|work files a bug against persia :P | 17:38 | |
| persia | sistpoty|work: Actually, all the stuff I want in terminator would fall into "New Feature" and so be unsuitable for lucid anyway (e.g, better screen integration, memory of window sizes in layouts, etc.) | 17:39 |
| sistpoty|work | heh | 17:39 |
| Ng | persia: I really want to fix as many bugs/regressions as I can, but if the flow slackens off then I have time to start knocking out the sane wishlists and pushing for 1.0, then fame, glory, riches and retirement ;) | 17:40 |
| persia | Ng: heh, yeah. But from what you write above, it sounds like you're getting close to catching up on bugs/regressions. | 17:41 |
| persia | (and thanks for that: it's an immensely useful tool that has massively improved my workflows) | 17:41 |
| Ng | persia: I hope so. the unfixed bugs at this point are, afaict, weird interactions between different gtk/pygtk/vte versions | 17:42 |
| Ng | if I had an interactive test suite I could automate finding them with VMs of different distro versions :D | 17:42 |
| Keybuk | cjwatson: Val's giving a talk about VFS Union Mounts now ;-) | 17:42 |
| persia | Ng: If it's accessibility-enabled, mago ought be able to do most of that. | 17:42 |
| Ng | persia: yeah I really want to poke at ldtp to see if I can make a functional test suite. Maybe I can beer my way to some tuition from a QA person at UDS ;) | 17:44 |
| persia | Ng: There's a good chance of that :) | 17:44 |
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-lunch | ||
| slangasek | didrocks: it came up for discussion in the release meeting and your name came up - no, I hadn't seen your comment, sorry :) | 17:58 |
| didrocks | slangasek: no pb, fixed with asac :) | 17:58 |
| === MacSlow is now known as MacSlow|capoeira | ||
| psusi | Keybuk, two questions for you... 1) does ureadahead open() all of the files first to get the inodes and any directory blocks needed to be read and out of the way before calling readahead(), and 2) is there a tool to do the leg work of translating the block numbers in the blktrace to file names for me? manually using debugfs is getting real annoying ;) | 18:10 |
| Keybuk | psusi: bzr branch lp:ubuntu/ureadahead | 18:13 |
| psusi | hehe... getting that and the kernel sources now... after looking at the blktrace it looks like sometimes ureadahead only queues a few reads that may span a few files, and other times it queues up to read_ahead_kb, which I increased from 128k to 64mb, so it queues a WHOLE Lot in one burst, then blocks until it all finishes while it waits for a directory block to be read | 18:15 |
| kenvandine | slangasek, i am going to upload ubuntuone-client with a patch reverting that string change | 18:16 |
| psusi | I've got one huge burst where it fills the queue very deep with sequential reads, and the disks spinf full titlt, then it goes haywire... this is after having defrag pack all the files ureadahead wants at the start of the disk | 18:16 |
| slangasek | kenvandine: great, thanks | 18:19 |
| Keybuk | psusi: bzr branch lp:ubuntu/ureadahead | 18:20 |
| === gtlz_ is now known as gtlz | ||
| kenvandine | slangasek, ok, ubuntuone-client uploaded again, make sure you approve the latest one :) | 18:51 |
| psusi | ohh, interesting... * So an mpage read of the first 16 blocks of an ext2 file will cause I/O to be submitted in the following order: 12 0 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16. e2defrag lays out the blocks 0-11, then the indirect block. sounds like it should lay out the indirect block first | 18:52 |
| psusi | ohh, nevermind... comment further on says they correct that ;) | 18:54 |
| === beuno-lunch is now known as beuno | ||
| zyga | hello | 19:05 |
| bryceh | slangasek, brian murray found a pretty nasty performance bug with the latest -ati 6.13.0 update - bug #564181 | 19:17 |
| ubottu | Launchpad bug 564181 in xserver-xorg-video-ati "[RV730] GPU soft reset infinite loop scrolling in firefox with compiz" [High,Triaged] https://launchpad.net/bugs/564181 | 19:17 |
| bryceh | slangasek, in investigating it, I've found that upstream slipped in a bunch of performance optimization changes right prior to 6.13.0 which seems to have caused some performance regressions, including this one as brian's testing confirmed | 19:18 |
| bryceh | slangasek, given that we're in final freeze, my conservative reaction is to revert all those performance changes | 19:19 |
| === oSoMoN_ is now known as oSoMoN | ||
| bryceh | slangasek, in parallel it appears Sarvatt felt similarly since he prepared the patches to revert all of it - http://sarvatt.com/downloads/radeon/ | 19:19 |
| bryceh | slangasek, pulling this set of changes out gets us down fairly close to the .192 version we had tested fairly heavily which would give me a good deal of confidence | 19:21 |
| bryceh | slangasek, however since this would be a pretty hefty amount of change to -ati in FF, I wanted to run it by you first for sanity checking. | 19:21 |
| bryceh | slangasek, the other option would be for us to stick with what we've got and wait for upstream to come up with fixes and sru them in. | 19:21 |
| bryceh | the only concern I have with that strategy is that maybe there are other performance bugs hiding in this new code. Honestly, this seems like the sort of changes which should *not* have gone in right before a release. | 19:23 |
| === dpm is now known as dpm-afk | ||
| === warp10_ is now known as warp10 | ||
| nosse1 | Hi guys. How is lucid going? E.g. I'm considering upping my amd64 to karmic on my work laptop. Is it stable enough to try (please, I do know it's beta)? | 19:56 |
| nosse1 | s/karmic/lucid/ | 19:56 |
| ScottK | nosse1: If you have to ask, the answer is no. | 20:01 |
| nosse1 | ScottK: It depends. When I was working on Debian, beta 2 didn't usually mean that the sw were bad. It was just the stability of the package system (dep's and such) which were going up and down | 20:03 |
| ScottK | nosse1: It's ~probably OK, but if you can't afford a few days of broken, I wouldn't advise it. | 20:04 |
| nosse1 | ScottK: So I hoped lucid were like "The SW is mostly ok, but the pkg system might be broken. wait until tomorrow to recheck" | 20:04 |
| ScottK | nosse1: There have been a lot of uploads in the last day or two. Hard to tell. | 20:04 |
| nosse1 | ScottK: If so, I'll jump in and help to discover issues :D | 20:04 |
| ScottK | If you aren't running i386 I would definitely not upgrade now as archive skew will get you almost for sure. | 20:05 |
| nosse1 | ScottK: Even on amd64? | 20:05 |
| ScottK | nosse1: It's less behind, but it's still behind. | 20:06 |
| ScottK | So you can end up with arch all bits and amd64 specific bits of packages out of sync. | 20:06 |
| ScottK | My predcition is that by tomorrow amd64 will be caught up. | 20:06 |
| nosse1 | Yeah, I see there's 28 waiting jobs in the build farm | 20:07 |
| psusi | aha! readahead() blocks to read the indirect block.... damn... I guess I have to get extents working | 20:27 |
| === foxbuntu` is now known as foxbuntu | ||
| micahg | mvo: ping | 20:36 |
| mvo | micahg: pong | 20:38 |
| micahg | mvo: we have an issue that app-install-data is using the firefox.desktop file from kubuntu-firefox-installer instead of firefox-branding, is there a way for multiple packages to have the same name for a .desktop file ATM or do we need to get the kubuntu-installer updated? | 20:39 |
| Riddell | kubuntu-firefox-installer shouldn't be in app-install-data | 20:40 |
| Riddell | probably needs some exception somewhere to be told that | 20:40 |
| Riddell | cjwatson: I was able to recreate bug 563309 :( logs attached | 20:40 |
| ubottu | Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [High,Confirmed] https://launchpad.net/bugs/563309 | 20:40 |
| cjwatson | Riddell: evan committed a patch earlier today ...? | 20:41 |
| cjwatson | Riddell: ubiquity r4095. maybe wowrth testing if you can reproduce it? | 20:42 |
| cjwatson | -w | 20:42 |
| Riddell | cjwatson: tsk, I should refresh my bugs before commenting :) | 20:42 |
| cjwatson | I haven't looked at the bug myself yet TBH | 20:43 |
| mvo | micahg: uh, I could manually fix it up, but currently that is not possible to have multiple ones | 20:48 |
| mvo | micahg: the extractor is not very smart | 20:48 |
| micahg | mvo: is there a way for packages to exempt themselves from app-install-data ATM or is there an exception list in the data package itself? | 20:49 |
| micahg | mvo: per Riddell kubuntu-firefox-installer shouldn't be in there | 20:49 |
| micahg | mvo: also, should I file a feature request to support multiple .desktop files w/the same name | 20:50 |
| mvo | micahg: I can do that via a manual blacklist | 20:58 |
| micahg | mvo: k, should I file a bug and where? | 20:58 |
| mvo | micahg: I added it now, I need to re-run the extraction, that will take a while | 20:59 |
| micahg | mvo: thanks, so, is it worth the feature request for multiple .desktop files w/the same name or should that normally be not done anyways | 21:00 |
| mvo | micahg: yeah, lp:~mvo/archive-crawler/mvo is the thing that is currently doing it | 21:01 |
| * mvo runs a update | 21:01 | |
| micahg | mvo: k, thanks | 21:01 |
| cjwatson | sbeattie: can you reproduce bug 558382 on demand? | 21:10 |
| ubottu | Launchpad bug 558382 in debian-installer "Partitioner throws "Unable to satisfy all constraints" when trying to use previously created partitions" [Medium,Confirmed] https://launchpad.net/bugs/558382 | 21:10 |
| cjwatson | sbeattie: if so, I might like to have you do some rather detailed debugging | 21:11 |
| === RoAk is now known as RoAkSoAx | ||
| joaopinto | on the boot process when rescue mode is selected is plymouth still used somehow ? | 21:35 |
| joaopinto | what could causing an hang immediately after a successful mountall using rescue mode ? | 21:35 |
| sbeattie | cjwatson: I think I can but it'll take some time. | 21:36 |
| ScottK | joaopinto: You can't boot without plymouth. | 21:37 |
| cjwatson | sbeattie: that's OK, I'm still working through the maths | 21:37 |
| cjwatson | I hope to be able to figure it out on my own, but I'm not certain ... | 21:37 |
| joaopinto | ok, so after mountall it's likely to be upstart or plymouth related right ? | 21:37 |
| * ScottK is not the Scott you are looking for .... | 21:38 | |
| joaopinto | it's kind of frustrating to see an user trying to boot for several hours and not have the know-how to help him :\ | 21:38 |
| Keybuk | plymouth probably | 21:39 |
| joaopinto | Keybuk, how can we debug it ? | 21:39 |
| Keybuk | root shell alongside | 21:40 |
| psusi | neat... ureadahead is smart enough to figure out what block groups the inodes of the files it's reading are in, and has e2fslib go read the inode tables for those groups off the bat so they are already in memory when needed by open().... slick... now this blktrace is making much more sense | 21:40 |
| Keybuk | psusi: that's because the author of ureadahead is a genius | 21:41 |
| joaopinto | Keybuk, is it described somewhere ? (I don't want to bore you with trivial questions) | 21:41 |
| psusi | hehehe ;) | 21:41 |
| Keybuk | joaopinto: the "open vt" trick on upstart.ubuntu.com/wiki/OMGBroken is the one I use | 21:41 |
| psusi | Keybuk, I also figured out that readahead() can block.. if it needs to read an indirect block... I need to get rid of those now... but first i need to figure out this big gap of no io in the middle of the ureadahead... | 21:43 |
| cjwatson | psusi: so this dmraid bug - it wasn't entirely clear to me from the bug log. are you and Keybuk now agreed that it is harmless to leave out change events from the rule? that's my understanding from having gone back and trawled IRC logs, but I wanted to check | 21:43 |
| Keybuk | psusi: does fadvise make any difference? I tried it but couldn't tell | 21:43 |
| psusi | Keybuk, I think it's basically the same code in the kernel, though I didn't specifically check that sys call, most of the code I read had comments indicating it was used by both | 21:44 |
| Keybuk | right, that's what I thought | 21:44 |
| Keybuk | which means one of the man pages is lying about always blocking or always not blocking ;) | 21:44 |
| psusi | Keybuk, it tries very hard to queue bios for the largest reads it can, but it doesn't know where the blocks are until it reads the indirect block | 21:44 |
| Keybuk | I suspect, since fadvise came later, the readahead man page is wrong | 21:44 |
| Keybuk | bear in mind, of course, that ext4 doesn't have indirect blocks | 21:45 |
| psusi | so it has to wait until the indirect block is read before it can queue reads for the blocks it maps... at least if the file is > 11 blocks | 21:45 |
| psusi | yes... I'm using -O ^extents right now though because I have not yet got e2defrag to understand them | 21:45 |
| Keybuk | right, I think that the e2fs inode group preloading is supposed to get those into memory too | 21:46 |
| Keybuk | but you never really know | 21:46 |
| psusi | once I do that, then readahead() should generate one quite bio to read the whole file, stick it in the queue, and return... so eventually ureadahead should exit and upstart will move on to mountall while most of the reads are still in the queue | 21:46 |
| ccheney | grr ooo-l10n backport test build is taking forever :-\ | 21:47 |
| psusi | cjwatson, I dunno, have to ask Keybuk ;) | 21:47 |
| * psusi wonders wtf shorted out in his brain that made him type quite bio | 21:48 | |
| Keybuk | psusi: once you do what? | 21:48 |
| cjwatson | 17:06 <Keybuk> so if psusi wants to patch it, he can <g> | 21:48 |
| Keybuk | oh, you mean once you get defrag to work? | 21:48 |
| psusi | Keybuk, get e2defrag understanding extents | 21:48 |
| Keybuk | yeah that should turn ureadahead into a bunch of calls that result in ONE VERY BIG READ | 21:48 |
| psusi | yea... extents is the last of the new ext4 features I don't have it working with yet | 21:48 |
| Keybuk | I appear to have put cjwatson on ignore | 21:49 |
| cjwatson | psusi: I just wanted to make sure that you'd considered the stuff in comment 4 on that bug, and explicitly rather than implicitly disregarded it :-) | 21:49 |
| Keybuk | I have no idea how I did that | 21:49 |
| * cjwatson pouts | 21:49 | |
| psusi | exactly... one very big async read that completes in the background after ureadahead returns and upstart moves on | 21:49 |
| Keybuk | psusi: extents is basically *the* ext4 feature though ? :) | 21:49 |
| Keybuk | though doesn't the defag currently in e2fsprogs deal with them? | 21:49 |
| psusi | Keybuk, yep... I should have it working in a few more days | 21:49 |
| cjwatson | this is a very tedious form of debugging | 21:50 |
| psusi | you mean the still experimental and unshipped e4defrag? | 21:50 |
| Keybuk | yes | 21:50 |
| cjwatson | /nick cjwatson-running-gdb-in-my-head | 21:50 |
| psusi | yes, since it uses ioctls to manipulate the blocks though the mounted filesystem rather than on the raw block device | 21:50 |
| psusi | though it just defragments files by allocating a new file, checking if that is contiguous, and atomically swapping the blocks as far as I have read | 21:51 |
| psusi | doesn't pack files, or defragment free space | 21:51 |
| psusi | the nice thing about the old e2defrag is that you can feed it a list of inodes to give higher priority to so it packs them together at the start of the disk | 21:51 |
| psusi | i.e. the list from ureadhead.pack | 21:52 |
| psusi | though I had to kind of hack it to force blocks there instead of allocating from their native block group first... I need to clean up that patch and probably add a switch to enable/disable it | 21:52 |
| psusi | cjwatson, what was that bug# again? | 21:53 |
| === akgraner` is now known as akgraner | ||
| Keybuk | cjwatson: sounds like my life ;) gdb -p 1 ... FAIL | 21:54 |
| cjwatson | psusi: bug 534743 | 21:57 |
| ubottu | Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [High,Triaged] https://launchpad.net/bugs/534743 | 21:57 |
| tedg | slangasek: Howdy. I have a patch for indicator-application which renames a binary package. Is that okay? bug 564506 | 21:57 |
| ubottu | Launchpad bug 564506 in indicator-application "libappindicator-cil-dev's .pc file points to the wrong place" [Critical,Triaged] https://launchpad.net/bugs/564506 | 21:57 |
| === blueyed_ is now known as blueyed | ||
| psusi | cjwatson, yes, as far as I know, there is no sensible situation where a change event on the underlying disk would occur and dmraid would care... it just needs to notice when the disks are added and scan them | 22:02 |
| psusi | cjwatson, and to get my system running I had to remove the |change and have not had any issues with it since | 22:03 |
| === BlackZ_ is now known as BlackZ | ||
| cjwatson | GrueMaster: bug 564992 - isn't this an arm platform, in which case dmidecode is unavailable? the installer syslog is generally the useful thing | 22:03 |
| ubottu | Launchpad bug 564992 in debian-installer "Debian installer fails to properly detect Marvell Avenger development platform" [Undecided,New] https://launchpad.net/bugs/564992 | 22:03 |
| cjwatson | GrueMaster: (and if so, the Ubuntu armel porters might be better-placed to work on it) | 22:04 |
| psusi | by the way, that upgrade I did a bit ago took AGES... we didn't get that bad sync() a million times dpkg patch again did we? | 22:04 |
| cjwatson | different one | 22:05 |
| cjwatson | apw tested it on ext4 and it didn't slow down unpack all that badly | 22:05 |
| psusi | ok, so what sucky thing does this one do? ;) | 22:05 |
| cjwatson | oh sod off | 22:05 |
| cjwatson | it's a Friday evening | 22:05 |
| psusi | hehehe | 22:05 |
| cjwatson | be polite or I'll do something else | 22:05 |
| cjwatson | sorry but not feeling up to this | 22:05 |
| * psusi passes cjwatson a cold one | 22:06 | |
| cjwatson | have a look at the dpkg 1.15.5.6ubuntu4 diff if you like | 22:06 |
| cjwatson | I'm interested in data if it is slow, but I would greatly prefer it not come with attached vitriol | 22:06 |
| psusi | sigh... guess I'll have to... took a good 5-10 minutes to update on my ssd | 22:06 |
| psusi | used to take maybe 1 min | 22:06 |
| cjwatson | and with no fsync at all, we know that some people end up with zero-length files | 22:07 |
| psusi | you mean if their system crashes? | 22:07 |
| cjwatson | yes | 22:07 |
| cjwatson | we have to do something, that isn't an acceptable failure mode | 22:07 |
| psusi | true... but a huge slowdown isn't either | 22:07 |
| cjwatson | depends how huge | 22:07 |
| cjwatson | Keybuk's one hour to unpack linux-headers was unacceptable | 22:08 |
| cjwatson | in between, there's some room for manoeuvre | 22:08 |
| Keybuk | actually, I did notice a slow upgrade this morning ... | 22:08 |
| cjwatson | what dpkg now does is to batch up all the fsync/renames for a package and do them at the end of its unpack | 22:08 |
| Keybuk | but hadn't had enough coffee to think about it | 22:08 |
| mrenouf | How do I use git-buildpackage with pbuilder? | 22:09 |
| psusi | ok... so it's not quite as bad, especially on packages with lots of files.... but still quite a hit flushing between each package when upgrading a number of packages | 22:09 |
| Keybuk | but there's also a fine line here between YES! FASTER! HARDER! and HURT ME! MAKE ME BLEED! | 22:09 |
| cjwatson | something like comparative unpacks of a single package with dpkg 1.15.5.6ubuntu3 vs. 1.15.5.6ubuntu4, and then also strace -tt of each, would be useful | 22:09 |
| psusi | would be much better to save all of the flushing and renaming until after all packages are unpacked | 22:10 |
| Keybuk | it's all well and good unpacking packages really fast, but we kinda need them to stick to the disk | 22:10 |
| psusi | and should still be safe, no? | 22:11 |
| cjwatson | if dpkg deferred all the renames very much further, it would substantially impair reliability of the packaging system as a whole | 22:11 |
| psusi | how so? | 22:11 |
| cjwatson | because it would mean that we'd go from having the new files available immediately after unpack, to having the old files or none available immediately after unpack until very much afterwards | 22:11 |
| cjwatson | it would not remotely surprise me if that broke a load of stuff | 22:11 |
| psusi | why is that a problem? | 22:11 |
| cjwatson | feel free to try it, then try a dist-upgrade, and see :-) | 22:12 |
| cjwatson | but my instincts tell me that it will be a problem | 22:12 |
| psusi | nothing should need the new files until after ALL of them have been unpacked no? | 22:12 |
| cjwatson | sadly, it isn't that simple | 22:12 |
| Keybuk | no | 22:12 |
| Keybuk | that's not the behaviour of dpkg | 22:12 |
| psusi | it's only then that you start doing any configuring and such right? | 22:12 |
| psusi | for configure they have to be in place, but doesn't dpkg unpack all, then configure all? | 22:13 |
| Keybuk | not when pre-depends and conflicts get involved | 22:13 |
| cjwatson | in practice, there are a number of cases even outside the essential set where some files from some packages are expected to be usable to some extent even while unconfigured | 22:13 |
| Keybuk | anyway, what you're talking about is very complicated | 22:14 |
| Keybuk | so patches welcome *after* the release ;-) | 22:14 |
| psusi | cjwatson, yes, but not while not yet unpacked ;) | 22:14 |
| psusi | the state of each package does not need to become unpacked until after all of the files have been extracted, THEN flushed and renamed do they? | 22:15 |
| cjwatson | I do not want to exercise that part of the packaging system | 22:15 |
| cjwatson | besides, it would use a hell of a lot more disk space during unpack | 22:15 |
| psusi | true... | 22:16 |
| cjwatson | the one thing I'd like is some way for dpkg to know that it doesn't need to bother with fsync, because the filesystem isn't optimised to death for benchmarks, but instead is designed for normal applications | 22:17 |
| cjwatson | but that requires kernel cooperation | 22:17 |
| psusi | by optimised to death for benchmarks do yuo mean using data=writeback? | 22:18 |
| psusi | if using the normal data=ordered this isn't a problem then... well... there is a reason why data=writeback is not the default, not recommended, and known to be dangerous ;) | 22:19 |
| cjwatson | and yet there's not a lot we can say when people file bugs saying that their system is now busted | 22:20 |
| psusi | sure there is... you busted it... don't use data=writeback | 22:20 |
| cjwatson | doesn't work that way | 22:20 |
| psusi | if the user is dumb enough to enable hardware write though cashes and disable barriers, there isn't anything the developers can do besides tell them they are an idiot, they were warned not to do that... | 22:21 |
| sladen | lock free ring buffers | 22:22 |
| jdong | I've dealt with a couple users who enabled data=writeback for their ext4 | 22:22 |
| cjwatson | for other applications, sure. but if dpkg breaks then you may not even be able to get back into your system to undo it. that's unacceptable | 22:22 |
| jdong | and had parts of kern.log show up in /var/lib/dpkg/status and all other fun stuff | 22:22 |
| jdong | in talking to those users, the best I can get is an admission they followed some sort of HOWTO on "tuning" their filesystems :) | 22:23 |
| jdong | so yes, the point is, it does happen | 22:23 |
| psusi | cjwatson, first, does this really only happen with data=writeback, or data=ordered too? if it happens either way then this discusstion is moot, but if it's only with data=writeback, that's the risk they take when they enable that and have been told this can hose your system | 22:23 |
| cjwatson | I honestly don't know, and have not put the effort in to finding out | 22:24 |
| cjwatson | because I don't think it's OK for dpkg to break either way | 22:24 |
| Keybuk | I'm going to start writing a new series of articles called HOWNOTTOs | 22:24 |
| cjwatson | sure, it's a filesystem configuration error, almost certainly. but dpkg is not the place you want to discover it | 22:24 |
| Keybuk | I can probably just C&P from ubuntu forums | 22:24 |
| psusi | hehe | 22:24 |
| ion | keybuk: Helpful workarounds from Launchpad bug report comments should also be good material. | 22:25 |
| psusi | personally I'm the kind of person who dose use writeback, no journal, no barriers and hardware write back caches, but I have a UPS and won't be surprised if the whole system crashes and leaves me with an unbootable system | 22:26 |
| psusi | good backup policy for the winz ;) | 22:26 |
| cjwatson | and frankly, from a user's point of view, Ubuntu should be a unified system. If we ship the ability to configure a system such that our own packaging system falls over, they won't be blaming the Linux kernel developers or themselves, they'll be blaming us, and all the protestations we make about it not being our fault aren't going to cut much ice | 22:26 |
| psusi | so are we going to try and prevent them from doing an rm -fr / too? ;) | 22:27 |
| Keybuk | cjwatson: this is why I say we shouldn't support XFS <g> | 22:27 |
| cjwatson | psusi: sigh, why does everyone always make this kind of comparison? | 22:27 |
| cjwatson | now, performance regressions do not make me happy, but if they're within vaguely reasonable bounds, I'll live with them if they're going to significantly improve reliability | 22:27 |
| psusi | hehe, reductio ad absurdum | 22:28 |
| cjwatson | if the performance regression makes you sad (and you can reproduce it - it's not something I see so I'm not in a good position to do anything about it), then find a way to achieve both goals | 22:28 |
| ion | I don’t think --preserve-root is as much for stupid users as for one-letter typos in maintscripts or equivalent things. | 22:28 |
| cjwatson | Keybuk: to be fair, XFS has had rename barriers since 2.6.17 | 22:29 |
| cjwatson | or so I understand it - pretty sure nobody's reported dpkg status files full of \0 on XFS for quite a while now | 22:30 |
| psusi | if the problem is specific to data=writeback then maybe dpkg could force a remount to data=ordered | 22:30 |
| ion | I’m under the impr\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0oblem has been fixed quite some time ago, yeah. | 22:31 |
| psusi | cjwatson, for testing purposes is there a magic flag I can throw so dpkg WON'T sync? that way I can get a good comparison | 22:31 |
| psusi | dpkg --please-break-my-system ;) | 22:31 |
| ion | If nothing else, LD_PRELOAD something that makes syncs dummy. :-P | 22:32 |
| psusi | hrm... never tried doing something like that | 22:33 |
| cjwatson | psusi: the other changes in ubuntu4 aren't all that performance-critical - just downgrade? | 22:33 |
| cjwatson | no, there is no such flag | 22:33 |
| psusi | hrm... ok | 22:33 |
| * psusi really wishes that btt's seeks output would combine sequential reads into one instead of spitting out 0 distance seeks over and over and over | 22:36 | |
| Keybuk | cjwatson: not only am I running gdb in my head | 22:43 |
| Keybuk | I'm now also running mountall in my head | 22:43 |
| GrueMaster | cjwatson: Ok, thanks. I'll reassign it (if you haven't already). | 22:43 |
| cjwatson | GrueMaster: I haven't | 22:54 |
| cjwatson | sbeattie: so, having run through a good chunk of libparted in my head (well, with an editor window and a calculator), its algorithms check out :-/ | 22:55 |
| cjwatson | sbeattie: so I'll probably have to give you debug patches to partman-base and parted to apply, build, and copy into a running d-i image before starting the partitioner | 22:55 |
| sbeattie | cjwatson: okay. | 22:56 |
| slangasek | bryceh: -ati> so looking at the publishing history, I'd say batch-reverting the performance-related changes to get us roughly to the code base we had for both betas is appropritae | 22:57 |
| cjwatson | sbeattie: ... but I think tonight I probably need to fall over now | 22:57 |
| cjwatson | sbeattie: I'll stick them on the bug for you? | 22:57 |
| sbeattie | cjwatson: that will work. | 22:57 |
| bryceh | bdmurray, have you had a chance to test my ppa? Given slangasek's go ahead I can upload once you verify it does in fact resolve the issue for you. | 22:58 |
| bdmurray | bryceh: just rebooted | 22:58 |
| slangasek | tedg: indicator-application> yes, seems reasonable here, please go ahead | 22:59 |
| bdmurray | bryceh: if I don't respond you'll know why! ;-) | 22:59 |
| tedg | Yeah! slangasek thinks I'm reasonable! ;) | 23:00 |
| tedg | slangasek: Thanks, will do. | 23:00 |
| bryceh | tedg, well that's just weird | 23:00 |
| cjwatson | psusi: merged and uploaded your dmraid change, thanks! | 23:04 |
| === arodriguez is now known as RoAk | ||
| cjwatson | (subject to release team approval) | 23:04 |
| bdmurray | bryceh: no crashing yet | 23:04 |
| psusi | cjwatson, yay! whew... dodged that bullet | 23:05 |
| === arodriguez is now known as RoAkSoAx | ||
| === RoAk is now known as prueba | ||
| === highvolt1ge is now known as highvoltage | ||
| bryceh | slangasek, bdmurray, ok also got confirmation of the ppa's goodness on #ubuntu-x so I've gone ahead and uploaded it | 23:23 |
| bdrung | bryceh: is there something i can do to speed up the fixing of bug #541579? | 23:27 |
| ubottu | Launchpad bug 541579 in xserver-xorg-video-intel "[gm45] does not detect monitor on docking station" [Undecided,Confirmed] https://launchpad.net/bugs/541579 | 23:27 |
| === RoAk is now known as testing | ||
| === testing is now known as testintnt | ||
| bryceh | bdrung, that's handled by the kernel now with kms | 23:29 |
| bryceh | bdrung, so your bug really should be filed against the kernel, not X | 23:29 |
| bdrung | bryceh: so i change it from intel -> linux | 23:30 |
| bryceh | bdrung, anyway, I would probably forward it upstream, they'll probably want you to test a newer kernel, it'll be fixed there so they'll just close it, so then you go hunting through kernel drm trees for a patch | 23:31 |
| bryceh | alternatively you could shut off kms and/or fiddle with it using xrandr and the usual UMS troubleshooting steps documented on the ubuntu-x wiki | 23:32 |
| bdrung | bryceh: ok, i will try a newer kernel and/or shut off kms once i get access to this machine. | 23:33 |
| slangasek | sladen: why do you have this impression that server doesn't have plymouth installed? mountall *depends* on it | 23:38 |
| bdrung | bryceh: if i disable kms and the bug persist, then i would be a bug in xserver-xorg-video-intel, right? | 23:50 |
| slangasek | bdrung: that just means it's a bug in both, I think :) | 23:51 |
| bdrung | ok | 23:51 |
| bdrung | testing a kernel from the mainline build would be sufficient, wouldn't it? | 23:52 |
| bdrung | something like v2.6.34-rc4-lucid? | 23:53 |
| slangasek | I dunno | 23:55 |
| bryceh | bdrung, no ums and kms each have their own separate code paths for handling outputs. They are different so it's possible one works where the other doesn't, but they both share common origins so if they're both broken it doesn't necessarily signify anything substantial except that they're both bugged | 23:58 |
| bryceh | bdrung, but if ums is *not* bugged then you can use it as a workaround, and it confirms the bug's in the kernel | 23:58 |
| bdrung | thanks | 23:59 |
| bryceh | bdrung, also be aware even if ums is still buggy, that is not getting maintained any further upstream, and we're carrying it only for fallback purposes and don't plan to fix bugs in it, so if ums doesn't work, don't worry about that, just focus on the kms aspect of the bug | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
