Re: Bug#787739: ITP: plip -- fully automated protein-ligand interaction profiler

[Alex Mestiashvili]

On 06/04/2015 11:35 PM, Simon Richter wrote:

Hi,

On 04.06.2015 17:21, Alexandre Mestiashvili wrote:


* Package name: plip


This might be confusing to old people. PLIP is a protocol for
transporting IP packets over the parallel port.

Simon




Hi Simon,

I agree that the name is a bit ambiguous, but I see a couple
of reasons why it is still might be ok:

- aptitude search plip shows only hplip, which has nothing to do with
 parallel port as well.
- plipconfig is provided by net-tools package, and I think
 it is not likely that somebody will create a package for parallel
 port ip protocol software only.
- it is not a python library to call it python-plip.
- any 4 letter name is ambiguous and currently
 there are ~ 790 such packages.

And honestly, being old doesn't mean using old technologies :)

After the discussion with the upstream, I think I can rename it to

 pliprofiler

The problem is that I've already created the repository:

 http://anonscm.debian.org/cgit/debian-med/plip.git

Which should be renamed in this case.

What is the correct way to do it ?

Thank you,
Alex


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55716b27.3060...@biotec.tu-dresden.de

Re: Proposal v2: enable stateless persistant network interface names

[Milan P. Stanic]

On Thu, 2015-06-04 at 19:41, Michael Biebl wrote:
> Am 04.06.2015 um 10:10 schrieb Josselin Mouette:
> > How about using only the last 3 bytes of the MAC?
> > 
> > The probability of using, on the same system, *two or more* controllers
> > from *different brands* with a collision in the last 3 bytes is
> > nonexistent in practice.
> > 
> > The clear benefit would be that 3 bytes / 6 hex digits are easy enough
> > to remember in the short term memory when you need to type a command. 6
> > hex digits are also regularly used as short git references for that same
> > reason. 
> 
> That's an interesting idea.I don't think though we should change the
> existing mac NamePolicy. After all, this naming policy could already be
> in use. Maybe introduce a new type, say mac-short ?

Maybe I have unusual configuration but look at this:

arya:~# ip link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: lan:  mtu 1500 qdisc pfifo_fast master br0 
state UP mode DEFAULT group default qlen 1000
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
4: br0:  mtu 1500 qdisc noqueue state UP mode 
DEFAULT group default
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
10: kvm0:  mtu 1500 qdisc pfifo_fast master 
br0 state UNKNOWN mode DEFAULT group default qlen 500
link/ether 4a:f9:f8:e1:5a:7a brd ff:ff:ff:ff:ff:ff

MAC address for lan and br0 are the same.
lan is physical Ethernet interface and br0 is bridge interface.

When I plug USB Ethernet adapter I have the next:

arya:~# ip link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: lan:  mtu 1500 qdisc pfifo_fast master br0 
state UP mode DEFAULT group default qlen 1000
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
4: br0:  mtu 1500 qdisc noqueue state UP mode 
DEFAULT group default
link/ether 00:60:6e:00:48:1a brd ff:ff:ff:ff:ff:ff
10: kvm0:  mtu 1500 qdisc pfifo_fast master 
br0 state UNKNOWN mode DEFAULT group default qlen 500
link/ether 4a:f9:f8:e1:5a:7a brd ff:ff:ff:ff:ff:ff
16: usb:  mtu 1500 qdisc pfifo_fast master br0 
state UP mode DEFAULT group default qlen 1000
link/ether 00:60:6e:00:48:1a brd ff:ff:ff:ff:ff:ff

Now, USB Ethernet interface (usb) and bridge (br0) have the same MAC.

I know that I made unusual config but anyway I think that the naming
interface by using MAC (or part of it) is not good idea.

Or I still live in the time when the interfaces have had real (i.e.
human readable and easy to remember) names.

-- 
Best regards


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150605085741.ga25...@arvanta.net

Regarding text display issues

[Himanshu Shekhar]

Hello
I am a Linux enthusiast and have started using Debian a few days back after
using Ubuntu for 2 years. Debian is really awesome and doesn't crash.
Well, right now I have two major issues :
1. Debian cannot display languages as Hindi, not even Google Hindi in
Chromium.
2. I just get confused in app names in Synaptic and want to install apps
without using DVD easily.
It would be great for this newbie to be properly guided.
Thanks

Himanshu Shekhar
Linux enthusiast

Re: Regarding text display issues

[Tomas Pospisek]

Hello Himanshu Shekar,

Am 05.06.2015 um 11:33 schrieb Himanshu Shekhar:
> Hello
> I am a Linux enthusiast and have started using Debian a few days back
> after using Ubuntu for 2 years. Debian is really awesome and doesn't crash.
> Well, right now I have two major issues :
> 1. Debian cannot display languages as Hindi, not even Google Hindi in
> Chromium.
> 2. I just get confused in app names in Synaptic and want to install apps
> without using DVD easily.
> It would be great for this newbie to be properly guided.

For user support you have the following options:

https://www.debian.org/support
https://lists.debian.org/debian-user/
http://forums.debian.net/
http://ask.debian.net/
irc://irc.oftc.net/debian

I hope this will help you on,
*t


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55717269.6020...@sourcepole.ch

Issue with PTS watch file service

[Daniel Leidert]

Hi,

Is it possible, that the watch file service of our PTS has some issue
atm? The PTS spuriously reports "temporary or permanent problems" for
some projects, although the watch files look perfectly ok to me and
uscan does work as expected. Some examples:

https://packages.qa.debian.org/a/abgate.html (sf.net)
https://packages.qa.debian.org/a/amsynth.html (github)
https://packages.qa.debian.org/c/calf.html (sf.net)
https://qa.debian.org/developer.php?login=debichem-de...@lists.alioth.debian.org
 (sf.net, other)

For the latter many of the sf.net based projects are missing the
upstream version in the output.

Please feel free to forward this to the correct address.

Regards, Daniel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433503454.27947.11.ca...@gmx.net

Re: Bug#787739: ITP: plip -- fully automated protein-ligand interaction profiler

[Simon Richter]

Hi Alex,

On 05.06.2015 11:25, Alex Mestiashvili wrote:

>> This might be confusing to old people. PLIP is a protocol for
>> transporting IP packets over the parallel port.

> I agree that the name is a bit ambiguous, but I see a couple
> of reasons why it is still might be ok:

Yes, I also think it is probably okay -- I just wanted to mention that
it might be confusing at first.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Regarding text display issues

[Konstantin Khomoutov]

On Fri, 5 Jun 2015 15:03:55 +0530
Himanshu Shekhar  wrote:

> Hello
> I am a Linux enthusiast and have started using Debian a few days back
> after using Ubuntu for 2 years. Debian is really awesome and doesn't
> crash. Well, right now I have two major issues :
> 1. Debian cannot display languages as Hindi, not even Google Hindi in
> Chromium.
> 2. I just get confused in app names in Synaptic and want to install
> apps without using DVD easily.
> It would be great for this newbie to be properly guided.

Hi!

First things first: please understand that this list is not a place to
ask for general user help as it's dedicated to the development of
Debian itself, so it features hard-core deeply technical discussions.
Tomas already pointed you to right directions for getting help so I
won't repeat that.

As to your specific problem with displaying Hindi text in Chrome,
I think that your system just misses the necessary fonts (that is, data
files that provide drawable representations for characters of a
specific language.  The basic Debian system supposedly only installs
fonts for the most commonly used scripts such as Western Latin etc.
I did a quick search among the available packages on my Debian Wheezy
system, and got this:

~% apt-cache search font hindi
fonts-deva-extra - Free fonts for Devanagari script
fonts-lohit-deva - Lohit TrueType font for Devanagari script
fonts-nakula - Free Unicode compliant Devanagari font
fonts-sahadeva - Free Unicode compliant Devanagari font
fonts-samyak-deva - Samyak TrueType font for Devanagari script
emacs-intl-fonts - Fonts to allow multi-lingual PostScript printing
task-hindi - Hindi environment

You can safely ignore the emacs-intl-fonts package as it is for use
with a particular text editor, but the others seem interesting,
in particular, the last one:

~% apt-cache show task-hindi
Package: task-hindi
Source: tasksel
Version: 3.14.1
Installed-Size: 21
Maintainer: Debian Install System Team 
Architecture: all
Depends: tasksel
Recommends: aspell-hi
Description-en: Hindi environment
 This task installs programs, data files, fonts, and
 documentation that makes it easier for Hindi speakers
 to use Debian.
[...]

Now, let's do a more targeted search:

~% apt-cache search task hindi
task-hindi - Hindi environment
task-hindi-desktop - Hindi desktop
task-hindi-kde-desktop - Hindi KDE desktop

So I'd say task-hindi-desktop would be a safe bet for you.

AFAIK, the next logical things to do is to (all commands are to be
execured in a console window):

1) Install that task package:

  # apt-get install task-hindi-desktop

2) Install the packages referenced by that task:

   * Run tasksel:

 # tasksel

   * Select the task for Hindi Desktop in the list,
 then press OK in the interface.

See  for more.

May be others will provide you with more user-friendly solutions
(I don't use tools like Synaptic anyway so can't help with this).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150605153204.41a7f57695c9da6d262c6...@domain007.com

Re: Bug#787739: ITP: plip -- fully automated protein-ligand interaction profiler

[Geert Stappers]

On Fri, Jun 05, 2015 at 02:08:37PM +0200, Simon Richter wrote:
> On 05.06.2015 11:25, Alex Mestiashvili wrote:
> 
> >> This might be confusing to old people. PLIP is a protocol for
> >> transporting IP packets over the parallel port.
> 
> > I agree that the name is a bit ambiguous, but I see a couple
> > of reasons why it is still might be ok:
> 
> Yes, I also think it is probably okay -- I just wanted to mention that
> it might be confusing at first.

In other words: 

 'plip' is a good name for
  the "protein-ligand interaction profiler"



Groeten
Geert Stappers
-- 
Leven en laten leven


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150605130439.gs23...@gpm.stappers.nl

Facilitating external repositories

[Wouter Verhelst]

Hi,

At $DAYJOB, I'm maintaining a few repositories with ready-to-install
packages for a number of distributions[1]

Currently, the instructions[2] say to do the following:
- Download and install an "eid-archive" package, which contains the GPG
  keys and generates a sources.list.d file for the repository;
- Run "apt-get update";
- Install the "eid-mw" and/or "eid-viewer" packages.

This works, but it has a number of downsides:
- The second step, "run apt-get update", is often overlooked; this seems
  to be the case especially for users of Ubuntu, where the default
  handler for installing packages is the "Software Center", a GUI
  software management tool that doesn't have any UI element for doing
  (the equivalent of) apt-get update
- There is no trust path from your already-installed distribution to the
  "archive" package (yes, I did sign the gpg keys; no, I don't consider
  that enough).
- It still requires users to manually install packages.

I note that other third-party developers often provide a single debian
package that can be installed, where the binary package itself already
contains repository configuration that gets installed. This method
works for application software, but (as in my case) if the intent is to
provide a library that wants to support multiarch, this approach doesn't
work.

There is add-apt-repository, which presumably works, but:
- It doesn't solve the "trust path" issue for third-party repositories,
  (except, *maybe*, for PPA's, but that's Ubuntu, not Debian, so doesn't
  solve my problem)
- It doesn't remove the "manually install" requirement
- I don't believe it solves the "user didn't do the apt-get update"
  step, although I haven't checked in detail.

Do we have anything better, or should I try to come up with something
myself?

[1] specifically, https://files.eid.belgum.be/
[2] http://eid.belgium.be/en/using_your_eid/installing_the_eid_software/linux/

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Re: Invoking ‘init’ from an init.d script (Wheezy)

[Alexander Thomas]

On Wed, Jun 3, 2015 at 6:09 PM, Konstantin Khomoutov
 wrote:
>
> On Wed, 3 Jun 2015 17:26:21 +0200
> Alexander Thomas  wrote:
>
> [...]
> > The long story:
> >
> > We have a setup with multiple servers (running Wheezy). When booting,
> > the servers check whether updates are available on a master server. If
> > available, they are pulled in through a dist-upgrade. This
> > check/update needs to happen before any of the normal services are
> > started, to avoid the need of taking down everything and then starting
> > it back up after the update.
> [...]
>
> Wouldn't it be simpler to implement this check and update using
> initramfs hooks?  You could bind-mount /dev, /sys and /proc to
> the root filesystem, chroot there and run there a script which would
> check for updates, apply them, if any, and exit.  After that the system
> would just resume booting.


That would be an option, but it might still cause the same problem of
apt-get hanging as we currently experience when doing the update
before runlevel S.

We looked deeper into this and found out that apt-get always hangs
while installing a package before the first runlevel switch. An strace
reveals an endless loop of SIGCONT and ioctl calls. Running other
commands that use ioctl also results in a hang, so the controlling
terminal seems to lack certain capabilities at this stage. We have
found a workaround: we spawn a new terminal with agetty and run the
update script in there, this allows to perform the apt-get
dist-upgrade in runlevel S and avoid the init 1 hack.

--
Alexander


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cakr4ymwhfxxd2sxrbwgpnu6hlsubllcygo9ofv0z7rz5g7n...@mail.gmail.com

Re: Proposal v2: enable stateless persistant network interface names

[Marco d'Itri]

On Jun 05, "Milan P. Stanic"  wrote:

> Now, USB Ethernet interface (usb) and bridge (br0) have the same MAC.
This is not relevant, because virtual interfaces like br0 are not 
subject to renaming.

-- 
ciao,
Marco


pgpfCA5WWp_SS.pgp
Description: PGP signature

Re: Facilitating external repositories

[Josh Triplett]

Wouter Verhelst wrote:
> At $DAYJOB, I'm maintaining a few repositories with ready-to-install
> packages for a number of distributions[1]
> 
> Currently, the instructions[2] say to do the following:
> - Download and install an "eid-archive" package, which contains the GPG
>   keys and generates a sources.list.d file for the repository;
> - Run "apt-get update";
> - Install the "eid-mw" and/or "eid-viewer" packages.
> 
> This works, but it has a number of downsides:
> - The second step, "run apt-get update", is often overlooked; this seems
>   to be the case especially for users of Ubuntu, where the default
>   handler for installing packages is the "Software Center", a GUI
>   software management tool that doesn't have any UI element for doing
>   (the equivalent of) apt-get update
> - There is no trust path from your already-installed distribution to the
>   "archive" package (yes, I did sign the gpg keys; no, I don't consider
>   that enough).
> - It still requires users to manually install packages.

Given that the packages in question appear to be Free Software (at least
from a quick check of a couple of them, as well as the repository being
named "main"), is there a reason you don't maintain them in Debian
(including backports or volatile if you need to provide the newest
packages for older distributions)?

If that's not an option for some reason, then given that the packages
are Free Software and of reasonably broad interest, you could at least
upload a package to Debian containing the archive key, similar to
pkg-mozilla-archive-keyring; that would establish a trust path.  (Which
doesn't solve the usability problem, but it does solve the trust
problem.)

I don't think you can have a dpkg trigger run apt update, since dpkg
will typically be invoked under the apt lock.  However, a higher-level
package manager that doesn't support manual updates could probably learn
to do an update when sources.list{,.d/*} gets updated.

> I note that other third-party developers often provide a single debian
> package that can be installed, where the binary package itself already
> contains repository configuration that gets installed. This method
> works for application software, but (as in my case) if the intent is to
> provide a library that wants to support multiarch, this approach doesn't
> work.

And presumably factoring that out into a "common" package that other
packages depend on won't help, because then you don't have a single
installable package, so you go back to needing a repository.

> [1] specifically, https://files.eid.belgum.be/

Did you mean https://files.eid.belgium.be/  Because the URL you posted
doesn't work with https, and the http version looks shady.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150605161051.GA1471@jtriplet-mobl1

Bug#787854: ITP: dm-writeboost -- log-structured caching for Linux

[Dmitry Smirnov]

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

   Package name: dm-writeboost
Version: 1.0.1
Upstream Author: Akira Hayakawa 
License: GPL
URL: https://github.com/akiradeveloper/dm-writeboost
Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/dm-writeboost.git
Description: log-structured caching for Linux
 dm-writeboost is an OS-level IO controller that builds logs from in-coming
 writes (data and metadata) and then writes the logs sequentially similar
 to log-structured filesystem. As a further extension, dm-writeboost
 supports read-caching which also writes data sequentially.
 .
 This package provides DKMS kernel module for Linux Kernel 3.10+.

---

dm-writeboost highlights the following features:

 Durable: Any power failure can't break consistency because each log consists
 of data, metadata and the checksum of the log itself.

 Lifetime: Other caching software separates data and metadata (e.g. dm-cache)
 and therefore submits writes to SSD too frequently. dm-writeboost, on the
 other hand, submits only one writes for hundreds data and metadata so the SSD
 lives longer since SSD's liftime depends how many writes are submitted.

 Fast: Since the sequential write is the best I/O pattern for every SSD and
 the code base is optimized for in-coming random writes, the write performance
 is the best of all caching drivers including dm-cache and bcache.

-- 
Regards,
 Dmitry Smirnov.


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

Re: Invoking ‘init’ from an init.d script (Wheezy)

[Konstantin Khomoutov]

On Fri, 5 Jun 2015 16:25:21 +0200
Alexander Thomas  wrote:

[...]
> That would be an option, but it might still cause the same problem of
> apt-get hanging as we currently experience when doing the update
> before runlevel S.
> 
> We looked deeper into this and found out that apt-get always hangs
> while installing a package before the first runlevel switch. An strace
> reveals an endless loop of SIGCONT and ioctl calls. Running other
> commands that use ioctl also results in a hang, so the controlling
> terminal seems to lack certain capabilities at this stage. We have
> found a workaround: we spawn a new terminal with agetty and run the
> update script in there, this allows to perform the apt-get
> dist-upgrade in runlevel S and avoid the init 1 hack.

I would try running apt-get with somelogfile 2>&1
redirections: that should ensure it sees no terminal at all on its stdin
and that should avoid code paths dealing with TTY-related ioctls
altogether.  (Well, excluding the isatty(3) call which supposedly uses
fstat(2) and checks to see the device's major number is that of a TTY).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150605203938.fd1322f3bbf2bc4426c6f...@domain007.com

Re: Regarding text display issues

[Christian PERRIER]

Quoting Konstantin Khomoutov (flatw...@users.sourceforge.net):

> Now, let's do a more targeted search:
> 
> ~% apt-cache search task hindi
> task-hindi - Hindi environment
> task-hindi-desktop - Hindi desktop
> task-hindi-kde-desktop - Hindi KDE desktop
> 
> So I'd say task-hindi-desktop would be a safe bet for you.


Definitely.

Would you have installed in Hindi (which requires to use the graphical
installer), everythign would have been installed : fonts, Hindi
localization of important software, etc.

You may want to try joining this list: https://lists.debian.org/debian-dug-in/



signature.asc
Description: Digital signature

Re: devis flyers et dépliants

[Blandine Renard - Service commercial]

Pour visualiser correctement ce message, accèdez à la version en ligne.






FAITES BONNE IMPRESSION !.






250 cartes de
visite







1.000 flyers
format a6





250 dépliants
commerciaux





Copyright © 2009 Numerifives, All rights reserved.
77 rue Pierre Legrand, 59000 Lille France
Tél: 03.20.04.06.82
Website: www.numerifives.com



Pour cesser de recevoir nos informations sur l'adresse 
debian-devel@lists.debian.org



Re: Facilitating external repositories

[Osamu Aoki]

Hi,

On Thu, Jun 04, 2015 at 06:18:16PM +0200, Wouter Verhelst wrote:
> Hi,
> 
...
> Currently, the instructions[2] say to do the following:
> - Download and install an "eid-archive" package, which contains the GPG
>   keys and generates a sources.list.d file for the repository;
> - Run "apt-get update";
> - Install the "eid-mw" and/or "eid-viewer" packages.
> 
...
> 
> There is add-apt-repository, which presumably works, but:
> - It doesn't solve the "trust path" issue for third-party repositories,
>   (except, *maybe*, for PPA's, but that's Ubuntu, not Debian, so doesn't
>   solve my problem)
> - It doesn't remove the "manually install" requirement
> - I don't believe it solves the "user didn't do the apt-get update"
>   step, although I haven't checked in detail.

The add-apt-repository command is from the softwareproperties-common
package.  It has associated GUI packages.
 softwareproperties-kde
 softwareproperties-gtk

These allow you to import key manually and add repository.

I did not check for the manual addition of repository source case, but
when I added and removed the non-free archive via GUI, the "apt-cache
... " result changed indicating the GUI program run "apt-get update"
equivalent in the background.

I did not check if installation of key has dialogue for verifying its
authenticity... if not, adding such functionality may be what you need.

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150605231303.GA31034@goofy.local

Re: Facilitating external repositories

[Brian May]

On Sat, 6 Jun 2015 at 02:11 Josh Triplett  wrote:

> Given that the packages in question appear to be Free Software (at least
> from a quick check of a couple of them, as well as the repository being
> named "main"), is there a reason you don't maintain them in Debian
> (including backports or volatile if you need to provide the newest
> packages for older distributions)?
>

In my case I maintain open source software Debian packages outside of
Debian because the software is far to volatile (e.g. important bug fixes on
a weekly basis) and I don't want old versions hanging around any longer
then absolutely required. It is also a very narrow market, possibly not of
general interest to the Debian community (this is hard to determine
however; maybe what this needs right now is expanded exposure).

There was also the (slightly confusing) perception in management that they
had to tightly control ownership and distribution, despite it being open
source GPL software, available on github, etc.

I note the original poster mentioned Ubuntu PPAs and add-apt-repository; my
understanding is that these don't solve the trust issue, I seem to recall
the user is shown a fingerprint and asked to confirm it is correct (based
on what???) - however I don't have an Ubuntu box I can test this on right
now.

Bug#787889: general: USB keyboard stops working after a few seconds due to USB suspend

[Jesse Hallett]

Package: general
Severity: important

Dear Maintainer,

* What led up to the situation?

Upgraded packages on 2015-05-04. Upgrades included kernel update from 
3.16.0-4-amd64 to 4.0.0-1-amd64.

* What exactly did you do (or not do) that was effective (or
  ineffective)?

Attempted to use USB keyboard in, in Xorg and in virtual TTY.

* What was the outcome of this action?

There appeared to be no input from the keyboard. After disconnecting and 
reconnecting the keyboard it functioned; but after a period of seconds it 
consistently stopped working until it was disconnected and reconnected again.

* What outcome did you expect instead?

I expected keyboard input to work consistently.

* Is there a workaround?

I am able to work around the issue by overriding USB power management for the 
keyboard device:

cat on | sudo tee /sys/bus/usb/devices/3-1.2.2/power/level


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'stable-updates'), (500, 'stable'), 
(400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/8 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)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150606001946.16407.26331.reportbug@twonky

Re: Facilitating external repositories

[Paul Wise]

On Sat, Jun 6, 2015 at 8:13 AM, Brian May wrote:

> the software is far to volatile (e.g. important bug fixes on a weekly basis)

We have a place for such software: experimental

> I don't want old versions hanging around any longer then absolutely required

We have a place for such software: experimental

>. It is also a very narrow market, possibly not of
> general interest to the Debian community (this is hard to determine however;
> maybe what this needs right now is expanded exposure).

We have a lot of obscure software in Debian already, the size of the
audience shouldn't matter.

> There was also the (slightly confusing) perception in management that they
> had to tightly control ownership and distribution, despite it being open
> source GPL software, available on github, etc.

We probably shouldn't distribute it if upstream doesn't want us to though.

> I note the original poster mentioned Ubuntu PPAs and add-apt-repository; my
> understanding is that these don't solve the trust issue, I seem to recall
> the user is shown a fingerprint and asked to confirm it is correct (based on
> what???) - however I don't have an Ubuntu box I can test this on right now.

I would guess based on the OpenPGP web of trust or the user's trust in
their OS that trusts the SSL CA that signed the Launchpad certs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/
http://wiki.openmoko.org/wiki/User:PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gw_fsko464vsqyncn_5bopn6o5m2u7fdwvj4p+scq...@mail.gmail.com

Bug#787898: ITP: fonts-pt -- PT (Public Type) fonts are free TrueType cyrillic fonts

[Relli054w]

Package: wnpp
Severity: wishlist
Owner: Relli054w 

* Package name: fonts-pt
  Version : 1.0
  Upstream Author : Aleksandra Korolkova (design) 
, Olga Umpelova (design) 
, Vladimir Yefimov (supervision), Isabella Chaeva 
(design)
* URL : http://www.paratype.com/public/
* License : OFL-1.1 or ParaType-1.3 
(http://www.paratype.com/public/pt_openlicense_eng.asp)
  Description : PT (Public Type) fonts are free TrueType cyrillic fonts

The Public Type or PT Fonts
are a family of free fonts,
released from 2009 onwards,
comprising PT Sans, PT Serif and PT Mono.
The latest version released in 2014.
They were commissioned
from the design agency ParaType by Rospechat,
a department of the Russian Ministry
of Communications, and Google
to form a font family
that supported all the different variations
of Cyrillic script used
by the minority languages of Russia,
as well as the Latin alphabet.
The main aim of the project
is to give possibility to the peoples of Russia
to read and write on their native languages.

The source package
will contains *.ttf files and
will produce the following
binary packages:
 - fonts-pt-sans;
 - fonts-pt-serif;
 - fonts-pt-mono and
 - metapackage fonts-pt
   that includes all of the above.

Similar bug:
https://bugs.launchpad.net/ubuntu/+bug/572061


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150606062759.6425.23400.reportbug@localhost