Re: Bug#540215: Introduce dh_checksums

[Goswin von Brederlow]

Russ Allbery  writes:

> Simon McVittie  writes:
>
>> Most packages (in terms of proportion of the archive, in particular for
>> architectures other than i386 and amd64) are built by a buildd, so each
>> buildd would have to have a signing key that could sign the checksums
>> file during build. Further, the build part of a buildd runs inside a
>> limited chroot running the target distribution, i.e. usually unstable
>> (the "real system" runs stable with a backported version of sbuild),
>> which doesn't have access to any key material in the "real system".
>
>> At the moment buildds don't have their own keys: a buildd maintainer
>> inspects the build log and signs the .changes file for upload.
>
>> Even for maintainer uploads, maintainers who build their packages in a
>> minimal chroot with schroot, pbuilder, cowbuilder etc. (which is
>> strongly recommended) don't necessarily have their signing key available
>> inside the chroot (nor should they!).
>
> Signatures per buildd or per DD doing uploads are moderately interesting,
> but not nearly as interesting as a signature by a long-term stable key
> such as the archive key.
>
> Do we actually rely anywhere on packages not changing hashes between
> upload and publication in the repository, or is it just something we have
> as an invariant now because there's no reason for it not to be one?  The
> path of least resistance here would be for DAK to add the package
> signature after verifying the signature of the uploader.  This has the
> drawback that it modifies the *.deb and therefore breaks the hashes in the
> *.changes file and hence its original signature, but given that we throw
> out the *.changes file anyway, do we actually care?

The changes files are afaik archived somewhere and are needed to verify
the archive integrity after a (feared) compromise.

And what do you do when the archive key expires? Resign every deb in the
archive and have every mirror download them all again? Same problem on
releases. Releasing a new stable means a new stable key so every deb
needs to be signed again and changes. I don't think this is a good idea.
This would also cause users (apt/aptitude actually) to reinstall the
packages needlessly creating even more mirror load.

For this to work the signature for the checksum files should be detached
so that it can be changed/extended without altering the deb files.

I suggested this before but lets repeat it. Why not include a digest of
the checksum file in DEBIAN/control, carry it into the changes file and
into Packages.gz. That way all current debs automatically have a clear
trust path.

Further the changes files could be included in the pool alongside the
debs and source files. That way everyone can verify the autenticity of
the debs (or just the checksum file) independent of the archive
key. Going one step further the changes files could be signed by the
archive key(s) as well. Adding a new signature to them when keys change
does mean they need to be mirrored again but they are relatively small.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iq8uf5lv@frosties.localdomain

Re: Suggestions to fix #433462 (add free space info to reportbug)

[Yves-Alexis Perez]

On mer., 2010-03-17 at 17:26 +0100, Goswin von Brederlow wrote:
> On the other hand including free space information will be difficult to
> handle properly and possibly expose information the user considers
> private.

But places where packages are supposed to write aren't that private.
Usually /home (but if people mount one fs per user there might be
privacy issues), /tmp (not really private), /var (either). Packages
install/upgrades will write in /usr and /etc and few other folders
(/boot..) which aren't really private either.

Real issues will appear for stuff using “named” mount point in /srv
(or /home as said above).
> 
> 
> But if you do go ahead with this consider this:
> 
> The bugreport gives the following argument: "I suspect that a lot of my
> packages would fail in mysterious ways if the root partition was full."
> How will his software behave with the root partition being mounted
> read-only? Listing the free space on root or /usr would be completly
> meaningless if they are read-only and writing to them would be a
> critical bug anyway.

One thing which could be done too is to run the df, detect if there are
full fs, and if there are, ask for the user if she wants to include the
result.

Cheers,
-- 
Yves-Alexis


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

Re: Bug#540215: Introduce dh_checksums

[Goswin von Brederlow]

Wouter Verhelst  writes:

> On Wed, Mar 17, 2010 at 04:12:46PM -0700, Russ Allbery wrote:
>> Wouter Verhelst  writes:
>> 
>> > This is not true.
>> 
>> > wou...@merkel:/org/ftp.debian.org/queue/done$ ls *ges|wc -l
>> > 28969
>> 
>> > These are only the *active* changes files, though:
>> 
>> > wou...@merkel:/org/ftp.debian.org/queue/done$ find . -name 'nbd*ges'|wc -l
>> > 898
>> 
>> > ... since no .changes file is ever thrown away:
>> 
>> > wou...@merkel:/org/ftp.debian.org/queue/done$ du -sh .
>> > 7.1G
>> 
>> > They may not be visible on the mirrors, but they are there.
>> 
>> Ah, thank you.  I didn't realize that we kept them at all.
>> 
>> Note, though, that if the concern is a cryptographically strong audit
>> trail, we could still retain a link from the original *.changes file to
>> the final package with a second (possibly signed) document archived with
>> the *.changes file listing the original and final checksums of the
>> now-signed packages.
>
> True.

False.

The changes files are signed by a human and therefor have a strong trust
level. The "was XYZ is now UVW" file would have to be automatically
signed and much less trustworthy. Esspecially if you suspect someone
broke into ftp-master and modified some debs. They would just recreate
and resign the "was XYZ is now UVW" file with the automatic archive key.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eijif5fs@frosties.localdomain

Re: Bits from the Release Team: What should go into squeeze?

[Yves-Alexis Perez]

On mer., 2010-03-17 at 19:01 +0700, Andrew Lee wrote:
> - lxdm 0.1: a simple display manager for LXDE

Which doesn't seem to be in Debian nor in NEW at the moment. Won't that
be a bit short?

Cheers,
-- 
Yves-Alexis


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

Re: Suggestions to fix #433462 (add free space info to reportbug)

[Bastien ROUCARIES]

On Thu, Mar 18, 2010 at 8:32 AM, Yves-Alexis Perez  wrote:
> On mer., 2010-03-17 at 17:26 +0100, Goswin von Brederlow wrote:
>> On the other hand including free space information will be difficult to
>> handle properly and possibly expose information the user considers
>> private.
>
> But places where packages are supposed to write aren't that private.
> Usually /home (but if people mount one fs per user there might be
> privacy issues), /tmp (not really private), /var (either). Packages
> install/upgrades will write in /usr and /etc and few other folders
> (/boot..) which aren't really private either.
>
> Real issues will appear for stuff using “named” mount point in /srv
> (or /home as said above).
>>
>>
>> But if you do go ahead with this consider this:
>>
>> The bugreport gives the following argument: "I suspect that a lot of my
>> packages would fail in mysterious ways if the root partition was full."
>> How will his software behave with the root partition being mounted
>> read-only? Listing the free space on root or /usr would be completly
>> meaningless if they are read-only and writing to them would be a
>> critical bug anyway.
>
> One thing which could be done too is to run the df, detect if there are
> full fs, and if there are, ask for the user if she wants to include the
> result.

Add also quota information if available


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/195c7a901003180212p56c3616aj72306e8d62750...@mail.gmail.com

Re: Re: Bug#571255: udev_151-3_amd64 failed at apt-get install

[Fabian Greffrath]

The preinst code which guaranteed lockstep upgrades of udev and kernel
packages does not work reliably anymore, apparently because apt now
tries to install the kernel and udev packages with different dpkg runs.
We need a new solution which does not require users to manually disable
the check...


IIRC the output of "dpkg -l" indicates that a package is "about to be 
installed" in the first two characters of the corresponding line.


Hope this helps...

 - Fabian


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba1ede0.9050...@leat.rub.de

Re: Bug#540215: Introduce dh_checksums

[Harald Braumann]

On Wed, Mar 17, 2010 at 02:36:31PM +, Simon McVittie wrote:
> On Wed, 17 Mar 2010 at 12:41:58 +0100, Harald Braumann wrote:
> > It should be signed at build time, just after dh_shasums and then the
> > sig file packaged together with all the other files. I don't see a
> > problem with that. Or maybe I'm not getting something here?
> 
> Most packages (in terms of proportion of the archive, in particular for
> architectures other than i386 and amd64) are built by a buildd, so each buildd
> would have to have a signing key that could sign the checksums file during
> build. Further, the build part of a buildd runs inside a limited chroot
> running the target distribution, i.e. usually unstable (the "real system" runs
> stable with a backported version of sbuild), which doesn't have access to any
> key material in the "real system".
> 
> At the moment buildds don't have their own keys: a buildd maintainer inspects
> the build log and signs the .changes file for upload.
> 
> Even for maintainer uploads, maintainers who build their packages in a
> minimal chroot with schroot, pbuilder, cowbuilder etc. (which is strongly
> recommended) don't necessarily have their signing key available inside
> the chroot (nor should they!).

Thanks for explaining all these details.

> I build my packages with sbuild/schroot, and my GPG key isn't available inside
> the build system as a result of using gfcombinefs to split my key between my
> laptop and a USB stick (so that if either is stolen, my key isn't 
> compromised).
> I'm told some developers take this further, and only store their key on a
> non-networked machine to which they transfer files for signing (the current
> package upload procedure makes this possible - they only really need to
> transfer the .changes file, in fact). I think it would be irresponsible to
> make it necessary for DDs to choose between weakening the security of their
> GPG keys, or producing less reproducible builds.

Theoretically you could produce rather short-lived keys that are
signed with your maintainer key, make those available in the build
environment and use them for signing. The signing key along with the
signature by the maintainer key would have to be included in the
package as well. But I guess that this would be a tad to complex and I
wouldn't propose it.

harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100318110955.gb17...@nn.nn

Re: Bug#540215: Introduce dh_checksums

[Harald Braumann]

On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
> Russ Allbery  writes:
> 
> > Simon McVittie  writes:
> >
> >> Most packages (in terms of proportion of the archive, in particular for
> >> architectures other than i386 and amd64) are built by a buildd, so each
> >> buildd would have to have a signing key that could sign the checksums
> >> file during build. Further, the build part of a buildd runs inside a
> >> limited chroot running the target distribution, i.e. usually unstable
> >> (the "real system" runs stable with a backported version of sbuild),
> >> which doesn't have access to any key material in the "real system".
> >
> >> At the moment buildds don't have their own keys: a buildd maintainer
> >> inspects the build log and signs the .changes file for upload.
> >
> >> Even for maintainer uploads, maintainers who build their packages in a
> >> minimal chroot with schroot, pbuilder, cowbuilder etc. (which is
> >> strongly recommended) don't necessarily have their signing key available
> >> inside the chroot (nor should they!).
> >
> > Signatures per buildd or per DD doing uploads are moderately interesting,
> > but not nearly as interesting as a signature by a long-term stable key
> > such as the archive key.
> >
> > Do we actually rely anywhere on packages not changing hashes between
> > upload and publication in the repository, or is it just something we have
> > as an invariant now because there's no reason for it not to be one?  The
> > path of least resistance here would be for DAK to add the package
> > signature after verifying the signature of the uploader.  This has the
> > drawback that it modifies the *.deb and therefore breaks the hashes in the
> > *.changes file and hence its original signature, but given that we throw
> > out the *.changes file anyway, do we actually care?
> 
> The changes files are afaik archived somewhere and are needed to verify
> the archive integrity after a (feared) compromise.
> 
> And what do you do when the archive key expires? Resign every deb in the
> archive and have every mirror download them all again? 

Why? A signature doesn't become invalid just because the key
expires, as long as the signature was created before the expiration of
the key. 

> Same problem on
> releases. Releasing a new stable means a new stable key so every deb
> needs to be signed again and changes. I don't think this is a good idea.
> This would also cause users (apt/aptitude actually) to reinstall the
> packages needlessly creating even more mirror load.
> 
> For this to work the signature for the checksum files should be detached
> so that it can be changed/extended without altering the deb files.
> 
> I suggested this before but lets repeat it. Why not include a digest of
> the checksum file in DEBIAN/control, carry it into the changes file and
> into Packages.gz. That way all current debs automatically have a clear
> trust path.
> 
> Further the changes files could be included in the pool alongside the
> debs and source files. That way everyone can verify the autenticity of
> the debs (or just the checksum file) independent of the archive
> key. Going one step further the changes files could be signed by the
> archive key(s) as well. Adding a new signature to them when keys change
> does mean they need to be mirrored again but they are relatively small.

Self-contained packages, where the signature is included and installed
along with the checksum file, would have a lot of
advantages. You wouldn't need access to a lot of infrastructure just
to verify a signature. It would be very simple. It could be used for
packages, that are not part of Debian. For instance, I could produce a
package and send it to a friend and he could later use my key for
verification. The same holds for projects that publish deb files. With
your proposal they would need a full fledged archive and keep a long
history of all the files. 

And what do you do with packages from testing/unstable/experimental?
Would you keep all incarnations of the Release/Packages/changes files?
And if I want to verify the signature of an installed file, from a
package I once installed from, say, unstable, how would I find the
right version of the changes file for the package?

Cheers,
harry


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100318113959.gc17...@nn.nn

Re: Symbols from C++ templates and ABI versioning

[Jakub Wilk]

* Christoph Egger , 2010-03-11, 19:31:

Currently irrlicht released a new minor version which I want to
upload to debian. Concerning the ABI the only relecvant change is the
removal of 4 symbols which are template instantiations.

I can, of course, force instantiation of these templates but that
feels quite like a hack. Does someone with deeper insight into that
topic know if just having that ABI change causes some potential harm
or whether I can just go ahead ignoring it?


[Disclaimer: I'm neither a shared libraries expert, nor a C++ expert. 
The following text is based only on my shallow knowledge and a couple 
of experiments.]


If we are very rigid, then unfortunately it is possible that some 
programs/libraries are already using these symbols and having them gone 
is an ABI breakage. But then we are doomed anyway: it is also possible 
that some symbols will disappear after a simple recompilation, just 
because compiler decided to inline more stuff than previously.


So, going back to reality:

If we can assume some level of sanity, i.e.:
- these templates are fully defined within the library headers (in all 
versions using the same SONAME);

- all software is actually using the library headers;
then it *looks* like that gcc will never generate binaries with the 
symbols in question undefined. Thus, it would be safe ignore 
disappearance of them.


Side note #1: According to dpkg-gensymbols(1), “A symbol marked as 
optional can disappear from the library at any time and that will never 
cause dpkg-gensymbols to fail. […] most of C++ template instantiations 
fall into this category.” Now let's merely define “most”…


Side note #2: I have the impression that maintaining shared libraries is 
a poorly understood topic for most upstreams *and* for most DD. However 
I also believe that we have some people within the project who are very 
knowledgeable about that. It is therefore sad that we lack good and 
properly maintained documentation on that matter.


--
Jakub Wilk


signature.asc
Description: Digital signature

VHDL-AMS Survey and Call for Participation

[training]

---
VHDL-AMS Survey and Call for Participation
---

The VHDL-AMS hardware description language is an extension of the VHDL 
language used since the late 1980s. Supporting the description and simulation 
of analog and mixed-signal devices, VHDL-AMS was first standardized as IEEE 
Std 1076.1 in 1999 and subsequently revised in 2007. VHDL-AMS is supported by 
tools from all the major EDA vendors as well as some of the smaller vendors, 
and it has been used in a variety of applications, mostly in IC and system 
design.
 
The IEEE P1076.1 Working Group is now starting with another revision of the 
language, and it is asking for your help. First, the WG has collected a number 
of possible language extensions, and it requests your input regarding the 
relative priority of these extensions. Second, the WG is looking for new 
members willing to participate in the work to define the language extensions. 
Participation in the work of the Working Group can take on many forms, 
including but not limited to:

* collection of detailed requirements
* review and approval of requirements
* definition of language extensions based on requirements
* review of language extensions
* creation of a new standard package
* testing of a new standard package

As you can see, the creation or extension of a standard requires many 
different skills. If you are interested in participating, please contact the 
WG Chair Ernst Christen, christen.1...@verizon.net. You can also find 
additional information about the IEEE P1076.1 Working Group at 
http://www.eda.org/vhdl-ams.
 
An overview of the projects considered for the upcoming revision of VHDL-AMS 
can be found at http://www.eda.org/twiki/bin/view.cgi/P10761/ProjectsArea. 
There are three kinds of projects. *Upgrade Projects* and *Maintenance 
Projects* are mandatory for the revision as they are related to incorporating 
the changes in the base VHDL language and the 1076.1.1 companion standard into 
VHDL-AMS. The section *New Feature Projects* describes the projects for which 
we are requesting guidance. These projects have been proposed by users of 
VHDL-AMS over the past few years.
 
We would like you as a user of, or a person otherwise interested in, the VHDL-
AMS language to give each New Feature Project a grade in the range
1 to 10 to reflect the importance this project has for you and your work, with 
10 being the highest grade. We will then tally the responses, together with 
responses we received from the Working Group, to determine the priorities for 
these projects. The priorities may affect which projects will be included in 
the next revision of VHDL-AMS, depending on the number of people participating 
in the work to define these extensions. The New Feature Projects are:
 
... Mixed netlists
 
... Frequency domain modeling
 
... Support for partial differential equations
 
... Table-driven modeling
 
... Vector/matrix operations
 
... Unified use of SPICE models in different tools
 
Please grade each project according to the importance it has for you and your 
work. Enter the grade in the space provided. You are also welcome to submit at 
this time requests for additional new features to include in VHDL-AMS. We will 
consider such requests to the extent possible in the upcoming revision. Enter 
your suggestions in the space below.
 

 

 

 
Return the completed questionnaire with your grades and suggestions to the 
Chair of the IEEE P1076.1 Working Group: Ernst Christen, 
christen.1...@verizon.net, by April 30, 2010.
 
Please also forward this email to other people that might be interested in 
either providing feedback to the WG or participating in the work to define the 
language extensions.
 
We are looking forward to your input and your help. If you have any questions 
please do not hesitate to contact me.
 
Ernst Christen
Chair, IEEE P1076.1 Working Group
email: christen.1...@verizon.net



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100318121922.03b9c7000...@msfrf2221.sfr.fr

Bug#574472: ITP: ns3 -- discrete-event network simulator

[syq]

Package: wnpp
Severity: wishlist
Owner: YunQiang Su 


* Package name: ns3
  Version : 3.7.1
  Upstream Author : ns3 team
* URL : http://www.nsnam.org/
* License : GPL version 2
  Programming Lang: C++,Python
  Description : discrete-event network simulator

 ns-3 is a discrete-event network simulator for Internet systems, 
 targeted primarily for research and educational use. 
 ns-3 is free software, licensed under the GNU GPLv2 license, 
 and is publicly available for research, development, and use.
 .
 ns-3 is intended as an eventual replacement for the popular
 ns-2 simulator. The project acronym “nsnam” derives 
 historically from the concatenation of ns (network simulator) 
 and nam (network animator). 



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100318130811.15444.91637.report...@syq-laptop

Bug#574471: ITP: ns3 -- discrete-event network simulator

[syq]

Package: wnpp
Severity: wishlist
Owner: YunQiang Su 


* Package name: ns3
  Version : 3.7.1
  Upstream Author : ns3 team 
* URL : http://www.nsnam.org/
* License : GPL version 2
  Programming Lang: C++, Python
  Description : discrete-event network simulator

 ns-3 is a discrete-event network simulator for Internet systems, 
 targeted primarily for research and educational use. 
 ns-3 is free software, licensed under the GNU GPLv2 license, 
 and is publicly available for research, development, and use.
 .
 ns-3 is intended as an eventual replacement for the popular
 ns-2 simulator. The project acronym “nsnam” derives 
 historically from the concatenation of ns (network simulator) 
 and nam (network animator).



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100318131526.15535.39932.report...@syq-laptop

Bug#574481: ITP: oropo-system -- System for task distribution and processing in a computer cluster.

[Maciej Smolenski]

Package: wnpp
Severity: wishlist
Owner: Maciej Smolenski 
Owner: Maciej Smolenski 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: oropo-system
  Version : 0.1
  Upstream Author : Maciej Smolenski 
* URL : http://www.oropo.org/
* License : BSD
  Programming Lang: C, C++
  Description : System for task distribution and processing in a computer 
cluster.

Oropo is a system for task distribution and processing in a computer cluster.
It is also a framework for building services for this system.
Oropo is design to process aribtrary tasks.
It is proof against computer failures and network failures.
More informations: http://www.oropo.org
Package oropo-system provides system for task distribution and processing in a 
computer cluster.

Maciej Smolenski (jezd...@gmail.com)
GPG: 2048D/884A0CB2


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

iF4EAREIAAYFAkuiN/YACgkQc6JyqTPYH2ez2wEAq4Y1/KuaipdN0495tpV+Ynq3
qTwywh8x/sqGQp5YNXABAKtfx8UdL+y6dBjWlDCc3oDkGyHNrydO21XJ2wmxmLMS
=EtD4
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100318142604.6507.14287.report...@webredir.vip.gandi.net

Bug#574482: ITP: oropo-executor -- Oropo service for executing programs.

[Maciej Smolenski]

Package: wnpp
Severity: wishlist
Owner: Maciej Smolenski 
Owner: Maciej Smolenski 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: oropo-executor
  Version : 0.1
  Upstream Author : Maciej Smolenski 
* URL : http://www.oropo.org/
* License : BSD
  Programming Lang: C, C++
  Description : Oropo service for executing programs.

Oropo is a system for task distribution and processing in a computer cluster.
It is also a framework for building services for this system.
Oropo is design to process aribtrary tasks.
It is proof against computer failures and network failures.
More informations: http://www.oropo.org
Package oropo-executor is oropo service for program execution.

Maciej Smolenski (jezd...@gmail.com)
GPG: 2048D/884A0CB2


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

iF4EAREIAAYFAkuiOcsACgkQc6JyqTPYH2cfXAEAxaSJ80PLCh36SW/gmnbgTz2y
Tf7ETNypxGVnrukpAZAA/Rpo8GWHAP97wyLUpEkJjkyOi+ak1TT/G4iV35XtcHow
=rYTD
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100318143351.6569.85032.report...@webredir.vip.gandi.net

Bug#574483: ITP: oropo-monitor -- Daemon that monitors state of rpc services on many hosts.

[Maciej Smolenski]

Package: wnpp
Severity: wishlist
Owner: Maciej Smolenski 
Owner: Maciej Smolenski 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: oropo-monitor
  Version : 0.1
  Upstream Author : Maciej Smolenski 
* URL : http://www.oropo.org/
* License : BSD
  Programming Lang: C, C++
  Description : Daemon that monitors state of rpc services on many hosts.

Oropo is a system for task distribution and processing in a computer cluster.
It is also a framework for building services for this system.
Oropo is design to process aribtrary tasks.
It is proof against computer failures and network failures.
More informations: http://www.oropo.org
Package oropo-monitor is monitor for rpc services in a computer cluster.

Maciej Smolenski (jezd...@gmail.com)
GPG: 2048D/884A0CB2


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

iF4EAREIAAYFAkuiOlwACgkQc6JyqTPYH2fJeQD8CDf9z99VdHuRStNOoP3y6A6N
gZIbMnEYG2rljyoXWGEA+wU0rVMfdJvFjXVi1XAZBRJhbAJAEr48KyCmoHGftUZM
=e8Zy
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100318143618.6629.20874.report...@webredir.vip.gandi.net

Bug#574484: ITP: liboropo1 -- Common library for Oropo system and Oropo services.

[Maciej Smolenski]

Package: wnpp
Severity: wishlist
Owner: Maciej Smolenski 
Owner: Maciej Smolenski 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: liboropo1
  Version : 0.1
  Upstream Author : Maciej Smolenski 
* URL : http://www.oropo.org/
* License : BSD
  Programming Lang: C, C++
  Description : Common library for Oropo system and Oropo services.

Oropo is a system for task distribution and processing in a computer cluster.
It is also a framework for building services for this system.
Oropo is design to process aribtrary tasks.
It is proof against computer failures and network failures.
More informations: http://www.oropo.org
Package liboropo1 is common part of other oropo system components.

Maciej Smolenski (jezd...@gmail.com)
GPG: 2048D/884A0CB2


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

iF4EAREIAAYFAkuiO68ACgkQc6JyqTPYH2embwEAzqwKyxBwPEwFI6seec+5J+kg
U2ETEot3hKc5fnGVm/UBAJWTek7VfLG+nDhYyt5gfarQTJGameEeQdmUDLYvShJU
=FvGw
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100318144157.6820.88986.report...@webredir.vip.gandi.net

Bug#574485: ITP: liboropo-dev -- Oropo common library (development resources).

[Maciej Smolenski]

Package: wnpp
Severity: wishlist
Owner: Maciej Smolenski 
Owner: Maciej Smolenski 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: liboropo-dev
  Version : 0.1
  Upstream Author : Maciej Smolenski 
* URL : http://www.oropo.org/
* License : BSD
  Programming Lang: C, C++
  Description : Oropo common library (development resources).

Oropo is a system for task distribution and processing in a computer cluster.
It is also a framework for building services for this system.
Oropo is design to process aribtrary tasks.
It is proof against computer failures and network failures.
More informations: http://www.oropo.org
Package liboropo-dev is common part to build other oropo system components.

Maciej Smolenski (jezd...@gmail.com)
GPG: 2048D/884A0CB2


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

iF4EAREIAAYFAkuiPFsACgkQc6JyqTPYH2cZEQEAj/TTm5bRQ99HdguzISJCgv/x
UIXDpuS44T9pFZnio8wBALz10RzgNqoOMby+vNtZYS1GwGgFFtveAgVkq/vID1Uk
=TrB3
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2010031817.6927.78514.report...@webredir.vip.gandi.net

Bug#574494: ITP: haskell-data-accessor -- Utilities for accessing and minpulating fields of records

[USB]

Package: wnpp
Severity: wishlist
Owner: "Ernesto Hernández-Novich (USB)" 


* Package name: haskell-data-accessor
  Version : 0.2.1.2
  Upstream Author : Henning Thielemann 
* URL : http://hackage.haskell.org/packages/data-accessor
* License : BSD
  Programming Lang: Haskell
  Description : Utilities for accessing and minpulating fields of records

With this library you can define record field accessors which allow
setting, getting and modifying values easily. You can combine accessors
of a record and sub-records to make the access look like the fields
of the sub-record belong to the main record.

This is a building dependency for Haskore, a Haskell DSL and combinator
library for music manipulation and generation.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (900, 'stable'), (1, 'experimental')
Architecture: i386 (i686)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100318152029.29268.42217.report...@deepthought.itverx.com.ve

Bug#574503: ITP: haskell-utility-ht -- Small helper functions for Lists, Maybes, Tuples and Functions

[USB]

Package: wnpp
Severity: wishlist
Owner: "Ernesto Hernández-Novich (USB)" 


* Package name: haskell-utility-ht
  Version : 0.0.5.1
  Upstream Author : Henning Tielemann 
* URL : http://hackage.haskell.org/packages/utility-ht
* License : BSD
  Programming Lang: Haskell
  Description : Small helper functions for Lists, Maybes, Tuples and 
Functions

This library provides various small helper functions for Lists, Maybes,
Tuples and Functions. Some of these functions are improved implementations
of standard functions. They have the same name as their standard
counterparts.

This is a building dependency for Haskore, a Haskell DSL and combinator
library for music manipulation and generation.
-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (900, 'stable'), (1, 'experimental')
Architecture: i386 (i686)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100318162553.6630.88504.report...@deepthought.itverx.com.ve

Re: Bug#540215: Introduce dh_checksums

[Russ Allbery]

Goswin von Brederlow  writes:

> And what do you do when the archive key expires?

Why would you need to do anything at all when the archive key expires?
Keys don't become magically compromised or worthless just because they've
expired.  All it means is that you can't trust the integrity of really old
signatures as much as you can trust the integrity of new ones.

> Same problem on releases. Releasing a new stable means a new
> stable key so every deb needs to be signed again and changes.

I don't see why.  The only *.debs that we might need to resign are ones
where there have been no uploads for an entire release cycle and hence may
be released with expired signatures, and while there are a few of those,
that's a much smaller problem.  You could even just do an all-arch binNMU
to deal with resigning those.

> For this to work the signature for the checksum files should be detached
> so that it can be changed/extended without altering the deb files.

We could do that as well, but it would require changing the binary package
format and the archive software to track an additional file, and I think
that's a much larger change.

> I suggested this before but lets repeat it. Why not include a digest of
> the checksum file in DEBIAN/control, carry it into the changes file and
> into Packages.gz. That way all current debs automatically have a clear
> trust path.

Multiple people have explained to you why this doesn't solve the problem:
it means that you lose your signature path as soon as the package is no
longer listed in Packages.

I'm not interested in new ways of authenticating packages that are still
current and still listed in Packages.  That's a solved problem, and while
we can provide some moderate additional convenience, it's not really
enough to justify the work.  I'm interested in ways of authenticating
packages that *aren't* listed in Packages, either because they're
unofficial or because they're old and have been superseded.  That would be
a useful new feature.

> Further the changes files could be included in the pool alongside the
> debs and source files. That way everyone can verify the autenticity of
> the debs (or just the checksum file) independent of the archive
> key. Going one step further the changes files could be signed by the
> archive key(s) as well. Adding a new signature to them when keys change
> does mean they need to be mirrored again but they are relatively small.

That's an interesting idea.  Yes, we could add additional signatures to
the *.changes file without any of this other impact.  To solve the full
problem for the Debian archive, we'd need to provide all the *.changes
files for every *.deb that we've ever released, but thankfully they're
small.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3z1h37v@windlord.stanford.edu

Re: Bug#540215: Introduce dh_checksums

[Russ Allbery]

Goswin von Brederlow  writes:

> The changes files are signed by a human and therefor have a strong trust
> level. The "was XYZ is now UVW" file would have to be automatically
> signed and much less trustworthy.

This objection makes no sense to me.  The archive key is *much* more
trusted in practice than the individual DD keys.  Haven't you been
advocating using the Packages file for this purpose, which is signed by
exactly the same key that would be doing this signature?

> Esspecially if you suspect someone broke into ftp-master and modified
> some debs.

Which they can do just as easily if you rely only on Packages.  Even more
easily, in fact.

The problems that you are citing here are problems that we already have;
that, in fact, are much worse now than they would be under that proposed
scheme.  (However, I will note that your *.changes idea does offer some
additional protection there over the scheme that I was considering.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w9ph328@windlord.stanford.edu

Re: Submitting bugs for manpage improvements

[James Vega]

On Sun, Mar 7, 2010 at 9:53 AM, Frank Lin PIAT  wrote:
> Dear devscripts maintainers,
>
> On Tue, 2009-10-20 at 07:17 +0200, Frank Lin PIAT wrote:
>>
>> I have written a small script to make it easy to submit manpage
>> improvements (it's attached).
>> I believe that it much more effective to submit a patch, rather than
>> explaining what needs to be improved. The tool works like quilt, dpatch
>> & co. One would just invoke:
>>
>>   % man-reportbug chfn
>
> Are you interested in shipping this tool in devscripts?
> (Let me know if you aren't, I would consider an alternative way to ship
> it).

It definitely looks like a useful tool to have somewhere.  I'm
interested in what the reportbug people (Cced) think about integrating
the functionality, as you suggested in your initial request.

In the mean time, I can add it to my list of things to look at when I
next have some time to work on devscripts.  I'm hoping to get some soon,
but things have been a bit hectic lately.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/14ccba101003181232y148de9a6vcb405d6c0eae7...@mail.gmail.com

Bug#574525: ITP: nltk -- Python libraries for natural language processing

[C.J. Adams-Collier]

Package: wnpp
Severity: wishlist
Owner: "C.J. Adams-Collier" 


The Python NLTK libraries are packaged for Ubuntu 10.04.  I'd like to
bring this package into conformance with Debian and Python policies
and include it in Debian.

* Package name: nltk
  Version : 2.0b8
  Upstream Author : Steven Bird , Edward Loper 
, Ewan Klein 
* URL : http://www.nltk.org/
* License : Apache License, Version 2.0
  Programming Lang: Python
  Description : Python libraries for natural language processing

The Natural Language Toolkit (NLTK) is a suite of open source Python
modules, data and documentation for research and development in
natural language processing. NLTK contains code supporting dozens of
NLP tasks, along with 40 popular corpora and extensive documentation
including a 375-page online book.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100318200459.22722.55281.report...@dev0

dash Debian package - RC bugs

[Gerrit Pape]

Hi,

I find myself to have from time to time less spare time and/or
motivation than some of the packages I maintain deserve.  So the dash
Debian package.

I'm looking for volunteers that are willing to help with maintaining
dash.  Most of the work is relaying bug reports to upstream, judging and
including prospective fixes if upstream is unresponsive, preparing
patches for bugs, and the usual bug reports management.

dash has outstanding RC bugs.  Some are a left-over from the /bin/sh
transition from bash to dash, and still unresolved.  IIRC Thorsten
Glaser had some ideas on how to proceed, but we never discussed anything
in this regard.  Luk Claes and Raphael Geissert were involved in
initiating the transition, but seem to no longer be able to contribute
to the resulting RC bugs.

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538822

I set up a mailing list to coordinate work on the dash package.  If
you're interested in helping, please subscribe to the
 mailing list by sending an email to
, and start to discuss
and contribute.  Thanks for your help.

Regards, Gerrit.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100318201304.7496.qm...@167d09f4679c67.315fe32.mid.smarden.org

Suggestion to developer tools

[ceduardo]

Hi every body, thaks you for your suggestions.

Well I am learning about C, C++ and Linux programing, jeje I am trying
to be a Debian developer this is my objetive. On my practices use
emacs and others tools from console.

What Do you developer tools sugges?

Thanks

PD: I sorry but my english is very bad, I am learning too.

--
ceduardo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/c068e3701003181532g79d476a4g497a49fc9ed84...@mail.gmail.com

Re: Suggestion to developer tools

[Marco Túlio Gontijo e Silva]

Hi Carlos.

Excerpts from ceduardo's message of Qui Mar 18 19:32:27 -0300 2010:
(...)
> Well I am learning about C, C++ and Linux programing, jeje I am trying
> to be a Debian developer this is my objetive. On my practices use
> emacs and others tools from console.
> 
> What Do you developer tools sugges?
> 
> Thanks
> 
> PD: I sorry but my english is very bad, I am learning too.

I could not understand what you are asking.  Do you speak portuguese?  Maybe
you want to join debian-devel-portugu...@lists.debian.org .  If not, you can
search for a development list in your language in
http://lists.debian.org/devel.html .

Greetings.
(...)
-- 
marcot
http://wiki.debian.org/MarcoSilva


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1268953772-sup-3...@zezinho

Re: Bug#540215: Introduce dh_checksums

[Frank Lin PIAT]

On Wed, 2010-03-17 at 11:31 +0100, Wouter Verhelst wrote:
> On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote:
> > Wouter Verhelst  writes:
> > > On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
> > >> Harald Braumann  writes:
> > >> > On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
> > >> >>
> > >> >> Having package.checksums be GPG-signed will take a significant change 
> > >> >> in
> > >> >> our infrastructure (buildd hosts, for instance, would need to have a 
> > >> >> way
> > >> >> to sign checksums files as well), so it's not going to happen
> > >> >> tomorrow.
> > >> 
> > >> That can be avoided by including a hash of the checksum file in the
> > >> Packages files.
> > >
> > > That doesn't help for the problem we're trying to fix here: having a
> > > path to a GPG signature from an individual binary on the hard disk,
> > > months or years after the package was installed.
> > >
> > > With your proposal, you lose the signatures once the package is out of
> > > the archive and you run 'apt-get update'.
> > 
> > Then don't do that. :)
> 
> We can hardly say to our users "if you want to be able to check
> signatures, never run run apt-get update"...

Not necessarily. I assume that it would be easy (and cheap) to preserve
a copy of the previous:
 http://ftp.debian.org/debian/dists/testing/InRelease
 http://ftp.debian.org/debian/dists/testing/main/binary-i386/Packages.diff/*

It would then be possible to reverse apply the diff, and validate the
packages when needed. The disk-space cost would be quite low. Currently,
that's 448K for 6 days (27MB/year), which is quite cheap compared to
cached binaries that have to be preserved too.

(And it comes to my mind that it might be possible to implement some
roll-back feature... If we were supporting to downgrade packages to some
extend;)

I have no strong preferences between signed APT and SIGNED DEBs... it is
just that the remaining of the thread showed that signed DEBs are quite
tough to implement. (and I still wonder how we could preserve the
current deb format with "tar.gz in ar", while signing the debs)

That's 2 more cents from me,

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1268956013.11872.58.ca...@solid.paris.klabs.be

Re: Bug#540215: Introduce dh_checksums

[Russ Allbery]

Frank Lin PIAT  writes:

> I have no strong preferences between signed APT and SIGNED DEBs... it is
> just that the remaining of the thread showed that signed DEBs are quite
> tough to implement. (and I still wonder how we could preserve the
> current deb format with "tar.gz in ar", while signing the debs)

You add an additional ar member that contains the signed checksums of all
of the files in data.tar.gz, possibly another additional member that
contains the signed checksums for control.tar.gz, or you document some
convention so that you can combine both into the same signed checksum
document.

There are other implementation methods possible, but that's probably the
most obvious one.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871vfhchnc@windlord.stanford.edu

Work-needing packages report for Mar 19, 2010

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 576 (new: 1)
Total number of packages offered up for adoption: 130 (new: 1)
Total number of packages requested help for: 64 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   ccontrol (#574013), orphaned 3 days ago
 Description: Compilation controller
 Installations reported by Popcon: 86

575 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   xpp (#573876), offered 4 days ago
 Description: X Printing Panel
 Reverse Depends: mseide
 Installations reported by Popcon: 879

129 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] gwibber (#573822), requested 4 days ago
 Description: microblogging client for GNOME
 Installations reported by Popcon: 359

   apt-cross (#540341), requested 223 days ago
 Description: retrieve, build and install libraries for
   cross-compiling
 Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa
   emdebian-rootfs emdebian-tools libemdebian-tools-perl
 Installations reported by Popcon: 323

   apt-xapian-index (#567955), requested 45 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache
 Installations reported by Popcon: 6028

   ara (#450876), requested 858 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 112

   asymptote (#517342), requested 384 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 1222

   athcool (#278442), requested 1969 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 154

   blender (#570053), requested 30 days ago
 Description: Very fast and versatile 3D modeller/renderer
 Reverse Depends: blender-ogrexml
 Installations reported by Popcon: 3165

   boinc (#511243), requested 434 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1678

   cron (#565143), requested 64 days ago
 Description: process scheduling daemon
 Reverse Depends: apticron autolog backintime-common buildd
   checksecurity cricket dtc-common email-reminder exim4-base fiaif (19
   more omitted)
 Installations reported by Popcon: 91574

   cvs (#354176), requested 1484 days ago
 Description: Concurrent Versions System
 Reverse Depends: autopoint crossvc cvs-autoreleasedeb
   cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd
   cvsps (11 more omitted)
 Installations reported by Popcon: 25357

   dctrl-tools (#448284), requested 873 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
   simple-cdd ubuntu-dev-tools
 Installations reported by Popcon: 13646

   debtags (#567954), requested 45 days ago
 Description: Enables support for package tags
 Reverse Depends: debtags-edit goplay packagesearch
 Installations reported by Popcon: 2738

   dietlibc (#544060), requested 202 days ago
 Description: diet libc - a libc optimized for small size
 Reverse Depends: libowfat-dev
 Installations reported by Popcon: 241

   doc-central (#566364), requested 54 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 296

   dpkg (#282283), requested 1943 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: acct adacontrol advi advi-examples alien alqalam
   alsa-source am-utils-doc apt-build apt-cross (491 more omitted)
 Installations reported by Popcon: 91668

   elvis (#432298), requested 983 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 410

   emdebian-tools (#540333), requested 223 days ago
 Description: emdebian crossbuilding tool set
 Reverse Depends: emdebian-buildsupport emdebian-qa emdebian-rootfs
   emdebian-tool

uploads to experimental

[Brian May]

Hello,

How do I make uploads to experimental?

I thought this putting experimental in the changelog was sufficient:

=== cut ===
 heimdal (1.4.0~git20100221.dfsg.1-2) experimental; urgency=low
 .
   * Update debshlibs dependancies. Anything compiled against the
 version of Heimdal in experimental will require the libraries from
 experimental. May not strictly be required for all libraries, but
 better be safe then sorry.
   * This also will resolves a bug for the experimental version that has
 already been solved in stable (closes: 571206).
=== cut ===

However the upload appears to have gone to unstable instead of experimental.

Is this because I used sbuild to build the package against a sid chroot?

How do I fix this mess up?

Thanks
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3c5cf5261003181758r2db6b8efs5c9c9978e2380...@mail.gmail.com

Re: uploads to experimental

[Russ Allbery]

Brian May  writes:

> How do I make uploads to experimental?

> I thought this putting experimental in the changelog was sufficient:

> === cut ===
>  heimdal (1.4.0~git20100221.dfsg.1-2) experimental; urgency=low
>  .
>* Update debshlibs dependancies. Anything compiled against the
>  version of Heimdal in experimental will require the libraries from
>  experimental. May not strictly be required for all libraries, but
>  better be safe then sorry.
>* This also will resolves a bug for the experimental version that has
>  already been solved in stable (closes: 571206).
> === cut ===

> However the upload appears to have gone to unstable instead of experimental.

The only thing that matters to the archive software is what distribution
is listed in the *.changes file.  Normally, this is taken from the
changelog.  I'm not sure why it would have been set to sid in this case,
but looking in the PTS at heimdal, you can see that the *.changes file
associated with the upload says sid.

> How do I fix this mess up?

Unfortunately, to get back to 1.3 in unstable, you have to upload
something with a higher version number than the upload that was supposed
to go to experimental, which means either using an epoch or an artificial
version number that's higher than the one above.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxy5un0m@windlord.stanford.edu

Re: uploads to experimental

[Ryan Niebur]

On Thu, Mar 18, 2010 at 06:18:49PM -0700, Russ Allbery wrote:
> Brian May  writes:
> 
> > How do I make uploads to experimental?
> 
> > I thought this putting experimental in the changelog was sufficient:
> 
> > === cut ===
> >  heimdal (1.4.0~git20100221.dfsg.1-2) experimental; urgency=low
> >  .
> >* Update debshlibs dependancies. Anything compiled against the
> >  version of Heimdal in experimental will require the libraries from
> >  experimental. May not strictly be required for all libraries, but
> >  better be safe then sorry.
> >* This also will resolves a bug for the experimental version that has
> >  already been solved in stable (closes: 571206).
> > === cut ===
> 
> > However the upload appears to have gone to unstable instead of experimental.
> 
> The only thing that matters to the archive software is what distribution
> is listed in the *.changes file.  Normally, this is taken from the
> changelog.  I'm not sure why it would have been set to sid in this case,
> but looking in the PTS at heimdal, you can see that the *.changes file
> associated with the upload says sid.
> 

It may have something to do with this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559659

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Bug#574563: ITP: haskell-monoid-transformer -- Transformers for Reader and State Monoids

[USB]

Package: wnpp
Severity: wishlist
Owner: "Ernesto Hernández-Novich (USB)" 


* Package name: haskell-monoid-transformer
  Version : 0.0.2
  Upstream Author : Henning Thielemann 
* URL : http://hackage.haskell.org/packages/monoid-transformer
* License : BSD
  Programming Lang: Haskell
  Description : Transformers for Reader and State Monoids

This library provides Monoid Transformers for the Reader Monoid and
the State Monoid. There's no Monoid Transformer for the Writer Monoid
since the Writer Monad transforms a Monoid into a Monad.

This is a building dependency for Haskore, a Haskell DSL and combinator
library for music manipulation and generation.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (900, 'stable'), (1, 'experimental')
Architecture: i386 (i686)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100319011200.22029.70608.report...@deepthought.itverx.com.ve

Re: Suggestion to developer tools

[Luke Cycon]

On Thu, 2010-03-18 at 17:32 -0500, ceduardo wrote:
> Hi every body, thaks you for your suggestions.
> 
> Well I am learning about C, C++ and Linux programing, jeje I am trying
> to be a Debian developer this is my objetive. On my practices use
> emacs and others tools from console.
> 
> What Do you developer tools sugges? 

*If* I understand what you are asking (For suggestions for development
tools), you have got some of the main ones.

When I need/want a nice GUI for when I am feeling lazy, I use Eclipse
(Available in the repos, though there are newer version out there).

Other than that, a nice console text editor and the compiler (In C/C++'s
case) is a very powerful development environment.

All in all, it is a matter of choice.  Do you like a more GUI-centric
style of programming?  Or are you comfortable using command line tools?

Again, sorry if I misunderstood the question.

(I am CCing you on the off chance that you may not be subscribed to this
list, sorry if you are (Somewhat of a generalization, I see many of
these questions asked by people not subscribed to the list.))

Thanks,
-- 
Luke Cycon 



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

Re: uploads to experimental

[Brian May]

On 19 March 2010 12:25, Ryan Niebur  wrote:
> It may have something to do with this:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559659

No, possibly more likely:



Except the justification given is wrong. I want to be able to pick the
schroot manually and have it automatically determine the distribution
for the changes file after building the package.

According to the man page in my version of sbuild:

   -d, --dist=distribution
  Fetch source packages from specified distribution.

However this documentation doesn't say this will also override the
distribution used in the changes file. Maybe it should also complain
if the distribution in the changes file doesn't match that in the log
file.

In this case I want to build against sid but still use experimental.

I see there is a --chroot option to sbuild, however I am not really
sure what it does, it doesn't seem to take an option (???):

   -c, --chroot
  Use  the  specified  chroot.  If  not  specified,  the
default is the first of $distribution-$arch-sbuild, $distribu-
  tion-sbuild, $distribution-$arch or $distribution that exists.

-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3c5cf5261003181910w7d4bd396p7b629da95e292...@mail.gmail.com

Re: uploads to experimental

[Cyril Brulebois]

Brian May  (19/03/2010):
> According to the man page in my version of sbuild:
>-d, --dist=distribution
>   Fetch source packages from specified distribution.
> 
> However this documentation doesn't say this will also override the
> distribution used in the changes file. Maybe it should also complain
> if the distribution in the changes file doesn't match that in the log
> file.

http://lists.debian.org/debian-devel/2010/02/msg00624.html gives a
slight idea, but indeed, NEWS.Debian + manpage fix would help, I
guess.

> In this case I want to build against sid but still use experimental.
> 
> I see there is a --chroot option to sbuild, however I am not really
> sure what it does, it doesn't seem to take an option (???):
> 
>-c, --chroot
>   Use  the  specified  chroot.  If  not  specified,  the
> default is the first of $distribution-$arch-sbuild, $distribu-
>   tion-sbuild, $distribution-$arch or $distribution that exists.

It says “specified”, one could think it's specified... as an argument
to this option? But usage probably should be clarified.

Anyway, there you go:
| k...@bowmore:/tmp$ sbuild -c sid-amd64-sbuild -d experimental 
gtk2-engines_2.18.5-2.dsc
| […]
| Chroot Build Dir: 
/opt/sid-amd64-sbuild/build/kibi-gtk2-engines_2.18.5-2-amd64-efx3bT
| […]
| k...@bowmore:/tmp$ grep ^Distribution gtk2-engines_2.18.5-2_amd64.changes
| Distribution: experimental

Mraw,
(kinda-experimental-related-screw-ups-specialist-)KiBi.


signature.asc
Description: Digital signature

Re: Suggestion to developer tools

[ceduardo]

2010/3/18 Luke Cycon :
> On Thu, 2010-03-18 at 17:32 -0500, ceduardo wrote:
>> Hi every body, thaks you for your suggestions.
>>
>> Well I am learning about C, C++ and Linux programing, jeje I am trying
>> to be a Debian developer this is my objetive. On my practices use
>> emacs and others tools from console.
>>
>> What Do you developer tools sugges?
>
> *If* I understand what you are asking (For suggestions for development
> tools), you have got some of the main ones.

I wanted to know aobut the typicals develoment toolt that you use.

> When I need/want a nice GUI for when I am feeling lazy, I use Eclipse
> (Available in the repos, though there are newer version out there).

I have Eclipse installed but I don't use this for C/C++, but It is a
good idea to try with this one. I am testing NetBeans IDE but I want
to know your suggestions.

> Other than that, a nice console text editor and the compiler (In C/C++'s
> case) is a very powerful development environment.
>
The powerfull, vi, vim, gcc, g++, gdb and the others that I don't know
in this moment.
> All in all, it is a matter of choice.  Do you like a more GUI-centric
> style of programming?  Or are you comfortable using command line tools?
>

> Again, sorry if I misunderstood the question.
>
Don't worry your message  can help me in my way
> (I am CCing you on the off chance that you may not be subscribed to this
> list, sorry if you are (Somewhat of a generalization, I see many of
> these questions asked by people not subscribed to the list.))
>
> Thanks,
> --
> Luke Cycon 
>
>

Thanks.

-- 
ceduardo


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/c068e3701003182012m57524ad3h86fe4abe617ee...@mail.gmail.com

Re: uploads to experimental

[Brian May]

On 19 March 2010 13:24, Cyril Brulebois  wrote:
> | k...@bowmore:/tmp$ sbuild -c sid-amd64-sbuild -d experimental 
> gtk2-engines_2.18.5-2.dsc

What happens if you omit the -d and only have -c?
-- 
Brian May 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3c5cf5261003182028k125c5556mfb3f6ebe33f38...@mail.gmail.com

Bug#574567: ITP: gdevilspie -- A user friendly interface for devilspie

[Chris Silva]

Package: wnpp
Severity: wishlist
Owner: Chris Silva 


* Package name: gdevilspie
  Version : 0.31
  Upstream Author : Islam Amer 
* URL : http://code.google.com/p/gdevilspie/downloads/list
* License : GPL-2
  Programming Lang: Python
  Description : A user friendly interface for devilspie

A user friendly interface to the devilspie window matching
daemon, to create rules easily.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100319030746.21171.31737.report...@chris.makeworld.com

Re: uploads to experimental

[Cyril Brulebois]

Brian May  (19/03/2010):
> On 19 March 2010 13:24, Cyril Brulebois  wrote:
> > | k...@bowmore:/tmp$ sbuild -c sid-amd64-sbuild -d experimental 
> > gtk2-engines_2.18.5-2.dsc
> 
> What happens if you omit the -d and only have -c?

As already pointed out in [1]: #559659, which resulted in what's
described in the 1st point of [2], which I mentioned in my previous
mail.

 1. http://lists.debian.org/debian-devel/2010/03/msg00597.html
 2. http://lists.debian.org/debian-devel/2010/02/msg00624.html

Anyway, for the sake of completeness: “No distribution defined”.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Suggestion to developer tools

[Luke Cycon]

On Thu, 2010-03-18 at 22:12 -0500, ceduardo wrote:
> 
> I wanted to know aobut the typicals develoment toolt that you use.
> 
I mainly use eclipse or gedit or a command line text editor (Depending
on my mood)

I suggest you learn how to use these as well, they allow for much
customization.
> 
> I have Eclipse installed but I don't use this for C/C++, but It is a
> good idea to try with this one. I am testing NetBeans IDE but I want
> to know your suggestions. 

I prefer Eclipse over NetBeans for all of my development because I feel
that NetBeans is a bit to "bloaty"

As I said, this is a matter of preference.  I can't really tell you what
you will like best ;)
-- 
Luke Cycon 


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

Bug#574569: ITP: clamz -- A command-line program to download MP3's from Amazon

[Chris Silva]

Package: wnpp
Severity: wishlist
Owner: Chris Silva 


* Package name: clamz
  Version : 0.2
  Upstream Author : Benjamin Moody 
* URL : http://code.google.com/p/clamz/
* License : GPL-3
  Programming Lang: C
  Description : A command-line program to download MP3's from Amazon

Clamz is intended to serve as a substitute for Amazon's official
MP3 Downloader, which is not free software. Clamz can be used to
download either individual songs or complete albums that you have
purchased from Amazon.
Usage:
When you buy a single song from Amazon, you have the option
to either download it in your web browser (the default behavior)
or via the MP3 Downloader. When you buy an album, Amazon gives
you no choice: you must enable the MP3 Downloader.

To enable the MP3 downloader in the web store, visit the URL
http://www.amazon.com/gp/dmusic/after_download_manager_install.html
(Ignore all the instructions on that page, of course.)  This works
by setting a cookie in your browser; it seems to be completely
separate from your Amazon account.

In any case, when you actually go to download the file(s), if the
appropriate cookie is set you will be directed to open or download
an AMZ file.  This file is basically just an encrypted list of URLs
plus additional information (artist, title, and so forth) about the
songs.

Save the AMZ file somewhere, and run clamz on it; by default this will
just download all of the linked files into the current directory.
More control over where the files are downloaded and how they are named is
available via the command line, as well as the configuration
file, ~/.clamz/config.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100319032904.22835.78208.report...@chris.makeworld.com

plz adddd me

[saugata chakraborty]