| directhex | and so it begins | 00:04 |
|---|---|---|
| * lamont wonders if bug 300108 belongs to debconf | 00:24 | |
| ubottu | Launchpad bug 300108 in postfix "during postfix installation i am getting "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process"" [Undecided,New] https://launchpad.net/bugs/300108 | 00:24 |
| directhex | james_w, thanks | 01:00 |
| james_w | directhex: no problem | 01:01 |
| directhex | this is kicking my ass, tbh. 1000 word migration guide going to ubuntu-devel and ubuntu-motu in 3...2...1... | 01:01 |
| directhex | and i still have 5 or so packages to snapshot from packaging svn | 01:02 |
| calc | ugh kino can't do HD :( | 01:16 |
| * calc is really not going to be able to convert his wife to linux between no photoshop and no HD video support :\ | 01:17 | |
| directhex | define "HD video support" | 01:18 |
| calc | directhex: being able to edit video shot in HD | 01:18 |
| calc | directhex: kino squashes into into 4:3 and has no way to keep it as HD afaict | 01:18 |
| calc | s/into/it/ | 01:18 |
| directhex | what kind of editing? | 01:18 |
| calc | pitivi seems like it is still in early dev stage from the webpage at least | 01:19 |
| calc | need to merge multiple cuts, and resize it to export to DVD, etc | 01:19 |
| calc | i can load the file into kino but it messes it up in the process | 01:19 |
| directhex | what kind of windows app is comparable? i mean, i'm pretty sure avidemux can do those kinds of things, but it's pretty much virtualdub for linux | 01:20 |
| calc | at least dvgrab knows how to dump it off the camera, i may be able to convert to linux while using photoshop and premiere in vmware | 01:20 |
| calc | directhex: adobe premiere | 01:20 |
| calc | her current machine is too slow to playback hd video so i was going to attempt to edit it on my system, but it can't load it properly without squashing it into 4:3 | 01:21 |
| cjwatson | lamont: sounds more like user error to me, TBPH - another instance of debconf running somewhere | 01:33 |
| cjwatson | lamont: I don't think it's even possible for the lock to hang around after the process has gone away | 01:33 |
| cjwatson | lamont: I've commented thus in the bug | 01:34 |
| persia | fta, The "unfortunate" nature of the naming is precisely why I suggest early discussion (pre-upload). Given that Google has more marketing leverage than chromium BSU, I suspect an amicable solution is available. Not having that conversation soon can lead to the awkwardness that is epiphany. | 01:40 |
| * directhex names a web browser "firebird" | 01:43 | |
| directhex | no, wait | 01:43 |
| directhex | more than past my bedtime. monodoc and mono-tools can remain unresolved for one night | 01:44 |
| === _Kopfgeldjaeger is now known as Kopfgeldjaeger | ||
| === foka_ is now known as foka | ||
| === anil1 is now known as anilg | ||
| === thegodfather is now known as fabbione | ||
| === Tweenaks is now known as Treenaks | ||
| dholbach | good morning | 06:14 |
| pitti | Good morning | 07:07 |
| NCommander | morning pitti | 07:08 |
| pitti | asac: SRUs> will process, thanks | 07:08 |
| NCommander | pitti, care to sponsor some uploads? | 07:08 |
| pitti | NCommander: sure, I'm happy to; please subscribe me to the bugs and ask for it | 07:08 |
| Hobbsee | morning pitti! | 07:08 |
| NCommander | pitti, one of my changes has a huge debdiff because it has a horribly broken clean rule :-/ | 07:09 |
| === tkamppeter_ is now known as tkamppeter | ||
| NCommander | pitti, https://bugs.edge.launchpad.net/ubuntu/+source/python2.5/+bug/300211 | 07:12 |
| ubottu | Launchpad bug 300211 in python2.5 "Please sponsor a no changes source upload" [Undecided,New] | 07:12 |
| pitti | NCommander: doing ^ | 07:15 |
| NCommander | pitti, score | 07:17 |
| NCommander | pitti, second up is kdelibs. I can post a debdiff, but its somewhat pointless w.r.t. to determining the changes | 07:18 |
| NCommander | (yay for broken clean rules) | 07:18 |
| pitti | NCommander: python uploaded | 07:19 |
| NCommander | Thanks | 07:19 |
| NCommander | pitti, https://bugs.edge.launchpad.net/ubuntu/+source/kdelibs/+bug/299909 | 07:22 |
| ubottu | Launchpad bug 299909 in kdelibs "armel build failure (package not yet in the archive)" [High,Triaged] | 07:22 |
| NCommander | pitti, I ran the patch through filterdiff to just pull out the debian folder bits. | 07:22 |
| pitti | NCommander: looks good; patch-wise; however, I didn't see any fix to the clean rule? | 07:29 |
| NCommander | pitti, I'm not sure how to fix it ATM. | 07:30 |
| NCommander | Lintian not giving any warnings about "patch-system-but-direct-changes-in-diff" | 07:30 |
| NCommander | So probably the last upload fixed the clean rule, but the package itself was dirty | 07:31 |
| pitti | NCommander: indeed, lsdiff -z kdelibs_3.5.10.dfsg.1-1ubuntu1.diff.gz looks horrible | 07:33 |
| NCommander | ubuntu2 isn't much better | 07:33 |
| NCommander | at least locally | 07:33 |
| * NCommander is suprised lintian isn't complaining | 07:33 | |
| pitti | NCommander: well, it looks alright; it's just autoreconf'ed | 07:35 |
| NCommander | ew | 07:35 |
| pitti | that's "buildprep" or so | 07:35 |
| pitti | uploading | 07:35 |
| NCommander | \o/ | 07:36 |
| * NCommander hates inlining | 07:36 | |
| persia | inlining? | 07:36 |
| NCommander | patch inlining in the diff.gz | 07:36 |
| NCommander | maintenance nightmare | 07:36 |
| NCommander | (see gcl for an extreme case, and its 70MB diff.gz) | 07:36 |
| persia | Oh. Well, nightmare for many packages. Saving grace for VCS-managed packages. | 07:37 |
| pitti | NCommander: well, for autoreconf'ing I can understand iti | 07:37 |
| NCommander | pitti, yeah, that's my exception | 07:37 |
| NCommander | If there is no patch system, and a package just needs autoreconf, I'll inline it | 07:37 |
| pitti | keeping the actual code changes in debian/patches, and just doing buildprep instead of keeping the autofoo stuff in patches does make things easier | 07:37 |
| NCommander | Not worth the headache of adding a patch system, then keeping it work | 07:37 |
| persia | pitti, Why not do that at build-time if it is to be done with every upload? The buildd will do it again anyway, if it's part of clean. | 07:37 |
| NCommander | pitti, do you have access to the buildds themselves? | 07:38 |
| pitti | persia: I don't like runtime autoreconf much, because I saw it break far too often | 07:38 |
| NCommander | +1 pitti | 07:38 |
| pitti | persia: but it's common to do that, of course | 07:38 |
| pitti | persia: but that doesn't help to get a clean diff either, unless you have some backup/restore magic | 07:38 |
| pitti | or use a separate build-tree/ | 07:39 |
| persia | pitti, Right, but my point is that auto-reconfing in "clean" is runtime autoreconf anyway, at source time, and binary time. | 07:39 |
| persia | (unless I'm missing something big). | 07:39 |
| persia | So to me it makes sense to either be manual, or to be at build-time. | 07:39 |
| pitti | persia: right, it is for source building; buildds don't run clean | 07:39 |
| persia | Ah. I'm missing something big. | 07:39 |
| * persia tweaks the local sbuild configuration | 07:39 | |
| pitti | NCommander: buildd access> not ssh wise or so | 07:39 |
| pitti | NCommander: I can rescore builds, stop/start buildds, and so on | 07:40 |
| NCommander | pitti, ah, I need someone to kill xvfb on the i386/amd64/lpia builders, and then give-back libgtk2-perl | 07:40 |
| NCommander | to a build admin ^ | 07:40 |
| pitti | NCommander: I can do the give-back, but killing builds isn't possible for buildd admins | 07:40 |
| pitti | it needs root on the buildd, and some dirty trick | 07:40 |
| NCommander | no | 07:40 |
| NCommander | its a process | 07:40 |
| pitti | IOW, elmo, lamont, or infinity | 07:41 |
| pitti | NCommander: why kill? did it get stuck? | 07:41 |
| NCommander | pitti, bug in xvfb on the buildds | 07:41 |
| NCommander | It occessionally hangs | 07:41 |
| pitti | oh, I see | 07:41 |
| pitti | you need one of these three then | 07:41 |
| NCommander | So any build that tries to use xvfb where it hangs also ahngs :-) | 07:41 |
| NCommander | pitti, since we're on the topic, how about a giveback, all architectures kdebindings | 07:42 |
| === jamesh_ is now known as jamesh | ||
| pitti | NCommander: done | 07:43 |
| * NCommander hugs pitti | 07:43 | |
| * pitti hugs NCommander back | 07:43 | |
| NCommander | I'm suddenly inspired to fix more FTBFS | 07:43 |
| pitti | go, NCommander, go! :-) | 07:44 |
| * NCommander notes that desktop should be installable on arm once python lands | 07:45 | |
| NCommander | python-apt might need a binary rebuild | 07:45 |
| NCommander | But other then that ... | 07:45 |
| * NCommander sees how to fix gconf-editor | 07:46 | |
| NCommander | actually | 07:47 |
| NCommander | a giveback might fix it | 07:47 |
| NCommander | ^ - pitti, mind giving back gconf-editor on i386 only? I want to see if it cleared itself, or if my backup fix is needed | 07:47 |
| pitti | done | 07:48 |
| NCommander | pitti, I have a possible fix for an armel FTBFS, but I'm not going to be able to actually test build on that architecture (kde4libs is way too big for my 233Mhz board) | 07:54 |
| NCommander | The previous upload applied the fix and worked, but I missed a single spot which caused the build to die at the very end | 07:54 |
| Hobbsee | directhex: you know, if you want some attention from ubuntu-main-sponsors for https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/300133, you *probably* want to actually subscribe them to the bug ;) | 08:20 |
| ubottu | Launchpad bug 300133 in mono "Mono 2.0.1 package (triggers major packaging transition, please read in full)" [Undecided,New] | 08:20 |
| directhex | Hobbsee, i've intentionally not done so yet, as I still need to reference monodoc and mono-tools in it, and want to avoid crapflooding main-sponsors by commenting on the bug post-ums-subscribe | 08:25 |
| Hobbsee | directhex: ahhh, right, fair enough. | 08:25 |
| directhex | and 2am was not the time to work on those, tbh | 08:26 |
| directhex | mono-tools is blocked by monodoc, so I haven't actually updated it yet in svn | 08:29 |
| directhex | monodoc is... well, short version: monodoc 2.0 as it stands requires mangling of an xml contents page for every doc package. our manglers have been rewritten (but untested) by our main monodoc guy, a dentist who is only online for brief bursts at weekends (making coordination tricky). monodoc 2.2 from svn has dynamic support which we really want, but due to some rearrangements in upstream svn, backporting is a fairly significant p | 08:32 |
| directhex | iece of work. | 08:32 |
| directhex | there's no "best" solution right now, but ideally i need to see where hanska's got with it on friday, and make a decision on whether to upload 2.0 as-is, wait for his 2.2 backports, or do it myself | 08:32 |
| directhex | dholbach, thanks RE libgdiplus | 08:33 |
| directhex | james_w, thanks RE gluezilla | 08:33 |
| directhex | at least gluezilla builds against xulrunner 1.9 (ff3) now instead of 1.8 (ff2). and, helpfully, the upstream author of that lib now hangs about in #debian-mono | 08:35 |
| Hobbsee | ahh | 08:35 |
| directhex | i'm half inclined to make a package of the current, lame, mangly 2.0 for my own use, so I have something to work on a mono-tools package with (mono-tools contains a doc browser, hence the dep) | 08:42 |
| directhex | but not until this evening. day job first. | 08:42 |
| NCommander | pitti, up for another sponsoring? | 09:06 |
| pitti | NCommander: a bit later, yes, please sub me to the bug | 09:06 |
| NCommander | pitti, you got bug | 09:07 |
| pitti | NCommander: uploaded | 09:28 |
| tkamppeter | pitti, hi | 09:36 |
| seb128 | evand: hi, not sure than starting using gnomevfs when it's deprecated is a good idea you should really use gio or gvfs rather | 09:42 |
| evand | seb128: noted, will fix | 09:44 |
| evand | thanks | 09:44 |
| seb128 | you're welcome | 09:44 |
| danigm | hello, i'm trying to run ubuntu debian-installer in a virtual machine with 32MB of ram, but it hangs at "Early unpacking initramfs...", what pkg-list can I remove to make it runnable with 32MB? | 09:51 |
| danigm | with 34MB of ram it runs ok | 09:52 |
| cjwatson | danigm: probably some kernel modules or something | 09:58 |
| cjwatson | danigm: if you're building it yourself and playing with pkg-lists you are welcome to experiment :) | 09:59 |
| tkamppeter | pitti, ping | 10:01 |
| pitti | hi tkamppeter | 10:01 |
| tkamppeter | It is about CUPS and another SRU. | 10:01 |
| tkamppeter | I would like the following bugs SRUed: | 10:02 |
| tkamppeter | - The permission problem of the ipp, http, lpd, and serial backends | 10:02 |
| tkamppeter | - bug 299707 | 10:03 |
| ubottu | Launchpad bug 299707 in cups "Impossible to print in reverse order" [Undecided,Fix committed] https://launchpad.net/bugs/299707 | 10:03 |
| tkamppeter | pitti, note that bug 299707 can have more impact as only making the reverse order not working, like duplicate application of N-up or so. | 10:04 |
| ubottu | Launchpad bug 299707 in cups "Impossible to print in reverse order" [Undecided,Fix committed] https://launchpad.net/bugs/299707 | 10:04 |
| danigm | cjwatson: kernel modules are in pkg-lists also? | 10:04 |
| pitti | tkamppeter: backend permissions are scheduled for SRU already | 10:10 |
| tkamppeter | pitti, great. Bug 299707 is a 1-byte change which fixes a lot of breakage on CUPS options, like N-up, outputorder, page-set, ... | 10:11 |
| ubottu | Launchpad bug 299707 in cups "Impossible to print in reverse order" [Undecided,In progress] https://launchpad.net/bugs/299707 | 10:11 |
| pitti | tkamppeter: that only affects the PDF workflow, right? thus not debian unstable/lenny | 10:12 |
| tkamppeter | It would be nice to SRU this bug together with the backend permissions. | 10:12 |
| pitti | tkamppeter: I added intrepid tasks to all three and assigned to me | 10:12 |
| pitti | will probably do an SRU today | 10:12 |
| tkamppeter | pitti, yes, in Debian it starts only with experimental. Lenny should not contain the cpdftocps filter. | 10:13 |
| tkamppeter | pitti, Saivann Carignan has posted a debdiff for SRUing bug 229346, but I think it is not worth the work, as the bug is only a typo in the package description. | 10:17 |
| ubottu | Launchpad bug 229346 in ddtp-ubuntu "Typo on string 123" [Undecided,Fix committed] https://launchpad.net/bugs/229346 | 10:17 |
| cjwatson | danigm: yes, looking like "foo-modules-${kernel:Version}" | 10:28 |
| === thegodfather is now known as fabbione | ||
| tkamppeter | pitti, ping | 11:00 |
| pitti | please don't ping; just ask | 11:01 |
| pitti | tkamppeter: 229346> can do as part of the other SRU, but not one by itself, yes | 11:01 |
| pitti | tkamppeter: is the Provides: actually depended on by anything? | 11:02 |
| === pedro__ is now known as pedro_ | ||
| tkamppeter | pitti, it is about bug 299542: Mark Purcell from Debian has moved the file /usr/share/pixmaps/HPmenu.xpm from hplip-gui to hplip to satisfy lintian. One release later he has also tried to fix the update conflict, simply adding "Replaces: hplip-gui" to hplip. This still does not work. | 11:10 |
| ubottu | Launchpad bug 299542 in hplip "package hplip 2.8.7-0ubuntu6 failed to install/upgrade: trying to overwrite `/usr/share/pixmaps/HPmenu.xpm', which is also in package hplip-gui" [Undecided,Fix released] https://launchpad.net/bugs/299542 | 11:10 |
| tkamppeter | pitti. ho has it to be done correctly? | 11:10 |
| tkamppeter | If this "Replaces: hplip-gui" in hplip I think it would even happenm that hplip-gui gets uninstalled by the update. | 11:11 |
| tkamppeter | pitti, one thing I forgot, the "Replaces: hplip-gui" is versioned, it is actually "Replaces: hplip-gui (<< 2.8.6.b-2)" | 11:11 |
| pitti | tkamppeter: when was the file moved in Ubuntu? Later than 2.8.6.b-2? | 11:13 |
| pitti | tkamppeter: usually packages like that should Conflicts:/Replace: package-moved-from (<< first-version-which-does-not-have-the-file-any-more) | 11:14 |
| pitti | tkamppeter: just "replaces" eases apt's upgrade ordering, but is slightly less clean on the dpkg level | 11:14 |
| pitti | both are pretty common | 11:14 |
| tkamppeter | In Debian the move happened in 2.8.6.b-2, the "fix" happened in 2.8.6.b-3 | 11:15 |
| pitti | tkamppeter: seems that our 2.8.7-something still had the file in the old location | 11:15 |
| tkamppeter | In Ubuntu it must be 2.8.10-0ubuntu1, as this is the first one after 2.8.6.b-2 | 11:17 |
| tkamppeter | pitti, yes, if you see the debian/changelog our 2.8.7-something is older than Debians 2.8.6.b-2 | 11:18 |
| tkamppeter | But as both do not appear in the same distribution no epoch is needed. | 11:18 |
| tkamppeter | pitti, then I only need to add "Conflicts: hplip-gui (<< 2.8.6.b-2)" to debian/control of hplip? | 11:20 |
| pitti | tkamppeter: no, Replaces: hplip-gui (<< 2.8.10-0ubuntu1), AFAICS | 11:20 |
| MacSlow | Riddell, hey Jonathan | 11:21 |
| tkamppeter | pitti, yes, to cover also the 2.8.7. | 11:22 |
| Riddell | hi MacSlow | 11:22 |
| MacSlow | Riddell, do you happen to know which classes or parts of Qt allow command-line handling (similar to glib's GOption)? | 11:22 |
| MacSlow | Riddell, right now I'm trying poking Qt-reference via that assistant frontend | 11:23 |
| Riddell | MacSlow: I tend to write KDE apps which use KCmdLineArgs, | 11:23 |
| MacSlow | Riddell, ah ok... that's at least a hint I can start with... thanks | 11:23 |
| tkamppeter | pitti, then with "Conflicts: hplip-gui (<< 2.8.10)" and "Replaces: hplip-gui (<< 2.8.10)" all should work for both Debian and Ubuntu? | 11:24 |
| Riddell | http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKCmdLineArgs.html | 11:24 |
| MacSlow | Riddell, thanks! | 11:24 |
| Riddell | MacSlow: pure Qt apps take the command line args as part of the QApplication, but only for the inbuilt Qt arguments (-style -display etc) for your own command line arguments you need to parse them yourself I think http://doc.trolltech.com/4.4/qapplication.html#QApplication | 11:25 |
| MacSlow | ok | 11:25 |
| === jussio1 is now known as jussi01 | ||
| * ogra scratches head | 11:44 | |
| ogra | acpid [i386 amd64] | 11:44 |
| ogra | .... | 11:44 |
| ogra | why would ltsp-client want to install acpid on armel with that dependency line | 11:44 |
| ogra | doko, i dont get it, it shouldnt even try | 11:45 |
| cjwatson | ogra: you're not trying to use [] in Depends, are you? it only works in Build-Depends | 11:45 |
| ogra | oh | 11:45 |
| cjwatson | ogra: if you want architecture-specific dependencies, you have to generate them using substvars | 11:46 |
| ogra | it comes from debian ... | 11:46 |
| ogra | weird | 11:46 |
| cjwatson | the above is true in Debian too | 11:46 |
| cjwatson | unless I'm out of date and they implemented it in dpkg | 11:46 |
| doko | cjwatson: hmm, wasn't this introduced recently? | 11:46 |
| persia | I've seen it a lot in binary Depends though. Seems a common bug, if a bug. | 11:46 |
| ogra | yeah | 11:46 |
| cjwatson | doko: it's possible | 11:49 |
| ogra | it definately works for packages that are only available for one arch | 11:49 |
| cjwatson | if it's implemented, it's at the dpkg-gencontrol level, not at the dpkg level | 11:49 |
| cjwatson | so it almost certainly doesn't work for Architecture: all packages | 11:49 |
| ogra | i.e. ltsp-client-core has " syslinux [i386 amd64], mkelfimage[i386] | yaboot[powerpc] | aboot[alpha] | sparc-utils[sparc]" | 11:49 |
| cjwatson | it probably only works to generate architecture-specific dependencies for architecture-dependent packages | 11:49 |
| cjwatson | ltsp-client-core is architecture-dependent, so I can believe that it would work for it | 11:50 |
| cjwatson | but it won't work for ltsp-client which is Architecture: all | 11:50 |
| ogra | yeah, understood | 11:50 |
| cjwatson | I still regard it as a gotcha because of that and avoid it, although y'all may be right that it has been implemented :) | 11:51 |
| ogra | well, not in dpkg on ubuntu armel it seems :) | 11:52 |
| ogra | else i wouldnt have any prob :) | 11:52 |
| ogra | i can pull it in through other ways though and just drop the hard dep for now | 11:52 |
| ogra | tjaalton, bryce, can either of you take a look at the xserver-xorg-video-savage FTBFS ? it keeps xserver-xorg-video-all uninstallable on armel (it FTBFS on all arches, so seems a general prob, but the others have an old package available) | 12:05 |
| tjaalton | ogra: * Reenable 02_temporary_revert_pciaccess.diff and append all recent pci-rework changes, closes: #483989. | 12:14 |
| tjaalton | ogra: that's why it fails | 12:14 |
| tjaalton | it was autosynced from unstable | 12:14 |
| ogra | ah | 12:15 |
| tjaalton | and unstable doesn't have xserver 1.5 which needs pciaccess | 12:15 |
| tjaalton | +lib | 12:15 |
| * ogra wonders how we will handle that on armel | 12:18 | |
| ogra | where you rarely have a PCI bus | 12:18 |
| directhex | sigh, hate mail. i should get used to this, i suppose | 12:20 |
| Hobbsee | directhex: i was wondering if that was meant in jest. Apparently not. | 12:21 |
| Hobbsee | wow, it's even a known contributor. | 12:21 |
| directhex | oh, he did CC the mailing list in the end then? i was just in To: | 12:21 |
| Hobbsee | directhex: if it was Morten? yes. | 12:22 |
| directhex | aye | 12:22 |
| hyperair | hmm? hate mail about what | 12:22 |
| tjaalton | ogra: I can revert that change so it'll build again | 12:22 |
| directhex | i mean, i'm pretty sure there are those present who disapprove of the work i do for debian/ubuntu (cough), but both debian-legal and SABDFL have made their decisions on the score ni question | 12:23 |
| ogra | tjaalton, that would be great (and unleash a lot of packages for armel) | 12:23 |
| cjwatson | Hobbsee: if somebody is sending hate mail to ubuntu-devel and is on the auto-accept whitelist, please take them out of the whitelist ... | 12:23 |
| Hobbsee | cjwatson: it was to -motu. I checked that first :-S | 12:23 |
| cjwatson | (I didn't see it in the queue, I assume you processed it) | 12:23 |
| cjwatson | oh, ok | 12:23 |
| Hobbsee | cjwatson: but, yes, noted for future reference :) | 12:24 |
| persia | Also, wasn't hate mail towards a person, but towards a piece of software. Still questionable, but not in quite the same class. | 12:25 |
| tjaalton | isn't it ok to hate software, like certain operating systems and such :) | 12:26 |
| directhex | i don't mind hating on apps, i mind "i hate fooapp for spurious reasons, so i want to ban you from contributing free software to ubuntu" | 12:26 |
| * Hobbsee sends the good old "this is not on"-style mail. | 12:27 | |
| tjaalton | directhex: right, didn't read that far :) | 12:28 |
| Hobbsee | directhex: yes, I thought it was in *particularly* poor taste, as it was so completely and totally irrelevant, and really mentioned nothing of use in your mail, apart from the fact that it was mono, and it was being upgraded | 12:28 |
| persia | Yeah. Not an ideal mail, and not aligned with that thread. | 12:28 |
| directhex | yeah. i DO question the kind of thought process that says "i will help save freedom, truth, and justice, by ensuring this IDE remains at 1.0 instead of 2.0. this will cause microsoft corp to go bankrupt. hail eris!". but i'm stepping into ad hominem here, so i'll quit when i'm ahead | 12:29 |
| Hobbsee | persia: maybe do the list a favour, and moderate that thread, and go thru it regularly? I know you're busy though, but mailman is quite fast :-S | 12:29 |
| persia | Hobbsee, Hrm? I'm not a listadmin for that list. | 12:29 |
| Hobbsee | persia: oh, I thought you were, as a member of the MC. | 12:30 |
| persia | Hobbsee, Nope. | 12:30 |
| persia | The set of listadmins for that list is similar to the set of people who are MC, but there are ex-MC who are still listadmin, and current-MC who are not. | 12:31 |
| === veloc1ty_ is now known as veloc1ty | ||
| directhex | on a related note, i've now completed a list of all packages affected by the transition, including versions in sid/exp/jaunty | 12:32 |
| Hobbsee | oh, cool | 12:32 |
| tjaalton | ogra: uploaded | 12:34 |
| * ogra hugs tjaalton | 12:34 | |
| * tjaalton hugs ogra for noticing the prob | 12:34 | |
| tkamppeter | pitti, I have tried with both Replaces: and Conflicts: and get http://pastebin.ubuntu.com/74741/ | 12:38 |
| pitti | tkamppeter: right, that's the bit about "make apt less confused"; I think it works better with apt | 12:38 |
| pitti | tkamppeter: if you drop the conflicts, it should work with dpkg, too | 12:39 |
| pitti | tkamppeter: or you build a local archive with apt-ftparchive packages and use apt-get to upgrade | 12:39 |
| tkamppeter | pitti, with only Conflicts: it is worse: http://pastebin.ubuntu.com/74745/ | 12:40 |
| pitti | tkamppeter: yes, you either need both, or only Replaces | 12:40 |
| pitti | just conflicts will hold back the pacakge | 12:40 |
| tkamppeter | pitti, then I use the version with both and hope that solves the problem. I hope it will not uninstall hplip-gui for all users. | 12:41 |
| tkamppeter | pitti, bad thing is also that Mark Purcell has added a 2.8.6b after my 2.8.7 in the SVN trunk to do an after-freeze update for Debian, instead of branching the SVN for the after-freeze update. | 12:44 |
| pitti | tkamppeter: no, at most they will not upgrade at all | 12:44 |
| pitti | eek, he should have created a lenny branch | 12:44 |
| tkamppeter | pitti, and what to do if it does not upgrade? Is this a bug in dpkg and/or apt which prevents from moving files from one package to another? | 12:45 |
| pitti | tkamppeter: no, it shoudl work; as I said, you can test it with apt-ftparchive and apt-get, but it's really such a standard situation that I'm sure it'll work | 12:46 |
| tkamppeter | pitti, so I will build and upload it with both Replaces: and Conflicts: now. | 12:47 |
| fta2 | persia, i don't see how we can easily solve the naming conflict with chromium. it seems to me that if we do a transition from chromium to chromium-bsc, at least some people with the game installed will end up with the browser | 12:51 |
| tkamppeter | pitti, uploaded. | 12:52 |
| persia | fta, Depends on the plan. Maybe have both chromium-bsc and chromium-browser for a while, and then transition. I just think it's worth having the discussion as early as possible. | 12:53 |
| pitti | tkamppeter: I didn't find any LP bug for debian bug 489045, so I won't SRU it for now | 12:56 |
| ubottu | Debian bug 489045 in cups "cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect" [Grave,Closed] http://bugs.debian.org/489045 | 12:56 |
| tkamppeter | pitti, probably it was never reported to Ubuntu. I got only aware of it through your debian/changelog and I considered it a severe issue which should be fixed in Ubuntu even without a Ubuntu user having hit it. | 12:58 |
| pitti | tkamppeter: right, it's an ugly bug, but very hard to reproduce, and it seems to happen very seldomly | 12:59 |
| pitti | and it's not obviously regression free | 13:00 |
| fta2 | persia, so far, i called the package chromium-browser, and upstream is now aware of that name collision. they didn't give me any direction so far, mostly because they think it's too early to work on packaging, with which i only partially agree. | 13:02 |
| directhex | tada: http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO | 13:06 |
| directhex | your 1-stop reference to the mono packaging migration | 13:06 |
| seb128 | directhex: good work there ;-) | 13:09 |
| directhex | seb128, yeah. perhaps i should do some actual day-job work | 13:09 |
| directhex | waiting on some mails, moaning about suse, it's a hard life | 13:10 |
| seb128 | heh ;-) | 13:10 |
| directhex | got a 500-core cluster i can't use, but hey, that's suse for you | 13:11 |
| persia | fta, OK. When you have some time, it's worth chatting with them. If not, no worries. | 13:11 |
| seb128 | doko: could you explain the change on bug #299911 and why it worked on debian, and do you plan to change your changes to debian too? | 13:20 |
| ubottu | Launchpad bug 299911 in gtksourceview "armel build failure (package not yet in the archive)" [High,Fix released] https://launchpad.net/bugs/299911 | 13:20 |
| doko | regex.h defines these only for __USE_GNU, likely the newer glibc | 13:21 |
| doko | or does debian build with -D_GNU_SOURCE by default? | 13:22 |
| seb128 | doko: ok, could you change the change to debian? they will likely have the same issue and there is no need to create an ubuntu delta | 13:22 |
| seb128 | dunno | 13:22 |
| seb128 | I've no clue about armel | 13:22 |
| * ogra wonders why it isnt in debian | 13:22 | |
| doko | seb128: it's not armel specific, fails on every arch | 13:23 |
| directhex | sniff sniff... glibc 2.8 changes? | 13:23 |
| seb128 | doko: ok, you will send the patch to debian right? | 13:24 |
| doko | seb128: come on, you're our gg ;) | 13:25 |
| seb128 | doko: it's ok for people to upload desktop packages but it's not ok to create extra delta and work for the desktop team without good reason | 13:25 |
| seb128 | either you do the work correctly or you let somebody else do the changes | 13:26 |
| doko | seb128: no, afaik we don't have such a policy, and again, it's needed for armel installabilty. | 13:26 |
| seb128 | I appreciate you want to get armel going, it's not a good reason to quickly upload and let the extra maintainship work to other people then though | 13:27 |
| seb128 | doko: I'm not going to increase my workload you don't want to do things properly, if you don't send that change to debian I'm going to drop it and sync again next time they do a change | 13:33 |
| ogra | anyone with buildd admin power to log in to the buildds directly: libgtk2-perl needs some special hand holding (mainly killing off the running xvfb instance from the last upload) in i386, amd64 and lpia buildds before it can be given back | 13:34 |
| cjwatson | doko,seb128: guys, please, sort this out. (a) doko should send the change to Debian (b) seb128 shouldn't drop changes that haven't been sent to Debian but are still needed. | 13:36 |
| seb128 | well right, but I'm not going to merge the package for doko next cycle if changes are not sent to debian | 13:42 |
| james_w | could a buildd admin please rescore akode/jaunty/armel, I'd like to know if my patch worked sometime this week :-) | 13:52 |
| Hobbsee | james_w: done | 13:58 |
| james_w | thanks Hobbsee | 13:58 |
| Hobbsee | james_w: you're welcome | 13:59 |
| ogra | Hobbsee, do you have ssh access to kill procs on the buildds ? | 13:59 |
| Hobbsee | ogra: uh, no? | 13:59 |
| ogra | sad, ok, seems i need lamont or so | 13:59 |
| Hobbsee | ogra: the only people who have ssh into chinstrap and beyond are canonical employees, and last i checked, i don't work there. | 13:59 |
| cody-somerville | Actually, it isn't even canonical employees :P | 14:00 |
| cody-somerville | Its only the elite IS sysadmins | 14:00 |
| ogra | heh | 14:00 |
| Hobbsee | cody-somerville: well, i did'nt say *where* beyond ;) | 14:00 |
| === thekorn_ is now known as thekorn | ||
| dholbach | can somebody please tell me which value you get for cat /proc/acpi/*/fan | grep speed ? | 14:23 |
| soren | cat: /proc/acpi/*/fan: No such file or directory | 14:23 |
| dholbach | I have /proc/acpi/ibm/fan it might be different for others | 14:24 |
| soren | On all my systems.. | 14:24 |
| dholbach | I'm sorry - I don't know where the fan speed is on other systems - I just wonder if 3867 is not a bit much when the machine is not actually doing much | 14:25 |
| dholbach | I turned up the music already to hear less of the fan, but I'm not sure that's the best solution ;-) | 14:25 |
| tedg | Hmm, my fan only goes on when the screensaver kicks in -- should turn off the fancy GL screensaver :) | 14:26 |
| dholbach | so no numbers from anybody? :) | 14:26 |
| johanbr | The only thing I have named fan anywhere in /proc/acpi is an empty /proc/acpi/fan directory (but my fan works fine). | 14:27 |
| dholbach | looking at the bugs in LP, I guess I can happy that my machine does not overheat :) | 14:27 |
| directhex | what johanbr said. | 14:27 |
| directhex | let me try my laptop | 14:27 |
| dholbach | in the thinkwiki it says you can just put "level 2" into some file and it will throttle down, but I think I prefer "auto" | 14:28 |
| seb128 | dholbach: there is no fan information on my laptop apparently | 14:28 |
| persia | dholbach, I've previously had speeds from 300 to 8000, depending on fan size and heat. | 14:29 |
| directhex | nothing on the laptop | 14:30 |
| dholbach | alright, maybe I'll just ask in #ubuntu-kernel :) | 14:30 |
| doko | james_w: I don't know why it fails on armel, but not on the other architectures | 14:34 |
| james_w | doko: akode? | 14:34 |
| doko | yes | 14:34 |
| james_w | yeah, me neither | 14:34 |
| james_w | it failed again due to a missing header in another file | 14:34 |
| Keybuk | kirkland: any word from Ted? | 14:35 |
| james_w | I don't really want to keep trying to fix it like this, It'd be much more efficient with access to hardware | 14:35 |
| kirkland | Keybuk: nothing in my inbox yet | 14:36 |
| torkel | dholbach: speed:3312 | 14:38 |
| tedg | kirkland: Keybuk: Not me, right? | 14:38 |
| kirkland | tedg: ;-) nope | 14:38 |
| kirkland | tedg: ted tso | 14:38 |
| tedg | kirkland: Okay, just checking I didn't miss a mail. | 14:39 |
| kirkland | Keybuk: i have his cell #, i'll call in a bit, when the west coast is on a reasonable hour | 14:39 |
| kirkland | tedg: well i can't guarantee that :-) | 14:39 |
| dholbach | thanks torkel, so it's probably not too bad | 14:40 |
| lamont | ogra: what process where and did you get it killed already? | 14:41 |
| Mithrandir | james_w: you know qemu can simulate arm, right? | 14:41 |
| ogra | lamont, no i didnt yet, its the old xvfb keeps running for libgtk2-perl builds thingie | 14:41 |
| persia | Mithrandir, The patch for EABI is widely considered somewhat unstable. Do you know of a version that works well for armel? | 14:42 |
| Mithrandir | persia: hm, ok. I didn't play with it | 14:42 |
| * persia has only looked at qemu upstream and qemu-arm-eabi upstream | 14:42 | |
| persia | Mithrandir, For old-ABI, it works just peachy | 14:42 |
| Mithrandir | yeah, but that's not helpful here | 14:43 |
| persia | So Debian "arm" architecture works, but "armel" for either Debian or Ubuntu is less stable. | 14:43 |
| Mithrandir | I guess you could use a chroot on an n810 or something. Slow, though. | 14:43 |
| ogra | lamont, must be on zirconium, palmer and crested if i didnt get that wrong | 14:43 |
| persia | Mithrandir, That's what most of the porters with hardware have been doing. n810, NSLU2, etc. | 14:44 |
| persia | BeagleBoard or GumStix is probably a better choice for speed, but nobody with those has been making much noise. | 14:45 |
| lamont | ogra: nothing looks amiss on zirconium | 14:45 |
| ogra | lamont, well, i'll just try a give-back, lets see | 14:46 |
| lamont | ditto on the other two | 14:46 |
| lamont | the only one I've seen this week is xvfb-run, which needs a bit of identification (next time we hit it, for sure...) | 14:47 |
| ogra | lamont, i just know you had to kill xvfb-run on ppc yesterday, so i wanted to make sure its out of the way before giving back | 14:47 |
| ogra | lpia given back now, lets see | 14:47 |
| * lamont checks all the buildds for xvfb-run | 14:48 | |
| === LucidFox_ is now known as LucidFox | ||
| === kapipi is now known as kapipi_afk_coffe | ||
| === kapipi_afk_coffe is now known as kapipi | ||
| ogra | lamont, looks like libgtk2-perl is just failing on molybdeium | 16:21 |
| ogra | *molybdenum | 16:22 |
| lamont | ogra: if it helps, it's running: /usr/bin/perl -w t/GtkRecentChooser.t | 16:25 |
| lamont | and xvfb-run is in the process tree | 16:25 |
| ogra | well, i only saw the log on LP | 16:25 |
| lamont | so I rather expect that after it finishes failing, there might be some pain left over | 16:25 |
| ogra | and the messages looked similar | 16:25 |
| doko | NCommander: back to zero with kdelibs and kde4libs | 16:30 |
| crweb | what package owns the default ubuntu background and how does it set it to default? | 16:30 |
| _MMA_ | crweb: Its a gconf key I believe. | 16:31 |
| ogra | ../libtool: line 818: X--tag=CC: command not found | 16:32 |
| ogra | ../libtool: line 851: libtool: ignoring unknown tag : command not found | 16:32 |
| ogra | ../libtool: line 818: X--mode=compile: command not found | 16:32 |
| ogra | ../libtool: line 985: *** Warning: inferring the mode of operation is deprecated.: command not found | 16:32 |
| * ogra scratches head | 16:33 | |
| _MMA_ | crweb: Looking at Synaptic should show you what package the background comes from. Either ubuntu-wallpapers or ubuntu-artwork. I forget. | 16:33 |
| doko | persia: please wait with killing sun-java5 in jaunty. there will be one more upload, which I need for -updates in earlier releases. it's easier to do this work in the development version first | 16:34 |
| doko | ogra: wrongly regenerated? | 16:34 |
| ogra | doko, well, i didnt do anything but dpkg-buildpackage -b for gnome-power-manager on armel | 16:35 |
| ogra | it seems to work on x86 | 16:35 |
| * ogra tries again on the faster arch | 16:35 | |
| seb128 | ogra: try running autoreconf to fix the error | 16:38 |
| persia | doko, No rush planned. slytherin will put together a spec, and we'll do a spec review process to make sure all interested parties concur before dropping it. | 16:38 |
| ogra | seb128, hmm, i thought cdbs does that automatically | 16:39 |
| persia | doko, The general goal is just to try to drop it before Jaunty releases, if it's not blocked by something, so as to give fair warning to uses that they have to start migration plans for the next LTS. | 16:39 |
| seb128 | ogra: the cdbs logic is buggy apparently | 16:39 |
| ogra | DEB_AUTO_UPDATE_AUTOCONF = "yes" | 16:39 |
| ogra | ah, k | 16:39 |
| doko | yes, agreed | 16:39 |
| ogra | hrm | 16:39 |
| soren | Keybuk: Do you have an opinion on bug 44194, in particular the fix applied to the udev rules file for ifupdown? | 16:40 |
| ubottu | Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released] https://launchpad.net/bugs/44194 | 16:40 |
| Keybuk | can you provide me a link to the diff you'd like me to look at? | 16:41 |
| soren | Keybuk: The first check in a current (intrepid and jaunty) /etc/udev/rules.d/85-ifupdown.rules. | 16:41 |
| Keybuk | oh, that | 16:42 |
| Keybuk | I saw that, and wondered who'd been taking drugs | 16:42 |
| soren | I'm glad we agree. | 16:42 |
| soren | IMO, what we should do is: | 16:42 |
| soren | Remove it, and make sure that any if-up.d script bails out if it needs rw access to various things. | 16:43 |
| Keybuk | indeed | 16:43 |
| Keybuk | it's perfectly valid to have no rw access at all, ever | 16:43 |
| soren | That way, if stuff just needs basic ifconfig, it works, and everything else gets to get configured later (S40networking) | 16:43 |
| soren | Keybuk: That's also a very good point. | 16:44 |
| soren | Keybuk: So: Remove the patch, thus attempting configuration at interface discovery, and filing bugs against packages with if-*.d scripts that can't deal with this... Sounds like a plan? | 16:47 |
| Keybuk | right | 16:48 |
| Keybuk | but you'd have to fix the underlying wpa_supplicant bug anyway | 16:48 |
| soren | s/you'd/someone would/ :) | 16:49 |
| * soren glances at siretart :) | 16:49 | |
| soren | Keybuk: But great, thanks for your input. | 16:49 |
| kirkland | Keybuk: how do i suspend/hibernate a system from the command line? | 16:52 |
| siretart | soren: sorry? | 16:52 |
| Keybuk | kirkland: pm-suspend ? | 16:53 |
| kirkland | Keybuk: is there a tool, or is it an echo of something to /proc/yada/yada | 16:53 |
| kirkland | Keybuk: thx! | 16:53 |
| soren | siretart: bug 44194 | 16:53 |
| ubottu | Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released] https://launchpad.net/bugs/44194 | 16:53 |
| siretart | oh that one | 16:53 |
| soren | siretart: Read the last 15 minutes of scrollback here for more context. | 16:53 |
| siretart | so you argue that my fix was wrong. correct? | 16:54 |
| soren | Yes. | 16:54 |
| siretart | okay. what's the problem with the fix? | 16:54 |
| soren | It stops interfaces from being configured at discovery time. | 16:55 |
| soren | and that makes me cry. | 16:55 |
| soren | and kittens die. | 16:55 |
| soren | Please. Think of the kittens. | 16:55 |
| siretart | why does that happen? (sorry, I just arrived at my desk and context switching is expensive) | 16:56 |
| Spads | siretart: soren weeps acid tears in the pet shop | 16:57 |
| Spads | siretart: HTH, HAND | 16:57 |
| soren | siretart: Why kittens die? | 16:58 |
| soren | siretart: I stab them. And it's your fault. | 16:58 |
| siretart | soren: why interfaces are no longer configured at discovery time | 16:58 |
| soren | siretart: ah. | 16:58 |
| siretart | soren: without the fix, the interface are not configured at boot time. which I consider worse | 16:58 |
| soren | siretart: Because discovery time is waaay before S40networking. | 16:58 |
| soren | siretart: Why wouldn't they be? | 16:59 |
| siretart | read the bug? | 16:59 |
| siretart | espc. https://bugs.edge.launchpad.net/ubuntu/+source/wpasupplicant/+bug/44194/comments/10 | 16:59 |
| ubottu | Launchpad bug 44194 in netbase "wpasupplicant doesn't start when the network start" [Undecided,Fix released] | 16:59 |
| * soren goes to read it again | 16:59 | |
| soren | I don't see why wpasupplicant's failure to function properly at that time should make everyone else suffer? | 17:00 |
| ogra | and especally the kittens | 17:02 |
| * ogra ha a totally new view of soren now | 17:03 | |
| ogra | *has | 17:03 |
| soren | Hey, it's not that I want to stab them. They just make excellent hostages. | 17:03 |
| robbiew | james_w: do you have a spec/blueprint that I can point to for UDS scheduling purposes? | 17:05 |
| robbiew | james_w: only need a stub | 17:06 |
| * soren goes to dinner | 17:06 | |
| james_w | robbiew: I'll write a stub for you now, sorry. | 17:06 |
| robbiew | james_w: great...thnx :) | 17:07 |
| siretart | soren: damn, university just went offline, I'm now on my mobile via umts | 17:07 |
| siretart | soren: you still did not explain why the patch would break configuration at discovery time | 17:08 |
| siretart | soren: would you please summarize your concerns in a new bug and give me the chance to comment on that? | 17:09 |
| siretart | I need to hurry home now anyways | 17:09 |
| siretart | soren: in short, wpasupplicant won't work before S40networking. I cannot give you the exact details why that doesn't work, but before reverting my change, please investigate that use case first | 17:12 |
| siretart | if you want to fix that, please do so after reverting the change that unbreaks wpasupplicant at boot time. btw, that is the most common way of using wpasupplicant on debian,and I do consider it a very important use case | 17:13 |
| ogra | oh, ekiga magically fixed itself on armel | 17:19 |
| doko | well, not that magically | 17:20 |
| ogra | did you give it back ? | 17:23 |
| ogra | i dont see any upload | 17:23 |
| ogra | ah, the autoreconf on g-p-m seems to have helped | 17:23 |
| ogra | which leaves me with an even more awkward patch ... but it will build on armel | 17:24 |
| kees | pitti: still around? | 17:24 |
| pitti | kees: *wave* | 17:24 |
| james_w | robbiew: https://blueprints.launchpad.net/ubuntu/+spec/distributed-development-debian-import | 17:26 |
| robbiew | james_w: thnx! | 17:26 |
| lore20 | hello | 17:28 |
| lore20 | i'm trying to compile brasero 0.8.3 | 17:28 |
| kees | pitti: cool. say, I've been pondering something slightly crazy, and I wanted to see what you thought of a possible (ab)use of jockey. | 17:28 |
| lore20 | i did "./configure" and "make", without any error | 17:28 |
| kees | pitti: I want to do this: https://blueprints.launchpad.net/ubuntu/+spec/use-pae-when-possible | 17:28 |
| pitti | kees: oh :) shoot | 17:28 |
| lore20 | but when I type "checkinstall --install=no" | 17:28 |
| kees | pitti: basically, we can only fit 1 kernel on the install CD, and as such it needs to be the -generic | 17:29 |
| Riddell | enrico: any idea what causes this in jaunty? debtags.cc:232: error: 'struct ept::core::PackageState' has no member named 'isUpgradable' | 17:29 |
| kees | pitti: however, I want hardware that is PAE-capable to run the -server kernel to get PAE, and therefore "nx" protections. | 17:29 |
| lore20 | I get this error: "/bin/mkdir: cannot create directory `/usr/local/etc/gconf': No such file or directory " | 17:29 |
| ogra | ++for rneaming -server | 17:29 |
| kees | pitti: (jaunty's -server kernel may get renamed to be a more sane name) | 17:29 |
| ogra | *renaming | 17:29 |
| kees | ogra: totally | 17:30 |
| ogra | all my ltsp users switch to -server and are always concerned that its not a deskto kernel | 17:30 |
| lore20 | why? | 17:30 |
| kees | pitti: it's not clear to me yet if this will be possible entirely from the installer, so I was trying to think of a way to have jockey prompt for it | 17:30 |
| ogra | ltsp usually uses >4G | 17:30 |
| kees | ogra: yeah, lots of people have desktops that they run 32bit and wonder where their memory went too. :P | 17:31 |
| ogra | yep | 17:31 |
| lore20 | It can't make a dir cause it doesn't exists? | 17:31 |
| kees | pitti: does jockey already prompt for system reboots when installing restricted drivers? | 17:31 |
| pitti | kees: in principle this is fairly easy to do (write handler which checsk the PAE bit and installs -server if enabled) | 17:32 |
| ogra | lore20, please see /topic | 17:32 |
| pitti | kees: the problem is how to describe and communicate this thing to the user in words they can understand | 17:32 |
| kees | pitti: sure, but that's just a bit of word-smithing. | 17:32 |
| pitti | kees: reboots are not tied to restrictedness, but to the particular handler | 17:32 |
| kees | pitti: I think "use all your memory" and "protect against crackers" would be motivational. | 17:32 |
| pitti | kees: if a handler gets enabled, but detects that it isn't active yet, it is shown as "needs reboot", yes | 17:33 |
| kees | pitti: perfect. | 17:33 |
| enrico | Riddell: that's mornfall's stuff | 17:33 |
| enrico | Riddell: he's probably changed something | 17:33 |
| kees | pitti: another handler I'd like to add then, is one that detects that both -generic and -server are installed, and that -server is booted. to prompt for the removal of -generic. | 17:33 |
| pitti | kees: installer> entirely possible for netboot and DVD, but not CD, yes | 17:33 |
| enrico | Riddell: do you have a link to mornfall? | 17:33 |
| kees | pitti: right. and it's the CD I'm most concerned about. | 17:33 |
| Riddell | enrico: a link to mornfall? he's in #kubuntu-devel dunno if he's at computer | 17:34 |
| kees | pitti: that's the bulk of installs, as well as the fact that jockey will prompt for people that do upgrades. | 17:34 |
| tkamppeter | pitti, for a possible SRU on bug 294671, bug 292257, and bug 298982 I got a patch for the Poppler-based pdftoraster from Koji Otani. I did not ask these people for testing the patch yet, but we could apply it to the -proposed CUPS package and see whether it helps. WDYT? | 17:34 |
| ubottu | Launchpad bug 294671 in gutenprint "Driver reports "ColorSpace is not supported" for Canon iP4500" [Undecided,Fix released] https://launchpad.net/bugs/294671 | 17:34 |
| pitti | kees: why would you want to remove -generic? that rather sounds like system-cleaner | 17:34 |
| ubottu | Launchpad bug 292257 in cups "epson printer d88 (dup-of: 294671)" [Undecided,New] https://launchpad.net/bugs/292257 | 17:34 |
| ubottu | Launchpad bug 298982 in ubuntu "Canon IP 4500 and printing Color (dup-of: 294671)" [Undecided,New] https://launchpad.net/bugs/298982 | 17:34 |
| ogra | wouldnt "last good boot" take care of that ? | 17:34 |
| kees | pitti: to avoid grub-positioning problems, reduce update bandwidth, reduce redundancy, reduce size of install. | 17:34 |
| kees | ogra: I'm nervous about removing -generic while it's running. | 17:35 |
| kees | pitti: what is "system-cleaner"? (and how does it run?) | 17:35 |
| ogra | well, last good boot only removes after the first successfull boot of a new kernel as i understood it | 17:36 |
| liw | kees, system-cleaner is the tool I wrote to remove "cruft" (it's now called Cruft Remover, although the package name is still system-cleaner) | 17:36 |
| pitti | kees: cruft-remover now | 17:36 |
| pitti | ogra: last-good-boot was pulled from intrepid | 17:37 |
| ogra | pitti, and ? arent we taking jaunty here ? | 17:37 |
| kees | liw: ah, very cool -- does it get run automatically? | 17:37 |
| ogra | i would expect it to come back | 17:37 |
| liw | kees, nope, user has to invoke it | 17:37 |
| ogra | but BenC can surely comment better on that | 17:37 |
| pitti | ogra: yes, certainly | 17:38 |
| pitti | we want it, it just had implementation problems | 17:38 |
| ogra | right | 17:38 |
| ogra | so jaunty should be its release :) | 17:38 |
| ogra | which then should solve the system cleaner prob | 17:38 |
| enrico | Riddell: ping him there then | 17:38 |
| pitti | tkamppeter: that sounds like a good followup SRU together with the "spin on backchannel EOF" bug, so that one coudl sit in -proposed longer | 17:38 |
| pitti | tkamppeter: the current three bugs in -proposed are easy to verify, so I'd like to finish that one first | 17:39 |
| enrico | Riddell: he'll see your messages if you address him | 17:39 |
| tkamppeter | pitti, OK. | 17:39 |
| pitti | kees: so yes, technically it is no problem to do that | 17:39 |
| kees | pitti: okay, great. this gives me much more to work with as far as fleshing out that spec; thank you! | 17:39 |
| pitti | kees: it's mostly an usability challenge, I think | 17:39 |
| BenC | ogra: yeah, that's the plan | 17:40 |
| kees | pitti: oh, how so? | 17:40 |
| pitti | kees: getting description right, and so on | 17:40 |
| tkamppeter | pitti, should I send you the patch to put together this next -proposed package of CUPS? I cannot put the patch into the BZR as there the Poppler-based pdftoraster is already removed. | 17:40 |
| pitti | tkamppeter: feel free to commit it to the intrepid branch | 17:40 |
| pitti | tkamppeter: lp:~ubuntu-core-dev/cups/intrepid | 17:41 |
| kees | pitti: right, sure. | 17:41 |
| tkamppeter | pitti, do I have write access there? And if not, can you activate write access for me? | 17:43 |
| liw | kees, hmm, I think it might be a cool plugin for system-cleaner/Cruft Remover to have it suggest the optimal kernel, assuming that's possible | 17:43 |
| pitti | tkamppeter: oh, you aren't core-dev any more, right | 17:43 |
| tkamppeter | yes, they have made me only MOTU-and-a-half | 17:43 |
| pitti | tkamppeter: just send me the patch then, probably easiest | 17:43 |
| pitti | tkamppeter: I can change the owner, but only with breaking the existing Vcs-Bzr: headers in packages | 17:44 |
| kees | liw: you mean to suggest removing -generic when -server was installed and running? | 17:45 |
| kees | liw: I think that would be great. | 17:45 |
| tkamppeter | pitti, you have mail | 17:48 |
| liw | kees, yes, exactly that | 17:49 |
| * liw makes a note | 17:49 | |
| kees | liw: I'll add it to the spec details too | 17:50 |
| * ogra takes rss-glx from the armel list | 17:53 | |
| kees | pitti, liw: do you mind if I subscribe you to the PAE-kernel-selection spec? | 17:55 |
| liw | kees, sure | 17:56 |
| pitti | kees: please do | 17:56 |
| kees | ogra: you interested too? I've added "rename kernels" to the list of things the spec may include | 17:57 |
| ogra | kees, interested sure, not sure i have so much time left for non mobile and non arm specs though | 17:57 |
| ogra | but feeel free to subscribe me | 17:58 |
| kees | ogra, liw, pitti: I've sub'd you all, but didn't mark you "required". please adjust however you want. :) | 17:58 |
| kirkland | pitti: Keybuk: hey, can i ask for a slot on the desktop UDS agenda, to discuss a couple of encrypted home directory graphical management utilities that we'd need? | 18:07 |
| kirkland | pitti: Keybuk: i've got working prototypes of the entire underlying framework | 18:08 |
| kirkland | pitti: Keybuk: but there's a lot of griping from people about wanting a pointy/clicky utility to manage their setup | 18:08 |
| Keybuk | pitti: no, put them on the server track | 18:09 |
| Keybuk | and ask for desktop people to attend | 18:09 |
| Keybuk | err | 18:09 |
| Keybuk | not pitti | 18:09 |
| Keybuk | kirkland: | 18:09 |
| * liw gets a mental image of a crossbow | 18:09 | |
| directhex | Ubuntu Sponsors for main team has been subscribed to this bug. | 18:31 |
| directhex | okay then, the big mono 2.0 transition is ready to be kicked off. more or less. | 18:34 |
| alex-weej | what package should i file bugs about guest session to? | 18:43 |
| cody-somerville | guest-gdm-session or something like that | 18:43 |
| alex-weej | asac: know anything about PPTP VPN connections failing? hasn't worked since at least intrepid released (it did work with pre-release NM 0.7 though) | 18:43 |
| alex-weej | cody-somerville: thanks | 18:44 |
| * ogra wonders where his yesterday given back rpm went | 18:51 | |
| ogra | anyway | 18:52 |
| * ogra goes out for dinner | 18:52 | |
| pitti | alex-weej: there's a current SRU for it | 19:04 |
| tkamppeter | pitti, I have a problem with pstopdf: See bug 282186 | 19:05 |
| ubottu | Launchpad bug 282186 in cups "HP Photosmart 2610 top first cm not printed" [Undecided,Fix released] https://launchpad.net/bugs/282186 | 19:05 |
| alex-weej | pitti: which issue exactly? | 19:05 |
| pitti | alex-weej: network-manager-pptp | 19:06 |
| tkamppeter | pitti, the pstopdf filter converts PostScript to PDF using Ghostscript. On the Ghostscript command line paper size, resolution, and unprintable margins (all taken from the PPD) are supplied on the command line. | 19:06 |
| alex-weej | pitti: there are at least 4 outstanding, independent issues i am having to workaround in order to connect | 19:06 |
| tkamppeter | This is done to get the best of the file conversion, and also so that a CUPS test page contains the correct data. | 19:07 |
| directhex | so. who feels like doing said kicking off. it's only 80 packages or so :) | 19:08 |
| * directhex prods pitti | 19:08 | |
| directhex | sooner the better with transitions, that's what i say | 19:09 |
| tkamppeter | pitti, the problem is that the PDF generated by Ghostscript has the margins clipped exactly at the borders defined in the PPD file. In general, one would think this is OK, as the PPD tells what are the unprintable margins of the printer, but in reality it is not the case. | 19:09 |
| pitti | alex-weej: look at the topmost bit of https://edge.launchpad.net/ubuntu/+source/network-manager-pptp | 19:09 |
| pitti | directhex: 80 packages what? syncs? can do; uploads? spread to several people please; "develop fixes"? no way :) | 19:10 |
| pitti | tkamppeter: I saw the reply, but how was it handled in the past? some mystic implicit extra margin? | 19:10 |
| directhex | pitti, https://bugs.launchpad.net/ubuntu/+source/mono/+bug/300133 plus recent messages to ubuntu-devel@ | 19:10 |
| ubottu | Launchpad bug 300133 in mono "Mono 2.0.1 package (triggers major packaging transition, please read in full)" [Undecided,New] | 19:10 |
| tkamppeter | pitti, the current HP inkjets for example have unprintable margins of 9 points (around 3 mm) alll around if not in full-bleed mode. The PPDs suggest all an unprintable margine of 36 points (12.7 mm) at the bottom. This makes pstopdf clipping a lot. | 19:11 |
| tkamppeter | pitti, formerly there was no filter which clipped borders. And the CUPS test page was rendered by the Ghostscript instance which ran the printer driver. | 19:12 |
| tkamppeter | The two possibilities which I can do are: | 19:12 |
| tkamppeter | 1. I do not feed the border info but only page size and resolution into Ghostscript. Then all normal jobs work correctly and I can also print full-bleed photos with flphoto. | 19:13 |
| tkamppeter | But the CUPS test page does not show margin info (all zero) and not the black border. | 19:14 |
| tkamppeter | 2. No change, which gives me a perfect CUPS test page but unwished margin widths on many normal jobs, especially no full-bleed with many photo managers. | 19:15 |
| tkamppeter | pitti, my suggestion is 1. both for Jaunty and as SRU for Intrepid. | 19:15 |
| kees | anyone know how to pin a command to a specific CPU? | 19:16 |
| directhex | kees, tastset? | 19:16 |
| directhex | task | 19:16 |
| tkamppeter | In Jaunty the CUPS test page will go away with CUPS 1.4, there is a new test page concept. | 19:16 |
| directhex | let's try that again: taskset | 19:16 |
| tkamppeter | pitti, in Intrepid users happen to print the CUPS test page rarely, as with s-c-p on A4 and Letter Ubuntu tesy pages are used. | 19:17 |
| directhex | unless that's in some sgi rpm... nope, util-linux | 19:17 |
| pitti | tkamppeter: (phone, bbl) | 19:18 |
| kees | directhex: perfect! thanks | 19:18 |
| tedg | pitti: Have you packaged devkit? | 19:18 |
| tkamppeter | pitti, simply answer after the call. I leave the window open, so it catches your answer also if I am not here. | 19:20 |
| pitti | tkamppeter: hm, so is the issue that the margin info in the PPDs are plainly wrong, or that they only apply to some modes (and not in full-bleed)? | 19:26 |
| === Michiel__ is now known as Eghie | ||
| pitti | tkamppeter: if they are wrong, fixing the PPD files seems most adequate? | 19:26 |
| pitti | tkamppeter: other than that, I'm all for breaking the test page to fix real printouts :) (your solution 1.) | 19:27 |
| pitti | tkamppeter: I mean, after all the printer will figure out the clipping on its own :) | 19:27 |
| pitti | tkamppeter: the only other useful thing would be to make applications aware of the clipping borders, so that you avoid putting contents to these areas in gimp, OO.o, or whereever; do PPDs provide that? | 19:28 |
| pitti | tkamppeter: if it's just some intermediate filters in the chain, then clipping there is fairly useless IMHO | 19:28 |
| === beuno_ is now known as beuno | ||
| devinheitmueller | I'm a developer for the Kaffeine project, and was wondering if there is a documented process for getting an upstream Pull into Ubuntu? We did a new release in July (0.8.7) and there was a launchpad ticket opened which never got responded to. What is the best way to ensure that that the newest release gets into Jaunty? | 19:33 |
| directhex | devinheitmueller, is kaffeine in ubuntu based on a debian package? | 19:34 |
| devinheitmueller | hmmm... that's a reasonable question. Let me look. | 19:35 |
| tkamppeter | pitti, it is an intermediate filter, pstopdf. So I think I will let the filter not clip, also if then the CUPS test page is wrong. I will do the change in Debian CUPS BZR trunk. Please put it into the current CUPS SRU then. The fix is obvious and does not need a long testing preiod. I have tested it also with flphoto by myself. | 19:35 |
| directhex | yes, it seems so | 19:35 |
| devinheitmueller | Yes, I believe so: | 19:35 |
| devinheitmueller | https://launchpad.net/ubuntu/+source/kaffeine | 19:35 |
| devinheitmueller | It would be really useful to get this in, since digital television scanning doesn't work in North America without the new release. | 19:36 |
| directhex | devinheitmueller, so: talk to the debian packager (who is likely to need to use Experimental, as debian is frozen) then request a sync/merge | 19:36 |
| directhex | devinheitmueller, debian kde extras team. pkg-kde-extras@lists.alioth.debian.org | 19:36 |
| cjwatson | (we can do it directly, but prefer to work via Debian if possible) | 19:36 |
| devinheitmueller | Is there a definitive way to determine who the debian packager is (admittedly I'm not familiar with Ubuntu/debian's packaging processes) | 19:37 |
| directhex | yes, we do! had a peek at my mono transition bug, cjwatson? someone's gonna have to take the plunge & start it off | 19:37 |
| devinheitmueller | Ah, ok. | 19:37 |
| cjwatson | directhex: I'm already literally doing something like five or six different things ... | 19:37 |
| directhex | devinheitmueller, generally: http://packages.qa.debian.org/sourcepkgname | 19:37 |
| directhex | poot. | 19:37 |
| cjwatson | directhex: most of which are critpath for jaunty alpha 1 :( | 19:38 |
| devinheitmueller | Hmm.... Looks like they're already at 0.8.7-1. | 19:38 |
| directhex | cjwatson, well, alpha 1 is basic toolchain isn't it/ that takes priority | 19:38 |
| devinheitmueller | http://packages.qa.debian.org/k/kaffeine.html | 19:38 |
| directhex | devinheitmueller, really? in that case, request a sync with a sync bug. details of how are on the ubuntu wiki someplace | 19:39 |
| devinheitmueller | Ok. | 19:39 |
| cjwatson | directhex: shouldn't this go after alpha 1 anyway? | 19:39 |
| devinheitmueller | In fact, it's been marked at "testing" since August 1st. | 19:39 |
| cjwatson | don't request a sync with a sync bug | 19:39 |
| directhex | devinheitmueller, it may need a merge (i.e. actual developer intervention) instead of syncing | 19:39 |
| cjwatson | it's modified in Ubuntu - somebody needs to merge it, but we already have a queue for that | 19:39 |
| cjwatson | i.e. it's on the list already | 19:40 |
| cjwatson | (http://merges.ubuntu.com/universe.html) | 19:40 |
| devinheitmueller | Pardon, are you saying Kaffeine is on the list already? | 19:40 |
| cjwatson | yes, I am | 19:40 |
| devinheitmueller | ok | 19:40 |
| cjwatson | at the start of each cycle we merge everything from Debian | 19:40 |
| cjwatson | we're partway through that process, but haven't finished yet | 19:40 |
| cjwatson | kaffeine is still on the to-do list | 19:40 |
| devinheitmueller | Now that I see how this is working, I'll see about merging whatever patches you have upstream for 0.8.8. | 19:41 |
| devinheitmueller | directhex, cjwatson: thanks for your help! | 19:45 |
| ScottK | devinheitmueller: apachelogger did the last uploader for it, so he's generally the one that would look at it. | 19:45 |
| Riddell | devinheitmueller: hi | 19:45 |
| devinheitmueller | Ah, I saw that name and thought perhaps it was an automated process. | 19:46 |
| Riddell | devinheitmueller: I actually was doing the kaffine update today but there's a problem in kdelibs that stopped it compiling | 19:46 |
| devinheitmueller | oh? | 19:46 |
| directhex | devinheitmueller, that's good - it's always ideal to have some connection between up & downstream, WRT patches | 19:46 |
| devinheitmueller | Yes, I definitely want to reduce the work required by the maintainers in terms of merging. It's bad for everybody. | 19:46 |
| Riddell | devinheitmueller: #kubuntu-devel is generally the place to ask about KDE related packages | 19:47 |
| devinheitmueller | Riddell: ah. Thank you for pointing that out. I'll switch over to the more appropriate channel. | 19:47 |
| cjwatson | could somebody score up gnome-control-center on armel, please? | 19:54 |
| directhex | NCommander, did i thank you for your armel mono fix? | 19:57 |
| NCommander | YOu don't have to thank me. | 19:58 |
| * NCommander kicks distcc | 19:58 | |
| RainCT | isn't "fix mono" something like introducing a bug? | 19:58 |
| * RainCT hides behind a big stone :P | 19:58 | |
| directhex | NCommander, contributors need recognition! | 19:58 |
| directhex | RainCT, rule 1 of irc: nobody can see your finger quotes or hear your sarcastic tone of voice. adjust smileys as appropriate ;) | 19:59 |
| Treenaks | directhex: "finger quotes" | 20:00 |
| directhex | Treenaks, if i used finger quotes when telling them shell commands to run, they'd give me a very funny look | 20:00 |
| directhex | s/them/people/ | 20:00 |
| RainCT | directhex: add a *sad look* to my previouse sentence then ;P | 20:01 |
| Treenaks | directhex: good point | 20:01 |
| directhex | bah. i need more sleep. up until all hours last night writing some mails about some packages | 20:01 |
| pitti | tkamppeter: current SRU is already uploaded | 20:18 |
| pitti | tkamppeter: I agree, clipping makes no sense at all in an intermediate filter | 20:18 |
| tkamppeter | pitti, as you have seen in the mail I have put the new pstopdf onto the BZR. It fixes for sure bug 282186 and perhaps also bug 293832. | 20:24 |
| ubottu | Launchpad bug 282186 in cups "HP Photosmart 2610 top first cm not printed" [Undecided,Fix released] https://launchpad.net/bugs/282186 | 20:24 |
| ubottu | Launchpad bug 293832 in foomatic-db "printer prints page at wrong position, page cut" [High,Incomplete] https://launchpad.net/bugs/293832 | 20:24 |
| soren | siretart: As I said: 17:00:54 < soren> I don't see why wpasupplicant's failure to function properly at that time should make everyone else suffer? | 20:26 |
| soren | siretart: The kernel discovers ethernet devices very early. It tells udev about this. Until you applied that patch, my interfaces were configured right then and there. | 20:27 |
| soren | And all my kittens were still alive. | 20:27 |
| soren | Now, nothing gets configured until S40networking is run. | 20:27 |
| === veloc1ty_ is now known as veloc1ty | ||
| === ogra_ is now known as ogra | ||
| ogra | can a buildd admin please priorize apmd (its holing up gnome-applets) | 20:57 |
| ogra | *holding | 20:59 |
| NCommander | I just had a brilliant idea on how to accelerate boot times | 21:23 |
| ogra | put the buildd boards on 380V ? | 21:24 |
| ogra | oh | 21:24 |
| ion_ | -O999 -funroll-loops -fgentoo | 21:24 |
| * ogra read s/boot/build/ | 21:24 | |
| NCommander | ion_, not quite | 21:26 |
| NCommander | OS designed have been playing around wit the idea of caching OS startup for years | 21:26 |
| NCommander | (OS X has BootCache, and I think Windows has something similar) | 21:26 |
| ScottK | NCommander: Since hibernate works so reliably we can just do that all the time? | 21:29 |
| NCommander | Not quite | 21:30 |
| * NCommander did have an idea about that but for another time | 21:30 | |
| NCommander | Well, w.r.t. to hibrenation, it might be worth investigating the point of having kernel execution cache its member state just before/after it executed init | 21:30 |
| soren | siretart: Either ping me here if you want to discuss it, or I'll file a bug tomorrow at some point. | 21:35 |
| persia | ScottK, Actually, yes. The issue is getting hibernate to work that reliably. Booting is usually not so helpful. | 21:53 |
| * persia has a linux box that gets about 1000 power cycles per reboot | 21:54 | |
| soren | Resuming from hibernation often takes longer than booting for me. | 21:54 |
| joaopinto | where there any recent updates (as in today) related to sound play ? | 21:56 |
| ogra | soren, dont hibernate your servers :P | 21:56 |
| jdong | soren: likewise, I only hibernate when I need to save my state | 21:56 |
| jdong | the problem is the swap-thrashing right after resuming | 21:56 |
| jdong | I find it actually better to hackishly swapoff -a; swapon -a after suspend in a suspend.d script | 21:56 |
| soren | persia: I see the potential for using something *like* hibernation to boot faster, though. | 21:57 |
| persia | soren, Well, depends on hardware, etc. On that device, resume-from-hibernate is about 1.5 seconds, but it's a custom kernel to support "instant-on" type behaviour. Boot takes about 4 minutes. | 21:58 |
| persia | It's also ARM, which boards tend to have shorter resume-from-hibernate cycles anyway. | 21:58 |
| ogra | yeah | 21:58 |
| ogra | we just need to switch the world to arm | 21:59 |
| ogra | that solves all power probs | 21:59 |
| jdong | it probably would :) | 22:00 |
| TheMuso_ | ogra: heh it also solves x86 domination probs. :p | 22:00 |
| persia | Well, no. Nobody builds ARM supercomputers. | 22:01 |
| ogra | TheMuso_, yeah, thats a sideeffect ... :) | 22:01 |
| ogra | persia, but why ? | 22:01 |
| ogra | you can get way more beagleboards in a 19" cabinet than blade servers :) | 22:02 |
| persia | ogra, Power-consumption-optimisation rather than instruction-throughput-optimisation, I'd say. | 22:02 |
| ogra | ah, well, mass compensates here ... | 22:02 |
| === beuno_ is now known as beuno | ||
| lamont | what's it mean when seahorse(?) blats out: Warning: Tried to connect to session manager, Could not open network socket | 22:27 |
| ogra | probably it didnt get a dbus connection ? | 22:28 |
| ogra | is the session dbus running ? | 22:29 |
| lamont | well, X died when kvm and xchat did battle | 22:29 |
| lamont | ogra: how do I see if the session dbus is running? | 22:30 |
| ogra | ah | 22:30 |
| ogra | ps ax|grep dbus|grep "session$" | 22:30 |
| ogra | but it usually gets started via dbus-launch with the --exit-with-session option | 22:31 |
| ogra | which means it dies with x-session-manager | 22:31 |
| ogra | lamont, while you are here, could you bump gnome-control-center and ampd on armel ? building them will make ubuntu-desktop installable | 22:33 |
| ogra | and they seem to sit with with a score of 0 in the queue .... | 22:33 |
| Hobbsee | I'm starting to hate email. | 22:38 |
| Hobbsee | or the MOTU community. Either way. | 22:38 |
| * Mithrandir ruffles Hobbsee | 22:39 | |
| * NCommander gives Hobbsee a shotgun | 22:39 | |
| NCommander | lamont, is it hypothetically possible for a build admin to be able to do a binary upload into a PPA? | 22:39 |
| NCommander | or, actually, to the buildd admins ^ | 22:40 |
| cprov | NCommander: not even in theory. What's the case ? | 22:41 |
| NCommander | cprov, cross-compiler bootstrapping | 22:41 |
| NCommander | cprov, I'm investiaging the possibility of packaging cross-compilers in the archive (with doko's blessing), or in a PPA (to stage) | 22:42 |
| NCommander | But to build a cross-compiler, you need a glibc compiled to that architecture | 22:42 |
| calc | i'm getting weird build errors (maybe hardware related) so i'm going to run memtest and other hardware tests, bbl | 22:42 |
| NCommander | Essentially, you need cross-binutils, cross-gcc min, cross-glibc built, cross-gcc built again full, full glibc | 22:42 |
| NCommander | Steps 2-4 would require a binary upload. Once all the packages are uploaded, its possible to rebuild itself | 22:43 |
| calc | system can't even unpack a previously known good tarball (from ~ 1hr ago) | 22:43 |
| TheMuso_ | calscary. | 22:43 |
| TheMuso_ | gah missed him. | 22:43 |
| === TheMuso_ is now known as TheMuso | ||
| NCommander | cprov, this would also allow us to work around cases where arch all packages require building on non-i386 platforms | 22:44 |
| cprov | NCommander: it's very tricky, I can see. | 22:44 |
| NCommander | i.e., QEMU BIOS | 22:44 |
| doko | NCommander: better to just build-depend on the corresponding -source packages and build it; you can even reuse most of the packaging | 22:44 |
| NCommander | YOu still have the issue problem of the first toolchain, I've never been able to get GCC to build properly without headers from glibc | 22:45 |
| NCommander | doko, does glibc even support cross-compilation? | 22:45 |
| NCommander | (the source package I mean) | 22:45 |
| NCommander | I know binutils and gcc do | 22:45 |
| doko | NCommander: have a look, but you can always build-depend on glibc-source. and better to apply all the patches we do in the native package | 22:46 |
| NCommander | Hrm | 22:47 |
| NCommander | It would probably be tricky to tweak the rules to get the toolchain to come out properly in a PPA without glibc binaries installed ... | 22:47 |
| NCommander | But not impossible | 22:47 |
| doko | hmm, I don't understand ... | 22:48 |
| NCommander | GCC requires glibc's headers for the target platform to be compilable | 22:49 |
| NCommander | (it cross-compiles libgcc to match the target) | 22:49 |
| * NCommander looks up his cross-compiler notes to make sure I'm not talking smack | 22:50 | |
| NCommander | d'oh | 22:50 |
| NCommander | I forgot you also need kernel headers | 22:50 |
| NCommander | I knew something was missing | 22:50 |
| === GuilhermeCunha is now known as GuilhermeCunha_ | ||
| NCommander | Oh | 22:51 |
| NCommander | They fixed the gcc needs glibc in the 4.x series | 22:52 |
| === GuilhermeCunha_ is now known as GuilhermeCunha | ||
| * NCommander is giving a hint the last time he built cross-compilers without cross-tool or equivelent | 22:52 | |
| NCommander | so in that case, it simply becomes cross-binutils, cross-gcc-core, cross-linux-headers, cross-glibc, cross-gcc-full | 22:53 |
| lamont | NCommander: no | 22:55 |
| lamont | one can upload source, buildds build, and launchpad uploads binaries to itself | 22:55 |
| NCommander | I know that. | 22:56 |
| lamont | (for the delayed response) | 22:56 |
| NCommander | BUt I mean in the case of bootstrapping in a PPA, would it be possible for a build admin to do a binary upload | 22:56 |
| doko | ogra: gcompris build failure on armel | 22:59 |
| ogra | doko, yeah | 22:59 |
| lamont | NCommander: that would be problematic, and not something I'd willingly touch | 22:59 |
| ogra | doko, the tird time or so | 22:59 |
| ogra | *third | 22:59 |
| lamont | *turd | 22:59 |
| ogra | waiting for gnome-games | 22:59 |
| lamont | :-) | 22:59 |
| NCommander | :-) | 22:59 |
| ogra | oh, wait gnome-games should be there | 23:00 |
| doko | ogra: no, please look first | 23:00 |
| * ogra looks | 23:00 | |
| lamont | NCommander: and I'd certainly defer to cprov on the answer to that | 23:00 |
| sebas | Hi | 23:00 |
| sebas | Is anybody aware of an issue where i as a user can't connect to networkmanager and HAL | 23:01 |
| sebas | Or at least, i'm getting permission problems when trying to use nm-applet or powermanagement stuff in HAL | 23:01 |
| sebas | Happens since a few days, maybe a week or so | 23:01 |
| sebas | I'm not quite grasping how this dbus / session / permission stuff works | 23:02 |
| cprov | NCommander: the model doesn't allow that, maybe you could upload a source with the binary blod inside it. | 23:03 |
| sebas | Or maybe someone has pointers to where I need to look if things are set up OK | 23:03 |
| NCommander | cprov, yeah, that was plan B, which was evil, but doable | 23:03 |
| cprov | NCommander: in LP binary needs a build the needs a source, we can't break this chain. | 23:04 |
| NCommander | cprov, we could upload the source package, no issue | 23:04 |
| cprov | s/cannot/don't want to | 23:04 |
| NCommander | But someone would have to manually upload the first binary build of it | 23:04 |
| cprov | NCommander: no, I meant a source that already contain the built binary | 23:05 |
| NCommander | cprov, no, that I got too | 23:05 |
| * NCommander was answering on breaking the chain | 23:05 | |
| doko | NCommander: please don't package the source again; use the available -source packages | 23:06 |
| * NCommander nods | 23:06 | |
| NCommander | doko, what about for binutils/gcc, do we want the cross-compilers building out of a single source package, or two, one for the main toolchain, and one for the cross-compilers? | 23:07 |
| directhex | what exaclty does the alpha 1 freeze freeze? | 23:08 |
| doko | NCommander: no, no more cross compilers out of the same package. we do that for spu and hppa64 because we do need it for those platforms. but for nothing else. | 23:08 |
| NCommander | doko, would you objection to say a gcc-cross source package to build cross-compilers (which would live in universe)? | 23:09 |
| NCommander | (assuming we put them in the archive ...) | 23:10 |
| doko | NCommander: yes, I do object, because a monster source building n cross compilers is just ugly | 23:10 |
| ogra | urgh, grcompris grew by 20 MB since i touched it last two releaes ago | 23:12 |
| ogra | *releases | 23:12 |
| NCommander | doko, what if we create a binutils-source which is the source w/ all binutils attached, then individual cross-toolchain packages which depend on that, gcc-source, and glibc source, and then works to build the cross-compiler? No duplication of source, no super-massive package to self-destruct | 23:20 |
| doko | NCommander: there is already a binutils-source package for this reason | 23:21 |
| NCommander | Oh | 23:22 |
| NCommander | I missed that it existed | 23:22 |
| NCommander | Well | 23:22 |
| NCommander | THat solves that :-) | 23:22 |
| ogra | doko, is tehre a bug open about gcompris (for my changelog) | 23:22 |
| * ogra doesnt get why that didt fail on any other arch | 23:24 | |
| ogra | *didnt | 23:24 |
| doko | ogra: no | 23:24 |
| ogra | good | 23:24 |
| doko | NCommander: and you could just copy the packaging, and set the target in debian/rules. but don't apply the patches again | 23:25 |
| NCommander | So then we need a binutils-*arch* package for each architecture we want a cross-compiler for ... | 23:26 |
| NCommander | when you update binutils, then we need to do no-changes binary uploads to update the cross-compilers. That works out to 3*architectures we want to support (binutils/gcc/glibc) | 23:26 |
| ogra | lamont, thanks for gnome-control-center | 23:29 |
| ogra | can any buildd admin rescore apmd on armel ? | 23:30 |
| Mithrandir | ogra: done | 23:31 |
| ogra | gracias :) | 23:31 |
| doko | done; why does lamont the thanks? | 23:31 |
| ogra | Mithrandir, you win a flowerpot for making ubuntu-desktop installable on armel :) | 23:31 |
| lamont | ogra: what did I do? | 23:32 |
| ogra | doko, oh, you rescored g-c-c ? | 23:32 |
| ogra | thanks to you then | 23:32 |
| Mithrandir | ogra: hurrah | 23:32 |
| ogra | :D | 23:32 |
| directhex | who feels like kick-starting the mono 2.0 transition then? it's got a steaming hot armel-ftbfs-fixing patch in it! | 23:33 |
| ogra | doko, did the cpp error checking change in any way since intreipd ? gcompris would never have built with the string handling code it has on jaunty | 23:35 |
| ogra | i really wonder how it did on the other arches | 23:35 |
| calc | still working on my system but found at least 1 bad memory stick :-\ | 23:54 |
| calc | so i probably won't get the replacement until after i leave for UDS :\ | 23:58 |
| calc | stuck with only 4GB of ram, heh | 23:58 |
| directhex | "only" | 23:58 |
| Mithrandir | you can't just walk to the closest shop and pick up a replacement? | 23:59 |
| calc | directhex: well OOo uses all it can get :) | 23:59 |
| Mithrandir | it's not like memory costs anything those days. | 23:59 |
| calc | Mithrandir: well it is under warranty so i'd like to avoid buying more, heh | 23:59 |
| directhex | i could be facetious and run "free" on my big box at work. can we take it as read that mine's bigger than yours? ;) | 23:59 |
| calc | especially since my record on buying new memory isn't any better | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!