=== dendro-afk is now known as dendrobates
=== ogra_ac_ is now known as ogra_ac
Riddelldavidm: ok to release images for RC?00:38
ogra_acRiddell, what does the isotracker say (and better ask GrueMaster, he is testing atm)00:38
ogra_acRiddell, theoretically they should all be fine00:39
Riddellogra_ac: if I read it right it says there's a couple of serious bugs and no failures00:41
ogra_acRiddell, great00:42
ogra_acso we are not jobless after RC :)00:44
ogra_acRiddell, looking at the treacker they seem to all be known bugs ... fine to release00:47
ogra_acRiddell, netbook preinstalled for armel omap and omap4 ... netbook live for armel dove are the images we release00:48
ogra_ac... and with that statement i'm off to bed00:49
jjardonHello, is there any possiblity to ship pygobject 2.26 in maverick? They are the only supported python bindings upstream01:37
jjardonAlso, PyGTK apps are recommended to switch to PyGObject ASAP01:37
persiaYou mentioned this before.  You might want to file a bug.  IRC is notoriously bad at maintaining state.01:38
persiaAt this point, it would require significant coordination push, and be considered release-critical by a number of people.01:38
persiaIt'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
persiaIt 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
pooliehi, will someone please sponsor maxb's upload from https://bugs.launchpad.net/bugs/63693001:59
ubottuLaunchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged]01:59
ScottKpoolie: 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
poolieScottK: the whole bugfix update02:05
poolieie all of 2.2.102:06
poolieScottK: we have a microreleaseupdate exception02:06
persiapoolie, 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
maxbI can't02:10
maxboops, I just responded ot something hours ago in scrollback02:10
pooliepersia, scottk, ok so what can we actually do with this specific package?02:15
maxbFirst things first, we need an official ubuntu-release verdict on whether to go release pocket or SRU02:17
maxbAs informal IRC opinions have been inconclusive02:17
persiapoolie, 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
pooliehow could we get in touch with such a person?02:19
pooliehistorically just subscribing the team to the bug and commenting has not got much of a response02:19
persiamaxb, If you're seeking that, then yes, you want to have had a different request.02:19
maxbExactly - thus, the first thing being getting the release team's verdict on whether they want this in release or proposed pocket02:19
persiapoolie, It's supposed to work that way.  When it doesn't, you can ask here or in #ubuntu-release.02:20
poolieScottK: i see you're in ~ubuntu-release, what do you think?02:26
poolierunning the tests now02:35
ScottKpoolie: 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
ScottKpoolie: 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_wI'm pretty sure it's just in main03:53
ScottKThat would make it less scary from my POV since it gives us almost another week to deal with regressions.03:54
persiaIf fails to show in any of the manifest files I mirror (which is an incomplete set, but wide).03:54
ScottKOf 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
=== jamesh_ is now known as jamesh
poolieScottK: i ran the tests and posted the outcome; not sure if you saw that yet04:48
poolieoh i see04:50
poolieok, i'll work out what's up with that ssl error04:50
=== jam1 is now known as jam
=== bjf is now known as bjf[afk]
pooliejames_w: your bug 646979 logic seems plausible to me on a brief read through05:27
ubottuLaunchpad bug 646979 in bzr-builddeb "merge-package should maybe vary which branch it merges the combined upstream to" [Undecided,New] https://launchpad.net/bugs/64697905:27
pooliei stress only brief for the moment05:30
james_wyeah, 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
dholbachgood morning07:39
jibeldidrocks, could you have a look at bug 651325. it was during a test upgrade from a fresh wubi 10.04.1 to 10.1008:17
ubottuLaunchpad 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/65132508:17
didrocksjibel: oh, let me check, I have an idea why we can have that :)08:17
didrocksjibel: yeah, dpkg doesn't have dpkg-maintscript-helper in list, I get trapped :)08:18
didrocksjibel: I'll fix that then, thanks for the info :)08:19
jibeldidrocks, thank you08:20
mvodidrocks: I have a fix ready, its just a missing pre-depends on dpkg08:20
didrocksmvo: oh good, thanks :)08:21
mvodidrocks: commited, I can upload if nothing else is pedning08:21
didrocksmvo: 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
didrocksnot sure where to list that however08:23
persiadebian/README.source might be a handy innocuous place for that sort of thing.08:23
=== dendrobates is now known as dendro-afk
didrockspersia: for dpkg? do you think people using dpkg-maintscript-helper will look at dpkg README file? :)08:24
persiadidrocks, 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
didrocksyeah, that was my guess, I'll patch it for natty08:25
YokoZarCan 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
StevenKYokoZar: To maverick?08:28
YokoZarStevenK: Yeah08:28
StevenKYokoZar: 0.29.1-0ubuntu1 ?08:29
YokoZarStevenK: yup08:30
StevenKYokoZar: Right, cool. Rejected.08:30
twbDoes Ubuntu have something like cdn.debian.net, which resolves to a "nearby" mirror?08:32
twbI 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
persiatwb, 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
twbI guess the other way to do it is to just get everyone onto ipv6 and use anycast :-P08:42
persiaHeh, indeed.08:42
pittiGood morning08:42
pittiyofel: will do, thanks for the MP08:43
pittiScottK: I guess bzr is at least on the DVDs08:43
twbActually, while we're discussing it, what is the *CLI* equivalent of apt-spy in Ubuntu?08:45
twbI 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
persiatwb, 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
twbokey dokey08:46
twbFor my own means I usually know out-of-band, but it comes up on #ubuntu-server occasionally08:47
persiaProbably easy enough to toss one together.08:47
mvotwb: there is a "mirror" protocol in apt08:47
mvotwb: you can use "deb mirror://mirrors.ubuntu.com/mirrors.txt maverick main universe"08:48
twbOh neat08:48
persiaOh, cool!08:48
mvoits not perfect yet, that is why we have no done it by default (yet)08:48
mvobut it should work pretty well 99% of the time08:48
twbThere was also that guy working on a bittorrent apt method, but I don't think he got it production-ready08:49
mvotwb: yeah, apt-transport-debtorrent - we have it in the archive08:50
twbDo you happen to know what the Debian equivalent of mirrors.ubuntu.com/mirrors.txt is?  README.mirrors.txt has a different format08:50
mvotwb: where is README.mirrors.txt located?08:54
pooliehi pitti,08:55
twbI *think* that's the file apt-spy uses08:55
pittihey poolie08:55
pooliegiven our test results that there are no new test failures from the installed bzr, in bug 63693008:55
ubottuLaunchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged] https://launchpad.net/bugs/63693008:55
pooliewhat's next?08:55
twbmethod/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 useful08:56
mvotwb: aha, thanks. the mirror method in apt depends on a server that uses geoip so it will not be able to use this file08:56
persiaThe fastest server is often not the nearest one geographically, depending on network topology.08:57
twbpersia: I was impressed that it even listed my ISP's tertiary mirror, though08:57
twbIt wasn't the first one in the list, though08:57
twbI 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
twbHmm, same result when coming from an ISP-assigned IP.08:59
=== badipod_ is now known as badipod
pooliepitti: ?09:05
mvotwb: 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 people09:07
=== spike_ is now known as spikeWRK
mvotkamppeter_: 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
pittipoolie: as I said, it can be uploaded to maverick-proposed09:12
=== dendro-afk is now known as dendrobates
pooliemaxb: so i think now you should ask someone to sponsor your upload to maverick-09:23
persiaCommon 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
maxbpoolie: well, hmm. only if the decision has been finally taken to handle this as a SRU, not a late-breaking release pocket upload09:27
maxbI 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 mentioned09:27
pooliemaxb, i don't know if that's optimal but it's pretty good09:31
pooliei suspect everybody running this will get -updates09:31
poolieand it'd be nice to just get it resolved and do other things09:32
mvotkamppeter_: if you have time I would like to talk about #647460, what we can do about it09:41
persiamaxb, 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
maxbpersia: yes, I think we shall aim for SRU. The confusion has been that we've had different thoughts on the matter from pitti and ScottK09:53
pittia week ago we weren't frozen for RC yet, so back then my suggestion was to just upload it if it was ready09:55
persiamaxb, 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
poolieyeah, or take the answer you like best :)10:04
pittiit didn't really differ, though10:04
pittiit makes a difference whether you ask before or after a freeze :)10:05
persiapoolie, 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
mvocjwatson: 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
dokoI'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 it10:17
persiaI thought I requested that.10:21
dokopersia: being aware of the armel and powerpc build failures in experimental? :-/10:35
persiaFrom experimental?  I didn't request that.10:38
persia(and I can't find the bug either :/ )10:38
dokothere is none ...10:38
persiaThere was one.  NCommander, I, ogra, and seb128 all touched it, and Riddell closed it, unless I'm thinking of a different lash10:40
persiaBut that was for a sync from *unstable*10:40
seb128I don't even know what that source is I doubt I touched it10:41
* ogra neither10:42
persiaseb128, There was an associated issue with d-shlibs and you told NCommander to fix it with hinting, rather than a hardcoded patch.10:42
ograoh, that one10:42
persiaRight.  I requested the sync of (https://launchpad.net/ubuntu/maverick/+source/lash/ )10:43
persiadoko, Sorry for the confusion.10:43
dokopersia, and we ended up with 0.6rc2?10:44
persiaI don't know how that happened. 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
seb128doko, ask quadrispro10:45
seb128he did the upload it seems10:45
seb128he apprently synced it manually himself10:46
Laneylooks like a syncpackage upload10:46
dokoseb128: it's a sync ...10:46
seb128doko, it's a fake sync10:46
seb128ie one done manually10:46
Laneyoverride distro in changesfile, sign, upload10:47
seb128otherwise it would be an Ubuntu Installer upload10:47
dokoseb128: yes, from experimental, so there should be a bug report?10:47
Laneythat's not enforced10:47
Laneyany developer can just upload as normal10:47
seb128doko, no, it's an upload by somebody with upload rights10:47
dokoahh, that could be. but quadrispro is the debian maintainer too, and uploading something which is broken on three archs is ... unfriendly10:47
seb128doko, talk to him I guess, I don't know why he uploaded10:48
persiaIt's rather unfortunate, really.  Lots uses lash.10:48
dokoanyway, fixed10:49
ograi asked him to apply the same patch to d-shlibs we used in all former releases10:49
ograwhich back then fixed
=== bilalakhtar_ is now known as bilalakhtar
dokoseb128: still wondering why a fake sync is required for an .orig.tar.gz not yet in ubuntu10:58
Laneydoko: People do it because it means your upload happens immediately rather than waiting for an archive admin10:58
dokoLaney: fine, imnsho this maybe should be restricted11:01
seb128doko, 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 itself11:01
seb128doko, there is no way to restrict that, it's like restricting upload to somebody having upload rights11:01
dokoseb128: policy?11:02
seb128he could as well have taken the debian version changed the number to 0ubuntu1 or 1~ubuntu and uploaded11:02
LaneyI've tried to convince individuals that it's usually not required.11:02
Laneyhaving said that though, I have used such scripts myself11:02
Laneyfor example when running a transition with long dep chains11:02
seb128doko, the last time that was discussed on the list nobody objected strongly to people doing their sync themself11:02
persiaLaney, Most archive-admins will happily run a sequence of lists for those over a few hours, if given a prepared list.11:02
seb128ideally we would not need archive admin to do syncs11:03
seb128whoever has upload right should be able to sync11:03
pittiI do that all the time; I fix somethign, and then upload to Debian and Ubuntu at the same time11:03
seb128there is no reason to review syncs over uploads11:03
persiaWe 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
ajmitchseb128: that requires a bit more work on soyuz though11:03
pittipersia: what do you think sync-source.py does? :-)11:03
seb128but that would not have solved the issue doko has there11:03
persiaajmitch, Not that much: mostly currently blocked on running the changelog import job.11:03
dokoseb128, Laney: yes, but please not from experimental, and not, if you know as debian maintainer, that the package builds on everything non ix8611:03
ajmitchpitti: I've seen the code, it's evil :)11:03
pittiat some point we'll have native source syncing, like copy-packages.py11:04
seb128doko, you have an issue with the maintainer decision there not with the policy or workflow11:04
persiapitti, 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
Laneydoko: Really it's just an instance of general care when uploading. In this case the fact that it's an emulated sync is immaterial11:04
pittiwhen we have a complete and current Debian import11:04
pittipersia: oh, you are an archive admin now?11:04
seb128doko, we would have synced it the same way if it was an official sync request11:04
pittipersia: (sync-source.py is the launchpad script)11:04
persiapitti, 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
dokoseb128: without looking for build failures first? sorry that a thing at least I do check11:05
seb128doko, we can check debian builds etc for the hundred of sync request every week, we just trust the maintainer who do requests11:05
persiaOh, I'm thinking of something different then.11:05
pittipersia: ah, that's something else; but in essence it does teh same as the launchpad script: craft a .changes for an existing .dsc11:05
seb128doko, it's the job of whoever has upload rights and been asking for the sync or acking it11:05
persiaRight.  There's a better way to do it mostly ready on LP, but pending some job execution time.11:05
seb128doko, and not archive admin doesn't have the time to do the submitter work and check everything for hundred of syncs11:06
persiaMaybe sometime during natty, if we're lucky.11:06
Laneypersia: 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
pittiFTR, archive admins can't check Debian FTBFS when doing sync processing either11:06
dokono, but it should be policy for the uploader11:06
persiaAnd they oughtn't be expected to.  archive-admins ought perform the syncs nearly blindly, if it has the right ACK.11:06
Laneyyou have to assume that the uploader knows what they are doing11:06
pittidoko: I agree11:06
seb128doko, right11:06
persiadoko, Yes.  Complain to quadrispro11:06
pittii. e. on the uploader's or sync requestor's side11:06
Laneyanyway, maybe a mail to the uploader CCed to some ML would work here11:06
seb128as said before the issue there is the maintainer, no how it was synced11:07
=== dendrobates is now known as dendro-afk
ajmitchnow if it was fine in debian & only failed to build on those archs in ubuntu, that's harder to catch for a maintainer11:08
bdrung_yes, the uploader has to make sure that the package builds11:08
pittipersia: 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
ajmitchbdrung_: right, but it's hard to test on hardware we don't have unless it's uploaded to PPAs11:09
LaneyIt's easy to catch, because you get a mail for the FTBFS.11:09
bdrung_ajmitch: it needs to build at least on your architecture11:10
persiapitti, 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
Laneyfixing with a subsequent upload isn't a problem11:10
Laneyignoring porting problems is11:10
quadrisproehy, I'm here, hi all. Sorry for the {delay,mistake}, I need just some minutes and I'm working on the patch11:10
pittipersia: hm; I just build on amd64; I don't think that a lot of people test-build on more than one arch11:10
persiaLaney, Ideally, I'd prefer that it wasn't like that, just because sometimes it interferes with images at milestone times.11:10
pittiand frankly, I think they shouldn't11:11
persiaWhy not?11:11
pittisudden arch specific FTBFS don't happen often enough to warrant slowing down every developer to test build on arm11:11
dokoquadrispro: it's now fixed11:11
pittiyou'd kill a lot of productivity for a very unlikely cause11:11
pittiand if it FTBFSes on the arm buildds, you'll get a mail and can still deal with it11:11
persiapitti, most packages don't take *that* long on armel, but yeah, until there's lots more fast HW...11:11
quadrisprooh, I get there late11:12
pittipersia: well, but few people have an armel box at home :)11:12
dokoyes, three month11:12
persiapitti, Yeah, well, ones capable of running what Ubuntu appears to have stabilized upon have only been on the market ~1 year.11:12
pittipersia: 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/power11:13
dokopitti: in this case: https://buildd.debian.org/status/package.php?p=lash&suite=experimental11:13
* persia needs to clean up and publish some scripts.11:13
pittidoko: oh, I wasn't arguing against checking the Debian buildds before requesting/doing a sync11:13
pittidoko: just that I don't want people to test-build every upload on three arches11:14
persiapitti, I think everyone should test-build on every arch *as long as it doesn't slow them down*.11:14
persiaI agree that waiting around for builds to finish is a waste of time.11:14
pittipersia: but it will slow you down..11:15
pittipersia: I don't think our buildds are a bottleneck enough to consider the odd arch specific FTBFS as too much of a resource waste11:15
pittideveloper time >> buildd time11:15
quadrisprothe ftbfs mail was put in spam by gmail... I'm very very sorry of that11:16
quadrispro25 september11:16
pittipersia: 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
persiaMaybe 10.11:16
pittithat's about 9 more than I know, so I'm honestly surprised11:16
pittipersia: well, let's just agree to disagree then11:16
dokopitti: but it adds work load for people then having to clear up things11:17
persiaI 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
pittidoko: no, why?11:17
dokopitti: http://people.canonical.com/~ubuntu-archive/NBS/11:17
pittidoko: if I upload a new package which suddenly FTBFSes on armel because of, say, a toolchain change, I get notified and can fix it afterwards11:17
pittihow does that slow down anyone else?11:17
dokoso the soname upload have to be done again11:18
pittibut 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 all11:18
pittidoko: soname upload?11:18
persiapitti, 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
pittipersia: presumably11:19
dokoliblash soname change11:19
pittipersia: but I'm specifically not talking about trying to fix an existing FTBFS11:19
persiaBecause I wish things worked the way you describe, but sympathise with doko's experience.11:19
pittiI'm not arguing about the lash example here11:19
pittiI agree that one should at least check Debian buildd status before requesting a sync11:20
dokobut while I have all your attention ...11:20
pittiI'm just aguing against your "every dev shoudl test-buid every upload on every arch"11:20
persiadoko, ?11:20
doko   ... there are still three powerpc build failures we should care about: performous-tools, mrpt and odin11:20
dokoand: http://people.canonical.com/~ubuntu-archive/NBS/libopensync0-dev11:21
azeemwhat's with libopensync0-dev?11:21
pittiit's NBS11:22
dokoazeem: not anymore in the archive11:22
pittiazeem: the reverse dependencies need to be rebuilt against libopensync1exp711:22
azeemgood luck11:22
pitticjwatson mentioned that these are nontrivial, i. e. require sourceful changes11:22
\shpitti: 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
persiadoko, 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
azeempitti: if you dropped libopensync0-dev, I advise to just pull opensync altogether11:22
pitti\sh: that's what I'm saying -- I don't think you should, unless you are working on an arm specific issue11:23
azeemwe dropped libopensync1exp7 for squeeze, or never really considered it11:23
pittiazeem: well, "you" -- Debian did11:23
pittiI guess someone asked for an experimental sync11:23
persia\sh, `mk-sbuild --arch=armel maverick` :)  (It's a bit buggy, and better to use real HW)11:23
azeemok, I don't know what the reason was to remove opensync-0.2211:24
\shpitti: 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 place11: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
\shpersia: 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
persiaI like them for really small laptops :)11:25
\shpitti: 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 purposes11:27
pitti\sh: we do have armel buildds11:28
pitti\sh: and you'll get a mail if it fails to build there11:28
persia\sh, Both Genesi and TI have currently open public board offerings for open source developers.11:28
\shpitti: 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 server11:29
\shpersia: 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
persiaI 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
persiaBut I'm just guessing.11:35
Riddellogra: where can I download the ubuntu netbook ARM images for beta?11:36
ograRiddell, http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/11:37
Riddellogra: oh aye, duh11:37
geserdoko: 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
dokogeser: on my radar, main is currently frozen11:45
cjwatsonhallyn: I really don't know very much about cryptsetup, I'm afraid ...11:47
cjwatsonmvo: 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
cjwatsonazeem: 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 is11: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
azeemcjwatson: right12:12
azeemcjwatson: it's just a pretty sad situation12:12
azeemupstream development picked up again, but 0.3x isn't even encouraged to be *packaged* by upstream12:12
azeemlet alone shipped12:12
mvocjwatson: 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 finished12:19
mvocjwatson: I have a fix in bzr that I'm testing currently12:19
cjwatsonmvo: I must be blind, I swear I looked for such a thing - but now you mention it I do see it12:21
=== amitk-afk is now known as amitk
cjwatsonmvo: your fix looks sensible to me12:23
mvocjwatson: fix is in r403, double checking  the diff is welcome of course12:23
mvocjwatson: great, I inspect hte image now, if that is good I will upload12:23
mvocjwatson: do I need to talk to IS to get it deployed or is that done automatically (i guess the later)?12:24
cjwatsonthe latter12:24
cjwatsonBuildLiveCD changes require an RT ticket; livecd.sh is upgraded at the start of every build run12:24
=== MacSlow is now known as MacSlow|lunch
=== rgreening_ is now known as rgreening
=== pedro__ is now known as pedro_
mvocould 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
cjwatsonmvo: http://paste.ubuntu.com/503200/13:01
mvothanks cjwatson13:02
elmo'desktop or server' seems a little outmoded13:02
rgreeningdoko: ping13:08
=== ivoks-afk is now known as ivoks
=== MacSlow|lunch is now known as MacSlow
james_wjibel: \o/ systematically refused is what I wanted :-)13:47
james_wjibel: it means I diagnosed the problem correctly at least. It's clearly not a fix though13:47
james_wjibel: thanks for testing13:47
jibeljames_w, that's completely user unfriendly, that's cool then.13:49
jibeljames_w, tell me when you want to test something else.13:49
james_woh yeah, it's not a proposed fix, just a way of verifying I had the right idea of the problem13:50
james_wI'll look at a way of fixing it now13:50
jibeljames_w, no problem, just ping me.13:50
Riddellakgraner: could you tell steveire what he has to do for his talk, he's not done one before14:04
pittimvo: is there an apt branch for lucid-updates?14:13
pittimvo: (I mean a real one derived from ~ubuntu-core-dev/apt/ubuntu)14:15
mvopitti: not currently, why?14:16
pittimvo: I'm about to merge our apt in the OEM common PPA with lucid-updates14:16
pittimvo: so I'll just grab the diffs from Launchpad and apply them14:16
mvopitti: aha, ok. that will be best14:16
akgranerRiddell, 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
quadrisprodoko__, I've left a patch on #646824, please let me know14:46
quadrisprosee you soon, bye!14:46
pittiRiddell: oh, maverick unapproved flushed? the RC images are good then?14:48
Riddellpitti: 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
pittiRiddell: great to hear14:49
Riddellpitti: ubuntu announcement is just waiting on various americans to wake up14:51
JontheEchidnasilly west coasters14:51
cjwatsonmvo: should bug 645436 be reclosed given your livecd-rootfs upload?  (though it does mention some typos)14:53
ubottuLaunchpad bug 645436 in ubuntu-meta (Ubuntu Maverick) "source NEW ubuntu-extras-keyring and upload new ubuntu-meta" [High,Fix committed] https://launchpad.net/bugs/64543614:53
meh2hey guys.. is there a developemrnt for ubuntu to support touchscreen laptops?14:53
=== doko__ is now known as doko
mvocjwatson: let me have a look14:59
mvocjwatson: I close it now, but fix the typos (they are harmless but confusing)15:00
cjwatsonmvo: thanks15:02
jcastrocan someone moderate my post to -devel from yesterday? (or it might have been the day before)15:07
jcastroalso, it's been 5 years, maybe I can get whitelisted now? :)15:07
paissad_guys, i'm prompted during my packaging by this15: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
ScottKpaissad_: Please don't ask the same question on multiple channels.15:13
paissad_not upgradable from apt-get or aptitude then15:13
paissad_ScottK, oh sorry ^^ ...15:13
cjwatsonjcastro: done and done15:19
seb128jcastro, so nothing is stopping you from spamming us now? ;-)15:20
highvoltagecjwatson: could you approve my message to the ubuntu-devel list?15:22
cjwatsonuh, I just did a moderation pass - when did you send it?15:22
jcastroseb128: don't worry, I will stay out of the default aps one. Since I know you already know what to do. :)15:23
highvoltagecjwatson: about 2 minutes ago15:23
seb128jcastro, ;-)15:23
highvoltage(perhaps it's just slow to get there)15:23
cjwatsonnot in the moderation queue yet.  be slightly more patient :-)15:23
highvoltageok :)15:23
=== bjf[afk] is now known as bjf
=== diwic is now known as diwic_afk
dokosiretart: ping15: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
OdyXtkamppeter_: 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
tkamppetermvo, 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
mvotkamppeter: thanks16:04
OdyXtkamppeter: afaik, it was a project of Chris Lawrence, who happens to be DD, so…16:05
mvotkamppeter: what about foomatic-db-gutenprint ? it depends on foomatic-db, can it also depend on foomatic-db-compressed-ppds?16:05
mvotkamppeter: same for ebox-printers?16:05
mvotkamppeter: those are the three that have no "foomatic-db-compressed-ppds|foomatic-db" in the dependencies16:05
tkamppetermvo, the problem is the following:16:06
mvotkamppeter: I wrote a request for removal for printconf16:07
tkamppeterfoomatic-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
tkamppeterCUPS never reads these XMLs and by default we use system-config-printer which talks only with CUPS via IPP.16:08
tkamppeterCUPS uses ready-made PPDs in /usr/share/ppd and PPD generators in /user/lib/cups/driver and /usr/share/cups/drv/.16:08
OdyXtkamppeter: Chris did an update to printconf /which is foomatic-gui/ in 2010 though.16:09
=== ivoks-afk is now known as ivoks
tkamppeterFoomatic 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
tkamppetermvo, OdyX ^^16:12
mvoOdyX: oh ? hm, so its worth keeping it?16:15
tkamppetermvo, 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
OdyXmvo: 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
tkamppeterOdyX, you could report a Debian bug suggesting the removal.16:17
OdyXyou could too :p16:18
mvotkamppeter: 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.0416:21
mvotkamppeter: 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
tkamppetermvo, 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
tkamppetermvo, 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
tkamppeterfoomatic-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
tkamppetermvo, for Ubuntu I recommend removing the foomatic-gui source package altogether, as in current Ubuntu it is totally unusable.16:33
OdyXtkamppeter: 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
tkamppeterOdyX, OK.16:36
OdyXnice. Thanks.16:37
tkamppetermvo, which other packages require foomatic-db? ebox-printer and which was the other?16:37
siretartdoko: hi16:38
mvotkamppeter: those theree, ebox-print, printconf and foomatic-db-gutenprint16:39
tkamppetermvo, bug 647460 updated.16:43
ubottuLaunchpad bug 647460 in update-manager (Ubuntu) "10.04 -> 10.10: printconf is blocking the upgrade" [High,Triaged] https://launchpad.net/bugs/64746016:43
tkamppeterfoomatic-db-gutenprint really needs foomatic-db as I told, but we have ijsgutenprint-ppds to replace it.16:44
tkamppetermvo ^^16:45
tkamppetermvo, 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
tkamppetermvo, I cannot find ebox-print or ebox-printer. What is the exact package name?16:51
=== bdrung_ is now known as bdrung
mvotkamppeter: its ebox-printers16:55
tkamppetermvo, 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
mvotkamppeter: thanks, if you can figure out more let me know, in the meantime I add the handling to update-manager17:00
tkamppetermvo, OK.17:01
doko_siretart: how to make ffmpeg more verbose?17:03
ricotzmvo, 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/63198017:07
ubottuLaunchpad bug 631980 in gnome-keyring (Ubuntu) "gnome-keyring doesn't unlock ssh key" [Low,Fix committed]17:07
mvoricotz: that is probably more something for didrocks or seb12817:07
ricotzmvo, ok, i just saw your upload17:08
didrocksricotz: no we won't17:08
didrocksricotz: it's quite late and we got some issues with it17:08
mvoricotz: yeah, it was just a drive-by-upload :)17:08
tkamppetermvo 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
mvoricotz: the real exports are didrocks and seb17:08
ricotzdidrocks, could you aleast add this http://git.gnome.org/browse/gnome-keyring/commit/?id=d9ef94455d115d8fed29a3071b5b19ca632fb93217:08
didrocksricotz: yeah, this commit seems safe :)17:09
ricotzdidrocks, this is the commit which is supposed to have fixed it17:09
seb128ricotz, do you have an upstream or launchpad bug for it?17:09
didrocksricotz: the gsettings transition was quite late in the process, hence the fact we don't update17:09
ubottuGnome bug 627815 in general "gnome-keyring ssh agent doesn't unlock ssh keys anymore" [Normal,Resolved: fixed]17:09
seb128didrocks, I can do it17:09
didrocksseb128: thanks :)17:09
seb128didrocks, you have quite some items on your todo already17:09
ubottuLaunchpad bug 631980 in gnome-keyring (Ubuntu) "gnome-keyring doesn't unlock ssh key" [Low,Fix committed]17:09
seb128ricotz, ok17:10
didrocksseb128: yeah, I keep seeing items appending :p17:10
ricotzseb128, thanks17:10
seb128ricotz, you're welcome17:11
mvois there someone with a dell mini9 who can tell me if sata is set to "compat" or "ahci" mode by default?17:12
tkamppetermvo, bug 647460 updated.17:27
ubottuLaunchpad bug 647460 in update-manager (Ubuntu) "foomatic-gui: Request for removal" [High,Triaged] https://launchpad.net/bugs/64746017:27
mvothanks tkamppeter17:27
=== ivoks-afk is now known as ivoks
=== beuno is now known as beuno-lunch
siretartin case doku pings me again. the answer is 'make V=1'17:55
=== al-maisan is now known as almaisan-away
* samiz is away: Away18:08
=== doko_ is now known as doko
=== beuno-lunch is now known as beuno
tkamppetermvo, I have reported Debian bug 598639 now.18:45
ubottuDebian bug 598639 in foomatic-gui "foomatic-gui/printconf: Not working in modern CUPS environments" [Serious,Open] http://bugs.debian.org/59863918:45
achianghm, i thought [[ expression ]] was legal posix shell18:45
achiangbut i'm getting [[: not found when using #!/bin/sh18:46
tkamppeterOdyX, see Debian bug 598639.18:46
ubottuDebian bug 598639 in foomatic-gui "foomatic-gui/printconf: Not working in modern CUPS environments" [Serious,Open] http://bugs.debian.org/59863918:46
=== ivoks is now known as ivoks-afk
james_wjibel: new package in my PPA if you could test it (I still can't reproduce)19:12
james_whopefully this one fixes it19:12
mvothanks tkamppeter, I just uploaded the new update-manager with the workaround as well19:32
=== Claudinux_ is now known as Claudinux
jibeljames_w, I'm testing the new package20:24
tkamppetermvo, does your workaround on update-manager also solve the foomatic-db-gutenprint problem, by replacing foomatic-db-gutenprint with ijfgutenprint-ppds?20:28
jibeljames_w, \o/ I've tried many different ways to reproduce the bug and failed. That seems to be fixed!20:39
jibeljames_w, any idea how I could test potential regressions ?20:39
james_wjibel: not really beyond using it20:39
james_wI'm not sure if we should try and get this in to final20:40
jibeljames_w, I would be better to do an SRU just after the release20:41
=== jtechidna is now known as JontheEchidna
jibeljames_w, I'm the only tester and only 20 minutes that's not enough to guarantee against the risk of regression.20:42
james_wyeah, I meant more whether we should scramble for more testing now, or take the time and do an SRU20:43
james_wI'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 experience20:44
jibeljames_w, have you seen lot users complaining about this bug ? You should raise it to the release team.20:44
james_wa fair number, but not hundreds20:45
james_wplus it's always been in lucid20:45
mvotkamppeter: thanks, I can add that too, its not there yet foomatic-db-gutenprint->ijfgutenprint-ppds?20:51
tkamppetermvo, yes, that's it.20:53
mvotkamppeter: I made a note and will add it tomorow20:53
tkamppetermvo, 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
kaizokuHi, 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]
SpamapScan somebody explain to me how openssh-server can both Replace and Depend on openssh-client ?23:45
ajmitchSpamapS: versioned Replaces & Depends23:48
ajmitchthe Replaces: version is << something quite old23:48
sorenajmitch: Yeah, 1:3.8.1p1-11 is timestamped October 2004 :)23:50
sorenEven Debian has had a few releases out since then :)23:51
ajmitchsoren: right, I was only checking launchpad, and even dapper had 4.2p1 :)23:52
sorenajmitch: warty was 1:3.8.1p1-11ubuntu3.23:55
ajmitchso this goes back to the pre-history of ubuntu :)23:55
SpamapSoh the apt-cache command didn't show the versions23:55
SpamapSshow does though23:56
sorenajmitch: But sure, if someone has a woody box they want to upgrade directly to maverick..23:57
* soren coughs23:57
sorenAh, no, even sarge, actually.23:57
sorenBut still, that's hardly relevant.23:57
ajmitchthen they should be hung, drawn & quartered?23:58
ajmitcheven a minimal chroot would hardly be able to upgrade23:58
sorenThey 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!