Bug#689388: ITP: erlang-proper -- QuickCheck-inspired property-based testing tool for Erlang

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: erlang-proper
  Version : 1.0
  Upstream Author : Manolis Papadakis 
Eirini Arvaniti 
Kostis Sagonas 
* URL : https://github.com/manopapad/proper.git
* License : GPLv3+
  Programming Lang: erlang
  Description : QuickCheck-inspired property-based testing tool for Erlang

PropEr (PROPerty-based testing tool for ERlang) is a QuickCheck-inspired
open-source property-based testing tool for Erlang.


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

Bug#689387: ITP: erlang-cherly -- Cherly (sher-lee) is an in-VM caching library for Erlang

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: erlang-cherly
  Version : 0.9.1
  Upstream Author : Cliff Moon, Yoshiyuki Kanno 
* URL : https://www.github.com/leo-project/cherly.git
Original upstream is https://github.com/cliffmoon/cherly.
* License : THE BEER-WARE LICENSE" (Revision 42)
  Programming Lang: erlang
  Description : Cherly (sher-lee) is an in-VM caching library for Erlang

Cherly (sher-lee) was originally developed by Cliff Moon for erlang to
deal with in memory caching based on LRU. Its functionality and performance
were awesome, but as time goes on, its implementation gradually obsoletes
and it's hard to maintain. To overcome these problems, I forked and made
Cherly improve with original purposes. Main improvements are described below.
  * Replaced the hash storing structure (originally used Judy
  * hash) with the  combination of Open addressing and Tree structure based
on golang's hash implementation. This structure is very scalable and stable.
  * Implemented slab allocator on off-heap.
  * Replaced implemantations of port driver with NIFs.
  * Rebarized


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

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

[Christian PERRIER]

Quoting Michael Hanke (m...@debian.org):

> I'm on an Intel SSD (120GB) since Aug 2009 -- running Debian testing all
> the time. I do not upgrade daily, but often. I have _not_ done any of
> the optimizations mentioned on the wiki. I have on average approx 15GB
> free on the drive. Obviously, I ran a kernel <3.2 for most of the time.
> I do lots of compiling on this SSD.


Exact same situation here, with a 64GB hard drive (often with a small
amount of free space). And I update daily. And I don't use "noatime".



signature.asc
Description: Digital signature

Bug#689381: Login screen fails to appear

[Jesse Rhodes]

reassign 689381 gdm3
thanks

Bug#689381: general: Login screen fails to appear, though you can still interact with it

[Gregory]

Package: general
Severity: important

After booting into Debian 6.0.6 the login screen fails to appear. This is an
intermittant problem.
I still hear the sound associated with the login screen and can interact with
it (eg enter my password and log in) but the screen itself is not visible. The
only thing visible is the default background colour.



-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)

Toshiba Notebook Satellite C650


-- 
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/20121002040542.2785.63974.reportbug@DebLap

New sip4 release with API bump

[Scott Kitterman]

The newest sip4 release, 4.14 increases the API version to 9.0.  Since it has 
potential incompatibilities, I've uploaded it to Experimental so maintainers 
of rdepends can investigate if changes are needed.  I hope to land this in 
unstable very shortly after Wheezy is released.

There are a few packages that use python-sip that have not converted to using 
dh_sip.  I'll add versioned breaks for those packages in the next sip4 upload.  
Here's a DD list for those:

Alastair McKinstry 
   vistrails

Andreas Tille 
   qtiplot (U)

Debian GIS Project 
   qgis

Debian Science Team 
   qtiplot

Francesco Paolo Lovergine 
   qgis (U)

Gudjon I. Gudjonsson 
   qtiplot (U)

Scott Howard 
   qtiplot (U)

For the dh_sip using packages, they aren't broken (in a packaging sense) by 
the new API version and should just need to be rebuilt (I've already taken 
care of python-qt4 and will deal with qscintilla2 as well):

Andreas Hildebrandt 
   ball (U)

Bernd Zeimetz 
   python-qt4 (U)

Daniel Leidert (dale) 
   avogadro (U)

Debian Med Packaging Team 
   ball

Debian Python Modules Team 
   pyqwt3d (U)
   pyqwt5 (U)
   python-qt4
   qscintilla2

Debian Qt/KDE Maintainers 
   pykde4

Debichem Team 
   avogadro

Gudjon I. Gudjonsson 
   pyqwt3d
   pyqwt5
   qscintilla2 (U)


Jeremy Sanders 
   veusz (U)

Joachim Breitner 
   serna-free

Martin Pitt 
   calibre (U)

Mathieu Malaterre 
   serna-free (U)

Michael Banck 
   avogadro (U)

Michael Casadevall 
   python-qt4 (U)

Michael Meskes 
   pykde4 (U)

Miriam Ruiz 
   calibre

Modestas Vainius 
   pykde4 (U)

Python Applications Packaging Team 
   veusz

Scott Kitterman 
   python-qt4 (U)
   qscintilla2 (U)

Sune Vuorela 
   pykde4 (U)

Torsten Marek 
   python-qt4 (U)
   qscintilla2 (U)


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

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Charles Plessy]

Le Mon, Oct 01, 2012 at 11:00:54PM +0200, Jakub Wilk a écrit :
> * Michael Tautschnig , 2012-10-01, 14:25:
> >>By policy, blank lines separate paragraphs, comments are
> >>discarded, so we end up with an empty first paragraph. Policy,
> >>however, requires that the *first* paragraph contains essential
> >>package information (Policy 5.2).
> 
> I'm not convinced by this interpretation the Policy. Common sense
> tells me that there's no such thing as "empty paragraph". So the
> question is: are empty liens allowed at the beginning of a control
> file?  I don't see an answer to that question in the Policy,
> unfortunately.

Indeed, the Policy does not consider that case.

This said, the format of the control data files is inspired from the RFC822,
which contains the following in its section 4.1:

 message =  fields *( CRLF *text )   ; Everything after
 ;  first null line
 ;  is message body

Another important factor for the Policy is the "current practice".  Before
proposing that empty lines are allowed or disallowed in control data files, I
think that we would need to survey what is done in Debian.  For instnace, is
gnome-pkg-tools an outlier, are there tools tolerating initial empty lines on
purpose, what is the situation for other control data files, etc.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20121001234804.ga12...@falafel.plessy.net

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Michael Tautschnig]

> Le lundi 01 octobre 2012 à 14:43 +0100, Ian Jackson a écrit : 
> > This wouldn't help people doing backports or whatever.  I think this
> > should be fixed in the packages involved.
> 
> Changing gnome-pkg-tools to replace the blank line with an empty comment
> is trivial. In unstable.
> 
> How does that help with backports?
> 

If gnome-pkg-tools were backported, any further backport build-depending on
gnome-pkg-tools would get fixed.

I think it is fair to say that this is a policy violation, but it clearly isn't
a *serious* policy violation, given its limited practical effect. I would ask
GNOME maintainers to get this fixed and uploaded, ideally also into t-p-u.

I'm going to file bugs against those packages not build-depending on
gnome-pkg-tools, but still containing comment+blank line at the start of
debian/control.

For all those packages build-depending on gnome-pkg-tools, I could then liaise
with the GNOME team to determine the best way forward.

Best,
Michael



pgpeJZMmzoRBc.pgp
Description: PGP signature

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Jakub Wilk]

* Michael Tautschnig , 2012-10-01, 14:25:
By policy, blank lines separate paragraphs, comments are discarded, 
so we end up with an empty first paragraph. Policy, however, requires 
that the *first* paragraph contains essential package information 
(Policy 5.2).


I'm not convinced by this interpretation the Policy. Common sense tells 
me that there's no such thing as "empty paragraph". So the question is: 
are empty liens allowed at the beginning of a control file?  I don't see 
an answer to that question in the Policy, unfortunately.


- it seems only pbuilder is really strict in its interpretation of 
policy here, but effectively that means that all our other build 
infrastructure doing parsing of debian/control is *not* 
policy-compliant


Couldn't pbuilder parse .dsc instead of debian/control? .dsc is 
guaranteed not to contain comments.


Taking a pragmatic position, it would be best to have policy 
acknowledge the fact that empty paragraphs don't count, and get the 
parser in pbuilder fixed.


ACK.

--
Jakub Wilk


--
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/20121001210054.ga6...@jwilk.net

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

[Tollef Fog Heen]

]] Vincent Bernat 

> In case of ext4 over encrypted LVM, does the kernel have all the
> discard/trim support? The Debian wiki says that LVM supports trim to
> declare unused space with lvresize as an example. Does it include unused
> space inside a logical volume?

Yes, but you need to enable it explicitly on all levels.

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

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Josselin Mouette]

Le lundi 01 octobre 2012 à 14:43 +0100, Ian Jackson a écrit : 
> This wouldn't help people doing backports or whatever.  I think this
> should be fixed in the packages involved.

Changing gnome-pkg-tools to replace the blank line with an empty comment
is trivial. In unstable.

How does that help with backports?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1349115458.13315.0.camel@tomoyo

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

[shyamal]

> "Frank" == Frank Bauer  writes:

Frank> Hi, I am considering migrating my Debian testing system to a
Frank> SSD to speed things up.  Since SSD lifetime is severely
Frank> limited (about 5000 overwrites for consumer grade MLC), I
Frank> wanted to know beforehand, how much writes does my system
Frank> generate.

Hi Frank,

Here is a data point for you.

I've been using a relatively inexpensive SSD (120G OCZ VERTEX-2) and I
have run Debian testing on this device for around 18 months now.

The machine in question is powered on 24 hours a day, every day of the
year but for a truly warm summer weekend or two (which are very
infrequent in Northern California). The machine is now six years old,
the SSD and additional RAM being the latest and only modification to
it. I use LVM like I would use it on a HDD based system, but I do not do
disk encryption.

I upgrade this machine to the latest packages in testing every working
day based on what apt-cron downloads overnight. I have performed no SSD
optimizations (e.g. no discard/TRIM settings for the ext4 file system,
don't do the no noatime thing). The file system hosts several large code
bases that see heavy edit/compile usage on a daily basis.

I have seen absolutely no performance degradation on my system for
typical use (edit/compile code), and no trouble from the SSD in my
logs. I would say that Debian testing is perfectly suitable for an SSD
based on my experience.

You can make the math suggest that this SSD should have died a while
ago, or you can make it suggest the SSD will last a decade. I've got 18
months of real usage out of it, and I expect a few more years to be
honest.

OK, now that I've said it, I'm waiting for the meltdown... ;-)

Cheers!
Shyamal




-- 
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/87lifqnm11@dallas.rhythmnetworks.com

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

[Vincent Bernat]

 ❦  1 octobre 2012 18:26 CEST, Jonathan McDowell  :

>> what are the main (ssd related) advantages of running a 3.2 kernel
>> instead of the 2.6.32 from squeeze? (I don't want to run 3.2 due to
>> wlan/intel gfx problems, though last time I tried was three months
>> ago, might been fixed by now.)
>
> For one thing our 2.6.32 kernel doesn't have full discard/trim support
> available, but the 3.2 kernel does.

In case of ext4 over encrypted LVM, does the kernel have all the
discard/trim support? The Debian wiki says that LVM supports trim to
declare unused space with lvresize as an example. Does it include unused
space inside a logical volume?
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


pgpwdruJLlYr2.pgp
Description: PGP signature

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

[Jonathan McDowell]

On Mon, Oct 01, 2012 at 03:37:19PM +0200, Holger Levsen wrote:
> On Montag, 1. Oktober 2012, Michael Hanke wrote:
> > Just a data point:
> 
> interesting, thanks. 
> 
> what are the main (ssd related) advantages of running a 3.2 kernel
> instead of the 2.6.32 from squeeze? (I don't want to run 3.2 due to
> wlan/intel gfx problems, though last time I tried was three months
> ago, might been fixed by now.)

For one thing our 2.6.32 kernel doesn't have full discard/trim support
available, but the 3.2 kernel does.

J.

-- 
Revd Jonathan McDowell, ULC | I can only see one nipple.


-- 
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/20121001162653.gx2...@earth.li

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Jon Dowland]

On Mon, Oct 01, 2012 at 02:25:36PM +0100, Michael Tautschnig wrote:
> - the problem affects all packages *build-depending* on gnome-pkg-tools, thus
>   I'd actually have to do an MBF (it's more than 160 packages)

It would be worth looking at a) whether those 160 packages have a common 
maintainer,
e.g. the Debian GNOME team, and b) whether those 160 packages have a VCS in 
common.
It might be something that can be simply fixed with a single commit, in which 
case
the beaurocracy of 160 bugs filed and then closed again would not be worth it 
IMHO.


-- 
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/20121001152555.GA21752@debian

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Ian Jackson]

Michael Tautschnig writes ("Comments+blank line in debian/control: 
Clarification in policy or MBF?"):
> Taking a pragmatic position, it would be best to have policy acknowledge the
> fact that empty paragraphs don't count, and get the parser in pbuilder fixed.

This wouldn't help people doing backports or whatever.  I think this
should be fixed in the packages involved.

If we want to relax the spec we should do that as a separate exercise.

Ian.


-- 
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/20585.40468.324999.906...@chiark.greenend.org.uk

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

[Holger Levsen]

Hi,

On Montag, 1. Oktober 2012, Michael Hanke wrote:
> Just a data point:

interesting, thanks. 

what are the main (ssd related) advantages of running a 3.2 kernel instead of 
the 2.6.32 from squeeze? (I don't want to run 3.2 due to wlan/intel gfx 
problems, though last time I tried was three months ago, might been fixed by 
now.)


cheers,
Holger


-- 
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/201210011537.20403.hol...@layer-acht.org

Comments+blank line in debian/control: Clarification in policy or MBF?

[Michael Tautschnig]

Hi,

While rebuilding our archive using pbuilder I noticed that all packages
build-depending on gnome-pkg-tools failed to build. That led me to filing
#684503, which I'll quote here for convenience:

| The file control.header ends with an empty blank line. As the contents of that
| file is prepended to debian/control for packages making using of
| gnome-pkg-tools, this results in
| 
| 
| 
| 
| 
| By policy, blank lines separate paragraphs, comments are discarded, so we end 
up
| with an empty first paragraph. Policy, however, requires that the *first*
| paragraph contains essential package information (Policy 5.2).
| 
| The current setup breaks at least pbuilder's build-dependency parsing, which
| relies on this fact.
| 
| If you believe that an empty first paragraph should not be considered a
| paragraph, please reassign to policy, asking for clarification that it's the
| *first non-empty* paragraph.

Ubuntu have fixed this bug in their version of gnome-pkg-tools already, but:

- the problem affects all packages *build-depending* on gnome-pkg-tools, thus
  I'd actually have to do an MBF (it's more than 160 packages)
- some other packages also contain comments and a blank line before the actual
  contents in debian/control (so at the very least I should be filing bugs
  against these as well)
- it seems only pbuilder is really strict in its interpretation of policy here,
  but effectively that means that all our other build infrastructure doing
  parsing of debian/control is *not* policy-compliant

Taking a pragmatic position, it would be best to have policy acknowledge the
fact that empty paragraphs don't count, and get the parser in pbuilder fixed.

Opinions would be much appreciated.

Best,
Michael



pgpmV8s6JWNA3.pgp
Description: PGP signature

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

[Andreas Beckmann]

On 2012-10-01 13:32, Frank Bauer wrote:
> On Mon, Oct 01, 2012 at 10:23:32AM +0800, Chow Loong Jin wrote:
>>
>> 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.
> 
> Reading specifications of intel's SSD 320 line at the following link:
> 
> http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-enterprise-server-storage-application-specification-addendum.html
> 
> states in section 2.3 Reliability that for 160GB drive the write
> endurance is 15TB, which gives about 94 full overwrite cycles. Not
> that much in my eyes.

And it will take about 70 days to do these 15 TB of 4KB writes
distributed over the full device (600 IOPS according to Table 1)
(15*10^12/4096/600/3600/24)
while 5000 sequential overwrites could be finished within 53 days
(5000*160*10^9/165/2^20/3600/24) (165 MB/s, Table 2)
Of course you may not interrupt your write workload by reading, which
would delay the wearout.

Do you have any information about the overprovisioning and erase block
size of that device?

> The point, however, is not whether the SSD in question will last 94 or
> 100 overwrites, but whether Debian's packaging system is not causing
> too much unneccessary write overhead.

Neither of the above extremes will probably match *your* workload.
I would assume apt-get update will mostly do sequential writes (on
several files) and this will cause some file system meta-data updates
which may result in "more random" I/Os (but restricted to a small
portion of the disk) and they go to the filesystem log, too.

That specification also gives some nice instructions how to use SMART
attributes to analyze your work load ... did you look into this?


Andreas


-- 
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/506997ec.3070...@abeckmann.de

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

[Michael Hanke]

On Mon, Oct 01, 2012 at 10:23:32AM +0800, Chow Loong Jin wrote:
> 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.

Just a data point:

I'm on an Intel SSD (120GB) since Aug 2009 -- running Debian testing all
the time. I do not upgrade daily, but often. I have _not_ done any of
the optimizations mentioned on the wiki. I have on average approx 15GB
free on the drive. Obviously, I ran a kernel <3.2 for most of the time.
I do lots of compiling on this SSD.

So far, I have nothing to complain about and consider this drive as
fairly reliable.

Michael





-- 
Michael Hanke
http://mih.voxindeserto.de


-- 
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/20121001131246.GD11280@meiner

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

[Thibaut Girka]

On Mon, Oct 01, 2012 at 06:27:04PM +0800, Paul Wise wrote:
> On Mon, Oct 1, 2012 at 6:14 PM, Wookey wrote:
> > Thibg's final report gives a useful summary:
> > http://lists.debian.org/debian-embedded/2012/08/msg2.html
> > and this blog post gives some more details:
> > http://gsoc.sitedethib.com/posts/State_of_Multiarch_Cross-toolchains_three_weeks_after_GSoC/
> 
> I tried following that the other week and came across some gotchas:
> 
> You really do need to apply his patches, the blog post doesn't make
> that too obvious.
> 
> He missed out the GCC_TARGET=armhf in front of the `debian/rules
> control` and `dpkg-buildpackage -uc -us -b` commands.

I have updated my blog post.
If something still isn't clear, please tell me in a private mail.


-- 
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/20121001122824.GA6696@localhost

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

[Frank Bauer]

On Mon, Oct 01, 2012 at 10:23:32AM +0800, Chow Loong Jin wrote:
>
> 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.

Reading specifications of intel's SSD 320 line at the following link:

http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-enterprise-server-storage-application-specification-addendum.html

states in section 2.3 Reliability that for 160GB drive the write
endurance is 15TB, which gives about 94 full overwrite cycles. Not
that much in my eyes.

The point, however, is not whether the SSD in question will last 94 or
100 overwrites, but whether Debian's packaging system is not causing
too much unneccessary write overhead.

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_KNssZ_6oU+VVgtg2_jqvLp1yGGsvtAbz=isqtqj0f...@mail.gmail.com

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

[Thibaut Girka]

On Sun, Sep 30, 2012 at 03:34:18PM +0100, peter green wrote:
> 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.

Great!
I'm busy with uni, but I'll try to help.

> 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.

The tool you're looking for is mk-build-deps from the devscripts package,
I'm not sure about how it handles multiarch, though. I'll have a look into it.

I think pbuilder comes with a similar script, but again, I'm not
sure it handles multiarch correctly.


-- 
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/20121001112852.GA2718@localhost

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

[Bart Martens]

On Mon, Oct 01, 2012 at 12:29:00PM +0200, Holger Levsen wrote:
> On Sonntag, 30. September 2012, Arno Töll wrote:
> > * We are effectively ruling out opinions of non-members. That's bizarre,
> > since we allow them to maintain (and even "hijack") packages. 
> 
> No, we d/won't allow non-members to hijack packages. We probably will allow 
> them to salvage packages OTOH. (And that's totally non-bizarre IMHO.)

I agree with Holger Levsen on this.  And the "seconding" I'm proposing is
obviously to have DDs (maybe also DMs ?) judge between an unwanted hijack and a
welcome salvage.

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/20121001110005.gd3...@master.debian.org

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

[Holger Levsen]

Hi,

On Sonntag, 30. September 2012, Arno Töll wrote:
> * We are effectively ruling out opinions of non-members. That's bizarre,
> since we allow them to maintain (and even "hijack") packages. 

No, we d/won't allow non-members to hijack packages. We probably will allow 
them to salvage packages OTOH. (And that's totally non-bizarre IMHO.)

This is a good example why language is important. And please dont write 
"hijack" if you mean _salvage_ or _salvage or high-jack_. Similary like you 
won't say "coffee" if you mean water or (water or coffee) ;-p


cheers,
Holger


--
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/201210011229.01274.hol...@layer-acht.org

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

[Paul Wise]

On Mon, Oct 1, 2012 at 6:14 PM, Wookey wrote:

> It's possible, but some more is still needed to have them built by the
> normal buildds. Wanna-build needs support for cross-arch dependencies;
> that's not been done yet. Splitting (multiarching) libc++-dev is also
> needed to build the g++ cross-compiler, http://bugs.debian.org/678623
> and it would need either a small source package to the do the
> non-standard GCC_TARGET=foo dpkg-buildpackage build, or a bit more
> work to make it standard.

Hmm, ok. I guess that means it would have to go experimental then.
Fine for me though.

> Thibg's final report gives a useful summary:
> http://lists.debian.org/debian-embedded/2012/08/msg2.html
> and this blog post gives some more details:
> http://gsoc.sitedethib.com/posts/State_of_Multiarch_Cross-toolchains_three_weeks_after_GSoC/

I tried following that the other week and came across some gotchas:

You really do need to apply his patches, the blog post doesn't make
that too obvious.

He missed out the GCC_TARGET=armhf in front of the `debian/rules
control` and `dpkg-buildpackage -uc -us -b` commands.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6ebcsn6ozk-omrwm1-exwapfu83suraqzutjyhntop...@mail.gmail.com

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

[Wookey]

+++ Wookey [2012-10-01 11:14 +0100]:
> +++ Paul Wise [2012-10-01 17:42 +0800]:
> > 
> > I'd like to see cross-toolchains in sid before wheezy is out, is that
> > going to be possible?

Sorry - meant to say, that whilst we should definately have a go at
this in experiemental, the libsdtc++ changes needed andprobaby some of
the others may not be a good idea in sid right now?

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20121001101657.gp24...@stoneboat.aleph1.co.uk

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

[Wookey]

+++ Paul Wise [2012-10-01 17:42 +0800]:
> On Sun, Sep 30, 2012 at 10:34 PM, peter green wrote:
> 
> > 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'd like to see cross-toolchains in sid before wheezy is out, is that
> going to be possible? Perhaps with some sort of temporary source
> package build-depending on gcc-4.7-source?

It's possible, but some more is still needed to have them built by the
normal buildds. Wanna-build needs support for cross-arch dependencies;
that's not been done yet. Splitting (multiarching) libc++-dev is also
needed to build the g++ cross-compiler, http://bugs.debian.org/678623
and it would need either a small source package to the do the
non-standard GCC_TARGET=foo dpkg-buildpackage build, or a bit more
work to make it standard. 

Thibg's final report gives a useful summary: 
http://lists.debian.org/debian-embedded/2012/08/msg2.html
and this blog post gives some more details:
http://gsoc.sitedethib.com/posts/State_of_Multiarch_Cross-toolchains_three_weeks_after_GSoC/


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20121001101413.go24...@stoneboat.aleph1.co.uk

Question Regarding A Resource For Prospective Students

[Lillian Clark]

Hi there,

I happened upon your collection of college and career web resources for 
prospective students here 
http://lists.debian.org/debian-devel/1998/09/msg00565.html and thought you 
might be interested in another authoritative online resource to add to those.

Are you the correct person to contact for having resources added as an 
additional link on this page? If not, could you please direct me to the right 
individual?

Thanks for your time. I hope to hear from you soon!
Lillian Clark


--
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/mcb1g7x6-4dre-ylm5-4zcg-36yrghuo...@gmail.com

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

[Ian Jackson]

Stefano Zacchiroli writes ("Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun 
and profit: A proposal"):
> 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.

It seems to me that when salvaging works well, the existing maintainer
is probably at least semi-active but is embarrassed about the
package or somehow otherwise blocked from working on it.

A successful salvage is then a quiet operation where we take this
burden from the maintainer and they don't have to feel too bad about
it.  Hopefully the maintainer, after a few months at least, will be
actually relieved.

I don't think seconding fits well into this.  It would encourage
dogpiles and noise.  If it achieves anything it will be to make the
maintainer feel worse and perhaps make them stubborn.

Ian.


-- 
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/20585.26461.670996.413...@chiark.greenend.org.uk

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

[Paul Wise]

On Sun, Sep 30, 2012 at 10:34 PM, peter green wrote:

> 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'd like to see cross-toolchains in sid before wheezy is out, is that
going to be possible? Perhaps with some sort of temporary source
package build-depending on gcc-4.7-source?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6hlvc4bkkkhspwtndshxkj7fkwmte-stmgfg7k9+fo...@mail.gmail.com

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

[Simon McVittie]

On 01/10/12 09:51, Thijs Kinkhorst wrote:
> I've had an NMU in the past for a package when I had a little less time,
> but the change was sound and correct. So I didn't bother to make an
> (empty) MU just to acknowledge it - I think that should be OK and not
> 'punished' by taking it as a sign of an unmaintained package.

I think it'd be reasonable to expect a maintainer to follow-up to the
BTS[1] in cases like this, just to say "that change looks fine" (and if
the upload is still in DELAYED, give the non-maintainer a chance to
reschedule it to the 0-day queue), e.g.
.

I also think it's reasonable to expect that people checking whether a
package is "effectively unmaintained" should check such bugs for
activity, and treat the NMU as having been acknowledged (in the
non-jargon sense of the word) if the maintainer replied.

S

[1] the same place the non-maintainer (should have) sent the nmudiff:
the bug closed if there was only one, or the new "integrate changes from
NMU 1.2-3" bug otherwise.


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

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

[Andrew Shadura]

Hello,

On Sun, 30 Sep 2012 13:22:01 +0200
Luca Bruno  wrote:

> * URL : http://www.rust-lang.org/
> * License : MIT
>   Programming Lang: C/C++, Rust
>   Description : a safe, concurrent, practical language

Oh, please, please package it! It seems like it's very interesting
language indeed!

-- 
WBR, Andrew


signature.asc
Description: PGP signature

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

[Neil Williams]

On Mon, 1 Oct 2012 10:51:22 +0200
"Thijs Kinkhorst"  wrote:

> Hi Arno,
> 
> Thanks for this initiative. It seems like a useful guideline.
> 
> > * A previous NMU was not acknowledged, and at least another issue
> > justifying another NMU is pending for /one month/ [5].
> 
> I was wondering what 'acknowledging an NMU' means nowadays. Of course, we
> all used this term from the time that NMU's did not close bugs in the BTS
> and therefore needed to be explicitly acknowledged by an MU. However,
> since we have version tracking there's no need and I guess also no real
> way to acknowledge a NMU anymore. Or would this just mean "a maintainer
> upload happened after the NMU that didn't revert the changes"?

... or that the changes in the NMU have been applied to the packaging
VCS and will therefore survive into next versions. To me, this is the
biggest part of acknowledgement - even having the packaging in
collab-maint doesn't ensure that the patch gets into the packaging VCS,
risking losing the changes at the next upload.

So it's useful to have a statement acknowledging the NMU in the next
changelog because it gives that assurance when checking the history of
the changelog via the PTS.

> I've had an NMU in the past for a package when I had a little less time,
> but the change was sound and correct. So I didn't bother to make an
> (empty) MU just to acknowledge it - I think that should be OK and not
> 'punished' by taking it as a sign of an unmaintained package.

An empty upload with no purpose other than to acknowledge the NMU
really does seem useless though, true.

If a package is to be salvaged, the VCS may well change as well, so
whether an NMU has been acknowledged or not isn't that useful for the
salvage process.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpLaKAIVl05Q.pgp
Description: PGP signature

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

[Charles Plessy]

Le Mon, Oct 01, 2012 at 10:51:22AM +0200, Thijs Kinkhorst a écrit :
> 
> I was wondering what 'acknowledging an NMU' means nowadays. Of course, we
> all used this term from the time that NMU's did not close bugs in the BTS
> and therefore needed to be explicitly acknowledged by an MU. However,
> since we have version tracking there's no need and I guess also no real
> way to acknowledge a NMU anymore. Or would this just mean "a maintainer
> upload happened after the NMU that didn't revert the changes"?

Hi Thijis,

Quoting Don Armstrong in the "Proposal to update NMU section 5.11.1" discussion
this year on debian-policy (as the list where changes to the Developers 
Reference
are also discussed):

  Versioning is a directed acyclic graph. Each version has at most one
  ancestor, though it may have many descendants. When you upload a
  maintainer upload (MU) without including the NMU changelog entry, you
  are indicating that your version is a descendant of the previous MU,
  not the NMU. That's perfectly ok, but if you've actually fixed bugs
  that were fixed in the NMU in your MU, you need to include lines in
  the changelog to that effect, or later on manually fix-up the
  versions.

http://lists.debian.org/debian-policy/2012/04/msg00060.html

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20121001091108.gc26...@falafel.plessy.net

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

[Thijs Kinkhorst]

Hi Arno,

Thanks for this initiative. It seems like a useful guideline.

> * A previous NMU was not acknowledged, and at least another issue
> justifying another NMU is pending for /one month/ [5].

I was wondering what 'acknowledging an NMU' means nowadays. Of course, we
all used this term from the time that NMU's did not close bugs in the BTS
and therefore needed to be explicitly acknowledged by an MU. However,
since we have version tracking there's no need and I guess also no real
way to acknowledge a NMU anymore. Or would this just mean "a maintainer
upload happened after the NMU that didn't revert the changes"?

I've had an NMU in the past for a package when I had a little less time,
but the change was sound and correct. So I didn't bother to make an
(empty) MU just to acknowledge it - I think that should be OK and not
'punished' by taking it as a sign of an unmaintained package.

> Procedure to salvage a package
> -

> 1) A bug with severity "serious" against the package in question must be
> filed, expressing the intent to take over maintainership of the package.
> The reporter may also offer co-maintenance of the package.

In my experience, a takeover of a package which is in dire need of some
love went most smoothly when it was done by just adding oneself as a
co-maintainer, not replacing the maintainer right away. This sends the
message that you want to help with the package, but doesn't send the
message that the current maintainer needs to go away.

Of course, if after a longer time the old maintainer still hasn't worked
on the package, he can be removed from the maintainer list (and may agree
to that if he sees that the new maintainer has done useful work).

I'd recommend to have the procedure advise principally that one just adds
oneself as a comaintainer, so to reword (1): "expressing the intent to add
oneself to the maintainer team for the package".


Cheers,
Thijs


-- 
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/320712f750ed9d7450e4d804e1252d47.squir...@aphrodite.kinkhorst.nl

Re: mass bug filing about versioned dependency on the libhdf5-7 virtual package

[Julien Cristau]

On Sun, Sep 30, 2012 at 00:28:15 +0700, Ivan Shmakov wrote:

>   I tend to think that a re-build (via binNMU or otherwise) will
>   be sufficient for most of the packages affected.
> 
>   Unless there'll be objections, I'm going to file the respective
>   bug reports regarding the versioned dependency on libhdf5-7
>   against the following packages.  (The affected versions and
>   architectures [though only amd64 and i386 were tested] are
>   shown, as well as the Depends: list items triggering the check.)
> 
NAK.  If a binNMU is all that's needed then please don't file bugs
against the packages.  See http://wiki.debian.org/binNMU

Cheers,
Julien
-- 
Julien Cristau  
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances


-- 
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/20121001084527.gb...@crater2.logilab.fr

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

[Johannes Schauer]

Hi,

On Mon, Oct 01, 2012 at 01:05:11AM +0100, Wookey 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.
> 
> 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-dev has dpkg-checkbuilddeps which also has the -a switch for
foreign architectures. But it has two problems:

 - the string it outputs contains versions in a format not compatible
   with the apt-get command line.
 - even with -a it doesnt seem to append architecture qualifiers to
   package name (package:arch)

But dpkg-checkbuilddeps could probably easily be used as a template for
a script that is able to feed apt.

> > 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?

When we talked about it, I did some quick hacking and created some
patches for the dose3 parser so that it would also be able to read
debian/control files. When I was in Paris we didnt talk much about dose3
but more about my code. I will ask Pietro about the best way to
integrate this into dose3 on the debian-bootstrap list [1] today.

> 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.

And it needs wanna-build fixing (support for architecture qualifiers eg
package:arch) in Debian.

cheers, josch

[1] http://lists.mister-muffin.de/cgi-bin/mailman/listinfo/debian-bootstrap


-- 
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/20121001083403.GB1682@hoothoot

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

[Simon McVittie]

On 01/10/12 07:51, Tollef Fog Heen wrote:
> Now that we have well working bind mounts, we could actually deprecate
> [sysadmins moving directories to a less full filesystem and leaving
> symlinks behind] and just tell people to use bind mounts instead.  At
least
> if our non-Linux ports has decent support for it.

kFreeBSD has "nullfs" which seems to be meant to work (at least, a
search for "kfreebsd nullfs" shows that bugs in it sometimes get fixed).

S


-- 
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/506947c5.9010...@debian.org