infinityapw: Your kernel build's been rescued and should be happy soon.00:19
infinityScottK: Ditto with kdevelop.00:19
ubottuLaunchpad bug 952694 in bluez (Ubuntu) "Toggling Bluetooth off also Disables Wifi Networking (Wifi Hardware Switched Off)" [Undecided,New]03:05
ScottKinfinity: Thanks.03:33
pittiGood morning05:55
jalcineHeh, it's very early over here :) almost 2 AM.05:57
pittidupondje: split needs an FFE bug, there we can review debdiffs etc.05:58
pittidupondje: if the -bin package doesn't change the boot process (that's the point of it), and it has proper breaks:/replaces, it's safe05:58
pittiapw: do you know why these kernel modules on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt want to go to universe? apparently they are not covered by linux-meta?06:03
pittiapw: it'd be a _lot_ easier to have all binaries in main06:04
pittimixed main/universe is a real dealbreaker for our current kernel SRU process, as PPAs don't have components06:04
pittigeser: done06:06
=== jalcine is now known as webjadmin_
vibhavHow Do I download a git patch?06:14
pittivibhav: github doesn't seem to support that directly; probably easiest to ctrl+mouse-mark the patch and paste it into an editor06:19
vibhavthanks pitti06:20
vibhavpitti: Is this fine then? http://paste.ubuntu.com/879972/06:27
pittivibhav: you need to remove the blank lines, but sure :)06:27
vibhavDo I need to remove the identation too?06:28
vibhavIs this alright now? http://paste.ubuntu.com/879974/06:30
vibhavwebjadmin_: Good night06:31
vibhavpitti :Is this alright now? http://paste.ubuntu.com/879974/06:34
pittijust try, patch will complain if it isn't :)06:35
pittivibhav: sorry, actually the initial indentation was correct06:35
vibhavThe earlier pastebin was right?06:36
pittiyes, except for the empty lines06:37
pittivibhav: it needs to look like the web veiw06:37
vibhavpatch: **** Only garbage was found in the patch input.06:40
vibhavIt aint working06:47
pittivibhav: probably easiest to just apply the changes manually; its' just a few changed lines after all06:48
vibhavpitti: I dont know how to do that :(06:50
=== jmp_ is now known as _jmp_
dholbachgood morning07:54
=== smb` is now known as smb
apwpitti, universe/main> erm, i presume they are threatening to move as they are LBM and not supported?  what do you mean not coverered by linux-meta ?08:28
pittiapw: shouldn't there be some metapackage to depend on the ABI specific binaries?08:38
apwpitti, there cirtainly should be in all cases, though that report looks to be showing one08:39
pittiapw: oh, hang on -- there are the corresponding linux-meta binaries08:40
pittiapw: I suppose we should seed the linux-meta ones08:40
apwpitti, isn't the second line there all the meta packages for the ones demoting in the first08:40
=== bludude is now known as soaringsky
apwpitti, ahh of course, the meta package has the release name in it08:40
apwpitti, so it'll need changing each release, i expect you have -oneiric- in oneiric08:41
pittisupported-kernel-common: * /^linux-(backports-modules-(headers|net)-oneiric-|headers-)?(386|cell|dove|ec2|generic|linaro-omap|linaro-vexpress|omap|omap4|armadaxp|powerpc|ps3|server|virtual).*/08:41
pittithat's it08:41
* pitti fixes08:41
pittiit doesn't have -cw, but I'll add that as well08:42
apwpitti, thanks ... i'll poke leann to add 'get the seeds fixed' to the schedule when LBM comes alive in Q08:43
pittiapw: I think I got it, will check c-m in an hour08:45
apwpitti, thanks a lot08:45
vibhavshouldn't the FTBFS part in the topic be in #ubuntu-motu?08:49
apwis anyone else seeing delayes during boot; with a new plymouth message "waiting for network configuration" (approximatly)08:54
pittiapw: other than bug 949891?08:57
ubottuLaunchpad bug 949891 in apparmor (Ubuntu Precise) "apparmor caching is not working which has severely regressed boot time" [High,Fix released] https://launchpad.net/bugs/94989108:57
dupondjepitti: for cryptsetup, you prefer an extra package that just provides the bins (and conflicts cryptsetup) or a real splitted up package, where cryptsetup requires cryptsetup-bin ? :)08:58
pittidupondje: the latter08:58
pitticryptsetup-bin would then be in the default install08:58
pittiand cryptsetup would be installed by d-i if you configure encrypted disk08:58
pitti(just as right now)08:58
dupondjewill check :)08:59
pittia conflict is awkward and unnecessary08:59
apwpitti, i updated just 10m ago, so i'd expect to have that fix no?08:59
pittiapw: ah, then you should08:59
pittiapw: kernel gone from http://people.canonical.com/~ubuntu-archive/component-mismatches.txt08:59
dupondjemost of ubuntu delta is also in debian now :) (became co-maintainer of it in debian)08:59
pittiah, nice09:00
apwpitti, am seeing this on two machines, and was seeing it on sunday on one of them on a physically dysperate network09:00
pittidupondje: I was just going to say, this should be coordinated with Debian, so that we don't carry the package split as a delta09:00
apwpitti, does anyone know what the message actually referes to, i've cirtainly never seen it on my network before09:00
pittiapw: not off-hand, no09:00
apwpitti, ok i'll update a test box and confirm it there (in this location) and file something09:01
dupondjepitti: http://artemis.dupie.be/dupondje/cryptsetup.patch what you think? :)09:06
pittidupondje: needs a Breaks:/Replaces: cryptsetup (<< version_of_the_split)09:09
pittidupondje: also, wrt. package description, I think it is "command line", not "commandline"09:10
pittidupondje: I can't verify debian/rules just by looking, checking the binary debdiffs would be easier for taht09:10
pittidupondje: but it looks fine09:11
dupondjewas not final indeed :) will check to create a debdiff today09:11
dupondjealso i'll add another patch that fixes a critical bug (and is only 1 line ^^)09:12
dupondjepitti: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/34336309:53
ubottuLaunchpad bug 343363 in udisks (Ubuntu) "gnome functional depends on cryptsetup, but not in package management " [Low,Triaged]09:53
dupondjeuploaded debdiff09:53
pittidupondje: thanks!10:38
pittidupondje: will you also push that to Debian?10:38
kikohey there10:47
kikoanybody seeing weird font issues in the precise terminal?10:47
ogra_kiko, only in my panel10:51
ogra_terminals look fine here10:51
pittikiko: WFM10:51
pittikiko: be sure that anything that breaks gnome terminals will raise a rebellion here :)10:52
pittilike bug 94861210:52
ubottuLaunchpad bug 948612 in vte3 (Ubuntu Precise) "gnome-terminal does not scroll with mousewheel" [Medium,Fix released] https://launchpad.net/bugs/94861210:52
Claudinuxhi all, if a menu isn't shwon in the application menu but is visible only if i start a session in gnome-shell, the bug should be opened for unity or for the application?11:00
geserogra_: like in bug #947059 or different issue?11:11
ubottuLaunchpad bug 947059 in unity-2d (Ubuntu) "Panel fonts are green and blurry" [Undecided,Confirmed] https://launchpad.net/bugs/94705911:11
ogra_geser, same thing11:11
ogra_and funny colored notifications11:11
geserare you using the light theme or the dark one? as I see this only with the light theme11:12
ogra_light here11:15
pittiI'm using the bright theme (Radiance) and it's fine11:15
ogra_havent cross checked with dark11:15
geserpitti: unity or unity-2d?11:16
kikopitti, can you help me debug? this is kinda driving me crazy11:27
kikopitti, what sort of settings or dotfiles might come into play?11:28
pittikiko: probably better if the unity-2d guys have a look, I wouldn't know where to begin :(11:28
kikopitti, for terminal?11:29
geserkiko: can you upload a screenshot of your terminal somewhere?11:30
kikogeser, pitti: http://www.async.com.br/~kiko/term.png11:30
kikogeser, that's a mutt threaded view11:30
geserand it worked before?11:31
kikogeser, definitely worked in natty11:31
geserlooks interesting11:33
kikogeser, it happens with rxvt and xterm too11:34
kikoit doesn't happen with other apps that I can see: çáé11:34
kikoso it's something to do with fonts. but what?11:35
kikolemme try and move .font* out of the way11:35
geserdo other programs, that use line drawing /boxes work?11:35
kikogeser, in the terminal nothing works11:36
kikoeven typing directly into the bash prompt11:36
kikobut say gvim works11:36
kikoit's really only to do with terminals11:37
kikowhat's special about rxvt, xterm and terminal11:38
kikothat makes it different from, say xditview or qtconfig-qt4 or chromium11:39
geserdoes it work in the real console (outside X)?11:40
* kiko installs terminator to test11:42
kikogood news is that apart from this precise is killer!11:42
kikoon my nfs-root setup11:42
kikoweirdly much faster in fact11:43
kikogeser, also busted in terminator11:44
kikopitti, by looking at my screenshot anything you suggest I could investigate?11:44
geserit looks like mutt (and other apps emit utf-8 codes) but the terminal doesn't handle it11:46
geserbut I don't have an idea how to verify it11:47
dupondjepitti: will be commited into debian, but maby there will be first a release with some bugfixes in debian, and then the split release.11:49
dupondjeI take care we have no delta for Precise+1 :)11:51
=== MacSlow is now known as MacSlow|lunch
kikoI think I know what's wrong12:10
kikogeser, locale lists everything as POSIX12:10
kikofound the issue12:12
kikoexport LANG=en_US.UTF812:13
kikohow was this being set before I wonder12:13
=== _salem is now known as salem_
ogra_kiko, /etc/default/locale12:15
jalcinekiko: perhaps via the environment?12:15
jalcineor in a .bashrc file?12:15
pittikiko: err, a locale setting causes the screen corruption?12:33
pittikiko: oh, the mutt one; yes, that's likely12:34
pittidupondje: that sounds fine12:34
dupondjepitti: you'll sponsor it? I subscribed ubuntu-release.12:42
pittidupondje: yes, can do12:42
scott-workcjwatson: good morning!  i have added my casper.log file to bug# 92381013:00
scott-workbug #92381013:00
ubottuLaunchpad bug 923810 in casper (Ubuntu) "preseeding passwd/user-default-groups is ineffective" [Medium,Fix released] https://launchpad.net/bugs/92381013:00
scott-worki was also wondering if anyone can point me in a direction to look or talk about unreadable ubiquity installer text ala bug #952462?13:01
ubottuLaunchpad bug 952462 in Ubuntu Studio "Ubuntustudio 12.04 installer has unreadable text" [Undecided,Confirmed] https://launchpad.net/bugs/95246213:01
scott-workinterestingly, this only affects the installer when choosen from the first menu, if the user lets the live FS come up and then chooses to install either from the applications menu or the "install" icon then the text appears normally13:02
=== MacSlow|lunch is now known as MacSlow
ScottKkenvandine and/or pitti: Is someone working on getting the farsight/farstream mess worked out?13:07
pittiI assigned it to kenvandine13:08
pittiah, he's online now13:08
pittikenvandine: ^ RSVP13:08
kenvandinehey pitti13:08
kenvandinei was just reading that bug report13:08
pittikenvandine: bug 95213613:08
ubottuLaunchpad bug 952136 in papyon (Ubuntu Precise) "libfarstream-0.1-0 not installable due to conflict with libgstfarsight0.10-0" [Critical,In progress] https://launchpad.net/bugs/95213613:08
pittikenvandine: not a good thing to upload library changes on a Friday evening :/13:08
pittikenvandine: I was wondering, is there a particular reason for the libraries to conflict?13:08
pittikenvandine: even when switching papyon to farstream, it'll still cause apt to have a hard time during upgrades13:09
kenvandinebecause they both provide the same gstreamer plugins13:09
kenvandinewe should make papyon get removed i think13:09
pittikenvandine: that ought to be a Breaks: then13:09
kenvandinetelepathy-butterfly isn't really supported upstream13:09
kenvandineupstream switched to haze13:09
kenvandinei'll do that13:10
pittikenvandine: i. e. add a Breaks: python-papyon somewhere?13:10
pittiplus removal bug plus seed fix?13:11
kenvandineis it seeded?13:11
ScottKIs there an alternative for MSN support?13:11
ScottKIt's seeded in Kubuntu.13:11
pittikenvandine: something pulls it into Kubuntu, so I guess yes13:11
kenvandinewell actually we don't want to break papyon13:11
ScottKThat's what broke the Kubuntu images over the weekend.13:11
pittikenvandine: you need to Breaks: it if you want it removed in upgrades13:11
pittiand if we keep papyon, the libraries can't conflict13:12
kenvandineor make papyon depend on the new one13:12
kenvandineassuming it works13:12
* kenvandine checks with upstream13:12
ScottKpapyon seems pretty widely used "Task: ubuntu-desktop, ubuntu-usb, kubuntu-desktop, kubuntu-full, kubuntu-active-desktop, kubuntu-active-full, kubuntu-active, edubuntu-desktop, edubuntu-usb, edubuntu-desktop-kde"13:13
pittipython-papyon is kubuntu and edubuntu-desktop-kde only13:13
kenvandinethe only rdepends is telepathy-butterfly13:13
kenvandinewhich telepathy will completely ignore now even if it is installed13:14
pittiright, and it seems ubuntu uses something else than butterfly for MSN13:14
ScottKRight.  Stale cache.13:14
kenvandineit uses telepathy-haze now13:14
pittikenvandine: then it seems we can just as well remove the package and breaks: it?13:14
kenvandineassuming the rdepends is accurate13:15
kenvandinei am surprised it was seeded directly13:15
ScottKpitti: Except then we lost msn support in the KDE telepathy stack (AIUI)13:15
kenvandineScottK, telepathy-mission-control-5 switched to haze for MSN13:15
kenvandineand internally it migrates all the settings13:15
pittiScottK: is libpurple too heavy for kubuntu?13:16
kenvandinethey effectively blacklisted butterfly/papyon13:16
ScottKpitti: I don't know.13:16
kenvandinebecause it was breaking nearly weekly13:16
pittiah no, libpurpose is alreayd on kubuntu13:16
pittierr, libpurple13:16
pittiso adding -haze shouldn't be a problem13:16
ScottKI really don't know the telepathy stuff at all.13:16
jmlI just distupgraded and lost13:16
jmlI just dist-upgraded and lost unity.13:16
ScottKThe only reason I'm caring at the moment is kenvandine's upload on Friday broke our image builds.13:17
Riddellpitti: oh really?  I wonder what that's for13:17
ScottKRiddell: Do you understand how the telepathy stuff runs together well enough to figure the best path forward here?13:18
pittiRiddell: http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.precise/desktop.depends13:18
Riddelloh it'll be telepathy-haze13:18
pittiRiddell: telepathy-haze is already on the kubuntu images13:18
dupondjemsn worked fine this weekend :D13:18
RiddellScottK: what's the issue?13:18
pittiso it seems we just need to drop -purpoe13:18
kenvandinethe haze/buttefly depends stuff changed a couple weeks ago13:18
pittierr, t-butterfly13:18
ScottKRiddell: See backscroll here.13:18
seb128jml, will teach you to dist-upgrade and ack without reading? ;-)13:18
* pitti mutters "precise-proposed"13:18
RiddellScottK: I have, not worked out what the issue is yet :)13:18
Riddellfarsight/farstream ?13:19
jmlseb128: yeah, I guess.13:19
ScottKRiddell: Yes.13:19
ironmhello. May I ask one question, please? Why do I need an invitation for the #ubuntu-live channel? I have found some issues with live-builder on ubuntu 11.01 or 12.04 (server) but can't report them anywhere. I am looking for current documentation how to create live images on ubuntu.13:19
ironmthank you in advance for any hints13:19
ScottKBug #952136 is why our builds broke over the weekend.13:19
ubottuLaunchpad bug 952136 in papyon (Ubuntu Precise) "libfarstream-0.1-0 not installable due to conflict with libgstfarsight0.10-0" [Critical,In progress] https://launchpad.net/bugs/95213613:19
kenvandinethey really conflict, but the question is does kubuntu really need papyon13:19
kenvandinenothing rdepends on it13:19
kenvandinebesides telepathy-butterfly, which won't work anymore anyway13:20
Riddellkenvandine: what's papyon ?13:20
ScottKRiddell: kenvandine and pitti are suggesting getting rid of papyon is the right answer, but I don't know what else would provide msn support then.13:20
kenvandinethe msn library that telepathy-butterfly uses13:20
pittikenvandine: I suppose not, but we still need something to breaks: it, to get it cleaned up on upgrades13:20
jmlexcept there are only so many giant walls of text I can deal with in a given day, so I'll probably make the same mistake again13:20
pittiScottK: telepathy-haze does, which is already in K13:20
kenvandineso it should be safe to drop it from the seed13:20
ScottKOK.  So then the question is doe that work with telepathy KDE?13:20
RiddellScottK: for kde-telepathy?  I expect libpurple through telepathy-haze does but I can check13:21
Riddelland kopete uses libmsn13:21
seb128jml, stop using command line tools and use update-manager?13:21
ScottKRiddell: Thanks.13:21
pittijml: actually, see bug 93021713:21
ubottuLaunchpad bug 930217 in Launchpad itself "Make proposed pocket useful for staging uploads" [Low,Triaged] https://launchpad.net/bugs/93021713:21
pittijml: if we get that, we can avoid temporary breakage like that13:21
ScottKironm: I suspect #ubuntu-installer is the channel you think you're looking for.13:21
pittijml: so if you happen to know a LP manager who can bump this... :-D13:21
jmlpitti: thanks.13:21
ironmthank you very much ScottK  :)13:22
Riddellkenvandine, ScottK: upstream kde-telepathy say telepathy uses telepathy-haze which uses libpurple13:23
kenvandineok, so it doesn't need to be seeded13:23
Riddellkenvandine: he says farsight has something to do with video/audio support which isn't yet in kde-telepathy so it's not an issue for us (might be for empathy I guess)13:25
kenvandineempathy already switched13:25
kenvandineso we're good13:26
* kenvandine is figuring out the right package to add the breaks too13:26
kenvandineit got removed from my box on dist-upgrade13:26
kenvandinei guess because of the farstream changed13:26
pittikenvandine: if apt can figure it out, that's ok13:27
pittikenvandine: but a single conflicts: in a library is usually relatively hard to get over13:27
pittiwithout a replaces:/provides or a breaks: on the app package layer13:28
kenvandinepitti, this is why we put it in the ubuntu-desktop ppa for a week first, to see if this caused any problems13:28
kenvandinei guess the best place would be in telepathy-mission-control-5 since it is effectly what removed butterfly support13:28
pittikenvandine: yes, that sounds good13:29
kenvandinebut technically farstream is what breaks papyon :)13:29
ScottKSo can butterfly and papyon be removed entirely?13:45
stgraber@pilot in13:46
=== udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
henrixpitti: ping13:47
pittihenrix: hello; please don't ping, just ask your question13:47
henrixpitti: i've been waiting for a while for the oneiric (and -lts) kernels to be promoted to -proposed13:48
henrixpitti: herton told me the right thing to do is to ping one of the arch admins...13:49
pittihm, I thought I did them all on Friday13:49
henrixpitti: i guess not :)13:49
pittiright, hit after my EOD on Friday13:49
pittiack, will do13:49
henrixok, no prob. i was just wondering whether there was something wrong.13:49
pittihenrix: all done14:01
henrixpitti: thanks!14:01
kenvandinepitti, ScottK:  i talked to the debian maintainer, he says he thinks the current farstream conflicts is enough14:03
kenvandinenobody reported any upgrade problems while it was in the ppa14:03
kenvandineand i just did a dist-upgrade in a VM and it did the right thing14:04
ScottKRight, but how many Kubuntu users use the PPA?14:04
kenvandineso i think we are fine as is14:04
pittikenvandine: well, that's not an indication, as nobody using the PPA ran kubuntu apparently14:04
kenvandinebut nothing in kubuntu actually depends on it14:04
kenvandinejust the seed14:04
pittiour auto dist-upgrade testing has some kubuntu support, though14:04
pittikenvandine: ok, so this just needs testing; if the dep gets dropped from k-desktop, it should work as well as in ubuntu14:05
kenvandinei think so14:05
kenvandineis someone fixing that?  or should i look at kubuntu-desktop?14:06
kenvandinepitti, ^^14:06
pittikenvandine: the seeds? please do14:07
kenvandineok, will do14:07
ScottKSo it looks like the path to papyon for Kubuntu is kde-telepathy -> telepathy-butterfly -> python-papyon.14:08
kenvandineScottK, and nothing should pull in telepathy-butterfly anymore, haze replaced it14:09
ScottKRight.  I can fix that.14:09
kenvandineand it won't be installable14:09
ScottKLooking now.14:09
Riddellif telepathy-core drops telepathy-butterfly then it won't be on the kubuntu images any more14:10
Riddellor ubuntu desktop or anything else14:10
Riddelljob done14:10
kenvandineit still needs to be removed from the kubuntu-desktop seed though14:10
hallynthe auto-quilt-pop-push in bzr merge is making for hard to review merges...14:12
hallynis there something better than 'bzr diff' and 'bzr st' to show what actually changed?14:12
hallynoh it didn't reapply them14:13
Riddellkenvandine: it's not in the kubuntu-desktop seed14:14
kenvandineah, great~14:14
ScottKRiddell: telepaty-butterfly provides Provides: telepathy-connection-manager14:14
kenvandinei thought pitti said it was14:14
kenvandinethen i don't need to worry about it :)14:14
ScottKThat's why it's getting pulled in.14:14
Riddellthe only thing in the seed is kde-telepathy14:15
ScottKwhich depends on telepathy-connection-manager14:15
Riddellif that ends up with telepathy butterfly installed then indeed there is another problem somewhere14:15
ScottKWhat else provides that?14:15
Riddelldunno, ask whoever maintaines telepathy14:16
ScottKHaze does14:16
ScottKWe have that already.14:16
ScottKRiddell: I think I know how to fix it.14:16
Riddellso demote telepaty-butterfly and job done14:16
kenvandinethat is a good idea14:16
ScottKkenvandine: Is there any reason not to just remove it?14:17
kenvandinetelepathy wouldn't use it even if it was installed14:17
kenvandineso yeah, we can do that too14:17
ScottKpitti: ^^^ Would you kill telepathy-butterfly, source and binary?14:18
cr3pitti: I see you packaged postgresql, do you think that postgresql-plpython should have an actual meta package instead of a purely virtual one? the latter prevents me from specifying a dependency like postgresql-plpython (>= 8.4)14:18
ScottKkenvandine: telepathy-gabble and telepathy-haze both provide telepathy-connection-manager.  Is one preferred?14:19
kenvandinedifferent services14:19
kenvandinegabble is jabber (including gtalk and facebook)14:20
ScottKRiddell: It's also a package back in the meta-kde-telepathy package to only depend on a virtual package.  It should depend on realpackage | virtualpackage to avoid these kinds of problems.14:20
RiddellScottK: file a bug and ping me if you need packages removed14:21
Riddellassuming it's a package I care about :)14:21
ScottKFirst I'll fix meta-kde-telepathy.14:21
pittiScottK: removing14:22
pittiand sync-blacklisted14:23
pitticr3: as the server-side extensions are version specific, it usually doesn't make too much sense to depend on an arbitrary one14:23
=== JanC_ is now known as JanC
cr3pitti: how can I express something like this then: postgresql (>= 8.4), postgresql-plpython (>= 8.4)14:24
cr3pitti: even though the extension are version specific, the package depending on it might not now the specific version :)14:24
cr3pitti: the only workaround I can think of would be to branch my project for each version of Ubuntu, which would seem unfortunate just because of postgresql-plpython :(14:26
pitticr3: how about Depends: postgresql (>= 8.4), postgresql-plpython14:26
cr3pitti: I'll give that a try, thanks!14:27
=== smb` is now known as smb
cr3pitti: worked like a charm, thanks!14:28
pitticr3: to be _really_ correct, you'd also need to require that server and plpython are of the same version, but that's hard to express with dependencies14:29
cr3pitti: yeah, I do that within my own packages, like (= ${binary:Version}), but I wouldn't know how for external packages14:30
ScottKpitti or Riddell: Bug #95306114:32
ubottuLaunchpad bug 953061 in papyon (Ubuntu) "Please remove papyon (source) and python-papyon (binaries) from precise" [Undecided,New] https://launchpad.net/bugs/95306114:32
lamonthttp://paste.ubuntu.com/880433/ <-- d-r-u got lost on run 1, the second run I get this14:40
infinitylamont: You might need to manually install at least libc6*, libstdc++*, libgcc*, libapt*, and apt_* from /var/cache/apt/archives. :/14:57
infinitylamont: Things getting wedged halfway through can end badly for apt, if it's at just the wrong time.14:57
infinitylamont: (And if any of those is actually unable to install/upgrade, bug reports plox!)14:58
lamontyeah - working thruogh it now14:58
henrixpitti: sorry to bother you again, but it looks like something went wrong during the upload14:59
henrixpitti: take a look at comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949882/comments/215:00
ubottuLaunchpad bug 949882 in Kernel SRU Workflow "linux: 3.0.0-17.30 -proposed tracker" [Undecided,In progress]15:00
m_3mhall119: please ping me if you get a chance... I'd like help with summit production configuration15:00
infinityhenrix: Will fix.15:01
henrixinfinity: thanks for taking a look at it15:01
mhall119m_3: ping15:01
m_3mhall119: hey15:02
m_3mhall119: so let me spin up a fresh stack of summit/postgresql/memcached15:03
infinityhenrix: Hrm.  Those meta packages appear to have always been in universe.15:04
* infinity will look again in a sec.15:04
henrixinfinity: interesting...15:05
pittihenrix: I promoted all pacakges to main, are these comments a bit misleading?15:06
pittihenrix: I. e. do they actually say "the package is in main, but should be in universe"?15:06
infinitypitti: Did you?15:06
pittihenrix: that's known; we can't do PPA copies and fix the components at the same time15:07
pittihenrix: so I'm usually waiting for replies like this, and then fix them up individually15:07
infinitypitti: Unless you just did (like, since the last publisher run), all these packages from linux-meta are still in universe.15:07
pittioh, I didn't override linux-meta15:07
infinitypitti: But, it also seems like they always have been.15:07
pittisince when does _that_ need overriding?15:07
infinitylinux-backports-modules-cw-3.2-oneiric-generic | | oneiric-security/universe | amd64, i38615:07
infinitylinux-backports-modules-cw-3.2-oneiric-generic | | oneiric-updates/universe | amd64, i38615:07
infinitylinux-backports-modules-cw-3.2-oneiric-generic | | oneiric-proposed/universe | amd64, i38615:07
infinity^-- For example.15:07
infinitypitti: It needs overriding when new backport packages are added.15:08
infinitypitti: New is new is new. :P15:08
infinitypitti: And it looks like the first time the -cw-3.2- stuff was added, it went to universe, and no one complained until now.  I guess.15:08
pittimeh; pretty please let's stop mixing components for the kernel; it's a PITA15:08
infinitypitti: We don't.15:08
pittithey should all be in main really15:08
infinitypitti: It should all be in main.15:08
infinitypitti: But LP punts new packages to universe, and some AAs are lazy? :P15:09
infinitypitti: AFAIK, everything from linux, linux-backports-modules, and linux-meta is meant to be in main.15:09
stgrabercan't we get regexp based component overrides? sounds like it'd help quite a bit with the kernel15:09
pittiok, overriding15:09
infinitystgraber: There's a bug open to just change the automagic logic.15:10
pittihenrix: fixed the overrides, thanks15:10
infinitystgraber: It's my contention that new binaries should default to the same component as their source.15:10
stgraberinfinity: that'd make sense indeed15:10
infinitystgraber: And others seem to agree.  But no one's bothered to fix it.  Was this you volunteering? ;)15:10
* pitti needs to reboot urgently, brb15:10
henrixpitti: great, thanks. i'm just looking at the irc backlog to understand what happen...15:11
pittihenrix: for hardy and lucid it's almost guaranteed that we'll get this kind of mail, and I'll fix it once we get it15:13
pittihenrix: (just so that you aren't scared in the future)15:13
henrixpitti: thanks :)15:14
henrixpitti: i *was* scared actually :)15:14
geserpitti, cr3: would it be even possible at all to specify a dependency on matching postgresql-plpython and server? given that several postgresql clusters can exists in different versions and it's possible that postgresql-plpython is only installed for one specific postgresql version and not the others15:16
pittigeser: it's a nice academic exercise15:16
pittidepends: (postgresql-8.4, postgresql-plpython-8.4) | (postgresql-9.1, postgresql-plpython-9.1)15:17
pittiand then do the usual boolean transformation to rewrite this in conjunctive normal form15:18
hertonpitti, infinity, about component mismatches, we got on Lucid as well, because of the preempt packages (bug 947375). Well this one is the problem that on lucid not everything goes on main for this case15:19
ubottuLaunchpad bug 947375 in Kernel SRU Workflow "linux: 2.6.32-40.87 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/94737515:19
stgraberinfinity: not volunteering just yet but might end up having a look next time I get hit by it (usually when doing netinstalls) :)15:19
pittiherton: oh, this sets the task to "incomplete", fixing my canned search to include this15:20
hertonpitti, I could change it back to confirmed, if you want15:20
hertonpitti, I mean, change the bot to do it instead of using incomplete15:21
pittiherton: fixed my canned search, but thanks15:23
henrixpitti: i got the same comment again on LP...15:29
pittihenrix: it needs about half an hour up to an hour to get effective (needs a publisher run)15:29
henrixpitti: ah, right. since the promote-to-proposed had changed to fix release, i though it was solved already15:30
henrixpitti: but it went back to incomplete again. anyway, i'll wait :)15:30
pittihenrix: well, I close it as soon as I fix the overrides15:30
pittiI don't wait for a publisher15:30
hertonpitti, I'll change the bot to delay the check, 1 hour of delay should ensure things to be published?15:30
pittiit's a hard enough process already :)15:31
pittiherton: yes, 1 hour is guaranteed to be enough15:31
pittiherton: publisher runs at :03 and :33 I believe15:31
hertonok cool15:31
pittiherton: cheers15:31
pittimvo: I'd appreciate a look from you at bug 950676; it does look like an apt problem, but it might be possible to add some dependency "hints" to work around it?15:34
ubottuLaunchpad bug 950676 in apt (Ubuntu Precise) "lucid->precise upgrade failure due to gir1.0->gir1.2 conflicts" [High,New] https://launchpad.net/bugs/95067615:34
mvopitti: will do, I'm curently on bug #94039615:35
ubottuLaunchpad bug 940396 in apt (Ubuntu Precise) "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [Critical,Confirmed] https://launchpad.net/bugs/94039615:35
pittimvo: ah, thanks; not that urgent, just if you could have a look in the next days15:36
pittiqueue a tab in firefox or so15:36
mvopitti: thanks, adding it now15:36
dupondjeWhen dh_installinit is executed in debian/rules. and there is an upstart file, does it start on all runlevels?15:38
pittihenrix, herton: the checker seems to be wrong for omap4, see bug 95057215:38
ubottuLaunchpad bug 950572 in Kernel SRU Workflow "linux-ti-omap4: 3.0.0-1208.18 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/95057215:38
pittidupondje: upstart doesn't have it's own concept of runlevels; it'll start as soon as the "start on" condition is true15:39
pittidupondje: "start on" might say "on run levels 2 to 5"15:39
hertonpitti, I think it should have gone to main originally, as all linux-ti-omap4 packages were on main previously (for natty and maverick)15:40
pittiherton: I agree; but that doesn't help us now, as oneiric release has it in universe15:40
hertonpitti, so couldn't it be moved to main on updates/proposed? But ok, I can add an exception for it, it this can't be done15:42
pittiherton: it could, but in general we try to avoid changing components after release15:42
pittiherton: e. g. linux-tools-omap4 might have a dependency on another universe package15:43
pittiwhich wuold break if we promote it to main15:43
pittiherton: I had assumed your script compares it against the component in the release, but seems not; is that a hardcoded mapping in your script?15:43
hertonpitti, depends, by default it checks the component on release, but for ti-omap4 it's a hardcoded enforce to be on main15:44
cjohnstonm_3, mhall119; mhall119, m_3    :-)15:45
m_3cjohnston: thanks!... we've been PMing15:46
m_3cjohnston: how would you like to handle the linuxplumbers theming?15:46
m_3we can branch ubuntu_website and modify the template there15:47
cjohnstonm_3: thats probably what will heppen15:47
m_3do they want to go with the ubuntu theme?15:47
m_3ah, ok15:47
cjohnstonno.. we are going to use a plumbers theme...15:48
cjohnstonthey can have the ubuntu theme for now tho15:48
cjohnstoni still havent gotten complete instructions15:49
dupondjeWhat trigger should be used in upstart to run on shutdown (after disks are umounted)15:49
m_3cjohnston: ok, well maybe I can just pass it as a config param for the charm... i.e., the theme/site branch15:49
m_3defaults to ubuntu_website15:50
m_3currently set to http://bazaar.launchpad.net/~ubuntu-community-webthemes/ubuntu-community-webthemes/light-django-theme15:50
hertonpitti, I see here that linux-ti-omap4 were released originally on main actually: http://pastebin.ubuntu.com/880527/15:51
infinityherton: Yes, but not linux-tools-omap4, which is from -meta.15:53
cjwatsonpitti: the publisher doesn't actually always quite manage to run every half-hour, as sometimes it overruns its slot; one hour is *usually* enough, I just wouldn't like to say "guarantee"15:53
stgraberseb128: I'm looking at https://code.launchpad.net/~nik90/ubuntu/precise/totem/add_quicklist/+merge/94170 just now, the submitter did the changes you requested and it looks good to me. I just wanted to check with you that it's indeed ok to upload this change at this point in the cycle as it's essentially adding new translatable strings15:54
hertoninfinity, oh right, nevermind15:55
seb128stgraber, hey, it's ok, we will warn the translators soon about the ones which got added in a batched way15:57
hertonpitti, infinity, I'll just fix the script to not enforce everything on main, the tools are on universe on maverick and natty as well15:58
herton*not enforce everything on main for ti-omap4 meta15:58
pitticjwatson: ah, thanks; anyway, probably good enough for the checker scripts15:59
stgraberseb128: ok, I'll make the upload then, unless you have a totem upload coming up soon?15:59
seb128nothing planned so feel free to upload15:59
hertonpitti, infinity, fyi, this is the class which checks the components:  ktl/check_component.py, used by  stable/check-component and the bot (from git://kernel.ubuntu.com/ubuntu/kteam-tools.git)16:00
m_3cjohnston: let's set up a walkthrough on managing the summit stack using the charms... I'm just waiting on info about which ec2 accounts to use, and then I'll be ready to go over it with you.16:07
stgrabercjwatson: could you hardcode lxc in the ubuntu-server packageset? it tends to get out of it pretty often (as it's not actually seeded on any of the server seeds but it's definitely actively maintained by the server team)16:37
stgraber(I just added it again manually but I suspect it'll be dropped next time the script runs)16:38
jamespagemicahg, around? can we discuss the native/non-native packages on the zentyal/ebox packages?16:38
micahgjamespage: sure, I"m heere16:39
cjwatsonstgraber: yeah, please don't change the automatically-maintained package sets manually :)16:40
jamespagemicahg, sweet - so I just read your comments on bug 92850116:40
ubottuLaunchpad bug 928501 in ebox (Ubuntu) "Precise will ship totally broken ebox packages" [High,Confirmed] https://launchpad.net/bugs/92850116:40
cjwatsonstgraber: I've added an exception for it now (which has caused it to drop out of edubuntu, incidentally)16:41
micahgstgraber: the source has dropped to universe for precise, is that intentional?16:41
stgrabercjwatson: thanks16:41
jamespagemicahg: upstream don't ship tarballs; they release packages and only for ubuntu16:41
stgrabermicahg: yes, nothing in main depends on it and it's not seeded by anything but edubuntu at the moment16:42
jamespagewhich was the thinking behind sticking with the native format - rather than switching to 3.0 (quilt) and adding in an extra step16:42
micahgstgraber: i.e. do they not want it "officially" supported16:42
stgrabermicahg: it probably should be seeded by server though but that's a discussion for the server team to have :)16:42
tumbleweedjamespage: is the Ubuntu pcakaging going to be maintained in their VCS branches?16:42
micahgDaviey: ^^16:42
jamespagetumbleweed, yes16:43
stgrabermicahg: I think we want to officialy support it and we kind of do, I'm all for an MIR + adding to at least supported seed. I remember the security review being a problem last time it was attempted though16:43
stgrabermicahg: hallyn would know more16:43
micahgjamespage: yes, but as it's not an Ubuntu specific thing in the sense that it's tied to our archive in some way, I'd think they should really release tarballs or use bzr snapshots, but there should be an upstream tarball as they're an upstream of Ubuntu16:43
micahgstgraber: ah, well, I don't want to increase security headaches ;)16:44
Davieystgraber: why would we seed something like this?16:44
micahgjamespage: s/bzr/vcs/16:44
Davieyjamespage: we don't want this in main do we?16:44
jamespagemicahg, I'm not seeing how its NOT an Ubuntu specific thing? maybe I'm missing something16:44
jamespageDaviey, no16:45
Davieyahh, two discussions happening concurrently16:45
* Daviey switches on SMP.16:45
micahgjamespage: it's Ubuntu specific in that they develop for Ubuntu not that it's inherently tied to Ubuntu16:45
stgraberDaviey: I'm talking about lxc, not ebox :)16:45
infinityI think lxc absolutely should go through the MIR dance and be supported.16:45
infinityIf for no other reason than it's the only way to approximate "virtualisation" (and I use the term loosely) on ARM.16:46
hallynstgraber: micahcg: sorry, i can't follow the above :)  when the otehr issues are done being discussed, pls ping me and re-ask16:46
Davieyinfinity: does qemu not work on arm? :)16:47
infinityDaviey: Full emulation, sure, no paravirt.16:47
Davieyinfinity: Have you been tracking the work kvm and xen are doing to work on arm?16:47
infinityDaviey: So, if you want a bunch of VMs that run at the speed of a TI graphinc calculator, you're set.16:48
m_3mhall119: dude... Daviey has a custom manage command that'll work http://pb.daviey.com/MTUs/16:48
m_3mhall119: can probably make that work for prepopulating menus too16:48
infinityDaviey: kvm and xen paravirt on ARM will only happen for A15 cores and beyond.  The hardware support just ain't there in current hardware.16:48
micahgjamespage: for instance if Debian or Fedora wanted ebox, from what I've read in that bug, the upstream developers would welcome patches16:50
jamespagemicahg: hmm16:50
mhall119m_3: that would work for superuser16:50
mhall119I think think it's better for us to make the code not crash when there isn't a menu (or summit)16:51
m_3mhall119: well... ok :)16:52
micahgjamespage: again, this is only for the distro packaging, for their own packaging purposes, they're free to use 3.0 (natiive)16:52
tumbleweedjamespage: also, native packages make no separatino between packaging and upstream. Unless all developers who have upload rights for the packages have commit rights on their source branches (and exercise them), they're likely to get out of sync16:53
micahgjamespage: and with source format 3.0, the upstream debian dir is ignored IIRC, so they don't conflict either16:54
jamespagemicahg, tumbleweed: so its really a) we fork the packaging and got with 3.0 (quilt) and have to merge each new upstream release in as we would do16:55
micahgjamespage: yep, same as any other upstream :)16:55
jamespageor b) we risk holding a delta over upstream by sticking with 3.0 (native)16:55
tumbleweeda hard to manage delta16:55
micahgI see b as wrong from the distro perspective which is why I mentioned it in the first place :)16:56
jamespagemicahg, I guess the challenge here is that upstream are also the maintainer of the packages...16:57
jamespagehence adding in a step to switch the format of the packaging seems like extra work16:58
micahgjamespage: but they're not as they're not Ubuntu developers (and we don't have maintainers in Ubuntu :))16:58
micahgthey're the upstream developers who may in time get upload rights to their packages16:58
tumbleweedit's really not that big an extra step. It's trivial to add a tarball generating rule to debian/rules16:59
Davieytumbleweed: Yes, you'd think we'd know that, right? :)17:00
* tumbleweed has an (I beleive fairly rational) hatred of native packages :)17:00
DavieySeriously, this should not require so much consideration17:01
tumbleweedthat too17:01
infinityIt's easily handled with VCS branches.17:01
infinityI used to maintain telepathy-glib upstream, Debian, and Maemo, and it was all just git branches of the same thing, with different debian directories plopped on top.17:02
infinityThe fact that "upstream" was also the maintainer in two distributions was handy, but not an argument for native packaging.17:03
dholbachone day we'll have a world without tarballs17:03
=== MacSlow is now known as MacSlow|dinner
infinity(In fact, it maintained my sanity to have the debian-less upstream source be the "base")17:03
Davieynative packages are policy compliant, i see their limitations, but really, why create extra work?17:03
infinitydholbach: Meh, a tarball is no different from an upstream tag in a VCS.  You still want a snapshot of a released state.17:04
Davieyit's upstream maintaining this, lets be flexible, but within policy17:04
infinitydholbach: (And, in fact, Nokia's internal build system for Maemo created orig.tar.gzs out of thin air from git tags)17:04
infinityDaviey: Oh, I don't care if people package natively.  But a project that seems open to being used in places other than Ubuntu might want advice on how best to do that, and native maintenance isn't it.17:05
infinityDaviey: I imagine that's what micahg was driving at.  I hope.17:05
Davieyright, and when that happens, let them switch the package to quilt17:05
dholbachinfinity, the current tarball + patch system + vcs world is very far from my ideal world :)17:05
infinitydholbach: I don't mind it too much, except when people forget that the archive is authoritative because they live in a fantasy world where the VCS is. :P17:06
micahgDaviey: infinity: yes, but I believe it's disingenuous to use 3.0 (native) for something that's not developed specifically by Ubuntu developers for use in the Ubuntu archive17:07
infinitydholbach: (The Maemo "releases are tags" thing kinda fixed that for them)17:07
Davieymicahg: currently that is the case.17:07
dholbachinfinity, if everything was all just branches, merging from each other would be a lot easier :)17:07
Davieymicahg: If you want to take on the work to switch it, please do.17:07
infinitymicahg: native doesn't imply origin, it's an unfortunate name.17:07
micahgand also, another argument is that it makes them always think about the packaging vs upstream difference which is important for distro uploaders17:08
micahginfinity: it doesn't, but it makes sense from a distro perspective to use it that way17:08
=== JanC_ is now known as JanC
micahgDaviey: and as has been pointed out lp:ubuntu/foo will be the authoratative packaging branch regardless, it would seem to make sense to enforce that at a packaging level by using 3.0 (quilt)17:09
Davieymicahg: great, please prepare the patches.17:10
micahgassuming it's up to date17:10
infinitymicahg: The authoritative packaging branch is "apt-get source ebox". :P17:10
infinitymicahg: Anything else is a delusion.17:10
micahginfinity: yes, well, that's why I said if it's up to date :P17:11
Daviey(for now)17:11
infinity(A delusion people are trying to make a reality, but until it all works right, I'm sticking with my statement)17:11
micahgDaviey: I've got a few other things I'm working on at the moment, but it should just be a matter of generating an upstream tarball and switching the debian/source/format content, I know there are links somewhere on how to generate an upstream tarball from a VCS17:13
cjwatsonscott-work: nothing reconfigures jack at boot on ubuntustudio live systems - I guess we want that to happen?17:13
scott-workcjwatson: yes please17:14
Davieymicahg: dude, we know that.. but if you feel that is how it should be done, please do it.17:15
Daviey(and liase with upstream)17:15
jamespagemicahg, Daviey: I'm really concerned that we are putting in place a barrier between Ubuntu and this upstream project17:16
jamespagethat we don't really need to have in place17:16
micahgjamespage: Daviey: I don't think I should be obligated to fix something that's not even in the archive yet in order to have it follow sane packaging requirements17:16
Davieymicahg: requirements ?17:16
Davieymicahg: Are you suggeting ntive is anti-policy?17:16
micahgthat barrier is that there's a difference between upstream and distro developement17:16
micahgDaviey: in this type of scenario, I think it is17:17
infinitymicahg: There isn't right now.  If they start accepting patches to work on other distros, there will be a difference between upstream and distro.17:17
infinitymicahg: For now, native, while perhaps not entirely correct, isn't entirely incorrect either.17:18
infinitymicahg: And it's trivial to change from native to non-native later.17:18
micahginfinity: there is as we might patch things at the distro level that "upstream" never needs to see including SRUs17:18
infinitymicahg: I tend to agree with you on what I prefer to see, but it's not that meaningful in cases like this.17:18
micahginfinity: I think it matters when people are trying to patch things17:19
infinitymicahg: Meh, we do SRUs of other native packages that often never need to go in the latest devel release.  I don't see the difference.17:19
jamespageI also think we have an upstream project who will want to know about SRU updates17:19
jamespagetheir entire product is based on Ubuntu...17:20
micahginfinity: it's a pain to patch a native package especially when the last "patch" needs to be removed17:20
infinitymicahg: It... Is?17:20
* cjwatson patches native packages all the time; if it's hard you're doing it wrong17:20
infinitymicahg: Apply change, dpkg-buildpackage, done.17:20
infinitymicahg: It's arguably easier to patch native packages, not harder.17:20
cjwatson(perhaps by mistakenly believing that patch systems are a good idea when applied to native packages)17:21
micahginfinity: cjwatson: well, you're both AAs and seasoned developers, am I wrong to be taking such a strong stance against this?17:22
infinitymicahg: I think that, as long as they continue to target only Ubuntu (and it's a pretty specific set of tools), the point is kinda moot.17:23
pittiI haven't followed the whole discussion, but why would we consider ebox a native package? because there's no upstream any more? (zentyal now)17:23
infinitymicahg: I agree with you that if/when they target other distros, they should perhaps branch packaging seperately from "upstream source", but I can't see how it matters one way or the other right now.17:24
infinitymicahg: I, personally, would have an upstream/distro division if it was my project, and obviously you would too, but if they literally ONLY release to Ubuntu right now, that's the definition of "native".17:25
pittii. e. they don't release at all, and don't have their own VCS, etc?17:25
infinitymicahg: And it's asking them to do extra busy work to do upstream release tags/tarballs/whatever if they don't actually do "upstream releases".17:26
micahginfinity: to enforce the upstream/distro packaging difference?  it's easy for the "upstream" branch to get out of sync17:26
infinitypitti: They have their own VCS, but AFAIUI, they only "release" to Ubuntu, not with "upstream releases".17:26
pittiso if they have their own VCS and development, it's not a native package17:26
infinitypitti: Err.17:26
micahginfinity: also, someone's going to have to get some type of tarball from them to upload, they're not Ubuntu devs, so what does it matter if that is an .orig.tar.gz or a .tar.gz?17:26
tumbleweedif they also plan to release to a PPA for older ubuntu releases, it' squite likely that there'll be times when the PPA packages will need to be different to current ubuntud dev release17:27
infinitypitti: There are any number of native packages (or have been in the past) in Debian that don't use {cvs,bzr,arch,git,svn}.debian.org17:27
pittiinfinity: that's not what I meant17:27
infinitypitti: The location of one's VCS doesn't define your release style, it's where you release to (in their case, the Ubuntu archive, not upstream tarballs)17:27
pittiinfinity: if they actually _use_ lp:ubuntu/ebox as their development trunk, it'd be native17:27
micahginfinity: and in fact from their perspective, the tarball won't make a difference regardless of that source format in the archive (unless packaging changes are needed)17:28
pittiif they have their own git or whatnot somewhere, then that his the trunk, and it can't conceptually be a native package17:28
infinitypitti: Well, that was kinda my point.  Them not using UDD branches doesn't define how they're releasing.17:28
* infinity shrugs.17:28
pittiinfinity: it's not just about releasing (although _if_ they release tarballs, then that certainly matters), it's also how they develop17:28
pittiand if their trunk can be different from our package, then it's not native, IMNSHO17:29
* micahg hugs pitti17:29
infinitypitti: So, before UDD, nothing was native?  Or when UDD branches happened, any native package that didn't immediate switch all development work to that branch was wrong?17:29
infinity(Hint, we have a few)17:29
pittiinfinity: I'm not speaking about UDD here; you can replace lp:ubuntu/precise with "apt-get source ebox"17:29
infinityAnd while the UDD machinery keeps them magically in sync, sometimes that breaks.17:29
pittiI just mean "whatever is in Ubuntu"17:29
infinitypitti: Ahh, then yes, AFAIK, 'apt-get source ebox/precise' matches their latest released version.17:30
pittibut anyway, I stated my opinion; it's apparently not unanimous, so I guess I STFU again and continue bug fixing :)17:30
infinitypitti: Since they only release it to Ubuntu.17:30
infinitypitti: That was sort of my point. :P17:30
pittiinfinity: so if they change something, they apt-get source, change, upload?17:30
pittithat's certainly a very strange project indeed17:30
maxbPerhaps the way to express it is "It is native if the VCS branch used for upstream development and the VCS branch used for uploads to Ubuntu are the same branch" ?17:30
infinitypitti: No, they change it in their VCS and upload.  Just like half the native packages we ship.17:31
pittiok; that certainly is weird17:31
pittibut I guess they can get away with a native package then17:32
jamespagepitti, if you consider the project I don't think it is - its entirely based on Ubuntu17:32
infinityI don't see it as any different from how we do kernel development, or some installer bits, or, or...17:32
infinityThe only argument here is that they're not devs, so they can't upload themselves, and somehow that's giving people hissy fits.17:32
infinityBut the development model is identical to how we do plenty of our own native packages.17:33
pittikernel is not native, FWIW, and it would certainly wrong for it to be17:33
pittibut I see what you mean17:34
infinitypitti: It often is, during development cycles, and flips non-native for release, actually.17:34
pittibut d-i is inherently a distro thing, while ebox isn't17:34
infinitypitti: Have you looked at ebox?17:34
infinitypitti: It's wildly distro-specific right now.17:34
pittiinfinity: a few years ago, yes17:34
pittinot recently17:34
pittifrankly, I considered its concept quite broken back then, but that might have changed17:34
infinityIt's not inherently so, in that it could be extended to work with others, but no one's doing that work.17:34
infinityI'm not a fan of it either, that's out of scope for this. :P17:35
micahginfinity: it's more than they're not devs, it's that while they're work is based on Ubuntu and for Ubuntu, it's not Ubuntu in that's it's not developed as part of the project for the archive17:36
infinitymicahg: It is when you start uploading their for-the-archive releases to the archive? :P17:37
infinitymicahg: There seems to be some chicken and egg issue there.17:37
micahginfinity: no, distro-specific != native to the project17:37
infinityI disagree.17:37
infinityIf it's distro-specific and in the archive, it's native.17:37
infinityUnless, as you claim you're not, you make the distinction based on the identity of the uploader.17:38
* infinity shrugs.17:38
infinityColin was smart enough to pretend not to have an opinion when asked.  I might do the same and go back to work. :P17:38
jamespagewell if you look at 'changed-by' most updates in the last 2 years have been done by ebox/zentyal guys...17:38
jamespagejust as sponsored uploades17:39
scott-workcjwatson: please let me know if i can help with anything17:40
micahgI'd posit that regardless of what you're targetting, what matters is where the development is done, the development for ebox is done as part of the ebox/zentyal project, not the Ubuntu project17:40
* scott-work realizes this is a pretty feeble offer17:40
dupondjeGot some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it?17:41
infinitymicahg: I think that's again splitting hairs, if all releases are meant to be released to the Ubuntu archive, where the development "happens" doesn't matter to me.17:42
* micahg is thinking of adding an item to the TB agenda if they're not dealing with more important issues17:42
infinitymicahg: All the development for my latest native upload happened on my hard drive.  Totally not an Ubuntu-blessed VCS.  And it was part of my own "flip bits on my hard drive until a package comes out" project.17:43
infinity(Which was successful, by the way, I'm a wizard with tiny magnets)17:43
micahginfinity: I'm not referring specifically to the VCS location either17:44
infinitymicahg: The only difference at all between me and them is that I didn't need to beg a sponsor to bless my upload.17:44
infinitymicahg: As an added point, my latest native package actually could be used on any system with upstart, probably.  So it's even less valid as native than theirs is, but no one challenged it when I uploaded. :P17:44
infinitymicahg: And, if I decide to convert it to something I could upload to Debian, then I'd un-native it, and do some upstream/distro split.17:45
infinitymicahg: But as long as it exists in exactly one distro, and every change has been targetted at release to that one distro, that's perfectly valid as native.17:46
cjwatsonscott-work: shouldn't be desperately hard, just rsyncing a current image17:51
micahginfinity: while I agree that defines it as native to Ubuntu, I don't agree that stuff in the archive should be like that :)17:52
infinitybroder: Pingaling.  I understand you have a lintian lab you might be able to let me play with (or play with on my behalf)?17:52
infinitybroder: I need a broad grep -r of */debian for armel, so I can go through with a fine-toothed comb and make sure any armel tweaks/etc have been applied to armhf.17:54
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
scott-workcjwatson: well, my offer is not all philanthropical ;) , i'd like to learn whatever i can as well :-)17:59
ScottKinfinity: One in particular to look for is !armel specifications in debian/control.  I've been doing amd64 i386 powerpc instead for awhile knowing armhf was coming.18:00
infinityScottK: Anything .*armel.* needs looking at, really.18:01
ScottKinfinity: True, I just know there are !armel incantations around that are buggy.18:01
infinityMost of them are probably incorrect for armel too.18:01
cjwatsonscott-work: it needs testing, but it's probably http://paste.ubuntu.com/880708/ in casper18:03
cjwatsonor something along those lines18:03
slangasekRiddell: any news about soprano testing?18:24
slangasekScottK: when you say that the farsight transition is fixed, that doesn't seem to encompass python-papyon being transitioned to python-farstream... did these packages simply get removed from the Kubuntu dependency stack?18:26
ScottKslangasek: The solution for python-papyon was removal.18:32
ScottK(from the archive)18:33
ScottKThere's probably more that could be done to progress farsight/farstream, but the thing that was breaking the image builds is resolved.18:33
dupondjeGot some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it?18:34
stgraber@pilot out18:42
=== udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== MacSlow|dinner is now known as MacSlow
slangasekScottK: oh, now I see; somehow I thought empathy was being removed rather than upgraded, but apparently no18:47
scott-workcjwatson: thank you!18:58
scott-workcjwatson: i presume that this will properly configure jack in the liveFS which in turn will yield an installed FS which also is configured correctly, am i misunderstanding this?19:01
Riddellslangasek: oh sorry, soprano is all good19:17
Riddelldid I fail to say that on the bug?19:17
slangasekRiddell: ah, apparently :)  no worries, I'll upload now - thanks!19:17
broderinfinity: i've been stalling on actually setting things up so i can give other people access, but i think it's actually time for me to come up with a real solution. give me a little while to come up with something19:28
infinitybroder: Sure.  If it's too much hassle, I'm happy with just the output of the above greppination.19:28
infinitybroder: But being able to give access based on ssh keys from LP or something would be shiny.19:29
broderinfinity: yeah, i've been meaning to set that up, and as of the last few weeks, i think we've crossed the threshold where it's more work for me to keep ad-hocing it for people than setting it up so i can use ssh keys from LP19:30
* infinity just got the evil idea to write a launchpad->userdir-ldap import/sync shim.19:31
infinitySome days, I don't like myself.19:31
infinityThis is one of them.19:31
broderhave to say, it is slightly irritating that i can just grab /+sshkeys but can't get it through the lp api anonymously19:35
infinitybroder: Well, I suppose it's a potential information leak, since ssh keys are often in the form user@host.19:36
broderinfinity: yeah, but https://launchpad.net/~broder/+sshkeys is accessible without authenticating19:37
infinitybroder: Oh, it is?19:37
infinityNevermind, then.19:37
infinityIt's obviously broken in one direction or the other. :P19:37
brodermaybe i shouldn't make too much fuss about it or someone might fix it the wrong way :-P19:37
infinityI'd probably be inclined to go that way, yeah.19:38
infinityGiven that you can't see people's email addresses without being logged in, the potential disclosure issue in ssh public key comments is similar.19:38
ajmitchssh-import-id sort of relies on it being publically accessible, doesn't it?19:39
infinityajmitch: It does, yes.19:40
infinityajmitch: Though, it could certainly be rewritten to be a launchpadlib application that requires authentication.19:40
infinityI'm not sure I care deeply, mind you.19:40
infinityBut I don't really care about that level of disclosure in general.19:41
infinityPeople still wonder why I don't obfuscate my whois records and such.19:41
cjwatsonscott-work: it does both separately, hence the separate casper-bottom and ubiquity-hooks scripts - the installed system starts by copying the squashfs contents, not by copying the live session19:41
broderthe problem with making it a lplib application is that i now have to put my lp credentials on my server for it to be useful19:41
infinitybroder: That's where my ud-ldap/launchpad shim idea comes in.19:42
scott-workcjwatson: okay, that makes more sense looking at the pastebin, thank you :)19:42
infinitybroder: Since ud-ldap does central processing, then pushes bits out to machines, you wouldn't need to have credentials anywhere but that one spot.19:42
broderinfinity: ah, sure. but ewww, ldap19:43
infinitybroder: Meh.  ud-ldap's ldap part could be repaced by anything, really.19:43
infinitybroder: It's the ssh triggering or passing around nss-db bits (and keeping machines entirely independant of network failures) that's shiny.19:44
=== barry` is now known as barry
=== rsalveti` is now known as rsalveti
kirklandinfinity: no, please no....requiring lp authentication would break many (most?) ssh-import-id use cases20:37
kirklandbroder: I didn't catch your use case, sorry, but would ssh-import-id suffice for what you want to do?20:38
broderkirkland: not entirely. i wanted to create separate accounts for each person i was handing out access to20:38
kirklandbroder: accounts where?  in a cloud instance?20:40
broderkirkland: personal server20:40
kirklandbroder: sudo adduser && ssh-import-id?20:40
broderpretty much what i did20:40
kirklandbroder: ;-)20:41
ubottucjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive20:48
ScottKgang65: What's up?20:49
gang65bug #41026220:49
ubottuLaunchpad bug 410262 in xserver-xorg-video-openchrome (Debian) "[VX800]openchrome hangs when the mouse cursor is inside of a image in gimp" [Unknown,Confirmed] https://launchpad.net/bugs/41026220:49
gang65two patches was send instead of one20:50
gang65100_fix_xaa_display_issues.patch is correct20:50
gang65101_xaa_solid.patch is wrong20:51
gang65It causing the system hangs20:51
infinityGiven how long that bug's been open, I'm thinking it doesn't warrant use of the emergency broadcasting system. ;)20:53
ScottKinfinity: The fix is rather more recent.20:54
infinityScottK: Yes, but it's only in -proposed, is it not?20:55
ScottKinfinity: No, it's in updates20:55
infinityOh, indeed.20:55
infinityI missed that.20:55
ScottKIt's been there for a week, so there's probably no point in blocking it now, but it should be addressed.20:56
infinityOh, no question that it should be fixed.20:56
infinityJust that it doesn't appear world-endingly incident-report-needing.20:56
ScottKbryceh: Can you look into this oneiric-proposed regression ^^^20:56
ScottKinfinity: Usually they aren't unless they affect you.20:57
infinityScottK: Well, it looks like it might just be trading one hang for another. ;)20:57
ScottKinfinity: Someone will need to start an incident report and all that stuff too.  Can you drive?20:57
infinityScottK: I'd prefer someone closer to the issue (ie: bryceh) do the reporting.20:58
infinityHe's in a better position to tell if it's actually necessary, and what steps should be taken.20:58
infinity(And I was about to head to lunch)20:58
* ScottK is at EOD.20:58
* ScottK looks for maybe slangasek.20:58
ScottKHe should be on that alert too.20:58
infinityNormally, I probably should be too.  No idea who to talk to about mangling it.20:59
slangasekmangling what?21:00
* mneptok perks21:00
infinityEither way, I'm not sure about the severity of this one, reading through the logs.  It seems the upload solved problems for some, and possibly caused problems for others.  If removing that one patch makes it work for everyone, yay, but I don't think things are "worse" now, just "different".21:00
infinityslangasek: The regression-alert thingamajig.21:01
gang65The main problem with this bug is that two patches was pushed:21:01
slangasekoh, the bot output?  I don't know21:01
ScottKslangasek: In any case we need someone to drive this regression alert to ground and I'm EOD and infinity is just about to leave.21:02
infinitygang65: I see that.  You also reported that it worked for you, though.  Can you reproduce the hang that the other reporter is seeing?21:02
ScottKI think it's mostly hunting down Bryce and making him look at it.21:02
gang65yes I could reproduce this21:02
infinitygang65: Ahh.  The bug log isn't clear on that point.21:03
gang65And Thomas Schlichter also21:03
infinityAnyhow, I have to run out for 30 minutes.21:05
slangasekgang65: can you confirm whether or not precise is affected?21:05
scott-workcjwatson: is line #17 correct in http://paste.ubuntu.com/880708/ ?21:06
slangasekbryceh: around?  Seems to have been a regression in the recent openchrome SRU ^^21:06
scott-workshould it include a pair of parenthesi ?21:06
gang65@slangasek No. Precise is not affected (it has a new openchrome version)21:08
udevbotError: "slangasek" is not a valid command.21:08
slangasekgang65: ok, thanks21:08
Q-FUNKev: it appears that whoopsie leaves an obsolete config from early releases.21:32
broderQ-FUNK: i'm confused. i added a bluez.maintscript that should be cleaning up the conffile...21:45
Q-FUNKbroder: apparently, it doesn't work as intended.21:46
broderok, looking21:46
brycehslangasek, I'm off today.  Does it need solved now or can it wait?21:47
brycehslangasek, probably should just revert both patches to be safe21:48
slangasekbryceh: I imagine it can wait until tomorrow; the SRU was published a week ago and the regression is just now coming to light21:49
brycehslangasek, I had sru'd them under the belief that the patches were well tested and safe; since it appears that's not the case, it's not worth having as an sru21:49
slangasekbryceh: the second patch is reported to not be upstream at all, the first patch is confirmed by two users to improve things?21:50
slangasek(including the user reporting the regression)21:50
brycehslangasek, well the trouble is that VIA hardware for testing openchrome is rather rare (I haven't got any), so validating changes is especially tough21:51
slangasekit seems there are at least two users available to test, which meets the SRU criteria21:52
brycehslangasek, well I'm thinking this might be one of those self-selecting cases21:52
brycehi.e. people who have the bug test...  but if the patch breaks people that have different hardware, we won't get those test results until it goes out live21:53
brycehwhich presumably is what happened here21:53
slangasekno, gang65 who tested the SRU was also able to confirm the regression afterwards; so this particular one wasn't an issue with differing hardware21:54
slangasekthe regression was just a corner case he didn't test initially21:54
brycehhmm, ok.  does the upstream patch alone fix it?  iirc some commenters said only with both patches did the original issue go away21:55
slangasekas far as I understand the bug log, yes, the first upstream patch is sufficient21:56
slangasekactually, now I'm doubting21:57
slangaseksince the regression reported by Thomas Schlichter is simply that the original bug was not fixed21:58
brycehslangasek, see last few comments on http://www.openchrome.org/trac/ticket/40221:58
slangasekso I can't understand how gang65 both confirmed the regression, *and* correctly verified the fix in the first place21:58
brycehyeah, it's a bit confusing21:58
slangasekmuddled history, not actually a regression (just a case of the bug not really being fixed); so not urgent at all21:59
brycehslangasek, okie.  shall I still keep it on my todo list to look at tomorrow?22:00
slangasekbryceh: that would be appreciated22:01
brycehwill do.22:01
brodercyphermox: are you still possibly uploading bluez soon? i've spotted the bug in my change22:05
broder(just want to check if we're going to step on each others' toes)22:05
=== yofel_ is now known as yofel
broderQ-FUNK: spotted the bug - i screwed up the version number when i call dpkg-maintscript-helper22:06
Q-FUNKbroder: that would explain it. :)22:07
broderQ-FUNK: i had the upload prepped, and then discovered that cyphermox had already uploaded bluez, so i had to merge his changes in and forgot to update it22:08
broderso if you had upgraded from 4.98-2ubuntu1 instead...:)22:08
Q-FUNKbroder: do you actually need to specify the last applicable version though?22:08
broderQ-FUNK: it's not strictly necessary, but it makes sure that the migration code only runs once22:09
chilicuilhi there, I'm trying to test if an app is completly translated in the latest ubuntu release, I do have a chroot environment (pbuilder) with it, how can I make it?, I know that the package is not complety translated, since I've it in ubuntu oneiric, I'd like to translate what's left, I've tried to branch the lp:pkg branch with no sucess, and the lp page https://launchpad.net/ubuntu/+source/klavaro has the "translations" link grayed out22:10
dupondjeGot some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it?22:14
=== salem_ is now known as _salem
slangasekkenvandine: hi, are you planning to follow up on the farsight->farstream transition so that we're not left carrying around an obsolete source package in universe for precise?22:18
slangasekdupondje: what is it you're trying to accomplish by integrating this into the upstart jobs?  That's a high risk change that I think is clearly not appropriate for a post-FF change22:20
slangasekdupondje: all of our filesystem teardown in 12.04 is still being done via sysvinit22:20
dupondjeslangasek: now we have 4 init scripts for cryptsetup. Would like to only use upstart for it.22:21
dupondjeand not for FF btw, but for Precise+1 :)22:21
slangasekwell, we use init scripts for the teardown because we use init scripts for all the fs teardown22:22
slangasekso any changes there need to include the big picture22:22
dupondjeThats getting changed or ?22:22
slangasekthere aren't any plans about changing it yet22:22
NisstyreWhy hasn't Ubuntu added a "python2" symlink to "python" yet?22:23
dupondjeOk, cause its a bit dirty imo to have 4 scripts for 1 'service' :)22:23
dupondjeI'm thinking for some ways to make it bit cleaner22:24
slangasekNisstyre: because /usr/bin/python is already assured to be python2, so adding that symlink would just encourage creating unportable scripts22:26
Nisstyreslangasek: it would make them more portable according to pep 39422:26
jtaylorthat pep is not accepted yet22:26
Nisstyresince "python" will invoke the python 3 interpreter on some systems22:27
Nisstyrefair enough22:27
slangasekon what systems?  Any system using 'python' to refer to python 3 is horribly broken22:27
slangasekand pep 394 offers no clean upgrade path22:27
Nisstyreslangasek: Arch Linux as well as Gentoo in the future22:28
slangasekreally?  broken22:28
Nisstyreslangasek: it's not manditory that python should refer to python 222:28
NisstyreIt would be nice if there were something that could work across all major distros, such as "python2"22:29
broderNisstyre: it would be nice if distros like Arch and Gentoo didn't arbitrarily go breaking every Python script in existence22:29
infinityUntil very recently, that thing was 'python'...22:29
dupondjeslangasek: would it for example be possibel to add 'stop on runlevel [016]' to the upstart? This would emulate the same as the current init script does?22:32
slangasekdupondje: definitely not22:32
jtayloroh interesting pep 394 was accepted recently22:33
dupondjemyea no sequence number :(22:33
slangasekdupondje: right.  also, the jobs are tasks, so they're stopped as soon as they finish, so 'stop on' won't help :)22:33
dupondjeso I guess there is not really a more clean way then the current situation?22:34
slangasekdupondje: yep, not really22:35
slangaseknot without significant changes to the shutdown22:35
dupondje'to the shutdown' as in upstart you mean then?22:35
slangasekdupondje: I mean a systematic transition for /etc/rc6.d22:36
dupondjenow finding a clean way to patch this in debian :) so we can sync in the future22:37
dokoNisstyre, slangasek: "python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions". so no, it won't point to python3 in Ubuntu22:41
Nisstyredoko: Sorry if I wasn't clear. I never said Ubuntu should point python to python322:42
dupondjeanyway slangasek thanks for the info :)22:42
infinitydoko: I think that was already well-established, he was saying that we should also have python2 pointing to python2.722:42
jtaylorwhich it already does in precise btw22:42
slangasekoh, does it really?22:42
=== jbicha is now known as Guest1267
slangasekdoko: when this was discussed last on debian-python, wasn't it agreed that it was a bad idea to provide this?  Is it there now because the PEP has been approved?22:43
infinityOh, it seems upstream was changed to provide the python->python2->python2.7 link chain.22:44
jtaylorI think the opinion was its a bad idea but if the pep gets accepted it will go in22:44
infinityNisstyre: So, there you have it.  It does what you want.22:44
Nisstyreinfinity: thanks for the information then22:45
dokoslangasek, I never thought it would be a bad idea, but some people did want to have the pep formally approved22:46
slangasekdoko: right22:46
slangasekdoko: fwiw I don't think it was a good idea either, but we might as well go along with it :)22:47
broderit's good that, after the python community went through all the trouble of separating out the backwards-incompatible changes, they've decided to open the door for making a backwards-incompatible change22:48

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!