| === dendro-afk is now known as dendrobates | ||
| === ogra_ac_ is now known as ogra_ac | ||
| Riddell | davidm: ok to release images for RC? | 00:38 |
|---|---|---|
| ogra_ac | Riddell, what does the isotracker say (and better ask GrueMaster, he is testing atm) | 00:38 |
| ogra_ac | Riddell, theoretically they should all be fine | 00:39 |
| Riddell | ogra_ac: if I read it right it says there's a couple of serious bugs and no failures | 00:41 |
| ogra_ac | Riddell, great | 00:42 |
| ogra_ac | so we are not jobless after RC :) | 00:44 |
| ogra_ac | Riddell, looking at the treacker they seem to all be known bugs ... fine to release | 00:47 |
| ogra_ac | Riddell, netbook preinstalled for armel omap and omap4 ... netbook live for armel dove are the images we release | 00:48 |
| ogra_ac | ... and with that statement i'm off to bed | 00:49 |
| jjardon | Hello, is there any possiblity to ship pygobject 2.26 in maverick? They are the only supported python bindings upstream | 01:37 |
| jjardon | Also, PyGTK apps are recommended to switch to PyGObject ASAP | 01:37 |
| persia | You mentioned this before. You might want to file a bug. IRC is notoriously bad at maintaining state. | 01:38 |
| persia | At this point, it would require significant coordination push, and be considered release-critical by a number of people. | 01:38 |
| persia | It's most especially concerning because it is known that all the apps that use the PyGTK and PyGObject implementations currently in maverick work (at least to the extent each application has been tested). | 01:39 |
| persia | It is most certainly unknown whether they would work with the latest PyGObject (And many likely remain to be ported) | 01:40 |
| === ivoks is now known as ivoks-afk | ||
| poolie | hi, will someone please sponsor maxb's upload from https://bugs.launchpad.net/bugs/636930 | 01:59 |
| ubottu | Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged] | 01:59 |
| ScottK | poolie: Are you asking for a 2.2.1 upload or just a fix for this? | 02:03 |
| ScottK | (I think I see both in the bug) | 02:03 |
| poolie | ScottK: the whole bugfix update | 02:05 |
| poolie | ie all of 2.2.1 | 02:06 |
| poolie | ScottK: we have a microreleaseupdate exception | 02:06 |
| persia | poolie, That's only a guarantee that the upstream can be processed, not that a given packaging of it happens to be suitable for sponsoring (not meaning anything either positive or negative towards this specific packaging) | 02:08 |
| maxb | I can't | 02:10 |
| maxb | oops, I just responded ot something hours ago in scrollback | 02:10 |
| poolie | persia, scottk, ok so what can we actually do with this specific package? | 02:15 |
| maxb | First things first, we need an official ubuntu-release verdict on whether to go release pocket or SRU | 02:17 |
| maxb | As informal IRC opinions have been inconclusive | 02:17 |
| persia | poolie, Wait for someone who can upload it (not me) to review and either upload or comment on why they aren't uploading. It's exceedingly unlikely to be sponsored pre-RC release, and even if it is so sponsored, isn't going to be accepted by the Release Team until post-RC. | 02:18 |
| poolie | how could we get in touch with such a person? | 02:19 |
| poolie | historically just subscribing the team to the bug and commenting has not got much of a response | 02:19 |
| persia | maxb, If you're seeking that, then yes, you want to have had a different request. | 02:19 |
| maxb | Exactly - thus, the first thing being getting the release team's verdict on whether they want this in release or proposed pocket | 02:19 |
| persia | poolie, It's supposed to work that way. When it doesn't, you can ask here or in #ubuntu-release. | 02:20 |
| poolie | ScottK: i see you're in ~ubuntu-release, what do you think? | 02:26 |
| poolie | running the tests now | 02:35 |
| ScottK | poolie: My view is that successfully completing the tests that would be mandated for an SRU is a precondition. If it can do that (and from the bug, I have the impression that you aren't quite there yet), then I would tend to be in favor, but I'd want to discuss it with pitti, since he seemed to lean against. If there's a focused patch for that particular issue, I'd recommend uploading that while it's decided. | 03:34 |
| ScottK | poolie: It would also be useful to know if bzr is in fact on an ISO or just in Main for other reasons. I don't know and I'm too tired to look it up at the moment. | 03:44 |
| james_w | I'm pretty sure it's just in main | 03:53 |
| ScottK | That would make it less scary from my POV since it gives us almost another week to deal with regressions. | 03:54 |
| persia | If fails to show in any of the manifest files I mirror (which is an incomplete set, but wide). | 03:54 |
| ScottK | Of course if I sponsor it, then I can't accept it and the final decision becomes "not my problem". That has a certain appeal too. | 03:55 |
| persia | heh | 03:56 |
| sladen | ScottK++ | 04:06 |
| === jamesh_ is now known as jamesh | ||
| poolie | ScottK: i ran the tests and posted the outcome; not sure if you saw that yet | 04:48 |
| poolie | oh i see | 04:50 |
| poolie | ok, i'll work out what's up with that ssl error | 04:50 |
| === jam1 is now known as jam | ||
| === bjf is now known as bjf[afk] | ||
| poolie | james_w: your bug 646979 logic seems plausible to me on a brief read through | 05:27 |
| ubottu | Launchpad bug 646979 in bzr-builddeb "merge-package should maybe vary which branch it merges the combined upstream to" [Undecided,New] https://launchpad.net/bugs/646979 | 05:27 |
| james_w | good | 05:27 |
| poolie | i stress only brief for the moment | 05:30 |
| james_w | yeah, I'm not going to take snap action after thinking about it for this long :-) | 05:30 |
| === almaisan-away is now known as al-maisan | ||
| === amitk-afk is now known as amitk | ||
| dholbach | good morning | 07:39 |
| jibel | didrocks, could you have a look at bug 651325. it was during a test upgrade from a fresh wubi 10.04.1 to 10.10 | 08:17 |
| ubottu | Launchpad bug 651325 in update-manager (Ubuntu) "package gnome-keyring 2.92.92.is.2.30.3-0ubuntu1.1 failed to install/upgrade: /var/lib/dpkg/tmp.ci/preinst: 31: dpkg-maintscript-helper: not found" [Undecided,New] https://launchpad.net/bugs/651325 | 08:17 |
| didrocks | jibel: oh, let me check, I have an idea why we can have that :) | 08:17 |
| didrocks | jibel: yeah, dpkg doesn't have dpkg-maintscript-helper in list, I get trapped :) | 08:18 |
| didrocks | jibel: I'll fix that then, thanks for the info :) | 08:19 |
| jibel | didrocks, thank you | 08:20 |
| mvo | didrocks: I have a fix ready, its just a missing pre-depends on dpkg | 08:20 |
| didrocks | mvo: oh good, thanks :) | 08:21 |
| mvo | didrocks: commited, I can upload if nothing else is pedning | 08:21 |
| didrocks | mvo: anything else as far as I know of, please do :) | 08:22 |
| didrocks | (that's maybe something to list until next LTS, if we use dpkg-maintscript-helper, for handling upgrade from lucid, we need the pre-depends on dpkg) | 08:23 |
| didrocks | not sure where to list that however | 08:23 |
| persia | debian/README.source might be a handy innocuous place for that sort of thing. | 08:23 |
| === dendrobates is now known as dendro-afk | ||
| didrocks | persia: for dpkg? do you think people using dpkg-maintscript-helper will look at dpkg README file? :) | 08:24 |
| persia | didrocks, I was thinking for that which needs it. If you want something more general, then it probably belongs in the dpkg-maintscript-helper manpage. | 08:25 |
| didrocks | yeah, that was my guess, I'll patch it for natty | 08:25 |
| YokoZar | Can someone reject my (pitti-sponsored) icoutils upload, I need to make a new one (the license has changed and debian/copyright needs to be fixed) | 08:27 |
| StevenK | YokoZar: To maverick? | 08:28 |
| YokoZar | StevenK: Yeah | 08:28 |
| StevenK | YokoZar: 0.29.1-0ubuntu1 ? | 08:29 |
| YokoZar | StevenK: yup | 08:30 |
| StevenK | YokoZar: Right, cool. Rejected. | 08:30 |
| twb | Does Ubuntu have something like cdn.debian.net, which resolves to a "nearby" mirror? | 08:32 |
| twb | I realize ubuntu's d-i has some cleverness to pick a nearby mirror at install time, but a one-shot detection is suboptimal for roaming laptops. | 08:33 |
| === smb` is now known as smb | ||
| persia | twb, I don't believe so. There's some mirror stuff in python-apt, and I think update-manager can use it (but I don't believe it does more than verify the sources.list only contains mirrors in the list) | 08:41 |
| twb | I guess the other way to do it is to just get everyone onto ipv6 and use anycast :-P | 08:42 |
| persia | Heh, indeed. | 08:42 |
| pitti | Good morning | 08:42 |
| pitti | yofel: will do, thanks for the MP | 08:43 |
| pitti | ScottK: I guess bzr is at least on the DVDs | 08:43 |
| twb | Actually, while we're discussing it, what is the *CLI* equivalent of apt-spy in Ubuntu? | 08:45 |
| twb | I see synaptic can do it, but that's no use on a server. | 08:45 |
| twb | (That is, go get the mirror list from ubuntu.com, count the hops to each one, then return the mirror with the fewest hops.) | 08:45 |
| persia | twb, I'm not sure we have one: there's a local mirror list from python-apt which would be a sensible place to start. | 08:46 |
| twb | okey dokey | 08:46 |
| twb | For my own means I usually know out-of-band, but it comes up on #ubuntu-server occasionally | 08:47 |
| persia | Probably easy enough to toss one together. | 08:47 |
| mvo | twb: there is a "mirror" protocol in apt | 08:47 |
| mvo | twb: you can use "deb mirror://mirrors.ubuntu.com/mirrors.txt maverick main universe" | 08:48 |
| twb | Oh neat | 08:48 |
| persia | Oh, cool! | 08:48 |
| mvo | its not perfect yet, that is why we have no done it by default (yet) | 08:48 |
| mvo | but it should work pretty well 99% of the time | 08:48 |
| twb | There was also that guy working on a bittorrent apt method, but I don't think he got it production-ready | 08:49 |
| mvo | twb: yeah, apt-transport-debtorrent - we have it in the archive | 08:50 |
| twb | Do you happen to know what the Debian equivalent of mirrors.ubuntu.com/mirrors.txt is? README.mirrors.txt has a different format | 08:50 |
| mvo | twb: where is README.mirrors.txt located? | 08:54 |
| twb | http://ftp.au.debian.org/debian/README.mirrors.txt | 08:55 |
| poolie | hi pitti, | 08:55 |
| twb | I *think* that's the file apt-spy uses | 08:55 |
| pitti | hey poolie | 08:55 |
| poolie | given our test results that there are no new test failures from the installed bzr, in bug 636930 | 08:55 |
| ubottu | Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged] https://launchpad.net/bugs/636930 | 08:55 |
| poolie | what's next? | 08:55 |
| twb | method/mirror.cc doesn't offer much explanation, except it implies that mirrors.txt would need to be dynamically generated by the server (based on geo-ip or such) to be useful | 08:56 |
| mvo | twb: aha, thanks. the mirror method in apt depends on a server that uses geoip so it will not be able to use this file | 08:56 |
| persia | The fastest server is often not the nearest one geographically, depending on network topology. | 08:57 |
| twb | persia: I was impressed that it even listed my ISP's tertiary mirror, though | 08:57 |
| twb | It wasn't the first one in the list, though | 08:57 |
| twb | I get http://paste.debian.net/92510/ from within the internode network, but I am originating from a portable IP so it probably doesn't get very well. | 08:59 |
| twb | s/get/guess/ | 08:59 |
| twb | Hmm, same result when coming from an ISP-assigned IP. | 08:59 |
| === badipod_ is now known as badipod | ||
| poolie | pitti: ? | 09:05 |
| mvo | twb: yes, it relies on the server, the long term goal is to provide stats (opt-in of course) so that the server can build a optimal list for most people | 09:07 |
| === spike_ is now known as spikeWRK | ||
| mvo | tkamppeter_: hi, around? is foomatic-db-compressed-ppds a drop-in replacement for foomatic-db or are there apps that breaks if foomatic-db-compressed-ppds are installed instead of foomatic-db ? | 09:10 |
| pitti | poolie: as I said, it can be uploaded to maverick-proposed | 09:12 |
| === dendro-afk is now known as dendrobates | ||
| poolie | maxb: so i think now you should ask someone to sponsor your upload to maverick- | 09:23 |
| poolie | proposed? | 09:23 |
| persia | Common procedure is to prepare a candidate upload with maverick-proposed in the changelog, and either propose a merge in LP or file a bug and subscribe the sponsors team with a debdiff. | 09:24 |
| maxb | poolie: well, hmm. only if the decision has been finally taken to handle this as a SRU, not a late-breaking release pocket upload | 09:27 |
| maxb | I am tempted to just arbitrarily decide it's a SRU, given that's what we were intending to do at first, before the idea of a late-breaking release pocket upload was ever mentioned | 09:27 |
| poolie | maxb, i don't know if that's optimal but it's pretty good | 09:31 |
| poolie | i suspect everybody running this will get -updates | 09:31 |
| poolie | and it'd be nice to just get it resolved and do other things | 09:32 |
| mvo | tkamppeter_: if you have time I would like to talk about #647460, what we can do about it | 09:41 |
| persia | maxb, The statement at :12 by a member of ~ubuntu-release seemed fairly definitive that it ought be considered for SRU. Feel free to copy & paste to a bug comment if you want it tracked there. | 09:48 |
| maxb | persia: yes, I think we shall aim for SRU. The confusion has been that we've had different thoughts on the matter from pitti and ScottK | 09:53 |
| pitti | a week ago we weren't frozen for RC yet, so back then my suggestion was to just upload it if it was ready | 09:55 |
| persia | maxb, The key is to take the first answer you get from any member of the release team, make sure it's documented somewhere, and run with it. If you wait for RT consensus, you'll end up in next cycle :) | 09:55 |
| persia | (and all the members of the release team tend to tell you to ask someone else if they aren't prepared to take a decision) | 09:56 |
| poolie | yeah, or take the answer you like best :) | 10:04 |
| pitti | it didn't really differ, though | 10:04 |
| pitti | it makes a difference whether you ask before or after a freeze :) | 10:05 |
| persia | poolie, Please don't do that. The first answer should be correct (there was a long discussion about one answer vs. two answers in agreement in the past with the conclusion that one was the right way to proceed) | 10:08 |
| mvo | cjwatson: I think I found the bug in the livefs script (just fyi so that we don't duplicate work) | 10:15 |
| === doko_ is now known as doko | ||
| doko | I'd like to understand why https://edge.launchpad.net/ubuntu/+source/lash/0.6.0~rc2-1 ended up in maverick. there's no sync request about it | 10:17 |
| persia | I thought I requested that. | 10:21 |
| doko | persia: being aware of the armel and powerpc build failures in experimental? :-/ | 10:35 |
| persia | From experimental? I didn't request that. | 10:38 |
| persia | (and I can't find the bug either :/ ) | 10:38 |
| doko | there is none ... | 10:38 |
| persia | There was one. NCommander, I, ogra, and seb128 all touched it, and Riddell closed it, unless I'm thinking of a different lash | 10:40 |
| persia | But that was for a sync from *unstable* | 10:40 |
| seb128 | I don't even know what that source is I doubt I touched it | 10:41 |
| * ogra neither | 10:42 | |
| persia | seb128, There was an associated issue with d-shlibs and you told NCommander to fix it with hinting, rather than a hardcoded patch. | 10:42 |
| ogra | oh, that one | 10:42 |
| persia | Right. I requested the sync of 0.5.4.0-2 (https://launchpad.net/ubuntu/maverick/+source/lash/0.5.4.0-2 ) | 10:43 |
| persia | doko, Sorry for the confusion. | 10:43 |
| doko | persia, and we ended up with 0.6rc2? | 10:44 |
| persia | I don't know how that happened. 0.5.4.0-2 was FTBFS on armel because of some other stuff related to d-shlibs, but 0.6rc2 is broken for much more annoying reasons. | 10:44 |
| seb128 | doko, ask quadrispro | 10:45 |
| seb128 | he did the upload it seems | 10:45 |
| seb128 | he apprently synced it manually himself | 10:46 |
| Laney | looks like a syncpackage upload | 10:46 |
| doko | seb128: it's a sync ... | 10:46 |
| seb128 | doko, it's a fake sync | 10:46 |
| seb128 | ie one done manually | 10:46 |
| Laney | override distro in changesfile, sign, upload | 10:47 |
| seb128 | otherwise it would be an Ubuntu Installer upload | 10:47 |
| doko | seb128: yes, from experimental, so there should be a bug report? | 10:47 |
| Laney | that's not enforced | 10:47 |
| Laney | any developer can just upload as normal | 10:47 |
| seb128 | doko, no, it's an upload by somebody with upload rights | 10:47 |
| doko | ahh, that could be. but quadrispro is the debian maintainer too, and uploading something which is broken on three archs is ... unfriendly | 10:47 |
| seb128 | doko, talk to him I guess, I don't know why he uploaded | 10:48 |
| persia | It's rather unfortunate, really. Lots uses lash. | 10:48 |
| doko | anyway, fixed | 10:49 |
| ogra | i asked him to apply the same patch to d-shlibs we used in all former releases | 10:49 |
| ogra | which back then fixed 0.5.4.0-2 | 10:50 |
| === bilalakhtar_ is now known as bilalakhtar | ||
| doko | seb128: still wondering why a fake sync is required for an .orig.tar.gz not yet in ubuntu | 10:58 |
| Laney | doko: People do it because it means your upload happens immediately rather than waiting for an archive admin | 10:58 |
| doko | Laney: fine, imnsho this maybe should be restricted | 11:01 |
| seb128 | doko, it's not required, it's somebody who decided to not wait on archive admins and file a proper sync request and did it manually itself | 11:01 |
| seb128 | doko, there is no way to restrict that, it's like restricting upload to somebody having upload rights | 11:01 |
| doko | seb128: policy? | 11:02 |
| seb128 | he could as well have taken the debian version changed the number to 0ubuntu1 or 1~ubuntu and uploaded | 11:02 |
| Laney | I've tried to convince individuals that it's usually not required. | 11:02 |
| Laney | having said that though, I have used such scripts myself | 11:02 |
| Laney | for example when running a transition with long dep chains | 11:02 |
| seb128 | doko, the last time that was discussed on the list nobody objected strongly to people doing their sync themself | 11:02 |
| persia | Laney, Most archive-admins will happily run a sequence of lists for those over a few hours, if given a prepared list. | 11:02 |
| seb128 | ideally we would not need archive admin to do syncs | 11:03 |
| seb128 | whoever has upload right should be able to sync | 11:03 |
| pitti | I do that all the time; I fix somethign, and then upload to Debian and Ubuntu at the same time | 11:03 |
| seb128 | there is no reason to review syncs over uploads | 11:03 |
| persia | We all agree that developers should be able to do syncs, but we should be doing them *IN LP*, not with hacked .changes files. | 11:03 |
| ajmitch | seb128: that requires a bit more work on soyuz though | 11:03 |
| seb128 | right | 11:03 |
| pitti | persia: what do you think sync-source.py does? :-) | 11:03 |
| seb128 | but that would not have solved the issue doko has there | 11:03 |
| persia | ajmitch, Not that much: mostly currently blocked on running the changelog import job. | 11:03 |
| doko | seb128, Laney: yes, but please not from experimental, and not, if you know as debian maintainer, that the package builds on everything non ix86 | 11:03 |
| ajmitch | pitti: I've seen the code, it's evil :) | 11:03 |
| pitti | at some point we'll have native source syncing, like copy-packages.py | 11:04 |
| seb128 | doko, you have an issue with the maintainer decision there not with the policy or workflow | 11:04 |
| persia | pitti, I know precisely what it does: I've used it. The key bit is that we track it nicely when we use the AA-based process. | 11:04 |
| Laney | doko: Really it's just an instance of general care when uploading. In this case the fact that it's an emulated sync is immaterial | 11:04 |
| pitti | when we have a complete and current Debian import | 11:04 |
| pitti | persia: oh, you are an archive admin now? | 11:04 |
| seb128 | doko, we would have synced it the same way if it was an official sync request | 11:04 |
| pitti | persia: (sync-source.py is the launchpad script) | 11:04 |
| persia | pitti, No, but I used your script back in the hardy-release-rush because you gave it to me to run out-of-archive because you didn't have time for my syncs :) | 11:05 |
| doko | seb128: without looking for build failures first? sorry that a thing at least I do check | 11:05 |
| seb128 | doko, we can check debian builds etc for the hundred of sync request every week, we just trust the maintainer who do requests | 11:05 |
| persia | Oh, I'm thinking of something different then. | 11:05 |
| pitti | persia: ah, that's something else; but in essence it does teh same as the launchpad script: craft a .changes for an existing .dsc | 11:05 |
| seb128 | doko, it's the job of whoever has upload rights and been asking for the sync or acking it | 11:05 |
| persia | Right. There's a better way to do it mostly ready on LP, but pending some job execution time. | 11:05 |
| seb128 | doko, and not archive admin doesn't have the time to do the submitter work and check everything for hundred of syncs | 11:06 |
| persia | Maybe sometime during natty, if we're lucky. | 11:06 |
| Laney | persia: Yes, indeed I could have, and have done in the past for haskell transitions. In this instance I had quite limited slots to work on the rebuilds so didn't want to block on anyone else, but I take your point. | 11:06 |
| pitti | FTR, archive admins can't check Debian FTBFS when doing sync processing either | 11:06 |
| doko | no, but it should be policy for the uploader | 11:06 |
| persia | And they oughtn't be expected to. archive-admins ought perform the syncs nearly blindly, if it has the right ACK. | 11:06 |
| Laney | you have to assume that the uploader knows what they are doing | 11:06 |
| pitti | doko: I agree | 11:06 |
| seb128 | doko, right | 11:06 |
| persia | doko, Yes. Complain to quadrispro | 11:06 |
| pitti | i. e. on the uploader's or sync requestor's side | 11:06 |
| Laney | anyway, maybe a mail to the uploader CCed to some ML would work here | 11:06 |
| seb128 | as said before the issue there is the maintainer, no how it was synced | 11:07 |
| === dendrobates is now known as dendro-afk | ||
| ajmitch | now if it was fine in debian & only failed to build on those archs in ubuntu, that's harder to catch for a maintainer | 11:08 |
| bdrung_ | yes, the uploader has to make sure that the package builds | 11:08 |
| pitti | persia: I mainly use my syncpackage script because it simplifies my workflow; I don't need to wait for a day after the Debian upload and then remember to do the sync, etc. | 11:08 |
| ajmitch | bdrung_: right, but it's hard to test on hardware we don't have unless it's uploaded to PPAs | 11:09 |
| Laney | It's easy to catch, because you get a mail for the FTBFS. | 11:09 |
| bdrung_ | ajmitch: it needs to build at least on your architecture | 11:10 |
| persia | pitti, I almost always wait, just to check for odd build issues, etc. (although less now that I can test-compile on all remaining architectures in Ubuntu) | 11:10 |
| Laney | fixing with a subsequent upload isn't a problem | 11:10 |
| Laney | ignoring porting problems is | 11:10 |
| quadrispro | ehy, I'm here, hi all. Sorry for the {delay,mistake}, I need just some minutes and I'm working on the patch | 11:10 |
| pitti | persia: hm; I just build on amd64; I don't think that a lot of people test-build on more than one arch | 11:10 |
| persia | Laney, Ideally, I'd prefer that it wasn't like that, just because sometimes it interferes with images at milestone times. | 11:10 |
| pitti | and frankly, I think they shouldn't | 11:11 |
| persia | Why not? | 11:11 |
| pitti | sudden arch specific FTBFS don't happen often enough to warrant slowing down every developer to test build on arm | 11:11 |
| doko | quadrispro: it's now fixed | 11:11 |
| pitti | you'd kill a lot of productivity for a very unlikely cause | 11:11 |
| pitti | and if it FTBFSes on the arm buildds, you'll get a mail and can still deal with it | 11:11 |
| persia | pitti, most packages don't take *that* long on armel, but yeah, until there's lots more fast HW... | 11:11 |
| quadrispro | oh, I get there late | 11:12 |
| pitti | persia: well, but few people have an armel box at home :) | 11:12 |
| doko | yes, three month | 11:12 |
| persia | pitti, Yeah, well, ones capable of running what Ubuntu appears to have stabilized upon have only been on the market ~1 year. | 11:12 |
| pitti | persia: and even if they do, I still consider test-rebuilding every package update locally on three arches before upload a massive waste of developer time/power | 11:13 |
| doko | pitti: in this case: https://buildd.debian.org/status/package.php?p=lash&suite=experimental | 11:13 |
| * persia needs to clean up and publish some scripts. | 11:13 | |
| pitti | doko: oh, I wasn't arguing against checking the Debian buildds before requesting/doing a sync | 11:13 |
| pitti | doko: just that I don't want people to test-build every upload on three arches | 11:14 |
| persia | pitti, I think everyone should test-build on every arch *as long as it doesn't slow them down*. | 11:14 |
| persia | I agree that waiting around for builds to finish is a waste of time. | 11:14 |
| pitti | persia: but it will slow you down.. | 11:15 |
| persia | Why? | 11:15 |
| pitti | persia: I don't think our buildds are a bottleneck enough to consider the odd arch specific FTBFS as too much of a resource waste | 11:15 |
| pitti | developer time >> buildd time | 11:15 |
| quadrispro | the ftbfs mail was put in spam by gmail... I'm very very sorry of that | 11:16 |
| quadrispro | 25 september | 11:16 |
| pitti | persia: how many devs do you know who have a fully automated kees-style sbuild system which will do automatic builds on three arches for a pacakge? | 11:16 |
| persia | Maybe 10. | 11:16 |
| pitti | wow | 11:16 |
| pitti | that's about 9 more than I know, so I'm honestly surprised | 11:16 |
| pitti | persia: well, let's just agree to disagree then | 11:16 |
| doko | pitti: but it adds work load for people then having to clear up things | 11:17 |
| persia | I might be over-estimating, but I know there's been quite a few of us who have been discussing the multi-arch simultaneous sbuild dispatch stuff over the past 3-4 cycles. | 11:17 |
| pitti | doko: no, why? | 11:17 |
| doko | pitti: http://people.canonical.com/~ubuntu-archive/NBS/ | 11:17 |
| pitti | doko: if I upload a new package which suddenly FTBFSes on armel because of, say, a toolchain change, I get notified and can fix it afterwards | 11:17 |
| pitti | how does that slow down anyone else? | 11:17 |
| doko | so the soname upload have to be done again | 11:18 |
| pitti | but 90% of the FTBFSes that I get are either random buildd congestion or bad timing with library transitions, etc.; and they don't happen on local rebuilds anyway, so they wouldn't help me at all | 11:18 |
| pitti | doko: soname upload? | 11:18 |
| pitti | "same"? | 11:19 |
| persia | pitti, The difference might be that folks who chase build failures get the worst of things, for packages that aren't watched so closely, and you take care of healthy packages that just work. | 11:19 |
| pitti | persia: presumably | 11:19 |
| doko | liblash soname change | 11:19 |
| pitti | persia: but I'm specifically not talking about trying to fix an existing FTBFS | 11:19 |
| persia | Because I wish things worked the way you describe, but sympathise with doko's experience. | 11:19 |
| pitti | I'm not arguing about the lash example here | 11:19 |
| pitti | I agree that one should at least check Debian buildd status before requesting a sync | 11:20 |
| doko | but while I have all your attention ... | 11:20 |
| pitti | I'm just aguing against your "every dev shoudl test-buid every upload on every arch" | 11:20 |
| persia | doko, ? | 11:20 |
| doko | ... there are still three powerpc build failures we should care about: performous-tools, mrpt and odin | 11:20 |
| doko | and: http://people.canonical.com/~ubuntu-archive/NBS/libopensync0-dev | 11:21 |
| azeem | what's with libopensync0-dev? | 11:21 |
| pitti | it's NBS | 11:22 |
| doko | azeem: not anymore in the archive | 11:22 |
| azeem | ah | 11:22 |
| pitti | azeem: the reverse dependencies need to be rebuilt against libopensync1exp7 | 11:22 |
| azeem | good luck | 11:22 |
| pitti | cjwatson mentioned that these are nontrivial, i. e. require sourceful changes | 11:22 |
| \sh | pitti: how should someone do sbuild setups for arm archs on an amd64 which can do i386 and amd64 for me? If that's needed, I'm happy to setup my machine for that... | 11:22 |
| persia | doko, performous looks reasonably easy. I'll try my quick solution on a build (but am planning to sleep, so won't upload for some hours) | 11:22 |
| azeem | pitti: if you dropped libopensync0-dev, I advise to just pull opensync altogether | 11:22 |
| pitti | \sh: that's what I'm saying -- I don't think you should, unless you are working on an arm specific issue | 11:23 |
| azeem | we dropped libopensync1exp7 for squeeze, or never really considered it | 11:23 |
| pitti | azeem: well, "you" -- Debian did | 11:23 |
| pitti | I guess someone asked for an experimental sync | 11:23 |
| persia | \sh, `mk-sbuild --arch=armel maverick` :) (It's a bit buggy, and better to use real HW) | 11:23 |
| azeem | ok, I don't know what the reason was to remove opensync-0.22 | 11:24 |
| \sh | pitti: well, but I would like to know if the packages are building on all supported platforms, even if arm is nothing I'm involved in the first place | 11:24 |
| persia | --arch=powerpc is supposed to work, but it doens't very well :( | 11:24 |
| pitti | \sh: if only we had machines which would automatically build your upload on all supported architectures :) | 11:24 |
| \sh | persia: yeah...that's one of the problem...it's not reliable then real hw...but I'm one of the happy guys, who don't own any arm devices, and I wouldn't know for what I would need such devices ;) | 11:24 |
| persia | I like them for really small laptops :) | 11:25 |
| \sh | pitti: well, if ARM ARCH vendors are interested in support ubuntu development they could sponsor a build farm or at least the access to those devices for building purposes | 11:27 |
| pitti | \sh: we do have armel buildds | 11:28 |
| pitti | \sh: and you'll get a mail if it fails to build there | 11:28 |
| persia | \sh, Both Genesi and TI have currently open public board offerings for open source developers. | 11:28 |
| \sh | pitti: yes...but we could testbuild them before occupying needed resources on those buildds...I mean, before I upload anything, I have at least two automatic arch builds on my local sbuild server | 11:29 |
| \sh | persia: for what purpose? more desktop agnostic, or as well server agnostic? for server things I could even occupy resources in our DC to eventually provide cheap and energy efficient alternatives for having Tomcat apps servers or Mono app servers...;) | 11:33 |
| persia | I believe TI is looking for folks to do exciting and cool things with their just announced new board. Genesi seems to be looking for folks to generally improve a number of use cases so they can push follow-on products. | 11:34 |
| persia | But I'm just guessing. | 11:35 |
| Riddell | ogra: where can I download the ubuntu netbook ARM images for beta? | 11:36 |
| ogra | Riddell, http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/ | 11:37 |
| Riddell | ogra: oh aye, duh | 11:37 |
| geser | doko: I just saw on the recent FTBFS rebuild results that python3-stdlib-extensions 3.1.2-1 FTBFS and that you fixed it already in Debian. Should we try to get the fix into maverick? | 11:44 |
| doko | geser: on my radar, main is currently frozen | 11:45 |
| cjwatson | hallyn: I really don't know very much about cryptsetup, I'm afraid ... | 11:47 |
| cjwatson | mvo: oh good, I hadn't analysed the output of my run yet. what was the problem? | 11:49 |
| === amitk is now known as amitk-afk | ||
| cjwatson | azeem: I'd be a bit concerned about dropping opensync given that we've had people turning up to UDS before telling us how important opensync is | 11:54 |
| cjwatson | (and yes, I know they haven't contributed the developer effort to get it all in sync for maverick, but still ...) | 11:54 |
| === diwic is now known as diwic_afk | ||
| azeem | cjwatson: right | 12:12 |
| azeem | cjwatson: it's just a pretty sad situation | 12:12 |
| azeem | upstream development picked up again, but 0.3x isn't even encouraged to be *packaged* by upstream | 12:12 |
| azeem | let alone shipped | 12:12 |
| mvo | cjwatson: there is a little part in the script that copy the build-hosts keys, creates a backup of the trusted.gpg file and then restores it when the livefs build finished | 12:19 |
| mvo | cjwatson: I have a fix in bzr that I'm testing currently | 12:19 |
| cjwatson | mvo: I must be blind, I swear I looked for such a thing - but now you mention it I do see it | 12:21 |
| === amitk-afk is now known as amitk | ||
| cjwatson | mvo: your fix looks sensible to me | 12:23 |
| mvo | cjwatson: fix is in r403, double checking the diff is welcome of course | 12:23 |
| mvo | cjwatson: great, I inspect hte image now, if that is good I will upload | 12:23 |
| mvo | cjwatson: do I need to talk to IS to get it deployed or is that done automatically (i guess the later)? | 12:24 |
| cjwatson | the latter | 12:24 |
| mvo | thanks | 12:24 |
| cjwatson | BuildLiveCD changes require an RT ticket; livecd.sh is upgraded at the start of every build run | 12:24 |
| mvo | ok | 12:25 |
| === MacSlow is now known as MacSlow|lunch | ||
| === rgreening_ is now known as rgreening | ||
| === pedro__ is now known as pedro_ | ||
| mvo | could some native speaker have a quick look at http://paste.ubuntu.com/503196/ please? the "To see whats new in this release visit" is new text that is displayed right before a lucid->maverick upgrade. | 12:59 |
| === diwic_afk is now known as diwic | ||
| cjwatson | mvo: http://paste.ubuntu.com/503200/ | 13:01 |
| mvo | thanks cjwatson | 13:02 |
| elmo | 'desktop or server' seems a little outmoded | 13:02 |
| rgreening | doko: ping | 13:08 |
| === ivoks-afk is now known as ivoks | ||
| === MacSlow|lunch is now known as MacSlow | ||
| james_w | jibel: \o/ systematically refused is what I wanted :-) | 13:47 |
| james_w | jibel: it means I diagnosed the problem correctly at least. It's clearly not a fix though | 13:47 |
| james_w | jibel: thanks for testing | 13:47 |
| jibel | james_w, that's completely user unfriendly, that's cool then. | 13:49 |
| jibel | james_w, tell me when you want to test something else. | 13:49 |
| james_w | oh yeah, it's not a proposed fix, just a way of verifying I had the right idea of the problem | 13:50 |
| james_w | I'll look at a way of fixing it now | 13:50 |
| jibel | james_w, no problem, just ping me. | 13:50 |
| james_w | thanks | 13:51 |
| Riddell | akgraner: could you tell steveire what he has to do for his talk, he's not done one before | 14:04 |
| pitti | mvo: is there an apt branch for lucid-updates? | 14:13 |
| pitti | mvo: (I mean a real one derived from ~ubuntu-core-dev/apt/ubuntu) | 14:15 |
| mvo | pitti: not currently, why? | 14:16 |
| pitti | mvo: I'm about to merge our apt in the OEM common PPA with lucid-updates | 14:16 |
| pitti | mvo: so I'll just grab the diffs from Launchpad and apply them | 14:16 |
| mvo | pitti: aha, ok. that will be best | 14:16 |
| akgraner | Riddell, sure I emailed all the session leaders for today and I'll touch base with him as well him on IRC as well.... | 14:20 |
| === ivoks is now known as ivoks-afk | ||
| quadrispro | doko__, I've left a patch on #646824, please let me know | 14:46 |
| quadrispro | see you soon, bye! | 14:46 |
| pitti | Riddell: oh, maverick unapproved flushed? the RC images are good then? | 14:48 |
| Riddell | pitti: they got approved by their various teams, I don't know if what's quite what you were asking :) | 14:49 |
| doko__ | quadrispro: loos fine, will you upload? | 14:49 |
| pitti | Riddell: great to hear | 14:49 |
| Riddell | pitti: ubuntu announcement is just waiting on various americans to wake up | 14:51 |
| pitti | yippie | 14:51 |
| JontheEchidna | silly west coasters | 14:51 |
| cjwatson | mvo: should bug 645436 be reclosed given your livecd-rootfs upload? (though it does mention some typos) | 14:53 |
| ubottu | Launchpad bug 645436 in ubuntu-meta (Ubuntu Maverick) "source NEW ubuntu-extras-keyring and upload new ubuntu-meta" [High,Fix committed] https://launchpad.net/bugs/645436 | 14:53 |
| meh2 | hey guys.. is there a developemrnt for ubuntu to support touchscreen laptops? | 14:53 |
| === doko__ is now known as doko | ||
| mvo | cjwatson: let me have a look | 14:59 |
| mvo | cjwatson: I close it now, but fix the typos (they are harmless but confusing) | 15:00 |
| cjwatson | mvo: thanks | 15:02 |
| jcastro | can someone moderate my post to -devel from yesterday? (or it might have been the day before) | 15:07 |
| jcastro | also, it's been 5 years, maybe I can get whitelisted now? :) | 15:07 |
| paissad_ | guys, i'm prompted during my packaging by this | 15:12 |
| paissad_ | out-of-date-standards-version 3.8.4 (current is 3.9.1) | 15:12 |
| paissad_ | but "apt-cache policy debian-policy" shows me 3.8.4 at most ! | 15:12 |
| ScottK | paissad_: Please don't ask the same question on multiple channels. | 15:13 |
| paissad_ | not upgradable from apt-get or aptitude then | 15:13 |
| paissad_ | ScottK, oh sorry ^^ ... | 15:13 |
| cjwatson | jcastro: done and done | 15:19 |
| jcastro | thanks! | 15:19 |
| seb128 | jcastro, so nothing is stopping you from spamming us now? ;-) | 15:20 |
| highvoltage | cjwatson: could you approve my message to the ubuntu-devel list? | 15:22 |
| cjwatson | uh, I just did a moderation pass - when did you send it? | 15:22 |
| jcastro | seb128: don't worry, I will stay out of the default aps one. Since I know you already know what to do. :) | 15:23 |
| highvoltage | cjwatson: about 2 minutes ago | 15:23 |
| seb128 | jcastro, ;-) | 15:23 |
| highvoltage | (perhaps it's just slow to get there) | 15:23 |
| cjwatson | not in the moderation queue yet. be slightly more patient :-) | 15:23 |
| highvoltage | ok :) | 15:23 |
| === bjf[afk] is now known as bjf | ||
| === diwic is now known as diwic_afk | ||
| doko | siretart: ping | 15:42 |
| === dholbach_ is now known as dholbach | ||
| === ogra_ac_ is now known as ogra_ac | ||
| tkamppeter_ | mvo, I have tested printconf and it is not compatible with Ubuntu any more. It lost track with the development of CUPS. I suggest removing it from Ubuntu. | 16:00 |
| OdyX | tkamppeter_: we might want to discuss this with Chris in order to get it removed from Debian too… | 16:02 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | mvo, OdyX, printconf's upstream ChangeLog ends on 2003-05-27 so it is discontinued upstream. What did hold it so long in the distros. | 16:03 |
| mvo | tkamppeter: thanks | 16:04 |
| OdyX | tkamppeter: afaik, it was a project of Chris Lawrence, who happens to be DD, so… | 16:05 |
| mvo | tkamppeter: what about foomatic-db-gutenprint ? it depends on foomatic-db, can it also depend on foomatic-db-compressed-ppds? | 16:05 |
| mvo | tkamppeter: same for ebox-printers? | 16:05 |
| mvo | tkamppeter: those are the three that have no "foomatic-db-compressed-ppds|foomatic-db" in the dependencies | 16:05 |
| tkamppeter | mvo, the problem is the following: | 16:06 |
| mvo | tkamppeter: I wrote a request for removal for printconf | 16:07 |
| tkamppeter | foomatic-db and foomatic-db-gutenprint contain XML files in /usr/share/foomatic. This consumes a lot of space and it is slow to generate PPDs from the XMLs. | 16:07 |
| tkamppeter | CUPS never reads these XMLs and by default we use system-config-printer which talks only with CUPS via IPP. | 16:08 |
| tkamppeter | CUPS uses ready-made PPDs in /usr/share/ppd and PPD generators in /user/lib/cups/driver and /usr/share/cups/drv/. | 16:08 |
| OdyX | tkamppeter: Chris did an update to printconf /which is foomatic-gui/ in 2010 though. | 16:09 |
| === ivoks-afk is now known as ivoks | ||
| tkamppeter | Foomatic XMLs are accessible to CUPS via /usr/lib/cups/driver/foomatic, but see the disadvantages I mentioned above. Therefore I migrated the Foomatic XML data to the smaller and faster compressed PPD archives, which are also CUPS PPD generators. This makes obtaining the PPDs much faster. Doing this step I was assuming that the printer setup tools currently in use support this by polling the available PPDs from CUPS. | 16:11 |
| tkamppeter | mvo, OdyX ^^ | 16:12 |
| mvo | OdyX: oh ? hm, so its worth keeping it? | 16:15 |
| tkamppeter | mvo, OdyX, foomatic-gui also does not start without foomatic-db installed but it has no package dependency on foomatic-db. I will check whether it also works without foomatic-db by removing the foomatic-db check from it. | 16:15 |
| OdyX | mvo: for Debian, I don't figure myself asking for removal of a package maintained and developped by a DD: it's his call. | 16:15 |
| tkamppeter | OdyX, you could report a Debian bug suggesting the removal. | 16:17 |
| OdyX | you could too :p | 16:18 |
| mvo | tkamppeter: I have not much knowledge about those packages, I leave it to you to decide if they shoudl stay or go, but I can add quirks code to ensure that the get removed on upgrade to not block the 10.10 upgrade from 10.04 | 16:21 |
| mvo | tkamppeter: what about foomatic-db-gutenprint, can that grow a "foomatic-db-compressed-ppds|foomatic-db" dpeendency? | 16:21 |
| === ivoks is now known as ivoks-afk | ||
| tkamppeter | mvo, OdyX, foomatic-gui is better but still unusable. It finds the local printers with the URIs of current CUPS, but for network printers it falls into an infinite loop (-> bug) and for the PPD choice it only offers PPDs to be generated from the currently installed XML files, no ready-made PPDs and no PPD generators (it does not ask CUPS for available drivers/PPDs). | 16:28 |
| tkamppeter | mvo, so I ask you to make the update from Lucid to Maverick uninstall printconf and foomatic-gui and install system-config-printer if it is missing. | 16:29 |
| tkamppeter | foomatic-db-gutenprint needs foomatic-db, as it is an add-on to foomatic-db. Users of foomatic-db-compressed-ppds who want to use ijsgutenprint have to install ijsgutenprint-ppds instead of foomatic-db-gutenprint. | 16:31 |
| tkamppeter | mvo, for Ubuntu I recommend removing the foomatic-gui source package altogether, as in current Ubuntu it is totally unusable. | 16:33 |
| OdyX | tkamppeter: could you send an argumented bugreport to the Debian foomatic-gui package with high severity ? That'd be great to track that issue. | 16:35 |
| tkamppeter | OdyX, OK. | 16:36 |
| OdyX | nice. Thanks. | 16:37 |
| tkamppeter | mvo, which other packages require foomatic-db? ebox-printer and which was the other? | 16:37 |
| siretart | doko: hi | 16:38 |
| mvo | tkamppeter: those theree, ebox-print, printconf and foomatic-db-gutenprint | 16:39 |
| tkamppeter | mvo, bug 647460 updated. | 16:43 |
| ubottu | Launchpad bug 647460 in update-manager (Ubuntu) "10.04 -> 10.10: printconf is blocking the upgrade" [High,Triaged] https://launchpad.net/bugs/647460 | 16:43 |
| tkamppeter | foomatic-db-gutenprint really needs foomatic-db as I told, but we have ijsgutenprint-ppds to replace it. | 16:44 |
| tkamppeter | mvo ^^ | 16:45 |
| tkamppeter | mvo, ebox-print I do not know what it is good for and who is supposed to use it. I will have a look into it. | 16:45 |
| tkamppeter | mvo, I cannot find ebox-print or ebox-printer. What is the exact package name? | 16:51 |
| === bdrung_ is now known as bdrung | ||
| mvo | tkamppeter: its ebox-printers | 16:55 |
| tkamppeter | mvo, found it, it is ebox-printers, but I could not test it due to dependency problems. The system refuses to install all this ebox stuff. | 16:55 |
| mvo | tkamppeter: thanks, if you can figure out more let me know, in the meantime I add the handling to update-manager | 17:00 |
| tkamppeter | mvo, OK. | 17:01 |
| doko_ | siretart: how to make ffmpeg more verbose? | 17:03 |
| ricotz | mvo, i hope you are updating gnome-keyring to 2.32 to solve the annoying ssh-key-unlock bug which is fixed since 2.31.92 https://bugs.edge.launchpad.net/ubuntu/+source/gnome-keyring/+bug/631980 | 17:07 |
| ubottu | Launchpad bug 631980 in gnome-keyring (Ubuntu) "gnome-keyring doesn't unlock ssh key" [Low,Fix committed] | 17:07 |
| mvo | ricotz: that is probably more something for didrocks or seb128 | 17:07 |
| ricotz | mvo, ok, i just saw your upload | 17:08 |
| didrocks | ricotz: no we won't | 17:08 |
| didrocks | ricotz: it's quite late and we got some issues with it | 17:08 |
| mvo | ricotz: yeah, it was just a drive-by-upload :) | 17:08 |
| tkamppeter | mvo the ebox stuff is a server infrastructure, probably generally not working on desktop systems. ebox-printers is written in Perl and directly using the Perl module of foomatic-db-engine. I do not know whether it asks also CUPS for PPDs or whether it requires the Foomatic XML database. Basing printer support exclusively on Foomatic is a bug in nowaday's life. | 17:08 |
| mvo | ricotz: the real exports are didrocks and seb | 17:08 |
| ricotz | didrocks, could you aleast add this http://git.gnome.org/browse/gnome-keyring/commit/?id=d9ef94455d115d8fed29a3071b5b19ca632fb932 | 17:08 |
| didrocks | ricotz: yeah, this commit seems safe :) | 17:09 |
| ricotz | didrocks, this is the commit which is supposed to have fixed it | 17:09 |
| seb128 | ricotz, do you have an upstream or launchpad bug for it? | 17:09 |
| didrocks | ricotz: the gsettings transition was quite late in the process, hence the fact we don't update | 17:09 |
| ricotz | https://bugzilla.gnome.org/show_bug.cgi?id=627815#c1 | 17:09 |
| ubottu | Gnome bug 627815 in general "gnome-keyring ssh agent doesn't unlock ssh keys anymore" [Normal,Resolved: fixed] | 17:09 |
| seb128 | didrocks, I can do it | 17:09 |
| didrocks | seb128: thanks :) | 17:09 |
| ricotz | https://bugs.edge.launchpad.net/ubuntu/+source/gnome-keyring/+bug/631980 | 17:09 |
| seb128 | didrocks, you have quite some items on your todo already | 17:09 |
| ubottu | Launchpad bug 631980 in gnome-keyring (Ubuntu) "gnome-keyring doesn't unlock ssh key" [Low,Fix committed] | 17:09 |
| seb128 | ricotz, ok | 17:10 |
| didrocks | seb128: yeah, I keep seeing items appending :p | 17:10 |
| ricotz | seb128, thanks | 17:10 |
| seb128 | ricotz, you're welcome | 17:11 |
| mvo | is there someone with a dell mini9 who can tell me if sata is set to "compat" or "ahci" mode by default? | 17:12 |
| tkamppeter | mvo, bug 647460 updated. | 17:27 |
| ubottu | Launchpad bug 647460 in update-manager (Ubuntu) "foomatic-gui: Request for removal" [High,Triaged] https://launchpad.net/bugs/647460 | 17:27 |
| mvo | thanks tkamppeter | 17:27 |
| === ivoks-afk is now known as ivoks | ||
| === beuno is now known as beuno-lunch | ||
| siretart | in case doku pings me again. the answer is 'make V=1' | 17:55 |
| === al-maisan is now known as almaisan-away | ||
| * samiz is away: Away | 18:08 | |
| === doko_ is now known as doko | ||
| === beuno-lunch is now known as beuno | ||
| tkamppeter | mvo, I have reported Debian bug 598639 now. | 18:45 |
| ubottu | Debian bug 598639 in foomatic-gui "foomatic-gui/printconf: Not working in modern CUPS environments" [Serious,Open] http://bugs.debian.org/598639 | 18:45 |
| achiang | hm, i thought [[ expression ]] was legal posix shell | 18:45 |
| achiang | but i'm getting [[: not found when using #!/bin/sh | 18:46 |
| tkamppeter | OdyX, see Debian bug 598639. | 18:46 |
| ubottu | Debian bug 598639 in foomatic-gui "foomatic-gui/printconf: Not working in modern CUPS environments" [Serious,Open] http://bugs.debian.org/598639 | 18:46 |
| === ivoks is now known as ivoks-afk | ||
| james_w | jibel: new package in my PPA if you could test it (I still can't reproduce) | 19:12 |
| james_w | hopefully this one fixes it | 19:12 |
| mvo | thanks tkamppeter, I just uploaded the new update-manager with the workaround as well | 19:32 |
| === Claudinux_ is now known as Claudinux | ||
| jibel | james_w, I'm testing the new package | 20:24 |
| james_w | thanks | 20:27 |
| tkamppeter | mvo, does your workaround on update-manager also solve the foomatic-db-gutenprint problem, by replacing foomatic-db-gutenprint with ijfgutenprint-ppds? | 20:28 |
| jibel | james_w, \o/ I've tried many different ways to reproduce the bug and failed. That seems to be fixed! | 20:39 |
| jibel | james_w, any idea how I could test potential regressions ? | 20:39 |
| james_w | jibel: not really beyond using it | 20:39 |
| james_w | I'm not sure if we should try and get this in to final | 20:40 |
| jibel | james_w, I would be better to do an SRU just after the release | 20:41 |
| james_w | yeah | 20:41 |
| === jtechidna is now known as JontheEchidna | ||
| jibel | james_w, I'm the only tester and only 20 minutes that's not enough to guarantee against the risk of regression. | 20:42 |
| james_w | yeah, I meant more whether we should scramble for more testing now, or take the time and do an SRU | 20:43 |
| james_w | I'm fine with the latter, it's just that if it affects a lot of people then it will be a stain on the software-center experience | 20:44 |
| jibel | james_w, have you seen lot users complaining about this bug ? You should raise it to the release team. | 20:44 |
| james_w | a fair number, but not hundreds | 20:45 |
| james_w | plus it's always been in lucid | 20:45 |
| mvo | tkamppeter: thanks, I can add that too, its not there yet foomatic-db-gutenprint->ijfgutenprint-ppds? | 20:51 |
| tkamppeter | mvo, yes, that's it. | 20:53 |
| mvo | tkamppeter: I made a note and will add it tomorow | 20:53 |
| tkamppeter | mvo, only for ebox-printers I do not know what is best. The ebox series of packages seems to be a server environment, so it is not very probable that someone installs it together with ubuntu-desktop. And ubuntu-desktop initiates the migration from foomatic-db to foomatic-db-compressed-ppds. | 20:56 |
| === amitk is now known as amitk-afk | ||
| === amitk-afk is now known as amitk | ||
| === amitk is now known as amitk-afk | ||
| kaizoku | Hi, I'm looking to enable ttys on a installation livecd. Anyone know how I can go about this? | 22:18 |
| === yofel_ is now known as yofel | ||
| === ivoks-afk is now known as ivoks | ||
| === bjf is now known as bjf[afk] | ||
| SpamapS | can somebody explain to me how openssh-server can both Replace and Depend on openssh-client ? | 23:45 |
| ajmitch | SpamapS: versioned Replaces & Depends | 23:48 |
| ajmitch | the Replaces: version is << something quite old | 23:48 |
| soren | ajmitch: Yeah, 1:3.8.1p1-11 is timestamped October 2004 :) | 23:50 |
| soren | Even Debian has had a few releases out since then :) | 23:51 |
| ajmitch | soren: right, I was only checking launchpad, and even dapper had 4.2p1 :) | 23:52 |
| soren | ajmitch: warty was 1:3.8.1p1-11ubuntu3. | 23:55 |
| ajmitch | so this goes back to the pre-history of ubuntu :) | 23:55 |
| SpamapS | oh the apt-cache command didn't show the versions | 23:55 |
| SpamapS | show does though | 23:56 |
| soren | ajmitch: But sure, if someone has a woody box they want to upgrade directly to maverick.. | 23:57 |
| * soren coughs | 23:57 | |
| soren | Ah, no, even sarge, actually. | 23:57 |
| soren | But still, that's hardly relevant. | 23:57 |
| ajmitch | then they should be hung, drawn & quartered? | 23:58 |
| ajmitch | even a minimal chroot would hardly be able to upgrade | 23:58 |
| soren | They at the very least deserve the pain of the sshd_config man page moving to openssh-server and dpkg shouting about it. | 23:59 |
| * soren is happy he's very tired, otherwise he'd be attempting such an upgrade, just for giggles. | 23:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!