=== xomas is now known as xomas_ === xomas_ is now known as xomas [01:22] mpt: yep, filter for ttf-* and otf-* should find all the relevant font packages. [01:22] thanks ArneGoetje === nhandler_ is now known as nhandler [04:05] slangasek, can I bug you for a minute about an archive question? [04:06] tgm4883: Just ask :) [04:06] persia, heh, was just getting to that [04:06] (people may be absent or long-term idle, but waiting for response is often futile and wastes a context switch) [04:08] I have a package showing up in multiverse/metapackages which is causing issues when trying to remove it from the software center (leaves a bunch of stuff leftover). persia checked debian/control and everything looks ok there. debian/control for the mythtv-themes package is http://pastebin.com/qEHHs2Zg [04:09] * persia suspects an override [04:10] which is the package in metapackages that you think shouldn't be? [04:11] mythtv-themes, I guess [04:12] yea mythtv-themes [04:13] it's not that it shouldn't be in there, but it apparently causes issues when trying to remove it via software center [04:13] tgm4883: if you think this is the wrong behavior, I can go ahead and change the override. I'd suggest double-checking with the other mythbuntu folks to confirm this wasn't intentional, if you haven't already [04:13] oh [04:13] specifically for bug 529740 [04:13] Launchpad bug 529740 in myththemes "mythtv-themes metapackage needs to be != metapackages section" [Medium,Triaged] https://launchpad.net/bugs/529740 [04:13] "shouldn't be there" meaning "shouldn't be in section metapackages", or? [04:13] yea, shouldn't be in section metapackages [04:14] superm1 had a discussion with mvo regarding how it works in the software center [04:15] ok, override changed (metapackages->graphics) [04:16] slangasek, awesome, thanks. Is there anything I need to do to the packaging to reflect that? [04:16] ArneGoetje: I'm seeing lots of traffic in bug #197537 again. I thought you had a good solution for this for lucid. Would you mind commenting with current plans when you have a chance? [04:16] it's already in section graphics in there [04:16] Launchpad bug 197537 in poppler "[MASTER] Can't read PDF file with CJK (Chinese/Japanese/Korean) text" [Unknown,Confirmed] https://launchpad.net/bugs/197537 [04:17] tgm4883: nope - I think you can go ahead and close the bug [04:17] slangasek, awesome, thanks again [04:27] persia: Is there a good reason that NEW upload rights shouldn't be granted to package(set)-specific uploaders? [04:28] wgrant: Yes. They have a conflict of interest since they may have uploaded the package in the first place. [04:29] wgrant: No, there isn't. The issue is that such behaviour isn't currently supported by Soyuz. [04:29] Specifically that the ACL for source NEW happens to be MOTU. [04:29] There are some issues involved, but the fix is technically easy. [04:30] StevenK: We're talking about different things: uploading to source NEW != reviewing source NEW. [04:30] At the moment, I believe that any component upload right is sufficient. [04:30] wgrant: That's good to hear. How do you think it ought be implemented so that all source NEW packages land in packagesets? [04:30] any movement on the upcoming appaurmor patch in karmic-backports? [04:31] persia: Arrrrrgh queue UI. [04:31] it scares me. [04:31] wgrant: I may have misunderstood previously. I had thought I remembered cjwatson saying that it defaulted those with component-based upload rights, rather than packageset-based upload rights. [04:32] wgrant: I don't care about UI. At a pure conceptual level: how can Soyuz allow arbitrary packages to land in NEW, even for folk that do not have upload rights to any component? [04:32] If that's trivial, then my issues are solved. Archive Admins can land stuff as appropriate, and the rest is social. [04:34] Ah. So. At the moment you need to have upload rights to the upload component. That's a bit of a strange definition, since the upload component is always universe. As I suspected, that can be easily relaxed to any privilege at all if people agree. [04:35] wgrant: So theoretically we could grant ~ubuntu-dev upload rights to the upload component, assuming agreement? [04:35] persia: Better to fix the code. [04:36] The potential social problem is that archive admins would have to verify permissions themselves. [04:36] Unless LP did a nice highlighting thing for this case. [04:37] wgrant: What do you mean by "fix the code"? [04:37] persia: Adjust the code to permit a NEW upload if the signer holds any upload privilege to the archive. [04:38] Rather than requiring permissions to the default component. [04:39] OK. This makes sense. Now, that sorted, what can we do for archive admins to reduce the chance that someone uploads something to NEW and can never upload it again? [04:39] I'd prefer that not to require an application to the TB for an extended package set [04:39] (although the entire proposal *does* need TB approval) [04:40] Very difficult. [04:42] Any ideas? I'd rather not implement something that coudl so easily lead to that social failure. [04:47] wgrant: So, to get back to your original question: the good reason that NEW upload rights shouldn't be gratned to package(set)-specific developers is that we have no idea how to model that sanely yet :) [04:49] persia: So it seems :/ [04:50] wgrant: Depending on one's philosophy, this may not be a real issue. Many package-specific developers are not yet trusted with wider scope. Many packageset teams can be expected to have at least one MOTU or core-dev with an understanding of archive-wide implications of adding packages. [04:51] persia: That's true. [04:51] So, where a packageset team needs something new, they get their capable member to push it, and then apply to the TB for a change. [04:51] We get reduced vanity packages from non-developers, and more stuff flowing through Debian. [04:52] It's suboptimal, but it's not yet terrible. [04:52] Then can we please revoke NEW uploads rights from just about everyone? :) [04:52] * wgrant forces everything through Debian. [04:52] I'd support someone else's presentation to the TB of an argument blocking NEW upload rights to all but core-dev. [04:53] I wouldn't support the argument that everything needs to go through Debian. Some stuff doesn't belong there (e.g. ubuntu-meta) [04:53] Right. [04:53] psh, then i'd have to upload my mozilla weave minimal server package to debian instead [04:53] (hence "just about everyone") [04:53] Right. Make a proposal :) === dendrobates is now known as dendro-afk [05:15] persia: The web U/I would also need some rework for archive admins that don't have shell access. [05:16] ScottK: Would that need change for the class of source NEW? I thought source NEW didn't have useful web UI already. [05:16] I can do source New just fine. [05:17] It's just that I only have the 4 existing componenents as targets for the package (Universe being default) [05:18] packagesets and components are distinct layers. [05:18] Can you also use the LP API to flip bits between packagesets? [05:21] dunno [05:25] OK. Let me ask differently: what do you think you can't do in the Web UI that would be required to allow other folk to upload NEW sources? [05:27] Select a packageset in the U/I. [05:27] Also some identifiable way to know what package set it was aimed at. [05:29] I think packagesets are entirely managed via the LP API (whether one has shell or not). [05:29] No reason it can't be exposed in the UI, but I'm not sure that shell/no-shell matters for that. [05:30] The identifiable way to know what package set is the right target is the hard problem that meant wgrant didn't just go fix this in Soyuz today. [06:52] ScottK, persia: Packagesets are indeed managed through the API. One must be a TB member to create them, or the owner of the packageset to alter them. [06:52] wgrant: Is there any necessary relation between a packageset owner and people with access to a packageset? [06:54] persia: None. [06:54] Cool. I was worried there for a bit. [06:55] The current owner is in all cases the techboard. [06:55] That matches my expectations. [07:00] when does motu lose upload-everywhere-but-main ? [07:00] e.g. when should I make a push for core dev [07:01] lifeless: As soon as it can be implemented. The necessary decisions have already been taken. [07:01] would you cheer for me? [07:01] lifeless: Realise that in practice when this is implemented MOTU will gain upload access to some of main, and lose upload access to mono packages in universe (at the present time). [07:02] * lifeless isn't about to cry over mono [07:02] So some of the mono stuff will be in the core exclusive set? [07:02] lifeless: I've sponsored none of your uploads to main, nor done close code review on any of them, so no. [07:02] wgrant: No, it's that the Mono/CLI team got approved at the last TB meeting, so MOTU will lose access to that in addition to the packagesets in main. [07:02] persia: :(. You know there is the 'good person' aspect :P [07:03] lifeless: Don't try to convince me to change my criteria for approving core devs :p [07:03] persia: not going to! [07:03] lifeless: But really, apply to core-dev if you want to be core-dev, as you might apply to any packageset. Don't let the changes in MOTU drive that decision. [07:04] persia: my feeling is I don't do enough regular work; I've been kindof-meaning-to for ages [07:04] persia: So membership in a package set now excludes generalists? I thought it was explicitly decided that that was a bad thing. [07:04] For the medium future, MOTU will only get access to *more* packages when components go away. [07:05] wgrant: No, it specifically excludes MOTU, based on the spec providing a definition for MOTU in the new world. [07:05] Ah, I guess I should keep more up to date with TB minutes. [07:05] * wgrant reads. [07:06] wgrant: More concretely, a sufficiency of folk (including myself) felt that there were enough developers who would be *glad* to have less responsibility and focus on QA and archive-health for packages inherited from Debian that it made sense to have that be separate from the "Generalist Developer" category/ [07:06] persia: Good. That had always been my largest concern about the reorg. [07:07] So the idea being that MOTU can have smaller scope and focus on making the unseeded stuff really work, rather than that these people are losing access (because access only goes away when someone else steps up to help enough that MOTU no longer needs access). [07:07] But I guess it needs Soyuz changes. [07:07] Definitely. [07:07] Yep, but that's the future. [07:07] The hard part (and part of why the discussion took over a year) was in finding a way to frame the definition of MOTU as a positive thing. [07:08] also, we should get the bzr packaging team in debian to have access to bzr packages in ubuntu nder a packageset [07:08] lifeless: Just apply to the TB. I'd like the DMB to vet any suggested members of the packageset maintainance team that aren't already UbuntuDevelopers, but that's not strictly necessary. [07:09] persia: packagesets aren't active yet though, right? [07:09] * dmb growls [07:09] lifeless: They are indeed, and have been since December, at least. [07:09] \o/ [07:10] lifeless: But the first packageset not based on an Ubuntu Flavour was approved last Tuesday. [07:10] There are lots of LP glitches, too. [07:10] Well, second actually. The first was kernel stuff, but that's kinda special (and kernel stuff was technically the first ever packageset) [07:11] (that was about a year ago, I think, but I'd have to check logs for a precise timing) [07:12] Good morning [07:12] tkamppeter_: o/ [07:13] persia: so is mono a 'restricted package set' [07:13] ? [07:13] lifeless: No. There are currently no restricted package sets. I hope we can continue with that. [07:13] A restricted packageset implies we have failed in our selection criteria for core-dev. [07:14] persia: so I don't understand why motu wouldn't be able to upload to them, if we wante dto. [07:14] https://wiki.ubuntu.com/ArchiveReorganisation/Permissions [07:14] Because MOTU will be redefined. [07:14] claims two things: [07:14] That page is out of date [07:14] restriced package sets allow looser criteria for core-dev [07:14] This is what I hadn't realised until a few minutes ago. [07:14] https://wiki.ubuntu.com/Specs/LucidMOTU [07:14] /argh/ [07:14] wgrant: *was* redefined. [07:14] persia: Well, the definition is approved but not in place. [07:15] wgrant: Soyuz bugs aside it is :) [07:15] But yeah. [07:15] Anyway, MOTU needs another month or two to adjust to the new team model anyway. [07:16] * persia repeatedly advocates redundancy with favor and encourages repetition [07:16] And one can hope that we have some clear definition of what to do in Soyuz first. [07:16] persia: I cannot parse the 'definition of responsibility' section [07:16] As we discussed earlier, the issue of NEW source packages is still messy. [07:17] lifeless: So, given a set of packages, there's a larger set needed to build those packages from source or install those packages. [07:17] (build || run)-deps [07:17] MOTU doesn't have responsibility for any of that: it belongs to people who volunteered to make that stuff work. [07:17] transitive, I presume [07:18] I'd hope so, although without any Soyuz implementation yet, or even a detailed spec, it's hard to say how it will finally be defined. [07:18] what is a 'explicit separated upload permission' [07:18] and how is it different to 'per-package upload rights' [07:19] It's upload rights for a packageset [07:19] the set-of-package language isn't a problem to parse [07:19] its the undefined terms [07:19] AIUI a packageset is the result of seed processing [07:19] Yeah well. I wrote that in the middle of the night one night because the people who volunteered to write it hadn't yet, and it perhaps was insufficiently edited :) [07:19] but what is a 'non explicit' seperated upload perission [07:20] lifeless: Yes, but not all seeds generate packagesets. [07:20] Or rather packagesets that have separate upload permission. [07:20] what would an 'explicit unified upload permission' be [07:20] Two examples that come to mind immediately are ubuntustudio and lubuntu [07:21] lifeless: the permission granted to core-dev in the absence of restricted packagesets, or the permission granted to some whole-archive-upload team in the presence of restricted package sets. [07:22] persia: I would like you to do something like the permissions page referenced before. It was easy to understand: it defined its primitives, then used them. [07:22] I neither have enough confidence that I understand what you mean, nor enough definitions on that page [or unambiguously imported from some other page] to interpret the page correctly. [07:23] persia: done [07:23] ArneGoetje: Thank you :) [07:23] you seem to imply *at least two* distinct mechanisms to get upload rights to a package, and that some of them will cut MOTU off, and others will not cut MOTU off. [07:23] lifeless: I'm not tempted to edit a document approved by the TB, but I agree that would be a good edit. I only wish you'd told me about it sometime in December or January :) [07:23] I think understanding is important, so that folk wanting to work on a package do not exclude MOTU by mistake. [07:24] persia: I was on leave in december, and horribly sick in january [07:24] persia: no internet == no feedback [07:24] lifeless: If a package has someone looking after it in any organised way, MOTU isn't responsible for it. [07:24] lifeless: Understand. Please consider my comment a lament rather than criticism. [07:25] persia: I have issued a MIR for poppler-data [07:25] anyhow, you could add an 'interpretation' section at the botto, e xplicit note the TB hasn't reviewed it, and once happy ask for blessing. [07:25] please excuse my keyboard [07:26] I'd really rather ignore it, continue the mailing list discussion on "Future of MOTU", and define a clear spec for how it is to be implemented in Soyuz at the next UDS. [07:26] ok [07:26] up to you [07:26] my concrete issue is this: [07:26] lifeless: Do you think the lack of an interpretation section is blocking in some way? [07:26] I can't decide if its better for bzr packages to have a [type 1] or [type 2] or [type N] request made [07:27] persia: I think its blocking in two ways; the first way is that what is being decided on may be subject to misinterpretations - so we're not agreeing to what we thought we were. [07:28] the dropping of restricted sets seems to imply keeping the generalist bar very high, [/me stops going down that path righ now. later. different channel too] [07:28] lifeless: What are the request types? I only know of one: requesting the definition of a packageset. That makes the uploaders the union of generalists (core-dev) and specialists (bzr-dev). MOTU will no longer have interest in the package. [07:28] the second way is that unless people know what the options are - clearly and fully - they can't figure out the implications [07:28] persia: the lucid spec implies at least two types [07:29] seeds-with-explicit-seperated-upload-permission [07:29] lifeless: Hrm. I think I need your help to understand. I don't think I disagree: I just don't know what you mean. Would you be amenable to helping me understand the confusion in a /query, and we can return here once we have a model? [07:30] per-package-upload-rights [07:30] + seed management is shaded as a different thing [07:30] sure [07:30] Oh, right. Those are different. per-package-upload only applies to a person: it doesn't otherwise affect a package. [07:39] jpds, cjwatson: seems the latest cdimage change to create trace files doesn't account for the directory already existing, causing every build to send mail; fixxoring now [07:41] good morning [08:41] cjwatson: I've rebase the changes with the last few hours one and made a merge a proposal for ubiquity (https://code.edge.launchpad.net/~didrocks/ubiquity/copy_wallpaper_cache/+merge/20434) === tkamppeter_ is now known as tkamppeter [08:43] pitti, hi === sabdfl1 is now known as sabdfl [09:13] https://bugs.launchpad.net/ubuntu/+source/libass/+bug/529860 [09:13] Launchpad bug 529860 in libass "Update libass to bugfix release 0.9.9" [Undecided,New] [09:14] am I doing anything wrong or does nobody care because the package isn't really maintained from Ubuntu's side? [09:14] slangasek: thanks [09:14] there are more bugs than people to solve them. [09:15] of course. [09:15] so to make the update happen quicker, prepare the change and propose it to ubuntu-sponsors [09:15] I'd do it myself if I had the necessary privileges [09:16] you can do everything except the upload itself [09:17] how so? put it into a PPA, for example? [09:17] do the update on your machine and check it builds, installs properly etc [09:17] you could use a PPA to do this [09:18] then attach the necessary new files to the bug report [09:18] and follow the normal sponsorship process to get a -sponsor to upload it [09:18] zgreg: The attached debdiff is the key point, PPA allows for easy testing [09:18] Generally we look for a diff.gz (or similar) that includes the packaging of the new vesion. [09:18] for a new upstream, that probably means a new orig tarball and a new diff.gz. A debdiff will help make it easy to review. [09:19] zgreg: Hang on, ignore me... [09:20] I generally don't like to see the new orig tarball, preferring to use a watch file or get-orig-source rule. [09:21] I usually construct the diff for review myself using interdiff [09:25] is this procedure documented somewhere? [09:25] there are two parts [09:25] standard development - thats documented under the packaging docs [09:26] and sponsorship - also documented [09:26] all on the wiki [09:38] cjwatson: btw, do you know why component-mismatches is empty? [09:39] IOError: [Errno 2] No such file or directory: '/srv/launchpad.net/ubuntu-archive/ubuntu-germinate//all_netbook_lucid_i386' [09:39] apw: FYI, -15 kernel NEWed now [09:40] Running germinate... ..gzip: /srv/launchpad.net/ubuntu-archive/ubuntu/dists/lucid/main/binary-lpia/Packages.gz: No such file or directory [09:40] D'OH [09:40] asac: StevenK: I want to add gthumb for having a photo importer into UNE, do you want I add it too for armel? [09:40] pitti, most excellent thanks for the heads up [09:41] brought up with soyuz folks [09:41] didrocks: Unless there's a really good reason for something to be arch-specific, it's probably better to just add for everything. How many rdepds does it pull? [09:43] persia: 4, for 3 Mib of deb. The most issue is that it has been demoted, I should have a look there. [09:46] didrocks: IIRC it got demoted for no longer being seeded [09:46] didrocks: But yeah, just stick it in: otherwise the experience will be poorer only for people with a single architecture. [09:47] persia: ok, I'll try to look if we can put gthumb back as it now depends on libopenrawgnome which has always been in universe [09:48] Have fun with MIRs :) [09:48] slangasek: fixed for next publisher run, thanks to mthaddon and bigjools [09:48] persia: ahah, I got used to ^^ [09:49] didrocks: does it use mono? [09:49] ;) [09:49] whoops, I broke 'man -l' for uncompressed files [09:49] asac: if you really want, I can bring f-spot back :p [09:49] less work for me ;) [09:56] lol [10:01] seb128, fyi, with todays upgrade evo seems to behave again, no 100% CPU usage anymore for me [10:01] ogra: ok good [10:06] siretart, siretart`: just letting you know about bug 530481 has nvidia-185-libvdpau-dev as build-dep which is causing the issue [10:06] Launchpad bug 530481 in mplayer "nvidia-current build-dep breaks libgl if hardware isn't nvidia" [Undecided,In progress] https://launchpad.net/bugs/530481 [10:29] right, 'man -l' fixed [10:32] pitti, hi [10:32] hi tkamppeter, wie gehts? [10:34] pitti, everything OK, you asked for me in the morning. [10:35] tkamppeter: ah, because you pinged me in the evening when I was already away :) [10:35] pitti, it is about CUPS, Red Hat's patch still does not support DNS-SD-based broadcasting. We have really a regression against CUPS 1.4. [10:36] s/1.4/1.3/ [10:36] hm, wasn't this the entire point of that avahi patch? [10:36] tkamppeter: would it work without the patch, when using the compat api (as upstream does)? [10:36] pitti, is there really no chance to compile CUPS using its native DNS-SD support? [10:36] mvo, good morning, thanks for the instructions about how to try the subcategories [10:37] pitti, one should try it. Perhaps it works with patches (also on the Avahi side). [10:37] tkamppeter: well, you tell me :) you added it in the first place [10:37] but the changelog says that cups doesn't build with avahi [10:37] without the patch [10:38] I have quickly taken this Red Hat solution because we were shortly before Karmic's FF and wanted to get CUPS 1.4 in. [10:40] pitti, perhaps one can get it to work with the compat API, perhaps now where the compat API development went on. [10:41] pitti, The Red Hat patch does only half the business, it only makes the DNS-SD backend work, so that printers can be discovered and used via DNS-SD. [10:43] tkamppeter: ah, so that's for client-side detection, but not for server-side broadcasting; understood [10:45] seb128, sorry, i take back the above ... back to 100% cpu usage, now its sitting at "recieving mail" since a while [10:45] * ogra wonders if there is an issue with POP3 handling [10:47] pitti: morning! is there any way you could help with https://bugs.launchpad.net/ubuntu/+source/apport/+bug/528680 [10:47] Launchpad bug 528680 in apport "apport-collect repeatedly crashes" [Undecided,New] [10:49] pitti, .configure finds my installed compat API. [10:51] pitti, problem is that it cannot determine the version of the dns_sd API. [10:52] pitti, config.log says 'kDNSServiceFlagsShareConnection' undeclared [10:56] mpt: sure, np - I hope it helps you to get started, if anything is odd, please let me know (might be bugs etc) [11:01] tkamppeter: seems the old avahi compat interface simply doesn't implement this? [11:02] Q-FUNK: the error message can presumably be made more friendly, yes [11:03] pitti: actually, the issue is that apport-collect is currently borken. [11:07] Q-FUNK: I just ran apport-collect 528680, and it worked fine [11:08] pitti: ok, so what do I and 10 other people (found in a duplicate bug) are missing? [11:08] it still doesn't work for you? [11:09] Q-FUNK: it's ultimately bug 336866; I already have lots of workarounds for that, but apparently not enough [11:09] Launchpad bug 336866 in lazr.restful "When adding tag or updating description, lp_save() gives "HTTP Error 412: Precondition Failed"" [High,Confirmed] https://launchpad.net/bugs/336866 [11:10] pitti: ok. recommendations to work around the issue and succeed at attaching the extra debug info? [11:10] Q-FUNK: I'm afraid there's no workaround; it needs a code change to apply a workaround in apport [11:11] ok [11:12] so the only other alternative is to file a new bug, with the new apport hooks for that particular package added? [11:12] that should work, yes [11:13] pitti, is it possible that the DNS-SD API which CUPS is using does not exist as free software? [11:13] tkamppeter: could be; after all, it's written against Apple's APIs [11:15] pitti, this would mean that fom CUPS 1.3 top 1.4 the DNS-SD broadcasting feature got removed from Linux. [11:17] pitti, how should such a regression be handles? [11:18] tkamppeter: (1) shrugging, (2) adding the new API to avahi; I don't see another way? [11:20] mvo, sorry, I forgot how to update the index after changing the categorization. ./utils/update-software-center returns "ImportError: No module named softwarecenter.enums" [11:43] pitti, it seems that SUSE has stopped at CUPS 1.3.11, I do not find any SUSE RPMS of CUPS 1.4.x. [11:46] tkamppeter: how much API is it missing? if it's just missing one symbol, perhaps cups can be patched to not use it; after all, it didn't need it in 1.3 either [11:46] tkamppeter: svn blame should find the patch which introduced the usage of that symbol [11:48] mpt: the system one should work fine, or use PYTHONPATH=. utils/update-software-center - but running that should not be needed, it should pick up changes in the .menu file after a restart of s-c [11:52] mpt: bad news btw, xapian does not support "*foo*", only "foo*", I'm investigating (with upstream) what can be done. maybe we need to postpone it. sorry for that [11:52] (wildcard searches) [11:53] mvo, what do we need "*foo*" searches for? [11:55] background picutres are speced as "*-backgrounds*" [11:55] themes as "*-themes" [11:55] mvo, that doesn't need to be a live search, that's a one-time categorization whenever Packages.gz changes, right? [11:55] the ttf* and otf* is no problem [11:56] I thought xapian was just for when you're typing stuff in the search field === MacSlow is now known as MacSlow|lunch [11:57] mpt: all categories are mapped to xapian querries internally, that is not impossible to change, but the current design is nice and elegant, I would really like to keep it [11:58] mvo, if you kept them all as xapian queries, I imagine the query involved in fixing bug 507042 would be hideous :-) [11:58] Launchpad bug 507042 in software-center "All graphical packages are listed in 'Get free software > System packages'" [Medium,Triaged] https://launchpad.net/bugs/507042 [11:59] mpt: not really, its the "Type" that we can use to filter out graphical vs non-graphical. [12:00] i.e. there is a property attached to each items for this [12:00] mvo, well the summary is a bit out of date, it's more about "appears in any other department vs. doesn't" [12:00] e.g. fonts shouldn't appear in "System" because they're appearing in "Fonts" [12:01] (actually, the summary is correct, but it's only a subset of the problem) [12:01] correct, for this using live querries is tricky [12:01] (see also the mapping of other->system) [12:01] same problem [12:06] mpt: constructing the category list at update-xapian-index time opens up new problems like mapping a search in a departement to a query. this gets really ugly really quick (in the code) [12:08] mvo, sorry I'm not familiar with the internal structure, but if you follow the #Genre algorithm for any new/changed packages whenever Packages.gz changes, then each item should have a static primary-department attribute [12:09] mvo, so whenever anyone does a search in a department, the live query would be "show me items that have this primary-department value and that also match this search:" [12:11] mpt: right, its not a question of "possible" vs "impossible" - its a question of how to map it to the code structure. its simpler to describe a solution than to implement it [12:11] undoubtedly :-) [12:12] cjwatson: in fact, the function "casper user" doesn't work in ubiquity for install mode (it's root) as there is no SUDO_USER variable. As I need the gconf value for the ubuntu user, I don't get the wallpaper cache, any idea? [12:13] hm, really? that's odd [12:13] didrocks: ok, just do what you were doing then, we'll refactor it later [12:14] cjwatson: ok, I'll update the merge proposal then in few minutes (it took me some time to find why the caching wasn't working with that code in install mode :)) [12:16] hi people, will NetworkManager 0.8 will make a cut into Lucid, or you will stick with 0.7.x? [12:18] pecisk: huh? [12:18] pecisk: 0.8 final is in already [12:18] and we had 0.8-pre in karmic already (e.g. 0.7.9xx) [12:18] missed that [12:18] allright, thanks for answer [12:27] looks like the dhclient-{enter,exit}-hooks aren't run when network-manager is used? [12:28] though it appears to use dhclient [12:29] also, mounting network shares is racy, since the DNS isn't necessarily functional yet [12:29] but where to file a bug? [12:44] Huh, seems like CD reading errors isn't because of CD-RW https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/461815 Kernel boots up fine, then comes CD errors and then very long waiting for squashfs and friends to load, as CD drive seemingly struggles to read it [12:44] Launchpad bug 461815 in linux "9.10 rc livecd takes a long time to boot, showing errors" [Undecided,New] === Tonio__ is now known as Tonio_ [12:52] ok so mountall is racy by design.. how confusing [12:53] makes booting more exciting that way :) [12:54] and debugging too === MacSlow|lunch is now known as MacSlow [13:57] is it possible for someone to binary new for php 5.3? === Eren is now known as Guest91686 [14:25] Riddell: ping can you binary new php 5.3 for me? [14:26] oh aye, it's my admin day so it is [14:27] 151 packages in New queue, good to know we take feature freeze seriously [14:30] zul: where's the feature freeze exception for this? [14:33] Riddell: https://bugs.launchpad.net/bugs/527286 [14:33] Launchpad bug 527286 in php5 "FFE for PHP 5.3" [Wishlist,Fix released] [14:36] groovy, accepted === robbiew_ is now known as robbiew [14:43] Riddell: thanks [15:05] geser: nixternal: soren: We'd like your help in -meeting :) [15:07] pitti, I succeeded to compile CUPS 1.4 without RH patch and without adding any new or Universe package. [15:07] tkamppeter: yay! you could drop teh usage of the new symbols? [15:07] pitti, I simply do s/kDNSServiceFlagsShareConnection/kDNSServiceFlagsShared/ on the whole source tree and CUPS compiles. [15:08] There was only one offending symbol. [15:08] sweet [15:25] pitti, kDNSServiceFlagsShareConnection is for an additional functionality which Avahi does not have bug apples (free software) mDNSResponder has. Probably one would need to add Apple's mDNSResponder to our distro. License is BSD. [15:27] tkamppeter: BZZT [15:27] mDNSResponder is Apache 2.0 [15:27] like most of Apple's open source stuff [15:27] we already have a Multicast DNS responder though, Avahi [15:27] if that's missing a feature, get it added to Avahi [15:28] Keybuk, is there some guarantee that if i boot lucid with devtmpfs.mount=0 udev will cope ? [15:28] ogra: udev should cope just fine [15:28] cool ! [15:28] udev doesn't really care [15:29] you may encounter bugs with other things === dottedma1 is now known as dottedmag [15:29] but they are bugs, and you should file them, and I'll fix them [15:29] well, i'm trying to use the same kernel across all VMs for rootstock for karmic and jaunty that needs devtmpfs.mount=0 ... i was wondering if i need to special case it for lucid, but that sounds good [15:30] ogra: why devtmpfs.mount=0 ? [15:30] that doesn't really make sense === dottedmag is now known as dottedma1 [15:30] that's only used if you don't have an initramfs === dottedma1 is now known as dottedmag [15:30] and even with that, devtmpfs is still "supported" so will be just mounted by mountall [15:30] because qemu doesnt boot without setting it and i dont use initramfs *and* use jaunty/karmic [15:30] why doesn't qemu boot? [15:31] all that option does is cause /dev to be mounted by the kernel [15:31] it moans about /dev ... i dont have the exact error handy atm [15:31] right, i suspect udev tries to create device nodes that are already there [15:31] no, udev copes perfectly with devtmpfs being mounted [15:31] if you really want to support that case i can file a bug [15:31] but its a very special corner case [15:32] in fact, even if you use devtmpfs.mount=0 - devtmpfs is mounted *before* udevd starts [15:32] and devtmpfs.mount=0 works just fine [15:32] right, but I want to understand this issue [15:32] you're telling me something *very* strange [15:32] by what is it mounted ? [15:32] ogra: mountall [15:32] hmm, but not in karmic [15:32] or jaunty [15:32] my probs are in jaunty and karmic with a lucid kernel and no initramfs [15:33] karmic and jaunty won't understand devtmpfs.mount=0 either [15:33] the kernel does [15:33] oh, sorry [15:33] apparently [15:33] you did not make *that* clear [15:33] i just wanted to know if lucid would cope if i keep devtmpfs.mount=0 a permanent setting :) [15:33] so i dont have to special case karmic and jaunty [15:34] but you answered that already [15:34] :) [15:34] I'm just wondering why jaunty and karmic fail here [15:34] karmic should see that /dev is already in the mount table [15:34] i think i had some bug with error messages ... [15:34] aha! [15:34] * ogra digs [15:34] but then karmic won't copy /lib/udev/devices over I guess [15:34]