Re: rm -rf /usr/somedir in maintainer scripts?

[Tollef Fog Heen]

]] Russ Allbery 

> A package that wants to change a directory to a symlink (or vice versa) is
> a very special case, and one that runs afoul of dpkg support for the local
> system administrator moving and symlinking directories (something that can
> be quite useful if one screws up disk partitioning or runs out of disk
> space in the / or /usr partition, which admittedly is getting less common
> on typical servers and desktops but can still be an issue for smaller
> devices).

Now that we have well working bind mounts, we could actually deprecate
the old way and just tell people to use bind mounts instead.  At least
if our non-Linux ports has decent support for it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87r4pid6rq@qurzaw.varnish-software.com

Bug#689279: ITP: erlang-bitcask -- Log-Structured Hash Table for Fast Key/Value Data

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: erlang-bitcask
  Version : 1.1.6
  Upstream Author : Basho Technologies
* URL : https://github.com/basho/bitcask
* License : Apache 2.0
  Programming Lang: erlang
  Description : Log-Structured Hash Table for Fast Key/Value Data

  Bitcask is an Erlang application that provides an API for storing and
  retrieving key/value data into a log-structured hash table that
  provides very fast access. The design owes a lot to the principles
  found in log-structured file systems and draws inspiration from a
  number of designs that involve log file merging.


-- 
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/20121001035528.21900.57393.reportbug@chimagu

Bug#689277: ITP: pd-chaos -- Pd library for calculating various chaotic attractors

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 


* Package name: pd-chaos
  Version : 0.1
  Upstream Author : Ben Bogart  and Michael McGonagle   

* URL : http://puredata.info/downloads/chaos
* License : GPLv2+
  Programming Lang: C
  Description : Pd library for calculating various chaotic attractors

 chaos is a library of Pd objects for calculating various chaotic attractors,
 including: lorenz, rossler, henon, ikeda, attract1, base, base3, dejong,
 gingerbreadman, hopalong, latoocarfian, latoomutalpha, latoomutbeta,
 latoomutgamma, logistic, lotka_volterra, martin, mlogistic, pickover,
 popcorn, quadruptwo, standardmap, strange1, tent, three_d, threeply,
 tinkerbell and unity.
 .
 The package includes 1, 2 and 3 dimentional attractors. There are outlets for
 each dimention, starting from the left, followed by three outlets for
 attractor data (see the help patches for details). The scale of the values
 vary between the different attractors.
 .
 Some of the algorithms were derived from other projects, including Julian
 C. Sproutt's attract.java and algorithms by Cliff Pickover.


-- 
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/20121001022550.25269.87221.report...@blinky.at.or.at

Re: Debian not suitable for SSD due to apt/dpkg?

[Chow Loong Jin]

On 30/09/2012 18:49, Frank Bauer wrote:
> Why not, my computer upgrade cycles are about 6-8 years and the
> computer won't be idling all the time - especially considering modern
> desktop environments running whole database engines to store
> config/meta data.
> 
> Is writing of 160GB/day realistic? Hopefuly not, but see my apt
> measurements below.
> 
> There is also something called SSD write amplification - the erase
> blocks on the device are often larger than your normal filesystem
> blocks, which might lead to up to 10x data actually writen to SSD,
> i.e. down to 1.3years of overwrites in the extreme case.

Have you done any actual calculation on this? A quick Google search on SSD write
cycles shows more articles debunking this theory than supporting it.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: thoughts on using multi-arch based cross-building

[Wookey]

+++ peter green [2012-09-30 15:34 +0100]:
> I've been attempting to use multi-arch for cross-building packages
> for raspbian (a debian derivative I am working on for armv6
> hardfloat) and run into a few things which I thought i'd share
> and/or ask about.

I've been doing a fair amount of this too. Some results for unstable
and quantal are here:
http://people.linaro.org/~wookey/buildd/

> Build-depends installation:
> apt-get build-dep is fine if you are building an unmodified package
> from a repo but it's of no use if you have modified the
> build-dependencies to make them satisfiable.

Annoying isn't it? This has been irritating me for years. 
/usr/lib/pbuilder-satisfydepends-classic is very useful for the
native-build case, but I am not aware of a multiarch-aware tool. A
tool like this should really be in devscripts.

> dpkg-checkbuilddeps doesn't tell me what architecture the packages
> need to be for and i'm not sure it can (since to do so it would need
> to know whether packages that are not installed are multi-arch
> foreign or not).
> 
> Does a tool exist that can be told "install the build-depends needed
> to build the debianised source tree in directory x for architecture
> y"? if not IMO such a tool (or a new option in an existing tool)
> needs to be created.

The dose3 tools can produce the same answers as apt for this problem,
and could quite easily be modified to look at a local source package
rather than only at packages files. Johannes Schauer was looking into
doing this a couple of weeks ago. Any joy Johannes?

I don't know how hard it is to get apt have a 'use the source in front
of you instead' option. That would guarantee consistency but is
somewhat antithetical to the way apt works. (all about archives, not
local sources).

> Pkg-config:
> A soloution needs to be found for this, so-far I have worked arround
> by hacking the package to be multi-arch foreign and then manually
> creating the symlink to the crosswrapper but there has to be a
> better soloution.

Yes. So in ubuntu the gcc-defaults- package produces a trivial
pkg-config- package which depends on pkg-config and install
the appropriate symlink.

I don't much like a package for each symlink, even though it's simple. 

Discussion at debconf suggested that for debian a cross-support
package should do this sort of thing. Currently dpkg-cross provides
per-arch autoconf variables, so getting it to stick in the pkg-config
link too seems sensible. At some point (after wheezy) it should be
renamed to cross-support and drop it's existing
library-package-mangling functionality. 

I have just created (following on from PJ McDermott's GSOC work) a
cross-build-essential source package that makes crossbuild-essential-
packages to bring in cross-gcc, cross-g++, dpkg-cross (aka
cross-support) pkg-config-. That in this PPA:
https://launchpad.net/~linaro-foundations/+archive/cross-build-tools
and needs some dpkg-vendor foo adding to make it right for both debian
and ubuntu. 

> Packages that need a specific gcc version:
> Sometimes packages need to be built using a non-default gcc version.
> We would rather they didn't but i'm sure there will always be such
> cases.
> 
> Conventionally in such cases I've added a build-depends on
> gcc- version and then set CC to gcc- but this
> obviously isn't suitable for cross-building.
> 
> Setting the CC environment variable is easy to fix (set it to
> -gcc- which afaict is fine for both native and
> cross building)

it is, and has been since gcc-4.4 in squeeze at least. 

> but I can't think of a good and simple soloution to
> the build-dependency problem since the package name for the
> cross-compiler depends on the architecture.

Hmm, I see what you mean. Build-essential brings in 'latest compiler'
and crossbuild-essential bring in 'latest cross-compiler'. Ideally
something would note the native build-dep on a specific not-latest
native compiler and bring in (or at least try to use) the
corresponding cross-compiler. I'm not sure what that something might
be. 

I think a good brainstorm is required on this whole subject,
because we have the clang/gcc issue and the cross/native issue and the gcc
version issue which all require 'compiler selection'. I'd like to
think that there was a good way to do this but I'm not at all sure
what is best. Solutions for one of these cases shouldn't break the
others, and I don't think we've achieved that yet. 

Default compiler selections is currently messy for toolchains:
_something_ in the system has to set the gcc- link to point
at gcc-. This is done by gcc-defaults in the native
case and gcc-defaults- for ubuntu toolchains, and using
alternatives mechanism for debian toolchains. I have been told why the
gcc-defaults mechanism is preferred over alternatives, but I've
fogotten. 

> Arch all development dependency packages:
> In debian there are some development dependency packages, typically
> packages that depend on the latest version of a library. Since these
> packag

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Stefano Zacchiroli]

On Sun, Sep 30, 2012 at 06:10:16PM +, Bart Martens wrote:
> > I don't know what to make of the "seconds" suggestion by Bart, though. I
> > understand the rationale, but is not clear to me how to raise the
> > interest by other DDs in reviewing the "intent to orphan" bugs filed by
> > 3rd parties. Maybe we should document to post them on -qa? That *might*
> > have the side-effect of fostering the creation of a review community for
> > these kind of actions on -qa. Mumble mumble...
> 
> Posting them on -qa sounds like a good idea to me.  Can you elaborate on that
> "side-effect" ? I don't understand that part.

I just meant that if we encourage to post seconds (which are in fact
just a form of review of the intention to orphan) on a list such as -qa
(which is more specific-purpose than, say, -devel), we might end up
attracting there people who have an interest in doing this sort of
package quality review. That sounds like a useful side-effect to me. But
I'm still unsure about the benefits of the seconds principle, though.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: rm -rf /usr/somedir in maintainer scripts?

[Russ Allbery]

Nikolaus Rath  writes:
> Tollef Fog Heen  writes:
>> ]] Nikolaus Rath 

>>> How do I check if a directory belongs to a package?

>> dpkg -S ?

> I guess you shouldn't have used "belongs" but "owns" here. For example,
> for /usr/share/dict dpkg -S lists wamerican, base-files and
> dictionaries-common. How do I find out which of these owns this
> directory and may rm -rf it?

This is not normally a thing that you would ever do, which is why that
answer is hard to come by.  Normally, in Debian, packages own files, and
directories appear and disappear based on whether the package has to put a
file in that directory.  (Yes, the directories themselves are also
included in the package, but it's not normally a useful conceptual model
for the *intent* of the package.)  There are some cases where the package
intends to ship an empty directory, often in /var for run-time state, but
this is the exception rather than the common case, and it's particularly
uncommon in /usr.

A package that wants to change a directory to a symlink (or vice versa) is
a very special case, and one that runs afoul of dpkg support for the local
system administrator moving and symlinking directories (something that can
be quite useful if one screws up disk partitioning or runs out of disk
space in the / or /usr partition, which admittedly is getting less common
on typical servers and desktops but can still be an issue for smaller
devices).

The most accurate statement about this case is probably "this change is
not fully supported by the current Debian packaging tools."  I don't think
it's something for which we currently have easy answers.  It may require
either some design work or some case-by-case analysis.

-- 
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/87y5jr6wdl@windlord.stanford.edu

Re: rm -rf /usr/somedir in maintainer scripts?

[Nikolaus Rath]

Tollef Fog Heen  writes:
> ]] Nikolaus Rath 
>
>> How do I check if a directory belongs to a package?
>
> dpkg -S ?

I guess you shouldn't have used "belongs" but "owns" here. For example,
for /usr/share/dict dpkg -S lists wamerican, base-files and
dictionaries-common. How do I find out which of these owns this
directory and may rm -rf it?


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/87pq535k5u@vostro.rath.org

Re: rm -rf /usr/somedir in maintainer scripts?

[Tollef Fog Heen]

]] Nikolaus Rath 

> How do I check if a directory belongs to a package?

dpkg -S ?

> What should package do if it wants to install a file in a directory
> owned by another package?

The maintainers should talk with each other and come to some sort of
agreement.  What they decide on should be documented in some kind of
policy document, typically shipped in the «owning» package.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87y5jrgy67@xoog.err.no

Bug#689241: ITP: libconfig-model-dpkg-perl -- editor for Dpkg source files with validation

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libconfig-model-dpkg-perl
  Version : 2.026
  Upstream Author : Dominique Dumont 
* URL : FIXME
* License : LGPL-2.1+
  Programming Lang: Perl
  Description : editor for Dpkg source files with validation

The command 'cme edit dpkg' provide a graphical editor for most files
of a package source.

The command 'cme chek dpkg' provide a command line that will check the
package file, a bit like lintian. But this command must be run in the
source package directoty and can be run before building the package.

Likewise, the command 'cme fix dpkg' will fix most of the warnings
found by the command above.

You can also run cme with a more restricted scope with:
 * cme edit|check|fix dpkg-control
 * cme edit|check|fix dpkg-copyright

This package is a spin off from libconfig-model-perl. Done by upstream author.

Dominique


-- 
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/201209302008.40869@debian.org

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Bart Martens]

On Sun, Sep 30, 2012 at 06:33:58PM +0200, Stefano Zacchiroli wrote:
> As a general principle, I'm with Bart here.  I don't think we will
> benefit from a new, relatively complex, procedure that overlaps with
> other existing mechanisms.
> 
> Socially, we need to acknowledge the fact that the current procedure to
> orphan packages might be too heavyweight, and too coarse-grained, to
> efficiently deal with the frequent situation where maintainers lose
> interest in specific packages.
...
> I don't know what to make of the "seconds" suggestion by Bart, though. I
> understand the rationale, but is not clear to me how to raise the
> interest by other DDs in reviewing the "intent to orphan" bugs filed by
> 3rd parties. Maybe we should document to post them on -qa? That *might*
> have the side-effect of fostering the creation of a review community for
> these kind of actions on -qa. Mumble mumble...

Posting them on -qa sounds like a good idea to me.  Can you elaborate on that
"side-effect" ? I don't understand that part.

Regards,

Bart Martens


-- 
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/20120930181016.ge2...@master.debian.org

Re: rm -rf /usr/somedir in maintainer scripts?

[Nikolaus Rath]

gregor herrmann  writes:
> On Sat, 29 Sep 2012 20:29:09 -0400, Nikolaus Rath wrote:
>
>>  I've solved that in the
>>  preinst script by 'rm -rf /usr/include/libfm' and I thought yet that was
>>  a right step since upgrade 1.0.1 -> 1.0.2 went smooth.
>> >>>Somehow that sounds like a really bad idea to me. Admittedly manually
>> >>>placing some file in /usr/include/libfm is pretty ugly, but I would
>> >>>still certainly not expect that upgrading the libfm package would remove
>> >>>it.
>> >>>Is that really good practice? Can packages "own" a directory, so that
>> >>>anything that the local admin puts there may be removed automatically?
>
> Yes, there's no guarantee that a directory belonging to a package
> will be there after the next upgrade.

How do I check if a directory belongs to a package?

What should package do if it wants to install a file in a directory
owned by another package?


Thanks,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/87obknwgmq@vostro.rath.org

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Arno Töll]

Hi,

On 30.09.2012 18:33, Stefano Zacchiroli wrote:
> As a general principle, I'm with Bart here.  I don't think we will
> benefit from a new, relatively complex, procedure that overlaps with
> other existing mechanisms.

As for me, I am fine with *any* proposal which works out in practice.
Bei it mine, Bart's or any other. I just hope to find consensus in a
practice eventually.

> I don't know what to make of the "seconds" suggestion by Bart, though. I
> understand the rationale, but is not clear to me how to raise the
> interest by other DDs in reviewing the "intent to orphan" bugs filed by
> 3rd parties. Maybe we should document to post them on -qa? That *might*
> have the side-effect of fostering the creation of a review community for
> these kind of actions on -qa. Mumble mumble...

I do not think the seconding is a good idea as a rationale to justify a
salvage/hijack. In my proposal I tried to avoid social side-effects by
providing a measurable quantity to determine when a package is orphaned.
If we rely on Debian Members to second a proposal I see these problems
mainly:

* We are effectively ruling out opinions of non-members. That's bizarre,
since we allow them to maintain (and even "hijack") packages. Why
wouldn't we allow them to second an attempt to hand someone else the
maintainership of a package? On the other hand, we cannot allow any
random someone to make binding votes, given impersonating identities on
the Internet is no challenge at all

* Seconding a proposal does not say anything about their rightfulness.
I'm pretty sure to find three seconds for almost any (not so) stupid
idea in Debian, even if 25 people may oppose it.

* On the other hand, it won't be a problem either to find (almost) any
number of people opposing a plan. Especially if we talk about a
controversial idea like that.

* If we rely on social metrics ("I think this your attempt is legit")
instead of quantifiable numbers ("Your attempt is legit because it
fulfills criterion X") it is pretty clear, we will end up in a dispute
over an individual case soon(er or later).


However, if we do not add a constraint which needs to be passed (be it a
time based constraint or seconding an intent by someone else) we haven't
won anything over the status quo: File an intent to salvage/hijack a
package, wait if people complain loud enough. We would still be in a
legal gray area, where it is not clear whether one is allowed to salvage
a package from a bad maintainership.

I think the most important rationale is to get people not to be afraid
to take over packages anymore, if their intentions are meant well.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

[Stefano Zacchiroli]

On Fri, Sep 28, 2012 at 05:52:23PM +, Bart Martens wrote:
> On Fri, Sep 28, 2012 at 06:48:22PM +0200, Arno Töll wrote:
> > Actual proposal follows:
> 
> The proposal adds a new procedure that overlaps/bypasses existing procedures.
> 
> We have discussed that before in this thread :
> http://lists.debian.org/debian-devel/2012/07/msg00540.html
> 
> What we essentially need, is a lightweight procedure to orphan individual
> packages.  I propose this :
[…]
> After the package is orphaned, the rest of the "salvaging" fits in the 
> existing
> procedures.

As a general principle, I'm with Bart here.  I don't think we will
benefit from a new, relatively complex, procedure that overlaps with
other existing mechanisms.

Socially, we need to acknowledge the fact that the current procedure to
orphan packages might be too heavyweight, and too coarse-grained, to
efficiently deal with the frequent situation where maintainers lose
interest in specific packages.  Procedurally, we need rule of thumbs
that empower more active and interested maintainers to understand when
they can go on. And we need to favor the current maintainers if they
show up again *doing* something on the packages in question.

Also, I've grown weary of procedures with several steps, each of which
with delays. In my (now fairly extensive) experience in promoting what
have been called "liberal NMUs", I think I've learned that the key is
empowering motivated people right there, when they are active and
interested. Ask them to wait in several steps, for several weeks, and
most of them will probably lose interest and move on.

Of course we need *some* waiting time for orphaning by 3rd-parties, but
IMHO we should not require more than a reasonable time frame before
acting + a long DELAYED/XX value. After that, waiting (for the
DELAYED/XX value to expire) should result in the desired behavior,
i.e. salvaged package.

I don't know what to make of the "seconds" suggestion by Bart, though. I
understand the rationale, but is not clear to me how to raise the
interest by other DDs in reviewing the "intent to orphan" bugs filed by
3rd parties. Maybe we should document to post them on -qa? That *might*
have the side-effect of fostering the creation of a review community for
these kind of actions on -qa. Mumble mumble...

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: thoughts on using multi-arch based cross-building

[James McCoy]

On Sun, Sep 30, 2012 at 03:34:18PM +0100, peter green wrote:
> Build-depends installation:
> apt-get build-dep is fine if you are building an unmodified package
> from a repo but it's of no use if you have modified the
> build-dependencies to make them satisfiable.
> 
> dpkg-checkbuilddeps doesn't tell me what architecture the packages
> need to be for and i'm not sure it can (since to do so it would need
> to know whether packages that are not installed are multi-arch
> foreign or not).
> 
> Does a tool exist that can be told "install the build-depends needed
> to build the debianised source tree in directory x for architecture
> y"? if not IMO such a tool (or a new option in an existing tool)
> needs to be created.

See mk-build-deps(1) from devscripts.  For example:

  mk-build-deps -a y -i -s sudo -r x/debian/control

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

thoughts on using multi-arch based cross-building

[peter green]

I've been attempting to use multi-arch for cross-building packages for 
raspbian (a debian derivative I am working on for armv6 hardfloat) and 
run into a few things which I thought i'd share and/or ask about.



Build-depends installation:
apt-get build-dep is fine if you are building an unmodified package from 
a repo but it's of no use if you have modified the build-dependencies to 
make them satisfiable.


dpkg-checkbuilddeps doesn't tell me what architecture the packages need 
to be for and i'm not sure it can (since to do so it would need to know 
whether packages that are not installed are multi-arch foreign or not).


Does a tool exist that can be told "install the build-depends needed to 
build the debianised source tree in directory x for architecture y"? if 
not IMO such a tool (or a new option in an existing tool) needs to be 
created.



Pkg-config:
A soloution needs to be found for this, so-far I have worked arround by 
hacking the package to be multi-arch foreign and then manually creating 
the symlink to the crosswrapper but there has to be a better soloution.



Packages that need a specific gcc version:
Sometimes packages need to be built using a non-default gcc version. We 
would rather they didn't but i'm sure there will always be such cases.


Conventionally in such cases I've added a build-depends on gcc- 
version and then set CC to gcc- but this obviously isn't 
suitable for cross-building.


Setting the CC environment variable is easy to fix (set it to 
-gcc- which afaict is fine for both native and cross 
building) but I can't think of a good and simple soloution to the 
build-dependency problem since the package name for the cross-compiler 
depends on the architecture.



Arch all development dependency packages:
In debian there are some development dependency packages, typically 
packages that depend on the latest version of a library. Since these 
packages don't contain anything that is actually architecture specific 
they are usually arch all. One example is tcl-dev.


The problem is that dpkg/apt always treat arch all packages the same as 
packages for the native architecture making these arch all packages 
useless for cross-building.


I see two possible soloutions to this
1: make those dependency packages arch any. This will take up a bit of 
archive space but since the packages in question are empty anyway it 
shouldn't be too bad.

2: introduce a concept of "effective architecture(s)" for arch all packages.


--
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/5068586a.50...@p10link.net

Re: Debian not suitable for SSD due to apt/dpkg?

[Игорь Пашев]

Relax :-)

It is a hardware problem.

Just keep doing your regular job till SDD become more robust.


-- 
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/CALL-Q8xFUS22ff1by=hxuqnd5gifmu5vdf5fh-tqblriwb3...@mail.gmail.com

Bug#689211: ITP: gcc-4.7-doc -- documentation for the GNU compilers (gcc, gobjc, g++, gcj, gnat, and gccgo)

[Guo Yixuan]

Package: wnpp
Severity: wishlist
Owner: Guo Yixuan 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org

* Package name: gcc-4.7-doc
  Version : 4.7.2-1
  Upstream Author : Free Software Foundation
* URL : http://gcc.gnu.org
* License : GFDL with front/back cover texts
  Programming Lang: mainly Texinfo
  Description : documentation for the GNU compilers (gcc, gobjc,
g++, gcj, gnat, and gccgo)

GCC's documents need an update, and I based my work on previous
maintainers of gcc-4.4-doc-non-dfsg: Nikita V. Youshchenko[1] and Samuel
Bronson[2].

[1] Nikita V. Youshchenko 
[2] Samuel Bronson 

This package contains documentation in manpage, info and pdf.


-- 
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/5068377d.9030...@gmail.com

Bug#689207: ITP: rust -- a safe, concurrent, practical language

[Luca Bruno]

Package: wnpp
Severity: wishlist
Owner: Luca Bruno 

* Package name: rust
  Version : 0.3.4
  Upstream Author : Graydon Hoare et al. 
* URL : http://http://www.rust-lang.org/
* License : MIT
  Programming Lang: C/C++, Rust
  Description : a safe, concurrent, practical language

 Rust is a curly-brace, block-structured expression language.
 It visually resembles the C language family, but differs significantly
 in syntactic and semantic details. Its design is oriented toward
 concerns of "programming in the large", that is, of creating and
 maintaining boundaries - both abstract and operational - that
 preserve large-system integrity, availability and concurrency.
 .
 It supports a mixture of imperative procedural, concurrent actor,
 object-oriented and pure functional styles. Rust also supports
 generic programming and metaprogramming, in both static and
 dynamic styles.


-- 
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/20120930112201.8443.24969.reportbug@localhost

Re: Debian not suitable for SSD due to apt/dpkg?

[Frank Bauer]

On Sat, Sep 29, 2012 at 11:15:45PM +0200, Bastian Blank wrote:
>
> If you have 5000 erase cycles, it will run for 13 years if you overwrite
> it once per day. Do you really expect this device to work until this?

Why not, my computer upgrade cycles are about 6-8 years and the
computer won't be idling all the time - especially considering modern
desktop environments running whole database engines to store
config/meta data.

Is writing of 160GB/day realistic? Hopefuly not, but see my apt
measurements below.

There is also something called SSD write amplification - the erase
blocks on the device are often larger than your normal filesystem
blocks, which might lead to up to 10x data actually writen to SSD,
i.e. down to 1.3years of overwrites in the extreme case.

> > iostat (part of sysstat) revealed, that simple apt-get update command
> > generated about 250MB of writes!
>
> How does it reveal this?

Running iostat -dm -p sda before and after apt-get, looking at the
MB_wrtn column.

Immediately after boot to xmonad:

Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn
sda  81,24 1,96 0,12175 10
sda1  3,38 0,01 0,00  1  0
sda2 64,64 1,89 0,12170 10
sda3  1,78 0,01 0,00  0  0
sda4  0,02 0,00 0,00  0  0
sda5  1,82 0,01 0,00  0  0
sda6  3,65 0,02 0,00  1  0
sda7  5,56 0,02 0,00  1  0

After running apt-get update after about a week (relevant device only,
focus on the last column):

Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn
sda2 42,66 0,75 4,32246   1413

so just updating the package info wrote 1.4GB of data (disabling pdiff
might help as you suggested)

After running apt-get upgrade (expected APT DL size: 87.2MB):

Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn
sda2 56,43 0,36 2,69317   2376

so installing 90 MB of packages produced about 900 MB of writes

Running apt-get update again (there is nothing to update right now),
about 40 MB of data are written in each subsequent run.

> Disable pdiffs, mount /var/cache/apt as tmpfs, so at least the packages
> are not written again.

Good call, thanks

Frank


-- 
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/CAPds5_KFZ+oHC5Z5iEErCPycP-yOEMq17FGuFQ=tmytwxr3...@mail.gmail.com