Re: Bug#719556: ITP: logcat-color -- a colorful alternative to "adb logcat"

[Bastian Blank]

On Mon, Aug 12, 2013 at 11:14:14PM -0400, Luke Faraone wrote:
> This package is designed to be used in conjunction with the Android
> "adb" utility to view logs on an Android device or emulator.

Why does it not mention this in the package name? And is there a reason
not to publish this in the adb package itself if it is that useful?

Bastian

-- 
I've already got a female to worry about.  Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0


-- 
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/20130813064501.gb9...@mail.waldi.eu.org

Re: UTF-8 in jessie

[Christian PERRIER]

Quoting Charles Plessy (ple...@debian.org):

> Hi Christian,
> 
> what I am proposing is a task that install all languages.  I made a bit of
> research earlier, and it is not as simple as installing all the existing 
> tasks,
> as the result on my computer was that some browsers started to display 
> Japanese
> texts with simplified Chinese glyphs.
> 
> http://bugs.debian.org/702050
> 
> Unfortunately, I did not get answer.  Feedback is much welcome.


It's quite likely the result of broken (or wrong) fontconfig files in
some of the installed fonts. For instance, fonts-arphic-u{kai|ming}
currently spit out warnings from their fontconfig files.




signature.asc
Description: Digital signature

Bug#719572: ITP: ruby-unicode -- Unicode string manipulation library for Ruby

[Per Andersson]

Subject: ITP: ruby-unicode -- Unicode string manipulation library for Ruby
X-Debbugs-CC: debian-devel@lists.debian.org
Package: wnpp
Owner: Per Andersson 
Severity: wishlist

* Package name: ruby-unicode
  Version : 0.4.4
  Upstream Author : Yoshida Masato 
* URL : http://www.yoshidam.net/Ruby.html
* License : Ruby or GPL
  Programming Lang: C and Ruby
  Description : unicode string manipulation library for Ruby

 Unicode string manipulation library for Ruby.
 .
 This library is based on UAX #15 Unicode Normalization Forms.
 .
 http://www.unicode.org/unicode/reports/tr15/


-- 
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/CABYrXSSxyHsiyrCOheRvsXAzg+=dY0F=i6yntvrjmlqiqud...@mail.gmail.com

Re: Switching default dpkg-source compressor for V2+ formats to xz

[Guillem Jover]

On Tue, 2013-08-13 at 11:12:16 +0900, Mike Hommey wrote:
> On Tue, Aug 13, 2013 at 03:52:51AM +0200, Guillem Jover wrote:
> > I'd like to switch the default dpkg-source compressor to xz for V2+
> > (not for V1) source formats, as suggested by Ansgar Burchardt in [0].
> > 
> >   [0] 
> > 
> > After having switched the default dpkg-deb compressor to xz in 1.17.0,
> > it only makes sense to update the new source formats too, more so when
> > an increasing number of packages are getting switched manually. And
> > given that there should be less of an issue wrt compatibility with
> > other systems, compared to .deb packages.
> > 
> > So if there's no strong opposition, this would probably happen around
> > dpkg 1.17.3 or thereabouts.
> 
> Is there actually much to win with this, since this is going to only
> affect -debian.tar.*?

There's the native packages too (see dpkg itself for example). Probably
not as much global gain as with binary packages, but the gain is
significant at least for native packages. In any case I think trying
to standardize on a single compressor across the board is a good thing,
and if people are going to be manually switching packages anyway, I'd
rather do it just once centrally.

Thanks,
Guillem


-- 
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/20130813084113.ga7...@gaara.hadrons.org

Re: UTF-8 in jessie

[Bastien ROUCARIES]

On Mon, Aug 12, 2013 at 5:56 PM, Thorsten Glaser  wrote:
> Florian Lohoff  zz.de> writes:
>
>> 5. All programs consuning UTF8 Text must understand a BOM.
>
> The kernel doesn’t, start there:
>
> tglase@tglase:~$ mksh -c 'print '\''\ufeff#!/bin/sh\necho foo'\' >x; chmod +x
> x; ./x
> ./x: line 1: #!/bin/sh: No such file or directory
> foo
>
> That’s running GNU bash, with bash as /bin/sh for testing, which deviates
> from my normal setup of running mksh… because I fixed mksh to support this
> (and the MirBSD kernel, too).

They was the utf8script package
http://packages.qa.debian.org/u/utf8script.html but it was O/RM some
time ago. Time to ressurect ?

>
> I disagree with requiring ASCII for $PATH though…
>
> bye,
> //mirabilos
>
>
> --
> 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/loom.20130812t175549-...@post.gmane.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/CAE2SPAa6jMkh=q2h0c0bbpnfz8k-teuptwok1e32regi9hs...@mail.gmail.com

Re: UTF-8 in jessie

[Thorsten Glaser]

Vincent Lefevre  vinc17.net> writes:

> If scripts intend to use LC_ALL=C.UTF-8 to force everything to
> the standard locale with UTF-8 support, then the glibc should
> be modified to regard C.UTF-8 like C w.r.t. $LANGUAGE. I mean:

Ouch! Scripts do, and this *is* how C.UTF-8 was intended: to
behave like C/POSIX except for the encoding.

> Both should have output in English.

Please reportbug that.

Thanks,
//mirabilos


-- 
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/loom.20130813t122454-...@post.gmane.org

Re: Switching default dpkg-source compressor for V2+ formats to xz

[Adam Borowski]

On Tue, Aug 13, 2013 at 10:41:13AM +0200, Guillem Jover wrote:
> In any case I think trying to standardize on a single compressor across
> the board is a good thing

xz supports null-compressed chunks but currently (AFAIK) doesn't expose any
way to force them.  That'd be an equivalent to uncompressed tarballs.  xz -0
is what you would expect from -1: fast but non-null compression.

If this would be dealt with (or we decide current -0 is fast enough), it
might be a good idea to drop support for producing packages compressed with
anything but xz.  Less complexity to maintain is always good.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130813113858.ga20...@angband.pl

Re: jessie release goal: verbose build logs

[Dmitrijs Ledkovs]

On 17 June 2013 23:58, Dmitrijs Ledkovs  wrote:
> tags 680686 patch
> thanks
>
> On 14 June 2013 12:35, Matthias Klose  wrote:
>>
>>  - Fix debhelper not passing --disable-silent-rules by default.
>>#680686
>>I think cdbs already does this.
>
> Patch attached for autoconf dh build system. cmake dh build system
> seems to be already enabling verbose makefiles.
>

Is there any reason this hasn't been applied yet?
Can I NMU this, as debhelper is marked as LowNMU package.
The patch itself is a trivial one-liner and fixes a Jessie release goal.
The bug report itself was filed a little over one year ago.

Regards,

Dmitrijs.


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

Re: UTF-8 in jessie

[Vincent Lefevre]

On 2013-08-13 10:25:31 +, Thorsten Glaser wrote:
> Vincent Lefevre  vinc17.net> writes:
> 
> > If scripts intend to use LC_ALL=C.UTF-8 to force everything to
> > the standard locale with UTF-8 support, then the glibc should
> > be modified to regard C.UTF-8 like C w.r.t. $LANGUAGE. I mean:
> 
> Ouch! Scripts do, and this *is* how C.UTF-8 was intended: to
> behave like C/POSIX except for the encoding.
> 
> > Both should have output in English.
> 
> Please reportbug that.

OK: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719590

-- 
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: http://lists.debian.org/20130813120507.ga18...@xvii.vinc17.org

Bug#719595: ITP: mussort -- simple tool that sorts a music collection

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: mussort
  Version : 0.3
  Upstream Author : Eskild Hustvedt 
* URL : http://random.zerodogg.org/mussort
* License : GPL
  Programming Lang: Perl
  Description : simple tool that sorts a music collection

Mussort is a useful tool for keeping large music collections in shape. It
recursively searches a directory for MP3, Ogg Vorbis and FLAC files,
processing them one by one. It then reads the information from the file and
puts them into a newly sorted directory tree.


-- 
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/20130813120436.13696.95949.reportbug@eden.localdomain

Re: jessie release goal: verbose build logs

[Joey Hess]

Dmitrijs Ledkovs wrote:
> Is there any reason this hasn't been applied yet?
> Can I NMU this, as debhelper is marked as LowNMU package.

Not for reasons such as allowing patches like this.

Making all builds verbose by default has both advantages and
disadvantages.

The disadvantages include making builds possibly so noisy that when one
runs them during daily work, once ignores all output. Including
important compiler warnings.

(This is the same reason why it's a bad idea to let a codebase
accumulate a lot of compiler warnings!)

I'd be ok with DH_VERBOSE enabling the verbose behavior, and the buildds
could then enable it.

-- 
see shy jo


signature.asc
Description: Digital signature

the local host/domainname - 127.0.0.1 vs. 127.0.1.1; Debian Reference updated.

[Osamu Aoki]

Hi,

On Mon, Aug 05, 2013 at 01:08:28PM -0400, Thomas Hood wrote:
> > /etc/hosts like these per default:
> > 127.0.0.1 localhost
> > 127.0.1.1 . 
> > As also described in the Debian reference[2].
> That's not entirely accurate. Wheezy and Ubuntu Desktop install
> an /etc/hosts like the following, without a domain_name.
>127.0.0.1 localhost
>127.0.1.1 
> The Debian Reference is out of date.

Fixed. :-)

> 127.0.0.1 localhost hostname.domain hostname
> in which case 'localhost' is the canonical name for alias 'hostname'.
> > or, alternatively:
> > 127.0.0.1 hostname.domain hostname localhost
> In that case 'hostname.domain' is the canonical name for alias 'localhost'.
> Before any move is made to conflate the system hostname with
> 'localhost' in this way I'd like to see some proof that this no longer
...

Please ping me if this happens.

Osamu


-- 
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/20130813163820.GA9347@goofy.localdomain

Re: UTF-8 in jessie

[Florian Lohoff]

On Mon, Aug 12, 2013 at 05:58:20PM +0200, Adam Borowski wrote:
> On Mon, Aug 12, 2013 at 03:50:19PM +0200, Florian Lohoff wrote:
> > 5. All programs consuning UTF8 Text must understand a BOM.
> 
> I'm afraid I don't agree here: BOMs are nasty stuff that serve no purpose
> once you standardize on UTF8.  They might help with exchange with a minority
> of Windows programs, at a cost at our side.  Windows hardly does plain text:
> most of that is MSVC/etc sources, but then, the C/C++ standards explicitely
> forbid junk in places other than comments.  Most other languages expect a
> hashbang on Unix, which makes BOMs impossible.

I agree that BOMs are nasty and should not be generated by our standard
tools. 

I have been bitten by BOMs more than once and had a hard time looking
for the fault until looking at the "plain ascii" file with a hex editor.
AFAIK Tools like vim understand and hide the fact that there is a BOM
and rewrite them.

Other tools give "interesting" results stumping on a BOM.

So its inconstistent which makes it hard to find.

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

[Dmitrijs Ledkovs]

On 13 August 2013 14:36, Joey Hess  wrote:
> Dmitrijs Ledkovs wrote:
>> Is there any reason this hasn't been applied yet?
>> Can I NMU this, as debhelper is marked as LowNMU package.
>
> Not for reasons such as allowing patches like this.
>

Ok.

> Making all builds verbose by default has both advantages and
> disadvantages.
>

I agree, there should be a way to toggle this.

> The disadvantages include making builds possibly so noisy that when one
> runs them during daily work, once ignores all output. Including
> important compiler warnings.
>

We have build log analyzers running for the build logs. And the
important compiler warnings (errors) fail the build.
If we make this opt-in, we will fail to achieve this goal. As when one
is debugging a failed build (e.g. the failure in the last hour of
webkit/qt/libreoffice compile on armhf porter box, or by hand
./debian/rules build) that's when one would start caring & wishing to
have the verbose output would have been set, but it would be too late.

The way I interpret this goal is to have the build logs verbose by
default and/or opt-out.

Making this opt-in, will need many machines modified - potentially all
the builders / CI integration. It's not just about Debian buildd
network, but anyone who rebuilds debian packages or derives from
Debian. Including all the ways people integrate and build debian
packages.

> (This is the same reason why it's a bad idea to let a codebase
> accumulate a lot of compiler warnings!)
>
> I'd be ok with DH_VERBOSE enabling the verbose behavior, and the buildds
> could then enable it.
>

I'm against re-using DH_VERBOSE variable:

* DH_VERBOSE has explicit meaning to control output of dh_* commands.
DH_VEBOSE=1 should print how/what dh_auto_* commands invokes. It
should not change the commands it invokes.

* this debian goal is not debhelper/cdbs/etc specific, but
helper/build-system agnostic.

How about a new DEB_BUILD_OPTION="silent" which opts into silent build
log? Does that sound reasonable.

For a policy change, I am hoping to mandatory require verbose build by
default, and optionally supporting DEB_BUILD_OPTION="silent".

Regards,

Dmitrijs.


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

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

[Julien Cristau]

[why oh why are you breaking threading?]

On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote:

> We have build log analyzers running for the build logs. And the
> important compiler warnings (errors) fail the build.
> If we make this opt-in, we will fail to achieve this goal. As when one
> is debugging a failed build (e.g. the failure in the last hour of
> webkit/qt/libreoffice compile on armhf porter box, or by hand
> ./debian/rules build) that's when one would start caring & wishing to
> have the verbose output would have been set, but it would be too late.
> 
I don't see how.  Either dpkg-buildpackage -nc or re-running
debian/rules build with the option set would give you what you want.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

[Dmitrijs Ledkovs]

On 13 August 2013 19:59, Julien Cristau  wrote:
> [why oh why are you breaking threading?]
>
> On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote:
>
>> We have build log analyzers running for the build logs. And the
>> important compiler warnings (errors) fail the build.
>> If we make this opt-in, we will fail to achieve this goal. As when one
>> is debugging a failed build (e.g. the failure in the last hour of
>> webkit/qt/libreoffice compile on armhf porter box, or by hand
>> ./debian/rules build) that's when one would start caring & wishing to
>> have the verbose output would have been set, but it would be too late.
>>
> I don't see how.  Either dpkg-buildpackage -nc or re-running
> debian/rules build with the option set would give you what you want.

For well behaved build-systems that would only show flags for the yet
to compile object, where the bug might be in the flags/libs used for
the already compiled objects. (i don't have an example here, something
like mixing with/without -fPIC but we get warnings which objects are
at fault anyway)

For less behaved build-systems this may cause a reconfigure and
restart the whole build. Which is suboptimal.

In the past there have been random bugs / build failures which are not
reproducible on re-runs (but I've yet to see one which depended on
build-flags, unless one gets different flags =/ on reruns which
wouldn't know about)

In controlled environments, one doesn't get to re-run a build, as the
instances are stripped-down and destroyed on build failure E.g. all
the jenkins instances running debian package builds, PPAs,
auto-package-tests, automated cross-builders. One would have to modify
each and every deployment of those...

Somehow we lived fine with verbose build-logs, until automake silent
rules and a few other build-systems started to become more silent. I
can understand the appeal of silent builds for upstream developers,
but it makes zero sense for a distribution or package maintainers or
our downstream.

Regards,

Dmitrijs.


-- 
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/CANBHLUi1+Q8PVTJF2TvhGKBLQh-y=elhrzpuv-7ntjlypch...@mail.gmail.com

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

[Adam Borowski]

On Tue, Aug 13, 2013 at 08:30:16PM +0200, Dmitrijs Ledkovs wrote:
> In controlled environments, one doesn't get to re-run a build, as the
> instances are stripped-down and destroyed on build failure E.g. all
> the jenkins instances running debian package builds, PPAs,
> auto-package-tests, automated cross-builders. One would have to modify
> each and every deployment of those...
> 
> Somehow we lived fine with verbose build-logs, until automake silent
> rules and a few other build-systems started to become more silent. I
> can understand the appeal of silent builds for upstream developers,
> but it makes zero sense for a distribution or package maintainers or
> our downstream.

Non-spammy builds are better for builds done by a human.
Spammy builds work around the inability to restart on a failure in automated
builds.

Trying to spot an irregularity can be really hard visually if you have half
a page of switches per every file.  With a terse build like:
  CC foo
  CC bar
  CC baz
  CC quux
  LD blah
any messages stand out.  And if a failure does happen, it's a matter of,
typically, make V=y.

Too bad you don't have this option on a buildd.

So I guess it would be best to put the threshold at automated vs
human-supervised builds.  What about setting the flag per-tool rather than
per-deployment?  For example, pbuilder would default to verbose (as you
can't restart builds) while dpkg-buildpackage in the absence of inherited
settings would default to terse.

This way we'd be spared the spam during development.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130813191008.ga...@angband.pl

Bug#719637: ITP: python-virtualenv-clone -- A script for cloning a non-relocatable virtualenv

[Jan Dittberner]

Package: wnpp
Severity: wishlist
Owner: Jan Dittberner 

* Package name: python-virtualenv-clone
  Version : 0.2.4
  Upstream Author : Edward George 
* URL : https://pypi.python.org/pypi/virtualenv-clone
* License : MIT
  Programming Lang: Python
  Description : A script for cloning a non-relocatable virtualenv

Virtualenv provides a way to make virtualenv's relocatable which could then
be copied as we wanted. However making a virtualenv relocatable this way
breaks the no-site-packages isolation of the virtualenv as well as other
aspects that come with relative paths and '/usr/bin/env' shebangs that may
be undesirable.

Also, the .pth and .egg-link rewriting doesn't seem to work as intended.
This attempts to overcome these issues and provide a way to easily clone an
existing virtualenv.

I intend to package it because it is a dependency of current
virtualenvwrapper versions.


Regards
Jan

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


signature.asc
Description: Digital signature

Re: jessie release goal: verbose build logs

[Joey Hess]

Joey Hess wrote:
> Making all builds verbose by default has both advantages and
> disadvantages.
> 
> The disadvantages include making builds possibly so noisy that when one
> runs them during daily work, once ignores all output. Including
> important compiler warnings.
> 
> (This is the same reason why it's a bad idea to let a codebase
> accumulate a lot of compiler warnings!)

At DebConf, Enrico came up with this idea: When the package is building
with the display going to the console, something could intercept the
stdout and convert \n to \r. Let stderr through untouched. The result
would be a build that makes it *very* easy to focus on the warnings, while
still providing a progress display of what is going on at any given
moment in the build.

I've attached a simple proof of concept you can try it out with building
your own packages.  For example:

   dpkg-buildpackage | ssh

(The implementation needs to be improved; it should read both stdout and
stderr and multiplex them properly. And it should check if stdout is not
to a TTY, and if so avoid munging the build log output. The only other
problem is that `make` outputs the lines it runs to stderr and so those
continue to pollute the build display.)

I'd like to see dpkg-buildpackage modified to use something like this by
default, because it would reduce the level of cruft we wade through
(often up to our eyeballs) when building packages, and allow
concentrating on what's important. At the same time, it allows adding as
verbose output as we like and getting that saved in the build logs for
when a detailed analysis is needed.

-- 
see shy jo
#!/usr/bin/perl
$|=1;
my $width=$ENV{COLUMNS} || 80;
while (<>) {
chomp;
print substr($_, 0, $width - 1).(" " x ($width - 1 - length $_))."\r";
}


signature.asc
Description: Digital signature

Bug#719645: ITP: fedmsg-meta-debian -- Debian-specific processors for the FedMsg bus

[Simon Chopin]

Package: wnpp
Severity: wishlist
Owner: Simon Chopin 

* Package name: fedmsg-meta-debian
  Version : 0.1
  Upstream Author : Simon Chopin
* URL : 
http://anonscm.debian.org/gitweb/?p=users/laarmen-guest/fedmsg-meta-debian.git;a=summary
* License : Expat
  Programming Lang: Python
  Description : Debian-specific processors for the FedMsg bus

FedMsg is a message passing system developed by Fedora for their
infrastructure. This package allows the various clients to process the
messages emitted on the Debian bus easily by providing customized
translators from msg to URL, human-readable summary, etc.


-- 
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/20130813203040.8995.44372.reportbug@beldin.wizards.local

Re: jessie release goal: verbose build logs

[Joey Hess]

Joey Hess wrote:
> (The implementation needs to be improved; it should read both stdout and
> stderr and multiplex them properly. And it should check if stdout is not
> to a TTY, and if so avoid munging the build log output. The only other
> problem is that `make` outputs the lines it runs to stderr and so those
> continue to pollute the build display.)

Also it could save the whole log to someplace when minimizing the
console output, to refer back to. Perhaps ../$package_$version.buildlog
(which gets a step closer to including that in the dsc and uploading
local build logs..)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: jessie release goal: verbose build logs

[Russ Allbery]

Joey Hess  writes:
> Joey Hess wrote:

>> (The implementation needs to be improved; it should read both stdout
>> and stderr and multiplex them properly. And it should check if stdout
>> is not to a TTY, and if so avoid munging the build log output. The only
>> other problem is that `make` outputs the lines it runs to stderr and so
>> those continue to pollute the build display.)

> Also it could save the whole log to someplace when minimizing the
> console output, to refer back to. Perhaps ../$package_$version.buildlog
> (which gets a step closer to including that in the dsc and uploading
> local build logs..)

debuild, pbuilder, and related packages currently use
../__.build for this output.  Maybe the
lower-level build architecture should take over maintaining that log file
instead and those tools should be modified to assume that's already
happening and move that log file around like the other build products?

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

OEDb.org's General Science OpenCourseWare Page

[Xavier Gray]

Hi there,

My name is Xavier Gray, I am a researcher of Open Education Database 
(OEDb.org). Over the years, we've built a comprehensive OpenCourseWare (OCW) 
portal featuring courses from leading universities in an array of topics.

I came across your site,lists.debian.org/debian-user/2002/07/msg02871.html and 
I wanted to share our specially curated General Sciences OCW page that I 
thought may be of interest to you and I believe that these types of information 
is very valuable to the readers of your site.

Feel free to view it here: http://oedb.org/open/subjects/science/

I'd be honored if you would add the link on your website as a useful and 
credible source of free online courses for your visitors to refer to. I would 
love to hear your feedback and answer any questions you may have.

Thank you and please let me know if you decide to post a link!

Kind Regards,
Xavier

Re: UTF-8 in jessie (debhelper and BOM)

[Adam Borowski]

On Tue, Aug 13, 2013 at 01:44:03PM +0900, Osamu Aoki wrote:
> But I do not understand goal #5.  Why "MUST"?  Do you have rationale?
> 
> On Mon, Aug 12, 2013 at 03:50:19PM +0200, Florian Lohoff wrote:
> > On Mon, Aug 12, 2013 at 02:51:52AM +0200, Adam Borowski wrote:
> > > I propose the following sub-goals:
> ...
> > > 4. all text files should be encoded in UTF-8
> 
> Yes.  But it will be nice to have some support by dh_installdocs :-)
>   ^^
> 
> > 5. All programs consuming UTF8 Text must understand a BOM.
>   
> 
> I agree as "SHOULD" but should we state "MUST"? 

Please note the number of '>' markers.

It is not part of my proposal, and the discussion in this thread, me
included, seems to be pretty hostile to adding BOMs.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130813224409.gc3...@angband.pl

Bug#719654: ITP: mpv -- video player based on MPlayer/mplayer2

[Alessandro Ghedini]

Package: wnpp
Owner: Alessandro Ghedini 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: mpv
  Version : 0.1.0
  Upstream Author : mpv team
* URL : http://mpv.io/
* License : GPL-2+
  Programming Lang: C
  Description : video player based on MPlayer/mplayer2

mpv is a movie player based on MPlayer and mplayer2. It supports a wide
variety of video file formats, audio and video codecs, and subtitle types.

Changes from mplayer2 to mpv include:
 * Removal of lots of unneeded code to encourage developer activity
 * Better OSD rendering
 * Cleaned up terminal output
 * Improved OpenGL output
 * Encoding functionality (replacement for mencoder)
 * Wayland support
 * Support for playing URLs of popular streaming sites
 * Screenshot improvements
 * ...
See mpv(1) for more info regarding changes between MPlayer, mplayer2 and mpv.

The Debian packaging is maintained at [0].

Cheers

[0] http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpv.git;a=summary


-- 
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/debian-devel

arm laptops and d-i

[Adam Borowski]

I loathe laptops, and thus didn't own one.  Needing one for DebConf (and
this time no friend had a working one for me to borrow), instead of getting
an used x86 one, I bought a $150 13.3" android thing.  Because, you know,
installing a certain universal operating system should be easy, especially
if it's a popular SoC (Allwinner) and graphics chip (Mali 400), right?
Oh naive me.

It took me way too much time to figure it out, and I'm not exactly a
Debian newbie (although no experience with laptops or arm bootloaders). 
The main block was no way to reflash the machine to a working state,
making me afraid to touch the nand bootloader in a non-obvious way.  That
is, until I learned that Allwinners boot first from a sd card; all you
need to do is to put an ubooted kernel into the right place and copy
appropriate code into sectors before the first partition.  Sounds... 
familiar.  That's not enough, of course, as without a module "lcd" there's
no display, etc -- debugging which requires moving the sd card, plopping
qemu-static-arm onto it and installing sshd.  Same for trying anything
else.

Now imagine a regular user trying that...

So, whom do I beat with this laptop to get d-i working?

Looks like a substantial part of Allwinner drivers got converted to DT in
3.8, 3.10 and 3.11 kernels, so it might work without a device-specific
kernel.

Thus, if anyone would like to play with such an exotic laptop, feel free
to either catch me on debconf, or send me d-i images to test...  It's an
Omega OAN133, not a widespread piece of hardware, but we need to do
something with incoming flood of Chromebooks and so on.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130813225427.gd3...@angband.pl

Re: arm laptops and d-i

[Cyril Brulebois]

Adam Borowski  (2013-08-14):
> I loathe laptops, and thus didn't own one.  Needing one for DebConf (and
> this time no friend had a working one for me to borrow), instead of getting
> an used x86 one, I bought a $150 13.3" android thing.  Because, you know,
> installing a certain universal operating system should be easy, especially
> if it's a popular SoC (Allwinner) and graphics chip (Mali 400), right?
> Oh naive me.

What?! Somebody needs to do some work before new hardware is supported?
Shocking.

> It took me way too much time to figure it out, and I'm not exactly a
> Debian newbie (although no experience with laptops or arm bootloaders). 
> The main block was no way to reflash the machine to a working state,
> making me afraid to touch the nand bootloader in a non-obvious way.  That
> is, until I learned that Allwinners boot first from a sd card; all you
> need to do is to put an ubooted kernel into the right place and copy
> appropriate code into sectors before the first partition.  Sounds... 
> familiar.  That's not enough, of course, as without a module "lcd" there's
> no display, etc -- debugging which requires moving the sd card, plopping
> qemu-static-arm onto it and installing sshd.  Same for trying anything
> else.
> 
> Now imagine a regular user trying that...
> 
> So, whom do I beat with this laptop to get d-i working?
> 
> Looks like a substantial part of Allwinner drivers got converted to DT in
> 3.8, 3.10 and 3.11 kernels, so it might work without a device-specific
> kernel.
> 
> Thus, if anyone would like to play with such an exotic laptop, feel free
> to either catch me on debconf, or send me d-i images to test...  It's an
> Omega OAN133, not a widespread piece of hardware, but we need to do
> something with incoming flood of Chromebooks and so on.

Since you're “not exactly a Debian newbie” maybe you could have figured
out that mailing -boot/-kernel might be a nice first bet, right?

Also, thanks for the “why the hell isn't shiny new hardware working out
of the box” attitude.

Not amused,
KiBi.


-- 
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/20130813230735.gb25...@mraw.org

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Emanuele Aina]

The Wanderer wrote:

> [...] and the "proprietary"[0] interfaces they seem to
> use [...]
>
> [...]
>
> [0] Meaning approximately "we create our own language and talk it to
> ourselves, and anyone else who wants to talk to us has to learn our
> language", not intending to imply "undocumented" or "legally restricted"
> or anything of the sort. This isn't a very good term for what I mean,
> but I couldn't find a better one.

I tend to think that "custom interfaces" would be more appropriate for
what you described here.

The term "proprietary" seems to imply some sort of exclusivity with
regard to those interfaces, while my current impression is that systemd
developers do not have any interest in locking them to systemd: to the
contrary the seem quite happy that some of them got adopted by others
(hostnamed, localed, logind, etc.) and link to them from their wiki:

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

In the case of logind, it has even been made able to run standalone to
let others reuse the same implementation, not only the interface.


Sorry for the digression, I just took the chance to mention this stuff
here since it's not the first time I see this term used somewhat
inappropriately in this context.

-- 
Emanuele Aina
http://www.collabora.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/1376431619.3526.35.ca...@autarpio.lan

Bug#719655: ITP: svnstsw -- SVNServe Tunnel-mode Setuid/setgid Wrapper

[Geoffrey Thomas]

Package: wnpp
Severity: wishlist
Owner: Geoffrey Thomas 

* Package name: svnstsw
  Version : 1.4
  Upstream Author : Richard Hansen 
* URL : http://www.ir.bbn.com/~rhansen/svnstsw/
* License : 3-clause BSD
  Programming Lang: C
  Description : SVNServe Tunnel-mode Setuid/setgid Wrapper

svnstsw is a wrapper around svnserve that sets the tunnel user equal to 
the username of the user that started the wrapper. It is intended be made 
setuid or setgid by the local administrator, to allow local users on a 
shared system to invoke svnserve without having direct access to the 
repository itself.


---

svnstsw's upstream source is in contrib/ in the Subversion repository, but 
contrib/ is not distributed as part of the Subversion release tarball. I'm 
copying the subversion packagers in case they have thoughts, want to 
co-maintain, etc.


--
Geoffrey Thomas
gtho...@mokafive.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/alpine.deb.2.02.1308131607580.2...@salmon-of-wisdom.skyblue-technologies.com

Re: We need a global decision about R data in binary format, and stick to it.

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 05 August 2013 17:48:27 Paul Wise wrote:
> On Mon, Aug 5, 2013 at 4:28 PM, Sune Vuorela wrote:
> > What about svg files that are converted into png's and then manually
> > adjusted?
> 
> I'd say the "source" is the combination of the SVG files plus the adjusted
> PNGs.
> 
> I guess you are thinking of a particular case here? What is the reason
> for manually adjusting them?

Maybe optipng-ed images? Anyway, AFAIR, last time I tried that I did all in 
the rules file, so nothing to be afraid here.

-- 
Passwords are like underwear. You shouldn’t leave them out where people can
see them. You should change them regularly. And you shouldn’t loan them out
to strangers.
  Anonymous

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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