Till Kamppeter joined the MOTU team

[Daniel Holbach]

Hello everybody,

I'm please to let you know that Till Kamppeter, our printing guru joined
the MOTU team!

Please give him a warm welcome to the team! 

Have a nice day,
 Daniel



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

Re: kde4 package conflict

[Sarah Hobbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

PPA's are not done by MOTU.  Reporting bugs from packages here, from
ppa's is useless.

This is also already known.

Hobbsee

Saurabh Asthana wrote:
> Yo,
> 
> While trying to install your package kdebase-runtime-bin-kde4 from
> http://ppa.launchpad.net/kubuntu-members-kde4/ubuntu, I got this
> error:
> dpkg: error processing
> /var/cache/apt/archives/kdebase-runtime-bin-kde4_4%3a3.97.0-1ubuntu3~gutsy1~ppa2_all.deb
> (--unpack):
>  trying to overwrite `/usr/bin/kwriteconfig', which is also in package
> kdebase-bin
> Seems an obvious error.
> 
> Saurabh
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHX4UH7/o1b30rzoURAj52AJoDM1aVU58FEcdarJ8AWGlxoP3mZACg0OCI
1kMkcx6dv4/rtI0bjApimDI=
=fU+Y
-END PGP SIGNATURE-

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

kde4 package conflict

[Saurabh Asthana]

Yo,

While trying to install your package kdebase-runtime-bin-kde4 from
http://ppa.launchpad.net/kubuntu-members-kde4/ubuntu, I got this
error:
dpkg: error processing
/var/cache/apt/archives/kdebase-runtime-bin-kde4_4%3a3.97.0-1ubuntu3~gutsy1~ppa2_all.deb
(--unpack):
 trying to overwrite `/usr/bin/kwriteconfig', which is also in package
kdebase-bin
Seems an obvious error.

Saurabh

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

Re: What DIF means to Universe (was: Impending Debian import freeze)

[Emmet Hikory]

On Wed, Dec 12, 2007 at 12:56:22AM +0900, I wrote:
> 1)  Go visit MoM, DaD, or multidistrotools, and merge everything by
> Wednesday night/  Don't worry if it doesn't have your name on it: at
> this point any merge is fair game.  Further, if you were waiting for a
> sync, now is the time to push the merge in: there's no more wait
> needed.

On Dec 12, 2007 1:00 AM, Scott Kitterman wrote:
> I would add that if stuff should not be merged from some reason, it'd be very
> good to note that in the comments field on DaD so others will know.

On Dec 12, 2007 9:59 AM, Steve Langasek wrote:
> This sounds like a reasonable policy to me for packages which have not yet
> been merged in hardy (which is what the deadline is actually for - initial
> merges), but I also don't presume to speak authoritatively here; as Scott
> mentions, there may be reasons for not merging a particular package, and I
> don't want to be blamed for encouraging people to merge recklessly. :-)

I'd agree with both of you on this.  My apologies if my message
failed to indicate that due care should be taken to not merge things
that shouldn't be merged, or that people should not continue to
coordinate merges as a team.

On Dec 12, 2007 9:59 AM, Steve Langasek wrote:
> On Wed, Dec 12, 2007 at 12:56:22AM +0900, Emmet Hikory wrote:
> > Further, if you were waiting for a sync, now is the time to push the merge
> > in: there's no more wait needed.
>
> I'm not sure I understand what you mean here.  By "waiting for a sync" do
> you mean "waiting for the archive admins to sync a package", or "waiting for
> the Debian package to be in a state that's syncable"?  If the latter, I
> agree completely.  If you mean the former, I would hope that's not an issue,
> and if it is please let me know so that we can address that.

Entirely the latter.  Prior to DIF, it is common practice to work
with Debian to try to get the package in an identical state for both
distributions.  Once the autosync ends, this is still a useful goal,
but I don't believe it should be a blocker for uploads to hardy any
longer.  The former seems well handled by the rotating sync processing
days.

> > 2)  After this point, merges may still be done, but should only be
> > done when the Debian change is explicitly desireable for inclusion in
> > hardy (e.g. "Contains feature foo which integrates better with the
> > default installation", or "Fixes bug bar which annoys a bunch of
> > people" or "The assigned merger didn't merge by the deadline, and we
> > want the new updates" (the last of these should be done in the next
> > week or two)).  Merges that change binary package names or otherwise
> > cause transitions should be avoided, and anyone contemplating such a
> > merge becomes responsible for coordinating updates to all the rdepends
> > (this typically requires a truly significant feature or important bug)
>
> I think this is a bit more conservative than necessary.  The aim of the DIF,
> as I understand it, is to make sure we don't find ourselves with packages
> getting merged right before FeatureFreeze for the first time in the release
> cycle, bringing in six months worth of Debian changes when we're supposed to
> be stabilizing.  As long as the bulk of these changes have been merged in
> advance of the DIF, I don't think the justification for an "updated merge"
> needs to be particularly elaborate.

Again, apologies for any confusion: I hadn't meant it to be
particularly conservative, just that we should focus on features and
bugfixes desired for hardy, rather than chasing every Debian update.
I'd consider "a member of ~ubuntu-dev thinks it's a good idea"
sufficient justification until feature freeze, and encourage the
adoption of any Debian bugfix uploads, which means that members of
~ubuntu-dev should feel no obligation to restrict processing.  For
those not members of ~ubuntu-dev, it's worth writing up two or three
reasons why the merge or sync is useful for hardy, just to ease
sponsorship.

-- 
Emmet HIKORY

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

Re: What DIF means to Universe (was: Impending Debian import freeze)

[Steve Langasek]

Hi Emmet,

On Wed, Dec 12, 2007 at 12:56:22AM +0900, Emmet Hikory wrote:
> On Dec 11, 2007 7:53 PM, Steve Langasek wrote:
> > Just a brief note to remind you all that the DebianImportFreeze[1] for Hardy
> > is two days away[2].  This is the deadline for initial merges of packages
> > for Hardy; after Thursday, December 13, merging packages is a freeze
> > exception, so please have your remaining merges for hardy finished before
> > this point.

> As this message has resulted in some confusion in #ubuntu-motu,

Ack, sorry for this; the message was drafted somewhat quickly with the
intention of giving people a reminder with as much lead time as possible,
but at the expense of clarity.

To clarify now: this wasn't meant to be taken as any sort of policy change,
just a reminder of the impending deadline.

> I've drafted the following guidelines on what DebianImportFreeze means
> for Universe.  I'm not speaking authoritatively, and would welcome
> correction if I am mistaken.

> 1)  Go visit MoM, DaD, or multidistrotools, and merge everything by
> Wednesday night/  Don't worry if it doesn't have your name on it: at
> this point any merge is fair game.

This sounds like a reasonable policy to me for packages which have not yet
been merged in hardy (which is what the deadline is actually for - initial
merges), but I also don't presume to speak authoritatively here; as Scott
mentions, there may be reasons for not merging a particular package, and I
don't want to be blamed for encouraging people to merge recklessly. :-)

> Further, if you were waiting for a sync, now is the time to push the merge
> in: there's no more wait needed.

I'm not sure I understand what you mean here.  By "waiting for a sync" do
you mean "waiting for the archive admins to sync a package", or "waiting for
the Debian package to be in a state that's syncable"?  If the latter, I
agree completely.  If you mean the former, I would hope that's not an issue,
and if it is please let me know so that we can address that.

> 2)  After this point, merges may still be done, but should only be
> done when the Debian change is explicitly desireable for inclusion in
> hardy (e.g. "Contains feature foo which integrates better with the
> default installation", or "Fixes bug bar which annoys a bunch of
> people" or "The assigned merger didn't merge by the deadline, and we
> want the new updates" (the last of these should be done in the next
> week or two)).  Merges that change binary package names or otherwise
> cause transitions should be avoided, and anyone contemplating such a
> merge becomes responsible for coordinating updates to all the rdepends
> (this typically requires a truly significant feature or important bug)

I think this is a bit more conservative than necessary.  The aim of the DIF,
as I understand it, is to make sure we don't find ourselves with packages
getting merged right before FeatureFreeze for the first time in the release
cycle, bringing in six months worth of Debian changes when we're supposed to
be stabilizing.  As long as the bulk of these changes have been merged in
advance of the DIF, I don't think the justification for an "updated merge"
needs to be particularly elaborate.

I do agree with you that mergers need to take responsibility for any
transitions they cause after this point, and that any exceptions for the DIF
should be made sooner rather than later.

> 3) The Universe DIF Freeze exception process works as follows:
> A: Document why the package should be merged (bugs are good for this)
> B: Determine the rdepends, and plan any required transition (avoid these)
> C: Get a member of ~ubuntu-dev (possibly including yourself) to agree
> D: Upload all affected packages (should be less than 10) (may
> include sync requests)

All of the above sounds perfectly reasonable to me.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]

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

Re: What DIF means to Universe (was: Impending Debian import freeze)

[Scott Kitterman]

On Tuesday 11 December 2007 10:56, Emmet Hikory wrote:
> On Dec 11, 2007 7:53 PM, Steve Langasek wrote:

> 1)  Go visit MoM, DaD, or multidistrotools, and merge everything by
> Wednesday night/  Don't worry if it doesn't have your name on it: at
> this point any merge is fair game.  Further, if you were waiting for a
> sync, now is the time to push the merge in: there's no more wait
> needed.

I would add that if stuff should not be merged from some reason, it'd be very 
good to note that in the comments field on DaD so others will know.

Scott K

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

What DIF means to Universe (was: Impending Debian import freeze)

[Emmet Hikory]

On Dec 11, 2007 7:53 PM, Steve Langasek wrote:
> Just a brief note to remind you all that the DebianImportFreeze[1] for Hardy
> is two days away[2].  This is the deadline for initial merges of packages
> for Hardy; after Thursday, December 13, merging packages is a freeze
> exception, so please have your remaining merges for hardy finished before
> this point.

As this message has resulted in some confusion in #ubuntu-motu,
I've drafted the following guidelines on what DebianImportFreeze means
for Universe.  I'm not speaking authoritatively, and would welcome
correction if I am mistaken.

1)  Go visit MoM, DaD, or multidistrotools, and merge everything by
Wednesday night/  Don't worry if it doesn't have your name on it: at
this point any merge is fair game.  Further, if you were waiting for a
sync, now is the time to push the merge in: there's no more wait
needed.

2)  After this point, merges may still be done, but should only be
done when the Debian change is explicitly desireable for inclusion in
hardy (e.g. "Contains feature foo which integrates better with the
default installation", or "Fixes bug bar which annoys a bunch of
people" or "The assigned merger didn't merge by the deadline, and we
want the new updates" (the last of these should be done in the next
week or two)).  Merges that change binary package names or otherwise
cause transitions should be avoided, and anyone contemplating such a
merge becomes responsible for coordinating updates to all the rdepends
(this typically requires a truly significant feature or important bug)

3) The Universe DIF Freeze exception process works as follows:
A: Document why the package should be merged (bugs are good for this)
B: Determine the rdepends, and plan any required transition (avoid these)
C: Get a member of ~ubuntu-dev (possibly including yourself) to agree
D: Upload all affected packages (should be less than 10) (may
include sync requests)

Note that the above is based on my understanding of best practices
from previous release cycles, and does not represent an official
statement of MOTU policy.  Please feel free to disagree if you know
better, or add to a MOTU Meeting Agenda if an official statement is
required.

-- 
Emmet HIKORY

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

Re: ~motu-sru team

[Scott Kitterman]

On Tuesday 11 December 2007 03:57, Daniel Holbach wrote:
> Hello Scott,
...
> > I'd also like to see such decisions taken transparently in a public
> > forum.
>
> What I personally want to avoid is to have public discussions about the
> merits of volunteers as they rarely do good. Giving input and sharing
> concerns is all fine and important (also a demonstration of how much you
> care about MOTU), but discussing the qualities (or lack thereof)
> of people who volunteer to do good work is likely to put people off.
>
> > I'm not a fan of secret decision making in FOSS projects.
>
> This makes it look much worse than it actually is.
>
I'm not sure how.

The MC took volunteers and made a decision without there being any publich 
record of it.  While I don't think there was any problem with the result in 
this case, I think that is pretty close to the dictionary defintion of 
secret.

I agree that there is a risk of alienating people when you discuss the merits 
and demerits of people in public, but you have to balance that against the 
benifits of openness. 

I believe that, in the long run, while there will be some negatives, the 
benifits of an open and transparent community management process are 
substantial and will definitely outweight those negatives.

Scott K

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

Re: general discussion about social conflicts (was: Request for MOTU Council to consider Marco Rodrigues (Kmos) not potentially suitable for MOTU)

[Stefan Potyra]

Hi,

(in response to: 
, 
CC-ing ubuntu-motu, as I guess we should continue with the general discussion 
there).

Am Dienstag, 11. Dezember 2007 12:23 schrieb Daniel Holbach:
[..]
>
> After commenting on all the points of your proposal, I'd like to add a
> few thoughts of my own. Your initial mail was a good attempt at trying
> to address all the problems around Marco. While this is important, I
> think it's even more important to have the general discussion.
>
> Which problems did we face programmatically? What can we do to fix them?
>
> Problems I can identify are:
>   * confusion of who's responsible for dealing with the problems
>   * lack of integration of Kmos in the team (I'd have expected Kmos
> to ask for more advice)
>   * much earlier escalation to the MC

* proactive reaction from MC at that time

I guess I'm guilty there too, having been a MC member at the time when the 
conflict first arose. Sorry!

* policy for conflict resolution

With this, I don't think of a policy document describing the exact details of 
how a conflict should get resolved, but rather to have some outline what 
measures can be taken: E.g. first actions could include mediation attempts 
but it should also be clear what last resort actions can be taken, in case 
every other attempt fails.

>   * 

Cheers,
   Stefan.


pgpjZlKH5ABQe.pgp
Description: PGP signature
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Shared library link problem when building debs

[Jules Colding]

On Tue, 2007-12-11 at 10:16 +0100, Jules Colding wrote:
> How do I make the Ubuntu package build system create this link in
> "/usr/lib/" without doing it manually in the Makefile?

Never mind - Mea Culpa.

Best regards,
  jules



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

Shared library link problem when building debs

[Jules Colding]

Hi,

Sorry for cross posting, but I wasn't aware that this was the correct
list until a few minutes ago.

With that out of the way...


I'm building debs for a simple keyring daemon for which you can get the
source here:

http://svn.42tools.net/repos/brutus-keyring/trunk/


My problem is related to the automatic creation of symbolic links in
"/usr/lib/" when installing. 

On all other platforms I see at least these files in "/usr/lib" after a
successful installation:

lrwxrwxrwx 1 root root30 2007-10-12 10:04 /usr/lib/libBrutusKeyringd-1.0.so 
-> libBrutusKeyringd-1.0.so.1.0.0
lrwxrwxrwx 1 root root30 2007-10-12 10:04 
/usr/lib/libBrutusKeyringd-1.0.so.1 -> libBrutusKeyringd-1.0.so.1.0.0
-rw-r--r-- 1 root root 32061 2007-10-12 10:04 
/usr/lib/libBrutusKeyringd-1.0.so.1.0.0


But on Ubuntu I only see:

lrwxrwxrwx 1 root root   30 2007-12-10 12:52 
/usr/lib/libBrutusKeyringd-1.0.so.1 -> libBrutusKeyringd-1.0.so.1.0.0
-rw-r--r-- 1 root root 6340 2007-12-10 12:48 
/usr/lib/libBrutusKeyringd-1.0.so.1.0.0


You can see that the "libBrutusKeyringd-1.0.so" symbolic link is
missing. This give rise to problems as applications want to do
"-lBrutusKeyringd-1.0" when linking. 

How do I make the Ubuntu package build system create this link in
"/usr/lib/" without doing it manually in the Makefile?

Thanks a lot,
  jules



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

Re: ~motu-sru team

[Daniel Holbach]

Hello Scott,

On Mo, 2007-12-10 at 12:45 -0500, Scott Kitterman wrote:
> I would have preferred (and did expect) someone from the MC to write the list 
> and say something along the lines of:
> 
> Here are the people who've volunteered...
> 
> We'll be taking a decision on date X.  Please let us know on the list (or in 
> private if needed) any comments you might have.

I agree that a timely action plan for such votes is needed. For the next
voting process we should have defined time-spans for nominations,
general input and coming to a final decision.


> I'd also like to see such decisions taken transparently in a public forum.  

What I personally want to avoid is to have public discussions about the
merits of volunteers as they rarely do good. Giving input and sharing
concerns is all fine and important (also a demonstration of how much you
care about MOTU), but discussing the qualities (or lack thereof)
of people who volunteer to do good work is likely to put people off.


> I'm not a fan of secret decision making in FOSS projects.

This makes it look much worse than it actually is. 

Have a nice day,
 Daniel



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