Re: Is Ubuntu a debian derivative or is it a fork?

[mag]

2005-05-31, k keltezéssel 16.24-kor John Hasler ezt írta:
> Steve writes:
> > The Unix world was badly hurt by deliberate code forking during the 80s.
> > Those of us who lived through it are scared of a repeat.
> 
> I don't believe that a Free Software fork can cause such damage. 

Forks in OSS do have drawbacks, this is why they are generally frowned
upon. Of course there are cases when advantages greater than drawbacks,
esp. when the latter are minimized, e.g. by submitting back patches.
Taxonomists may argue that such forks has to be called spoons;)
Other taxonomist may also argue that Debian is an infrastructural
distribution, which is well suited to be the base of such "spoons".

Re: Is Ubuntu a debian derivative or is it a fork?

[mag]

2005-05-31, k keltezéssel 21.00-kor John Goerzen ezt írta:
> > Other taxonomist may also argue that Debian is an infrastructural
> > distribution, which is well suited to be the base of such "spoons".
> 
> Perhaps, but there are some issues with that.
> 
> In the ubuntu case in particular, I wish that they would be more
> proactive in sending their patches to the Debian maintainers. 

> Sometimes they are changing things for some unique "ubuntu way". 

Okay, these were the problems.

And here is a good part of the solution:

> Finally, I would like to see many more developers putting their
> packages a distributed version control system like Arch or, better
> yet, Darcs.  


If everyone in the food chain, at least down from the debian maintainer,
would use that, it would greatly simplify problems with patch
management. Just I highly doubt it is doable.

It could also help to apply upper stream patches for spoons while
sticking to their spoonerisms ;), and even not giving them back in
patches again and again.

I guess that we, as Debian developers have no ground to criticise
downstream for doing things in their own way, provided they don't keep
pushing things deemed unacceptable.

It is another thing that I also used to be nervous to an other Debian
spoon;) when my friends ask for help, and I face its own little ugly
ways like completely changed init, or postinst scripts made completely
unintelligible...

proper way to generate shlibs.local?

[(mag)]

Hi!

There are several binary packages are created out of the zorp source.
Some of them depends on libzorp2, generated from there as well.
Because of that I need a shlibs.local file to tell dh_slibdeps
about the versioned dependency. I am creating it from the
shlibs file created dh_makeshlibs, thus:

dh_makeshlibs -n
dh_makeshlibs -plibzorp2 -V
dh_installdeb -a
find debian/ -name shlibs |xargs cat >debian/shlibs.local
dh_shlibdeps -a -l`pwd`/debian/libzorp2/usr/lib

Questions:
1. do I need the shlibs.local file, is not, what to do?
2. is the above the Right Way, or is there a More Right Way?

Thank you for your advice.

Assurance measures: ACM

[(mag)]

Hi!

Sorry for starting with the more boring part. Here is a short overview
of the assurance requirements of Common Criteria, and how they
are covered by Debian (in parenthesis).

This overview is made for the Adamantix developers, but might be
interesting for debian developers also.

This part covers ACM (configuration management). Debian is
really outstanding in this area. Watch out for further issues:)

ACM_AUT.2 Complete CM automation (appears at EAL6, which is a very high
assurance level. Haven't heard about a product above EAL4)
ACM_AUT.2.1D The developer shall use a CM system.
(This is the source repository and the build daemons.
To cover all requirements, a gnu arch or cvs repository
for the sources should be set up.)
ACM_AUT.2.2D The developer shall provide a CM plan.
(This is in the policy manual. Nicely fine grained.)
ACM_AUT.2.1C  The CM system shall provide an automated means by which
only authorised changes are made to the TOE implementation
representation, and to all other configuration items.
(This is made by signing the changes file, and by the
ftpadmin approval).
ACM_AUT.2.2C  The CM system shall provide an automated means to support
the generation of the TOE.
(Build daemons)
ACM_AUT.2.3C  The CM plan shall describe the automated tools used in the
CM system.
(Developers reference)
ACM_AUT.2.4C  The CM plan shall describe how the automated tools are
used in the CM system.
(Developers reference)
ACM_AUT.2.5C  The CM system shall provide an automated means to
ascertain the changes between the TOE and its preceding version.
('tla what-changed' or 'cvs diff')
ACM_AUT.2.6C  The CM system shall provide an automated means to identify
all other configuration items that are affected by the
modification of a given configuration item.
(looking up reverse dependencies)

ACM_CAP.5 Advanced support (appears at EAL6)
(If ACM_CAP.5 seems to be too strong, ACM_CAP.4 is the same but without
13C-21C, and appears at EAL4)
ACM_CAP.5.1D The developer shall provide a reference for the TOE.
(version numbers of packages)
ACM_CAP.5.2D The developer shall use a CM system.
(This is the source repository and the build daemons.
To cover all requirements, a gnu arch or cvs repository
for the sources should be set up.)
ACM_CAP.5.3D The developer shall provide CM documentation.
(policy manual, developers reference)
ACM_CAP.5.1C The reference for the TOE shall be unique to each version
of the TOE.
(Yes, each version have a different version number:)
ACM_CAP.5.2C The TOE shall be labelled with its reference.
(each package have its version number both in the file name
and in the control file)
ACM_CAP.5.3C  The CM documentation shall include a configuration list, a
CM plan, an acceptance plan, and integration procedures.
The configuration list shall uniquely identify all
configuration items that comprise the TOE.
(The CM plan, acceptance plan and integration procedures
are described in the policy manual and the developers
reference. The configuration list (dpkg -l) indeed lists
all configuration items (packages) with version number.)
ACM_CAP.5.4C  The configuration list shall describe the configuration
items that comprise the TOE.
(apt-cache show does just that)
ACM_CAP.5.5C  The CM documentation shall describe the method used to
uniquely identify the configuration items.
(Maybe the apt and/or dpkg man page is also part of the CM
documentation)
ACM_CAP.5.6C  The CM system shall uniquely identify all configuration
items.
(name, version)
ACM_CAP.5.7C  The CM plan shall describe how the CM system is used.
(the docs are good)
ACM_CAP.5.8C  The evidence shall demonstrate that the CM system is
operating in accordance with the CM plan.
(debian/changelog, build daemon logs, etc. There might be minor
issues with it, but not much.)
ACM_CAP.5.9C  The CM documentation shall provide evidence that all
configuration items have been and are being effectively
maintained under the CM system.
(see above)
ACM_CAP.5.10C The CM system shall provide measures such that only
authorised changes are made to the configuration items.
(The debian keyring and the ftpmaster)
ACM_CAP.5.11C The CM system shall support the generation of the TOE.
(Build daemons)
ACM_CAP.5.12C The acceptance plan shall describe the procedures used to
accept modified or newly created configuration items as part of
the TOE.
(policy manual)
ACM_CAP.5.13C The integration procedures shall describe how the CM
system is applied in the TOE manufacturing process.
(policy manual. unstable, testing, stable, proposed-updates,
etc)

ACM

Assurance measures: AGD (that fabulous manual we like to have but hate to write)

[(mag)]

Hi!


AGD_ADM.1 Administrator guidance (all EALs)

AGD_ADM.1.1D   The developer shall provide administrator guidance
addressed to system administrative personnel.
(This is man 8, and the various administrators' guides
and HOWTOs. We do have it in most cases. Thanks to the
LDP project and the numerous people who have written it.)
AGD_ADM.1.1C The administrator guidance shall describe the
administrative functions and interfaces available to the
administrator of the TOE.
(It works in most cases. The GNU coding standards mandate
that even the --help option should do its essentials.)
AGD_ADM.1.2C The administrator guidance shall describe how to administer
the TOE in a secure manner.
(Well, there docs where you can find warnings about security,
and unfortunately there are the ones which describe insecure
practices.)
AGD_ADM.1.3C The administrator guidance shall contain warnings about
functions and privileges that should be controlled in a secure
processing environment.
(See above)
AGD_ADM.1.4C The administrator guidance shall describe all assumptions
regarding user behaviour that are relevant to secure operation
of the TOE.
(These assumptions are not made explicit in a lot of cases,
and because that they do not get into the admin guide.)
AGD_ADM.1.5C The administrator guidance shall describe all security
parameters under the control of the administrator,
indicating secure values as appropriate.
(Where we have admin guide, the parameters are described
in most cases, but there are indication only in a few
spots.)
AGD_ADM.1.6C The administrator guidance shall describe each type of
security-relevant event relative to the administrative
functions that need to be performed, including changing the
security characteristics of entities under the control of the
TSF.
(It is also a grey spot in a lot of cases.)
AGD_ADM.1.7C The administrator guidance shall be consistent with all
other documentation supplied for evaluation.
(Well, being up-to-date is a great challenge with free
software. From that perspectiveit works with a surprisingly
high percentage of packages.)
AGD_ADM.1.8C The administrator guidance shall describe all security
requirements for the IT environment that are relevant to the
administrator.
(It is nearly the same case as the assumptions about user
behaviour.)

AGD_USR.1 User guidance (all EALs)

AGD_USR.1.1D   The developer shall provide user guidance.
(manpages, user guides, howtos. See AGD_ADM.1.1D)
AGD_USR.1.1C   The user guidance shall describe the functions and
interfaces available to the non-administrative users of the TOE.
(It exists in most cases. See AGD_ADM.1.1C)
AGD_USR.1.2C   The user guidance shall describe the use of
user-accessible security functions provided by the TOE.
(It is okay more often than not.)
AGD_USR.1.3C   The user guidance shall contain warnings about
user-accessible functions and privileges that should be
controlled in a secure processing environment.
(Well, sometimes they do, sometimes don't.)
AGD_USR.1.4C The user guidance shall clearly present all user
responsibilities necessary for secure operation of the TOE,
including those related to assumptions regarding user behaviour
found in the statement of TOE security environment.
(I guess that there are only a few cases where these
statements exists, and only a bit more where the
responsibilities are described.)
AGD_USR.1.5C The user guidance shall be consistent with all other
documentation supplied for evaluation.
(See AGD_ADM.1.7C)
AGD_USR.1.6C The user guidance shall describe all security requirements
for the IT environment that are relevant to the user.
(See AGD_ADM.1.8C)

MAG CITY Townhouses MEYDAN MBR City District-7

[MAG CITY]

If you have trouble viewing this email, read the online version.
[http://app.marketing.magpd.com/e/es.aspx?s=984077094&e=10008&elq=3d9b18686de64df583394a4d2d64fc31]
 



   

EXPRESS YOUR INTEREST 

  


   

800MAG(624) 


WWW.MAGCITY.AE 



   


   


To unsubscribe from future emails or to update your email preferences, please 
cut and paste this link into the browser. 
[http://app.marketing.magpd.com/e/u.aspx?s=984077094&elq=3d9b18686de64df583394a4d2d64fc31]

Your Company Name
Your Company Address
Your Company City and State
Your Company Postal Code/Zip Code
Your Company Phone

Privacy Policy
[LINK TO CLIENT PRIVACY POLICY GOES HERE]