ask github to encourage signed git tags

[Thomas Koch]

Hi,

we want upstream to sign releases. Nowadays a lot of software is on github and 
a release is just a git tag. - An unsigned git tag ... :-(

Github has a site that shows tags[1] but it does not give any indication 
whether the tag is signed or not.
[1] e.g. https://github.com/Flameeyes/unpaper/tags

Github should add visual feedback on this tags page: grey for unsigned, yellow 
for signed and green for signed and connected to the web-of-trust. Next to a 
grey or yellow tag there should be links to help texts.

I expect that this would help to increase the usage of signed git tags.

I asked github.com/contact to do this more than a year ago. - No response. 
What, if the debian project together with others would request this through a 
more official channel?

Yes, github is proprietary. Still it would be in the best interest of 
everybody if software was signed. Even github would not want to host malicious 
code.

Does anybody have contact to github?

Thomas Koch

Re: ask github to encourage signed git tags

[Timo Weingärtner]

Hi,

2015-08-21 09:51:45 Thomas Koch:
> we want upstream to sign releases. Nowadays a lot of software is on github
> and a release is just a git tag. - An unsigned git tag ... :-(
> 
> Github has a site that shows tags[1] but it does not give any indication
> whether the tag is signed or not.
> [1] e.g. https://github.com/Flameeyes/unpaper/tags
> 
> Github should add visual feedback on this tags page: grey for unsigned,
> yellow for signed and green for signed and connected to the web-of-trust.
> Next to a grey or yellow tag there should be links to help texts.

Connected to the WOT means the strong set?

While I think signed tags are enough, many things rely on signed tarballs.
github should thus also allow uploading signatures for the tarball generated
from the (signed) tags and provide instructions for how to generate the
tarballs yourself.

I can generate github-identical tarballs with:
$ git archive --prefix="${PROJECT}-${TAG}/" -o 
"${HOME}/build-area/${PROJECT}_${TAG}.orig.tar.gz" "${TAG}"

> Yes, github is proprietary. Still it would be in the best interest of
> everybody if software was signed. Even github would not want to host
> malicious code.

Signed software does not imply non-malicious code.


Regards
Timo

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

use signed git tags to verify upstream tarball

[Thomas Koch]

Sometimes we are lucky and upstream uses signed git tags. That still does not 
help us to verify the orig.tar.gz. It can however still be very useful.

If we store some git objects in debian/upstream/.../ than we can at least 
verify those files that are the same in the tarball and in the tagged git 
commit.

We need to store the git tag, git commit and all tree objects from the tagged 
commit. Then we have trusted sha1 signatures of all files from the tagged git 
commit. The tarball might contain additional files, e.g. compiled stuff or 
configure files, but we don't want to rely on those anyways.

Maybe this file structure?

debian/upstream/git
  objects // flat structure, unlike gits two level structure
5f19d6d7380dc9416f5f852e8b3a9c06f239cb93 // plain, no zlib compression
  refs
tags
  1.0.3 // same as in git

Objects are not compressed since they end up in a tar.gz anyways. The objects 
store does not contain any blobs, only tree, commit and tag objects.

Somebody wants to write the necessary tools (in haskell...)?  

Thomas Koch

Re: libstdc++ follow-up transitions

[Simon McVittie]

On 18/08/15 00:37, Steve Langasek wrote:
> On Mon, Aug 17, 2015 at 01:46:16PM +0100, Simon McVittie wrote:
>> Having done more rebuilds in Ubuntu, it would be great if you could
>> publish a complete list of the transitions you believe to be necessary
> 
> Here's the count of source packages in Ubuntu wily that produce binary
> packages ending in 'v5', which is probably a good approximation

Thanks, I have added them to  so we can
hopefully get a better picture of what needs to be done.

For the items that are still to-do or undecided, I've been adding
reverse dependency counts to that list, using max(broken build-depends,
source packages with broken depends) from a dak command like "dak rm -R
-n adplug", so that people can see whether they are "almost leaf"
packages or not. In most cases the answer is that they have < 10 direct
rdeps, which strikes me as getting into "fix it later" territory.

hunspell is one notable exception, if it does indeed need renaming (I
haven't verified)

I think we might be at or approaching a point where it is worthwhile to
schedule a significant number of binNMUs and make more of unstable
installable again, without needing to re-binNMU too many of the same
packages later? For instance, the ilmbase -> openexr -> opencv stack are
all fixed in unstable, and so are most of the glibmm stack (e.g. gtkmm).

S

Re: ask github to encourage signed git tags

[Asheesh Laroia]

On Fri, Aug 21, 2015 at 9:51 AM, Thomas Koch  wrote:

>
> Does anybody have contact to github?
>

Yes, I do! I've pinged a friend at GitHub and CC:d the people who have
participated in this thread so far. Let's see how that conversation goes.

-- Asheesh.

Re: ask github to encourage signed git tags

[Harlan Lieberman-Berg]

Asheesh Laroia  writes:
> Yes, I do! I've pinged a friend at GitHub and CC:d the people who have
> participated in this thread so far. Let's see how that conversation goes.

Just as an FYI, signing a git tag produces a slightly weaker security
guarantee than signing a tarball.

Specifically, an attacker who is capable of a second-preimage attack on
SHA-1 can forge git commits which will still verify if signed.  No one
has publically been able to produce even a collision in SHA-1 yet,
though most people suspect it is either already in the capability of
state-level attackers or will be in the next few years.  Second-preimage
is harder than just producing collisions, but it is still something
that's good to be aware of.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Re: libstdc++ follow-up transitions

[Rene Engelhard]

Hi,

On Fri, Aug 21, 2015 at 12:12:40PM +0100, Simon McVittie wrote:
> hunspell is one notable exception, if it does indeed need renaming (I
> haven't verified)

It was already bin-NMUed without renaming 16d ago. That said, a testbuild
of LO with non-transitioned libs did NOT give me a build failure and
installing libhunspell-1.3-0 1.3.3-3 from stretch doesn't break spellchecking
in LO in sid (already built with gcc 5). So...

Regards,

Rene

Bug#796337: ITP: node-cross-spawn-async -- Cross platform child_process#spawn

[Ross Gammon]

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

* Package name: node-cross-spawn-async
  Version : 2.0.0
  Upstream Author : IndigoUnited 
(http://indigounited.com)
* URL :
https://github.com/IndigoUnited/node-cross-spawn-async#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Cross platform child_process#spawn
A cross platform solution to node's spawn.
.
The same module can be used on WIndows and Linux. It correctly handles
PATHEXT, shebangs, del or dir and, escape arguments with spaces or
special characters.
.
Node.js is an event-based server-side JavaScript engine.

This package is a new dependency for the latest node-cross-spawn, and
will be maintained alongside node-cross-spawn in the Debian Javascript Team.



signature.asc
Description: OpenPGP digital signature

Re: use signed git tags to verify upstream tarball

[Danny Edel]

On 21/08/15 11:12, Thomas Koch wrote:
> Sometimes we are lucky and upstream uses signed git tags. That still does not 
> help us to verify the orig.tar.gz. It can however still be very useful.
> 

Hi Thomas,

In case you're intrested, I've tried to reproduce a "git archive" style
tarball (for example, as generated by github) from a gpg-signed tag.

This should at least imply some kind of trust.


Basically do (assuming you have some WOT toward the signer's key)

(1) git clone

(2) git tag --verify v1.31

(3) git archive v1.31 --prefix="projectname-1.31/" --format=tar | gzip
-n > projectname-1.31.tar.gz

The produced tarball will be exactly the same as the github-generated
tarball, so if you use this as .orig.tar.gz, embedding the checksum into
your signed debian-changes file, you can use github's mirror safely and
should not have to worry about man-in-the-middle attacks.

Since you now have a direct correlation between signed+verified tag and
(locally, on your trusted system, regenerated) orig.tar.gz from this
very tag, does this help?

- Danny

Bug#796363: ITP: libsis-base-java -- supplies some utility classes needed for libraries like sis-jhdf5

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: libsis-base-java
  Version : 14.12.0
  Upstream Author : ETH Zuerich, CISD
* URL : https://wiki-bsse.ethz.ch/display/JHDF5/Download+Page
* License : Apache
  Programming Lang: C, Java
  Description : supplies some utility classes needed for libraries like 
sis-jhdf5

Base libraries used by software from the SIS division at ETH Zurich
 This library supplies some utility classes needed for libraries like sis-jhdf5.

Re: gfortran: handling binNMU for .mod file format change

[Michael Banck]

Hi,

I had a look at your dh-fortran-mod package, and am quite sorry I missed
this until now :-/

I assume this is meant for ${misc:Depends} in the -dev package, right?

On Wed, Mar 12, 2014 at 06:44:50PM +0100, Sébastien Villemot wrote:
> Le dimanche 11 août 2013 à 11:11 +0900, Ryo IGARASHI a écrit :
> > >From my limited understanding of debian packaging, I have to write a
> > debhelper script (say: dh_fortran_mod) which add the correct virtual
> > dependencies of Fortran mod file to ${misc:depends}.
> > 
> > Is this the correct way to proceed?
> 
> I think this goes in the right direction. Did you make any progress on
> this?
> 
> More specifically, I think that dh_fortran_mod should do the following:
> 
> - it would read a file debian/[package.]fortran-mod, which would contain
> a list of mod files created by gfortran and to be installed into binary
> packages

I was caught off-guard that I needed to list the *.mod files in
debian/.fortran-mod.
 
Can you explain why it cannot just scan debian/tmp (or rather
tmpdir($package)) I guess for .mod files recursively?  Probably /usr
would be enough.  Or is this following a general debhelper design
decision I am not familiar with?

> - it would also add the relevant virtual dependencies on
> gfortran-mod- in ${misc:Depends}
 
OK, sounds good.

The only other question I have right now (and which we couldn't 100%
figure out at DebConf15), is whether Fortran90 (or even Fortran77)
applications break at run-time if the module version changes and/or the
created libraries are different depending on the fortran module version.
We thought it wasn't, but it's probably a good idea to make sure.


Michael


Michael

Who has rights to override/ignore systemd inhibitors?

[Jayson Willson]

Hello. I have realized, that my user (groups: 
tty,disk,mail,news,dialout,voice,sudo,audio,www-data,video,plugdev,users,mlocate,kvm,vboxusers,libvirt) 
can ignore inhibitors (such as root being logged in) using "systemctl 
suspend/poweroff/etc -i" without password prompt (with standard polkit 
configuration and without NOPASSWD in sudoers). I have asked in 
systemd-devel, why does it happen, and Lennart has answered, that 
authentication is handled by Polkit policy in file 
/usr/share/polkit-1/actions/org.freedesktop.login1.policy


That's what I have in this file:


Power off the system while an application 
asked to inhibit it
Authentication is required for powering off 
the system while an application asked to inhibit it.


auth_admin_keep
auth_admin_keep
auth_admin_keep

key="org.freedesktop.policykit.imply">org.freedesktop.login1.power-off



It seems like authentication IS required to poweroff/suspend/etc system, 
disregarding inhibitors. However, on my system, without any special 
polkit configuration standard user (which is in the groups mentioned 
above) can ignore inhibitors by running systemctl poweroff -i without 
being asked for authentication.
Could you please help me to understand, why doest it happen and how can 
I change this behaviour? Thank you.

Re: Permissions on collab-maint

[Geeg Geeg]

I need... some shit.. just get me some shit...

On Fri, Aug 21, 2015 at 12:12 PM, Alexander Wirt 
wrote:

> Hi,
>
> I am doing some urgent fixes on debian collab-maint. After I finished only
> DDs
> (group Debian) will be able to create repos and change hooks.
>
> If you need to create a new repository please ask a member of the Debian
> group to create the repository. If you are a member of the Debian and want
> to
> create a new repository please use /git/collab-maint/setup-repository,
> otherwise non Debian members won't be able to commit.
>
> Alex - Alioth administrator
>

Bug#796390: ITP: libsis-jhdf5-java -- HDF library for Java

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: libsis-jhdf5-java
  Version : 14.12.1
  Upstream Author : ETH Zuerich CISD
* URL : http://svncisd.ethz.ch/repos/cisd/jhdf5/tags/release/
* License : Apache
  Programming Lang: C, Java
  Description : HDF library for Java

JHDF5 is a Java binding to the HDF Group library for HDF5 focusing on
ease-of-use, which was developed by CISD and is now maintained by ETH SIS.
The library uses HDF5 1.8 from the HDF Group and files created with
JHDF5 are fully compatible with HDF5 1.6/1.8 (as you choose).

Re: Bits from the Wanna Build team

[Steve Langasek]

Hi Mehdi,

On Fri, Aug 21, 2015 at 01:12:12PM +0200, Mehdi Dogguy wrote:
> Auto-building arch:all packages
> ===

> We have worked on getting arch:all packages buildable on our
> autobuilders. We've got a few patches [2,3] added to make that
> happen. Architecture independent packages (arch:all) are now
> auto-built on dedicated amd64 builders. We tested our changes as much
> as we were able to and enabled arch:all uploads for Sid and
> Experimental. If your auto-built arch:all package doesn't make it
> through to ftp-master's archive, please do contact us [4] so that we
> can have a look and get it fixed quickly.

> Before rushing on uploading source-only packages, please do test your
> packages by building, installing and testing them locally in order to
> minimize build failures and avoid blocking ongoing transitions. Note
> that the arch:all buildds use the "build-indep" target in debian/rules
> which probably hasn't seen wide testing yet.

> [2] https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/log/
> [3] https://buildd.debian.org/git/wanna-build.git/
> [4] https://lists.debian.org/debian-wb-team/

This is all great news!

If I'm not mistaken, the last feature that needs to be implemented in
wanna-build for us to be able to drop all maintainer-uploaded binaries, and
only ship binaries built on the buildds, is build architecture affinity for
architecture: all packages.  What's the outlook on this happening?

-- 
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: Bits from the Wanna Build team

[Jakub Wilk]

* Mehdi Dogguy , 2015-08-21, 13:12:
We tested our changes as much as we were able to and enabled arch:all 
uploads for Sid and Experimental.


:D

Before rushing on uploading source-only packages, please do test your 
packages by building, installing and testing them locally in order to 
minimize build failures and avoid blocking ongoing transitions. Note 
that the arch:all buildds use the "build-indep" target in debian/rules 
which probably hasn't seen wide testing yet.


Hmm, how do you build only arch:all packages in sbuild?

*-indep targets of these packages are most likely broken:
https://qa.debian.org/bls/bytag/E-binary-arch-produces-all.html

Any volunteers to file bugs?
Or to make a full archive rebuild to find even more bugs? :)

--
Jakub Wilk

Re: Bits from the Wanna Build team

[Luca Falavigna]

2015-08-21 19:54 GMT+02:00 Jakub Wilk :
> Hmm, how do you build only arch:all packages in sbuild?

See commit below, not uploaded to sid yet:
https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=fec82ed70d7efdfe17f676c60e1114bd8bb4a888

-- 
Cheers,
Luca

Bug#796401: ITP: disorderfs -- FUSE filesystem that introduces non-determinism

[Andrew Ayer]

Package: wnpp
Severity: wishlist
Owner: Andrew Ayer 

* Package name: disorderfs
  Version : 0.1.0
  Upstream Author : Andrew Ayer 
* License : GPL-3+
  Programming Lang: C++
  Description : FUSE filesystem that introduces non-determinism

disorderfs is an overlay FUSE filesystem that introduces non-determinism
into filesystem metadata.  For example, it can randomize the order
in which directory entries are read.  This is useful for detecting
non-determinism in the build process.

Re: Who has rights to override/ignore systemd inhibitors?

[Simon McVittie]

On 21/08/15 17:14, Jayson Willson wrote:
> Hello. I have realized, that my user (groups:
> tty,disk,mail,news,dialout,voice,sudo,audio,www-data,video,plugdev,
> users,mlocate,kvm,vboxusers,libvirt)
> can ignore inhibitors (such as root being logged in) using "systemctl
> suspend/poweroff/etc -i"

Root being logged in is a factor that might (depending on policy)
prevent you from powering off, but it is not an inhibitor. An inhibitor
is a specific systemd-logind feature: when a program tells logind "don't
shut down until I say you can", that is an inhibitor.

org.freedesktop.login1.power-off-multiple-sessions is what might stop
you from shutting down while another user is logged in, and its default
policy is:


auth_admin_keep
auth_admin_keep
yes


You will notice that "active" users (the user who is at the current
virtual console, if you are using fast user switching) can do this, by
default. This is because, if the user is local (physically present),
restricting the ability to shut down is an annoyance with no actual
security value: a physically present user could just unplug power and/or
remove a laptop battery, which is an implementation of shutdown that
clearly does not respect inhibitors.

If this default is unsuitable for your security policy (for instance
because your computer's power cable is not physically accessible by its
user), you can change it.

> I have asked in
> systemd-devel, why does it happen, and Lennart has answered, that
> authentication is handled by Polkit policy in file
> /usr/share/polkit-1/actions/org.freedesktop.login1.policy

That is part of it, but not the full story. If you have polkit from
unstable or older, .pkla files in /var/lib/polkit-1/localauthority and
/etc/polkit-1 are also relevant. (In theory someone could write a plugin
other than the "local authority" one, but in practice everyone uses that
plugin, which was originally just meant to be a reference implementation.)

With the newer polkit in experimental, JavaScript in
/usr/share/polkit-1/rules.d and /etc/polkit-1/rules.d is relevant instead.

Either way, it is possible to write rules in /etc to allow or deny
actions, overriding both the defaults in the .policy file and the
Debian-supplied rules in /var and /usr (which you can use as examples).

> without password prompt (with standard polkit
> configuration and without NOPASSWD in sudoers).

polkit does not run sudo, read sudoers, or understand sudoers syntax, so
whether you have NOPASSWD there is irrelevant. Its only relationship to
sudo is that both sudo and polkit, under their default configuration on
Debian, use the group named sudo to mean "this user is root-equivalent /
an administrator". It is not necessarily directly related to this
particular question, but if you don't want your user to be arbitrarily
powerful, don't put it in the sudo group.

The disk group is also highly inappropriate for a user that is not meant
to be root-equivalent, since it normally has access to the raw disk
devices for hard disks, and can bypass all access controls by (for
instance) editing the filesystem metadata of a shell to make it setuid-root.

If you want your user to not be root-equivalent, but you want to be able
to (for instance) edit the raw data of USB drives, I suggest a udev rule
in /etc/udev/rules.d/70yourname.rules. For instance this rule (which is
one long line) gives the active local user read/write access to all
USB-attached disk devices:

ACTION!="remove", ENV{MAJOR}!="", ENV{ID_BUS}=="usb",
SUBSYSTEM=="block", TAG+="uaccess"

S

Re: Who has rights to override/ignore systemd inhibitors?

[Jayson Willson]

Thank you very much for your answer, I have understood everything.
Only one question is left:
Does it mean, that with such configuration those users, which are 
connected using ssh, for example, won't be able to shutdown computer, 
unless he passes polkit authentication? Also, are users, who logged in 
using display manager considered local?

Re: Who has rights to override/ignore systemd inhibitors?

[Simon McVittie]

On 21/08/15 20:18, Jayson Willson wrote:
> Does it mean, that with such configuration those users, which are
> connected using ssh, for example, won't be able to shutdown computer,
> unless he passes polkit authentication?

You could try it and find out? But I believe you are correct.

> Also, are users, who logged in
> using display manager considered local?

Yes. Use "loginctl list-sessions" to list login sessions by ID, then
"loginctl show-session 42", where 42 is the session ID, to see whether
they are considered active, local (Remote=no), and so on.

S

Bug#796464: general: there is no auto crash reporting

[Richard Jasmin]

Package: general
Severity: important

debian should implement an automatic crash detection and reporting system like
Fedora and Ubuntu teams have.If not mistaken, Fedora uses upstream of what
ubuntu uses --apport.

There is no reason for debian to not have this feature.Yes, it is mostly a gui
tool. Debian is used on both client workstations and servers.

Tool should catch crashes as they happen and allow users to report them.It
should auto-generate and allow people to auto generate debugging backtrace
reports, installing gdb packages as needed.This would generate useful traces
for developers in non-trivial way.

Hint: corekeeper? ..but that is console based. Who uses a console these days?



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#796464: general: there is no auto crash reporting

[Aron Xu]

On Sat, Aug 22, 2015 at 6:04 AM, Richard Jasmin  wrote:
> Package: general
> Severity: important
>
> debian should implement an automatic crash detection and reporting system like
> Fedora and Ubuntu teams have.If not mistaken, Fedora uses upstream of what
> ubuntu uses --apport.
>
> There is no reason for debian to not have this feature.Yes, it is mostly a gui
> tool. Debian is used on both client workstations and servers.
>
> Tool should catch crashes as they happen and allow users to report them.It
> should auto-generate and allow people to auto generate debugging backtrace
> reports, installing gdb packages as needed.This would generate useful traces
> for developers in non-trivial way.
>
> Hint: corekeeper? ..but that is console based. Who uses a console these days?

We have a GSoC project this year working specifically on Apport for
Debian, and you might be interested to follow up on that, :)

Thanks,
Aron

[1]https://wiki.debian.org/SummerOfCode2015/Projects#SummerOfCode2015.2FProjects.2FApportForDebian.Apport_for_Debian
[2]http://blog.yurushao.info/2015/07/Debian-Apport-GSoC/
[3]http://www.researchut.com/blog/gsoc-apport-for-debian

Bug#796467: general: if user has mail then how do we tell them if in GUI mode?

[Richard Jasmin]

Package: general
Severity: important

telling user has mail is easy as pi in console mode and when using a server.
But how do we tell the user they have mail without a configured mail client
when under runlevel 5? The activation of X11 practically hides all console
activity.

We would need a UI tool to do this. We cannot assume use of neither gnome nor
KDE. User may have MATE or other UI installed.We should make an app
indicator(and mail viewer) as lite as possible.

Also, when launching xterm or similar, user is never told if they have mail or
not.This should be a more eay fix.Since xterm emulates a vterm/getty checking
mail this way should never fail.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: Bug#796467: general: if user has mail then how do we tell them if in GUI mode?

[Adam Borowski]

On Fri, Aug 21, 2015 at 05:20:17PM -0500, Richard Jasmin wrote:
> telling user has mail is easy as pi in console mode and when using a server.
> But how do we tell the user they have mail without a configured mail client
> when under runlevel 5? The activation of X11 practically hides all console
> activity.
> 
> We would need a UI tool to do this. We cannot assume use of neither gnome nor
> KDE. User may have MATE or other UI installed.We should make an app
> indicator(and mail viewer) as lite as possible.

apt-cache search biff

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)

Re: Bug#796467: general: if user has mail then how do we tell them if in GUI mode?

[Riley Baird]

On Fri, 21 Aug 2015 17:20:17 -0500
Richard Jasmin  wrote:

> Package: general
> Severity: important
> 
> telling user has mail is easy as pi in console mode and when using a server.
> But how do we tell the user they have mail without a configured mail client
> when under runlevel 5? The activation of X11 practically hides all console
> activity.
> 
> We would need a UI tool to do this. We cannot assume use of neither gnome nor
> KDE. User may have MATE or other UI installed.We should make an app
> indicator(and mail viewer) as lite as possible.
> 
> Also, when launching xterm or similar, user is never told if they have mail or
> not.This should be a more eay fix.Since xterm emulates a vterm/getty checking
> mail this way should never fail.

Have you tried xfce4-mailwatch-plugin?


pgpiJzGW0Udv_.pgp
Description: PGP signature

Bug#796467: general: if user has mail then how do we tell them if in GUI mode?

[Josh Triplett]

On Fri, 21 Aug 2015 17:20:17 -0500 Richard Jasmin  
wrote:
> telling user has mail is easy as pi in console mode and when using a server.
> But how do we tell the user they have mail without a configured mail client
> when under runlevel 5? The activation of X11 practically hides all console
> activity.
> 
> We would need a UI tool to do this. We cannot assume use of neither gnome nor
> KDE. User may have MATE or other UI installed.We should make an app
> indicator(and mail viewer) as lite as possible.
> 
> Also, when launching xterm or similar, user is never told if they have mail or
> not.This should be a more eay fix.Since xterm emulates a vterm/getty checking
> mail this way should never fail.

To a first approximation, for the majority of users, if they don't have
a mail client configured, they don't have mail.  One of these days I'd
still like to get mail-transport-agent removed from "standard", to get
rid of one of the last listening services in a default install, as the
majority of users don't need it and those that do can easily install it.

That said, if you care about a local mail server, and you don't have a
local mail client configured, there are a few different tools to handle
that case, including variations on biff or services that use desktop
notifications.  You could also configure a local mail client, since you
might want to read that mail once you know of its existence.

- Josh Triplett

Re: Bug#796464: general: there is no auto crash reporting

[Stephen Allen]

On Fri, Aug 21, 2015 at 05:04:43PM -0500, Richard Jasmin wrote:
> Package: general
> Severity: important
> 
> debian should implement an automatic crash detection and reporting system like
> Fedora and Ubuntu teams have.If not mistaken, Fedora uses upstream of what
> ubuntu uses --apport.

apport is in experimental.

Bug#796487: ITP: repeatmasker-recon -- indentification of repeat families from biological sequences

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: repeatmasker-recon
  Version : 1.08
  Upstream Author : Institute for Systems Biology
* URL : http://www.repeatmasker.org/
* License : GPL
  Programming Lang: C, Perl
  Description : indentification of repeat families from biological sequences

The RECON package implements a de novo algorithm for the
indentification of repeat families from biological sequences.  For
details about the algorithm, see

Bao Z. and Eddy S.R. (2002) Automated de novo Identification of Repeat
Sequence Families in Sequenced Genomes. Submitted.

and

http://www.genetics.wustl.edu/eddy/recon

This distribution includes two Perl scripts and several C programs.
Most users only need to run the scripts and the C programs should be
transparent.