Re: bash exorcism experiment ('bug' 762923 & 763012)

[Troy Benjegerdes]

On Sat, Sep 27, 2014 at 08:42:57PM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Sat, 27 Sep 2014, Guillem Jover wrote:
> > > In the case of bash, dpkg can (and does!) use bash explicitly (i.e.,
> > > without going through /bin/sh), so removing bash will pretty much nuke
> > > your system.
> > 
> > Hmm, where?
> 
> Wouter has been too quick, it's not dpkg. The output shown by Troy points
> to the menu trigger which runs /usr/bin/update-menus which in turn calls
> bash:
> $ strings /usr/bin/update-menus|grep bash
> exec /bin/bash -o pipefail -c '

Menus is kinda nice to have work right, but it's not really 'essential'

So far about the only 'essential' thing I see about bash is some maintainer
scripts and dhclient-script. Yes, it's important, and I'm probably going to
get tired of trying to learn zsh soon and reinstall bash, but I have a 
perfectly usable system without it.

libc, /bin/sh, dpkg, apt  ... those seem essential. (as well as solving 
bug #620898), 

Does update-menus really need bash? Why?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140928021144.ge1...@nl.grid.coop

Re: binary data file and endianness and multiarch

[Juliusz Chroboczek]

>> That's not what my mail was about.  My point is that the issue with the
>> software should be resolved upstream,

> in my case, it cannot be resolved upstream,

Yes, abandoned software is a problem, unfortunately quite common in the
scientific community.  (Understandably so, since researchers get funding
and kudos for developing new stuff, not for maintaining existing software.)

Adam, sorry for the tone of my previous mail.  That was uncalled for.

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq8o8w8y.wl-...@pps.univ-paris-diderot.fr

Re: binary data file and endianness and multiarch

[Jerome BENOIT]

Hello All,

thanks for your answer.

On 27/09/14 23:37, Juliusz Chroboczek wrote:
>>> Standardising on big-endian is a good idea [...]
> 
>> Except that the endianness war has been won by little-endian
> 
> That's not what my mail was about.  My point is that the issue with the
> software should be resolved upstream,

in my case, it cannot be resolved upstream,

 rather than implementing yet another
> dodgy hack in dpkg.

Agree.

I finally fix my issue by putting those data in the localstatedir 
(/var/SOMETHING)

> 
> Which particular encoding upstream chooses should be of no import to
> Debian, as long as it is arch-independent.  Should you have strong
> feelings one way or the other, please feel free to discuss it with
> upstream on the appropriate forum.

Thanks,
Jerome

> 
> -- Juliusz
> 
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54273d5c.1070...@rezozer.net

Re: binary data file and endianness and multiarch

[Juliusz Chroboczek]

>> Standardising on big-endian is a good idea [...]

> Except that the endianness war has been won by little-endian

That's not what my mail was about.  My point is that the issue with the
software should be resolved upstream, rather than implementing yet another
dodgy hack in dpkg.

Which particular encoding upstream chooses should be of no import to
Debian, as long as it is arch-independent.  Should you have strong
feelings one way or the other, please feel free to discuss it with
upstream on the appropriate forum.

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tqwagog.wl-...@pps.univ-paris-diderot.fr

Re: binary data file and endianness and multiarch

[Vincent Lefevre]

On 2014-09-27 11:18:18 +0100, Jonathan Dowland wrote:
> > On 27 Sep 2014, at 10:36, Adam Borowski  wrote:
> > 
> > Except that the endianness war has been won by little-endian
> 
> And yet, network byte order remains big.

But does this matter in the context of these binary data files?

On 2014-09-27 13:06:56 +0200, Matthias Urlichs wrote:
> Jonathan Dowland:
> > It's less important which endian they pick, but that they pick one
> > and use it consistently across arches.
> > 
> The advantage of using big-endian data on a little-endian system is that
> you actually have a chance of finding mis-swapped and/or mis-sized items.

However, conversely, if little-endian data is chosen, you just need to
test on a big-endian system.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927205834.ga24...@xvii.vinc17.org

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Peter Palfrader]

On Fri, 26 Sep 2014, Paul Wise wrote:

> On Thu, Sep 25, 2014 at 11:21 PM, Christoph Anton Mitterer wrote:
> 
> > Well I think snapshot is it's own construction site, isn't it?
> 
> snapshot is a read-only (modulo cosmic rays and removal of
> non-redistributable things) historical record, files in it will not be
> modified to re-sign with newer keys nor to update Valid-Until.

That doesn't mean one couldn't consider providing an overlay of sorts,
that provides re-signed release files if the original ones verified.
Under a different path obviously.  We could look at patches if they
somehow appeared.

> Updating the Release files more often will simply mean slightly more
> disk space used for the extra Release files. Depending on the update
> frequency, the quantity of data is probably too little to make any
> significant difference in the disk usage of the snapshot service so
> nothing to worry about IMO.

Right, I don't think the additional space of 4 or 10 more Release files
a day are an issue.

However, it seems unsmart to bet on ftp-master or security-master never
being offline longer than a few hours.  We do not have the set-up to
guarantee that kind of high availability.

Thus, I think significantly shortening validity times is a Very Bad
Idea.

Cheers,
weasel
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927203435.gr26...@anguilla.noreply.org

repost: Reproducible builds? I never did any - manually

[Holger Levsen]

Hi,

for those who don't read planet.d.o...

# Reproducible builds? I never did any - manually :)

I've never done a reproducible build attempt of any package, manually, ever. 
But what I've done now is setting up [reproducible builds]
(https://wiki.debian.org/ReproducibleBuilds) on 
[jenkins.debian.net](https://jenkins.debian.net) which will build hundreds or 
thousands of packages, hopefully reproducibly, 
regularily in the future. Thanks to Lunar's and many other peoples work, this 
was actually rather easy. If you want to do this manually, it should take you 
just a few 
minutes to setup a suitable build environment.

So three days ago when I wasn't exactly bored I decided that it was a good 
moment to implement some [reproducible build jobs on jenkins.d.n]
(https://jenkins.debian.net/view/reproducible), and so I gave it a try and two 
hours later the basic implementation was working, and then it was an evening 
and morning of 
fine tuning until I was mostly satisfied. Since then there has been some 
polishing, but the basic setup is done and has been working since.

What's the result? One job, 
[reproducible_setup](https://jenkins.debian.net/view/reproducible/job/reproducible_setup/)
 will just create a suitable environment for 
[pbuilding reproducible packages as documented so 
well](https://wiki.debian.org/ReproducibleBuilds#Usage_example) on the Debian 
wiki. And as that job runs 3.5 minutes only 
(to debootstrap from scratch), it's run daily.

And then there are currently 16 other jobs, which test reproducible builds in 
different areas: 
[d-i](https://jenkins.debian.net/view/reproducible/job/reproducible_build_d-
i/), 
[core](https://jenkins.debian.net/view/reproducible/job/reproducible_build_core/),
 
[some](https://jenkins.debian.net/view/reproducible/job/reproducible_build_gnome/)
 
[six](https://jenkins.debian.net/view/reproducible/job/reproducible_build_kde/) 
[major](https://jenkins.debian.net/view/reproducible/job/reproducible_build_xfce/)
 
[desktops](https://jenkins.debian.net/view/reproducible/job/reproducible_build_lxde/)
 
[and](https://jenkins.debian.net/view/reproducible/job/reproducible_build_mate/)
 
[some](https://jenkins.debian.net/view/reproducible/job/reproducible_build_cinnamon/)
 selected [desktop applications]
(https://jenkins.debian.net/view/reproducible/job/reproducible_build_desktop-apps/),
 some [security + privacy]
(https://jenkins.debian.net/view/reproducible/job/reproducible_build_security-privacy/)
 related packages, some [build chains]
(https://jenkins.debian.net/view/reproducible/job/reproducible_build_build-tools)
 we have in Debian, [libreoffice]
(https://jenkins.debian.net/view/reproducible/job/reproducible_build_libreoffice)
 and 
[X.org](https://jenkins.debian.net/view/reproducible/job/reproducible_build_xorg/).
 
Most of these jobs run several hours, but luckily not days. And they discover 
packages which still fail to build reproducibly, which already has caused some 
bugs to be 
filed, eg. [#762732 "libdebian-installer: please do not write timestamps in 
Doxygen generated documentation"](https://bugs.debian.org/762732).

So this is the [output from testing the reproducibilty of all debian-installer 
packages](https://jenkins.debian.net/view/reproducible/job/reproducible_build_d-
i/lastBuild/console): 72 packages were successfully built reproducibly, while 6 
packages failed to do so. I was quite impressed by these numbers as AFAIK noone 
tried to 
build d-i reproducibly before.


72 packages successfully built reproducibly: userdevfs user-setup usb-discover 
udpkg tzsetup rootskel rootskel-gtk rescue preseed pkgsel partman-xfs 
partman-target partman-
partitioning partman-nbd partman-multipath partman-md partman-lvm partman-jfs 
partman-iscsi partman-ext3 partman-efi partman-crypto partman-btrfs 
partman-basicmethods 
partman-basicfilesystems partman-base partman-auto partman-auto-raid 
partman-auto-lvm partman-auto-crypto partconf os-prober oldsys-preseed 
nobootloader network-console 
netcfg net-retriever mountmedia mklibs media-retriever mdcfg main-menu lvmcfg 
lowmem localechooser live-installer lilo-installer kickseed kernel-wedge 
kbd-chooser iso-scan 
installation-report installation-locale hw-detect grub-installer finish-install 
efi-reader dh-di debian-installer-utils debian-installer-netboot-images 
debian-installer-
launcher clock-setup choose-mirror cdrom-retriever cdrom-detect cdrom-checker 
cdebconf-terminal cdebconf-entropy bterm-unifont base-installer apt-setup anna 
6 packages failed to built reproducibly: win32-loader libdebian-installer 
debootstrap console-setup cdebconf busybox 


What's also impressive: all packages for the newly introduced [Cinnamon Desktop 
build reproducibly]
(https://jenkins.debian.net/view/reproducible/job/reproducible_build_cinnamon/1/console)
 from the start!

The jenkins setup is configured via just three small files:

- 
[job-cfg/reproducible.yaml](http://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Raphael Hertzog]

Hi,

On Sat, 27 Sep 2014, Guillem Jover wrote:
> > In the case of bash, dpkg can (and does!) use bash explicitly (i.e.,
> > without going through /bin/sh), so removing bash will pretty much nuke
> > your system.
> 
> Hmm, where?

Wouter has been too quick, it's not dpkg. The output shown by Troy points
to the menu trigger which runs /usr/bin/update-menus which in turn calls
bash:
$ strings /usr/bin/update-menus|grep bash
exec /bin/bash -o pipefail -c '

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140927184257.ga26...@x230-buxy.home.ouaza.com

Re: Licensing issue in images files on several packages

[Holger Levsen]

Hi Clement,

On Samstag, 27. September 2014, Clement Hermann wrote:
> > If there is no reply to this issue yet again (in say two weeks) I'd
> > recommend filing bugs about this. RC bugs. This also follows nicely the
> > tradition of making the freeze longer by filing bugs late ;-/
> I did, only with severity "important" - just as a way to track this.
> see #763060 to #763067.

Great, thanks for this!
 
> I actually resolved the issue in OpenPGP Applet by making new icons
> based on the last version of the Tango Icon Library, which is licensed
> under CC0 (Public Domain), and including them upstream.

awesome! :)
 
> That said, I think it would benefit others if this can be clarified. I
> spent a long time wondering what to do, and even longer trying to find
> an upstream that would answer my request...

indeed.


cheers,
Holger




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

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Guillem Jover]

Hi!

On Sat, 2014-09-27 at 18:30:17 +0200, Wouter Verhelst wrote:
> On Sat, Sep 27, 2014 at 10:32:18AM -0500, Troy Benjegerdes wrote:
> > So far, I need to do the following to remove bash (and associated risk of
> > 0-days until something sane is done about functions)
> 
> That is not supported, sorry. Bash is in the "essential" set, which
> means that packages can (and do!) use functionality from bash without an
> explicit dependency.

This has been discussed before, I've done a quick initial summary of
the previous discussion here:

  

> In the case of bash, dpkg can (and does!) use bash explicitly (i.e.,
> without going through /bin/sh), so removing bash will pretty much nuke
> your system.

Hmm, where?

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927181845.ga2...@gaara.hadrons.org

Bug#763081: ITP: python-pytest-django -- Django plugin for the py.test Python testing tool

[Jan Dittberner]

Package: wnpp
Severity: wishlist
Owner: Jan Dittberner 

* Package name: python-pytest-django
  Version : 2.6.2
  Upstream Author : Ben Firshman, Andreas Pelme and contributors
* URL : https://github.com/pelme/pytest_django
* License : BSD
  Programming Lang: Python
  Description : Django plugin for the py.test Python testing tool

pytest-django is a plugin for pytest that provides a set of useful tools for
testing Django applications and projects.

Running the test suite with pytest offers some features that are not present in 
Djangos standard test mechanism:

* Less boilerplate: no need to import unittest, create a subclass with
  methods. Just write tests as regular functions.
* Manage test dependencies with fixtures
* Database re-use: no need to re-create the test database for every test
  run.
* Run tests in multiple processes for increased speed
* There are a lot of other nice plugins available for pytest.
* Easy switching: Existing unittest-style tests will still work without any
  modifications.

I plan to maintain the package under the umbrella of the DPMT. The package
is a dependency to implement build time testing for python-django-braces
(See #763075).


Best regards
Jan

-- 
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
 B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://portfolio.debian.net/ - http://people.debian.org/~jandd/


signature.asc
Description: Digital signature

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Wouter Verhelst]

Hi Troy,

On Sat, Sep 27, 2014 at 10:32:18AM -0500, Troy Benjegerdes wrote:
> So far, I need to do the following to remove bash (and associated risk of
> 0-days until something sane is done about functions)

That is not supported, sorry. Bash is in the "essential" set, which
means that packages can (and do!) use functionality from bash without an
explicit dependency.

In the case of bash, dpkg can (and does!) use bash explicitly (i.e.,
without going through /bin/sh), so removing bash will pretty much nuke
your system.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927163017.ga7...@grep.be

Re: Licensing issue in images files on several packages

[Clement Hermann]

Hi,

On 23/09/2014 16:52, Holger Levsen wrote:
> On Montag, 4. August 2014, Clement Hermann wrote:
>
>> I saw that on my Sid system, some packages have the same issue :
>> rgrep -rl 'by-sa/2\.0' /usr/share/icons/*/scalable |xargs dlocate
>> --package-only
>> gitg
>> network-manager-gnome
>> soundconverter
>> thunar-volman
>> xfburn
>> xfce4-battery-plugin
>> xfce4-fsguard-plugin
>> xfce4-power-manager-data
> If there is no reply to this issue yet again (in say two weeks) I'd recommend 
> filing bugs about this. RC bugs. This also follows nicely the tradition of 
> making the freeze longer by filing bugs late ;-/

I did, only with severity "important" - just as a way to track this.
see #763060 to #763067.

> Or upload OpenPGP Applet and hope that the ftpmasters will let it through, 
> based on the above. 
>
> Or both ;)
>
I actually resolved the issue in OpenPGP Applet by making new icons
based on the last version of the Tango Icon Library, which is licensed
under CC0 (Public Domain), and including them upstream.

That said, I think it would benefit others if this can be clarified. I
spent a long time wondering what to do, and even longer trying to find
an upstream that would answer my request...

Cheers,

-- 
Clément (nodens)




signature.asc
Description: OpenPGP digital signature

bash exorcism experiment ('bug' 762923 & 763012)

[Troy Benjegerdes]

So far, I need to do the following to remove bash (and associated risk of
0-days until something sane is done about functions)

So far everything I've tested on one desktop and one server is fine.

What reasonable ways might there be to support changes to a few 
packages to run wheezy without bash, and explicitly add proper
dependencies instead of just calling it 'essential'

--- dhclient-script.bad 2014-09-27 00:21:48.377145358 -0500
+++ /sbin/dhclient-script   2014-09-27 00:15:31.508982652 -0500
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 # dhclient-script for Linux. Dan Halbert, March, 1997.
 # Updated for Linux 2.[12] by Brian J. Murrell, January 1999.


apt-get remove bash gets the following:

The following packages will be REMOVED:
  bash bash-completion dpatch foo2zjs foomatic-db-engine foomatic-filters 
printer-driver-foo2zjs
  printer-driver-m2300w printer-driver-pxljr
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  bash
0 upgraded, 0 newly installed, 9 to remove and 0 not upgraded.
After this operation, 10.8 MB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] Yes, do as I say!
(Reading database ... 293950 files and directories currently installed.)
Removing printer-driver-pxljr ...
Removing printer-driver-m2300w ...
Removing foomatic-db-engine ...
Removing foo2zjs ...
Removing printer-driver-foo2zjs ...
Removing foomatic-filters ...
Removing dpatch ...
Removing bash-completion ...
dpkg: warning: overriding problem because --force enabled:
 This is an essential package - it should not be removed.
Removing bash ...
Processing triggers for cups ...
Starting Common Unix Printing System: cupsd.
Processing triggers for man-db ...
Processing triggers for desktop-file-utils ...
Processing triggers for menu ...
sh: 1: exec: /bin/bash: not found
Unknown error, message=exec /bin/bash -o pipefail -c 'dpkg-query --show 
--showformat="\${status} \${provides} \${package}\n" | sed -n -e 
"/installed\|triggers-awaited\|triggers-pending 
/{s/^.*\(installed\|triggers-awaited\|triggers-pending\) *//; s/[, ][, ]*/\n/g; 
p}"'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927153218.gb1...@nl.grid.coop

Re: virt-manager

[Cameron Norman]

On Sat, Sep 27, 2014 at 7:58 AM, Fabrice Aeschbacher
 wrote:
> Dear maintainers,
>
> For now, virt-manager v1.x is in experimental only (1.0.1).
>
> The freeze for Jessie is approaching, and I wondered if something
> particular is preventing the package migration from experimental to
> unstable before the freeze (in less than 6 weeks).

Looks like this bug filed onto the version in experimental:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740047.

Seems like the maintainer might need help with it.

Cheers,
--
Cameron Norman


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

virt-manager

[Fabrice Aeschbacher]

Dear maintainers,

For now, virt-manager v1.x is in experimental only (1.0.1).

The freeze for Jessie is approaching, and I wondered if something
particular is preventing the package migration from experimental to
unstable before the freeze (in less than 6 weeks).

Upstream, v1.0.0 is out for 7 months, v1.1.0 for 3 weeks.

Thank you and kind regards,
Fabrice Aeschbacher


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

Bug#763045: ITP: libparse-pmfile-perl -- module to parse .pm file as PAUSE does

[gregor herrmann]

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

* Package name: libparse-pmfile-perl
  Version : 0.26
  Upstream Author : Kenichi Ishigaki 
* URL : https://metacpan.org/release/Parse-PMFile
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to parse .pm file as PAUSE does

Most of the code of this module is taken from the PAUSE code as of April 2013
almost verbatim. Thus, the heart of Parse::PMFile should be quite stable.

Parse::PMFile doesn't provide features to extract a distribution or parse
meta files intentionally.


signature.asc
Description: Digital Signature

Re: binary data file and endianness and multiarch

[Matthias Urlichs]

Hi,

Jonathan Dowland:
> It's less important which endian they pick, but that they pick one and use it 
>  consistently across arches.
> 
The advantage of using big-endian data on a little-endian system is that
you actually have a chance of finding mis-swapped and/or mis-sized items.

I do admit that I've stared at too many m68k hexdumps (in an earlier life)
to ever become comfortable with LE data. ;-)

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927110656.ge6...@smurf.noris.de

Re: binary data file and endianness and multiarch

[Jonathan Dowland]

> On 27 Sep 2014, at 10:36, Adam Borowski  wrote:
> 
> Except that the endianness war has been won by little-endian

And yet, network byte order remains big.

It's less important which endian they pick, but that they pick one and use it  
consistently across arches.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/c44c80e0-6812-43e1-a584-3c0da7891...@debian.org

Re: Mass "do not use bash" bug filing

[Holger Levsen]

On Freitag, 26. September 2014, Jakub Wilk wrote:
> I was once accused of doing an unannounced MBF after filing a single
> bug. :> It's not necessarily the bug volume that triggers anti-MBF
> defence mechanisms in developers.

lol / wow! 

/me giggles



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

Re: binary data file and endianness and multiarch

[Adam Borowski]

On Sat, Sep 27, 2014 at 04:41:42AM +0200, Juliusz Chroboczek wrote:
> Standardising on big-endian is a good idea, not only because it is the
> canonical byte ordering, but also because little-endian arches tend to
> have more efficient byte-swapping instructions.

Except that the endianness war has been won by little-endian and thus your
code would optimize for an already tiny part of the population that is going
to only decrease: arm, mips switched from mostly be to almost only le, and
the newest Debian architecture is ppc64el.  hppa, sparc, m68k are dead,
which leaves s390 as the only arch that's not heading to little-endian,
and s390 has only a handful of installations.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927093645.ga12...@angband.pl