| === JayFo is now known as JFo | ||
| === dous__ is now known as dous | ||
| === Whoopie_ is now known as Whoopie | ||
| === dendro-afk is now known as dendrobates | ||
| === asac_ is now known as asac | ||
| dholbach | good morning | 07:05 |
|---|---|---|
| mvo | hey dholbach | 07:07 |
| dholbach | hey mvo | 07:07 |
| dholbach | mvo: ALTER!!!!! | 07:07 |
| * dholbach hugs mvo | 07:07 | |
| mvo | :) | 07:07 |
| * mvo hugs dholbach | 07:07 | |
| dholbach | Up early? | 07:07 |
| mvo | yes | 07:07 |
| dholbach | same here :) | 07:08 |
| jml | are we the upstream of the acpi-support package? | 07:10 |
| jml | dholbach, hello! | 07:10 |
| dholbach | hiya jml | 07:11 |
| dholbach | jml: what about that UDW session? :-D | 07:11 |
| jml | dholbach, last week of January, right? I'll be in the UK that week. | 07:12 |
| dholbach | https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule | 07:12 |
| jml | dholbach, I was just about to ask :) | 07:12 |
| dholbach | jml: acpi-support is in debian too | 07:12 |
| jml | I'm trying to find the upstream vcs for it. | 07:13 |
| dholbach | let me see | 07:13 |
| jml | dholbach, I can do the Friday 1800 slot. | 07:13 |
| dholbach | wow, it's even in sync with debian in lucid | 07:13 |
| dholbach | jml: which topic? lplib? :) | 07:14 |
| jml | dholbach, I can do lplib. I could also do an "Ask Launchpad" session | 07:14 |
| jml | dholbach, whichever you think would be more interesting. | 07:14 |
| dholbach | jml: which one would you prefer? | 07:14 |
| jml | dholbach, I have no preference. | 07:15 |
| jml | wow, it's going to be exciting being able to actually attend some of these sessions :) | 07:15 |
| jml | dholbach, probably lplib is best. | 07:16 |
| jml | dholbach, keep it concrete & code-y | 07:16 |
| dholbach | hum, it could be that we're "upstream" for acpi-support | 07:16 |
| dholbach | it's a bit of a weird divergence | 07:17 |
| dholbach | slangasek might know more | 07:17 |
| dholbach | the debian/copyright of the debian source package says something like "It was downloaded from http://archive.ubuntu.com/....." | 07:17 |
| dholbach | jml: shall I pencil you in? session title? :) | 07:18 |
| * jml tries to think of a clever title that doesn't violate the CoC | 07:19 | |
| dholbach | haha | 07:19 |
| * dholbach hugs jml | 07:19 | |
| jml | I'm all out of clever. How about "Meet launchpadlib"? | 07:20 |
| StevenK | "launchpadlib and you: Making access to Launchpad easier" ? | 07:21 |
| dholbach | sounds good to me :) | 07:21 |
| jml | I'm just going to make lp:~ubuntu-core-dev/acpi-support/trunk the dev focus for acpi-support. slangasek can correct me if I'm wrong. | 07:22 |
| dholbach | jml: sounds good to me | 07:22 |
| dholbach | jml: thanks a bunch for helping out with UDW :) | 07:23 |
| jml | dholbach, my pleasure. | 07:23 |
| dholbach | we have a fantastic line-up this time | 07:23 |
| dholbach | I mean we always do :) | 07:23 |
| jml | dholbach, yeah. I'm looking forward to heckling at rockstar's talk :) | 07:24 |
| dholbach | haha | 07:24 |
| jml | Ng, hello. | 07:25 |
| jml | Ng, could I persuade you to set the development focus branch for https://code.edge.launchpad.net/evdev ? | 07:25 |
| dholbach | who can I interest in another UDW session? there's still 4 open slots! | 07:26 |
| dholbach | https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep | 07:26 |
| === dendrobates is now known as dendro-afk | ||
| slangasek | jml: that should work | 07:31 |
| jml | slangasek, thanks. | 07:31 |
| * jml is doing a little mindless data gardening | 07:32 | |
| wgrant | Can I convince somebody to sync something like jack-tools? 3.0 support works now, and I'd like to see that syncing actually works. | 07:35 |
| wgrant | (jack-tools has all the things that are likely to trip Soyuz up, and it has no real changes, so it seems like a good test) | 07:36 |
| slangasek | wgrant: I synced one already | 07:38 |
| slangasek | (abraca, now in dep-wait) | 07:38 |
| wgrant | slangasek: But it at least hit the buildds? Good. | 07:38 |
| slangasek | yep | 07:39 |
| slangasek | thanks for all your help to get v3 happening :) | 07:40 |
| wgrant | np | 07:40 |
| wgrant | Sorry it took so long. | 07:40 |
| === tkamppeter_ is now known as tkamppeter | ||
| junjun | hi | 08:08 |
| junjun | i get the source of 9.10 kernel, and found that Ubuntu patches the vanilla kernel. where can i find the information on the patch? | 08:09 |
| junjun | i want to know which change Ubuntu made to the vanilla kernel | 08:09 |
| junjun | the patch to 2.6.31 is pretty big. | 08:09 |
| junjun | except AppArmor, and ndiswrapper, what else Ubuntu change to the kernel? | 08:10 |
| dholbach | junjun: try asking in #ubuntu-kernel (and maybe wait a bit, the folks might still be asleep :-)) | 08:13 |
| junjun | dholbach: thanks! | 08:13 |
| pitti | Good morning | 08:14 |
| pitti | slangasek: right, I think there should be an extra field in the workitems table eventually; but oh well, kees already fixed it for now | 08:16 |
| junjun | from Ubuntu 9.10, we patch kernel with Non-Exec stack patch. Is that exactly the patch named Exec-Shield from Redhat? | 08:21 |
| junjun | if not, what is the difference with Redhat's Exec-shield?? | 08:21 |
| junjun | oh well, it seems Ubuntu uses the patch from Redhat (Fedora) | 08:24 |
| kees | junjun: "execshield" is the entire unbrella project that Redhat put all their hardening features under. | 08:25 |
| kees | junjun: Ubuntu's kernel carries the last remaining piece of that which is not already upstream, the partial nx-emulation for i386 | 08:25 |
| junjun | kees: so you mean we only port the kernel patch to Ubuntu, but not the rest? | 08:25 |
| kees | junjun: everything else already in the kernel, userspace, etc. | 08:25 |
| kees | junjun: some details here: https://wiki.ubuntu.com/Security/Features | 08:26 |
| junjun | it is interesting to know, thanks | 08:26 |
| kees | sure, np | 08:26 |
| junjun | so far, it seems only kernel of Fedora (and Redhat, CentOS) and Ubuntu uses this patch. | 08:26 |
| kees | junjun: afaik, SUSE uses it as well, but I haven't personally verified it. | 08:27 |
| junjun | the rest like OpenSuse, Debian, .... dont. is that correct? | 08:27 |
| kees | Debian does not use it, correct. I'm unsure about SUSE | 08:27 |
| junjun | kees: ok, i will check that | 08:27 |
| kees | junjun: as linked from https://wiki.ubuntu.com/Security/Features#Non-Exec%20Memory I have a simple regression test that can help validate a given kernel. | 08:28 |
| kees | junjun: the patch itself is here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commitdiff;h=eb56f42a4bc9c671a19dcf8fd36eb3f341de7dfa | 08:29 |
| kees | it's based on the bits from http://www.codemonkey.org.uk/projects/execshield/ | 08:30 |
| junjun | kees: very clear, thanks! | 08:32 |
| junjun | kees: why this patch doesnt work for 64bit kernel?? | 08:33 |
| kees | junjun: the cs-limit approach doesn't make sense for 64bit, and nearly all 64bit system already implement non-exec in hardware, so the emulation is unneeded. | 08:33 |
| === doko__ is now known as doko | ||
| junjun | what do you mean by "cs-limit approach doesn't make sense"?? | 08:34 |
| kees | the partial nx-emulation patch uses the cs segment limit to split userspace into two region (one executable, the other not). as I understand it, there's no reason to do this for 64bit, since 64bit is PAE, which implements the NX bit in the page table, so no artificial separation is needed. | 08:35 |
| tseliot | pitti: shall I make nvidia depend on acpid and acpi-support or would the former suffice? | 08:41 |
| pitti | tseliot: just acpid, please | 08:41 |
| pitti | acpi-support is unrelated to what nvidia does, and is still on the "to die" list | 08:41 |
| tseliot | pitti: ok, the latter seemed too much as a dependency to me but I wanted to be sure | 08:42 |
| fabbione | zul: ping? is there a bacula 3.0.X backport for hardy anywhere? | 08:45 |
| tkamppeter | pitti, can you upload Poppler for me, debdiff on bug 293832? Thanks. | 09:02 |
| ubottu | Launchpad bug 293832 in poppler "printer prints page at wrong position, page cut" [High,Fix committed] https://launchpad.net/bugs/293832 | 09:02 |
| pitti | tkamppeter: hi! sure | 09:24 |
| pitti | tkamppeter: should the other tasks be "invalid"ated then? | 09:25 |
| Ng | jml: hey, is that still required? | 09:26 |
| tkamppeter | pitti, I think so. | 09:26 |
| pitti | tkamppeter: uploaded | 09:26 |
| Ng | jml: well, I suppose I can see that there's no focus set, so I suppose a better question would be what would you like it set to? ;) | 09:26 |
| tkamppeter | pitti, the non-Poppler tasks are invalidated now, thanks for uploading. | 09:28 |
| pitti | ogra: bryce_ wrote a basic test plan for touch screens to check that the udevification didn't break anything (https://wiki.ubuntu.com/X/Testing/Touchscreen); does that look reasonable to you, or is there something important that should be added there? | 09:28 |
| mdz | Ng: re: the mkinitramfs error, 17-12-2009 11:30:21 < slangasek!n=vorlon@minbar.dodds.net: mdz: yes, Keybuk said he was going to fix that today | 09:50 |
| Ng | ah, sorry | 09:51 |
| StevenK | pitti: What was the magical gvfs-mount option again? | 10:24 |
| pitti | StevenK: for doing what? | 10:24 |
| StevenK | pitti: A USB key I just inserted is not automounting | 10:25 |
| pitti | StevenK: so you want to mount it manually? gvfs-mount -d /dev/foo | 10:28 |
| StevenK | steven@liquified:~% gvfs-mount -d /dev/sdb | 10:28 |
| StevenK | No volume for device file /dev/sdb | 10:28 |
| pitti | so gvfs-mount -li doesn't have /dev/sdb then? | 10:30 |
| pitti | does devkit-disks --mount /dev/sdb work? | 10:30 |
| StevenK | pitti: No, gvfs-mount -li does not have sdb | 10:31 |
| StevenK | devkit-disks ... does work, though | 10:31 |
| pitti | StevenK: does gvfs-mount -oi say anything when you plug this in? | 10:34 |
| StevenK | pitti: Yes, and it actually mounted it this time. | 10:35 |
| * StevenK curses heisenbugs | 10:35 | |
| pitti | free: can you please make bug 455217 public, so that it can be SRU-processed? | 10:50 |
| ubottu | Bug 455217 on http://launchpad.net/bugs/455217 is private | 10:50 |
| free | pitti: oops, sorry, just made it pubblic, thanks | 10:51 |
| pitti | free: and please make sure that all the fixed bugs have proper ubuntu package tasks | 10:51 |
| free | pitti: I think I'm not entitled to create tasks? or how do I? | 10:52 |
| free | pitti: I couldn't figure out how to do it last time | 10:52 |
| pitti | free: "Also affects distribution" -> ubuntu/landscape-client | 10:52 |
| free | pitti: okay, on all the bugs related to the SRU? | 10:52 |
| pitti | right | 10:52 |
| pitti | we need to track their fixes/status in all releases | 10:53 |
| pitti | I started adding them | 10:53 |
| free | okay | 10:54 |
| pitti | all added now, I think | 10:55 |
| pitti | free: would you mind reviewing the bugs and closing the lucid tasks which are already fixed? | 10:55 |
| free | pitti: sure | 10:56 |
| pitti | thanks | 10:56 |
| free | pitti: I guess I can use "Fix released" for lucid tasks right? | 11:06 |
| pitti | free: if they are fixed in lucid, yes | 11:06 |
| free | pitti: okay, so that's done | 11:06 |
| pitti | cheers | 11:07 |
| free | pitti: there a now bugs that have the Lucid task with fix-released, and bugs that have a new Ubuntu task (no release-specifc tasks yet) | 11:07 |
| free | pitti: so, I don't think I can open release-specifc tasks, can I? | 11:08 |
| pitti | free: you can nominate | 11:08 |
| free | pitti: what does that mean exactly? | 11:08 |
| pitti | free: the tasks won't be created yet, but they will shown as "proposed for jaunty-update", etc. | 11:09 |
| pitti | I'll accept them while reviewing | 11:09 |
| free | okay | 11:09 |
| free | pitti: I can't figure out how to nominate, I can't see any "nominate" or similar button in the bug page UI.. | 11:12 |
| pitti | free: "Target to release" | 11:12 |
| pitti | (with the ubuntu task selected, not the upstream task) | 11:12 |
| free | pitti: and how do you select the Ubuntu task? clicking on it just brings me to the landscape-client source page in the ubuntu LP project | 11:17 |
| === jelmer_ is now known as jelmer | ||
| pitti | free: hm; just change the URL to /ubuntu/+source/landscape-client/... ? | 11:18 |
| pitti | or change anything else in the ubuntu task | 11:19 |
| pitti | like priority, assignee, etc. | 11:19 |
| free | pitti: okay, manually entering the url like you suggest works, but changing something the ubuntu task doesn't, I couldn't find any way to do it except manually entering the url | 11:22 |
| free | pitti: okay, the bugs without specific release tasks should be all nominated now (for intrepid to lucid) | 11:26 |
| pitti | free: can bug 455217 be fixed in lucid, too? | 12:00 |
| ubottu | Launchpad bug 455217 in landscape-client "Handle release-upgrade messages in the packagemanager plugin" [Medium,Fix committed] https://launchpad.net/bugs/455217 | 12:00 |
| free | pitti: yes | 12:01 |
| free | pitti: just marked it as Fix released | 12:02 |
| pitti | great | 12:02 |
| === Hellow_ is now known as Hellow | ||
| === vila is now known as vila-lunch | ||
| === ara_ is now known as ara | ||
| === mac_v_ is now known as mac_v | ||
| === vila-lunch is now known as vila | ||
| zul | fabbione: no there isnt a backport | 13:16 |
| fabbione | zul: thanks, I have done myself | 13:16 |
| zul | fabbione: cool | 13:16 |
| fabbione | zul: you might want to take care of Lucid release notes for upgrading tho | 13:16 |
| fabbione | zul: you need to have a director > 3.0 to talk to fd > 3.0 | 13:17 |
| fabbione | zul: dir 3.0 can talk to fd in any version but not the other way around | 13:17 |
| zul | fabbione: thanks for the heads up | 13:17 |
| fabbione | zul: so basically, if you want LTS to LTS upgrade plan, the director machine needs to be done first | 13:17 |
| zul | gotcha | 13:18 |
| zul | james_w: did the import failed for samba i dont see it in launchpad? | 13:46 |
| james_w | zul: it was stuck in the queue, I've set it to run next | 13:47 |
| zul | james_w: thanks | 13:48 |
| Keybuk | mdz, Ng: it was stuck in NEW :p | 14:06 |
| === asac_ is now known as asac | ||
| Chipzz | http://www.advogato.org/person/robertc/diary.html?start=129 | 14:27 |
| Chipzz | this gets a major ++ from me | 14:27 |
| Chipzz | I would hope this mentality would propagate to more debian and ubuntu developers | 14:27 |
| joaopinto_ | I really don't see the relation between upstreams doing their own packaging, and including the debian/* in the upstream source | 14:31 |
| joaopinto_ | I agree with the first, not with the second | 14:32 |
| james_w | why? | 14:32 |
| joaopinto_ | because debian/* use dependencies or rules some times tweeaked for specific distros/releases | 14:33 |
| joaopinto_ | there is no advantage on having them including on the source, there is the advantage that other packagers will need to patch or rm the upstream debian/* | 14:33 |
| joaopinto_ | ops, disadvantage | 14:34 |
| joaopinto_ | upstreams doing the packaging is a social subject, including debian/* in the source is a technical one | 14:35 |
| james_w | upstream sometimes has code that doesn't work on Ubuntu, so there is a disadvantage that we sometimes need to patch it, so upstream shouldn't ship any code | 14:36 |
| joaopinto_ | james_w, source code is generic, as far as possible, debian/rules are not, and you failed ot mention what at the advantages of having it include on the source :) | 14:38 |
| joaopinto_ | ops, I meant debian/* | 14:38 |
| james_w | debian/* are generally, otherwise we wouldn't be able to derive from Debian without making vastly more changes than we do | 14:38 |
| Ng | joaopinto_: I like it when I unpack a tarball of some new software and I can just build a package out of it immediately. That's why I include a debian/ in my projects :) | 14:40 |
| ScottK | Is Google Talk audio supposed to be working with Empathy in Karmic? | 14:40 |
| ScottK | Ng: The problem is most upstreams that attempt to do this, don't know a lot about Debian packaging. | 14:40 |
| james_w | ScottK: I don't see that as a reason to tell every single upstream that does it off, as seems to be the culture currently | 14:41 |
| joaopinto_ | james_w, you are refering to the general case of Debian versus Ubuntu, the debian/* world does not stop there, and still, your sentence is not accurate when you need to backport | 14:41 |
| Ng | ScottK: I would absolutely fit in that pot, which is why I merge back in the correctness from nxvl's packaging :) | 14:41 |
| joaopinto_ | Ng, if you want your projects just to build, provide a .dsc file | 14:42 |
| joaopinto_ | Ng, you will help those which "just want to build" per your rules, without interfering with others that want to build in another way | 14:43 |
| Ng | joaopinto_: I don't follow, how does a .dsc help? | 14:43 |
| james_w | for a .dsc file to make any sense you have to have a debian directory, no? | 14:43 |
| joaopinto_ | Ng, dget file.dsc && debuild | 14:43 |
| joaopinto_ | no, you just need the .dsc, diff, and orig | 14:44 |
| joaopinto_ | and everone is happy with a single dget command, versus a wget source | 14:44 |
| StevenK | joaopinto_: Which you can't build without a debian directory in the source | 14:44 |
| joaopinto_ | StevenK, you can, because I am refering to a .dsc which points to both the orig.tar.gz and the debian diff | 14:45 |
| StevenK | joaopinto_: And what do you think is in the debian diff? The debian directory. | 14:46 |
| joaopinto_ | StevenK, right, but provided as it should as a diff, not included on the original source | 14:46 |
| james_w | joaopinto_: so you refuse to let us re-use and collaborate on that debian/ directory in the most natural way, as we do the rest of the code? | 14:47 |
| james_w | no thanks | 14:47 |
| joaopinto_ | james_w, no, but I don't agree that the proper place for packaging collaboration is the source, you do collaboration for a group at the cost of other group | 14:48 |
| ScottK | Another issue is that improvements to Debian packaging need a new upstream release if that's the canonical source for them. | 14:48 |
| james_w | it's not a cost that means much | 14:48 |
| james_w | it doesn't have to be the canonical source, or diff.gz can make modifications | 14:49 |
| Ng | how much variation is there in the packaging of debian derivatives? talk of costs without numbers seems a bit pointless | 14:49 |
| joaopinto_ | james_w, ah ok, so you assume that your need for collaboration is more important than others needs for a clean source :) | 14:49 |
| james_w | improvements to the code don't need a new upstream release, we are generally happy to patch and feed the changes back for the next release | 14:49 |
| joaopinto_ | that's something personal, nothing to argue about :) | 14:49 |
| joaopinto_ | james_w, upstreams should be able to collaborate if the debian/* dir is kept in any VCS | 14:52 |
| Keybuk | huh? | 14:55 |
| Keybuk | upstream should never put the debian/ directory into their VCS | 14:55 |
| Keybuk | that's just wrong | 14:55 |
| joaopinto_ | the only good reason I see on this change would be, "Hey you cand build .debs from the source", when there is no one able to set up a PPA or get it into the repositories | 14:56 |
| Keybuk | anyone can have a PPA | 14:56 |
| joaopinto_ | but again, that is not collaboration :) | 14:56 |
| joaopinto_ | Keybuk, we are debating that http://www.advogato.org/person/robertc/diary.html?start=129 | 14:56 |
| Keybuk | there's no loop or step to getting one, just create a Launchpad account | 14:57 |
| Keybuk | I disagree strongly with Robert ;) | 14:57 |
| Keybuk | one of the biggest problems I ever have, as a distribution maintainer, is upstreams who put the packaging into their tarball | 14:57 |
| Keybuk | because it's always wrong | 14:57 |
| Keybuk | and it makes it very hard for us to modify it | 14:57 |
| jcastro | it should just be another branch imo | 14:58 |
| Keybuk | in certain ways, for example removing a debhelper config file, it becomes impossible to modify without repackaging the software entirely | 14:58 |
| jcastro | like how we're doing for UDD | 14:58 |
| joaopinto_ | Keybuk, that was the pointing I was making | 14:58 |
| Keybuk | (because our source package format doesn't permit removing files in the diff.gz) | 14:58 |
| james_w | Keybuk: to be fair, Rob says we should fix that. | 14:58 |
| Keybuk | you also end up the situation where it looks like it's got a package | 14:59 |
| Keybuk | but the package is wrong | 14:59 |
| Keybuk | so people think they can grab the upstream tarball | 14:59 |
| Keybuk | build it | 14:59 |
| Keybuk | and then install it on their distribution | 14:59 |
| Keybuk | that could go *badly* wrong | 14:59 |
| Keybuk | look at the .spec file issues between SuSE and RedHat for an example ;) | 15:00 |
| LaserJock | hmm, so what happens if upstream has a debian/ but Debian, Ubuntu, <any old .deb-based distro> wants to package in different ways? | 15:02 |
| LaserJock | does the upstream need to pick which distro to support? or do they use something like control.in? | 15:03 |
| Keybuk | LaserJock: it gets more fun | 15:04 |
| Keybuk | upstream might disagree with the way distributions change their packages | 15:04 |
| Keybuk | and deliberately make it hard for distributions | 15:04 |
| Keybuk | (this happens) | 15:04 |
| Ng | Keybuk: why are you packaging things in isolation from the upstream? if their debian/ is wrong they must care enough to have one, so presumably want a correct one? | 15:11 |
| Keybuk | Ng: it means they want one they *think* is correct | 15:12 |
| Keybuk | that's so far removed from "a correct one" that they may as well be in different universes | 15:12 |
| Ng | Keybuk: I think they want one that produces a working package | 15:13 |
| Keybuk | see, that's the problem | 15:13 |
| Keybuk | let me give you an example | 15:13 |
| ScottK | Ng: Which is a small subset of what it takes to be correct. | 15:13 |
| Keybuk | I have an upstream, who we'll call Ted | 15:13 |
| Keybuk | he maintains a piece of software, which we'll call e2fsprogs | 15:13 |
| Keybuk | and he also happens to put the entire debian/ directory in his package | 15:13 |
| Ng | Ted sounds like he cares about his users! | 15:14 |
| Keybuk | tricks that Ted has done in the past include adding code to his debian/rules to disable features on Ubuntu | 15:14 |
| Keybuk | because he thought that Ubuntu was doing things wrong | 15:14 |
| Keybuk | turned out that was a bug in his kernel code he was hiding | 15:14 |
| Keybuk | the only reason he was getting bug reports from Ubuntu users is because we have lots of users | 15:14 |
| Ng | so to avoid fixing a kernel bug we just take the packaging away from him? | 15:15 |
| Keybuk | Ted has deliberately blocked library transitions | 15:15 |
| Keybuk | etc. | 15:15 |
| Keybuk | no | 15:15 |
| Keybuk | I'm saying that in the released upstream tarball is the wrong place for packaging | 15:15 |
| Keybuk | for a start, what's right for Debian might not be right for Ubuntu | 15:15 |
| Keybuk | even though the packaging files are the same) | 15:15 |
| Keybuk | I think the right way is what we do on Upstart | 15:15 |
| Keybuk | we have a tarball we release without packaging | 15:15 |
| Keybuk | then an upstream branch which is the tarball + packaging | 15:16 |
| Keybuk | and we collaborate on that | 15:16 |
| Ng | I'd concede plumbing stuff, but I like being able to grab a tarball or vcs checkout of some application and have it be ready to build | 15:16 |
| Keybuk | if distros need their own tweaks, they branch off it | 15:16 |
| james_w | so one person spoils it for the rest of us? | 15:16 |
| Keybuk | Ng: build for Ubuntu or build for Debian? | 15:16 |
| Keybuk | or build for SuSE or build for RedHat? | 15:16 |
| Keybuk | if you build something for Ubuntu, it might not work on Debian | 15:16 |
| Keybuk | and vice-vera | 15:16 |
| james_w | plus, the same arguments can apply for code, though admittedly less often | 15:16 |
| Keybuk | james_w: one of the major portions of packaging is patches to the code | 15:17 |
| Keybuk | that's kinda the point | 15:17 |
| Keybuk | here's a better question for you | 15:17 |
| Keybuk | why do we have packaging at all? | 15:17 |
| Keybuk | if the upstream tarball is perfect as-is | 15:17 |
| Keybuk | why do we *need* a debian directory in it? | 15:17 |
| Keybuk | why can't we automate the process of taking an autoconfery tarball and turning it into debs? | 15:17 |
| Keybuk | packaging is all about hacks to the code | 15:17 |
| Keybuk | packaging is changing the code to fit the distribution | 15:18 |
| Keybuk | or changing the default configuration of the code or result | 15:18 |
| Keybuk | changing install paths | 15:18 |
| Keybuk | removing files we don't want | 15:18 |
| Keybuk | adding ones that aren't incldued | 15:18 |
| Keybuk | etc. | 15:18 |
| Keybuk | if the upstream tarball is correct | 15:18 |
| Keybuk | (which it often is in a large majority of the cases) | 15:18 |
| Keybuk | you don't need packaging | 15:18 |
| Keybuk | this is probably the primary reason I don't like packaging-in-upstream | 15:19 |
| james_w | aside from the issue of autoconf/setup.py/Makefile.PL etc., yes | 15:19 |
| Keybuk | you end up with a qmail-esque bizarre situation where you have "the upstream code", and "the upstream approved patches to the code" | 15:19 |
| james_w | it strikes me you should write all this in a blog post and propose your preferred way instead | 15:19 |
| Keybuk | we discussed this in autotools a while back | 15:20 |
| Keybuk | the only bit you're really missing is knowing which files are libraries, which are headers, which are data, which are docs, etc. | 15:20 |
| Keybuk | a lot of that can be guessed by path | 15:20 |
| Keybuk | but you kinda want a manifest-like file that hints to a packaging system | 15:20 |
| Keybuk | you also want a standard format file for things like source descriptions, licencing, etc. | 15:21 |
| === binitamshah is now known as binitamshah|away | ||
| === dendro-afk is now known as dendrobates | ||
| LaserJock | hmm, maybe you would want all that in a directory, maybe you could call it debian/ or something ;-) | 15:24 |
| Keybuk | LaserJock: the idea is that it'd be useful for everyone | 15:25 |
| Keybuk | and the debian formats are ... bizarre | 15:25 |
| Keybuk | like, why the hell would an upstream want to have a separate changelog? | 15:25 |
| Keybuk | their version number is already in configure.ac | 15:25 |
| Keybuk | unfortunately the discussion kinda veered towards "looks a lot like a .spec file" <g> | 15:25 |
| LaserJock | heh | 15:25 |
| LaserJock | the problem I see mostly though is upstreams either 1) don't want to package at all or 2) don't want to package for several different distros | 15:26 |
| ScottK | Or don't want to deal with distros at all and just have their users get packages from them | 15:27 |
| LaserJock | yes | 15:27 |
| ScottK | One of my upstreams (who uses Fedora) didn't see the point of getting his stuff into distros. | 15:29 |
| ScottK | I got one of his packages into Debian/Ubuntu and he mentioned he'd gotten a lot of new users show up right after I did that on his mailing list. | 15:29 |
| ScottK | Suddenly he got it and he packages his stuff for Fedora now. | 15:29 |
| ion | Had he been tuomov, he’d have hated you for getting new users. | 15:30 |
| Ng | popcon numbers can sometimes make a good impression :) | 15:30 |
| LaserJock | must upstreams I know just don't have time to learn .specs and debian/ etc. | 15:31 |
| LaserJock | *most | 15:31 |
| ScottK | This guy was distributing rpms already, he just hadn't seen the point in going to the trouble to get it in a distro. | 15:32 |
| LaserJock | and then there are upstreams that fork dependencies in PPAs and call it good ;-) | 15:33 |
| jam | barry: ping | 15:34 |
| jam | you sent a mail as "barry@canonical.com" that got blocked going to udd | 15:34 |
| jam | did you want me to add that address? | 15:34 |
| barry | jam: dang. yes please! | 15:35 |
| jam | hmm.. it says the sender is "now" a member of the list already | 15:36 |
| jam | so apparently it should just work now | 15:36 |
| jam | I know I have a few accounts that get a bit confused sometimes | 15:36 |
| barry | weird, maybe it got held for other reasons | 15:36 |
| Keybuk | if upstreams did their job properly, we wouldn't _need_ distros ;-) | 15:36 |
| jam | I'm pretty sure it thought you weren't a member for a bit | 15:36 |
| === freeflyi1g is now known as freeflying | ||
| jam | barry: ahh, I see why now | 15:37 |
| jam | Reason: SpamAssassin identified this message as possible spam (score 3.8) | 15:37 |
| barry | ouch. i should use fewer ! and $ | 15:38 |
| jam | barry: though the message that got through was: X-Spam-Status: No, score=-2.2 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT autolearn=ham version=3.1.7 | 15:38 |
| jam | had you posted to udd before? | 15:38 |
| jam | As it looks like SQLGrey may have also been involved | 15:39 |
| barry | jam: yep, lots | 15:39 |
| jam | (I'm pretty sure you have) | 15:39 |
| jam | oh, and that sqlgrey stuff may be my local machine, not canonicals | 15:39 |
| jam | yeah, it probably is | 15:40 |
| LaserJock | was barry trying to sell us on the "effects" bzr can have on our personal life? ;-) | 15:40 |
| jam | apparently my mail host likes you | 15:40 |
| jam | but canonical's doesn't :) | 15:40 |
| jam | barry: so my guess is that SA doesn't like "date in past" | 15:41 |
| jam | since it seems to think that it was sent at 4am | 15:41 |
| jam | and then the fact that your mail client encodes everything as base64 | 15:41 |
| * barry restarts ntpd | 15:41 | |
| jam | even though it is just text | 15:41 |
| * persia reads backscroll and yet again wishes that `gzcat foo.diff.gz | patch` was capable of deleting files | 15:41 | |
| Keybuk | persia: it is | 15:41 |
| Keybuk | Ian Jackson just disagreed with being able to do it, so had dpkg refuse to do so | 15:42 |
| barry | jam: i'm posting from a vm and when the host sleeps, my time gets out of whack. unfortunately, that also seems to kill the ntpd service for some reason :( | 15:42 |
| Keybuk | persia: I think the reason dpkg refuses is quite logical | 15:43 |
| Keybuk | people might think that patching a file out of the tarball is an acceptable way to solve DFSG issues | 15:43 |
| Keybuk | when, of course, it isn't | 15:43 |
| persia | That's all! | 15:44 |
| Keybuk | because Debian would still have been distributing the file in the tarball | 15:44 |
| maco | arent you sposed to do that in the orig? | 15:44 |
| Keybuk | of course, nobody believed people would ever put debian directories in the tarball ;) | 15:44 |
| persia | I agree that it's not an acceptable way to make something DFSG-free (the tarball is shipped anyway), but it would mean that suddenly it wouldn't *matter* if upstream ships packaging (debhelpers -i helps to some degree, but only to some degree) | 15:45 |
| Keybuk | it still makes your life hard | 15:45 |
| Keybuk | you'd have to review every new upstream version carefully | 15:45 |
| persia | Can we revisit that, or is that reviving horses that are best forgotten? | 15:45 |
| Keybuk | "grr, upstream added a debian/wibble.foo file that I missed, and now my package fails to install" | 15:45 |
| Keybuk | if we were to revisit anything basic like that, we should probably just invent a new source package format | 15:46 |
| persia | Yeah, but one should be at least reviewing the file listing and dpkg --contents listings anyway, at an absolute minimum. | 15:46 |
| Keybuk | put it in an ubuntu/ directory | 15:46 |
| Keybuk | and then be done ;) | 15:46 |
| persia | Hrm. tempting.... but maybe not. | 15:46 |
| Keybuk | if Colin ever gets hit by a bus, it'll be one of my first jobs ;) | 15:47 |
| Keybuk | Mark's been wanting to do that since day one, so I know I'll be allowed <g> | 15:47 |
| * pitti tosses http://cdimage.ubuntu.com/daily-live/20091218.1/ Keybukwards | 15:48 | |
| Keybuk | pitti: way ahead of you ;) already rsync'd down and updating TFTP and NFS roots | 15:48 |
| Keybuk | will be interesting to see how this works | 15:49 |
| Keybuk | I got good numbers on ratchet | 15:49 |
| Keybuk | and I'm getting increasingly convinced that ratchet is slightly slower than max | 15:49 |
| pitti | good luck! | 15:49 |
| james_w | what's new in this image? | 15:51 |
| pitti | james_w: Keybuk's speedup work from today | 15:51 |
| pitti | (initramfs-tools, etc.) | 15:51 |
| Keybuk | well, last night | 15:51 |
| Keybuk | mostly initramfs-tools | 15:51 |
| james_w | the tsort stuff? | 15:52 |
| ion | How about devtmpfs? | 15:52 |
| Keybuk | no, that was in 18 | 15:52 |
| Keybuk | I replaced all of the scripts/local loop with a tiny binary | 15:52 |
| Keybuk | that uses libudev to do what all that shell was trying to do *properly* | 15:52 |
| james_w | cool | 15:52 |
| Keybuk | ie. if the device doesn't exist, use netlink to wait for udev to finish with it | 15:52 |
| Keybuk | if the device exists, and is in udev's queue, also use netlink | 15:52 |
| Keybuk | if the device exists, and is not in udev's queue, done | 15:53 |
| Keybuk | also obviously outputs the filesystem type as udev knows it, so we don't have to separately probe fstype/blkid in the initramfs | 15:53 |
| Keybuk | one major advantage speed-wise is that it never calls "settle" | 15:54 |
| Keybuk | which means you can mount the root fs in the initramfs while loading of irrelevant modules is still happening | 15:54 |
| pitti | update-initramfs: Generating /boot/initrd.img-2.6.32-8-generic | 15:54 |
| pitti | .: 4: Can't open /scripts/functions | 15:54 |
| pitti | Keybuk: ^ known? | 15:54 |
| Keybuk | pitti: no, can you check through scripts/*/* and see which sources /scripts/functions *before* checking for "prereqs" | 15:55 |
| pitti | ./local-top/cryptroot | 15:56 |
| pitti | so, from cryptsetup | 15:56 |
| Keybuk | pitti: fix is obvious, don't source /scripts/functions until after the prereqs case | 15:56 |
| Keybuk | can you do that one while you're there? | 15:56 |
| * Keybuk has an allergy to cryptsetup | 15:57 | |
| pitti | hm, I moved it down, now it says | 15:57 |
| pitti | [: 22: Private: unexpected operator | 15:57 |
| * pitti sighs | 15:57 | |
| Keybuk | pitti: pastebin the script? | 15:57 |
| pitti | Keybuk: I'll try to squeeze it in (release meeting now) | 15:58 |
| Keybuk | oh, cryptsetup has a *weird* prereqs! | 15:58 |
| pitti | Keybuk: http://people.canonical.com/~pitti/tmp/cryptroot | 15:58 |
| Keybuk | yeah that for just won't work ;) | 15:58 |
| Keybuk | probably should be $(dirname $0) rather than /scripts/local-top | 15:59 |
| === binitamshah|away is now known as binitamshah | ||
| Keybuk | pitti: a change I made the other day is that the prereqs bit of each script is run at mkinitramfs time | 16:01 |
| Keybuk | rather than inside the initramfs | 16:01 |
| Keybuk | so the generated initramfs already knows what order to run things in | 16:02 |
| pitti | Keybuk: updated script (same URL), it doesn't complain now | 16:02 |
| pitti | but I don't claim I really understood what I was doing | 16:02 |
| Keybuk | basically was just expecting /scripts to exist | 16:03 |
| Keybuk | when that's /usr/share/initramfs-tools/scripts | 16:03 |
| Keybuk | (because I'm running it from mkinitramfs now) | 16:04 |
| pitti | Keybuk: so, I'm fine to do that upload if you want me | 16:04 |
| Keybuk | yup, go for it | 16:04 |
| Keybuk | I imagine we'll hit a few of those | 16:04 |
| pitti | uploaded | 16:08 |
| pitti | nice, bzr bd now DTRT even without a .bzr-builddeb/ config | 16:09 |
| james_w | inferring --merge? | 16:09 |
| pitti | right | 16:09 |
| pitti | the cryptsetup tree is full source, but it downloaded the orig.tar.gz, etc. | 16:09 |
| james_w | yeah, that's (yet another) thing you can thanks jelmer for | 16:09 |
| pitti | so far we just copied the very same config into all of our desktop trees | 16:10 |
| pitti | jelmer: *hug* | 16:10 |
| jelmer | pitti: :-) Glad to hear | 16:10 |
| jelmer | we have similar itchjes | 16:10 |
| Keybuk | james_w: I still have issues getting the first tarball into bzr ;) | 16:38 |
| Keybuk | I do sick and evil things like make a pretend upstream-last-release tag | 16:38 |
| Keybuk | or remove debian/changelog and import-dsc the source package I just generated | 16:38 |
| Keybuk | I noticed that it seems to upset the auto-importer though ;-( | 16:39 |
| james_w | hmm | 16:40 |
| james_w | I thought merge-upstream was supposed to work, but I can believe that I broke it | 16:40 |
| Keybuk | it won't work if there isn't a previous upstream tarball | 16:40 |
| Keybuk | it will only make deltas I assume | 16:40 |
| Keybuk | never the initial tarball | 16:41 |
| Keybuk | you can trick it into doing so though | 16:41 |
| james_w | yeah | 16:41 |
| james_w | we should fix that :-) | 16:41 |
| Keybuk | I have been heavily using the bzr stuff though | 16:47 |
| Keybuk | my workflow this cycle is "bzr branch lp:..." ... doesn't exist? file bug; out of date? file bug (and apt-get source) | 16:47 |
| Keybuk | otherwise just use the bzr | 16:47 |
| pitti | ttx: what I meant is that e. g. bug 497455 -> we won't promote until it actually appears on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 16:52 |
| ubottu | Launchpad bug 497455 in libwoodstox-java "MIR for libwoodstox-java" [High,Fix committed] https://launchpad.net/bugs/497455 | 16:52 |
| ttx | pitti: right. It's a eucalyptus runtime dep, so I guess it will show up once the package in built | 16:53 |
| jelmer | pitti: btw, I noticed the MIR for tdb - some of the issues there should be fixed in the version of tdb in sid | 16:53 |
| jelmer | pitti: Are you the right person to talk to about the MIR, or somebody else? | 16:53 |
| jelmer | pitti: (I'm the Debian maintainer) | 16:53 |
| pitti | jelmer: I'm one right person, yes | 16:53 |
| kees | pitti: for the SIGXCPU+apport thing, I saw that you merged it, but I just wanted to make sure you felt that was a valid approach. | 16:54 |
| pitti | jelmer: which "issues" do you mean? | 16:54 |
| pitti | kees: it looks fine to me | 16:55 |
| kees | pitti: ok, cool. No other signals like those two jumped out. | 16:55 |
| jelmer | pitti: tdb-dev has been renamed to libtdb-dev, manpages will be included in the next upstream version | 16:56 |
| ScottK | slangasek: It'd be nice (although lower priority than powerpc) if you could look at qt4-x11 on ia64 too. I'm lost in a twisty turny maze of ifdefs. | 17:21 |
| * slangasek gibbers | 17:24 | |
| ScottK | slangasek: The upstream feedback was: You have a config.h, remove it. the issue is that #include "config.h" is including the wrong file | 17:25 |
| ScottK | Since it works on other archs. | 17:25 |
| ScottK | I think it's an ifdef issue | 17:26 |
| Keybuk | mdz: are any of the videod sessions ever going to appear on blip.tv ? | 17:57 |
| === markus_ is now known as thekorn_ | ||
| machina | hi, I'm trying to update this copyright from this http://pastebin.com/d5200e964 to this http://pastebin.com/d1fafa456 but I don't know if it's right for me to put a copyright under the debian maintainer's name? | 18:09 |
| machina | this is about updating an Ubuntu/debian package btw.. | 18:10 |
| ebroder | I don't suppose I could ask somebody to do a sync run so the new version of the packge I was just about to work on would hit the repos? :) | 18:49 |
| ScottK | slangasek: I think I found my way through the twisty/turny maze for qt4-x11 ifdefs and ia64. Found a "- || defined(__ia64__) \" between the last version and the current one. | 18:55 |
| slangasek | ah, cool | 18:55 |
| slangasek | ebroder: what package? | 18:55 |
| ebroder | slangasek: open-vm-tools | 19:00 |
| slangasek | ah, needs a sync run on contrib; looking | 19:00 |
| slangasek | ebroder: syncing | 19:05 |
| ebroder | Yay! Thanks, slangasek | 19:07 |
| === yofel_ is now known as yofel | ||
| Lutin | those days, who do I have to ask to get a give-back on the buildds ? | 19:09 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| ScottK | slangasek: If I give you a debdiff for qt4-x11, could you testbuild it on a ia64 porter box? It's a huge package for me just to blind upload. | 19:28 |
| slangasek | sure | 19:28 |
| ScottK | OK. I'll have it in a few. | 19:28 |
| ScottK | .dff.gz for that package takes an eternity to generate on my laptop. | 19:29 |
| ScottK | dff/diff | 19:29 |
| === mehdid_ is now known as darkwise | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| ScottK | Right, so the good news is the emergency drop protection shutdown on my laptop works. The bad news is the diff.gz wasn't done yet. | 19:48 |
| ScottK | It was kind of cool to see the laptop blink off in mid-air when I dropped it. | 19:48 |
| slangasek | heh | 19:54 |
| ion | Why power down the entire laptop? Why not just park the HDD heads? | 19:57 |
| Lutin | could someone with a lucid chroot try to install libeina-svn-05 (no matter what arch.) | 20:00 |
| slangasek | Lutin: could; but is the problem you're trying to solve related to the fact that this package needs a binary promotion to main? | 20:02 |
| * ScottK guesses yes. | 20:03 | |
| ScottK | ion: I didn't design the hardware. | 20:03 |
| ion | Nobody blamed you for the hardware design. | 20:04 |
| ScottK | It just seemed odd to ask me why it worked the way it does. | 20:04 |
| ion | I asked the channel. | 20:04 |
| ScottK | ok | 20:04 |
| ion | sincerely willing to learn the technical reason for shutting down everything. | 20:05 |
| slangasek | perhaps because the hardware doesn't trust the OS to park the heads and leave them parked | 20:07 |
| ion | The hardware could force the heads to be parked for a period and the OS to wait. | 20:08 |
| ScottK | slangasek: http://pastebin.com/f3e99eaa3 | 20:11 |
| ScottK | slangasek: On the off chance that builds, please just throw it at the archive. | 20:11 |
| slangasek | how do I extract a usable patch from pastebin? | 20:12 |
| arthur_ | slangasek: see the textarea in the bottom | 20:14 |
| slangasek | I see it; cut-n-pasting from it didn't please patch, that's why I was asking | 20:14 |
| arthur_ | right after "To highlight particular lines, prefix each line with @@" | 20:14 |
| arthur_ | ah | 20:14 |
| slangasek | patch: **** Only garbage was found in the patch input. | 20:14 |
| slangasek | oh, haha | 20:15 |
| slangasek | because it eats @@ at the beginning of a line | 20:15 |
| arthur_ | nice spot | 20:15 |
| slangasek | ok, got it | 20:15 |
| ScottK | Oops | 20:16 |
| ScottK | When I click on download it comes up correct. | 20:17 |
| slangasek | oh, there's a download button, ok | 20:17 |
| slangasek | :) | 20:17 |
| Lutin | slangasek: that's it, thanks | 20:22 |
| slangasek | Lutin: ok, should be fixed in the next pulse then | 20:22 |
| Lutin | alright, thanks a lot | 20:22 |
| Lutin | slangasek: in fact JamieBennett just pointed out that it's been promoted some times ago | 20:39 |
| slangasek | Lutin: not so; the binary was in universe until around the time I commented | 20:39 |
| JamieBennett | Jonathan Riddell wrote on 2009-08-24:#6 Package moved to main | 20:39 |
| JamieBennett | from the bug comments | 20:40 |
| * ScottK suspects a library transition | 20:41 | |
| slangasek | that refers to a source package | 20:41 |
| Lutin | ah, true. the source package introduces a new binary package which wouldn't have been promoted automatically ? | 20:44 |
| JamieBennett | slangasek: Is there an active archive admin around which could kick the binary into main for us then? | 20:49 |
| slangasek | JamieBennett: already did, see above | 20:51 |
| JamieBennett | OK, thanks | 20:52 |
| slangasek | Lutin: it's a routine archive admin activity to reconcile http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, so it /should/ be < 48h turnaround from accepting the package to making sure it's in main if it's supposed to be | 20:52 |
| Lutin | slangasek: ok, thanks for the explanation | 20:55 |
| wgrant | lamont: Are you planning to get the lp-buildd changes merged soonish? | 21:16 |
| lamont | bigjools was supposed to land them, I thought | 21:16 |
| wgrant | Ah, OK. | 21:16 |
| lamont | lp:~lamont/launchpad/lp-buildd/ | 21:16 |
| lamont | is what I actually built | 21:17 |
| lamont | and actually has changes beyond 54 | 21:17 |
| wgrant | Ah, I wondered what those extra three revs were for. | 21:17 |
| lamont | yeah, it was the lalalalalalala fix these too things that fell out of reviewing changes to the machines where I installed the package | 21:18 |
| lamont | some just landed after I'd cut 54, and/or were invasive enough that I want them to get more testing before I roll them. | 21:18 |
| HenriqueRocha | hi | 21:45 |
| lamont | slangasek: bug 498331 | 21:46 |
| ubottu | Launchpad bug 498331 in libgphoto2 "FTBFS: excessive something" [Undecided,New] https://launchpad.net/bugs/498331 | 21:46 |
| HenriqueRocha | i'm trying to install lucid alpha 1 but it doesn't install | 21:46 |
| slangasek | lamont: how precise :-) | 21:46 |
| lamont | slangasek: I decided to make sure it had a descriptive subject.... | 21:46 |
| === HenriqueRocha is now known as hrocha | ||
| lamont | dear fellow buildd admins: DO NOT give-back libgphoto2/armel. | 21:47 |
| hrocha | is it possible that it is not installing because i'm using the locale in portuguese? | 21:47 |
| slangasek | hrocha: #ubuntu+1 is the channel for lucid support; I'm not aware of any locale-specific issues in alpha-1 | 21:48 |
| hrocha | ok, thanks | 21:48 |
| === asac_ is now known as asac | ||
| === sabdfl1 is now known as sabdfl | ||
| === jam1 is now known as jam | ||
| === Tm_K is now known as Tm_Tr | ||
| === Tm_T is now known as Tm_P | ||
| === Tm_P is now known as Tm_T | ||
| === asac_ is now known as asac | ||
| === elky is now known as elky` | ||
| === elky` is now known as elky | ||
| ebroder | Wait, what? Why can't I target bug #191776 for Hardy? The package has always been in multiverse - I should be able to | 23:31 |
| ubottu | Launchpad bug 191776 in open-vm-tools "Shutdown guest using the VI Client with VMware ESX 3.0.2 doesn't work" [Low,Fix released] https://launchpad.net/bugs/191776 | 23:31 |
| wgrant | ebroder: It doesn't exist in Hardy. | 23:42 |
| wgrant | It was removed just before release. | 23:42 |
| ebroder | Huh! How about that | 23:42 |
| wgrant | (and it was in universe then) | 23:42 |
| ebroder | Oh yeah - the bug was reported against Hardy a4 | 23:43 |
| ebroder | It seems like it would be useful if I could deal with nominations for releases the package wasn't in at all. Oh well | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!