Re: Debug output etc, cluttering the terminal

[Michael Welle]

Good morning (at least in my time zone ;)),

Christian PERRIER  writes:

> Quoting Michael Welle (mwe012...@gmx.net):
>> Hello,
>> 
>> what is the reason that many applications clutter the terminal with
>> output that is obvisously debug output? Lets take digikam as an
>> example:
>
>
> (I read most other comments in this thread before writing this)
tough guy ;).


> I have to concur to everything that was brought by poeple who *don't*
> want this debug gibberish to appear either in their terminal or in
> their ~/.xsession-errors:
>
> Here's mine, started yesterday morningand I barely did nothing
> since then as I'm more travelling around Vermont that playing with my
> KDE apps:
>
> bubu...@mykerinos:~/travail/debian/translation/po-debconf/gitolite> ls -l 
> ~/.xsession-errors
> -rw--- 1 bubulle bubulle 2511641 15 août  18:28 
> /home/bubulle/.xsession-errors
[...]
> And, finally, as someone who often leaves his own desktop environment
> opened for months in the same session, at work, I deeply concur to
> Holger's comment about wasting space in home directories (mine being
> constrained to a few gigabytes). 
Try to delete it ;-).


> Thankfully, there, I'm not using KDE
Neither do I.


> and not even Debian, indeed..:-)
And there goes another hero down the drain ;).


Sorry for only kidding in this posting. I'd just returned from a wasted
morning with my government and need to recover.


Regards
hmw

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html


--
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/87wrrr57b3@stella.c0t0d0s0.de

Re: why are there /bin and /usr/bin...

[Marc Haber]

On Sun, 15 Aug 2010 18:30:04 -0400, "Perry E. Metzger"
 wrote:
>The true reason is that back in ancient days, hard drives were too
>small to put everything in one place, so ancient Unix machines at Bell
>Labs in the 1970s ended up with some programs on the root disk and
>some on the same supplementary disk where the home directories were
>typically put. This was not done with any great forethought, it was
>simply a temporary expediency. Because / was on the boot disk, it was
>necessary to make sure that every program needed for initial boot was
>there, and thus some programs were more important to put in /bin and
>the like.
>
>By the early 1990s this was long since unneeded but people continued
>to do it anyway, and in fact started to think it was done for
>technical reasons rather than because of a simple lack of space in an
>earlier era. At this point (2010), with all of the system files
>fitting in under a dollar's worth of disk space, people tell
>themselves quite elaborate "just so" stories about why the segregation
>is maintained.

I like the idea that a server in an unattended location only needs a
tiny (50 MB would be more than enough if our kernels weren't so huge)
partition to come up to a manageable state, even if the larger file
systems holding the major parts of the system were corrupted or
absent. This has enabled me to repair systems from remote more than
once in the past.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1okv91-0008hm...@swivel.zugschlus.de

Re: libcairo2 in squeeze & subpixel rendering

[Josselin Mouette]

Le lundi 09 août 2010 à 23:40 +0400, Stanislav Maslovski a écrit :
> Thus I repeat: the subpixel rendering of fonts in current squeeze is
> suboptimal, because instead of providing flexibility and full control
> it virtually limits the choice of fonts by roughly two families, one
> of which is non-free.

And the other one being the default.

I’ll let you come back with accurate figures of the number of users who
change the default fonts.

kthxbye,
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
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/1281953208.5689.10.ca...@meh

libexplain: need access to debian alpha machine

[Peter Miller]

Hi Folks,

I'm trying to get my libexplain project [1] to build on Debian alpha.
I don't actually have access to an alpha machine, so my feedback loop is
via the Debian build farm [2]... one fix per release.

This isn't completely satisfactory.  Can anyone suggest a dev machine I
can ssh to, and do the edit-build-test loop more efficiently?

[1] http://libexplain.sourceforge.net/
[2] https://buildd.debian.org/pkg.cgi?pkg=libexplain&dist=unstable

-- 
Peter Miller 


--
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/1281953143.28554.6.ca...@hawk

Re: Notes from the DebConf Source Format BoF

[Simon McVittie]

On Sun, 15 Aug 2010 at 22:28:52 +0100, Roger Leigh wrote:
> > Best practices for Git repository layout?
> > - git-buildpackage documentation is closest to that
> 
> I would have to disagree here, the git-buildpackage default layout is
> far too "Debian-centric".  By naming the Debian and Upstream branches
> "master" and "upstream" it's only really useful if you're importing
> upstream release tarballs.

In pkg-telepathy, I objected to 'master' for the same reasons. We use:

debian
Main Debian branch (and set foo.git/HEAD on git.debian.org to point to it,
using:
git symbolic-ref HEAD refs/heads/debian)
debian-squeeze, debian-experimental (etc.)
Other Debian branches, whenever we need to fork the packaging
upstream
git-import-orig imports of upstream release tarballs
upstream-experimental (etc.)
(occasionally) g-i-o imports of upstream release tarballs for which we're
currently targeting experimental (etc.)
debian-patches
Patches cherry-picked from upstream, rebased onto 'upstream' with each
upstream release (also occasionally debian-squeeze-patches, etc.)

We've occasionally also had Maemo release names (diablo, fremantle) as
downstream branches from the 'debian' branch, to make backports to Maemo's
older toolchain.

At the moment we use upstream orig tarballs on our upstream branch rather than
the contents of upstream git, but only because this seems to be best-practice.
I'm not entirely happy about the branch name 'upstream' for this reason (I
wanted to call it 'tarballs'), but other team members persuaded me that
following the de facto standard layout was more important.

We check in a debian/gbp.conf to make sure everyone is using this branch
structure and using pristine-tar, and alter it as necessary when branching.
For instance, see the patch to that file in:
http://git.debian.org/?p=pkg-telepathy/telepathy-glib.git;a=commitdiff;h=5176e10ea4a4c3e15aa26f1f456bafa202c2c275

When dealing with projects that need individual patches backported, I sometimes
add the upstream git repository as a remote, and cherry-pick patches that way.

In practice the debian-patches branch is troublesome; we've had to switch off
the normal shared repository "deny non-fast-forwards" option for its benefit.
If I was setting up git repositories for a new team, I'd advocate the way
gbp-pq works instead (its patch-queue branch is intended to be a
local-developer thing that's never pushed, and everyone synchronizes via the
patch series in debian/patches).

Simon


-- 
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/20100816102751.ga28...@reptile.pseudorandom.co.uk

Re: Debug output etc, cluttering the terminal

[Tollef Fog Heen]

]] Lars Wirzenius 

| On su, 2010-08-15 at 14:19 +0200, Tollef Fog Heen wrote:
| > I would guess they still fill up the .xsession-errors file, though?  At
| > least for me, that file is mostly useless due to:
| > 
| > « ...Too much output, ignoring rest... »
| > 
| > as the last line.
| 
| It's pretty clear to me that both .xsession-errors and the stderr of GUI
| apps are lousy ways of logging debugging messages. Something similar to
| syslog for a per-user/per-session would be a very useful thing to have,
| in my opinion.

FWIW, systemd (which can work both as an init replacement as well as a
session manager) handles this by forwarding those to syslog (by
default), which at least partially works around the problem of disks
filling up.  Priority is then set by the same convention as printk, that
is, you do <4> Foo to log «Foo» at log level 4, aka warning.  It'd be
neat to have a way to post-mortem get at the logged output of an
application and have that appear if you submit a bug report or similar.
(Think bug-buddy in gnome or apport in Ubuntu.)

-- 
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/877hjqalv6@qurzaw.linpro.no

Re: RFC: Policy 10.1 and appropriateness of package conflicts

[Ian Jackson]

Wouter Verhelst writes ("Re: RFC: Policy 10.1 and appropriateness of package 
conflicts"):
> wou...@celtic:~$ ls -l /usr/bin/gcc
> lrwxrwxrwx 1 root root 7 jun  6 07:23 /usr/bin/gcc -> gcc-4.4
> wou...@celtic:~$ dpkg -S /usr/bin/gcc
> gcc: /usr/bin/gcc
> wou...@celtic:~$ dpkg -S /usr/bin/gcc-4.1
> gcc-4.1: /usr/bin/gcc-4.1
> 
> How is that any different?

The name "gcc" isn't namespace pollution.  The package which provides
the name gcc is also a stably-named metapackage so has another reason
for existing.  I don't think this is the case with fsl.

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

Re: Raw Idea: one more control field for sponsors

[Ian Jackson]

Bernd Zeimetz writes ("Re: Raw Idea: one more control field for sponsors"):
> On 08/13/2010 06:22 PM, Goswin von Brederlow wrote:
> > How? The changes file might not contain the sponsor not the control
> > file. You can get the keyid of the sponsor from the changes file. But
> > would people be happy to recieve bug reports on the email address of
> > their gpg key? And which uid do you use?
> 
> You use usern...@debian.org. The key-id of the uploader is tracked anyway, so
> there is not much missing.

Debian developers are not required to use or accept mail at their
@debian.org address.  I don't, because of spam.

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

Re: More advanced home directory creation in Debian?

[Ian Jackson]

Ben Hutchings writes ("Re: More advanced home directory creation in Debian?"):
> On Fri, Aug 13, 2010 at 03:41:45PM +0100, Ian Jackson wrote:
> > One problem is that run-parts does not currently support passing
> > arguments to its scripts:
> 
> It does; use the --arg option.

So it does.  Urgh, what a horrid syntax!  I admit that I assumed that
you'd pass the arguments as arguments ...

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

Re: Notes from the DebConf Source Format BoF

[Ian Jackson]

Adam Borowski writes ("Re: Notes from the DebConf Source Format BoF"):
> On Fri, Aug 13, 2010 at 11:54:07PM +0100, Ben Hutchings wrote:
> > git://foo.bar.org/meow#debian
>
> At least, neither git clone, merge nor fetch understand that syntax.

They could and should, however, be updated to do so.  (Why they don't
is just one more mystery about git's atrocious user interface.)

> But for tools that can split that URL and specify --branch, either space and
> hash would work.  I never heard of that convention before, but if there are
> any people who already use hash, that makes it better than space which I
> invented just in the previous mail.

The space syntax can't be sensibly supported by git-clone etc.  So
that's another reason to prefer the # syntax.

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

Re: Notes from the DebConf Source Format BoF

[Ian Jackson]

Russ Allbery writes ("Re: Notes from the DebConf Source Format BoF"):
> That's not the problem being discussed here.  The signature is fine.  The
> problem is that while Joey may think that his repository is completely
> DFSG-free, it's the current job of ftp-master to actually check that.  For
> a complete repository, that's a lot of work.  Should ftp-master just trust
> Joey that there's no non-DFSG code anywhere in history?  Who should be
> trusted?  We get into very murky ground here, which is much different than
> the current review process.

I would suggest that if we can solve the other problems, this can be
dealt with by saying that ftpmaster is expected to check that:
  * The repository with full history is publicly available elsewhere
  * The tip of the branch which will be in our archive is fine

If it should happen that the repository is unredistributable then
we'll remove it when this is pointed out.

We should have a policy about non-free but redistributable.

Personally I think this is in the same category as repackaging source
packages to remove RFCs: useless make-work.  We are not helping
software freedom by making our own work more difficult because of a
largely entirely theoretical possibility that promotion of non-free
licences or code might be encouraged by our failure to redact their
existence out of even the history of our little fragment of the
universe.

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

Re: Debug output etc, cluttering the terminal

[Ben Hutchings]

On Sun, 2010-08-15 at 17:02 +0100, Neil Williams wrote:
[...]
> Most of the stuff in ~/.xsession-errors which has been mentioned here,
> are exactly these kind of assertion failure errors:
> 
> (gnome-power-manager:2346): GLib-GObject-WARNING **: value "-nan" of
> type `gdouble' is invalid or out of range for property `percentage' of
> type `gdouble'
> 
> (polkit-gnome-authentication-agent-1:2468): GLib-CRITICAL **:
> g_once_init_leave: assertion `initialization_value != 0' failed
> 
> Those are BUGS. It might not cause symptoms now but it is still
> relevant to how other bugs in that application are triaged. The
> upstream code needs to be fixed to check these values before passing
> them to the relevant function.

I mostly agree with this.  These are warnings, not simply debug
information, and the application author should fix them.  However, each
specific warning should only be printed once, since that's enough to
indicate the existence of the bug.

[...]
> Not a default across all packages and all debug output but there are
> situations where *some* debug output needs to be part of the default
> output of the application in order to actually capture the data
> necessary to fix the bugs.
> 
> Some applications, even some mature applications, need to be able to
> output debug information to the controlling terminal as a matter of
> course in order to fix unreproducible and/or intermittent bugs.
[...]

This is nonsense.  What the application authors need in this case is
logging, and writing to stderr is not logging (modulo use of e.g.
systemd to capture stderr).  They need to open an application- and
user-specific log file and write to that instead.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

OMG WTF BBQ balloons

[Ian Jackson]

I just had to tell NoScript "forbid debian.org" because I wanted to
read a bug report.

I don't want to be a spoilsport but, honestly!

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

Re: Notes from the DebConf Source Format BoF

[Josef Spillner]

In data lunedì, 16. di agosto 2010 12:35:29, Ian Jackson ha scritto:
: > Adam Borowski writes ("Re: Notes from the DebConf Source Format BoF"):
> > On Fri, Aug 13, 2010 at 11:54:07PM +0100, Ben Hutchings wrote:
> > > git://foo.bar.org/meow#debian
> > 
> > At least, neither git clone, merge nor fetch understand that syntax.
> 
> They could and should, however, be updated to do so.  (Why they don't
> is just one more mystery about git's atrocious user interface.)

A good complementary action would be to poke the respective developers to 
establish at least provisional URI schemes at IANA [1] so that the semantics 
of the URL components can be fixated. From my own experience doing so [2] it 
was communicated to me that fragment identifiers (#foo) are somewhat 
problematic when used beyond of document URLs. Similarly, SVN peg revisions 
(@foo) were added as an afterthought rather than part of the initial SVN 
designs which reuse file, HTTP and +SSH URI schemes, and similar issues might 
affect other VCSs.

Josef

[1] http://www.iana.org/assignments/uri-schemes.html
[2] http://www.ietf.org/mail-archive/web/uri-review/current/msg00817.html


--
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/201008161331.06827.2...@kuarepoti-dju.net

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Ian Jackson]

Russ Allbery writes ("Re: Non-recompilable binaries in source and binary 
packages (Adobe Flash strikes again)"):
> Ian Jackson  writes:
> > If you have this situation you have to have two separate source
> > packages; one in main which builds only the free parts, and one in
> > non-free which builds only the non-free parts.
> 
> I don't believe this is correct.  Source packages in main can build
> binaries in contrib, and I believe the problem with not being able to
> rebuild with free tools is more of a contrib thing than a non-free thing.

Well, some maintainers have been rebuilding source packages to remove
things like RFCs and non-free-GFDL documentation.  Perhaps not
everyone has.

> But I'm not certain, which is why I was hesitating to reply to the first
> message.

It looks like there's confusion in this area.  Perhaps policy could be
clarified.

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

Re: OMG WTF BBQ balloons

[Dominic Hargreaves]

On Mon, Aug 16, 2010 at 12:00:09PM +0100, Ian Jackson wrote:
> I just had to tell NoScript "forbid debian.org" because I wanted to
> read a bug report.
> 
> I don't want to be a spoilsport but, honestly!

Agreed, this is just disruptive. If they must stay, at least make it
possible to turn them off without resorting to local browser policies.

Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


-- 
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/20100816112633.gw...@urchin.earth.li

Re: why are there /bin and /usr/bin...

[Tollef Fog Heen]

]] "Perry E. Metzger" 

| In the embedded space, which I know a lot about, it is true that the
| root FS is on flash or other expensive media -- but it isn't like /usr
| is on cheaper media in such an environment, it is always part of the
| root fs anyway, so it makes no difference.

Take a look at the N900 where most of the user-installed applications
are on /home (well, /opt, but that's a symlink to /opt/home), which is a
32GB eMMC flash, while the root file system is a 256MB NAND flash, which
is vastly more expensive.  So while the situation you are describing
might be common, it's not always true.

[...]

| I have no actual expectation that anyone is going to change how this
| is done, because /usr is so heavily ingrained in people's experience
| of Unix even though it is an onion.

What I'd like to see happen here is that having /usr a symlink to /
becoming a supported configuration.  I keep meaning to set up a system
like that and see what breaks, but haven't gotten around to it yet.

-- 
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/87zkwm9399@qurzaw.linpro.no

Re: OMG WTF BBQ balloons

[Tanguy Ortolo]

Le lundi 16 août 2010, Dominic Hargreaves a écrit :
> Agreed, this is just disruptive. If they must stay, at least make it
> possible to turn them off without resorting to local browser policies.

I suggest that right-clicking on them could make the explode
(left-clicking is already used to go to the thanks website). :-)

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: why are there /bin and /usr/bin...

[Giacomo A. Catenazzi]

On 16.08.2010 01:22, Perry E. Metzger wrote:

On Sun, 15 Aug 2010 16:00:23 -0700 Steve Langasek
wrote:

On Sun, Aug 15, 2010 at 06:30:04PM -0400, Perry E. Metzger wrote:

By the early 1990s this was long since unneeded but people
continued to do it anyway, and in fact started to think it was
done for technical reasons rather than because of a simple lack
of space in an earlier era. At this point (2010), with all of the
system files fitting in under a dollar's worth of disk space,
people tell themselves quite elaborate "just so" stories about
why the segregation is maintained.


You wrongly assume here that every Unix system has a hard drive as
its root filesystem.  Some root devices cost a lot more than a
dollar for that amount of disk.


Ah, onions.


I consider it offensive, so please consider that some people
know what they are using.

As you can easily check, there is a lot of Debian installation
who use networked disks. Usually not embedded devices, but usual
desktop installations (e.g. using huge number of desktops as in
schools or corporate environments).
In this case the separation of /usr and / is still important.

And Debian still don't have a live distribution to be used for
rescue, so a minimal / is essential, also for emergency
backup uses. [BTW I don't think that we could have a CD-ROM
or USB live/emergency disk on all architectures].

If you don't use it, or if there are alternatives (but
it is still to prove that such alternatives are easier) don't
mean that who use it, used it as your onions. Probably with
time it will become useless, but your "early 1990" should be
read "late 2010 (or later)".

IMHO you should write things more neutral, and maybe reading
the old discussion, with real case usages, before to
imply idiocy to people arguing for the need of /usr as
separate partition. (and IMHO it is not a big issue
or things that make complexer the filesystem).


PS: With the exception for this threading (with an "automatic
tools" to find misplaced programs/libraries), usually the
bugs are reported because real use cases (real usefull onions).

ciao
cate


PS:
There are some other strange things in our file system
partition: the split of architecture independent to architecture
depend things. In such cases I don't think there are
many uses, and the spare disk usage is also not so relevant
[although we consider that we have a lot of architectures].
But maybe there are use cases.


--
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/4c693258.9010...@debian.org

Re: why are there /bin and /usr/bin...

[Yves-Alexis Perez]

On 16/08/2010 14:00, Tollef Fog Heen wrote:
> ]] "Perry E. Metzger" 
> 
> | In the embedded space, which I know a lot about, it is true that the
> | root FS is on flash or other expensive media -- but it isn't like /usr
> | is on cheaper media in such an environment, it is always part of the
> | root fs anyway, so it makes no difference.
> 
> Take a look at the N900 where most of the user-installed applications
> are on /home (well, /opt, but that's a symlink to /opt/home), which is a
> 32GB eMMC flash, while the root file system is a 256MB NAND flash, which
> is vastly more expensive.  So while the situation you are describing
> might be common, it's not always true.

To be honest, I'm not sure the N900 /opt debacle is really to be taken
as an example. (and / and /usr are basically on the same media, when it
comes to boot)

Cheers,
-- 
Yves-Alexis


-- 
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/4c69337c.7010...@debian.org

Re: why are there /bin and /usr/bin...

[Bruce Sass]

On August 15, 2010 04:30:04 pm Perry E. Metzger wrote:
> On Tue, 10 Aug 2010 03:15:35 -0600 Bruce Sass  wrote:
> > /sbin and /usr/sbin, /lib and /usr/lib directories?
> >
> > AFAICT, the reason is so that a minimal but functional system is
> > guaranteed to exist so long as a local HDD with a root filesystem
> > is available (which doesn't necessarily include /usr);
>
> The true reason is that back in ancient days, hard drives were too
> small to put everything in one place, so ancient Unix machines at
> Bell Labs in the 1970s ended up with some programs on the root disk
> and some on the same supplementary disk where the home directories
> were typically put. This was not done with any great forethought, it
> was simply a temporary expediency. Because / was on the boot disk, it
> was necessary to make sure that every program needed for initial boot
> was there, and thus some programs were more important to put in /bin
> and the like. ...

Thanks. I like the "onion" story, I don't think it is entirely fitting 
though--to gain the benefit of that dollar or so worth of HDD space I'd 
need to effectively re-tool to get it installed... if it was necessary 
to replace the vat (shutdown production, remove a wall or two, rewire 
the controls, etc.) to get rid of the onion I suspect they'd still be 
used in some older varnish plants.

What I'd really like to see is support for a shared /usr hierarchy and a 
way to optionally push configs onto separate boxes. Such a setup would 
be useful in a classroom or office where it is desirable for everyone 
to have the same software installed and there are enough boxes that 
maintaining them as independent units can be expensive.


- Bruce


-- 
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/201008160654.05513.bms...@shaw.ca

Re: why are there /bin and /usr/bin...

[Josselin Mouette]

Le lundi 16 août 2010 à 14:43 +0200, Giacomo A. Catenazzi a écrit :
> As you can easily check, there is a lot of Debian installation
> who use networked disks. Usually not embedded devices, but usual
> desktop installations (e.g. using huge number of desktops as in
> schools or corporate environments).
> In this case the separation of /usr and / is still important.

Putting /usr on a network device but not / is just plain stupid. Debian
can now work with a read-only / on NFS.

> And Debian still don't have a live distribution to be used for
> rescue, so a minimal / is essential, also for emergency
> backup uses.

This is completely irrelevant. When / is not accessible, you get the
same problem. (Oh, and d-i CDs include the necessary tools to rescue a
system.)

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
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/1281963889.5689.14.ca...@meh

Re: OMG WTF BBQ balloons

[Ian Jackson]

Dominic Hargreaves writes ("Re: OMG WTF BBQ balloons"):
> On Mon, Aug 16, 2010 at 12:00:09PM +0100, Ian Jackson wrote:
> > I just had to tell NoScript "forbid debian.org" because I wanted to
> > read a bug report.
> > 
> > I don't want to be a spoilsport but, honestly!
> 
> Agreed, this is just disruptive. If they must stay, at least make it
> possible to turn them off without resorting to local browser policies.

NB that the obvious implementation of this, a "no balloons" cookie,
doesn't work for people (like me) who don't accept cookies unless we
want to identify ourselves to the site in question.

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

Re: OMG WTF BBQ balloons

[Matthew Johnson]

On Mon Aug 16 12:00, Ian Jackson wrote:
> I just had to tell NoScript "forbid debian.org" because I wanted to
> read a bug report.
> 
> I don't want to be a spoilsport but, honestly!

You should read bugs.d.o in IE, they don't show up there

Matt


signature.asc
Description: Digital signature

Re: OMG WTF BBQ balloons

[Jordan Metzmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/16/2010 09:46 AM, Matthew Johnson wrote:
> 
> You should read bugs.d.o in IE, they don't show up there
> 
> Matt

Is that packaged for Debian?

- -- 
Jordan Metzmeier

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJMaU2BAAoJEKj/C3qNthmTI6IQAJT7QT/B0wJqnPoMtlqDJjm8
w2VBhqL6uEABjIPp4DIfWMWka3YHj8nwzzqmRGLBTk9/Up3nDNP/Ssml1zq+5ege
v1ZY4v2vKbn9dFjOIPHdZ/8ZbGA4cdhbk3NyKMzYCPQLGB0ledLUUNPiNpwThmIX
OTtqawVIeAL/2BmMPs9PhkFEaP7bKQOm0kwtNezWFSeMTg0nv/Kj8GodbqRay0Cu
JTPcFnfsZMItdKbuhzW8RG0I/X+j45UURi/tXMBw0zcJlTG3NNX41zyfUeN6ec7r
ED+ImjaHuZghJmy42S44Lkrc2ZNpYhP9+3T2PtfEhbvlJP5xYxp1ACfrkRE/yfYX
llhSsI8XLLhw0AI6ZnCdgJdv5IdN/n+24ZctRs2egtG48zGR4YNlK/GEdShu9lrn
QkG493wStNU3x+c++BZ09m8WhThAuGsKbYhpggpMEqLLw1suGitL4T/1Q9MLyzHi
RoyeNOzWgFm6ac//Z6UGloqNloQO556JbTxRqDA85rst0VHh1yGPlNEq9U+4VpFn
LDwj2qXhCoFoOvf9O9fVBqcoOFOmFe4t99695/tWQYvAgAI0F8PKyjucvzj/TGPv
NPWLissMqXLIY0mnDEC74iK9CPCOIaTRU4M75Bws+t+BSlRInVSXIrgnRH0Y5ofU
wfC6e3h6A7VbdoFvlaMb
=d4p9
-END PGP SIGNATURE-


-- 
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/4c694d81.3010...@gmail.com

Re: Notes from the DebConf Source Format BoF

[Guido Günther]

Hi Roger,
On Sun, Aug 15, 2010 at 10:28:52PM +0100, Roger Leigh wrote:
> On Tue, Aug 10, 2010 at 08:27:24PM -0700, Russ Allbery wrote:
[..snip..] 
> > Best practices for Git repository layout?
> > - git-buildpackage documentation is closest to that
> 
> I would have to disagree here, the git-buildpackage default layout is
> far too "Debian-centric".  By naming the Debian and Upstream branches
> "master" and "upstream" it's only really useful if you're importing
> upstream release tarballs.  We should really be using a "debian" branch
> for Debian-specific changes, and possibly even using multiple branches
> for tracking oldstable/stable/unstable/experimental work.

When tracking upstreams VCS I usually put upstream's branches into their
own "namespace" like:

upstream/master
upstream/2.30
upstream/2.28

I then use master for sid and create branches for the other
distributions like

master(current sid develoment)
lenny (lenny stable updates)
bpo-lenny (lenny-backports)xi
experimental  (experimental)

etc. We could also move all the debian work into it's own namespace
like:

debian/sid
debian/lenny
debian/bpo-lenny
debian/experimental

but I think that's rather overkill and more typing. When cloning from
git.debian.org I'd like to have the current development on master,
because that's what one expects to happen in a git repository of a
Debian package.
Cheers,
 -- Guido

> 
> If upstream is already using git, you might want to skip the tarball
> step and use their git branches directly (and they might have their
> own master branch).  Also potentially annoying for our downstreams as
> well.
> 
> > git push as an upload mechanism
> > - Attractive because over time it builds a Git repository for the package
> > - However, it assumes binaryless uploads, which we currently don't allow.
> 
> This is something to think about for the future though; dropping
> binary uploads (by maintainers, not buildds) has been on the cards
> for some time now hasn't it?  Is this still planned?
> 
> > If you're implementing 3.0 format, please don't hard-code the extensions 
> > that
> > you "know" will be found in source packages, because as we add additional
> > files listed in *.dsc, we may add other types of files.
> 
> We already found this out the hard way in sbuild; hopefully it's now
> completely clean--we removed all assumptions about the expected
> extensions.
> 
> > What about repository size bloat if revision control history is included?
> 
> In practice, a shallow clone is typically only half the size of a
> complete clone, so it's not going to eat too much extra archive space.
> For schroot:
> 
> % du -sk schroot-shallow schroot schroot-full
> 4372  schroot-shallow
> 7556  schroot [cloned --depth 1 and then fetched all history]
> 6008  schroot-full
> % du -sk schroot-shallow/.git schroot/.git schroot-full/.git
> 1720  schroot-shallow/.git
> 4904  schroot/.git [cloned --depth 1 and then fetched all history]
> 3356  schroot-full/.git
> After repack and gc:
> %  du -sk schroot-shallow/.git schroot/.git schroot-full/.git 
> 1520  schroot-shallow/.git
> 2920  schroot/.git
> 2916  schroot-full/.git
> Packaged .git (after repack and gc):
>  ls -l schroot*.bz2 
> -rw-r--r-- 1 rleigh rleigh 2765372 Aug 15 21:50 schroot-full.tar.bz2
> -rw-r--r-- 1 rleigh rleigh 1403301 Aug 15 21:50 schroot-shallow.tar.bz2
> -rw-r--r-- 1 rleigh rleigh 2764894 Aug 15 21:50 schroot.tar.bz2
> 
> So a five year history in this case is slightly less than double the
> packed size--not a bad tradeoff for the entire project history (IMO).
> Obviously for exceptional cases such as the Linux kernel this might
> not be quite so optimal.  Not sure why there's a size difference if
> you shallow clone then fetch all, rather than cloning the entire
> thing--any history differences or just packed slightly differently?
> 
> > Currently in 3.0 (git), origin points to the bundle and doesn't embed the
> > actual repository, but Joey is working on fixing that.  (Setting origin
> > based on Vcs-Git.)
> 
> As I mentioned above, would it make sense to set Vcs-Git based on origin
> on packing?  On unpack after debcheckout the opposite may be useful as
> you say above.
> 
> > source.debian.org is working on importing source packages into a Git
> > repository and storing the history as one revision per new source package
> > upload.
> 
> While useful, don't we already have that if you're properly tagging
> all Debian releases in your git repository already?  A central resource
> would be useful in case the original repos go offline, but given the
> space requirements, storing all the history should be possible, in which
> case why not simply track the upstream(s)?
> 
> 
> Lastly, one thing I'd like to push with git usage in Debian is
> better integration with upstreams.  Rather than repeating it
> all here, this is detailed in these mails:
> 
>   
> http://lists.alioth.debian.org/pi

Re: why are there /bin and /usr/bin...

[The Fungi]

On Mon, Aug 16, 2010 at 02:43:04PM +0200, Giacomo A. Catenazzi wrote:
[...]
> And Debian still don't have a live distribution to be used for
> rescue,

Well, there's this, which I've had great experiences with so far
(though the automatic reassembly of md devices and activation of
volume groups was recently mentioned as dangerous in some cases):

http://cdimage.debian.org/cdimage/release/current-live/i386/iso-cd/debian-live-505-i386-rescue.iso

> so a minimal / is essential, also for emergency backup uses. [BTW
> I don't think that we could have a CD-ROM or USB live/emergency
> disk on all architectures].
[...]

Certainly not all architectures, I would agree (and the
above-mentioned ISO was only provided for i386 and amd64 with etch).
-- 
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.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/20100816155739.gd2...@yuggoth.org

Re: why are there /bin and /usr/bin...

[Steve Langasek]

On Mon, Aug 16, 2010 at 02:47:56PM +0200, Yves-Alexis Perez wrote:
> On 16/08/2010 14:00, Tollef Fog Heen wrote:
> > ]] "Perry E. Metzger" 

> > | In the embedded space, which I know a lot about, it is true that the
> > | root FS is on flash or other expensive media -- but it isn't like /usr
> > | is on cheaper media in such an environment, it is always part of the
> > | root fs anyway, so it makes no difference.

> > Take a look at the N900 where most of the user-installed applications
> > are on /home (well, /opt, but that's a symlink to /opt/home), which is a
> > 32GB eMMC flash, while the root file system is a 256MB NAND flash, which
> > is vastly more expensive.  So while the situation you are describing
> > might be common, it's not always true.

> To be honest, I'm not sure the N900 /opt debacle is really to be taken
> as an example. (and / and /usr are basically on the same media, when it
> comes to boot)

Yes, but *if* they had been following the FHS, putting /usr on the separate
disk would be the way to do it :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Is Jonas Genannt MIA?

[Damyan Ivanov]

On Tue, Aug 10, 2010 at 10:06:38AM -0430, Ernesto Hernández-Novich wrote:
> I am particularly interested in liblog-dispatch-perl [1] because it's
> blocking other things I need to fix in webgui. Regardless, his QA page
> shows little activity. Has anyone seen any sign of him?
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576912

No good news from me, sorry, just a "me too".

I need another of Jonas's packages upgraded - libfile-homedir-perl
(#587756). It is currently blocking a new version of padre I am working
on.

Adding Daniel Baumann, the sponsor of the above two packages, to CC in case he
can shed some light.


-- 
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/20100816172215.ga26...@master.debian.org

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes:

>> I don't believe this is correct.  Source packages in main can build
>> binaries in contrib, and I believe the problem with not being able to
>> rebuild with free tools is more of a contrib thing than a non-free
>> thing.

> Well, some maintainers have been rebuilding source packages to remove
> things like RFCs and non-free-GFDL documentation.  Perhaps not
> everyone has.

RFCs are definitely non-free because they're unmodifiable.  They can't
even be in contrib.  What I'm not sure about is software that's freely
modifiable but just requires non-free tools to build after modification.
I know that's okay for contrib, and I know it's not okay for main in
packages, but I wasn't sure if it was okay for main source packages if
it's not installed in a main package.

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

Reference.net is for Sale

[Toby Clements]

To whom it may concern:

We wanted to bring to your attention that Reference.net is available for
sale.

Please contact me with any questions you have regarding this sale.


Best Regards,

Toby Clements

Partner

+1.615.944.3501

RickLatona.com | RickLatonaAuctions.com | DigiPawn.com | DigiLoan.com |
ccTLDs.com


-- 
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/35689.116.50.236.226.1281981145.squir...@www.mynatmail.com

Re: why are there /bin and /usr/bin...

[Perry E. Metzger]

I want to make it clear, btw, that I don't think that getting rid of
/usr is something worth fighting for. I just think that there is no
reason to keep it other than the fact that years of experience say
people will irrationally fight for it endlessly, and the minimal
benefits of getting rid of it aren't worth that fight.

On Mon, 16 Aug 2010 14:43:04 +0200 "Giacomo A. Catenazzi"
 wrote:
> As you can easily check, there is a lot of Debian installation
> who use networked disks.

> In this case the separation of /usr and / is still important.

I managed such systems for years. There is no reason to separate / and
/usr on an NFS based system either.

The fact that you're running diskless makes pretty much no difference
that I can see whether awk is located in /bin or /usr/bin

When I managed diskless machines in the 1980s, it was still vaguely
useful to keep / and /usr distinct. People thought that you needed
each machine to mount its own /etc and /var in order to have local
manageability, while mounting a common /usr to save server disk
space. As it happens, and as we didn't understand back then, you can
easily handle this with a couple of symlinks without needing a
distinct root partition, but we can be excused for being somewhat
blinded by lack of experience. We'd only had real LANs for a few
years.

> And Debian still don't have a live distribution to be used for
> rescue, so a minimal / is essential,

I agree, having a minimal rescue disk is a fine thing to want, but
what does this have to do with / vs /usr segregation?

If all your binaries on your rescue media are in /bin etc., simply
don't put more in /bin than you have space for. If you want sed but
don't want perl, then put sed in your /bin rescue disk and don't put
perl there.

It makes no difference what the directories are called in order to
keep the space usage down -- you keep space down by not including
things, not by giving them different names.

The arguments for keeping a /usr are all, in the end, "Onion" over and
over again.

> If you don't use it, or if there are alternatives (but
> it is still to prove that such alternatives are easier) don't
> mean that who use it, used it as your onions. Probably with
> time it will become useless, but your "early 1990" should be
> read "late 2010 (or later)".

It really was insanely obsolete 20 years ago. People are just attached
to the whole /usr thing, the way they used to be insanely attached to
keeping binaries in /etc before we created /sbin and the way they used
to really, really want to put sendmail into /usr/lib

The arguments for / and /usr being distinct are all really about /sbin
and /bin vs /usr/sbin and /usr/bin and all come down to this:

1) "I don't have enough space for everything in root because I'm using
some sort of expensive media!" -- well, then, it doesn't matter what
pathname the binaries are in, if you only have so many bytes, you
won't get more by putting some binaries in /usr on your flash drive
and some in /. Your embedded system isn't going to have more space
because you put awk into /usr/bin instead of in /bin

2) "I am running machines with file systems on the network!" -- so,
why does putting some files in /usr and some in / improve this? See
above for more on this one.

3) "I'm on an old architecture! I have little disk space!" -- well,
how does keeping some files in one partition and some in the other fix
this? Unless your root disk is unable to store your binaries (and no
disk made in the last couple of decades is that small) there is no
real issue. I can see this being a problem for someone who is keeping
an authentic PDP-11 or Vax alive with entirely original equipment, of
course.

4) "I'm using an SSD boot drive!" -- well, I've never seen one of
those that isn't larger than pretty much all the app binaries anyone
ever runs.

The most reasonable argument against altering such things is that
after decades, people are used to the whole /usr thing and the fight
to change it isn't worthwhile. That I will agree with -- see the
emotional reactions people get when you suggest their preferred layout
is an "onion". Fixing things so that /usr goes away would not bring
much improvement (other than some reduction in mental baggage,
eliminating wasted time deciding where things go, etc.) even though
/usr is long since obsolete, while dealing with people's emotional
reaction to the "necessity" of /usr wastes lots of time and causes ill
feeling.

Still, /usr has been obsolete for decades, and if I were starting over
again today, with a brand new flavor of Unix, I'd dump /usr entirely,
leaving perhaps a compat symlink the way we left compat symlinks
around for things like /usr/spool and other "ghosts" in the old days.

Perry
-- 
Perry E. Metzgerpe...@piermont.com


-- 
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/20100816142116.41610...@

Re: OMG WTF BBQ balloons

[Don Armstrong]

On Mon, 16 Aug 2010, Ian Jackson wrote:
> I just had to tell NoScript "forbid debian.org" because I wanted to
> read a bug report.
> 
> I don't want to be a spoilsport but, honestly!

Heh. I tweaked the js to be slightly less annoying; it's only for a 24
hour period. [There's aleady an at job in place to remove it, so I
don't have to do anything.]


Don Armstrong

-- 
Everyone has to die. And in a hundred years nobody's going to inquire
just how most people died. The best thing is to do it in the way that
strikes your fancy most.
 -- Kenzaburō Ōe _Silent Cry_ p5

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20100816182450.gu17...@teltox.donarmstrong.com

Re: status of /etc/environment?

[Christoph Anton Mitterer]

Well does this perhaps deserve it's own manpage? At least if it's
not deprecated?
I barely found any real documentation about it (how it's intended to be
used and so).

It seems to be 


Some init-scripts on my system merely use it as a location for the local
settings, e.g. console-screen.sh, keymap.sh and pcscd, overriden
by /etc/defaults/locale:
[ -r /etc/environment ] && ENV_FILE="/etc/environment"
[ -r /etc/default/locale ] && ENV_FILE="/etc/default/locale"
#then sourcing it somehow

One of Debian's derivates has some nice specification:
https://help.ubuntu.com/community/EnvironmentVariables#System-wide%
20environment%20variables

Cheers,
Chris.


-- 
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/1281984888.12367.37.ca...@fermat.scientia.net

Bug#593260: ITP: bar -- Show information about a data transfer

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: bar
  Version : 1.10.9
  Upstream Author : Michael Peek 
* URL : http://clpbar.sourceforge.net/
* License : GPL-2
  Programming Lang: C
  Description : Show information about a data transfer

 Bar is a simple tool to process a stream of data and print a display  for
 the  user  on stderr showing (a) the amount of data passed, (b) the
 throughput of the data  transfer,  and, if the total size of the data stream
 is known, (c) estimated time remaining, percent complete, and a progress bar.
 .
 Bar was originally written for the purpose of estimating the amount  of time
 needed to transfer large amounts (many, many gigabytes) of data across a
 network.  (Usually in an SSH/tar pipe.)



-- 
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/20100816183621.30628.75249.report...@www.khaznadar.fr

Re: why are there /bin and /usr/bin...

[Bernhard R. Link]

* Perry E. Metzger  [100816 20:21]:
> The most reasonable argument against altering such things is that
> after decades, people are used to the whole /usr thing and the fight
> to change it isn't worthwhile. That I will agree with -- see the
> emotional reactions people get when you suggest their preferred layout
> is an "onion".

Accusion people of irrational behaviour almost always results in
irrational behviour. Either they were irrational already before or
making false insulting accusations. So I should better not tell you
that accusing people of irrational behaviour is quite irrational...

Also do not confuse two things. It is one thing to fight for being
able to do without /usr. That would need some work (I think HURD
tried it, but I lost track about it) but is a worthy goal though
perhaps not worth the work for so little benefits.
It is something else to suggest no longer supporting a /usr on
its own partition. This will break people's setups and just telling
them their setups are stupid or make no sense as they make no sense
with your weighting of factors will not make their reactions look
rational from your point of view.

Bernhard R. Link


-- 
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/20100816190142.ga10...@pcpool00.mathematik.uni-freiburg.de

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Joerg Jaspert]

> Aren't the licenses of source files generally documented by upstream,
> either by e.g. the COPYING file or inline within the files themselves?
> Why is there a requirement to duplicate this information in the
> copyright file?

Thats certainly a nice dream, but in most cases not reality (having
upstream document it sanely).
In many cases upstream doesnt even know what they all have.

-- 
bye, Joerg
[...] some would argue that too much free beer with hamper your ability to free
speech; this is an opinion.


-- 
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/87aaom1iug@gkar.ganneff.de

Re: Bug#593260: ITP: bar -- Show information about a data transfer

[Don Armstrong]

On Mon, 16 Aug 2010, Georges Khaznadar wrote:
>  Bar is a simple tool to process a stream of data and print a display  for
>  the  user  on stderr showing (a) the amount of data passed, (b) the
>  throughput of the data  transfer,  and, if the total size of the data stream
>  is known, (c) estimated time remaining, percent complete, and a progress bar.

How does this differ from pv?


Don Armstrong

-- 
Some pirates achieved immortality by great deeds of cruelty or
derring-do. Some achieved immortality by amassing great wealth. But
the captain had long ago decided that he would, on the whole, prefer
to achieve immortality by not dying.
 -- Terry Pratchet _The Color of Magic_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20100816191044.gx17...@teltox.donarmstrong.com

Re: Bug#593260: ITP: bar -- Show information about a data transfer

[Georges Khaznadar]

Don Armstrong a écrit :
> [as a handfull of other vigilant developers]
> How does this [bar] differ from pv?

h...

I used Michael Peek's bar for a few years because I never heard about
pv. Thank you for this notice.

When I read pv's manpage, it appears as more featureful than bar.

I use currently bar to monitor the cloning of USB sticks, as a
replacement of dd to dump 4GB of an image into a flash memory driver.

Is pv able to do the same? for example how can I use pv to monitor the
transfer which is done by modifying a command such as:

dd if=someImageFile of=/dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0

with bar, the replacement would be:
bar -s 4G -if someImageFile -of 
/dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0

Best regards,   Georges.



signature.asc
Description: Digital signature

Re: Bug#593260: ITP: bar -- Show information about a data transfer

[Samuel Thibault]

Georges Khaznadar, le Mon 16 Aug 2010 21:57:28 +0200, a écrit :
> Is pv able to do the same? for example how can I use pv to monitor the
> transfer which is done by modifying a command such as:
> 
> dd if=someImageFile of=/dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0

killall -USR1 dd

Samuel


-- 
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/20100816195934.gk5...@const.famille.thibault.fr

Re: Bug#593260: ITP: bar -- Show information about a data transfer

[Peter Samuelson]

[Georges Khaznadar]
> Is pv able to do the same? for example how can I use pv to monitor the
> transfer which is done by modifying a command such as:
> 
> dd if=someImageFile of=/dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0

pv < someImageFile > /dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0


> with bar, the replacement would be:
> bar -s 4G -if someImageFile -of 
> /dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0

pv has a -s option, but there's no need for it in this case, since
fstat() will give it the size of the file on stdin.  You need -s if the
input is a pipe or socket, where fstat() won't work.

Peter


-- 
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/20100816201516.gj3...@p12n.org

Re: Bug#593260: ITP: bar -- Show information about a data transfer

[Don Armstrong]

On Mon, 16 Aug 2010, Georges Khaznadar wrote:
> Don Armstrong a écrit :
> > [as a handfull of other vigilant developers]
> > How does this [bar] differ from pv?
> 
> I used Michael Peek's bar for a few years because I never heard
> about pv. Thank you for this notice.

No problem.[1]
 
> Is pv able to do the same? for example how can I use pv to monitor the
> transfer which is done by modifying a command such as:
> 
> dd if=someImageFile of=/dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0

pv someImageFile > /dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0

if you wanted to use dd, you'd do something like:

pv someImageFile | dd of=/dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0
 
You could also use dcfldd:

dcfldd if=someImageFile of=/dev/disk/by-id/usb-TheNiceStick_0878101B77D1D977-0:0

or a more complicated example with pv and dd

dd if=/dev/zero bs=1M count=500 | pv -s 500m -N dd | gzip - | pv -cN gzip > 
/dev/null


Don Armstrong

1: I don't have an opinion on whether you should or shouldn't package
bar, so long as if you do, you make it obvious why you'd use it
instead of pv.
-- 
When I was a kid I used to pray every night for a new bicycle. Then I 
realized that the Lord doesn't work that way so I stole one and asked
Him to forgive me.
 -- Emo Philips.

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20100816203048.gz17...@teltox.donarmstrong.com

Re: Debug output etc, cluttering the terminal

[Emilio Pozuelo Monfort]

On 16/08/10 02:01, Russ Allbery wrote:
> gregor herrmann  writes:
> 
>> Among the contents are e.g. ~20.000 lines saying:
>> (firefox-bin:28026): Gdk-WARNING **: XID collision, trouble ahead
> 
> I tracked this down at one point and decided that this was the fault of
> Adobe's Flash player rather than anything the Mozilla folks had any
> control over.  I now just redirect the output of Iceweasel to /dev/null
> where I have to run the Flash player.

That may actually be X's fault, see
http://bugs.freedesktop.org/show_bug.cgi?id=21583

Regards,
Emilio


-- 
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/4c69b107.8090...@debian.org

Re: libexplain: need access to debian alpha machine

[Paul Wise]

On Mon, Aug 16, 2010 at 6:05 PM, Peter Miller  wrote:

> I'm trying to get my libexplain project [1] to build on Debian alpha.
> I don't actually have access to an alpha machine, so my feedback loop is
> via the Debian build farm [2]... one fix per release.
>
> This isn't completely satisfactory.  Can anyone suggest a dev machine I
> can ssh to, and do the edit-build-test loop more efficiently?

There is one alpha porterbox available:

http://db.debian.org/machines.cgi?host=albeniz

It is listed as public rather than developer only so as a non-DD you
would probably be able to get access. Please contact the Debian
sysadmins about it.

-- 
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/aanlktikysbfvzu8llfcwdcygbx_q2d5vtigjq0p5a...@mail.gmail.com

Is Ryan Niebur MIA?

[Yves-Alexis Perez]

Hey,

did anybody have news from Ryan recently? Some time ago we discussed
midori new upstream release (debian has 0.2.4, 0.2.7 just came out), but
I heard no news since few months. I pinged him on irc, by mail and on
the BTS, but nothing. Seems the last activity was like a month ago, and
I don't know about a [VAC].

Do we know if he's ok?

On a side note, I'd very much like to update midori, but doing a NMU for
a new upstream release (he already packaged 0.2.6) is a bit rude, so I'd
really prefer he we had news and if he's coming back soon :)

Cheers,
-- 
Yves-Alexis


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