FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

LinkBack Thread Tools
Old 07-04-2011, 01:34 AM
Jonas Smedegaard
Default Bug#632610: ITP: ruby-chunky-png -- pure ruby library for read/write, chunk-level access to PNG files

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard <dr@jones.dk>

* Package name : ruby-chunky-png
Version : 1.2.0
Upstream Author : Willem van Bergen <willem@railsdoctors.com>
* URL : https://github.com/wvanbergen/chunky_png/
* License : Expat
Programming Lang: Ruby
Description : pure ruby library for read/write, chunk-level access to PNG files

This pure Ruby library can read and write PNG images without depending
on an external image library, like RMagick. It tries to be memory
efficient and reasonably fast.
* Decodes any image that the PNG standard allows. This includes all
standard color modes, all bit depths and all transparency,
interlacing and filtering options.
* Encodes images supports all color modes (true color, grayscale and
indexed) and transparency for all these color modes. The best color
mode will be chosen automatically, based on the amount of used
* R/W access to the image's pixels.
* R/W access to all image metadata that is stored in chunks.
* Memory efficient (uses a Fixnum, i.e. 4 or 8 bytes of memory per
pixel, depending on the hardware)
* Reasonably fast for Ruby standards, by only using integer math and a
highly optimized saving routine.
* Interoperability with RMagick if you really have to.

To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110704013434.18154.56771.reportbug@localhost.loc aldomain">http://lists.debian.org/20110704013434.18154.56771.reportbug@localhost.loc aldomain

Mon Jul 4 05:30:01 2011
Return-path: <users-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Mon, 04 Jul 2011 04:40:08 +0300
Received: from bastion02.fedoraproject.org ([]:55655 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <users-bounces@lists.fedoraproject.org>)
id 1QdY8u-0006gS-74
for tom@linux-archive.org; Mon, 04 Jul 2011 04:40:08 +0300
Received: from lists.fedoraproject.org (collab1.vpn.fedoraproject.org [])
by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP id 987541108F6;
Mon, 4 Jul 2011 01:43:53 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [])
by lists.fedoraproject.org (Postfix) with ESMTP id A3F4E3267A1;
Mon, 4 Jul 2011 01:43:52 +0000 (UTC)
X-Original-To: users@lists.fedoraproject.org
Delivered-To: users@lists.fedoraproject.org
Received: from smtp-mm01.fedoraproject.org (smtp-mm01.fedoraproject.org
by lists.fedoraproject.org (Postfix) with ESMTP id A0A5C3267A0
for <users@lists.fedoraproject.org>;
Mon, 4 Jul 2011 01:43:50 +0000 (UTC)
Received: from smtp507.mail.kks.yahoo.co.jp (smtp507.mail.kks.yahoo.co.jp
by smtp-mm01.fedoraproject.org (Postfix) with SMTP id D5EDD87E5F
for <users@lists.fedoraproject.org>;
Mon, 4 Jul 2011 01:43:48 +0000 (UTC)
Received: (qmail 28620 invoked by alias); 4 Jul 2011 01:43:43 -0000
Received: from unknown (HELO ? ( with plain)
by smtp507.mail.kks.yahoo.co.jp with SMTP; 4 Jul 2011 01:43:43 -0000
X-Apparently-From: <supergiantpotato@yahoo.co.jp>
Subject: Re: HD permissions stay put
From: =?UTF-8?Q?=E5=A4=9C=E7=A5=9E_=E5=B2=A9=E7=94=B7?=
To: users@lists.fedoraproject.org
In-Reply-To: <1309737368.487.16.camel@bree.homelinux.com>
References: <4E108F93.6080206@telkomsa.net> <iuqadr$tci$2@dough.gmane.org>
<4E10AE63.2040709@gmail.com> <4E10B058.4030007@telkomsa.net>
<4E10B436.2030809@gmail.com> <iuqmq5$rmc$3@dough.gmane.org>
Date: Mon, 04 Jul 2011 10:43:42 +0900
Message-ID: <1309743822.14981.12.camel@ika.shinden.murasaki>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14)
X-BeenThere: users@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Community support for Fedora users <users@lists.fedoraproject.org>
List-Id: Community support for Fedora users <users.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/users>,
<mailto:users-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/users>
List-Post: <mailto:users@lists.fedoraproject.org>
List-Help: <mailto:users-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/users>,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: users-bounces@lists.fedoraproject.org
Errors-To: users-bounces@lists.fedoraproject.org

On Sun, 2011-07-03 at 19:25 -0430, Patrick O'Callaghan wrote:
> On Sun, 2011-07-03 at 14:46 -0700, JD wrote:
> > I think you have exposed a very interesting problem.
> It would be interesting if the problem hadn't been known about for the
> last 20 or 30 years, i.e. since Unix systems started being networked in
> large numbers.
> This is exactly the reason Sun created NIS (formerly called Yellow
> Pages). Using NIS a set of machines can keep user ids and other info in
> sync. Nowadays LDAP is also used for this, as is Active Directory in the
> Windows world.
> Unfortunately for people with only a couple of machines on their home
> network, these are usually too much trouble to set up, so the only
> solution is manually to keep UIDs/GIDs consistent across machines.
> poc

Yeah... NIS would be a bit overkill for a single user case.

I used to play on multiple distros (a *lot*), split right down the
middle between Debian- and RPM-based systems. The solution to this is
pretty simple for a single-user (or very few user) system. Every time
you create a user on any system, specify the UID & GID explicitly, and
always use UIDs/GIDs <= 1000. Fedora doesn't care if you have a UID much
higher than 500, but Debian does care if your UID is lower than 1000 (in
fact, the man page for "useradd" on Fedora even says that 1000 is the
standard, Fedora just doesn't actually follow that).

So an example for me could be:

useradd -u 1001 -g 1001 i-yagami

So long as I use that same command to add myself to every system, no
conflicts occur anywhere. On the other hand, if I add a new system and
just enter "useradd i-yagami" (or use a GUI tool to add a user without
declaring the uid/gid manually) then the account will either have a uid
and gid of 1000 or 500, but either way my real /home/i-yagami folder
will not be the place my new, mistaken home gets created and the
permissions of the real home folder from within the new system will
simply say 1001:1001.

I don't really like the idea of passing the shadow and passwd files
around between systems or doing a lot of pipeline magic to fix
inconsistencies between such files across distros. The problem is that
different distros/systems handle user creation differently and you can
be unexpectedly missing things or having weird minor trouble with your
shared home folder. So going through the explicit "useradd -u # -g #
[name]" process was the easiest way for me and its anything but a burden
when dealing with a handful of users.

users mailing list
To unsubscribe or change subscription options:
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Thread Tools

All times are GMT. The time now is 02:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org