| Pollywog | cjwatson: I even followed the instructions in the wiki for using chroot and there are some things left out that I had to figure out on my own | 00:00 |
|---|---|---|
| Pollywog | and I am using schroot instead of dchroot | 00:00 |
| Pollywog | so this learning process will be slow | 00:01 |
| directhex | YokoZar, which player? | 00:01 |
| YokoZar | directhex: default totem (installing -restricted-extras didn't change anything) | 00:02 |
| cjwatson | the most important thing to realise is which things are important ... chroots are a nicety that you can look into once you have the basics working. The purpose of using a chroot is either to make sure that your package builds in a clean environment, or to build it for some different environment than your usual one. It is not the first thing that you should be reaching for when trying to debug why something is not working | 00:02 |
| cjwatson | start small and build up | 00:02 |
| Pollywog | I wanted to build on a machine running Intrepid, but the package is for another running Hardy | 00:03 |
| Pollywog | hence the chroot | 00:03 |
| Pollywog | and I wanted to make a custom deb package because one does not exist | 00:04 |
| Pollywog | I have used checkinstall for this for years but I wanted to do it the right way | 00:04 |
| cjwatson | well, if you're using a chroot for that purpose then you probably need it, but you should start by constructing an environment within the chroot that you can debug in just as you would outside the chroot | 00:04 |
| cjwatson | the goal being that you shouldn't need to remember that you're in a chroot most of the time | 00:05 |
| cjwatson | the fewer bits of state you have to keep in your head at once, the better | 00:05 |
| cjwatson | the fact that you mention that a chroot is slowing your learning process indicates to me that you haven't quite got there yet :) | 00:05 |
| directhex | i find a stateless brain helps | 00:05 |
| Pollywog | no chroot is not slowing the process | 00:06 |
| Pollywog | the process is just a slow one | 00:06 |
| Pollywog | since some things are not documented | 00:06 |
| cjwatson | what you need to do is teach yourself the basic tools first | 00:07 |
| cjwatson | trying to figure out what DEB_CONFIGURE_EXTRA_ARGS does is starting from the wrong end | 00:07 |
| Pollywog | and when I came to Ubuntu from Debian, I found some things are not the same | 00:07 |
| cjwatson | start by learning the basics of GNU make and shell scripting if you don't already know them | 00:07 |
| Pollywog | though they are similar | 00:08 |
| Pollywog | k | 00:08 |
| Pollywog | good advice | 00:08 |
| cjwatson | then read through the policy manual and familiarise yourself with the packaging format | 00:08 |
| cjwatson | then pick a sample package, read its debian/rules, and look up manual pages for anything you don't recognise that looks interesting | 00:08 |
| cjwatson | repeat | 00:08 |
| Pollywog | is the Ubuntu Policy Manual different from the Debian one? | 00:09 |
| cjwatson | in small ways, none of which are relevant to you | 00:09 |
| cjwatson | at least not the problem you have described | 00:09 |
| Pollywog | I wanted to do that with kmail but I think I should pick a smaller app | 00:09 |
| Pollywog | cjwatson: I read this same advice about learning a package, but perhaps kmail is too complex for a first package | 00:10 |
| cjwatson | Pollywog: cdbs is the least well-documented of all the popular helper packages | 00:10 |
| cjwatson | not only is kdepim large in and of itself, but it's using a packaging helper which is designed to allow the maintainer to express very powerful things while typing very little | 00:11 |
| cjwatson | while furthermore largely not explaining what it does | 00:11 |
| cjwatson | this is certainly not going to be conducive to learning; but the majority of Ubuntu (and Debian) packages are much simpler | 00:11 |
| ebroder | Yeah, that's definitely true. The people I learned packaging from use cdbs exclusively, but you can't really use it without understanding at least the concepts behind debhelper packaging | 00:11 |
| Pollywog | I guess I could use some smaller package like equivs | 00:11 |
| cjwatson | ebroder: right, hence my comments about building up | 00:12 |
| Pollywog | the reason I picked kmail is that it has an annoying bug of long standing | 00:12 |
| cjwatson | debhelper is a straightforward set of helper tools that operate by abstracting out things you might otherwise type into debian/rules, but in a fairly simple subroutine-call kind of way | 00:12 |
| cjwatson | debhelper is also generally very well-documented | 00:12 |
| cjwatson | since cdbs builds on top of debhelper, you must understand debhelper first | 00:13 |
| cjwatson | in order to understand debhelper, you must understand the things it's abstracting, i.e. the basic packaging format | 00:13 |
| cjwatson | if you work in the right order, it is all much easier and less overwhelming | 00:13 |
| Pollywog | I will read the debhelper stuff again and again, it was hard to digest | 00:13 |
| cjwatson | did you read it before understanding the basic packaging format, though? | 00:14 |
| cjwatson | it's written for people who already know that | 00:14 |
| Pollywog | no | 00:14 |
| Pollywog | k | 00:14 |
| directhex | we've seen some frankly bizarre ones here before from people seeking to avoid learning the "right way" - one guy was editing control.tar.gz in a .deb by hand | 00:14 |
| cjwatson | oh, well, I've done that for very specific reasons, but I already knew what I was doing ;-) | 00:15 |
| ebroder | ..eww | 00:15 |
| cjwatson | (it's a straightforward way to work around broken preinsts if you're in a rush) | 00:15 |
| directhex | cjwatson, i think you've probably earnt the right to do sordid things to packages by now | 00:15 |
| Pollywog | I had to fix a script in a Debian package once and then put the package together again | 00:16 |
| Pollywog | so I could remove it and then install it again | 00:16 |
| Pollywog | it worked :) | 00:16 |
| cjwatson | the preinst (well, and nowadays the config as well) is the only case where you actually need to reassemble the package like that | 00:16 |
| cjwatson | everything else you can just fiddle about in /var/lib/dpkg/info/ or elsewhere on the filesystem | 00:16 |
| Pollywog | yes a preinst or postinst was broken | 00:17 |
| cjwatson | editing a postinst does not require disassembling and reassembling the .deb | 00:17 |
| cjwatson | for the simple reason that the postinst is run in a distinct step (with its own dpkg option, even) after the package is unpacked | 00:18 |
| Pollywog | another trick I have used is to make a fake package with equivs | 00:18 |
| Pollywog | then remove the fake | 00:18 |
| cjwatson | none of this is required to deal with problems removing packages | 00:19 |
| cjwatson | if a prerm fails (which is one case where dpkg doesn't provide you a clean get-out), then it's much simpler and more reliable to edit the script in /var/lib/dpkg/info/ | 00:20 |
| Pollywog | well I did not know that at the time | 00:20 |
| Pollywog | yes I have done the editing too | 00:20 |
| Pollywog | I think someone told me to do that instead of making fake packages | 00:20 |
| cjwatson | the point I'm trying to make is not "woo I'm so tough I can edit files in /var/lib/dpkg/info/" :-) but that, rather than having to remember all the tricks, it all becomes obvious once you know how the mechanisms work | 00:21 |
| cjwatson | it's like your car mechanic mostly doesn't have to learn every single possible part number and what might fail with each - they learn how cars work instead | 00:22 |
| * NCommander kicks debmirror | 00:24 | |
| * cjwatson stops preaching and goes to bed. :) | 00:29 | |
| NCommander | have a good night cjwatson | 00:32 |
| ebroder | Is script/runner "Repository.fetch_changesets" what causes tickets to get updated based on commit messages? | 00:40 |
| ebroder | Err..sorry - wrong window | 00:40 |
| slangasek | Nafallo: and that's exceptional based on the previous pattern? | 00:54 |
| === Ampelbein is now known as ampelbein | ||
| === ampelbein is now known as Ampelbein | ||
| calc | anyone know enough about python/launchpadlib to know why this code is wrong: if task.bug_watch != "None": | 02:42 |
| Snova | Remove the quotes around None. | 02:43 |
| stgraber | are you sure it's "None" and not None ? | 02:43 |
| stgraber | I'd guess it's a NoneType and not the string None | 02:43 |
| ebroder | "task.bug_watch is not None" would be the more typical way of doing that | 02:43 |
| calc | ah maybe so | 02:45 |
| calc | thanks guys that worked | 02:45 |
| * calc thinks launchpadlib is really slow | 02:52 | |
| calc | something like 2 seconds per bug that it is checking | 02:53 |
| ScottK | calc: It can't be any faster than Launchpad. | 02:59 |
| calc | ScottK: true, maybe there isn't a quick way to get at this data, similar data comes up nearly instantly in the web interface | 02:59 |
| calc | i ended up with this, i think it works but its still running | 03:00 |
| calc | for pkgbug in package.searchTasks(status=['Triaged']): | 03:00 |
| calc | for task in pkgbug.bug.bug_tasks: | 03:00 |
| calc | if task.target.resource_type_link.split('#')[1] is 'project' and task.status is 'Invalid' and task.bug_watch is None: | 03:00 |
| calc | print task.bug.id, "-", task.bug_target_name | 03:00 |
| calc | those are the type of bugs that end up vanishing at least afaict when searching in the web interface | 03:01 |
| calc | eg if you use hide_upstream they are hidden and if you use resolved_upstream it only shows invalid if it has a bug_watch | 03:01 |
| ArneGoetje | slangasek: new -base language-packs for Jaunty have been uploaded. | 03:13 |
| calc | ah is and == aren't quite the same thing | 03:19 |
| ebroder | Right - "is" is pointer equality, and "==" are value equality, roughly speaking | 03:21 |
| calc | ebroder: ok | 03:27 |
| slangasek | ArneGoetje: thanks; accepting | 03:34 |
| === Ampelbein is now known as ampelbein | ||
| calc | jcastro: what format was she trying to save in? | 04:10 |
| calc | jcastro: i'm guessing at word 2003 xml | 04:11 |
| jcastro | calc: I think so, I will investigate tomorrow | 04:19 |
| jcastro | I've been trying to deal with this crap all night. :-/ | 04:19 |
| calc | jcastro: fun :\ | 04:20 |
| calc | jcastro: too bad we can't just cram java onto the cd, it breaks lots of bits of OOo | 04:20 |
| jcastro | ok so it's not really a bug, it's just a tradeoff for that certain format? | 04:21 |
| calc | the filters are written in xsl which OOo uses java for the xslt libraries, etc | 04:22 |
| lifeless | ScottK: launchpadlib can be faster in theory, as portlets are not rendered etc | 04:22 |
| jcastro | calc: it would be nice if it installed that kind of stuff on-demand like with mp3's, etc. | 04:25 |
| maco | can it be taught that? | 04:25 |
| jcastro | we do it with rhythmbox and totem, how hard could it be? *grin* | 04:26 |
| calc | lmao | 04:28 |
| calc | for one OOo is its own platform | 04:28 |
| calc | not easy at all, i am accepting patches of course :) | 04:28 |
| calc | pretty much if you use OOo you need Java | 04:28 |
| calc | you can't even search help without Java | 04:29 |
| maco | really? eek | 04:29 |
| calc | i suppose i could add a check to the OOo startup script to automatically ask the user to install java if it isn't already | 04:29 |
| jcastro | you know, I think I'd prefer if it did just that, be honest to me upfront, etc .. | 04:30 |
| calc | i added to the javaldx error message a few weeks ago to tell the user to install the openoffice.org-java-common package which installs java along with it | 04:30 |
| jcastro | a "No seriously you need this" thing on startup or something | 04:30 |
| calc | jcastro: problem is that would happen for all instances running OOo pretty much | 04:31 |
| calc | jcastro: which would cause people to complain that it annoys them, heh | 04:31 |
| jcastro | yeah but on the other hand she had no idea what to do when she got the error | 04:31 |
| calc | we just need to bite the bullet and either 1. force Java onto the CD somehow, 2. ask the user to install Java when they get a net connection, or 3. get rid of OOo from default install so it can have proper depends | 04:32 |
| calc | the more OOo is developed the more things in it depend on Java | 04:33 |
| TheMuso | thats... um.... icky. | 04:33 |
| TheMuso | IMO | 04:33 |
| calc | in 10 years it probably will be completely written in Java ;-) | 04:33 |
| jcastro | calc: going to bed now, I'll add it to my "things I should bring up at UDS" | 04:33 |
| jcastro | thanks for the tip! | 04:33 |
| calc | jcastro: rick mentioned getting Java onto the cd for karmic, but i'm not sure how that will happen it pulls in a lot of packages to make OOo work | 04:34 |
| LordKow | isn't the cd image size currently pushing 700 already? | 04:34 |
| TheMuso | Yes | 04:34 |
| maco | calc: what if in ~/.openoffice it touched a file after they'd been prompted once? | 04:35 |
| maco | calc: check for that file's existence and don't prompt again | 04:35 |
| calc | maco: maybe, i don't know how to hook that into OOo itself though, its pretty ugly as it has its own toolkit, etc | 04:36 |
| superm1 | if that was checked on the first startup of OOo, then you wouldn't really have utility of using it on a live disk anymore, as you'd use use up the the tmpfs with those installed packages if you installed on the live session | 04:36 |
| * calc wishes people would stop writing their own toolkit for their apps and just use something standard | 04:37 | |
| maco | superm1: its not needed to run, just to use some of the more advanced features and help | 04:37 |
| maco | so maybe....is there a way to see if its the live cd and not prompt? | 04:37 |
| maco | oy, getting complicated | 04:37 |
| superm1 | maco, but wasn't calc proposing possibly adding it to the startup script? | 04:37 |
| calc | maco: or saving to file formats | 04:37 |
| maco | yes | 04:37 |
| calc | maco: its used in many features, i don't even know what all myself | 04:38 |
| maco | oh right what jorge was just saying | 04:38 |
| maco | superm1: yes. i was suggesting that the script do if ((java not installed) && (not live cd) && (havent prompted before)): ask | 04:40 |
| ebroder | Where can I find documentation on how the netboot images are built? | 05:24 |
| ebroder | (Is there documentation?) | 05:25 |
| highvoltage | for booting workstation terminals or remote installation? | 05:28 |
| ebroder | Err, sorry - not actually netboot. The mini.iso images that are buried in the netboot directory | 05:29 |
| highvoltage | iirc, mini.iso is if you want to boot from a small cd image and install the rest of the system over the network | 05:31 |
| ebroder | Right. I'm looking to customize it, and I was wondering how they're generated for the archives | 05:31 |
| highvoltage | ah, ok | 05:31 |
| ebroder | It's, uh, relatively hard to try and search for | 05:32 |
| TheMuso | ebroder: you want the dbian-installer source package. | 05:33 |
| TheMuso | debian-installer even | 05:33 |
| * ebroder stares at the build-depends | 05:35 | |
| ebroder | I'm mildly disturbed by this package | 05:37 |
| ebroder | Thanks, TheMuso | 05:37 |
| TheMuso | ebroder: np | 05:37 |
| Amaranth | ebroder: I think everyone is, really | 05:40 |
| Amaranth | Here there be dragons | 05:40 |
| === foxbuntu` is now known as foxbuntu | ||
| pitti | Good morning | 06:30 |
| pitti | slangasek: 345531> I agree that forward is better than backwards; I saw the branch, I'll review/pull/upload | 06:34 |
| pitti | calc: 325973> no, it's not supposed to happen by default; as I read it, you need to disable a gconf key (manage desktop with nautilus) to get it | 06:34 |
| pitti | calc: there might be some timing issues which trigger the same behaviour on the live system, though | 06:35 |
| dholbach | good morning | 06:35 |
| pitti | calc: do you get that every time you boot a live system, or just seldomly? | 06:35 |
| * pitti hugs dholbach | 06:36 | |
| * dholbach hugs pitti back :) | 06:36 | |
| dholbach | there's lots of good stuff still in the sponsoring queue | 06:38 |
| slangasek | pitti: spiff; let me know if there's anything you think should be changed about it, I don't really understand how things are meant to split between hal vs. hal-info and policy vs. information vs. preprobe | 06:42 |
| pitti | slangasek: what sets the sony-nvidia method? | 06:46 |
| slangasek | pitti: it's set in the added fdi file; that got committed, right? | 06:47 |
| pitti | slangasek: ah, I see it now; odd, that got dropped from the patch attachment in the merge request email | 06:47 |
| slangasek | ah, no | 06:48 |
| slangasek | the merge request mail went out before I committed that part | 06:48 |
| slangasek | (at that point, I was thinking perhaps it belonged in hal-info instead of hal) | 06:48 |
| pitti | slangasek: ideally the fdi file should be in smartdimmer | 06:48 |
| pitti | but hal-info is also okay | 06:48 |
| slangasek | but not hal? | 06:48 |
| slangasek | most 'policy' stuff of this sort seems to be in hal | 06:49 |
| slangasek | as I said, I don't understand how things are actually divided | 06:49 |
| pitti | hal-info has the hardware specific lists | 06:49 |
| pitti | slangasek: but either way, if that's for beta, let's leave it like it is | 06:49 |
| slangasek | then why is 10-dell-laptop-brightness.fdi in hal? :) | 06:49 |
| pitti | slangasek: but that needs to be discussed upstream first, I don't want to just commit those patches upstream | 06:50 |
| slangasek | sure | 06:50 |
| slangasek | I don't mind moving it to hal-info; not knowing which package it belongs in was part of why I sent the merge request | 06:50 |
| slangasek | (or to smartdimmer, either) | 06:50 |
| pitti | slangasek: indeed 10-dell-laptop-brightness.fdi is weird; it's not a vendor/product list, but rather a kludge (it will disappear with kernel 2.6.29) | 06:51 |
| slangasek | ah | 06:51 |
| pitti | slangasek: don't waste too much work on it; we can clean it up after beta, when it got discussed upstream | 06:51 |
| pitti | slangasek: I'm happy to upload this now | 06:51 |
| slangasek | also, are the fdi files parsed in alphabetical order? If so we may need to rename this file, so that it sorts before 10-laptop-panel-mgmt-policy.fdi | 06:51 |
| pitti | slangasek: they are | 06:52 |
| slangasek | ok, then we need a different name for this file | 06:52 |
| slangasek | hmm, I think | 06:52 |
| pitti | slangasek: shouldn't make a difference, though? since you use <merge>, i. e. the device will get all access methods anyway? | 06:52 |
| slangasek | oh, right | 06:52 |
| slangasek | yeah, doesn't matter after all | 06:52 |
| pitti | slangasek: if you change keys, the last change wins, not the first change | 06:53 |
| slangasek | sure | 06:53 |
| pitti | so sorting after sounds right | 06:53 |
| slangasek | I was concerned that laptop-panel-mgmt-policy was doing things that were conditional on the keys we set in this new fdi | 06:53 |
| slangasek | but it doesn't, it just cares that access_method != "custom" | 06:53 |
| slangasek | feel free to upload, then - I actually wasn't expecting all the pieces to come together until after beta, since there's an MIR involved also | 06:54 |
| pitti | slangasek: how urgent is the upload? do you need it right now, or can I have another hour or so for bug 322798? | 06:54 |
| ubottu | Launchpad bug 322798 in hal "Segfault in hald startup (hald/linux/devices.c)" [High,In progress] https://launchpad.net/bugs/322798 | 06:54 |
| pitti | slangasek: it has a patch, but I'd like to go through it with a fine comb first | 06:55 |
| slangasek | speaking of which, could you review bug #95444 for me? (FFe request for nvclock, which motu-release punted back to ubuntu-release due to the MIR) | 06:55 |
| ubottu | Launchpad bug 95444 in nvclock "No Screen Backlight Control; Notebooks (Vaio, Macbook, HP/Compaq, Samsung, Zepto et al.) with Nvidia Geforce8/Geforce9/Quadro series graphics" [Undecided,Confirmed] https://launchpad.net/bugs/95444 | 06:55 |
| slangasek | pitti: not urgent at all | 06:55 |
| pitti | okay, great | 06:55 |
| pitti | slangasek: so the acpi-support task should be wontfix then? | 06:56 |
| slangasek | if there's agreement to move forward, yes | 06:57 |
| slangasek | siretart: you could've reuploaded ffmpeg-debian with the same version number and asked for the first to be killed from the unapproved queue ;) | 07:00 |
| pitti | slangasek: I'm a bit confused; your hal patch adds a dependency to smartdimmer, and there you need a newer nvclock which talks about obsoleting the smartdimmer package and include its own smartdimmer program? | 07:01 |
| slangasek | pitti: plan goes like this: 1) newer nvclock, 2) MIR, 3) make nvclock start building the smartdimmer binary package from the new source, 4) profit | 07:02 |
| slangasek | pitti: I may have said something different in a bug log at an earlier point, but that's the current plan | 07:03 |
| pitti | slangasek: ah, I see | 07:06 |
| pitti | slangasek: reviewed and comment added; looks fine to me, modulo the Encoding= line from the .desktop file | 07:09 |
| pitti | oh, buildds are langpack'ed | 07:11 |
| pitti | slangasek: on a tangent, new langpacks won't help CD downsizing; the update packs replace -base, thus there should never be duplicate files on the live system | 07:11 |
| slangasek | yeah; I accepted those ASAP to try to get them through for beta | 07:11 |
| slangasek | hmm | 07:11 |
| slangasek | well, maybe that's why only alternates are currently oversized :) | 07:12 |
| slangasek | er, except i386 desktop is also oversized, darn | 07:12 |
| slangasek | still, that's only 1 ISO to worry about shrinking, instead of all 4 | 07:13 |
| slangasek | pitti: the .desktop file isn't shipped in the package; ok to punt on that change? | 07:14 |
| pitti | slangasek: fine | 07:15 |
| Nafallo | slangasek: except I had a gdm screen waiting this morning :-/ | 07:16 |
| slangasek | Nafallo: aha; so doesn't appear to be toolchain-related after all | 07:17 |
| slangasek | Nafallo: do you have a useful backtrace in your gdm.log? | 07:17 |
| slangasek | er, s/\./ / | 07:17 |
| * Nafallo installs pastebinit | 07:23 | |
| Nafallo | slangasek: http://paste.ubuntu.com/135876/ | 07:25 |
| pitti | slangasek: oh, seems we need to keep the hal patch as Ubuntu specific for now, see mjg59's response to http://lists.freedesktop.org/pipermail/hal/2009-January/012858.html | 07:31 |
| slangasek | pitti: yes, not surprising, this ultimately should be a sensible sysfs interface | 07:33 |
| pitti | slangasek: oh, and the patch doesn't cause the fdi to actually be installed; I'll fix that | 07:33 |
| slangasek | oh | 07:33 |
| slangasek | ok | 07:33 |
| slangasek | didn't realize there was an explicit list, sorry :) | 07:33 |
| slangasek | the comment about sony-laptop providing a backlight interface worries me slightly; I hope this change isn't a regression for users of any of these models who don't have smartdimmer installed | 07:34 |
| pitti | slangasek: explicit list> welcome to automadness :/ | 07:34 |
| slangasek | :) | 07:34 |
| * Nafallo heads in for breakfast and data centres | 07:40 | |
| pitti | slangasek: hal uploaded; the other patch I was talking about was already in | 07:48 |
| === thekorn_ is now known as thekorn | ||
| dholbach | bryce: around? do you know the state of the x11proto-xext libxi-dev depends discussion? | 07:54 |
| dholbach | seems that libvncserver (bug 346836) and libxtst (bug 346841) FTBFS because of that | 07:54 |
| ubottu | Launchpad bug 346836 in libvncserver "FTBFS in jaunty" [Undecided,New] https://launchpad.net/bugs/346836 | 07:54 |
| ubottu | Launchpad bug 346841 in libxtst "FTBFS in jaunty" [Undecided,New] https://launchpad.net/bugs/346841 | 07:54 |
| dholbach | bryce: debian bug 499858 is still open | 07:55 |
| ubottu | Debian bug 499858 in x11proto-xext-dev "x11proto-xext-dev: Missing libxi-dev dependency" [Important,Open] http://bugs.debian.org/499858 | 07:55 |
| dholbach | (and the patch in there says "libx1-dev" instead of "libxi-dev" :)) | 07:55 |
| slangasek | Nafallo: aha, your backtrace matches mdz's latest - very promising progress | 08:01 |
| slangasek | hmm, only the inner part matches | 08:02 |
| slangasek | but this could mean it's a bug in the logging routines themselves... | 08:02 |
| dholbach | bryce: nevermind, just read up on the situation | 08:02 |
| slangasek | Nafallo: would appreciate it if you could post that backtrace to bug #328035 | 08:10 |
| ubottu | Launchpad bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] https://launchpad.net/bugs/328035 | 08:10 |
| === crdlb_ is now known as crdlb | ||
| * NCommander wonders if debian-cd comes with instructions ... | 08:29 | |
| slangasek | Nafallo: how do you feel about running your X under valgrind, btw? :) | 08:33 |
| slangasek | your crash seems to happen at the exact point that mine did before; I can't see any bugs in the actual log handling code, so it looks like it's external heap corruption | 08:34 |
| pitti | Nafallo, slangasek: I just encountered an X.org crash after suspend yesterday, is that what you are talking about? (I only got some drm:i915 unknown parameter error in dmesg, no xf86Wakeup() call messages) | 08:35 |
| slangasek | pitti: that matches the high-level description of the bug, yes. | 08:35 |
| slangasek | pitti: check gdm log for the glibc backtrace | 08:36 |
| slangasek | (it's SIGABORT on heap corruption, so no apport love) | 08:36 |
| slangasek | er, SIGABRT rather | 08:36 |
| slangasek | pitti: bug #328035, targeted for jaunty but we don't have any real traction on it yet | 08:37 |
| ubottu | Launchpad bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] https://launchpad.net/bugs/328035 | 08:37 |
| pitti | [ 30.805891] (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70. | 08:37 |
| pitti | I have a ton of those | 08:37 |
| pitti | but none of xf86Wakeup | 08:37 |
| * pitti checks the bug | 08:37 | |
| pitti | slangasek: thanks | 08:37 |
| slangasek | which version of xserver-xorg-core do you have? | 08:38 |
| slangasek | (the fix to have glibc stacktraces dumped to the log was only added in the latest upload) | 08:38 |
| slangasek | hrm, I wonder why iwl3945 is being totally inconsistent today about seeing the APs in the neighborhood | 08:40 |
| pitti | slangasek: 2:1.6.0-0ubuntu4, the one with Kees' patch | 08:41 |
| slangasek | it couldn't see our own AP earlier today when it was sitting right above my head; now it only sees our AP, when there are two others in range | 08:41 |
| slangasek | pitti: ok | 08:41 |
| pitti | hm, but it was only installed yesterday around noon | 08:41 |
| slangasek | ah :) | 08:41 |
| pitti | I'm pretty sure I rebooted after that, though | 08:41 |
| pitti | yep, I did, 5 hours later | 08:42 |
| slangasek | alrighty | 08:42 |
| pitti | and I got the crash this morning | 08:42 |
| pitti | I'll keep this under observation | 08:42 |
| * slangasek nods | 08:42 | |
| * slangasek is going to try to spend some more time today reproducing it again here | 08:43 | |
| slangasek | if I can get the backtrace, I can start fiddling with valgrind | 08:43 |
| pitti | slangasek: do you know enough about NIS to make a call on bug 345137? I'm afraid it's a little outside of my realm | 08:44 |
| ubottu | Launchpad bug 345137 in nis "nis should recommend nscd" [Undecided,New] https://launchpad.net/bugs/345137 | 08:44 |
| slangasek | I know enough about nscd to say that nothing should recommend it ;) | 08:45 |
| NCommander | +1 slangasek | 08:45 |
| slangasek | (to be fair, that's based on earlier versions of nscd... maybe it's saner now) | 08:45 |
| slangasek | pitti: libnss-ldap only Suggests: it; the same is probably appropriate for nis | 08:46 |
| directhex | how about gnscd? | 08:47 |
| directhex | we use it in production, it seems to suffer far less from terminal suck | 08:47 |
| pitti | slangasek: okay, I leave the reply to that to you then :) | 08:48 |
| slangasek | pitti: oh, recommending nscd would also mean a universe -> main promotion | 08:51 |
| pitti | right | 08:51 |
| pitti | it doesn't seem very appropriate to me at this late time, but I know next to nothing about nscd | 08:51 |
| Nafallo | slangasek: sure. can do. | 08:52 |
| Nafallo | slangasek: (posting the output. the valgrind thing I would need hand holding on I reckon ;-)) | 08:53 |
| slangasek | Nafallo: it involves dpkg-divert /usr/bin/X and replacing it with a shell script that exec's valgrind. :) | 08:55 |
| slangasek | (may require setting valgrind suid since X is suid, sigh) | 08:55 |
| slangasek | also: yuck, why is gdm still referencing /usr/X11R6/bin as the path to X | 08:55 |
| directhex | in case you decide to run it on RH7.2? | 08:56 |
| slangasek | Nafallo: valgrind recipe posted, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/328035/comments/34 | 09:13 |
| ubottu | Ubuntu bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] | 09:13 |
| slangasek | (untested, so keep hold of the unwind directions in case the valgrind script breaks your X ;) | 09:13 |
| Nafallo | slangasek: anything else then valgrind needs installing? | 09:15 |
| slangasek | nope | 09:15 |
| Nafallo | Suggested packages: | 09:15 |
| Nafallo | libc6-dbg kcachegrind alleyoop | 09:15 |
| Nafallo | oki :-) | 09:15 |
| slangasek | and since valgrind traps & handles most heap corruption on its own, you probably have to peek in the log after each resume to check if there's anything interesting there | 09:16 |
| slangasek | since chances are X won't crash | 09:16 |
| slangasek | btw, you've used valgrind before, right? You know this is probably going to make X an order of magnitude slower / more memory-intensive? | 09:17 |
| Nafallo | hehe. no. didn't know that :-) | 09:17 |
| slangasek | ah, yeah | 09:17 |
| infinity | *cough* | 09:17 |
| infinity | Yeah, just slightly slower... | 09:17 |
| Nafallo | oh well. let's wait until X crashes so GDM launches the valgrind then :-) | 09:17 |
| slangasek | it has to intercept all heap activity. That's expensive. :) | 09:17 |
| slangasek | TheMuso: this dmraid debdiff is hard to read given that it clobbers previous ubuntu revisions; is this targeted for beta, or should I set it aside for the time being? | 09:26 |
| TheMuso | slangasek: feel free to set it asside, it clobbers Ubuntu revisions because they are in Debian, and due to differing MD5 sums for orig tarballs, its a fake sync. | 09:27 |
| === yofel_ is now known as yofel | ||
| === cjwatson_ is now known as cjwatson | ||
| siretart | slangasek: oh, indeed, well version numbers are cheap, aren't they? ;-) | 09:30 |
| mvo | Riddell: could you please apply http://people.ubuntu.com/~mvo/tmp/desktop-effects-kde_0.4.4.1.debdiff to the bzr tree or give me acccess to the bzr so that I can commit it myself? | 09:35 |
| cjwatson | damn, if it had occurred to me that language packs wouldn't affect desktop CD size, I'd have done something about the latter yesterday | 09:37 |
| slangasek | well, the langpacks took care of alternate CD size nicely in any case | 09:43 |
| agateau_ | asac: ping | 09:43 |
| asac | agateau_: hello | 09:43 |
| agateau_ | asac: I was sent to you because I have troubles connecting to my wifi AP with NM | 09:44 |
| === agateau_ is now known as agateau | ||
| agateau | I am running Jaunty and can connect to my wifi AP manually or with wicd, but not with NM (tried KDE plasmoid and nm-applet) | 09:45 |
| agateau | asac: what's the best way to give you useful info about this? | 09:46 |
| asac | agateau: a good start is starting your system, trying to connect once and then give me your syslog | 09:48 |
| agateau | asac: ok, going for this | 09:49 |
| agateau | asac: just tried it and realized i did not use the appropriate entry in "Security" combo box. It works now, problem was between keyboard and chair... sorry for the noise :) | 09:58 |
| asac | agateau: is that WEP? | 10:03 |
| mvo | doko: I uploaded a new command-not-found that should suggest "pythonX.Y" now instead of "pythonX.Y-minimal" when "pythonX.Y" is not found | 10:18 |
| doko | nice | 10:19 |
| === azeem_ is now known as azeem | ||
| slangasek | pitti: btw, over the weekend we converted the hal bzr branch to 1.6.1-rich-root instead of the dead-end dirstate-with-subtree; so you may want to redo any local checkouts you have, for a noticeable speed boost. :) | 10:38 |
| pitti | slangasek: I can't, since mine is a branch from an svn checkout | 10:38 |
| pitti | slangasek: well, bzr-svn might have caught up in the most recent version, trying | 10:39 |
| slangasek | 1.6.1-rich-root is specifically one of the formats that can handle bzr-svn | 10:39 |
| slangasek | (getting it there is a PITA though, you can't bzr upgrade you have to bzr init + bzr pull) | 10:39 |
| wgrant | It is the second-latest recommended format for bzr-svn. | 10:39 |
| pitti | bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>. Does not support rich root data. | 10:39 |
| pitti | nope, seems not | 10:40 |
| slangasek | er, see above | 10:40 |
| wgrant | That's not the same error, is it? | 10:40 |
| wgrant | pitti: What command was that? | 10:40 |
| wgrant | bzr upgrade --1.6.1-rich-root | 10:40 |
| pitti | I tried that, but doesn't work either | 10:40 |
| pitti | bzr: ERROR: No repository present: "file:///home/martin/ubuntu/hal/ubuntu/" | 10:40 |
| cjwatson | 10:39 <slangasek> (getting it there is a PITA though, you can't bzr upgrade you have to bzr init + bzr pull) | 10:40 |
| cjwatson | so bzr init --1.6.1-rich-root and then bzr pull into that | 10:40 |
| pitti | oops, the previous attempt moved .bzr away, sorry | 10:41 |
| slangasek | yeah, it has a habit of doing that :-P | 10:41 |
| pitti | ok, sorry | 10:41 |
| * pitti engages full brain here | 10:41 | |
| slangasek | oh, the :-P wasn't for you, it was at the memory of how many times I had to restore .bzr on the LP branch using lftp the other night :) | 10:42 |
| slangasek | would be nice if bzr were more clever about that | 10:42 |
| * wgrant forgot it did the rich root error, *then* the subtrees error. | 10:42 | |
| pitti | hm, so what's the magic incantation to pull into a freshly init'ed branch? | 10:43 |
| wgrant | bzr pull, oddly enough. | 10:43 |
| wgrant | cd into the new branch, bzr pull from the old one. | 10:44 |
| pitti | oh, interesting; magic.. | 10:44 |
| slangasek | pitti: if you know of any other bzr branches of interest on LP that were made using old bzr-svn (and are therefore using dirstate-with-subtree), feel free to let me know; I seem to be becoming quite practiced at such conversions, perhaps eventually they'll stop being painful :) | 10:46 |
| pitti | slangasek: the only other one I'm aware of is cdbs; but I think that's even older (pack-0.92) | 10:47 |
| pitti | it's again a case where I have debian (bzr-svn) and ubuntu branches, and merge from the former | 10:48 |
| slangasek | ah - pack-0.92 might actually upgrade cleanly | 10:48 |
| pitti | trying | 10:48 |
| slangasek | <nod> | 10:48 |
| slangasek | heh, try it locally first to spare yourself the lftp pain ;) | 10:48 |
| wgrant | pack-0.92 will upgrade to 1.6 fine. | 10:49 |
| pitti | yes, works fine | 10:49 |
| wgrant | pack-0.92 is positively modern compared to dirstate-with-subtree, AFAICT. | 10:49 |
| pitti | unfortunately the upgrade broke merging again | 10:51 |
| pitti | .. but I think that was rather due to the bzr pull in the debian branch | 10:51 |
| pitti | *sigh* | 10:51 |
| pitti | slangasek: I know what you mean; for cdbs I got a "file exists: backup.bzr" | 10:56 |
| pitti | slangasek: (on the remote lp branch) | 10:56 |
| * pitti lftps it away | 10:57 | |
| * slangasek opens evolution for the first time since the font size change and snorts at the ridiculousness | 11:01 | |
| slangasek | asac: this default font size change makes evolution look absurd; is that a known issue on its way to being fixed, or should I be sending screenshots? | 11:05 |
| slangasek | (and does it actually look !absurd in some configuration?) | 11:05 |
| seb128 | slangasek: it does look alright there | 11:06 |
| pitti | it looks fine here, but then again I might have a manual configuration of my font setting | 11:06 |
| pitti | seb128, asac: is there some magic gconftool -R /some/path for resetting font configuration to the factory defaults? | 11:06 |
| directhex | slangasek, can i see a screen? | 11:06 |
| slangasek | seb128, pitti: System -> Preferences -> Appearance -> Fonts -> Application font: 13.333? | 11:07 |
| pitti | hm, that says "10" here | 11:07 |
| pitti | I thought it'd be 10 pt == 13.333 px on my 96 dpi? | 11:08 |
| pitti | erm, I mean s/-R/--recursive-unset/ | 11:08 |
| seb128 | slangasek: http://people.ubuntu.com/~seb128/evo.png | 11:09 |
| seb128 | slangasek: what is stupid looking there? | 11:09 |
| slangasek | seb128: ah; I meant the calendar panel | 11:09 |
| slangasek | (I don't use it for mail) | 11:09 |
| pitti | me too, and it looks fine to me | 11:10 |
| seb128 | the 2 labels in the sidepane could be a tide smaller | 11:10 |
| slangasek | seb128: that's the part that was looking absurd :) | 11:10 |
| seb128 | slangasek: http://people.ubuntu.com/~seb128/evocal.png | 11:10 |
| pitti | ah, is it /desktop/gnome/font_rendering ? | 11:10 |
| asac | slangasek: evolution is known | 11:10 |
| pitti | I assume so | 11:10 |
| seb128 | slangasek: I would not go until calling that absurd | 11:10 |
| asac | slangasek: its the gtkhtml which doesnt honour absolute font sizinbg | 11:11 |
| pitti | and /desktop/gnome/interface/{font_name,document_font_name,...} | 11:11 |
| asac | slangasek: i even have the patches for that, but i am trying to get some feedback on it from pango developer first | 11:11 |
| asac | pitti: yes. i only can give you a command that unsets the individual settings | 11:11 |
| * pitti does gconftool --recursive-unset /desktop/gnome/interface | 11:11 | |
| asac | pitti: lol | 11:11 |
| asac | pitti: metacity title font also needs to be changed to px in the end | 11:12 |
| pitti | slangasek: right, now I get it, too | 11:12 |
| pitti | it's way too big | 11:12 |
| seb128 | I start thinking we should roll back to 96 dpi for jaunty | 11:13 |
| seb128 | that's good we tackle those issues but it's late for this cycle | 11:13 |
| slangasek | er, I'm *at* 96dpi | 11:13 |
| seb128 | we have a good idea on what to do now | 11:13 |
| seb128 | slangasek: well, 96dpi forced and 10pt fonts the intrepid way | 11:13 |
| slangasek | ok | 11:14 |
| seb128 | slangasek: right now we have autodetected dpi and px fonts settings | 11:14 |
| seb128 | and we start discovering all those applications not handling px correctly | 11:14 |
| asac | pitti: slangasek: http://paste.ubuntu.com/135952/ http://paste.ubuntu.com/135953/ | 11:14 |
| seb128 | I think it's late for this cycle we should just roll back getting jaunty stable and rocking with not too many changes as said | 11:14 |
| asac | gtkhtml + evolution patch | 11:14 |
| seb128 | and deal with that early next cycle | 11:14 |
| asac | funnily gtkhtml had all the "point" booleans in place | 11:15 |
| asac | just not implemented | 11:15 |
| slangasek | seb128: this definition of "correctly" is completely wrong, but that's somewhat beside the point | 11:15 |
| seb128 | slangasek: right, let's say applications just don't behave correctly with the current defaults | 11:15 |
| seb128 | or don't look right | 11:15 |
| seb128 | or whatever you call it ;-) | 11:15 |
| pitti | asac: hm, those look backwards somehow | 11:16 |
| asac | pitti: backwards? | 11:16 |
| pitti | IF get_size_is_absolute THEN set_size ELSE set_absolute_size | 11:16 |
| asac | pitti: which line? | 11:16 |
| pitti | asac: I'm not saying that they are wrong, just that they look wird | 11:17 |
| asac | pitti: e-text? | 11:17 |
| pitti | asac: first hunk in http://paste.ubuntu.com/135953/ | 11:17 |
| pitti | yes | 11:17 |
| pitti | second hunk as well | 11:17 |
| seb128 | slangasek: will we get language pack updates for beta? | 11:17 |
| asac | pitti: yeah right. i didnt update my .dsc ;) | 11:17 |
| asac | pitti: in build tree i have !...is_absolute) | 11:18 |
| slangasek | seb128: already happening | 11:18 |
| pitti | asac: ah :) | 11:18 |
| seb128 | slangasek: ok good thanks | 11:18 |
| asac | http://paste.ubuntu.com/135954/ | 11:19 |
| slangasek | cf. https://launchpad.net/ubuntu/+builds?build_text=&build_state=pending :) | 11:19 |
| asac | lets hope that evolution has a clean build system ... updating diff.gz | 11:19 |
| seb128 | asac: "clean"? | 11:20 |
| pitti | asac, slangasek: WDYT about reverting those changes (two gconf key defaults, for font size and 96 dpi) in libgnome for the beta? | 11:20 |
| slangasek | were the gconf key defaults all that was changed? | 11:21 |
| seb128 | yes | 11:21 |
| asac | pitti: yeah go for it. | 11:21 |
| slangasek | and is the intent to add those changes back post-beta? | 11:21 |
| pitti | slangasek: well, there were some application fixes for dynamic size handling; but we can surely keep those | 11:21 |
| seb128 | I would be in favor of staying with 96dpi fixed in jaunty | 11:21 |
| * pitti too | 11:21 | |
| seb128 | we said jaunty would be a stable not disruptive version | 11:21 |
| asac | most issues i found are in gnomea pps | 11:21 |
| seb128 | let's deal with that next cycle | 11:21 |
| pitti | I'd like to get bugs filed for all the issues that popped up and revert for jaunty | 11:21 |
| asac | i will upstream them and let them decide if they take them for .1 | 11:21 |
| asac | yeah | 11:21 |
| asac | next cycle | 11:21 |
| asac | pitti: i have a big list already | 11:22 |
| pitti | but it was a great experiment to learn where work needs to be done, and the issues around it | 11:22 |
| pitti | so it was far from vein | 11:22 |
| seb128 | indeed | 11:22 |
| asac | pitti: i will make super bug out of 345189 | 11:22 |
| pitti | vain, I mean | 11:22 |
| asac | and upstream from there | 11:22 |
| pitti | asac: awesome | 11:22 |
| BUGabundo | asac: I just added to more apps to the bug | 11:22 |
| asac | BUGabundo: thanks! | 11:22 |
| slangasek | then yes, I think reverting this for jaunty is reasonable | 11:22 |
| BUGabundo | UM and OOo | 11:22 |
| asac | ok i can upload it | 11:22 |
| BUGabundo | do all of them need to be upstream? | 11:22 |
| asac | seb128: pitti ^^? | 11:22 |
| seb128 | slangasek: would you accept a fusa upload to add some _() so strings are showed translated before beta? | 11:22 |
| asac | BUGabundo: yes. all needs to be upstreamed | 11:23 |
| seb128 | asac: please do | 11:23 |
| pitti | asac: libgnome you mean? fine from my side, needs slangasek's ack for beta coordination | 11:23 |
| BUGabundo | doing so for OOo then | 11:23 |
| asac | pitti: yeah. i backout the gconf change | 11:23 |
| asac | great | 11:23 |
| slangasek | seb128: hmm, do the translations exist anywhere? | 11:23 |
| pitti | asac: the other one, too? (96 dpi) | 11:23 |
| asac | or well not so great. i would have loved if apps are smarter about font handling ;) | 11:23 |
| asac | pitti: i have no strong opinion about it | 11:23 |
| pitti | asac: yeah, I guess everyone would have.. | 11:23 |
| * BUGabundo would love a peaceful world too | 11:23 | |
| asac | pitti: but maybe that make sense | 11:23 |
| BUGabundo | we can't always get everything | 11:23 |
| seb128 | slangasek: yes, they are translated but some of the call lack _() so the english string is displayed | 11:24 |
| asac | hehe | 11:24 |
| pitti | asac: would it even make sense to have one without the other? | 11:24 |
| directhex | asac, never seen a 200dpi screen? | 11:24 |
| slangasek | seb128: ah - yes, please upload | 11:24 |
| seb128 | slangasek: ok thanks | 11:24 |
| asac | pitti: well. if we keep the dpi detection we see the bug that caused the change of font default ... so i think no | 11:24 |
| asac | directhex: please send me a 200dpi screen | 11:24 |
| dholbach | I was just taking a look at the problem of packages that don't (implicitly or explicitly) build-dep on libxi-dev but include XTest.h somewhere - unrelatedly gthumb and xnee FTBFS, if somebody wants to take a look at them | 11:24 |
| BUGabundo | hihi | 11:24 |
| asac | directhex: we also have a firefox feature we would need to test on screens with higer dpi than 150 | 11:24 |
| pitti | asac: that's what I thought | 11:24 |
| directhex | asac, http://club.vaio.sony.co.uk/clubvaio/gb/en/vaiopseries/page.jsp | 11:24 |
| asac | unfortunately we never found anyone | 11:25 |
| asac | who could test that | 11:25 |
| asac | directhex: well. i think in mozilla bug we also found a monitor with 300 dpi ;) | 11:25 |
| asac | but that was way too expensive ;) | 11:25 |
| BUGabundo | asac: ask on the ML -devel | 11:26 |
| BUGabundo | someone said they had access to those big screens | 11:26 |
| Trewas | the font sizes are currently very ridiculous at least when running in virtualbox, "echo $COLUMNS" in gnome-terminal offers 71 when the window is maximised (with everything at defaults and the maximum available resolution, 800x600) | 11:26 |
| slangasek | Trewas: what does xdpyinfo within vbox show? Sounds like a bug in vbox. | 11:29 |
| directhex | Trewas, oh, what's why my jaunty kvm's consoles look silly | 11:29 |
| Trewas | slangasek: "dimensions: 800x600 pixels (212x159mm), resolution: 96x96 dots per inch" | 11:30 |
| slangasek | ttx: sblim-sfcb> you know that s-s-d option can be specified more simply as '--retry=5'? | 11:31 |
| slangasek | Trewas: ah; I suppose I'm not seeing that on my 96dpi display because I've customized gnome-terminal before now | 11:32 |
| Laney | you only see the full impact of the new fonts on clean installs | 11:33 |
| directhex | or new users? | 11:33 |
| Laney | potentially | 11:34 |
| slangasek | geser: huh, any idea what's going on with the bittorrent upload failure? | 11:34 |
| Laney | well, actually I tried this and it wasn't that bad. Dunno if I changed some system-wide setting | 11:34 |
| * directhex updates his vm | 11:34 | |
| slangasek | Laney: what's the real dpi of your display? | 11:36 |
| slangasek | or do you mean that you get different results for new install vs. new user? | 11:36 |
| Laney | slangasek: I mean I tried it on my laptop and instantly noticed several broken applications, but a dist-upgraded install on my desktop has been fine | 11:37 |
| Laney | so "customisation masks the problems" is my message | 11:37 |
| BUGabundo | slangasek: I had to request asac help to get my system to a similar state of a clean install | 11:37 |
| === ziroday` is now known as ziroday | ||
| \sh | slangasek: is it planned to have a full archive rebuild run for jaunty before RC? | 11:45 |
| asac | libgnome uploaded | 11:46 |
| slangasek | \sh: a rebuild of main is in progress. I don't know whether there are plans to rebuild universe. | 11:46 |
| \sh | cjwatson: bug #346797 I was sitting yesterday and tried to fix it...it needs some more love then just changing the .tab file...and it looks like that /usr/share/i18n/SUPPORTED and /usr/share/iso-codes/*.tab is not in sync after a trivial change ...most of the UI code just breaks... | 11:49 |
| ubottu | Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/346797/+text) | 11:49 |
| === Stskeepz is now known as Stskeeps | ||
| pitti | asac: thanks, accepted | 11:58 |
| ttx | slangasek: I missed that. Thanks for the pointer :) | 12:11 |
| kirkland | any idea why firefox slowed down tremendously after upgrading this weekend? | 12:20 |
| kirkland | it's like it's single threaded, can't do more than one thing at a time | 12:20 |
| directhex | Trewas, okay, i get COLUMNS=91 at 1024x768 in kvm | 12:21 |
| directhex | and 71 at 800x600 | 12:23 |
| dholbach | gthumb and xnee FTBFS, if somebody wants to take a look at them | 12:24 |
| seb128 | we should drop some screensavers | 12:25 |
| seb128 | there is over 7megas of those on the CD | 12:25 |
| seb128 | the skyrocket one taking almost 1.5megas | 12:26 |
| directhex | i agree. who uses screensavers anymore? | 12:27 |
| directhex | drop rss-glx? | 12:27 |
| jcastro | seb128: we should ship like 4 at the most | 12:39 |
| seb128 | right | 12:40 |
| jcastro | the feet, the ubuntu logos, black, and maybe the squares or something | 12:40 |
| seb128 | bah | 12:40 |
| seb128 | doko: when packages are in bzr and you modify those please push the change to bzr too | 12:40 |
| doko | seb128: err, all of these were rebuild-only uploads | 12:46 |
| seb128 | doko: and? | 12:46 |
| seb128 | doko: which means I do bzr pull, do my changes upload and get it rejected because bzr is outdated | 12:46 |
| seb128 | then I've to commit your changes redo the work, etc | 12:47 |
| seb128 | not nice | 12:47 |
| seb128 | it would be better if you could push your changes to bzr too | 12:47 |
| doko | then we should use another version numbering scheme, so that you can do just that | 12:48 |
| seb128 | do what? ignore your upload? | 12:48 |
| doko | yes | 12:50 |
| doko | hopefully we'll get binnmus ... | 12:50 |
| siretart` | seb128: but package uploads to the archive are pushed automatically to package-import.u.c, aren't they? | 12:53 |
| siretart` | 12:53 | |
| siretart` | 12:53 | |
| slangasek | yes, but that's not mergeable with existing package branches | 12:53 |
| seb128 | siretart`: I don't know I don't use package-import | 12:53 |
| siretart` | right, that requires to actually use those branches.. | 12:54 |
| seb128 | I'm wondering if we have an interest to still install gamin by default | 12:55 |
| slangasek | tseliot: what more is happening on bug #320632 between now and beta? | 12:55 |
| seb128 | I don't think anything really use it | 12:55 |
| ubottu | Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632 | 12:55 |
| slangasek | seb128: is everything using inotify now? | 12:55 |
| seb128 | slangasek: yes, at least gio is and I'm not sure what is using libgamin out of libgio-fam which is in universe right now | 12:56 |
| tseliot | slangasek: nothing I guess. I haven't had the time to look at the change mentioned in comment 142. Furthermore if that is the cause of the problem, reverting that change might cause regressions - which is not nice - especially when I don't have the specific piece of hardware affected by the problem. | 13:01 |
| slangasek | tseliot: would it cause regressions relative to intrepid, or just relative to earlier jaunty? | 13:01 |
| tseliot | slangasek: regressions in jaunty since the commit's date is Dec 4 17:16:40 2008 | 13:02 |
| slangasek | tseliot: well, that seems like an acceptable risk; and more acceptable before beta than after, if it's going to happen... | 13:03 |
| cjwatson | \sh: I'll convert it to use the XML files | 13:04 |
| cjwatson | \sh: it's no wonder that things totally break when you use iso_639.tab instead; that's for languages, not countries! | 13:05 |
| tseliot | slangasek: ok, I'll see what I can do. I can't promise anything though as I have a lot of work to do already | 13:05 |
| slangasek | tseliot: understood; thanks | 13:05 |
| \sh | cjwatson: well, I was wondering where the other file was... | 13:13 |
| cjwatson | \sh: /usr/share/xml/iso-codes/iso_3166.xml in a different format. In practice what you're supposed to do nowadays is use isoquery. | 13:17 |
| \sh | cjwatson: ah ok..and I thought iso_639.tab replaced the 1366.tab...my mistake | 13:26 |
| slangasek | lool: bug-buddy changelog shows you dropping then re-adding the Recommends: on gnome-dbg; this still wants to pull a bunch of libraries from universe into main | 13:27 |
| slangasek | lool: can I just drop the recommends again? | 13:27 |
| lool | slangasek: bug-buddy shouldn't be in main | 13:35 |
| lool | slangasek: We drop deps on bug-buddy rather than bug-buddy deps usually | 13:36 |
| slangasek | oh | 13:36 |
| lool | slangasek: I re-added the recommends to avoid a delta on bug-buddy with Debian | 13:36 |
| lool | Debian uses bug-buddy/-dbgs and we use apport/-dbgsyms, so it kind of makes sense to pull -dbg for Debian and bug-buddy usage in general, and to avoid bug-buddy in Ubuntu | 13:36 |
| slangasek | hrm, then what is bug-buddy doing in main in the first place | 13:37 |
| slangasek | meh, seeded on the DVD | 13:37 |
| lool | I wonder why | 13:38 |
| cjwatson | hysterical raisins I imagine | 13:38 |
| slangasek | been seeded for a long time, in fact | 13:38 |
| lool | # included so that upstream GNOME community members can use it | 13:38 |
| cjwatson | the DVD seed was mostly just moved wholesale from the old supported seed | 13:38 |
| * slangasek nods | 13:38 | |
| \sh | kees: pitti: would you like to take care about bug #332025 (it just needs a sync...sec update...cve included) | 13:39 |
| ubottu | Launchpad bug 332025 in uw-imap "Please sync uw-imap 8:2007b~dfsg-1.1 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/332025 | 13:39 |
| \sh | we still have -1 | 13:39 |
| lool | Move bug-buddy from desktop to supported | 13:40 |
| lool | cjwatson: Good catch :) | 13:40 |
| lool | It was Tue 2008-08-26 so not too far awy though | 13:40 |
| slangasek | lool: that's when it was moved to supported from desktop; the addition was much farther back | 13:41 |
| pitti | \sh: ah, ubuntu-archive wasn't subscribed; I did that now | 13:41 |
| slangasek | ArneGoetje, pitti: language-support-translations-cs doesn't appear to Depend on evolution-documentation-cs | 13:42 |
| \sh | pitti: grmpf...right...my fault...I thought kees wanted to have a look about it first as it was a security bug..thx :) | 13:42 |
| lool | haha back in the past bug-buddy was downgraded to a recommends: "Our guiding philosophy should be that the user should be able to remove/replace default applications and documentation as they wish without disturbing the metapackage, while ensuring that essential infrastructure is implied by the metapackage" | 13:42 |
| lool | (just had recent exchange about usplash/plymouth with cjwatson where I wanted to make it a recommends; I guess it boils down to what "essential infrastructure" is) | 13:43 |
| lool | Ok, bug-buddy dates from revision 1 | 13:44 |
| pitti | slangasek, ArneGoetje: ah, it's already in the lists, seems it just wasn't rebuilt; doing | 13:44 |
| lool | So it's definitely old cruft | 13:44 |
| slangasek | lool: and now it's removed cruft :) | 13:44 |
| lool | slangasek: If you care about -dbg, you might want to drop Extra-Include: *-dbg *-debug from supported perhaps? | 13:44 |
| slangasek | 06:20 < cjwatson> slangasek: anything that actually ships a -dbg is either (a) cruft from dbgsym and should go in Extra-Exclude or (b) actually useful due to being a second build pass. IMO anyway ... | 13:45 |
| \sh | cjwatson: pkgsel pkgsel/install-language-support boolean false should avoid any try to install langpacks during preseeding installation, right? or do I need to empty pkgsel/language-pack-patterns ? | 13:45 |
| lool | slangasek: That's an *Include* | 13:45 |
| cjwatson | \sh: the latter | 13:45 |
| slangasek | lool: yes, I know. the above is cjwatson's argument against removing the -Include. | 13:46 |
| cjwatson | I'm not sure it's directly an argument against; it's a maybe | 13:46 |
| slangasek | ok, "response" :) | 13:46 |
| cjwatson | my concern is whether we would miss out on useful debugging facilities | 13:46 |
| lool | Well the python -dbg packages are special infrastructure we use | 13:46 |
| slangasek | the current solution does have the advantage that someone has to look at the -dbg packages (they show up on component-mismatches fairly automatically) | 13:47 |
| pitti | slangasek: l-support-tr-cs uploaded | 13:47 |
| slangasek | ok | 13:47 |
| lool | slangasek: with extra-include? I don't understand why they show up as a mismatch if they are seeded | 13:48 |
| ArneGoetje | pitti: thanks | 13:48 |
| slangasek | lool: because when new ones show up they tend to show up in universe | 13:48 |
| \sh | cjwatson: somehow the documentation from debconf-get-selections --installer is not as obvious as it should be...but I'll learn quickly ,-) | 13:48 |
| slangasek | and get looked at before being promoted | 13:48 |
| lool | I see | 13:48 |
| cjwatson | \sh: it's not supposed to be documentation. Use the installation guide | 13:48 |
| cjwatson | heh, not that this is documented there either | 13:49 |
| \sh | cjwatson: that's what I wanted to say...and when I follow the installation guide, I always end with lang-packs of gnome, openoffice and friends ,-) | 13:49 |
| cjwatson | oh, I improved the logic in jaunty | 13:50 |
| cjwatson | * Fix logic to check whether pkgsel/language-packs has been preseeded. | 13:50 |
| cjwatson | previously preseeding it to the empty string was incorrectly taken to mean "not preseeded" | 13:50 |
| cjwatson | \sh: so this will work in jaunty, but in previous releases you had to use 'd-i pkgsel/install-language-support boolean false'. Sorry for my incorrect statement earlier about pkgsel/language-pack-patterns. | 13:51 |
| cjwatson | \sh: note that it ought to be "d-i" as the first field there, not "pkgsel". | 13:51 |
| Riddell | mvo: desktop-effects-kde committed thanks (you are free to join kubuntu-users yourself of course :) | 13:51 |
| cjwatson | (otherwise you will end up with cruft in your installed system's debconf database) | 13:51 |
| \sh | cjwatson: ok...thx for the heads up :) | 13:51 |
| mvo | Riddell: thanks | 13:52 |
| Riddell | mvo: apport's config file seems to prompt during an upgrade from intrepid http://humboldt.canonical.com/~jriddell/9.04-upgrade/intrepid-upgrade-7.png | 13:53 |
| mvo | Riddell: right, know issue. we can apport during the upgrade and that causes it to prompt, it will go away for the final release | 13:53 |
| Riddell | mvo: ok, another problem was this packagekit crash during the upgrade, bug 347290 | 13:57 |
| ubottu | Bug 347290 on http://launchpad.net/bugs/347290 is private | 13:57 |
| mvo | Riddell: could you make it public please? | 13:57 |
| Riddell | bug 347290 | 13:58 |
| ubottu | Launchpad bug 347290 in packagekit "aptDBUSBackend.py crashed with ImportError in <module>()" [Undecided,New] https://launchpad.net/bugs/347290 | 13:58 |
| Riddell | mvo: fixed | 13:58 |
| Riddell | mvo: it lacks a dependency? | 13:58 |
| mvo | Riddell: maybe - or it was a problem gconf not configured yet | 13:59 |
| Riddell | gconf? surely just python-gobject? | 13:59 |
| mvo | Riddell: eh, right. sorry | 14:00 |
| mvo | Riddell: just to confirm, "fixed" refered to that you fixed it in bzr already? | 14:08 |
| Riddell | mvo: in respect to what? | 14:09 |
| Riddell | mvo: no, the fixed was the bug privacy | 14:09 |
| seb128 | ok | 14:26 |
| seb128 | so we could get libgnomeprint and libgnomeprintui out of the CD quite easily for jaunty if we want | 14:26 |
| seb128 | we just need to split the gnome-python-desktop bindings | 14:27 |
| seb128 | and to look through the archive to what is still using those binding and depends on the binary to those | 14:27 |
| seb128 | do you think it's worth the effort? | 14:27 |
| slangasek | I'm very nervous about splitting those python bindings | 14:28 |
| seb128 | slangasek: why? | 14:28 |
| slangasek | are you going to look through universe/multiverse as well? | 14:28 |
| seb128 | slangasek: | 14:29 |
| seb128 | $ apt-cache rdepends python-gnome2-desktop | wc -l49 | 14:29 |
| seb128 | ups | 14:30 |
| seb128 | -> 49 | 14:30 |
| slangasek | seems like a lot of packages | 14:30 |
| slangasek | do you disagree? | 14:30 |
| seb128 | that's a not too big list, grepping for "import gnomeprint" in this list should be quick enough | 14:30 |
| slangasek | no tar-in-tar that we have to worry about missing in a grep? | 14:30 |
| seb128 | slangasek: 49 sources to get and grep? yes I disagree | 14:30 |
| pitti | Keybuk: cups only sends d-bus signals to the system bus, it doesn't export any interfaces to call; it seems that this doesn't need a dbus config file at all, or am I missing something? | 14:30 |
| seb128 | slangasek: gtksourceview and gnomeprint are deprecated libs for some time and I don't many things are using them | 14:31 |
| seb128 | slangasek: and going through 47 sources manually is not too much work ... but right we can wait next cycle | 14:31 |
| slangasek | seb128: if the number of packages that need to be changed turns out to be sanely small, then I guess I'm ok with that. We will break any third-party packages depending on python-gnome2-desktop and using these libs though | 14:31 |
| Amaranth | looking at that list I can't imagine many of them using libgnomeprint anyway | 14:31 |
| slangasek | seb128: for next cycle, I believe Debian is already working on a transition plan | 14:32 |
| dholbach | seb128: how correct was this list? http://paste.ubuntu.com/136041/ | 14:32 |
| seb128 | slangasek: right, I would just have split those 2 to get the corresponding libs out of the CD for jaunty if we wanted to | 14:32 |
| seb128 | dholbach: it has only things installed on your box but otherwise good ;-) | 14:33 |
| dholbach | seb128: no, that's sources I downloaded | 14:33 |
| seb128 | oh | 14:33 |
| seb128 | should be an accurate summary if there is no tarball in the tarball sources there | 14:34 |
| dholbach | seb128: that's a quote from a discussion we had a few days ago, remembeR? :) | 14:34 |
| seb128 | Installed-Size: 320 | 14:34 |
| seb128 | Installed-Size: 584 | 14:34 |
| seb128 | that's probably not worth the trouble for jaunty | 14:35 |
| slangasek | seb128: yep - which changes the definition of "python-gnome2-desktop" for packages already depending on it. I'm not convinced it's worth it for < 1MB, yeah | 14:35 |
| seb128 | we are not going to move libgnomeprint to universe anyway, abiword still use it | 14:35 |
| dholbach | boooooh! | 14:35 |
| seb128 | slangasek: that's why I suggested to go through the rdepends but let's wait next cycle and do the full split as debian then | 14:35 |
| seb128 | hum | 14:37 |
| seb128 | the respective -datas add over 3megas though | 14:37 |
| seb128 | slangasek: ^ | 14:38 |
| slangasek | hmm | 14:39 |
| slangasek | yes, that would be worth it | 14:39 |
| seb128 | those libs are deprecated for some years and I'm pretty confident few things use them | 14:40 |
| seb128 | I will go through the list but http://paste.ubuntu.com/136041 is basically that | 14:40 |
| * dholbach hugs seb128 | 14:40 | |
| seb128 | gnome-games can be dropped from there they used gnomeprint in sudoku and that has been fixed in svn since | 14:40 |
| * seb128 hugs dholbach | 14:40 | |
| Keybuk | pitti: correct | 14:46 |
| slangasek | dholbach: strange, why is XInput.h not in x11proto-input-dev? | 14:47 |
| Keybuk | though reading the e-mail, Matthew is correct | 14:47 |
| Keybuk | if you *send* signals, you should support introspection | 14:47 |
| Keybuk | thus need a policy to enable it | 14:47 |
| slangasek | dholbach: that seems like the one obvious header to be in a package with that name... | 14:47 |
| === ampelbein is now known as Ampelbein | ||
| dholbach | slangasek: bryce and jcristau might be the best people to talk to about it - I merely stumbled over it during sponsoring | 14:49 |
| seb128 | <jcristau> XInput.h is in x11proto-input-dev in debian still | 14:50 |
| seb128 | from #ubuntu-x earlier | 14:50 |
| slangasek | hmm, so why was it moved? | 14:50 |
| dholbach | or tjaalton: ^ | 14:50 |
| seb128 | slangasek: <tjaalton> it was moved in intrepid because of the input-properties changes, but then upstream moved it back for XI 1.5 | 14:50 |
| seb128 | <tjaalton> so we're just waiting for XI2 and things should be in sync again :) | 14:51 |
| slangasek | hmm | 14:51 |
| seb128 | slangasek: ok, found an another easy 900k | 14:58 |
| slangasek | wow :) | 14:59 |
| seb128 | slangasek: libbonoboui2-common has the html api documentation which should be in -dev | 14:59 |
| seb128 | changing that now | 14:59 |
| maco | trying to slim down packages to make more room on the cd? | 15:00 |
| seb128 | trying to get some extra translations on the CD yes | 15:00 |
| Riddell | mvo: hardy to jaunty upgrade isn't possible? | 15:00 |
| davmor2 | Riddell: hardy .2 | 15:02 |
| davmor2 | or hardy kde4 | 15:02 |
| Riddell | hardy.2 | 15:03 |
| davmor2 | I'll have a play with it after and see if I can do it on ubuntu too | 15:04 |
| mvo | Riddell: not out of the box, I do it for testing sometimes and it seems to work ok | 15:09 |
| Riddell | mvo: well we need it to be possible for Kubuntu | 15:09 |
| mvo | Riddell: oh? could you get into more details? | 15:10 |
| mvo | Riddell: why do you skip intrepid? | 15:11 |
| mvo | Riddell: do you do it for all hardy installs? or just for particular ones (like kde4 installs)? | 15:11 |
| maco | mvo: my guess is "just to see what'll happen" | 15:11 |
| maco | oh missed that line | 15:12 |
| maco | nevermind | 15:12 |
| Riddell | mvo: I'm sure we've talked about this lots. Kubuntu hardy isn't LTS but intrepid was not ready for many users so we turned off the upgrade prompt from hardy, but want it back on so people upgrade before hardy loses support | 15:12 |
| maco | and 4.2 is nice | 15:12 |
| mvo | Riddell: right - what metarelease uri is kubuntu hardy using? | 15:14 |
| Riddell | mvo: http://changelogs.ubuntu.com/meta-release but skipping intrepid | 15:15 |
| mvo | Riddell: or what bzr branch for the kde version of the update-manager download thing (adept I guess?) - so that I can check myself? | 15:15 |
| mvo | Riddell: if you direct me to the hardy version of that tool I check what we need to do | 15:16 |
| Riddell | mvo: it's the DistUpgrade tool that's the problem http://muse.19inch.net/~jr/tmp/jaunty-upgrade-1.png | 15:16 |
| mvo | Riddell: ok - if everything else is settled, I add the support for that now (that should be trivial) | 15:17 |
| mvo | Riddell: sorry for the trouble, it was not on my radar | 15:18 |
| === Ampelbein is now known as ampelbein | ||
| Riddell | mvo: mm, looks like adept is doing the wrong thing anyway, but that's my problem | 15:21 |
| mvo | Riddell: ok, I commited what needs to be done, hopefully that is enough, I do a test kubuntu hardy->jaunty upgrade now | 15:22 |
| === ampelbein is now known as Ampelbein | ||
| slangasek | seb128: hmm, file-roller declares a Vcs-Bzr header pointing to a non-existent branch | 15:31 |
| seb128 | slangasek: right, the product is called fileroller and not file-roller on launchpad and I noticed after upload that I couldn't push due to that | 15:32 |
| seb128 | I wanted to ask somebody if the product name can be fixed but I forgot | 15:32 |
| seb128 | if you need to do a change just upload for now I will fix that later | 15:32 |
| slangasek | ok | 15:33 |
| cjwatson | answers.launchpad.net/launchpad for renaming a project, I think | 15:33 |
| slangasek | it's a missing build-dep on libtool, FWIW, causing a FTBFS | 15:33 |
| seb128 | cjwatson: thanks | 15:34 |
| seb128 | slangasek: weird, it uses cdbs which depends on intltool in ubuntu | 15:34 |
| seb128 | ups, libtool you said | 15:35 |
| seb128 | why does it require libtool? | 15:35 |
| slangasek | for an m4 macro | 15:35 |
| seb128 | that's rather the autoreconf patch which is buggy | 15:35 |
| slangasek | oh? you're meaning to avoid build-time re-confing? | 15:35 |
| seb128 | I guess that's another bug due to a lack of quilt add | 15:35 |
| seb128 | I hate quilt | 15:36 |
| seb128 | slangasek: yes, we autoreconf with known to be working versions to avoid surprises | 15:36 |
| seb128 | so we are sure builds don't break when autotools changes and the new version doesn't work correctly with some old syntax or something | 15:37 |
| slangasek | hm. let me look more closely at this build log; I don't see anything related to the debian/patches | 15:37 |
| seb128 | slangasek: DOH | 15:37 |
| slangasek | configure: WARNING: unrecognized options: --disable-maintainer-mode | 15:37 |
| slangasek | well, that's clever | 15:37 |
| slangasek | seb128: you've seen something? | 15:37 |
| allquixotic | Is anyone else getting broken metacity compositing in the latest devel? I get "Desktop Effects could not be enabled" on Intel i965 hardware. I know it's a bug *in metacity* because xcompmgr correctly composites, even though it doesn't add any effects. When I drag a window on top of an OpenGL window, with xcompmgr there is no damage region (black area) left behind. But there is without. | 15:38 |
| seb128 | slangasek: yes, I forgot the quilt add aclocal.m4 apparently | 15:38 |
| seb128 | slangasek: fixing now | 15:38 |
| slangasek | seb128: ok, I'll leave it to you | 15:38 |
| pitti | quilt becomes even more *headdesk* for newly created files :/ | 15:38 |
| pitti | I spent some 45 minutes last Thursday just on creating a working autoreconf patch with quilt | 15:39 |
| ScottK | But 'everyone' says that quilt is better (for reasons that also escape me) .... | 15:40 |
| ScottK | ;-) | 15:40 |
| seb128 | pitti: I usually change the quilt-patchsys.mk to simple-patchsys.mk use cdbs-edit-patch and switch back | 15:40 |
| slangasek | because it is better, pff | 15:40 |
| slangasek | infidels | 15:40 |
| seb128 | we should really fix cdbs-edit-patch to work with quilt | 15:40 |
| pitti | seb128: ah, nice trick; I quilt push'ed to n-1, copied tree, autoreconf and clean thhere, and diff -Nur > /tmp/patch | 15:40 |
| seb128 | I never know | 15:40 |
| seb128 | but the desktop CD has compression? | 15:41 |
| pitti | ScottK: well, the idea of quilt is nice, in terms of workflow | 15:41 |
| pitti | you have a full tree, can build it, test it, and in the end quilt refresh | 15:41 |
| seb128 | ie the CD space win is the installed size value or not? | 15:41 |
| pitti | but the idea is spoilt by several things which make it absolutely useless, such as quilt add, or not being able to clean cruft | 15:41 |
| seb128 | gnome-games documentation translations = 21megas | 15:41 |
| seb128 | we can split that after beta if we want to win an another locale | 15:41 |
| ScottK | pitti: I agree it has some nice ideas, and I'm kind of getting the hang of it. I just don't find it a panacea for all situations. | 15:42 |
| cjwatson | seb128: the desktop CD is compressed, yes, although the compression is different from .deb compression | 15:42 |
| pitti | ScottK: personally I really like bzr looms, which combine the original "in-place" idea of quilt with sane file handling | 15:42 |
| allquixotic | Oh hmm, `SKIP_CHECKS=yes compiz --replace` works, but regular old `compiz --replace` doesn't. Looks like my card (i965) is no longer on the whitelist after it being on it for 8.10?? | 15:42 |
| cjwatson | seb128: so in general CD space win will be fairly close to .deb size, but not in all situations | 15:42 |
| seb128 | ok | 15:42 |
| cjwatson | seb128: for example duplicate files across packages will probably be compressed better on the live CD than in .debs | 15:42 |
| seb128 | there is no easy way to simulate that I guess | 15:43 |
| seb128 | just use the deb win as a rough estimation | 15:43 |
| slangasek | yep | 15:43 |
| seb128 | thanks | 15:43 |
| pitti | seb128: it's not that rough actually | 15:43 |
| ScottK | pitti: I mostly want to stop having to learn n+1 different patching system/vcs/etc every third time I touch a package. | 15:43 |
| pitti | ScottK: *nod* | 15:43 |
| maco | er allquixotic went away....but er...regular compiz --replace works fine on i965 here. | 15:46 |
| seb128 | bah, I hate symlink handling on upgrade | 15:51 |
| pitti | bdmurray, sbeattie: bug 345953 FYI (IIRC you were involved in cups apport hooks) | 15:51 |
| ubottu | Launchpad bug 345953 in cups "/var/log/cups/* should be adm group readable" [High,Fix committed] https://launchpad.net/bugs/345953 | 15:51 |
| seb128 | so libbnoboui2-common does | 15:52 |
| seb128 | lrwxrwxrwx 1 root root 34 2009-03-23 15:46 /usr/share/gtk-doc/html/libbonoboui -> ../../doc/libbonoboui2-common/html | 15:52 |
| seb128 | what is the right way to replace that by a real directory on upgrade? | 15:52 |
| slangasek | rm the link in the preinst | 15:53 |
| seb128 | ok, ,what I did but using at if -d | 15:53 |
| seb128 | I guess that's not correct because the directory might be removed first and which case the link is not a directory | 15:53 |
| seb128 | hum no, I didn't clean up everything, let's try again | 15:55 |
| sbeattie | pitti: great! | 15:55 |
| geser | slangasek: re the upload failure: checking but I don't have an idea what went wrong. It looks like the upload both failed and succeed (processed twice?). will try to get an answer from LP people | 15:57 |
| slangasek | geser: alrighty | 15:57 |
| geser | slangasek: known bug, cprov is fixing it | 15:59 |
| slangasek | geser: huzzah | 16:00 |
| ogra | could anyone from ubuntu-mir takle a look at bug 345294 | 16:03 |
| ubottu | Launchpad bug 345294 in redboot-imx "MIR for RedBoot-imx" [Undecided,Confirmed] https://launchpad.net/bugs/345294 | 16:03 |
| seb128 | slangasek: libbonoboui uploaded with the documentation installed in the correct binary and file-roller uploaded which should build correctly | 16:14 |
| seb128 | current i386 desktop iso = 698meg == no need to drop the french language pack now? ;-) | 16:17 |
| slangasek | seb128: how much does libbonoboui save us? | 16:17 |
| seb128 | slangasek: 900k of installed files, not sure how much that will be on the CD | 16:17 |
| slangasek | I already kicked pt off to get it to fit; so I'd like to add pt back again if we find the room | 16:17 |
| seb128 | Installed-Size: 1612 | 16:18 |
| seb128 | Installed-Size: 2536 | 16:18 |
| seb128 | slangasek: how much was pt? we didn't win so much space for deskbar-applet + one language pack | 16:19 |
| slangasek | seb128: pt is 7MB; I took pt off and shoved a bunch of other langs on in its place | 16:19 |
| seb128 | ah ok | 16:19 |
| cjwatson | Riddell,mvo: do we need to make the Kubuntu CDs ship an update-manager including hardy-backports rather than intrepid-backports? | 16:20 |
| tkamppeter | pitti, I have added a fix for bug 345183 to the BZR repo of CUPS. | 16:23 |
| ubottu | Launchpad bug 345183 in cups "CUPS, foomatic, & pdftopdf fail when printing more than one copy of an image" [High,Fix committed] https://launchpad.net/bugs/345183 | 16:23 |
| pitti | tkamppeter: ah, thanks | 16:24 |
| pitti | tkamppeter: I'll do an upload after beta; currently discussing bug 318742 still | 16:24 |
| ubottu | Launchpad bug 318742 in cups "D-Bus Policy needs checking" [Low,Incomplete] https://launchpad.net/bugs/318742 | 16:24 |
| Riddell | cjwatson: we have backports on the CDs? | 16:24 |
| mvo | cjwatson: we do not use -backports currently, so it should be ok | 16:24 |
| cjwatson | Riddell: just of dpkg and apt for update-manager | 16:25 |
| cjwatson | mvo: hmm, you don't? why are we wasting CD space with them then? | 16:25 |
| cjwatson | oh, hmm, maybe we aren't :) | 16:25 |
| cjwatson | ok, I'll ignore that problem then | 16:26 |
| cjwatson | Riddell: ok, I guess I'll rephrase, we have the capacity to do so but it's only if there are actually release-upgrader-{apt,dpkg} packages in -backports | 16:26 |
| cjwatson | which apparently there aren't | 16:26 |
| pitti | Keybuk: I'm still confused about cups/dbus; are you saying that cups really ought to provide a real d-bus object, or that a by and large empty (just introspection) d-bus configuration file is necessary? | 16:43 |
| Keybuk | yes | 16:43 |
| Keybuk | you can't just connect to the bus, fire off a signal, and expect everything to be able to catch that | 16:44 |
| pitti | well, that's what cups does right now :/ | 16:44 |
| seb128 | slangasek: ok, so splitting gnome-games documentation would make a 11.6meg deb difference on gnome-games-data | 16:44 |
| seb128 | do we have an estimation of what language packs we could add with that? | 16:44 |
| Keybuk | pitti: right, so it never has a registered bus name | 16:44 |
| pitti | Keybuk: right | 16:45 |
| Keybuk | which means most bindings won't let you match the signal (they expect you to provide the registered bus name) | 16:45 |
| pitti | seb128: I have a script to tell exactly | 16:45 |
| Keybuk | and many of the more modern bindings won't even let you anyway, since they can't introspect the object | 16:45 |
| slangasek | seb128: that might be enough to get French onto amd64 desktop, which doesn't have it right now | 16:45 |
| seb128 | pitti: please do tell me then ;-) | 16:45 |
| pitti | Keybuk: ATM it's just being used by system-config-printer (by the Python bindings) | 16:45 |
| seb128 | slangasek: ok, we will do that after beta then | 16:45 |
| pitti | seb128: we are up to de? | 16:45 |
| slangasek | seb128: excellent | 16:46 |
| Keybuk | pitti: the Python bindings (at least the newer versions) certainly fall into the "difficult to get them to play ball" category | 16:46 |
| seb128 | pitti: something around that I guess, we have de and fr but not pt on I386 now | 16:46 |
| pitti | seb128: pt is 10.5 MB, so we could add that back | 16:46 |
| Keybuk | but if it works now, it works | 16:47 |
| seb128 | I don't want to do too much documentation splitting | 16:47 |
| Keybuk | it just isn't really a useful signal or a well-behaved service :p | 16:47 |
| pitti | seb128: oh, that's probably not true, since my script doesn't count replaced files | 16:47 |
| seb128 | but I guess gnome-games is a good win so we can do this one | 16:47 |
| pitti | seb128: it should be more like 6 MB.. | 16:47 |
| pitti | seb128: ah, if we are talking about the alternate, then it is correct | 16:47 |
| ebroder | Where can I find out why a package isn't synced from Debian? (I'm specifically looking for locales-all, but I'm curious about the process) | 16:47 |
| pitti | seb128: we need to wait for today's langpack builds really | 16:48 |
| seb128 | right | 16:48 |
| pitti | Keybuk: it does | 16:48 |
| seb128 | those changes are for after beta anyway | 16:48 |
| slangasek | pitti: 10.5MB? How do you get a different number than I do? | 16:48 |
| slangasek | (larger by 3MB) | 16:48 |
| pitti | slangasek: that's probably the previous langpack version; apt-get update'ing right now | 16:49 |
| cjwatson | ebroder: if it's a source package, then http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt often has useful comments. However, in this case, locales-all is a binary package that's part of the glibc source package in Debian, so you'd look at glibc's Ubuntu changelog | 16:50 |
| cjwatson | ebroder: and the short answer is because our locale handling is substantially different from Debian's due to the presence of language packs, I imagine | 16:51 |
| ebroder | cjwatson: Yeah, that seems to be the case | 16:51 |
| pochu | should I notify the tech board for regressions in security updates? | 16:51 |
| mvo | calc: do you know anything about #346525 ? | 16:52 |
| calc | mvo: was OOo 2.4.1 before the update? | 16:53 |
| cjwatson | pochu: yes please, although also the security team of course | 16:53 |
| mvo | calc: I don't know but I can ask | 16:53 |
| calc | mvo: there is/was a bug with fontconfig that could cause OOo to die, which has been fixed in 3.0.1 | 16:53 |
| mvo | calc: ok, mind if I reassign to OOo ? | 16:53 |
| calc | mvo: but if they were running 2.4.1 at the time it died that could be expected unfortunately | 16:53 |
| pochu | cjwatson: sure, thank you | 16:53 |
| calc | mvo: it has no backtrace so its really a bug i would just mark invalid unless they could come up with useful information, just a it crashed isn't enough to debug it :\ | 16:54 |
| mvo | calc: ok, I asked for more information for now | 16:55 |
| calc | mvo: ok i followed up to it as well | 16:55 |
| pitti | slangasek, seb128: right; with today's langpacks, pt is 7.11 MB; fr is 4.67 | 16:55 |
| calc | i thought i did but it apparently was a race condition ;-) | 16:55 |
| seb128 | pitti: weird that there is a such difference | 16:56 |
| pitti | seb128: the previous update packs were really big | 16:57 |
| pochu | are there logs for security builds available somewhere? | 16:58 |
| seb128 | ok | 16:58 |
| Riddell | mvo: ping | 17:06 |
| Riddell | mvo: it is your fault after all :) | 17:07 |
| Riddell | mvo: "Date: Thu, 24 April 2009 12:00:00 UTC" in meta-release April should be Apr else QDate won't parse it | 17:07 |
| Riddell | meta-release-development that is | 17:07 |
| tkamppeter | Any Perl exper here? There is bug 346044, which reports a segmentation fault on a Perl program, in exit(). | 17:08 |
| ubottu | Launchpad bug 346044 in foomatic-db-engine "foomatic-ppdfile crashed with SIGSEGV in exit()" [Medium,New] https://launchpad.net/bugs/346044 | 17:08 |
| mvo | Riddell: heh :) | 17:09 |
| mvo | Riddell: ok, will fix that (also I think its a bit unclever that qdate ;) | 17:09 |
| tkamppeter | For me it looks like a bug in the Perl interpreter. | 17:09 |
| kees | pochu: what's the issue you found? | 17:11 |
| pochu | kees: bug 347351 | 17:11 |
| ubottu | Launchpad bug 347351 in wesnoth "wesnoth 1:1.4.5-1ubuntu0.2 english only not italian" [Critical,Triaged] https://launchpad.net/bugs/347351 | 17:11 |
| cjwatson | tkamppeter: certainly a segfault is a bug in C code rather than in Perl code, in general, but it's not necessarily in the interpreter; it could be a memory allocation bug in some XS module that's being loaded | 17:12 |
| cjwatson | tkamppeter: valgrind would probably help to track it down, and it might even be possible to do that without being able to reproduce the segfault directly | 17:13 |
| tkamppeter | cjwatson, what is an XS module? | 17:13 |
| cjwatson | a Perl extension module written in C | 17:14 |
| cjwatson | (approximately) | 17:14 |
| Riddell | mvo: when do you expect to upload update-manager? | 17:14 |
| mvo | Riddell: the meta-releae file is fixed now | 17:15 |
| mvo | Riddell: the update-manager upload, not sure, today? | 17:15 |
| tkamppeter | cjwatson, then I think it is better to move this bug to Perl, so that people working on Perl itself and on general Perl libraries see it. Foomatic does not provide any XS module. | 17:15 |
| cjwatson | probably, yes | 17:15 |
| kees | pochu: uhm, that is very strange. | 17:15 |
| tkamppeter | cjwatson, thanks for the help. | 17:15 |
| kees | pochu: i'll poke at it. | 17:15 |
| Riddell | mvo: let me know when it's in so I can test out the full upgrade process | 17:16 |
| cjwatson | valgrind is not showing up anything particularly scary for me | 17:16 |
| pochu | kees: thanks | 17:16 |
| cjwatson | it's interesting that the stacktrace seems to think the problem is in libcrypt though ... | 17:17 |
| cjwatson | but that could just be the victim | 17:18 |
| mvo | Riddell: I was going over the buglist to look for other low hanging fruits | 17:18 |
| jdstrand | kees: I'd be happy to look at it | 17:24 |
| cjwatson | kees: my guess is that since PPAs are not especially component-aware then maybe translations are being stripped from everything regardless of whether they're in main or not | 17:24 |
| devilsadvocate | ok, i know this is not a question for the dev channel, but can someone tell me what happened to /dev/ttyUSB0 (and why, if thats ok) | 17:24 |
| kees | cjwatson: if that were true, no one has noticed for 6 months. :P | 17:25 |
| kees | cjwatson: I don't think it is, since the security queue uses non-virtual buildds. | 17:25 |
| kees | cjwatson: but we'll check. | 17:25 |
| Pollywog | I notice that in addition to the -dbgsym packages, there are often the -dbg packages and I can find documentation for using the dbg packages. Is there a difference between the two types? | 17:29 |
| maco | Pollywog: dbgsym are only in ddebs and -dbg is in main. i think you can only use one (of a specific package) at a time and ddebs has more of them | 17:30 |
| Pollywog | btw now that I am using the debugging kmail packages, kmail is not crashing | 17:30 |
| maco | either should work fo getting a stacktrace, i think | 17:30 |
| Pollywog | I see | 17:30 |
| Pollywog | thanks | 17:30 |
| Pollywog | and yes the two types seem to be incompatible | 17:30 |
| Pollywog | With some packages, when I run dbg is says there are no debugging symbols, so I wonder if they were correctly built or if I am missing something | 17:31 |
| Pollywog | but kmail-dbgsym seems to be fine | 17:32 |
| LaserJock | -dbg and -dbgsym are created in somewhat different ways but I believe they aim to provide the same thing | 17:33 |
| LaserJock | -dbg packages are included in the source package, and hence could have mistakes | 17:33 |
| Pollywog | LaserJock: ty, I had never heard of the ddebs until recently and I usually compiled my own package with debugging enabled | 17:34 |
| Pollywog | yes I suppose they could have mistakes, I had not thought of that | 17:34 |
| LaserJock | ddebs is created outside of the packaging | 17:35 |
| Pollywog | yes I see that they are :) | 17:35 |
| Pollywog | I just started using them yesterday | 17:35 |
| Pollywog | I will have to wait for this annoying bug to show itself, usually happens when I try to delete a spam | 17:36 |
| Pollywog | a spam that contains an image or html | 17:36 |
| cjwatson | *-dbgsym are automatically created by extracting debugging symbols from packages and stuffing them into a new package. *-dbg are created manually and independently by various packages; sometimes they are essentially the same as *-dbgsym and sometimes they are different (e.g. a different build pass that enables more debugging features in the binary itself). | 17:36 |
| cjwatson | In many cases the reason why there's duplication is that we inherit a lot of the *-dbg packages from Debian, which doesn't have *-dbgsym. | 17:37 |
| Pollywog | cjwatson: I suspected that, since Debian does not have them | 17:37 |
| Pollywog | I have only been using Ubuntu for about 2 yrs, used Debian before that | 17:37 |
| Pollywog | I thought I saw a book in the No Starch series, having to do with Ubuntu, I will have to find out if one exists. Maybe it explains these things | 17:39 |
| Pollywog | There was such a book for Debian | 17:39 |
| Pollywog | but that was several yrs ago | 17:40 |
| === apw is now known as cafetiere | ||
| calc | pitti: i see someone else followed up to bug 325973 seeing it on vmware as well | 17:52 |
| ubottu | Launchpad bug 325973 in nautilus ""Starting File Manager" windows open uncontrollably" [Unknown,Fix released] https://launchpad.net/bugs/325973 | 17:52 |
| pitti | calc: ah, thanks | 17:53 |
| calc | pitti: actually it was in bug 328176 which seems a lot of people are seeing this issue in vmware | 17:53 |
| ubottu | Launchpad bug 328176 in meta-gnome2 ""Starting File Manager" infinite loop after GNOME login (dup-of: 325973)" [Low,Incomplete] https://launchpad.net/bugs/328176 | 17:53 |
| ubottu | Launchpad bug 325973 in nautilus ""Starting File Manager" windows open uncontrollably" [Unknown,Fix released] https://launchpad.net/bugs/325973 | 17:53 |
| calc | pitti: it might be related to the double free bit that was mentioned in the upstream report and i also saw it in .xsession-errors myself | 17:54 |
| pitti | seb128: do you think robert and you can take a look at this this week? ^ | 17:54 |
| calc | repeatedly crashing might cause that same behavior(?) | 17:54 |
| pitti | calc: yes, I think so; if you kill the 'main' nautilus, it'll respawn, and then open a window | 17:54 |
| calc | i haven't tested an i386 cd but on amd64 cd it happens immediately on bootup of the live cd | 17:54 |
| pitti | calc: so in the end it might be a totally different bug which just looks similar in effect | 17:55 |
| calc | pitti: i did ps aux and killed what i saw but it was respawning into infinity anyway | 17:55 |
| calc | it seems something restarts nautilus so there isn't really a main nautilus process | 17:55 |
| calc | pitti: yea it might be a different bug that just looks similar | 17:55 |
| pitti | calc: I mean the process which drives the desktop | 17:55 |
| calc | pitti: ah ok | 17:55 |
| pitti | calc: it's spawned by gnome-session | 17:55 |
| seb128 | pitti: as said this morning we can | 17:56 |
| seb128 | gnome-session restart everything which crash or exit which has autorestart on | 17:56 |
| seb128 | I doubt the issue there is the same | 17:56 |
| calc | i only have a current iso but if it is useful i can try downloading older alphas and see what it starts happening | 17:56 |
| calc | s/what/when/ | 17:56 |
| seb128 | the sjow_desktop one is "nautilus has nothing to do and exit, gnome-session restart it" | 17:56 |
| seb128 | you could start by attaching gdb to nautilus and see if it crashes | 17:57 |
| calc | hmm actually older alphas aren't on the server | 17:57 |
| calc | seb128: nautilus is crashing immediately | 17:57 |
| seb128 | get a stacktrace then | 17:57 |
| calc | seb128: ps aux shows a different process id every time i run it | 17:57 |
| === cafetiere is now known as apw | ||
| calc | seb128: so i need to trace from gnome-session? | 17:58 |
| seb128 | calc: no, open a command line and gdb --pid $(pidof nautilus) | 17:58 |
| pitti | calc: you said "double free bit" | 17:58 |
| seb128 | the double free should show in .xsession-errors | 17:58 |
| pitti | calc: so perhaps there's already a stack trace in the upstream report? | 17:58 |
| seb128 | and I bet it's librasero again | 17:58 |
| calc | pitti: yea i saw a glibc double free error message like is noted in the bug report | 17:58 |
| seb128 | what bug? | 17:59 |
| pitti | calc: it doesn't leave a .crash file behind :( | 17:59 |
| calc | pitti: from what i recall there isn't one in the upstream report | 17:59 |
| pitti | calc: ? | 17:59 |
| * calc looks | 17:59 | |
| seb128 | your issue is a different one | 17:59 |
| seb128 | don't abuse the show_desktop bug please | 17:59 |
| seb128 | yours is not a respawning bug but a crasher | 17:59 |
| calc | it shows up as a respawning bug which is why i added to it | 18:00 |
| seb128 | get me the .xsession-errors but I'm ready to bet it's librasero | 18:00 |
| calc | it spawns huge number of nautilus windows that looked just like that bug report | 18:00 |
| calc | ok i'll boot it up and copy out the xsession-errors | 18:00 |
| calc | http://bugzilla.gnome.org/show_bug.cgi?id=571417#c5 | 18:01 |
| ubottu | Gnome bug 571417 in Navigation "nautilus flips out when show_desktop is unchecked" [Normal,Unconfirmed] | 18:01 |
| pitti | calc: the problem here is that the mechanics of the respawning are exactly the same; just the cause is different (crash vs. nautilus is configured to disable itself) | 18:01 |
| calc | that is similar to what i see wrt .xsession-errors double free | 18:01 |
| pitti | calc: thanks for investigating this, much appreciated! | 18:01 |
| calc | so yea it looks like it is brasero, but i will get the log file | 18:01 |
| calc | seb128: is there another bug number for the brasero issue? | 18:03 |
| calc | ah i see a couple of them | 18:05 |
| Pollywog | I did not know this channel had an Ubottu | 18:05 |
| seb128 | yeah, I've just been reassigning nautilus bugs there | 18:05 |
| Pollywog | is he a twin or the same bot? | 18:05 |
| seb128 | pedro_: ^ maybe you know | 18:05 |
| seb128 | pedro_: seems there is a frequent double free issue is libbrasero | 18:05 |
| seb128 | is -> in | 18:05 |
| calc | yea it is definitely brasero | 18:06 |
| calc | i just looked in the log in more detail | 18:06 |
| calc | its still happening as of mar 22 cd i downloaded | 18:06 |
| seb128 | it will not have changed since | 18:07 |
| calc | ok | 18:07 |
| calc | seb128: do you want my xsession-errors as well it looks essentially the same as bug 335286 but is on amd64 (that bug report is i386) | 18:09 |
| ubottu | Launchpad bug 335286 in brasero "Nautilus - repeated crash/restarts while starting Jaunty LiveCD Alpha5" [Medium,Incomplete] https://launchpad.net/bugs/335286 | 18:09 |
| seb128 | calc: no need | 18:09 |
| calc | ok | 18:10 |
| seb128 | calc: http://bugzilla.gnome.org/show_bug.cgi?id=576439 | 18:11 |
| ubottu | Gnome bug 576439 in libbrasero-media "nautilus crash because of probable double g_free in brasero_medium_get_css_feature" [Critical,Unconfirmed] | 18:11 |
| seb128 | calc: bug #339993 | 18:11 |
| ubottu | Launchpad bug 339993 in brasero ""Starting File Manager" windows open uncontrollably, even when displaying desktop" [Medium,Confirmed] https://launchpad.net/bugs/339993 | 18:11 |
| calc | seb128: is that something that could be fixed before beta, otherwise our call for testing the cd may end up with just lots of duplicates of this issue :\ | 18:12 |
| seb128 | calc: you are welcome to work on the issue since you have the bug on your box | 18:13 |
| seb128 | we didn't get so many duplicates until now and it's not new | 18:13 |
| seb128 | could be configuration specific or something | 18:13 |
| calc | may be just showing up under vmware | 18:13 |
| seb128 | I'm doing CD testing under kvm and I've no such issue | 18:13 |
| * calc is very busy with fixing OOo issues atm so probably can't get to it in time | 18:13 | |
| calc | i found the issue while trying to work on OOo issues actually lol | 18:14 |
| calc | is the line removal in upstream bug report sane? it might cause leaks? | 18:15 |
| seb128 | just move the brasero thing away while you want to get work done | 18:15 |
| seb128 | the upstream bug seems pretty well described | 18:15 |
| seb128 | I added a comment there | 18:15 |
| seb128 | I've no clue about this code I don't work on brasero | 18:15 |
| calc | ok | 18:15 |
| seb128 | let's wait for them to comment | 18:16 |
| calc | ok | 18:16 |
| calc | i'll bbl, about to have a meeting | 18:17 |
| Riddell | mvo: upgrade from hardy seems to work with DistUpgrade from bzr, yay | 18:20 |
| mvo | Riddell: excellent | 18:20 |
| mvo | Riddell: feel free to upload (bzr-buildpackage -S should work fine) - otherwise I do it tomorrow morning (I need to leave now) | 18:21 |
| ebroder | mvo: question about the disable third party sources.list entries bug (I can't find the LP number right now...) | 18:23 |
| ebroder | Will that work for Intrepid -> Jaunty upgrades? Or just upgrades after Jaunty? | 18:23 |
| seb128 | hum | 18:23 |
| ebroder | bug 147080 - there it is | 18:23 |
| ubottu | Launchpad bug 147080 in update-manager-core "do-release-upgrade should make disabling third party repositories optional" [Wishlist,Fix released] https://launchpad.net/bugs/147080 | 18:23 |
| seb128 | current daily still has deskbar-applet why? | 18:26 |
| pitti | seb128: can you check the .manifest whether the current livefs really has the new gnome-applets with the suggest? | 18:30 |
| seb128 | pitti: well the installed version is the new one and apt-cache show lists it as suggest | 18:31 |
| seb128 | where is the .manifest? | 18:31 |
| pitti | http://cdimage.ubuntu.com/daily-live/current/jaunty-desktop-i386.manifest | 18:31 |
| seb128 | yes, it's current | 18:31 |
| seb128 | gnome-applets 2.26.0-0ubuntu3 | 18:31 |
| pitti | hmm | 18:31 |
| seb128 | grep-dctrl -s Package -F Recommends deskbar-applet ... lists nothing else | 18:32 |
| seb128 | and apt-get remove on the liveCD just uninstall it without complain | 18:32 |
| pitti | pitti@rookery:~/seeds/ubuntu.jaunty$ grep deskbar-applet * | 18:32 |
| pitti | dvd: * deskbar-applet | 18:32 |
| pitti | hm, nothing here either | 18:32 |
| LaserJock | cjwatson: if I clean out non-Edubuntu items from edubuntu.jaunty's supported seed will that mess anything up? | 18:34 |
| RainCT | Uhm.. On Jaunty screen dimming doesn't work properly here (this is a regression from Intrepid). If I plug out the cable brightness doesn't change, but if I open gnome-power-preferences it goes down; if I plug it in again, it only changes at the moment I open gnome-power-preferences | 18:34 |
| RainCT | Any idea on this, or should I file a bug (with what info?)? | 18:34 |
| LaserJock | I noticed that it seems to be causing a component mismatch for gcc 4.1 an 4.2 | 18:35 |
| seb128 | pitti: ok, nothing depends or recommends it so I don't know | 18:36 |
| pitti | seb128: it's a mystery to me, too | 18:36 |
| * pitti -> Taekwondo, cu tomorrow | 18:37 | |
| seb128 | pitti: have fun! | 18:37 |
| Pollywog | btw what are "udeb" packages? | 18:39 |
| Pollywog | I have seen them a few times when compiling my own packages | 18:40 |
| seb128 | special debs for the installer | 18:40 |
| Pollywog | they end up in the same directory as my new packages | 18:40 |
| ebroder | "microdebs" | 18:40 |
| Pollywog | oic | 18:40 |
| mdz | pitti: I've filed bug 347457 with a trivial hal-info patch. I assume that you sweep through those and batch them into uploads. If it would be better for me to just upload with this one change, I'm happy to do that instead, just let me know | 18:47 |
| ubottu | Launchpad bug 347457 in hal-info "Should ignore U3 (Windows software) on SanDisk Cruzer Titanium" [Low,Triaged] https://launchpad.net/bugs/347457 | 18:47 |
| imachine | sup, | 18:58 |
| imachine | anyone else experiencing problems with qt apps not respecting dpi? | 18:58 |
| imachine | ever since Jaunty | 18:58 |
| imachine | they respect font, looks, etc. | 18:58 |
| imachine | (I think qt-gtk-engine or whtever it's called, intorduced in 4.5 of qt is in works here) but they don't respect the dpi size for fonts, .i.e, I get slighlty larger fonts with qt apps. | 18:59 |
| imachine | any ideas what might be wrong and where I ought to start looking ? | 18:59 |
| imachine | I don't think it's plainly Ubuntu's faulkt | 19:05 |
| imachine | since if I create a new user, there is no such issue. | 19:06 |
| imachine | any ideas where I could look for this setting? | 19:06 |
| imachine | #gnome? P | 19:06 |
| imachine | ;P | 19:06 |
| Nafallo | imachine: /topic | 19:06 |
| imachine | I've read it. | 19:07 |
| imachine | oh, not fully I guess | 19:07 |
| imachine | so. -bugs huh? | 19:07 |
| imachine | I automatically supposed that if it's jaunty, -devel would be a better palce. | 19:07 |
| imachine | no probs, will try #-bugs | 19:07 |
| Nafallo | imachine: #ubuntu would be a good first one. | 19:08 |
| calc | asac: ping | 19:08 |
| calc | asac: can you look at bug 271283 someone claims this could be fixed in gnome somewhere by setting an option in a file | 19:08 |
| ubottu | Launchpad bug 271283 in openoffice "[ooo-build] OpenOffice.org subpixel font rendering broken with new cairo" [Unknown,Confirmed] https://launchpad.net/bugs/271283 | 19:08 |
| imachine | Nafallo, I guess it's a bit too crowded ;p | 19:08 |
| calc | asac: https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/271283/comments/19 <- that comment in particular | 19:09 |
| ubottu | Ubuntu bug 271283 in openoffice "[ooo-build] OpenOffice.org subpixel font rendering broken with new cairo" [Unknown,Confirmed] | 19:09 |
| seb128 | slangasek: ok, I've been looking through the archive, nothing out of gnome-games sudoku uses python gnomeprint (and that's fixed in svn now) | 19:17 |
| seb128 | slangasek: and only 5 packages use python gtksourceview1 | 19:17 |
| seb128 | slangasek: the gtksourceview split is not worth it, the debs are less than 300k, gnomeprint might be worth doing | 19:18 |
| seb128 | and deskbar-applet is still on the current daily-live for no obvious reason | 19:19 |
| === evalles__ is now known as effie_jayx | ||
| asac | calc: yes. checking | 19:49 |
| calc | asac: thanks | 19:53 |
| asac | calc: is there a trick to svn checkout openoffice? | 19:54 |
| asac | calc: i tried it a few hours ago, but at some point my svn spit out some "XML" errors and then consumed all memory | 19:54 |
| calc | i don't know i normally just use the tarballs | 19:55 |
| asac | heh. ok ;) | 19:55 |
| calc | i haven't checked out OOo in a while, before its conversion to svn | 19:55 |
| asac | calc: ever requested a bzr sync ;)? | 19:55 |
| calc | heh, no | 19:55 |
| asac | calc: so they migrated _this_ year from cvs to svn? | 19:56 |
| asac | calc: is there a cross reference for ooo source with quick searching? | 19:58 |
| === seb128_ is now known as seb128 | ||
| calc | asac: yea migrated this year | 20:06 |
| calc | asac: not sure if there is a cross reference | 20:06 |
| calc | asac: if there is one i don't know about it | 20:07 |
| calc | and searching on google turns up nothing | 20:07 |
| asac | calc: and a web code browser where i can search for functions/strings? | 20:10 |
| calc | asac: not afaik :\ | 20:12 |
| calc | asac: OOo needs to be brought into the 20th century first ;-) | 20:12 |
| calc | before it can catch up with the 21st century ;-) | 20:12 |
| seb128 | cjwatson: any idea why deskbar-applet is still on the current i386 livecd image? | 20:16 |
| === DrKranz is now known as DktrKranz | ||
| === pedro__ is now known as pedro_ | ||
| Laney | world's speediest archive admin! | 20:20 |
| walters | asac: you have tried http://google.com/codesearch, right ? | 20:21 |
| cjwatson | seb128: the most recent livefs builds for both amd64 and i386 seem to have been killed with SIGTERM part-way through. I don't know why | 20:21 |
| cjwatson | infinity: ^- do you? | 20:21 |
| seb128 | cjwatson: the current published iso has it but nothing recommends or depends on it | 20:22 |
| seb128 | cjwatson: ie the manifest and iso have the current gnome-applets which use a Suggests now | 20:22 |
| infinity | cjwatson: What time? | 20:22 |
| seb128 | cjwatson: but deskbar-applet is still on the image | 20:23 |
| cjwatson | seb128: read what I just said :-) | 20:23 |
| infinity | cjwatson: vorlon asked lamont to whack some builds and return terranova/king to a sane state earlier today (4 or 5 hours ago?) | 20:23 |
| cjwatson | seb128: the most recent livefs build, presumably after your gnome-applets change, failed. Therefore the gnome-applets change is not yet reflected in the current image | 20:23 |
| cjwatson | infinity: ah | 20:24 |
| seb128 | cjwatson: ok, the current image has the fixed gnome-applets version when you dpkg -l there though so I though it would reflect the version used for the build | 20:25 |
| * seb128 should learn about cd images build | 20:25 | |
| cjwatson | seb128: strange | 20:27 |
| seb128 | the .manifest on cdimage also list the current version | 20:27 |
| cjwatson | hmm, I mean, you're right, it does | 20:27 |
| cjwatson | but the manifest's date is around the time of http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/ubuntu/20090323.3/ | 20:28 |
| seb128 | ok, let's wait for the next successful build then | 20:29 |
| cjwatson | seb128: ok, I *think* what may have happened is that deskbar-applet wasn't actually being pulled in by the recommendation directly, but because it still had a Task: ubuntu-desktop field in the archive | 20:29 |
| seb128 | we can still investigate if the new build is buggy | 20:29 |
| cjwatson | seb128: due to a design problem in Soyuz, Task fields can take one additional publisher run to settle sometimes | 20:30 |
| cjwatson | so I think that's probably what was going on here | 20:30 |
| seb128 | ah ok, that would make sense | 20:30 |
| seb128 | thanks for the explanation ;-) | 20:30 |
| cjwatson | seb128: sorry for misexplaining earlier | 20:30 |
| cjwatson | I hadn't noticed that gnome-applets was up to date | 20:31 |
| seb128 | cjwatson: that's alright, I was just not sure if I was missing something obvious, it makes sense now ;-) | 20:33 |
| cjwatson | the fix for the Soyuz bug would be to run germinate based on the expected results of publication *before* actually publishing the dists/ tree | 20:36 |
| cjwatson | the basic problem is that the Packages files are an input to germinate, but also germinate's output is an input to Packages file generation | 20:37 |
| cjwatson | so, to decouple this, germinate would need to be fed equivalent data to Packages internally in Soyuz, so that its output could be used to generate the Task fields straight away | 20:38 |
| cjwatson | to make matters slightly worse, changes in germinate's output are not enough to cause Soyuz to treat a pocket as "dirty", so sometimes the subsequent publisher run won't have any effect until you give it a package to publish | 20:39 |
| cjwatson | but, in the meantime, repeated publisher runs and the odd judicious accept are usually enough to work around all the problems | 20:40 |
| seb128 | seems to be some non trivial work | 20:41 |
| seb128 | for little win | 20:41 |
| cjwatson | it is worth it, I think, but not immediately urgently | 20:44 |
| cjwatson | it does result in confusion and wasted time at exactly those times when we're in a rush | 20:44 |
| asac | calc: http://svn.services.openoffice.org/opengrok/xref/ | 20:51 |
| cody-somerville | cjwatson, can you associate https://edge.launchpad.net/germinate/trunk with the correct branch? | 20:52 |
| === kenvandine_wk1 is now known as kenvandine_wk | ||
| cjwatson | cody-somerville: done | 20:56 |
| cody-somerville | thanks | 20:56 |
| calc | asac: cool! thanks for the url | 21:06 |
| calc | asac: that will come in handy for me as well :) | 21:07 |
| calc | asac: unfortunately it doesn't include 3.0.1 but should still be fairly useful | 21:07 |
| kwah | hi all | 21:47 |
| kwah | just got a situation | 21:47 |
| kwah | totem upon running a video file crashes x-server | 21:47 |
| kwah | do not see anything suspicious in the logs | 21:47 |
| kwah | what else can I do to find out the source of problem? | 21:48 |
| kwah | second run on the same file does not reproduce the problem | 21:48 |
| TheMuso | slangasek: that first test build for studio on the tracker is no good, a lot of langpacks are broken. I am suspecting they will sort them out, but will need an ETA for that. | 21:56 |
| TheMuso | to know when we can start testing. | 21:56 |
| TheMuso | ./c | 21:56 |
| bryce | slangasek: Seen http://jasondclinton.livejournal.com/72910.html ? | 22:08 |
| bryce | slangasek: it's been suggested that some of the -intel performance regressions people have complained about might be due to ondemand brokenness rather than X or the video driver as has been assumed... | 22:08 |
| davmor2 | bryce: sorry to bug you but do you know of a way to enable the mouse for a wacom tablet at all. The fix for Intrepid doesn't seem to work for Jaunty. Only I can't find any info on it :( | 22:09 |
| bryce | davmor2: sorry not offhand. tjaalton might know better | 22:10 |
| davmor2 | bryce: Thanks :) | 22:11 |
| davmor2 | tjaalton: was it you I spoke to before? | 22:11 |
| kwah | don't bother... I found bug-report. | 22:11 |
| === maco_ is now known as maco | ||
| === spm_ is now known as spm | ||
| slangasek | TheMuso: is the ubuntustudio-look upload intended for beta? | 23:00 |
| TheMuso | slangasek: yes due to the engine for th theme likely to give weird errors and users reporting bugs otherwise | 23:00 |
| slangasek | bryce: oh argh, ondemand has regressed? :( | 23:02 |
| slangasek | well, I guess that nicely ties together all the complaints about it :P | 23:02 |
| bryce | heh | 23:02 |
| bryce | slangasek: that was just posted to ubuntu-x | 23:02 |
| slangasek | seb128: gnomeprint after beta, then? | 23:02 |
| seb128 | slangasek: if you are fine doing it before jaunty yes | 23:03 |
| seb128 | slangasek: btw any reason we have deb-src sources on the livecd? | 23:03 |
| seb128 | the apt index corresponding takes some space | 23:03 |
| slangasek | I don't know | 23:05 |
| seb128 | the current CD images still have deskbar-applet btw the livefs update didn't work correctly apparently or something | 23:05 |
| seb128 | you will probably win some other megs in the next update | 23:06 |
| slangasek | yep, expecting that :) | 23:06 |
| slangasek | TheMuso: "weird errors" - I guess you mean the warnings that everyone gets on console when starting a gtk app... I don't think that's fixed in the Ubuntu theme yet, even :) | 23:09 |
| TheMuso | slangasek: does the murrine engine get used for the ubuntu theme? | 23:10 |
| slangasek | but that's fine, ubuntustudio needs a reroll anyway and we can afford to wait another hour for ubuntustudio-look to publish | 23:10 |
| slangasek | TheMuso: AIUI the human theme uses it | 23:10 |
| TheMuso | ok | 23:10 |
| bombshelter13 | Where can I get the source for Wubi? Specifically I'm most interested in it's initrd. The wubi site only seems to offer the binary. | 23:21 |
| bombshelter13 | cjwatson: ping | 23:23 |
| IntuitiveNipple | bombshelter13: This any good? https://wiki.ubuntu.com/WubiGuide#Where%20is%20the%20source%20code? | 23:24 |
| === asac_ is now known as asac | ||
| bombshelter13 | That looks promising... now gotta see if I can figure out how they're getting the NTFS partition support in their initrd | 23:25 |
| IntuitiveNipple | bombshelter13: grub4dos/stage2/fsys_ntfx.c | 23:30 |
| IntuitiveNipple | minus the typo :) | 23:30 |
| bombshelter13 | IntuitiveNipple: *looks at that* this could prove useful, actually, I might need it... | 23:32 |
| bombshelter13 | IntuitiveNipple: So they use this to mount the NTFS? Is Fuse/NTFS-3G involved in the process? | 23:32 |
| cjwatson | yes | 23:33 |
| cjwatson | it's basically just the normal Ubuntu initrd | 23:34 |
| cjwatson | the Ubuntu fuse and ntfs-3g packages install the relevant scripts into the initramfs | 23:34 |
| bombshelter13 | Hmm, interesting. I'm trying to implement something with a similar overall purpose, my plan had been to integrate Fuse and NTFS-3g into the initrd and use those to mount the Windows partition..... curious, do you know if that option was considered, and, if so, whether there was a particular reason it was rejected? | 23:36 |
| seb128 | cjwatson: do you know if the deb-src are useful on the livecd? | 23:36 |
| cjwatson | bombshelter13: err ... that's what we do | 23:37 |
| cjwatson | seb128: it's probably OK to remove it | 23:37 |
| cjwatson | seb128: obviously it's useful, it's all relative | 23:37 |
| bombshelter13 | perhaps I misunderstood; I thought you said it was the normal ubuntu initrd? (or are fust and initrd part of the normal ubuntu initrd?) | 23:37 |
| seb128 | I'm not sure how much space we are trying to win in fact, I've just been looking through candidates for some extra space today | 23:38 |
| cjwatson | fuse and ntfs-3g are installed in the standard Ubuntu system, and therefore the scripts they provide are part of the normal Ubuntu initrd | 23:38 |
| seb128 | the source index is 2.7meg | 23:39 |
| bombshelter13 | cjwatson: hmm, i see... i'll have to look into how I can accomplish something similar, I guess. | 23:40 |
| cjwatson | seb128: and compressed? | 23:41 |
| cjwatson | or is that compressed? | 23:41 |
| seb128 | 685k gziped | 23:42 |
| seb128 | not a real win | 23:42 |
| seb128 | I mean it will not win us another language pack and the deb-src can be handy | 23:42 |
| seb128 | ok, I'm done listing obvious targets I think | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
