Re: Report from the Bug Squashing Party in Salzburg

2012-06-20 Thread Philip Ashmore

On 19/06/12 23:26, Bernd Zeimetz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

For those who do not read Planet Debian, here is the report from the Debian
BSP in Salzburg (markdown/ikiwiki source, sorry for not re-formatting it :))


Participation and Results
- ---
- From June 15-17th we held a Debian BugSquashingParty in Salzburg, hosted and
sponsored by [conova communications GmbH](http://www.conova.com/). It was a
fun and busy weekend, with 15-17 people from 5 coutries being around, mainly
working on RC bugs in Testing/Unstable. Gerfried Fuchs (rhonda) also worked on
triaging the impact of RC bugs on the version in Squeeze, while Peter
Palfrader (weasel) took care of Tor related things and Debian sysadmin work,
including starting on the new bugs and udd hosts. Phillip Hug (hug) worked on
the  debian.ch infrastructure.
Together with Miroslav Suchý from Red Hat Bernd Zeimetz (bzed) worked on the
packaging of the necessary libraries and daemons to add (basic) Spacewalk
client support to Debian. As soon as the packages passed NEW and
[#677871](http://bugs.debian.org/677871) was applied (thanks to the APT guys
for working on that already), managing Debian clients with Spacewalk should
work out of the box.
Of course we also had a little keysigning party :)

Statistics
- ---
- -  about 68 bugs in unstable/testing were triaged/patched/fixed or at least 
pinged
- -  54 bugs were tagged to show if they affect Squeeze, several other bugs were
pinged to retrieve necessary information or to trigger an update in the next
stable pointrelease.
- -  5 packages were introduced into Debian (still in NEW, though) - the
Spacewalk client related packages and libapache2-mod-auth-memcookie.

Accomodation
- -
Thanks to Debian funds we were able to provide accomodation for four
participants in the JUFA youth hostel in Salzburg.
We had paid in advance for eight, but changing to rooms with a higher category
for only 4 people would have been equally or more expensive.


Press/Media coverage
- ---_-
Additionally to being mentioned in the calendars on ProLinux and similar
pages, we had some press coverage by the local newspaper and online magazines:

- -  [Scan of Salzburger Woche / Stadt
Nachrichten](http://www.conova.com/fileadmin/user_upload/dl.php?file=files/Presse_Debian_Bug_Squashing_Party_Stadt_Nachrichten.pdf)
- -  [article on the Salzburger Nachrichten
website](http://search.salzburg.com/news/artikel.html?uri=http%3A%2F%2Fsearch.salzburg.com%2Fnews%2Fresource%2Fsn%2Fnews%2Fst152700_15.06.2012_41-40204916)
- -
[meinbezirk.at](http://regionaut.meinbezirk.at/salzburg-stadt/leute/debian-bug-squashing-party-erstmals-in-salzburg-d194324.html/action/lesen/1/recommend/1/)
- -  [Salzburg Cityguide -
Photogallery](http://www.salzburg-cityguide.at/de/partyzone/detail/debian-bug-squashing-party---conova_102492)


Fun facts
- -
We consumed 2kg of Leberkas, a big plate of "Buchteln mit Vanillesosse", about
16000cm^2 of Pizza, about 80 litres of coke, juice, beer and whine and I guess
we drank at least the same amount of water. We had coffee made of 1.5kg coffee
beans and managed to empty the (formerly well filled) icemaker in the fridge.
Also we had successful training sessions of a standard Debconf game (rules
won't be explained here obviously). Maybe we even successfully spread the game
to the employees of a commercial linux distribution ;)



- -- 
  Bernd ZeimetzDebian GNU/Linux Developer

  http://bzed.dehttp://www.debian.org
  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIbBAEBCAAGBQJP4PysAAoJEOs2Fxpv+UNfedIP+LpbOOiIgbSOR95L+78kxzM1
AXr/eDEVv3uGpIslaQ2PIUaDGFiB0ecBxnloajrXBKoY46X/rLORQMBb6yyN/jHD
L3HzZWU8tZyyvObFiedMsi/OwW/qALT/BXi3MAIIR8+Y8pMKUWCt0jWjCKr13QOC
F/0ZFA47R7uFO2iQOgw6bkQp2NIBeh7PUX3TV/sK0AUwWt3e7LeVF4rU5nzDyzCu
gACn4+jG7XwdTERT/3YMmMwhKOl7HLUBGMWNX6/JfFhj0xDxc9SXckpiZg+bk+xi
Vp0yjwEkNd63GPk5032hqBa60yYlqJaJot1DVKKHbQSm1xPyXTn7NaLWvSxJCb5y
7NwyCGkQGnWGjQvxvy+22OsuYgWAc6GknQuMOCwX6l6bDIfbM013uXPmELi3m6Bj
5Y231jxa4HbZYuk5ZKSx1H7ktNE49dxyTHxa0T0pK97PDb0EpM4Uwp9iPkc1r5Bg
feOee7QBotQEg/DFuRGNqylVsnWwxqtL+mmRIGPrfhvI3/41gt/Tm+yvm6bpPUGq
DW68QTqhQBwLzcdMO4vYpAlFsR9Ggk1GQxF3hv7EyEPVeg3yHrpKVNocJbti0EIg
wl6uSxlnVOIW2M1U5Ezo45yqy8tjx4FDp0QMgUpt0OwKxWH3Cwh86udQUOTRYPbf
yHMWXVt2ordA5q7jCbc=
=SpWN
-END PGP SIGNATURE-



Sounds like it was a lot of fun!

Has anyone thought about starting a hangout at Google+?

It would be a lot more convenient (especially for newbies)
than Internet Relay Chat (IRC), something I never took to.

Regards,
Philip Ashmore


--
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/4fe1c34

Re: Summary: Moving /tmp to tmpfs makes it useless

2012-06-20 Thread Stephan Seitz

On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote:

If you write to /tmp on disk and someone or something calls "sync" at
precisely the wrong moment, you're stuck, and your performance suffers.
Not so with tmpfs.


Maybe, but we are talking about defaults. Please correct me, but I think 
that most Debian systems are in some way single user systems.



I'm not saying the speedup will be extreme, but it will be there, and
(cumulated over loads of programs using /tmp) it will be significant
enough to be noticeable.


If you train the user to keep away from /tmp, because it may be too small 
with tmpfs, how much programs will use it then?



- Any data transformation or filtering which needs to be done in
 multiple passes over a file would use a temporary file for
 intermediate results, which it then reads in again for the next pass.
 Multi-pass video transcoding is an example of this, and which
 (depending on the codecs used and the hardware on which it runs) could
 certainly be I/O bound.


I agree, but only if your tmpfs is big enough to hold the file. Ripping 
DVDs or BDs will exceed any tmpfs limit on most systems.



The point is that neither you nor I can reasonably be expected to list
all possible uses of /tmp; and that RAM is faster than disk, so that
when you access a tmpfs you're going to be somewhat faster than when you
access a disk-backed filesystem, at least until you start swapping (if
not longer).


Nobody disagrees that RAM is faster than disk, but I hope you don’t 
disagree as well that most people will have more disk space than RAM.



Now whether that advantage outweighs the disadvantages you've outlined
is something we can talk about. However, whether RAM is faster than disk


Fine let’s talk. Why can’t we find a compromise? Additional to our disk 
/tmp we create a /ramtmp (so the name suggests that this tmp is 
a ramdisk) with tmpfs. This should be doable in time for Wheezy. The 
release notes should mention it. And those who wish can patch their 
programs to use the ramdisk if they think their program uses only small 
temporary files. In this way, we get some data and experience. And we 
have both worlds. /tmp on disk for even large temporary files and /ramtmp 
as fast ramdisk.



No, that's not true. The real danger in filling up /tmp is not that
other processes can't write temporary files anymore (causing a minority
of processes to hang or die; those who just happen to need temporary
storage at that point in time), but that no process can write any file
anymore (causing a significant majority of processes to hang or die).


But this will only happen if your /tmp is not a separate partition. And 
it can happen with /var as well. I’ve seen programs logging so fast that 
/var had no space left breaking the logging and the database.


We can now start another discussion what should be the best partition 
layout for a default installation, but /tmp is not the only problem. And 
/var/tmp exists as well for everyone writeable.


Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature


Bug#678273: ITP: powerstat -- laptop power measuring tool

2012-06-20 Thread Colin Ian King
Package: wnpp
Severity: wishlist
Owner: Colin Ian King 

* Package name: powerstat
  Version : 0.01.15
  Upstream Author : Colin Ian King 
* URL : http://kernel.ubuntu.com/~cking/powerstat
* License : GPL-2
  Programming Lang: C
  Description : laptop power measuring tool

Powerstat measures the power consumption of a mobile PC that has
a battery power souce.  The output is like vmstat but also shows
power consumption statistics.  At the end of a run, powerstat
will calculate the average, standard deviation and min/max of
the gathered data.



-- 
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/20120620141415.23225.64635.reportbug@lenovo



Bug#678277: ITP: eventstat -- kernel event states monitoring tool

2012-06-20 Thread Colin Ian King
Package: wnpp
Severity: wishlist
Owner: Colin Ian King 

* Package name: eventstat
  Version : 0.01.14
  Upstream Author : Colin Ian King 
* URL : http://kernel.ubuntu.com/~cking/eventstat
* License : GPL-2
  Programming Lang: C
  Description : kernel event states monitoring tool

Eventstat periodically dumps out the current kernel event state.
It keeps track of current events and outputs the change in events
on each output update.  The tool requires sudo to run since it
needs to write to /proc/timer_stats to start and stop the event
monitoring.



-- 
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/20120620143810.23901.18114.reportbug@lenovo



Re: Report from the Bug Squashing Party in Salzburg

2012-06-20 Thread The Fungi
On 2012-06-20 13:34:22 +0100 (+0100), Philip Ashmore wrote:
[...]
> Has anyone thought about starting a hangout at Google+?
[...]

Sounds intruiging. Is there a Debian package in main so I can run a
Google+ server easily? Setting up my own IRC servers is already
pretty trivial, but if all the cool kids are installing Google+
servers these days...
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }


-- 
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/20120620144821.gx1...@yuggoth.org



Bug#678294: ITP: innoextract -- a tool for extracting data from an Inno Setup installer

2012-06-20 Thread Lennart
Package: wnpp
Severity: wishlist
Owner: Lennart 


* Package name: innoextract
  Version : 1.2
  Upstream Author : Daniel Scharrer 
* URL : https://github.com/dscharrer/InnoExtract
* License : ZLib
  Programming Lang: C++ 
  Description : a tool for extracting data from an Inno Setup installer

Inno Setup is a tool to create installers for Microsoft Windows applications.
Inno Extracts allows one to extract such installers under non-windows systems
without running the actual installer using wine. Inno Extract currently
supports installers created by Inno Setup 1.2.10 to 5.4.3.



-- 
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/20120620170844.11841.84742.reportbug@nas.local



Re: Summary: Moving /tmp to tmpfs makes it useless

2012-06-20 Thread Carlos Alberto Lopez Perez
On 20/06/12 15:18, Stephan Seitz wrote:
>>
> 
> Fine let’s talk. Why can’t we find a compromise? Additional to our disk
> /tmp we create a /ramtmp (so the name suggests that this tmp is a
> ramdisk) with tmpfs. This should be doable in time for Wheezy. The
> release notes should mention it. And those who wish can patch their
> programs to use the ramdisk if they think their program uses only small
> temporary files. In this way, we get some data and experience. And we
> have both worlds. /tmp on disk for even large temporary files and
> /ramtmp as fast ramdisk.

I really think this is the way to go :)


-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature


Re: [hardening-discuss] Using hardening-wrapper but lintian warning still present

2012-06-20 Thread Kees Cook
Hi José,

On Wed, Jun 20, 2012 at 12:21:15PM +0200, José Luis Segura Lucas wrote:
> I'm intending to package a software for Debian. I have a Debian package
> with some lintian warning about hardening, but I removed most of them
> using hardening-wrapper and the env DEB_BUILD_HARDENING=1 in my
> debian/rules.

If you're using debhelper compat level 9, you don't have to worry about
including hardening-wrapper and using DEB_BUILD_HARDENING=1. You'll get
the defaults automatically through debhelper. This is the preferred way
to get build flags now.

> I only have one lintian warning now: hardening-no-fortify-functions
> 
> I see that the -D_FORTIFY_SOURCE=2 is included in each compiler
> execution. This is the output of hardening-check:
> 
> $ hardening-check --verbose /usr/bin/grive
> /usr/bin/grive:
>  Position Independent Executable: yes
>  Stack protected: yes
>  Fortify Source functions: no, only unprotected functions found!
> unprotected: memmove
> unprotected: read
> unprotected: memcpy
>  Read-only relocations: yes
>  Immediate binding: yes
> 
> I asked on debian-devel and they told me that I can add an override if
> only memmove ormemcpy is shown, but I have an unprotected read too.
> 
> How can I avoid this warning? It is my last problem after doing the RFS...

It is possible that the read() was checked at compile-time to be
safe which is why it was not linked with the protected version
("__read_chk"). For example, this will always be safe:

char buf[100];
...
read(fd, buf, 50);

In this case, the compiler can see that the read() can never overflow
the buf (50 is less than 100), so there is no reason to use the protected
function.

If you're building with -O1 (or higher) and -D_FORTIFY_SOURCE=2, the
compiler is always always going to be doing the right thing. :)

If you really want to, you can test that this is the case by finding the
uses of read() and using a volatile global variable to replace the length
argument. (Don't leave the code like this, since it's not a useful change,
but it can be used to make sure the compiler is doing the right thing.)

  volatile size_t read_length;
  ...
  char buf[100];
  ...
  read_length = 50;
  read(fd, buf, read_length);

If making that change causes hardening-check to see the __read_chk call,
then the compiler is being smart and noticed that it doesn't need to do
extra work at run time to verify the arguments, and you're clear to put
in a lintian override.

-Kees

-- 
Kees Cook@outflux.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120620195621.ge5...@outflux.net



Re: [hardening-discuss] Using hardening-wrapper but lintian warning still present

2012-06-20 Thread Kees Cook
On Wed, Jun 20, 2012 at 12:56:21PM -0700, Kees Cook wrote:
> If you're building with -O1 (or higher) and -D_FORTIFY_SOURCE=2, the
> compiler is always always going to be doing the right thing. :)

Heh, this was supposed to read "almost always". :P

-- 
Kees Cook@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/20120620200125.gg5...@outflux.net



Re: [hardening-discuss] Using hardening-wrapper but lintian warning still present

2012-06-20 Thread Julien Cristau
On Wed, Jun 20, 2012 at 12:56:21 -0700, Kees Cook wrote:

> If you're using debhelper compat level 9, you don't have to worry about
> including hardening-wrapper and using DEB_BUILD_HARDENING=1. You'll get
> the defaults automatically through debhelper. This is the preferred way
> to get build flags now.
> 
Only if you're using dh.  Not quite the same thing.

Cheers,
Julien


signature.asc
Description: Digital signature


Re: [hardening-discuss] Using hardening-wrapper but lintian warning still present

2012-06-20 Thread Russ Allbery
Julien Cristau  writes:
> On Wed, Jun 20, 2012 at 12:56:21 -0700, Kees Cook wrote:

>> If you're using debhelper compat level 9, you don't have to worry about
>> including hardening-wrapper and using DEB_BUILD_HARDENING=1. You'll get
>> the defaults automatically through debhelper. This is the preferred way
>> to get build flags now.

> Only if you're using dh.  Not quite the same thing.

And the build system honors the flags that dh passes in.  There are a
variety of prerequisites that have to be in place for this to all just
work.  If the package is using Autoconf and friends, it probably will, but
it's not guaranteed.  (I have at least one package using Autoconf that
overrides the build flags for historical reasons and loses the hardening
stuff.)

-- 
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/878vfh7n9w@windlord.stanford.edu



Bug#678338: ITP: konoha -- interpreter of statically-typed scripting language Konoha

2012-06-20 Thread Tadaki SAKAI
Package: wnpp
Severity: wishlist
Owner: Tadaki SAKAI 

* Package name: konoha
  Version : 2.0.0
  Upstream Author : Kimio Kuramitsu 
* URL : https://github.com/konoha-project/konoha
* License : 2-clause BSD license
  Programming Lang: C
  Description : interpreter of statically-typed scripting language Konoha

Konoha is a new scripting language that offers flexible scripting and
static programming features. It guaranteed a smooth coding environment
and ease of use.



-- 
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/5e7gv1fwx9.wl%stadaki@gmail.com



Re: Report from the Bug Squashing Party in Salzburg

2012-06-20 Thread Philip Ashmore

On 20/06/12 15:48, The Fungi wrote:

On 2012-06-20 13:34:22 +0100 (+0100), Philip Ashmore wrote:
[...]

Has anyone thought about starting a hangout at Google+?

[...]

Sounds intruiging. Is there a Debian package in main so I can run a
Google+ server easily? Setting up my own IRC servers is already
pretty trivial, but if all the cool kids are installing Google+
servers these days...
No, I meant using Googles Google+ as an alternative to setting a 
location, arranging accommodation, setting aside X number of days for 
the trip, getting to and from there...


Some bugs triaging may require participants to reboot their PC (not 
everyone has laptops) so a bug squashing hangout would allow members to 
come and go.


The thought of setting up personal (or even Debian-wide) Google+ servers 
never occurred to me.


Regards,
Philip Ashmore


--
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/4fe253b5.5010...@philipashmore.com



Re: Report from the Bug Squashing Party in Salzburg

2012-06-20 Thread Paul Wise
On Thu, Jun 21, 2012 at 6:50 AM, Philip Ashmore wrote:

> The thought of setting up personal (or even Debian-wide) Google+ servers
> never occurred to me.

I think you might have missed the point. Google+ is a proprietary SaaS
used for selling your eyeballs to advertisers. It is unlikely that
Google will ever let it be installed on other servers, let alone
release the source code under a free license. Debian should avoid
using such SaaS offerings and promote the free alternatives that exist
and the movements that support them, some links:

http://autonomo.us/
http://wiki.debian.org/FreedomBox
http://mako.cc/writing/hill-free_tools.html

-- 
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/CAKTje6Ejw0KnhFDcgJpkxWJi3i-vNcBUJC6Tjfev2oUXgU+U=g...@mail.gmail.com