Re: buildd stuff

[Bastian Blank]

On Mon, Jan 29, 2007 at 11:04:12AM +0100, Aurelien Jarno wrote:
> You think wrong. Using the public ldap database, you can find the
> following details:

This access is only usable for people which have login access to
ftp-master (or where the info currently is located).

Even if I'm included into wb-m68k, I can't use this access since the
machine was restricted as I don't operate a m68k buildd currently.

Bastian

-- 
Fascinating is a word I use for the unexpected.
-- Spock, "The Squire of Gothos", stardate 2124.5


signature.asc
Description: Digital signature

Re: source code "forensic" practices

[Florian Weimer]

* Yaroslav Halchenko:

> The question is: are there any helper tools for doing source code
> validation subject to possibly available snippets of code which might be
> for illegal activity (ie sending out private information, or serve as
> backdoors, etc)?

There are several commercial bug finding tools and services.  I don't
know how good they are at detecting logic bombs and similar things.

> May be some language specific tools (JS, Java, python)
> which could catch snippets intended for data transmission/receival? 

Java is doable at least, but due to their dynamic nature, JavaScript
and Python are in a completely different league.  JavaScript is
extremely obnoxious because you can easily download scripts from the
Net, triggered from self-modifying code.  In fact, this is a common
practice in the online advertising world.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd stuff

[Goswin von Brederlow]

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow a écrit :
>> Aurelien Jarno <[EMAIL PROTECTED]> writes:
>> 
>>> One first step would be to keep the current build daemons maintainers
>>> (ie the person who signs the upload), and give and access to some
>>> porters to the wanna-build database. This way they could reschedule
>>> failed builds, add dep-wait, or do binNMU. If I am right Steve Langasek
>>> already has access to the wanna-build database of all architectures, so
>>> that should not be a technical problem.
>> 
>> I think from a technical point every buildd admin has access to
>> wanna-build for all architectures. It is just policy not to mess
>> around in someone elses backyard.
>
> You think wrong. Using the public ldap database, you can find the
> following details:
>
> wb-alpha: ajt, rmurray, troup, vorlon
> wb-arm: ajt, rmurray, troup, vorlon
> wb-hppa: ajt, bdale, rmurray, stephen, taggart, tausq, troup, vorlon, willy
> wb-hurd-i386: ajt, jbailey, rmurray
> wb-i386: ajt, rmurray, troup, vorlon
> wb-ia64: ajt, bdale, dsp, koala, rmurray, stephen, taggart, tausq,
> troup, vorlon, willy
> wb-m68k: adconrad, ajt, branden, cts, rmurray, roman, schmitz, smarenka,
> troup, vorlon, waldi, wouter, younie
> wb-mips: ajt, rmurray, vorlon
> wb-ppc: ajt, daenzer, dan, michaelw, rmurray, schmitz, smarenka, troup,
> vorlon
> wb-s390: ajt, cowboy, gt, jr, rmurray, sgybas, vorlon, waldi
> wb-sparc: ajt, bcollins, jbailey, rmurray, troup, vorlon
>
> There is no wb-amd64 nor wb-mipsel. I don't know why.

Iirc amd64 reuses i386 because something run out of groups. And I
guess mipsel is included in mips.

And does w-b actualy enforce this? Are the databases actualy only
readable for the right groups?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to maintain packaging files for multiple distributions in the same tree?

[Goswin von Brederlow]

Loïc Minier <[EMAIL PROTECTED]> writes:

> On Mon, Jan 29, 2007, Goswin von Brederlow wrote:
>> In Ubuntu you have a parallel version. You split of from the main
>> trunk but you follow parallel to it at a small distance. For every new
>> main version you want a new ubuntu version. Ubuntu versions aren't a
>> branch but rather a filter on top of the main release. The main
>> release changes, the filter remains constant (hopefully).
>> 
>> Branches don't work so well for ubuntu as you have to pull over the
>> changes from the main branch to the ubuntu branch on every
>> release. Which means (unneccessary) work.
>
>  Are you comparing in the general case of packages in Debian and in
>  Ubuntu?

No, just comparing tracking stable releases against parallel
developement in multiple distributions. What I said for
stable/testing/unstable works for sarge/etch/sid just as well as for
badger/bzreeze/whatever-ubuntus-crawler-of-the-day-is-called.

>  I think it's possible to manage software with a trunk for development
>  and regular "snapshots" of this trunk for either a Debian/unstable or
>  an Ubuntu upload or both.
>
>  (I agree on what you said for uploads to testing or stable.)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Suggesting new method to handle dpkg diversions

[Ian Jackson]

Goswin von Brederlow writes ("Suggesting new method to handle dpkg diversions"):
> What if each package could list all its current diversions in
> DEBIAN/diverions (i.e. in the control.tar.gz)?

This is in principle a good idea.  It does need thinking about quite
carefully to make sure everything happens just in the right order,
even when errors occur.

> I think most diversions could be handled this way simplifying the
> maintainer scripts and removing the risk of screwing it up. Dpkg would
> take care to install/update/remove diversions in the right order and
> packages could not leave old diversions behind by mistake.

Indeed.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to maintain packaging files for multiple distributions in the same tree?

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> On Mon, Jan 29, 2007 at 10:20:23AM +0100, Goswin von Brederlow wrote:
>> In stable/testing/unstable you have releases with a fixed version that
>> can only split of from the main trunk. Any change to stable/testing
>> MUST be made special for the old version in stable/testing and forks
>> off the main developement on its own course. There is no developement
>> going on in stable/testing, just bugfixes. You often have to prepare
>> backports for patches from unstable to share fixes.
>> 
>> In Ubuntu you have a parallel version. You split of from the main
>> trunk but you follow parallel to it at a small distance. For every new
>> main version you want a new ubuntu version. Ubuntu versions aren't a
>> branch but rather a filter on top of the main release. The main
>> release changes, the filter remains constant (hopefully).
>
> The meaning of your "filter" analogy above isn't clear to me.  By "Ubuntu
> versions" do you mean "releases of Ubuntu" or "Ubuntu versions of packages
> derived from Debian"?

In this example it would be an Ubuntu package derived from Debian. Say
yu have package debmirror and you change the examples in the manpage
from the debian url to the ubuntu url for the mirror to use. On every
new debmirror debian release you want to do the exact same changes
again for the ubuntu release.

Release branch:

---+-+- sid
   |s|e
   |a|t
   |r|c
   |g|h
   |e

Distribution filter: (with patches going both ways)

+--+--+--+--- Debian
 \  \/\
  +--+--+--+- Ubuntu

>> Branches don't work so well for ubuntu as you have to pull over the
>> changes from the main branch to the ubuntu branch on every
>> release. Which means (unneccessary) work.
>
> It is work, yes, but in many cases it is necessary, and we do quite a bit of
> it at present.

Hopefully the graphic above makes it clear why a branch isn't the most
helpfull construct for it. Unfortunately I know of no RCS that has
something better for this kind of parallel developement.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: x86 buildd for experimental ?

[Goswin von Brederlow]

Loïc Minier <[EMAIL PROTECTED]> writes:

> On Mon, Jan 29, 2007, Goswin von Brederlow wrote:
>> I think that is a shortcomming of apt though.
>> apt-get install foo=1.2-3
>> will fetch foo 1.2-3 from whatever repository that has that
>> version. But with
>> Package: foo
>> Version: 1.2-3
>> Depends: bar (= 1.2-3)
>> apt-get will NOT fetch bar 1.2-3 unless it happens to have the highest
>> pin and highest version by chance.
>
>  You mean a shortcoming of apt-get?  I think aptitude manages this more
>  naturally.

If it really does then we could use aptitude in sbuild. If you have
the time please do try.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: update on binary upload restrictions

[Goswin von Brederlow]

Steffen Moeller <[EMAIL PROTECTED]> writes:

> On Monday 29 January 2007 10:42:25 Goswin von Brederlow wrote:
>> Santiago Vila <[EMAIL PROTECTED]> writes:
>> > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote:
>> >> If we do go to source-only uploads, could this problem be avoided by
>> >> having arm and other slow arches wait until at least one other arch
>> >> successfully builds the package?
>> >
>> > I think that would be a good idea anyway, even if we do not go to
>> > source-only uploads. There is no point in wasting expensive CPU cycles
>> > to build a package if it FTBFS on every architecture.
>>
>> I would rather do the opposite. Stop building a package when it fails
>> on other archs. Thing about the (unlikely) situation that arm is
>> idle. Nothing to build. Now someone uploads foobar. Should we wait or
>> just try? If it works we saved time. If it fails only idleing is lost.
>>
>>
>> Even better would be to take the number of architectures
>> failed/succeeded/needs-build into account when deciding on the
>> priority of a package. The more archs fail the lower a source drops in
>> needs-build, the more succeed the higher it rises. The more backlog a
>> port has the more successfull this priority would be, i.e. it works
>> best for the problematic archs that need it.
>
> We need to distinguish between the multiple reasons for potential failures, 
> though. I do not know about the latest developments of the build daemon, so 
> maybe my example is now outdated, but a failure because of missing build 
> dependencies should not be punished since the package may be fine per se. 
> Problems with available memory, disk space etc would fall under the same 
> category. 
>
> Steffen

Wanna-build gets (some of) the Build-Depends automatically set and the
package remains in Dep-Wait till they are available. There is also a
difference between a maybe-failed buildd log and the actual admin
setting the package to failed after checking. So "failed" has 2 levels
of certainty.

If the amount of failures is used as priority then even some wrong
results would only delay a package but not totaly stop it from being
build. There would be some (unjust) delay in a few cases but I highly
doubt anyone would mind much. The current system is much worse and
there hasn't been a GR about it yet.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: prospect of non-US?

[Goswin von Brederlow]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Jan 29, Josip Rodin <[EMAIL PROTECTED]> wrote:
>
>> What is the current prospect for the non-US archive?
> It has been dead for a long time and apparently there are no plans to
> resurrect it.
>
> -- 
> ciao,
> Marco

Wasn't it officialy put to rest years ago? The archive signature has been
expired a long time ago (was it after 2003?) and has never been
renewed. With etch apt you can't even use it even if you try.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mirror of archive maintenance scripts

[Florian Weimer]

* Anthony Towns:

> On Sun, Jan 28, 2007 at 10:57:51AM +0100, Florian Weimer wrote:
>> Is their a developer-accessible mirror (on a non-restricted host) of
>> the archive maintenance which are in production, including (most of)
>> the configuration?
>> There used to be a mirror on merkel.debian.org, but it's no longer
>> current.
>
> It is now; the katie -> dak rename broke it.

Uhm, it seems that it's still lacking James' recent changes.  Are you
sure the mirror is working?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: x86 buildd for experimental ?

[Roger Leigh]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Loïc Minier <[EMAIL PROTECTED]> writes:
>
>> On Mon, Jan 29, 2007, Goswin von Brederlow wrote:
>>> I think that is a shortcomming of apt though.
>>> apt-get install foo=1.2-3
>>> will fetch foo 1.2-3 from whatever repository that has that
>>> version. But with
>>> Package: foo
>>> Version: 1.2-3
>>> Depends: bar (= 1.2-3)
>>> apt-get will NOT fetch bar 1.2-3 unless it happens to have the highest
>>> pin and highest version by chance.
>>
>>  You mean a shortcoming of apt-get?  I think aptitude manages this more
>>  naturally.
>
> If it really does then we could use aptitude in sbuild. If you have
> the time please do try.

Alternatively, how much of the apt-get logic lives in libapt?  We
could just use libapt directly.

(This might involve rewriting sbuild in C++; this is a possibility
I've been considering for several years, but not yet got around
to--writing schroot was the first step of that plan.)


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpig4A8MtDrk.pgp
Description: PGP signature

Re: How to maintain packaging files for multiple distributions in the same tree?

[Roger Leigh]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Release branch:
>
> ---+-+- sid
>|s|e
>|a|t
>|r|c
>|g|h
>|e
>
> Distribution filter: (with patches going both ways)
>
> +--+--+--+--- Debian
>  \  \/\
>   +--+--+--+- Ubuntu
>
>>> Branches don't work so well for ubuntu as you have to pull over the
>>> changes from the main branch to the ubuntu branch on every
>>> release. Which means (unneccessary) work.
>>
>> It is work, yes, but in many cases it is necessary, and we do quite a bit of
>> it at present.
>
> Hopefully the graphic above makes it clear why a branch isn't the most
> helpfull construct for it. Unfortunately I know of no RCS that has
> something better for this kind of parallel developement.

tla star-merge ?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpUwTBEFV0r2.pgp
Description: PGP signature

Re: source code "forensic" practices

[Yaroslav Halchenko]

> * Yaroslav Halchenko:

> > The question is: are there any helper tools for doing source code
> > validation subject to possibly available snippets of code which might be
> > for illegal activity (ie sending out private information, or serve as
> > backdoors, etc)?

> There are several commercial bug finding tools and services.  I don't
> know how good they are at detecting logic bombs and similar things.
some googling helped me to find some interesting pieces

from 1995: MCF: A Malicious Code Filter
http://seclab.cs.ucdavis.edu/papers/llo95.ps

Unfortunately articles such as "Detecting and Removing Malicious Code"
http://www.securityfocus.com/infocus/1610
do not list about any source code analysis.

This one
http://www.dsv.su.se/research/seclab/pages/pdf-files/2005-x-208.pdf
seems to be quite nice but talks about MS Access source code analysis
but it referred me to another interesting reading

Secure Software Development and Code Analysis Tools
http://www.sans.org/reading_room/whitepapers/securecode/389.php

Unfortunately I have to agree with

When a programmer intends to cause harm developing software, he will try to 
obfuscate
the code to hide it in many line codes. There are even automated tools that any
programmer could use to obfuscate code (they can also be used to avoid reverse
engineering). Essentially, when an auditor finds code with non-sense structures 
or that is
particularly difficult to follow it could point him to two different 
conclusions, first, that
the programmer intends to obfuscate the code, or second, that the system wasn't 
properly
programmed, since it not only makes security analysis complex, but maintenance 
as well.
Many times we hear that so many tools have been developed and the complexity of
choosing the right one makes it even harder to effectively protect an 
information
technology environment. Ashyby's law on requisite variety, "variety kills 
variety"
(referenced by Louise Yngstr�m in [LY03]) is in my opinion a realistic approach 
to
security in today's environment. We can not today, and probably never will, 
rely on a
silver bullet tool that will resolve all our security issues. This is due to 
the high level of
complexity we are facing; therefore we need several tools that can cope with 
several
different and specific problems.

Just wanted to share and see if there is any opinion/ideas on how to
give at least some assurance that the software which we package is safe
to use. Most of the time we are to rely on how obvious is a good intent
of the upstream authors from our subjective judgment.

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]

Re: How to maintain packaging files for multiple distributions in the same tree?

[Yaroslav Halchenko]

> Hopefully the graphic above makes it clear why a branch isn't the most
> helpfull construct for it. Unfortunately I know of no RCS that has
> something better for this kind of parallel developement.
svk has nice ability to perform 'tag-less' merges.
I am yet to discover proper structuring for svn-buildpackage to contain
multiple trunks for different releases. Probably I would need to branch
at top level, ie to have projectname{,.sarge,.etch}/{trunk,branches,...}


-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to maintain packaging files for multiple distributions in the same tree?

[Robert Collins]

On Tue, 2007-01-30 at 15:23 +, Roger Leigh wrote:

> >>> Branches don't work so well for ubuntu as you have to pull over the
> >>> changes from the main branch to the ubuntu branch on every
> >>> release. Which means (unneccessary) work.
> >>
> >> It is work, yes, but in many cases it is necessary, and we do quite a bit 
> >> of
> >> it at present.
> >
> > Hopefully the graphic above makes it clear why a branch isn't the most
> > helpfull construct for it. Unfortunately I know of no RCS that has
> > something better for this kind of parallel developement.
> 
> tla star-merge ?

or just about any recent VCS to be honest.
bzr merge handles back and forth work like this trivially.

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

iFatti.com - mailing list del 30/01/2007

[newsletter]

  
Newsletter del: 30/01/2007   Informazioni
Annulla
Registrazione
Flash news
Pubblicità

  

ECCO LE NOTIZIE DE "IFATTI" CHE ASSOLUTAMENTE NON DOVEVATE PERDERE.


Vignetta

Triangoli di fatto...

http://www.ifatti.com


Pacs, Barbato: «L'Udeur non voterà il ddl sulle unioni di fatto
eterosessuali e non, libertà di coscienza» 
Grillini (Ds): «Omofobia della gerachia vaticana che pretende di dettare
l'agenda politica del Governo» 

Roma (Antonio Di Filippo) - Il clima è quello dei Mondiali di Calcio.
Non si parla d'altro in questi giorni. Pacs, Pacs, Pacs. La contesa
(mezza intesa) è tra la Chiesa di Roma e le Istituzioni italiane. 
http://www.ifatti.com/articolo.asp?ID_ARTICOLO=800
 


Alitalia, ecco gli undici potenziali acquirenti 
Privatization of Alitalia: 11 indications of interest received 

Roma (Redazione) - Il ministero dell'Economia e delle Finanze comunica
di aver ricevuto 11 manifestazioni di interesse all'acquisto di una
quota non inferiore al 30,1% del capitale di Alitalia e della totalità
delle obbligazioni convertibili Alitalia detenute dal Ministero stesso,
secondo quanto indicato nell'invito pubblicato lo scorso 29 dicembre. 
http://www.ifatti.com/articolo.asp?ID_ARTICOLO=794

Agguato contro i Rom, donna uccisa al Villaggio di via degli Stadi 
Salvi gli altri familiari, si pensa a vendetta tra zingari per traffico
di droga 

Cosenza (Giovanni Maiolo) - Nella loro lingua il termine "Rom" significa
"essere umano". Ma qualcuno ieri pomeriggio, al villaggio Rom di via
degli Stadi a Cosenza, un ghetto pieno di sporcizia e carcasse di auto,
non ha avuto alcun rispetto della vita umana. 
http://www.ifatti.com/articolo.asp?ID_ARTICOLO=799
 


Nel "cuore" degli italiani il Monastero di Clausura di San Giacomo
Veglia e il Parco della Rocca Borromea 
Fai e Intesa Sanpaolo raccolgono desideri, emozioni e sentimenti di
120mila connazionali 

Roma (Antonio Di Filippo) - Al primo posto il Brolo del Monastero di San
Giacomo di Veglia, Vittorio Veneto; al secondo posto il Parco della
Rocca Borromea, Arona; al terzo posto il Lago Azzurro a Campodolcino. 
http://www.ifatti.com/articolo.asp?ID_ARTICOLO=795
 



  _  


Segnala ad un amico la newsletter
  

Invia la newsletter ad un amico  

  _  

iFatti.com
è un'agenzia giornalistica d'informazione per la stampa e per le
emittenti radiotelevisive di Edizioni Senzaprezzo S.r.l.
registrata presso il tribunale di Napoli al numero 26 in data 17 marzo
2006.

  _  

Pubblicità
Vuoi pubblicizzare i prodotti o i servizi offerti dalla tua azienda
sulle nostre Newsletter? Per contattarci clicca qui
  

  _  

Sulla tutela della Privacy
Ai sensi del Decr.Lgs 196/2003 la informiamo che i dati in nostro
possesso vengono impiegati coi principali scopi di indagini di mercato e
nelle modalità previste dallo stesso, prevalentemente con mezzi
informatici. Potranno altresì venire impiegati per l'inoltro di riviste,
o di proposte commerciali, relative a società del gruppo. È in ogni caso
fatto diritto dell'interessato esercitare i propri diritti, nei modi
previsti dal "Titolo II art. 7" della legge sopra citata, inviando una
e-mail a [EMAIL PROTECTED], telefonando allo 08119312361 o scrivendo
al Titolare del trattamento presso Edizioni Senzaprezzo S.r.l. Leggi
l'Informativa sulla Privacy. 

  _  

Disclaimer
Quanto sopra e' espressione del mittente.
Edizioni Senzaprezzo S.r.l. non si fa carico di omissioni o errori
dovuti alla trasmissione via Internet. Le informazioni contenute nel
presente messaggio sono destinate esclusivamente al/ai destinatario/i in
esso indicato/i. Qualora riceviate il presente messaggio per errore, vi
preghiamo di voler cortesemente darcene notizia via e-mail a
[EMAIL PROTECTED] e di provvedere ad eliminare il messaggio ricevuto
erroneamente, essendo ogni utilizzo, divulgazione, distribuzione o copia
dello stesso vietata dalla Legge. 

  _  

Supplemento a iFatti.com, quotidiano distribuito via Internet.
Registrazione tribunale di Napoli n.° 26 del 17/03/2006 

 

  _  


   Se vuoi cancellare il tuo indirizzo di posta elettronica e non
ricevere più informazioni di questo tipo clicca qui
 

iFatti.com - mailing list del 30/01/2007

[newsletter]

  
Newsletter del: 30/01/2007   Informazioni
Annulla
Registrazione
Flash news
Pubblicità

  

ECCO LE NOTIZIE DE "IFATTI" CHE ASSOLUTAMENTE NON DOVEVATE PERDERE.


Vignetta

Triangoli di fatto...

http://www.ifatti.com


Pacs, Barbato: «L'Udeur non voterà il ddl sulle unioni di fatto
eterosessuali e non, libertà di coscienza» 
Grillini (Ds): «Omofobia della gerachia vaticana che pretende di dettare
l'agenda politica del Governo» 

Roma (Antonio Di Filippo) - Il clima è quello dei Mondiali di Calcio.
Non si parla d'altro in questi giorni. Pacs, Pacs, Pacs. La contesa
(mezza intesa) è tra la Chiesa di Roma e le Istituzioni italiane. 
http://www.ifatti.com/articolo.asp?ID_ARTICOLO=800
 


Alitalia, ecco gli undici potenziali acquirenti 
Privatization of Alitalia: 11 indications of interest received 

Roma (Redazione) - Il ministero dell'Economia e delle Finanze comunica
di aver ricevuto 11 manifestazioni di interesse all'acquisto di una
quota non inferiore al 30,1% del capitale di Alitalia e della totalità
delle obbligazioni convertibili Alitalia detenute dal Ministero stesso,
secondo quanto indicato nell'invito pubblicato lo scorso 29 dicembre. 
http://www.ifatti.com/articolo.asp?ID_ARTICOLO=794

Agguato contro i Rom, donna uccisa al Villaggio di via degli Stadi 
Salvi gli altri familiari, si pensa a vendetta tra zingari per traffico
di droga 

Cosenza (Giovanni Maiolo) - Nella loro lingua il termine "Rom" significa
"essere umano". Ma qualcuno ieri pomeriggio, al villaggio Rom di via
degli Stadi a Cosenza, un ghetto pieno di sporcizia e carcasse di auto,
non ha avuto alcun rispetto della vita umana. 
http://www.ifatti.com/articolo.asp?ID_ARTICOLO=799
 


Nel "cuore" degli italiani il Monastero di Clausura di San Giacomo
Veglia e il Parco della Rocca Borromea 
Fai e Intesa Sanpaolo raccolgono desideri, emozioni e sentimenti di
120mila connazionali 

Roma (Antonio Di Filippo) - Al primo posto il Brolo del Monastero di San
Giacomo di Veglia, Vittorio Veneto; al secondo posto il Parco della
Rocca Borromea, Arona; al terzo posto il Lago Azzurro a Campodolcino. 
http://www.ifatti.com/articolo.asp?ID_ARTICOLO=795
 



  _  


Segnala ad un amico la newsletter
  

Invia la newsletter ad un amico  

  _  

iFatti.com
è un'agenzia giornalistica d'informazione per la stampa e per le
emittenti radiotelevisive di Edizioni Senzaprezzo S.r.l.
registrata presso il tribunale di Napoli al numero 26 in data 17 marzo
2006.

  _  

Pubblicità
Vuoi pubblicizzare i prodotti o i servizi offerti dalla tua azienda
sulle nostre Newsletter? Per contattarci clicca qui
  

  _  

Sulla tutela della Privacy
Ai sensi del Decr.Lgs 196/2003 la informiamo che i dati in nostro
possesso vengono impiegati coi principali scopi di indagini di mercato e
nelle modalità previste dallo stesso, prevalentemente con mezzi
informatici. Potranno altresì venire impiegati per l'inoltro di riviste,
o di proposte commerciali, relative a società del gruppo. È in ogni caso
fatto diritto dell'interessato esercitare i propri diritti, nei modi
previsti dal "Titolo II art. 7" della legge sopra citata, inviando una
e-mail a [EMAIL PROTECTED], telefonando allo 08119312361 o scrivendo
al Titolare del trattamento presso Edizioni Senzaprezzo S.r.l. Leggi
l'Informativa sulla Privacy. 

  _  

Disclaimer
Quanto sopra e' espressione del mittente.
Edizioni Senzaprezzo S.r.l. non si fa carico di omissioni o errori
dovuti alla trasmissione via Internet. Le informazioni contenute nel
presente messaggio sono destinate esclusivamente al/ai destinatario/i in
esso indicato/i. Qualora riceviate il presente messaggio per errore, vi
preghiamo di voler cortesemente darcene notizia via e-mail a
[EMAIL PROTECTED] e di provvedere ad eliminare il messaggio ricevuto
erroneamente, essendo ogni utilizzo, divulgazione, distribuzione o copia
dello stesso vietata dalla Legge. 

  _  

Supplemento a iFatti.com, quotidiano distribuito via Internet.
Registrazione tribunale di Napoli n.° 26 del 17/03/2006 

 

  _  


   Se vuoi cancellare il tuo indirizzo di posta elettronica e non
ricevere più informazioni di questo tipo clicca qui
 

Re: How to maintain packaging files for multiple distributions in the same tree?

[Matt Zimmerman]

On Tue, Jan 30, 2007 at 03:07:27PM +0100, Goswin von Brederlow wrote:
> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Jan 29, 2007 at 10:20:23AM +0100, Goswin von Brederlow wrote:
> >> In Ubuntu you have a parallel version. You split of from the main
> >> trunk but you follow parallel to it at a small distance. For every new
> >> main version you want a new ubuntu version. Ubuntu versions aren't a
> >> branch but rather a filter on top of the main release. The main
> >> release changes, the filter remains constant (hopefully).
> >
> > The meaning of your "filter" analogy above isn't clear to me.  By "Ubuntu
> > versions" do you mean "releases of Ubuntu" or "Ubuntu versions of packages
> > derived from Debian"?
> [...]
> Distribution filter: (with patches going both ways)
> 
> +--+--+--+--- Debian
>  \  \/\
>   +--+--+--+- Ubuntu

What you have described is a branch, in revision control terminology.

> > It is work, yes, but in many cases it is necessary, and we do quite a bit of
> > it at present.
> 
> Hopefully the graphic above makes it clear why a branch isn't the most
> helpfull construct for it. Unfortunately I know of no RCS that has
> something better for this kind of parallel developement.

This is a fundamental feature of Bazaar and other modern distributed RCS.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: update on binary upload restrictions

[Tim Cutts]

On 25 Jan 2007, at 1:23 am, James Troup wrote:


 (a) we don't currently have the buildd infrastructure for this - it
 would require a minimum of 2 (preferably 3) machines dedicated to
 being i386 buildds.  It would also make i386 uploads much more
 sensitive to delays and really require better coverage than one
 human could provide.


Sanger could easily host at least one of these, in addition to the  
new alpha buildd we host.  We have reserved 6 IP addresses in the  
firewall zone that goetz.debian.org sits in, so we can host another 5  
machines for whatever purpose the Debian Admins would like.  We have  
lots of bandwidth, and management buy-in to us hosting this stuff is  
strong (after all, we use Debian on thousands of machines here, so  
it's in our interests to help the project work)


Tim


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Draft spec for new dpkg "triggers" feature

[Ian Jackson]

For some time the idea of having some kind of event queue notification
mechanism in dpkg has been floating about.  For example, it would be
used to avoid running scrollkeeper-update dozens of times during an
upgrade and could simplify the emacs addon registration.  Wichert and
I even had a good design conversation in a taxi some years ago but we
failed to make proper notes and write it up.

I hope to be able to implement such a feature at some point in the
nearish future.  To this end I've written a draft specification which
you can find below.  If you're interested, please read it and comment.

Note the wide crosspost of this message.  I have set followups to go
to debian-dpkg, which is probably the right place for this discussion.

Regards,
Ian.


TRIGGERS


Introduction


A dpkg trigger is a facility that allows events of interest to a
package to be recorded and aggregated, and processed later by that
package.  This feature simplifies various registration and
system-update tasks and reduces duplication of processing.

(NB: Triggers are intended for events that occur during package
installation, not events that occur in general operation.)


Concepts


Each trigger is named, and at any time zero or more packages may be
interested in it.

We currently envisage three kinds of triggers:
 * Explicit triggers.  These can be activated by any program
   by running dpkg-trigger (at any time, but ideally from a maintainer
   script).
 * File triggers.  These are activated automatically by dpkg
   when a matching file is installed, upgraded or removed as part
   of a package.  They may also be explicitly activated by running
   dpkg-trigger.
 * Special triggers, which activate magic code in dpkg itself.
   Currently none of these are defined.

Trigger names contain only printing 7-bit ascii characters (no
whitespace).  Each trigger kind has a distinct subset of the trigger
name space so that the kind can be determined from the name.  After we
run out of straightforward syntaxes, we will use :.

When a trigger is activated, it becomes pending for every package
which is interested in the trigger at that time.  Each package has a
list of zero or more pending triggers.

A package with pending triggers is not considered properly installed
until efforts to notify it of the trigger event have been successful.
The new state of having pending triggers is a dpkg package status of
`triggered', which lies somewhere between `config-failed' and
`installed'.


Details
---

When one of the triggers in which a package is interested is
activated, the package goes from state `installed' to state
`triggered'; the list of pending triggers for each package is
recorded.

If no package is interested in a trigger then activations are ignored;
this is not an error.

To restore a package in state `triggered' to `installed', dpkg will
run the postinst script:
   postinst triggered "  ..."

This will be attempted for each package in state `triggered' at the
end of each dpkg run; so, normally, in the same dpkg run as the event
which made the package go to `triggered'.  This leaves packages in
reasonable states by default.

If the `postinst triggered' run fails the package goes to
`config-failed', so that the trigger processing will not be attempted
again until explictly requested.


 |
 V
   ,.
   |  unpacked  |
   `'
 |
 |
  (automatic)| ,--.
 | | config-  |
 | |  failed  |
 | `--'
 |   |  ^
 |   |  |
 |,---<--'  |
 |  (user   |
postinst |   request)   |
 "configure" |  |   ,---.
 |  |   | triggered |
 |  |   `---'
 |`->--'|  |^
 |error |postinst  ||
 |  |  "triggered" || trigger(s)
 |  |  (automatic) ||  activated
 |  |  ||
 |  `-<---'||
 |  error  ||
 | ||
 V V|
   ,.
   |   installed|
   `'


Timing guarantees, races, etc.
--

Activating a trigger will not have any immediate effect, although
putative resulting status changes will show up in dpkg --status etc.
(Putative because the actual status changes may depend on the state of
trigger interests when dpkg processes the trigger activation into
the status database, rather than that when dpkg --status is run.

Re: update on binary upload restrictions

[Wouter Verhelst]

On Mon, Jan 29, 2007 at 10:42:25AM +0100, Goswin von Brederlow wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
> > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote:
> >
> >> If we do go to source-only uploads, could this problem be avoided by
> >> having arm and other slow arches wait until at least one other arch
> >> successfully builds the package?
> >
> > I think that would be a good idea anyway, even if we do not go to
> > source-only uploads. There is no point in wasting expensive CPU cycles
> > to build a package if it FTBFS on every architecture.
> 
> I would rather do the opposite. Stop building a package when it fails
> on other archs.

How many other architectures. One? All of them?

Imagine something breaks R on m68k (which, by a string of total
coincidence, just happens to be true at this point in time), and then
someone uploads a new R package, which obviously fails to build there.
Should all other architectures refuse to build it now, just because that
package was new and thus not yet marked as "don't build this on m68k
until that R bug is fixed"? Stop building a package when it fails on one
other arch is not really an option.

Stop building when it fails on all other architectures? That kinda
defeats the purpose, because then only *one* other architecture will be
able to spare CPU cycles.

I don't think it's a bad idea to add upload date to the order in which
packages are built; that would allow slow architectures to chicken out
on the upload frenzy of a silly maintainer. But other than that...

Besides, the way wanna-build is implemented, it's impossible to use the
state of a package in *another* architecture as a parameter for
anything without resorting to the ugliest hacks one can come up with.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd stuff

[Wouter Verhelst]

On Mon, Jan 29, 2007 at 10:35:04AM +0100, Goswin von Brederlow wrote:
> Aurelien Jarno <[EMAIL PROTECTED]> writes:
> 
> > One first step would be to keep the current build daemons maintainers
> > (ie the person who signs the upload), and give and access to some
> > porters to the wanna-build database. This way they could reschedule
> > failed builds, add dep-wait, or do binNMU. If I am right Steve Langasek
> > already has access to the wanna-build database of all architectures, so
> > that should not be a technical problem.
> 
> I think from a technical point every buildd admin has access to
> wanna-build for all architectures. It is just policy not to mess
> around in someone elses backyard.

That's not true; I have access to m68k w-b, and that alone (and even
then only indirectly, by doing SSH to a buildd host and doing a su/ssh
dance there).

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd stuff

[Wouter Verhelst]

On Mon, Jan 29, 2007 at 11:04:12AM +0100, Aurelien Jarno wrote:
> There is no wb-amd64 nor wb-mipsel. I don't know why.

Because for actual w-b access from buildd hosts, those groups are no
longer used. Instead, there's a buildd_$arch user for every architecture
on buildd.d.o, to which access is regulated through SSH keys.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd stuff

[Wouter Verhelst]

On Mon, Jan 29, 2007 at 11:40:00PM +1100, Hamish Moffatt wrote:
> On Mon, Jan 29, 2007 at 11:04:12AM +0100, Aurelien Jarno wrote:
> > Goswin von Brederlow a écrit :
> > > Aurelien Jarno <[EMAIL PROTECTED]> writes:
> > > 
> > >> One first step would be to keep the current build daemons maintainers
> > >> (ie the person who signs the upload), and give and access to some
> > >> porters to the wanna-build database. This way they could reschedule
> > >> failed builds, add dep-wait, or do binNMU. If I am right Steve Langasek
> > >> already has access to the wanna-build database of all architectures, so
> > >> that should not be a technical problem.
> > > 
> > > I think from a technical point every buildd admin has access to
> > > wanna-build for all architectures. It is just policy not to mess
> > > around in someone elses backyard.
> > 
> > You think wrong. Using the public ldap database, you can find the
> > following details:
> 
> Why is w-b access so sacred?

It's not that it's sacred; it's that w-b uses a Berkeley DB with a
database-level lock for every access (including read-only access); so
giving such access to everyone who asks for it will interfere with
proper buildd operation.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug #118715 and #246680

[Turbo Fredriksson]

> "Lionel" == Lionel Elie Mamane <[EMAIL PROTECTED]> writes:

Lionel> On Sat, Jan 20, 2007 at 09:07:28PM +0100, Turbo
Lionel> Fredriksson wrote:
>> Is there no interest in fixing this even though there's
>> patch(es!)?

Lionel> A cursory glance suggests that code is not actively
Lionel> maintained (no release since May 2005).

So if code haven't been worked on in a long while, it's useless?!
Oh, come now...

I've been running the code for MORE than that, and so far I haven't 
seen any bugs with it...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd stuff

[Marc Haber]

On Tue, 30 Jan 2007 20:29:33 +0100, Wouter Verhelst
<[EMAIL PROTECTED]> wrote:
>It's not that it's sacred; it's that w-b uses a Berkeley DB with a
>database-level lock for every access (including read-only access); so
>giving such access to everyone who asks for it will interfere with
>proper buildd operation.

That looks like bad design to me.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: source code "forensic" practices

[Thomas Viehmann]

Hi Yaroslav,

Yaroslav Halchenko wrote:
> I ITPed a package which unfortunately ended up not providing original
> sources (sources everybody gets were indentation removed). Unreasonable
> denial of providing original source forced me to question good intent of
> the author to provide useful and spam/crap-free software. Since I could
> not possibly to examine that code, I've decided to look at other
> software written by the same author, and which has original source code,
> which probably nobody else ever examined anyways.

regardless of any possible outcome of your audit, I'm not sure that it's
a very good idea to include such code in Debian. IMO the results of your
analysys cast a shadow on the author's intend to provide free software
in the spirit of DFSG. There have been issues with upstream authors in
the the past and it seems these things offer a huge amount of agony we
best avoid.
That said, if you feel like it, you could approach the author and
potentially advocate better release practices to him.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Draft spec for new dpkg "triggers" feature

[Florian Weimer]

* Ian Jackson:

> To restore a package in state `triggered' to `installed', dpkg will
> run the postinst script:
>postinst triggered "  ..."

Is this completely POSIX-conforming if there are many triggers?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mirror of archive maintenance scripts

[Anthony Towns]

On Tue, Jan 30, 2007 at 03:28:19PM +0100, Florian Weimer wrote:
> > It is now; the katie -> dak rename broke it.
> Uhm, it seems that it's still lacking James' recent changes.  Are you
> sure the mirror is working?

They're there and it is. Grep for "Binary-Upload-Restrictions".

Cheers,
aj


signature.asc
Description: Digital signature

Re: Bug#408524: If I play piano while my computer starts up, /dev/dsp disappears !

[Gunnar Wolf]

Marco d'Itri dijo [Fri, Jan 26, 2007 at 02:44:19PM +0100]:
> > My guess is that it's either the kernel or udev which is doing something
> > wrong here. I'm filing this as a bug on udev for the time being; I'm
> > sure Marco will properly reassign this bug once you've provided the
> > extra information.
> Sure... When in doubt just blame udev.
> (Hint: README.Debian.)

No, Marco, what he meant is that it's fun to actually see you rage
about yet-another-bug :)

(or is your personal mail address listed in README.Debian as a
pressure reliever?)

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


signature.asc
Description: Digital signature

Re: update on binary upload restrictions

[Gunnar Wolf]

Goswin von Brederlow dijo [Mon, Jan 29, 2007 at 10:42:25AM +0100]:
> I would rather do the opposite. Stop building a package when it fails
> on other archs. Thing about the (unlikely) situation that arm is
> idle. Nothing to build. Now someone uploads foobar. Should we wait or
> just try? If it works we saved time. If it fails only idleing is lost.

Even in the worst cases, it would mean just waiting a couple of hours
until a build was detected as successful in our fastest buildds - I
doubt ARM/m68k buildds are often that much time idle ;-)

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]