[00:16] chrisccoulson: it's working [00:16] chrisccoulson: hmm, hang on a sec, testing something else [00:21] chrisccoulson: confirmed, with the two packages you pushed to your PPA it's working [00:21] gnome-settings-daemon only doesn't work but upgrading gnome-desktop as well fixes everything [00:22] stgraber - that's expected, the gnome-settings-daemon package was just for some debug information for another issue ;) [00:22] i probably should have mentioned that first [00:22] thanks for testing though! [00:23] stgraber - this is probably SRU material now. would you mind adding a karmic task to that bug, and i will add a karmic-updates milestone and work on the SRU paperwork now [00:30] chrisccoulson: sure [00:30] thanks:) [00:34] chrisccoulson: approved [00:35] cool, thank you [02:15] mdeslaur: now you can review attached debdiff in bug #431080 [02:15] Launchpad bug 431080 in drupal6 "Fix critical security vulnerability (SA-CORE-2009-008)" [Undecided,Fix released] https://launchpad.net/bugs/431080 [02:33] okies dokie lets fix some ftbfs [02:46] question. I've got a package where upstream is dead, there is no patch system, the packaging is in git, and I'd like to patch it. Should I just do it in git or should I add a patch system? [02:48] Laserjock - by "packaging" is in GIT, do you mean just the debian/ folder, or the whole debian source package (upstream source + debian/ folder)? [02:49] whole thing [02:49] I have 3 branches currently [02:49] upstream, debian, and pristine-tar [02:49] I was thinking I could do the patch as a separate branch [02:50] but I wonder if it's a pitfall to do that much in DVCS [02:50] i normally always add a patch system, but i've touched quite a few packages where people have directly patched the upstream source without adding a patch system (outside of bzr / GIT) [02:50] if it's in GIT, then it's probably ok without a patch system, especially if upstream is dead anyway [03:38] why is it ,that all of a sudden the build for 64bit complians that my machine is not 64 bit? [03:39] http://pastie.org/667621 [03:40] because you've told it that [03:40] --host=i386-pc-solaris2.11 \ [03:40] --build=i386-pc-solaris2.11 \ [03:42] based on dpkg-architecture... what needs to be changed? [03:42] i know i386 has to .. but where and how? [03:43] lifeless: dpkg-architecture no where shows that this is 64 bit [03:44] dpkg-architecture [03:44] ... [03:44] DEB_HOST_ARCH_BITS=64 [03:44] seems fine to me [03:44] perhaps you should try Ubuntu :) [03:44] hmm [03:45] I have to assume that you, or another solaris kernel+ubuntu userland developer have patched dpkg or glibc or some other package wrong [03:46] hmm [03:49] zul: I accepted your Ruby/LDAP upload. Did you notice that it was ....build2 so it'll get automatically sync'ed over in Lucid? [03:49] If that was on purpose, fine. Just wanted to make sure. [03:54] lifeless: thats really weird ... coz just about 5 hrs ago i built the a 64bit version of the same pkg and installed it on this very mahcine.. [03:56] wrapster: well, check you don't have any variables influencing it and debug dpkg-architecture [03:57] hmm [04:15] can you put a specific exception in a watch file? [05:35] How do I update the standards-version ? [05:52] bodhizazen: Check the package really conforms to the new version and then edit the Standards-Version: line in debian/control to the new number, and add an entry to debian/changelog saying you bumped the standards version to 3.8.3 or whatever. [05:55] jmarsden, I bumped the line, but got errors when I did that [05:56] bodhizazen: Be specific... what errors? pastebin something I can read please? [05:56] I tried to google the Standards-Version 3.8.3 - not much luck in finding something telling me what I am doing wrong [05:57] W: source: empty-debian-diff === Amaranth__ is now known as Amaranth [05:59] That has nothing to do with standards version as far as I know... it suggests confusion over source vs packaging stuff, and failure to keep them separate, such that debuild creates a zero length diff file... [06:00] bodhizazen: You do have an orig.tar.gz source tarball, plus your debian/ tree, right? [06:00] yes [06:00] when I change the Standards-Version back to 3.8.1 I do not get that warning , and the package builds [06:00] and the orig.tar.gz has *no* debian/ stuff in it? [06:01] it does have debian/stuff in it [06:01] aha. The Packaging Guide is pretty clear about not doing that... did you read that part of it? [06:02] I read it, but it is long and I do not recall seeing that information [06:02] let me try fixing that [06:03] If you include the debian/ in the tarball then you are in effect building a "native" package, which is a different and somewhat unusual thing to be doing. [06:04] The bit in the Packaging Guide is: "If a package already contains a debian/ directory, do not repackage it. Ask the author(s) to delete debian/ and provide a diff.gz instead. This makes it easier to review their work, and it separates packaging from program source. " [06:04] something I think is a bit bong if the upstream don't have a dvcs [06:04] packaging productises software, why shouldn't upstreams productise their code. [06:06] lifeless: Feel free to suggest changes to Policy in an appropriate forum :) But for now, I'm trying to help someone package something per the current policy and expected and documented approach, not debate it. [06:10] jmarsden, well, I am building this package from scratch [06:10] So you are both author and packager. OK... so you should still follow the guidelines and keep the two things separate, as far as I know. [06:10] jmarsden: who was debating ? ;) [06:11] I had to include /debian/pre and debian/post scripts , but remove everything else from the tar ball and it now builds [06:11] without warnings [06:11] jmarsden: btw, having debian in the upstream tarball doesn't make the resulting package a native package. [06:11] is that a problem , to have some things in debian in the tar ball ? [06:11] bodhizazen: as jmarsden says, its frowned upon [06:11] lifeless: Per the packaging guide: "A native package is one that is specific to Ubuntu/Debian. It has the debian/ directory containing the packaging information and any changes to the source included in the tarball (usually _.tar.gz). " [06:12] bodhizazen: the primary reason its frowned upon is that our toolchain shows a single diff from tarball to packaged source per source upload, and if there is packaging [06:12] data in the tarball, that diff becomes insufficient to tell what will happen when the package is built [06:12] well I do have a debian directory, but it does not contain that kind of information [06:13] jmarsden: you have confused necessary and sufficient [06:13] jmarsden: having a debian dir in the upstream tarball is not sufficient to make it a native package [06:14] bodhizazen: what does it contain? [06:14] Quite likely... I'm just going by what the guide said... perhaps it should be fixed to be more specific about the other things (version number style in debian/changelog?) necessary for it to be native? [06:14] no, it assumes [rightly] full familiarity with the toolchain [06:14] it contains 3 scripts [06:15] bodhizazen: called? [06:15] perinst postinst and postrm [06:15] bodhizazen: re: changing the standards version. See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz [06:16] *preinst [06:16] bodhizazen: those scripts are typically part of the packaging metadata; it would be much better for us if they were not there. [06:16] bodhizazen: because otherwise a reviewer will see e.g. debian/rules and debian/control and not those scripts [06:16] is it better to build with Standards-Version 3.8.1 then ? [06:16] no [06:16] you should read the upgrading checklist [06:17] whatever error you are getting is [probably] not related to having those scripts in the tarball [06:18] when I update the Standards-Version to 3.8.3 [06:18] I am getting [06:18] W: source: empty-debian-diff [06:18] ok [06:18] so, a) have you read /usr/share/doc/debian-policy/upgrading-checklist.txt.gz [06:18] I do not get that when I keep Standards-Version 3.8.1 [06:18] b) clearly you have more than those three scripts in your upstream tarball! [06:19] jmarsden: I seem to have taken over the conversation; sorry. [06:19] those are the only things I need to add to the tar ball in debian to build with the 3.8.3 standards [06:20] bodhizazen: repeating your assertion doesn't move this forward [06:20] lifeless: That's fine, I'm only a bugfixer and packager of a few things myself, not (yet?) a MOTU... [06:20] please pastebin 'ls debian' in a frest extracted copy of your tarball [06:21] in the one that works ? [06:21] you have more than one release? [06:22] bodhizazen: lets go back a step. Are you packaging this for inclusion in Ubuntu, or for uploading to your own PPA? [06:22] lifelies: 22:10 I had to include /debian/pre and debian/post scripts , but remove everything else from the tar ball and it now builds [06:22] jmarsden: thanks [06:22] ls debian [06:23] postinst postrm preinst [06:23] lifeless, for now, ppa [06:24] and I do not seem to have a /usr/share/doc/debian-policy/ directory, what package is that in ? [06:24] bodhizazen: debian-policy [06:24] which Ubuntu policy builds on [06:24] thank you [06:25] the errors from lintian, which you are seeing, are about Debian policy [06:29] is there a way to know where the error in policy is coming from ? [06:31] Yes, if you run lintian with the -i switch you get an explanation of each warning as well as the warning itself. [06:31] also you can do lintian-info -t empty-debian-diff [06:38] OK, thank you for your patience, I will look at this [06:38] bodhizazen: ok, I think you should do your build with 3.8.3, and pastebin (that means http://paste.ubuntu.com): [06:38] - the output [06:38] - the zcat of the diff [06:38] e.g. [06:39] debuild -us -uc 2>&1 > build.log [06:39] pastebinit -i build.log [06:40] zcat ../ | pastebinit -i - [06:40] then we can really see whats going on [06:43] you are very patient and I appreciate that [06:43] with your help I was able to sort it, as it turns out my tar was the problem [06:44] I have removed the debian directory, re-packaged the source, and it now builds with Standards-Version 3.8.3 [06:44] =) [06:45] bodhizazen: lifeless rocks :) [06:45] for so many reasons too. [06:48] this packaging stuff is not easy =) [06:48] once ya get the hang of it it gets easier :P [06:48] that it does [06:48] just a lot of rules and exceptions to keep in mind :) [06:49] once you learn that debuild -S -sa is needed if you want to dput the orig tarball, that helps too :P [06:49] once you've been through the drill a couple times, at least you know where to look to refresh your memory. === freeflyi1g is now known as freeflying [08:58] how can I join to ubuntu-bugcontrol ? [08:59] see the wiki [08:59] it has details for everything :) [09:01] oh, this bureaucracy :P [09:33] can someone sponsor this: LP 459629 [09:33] Launchpad bug 459629 in sabily-xsplash-artwork "FFe: Fix english verse translation" [Undecided,New] https://launchpad.net/bugs/459629 === lionel_ is now known as lionel [11:16] devs, is there a complete work on maven2? [11:17] people says on launchpad that their problems has been resolved [11:17] but bugs are still open [11:51] ari-tczew: if the bug is open and shouln't be close it [11:51] otherwise, the bug should be open:P [11:54] I guess that developers are working on getting remaining packages libmaven* or libplexus*. [11:55] ari-tczew: we' [11:55] re in deep freeze for the release [11:55] I just only want to know what are doing in Ubuntu as proposed member to Ubuntu BugControl ;-) [11:55] yes I know [11:55] Ask on specific bugs [11:56] I'm not doing anything in that space at the moment, the whole maven collection is basically just synced from Debian [11:58] yes, I know... ;-) [11:59] I think about jabref [11:59] @launchpad is reported bug which says that jabref in karmic is broken [12:06] where can I talk about security updates - SRU ? [12:06] here? or other channel? [12:19] ari-tczew: for universe packages here [12:19] for main ubuntu-devel [16:09] Hello. I wonder if there is someone here who wouldn't mind answering a few packaging questions... [16:26] Goodday, gentlefolk. I am wondering if it is possible to submit a source package to a ppa that will build on multiple Ubuntu versions (karmic and jaunty). [16:27] I don't know offhand if you can do it with just one source package upload. [16:27] You certainly can do it with multiple source package uploads, one for each targeted version. [16:27] (changing the distribution field in debian/changelog and regenerating the source package) [16:27] Ah I see. [16:28] Do I need to setup pbuilder any differently? I am running jaunty, but want to build for karmic.. [16:28] it'll be best to have a separate Karmic pbuilder [16:31] Thanks dtchen! Found a nice blog post about it.. setting up now... [16:32] Another question... The ppa I'm working on is for Scratch, a programming language for kids developed at MIT. [16:33] Scratch runs on a squeak virtual machine, so the package is mainly installing / configuring that. [16:34] Recently someone with a 64 bit system tried to install but couldn't because we haven't submitted an amd64 package. [16:34] But when they forced the install, everything worked. [16:35] Is it acceptable to just submit the same package as amd64 and i386 compatible? [16:41] lightnin: are there real constraints such that it can't run on ppc, ia64, etc.? [16:44] Yes, because we are just installing a pre-built virtual machine binary. [16:45] When (if?) the squeak-vm package gets updated, we'll stop installing our own and just depend on the squeak-vm i386, or amd64 (or ppc if it exists). [16:49] So, given that, I guess I should change the Architecture field in my control file to: i386, amd64 [16:51] or rather i386 ia64 [16:52] you could do that if you're certain that the vm binary works fine on amd64. [16:54] Should manepages go in foo or in foo-data? [16:55] s/mane/man/ [16:57] Hmmm... just one user reporting on our forum that it does. Also - should I add i686 to architecture line? [17:00] ryanakca: foo-data [17:00] lightnin: We don't have an i686 architecture. [17:00] ScottK: thanks [17:03] ScottK: Ah, ok. Thanks. :) So just i386 and ia64, assuming there are no issues with the squeak-vm. [17:04] lightnin: ia64 is Itanium. Proabably not what you want. [17:04] You probably want amd64. [17:04] That's both AMD and Intel 64 bit. [17:07] ScottK: Thanks! I got confused by all the tags that dpkg-architecture -L gave me... === ogra__ is now known as ogra [18:03] * ScottK wonders where the last minute rush of MOTU uploading bug fixes went? [18:06] * DktrKranz hidez [18:12] Is the goal to get http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html fixed, or is it too late? (Noting also that the page is a month and a half old) [18:19] ryanakca: It's not to late. [18:19] ryanakca: The page is updated when packages are fixed, so stuff listed needs doing. [19:25] I have the file debian/knmap.lintian-overrides that contains 'knmap: binary-without-manpage usr/bin/knmap', however, when I run 'lintian -IivmE knmap*i386.changes', lintian still complains that 'knmap: binary-without-manpage usr/bin/knmap' ... what am I missing. I don't see the lintian override getting included in the binary package [19:29] ryanakca: You shouldn't override that anyway [19:31] ScottK: http://paste.ubuntu.com/300771/ .... [19:32] ryanakca: OK. Makes sense. [19:33] ryanakca: You need to put exactly what lintian spits out as the error. Usually when I've had problems, that was it. [19:35] ScottK: Copy pasted it :/ [19:35] OK, no idea then. Sorry. [19:35] Also, if I don't manage to fix the LaTeX errors with libspe2 (one of the FTBFS packages on the above list), one way to get it to build would be to drop the -doc package (and comment out the couple of lines in Makefile that build the documentation for it). Not ideal, but imho, it's better than having no libspe2 nor the packages that are blocking since they have it as a B-D... Would that be a possibility? [19:35] ScottK: OK, thanks anyways :) [19:40] ryanakca: When you copied and pasted, did you copy the entire line starting with "W: " (or whatever type it was) [19:40] ryanakca: At this point I'm OK with dropping docs to fix FTBFS. [19:40] anyone up for sponsoring bug #458600? :) [19:41] Launchpad bug 458600 in rlpr "rlpr FTBFS" [Low,New] https://launchpad.net/bugs/458600 [19:42] ScottK: No (I modeled it after the rest of the packages in debian-qt-kde's kde-extra's SVN repo) [19:42] I may be wrong, but I think you need that too === asac__ is now known as asac [19:54] ScottK: OK, I'll try including it. In regards to libspe2, it may only be the PDF documentation that we need to drop (and keep the rest) [19:55] OK. [20:02] What is the real upgradeable package associated with https://launchpad.net/ubuntu/+source/partman-basicmethods ?? [20:06] How should I deal with a bug report of the "please update package to $version" variety when $version is already in Debian unstable ready for syncing for lucid? [20:07] tonyyarusso: Mark them wontfix with a comment that it'll happen automatically for Lucid. [20:08] ScottK: gotcha, ty [20:10] ScottK: libspe2 uploaded to PPA (I don't own any powerpc nor ppc64 computers... and since the two archs aren't supported in Ubuntu, I wonder if I should bother spending any more time on the package) [20:10] Maybe TheMuso could have a look if it's powerpc related. [20:11] ScottK: err, does wontfix = invalid on LP? [20:12] tonyyarusso: Not quit, but you may not have wontfix. Invalid is fine with the comment. [20:12] quit/quite [20:12] Yeah, I don't see a wontfix in my menu. Must not be cool enough. [20:13] Haha, PPA rejected libspe2 because "Cannot build any of the architectures requested: powerpc ppc64 all" [20:19] tonyyarusso: I think you need to be in bugsquad (or whatever they call it now) or be MOTU. [20:20] prolly [20:20] bugcontrol [20:26] Hi, can you explain please why this bug has the debian bug linked on the top? [20:26] https://bugs.launchpad.net/debian/+source/phpmyadmin/+bug/456674 [20:26] Launchpad bug 456674 in phpmyadmin "giuseppe@ulisse:~$ sudo /etc/init.d/apache2 restart * Restarting web server apache2 apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName ... waiting apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName [ OK ]" [Undecided,New] [20:26] dbernar1: because its been reported upstream at debian too... [20:27] so if they find a way to fix it, we get notified [20:27] But by another user, and afaict, it is a different issue, etc. Was this relation between the two bugs done by the system or by a human, and how can I tell? [20:27] by a human, always [20:27] Hm... [20:27] Where does it say? [20:27] what? [20:27] say what? [20:27] Where does it say who made the relation. [20:27] the activity log [20:28] the machine can do it, but it doesnt go find and lok on its own. itll link bugs mentioned in the report or comment [20:28] Where's that, I don't see those words on the page. === dbernar1 is now known as dabaR [20:29] add /+activity to the end of the url [20:30] So.... the debian guy made the connection between the bugs? [20:30] Is the bug watch added the thing that made the link? [20:30] Is the "bug watch added" the thing that made the link? [20:31] yes [20:32] Hm...interesting. [20:32] How does it work again, can anyone close bugs? [20:33] you know, your nick is funny... [20:33] I mean, it is funny that you would have that nick. [20:33] I use the word maco to mean kitty. [20:34] And it is sort of a coincidence, I had a server called paco for a while. [20:34] its derived from my real name [20:34] paco meaning doggy. [20:34] Cool. [20:34] in what lang? [20:34] It is a modification of the word maca, in Yugoslavian languages. [20:34] Croatian, Serbian... [20:35] zdravo :) [20:35] Cool. [20:36] i think anyone can remove bug links, but only bug control & devs can close bugs [20:36] at least as wontfix... [20:36] not sure about who can do fix release and invalid [20:36] Anyone with an LP account [20:36] thanks [20:36] wasnt sure if bugsquad membershi was needed [20:37] maco: Could you have a look at a lmms merge from Debian. It got an approved FFe, but no one ever did the upload. [20:37] i can try [20:37] Thanks. [20:38] ive never done a merge before, though [20:38] Anyway, I am considering turning this bug into a question. [20:38] maco: Use grab-merge from ubuntu-dev-tools [20:38] alright thanks [20:41] porthose: Looking [20:53] porthose: Uploaded. Thank you for your contribution to Ubuntu. [20:53] ScottK, ty :) [20:55] ScottK: maybe you know, what about lm-sensors-3 in karmic? Is it will not merged? [20:55] bug #336418 [20:55] Launchpad bug 336418 in lm-sensors-3 "Please merge lm-sensors 3.1.1-4 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/336418 [20:55] ari-tczew: It's in Main, so unless it fixes a really serious bug, no. [20:55] * ScottK looks [20:58] ari-tczew: It looks far to invasive for this late to me. [21:01] ubuntu's users says that 3.1.1 version supports more devices [21:03] ari-tczew: that's Lucid material, really. [21:04] ari-tczew: Yes, but it's a lot of change, so the regression risk is too high now. Also it's more for #ubuntu-devel since it's in Main anyway [21:05] ok === jdong_ is now known as jdong [21:33] hello [21:35] Hello mirsal [21:37] I need some insights about how to submit a patch against an ubuntu package in universe [21:38] is there a bug reported [21:38] ? [21:38] yes [21:38] is the patch attached to the bug? [21:39] I actually uploaded a patched package to my ppa [21:39] https://bugs.launchpad.net/ubuntu/+source/xf86-input-evtouch/+bug/401039 [21:39] Launchpad bug 401039 in xf86-input-evtouch "Add support for TouchPack family touchscreens (Clevo TN120 series tablets / ASUS eeeTOP and other devices)" [Undecided,Incomplete] [21:39] for testing? attach the same patch to the bug, or, since you already generated a new source package, make a debdiff and attach that [21:40] then subscribe ubuntu-universe-sponsors [21:40] okay [21:40] Didn't know about debdiff [21:40] thanks [21:40] (debdiff just means run "debdiff oldpackage.dsc newpackage.dsc > newpackage.debdiff) [21:41] mirsal, cevo120tn definately works since intrepid with that driver [21:41] *clevo [21:41] ogra, Recent ones don't [21:42] (though all clevo 120s i have seen use ideaco touchscreens) [21:42] did clevo change the touchscreen ? [21:42] ogra, yeah. [21:42] New ones are supported by evtouch [21:43] bastards .... they should at least indicate that in the model name :P [21:43] old ones are too :) [21:43] New ones are *also* supported by evtouch :p [21:43] i developed all changes i did to the evtouch driver in intrepid on a clevo 120tn [21:43] the package only lacks a fdi file [21:43] yep [21:43] ogra, nice :) [21:44] ogra: Since you're at the very least somewhat familiar with this, could you review the change? [21:44] sadly i didnt have the time to go on working on it in jaunty and karmic .... so it's a bit behind [21:45] ScottK, sure [21:45] Thanks. [21:45] mirsal, btw, do you know bug 317094 ? [21:45] Launchpad bug 317094 in xf86-input-evtouch "meta bug to collect lshal touchscreen info" [Undecided,New] https://launchpad.net/bugs/317094 [21:45] ogra, yes, I already submitted the needed info there [21:46] well, would be good if someone who understands how the fdi stuff works could go through it and create .fdi files from the collected lshal info :) [21:47] ogra, Actually my company is selling computers with these touchscreens, so we needed them supported on ubuntu real quick, so I also build a package. [21:47] mirsal, can you attach the debdiff to your bug ? [21:47] ogra: are you the one that was poking at wacoms before? [21:47] nope [21:47] ogra, I'll do that in a minute [21:47] tablet != touchscreen :) [21:48] i wonder who that was then [21:48] tablets are wa more complex due to the additional input device you need [21:48] *way [21:48] yeah ive noticed [21:48] i have one that half-works ;) [21:48] maco, i thought wgrant was on that a while ago [21:49] ah ok. i thought it was someone with a g* last name [21:49] not sure if he still is though .... [21:49] wgrant: ping [21:50] contentless pings are bad. [21:50] and lonely [21:50] the context is 2 lines up! [21:51] ok 5 [21:51] so your ping cant hold hands with it :( [21:51] and clients don't always have sufficient scrollback [21:51] and it's a PITA to go to irclogs.uc, etc., etc. [21:52] fine fine [21:52] Sorry, did anyone reply? My connection is flaky. Does the apport tag on a bug in launchpad mean the bug was reported by apport? [21:52] dbernar1: Yes [21:52] wgrant: this is a ping regarding wacom support, wondering if you were still working on it [21:52] now thats a happy ping :D [21:55] OK, well, I am trying to see whether I can resolve some bugs. I see several bugs, related to installing phpmyadmin, on launchpad, and I tried to install it myself. The error seems to be caused by the fact that mysql-server is not installed, phpmyadmin does not have it as a dependancy, and does not want to install without it. [21:56] simple enough to fix. which version are you testing this on? [21:56] 9.04. [21:56] Same as the bug [21:56] lemme see if its fixed in 9.10 [21:57] make sure you don't have mysql-server installed... [21:57] i was just going to read the dependency list [21:57] \ [21:57] it says it suggests mysql-server [21:57] which means it wont automatically pull it in. are you saying one of the install scripts requires mysql-server? [21:57] how do you read the dep list? apt-cache show? [21:57] yes [21:58] Well...I think, I am not 100% sure, heh, that the phpmyadmin is a php based mysql administration app [21:59] (back) [21:59] ogra, I attached the diff [21:59] dbernar1_: yeah [21:59] And, it creates a mysql database for its config. [21:59] mirsal, checking ... [22:00] maco: So, yes, it seems that one of the install scripts requires it. [22:01] mirsal, hrm ... why do you patch udev ? [22:01] * maco tries toinstall [22:01] i explicitly disabled that (in intrepid though) since it messed up a lot [22:01] Ya, I did the same, it is quite simple to reproduce the error. [22:01] ogra, oh ok [22:02] mirsal, does it work with just the fdi ? [22:02] yes [22:02] ok, can you make a debdiff that has just the fdi ? the fdi looks ok and i'll hapily upload it right away [22:02] dbernar1_: this? [22:02] ERROR 2002 (HY000): Can't connect to local MySQL server through socket │ [22:02] │ '/var/run/mysqld/mysqld.sock' (2) [22:02] *happily [22:03] maco, sure, it should even open up an apport for you. [22:03] okay [22:03] dbernar1_: it does not [22:03] dbernar1_: it asks if i want to abort, retry, or ignore. if i choose ignore, it just finishes installing without being configured anywhere [22:03] maco, well, it did for me, I tried a few times to retry. [22:04] maco, so a feature, then? :-) [22:04] dbernar1_: is it possible that phpmyadmin can be installed on one system to configure a database on another system, so not having a local db isnt catastrophic? [22:06]