Nabble - ubuntu-devel

Re: Merging ubuntu-sru and motu-sru?

2009-12-02T22:30:40Z

On Thu, Dec 03, 2009 at 09:25:50AM +1100, William Grant wrote:
[...]
> > It would be nice if there was a 'merge teams' in LP that would
> > automatically transfer everything over. This way here ~motu-sru would
> > disappear and ~ubuntu-sru would get everything.
>
> There is, but only Launchpad admins can do it.

Well there you go, how about just doing it this way if it works as planned?

--
Name| Richard JOHNSON
Title| Developer
WWW| http://www.ubuntu.com
Email| nixternal@...
GnuPG| 3578 0981 A21D D662 2A96 7623 F4C1 838C D8C4 4738

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (852 bytes) Download Attachment

Re: Merging ubuntu-sru and motu-sru?

2009-12-02T14:25:50Z

On Wed, 2009-12-02 at 10:57 -0600, Richard JOHNSON wrote:

> On Wed, Dec 02, 2009 at 10:01:42AM +0100, Martin Pitt wrote:
> [...]
> > I propose the following:
> >
> > * Structurally, add the three ~motu-sru members (John, David, Cody)
> > to ~ubuntu-sru, remove them from ~motu-sru.
> >
> > Make ~ubuntu-sru the sole member of ~motu-sru, to retain backwards
> > compatibility wrt. existing bug subscriptions, and until folks stop
> > subscribing ~motu-sru.
>
> It would be nice if there was a 'merge teams' in LP that would
> automatically transfer everything over. This way here ~motu-sru would
> disappear and ~ubuntu-sru would get everything.

There is, but only Launchpad admins can do it.

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Merging ubuntu-sru and motu-sru?

2009-12-02T11:19:00Z

Hi Martin,

Thanks for taking the time to initiate the merge!

I think this workflow will work fine for me. In all of my experience on the motu-sru team I've never had an issue with the response time of the archive admins.

Thanks,

John

On Dec 2, 2009, at 4:01 AM, Martin Pitt wrote:

> Hello SRU teams,
>
> (CC'ing ubuntu-devel@ to archive the discussion and raise awareness of
> this matter)
>
> a while ago we already had a quick discussion about merging the two
> teams. Now that the archive reorganization has become a practical
> reality [1], I think it's time to resurrect and finish this process.
>
> Back then, the two motu-sru special cases were removed from the policy
> [2], but we still practiced the separation for recent SRUs.
>
> I propose the following:
>
> * Structurally, add the three ~motu-sru members (John, David, Cody)
> to ~ubuntu-sru, remove them from ~motu-sru.
>
> Make ~ubuntu-sru the sole member of ~motu-sru, to retain backwards
> compatibility wrt. existing bug subscriptions, and until folks stop
> subscribing ~motu-sru.
>
> * Non-archive admins amongst us (i. e. the current motu-sru members)
> still can't technically accept pending uploads, but just as now
> they can review and approve bugs, so that any archive admin can
> just go ahead and accept approved uploads. (In practice this will
> mostly be done by the archive admins which are in ~ubuntu-sru,
> though).
>
> * Every team member can approve/reject any proposed SRUs. Since
> everyone gets the bug mail, there's plenty of chance to discuss
> SRUs.
>
> * If someone doesn't feel comfortable with reviewing an upload,
> please do express your concerns in the bug (too intrusive patch,
> the aim of the change is not clear, etc.), or just leave it for
> someone else to review.
>
> How do you feel about this? Would you prefer just having one team for
> the entire archive, or envision a different structure which might work
> better?
>
> Thank you,
>
> Martin
>
> [1] https://lists.ubuntu.com/archives/ubuntu-devel/2009-November/029618.html
> [2] https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev2=137&rev1=136
> --
> Martin Pitt | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Merging ubuntu-sru and motu-sru?

2009-12-02T08:57:29Z

On Wed, Dec 02, 2009 at 10:01:42AM +0100, Martin Pitt wrote:
[...]
> I propose the following:
>
> * Structurally, add the three ~motu-sru members (John, David, Cody)
> to ~ubuntu-sru, remove them from ~motu-sru.
>
> Make ~ubuntu-sru the sole member of ~motu-sru, to retain backwards
> compatibility wrt. existing bug subscriptions, and until folks stop
> subscribing ~motu-sru.

It would be nice if there was a 'merge teams' in LP that would
automatically transfer everything over. This way here ~motu-sru would
disappear and ~ubuntu-sru would get everything.

--
Name| Richard JOHNSON
Title| Developer
WWW| http://www.ubuntu.com
Email| nixternal@...
GnuPG| 3578 0981 A21D D662 2A96 7623 F4C1 838C D8C4 4738

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (852 bytes) Download Attachment

Merging ubuntu-sru and motu-sru?

2009-12-02T01:01:42Z

Hello SRU teams,

(CC'ing ubuntu-devel@ to archive the discussion and raise awareness of
this matter)

a while ago we already had a quick discussion about merging the two
teams. Now that the archive reorganization has become a practical
reality [1], I think it's time to resurrect and finish this process.

Back then, the two motu-sru special cases were removed from the policy
[2], but we still practiced the separation for recent SRUs.

I propose the following:

* Structurally, add the three ~motu-sru members (John, David, Cody)
to ~ubuntu-sru, remove them from ~motu-sru.

Make ~ubuntu-sru the sole member of ~motu-sru, to retain backwards
compatibility wrt. existing bug subscriptions, and until folks stop
subscribing ~motu-sru.

* Non-archive admins amongst us (i. e. the current motu-sru members)
still can't technically accept pending uploads, but just as now
they can review and approve bugs, so that any archive admin can
just go ahead and accept approved uploads. (In practice this will
mostly be done by the archive admins which are in ~ubuntu-sru,
though).

* Every team member can approve/reject any proposed SRUs. Since
everyone gets the bug mail, there's plenty of chance to discuss
SRUs.

* If someone doesn't feel comfortable with reviewing an upload,
please do express your concerns in the bug (too intrusive patch,
the aim of the change is not clear, etc.), or just leave it for
someone else to review.

How do you feel about this? Would you prefer just having one team for
the entire archive, or envision a different structure which might work
better?

Thank you,

Martin

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2009-November/029618.html
[2] https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev2=137&rev1=136
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment

Re: signable 1.1 code of conduct?

2009-12-01T00:32:18Z

On Sat, Nov 28, 2009 at 2:41 AM, Michael Gilbert
<michael.s.gilbert@...> wrote:
> i would very much like to sign the ubuntu code of conduct; however,
> i will not sign version 1.0.1, which is the only one available at
> present [0]. i have signed version 1.1 [1], but when i try to
> upload it [2], launchpad says that my signed text does not match
> the code of conduct. thanks.

This is the relevant bug -
https://bugs.launchpad.net/launchpad-registry/+bug/479870

--
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Merging with Bazaar

2009-11-30T15:35:09Z

On Mon, 2009-11-09 at 14:15 +0000, Scott James Remnant wrote:

> lp:~ubuntu-core-dev/ubuntu/karmic/mountall/ubuntu
>
This should now be lp:~ubuntu-core-dev/ubuntu/lucid/mountall/lucid

> lp:~scott/+junk/ureadahead
>
This should now be lp:~ubuntu-core-dev/ubuntu/lucid/ureadahead/lucid

Scott
--
Scott James Remnant
scott@...

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment

Re: Proposing an update to the PackagingGuide

2009-11-30T14:43:50Z

On Mon, Nov 30, 2009 at 5:34 PM, James Westby <jw+debian@...> wrote:
> On Mon Nov 30 15:40:23 -0500 2009 Andrew SB wrote:

[...]

>> It hasn't been incorporated in the Packaging Guide yet, but the
>> Distributed Development documentation seems to be the most complete
>> introduction to the topic:
>>
>> https://wiki.ubuntu.com/DistributedDevelopment/Documentation

Yes. Found that one during the day, after sending the email.

>
> Yes, I've been writing that with the recommended way of doing things.
> Do you think it should be merged in to the Packaging Guide somehow now?
>

My take would be yes :)

/ Matt

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proposing an update to the PackagingGuide

2009-11-30T14:34:56Z

On Mon Nov 30 15:40:23 -0500 2009 Andrew SB wrote:
> On Mon, Nov 30, 2009 at 8:54 AM, Mathieu Trudel-Lapierre
> <mathieu.tl@...> wrote:
> > Hi,
> >
> > I've been looking for a page to roughly describe how to deal with
> > updating packages that are maintained from Bzr. I found
> > PackagingGuide/Recipes/UseBzrAndBzrBuildpackage, but noticed it was
> > fairly short and missing explanations.

Thanks, I wasn't aware of this page.

> It hasn't been incorporated in the Packaging Guide yet, but the
> Distributed Development documentation seems to be the most complete
> introduction to the topic:
>
> https://wiki.ubuntu.com/DistributedDevelopment/Documentation

Yes, I've been writing that with the recommended way of doing things.
Do you think it should be merged in to the Packaging Guide somehow now?

Thanks,

James

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

New Kubuntu Developer (kubuntu-dev): Jonathan Thomas (JontheEchidna)

2009-11-30T12:58:42Z

We're pleased to announce that we unanimously voted Jonathan Thomas
into the kubuntu-dev team.

Application: https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
Votes in Favour: Scott Kitterman, Anthony Mercatante, Harald Sitter, and
Richard Johnson.
IRC Logs are missing from http://irclogs.ubuntu.com so are attached instead.

This is the first time kubuntu-dev has met to review a prospective developer
application. This is a new team formed as part of the archive reorganisation
effort. Please see https://wiki.kubuntu.org/Kubuntu/KubuntuDevelopers for
details on the team.

Scott K
For kubuntu-dev

[15:01:33] <ScottK> #startmeeting
[15:01:35] <MootBot> Meeting started at 14:01. The chair is ScottK.
[15:01:35] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:01:52] --> nxvl_ (n=nxvl@ubuntu/member/nxvl) has joined #ubuntu-meeting
[15:02:09] <ScottK> apachelogger, Riddell, nixternal ?
[15:02:30] <apachelogger> ahoy ahoy
[15:02:50] <ScottK> OK. That's two. We need three for a quorum.
[15:03:24] --> Mamarok (i=mamarok@amarok/rokymotion/mamarok) has joined #ubuntu-meeting
[15:05:03] <nixternal> oi
[15:05:09] <ScottK> JontheEchidna are you here? That's all we need.
[15:05:12] <JontheEchidna> yay, 3
[15:05:19] <JontheEchidna> yup
[15:05:31] <ScottK> OK. It's been 5 minutes and we have a quorum, let's stary.
[15:05:44] <ScottK> JontheEchidna: Where's you're application?
[15:05:48] <JontheEchidna> https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
[15:06:02] <ScottK> [LINK] https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
[15:06:03] <MootBot> LINK received: https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
[15:06:21] <ScottK> apachelogger and nixternal: You've reviewed this, right?
[15:06:26] --> Tonio__ (n=tonio@...) has joined #ubuntu-meeting
[15:06:27] <apachelogger> aye
[15:06:31] -*- ScottK goes straight to questions ...
[15:06:33] <Tonio__> hi
[15:06:38] <JontheEchidna> o/
[15:06:44] <ScottK> Excellent. Hello Tonio_.
[15:07:03] <ScottK> Tonio_: https://wiki.kubuntu.org/JonathanThomas/KubuntuDevApplication
[15:07:44] <ScottK> JontheEchidna: If you're a kubuntu-dev, you'll have access to Kubuntu's seeds. Any thoughts on that? Have you done anything with seed changes?
[15:08:16] <JontheEchidna> I have done some work with the Kubuntu seeds. let me see if I can find the bzr branch
[15:08:36] <JontheEchidna> https://code.edge.launchpad.net/~echidnaman/ubuntu-seeds/mykubuntu
[15:08:48] <JontheEchidna> ^as part of the gtk-qt-engine -> kde-style-qtcurve transition
[15:08:55] <ScottK> [LINK] https://code.edge.launchpad.net/~echidnaman/ubuntu-seeds/mykubuntu
[15:08:56] <MootBot> LINK received: https://code.edge.launchpad.net/~echidnaman/ubuntu-seeds/mykubuntu
[15:09:28] --> lukjad007 (n=lukjadOO@unaffiliated/lukjad007) has joined #ubuntu-meeting
[15:09:34] <ScottK> OK.
[15:09:36] <nixternal> JontheEchidna: how closely are you working with Debian with the KDE packages? Are you contributing directly back to Debian in such cases?
[15:10:21] <JontheEchidna> In all honesty, working with Debian is not a strong point for me. I do, however, work with the Debian maintainer of the konq-plugins package
[15:10:39] <JontheEchidna> we subscribe to the feeds to each others' vcs-es for the packaging
[15:10:58] <ScottK> JontheEchidna: After your seed change gets applied, how to you get the metapackage change in the archive?
[15:11:47] <JontheEchidna> Hmm.. let me see if I can remember
[15:12:21] -*- Tonio_ has an improvised network meeting... grrrrrrr... brb
[15:12:27] <JontheEchidna> I know Tonio sponsored a lot of my packages during the transition
[15:12:35] --> jcastro (n=jorge@ubuntu/member/jcastro) has joined #ubuntu-meeting
[15:12:48] <ScottK> JontheEchidna: It isn't essential. If you don't know, that's fine.
[15:12:59] <JontheEchidna> Yeah, Tonio sponsored the changes I believe
[15:13:19] <ScottK> JontheEchidna: What should we be doing differently. We advertised kubunut-dev has having a voice in technical direction of Kubuntu. What would you change?
[15:13:53] <JontheEchidna> If more developers would look at the bug tracker more often, then that would be great.
[15:14:03] <JontheEchidna> Sometimes I feel that bugs fall by the wayside because nobody ever looks at them
[15:14:20] <JontheEchidna> I know we have a limited pool of resources, but it gets frustrating at times
[15:14:51] -*- ScottK nods.
[15:14:51] <rgreening> JontheEchidna: Do you have a proposal to make bug triage, solving more accessible for new entrants?
[15:14:53] <rgreening> :)
[15:15:30] <JontheEchidna> hmm
[15:15:44] <ScottK> I don't have any more questions.
[15:15:54] <JontheEchidna> well in general it's not so much the triage, but what happens (or doesn't) after that
[15:16:14] <nixternal> JontheEchidna: speaking of bugs, when you upload a new package, do you see if the new upload may close already open bugs? I think many developers not doing this, is the reason for so many stale bugs that may no longer be an issue
[15:16:40] <JontheEchidna> Yeah, as one of the primary bug triagers I keep a close eye on bugs that new uploads release
[15:17:12] <JontheEchidna> since I wear both developer and bug triager hats
[15:17:21] <nixternal> JontheEchidna: do you test every package for regressions prior to uploading? if so, what kind of process do you go through when testing?
[15:17:27] --> rafael_carreras (n=quassel@...) has joined #ubuntu-meeting
[15:18:03] <JontheEchidna> After I pbuild the package I install it to make sure it installs fine, then do simple stuff with the application
[15:18:05] -*- nixternal appologizes for not endorsing, I am bad at that for some reason
[15:18:41] <ScottK> nixternal: It's OK. There's more tension if not everyone with a vote has pre-endorsed the application.
[15:18:55] <ScottK> Tonio_ or apachelogger: Questions?
[15:18:55] <nixternal> true, that means I can play bad cop then :p
[15:19:04] <apachelogger> nothing here
[15:19:10] <Tonio_> ScottK: not for me...
[15:19:16] <ScottK> nixternal: Any more from you?
[15:19:31] <apachelogger> nixternal is bad cop so must have some more bad cop questions
[15:19:33] <apachelogger> :D
[15:19:38] <nixternal> JontheEchidna: ScottK stated in the areas of imporvement -> "As with anyone, he could sometimes stand to be a bit more careful..." what are you doing now to be more careful that you might not have previously?
[15:19:45] <nixternal> of course I always have questions
[15:20:04] <nixternal> you get good at this stuff after doing membership stuff for more than 2 years in the development arena :)
[15:20:26] <nixternal> plus dholbach and persia` aren't around, so they can't beat me to a question :)
[15:20:30] <JontheEchidna> for the example here: http://bazaar.launchpad.net/~kubuntu-members/kdelibs/ubuntu/revision/130
[15:20:35] <apachelogger> nixternal: lol
[15:20:52] <nixternal> JontheEchidna: what text editor do you use?
[15:21:01] <JontheEchidna> I could have paid more attention to what debuild was saying
[15:21:03] <nixternal> I know with vim, it will highlight mistakes like that in the changelog
[15:21:12] <JontheEchidna> nixternal: nano
[15:21:18] -*- nixternal giggles a bit
[15:21:19] <apachelogger> Oo
[15:21:26] <apachelogger> that just made me shiver
[15:21:29] <apachelogger> oh my
[15:21:29] <ScottK> You totally should not have admitted that until after we voted.
[15:21:31] <nixternal> emacs has the mistake highlighting as well
[15:21:33] <JontheEchidna> ha
[15:21:38] <nixternal> ScottK: haha, I was thinking the same exact thing
[15:21:38] -*- apachelogger needs to become bad cop now
[15:21:39] <nixternal> hahahaha
[15:21:55] -*- nixternal hands the club over to apachelogger...get to beatin'!
[15:22:05] --> gregknicholson (n=greg@...) has joined #ubuntu-meeting
[15:22:09] -*- apachelogger is not going to tell the story about MS engineer praising emacs now
[15:22:19] -*- rgreening will miss the Kubuntu icon..
[15:22:29] <apachelogger> I think we should get to a vote before everyone realises that JontheEchidna uses nano :P
[15:22:31] <ScottK> OK, any more questions before we vote?
[15:22:37] --> damagednoob (n=me@...) has joined #ubuntu-meeting
[15:22:42] <nixternal> none here
[15:22:47] <nixternal> nano here rather :p
[15:22:51] <JontheEchidna> lol
[15:22:54] -*- apachelogger actually read nano :P
[15:22:55] <ScottK> [VOTE] JontheEchidna for kubuntu-dev (please only vote if you're in kubuntu-dev)
[15:22:56] <MootBot> Please vote on: JontheEchidna for kubuntu-dev (please only vote if you're in kubuntu-dev).
[15:22:56] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot
[15:22:56] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:23:01] <nixternal> +1
[15:23:01] <MootBot> +1 received from nixternal. 1 for, 0 against. 0 have abstained. Count is now 1
[15:23:05] <ScottK> +1
[15:23:05] <apachelogger> MootBot: +1
[15:23:05] <MootBot> +1 received from ScottK. 2 for, 0 against. 0 have abstained. Count is now 2
[15:23:16] <apachelogger> +1
[15:23:16] <MootBot> +1 received from apachelogger. 3 for, 0 against. 0 have abstained. Count is now 3
[15:23:46] -*- ScottK looks at Tonio_
[15:24:27] <Tonio_> +1 :)
[15:24:27] <MootBot> +1 received from Tonio_. 4 for, 0 against. 0 have abstained. Count is now 4
[15:24:29] <Tonio_> of course
[15:24:35] <JontheEchidna> :)
[15:24:39] <ScottK> [ENDVOTE]
[15:24:40] -*- apachelogger is wondering why we vote anyway :P
[15:24:41] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[15:24:43] <nixternal> woo, congrats JontheEchidna \o/
[15:24:46] <JontheEchidna> \o/
[15:24:47] <apachelogger> congrats JontheEchidna
[15:24:49] <ScottK> JontheEchidna: Congratulations.
[15:24:50] <Mamarok> Congratulations, JontheEchidna!
[15:24:52] <JontheEchidna> Thanks
[15:24:54] <jussi01> congrats JontheEchidna
[15:24:57] <rgreening> gratz
[15:24:59] <nixternal> any other business?
[15:25:08] -*- JontheEchidna edits his next changelog in notepad.exe
[15:25:14] <nixternal> hahaha
[15:25:15] <rgreening> ouch
[15:25:22] <nixternal> vi vi vi
[15:25:23] <rgreening> wine notepad.exe
[15:25:25] <nixternal> the sign of the devil!
[15:25:31] <JontheEchidna> haha
[15:25:32] <apachelogger> JontheEchidna: that is going to get you into newline hell
[15:25:40] <JontheEchidna> I kid :P
[15:25:43] -*- apachelogger reports bug about nano
[15:25:51] <nixternal> ScottK: you gonna send out the email to all of the lists?
[15:25:55] <ScottK> [ENDMEETING]
[15:26:02] <ScottK> nixternal: Sure.
[15:26:06] <JontheEchidna> ScottK: thanks a lot for organizing everything
[15:26:17] <nixternal> kubuntu-devel, ubuntu-devel, CC, TB, with a cc: sabdfl
[15:26:18] <rgreening> thanks ScottK :)
[15:26:26] <nixternal> oh, ScottK and ubuntu-news :)
[15:26:30] <apachelogger> cookies to ScottK!
[15:26:53] -*- nixternal gets the dog from outside before it freezes
[15:27:00] <ScottK> #endmeeting
[15:27:01] <MootBot> Meeting finished at 14:26.

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment

Re: Proposing an update to the PackagingGuide

2009-11-30T12:40:23Z

On Mon, Nov 30, 2009 at 8:54 AM, Mathieu Trudel-Lapierre
<mathieu.tl@...> wrote:
> Hi,
>
> I've been looking for a page to roughly describe how to deal with
> updating packages that are maintained from Bzr. I found
> PackagingGuide/Recipes/UseBzrAndBzrBuildpackage, but noticed it was
> fairly short and missing explanations.

It hasn't been incorporated in the Packaging Guide yet, but the
Distributed Development documentation seems to be the most complete
introduction to the topic:

https://wiki.ubuntu.com/DistributedDevelopment/Documentation

- Andrew Starr-Bochicchio

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

UDS Attendees, please fill out the survey.

2009-11-30T06:54:25Z

Hi everyone,

In case you missed the announcement on Friday of UDS we would
appreciate UDS attendees (including remote participants!) to fill out
the survey so we know what to improve for next time.

http://www.surveymonkey.com/s.aspx?sm=sHeqDqNEEbQriQtuwHS_2fvA_3d_3d

--
Jorge Castro
jorge (at) ubuntu.com
External Project Developer Relations
Canonical Ltd.

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Proposing an update to the PackagingGuide

2009-11-30T05:54:45Z

Hi,

I've been looking for a page to roughly describe how to deal with
updating packages that are maintained from Bzr. I found
PackagingGuide/Recipes/UseBzrAndBzrBuildpackage, but noticed it was
fairly short and missing explanations.

I've copied it to here:
https://wiki.ubuntu.com/Mtrudel/Recipes/UseBzrAndBzrBuildpackage

And made changes following my own experience in the process in the
past few weeks. I want to update the PackagingGuide pages, but since
it's a fairly important change I thought it would be best to consult.

Is anything I wrote in there terribly wrong? :)

Mathieu Trudel
mathieu.tl@...

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Translations for the ptPT locale

2009-11-29T06:57:25Z

On Sun, 2009-11-29 at 09:42 -0500, Mike Rooney wrote:
> On Fri, Nov 27, 2009 at 5:14 AM, Henrique Rocha <hmrocha@...> wrote:

> > How can I contribute with the translations for strings that are still in
> > English?
> >
>
>
> Hi Henrique,
>
> Translations are done in Launchpad at
> http://translations.launchpad.net/ubuntu . You'll need to become a
> member of the Ubuntu Translators group to gain permissions to
> translate, perhaps by joining https://launchpad.net/~ubuntu-l10n-pt .
> Have fun and thanks for your interest in contributing to Ubuntu;
> translations are a very excellent contribution!
>

Hi Henrique,

You may also wish to join the #ubuntu-pt channel on irc.ubuntu.com. At
least some of the translators for pt-PT are usually present there.

..C..

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment

Re: Translations for the ptPT locale

2009-11-29T06:42:07Z

On Fri, Nov 27, 2009 at 5:14 AM, Henrique Rocha <hmrocha@...> wrote:

> Hi,
>
> Yesterday I installed Ubuntu 9.10 with the Portuguese (ptPT) locale because
> that's the locale that my students are using and I noticed that there are a
> lot of things left untranslated in the installation process and some minor
> translation bugs in some applications.
>
> How can I contribute with the translations for strings that are still in
> English?
>

Hi Henrique,

Translations are done in Launchpad at
http://translations.launchpad.net/ubuntu . You'll need to become a
member of the Ubuntu Translators group to gain permissions to
translate, perhaps by joining https://launchpad.net/~ubuntu-l10n-pt .
Have fun and thanks for your interest in contributing to Ubuntu;
translations are a very excellent contribution!

--
Michael Rooney
mrooney@...

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signable 1.1 code of conduct?

2009-11-27T18:41:37Z

hi,

i would very much like to sign the ubuntu code of conduct; however,
i will not sign version 1.0.1, which is the only one available at
present [0]. i have signed version 1.1 [1], but when i try to
upload it [2], launchpad says that my signed text does not match
the code of conduct. thanks.

mike

[0] https://launchpad.net/codeofconduct/
[1] http://bazaar.launchpad.net/~mako/ubuntu-codeofconduct/proposed-revision/annotate/head:/CodeOfConduct.txt
[2] https://launchpad.net/codeofconduct/1.0.1/+sign

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Translations for the ptPT locale

2009-11-27T02:14:01Z

Hi,

Yesterday I installed Ubuntu 9.10 with the Portuguese (ptPT) locale because that's the locale that my students are using and I noticed that there are a lot of things left untranslated in the installation process and some minor translation bugs in some applications.

How can I contribute with the translations for strings that are still in English?

Thanks in advance.

--
Henrique Rocha
ExpertRating Certified Unix Shell Script Professional
ExpertRating Certified Unix Professional
ExpertRating Certified Object-Oriented Concepts Professional
ExpertRating Certified HTML 4 Professional
ExpertRating Certified C Programming Professional

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

New MOTU: Evan Broder (ebroder / broder)

2009-11-26T10:06:40Z

Hello everybody,

the MOTU Council is very pleased to announce that Evan Broder just
joined the MOTU team. Among his interests are SRUs, Backports,
Sponsoring and much more.

Please give him a warm welcome to the team.

Have a great day,
Daniel

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ARM rebuild

2009-11-26T04:18:54Z

On Mon, Nov 16, 2009 at 09:21:56AM -0800, Kees Cook wrote:
> While it requires other scripts and settings from our tree, I wrote a
> tool[1] to identify source packages with ELF outputs that have been
> unchanged since a given release. It's mostly just a wrapper around
> "comm -1 -2" with lists of source package versions. (Note also that it
> currently hard-codes arch checks.)

suite-diff may also be useful for this kind of thing.

https://code.launchpad.net/~cjwatson/+junk/suite-diff

--
Colin Watson [cjwatson@...]

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ubuntu-desktop team members can now upload

2009-11-26T04:16:44Z

On Wed, Nov 25, 2009 at 11:33:43PM -0500, Scott Kitterman wrote:
> It may be I'm unclear on the concept, but it was my recollection that
> packages for each specialist team were supposed to be unique and that
> packages that landed in multiple team areas were supposed to be uploaded
> by whatever core-dev turns into?

In some cases it is appropriate to seed things somewhere core (e.g. the
desktop-common seed) when they're in an intersection. We didn't specify
a rule like that, though - it was mooted at one point but I didn't think
it was feasible to make it anything but a judgement call. That would
mean that the presence of any two flavours of Ubuntu that used the same
desktop environment would cause all of that desktop environment to land
in core.

> Looking at the intersection of the ubuntu-desktop and kubuntu sets (less
> language pack stuff that made the list even more unwieldy) I get the
> attached list of packages in both sets.
>
> First, I'd thought the intersection was supposed to be null and some of
> them seem distinctly odd (ubuntu-artwork in the kubuntu set

Some of this is due to build-dependencies (e.g. xscreensaver) and the
rest is due to the education seed which generally makes analysis
difficult. Suggestions for what to do with the latter welcome.

> and kdebindings in the ubuntu set, for example).

Bindings, and other core libraries, tend to end up all over the place.
ubiquity is core but ships binaries that depend on python-kde4.

> Is this what was intended?

I'd like to have facilities for manual overrides of some kind, but it's
a bit unwieldy while we're still manually moving stuff back and forward
between main and universe *as well*, and while those moves have to be
done using shell access on the master archive system whereas package
sets need to be manipulated using the Launchpad API and therefore on a
client system. Right now I'm just checking the package set changes every
so often by eye to make sure that specialist teams aren't gaining access
to things that I think should be in core instead. Obviously this doesn't
scale.

If overrides could be changed using the Launchpad API, then that would
help a lot because we'd be able to put all the logic in one place in
ubuntu-archive-tools and then manual overrides would be more feasible.

--
Colin Watson [cjwatson@...]

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ubuntu-desktop team members can now upload

2009-11-26T04:07:22Z

On Wed, Nov 25, 2009 at 09:50:23AM -0600, Mario Limonciello wrote:
> 1) I see a handful of packages that overlap the xubuntu package sets
> (xfce4-*). Is this how it's supposed to work?

Yes. Overlaps are OK in general if both flavours are using something; in
some cases, maybe it's appropriate for something to be seeded somewhere
more central to indicate that it's a "core" package.

> 2) Some of the core packages that would normally be uploaded by someone in
> ~mythbuntu-dev: mythtv mythplugins, and mythexport are all absent from the
> list. I'm not sure why.

mythtv, mythplugins: The relevant script wasn't looking at multiverse.
Fixed, thanks.

mythexport: If you want this, you'll need to seed it somewhere, or have
something (build-)depend on it.

--
Colin Watson [cjwatson@...]

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ubuntu-desktop team members can now upload

2009-11-25T20:33:43Z

> Hello desktoppers,

>
> (CC'ing -devel@ since it applies to ~kubuntu-dev and ~mythbuntu-dev as
> well, and is of general interest)
>
> with the ongoing archive restructuring and the TB approval of
> delegating upload privileges to https://launchpad.net/~ubuntu-desktop,
> Colin Watson now threw the switch.
>
> That means that everyone in the team can now upload packages which
> belong to the desktop package set, i. e. the usual
> GTK/GNOME/KDE/i18n bits.
>
> To get a complete list of packages, or test for a particular package,
> grab edit_acl.py from ubuntu-archive-tools [1]:
>
> $ ./edit_acl.py -s gnome-power-manager query
> == All uploaders for package 'gnome-power-manager' =Archive Upload Rights
> for ubuntu-core-dev: package set 'ubuntu-desktop' in karmic
> Archive Upload Rights for ubuntu-core-dev: package set 'unr' in karmic
> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in
> karmic
> Archive Upload Rights for ubuntu-core-dev: package set 'ubuntu-desktop' in
> lucid
> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in
> lucid
> Archive Upload Rights for ubuntu-core-dev: package set 'unr' in lucid
>
> -> ~ubuntu-desktop can upload
>
> $ ./edit_acl.py -s ubiquity query
> == All uploaders for package 'ubiquity' =Archive Upload Rights for
> ubuntu-core-dev: package set 'core' in karmic
> Archive Upload Rights for ubuntu-core-dev: package set 'core' in lucid
>
> -> ~ubuntu-desktop can't upload
>
> $ ./edit_acl.py -P ubuntu-desktop -S lucid query
> == All source packages in package set 'ubuntu-desktop' in 'lucid' =abiword
> acpica-unix
> adns
> aiksaurus
> alacarte
> [...]
>
> -> list of packages ~ubuntu-desktop can upload
>
> Martin
>
> [1]
> http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/

It may be I'm unclear on the concept, but it was my recollection that
packages for each specialist team were supposed to be unique and that
packages that landed in multiple team areas were supposed to be uploaded
by whatever core-dev turns into?

Looking at the intersection of the ubuntu-desktop and kubuntu sets (less
language pack stuff that made the list even more unwieldy) I get the
attached list of packages in both sets.

First, I'd thought the intersection was supposed to be null and some of
them seem distinctly odd (ubuntu-artwork in the kubuntu set and
kdebindings in the ubuntu set, for example).

Is this what was intended?

Scott K
adns
aiksaurus
alien
app-install-data-ubuntu
apt-xapian-index
apturl
aspell-tl
ayaspell-dic
b43-fwcutter
bbdb
bcmwl
beecrypt
bgoffice
br.ispell
brasero
cairomm
cdrdao
clientcookie
commons-httpclient
culmus
dcraw
devicekit-power
dict-foldoc
dict-gcide
dict-jargon
dict-moby-thesaurus
dict-nr
dict-ns
dict-ss
dict-st
dict-tn
dict-ts
dict-ve
dict-xh
dict-zu
dictclient
dictdlib
dnsmasq
dnspython
dsdo
dutch
dvipng
egenix-mx-base
eo-spell
espa-nol
evince
evolution
eyed3
flute-openoffice.org
fortune-mod
gconfmm2.6
gdebi
gdm
genetic
ggz-client-libs
gimp-help
gle
gmime2.4
gnome-media
gnome-pilot
gnome-python
gnome-python-desktop
gnome-session
gnome-vfsmm2.6
gob2
gst0.10-python
gtk-im-libthai
gtk2-engines-murrine
gtkhtml3.14
gtkmm2.4
gtksourceview
gtkspell
hkgerman
htmlgen
human-theme
humanity-icon-theme
hunspell-gl-es
hunspell-se
hyphen
ibus
ibus-anthy
ibus-chewing
ibus-hangul
ibus-pinyin
ibus-table
ibus-table-cangjie
ibus-table-extraphrase
ibus-table-wubi
igaelic
igerman98
iirish
im-switch
imanx
ipolish
ispell
ispell-czech
ispell-et
ispell-fo
ispell-gl
ispell-lt
ispell-uk
ispell.pt
ispellcat
jabber.py
javacc
jockey
kdebindings
konwert
latex-xft-fonts
lbdb
libao
libbase-openoffice.org
libbeagle
libchewing
libcommons-codec-java
libcommons-lang-java
libfonts-openoffice.org
libformula-openoffice.org
libgadu
libggz
libglademm2.4
libgnomecanvasmm2.6
libgnomecups
libgnomemm2.6
libgnomeprint
libgnomeprintui
libgnomeuimm2.6
libgpod
libgtop2
libhangul
libindicate
liblayout-openoffice.org
libloader-openoffice.org
libmtp
libmusicbrainz-2.1
libpst
librepository-openoffice.org
libserializer-openoffice.org
libspectre
libvformat
libvigraimpex
libwpd
libwpg
libwps
libxml-openoffice.org
libytnef
libzip
lilo
linux-wlan-ng
loudmouth
lp-solve
lyx
magyarispell
malaga
mbr
meanwhile
modemmanager
mutagen
myspell
myspell-el-gr
myspell-fa
myspell-hr
myspell-hy
myspell-ku
myspell-lv
myspell-pt-br
myspell-ro
myspell-sk
myspell-sl
myspell-sv
myspell.pt
nabi
nautilus-cd-burner
ndiswrapper
nevow
nis
norwegian
nvidia-settings
openoffice.org
openoffice.org-dictionaries
openoffice.org-en-au
openoffice.org-hyphenation
openoffice.org-hyphenation-pl
openoffice.org-l10n
openoffice.org-thesaurus-it
openoffice.org-thesaurus-pl
openthesaurus
pangomm
pax
pentaho-reporting-flow-engine-openoffice.org
pexpect
pilot-link
pptp-linux
pyao
pycurl
pyenchant
pygresql
pyogg
pyopenssl
pyorbit
python-adns
python-cddb
python-cups
python-gd
python-geoip
python-ldap
python-levenshtein
python-mysqldb
python-pam
python-pullparser
python-pylibacl
python-pyxattr
python-reportlab
python-smbc
python-unit
python-vobject
python-xmpp
pyvorbis
pyxdg
qscintilla2
redland-bindings
rpm
rus-ispell
sacjava
scowl
setserial
simpletal
sl-modem
software-properties
stlport4.6
suitesparse
suomi-malaga
swedish
system-config-printer
tex4ht
thunderbird-locales
tmispell-voikko
totem-pl-parser
translate-toolkit
ttf-alee
ttf-arabeyes
ttf-arphic-bsmi00lp
ttf-arphic-gbsn00lp
ttf-arphic-ukai
ttf-arphic-uming
ttf-farsiweb
ttf-manchufont
ttf-mgopen
ttf-nafees
ttf-sazanami
ttf-sil-abyssinica
ttf-sil-ezra
ttf-sil-padauk
ttf-sil-scheherazade
ttf-sil-yi
ttf-tmuni
ttf-unfonts
twisted
twisted-conch
twisted-lore
twisted-mail
twisted-names
twisted-news
twisted-runner
twisted-web
twisted-words
ubuntu-artwork
ubuntu-wallpapers
unattended-upgrades
unclutter
usb-creator
utidylib
uzbek-wordlist
vera
vlan
vorbisgain
wfrench
witalian
wspanish
x-kit
xapian-bindings
xcursor-themes
xfonts-mathml
xfonts-wqy
xrestop
xscreensaver
xuxen-eu-spell
yelp
--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Server Team 20091125 meeting minutes

2009-11-25T19:44:47Z

Hi,

Here are the minutes of the meeting. They can also be found online with
the irc logs here: https://wiki.ubuntu.com/MeetingLogs/Server/20091125.

==== Review ACTION from previous meeting ====

ACTION: ttx to review status of bugs 455625, 460085 and 461156 for any
missing info
ACTION: mathiaz to compile a list of easy merges for publication

==== Check blueprint status and progress for the week (mdz) ====

mdz reminded that the list of blueprints [1] is used to track plans for Lucid.
The focus is now on drafting the specifications after last week discussions at
UDS. Work items [2] should also be added to the blueprint whiteboard so that a
burn down chart can be generated during the cycle. Once the wiki page is
written and the work items have been defined the status of the blueprint
should be set to Review.

All of the blueprints should be ready for review first thing Monday morning.

[1]: https://edge.launchpad.net/ubuntu/lucid/+specs?searchtext=server-lucid-
[2]: https://wiki.ubuntu.com/WorkItemsHowto

==== Assigned and to-be-assigned bugs: http://qa.ubuntu.com/reports/team-
assigned/canonical-server-assigned-bug-tasks.html (mdz) ====

Nothing was assigned to the team. Most of the bugs seemed to be SRU-related.

==== Work items tracking (mdz) ====

mathiaz asked how to handle work items that can't be defined up-front as they
depends on completion of existing work items. mdz suggested to create work
items for each of the proposed changes. If some of them can be skipped, it's
easy to skip them later, but we don't want to forget any. The most important
thing is that the list is at approximately the right level of granularity, so
that we make steady progress through the list. Work items need to fit into a
1-2 day chunk of work.

==== Weekly SRU review (mathiaz) ====

Only the hardy nomination list had one bug to be reviewed. The last two weeks
of fixed bugs have also been reviewed for potential SRUs.

==== Spamassassin update ====

ScottK asked about the status of Spamassassin in Lucid. mathiaz replied that
Daviey had been investigating the situation with upstream. He also suggested
to define work items in the associated blueprint even if the drafter doesn't
plan to do the work. Documenting what needs to be done may help in getting
things moved forward by other people.

==== Agree on next meeting date and time ====

kirkland to discuss a new time slot with maria.

Next meeting will be on Wednesday, December 2nd at 14:00 UTC in #ubuntu-
meeting.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment

Re: ubuntu-desktop team members can now upload

2009-11-25T07:50:23Z

Hi Martin:

Thanks for the information. I've got some questions though.

On Wed, Nov 25, 2009 at 08:34, Martin Pitt <martin.pitt@...> wrote:

Hello desktoppers,

(CC'ing -devel@ since it applies to ~kubuntu-dev and ~mythbuntu-dev as
well, and is of general interest)

with the ongoing archive restructuring and the TB approval of
delegating upload privileges to https://launchpad.net/~ubuntu-desktop,
Colin Watson now threw the switch.

That means that everyone in the team can now upload packages which
belong to the desktop package set, i. e. the usual
GTK/GNOME/KDE/i18n bits.

To get a complete list of packages, or test for a particular package,
grab edit_acl.py from ubuntu-archive-tools [1]:

$ ./edit_acl.py -s gnome-power-manager query
== All uploaders for package 'gnome-power-manager' ==
Archive Upload Rights for ubuntu-core-dev: package set 'ubuntu-desktop' in karmic
Archive Upload Rights for ubuntu-core-dev: package set 'unr' in karmic
Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in karmic
Archive Upload Rights for ubuntu-core-dev: package set 'ubuntu-desktop' in lucid
Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in lucid
Archive Upload Rights for ubuntu-core-dev: package set 'unr' in lucid

-> ~ubuntu-desktop can upload

$ ./edit_acl.py -s ubiquity query
== All uploaders for package 'ubiquity' ==
Archive Upload Rights for ubuntu-core-dev: package set 'core' in karmic
Archive Upload Rights for ubuntu-core-dev: package set 'core' in lucid

-> ~ubuntu-desktop can't upload

$ ./edit_acl.py -P ubuntu-desktop -S lucid query
== All source packages in package set 'ubuntu-desktop' in 'lucid' ==
abiword
acpica-unix
adns
aiksaurus
alacarte
[...]

-> list of packages ~ubuntu-desktop can upload

Martin

[1] http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksNQF0ACgkQDecnbV4Fd/IP4QCffXuCec1KorDnnQu/EN0mJVa6
w9oAoIeDep6b02wtx3KWnMROUYvDLI5Q
=Uy2d
-----END PGP SIGNATURE-----

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

I tried to run this on the mythbuntu package set:

~/src/ubuntu-archive-tools$ ./edit_acl.py -P mythbuntu -S lucid query

== All uploaders for package set 'mythbuntu' in 'lucid' ==

Archive Upload Rights for motu: package set 'mythbuntu' in lucid

Archive Upload Rights for mythbuntu-dev: package set 'mythbuntu' in lucid

== All source packages in package set 'mythbuntu' in 'lucid' ==

a52dec

acpi

celt

crypt-ssleay

dpkg-awk

etherwake

exo

faad2

feh

giblib

glide

isdnutils

jack-audio-connection-kit

kakasi

libass

libb-keywords-perl

libclass-data-inheritable-perl

libclass-methodmaker-perl

libclass-singleton-perl

libdata-optlist-perl

libdatetime-format-strptime-perl

libdatetime-locale-perl

libdatetime-perl

libdatetime-timezone-perl

libdca

libdevel-stacktrace-perl

libdvbpsi5

libdvdnav

libdvdread

libebml

libemail-address-perl

libemail-date-format-perl

libemail-find-perl

libemail-valid-perl

libexception-class-perl

libexporter-lite-perl

libfcgi-perl

libffado

libfile-homedir-perl

libfile-slurp-perl

libfile-which-perl

libfreebob

libggi

libggimisc

libgii

libhdhomerun

libhtml-element-extended-perl

libhtml-fromtext-perl

libhtml-tableextract-perl

libhttp-cache-transparent-perl

libhttp-response-encoding-perl

libhttp-server-simple-perl

libio-socket-ssl-perl

liblingua-preferred-perl

liblivemedia

liblog-tracemessages-perl

libmatroska

libmime-lite-perl

libmime-types-perl

libmodule-build-perl

libnet-domain-tld-perl

libnet-jabber-perl

libnet-libidn-perl

libnet-ssleay-perl

libnet-xmpp-perl

libpar-dist-perl

libparams-validate-perl

libperl-critic-perl

libpod-readme-perl

libpod-spell-perl

libreadonly-perl

libreadonly-xs-perl

libregexp-common-perl

libstring-format-perl

libsub-exporter-perl

libsub-install-perl

libtar

libterm-progressbar-perl

libtest-deep-perl

libtest-harness-perl

libtest-mockobject-perl

libtest-output-perl

libtest-perl-critic-perl

libtest-taint-perl

libtest-warn-perl

libtext-kakasi-perl

libtie-cphash-perl

libtime-modules-perl

libtk-tablematrix-perl

libtree-dagnode-perl

libuniversal-can-perl

libuniversal-isa-perl

libwww-mechanize-perl

libxfce4menu

libxfce4util

libxfcegui4

libxml-libxslt-perl

libxml-stream-perl

libxml-writer-perl

linuxtv-dvb-apps

mousepad

mpeg2dec

mythbuntu-artwork-usplash

mythbuntu-common

mythbuntu-control-centre

mythbuntu-default-settings

mythbuntu-diskless

mythbuntu-gdm-theme

mythbuntu-lirc-generator

mythbuntu-live-autostart

mythbuntu-log-grabber

myththemes

pastebinit

perl-tk

perltidy

soap-lite

svgalib

tcl8.3

text-bidi

thunar

thunar-volman

twolame

vcdimager

vlc

vnc4

x264

xfce4-mixer

xfce4-panel

xfce4-session

xfce4-settings

xfce4-terminal

xfce4-utils

xfce4-volumed

xfconf

xfdesktop4

xfwm4

xfwm4-themes

xmltv

yasm

two problems.

1) I see a handful of packages that overlap the xubuntu package sets (xfce4-*). Is this how it's supposed to work?

2) Some of the core packages that would normally be uploaded by someone in ~mythbuntu-dev: mythtv mythplugins, and mythexport are all absent from the list. I'm not sure why.

--
Mario Limonciello
superm1@...
Sent from Austin, TX, United States

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

ubuntu-desktop team members can now upload

2009-11-25T06:34:05Z

Hello desktoppers,

(CC'ing -devel@ since it applies to ~kubuntu-dev and ~mythbuntu-dev as
well, and is of general interest)

with the ongoing archive restructuring and the TB approval of
delegating upload privileges to https://launchpad.net/~ubuntu-desktop,
Colin Watson now threw the switch.

That means that everyone in the team can now upload packages which
belong to the desktop package set, i. e. the usual
GTK/GNOME/KDE/i18n bits.

To get a complete list of packages, or test for a particular package,
grab edit_acl.py from ubuntu-archive-tools [1]:

$ ./edit_acl.py -s gnome-power-manager query
== All uploaders for package 'gnome-power-manager' ==
Archive Upload Rights for ubuntu-core-dev: package set 'ubuntu-desktop' in karmic
Archive Upload Rights for ubuntu-core-dev: package set 'unr' in karmic
Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in karmic
Archive Upload Rights for ubuntu-core-dev: package set 'ubuntu-desktop' in lucid
Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in lucid
Archive Upload Rights for ubuntu-core-dev: package set 'unr' in lucid

-> ~ubuntu-desktop can upload

$ ./edit_acl.py -s ubiquity query
== All uploaders for package 'ubiquity' ==
Archive Upload Rights for ubuntu-core-dev: package set 'core' in karmic
Archive Upload Rights for ubuntu-core-dev: package set 'core' in lucid

-> ~ubuntu-desktop can't upload

$ ./edit_acl.py -P ubuntu-desktop -S lucid query
== All source packages in package set 'ubuntu-desktop' in 'lucid' ==
abiword
acpica-unix
adns
aiksaurus
alacarte
[...]

-> list of packages ~ubuntu-desktop can upload

Martin

[1] http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment

Re: ARM rebuild

2009-11-25T06:08:40Z

On Wed, Nov 25, 2009 at 01:21:54PM +0000, Matt Zimmerman wrote:

> On Wed, Nov 25, 2009 at 01:32:09PM +0100, Alexander Sack wrote:
> > Right, actually during the arm rebuild session this was the outcome,
> > meaning: do in-the-archive rebuild for main and for selected universe
> > packages (and no out-of-archive test rebuild to to produce a CD image
> > from).
> >
> > Looking at the past releases we found that most of main gets rebuild
> > anyway, so current plan is to let the archive evolve as usual (by
> > merges/syncs) and at some point review what packages did not
> > automatically got rebuild and then do those those manually.
>
> This seems like a reasonable plan. At what point will the review happen?
>

I think consent was to do the review and after Debian Import Freeze
... so 11th Feb according to LucidReleaseSchedule

- Alexander

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ARM rebuild

2009-11-25T05:31:39Z

hi,
Am Mittwoch, den 25.11.2009, 13:20 +0000 schrieb Matt Zimmerman:

> On Wed, Nov 25, 2009 at 12:48:44PM +0100, Oliver Grawert wrote:
> > hi,
> > Am Mittwoch, den 25.11.2009, 11:08 +0000 schrieb Matt Zimmerman:
> > > Instead, I'm proposing:
> > >
> > > * Rebuild the packages in the archive
> > >
> > > Isn't that much simpler and more effective?
> > it definately is simpler, but with the amount of buildds we have it will
> > put us out of work for quite some time. we are lacking build hardware
> > for it to fulfill the effective part and still do our work ...
>
> I don't see why this should create a problem if the builds are spaced out
> (as I suggested) and run at a lower priority relative to the packages that
> you upload.

the prob here is the speed and amount of build machines, to my knowledge

it took up to three months to rebuild the whole of main with the buildds
we had when we started the arm port, now we have slower machines but
more of them which will roughly level out the loss off power here but
likely still generate issues to get everything done in time ...

>
> > we decided to do a test rebuild of all the libs in main for which tobin
> > davis will establish an additional automatic LSB ABI test on the build
> > machines, so we see ABI breakage induced by the toolchain switches (this
> > will give us an overview of all the libs).
> > Then, once DIF is in place we will generate a combined list of all
> > packages in main modulo the ones on the images (which are definately
> > getting uploads/rebuilds anyway) and the packages already pulled from
> > debian before DIF, so we get a list of the remaining packages that
> > havent been touched yet and will upload these manually.
>
> Yes, I'm definitely not suggesting rebuilding the things which were already
> rebuilt in the normal course of development. Only the ones which aren't
> otherwise touched.

right, thats why we wait until DIF to have a proper overview ...

ciao
oli

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment

Re: apport integration into postinst scripts

2009-11-25T05:24:07Z

On Wed, Nov 25, 2009 at 02:05:37PM +0100, Reinhard Tartler wrote:
> Matt Zimmerman <mdz@...> writes:
>
> > If there is some common hook already for emacs packages, you could probably
> > do better.
>
> No, there is no such hook (yet). I don't see how an hook could help with
> this particular case.

For example, if all emacsen invoked the same script to byte-compile the
modules, you could add the error handler to that script instead of waiting
for the postinst to fail.

--
- mdz

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ARM rebuild

2009-11-25T05:22:47Z

On Wed, Nov 25, 2009 at 01:51:25PM +0100, Martin Pitt wrote:

> Matt Zimmerman [2009-11-25 11:08 +0000]:
> > If I understand correctly, you're suggesting:
> >
> > * Test rebuild the archive
> > * Save the packages
> > * Build a CD from those packages
> > * Test the CD
> >
> > Instead, I'm proposing:
> >
> > * Rebuild the packages in the archive
> >
> > Isn't that much simpler and more effective?
>
> It doesn't seem to be simpler to me. We already have working
> infrastructure to test-rebuild the archive, and building a CD from
> this archive shouldn't be rocket science. Testing the CD needs to
> happen in either case.

We are already building CDs every day from the main archive, and they will
already be tested. Building and testing separate CDs is double work, and I
don't see the benefit.

> OTOH, rebuilding the packages in the actual archive will take lots of
> sourceful manual uploads, and also blocks production buildds for quite
> a while. (Of course both points could be addressed with Soyuz/buildd
> management improvements, but we don't have those yet.)

Re-scoring builds is already possible today, and by spacing out the uploads,
the impact should be minimal.

--
- mdz

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ARM rebuild

2009-11-25T05:21:54Z

On Wed, Nov 25, 2009 at 01:32:09PM +0100, Alexander Sack wrote:
> Right, actually during the arm rebuild session this was the outcome,
> meaning: do in-the-archive rebuild for main and for selected universe
> packages (and no out-of-archive test rebuild to to produce a CD image
> from).
>
> Looking at the past releases we found that most of main gets rebuild
> anyway, so current plan is to let the archive evolve as usual (by
> merges/syncs) and at some point review what packages did not
> automatically got rebuild and then do those those manually.

This seems like a reasonable plan. At what point will the review happen?

--
- mdz

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ARM rebuild

2009-11-25T05:20:50Z

On Wed, Nov 25, 2009 at 12:48:44PM +0100, Oliver Grawert wrote:

> hi,
> Am Mittwoch, den 25.11.2009, 11:08 +0000 schrieb Matt Zimmerman:
> > Instead, I'm proposing:
> >
> > * Rebuild the packages in the archive
> >
> > Isn't that much simpler and more effective?
> it definately is simpler, but with the amount of buildds we have it will
> put us out of work for quite some time. we are lacking build hardware
> for it to fulfill the effective part and still do our work ...

I don't see why this should create a problem if the builds are spaced out
(as I suggested) and run at a lower priority relative to the packages that
you upload.

> we decided to do a test rebuild of all the libs in main for which tobin
> davis will establish an additional automatic LSB ABI test on the build
> machines, so we see ABI breakage induced by the toolchain switches (this
> will give us an overview of all the libs).
> Then, once DIF is in place we will generate a combined list of all
> packages in main modulo the ones on the images (which are definately
> getting uploads/rebuilds anyway) and the packages already pulled from
> debian before DIF, so we get a list of the remaining packages that
> havent been touched yet and will upload these manually.

Yes, I'm definitely not suggesting rebuilding the things which were already
rebuilt in the normal course of development. Only the ones which aren't
otherwise touched.

--
- mdz

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: apport integration into postinst scripts

2009-11-25T05:05:37Z

Matt Zimmerman <mdz@...> writes:

> On Wed, Nov 18, 2009 at 04:37:50PM +0100, Reinhard Tartler wrote:
>> Matt Zimmerman <mdz@...> writes:
>>
>> > I suggest looking at the existing scripts in /usr/share/apport which create
>> > problem reports in response to various error events.
>>
>> Ok, it seems that currently the best way would be to change
>> /usr/share/apport/general-hooks/ubuntu.py, since apport (currently) does
>> not seem to provide better integration for postinst failiures. That file
>> contains special handling for grub, grub2, initramfs, and kernel
>> packages, so I guess adding emacsen to that list is the way to go.
>
> The logic for maintainer script failures in ubuntu.py tries to guess the
> right package where apt gets it wrong, e.g. when the kernel postinst fails
> because of grub2. If that's analogous to the issue with emacsen (e.g. an
> elisp package causing some other package's postinst to fail), then you could
> do the same thing. It's a bit of a hack, though, as it parses through the
> log to try to figure out what happened.

Yes, this is about exactly the situation. emacsen need to byte-compile
all installed add-on packages. This recompilation happens from emacsen's
postinst script, but the fix needs to happen in the add-on package.

> If there is some common hook already for emacs packages, you could probably
> do better.

No, there is no such hook (yet). I don't see how an hook could help with
this particular case.

> Does that make sense?

It does, thanks!

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ARM rebuild

2009-11-25T04:51:25Z

Matt Zimmerman [2009-11-25 11:08 +0000]:

> If I understand correctly, you're suggesting:
>
> * Test rebuild the archive
> * Save the packages
> * Build a CD from those packages
> * Test the CD
>
> Instead, I'm proposing:
>
> * Rebuild the packages in the archive
>
> Isn't that much simpler and more effective?

It doesn't seem to be simpler to me. We already have working
infrastructure to test-rebuild the archive, and building a CD from
this archive shouldn't be rocket science. Testing the CD needs to
happen in either case.

OTOH, rebuilding the packages in the actual archive will take lots of
sourceful manual uploads, and also blocks production buildds for quite
a while. (Of course both points could be addressed with Soyuz/buildd
management improvements, but we don't have those yet.)

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ARM rebuild

2009-11-25T04:32:09Z

On Wed, Nov 25, 2009 at 11:08:12AM +0000, Matt Zimmerman wrote:

> On Wed, Nov 18, 2009 at 04:10:57PM -0600, Matthias Klose wrote:
> > On 18.11.2009 08:58, Matt Zimmerman wrote:
> > > On Mon, Nov 16, 2009 at 10:42:34AM -0600, Steve Langasek wrote:
> > >> On Sat, Nov 14, 2009 at 12:52:58PM -0600, Matt Zimmerman wrote:
> > >>>> We should be a little careful about how we phrase our commitment here.
> > >>>> As yet, we don't have the capability to do binary-only rebuilds on a
> > >>>> single architecture, so the only way to rebuild all armel binaries would
> > >>>> be to reupload every source package in the archive. This is a pretty
> > >>>> good way to lose Ubuntu mirrors, and in the past we've decided that we
> > >>>> didn't want to do that after all.
> > >>
> > >>>> I think it should be adequate to identify a core set of packages and
> > >>>> ensure that all of those get rebuilt, either during the initial merge
> > >>>> from Debian or separately.
> > >>
> > >>> I realize we've been conservative about this in the past, and for good
> > >>> reason, but I think there are risks to this approach as well. Unless we
> > >>> rebuild everything, we don't know if it builds and works with the new
> > >>> compilation defaults.
> > >>
> > >> If this is the main concern, then I think we're much better served by an
> > >> archive test rebuild that uses its own output, since this lets us rebuild
> > >> everything without a need for per-package human intervention. To do a full
> > >> archive rebuild, someone will have to do a sourceful upload of each package,
> > >> which I don't think makes sense if the goal is only to test the toolchain
> > >> changes.
> > >
> > > A test rebuild, as I understand it has been done in the past, will not tell
> > > us whether the software works, only whether it builds. Testing the
> > > toolchain requires functionally testing its output as well, not just the
> > > toolchain itself, no?
> >
> > except for packages where a testsuite is run during the package build. but yes,
> > it would be good to keep the packages built and build a CD from these packages
> > and test this one as well.
>
> If I understand correctly, you're suggesting:
>
> * Test rebuild the archive
> * Save the packages
> * Build a CD from those packages
> * Test the CD
>
> Instead, I'm proposing:
>
> * Rebuild the packages in the archive
>
> Isn't that much simpler and more effective?
>

Right, actually during the arm rebuild session this was the outcome,
meaning: do in-the-archive rebuild for main and for selected universe
packages (and no out-of-archive test rebuild to to produce a CD image
from).

Looking at the past releases we found that most of main gets rebuild
anyway, so current plan is to let the archive evolve as usual (by
merges/syncs) and at some point review what packages did not
automatically got rebuild and then do those those manually.

- Alexander

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ARM rebuild

2009-11-25T03:48:44Z

hi,
Am Mittwoch, den 25.11.2009, 11:08 +0000 schrieb Matt Zimmerman:
> Instead, I'm proposing:
>
> * Rebuild the packages in the archive
>
> Isn't that much simpler and more effective?
it definately is simpler, but with the amount of buildds we have it will
put us out of work for quite some time. we are lacking build hardware
for it to fulfill the effective part and still do our work ...

we decided to do a test rebuild of all the libs in main for which tobin
davis will establish an additional automatic LSB ABI test on the build
machines, so we see ABI breakage induced by the toolchain switches (this
will give us an overview of all the libs).
Then, once DIF is in place we will generate a combined list of all
packages in main modulo the ones on the images (which are definately
getting uploads/rebuilds anyway) and the packages already pulled from
debian before DIF, so we get a list of the remaining packages that
havent been touched yet and will upload these manually.

ciao
oli

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (204 bytes) Download Attachment