| === xomas is now known as xomas_ | ||
| === xomas_ is now known as xomas | ||
| ArneGoetje | mpt: yep, filter for ttf-* and otf-* should find all the relevant font packages. | 01:22 |
|---|---|---|
| mpt | thanks ArneGoetje | 01:22 |
| === nhandler_ is now known as nhandler | ||
| tgm4883 | slangasek, can I bug you for a minute about an archive question? | 04:05 |
| persia | tgm4883: Just ask :) | 04:06 |
| tgm4883 | persia, heh, was just getting to that | 04:06 |
| persia | (people may be absent or long-term idle, but waiting for response is often futile and wastes a context switch) | 04:06 |
| tgm4883 | 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:08 |
| * persia suspects an override | 04:09 | |
| slangasek | which is the package in metapackages that you think shouldn't be? | 04:10 |
| slangasek | mythtv-themes, I guess | 04:11 |
| tgm4883 | yea mythtv-themes | 04:12 |
| tgm4883 | 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 |
| slangasek | 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 |
| slangasek | oh | 04:13 |
| tgm4883 | specifically for bug 529740 | 04:13 |
| ubottu | Launchpad bug 529740 in myththemes "mythtv-themes metapackage needs to be != metapackages section" [Medium,Triaged] https://launchpad.net/bugs/529740 | 04:13 |
| slangasek | "shouldn't be there" meaning "shouldn't be in section metapackages", or? | 04:13 |
| tgm4883 | yea, shouldn't be in section metapackages | 04:13 |
| tgm4883 | superm1 had a discussion with mvo regarding how it works in the software center | 04:14 |
| slangasek | ok, override changed (metapackages->graphics) | 04:15 |
| tgm4883 | slangasek, awesome, thanks. Is there anything I need to do to the packaging to reflect that? | 04:16 |
| persia | 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 |
| tgm4883 | it's already in section graphics in there | 04:16 |
| ubottu | 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:16 |
| slangasek | tgm4883: nope - I think you can go ahead and close the bug | 04:17 |
| tgm4883 | slangasek, awesome, thanks again | 04:17 |
| wgrant | persia: Is there a good reason that NEW upload rights shouldn't be granted to package(set)-specific uploaders? | 04:27 |
| StevenK | wgrant: Yes. They have a conflict of interest since they may have uploaded the package in the first place. | 04:28 |
| persia | wgrant: No, there isn't. The issue is that such behaviour isn't currently supported by Soyuz. | 04:29 |
| persia | Specifically that the ACL for source NEW happens to be MOTU. | 04:29 |
| wgrant | There are some issues involved, but the fix is technically easy. | 04:29 |
| persia | StevenK: We're talking about different things: uploading to source NEW != reviewing source NEW. | 04:30 |
| wgrant | At the moment, I believe that any component upload right is sufficient. | 04:30 |
| persia | 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 |
| crypt-0 | any movement on the upcoming appaurmor patch in karmic-backports? | 04:30 |
| wgrant | persia: Arrrrrgh queue UI. | 04:31 |
| wgrant | it scares me. | 04:31 |
| persia | 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:31 |
| persia | 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 |
| persia | If that's trivial, then my issues are solved. Archive Admins can land stuff as appropriate, and the rest is social. | 04:32 |
| wgrant | 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:34 |
| persia | wgrant: So theoretically we could grant ~ubuntu-dev upload rights to the upload component, assuming agreement? | 04:35 |
| wgrant | persia: Better to fix the code. | 04:35 |
| wgrant | The potential social problem is that archive admins would have to verify permissions themselves. | 04:36 |
| wgrant | Unless LP did a nice highlighting thing for this case. | 04:36 |
| persia | wgrant: What do you mean by "fix the code"? | 04:37 |
| wgrant | persia: Adjust the code to permit a NEW upload if the signer holds any upload privilege to the archive. | 04:37 |
| wgrant | Rather than requiring permissions to the default component. | 04:38 |
| persia | 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 |
| persia | I'd prefer that not to require an application to the TB for an extended package set | 04:39 |
| persia | (although the entire proposal *does* need TB approval) | 04:39 |
| wgrant | Very difficult. | 04:40 |
| persia | Any ideas? I'd rather not implement something that coudl so easily lead to that social failure. | 04:42 |
| persia | 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:47 |
| wgrant | persia: So it seems :/ | 04:49 |
| persia | 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:50 |
| wgrant | persia: That's true. | 04:51 |
| persia | 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 |
| persia | We get reduced vanity packages from non-developers, and more stuff flowing through Debian. | 04:51 |
| persia | It's suboptimal, but it's not yet terrible. | 04:52 |
| wgrant | Then can we please revoke NEW uploads rights from just about everyone? :) | 04:52 |
| * wgrant forces everything through Debian. | 04:52 | |
| persia | I'd support someone else's presentation to the TB of an argument blocking NEW upload rights to all but core-dev. | 04:52 |
| persia | 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 |
| wgrant | Right. | 04:53 |
| pwnguin | psh, then i'd have to upload my mozilla weave minimal server package to debian instead | 04:53 |
| wgrant | (hence "just about everyone") | 04:53 |
| persia | Right. Make a proposal :) | 04:53 |
| === dendrobates is now known as dendro-afk | ||
| ScottK | persia: The web U/I would also need some rework for archive admins that don't have shell access. | 05:15 |
| persia | ScottK: Would that need change for the class of source NEW? I thought source NEW didn't have useful web UI already. | 05:16 |
| ScottK | I can do source New just fine. | 05:16 |
| ScottK | It's just that I only have the 4 existing componenents as targets for the package (Universe being default) | 05:17 |
| persia | packagesets and components are distinct layers. | 05:18 |
| persia | Can you also use the LP API to flip bits between packagesets? | 05:18 |
| ScottK | dunno | 05:21 |
| persia | 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:25 |
| ScottK | Select a packageset in the U/I. | 05:27 |
| ScottK | Also some identifiable way to know what package set it was aimed at. | 05:27 |
| persia | I think packagesets are entirely managed via the LP API (whether one has shell or not). | 05:29 |
| persia | No reason it can't be exposed in the UI, but I'm not sure that shell/no-shell matters for that. | 05:29 |
| persia | 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. | 05:30 |
| wgrant | 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 |
| persia | wgrant: Is there any necessary relation between a packageset owner and people with access to a packageset? | 06:52 |
| wgrant | persia: None. | 06:54 |
| persia | Cool. I was worried there for a bit. | 06:54 |
| wgrant | The current owner is in all cases the techboard. | 06:55 |
| persia | That matches my expectations. | 06:55 |
| lifeless | when does motu lose upload-everywhere-but-main ? | 07:00 |
| lifeless | e.g. when should I make a push for core dev | 07:00 |
| persia | lifeless: As soon as it can be implemented. The necessary decisions have already been taken. | 07:01 |
| lifeless | would you cheer for me? | 07:01 |
| persia | 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:01 |
| * lifeless isn't about to cry over mono | 07:02 | |
| wgrant | So some of the mono stuff will be in the core exclusive set? | 07:02 |
| persia | lifeless: I've sponsored none of your uploads to main, nor done close code review on any of them, so no. | 07:02 |
| persia | 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 |
| lifeless | persia: :(. You know there is the 'good person' aspect :P | 07:02 |
| persia | lifeless: Don't try to convince me to change my criteria for approving core devs :p | 07:03 |
| lifeless | persia: not going to! | 07:03 |
| persia | 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:03 |
| lifeless | persia: my feeling is I don't do enough regular work; I've been kindof-meaning-to for ages | 07:04 |
| wgrant | persia: So membership in a package set now excludes generalists? I thought it was explicitly decided that that was a bad thing. | 07:04 |
| persia | For the medium future, MOTU will only get access to *more* packages when components go away. | 07:04 |
| persia | wgrant: No, it specifically excludes MOTU, based on the spec providing a definition for MOTU in the new world. | 07:05 |
| wgrant | Ah, I guess I should keep more up to date with TB minutes. | 07:05 |
| * wgrant reads. | 07:05 | |
| persia | 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 |
| wgrant | persia: Good. That had always been my largest concern about the reorg. | 07:06 |
| persia | 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 |
| wgrant | But I guess it needs Soyuz changes. | 07:07 |
| wgrant | Definitely. | 07:07 |
| persia | Yep, but that's the future. | 07:07 |
| persia | 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:07 |
| lifeless | also, we should get the bzr packaging team in debian to have access to bzr packages in ubuntu nder a packageset | 07:08 |
| persia | 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:08 |
| lifeless | persia: packagesets aren't active yet though, right? | 07:09 |
| * dmb growls | 07:09 | |
| persia | lifeless: They are indeed, and have been since December, at least. | 07:09 |
| lifeless | \o/ | 07:09 |
| persia | lifeless: But the first packageset not based on an Ubuntu Flavour was approved last Tuesday. | 07:10 |
| wgrant | There are lots of LP glitches, too. | 07:10 |
| persia | Well, second actually. The first was kernel stuff, but that's kinda special (and kernel stuff was technically the first ever packageset) | 07:10 |
| persia | (that was about a year ago, I think, but I'd have to check logs for a precise timing) | 07:11 |
| pitti | Good morning | 07:12 |
| pitti | tkamppeter_: o/ | 07:12 |
| lifeless | persia: so is mono a 'restricted package set' | 07:13 |
| lifeless | ? | 07:13 |
| persia | lifeless: No. There are currently no restricted package sets. I hope we can continue with that. | 07:13 |
| persia | A restricted packageset implies we have failed in our selection criteria for core-dev. | 07:13 |
| lifeless | persia: so I don't understand why motu wouldn't be able to upload to them, if we wante dto. | 07:14 |
| lifeless | https://wiki.ubuntu.com/ArchiveReorganisation/Permissions | 07:14 |
| wgrant | Because MOTU will be redefined. | 07:14 |
| lifeless | claims two things: | 07:14 |
| wgrant | That page is out of date | 07:14 |
| lifeless | restriced package sets allow looser criteria for core-dev | 07:14 |
| wgrant | This is what I hadn't realised until a few minutes ago. | 07:14 |
| persia | https://wiki.ubuntu.com/Specs/LucidMOTU | 07:14 |
| lifeless | /argh/ | 07:14 |
| persia | wgrant: *was* redefined. | 07:14 |
| wgrant | persia: Well, the definition is approved but not in place. | 07:14 |
| persia | wgrant: Soyuz bugs aside it is :) | 07:15 |
| persia | But yeah. | 07:15 |
| persia | Anyway, MOTU needs another month or two to adjust to the new team model anyway. | 07:15 |
| * persia repeatedly advocates redundancy with favor and encourages repetition | 07:16 | |
| persia | And one can hope that we have some clear definition of what to do in Soyuz first. | 07:16 |
| lifeless | persia: I cannot parse the 'definition of responsibility' section | 07:16 |
| persia | As we discussed earlier, the issue of NEW source packages is still messy. | 07:16 |
| persia | 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 |
| lifeless | (build || run)-deps | 07:17 |
| persia | MOTU doesn't have responsibility for any of that: it belongs to people who volunteered to make that stuff work. | 07:17 |
| lifeless | transitive, I presume | 07:17 |
| persia | 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 |
| lifeless | what is a 'explicit separated upload permission' | 07:18 |
| lifeless | and how is it different to 'per-package upload rights' | 07:18 |
| persia | It's upload rights for a packageset | 07:19 |
| lifeless | the set-of-package language isn't a problem to parse | 07:19 |
| lifeless | its the undefined terms | 07:19 |
| lifeless | AIUI a packageset is the result of seed processing | 07:19 |
| persia | 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 |
| lifeless | but what is a 'non explicit' seperated upload perission | 07:19 |
| persia | lifeless: Yes, but not all seeds generate packagesets. | 07:20 |
| persia | Or rather packagesets that have separate upload permission. | 07:20 |
| lifeless | what would an 'explicit unified upload permission' be | 07:20 |
| persia | Two examples that come to mind immediately are ubuntustudio and lubuntu | 07:20 |
| persia | 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:21 |
| lifeless | 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 |
| lifeless | 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:22 |
| ArneGoetje | persia: done | 07:23 |
| persia | ArneGoetje: Thank you :) | 07:23 |
| lifeless | 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 |
| persia | 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 |
| lifeless | I think understanding is important, so that folk wanting to work on a package do not exclude MOTU by mistake. | 07:23 |
| lifeless | persia: I was on leave in december, and horribly sick in january | 07:24 |
| lifeless | persia: no internet == no feedback | 07:24 |
| persia | lifeless: If a package has someone looking after it in any organised way, MOTU isn't responsible for it. | 07:24 |
| persia | lifeless: Understand. Please consider my comment a lament rather than criticism. | 07:24 |
| ArneGoetje | persia: I have issued a MIR for poppler-data | 07:25 |
| lifeless | 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 |
| lifeless | please excuse my keyboard | 07:25 |
| persia | 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 |
| lifeless | ok | 07:26 |
| lifeless | up to you | 07:26 |
| lifeless | my concrete issue is this: | 07:26 |
| persia | lifeless: Do you think the lack of an interpretation section is blocking in some way? | 07:26 |
| lifeless | I can't decide if its better for bzr packages to have a [type 1] or [type 2] or [type N] request made | 07:26 |
| lifeless | 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:27 |
| lifeless | 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 |
| persia | 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 |
| lifeless | the second way is that unless people know what the options are - clearly and fully - they can't figure out the implications | 07:28 |
| lifeless | persia: the lucid spec implies at least two types | 07:28 |
| lifeless | seeds-with-explicit-seperated-upload-permission | 07:29 |
| persia | 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:29 |
| lifeless | per-package-upload-rights | 07:30 |
| lifeless | + seed management is shaded as a different thing | 07:30 |
| lifeless | sure | 07:30 |
| persia | Oh, right. Those are different. per-package-upload only applies to a person: it doesn't otherwise affect a package. | 07:30 |
| slangasek | 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:39 |
| dholbach | good morning | 07:41 |
| didrocks | 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) | 08:41 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | pitti, hi | 08:43 |
| === sabdfl1 is now known as sabdfl | ||
| zgreg | https://bugs.launchpad.net/ubuntu/+source/libass/+bug/529860 | 09:13 |
| ubottu | Launchpad bug 529860 in libass "Update libass to bugfix release 0.9.9" [Undecided,New] | 09:13 |
| zgreg | am I doing anything wrong or does nobody care because the package isn't really maintained from Ubuntu's side? | 09:14 |
| cjwatson | slangasek: thanks | 09:14 |
| lifeless | there are more bugs than people to solve them. | 09:14 |
| zgreg | of course. | 09:15 |
| lifeless | so to make the update happen quicker, prepare the change and propose it to ubuntu-sponsors | 09:15 |
| zgreg | I'd do it myself if I had the necessary privileges | 09:15 |
| lifeless | you can do everything except the upload itself | 09:16 |
| zgreg | how so? put it into a PPA, for example? | 09:17 |
| lifeless | do the update on your machine and check it builds, installs properly etc | 09:17 |
| lifeless | you could use a PPA to do this | 09:17 |
| lifeless | then attach the necessary new files to the bug report | 09:18 |
| lifeless | and follow the normal sponsorship process to get a -sponsor to upload it | 09:18 |
| arand | zgreg: The attached debdiff is the key point, PPA allows for easy testing | 09:18 |
| persia | Generally we look for a diff.gz (or similar) that includes the packaging of the new vesion. | 09:18 |
| lifeless | 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:18 |
| arand | zgreg: Hang on, ignore me... | 09:19 |
| persia | I generally don't like to see the new orig tarball, preferring to use a watch file or get-orig-source rule. | 09:20 |
| Laney | I usually construct the diff for review myself using interdiff | 09:21 |
| zgreg | is this procedure documented somewhere? | 09:25 |
| lifeless | there are two parts | 09:25 |
| lifeless | standard development - thats documented under the packaging docs | 09:25 |
| lifeless | and sponsorship - also documented | 09:26 |
| lifeless | all on the wiki | 09:26 |
| slangasek | cjwatson: btw, do you know why component-mismatches is empty? | 09:38 |
| cjwatson | IOError: [Errno 2] No such file or directory: '/srv/launchpad.net/ubuntu-archive/ubuntu-germinate//all_netbook_lucid_i386' | 09:39 |
| pitti | apw: FYI, -15 kernel NEWed now | 09:39 |
| cjwatson | Running germinate... ..gzip: /srv/launchpad.net/ubuntu-archive/ubuntu/dists/lucid/main/binary-lpia/Packages.gz: No such file or directory | 09:40 |
| cjwatson | D'OH | 09:40 |
| didrocks | 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 |
| apw | pitti, most excellent thanks for the heads up | 09:40 |
| cjwatson | brought up with soyuz folks | 09:41 |
| persia | 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:41 |
| didrocks | persia: 4, for 3 Mib of deb. The most issue is that it has been demoted, I should have a look there. | 09:43 |
| persia | didrocks: IIRC it got demoted for no longer being seeded | 09:46 |
| persia | didrocks: But yeah, just stick it in: otherwise the experience will be poorer only for people with a single architecture. | 09:46 |
| didrocks | 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:47 |
| persia | Have fun with MIRs :) | 09:48 |
| cjwatson | slangasek: fixed for next publisher run, thanks to mthaddon and bigjools | 09:48 |
| didrocks | persia: ahah, I got used to ^^ | 09:48 |
| asac | didrocks: does it use mono? | 09:49 |
| asac | ;) | 09:49 |
| cjwatson | whoops, I broke 'man -l' for uncompressed files | 09:49 |
| didrocks | asac: if you really want, I can bring f-spot back :p | 09:49 |
| didrocks | less work for me ;) | 09:49 |
| asac | lol | 09:56 |
| ogra | seb128, fyi, with todays upgrade evo seems to behave again, no 100% CPU usage anymore for me | 10:01 |
| seb128 | ogra: ok good | 10:01 |
| nigel_nb | siretart, siretart`: just letting you know about bug 530481 has nvidia-185-libvdpau-dev as build-dep which is causing the issue | 10:06 |
| ubottu | 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:06 |
| cjwatson | right, 'man -l' fixed | 10:29 |
| tkamppeter | pitti, hi | 10:32 |
| pitti | hi tkamppeter, wie gehts? | 10:32 |
| tkamppeter | pitti, everything OK, you asked for me in the morning. | 10:34 |
| pitti | tkamppeter: ah, because you pinged me in the evening when I was already away :) | 10:35 |
| tkamppeter | 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:35 |
| tkamppeter | s/1.4/1.3/ | 10:36 |
| pitti | hm, wasn't this the entire point of that avahi patch? | 10:36 |
| pitti | tkamppeter: would it work without the patch, when using the compat api (as upstream does)? | 10:36 |
| tkamppeter | pitti, is there really no chance to compile CUPS using its native DNS-SD support? | 10:36 |
| mpt | mvo, good morning, thanks for the instructions about how to try the subcategories | 10:36 |
| tkamppeter | pitti, one should try it. Perhaps it works with patches (also on the Avahi side). | 10:37 |
| pitti | tkamppeter: well, you tell me :) you added it in the first place | 10:37 |
| pitti | but the changelog says that cups doesn't build with avahi | 10:37 |
| pitti | without the patch | 10:37 |
| tkamppeter | 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:38 |
| tkamppeter | pitti, perhaps one can get it to work with the compat API, perhaps now where the compat API development went on. | 10:40 |
| tkamppeter | 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:41 |
| pitti | tkamppeter: ah, so that's for client-side detection, but not for server-side broadcasting; understood | 10:43 |
| ogra | 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:45 | |
| Q-FUNK | pitti: morning! is there any way you could help with https://bugs.launchpad.net/ubuntu/+source/apport/+bug/528680 | 10:47 |
| ubottu | Launchpad bug 528680 in apport "apport-collect repeatedly crashes" [Undecided,New] | 10:47 |
| tkamppeter | pitti, .configure finds my installed compat API. | 10:49 |
| tkamppeter | pitti, problem is that it cannot determine the version of the dns_sd API. | 10:51 |
| tkamppeter | pitti, config.log says 'kDNSServiceFlagsShareConnection' undeclared | 10:52 |
| mvo | mpt: sure, np - I hope it helps you to get started, if anything is odd, please let me know (might be bugs etc) | 10:56 |
| pitti | tkamppeter: seems the old avahi compat interface simply doesn't implement this? | 11:01 |
| pitti | Q-FUNK: the error message can presumably be made more friendly, yes | 11:02 |
| Q-FUNK | pitti: actually, the issue is that apport-collect is currently borken. | 11:03 |
| pitti | Q-FUNK: I just ran apport-collect 528680, and it worked fine | 11:07 |
| Q-FUNK | pitti: ok, so what do I and 10 other people (found in a duplicate bug) are missing? | 11:08 |
| pitti | it still doesn't work for you? | 11:08 |
| pitti | Q-FUNK: it's ultimately bug 336866; I already have lots of workarounds for that, but apparently not enough | 11:09 |
| ubottu | 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:09 |
| Q-FUNK | pitti: ok. recommendations to work around the issue and succeed at attaching the extra debug info? | 11:10 |
| pitti | Q-FUNK: I'm afraid there's no workaround; it needs a code change to apply a workaround in apport | 11:10 |
| Q-FUNK | ok | 11:11 |
| Q-FUNK | so the only other alternative is to file a new bug, with the new apport hooks for that particular package added? | 11:12 |
| pitti | that should work, yes | 11:12 |
| tkamppeter | pitti, is it possible that the DNS-SD API which CUPS is using does not exist as free software? | 11:13 |
| pitti | tkamppeter: could be; after all, it's written against Apple's APIs | 11:13 |
| tkamppeter | pitti, this would mean that fom CUPS 1.3 top 1.4 the DNS-SD broadcasting feature got removed from Linux. | 11:15 |
| tkamppeter | pitti, how should such a regression be handles? | 11:17 |
| pitti | tkamppeter: (1) shrugging, (2) adding the new API to avahi; I don't see another way? | 11:18 |
| mpt | 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:20 |
| tkamppeter | 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:43 |
| pitti | 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 |
| pitti | tkamppeter: svn blame should find the patch which introduced the usage of that symbol | 11:46 |
| mvo | 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:48 |
| mvo | 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 |
| mvo | (wildcard searches) | 11:52 |
| mpt | mvo, what do we need "*foo*" searches for? | 11:53 |
| mvo | background picutres are speced as "*-backgrounds*" | 11:55 |
| mvo | themes as "*-themes" | 11:55 |
| mpt | mvo, that doesn't need to be a live search, that's a one-time categorization whenever Packages.gz changes, right? | 11:55 |
| mvo | the ttf* and otf* is no problem | 11:55 |
| mpt | I thought xapian was just for when you're typing stuff in the search field | 11:56 |
| === MacSlow is now known as MacSlow|lunch | ||
| mvo | 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:57 |
| mpt | mvo, if you kept them all as xapian queries, I imagine the query involved in fixing bug 507042 would be hideous :-) | 11:58 |
| ubottu | 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:58 |
| mvo | mpt: not really, its the "Type" that we can use to filter out graphical vs non-graphical. | 11:59 |
| mvo | i.e. there is a property attached to each items for this | 12:00 |
| mpt | mvo, well the summary is a bit out of date, it's more about "appears in any other department vs. doesn't" | 12:00 |
| mpt | e.g. fonts shouldn't appear in "System" because they're appearing in "Fonts" | 12:00 |
| mpt | (actually, the summary is correct, but it's only a subset of the problem) | 12:01 |
| mvo | correct, for this using live querries is tricky | 12:01 |
| mvo | (see also the mapping of other->system) | 12:01 |
| mvo | same problem | 12:01 |
| mvo | 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:06 |
| mpt | 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:08 |
| mpt | 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:09 |
| mvo | 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 |
| mpt | undoubtedly :-) | 12:11 |
| didrocks | 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:12 |
| cjwatson | hm, really? that's odd | 12:13 |
| cjwatson | didrocks: ok, just do what you were doing then, we'll refactor it later | 12:13 |
| didrocks | 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:14 |
| pecisk | hi people, will NetworkManager 0.8 will make a cut into Lucid, or you will stick with 0.7.x? | 12:16 |
| asac | pecisk: huh? | 12:18 |
| asac | pecisk: 0.8 final is in already | 12:18 |
| asac | and we had 0.8-pre in karmic already (e.g. 0.7.9xx) | 12:18 |
| pecisk | missed that | 12:18 |
| pecisk | allright, thanks for answer | 12:18 |
| tjaalton | looks like the dhclient-{enter,exit}-hooks aren't run when network-manager is used? | 12:27 |
| tjaalton | though it appears to use dhclient | 12:28 |
| tjaalton | also, mounting network shares is racy, since the DNS isn't necessarily functional yet | 12:29 |
| tjaalton | but where to file a bug? | 12:29 |
| pecisk | 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 |
| ubottu | Launchpad bug 461815 in linux "9.10 rc livecd takes a long time to boot, showing errors" [Undecided,New] | 12:44 |
| === Tonio__ is now known as Tonio_ | ||
| tjaalton | ok so mountall is racy by design.. how confusing | 12:52 |
| ogra | makes booting more exciting that way :) | 12:53 |
| tjaalton | and debugging too | 12:54 |
| === MacSlow|lunch is now known as MacSlow | ||
| zul | is it possible for someone to binary new for php 5.3? | 13:57 |
| === Eren is now known as Guest91686 | ||
| zul | Riddell: ping can you binary new php 5.3 for me? | 14:25 |
| Riddell | oh aye, it's my admin day so it is | 14:26 |
| Riddell | 151 packages in New queue, good to know we take feature freeze seriously | 14:27 |
| Riddell | zul: where's the feature freeze exception for this? | 14:30 |
| zul | Riddell: https://bugs.launchpad.net/bugs/527286 | 14:33 |
| ubottu | Launchpad bug 527286 in php5 "FFE for PHP 5.3" [Wishlist,Fix released] | 14:33 |
| Riddell | groovy, accepted | 14:36 |
| === robbiew_ is now known as robbiew | ||
| zul | Riddell: thanks | 14:43 |
| persia | geser: nixternal: soren: We'd like your help in -meeting :) | 15:05 |
| tkamppeter | pitti, I succeeded to compile CUPS 1.4 without RH patch and without adding any new or Universe package. | 15:07 |
| pitti | tkamppeter: yay! you could drop teh usage of the new symbols? | 15:07 |
| tkamppeter | pitti, I simply do s/kDNSServiceFlagsShareConnection/kDNSServiceFlagsShared/ on the whole source tree and CUPS compiles. | 15:07 |
| tkamppeter | There was only one offending symbol. | 15:08 |
| pitti | sweet | 15:08 |
| tkamppeter | 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:25 |
| Keybuk | tkamppeter: BZZT | 15:27 |
| Keybuk | mDNSResponder is Apache 2.0 | 15:27 |
| Keybuk | like most of Apple's open source stuff | 15:27 |
| Keybuk | we already have a Multicast DNS responder though, Avahi | 15:27 |
| Keybuk | if that's missing a feature, get it added to Avahi | 15:27 |
| ogra | Keybuk, is there some guarantee that if i boot lucid with devtmpfs.mount=0 udev will cope ? | 15:28 |
| Keybuk | ogra: udev should cope just fine | 15:28 |
| ogra | cool ! | 15:28 |
| Keybuk | udev doesn't really care | 15:28 |
| Keybuk | you may encounter bugs with other things | 15:29 |
| === dottedma1 is now known as dottedmag | ||
| Keybuk | but they are bugs, and you should file them, and I'll fix them | 15:29 |
| ogra | 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:29 |
| Keybuk | ogra: why devtmpfs.mount=0 ? | 15:30 |
| Keybuk | that doesn't really make sense | 15:30 |
| === dottedmag is now known as dottedma1 | ||
| Keybuk | that's only used if you don't have an initramfs | 15:30 |
| === dottedma1 is now known as dottedmag | ||
| Keybuk | and even with that, devtmpfs is still "supported" so will be just mounted by mountall | 15:30 |
| ogra | because qemu doesnt boot without setting it and i dont use initramfs *and* use jaunty/karmic | 15:30 |
| Keybuk | why doesn't qemu boot? | 15:30 |
| Keybuk | all that option does is cause /dev to be mounted by the kernel | 15:31 |
| ogra | it moans about /dev ... i dont have the exact error handy atm | 15:31 |
| ogra | right, i suspect udev tries to create device nodes that are already there | 15:31 |
| Keybuk | no, udev copes perfectly with devtmpfs being mounted | 15:31 |
| ogra | if you really want to support that case i can file a bug | 15:31 |
| ogra | but its a very special corner case | 15:31 |
| Keybuk | in fact, even if you use devtmpfs.mount=0 - devtmpfs is mounted *before* udevd starts | 15:32 |
| ogra | and devtmpfs.mount=0 works just fine | 15:32 |
| Keybuk | right, but I want to understand this issue | 15:32 |
| Keybuk | you're telling me something *very* strange | 15:32 |
| ogra | by what is it mounted ? | 15:32 |
| Keybuk | ogra: mountall | 15:32 |
| ogra | hmm, but not in karmic | 15:32 |
| ogra | or jaunty | 15:32 |
| ogra | my probs are in jaunty and karmic with a lucid kernel and no initramfs | 15:32 |
| Keybuk | karmic and jaunty won't understand devtmpfs.mount=0 either | 15:33 |
| ogra | the kernel does | 15:33 |
| Keybuk | oh, sorry | 15:33 |
| ogra | apparently | 15:33 |
| Keybuk | you did not make *that* clear | 15:33 |
| ogra | i just wanted to know if lucid would cope if i keep devtmpfs.mount=0 a permanent setting :) | 15:33 |
| ogra | so i dont have to special case karmic and jaunty | 15:33 |
| ogra | but you answered that already | 15:34 |
| ogra | :) | 15:34 |
| Keybuk | I'm just wondering why jaunty and karmic fail here | 15:34 |
| Keybuk | karmic should see that /dev is already in the mount table | 15:34 |
| ogra | i think i had some bug with error messages ... | 15:34 |
| Keybuk | aha! | 15:34 |
| * ogra digs | 15:34 | |
| Keybuk | but then karmic won't copy /lib/udev/devices over I guess | 15:34 |
| Keybuk | so you might be missing /dev/pts and /dev/shm | 15:34 |
| ogra | yeah, something like that was in the error msg | 15:35 |
| Keybuk | yeah that makes sense | 15:35 |
| Keybuk | not sure why jaunty would fail | 15:35 |
| ogra | sigh, why did LP drop the "show all bugs ever reported" thingie | 15:35 |
| Keybuk | lucid with devtmpfs.mount=0 and no initramfs will have a brief period where you don't know what *is* on /dev | 15:36 |
| Keybuk | as long as you have a /dev/null and /dev/console node in there, you should be ok | 15:36 |
| ogra | http://ynezz.true.cz/qemu.png | 15:36 |
| Keybuk | mountall will mount devtmpfs on /dev and then carry on | 15:37 |
| ogra | thats the error i got for the karmic bug | 15:37 |
| Keybuk | Upstart uses /proc/self/fd now, rather than /dev/fd, to avoid other complications | 15:37 |
| Keybuk | ogra: yay, yeah that fits my understanding of what karmic would do -- I'd be interested in seeing the jaunty error too | 15:37 |
| ogra | i dont have a report for jaunty atm | 15:37 |
| ogra | just IRC reports where i told people to try devtmpfs.mount=0 which helped | 15:38 |
| tkamppeter | Keybuk, in Avahi the kDNSServiceFlagsShareConnection functionality is not included, an upstream bug is already reported (http://www.avahi.org/ticket/303) but not fixed. | 15:38 |
| Keybuk | tkamppeter: I'm sure upstream welcomes patches | 15:38 |
| * ogra really hopes people will soon stop building jaunty rootfses with rootstock ... | 15:39 | |
| Keybuk | ogra: I wonder whether jaunty fails in Upstart somewhere | 15:39 |
| Keybuk | Upstart in jaunty does rely on /dev/fd being a symlink to /proc/self/fd | 15:39 |
| ogra | i'll try a testbuild | 15:39 |
| Keybuk | devtmpfs won't have that symlink | 15:39 |
| shtylman_ | \sh: anything new on bug: #522106 ? its a blocker for #519996 and likewise the freeze exception request for perftools | 15:40 |
| Laney | Can TB members please comment on the proposed CLI/Mono packages that I emailed out last week? | 15:43 |
| Keybuk | ogra: of course, Upstart should then just pipe the whole shell script on the command-line - but there may be an issue there somewhere | 15:44 |
| Keybuk | oh, hmm, jaunty has 0.3.9 ... wonder whether that didn't do that | 15:44 |
| ogra | Keybuk, i'm building an ubuntu-minimal now ... will take 30min or so | 15:44 |
| ogra | i'll tell you waht i see with or without devtmpfs | 15:44 |
| Keybuk | thanks | 15:44 |
| === dendro-afk is now known as dendrobates | ||
| === Mamarok_ is now known as Mamarok | ||
| james_w | mvo: we won't be having the new python-apt API in lucid? | 16:04 |
| mvo | james_w: I hope so, I did a bunch of work on this last week, but there are some small compat issues left | 16:05 |
| james_w | oh ok | 16:05 |
| james_w | I got a patch to use it, and wondered if I should implement compatibility with the old one so not to diverge from Debian | 16:05 |
| mvo | james_w: lets talk tomorrow or so about it, its definitely a goal of me, because it will make the next LTS upgrade much less painful | 16:06 |
| mvo | a bit unfortunate timing | 16:07 |
| james_w | yeah | 16:07 |
| mvo | (after FF, I will need a FFe) | 16:07 |
| james_w | not a problem my end | 16:07 |
| james_w | I'll probably do it either way to facilitate backporty | 16:08 |
| pitti | slangasek, Keybuk: is the hard plymouth dependency in cryptsetup really necessary? wouldn't it just ask for the password on VT if plymouth isn't installed? (it used to in the past) | 16:16 |
| Keybuk | pitti: I would argue cryptsetup's VT code should be ripped out | 16:18 |
| Keybuk | and it should hard-depend on Plymouth | 16:18 |
| Keybuk | otherwise it's always going to be running the risk of stealing VTs from other things, including X! | 16:18 |
| pitti | Keybuk: X? | 16:20 |
| pitti | X should certainly not start yet if things in /etc/crypttab (root, /home) aren't mounted yet | 16:20 |
| ogra | Keybuk, jaunty seems to cope even without devtmpfs.mount=0 being set | 16:21 |
| Keybuk | ogra: cool, that makes sense | 16:21 |
| Keybuk | pitti: why? | 16:21 |
| pitti | Keybuk: either way, once the scripts only talk to plymouth and nothing else, the depedency is probably justified; but I thuoght the text fallback was still in | 16:21 |
| Keybuk | pitti: you could put nobootwait in fstab for /home | 16:21 |
| Keybuk | then have cryptsetup crash X :) | 16:21 |
| pitti | how would you enter the home password while gdm is already up? | 16:22 |
| Keybuk | one of the whole reasons for picking plymouth was that it solves the entire "we need to ask for things during boot" problem | 16:22 |
| Keybuk | so why is the hard dependency a problem? | 16:22 |
| ogra | Keybuk, btw, id /dev/root responsibility of the kernel or udev ? (its missing in lucid and forces me to add an entry for / to fstab to boot) | 16:22 |
| ogra | s/id/is/ | 16:22 |
| pitti | I can't purge plymouth, at least not without purging cryptsetup | 16:23 |
| pitti | Keybuk: so plymouth has a kind of X overlay where cryptsetup could ask for the password while X is already running? | 16:23 |
| apw | is there a process for getting people approved to be ops on specific channels? | 16:24 |
| Keybuk | pitti: it's supposed to have | 16:24 |
| pitti | but I need cryptsetup to do udisks development and encrypted usb keys, etc., so it's inconvenient to have it not installed | 16:24 |
| pitti | Keybuk: interesting | 16:24 |
| Keybuk | pitti: why do you want to purge plymouth? | 16:24 |
| pitti | Keybuk: I want to have bootable systems? :-) | 16:24 |
| Keybuk | ogra: nothing makes /dev/root | 16:24 |
| Keybuk | pitti: you could help *fix* things instead, y'know :p | 16:24 |
| ogra | it used to be there in karmic | 16:24 |
| Keybuk | ogra: probably by chance/accident/fluke | 16:25 |
| ogra | hmm | 16:25 |
| zgreg | what does plymouth do without a framebuffer, anyway? | 16:25 |
| Keybuk | zgreg: there's always a framebuffer | 16:25 |
| apw | Keybuk, ogra isn't /dev/root the fake name of the device that the original ramfs is mounted from? | 16:25 |
| persia | Keybuk: Even on systems with no video out? | 16:25 |
| ogra | apw, i thought so too | 16:26 |
| Keybuk | persia: systems with no video out have a serial console - and plymouth can do text on that | 16:26 |
| ogra | apw, which is why i'm surprised that its gone in lucid | 16:26 |
| Keybuk | apw: only if you use lilo and have ROOT=8:1 or something | 16:26 |
| ogra | even mountall has it in its defaults | 16:26 |
| apw | ogra, i am not sure i ever existed did it? | 16:26 |
| persia | Keybuk: Not necessarily | 16:27 |
| * ogra boots the jaunty install he just built | 16:27 | |
| ogra | lets see | 16:27 |
| pitti | Keybuk: can't be everywhere... I got as far as checking fuser, but beyond that I have no clue where to start; any suggestions? | 16:27 |
| * persia has a system with neither video out nor serial console | 16:27 | |
| apw | ogra, it doesn't represent the real root filesystem | 16:27 |
| Keybuk | ogra: mountall always gets root from mountinfo - whatever is in fstab as the device means nothing ;-) | 16:27 |
| Keybuk | persia: you have some kind of console :p | 16:27 |
| ogra | Keybuk, well, all i can say is that lucid doesnt boot my qemu armel images if i dont have an entry in fstab, karmic and jaunty didnt need it | 16:28 |
| apw | ogra, i don't even see it mentioned in /proc/mounts any more ...so its not clear why you'd be needng it when booted | 16:28 |
| Keybuk | ogra: kernel mounts root, not mountall ;-) | 16:28 |
| persia | Keybuk: Really, I don't. I can solder in a serial console, but it's an optional extra kit to buy. | 16:28 |
| ogra | god, jaunty booted sloooow | 16:28 |
| Keybuk | persia: you have a console device in the kernel, even if it's being faked | 16:28 |
| persia | And plymouth spits text at that, and all is good? | 16:29 |
| ogra | hmm, right, jaunty doesnt have /dev/root either | 16:29 |
| persia | (even if I never see it) | 16:29 |
| Keybuk | ogra: to my knowledge, the only thing that ever made /dev/root is initramfs-tools if you boot with the really old boot protocol | 16:29 |
| apw | so where the heck is anyone getting that string from | 16:29 |
| ogra | so what prevents me from booting lucid without fstab entry | 16:29 |
| Keybuk | we support it still | 16:29 |
| Keybuk | but nothing *makes* it if you're using anything more recent | 16:29 |
| Keybuk | like, say, grub | 16:29 |
| Keybuk | or grub2 | 16:29 |
| apw | Keybuk, ogra i bet its initrd format things which use it | 16:30 |
| Keybuk | possibly | 16:30 |
| Keybuk | but again, it's up to them to mknod it | 16:30 |
| zgreg | I don't like that plymouth has so many dependencies | 16:30 |
| ogra | i dont use initrd with qemu ... so that might be | 16:30 |
| apw | don't your arm things use that crap? | 16:30 |
| ogra | but still i didnt use initrd with jaunty/karmic either | 16:30 |
| ogra | and there i could boot without fstab entry | 16:31 |
| Keybuk | ogra: which filesystem is fstab on? | 16:31 |
| apw | ogra, is it in your /proc/mounts list? | 16:31 |
| ogra | Keybuk, ext2 | 16:31 |
| Keybuk | ogra: no, I mean which filesystem | 16:31 |
| Keybuk | is it on the "root filesystem" by any chance? | 16:31 |
| ogra | /dev/sda | 16:31 |
| * ogra doesnt get the question | 16:31 | |
| Keybuk | because you're telling me that you can't mount the root filesystem unless details of it are in a file which you can't access until it's mounted ;-) | 16:31 |
| === jamie is now known as Guest28097 | ||
| apw | cirtainly that must be occuring in userspace | 16:32 |
| ogra | Keybuk, i cant *boot* :) unless i add a fstab entry | 16:32 |
| apw | if mountall is complaining about it ... as we mounted it to talk to it | 16:32 |
| ogra | so / doesnt get mounted ... | 16:32 |
| Keybuk | mountall won't care | 16:32 |
| === dendrobates is now known as dendro-afk | ||
| Keybuk | it's possible it won't get remounted rw without an fstab entry | 16:32 |
| ogra | and i looked at mountall defaults where i found 7dev/root | 16:32 |
| apw | now that is believeable | 16:32 |
| Keybuk | and won't get fsck run ;) | 16:32 |
| ogra | which made me think its that ... | 16:33 |
| Keybuk | nah, that field for the root filesystem is utterly ignored | 16:33 |
| Keybuk | I just stuck /dev/root in there to support lilo booters | 16:33 |
| Keybuk | which will have /dev/root in mountinfo for it, so it matches | 16:33 |
| apw | Keybuk, of course the world is utterly different on lucid if you don't have an initramfs right ... as we do that devtmpfs automount magic | 16:33 |
| Keybuk | apw: I still want the kernel to automount /proc and /sys ;-_) | 16:34 |
| apw | Keybuk, heh | 16:34 |
| ogra | apw, well, it works fine without initrd ... apart from the fstab entry i need now | 16:34 |
| Keybuk | apw: though I've worked around that now by having init mount /proc and /sys ,g> | 16:34 |
| Keybuk | ogra: what happens without the fstab entry? | 16:35 |
| ogra | let me fins a lucid qemu image :) | 16:35 |
| ogra | *find even | 16:35 |
| Keybuk | because without an entry in /etc/fstab mountall will use the one in /lib/init/fstab instead | 16:35 |
| Keybuk | and without that, it'll use what's in /proc/self/mountinfo | 16:35 |
| Keybuk | so it's utterly impossible to end up without something ;) | 16:35 |
| apw | ogra, also what is the entry as you need it to be to be able to boot? | 16:36 |
| ogra | apw, any entry for / works ... (device/partition or uuid) | 16:36 |
| Keybuk | ogra: what if you just copy the entry from /lib/init/fstab ? | 16:37 |
| Keybuk | does that work? | 16:37 |
| ogra | let me quickly try to reproduce i currenbtly only have images with ftsab entries | 16:37 |
| flower | I tried to build the devel package fluid for ubuntu on the opensuse buildservice, but it looks like something is wrong in the code: | 16:37 |
| flower | https://build.opensuse.org/package/live_build_log?arch=i586&package=fluid&project=home%3Aroooz%3Akarmic&repository=xUbuntu_9.10 | 16:37 |
| ogra | Keybuk, first thing i see is that ureadahead terminates with 3 | 16:38 |
| ogra | Keybuk, and it hangs forever afterwards ... likely because it cant remount rw | 16:40 |
| Keybuk | if it hasn't been told to remount rw, it won't wait to do it | 16:40 |
| ogra | how would i tell it to ? | 16:40 |
| ogra | apart from fstab | 16:40 |
| Keybuk | that's my point | 16:41 |
| ogra | or better, how do karmic and jaunty do handle that | 16:41 |
| ogra | since it doesnt occur there | 16:41 |
| Keybuk | add --debug to mountall | 16:41 |
| ogra | god ! | 16:44 |
| ogra | can i make it log somewhere ? | 16:44 |
| ogra | it ends with: | 16:45 |
| mathiaz | could some from ubuntu-archive unsubscribe ubuntu-archive from bug 530468? | 16:45 |
| ubottu | Launchpad bug 530468 in vlan "[FFE] Build udeb for vlan" [Undecided,New] https://launchpad.net/bugs/530468 | 16:45 |
| ogra | try_mount / waiting for device | 16:45 |
| ogra | try_mount /tmp waiting for device | 16:45 |
| ogra | err waiting for / in the last line | 16:45 |
| Keybuk | ok, interesting | 16:47 |
| Keybuk | could you boot with init=/bin/bash | 16:47 |
| Keybuk | mount /proc | 16:47 |
| Keybuk | and grab the root line out of /proc/self/mountinfo and paste it here | 16:47 |
| ScottK | mathiaz: Done. | 16:48 |
| nixternal | cjwatson, persia: sorry for not being at the meeting...I am quite busy this week due to my aunt passing away | 16:48 |
| mathiaz | ScottK: thank you | 16:48 |
| ogra | Keybuk, btw i boot with: root=/dev/sda mem=256M ro (/me goes grabbing proc, one sec) | 16:49 |
| ogra | Keybuk, 14 1 8:0 / / ro,relatime - ext3 /dev/root ro,errors=continue,data=ordered | 16:51 |
| Keybuk | ok, interesting | 16:51 |
| Keybuk | is /dev mounted? | 16:51 |
| ogra | ls /dev | 16:51 |
| ogra | bah, damned focus ! | 16:51 |
| Keybuk | and is there a /dev/root in there? | 16:51 |
| ogra | devtmpfs is mounted on dev | 16:52 |
| ogra | (init=/bin/bash ...) | 16:52 |
| Keybuk | and is there a /dev/root in there? | 16:52 |
| ogra | nope | 16:52 |
| Keybuk | ok, great | 16:52 |
| Keybuk | so your problem is: | 16:53 |
| Keybuk | - you had the kernel mount the root filesystem directly | 16:53 |
| Keybuk | - rather than passing the actual root= argument, the kernel just claims it mounted /dev/root | 16:53 |
| ogra | right with the root= line | 16:53 |
| Keybuk | - there is no /dev/root in the devtmpfs the kernel created | 16:53 |
| Keybuk | - there is no root fs entry in /etc/fstab | 16:53 |
| Keybuk | - mountall has no idea what to wait for (it's waiting for /dev/root) | 16:54 |
| ogra | so itz kernel bug ? | 16:54 |
| Keybuk | - udev can't create the /dev/root symlink because it doesn't know what you mounted (the kernel isn't telling) | 16:54 |
| Keybuk | no, not really | 16:54 |
| Keybuk | I think this is behaving correctly | 16:54 |
| persia | Um, root=(device) is very common as a boot argument for some bootloaders | 16:54 |
| Keybuk | the missing link is that if the root filesystem is still listed as /dev/root by the time mountall gets to it, it should make that | 16:54 |
| getxsick | hi, i don't know if it's a correct channe, but could you tell me which source package format is adequate for ubuntu? 3.0? or 1.0? | 16:54 |
| Keybuk | persia: sure, but you also tend to have a line in /etc/fstab that tells the system the same thing ;-) | 16:55 |
| persia | Keybuk: Not on the the retail device I use daily. | 16:55 |
| cjwatson | nixternal: sorry to hear that | 16:55 |
| ogra | Keybuk, well, it will confuse users coming from jaunty or karmic ... indeed i can mount with rw or hack rootstock to add a fstab entry (which is my current workaround) ... but i wanted to find the initial cause of it | 16:56 |
| persia | Keybuk: The specific reason for this is that it's common for a rootfs to be copied between devices so the contents of the filesystem don't know how they are being mounted (and it's desired that it's portable). | 16:56 |
| Keybuk | yes, yes | 16:56 |
| Keybuk | you don't need to convince me this is a bug | 16:56 |
| persia | In what is it a bug? | 16:56 |
| Keybuk | you can tell I think it's a bug because I'm trying to triage it | 16:56 |
| persia | heh :) | 16:57 |
| ogra | :) | 16:57 |
| Keybuk | rather than pointing at you and laughing ;-) | 16:57 |
| Keybuk | we clearly have a gap here where if the kernel mounts the root filesystem, and it's not listed in /etc/fstab, we fail to boot | 16:57 |
| Keybuk | but we can trivially find out what the kernel mounted | 16:58 |
| Keybuk | stat("/") would tell us the dev_t | 16:58 |
| Keybuk | it's also given in plain numbers in /proc/self/mountinfo | 16:58 |
| persia | Keybuk: What if we're using something like ubifs where it doesn't necessarily have an associated /dev node? | 16:58 |
| persia | (so mounted as none in the output of `mount`) | 16:59 |
| Keybuk | persia: can you boot one of those as above and tell me what stat("/") and /proc/self/mountinfo say? | 16:59 |
| ogra | then /proc/self/mountinfo should still have the info | 16:59 |
| persia | Keybuk: Only with a jaunty kernel (I don't have a lucid kernel for such a device yet) | 16:59 |
| Keybuk | persia: either kernel should be fine | 16:59 |
| Keybuk | I'd like to know the answer, since it may affect the fix | 16:59 |
| persia | Keybuk: /proc/self/mountinfo has "11 1 252:1 / / rw - ubifs ubi0:rootfs rw" | 17:00 |
| persia | stat() requires me to write a program :) | 17:00 |
| Keybuk | persia: there's a /usr/bin/stat | 17:01 |
| Keybuk | persia: is ubifs listed in /proc/filesystems ? | 17:01 |
| * ogra would assume such a kernel has it compiled in | 17:02 | |
| ogra | i.e. if its supposed to boot from ubifs | 17:02 |
| * persia wants a faster device on which to check stuff | 17:03 | |
| ogra | heh | 17:03 |
| ogra | i thought you like the netwalker :) | 17:03 |
| persia | I do, but it can't keep up with Keybuk asking good questions whilst running firefox :) | 17:03 |
| nixternal | cjwatson: thanks | 17:03 |
| ogra | lol, run chromium :) | 17:04 |
| persia | Keybuk: http://paste.ubuntu.com/387108/ | 17:04 |
| Keybuk | persia: and grep ubifs /proc/filesystems | 17:04 |
| persia | Keybuk: http://paste.ubuntu.com/387109/ | 17:05 |
| persia | It's there, with nodev | 17:05 |
| Keybuk | persia: it's nodev - so should work fine | 17:05 |
| persia | Ah, so it's only an issue if it's not nodev? | 17:05 |
| persia | OK. | 17:05 |
| Keybuk | yes | 17:05 |
| Keybuk | mountall doesn't wait for the device of a nodev filesystem ;-) | 17:05 |
| * persia puts away the exotic use case | 17:05 | |
| Keybuk | I just wanted to make sure that your "exotic" case was properly dressed | 17:06 |
| persia | Seems to be. When I get a kernel, I'll file a bug if there's something funny. | 17:06 |
| ogra | who knows, might not be *that* exotic anymore in the nearer future if more arm devices show up | 17:06 |
| Keybuk | ok | 17:07 |
| Keybuk | so back to me | 17:07 |
| Keybuk | root=/dev/sdXY on kernel command-line, no initrd/initramfs, and root not listed in /etc/fstab | 17:07 |
| Keybuk | we have the dev_t from mountinfo and from stat("/") | 17:07 |
| Keybuk | but mountinfo says /dev/root, which is not created | 17:08 |
| Keybuk | either | 17:08 |
| Keybuk | 1) something should create /dev/root | 17:08 |
| Keybuk | 2) mountall should mentally substitute /dev/root for /dev/block/MAJOR:MINOR | 17:08 |
| ogra | 1) has to be devtmpfs, no ? | 17:08 |
| Keybuk | I'm inclined to say that #1 is correct - since it means everything will work | 17:08 |
| Keybuk | no, udev can create it as a symlink | 17:08 |
| Keybuk | and if udev does that, it'll be in the SYMLINKS= list of the uevent | 17:08 |
| Keybuk | which means mountall will just work | 17:09 |
| ogra | where does udev come from before / is there ? | 17:09 |
| Keybuk | (and other things piled on top will just work) | 17:09 |
| Keybuk | ogra: / is there - it's mounted by the kernel <g> | 17:09 |
| ogra | oh, right | 17:09 |
| * ogra slaps forehead ... we try to remount :) | 17:09 | |
| Keybuk | so we basically need a udev rule that creates /dev/root | 17:09 |
| Keybuk | it should be something like: if the root fs is listed as /dev/root in mountinfo, and the MAJOR/MINOR in mountinfo matches this block device, SYMLINK+="root" | 17:10 |
| ogra | Keybuk, so the initial question still stands, why did it work in jaunty/karmic without /dev/root ? did mountall change that much ? | 17:10 |
| Keybuk | ogra: jaunty/karmic had a bug that would have caused the root to be ignored | 17:11 |
| Keybuk | which broke other things (nbd roots, etc.) | 17:11 |
| ogra | ah | 17:11 |
| ogra | yeah i remember ltsp bugs about that | 17:11 |
| Keybuk | so I'm thinking | 17:13 |
| Keybuk | mountall already parses mountinfo and already has all the information to make the decision | 17:13 |
| Keybuk | we don't want a permanent udev rule to make a particular device /dev/root - it'll only go wrong | 17:13 |
| Keybuk | and a rule that queries mountinfo for every block device would be slow | 17:13 |
| Keybuk | so why not just have mountall write a temporary udev rule out | 17:13 |
| Keybuk | if it sees that the root device (which it always has a pointer to) is on /dev/root | 17:14 |
| Keybuk | it can write a /dev/.udev/rules.d/root.rules that contains: | 17:14 |
| Keybuk | SUBSYSTEM=="block", ENV{MAJOR}=="X", ENV{MINOR}=="Y", SYMLINK+="root" | 17:14 |
| persia | Where X and Y are set based on the actual device detected as / ? | 17:16 |
| ogra | if that works | 17:16 |
| Keybuk | persia: exactly | 17:16 |
| ogra | makes sense | 17:16 |
| Keybuk | ogra: could you try this for me | 17:16 |
| Keybuk | add to your test case a file /etc/udev/rules.d/root.rules | 17:16 |
| Keybuk | with the content | 17:16 |
| persia | Sounds sane, because the "I can't boot" is mountall being confused, and mountall would be resolving it's own confusion. | 17:16 |
| persia | udev just sees another rule, and implements it, and presto, it works. | 17:16 |
| Keybuk | SUBSYSTEM=="block", ENV{MAJOR}=="8", ENV{MINOR}=="0", SYMLINK+="root" | 17:17 |
| Keybuk | ogra: ^ and then let me know whether that works | 17:17 |
| Keybuk | persia: right, mountall writes a udev rule out so that it resolves its own confusion later | 17:17 |
| Keybuk | and that same rule file solves any other program ever having the same confusion either :p | 17:17 |
| persia | Right, but none of them ought have a chance to get confused before mountall | 17:17 |
| ogra | takes a min | 17:18 |
| Keybuk | persia: indeed, because udevd is started by mountall ;-) | 17:19 |
| Keybuk | we could do this without mountall by something like: | 17:19 |
| Keybuk | SUBSYSTEM=="block", PROGRAM="is-this-dev-root", SYMLINK+="root" | 17:20 |
| Keybuk | where is-this-dev-root contained code to grep through mountinfo, matching major/minor and checking against /dev/root | 17:20 |
| Keybuk | but that's fairly expensive for every block device, and would be the same code as in mountall | 17:20 |
| persia | Presumably that would get added by the package containing is-this-dev-root | 17:20 |
| persia | And only be used if there was some reason *not* to use mountall in a particular installation. | 17:20 |
| Keybuk | and really, we only need to do this once, and mountall already happens to do that | 17:20 |
| Keybuk | well, if you're not using mountall, you won't have the bug where mountall is waiting for /dev/root to show up in /dev ;-) | 17:21 |
| Keybuk | and one assumes you've already solved the remounting root issue, probably just by ignoring the problem | 17:21 |
| ogra | it boots, i missed possible mountall errors though (forgot to take out --debug) | 17:21 |
| Keybuk | ogra: it boots sounds like a win to me | 17:22 |
| ogra | yeah | 17:22 |
| ogra | yup, no mountall errors on second boot | 17:22 |
| * ogra gets dinner ... bbl | 17:23 | |
| Keybuk | ogra: could you file a bug on mountall with the above for me | 17:24 |
| ogra | Keybuk, oh, i think lool was so kind to do that already | 17:24 |
| * ogra looks for it | 17:24 | |
| ogra | Keybuk, bug 527216 | 17:24 |
| ubottu | Launchpad bug 527216 in mountall "Boot hangs waiting for local filesystems if / isn't in fstab and / is only mounted ro" [Low,New] https://launchpad.net/bugs/527216 | 17:24 |
| \sh | shtylman_: nope...nothing...the patch from fedora is there..it removes the FTBFS bugger but I can't say, if this will break ABI with google-perftools...if you are more knowledged on this matter, please take over | 17:26 |
| ogra | Keybuk, want it assigned ? i added the info about the rules file and its content | 17:27 |
| shtylman_ | \sh: won't perftools be compiled against it? what is the ABI problem then? | 17:28 |
| ogra | Keybuk, assigned it to you ... | 17:28 |
| shtylman_ | \sh: I can compile both fo them... is there some set of actions I can take to move the process along? if libunwind builds and then perftools builds... | 17:29 |
| * ogra really needs to go for that dinner else i get slayn ... | 17:29 | |
| Keybuk | thanks | 17:29 |
| shtylman_ | I am just unclear about what I can do ... cause from my end it seemed like it was just blocked on things to build | 17:29 |
| \sh | shtylman_: if libunwind builds without changes (ftbfs because of some magic in glibc not liking what libunwind does or so)...and google-perftools builds with libunwind...please go ahead and force the FFe | 17:29 |
| shtylman_ | \sh: alright... I will try building both on my end here and see what happens.. (what do you mean builds without changes? does the patch to fix the first FTBFS count as cahnges?) | 17:32 |
| \sh | 16:39:09 shtylman_ | \sh: anything new on bug: #522106 ? its a blocker for #519996 and likewise the freeze exception request for perftools │ a|wen | 17:33 |
| \sh | argl | 17:33 |
| shtylman_ | heh | 17:34 |
| \sh | http://cvs.fedoraproject.org/viewvc/devel/libunwind/libunwind-disable-setjmp.patch?view=log <- this patch fixes the ftbfs but removes some lines | 17:34 |
| \sh | s/lines/features??/ | 17:34 |
| shtylman_ | \sh: right.. so if it builds with that and likewise if perftools builds on top of that... I should? | 17:35 |
| \sh | shtylman_: read the comment from stefanpotyra...the fix from fedora fixes it...but stefan is right about what he says | 17:37 |
| shtylman_ | \sh: I see .. ok that makes sense... I will take a look | 17:38 |
| \sh | shtylman_: feel free to invest more work into that matter..I'm a bit busy with work to deal with this right now.. | 17:48 |
| shtylman_ | \sh: no problem... will let you know how it goes | 17:49 |
| === MacSlow is now known as MacSlow|capoeira | ||
| qense | What if you're compiling two or three binaries -- including a shared library -- from one source project and you want to link to that library inside the other two projects? What do you add to binaryname_SOURCES in the Makefile? Or should you add something elsewhere? I don't want include the library code in three binaries, that's a bit overkill. | 17:55 |
| === kenvandine is now known as kenvandine[busy] | ||
| cjwatson | asac: sun-java6 is in the partner archive now. is now a good time to remind you about the WI assigned to you on https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-dropping-sun-java6? | 17:59 |
| === kenvandine[busy] is now known as kenvandine | ||
| === deryck is now known as deryck[lunch] | ||
| === tumbleweed_ is now known as tumbleweed | ||
| cjwatson | slangasek: foundations-lucid-gfxboot-update is ready to land, pending the FFE request in bug 530713; would appreciate your comments | 18:45 |
| ubottu | Launchpad bug 530713 in gfxboot-theme-ubuntu "[FFe] move live CD greeter functionality into ubiquity." [Undecided,Fix committed] https://launchpad.net/bugs/530713 | 18:45 |
| === dendro-afk is now known as dendrobates | ||
| shtylman_ | \sh: perftools is fine without the setjmp library so it is ok to not build that | 18:52 |
| shtylman_ | \sh: how should I indicate this on the various bug reports? I figure it needs to start with libunwind and that needs to build first | 18:53 |
| mdeslaur | tjaalton: do you mind if I merge xserver-xorg-input-vmmouse? The current one in lucid is broken and the merge will fix it... | 19:01 |
| === deryck[lunch] is now known as deryck | ||
| mdeslaur | tjaalton: actually, scratch that, I'll just add the appropriate patch | 19:18 |
| === dendrobates is now known as dendro-afk | ||
| slangasek | cjwatson: FFe ack | 19:50 |
| sebner | jdstrand: around? | 19:51 |
| jdstrand | sebner: yes | 19:51 |
| sebner | jdstrand: I just wanted to debdiff moin but found serveral issues, our cdbs is too old so some parts of the 1.9.2 debian/ update needs to be reverted and as I'm really am no cdbs expert (I hate it and don't use it) I'm wondering if you can give me a hand | 19:53 |
| jdstrand | sebner: this is for the lucid merge? | 19:53 |
| sebner | jdstrand: aye | 19:54 |
| slangasek | pitti: the reason cryptsetup now depends on plymouth is that I removed 'console output' from the upstart job because this was generating console noise; and if we're no longer allowed to use the console, the non-plymouth fallback doesn't work | 19:54 |
| slangasek | pitti: (aside from all the other reasons Keybuk gave) | 19:54 |
| jdstrand | sebner: does MoM not work for you? | 19:54 |
| sebner | jdstrand: I stopped using MoM a long time ago because most of the time (on more complex merges) fixing the MoM result took me more time than doing it by hand (partly automatically) :\ | 19:56 |
| lucas | hi, does an archive admin have time for a bunch of ruby-related syncs? (all 1.9->1.9.1 transition, universe, minor packages) list: ruby_syncs.txt | 19:56 |
| lucas | oops, http://blop.info/pub/ruby_syncs.txt | 19:56 |
| jdstrand | sebner: I am not familiar with the packaging issues you are facing and have not merged it in the past. I am working on the moin security updates for stable releases atm. I don't think I can help right now. I suggest asking the last person who merged it or if the FFe has been granted, I can just do it after I'm done with my updates | 19:58 |
| sebner | jdstrand: I haven't touched it at all in the past and I'm wondering if the last uploader is capable of doing it. Nvm, I have no other plans for the evening anyways ;D | 20:00 |
| sebner | pitti: is this a known issue when dmesg shows the external harddrive but doesn't mount it? Mounting by hand is possible but the folder is only browsable with root then :\ | 20:02 |
| === dendro-afk is now known as dendrobates | ||
| mathiaz | what could cause the following error: useradd: cannot lock /etc/passwd; try again later.? | 21:22 |
| mathiaz | happening during a package installation | 21:22 |
| persia | mathiaz: Did you implement some cool parallel dpkg? Aside from that, do you have other things that are locking /etc/passwd? | 21:23 |
| mathiaz | persia: bug 523896 | 21:24 |
| ubottu | Launchpad bug 523896 in postfix "package postfix 2.6.5-3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/523896 | 21:24 |
| persia | It *shouldn't* happen for a quiescent system just running dpkg. | 21:24 |
| mathiaz | persia: when installing jetty the error started to appear | 21:24 |
| === sabdfl1 is now known as sabdfl | ||
| james_w | mathiaz: possibly bug 432964 | 21:27 |
| persia | mathiaz: Sorry. Nothing obvious. I'm curious if comment #6 implies chromium-browser | 21:27 |
| ubottu | Launchpad bug 432964 in shadow "System crash in guest session locks /etc/passwd forever" [Medium,Confirmed] https://launchpad.net/bugs/432964 | 21:27 |
| highvoltage | is it just my imagination or is the ubuntu wiki way faster than usual today? | 21:27 |
| mathiaz | james_w: hm - ok. I've reassigned the bug to the shadow package | 21:27 |
| sabdfl | highvoltage: maybe those cables are starting to land in SA? | 21:31 |
| highvoltage | sabdfl: seems so! | 21:32 |
| JordiGH | We're considering using Launchpad for BTS. Does it have an email interface? Our BDFL is used to an email interface, doesn't like web. | 21:54 |
| RAOF | JordiGH: You'd be better served in #launchpad, and yes. It does have an email interface. | 21:55 |
| JordiGH | Thanks! | 21:56 |
| jono | didrocks, around? | 22:02 |
| highvoltage | didrocks: congrats on making core-dev! | 22:13 |
| stgraber | didrocks: congrats and sorry for not being there, I was somewhere between London and Geneva at the time ... (and for some reason I forgot to e-mail the DMB about it as I did for EMEA) | 22:14 |
| persia | Could someone approve my mail to ubuntu-devel-announce@ please? | 22:22 |
| persia | Err, or not. | 22:23 |
| * persia fiddles sender addresses and tries again | 22:23 | |
| === MacSlow|capoeira is now known as MacSlow | ||
| persia | OK. Could someone approve my mail to ubuntu-devel-announce@ (really this time :) ) | 22:26 |
| === sconklin is now known as sconklin-gone | ||
| === robbiew is now known as robbiew_ | ||
| cjwatson | persia: done | 23:57 |
| persia | cjwatson: Thanks. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
