Re: YAGF is a seriously screwed package

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jul 10, 2015 at 12:20:16PM +0530, Susmita/Rajib Bandopadhyay wrote:
> Dear Sir,
> Bug, what bug? The program is itself screwed. :-)
> However a bug report has been sent, as directed.
> Acknowledgement:
> 
> #792015

Thanks!

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWfcG0ACgkQBcgs9XrR2kbZTgCfY1a3PmJ+aMOn78zp9JEIUxki
rOgAn1eO0NRjTwcA9CwaZNlNcjGBEnh0
=QDld
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150710071245.ga3...@tuxteam.de

Re: ISS is running GNU Linux Debian :)

[tomas]

On Thu, Feb 10, 2022 at 10:45:42PM +, Wookey wrote:
> On 2022-02-10 21:39 +0100, dude wrote:
> >  International Space Station adopts Debian Linux, drops Windows & Red Hat 
> > into
> >   airlock X-D
> > 
> >
> > https://www.computerweekly.com/blog/Open-Source-Insider/International-Space-Station-adopts-Debian-Linux-drops-Windows-Red-Hat-into-airlock
> 
> Or at least was in 2013/4.

A bit newer (2016), but by far not current:

  
https://space.stackexchange.com/questions/13539/which-operating-systems-is-the-international-space-station-running

(The nice part about this internet thing is that there are search
engines -- no, not Google, use that other one ;-)

The answer is, as always, more nuanced. The question "which OS is the
ISS running" is so naïve as the question "which kind of cell is your
organism made of". Well, duh, many kinds, of course :-)

The ISS is up there since 1998. Computers have changed a bit since
then. And then, you have life support systems, steering and navigation,
tons of scientific instruments and yes, probably entertainment, too.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[tomas]

On Sat, Mar 08, 2025 at 02:51:29PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> Hi,
> 
> Quoting Simon Josefsson (2025-03-08 13:43:26)
> > My point was that there is no reasonable way to gain confidence about
> > security properties of any piece of non-free microcode.  Everyone can now
> > produce AMD microcode that corrupts your machine in advanced ways that evade
> > detection, but we don't know if such malicious corruption is included in the
> > official microcode.  Having source code for the microcode would help gain
> > confidence in it, and is the reasonable request.  If the request is denied, 
> > I
> > would consider the vendor not trustworthy and look into options.
> 
> I do not understand something about this argument.
> 
> If you don't trust the vendor, then it makes no difference whether or not new
> official firmware/microcode can be uploaded/flashed or not. If you don't trust
> the vendor, then the initial microcode that came with your device might 
> already
> be doing things that go against your interests.

Trust in wendors (actually also their trustworthiness) is a function of
time. Remember when Github was bought by Microsoft? Remember when Twitter
was bought by -- uh -- whatever?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Xsession doesn't use umask setting from /etc/login.defs

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alban browaeys skrev:
| In october you told:
|
|> Searching Google for "xsession umask" will give you some hints.
|>
|>
|>
|>> /etc/login.defs explicitly indicates that it is
|>> "Configuration control definitions for the login package",
|>> and many of its parameters are inapplicable to display
|>> managers, or already implemented in parallel (e.g., how long
|>> do wait after a failed login before displaying the
|>> prompt/greeter again?).
|
|
|> I believe that /etc/login.defs _is_ the right place to define
|> the default umask property.
|
|
| I strongly disagree. Google is not a reference by itself and the
| few example (gdm and kde session scripts) have been fixed (gdm no
| longer import login.defs) upstream or are mere hints for the
| user to have a quick fix (kde Xsession hacks).
I'm glad to hear that gdm and kdm have been fixed. And how does
these fixes improve the issue of a reasonable default umask?
| Though login.defs is still sourced by "login" program, half of
| its settings are already overridden by pam defaults one. The few
| remaining usefull one (ENV_PATH ENVSU_PATH mostly) are overriden
| by most shell "profile" too because they disagree with it.
PAM is good. The fact remains, it doesn't handle default umask.
| It confuse beginners who read manual carefully and up wondering
| why their settings are not working. The sooner it it emptied of
| system wide environment settings the better.
So exactly where, according to you, is the proper place for a system
wide default umask property, if not /etc/login.defs?
Regards
- --
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCD89wwYdzVZ/o1QQRAt3ZAJ0crhms5ydte0zEL8am+OHyxlELzgCfXi8O
nJHVLsLr7eiLuFcMYUXF88U=
=9Afz
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: krb5: ABI Issue--confirm your packages work against 1.4.3 in experimental

[Tomas Pospisek]

On Sat, 19 Nov 2005, Sam Hartman wrote:


I'd appreciate it if you would take the time to see if your package
works against the new Kerberos library.  The easiest way to do this is
to build your package or at least the kerberos using parts of your
package against the new libkrb5-dev package and confirm there are no
warnings about missing prototypes and that your package can
successfully link to libkrb5.


Mailsync at least links fine against the new libkrb5. Since I don't have 
access to a kerberos environment I however can't test if it also does

fine at runtime.

Thanks,
*t

--
----
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

New maintainer for rdesktop

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello

My name is Tomas Fasth and I'm a Debian Developer. I just recently
made a Non Maintainer Upload of rdesktop version 1.4.0. This was
done with the explicit consent from Sam Johnston, the current
maintainer.

Sam indicated in a letter to me that he had little time, if any, to
maintain the rdesktop package. Since I have personal interest in
this package, and time to maintain it, I made an offer to take over
the maintainership, and he accepted.

If anyone on this list disagree, please respond.

Regards,
- --
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCXveYwYdzVZ/o1QQRAisNAKCQhAZAQUrDZbO6uDgG4ZA78pZwQACcCZB1
yeBYHz88o0gBb+eXJy6xF4I=
=EodP
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#307412: ITP: dbxml -- a native XML database

[Tomas Fasth]

Package: wnpp
Severity: wishlist
Owner: Tomas Fasth <[EMAIL PROTECTED]>

* Package name: dbxml
  Version : 2.0.9
  Upstream Author : Sleepycat Software <[EMAIL PROTECTED]>
* URL : http://www.sleepycat.com/download
* License : Sleepycat License, BSD compatible
  Description : a native XML database

Berkeley DB XML is a native XML database. Berkeley DB
XML is a library that provides access into a database
of document containers using either XQuery or XPath.
XML documents are stored and indexed in their native
format using Berkeley DB as the transactional database
engine.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-co-0.6.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312580: ITP: sdparm -- Display or change SCSI device parameters

[Tomas Fasth]

Package: wnpp
Severity: wishlist
Owner: Tomas Fasth <[EMAIL PROTECTED]>

* Package name: sdparm
  Version : 0.93
  Upstream Author : Douglas Gilbert 
* URL : http://sg.torque.net/sg/sdparm.html
* License : GPL / FreeBSD
  Description : Change and display SCSI device parameters

The sdparm utility outputs and in some cases modifies SCSI device parameters.
It can be used to output and modify parameters on any device that uses a SCSI
command set. Apart from SCSI disks, such devices include CD/DVD drives
(irrespective of transport), SCSI and ATAPI tape drives and SCSI enclosures.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-co-0.6.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Postgres removing old database

[Tomas Berndtsson]

Recently, I upgraded from Postgres 6.5.3 (stable Debian) to Postgres
7.0 (unstable). During the installation, it didn't ask me anything,
besides overwriting the config files. Instead it gladly removed all my
databases which were in /var/lib/postgres/data/base/.

Luckily, I had made a dump myself, prior to the upgrade, so there was
no problem getting them back, but it would've been a good idea to have
it dump and restore the databases itself. I can remember an older
upgrade of postgres (6.0 -> 6.5 perhaps?) doing just this, so I wonder
why this didn't.


Tomas

Draw font with different size

[Tomas Kratochvil]

Hello,
  could you help me, please. I wrote X aplication which draw text into
window. How could I draw text with different font size? I`m able only
use fonts which are in font.aliases. And I want to draw text with size
50, 54, 60,...


// this way I do it now.
// init font
font1 = XLoadQueryFont(display,"*-helvetica-*-12-*"); 
font2 = XLoadQueryFont(display,"*-helvetica-*-18-*"); 
font3 = XLoadQueryFont(display,"*-helvetica-*-24-*"); 

// draw text 
void Win::DrawText(int x, int y, char *text, char *col, int fnt)
{
XFontStruct *ft;

if (fnt==FONT_SMALL) ft = font1; else
if (fnt==FONT_MEDIUM) ft = font2; else ft = font3;

XSetForeground(display, gc, get_color(col));

XSetFont(display, gc, ft->fid);
XDrawString(display, buffer, gc, x, y+ft->ascent, text, strlen(text));
} 

Regards,

Tomas

Re: fresh blood gets congested: long way to become DD

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas Barth skrev:
> * Thijs Kinkhorst ([EMAIL PROTECTED]) [050802 13:41]:
> 
>>And even then, appearently the DAM works like this: I approve person X,
>>let's check his box, but I'll add the account at some point later on (this
>>takes weeks on average). When you check the box you might add the account
>>aswell when you're at it, right?
> 
> 
> Just that the person who checks the reports is not root in Debian's ldap
> system.

There is delegation and group access available in OpenLDAP. So, one
would not need to have write access to the whole directory tree,
only to the necessary branches. Also, this could very well be
handled the same way as .commands on ftp-master.d.o, that is, by
requiring valid signatures of ldap commands in ldif format from a
limited number of people operating on a restricted part of the ldap
tree.

Just a thought, no flames please :)

// Tomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC726ywYdzVZ/o1QQRAv8tAJ9gBsOJ6j+xqL1wR1ezmtsnnzFxvgCfaKFE
zy5shd7inv3al0LliXc6XcY=
=hUtq
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

building own package

[Tomas Davidek]

Hello,
 I am trying to build my own package (containing only few shell 
scripts) to make easier the system maintainance specific to our 
department. I followed the instruction in the Debian New Maintainer's 
Guide, but I probably misunderstood something, since I have the 
following problems:


* I store all the scripts in a tarball, so all I have to do is to unpack 
them in the respective directory during the "make install" stage (i.e. 
no compilation is needed). I succeeded to do so by introducing  the 
following Makefile:

-
clean:
   rm -fr debian/ucjf-security

install:
   cd $(DESTDIR) ; \
   tar -xvzf ../../../ucjf-security_1.0.1.orig.tar.gz 
--
It works, however I would expect that the path to a tarball can be 
specified in a better way (is there any variable containing the top 
directory name ?). Also, the version should not be hardcoded there, I 
guess. Is there a way to tell the Makefile to use the latest 
version/same version as is the name of the working directory ?


* since the pakcage contains only few shell scripts, it should be 
architecture-independent. Therefore, I specified "Architecture: any" in 
the "control" file and also moved all the action in the "rules" file 
into the binary-indep section (see attachment) However, the 
resulting package still contains in its control file the item 
"Architecture: i386" (which is where the package is produced, but ).


* the script don't have any config file, therefore I didn't introduce 
the "conffiles" in the debian directory. However, the resulting package 
contains in its conffiles the first file of the tarball. Is there a good 
reason for that ? How do I get rid off this feature ?


* the man pages installation works pretty well, the only problem is that 
the mandb is not updated after the package installation. It means user 
can display the new manpage, but "man -k" does not find it. One would 
need to run mandb automatically - should this be done via postinst 
(postrm) scripts or is there a simpler way to do so ?


Thanks a lot for any hint,

best regards
  Tomas

E-mail : [EMAIL PROTECTED],
  [EMAIL PROTECTED]

#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on verbose mode.
export DH_VERBOSE=1




CFLAGS = -Wall -g

ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif

configure: configure-stamp
configure-stamp:
dh_testdir
# Add here commands to configure the package.

touch configure-stamp


build: build-stamp

build-stamp: configure-stamp 
dh_testdir

# Add here commands to compile the package.
$(MAKE)
#docbook-to-man debian/ucjf-security.sgml > ucjf-security.1

touch build-stamp

clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp

# Add here commands to clean up after the build process.
-$(MAKE) clean

dh_clean 

install: build
dh_testdir
dh_testroot
dh_clean -k 
dh_installdirs

# Add here commands to install the package into debian/ucjf-security.
$(MAKE) install DESTDIR=$(CURDIR)/debian/ucjf-security


# Build architecture-independent files here. Everything here, since we have
# just set of scripts:
binary-indep: build install
dh_testdir
dh_testroot
dh_installchangelogs 
dh_installdocs README TODO
dh_installexamples
#   dh_install
#   dh_installmenu
#   dh_installdebconf   
#   dh_installlogrotate
#   dh_installemacsen
#   dh_installpam
#   dh_installmime
#   dh_installinit
#   dh_installcron
#   dh_installinfo
dh_installman ucjf-security.8
dh_link
dh_strip
dh_compress
dh_fixperms
#   dh_perl
#   dh_python
#   dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb

# Build architecture-dependent files here.
binary-arch: build install
# We have nothing to do by default.

binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure

Re: fresh blood gets congested: long way to become DD

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Langasek skrev:
> On Tue, Aug 02, 2005 at 03:01:39PM +0200, Tomas Fasth wrote:
>> Andreas Barth skrev:
>>> * Thijs Kinkhorst ([EMAIL PROTECTED]) [050802 13:41]:
>>>> And even then, appearently the DAM works like this: I
>>>> approve person X, let's check his box, but I'll add the
>>>> account at some point later on (this takes weeks on
>>>> average). When you check the box you might add the account 
>>>> aswell when you're at it, right?
>>> Just that the person who checks the reports is not root in
>>> Debian's ldap system.
>> There is delegation and group access available in OpenLDAP. So,
>> one would not need to have write access to the whole directory
>> tree, only to the necessary branches.
> I'm amused that you think there's anything in Debian's LDAP
> directory *besides the user accounts themselves that you're
> proposing to give people access to* that would warrant this level
> of granular access control.

I'm equally amused that you think there isn't.

[EMAIL PROTECTED]:~$ ldapsearch -x objectclass=* | grep dn: | cut -d ' '
- -f 2- | sort | uniq -t = -W 1
cn=LDAP Administrator,ou=users,dc=debian,dc=org
dc=debian,dc=org
gid=Debian,ou=users,dc=debian,dc=org
host=auric,ou=hosts,dc=debian,dc=org
ou=hosts,dc=debian,dc=org
uid=93sam,ou=users,dc=debian,dc=org

Thijs suggested to allow the DAM to create the account directly
instead of just passing the stick on to yet another person causing
yet more delays. You were implying that it can't be done without
root access which I interpreted as giving write access to the whole
database. My assertion was that it can be done by giving DAM write
access to a specific branch in the tree, in this case the
"ou=users,dc=debian,dc=org" branch.

If it can be done and you just refuse do do it that way then say so
instead of expressing amusement based on unfair generalisations.

And if you feel uncomfortable to give DAM write access to
ou=users,dc=debian,dc=org directly, then let DAM create new accounts
in a sandbox node from where entries can be moved to the right
place by a cron script that can be programmed to make sure no
existing accounts is tampered with.

- --
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC8KLjwYdzVZ/o1QQRApcRAJ4l4Pct4DdYI1X0ccrEkFCRrKq+ggCfbR5F
vFNBPPdDTlpFAQI0ksRUsRs=
=lv/i
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: building own package

[Tomas Davidek]

Hello again,
 thanks to all who replied to my previous mail. Using your advice I 
solved/correct all the problems/bugs, but still there is one thing I 
don't understand:


Lionel Elie Mamane wrote:


On Wed, Aug 03, 2005 at 11:21:35AM +0200, Tomas Davidek wrote:
 


* I store all the scripts in a tarball,

   


If you are using the .orig.tar.gz directly, you have misunderstood the
structure of a Debian source package: The .orig.tar.gz is unpacked,
the tree is patched with the .diff.gz and then one builds / installs
entirely from there.

You may actually want to do a "Debian native" package that has only a
.tar.gz and no .diff.gz.
 

Yes, this is exactly the problem - the *.orig.tar.gz should be unpacked, 
but apparently it is not. When I have in my makefile:

.
install:
 cp -a usr $(DESTDIR)/usr
.
it fails with the error message:
--
# Add here commands to install the package into debian/ucjf-security.
/usr/bin/make install 
DESTDIR=/home/davidek/debian/ucjf-security-1.0.2/debian/ucjf-security

make[1]: Entering directory `/home/davidek/debian/ucjf-security-1.0.2'
cp -a usr /home/davidek/debian/ucjf-security-1.0.2/debian/ucjf-security/usr
cp: cannot stat `usr': No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/davidek/debian/ucjf-security-1.0.2'
make: *** [install] Error 2
-
Someone of you mentioned that it should be debian/rules script that 
unpacks the .orig.tar.gz. I tried to issue the commands one-by-one, but 
none of them unpacked the orig tarball. BTW, should it be unpacked into 
/home/davidek/debian/ucjf-security-1.0.2 (see above) or somewhere else ?


I probably miss something in the debian/rules (attached), the full 
output of dpkg-buildpackage -rfakeroot is also attached.


Thanks a lot for help,

best regards

  Tomas

E-mail : [EMAIL PROTECTED],
  [EMAIL PROTECTED]

dpkg-buildpackage: source package is ucjf-security
dpkg-buildpackage: source version is 1.0.2-1
dpkg-buildpackage: source maintainer is Tomas Davidek <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture is i386
 fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
#-/usr/bin/make clean
dh_clean 
rm -f debian/ucjf-security.substvars
rm -f debian/ucjf-security.*.debhelper
rm -rf debian/ucjf-security
rm -f debian/files
find . -type f -a \( -name \#\*\# -o -name .\*\~ -o -name \*\~ -o -name 
DEADJOE -o -name \*.orig -o -name \*.rej -o -name \*.bak -o -name .\*.orig -o 
-name .\*.rej -o -name .SUMS -o -name TAGS -o -name core -o \( -path 
\*/.deps/\* -a -name \*.P \) \) -exec rm -f {} \;
rm -rf autom4te.cache
 dpkg-source -b ucjf-security-1.0.2
dpkg-source: building ucjf-security using existing 
ucjf-security_1.0.2.orig.tar.gz
dpkg-source: building ucjf-security in ucjf-security_1.0.2-1.diff.gz
dpkg-source: warning: ignoring deletion of directory sbin
dpkg-source: warning: ignoring deletion of file sbin/hledej_skodice
dpkg-source: warning: ignoring deletion of file sbin/ipt-skodici
dpkg-source: building ucjf-security in ucjf-security_1.0.2-1.dsc
 debian/rules build
dh_testdir
# Add here commands to configure the package.
touch configure-stamp
dh_testdir
# Add here commands to compile the package.
#/usr/bin/make
#docbook-to-man debian/ucjf-security.sgml > ucjf-security.1
touch build-stamp
 fakeroot debian/rules binary
dh_testdir
dh_testroot
dh_clean -k 
rm -f debian/ucjf-security.substvars
rm -f debian/ucjf-security.*.debhelper
rm -rf debian/ucjf-security
find . -type f -a \( -name \#\*\# -o -name .\*\~ -o -name \*\~ -o -name 
DEADJOE -o -name \*.orig -o -name \*.rej -o -name \*.bak -o -name .\*.orig -o 
-name .\*.rej -o -name .SUMS -o -name TAGS -o -name core -o \( -path 
\*/.deps/\* -a -name \*.P \) \) -exec rm -f {} \;
rm -rf autom4te.cache
dh_installdirs
install -d debian/ucjf-security
install -d debian/ucjf-security/usr/sbin
# Add here commands to install the package into debian/ucjf-security.
/usr/bin/make install 
DESTDIR=/home/davidek/debian/ucjf-security-1.0.2/debian/ucjf-security
make[1]: Entering directory `/home/davidek/debian/ucjf-security-1.0.2'
cp -a usr /home/davidek/debian/ucjf-security-1.0.2/debian/ucjf-security/usr
cp: cannot stat `usr': No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/davidek/debian/ucjf-security-1.0.2'
make: *** [install] Error 2
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on v

fakeroot: line 152: 7689 Segmentation fault

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello

I noticed the following problem with the build daemon on the hppa
architecture:

dpkg-source: extracting sqlite3 in sqlite3-3.2.2
dpkg-buildpackage: source package is sqlite3
dpkg-buildpackage: source version is 3.2.2-3
dpkg-buildpackage: host architecture hppa
 /usr/bin/fakeroot debian/rules clean
/usr/bin/fakeroot: line 152:  7689 Segmentation fault
FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@"

Is this a known problem?
Does it require any further action by me?

Thanks
- --
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+TKxwYdzVZ/o1QQRAmXMAKCOwGrO+xBpAVfoYq2Q4fkGFTg1VACfSgd4
s1bFB6rHG11bQliKekHTeuc=
=IQ75
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#324354: ITP: libpathan -- open source implementation of the W3C XPath 2 specification

[Tomas Fasth]

Package: wnpp
Severity: wishlist
Owner: Tomas Fasth <[EMAIL PROTECTED]>

* Package name: libpathan
  Version : 2.0beta
  Upstream Author : DecisionSoft Limited <[EMAIL PROTECTED]>
* URL : http://software.decisionsoft.com/pathan2Info.html
* License : BSD
  Description : Open source implementation of the W3C XPath 2 specification

Pathan 2 is a code library implemented in C. It uses the Xerces-C DOM
XML parser by the Apache Foundation and hence can be used in concert
with Xerces-C to provide Path functionality in 3rd party software.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-co-0.6.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using buildds only

[Tomas Fasth]

Martin Pitt skrev:
> Hi Wouter!
>
> Wouter Verhelst [2005-08-23  1:26 +0200]:
>
>>So you suggest throwing buildd out of the window and switching to
>>pbuilder, then?
>
>
> Something like this is in fact considered. Probably Ubuntu won't use
> pbuilder itself since it is not the most efficient implementation
> around, but rebuilding the buildd chroots from scratch would help to
> eliminate many FTBFS bugs due to polluted chroots.

I find your statement about pbuilder and efficiency interesting.
Would you care to explain what you mean?

As a side note, I have myself thought about extending pbuilder using
unionfs and overlays to avoid the tarball extraction for each build.

--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504


signature.asc
Description: OpenPGP digital signature

update of (several) config files

[Tomas Davidek]

Hello,
 I am trying to set up a tool for easy update of several computers in 
our institute. For example, I would like to create a package that 
updates several config files, e.g. /etc/apt/sources.list etc.

What is the best way of doing that ?

So far I think about an package that only contains a pre-install, 
post-install, pre-remove and post-remove scripts. These scripts would 
then add/remove certain lines from the config files and run updates. Is 
this the right way or is there better way how to proceed ?


Thanks a lot,

best regards

  Tomas

E-mail : [EMAIL PROTECTED],
  [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using buildds only

[Tomas Fasth]

Martin Pitt skrev:
> Hi Tomas!
>
> Tomas Fasth [2005-08-23  9:31 +0200]:
>
>>As a side note, I have myself thought about extending pbuilder using
>>unionfs and overlays to avoid the tarball extraction for each build.
>
>
> Indeed I referred to the overhead of tarball extraction and the like.
> unionfs is a great idea, do you plan to integrate this into the
> main pbuilder package? This would really rock. :)

The idea came to me just recently. I have no written code or patch
for pbuilder yet, and I have barely started to familiarize myself
with unionfs in general. I would definitely like to have such a
feature in pbuilder, so yes, integration is the preferred way to go.
If I manage to produce some working code I will post a patch for
pbuilder through BTS.

--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504



signature.asc
Description: OpenPGP digital signature

How can I build a package from source that require the source of another (library) package?

[Tomas Fasth]

Hello fellow developers, I have a problem on which I need advice.

Pathan is a library that implements XPath functionality in c++. It
is available both as a separate tarball as well as bundled with the
Berkeley DB XML sources provided by Sleepycat Software. The pathan
build script require a path to the xerces source code tree. I have
tried to find a way to build the pathan library without providing
the xerces source but failed.

Is there anything I can do to work around this source dependency?

I can always give up the idea of an independent build of the pathan
library and ship it as part of dbxml where the source include both
pathan and xerces (and berkeley db, and xquery; in the same source,
sic; talk about bloat).

Any advice is welcome.

--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504


signature.asc
Description: OpenPGP digital signature

Re: How can I build a package from source that require the source of another (library) package?

[Tomas Fasth]

The Fungi skrev:
> On Fri, Sep 16, 2005 at 09:34:30PM +0200, Tomas Fasth wrote:
> [...]
>
>>Pathan is a library that implements XPath functionality in c++. It
>>is available both as a separate tarball as well as bundled with the
>>Berkeley DB XML sources provided by Sleepycat Software. The pathan
>>build script require a path to the xerces source code tree. I have
>>tried to find a way to build the pathan library without providing
>>the xerces source but failed.
>
> [...]
>
> Can you intead build-depend on libxerces26-dev and give it the path
> to the headers that package installs?

Well, I can and already do. But it doesn't make a difference because
pathan has been programmed to depend on the xerces source, not the
exported library interface. For example, this is how the compiler
error looks like:

In file included from NamespaceAxis.cpp:14:
../dom-extensions/impl/XPathNamespaceImpl.hpp:12:44:
xercesc/dom/impl/DOMNodeImpl.hpp: No such file or directory
In file included from NamespaceAxis.cpp:14:
../dom-extensions/impl/XPathNamespaceImpl.hpp:24:
error: syntax error before `;' token

--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504


signature.asc
Description: OpenPGP digital signature

Re: What happened to Agnula.org (DeMuDi)?

[Tomas Nykung]

RalfGesellensetter wrote:

> 
> Maybe I'd rather go for the Suse Multimedia Live CD.
>
ftp://ftp.suse.com/pub/suse/i386/live-cd-9.2/SUSE-Linux-9.2-LiveCD-Audio.iso

This is OT for this mailinglist, but...

DeMuDi is dead, SUSE 9.2 is antique and AFAIK not security supported
anymore.

I would recommend you to try out 64Studio.
http://64studio.com

It's based on Debian testing (Etch).
Note that there is both a 64 bit and a 32 bit version available, be
sure to download the correct version for your hardware if you
decide to try it.


Tomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What happened to Agnula.org (DeMuDi)?

[Tomas Nykung]

(Hope that I'm not breaking the threading, I'm not subscribed to Debian
devel, and if I reply through gmane as I did before, then
debian-custom@lists.debian.org vill not be CC:ed and I'm trying to
respect your wish to CC that list.)


Andreas Tille wrote:

> On Tue, 13 Mar 2007, Tomas Nykung wrote:
>
>> DeMuDi is dead,
>
> H, well, what exactly means dead?

It's not developed anymore (at least not for now).


> I did not dived into the
> DeMuDi project personally, but besides producing ISO images ready
> to install my impression was that the people connected to that
> project are busy integrating audio related software into Debian
> and try to care about a general audio infrastructure.  This
> effort belongs to the scope of Custom Debian Distributions and
> thus the relevant list is in CC.

We have the impression about what DeMuDi was then :)


>> I would recommend you to try out 64Studio.
>> http://64studio.com
>
> Well, so far for your recommendation.  My personal recommendation
> would
> be that somebody who is interested in multimedia in Debian would try
> to contact the people behind 64studio.com and explain them the
> advantage
> they could gain if they would try to continue what DeMuDi started
> or to work together with the DeMuDi people.

Well, Free Ekanayaka was the main developer behind DeMuDi, and he is the
main developer behind 64 Studio, no need for him to contact himself :)
He is also an Debian developer working with improving multimedia
support in Debian.

The reason I recommended 64 Studio to the OP was simply that I don't
think it's a good idea to install an ancient version of SuSE when there
are IMHO better and supported alternatives around, for example 64
Studio.

The reason I didn't recommend the OP to install Etch is that Etch is not
ready for multimedia out of the box, most importantly there is no real
time enabled kernel in stock Etch, and that is a _must_ when working
with real time audio (latency).
It's of course possible to patch and compile the kernel oneself, and
tweak the installation until it works for an audio studio or whatever,
but it's a lot of fiddling around and Free has already done this with 64
Studio, so why not use it? :)

I was myself an DeMuDi user, and my multimedia system is still based on
that DeMuDi install, but I have upgraded to Debian Etch, so there is not
much left on the system from DeMuDi anymore.

(As a side note, I'm using Sarge on my other computers, so I'm a living
proof that there really are people out there in the real world that are
using Debian stable :)

I haven't tried 64 Studio myself, but based on my experience with
DeMuDi, and knowing that it's basically the same guys behind 64 Studio
(Free) I think it must be good enough for me to dare recommend people to
at least try it.

64 Studio is also based on Debian, and fully compatible (AFAIK) as
DeMuDi also was, so it's possible to install packages from Etch on 64
Studio. In fact being lazy as I am, I'm running the 2.6.19 realtime
enabled kernel from 64 Studio on my DeMuDi / Etch system and it works
great :)


> If needed I might seek
> for some examples where I did so when DeMuDi was "farer away" from
> Debian.
> If the 64studio.com people would learn this lession they might
> increase their chances that after a couple of years a mail pops
> up saying "64studio.com is dead, use XYZ instead".  It would be
> so good if people would try to work together with Debian for
> their own profit.

Well, Free is as I already mentioned an Debian developer, so he is
obviously working with Debian already.

In my view 64 Studio _is_ Debian, tweaked out of the box for multimedia
use + commercial support if you need/want it.



Regards
Tomas Nykung

(Please CC me, I'm not subscribed)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Xsession doesn't use umask setting from /etc/login.defs

[Tomas Fasth]

Branden Robinson wrote:
[Redirecting to debian-devel; followups set.]
On Mon, Sep 20, 2004 at 02:29:32PM +0200, Wouter Hanegraaff
wrote:
Hi,
After a fresh sarge install, I'm having problems with umask
settings. In /etc/login.defs I set umask to 002, and that works
for logging in on the console or remote via ssh. However, if I
use {g,x,k}dm I keep getting an umask of 022, because Xsession
is started by the display manager which has a default umask of
022.
It seems that Xsession doesn't change the UMASK at all. Should
it do so? If not, which program should set the umask during a
graphical login?
Searching Google for "xsession umask" will give you some hints.
/etc/login.defs explicitly indicates that it is "Configuration
control definitions for the login package", and many of its
parameters are inapplicable to display managers, or already
implemented in parallel (e.g., how long do wait after a failed
login before displaying the prompt/greeter again?).
I believe that /etc/login.defs _is_ the right place to define the
default umask property.
// Tomas
--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504

Re: Xsession doesn't use umask setting from /etc/login.defs

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Branden Robinson wrote:
| On Thu, Oct 14, 2004 at 12:14:58AM +0200, Tomas Fasth wrote:
[...]
|> I believe that /etc/login.defs _is_ the right place to define
|> the default umask property.
|
| It feels wrong to me to make display managers selectively parse
| the configuration file of a different piece of software for
| configuration parameters that might be of interest to them.
However, umask is not an ordinary software configuration property,
it's a process property initially inherited from init which, by the
way, set it to 022 (I just checked the source of sysvinit in unstable).
Now, I can understand that an administrative domain need to change
the default value of umask according to site policy. What I don't
understand is why you think the umask preference should be applied
differently depending on the type of interface the user choose to
initiate an interactive session with.
In order to achieve good interoperability there should be a backward
compatibility requirement for display managers to adhere. I also
think text terminal logins as well as graphical equivalents should
all have the same source of default process and environment
properties. If you agree that there should be a common source for
this information, but do not agree that login.defs file and passwd
GECOS field extension (the latter which can be provided by other
sources, like LDAP) is acceptable as source, then what do you
suggest we use instead?
| $ man 5 login.defs
|
| No mention of X Window System display managers there.
|
| Huh, well...
|
| BUGS Much of the functionality that used to be provided by the
| shadow password suite is now handled by PAM.  Thus,
| /etc/login.defs is no longer used by programs  such  as login(1),
| passwd(1) and su(1). Please refer to the corresponding PAM
| configuration files instead.
|
| Maybe that's the direction we should head?
I think the key word here is "Much", meaning "Not all". And the
assertion that /etc/login.defs is no longer used by programs such as
login is not accurate, at least not according to "The Source" (tm).
It may be so in the future, but not for the time being.
// Tomas
- --
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBcQXbwYdzVZ/o1QQRAh3OAJ9k+tU2m4Lqxp6V4j6ZPAH5P5N/GwCfWsrc
pklh+ry/fCweLMcBSPXgGe4=
=Czmv
-END PGP SIGNATURE-

Re: Xsession doesn't use umask setting from /etc/login.defs

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Branden,
Branden Robinson wrote:
| On Sat, Oct 16, 2004 at 01:28:31PM +0200, Tomas Fasth wrote:
|
|> What I don't understand is why you think the umask preference
|> should be applied differently depending on the type of
|> interface the user choose to initiate an interactive session
|> with.
|
|
| I don't.  Kindly stop putting words in my mouth, and re-read my
| original mail.  If you can discuss this subject without indulging
| yourself in straw-man attacks like this, please follow-up with a
| more reasonable message.
I have re-read your mail and I beg you for pardon. I was wrong.
| And, by the way: X-No-CC: I subscribe to this list; do not CC me
| on replies.
I'm very sorry but I'm not perfect. My earlier reply did not cc:
you. Could you please wait for it to happen a second time in the
same thread before complaining? You seem a bit touchy about it.
I found the following when I was googling for X-No-CC:
~ From: Stepan Kasal
~ Subject: Re: Paragraph indentation suppression
~ Date: Tue, 8 Apr 2003 10:00:55 +0200
[...]
~ PS: I'm not sending cc to the original poster, as I'm scared by
~ this: X-No-CC: If you CC me on this list, I will feed you to
~ Branden Robinson. (It seems that Karl has already been fed.)
I couldn't but smile. "Oh no, please have mercy, don't feed me to
Branden!" Poor Karl :)
| Please get an MUA that respects Mail-Copies-To:.
Thanks for the advice, but I prefer Firefox for the time being. I
may try to persuade the Mozilla people to accept a patch. Can you
give me a reference to a RFC-draft or something equivalent?
Live in peace, Tomas
- --
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBdBw+wYdzVZ/o1QQRAuYQAJ91qTyek/fp58fX3TSGWRUmc0oUZgCfVFyA
8iz8rKvhvF3QuEX0VL4nH/c=
=cKe+
-END PGP SIGNATURE-

Re: Xsession doesn't use umask setting from /etc/login.defs

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Branden Robinson wrote:
| On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote:
|
|> environment variables, at least, are trivial to accomplish
|> using the pam_env module.  Properly setting a umask would call
|> for something else yet.
|
| Would pam_umask.so be a worthwhile exercise for some enterprising
| person?
May I suggest pam_logindefs.so?
| I somehow suspect that umasks predate environment variables in
| the misty early history of Unix, else the umask would've been
| made one.
I don't think so. I think it is a result of careful and thorough
system design. Environment variables are excellent for tailoring
user space activities. Umask (ulimit, nice) is kernel business,
belong in it's data structures and therefore manipulated only
through system calls.
// Tomas
- --
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBdDQ3wYdzVZ/o1QQRAtufAJ40I0q4CHw1qRlf/MJH9e3pnb1jWwCfbzie
+VTh0TnXv6qGrHgtuVZE6Ug=
=3UTD
-END PGP SIGNATURE-

Re: Xsession doesn't use umask setting from /etc/login.defs

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Langasek wrote:
| On Mon, Oct 18, 2004 at 02:06:16AM -0500, Branden Robinson wrote:
|> On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote:
|>> environment variables, at least, are trivial to accomplish
|>> using the pam_env module.  Properly setting a umask would
|>> call for something else yet.
|
|> Would pam_umask.so be a worthwhile exercise for some
|> enterprising person?
|
| (after discussing on IRC) Considering we already have a
| pam_limits.so for ulimits, yes.
Good thinking. I looked at the source. It (pam_limits) already
(conditionally) support things like Linux system capabilities.
Should be able to handle support for umask as well, preferably
upstream. I have sent the authors (redhat staff) a query.
// Tomas
- --
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBdGVewYdzVZ/o1QQRAkwuAJ9IGMwWtNBZV6r5zfcsHe0m5WGoKgCfR1Aa
mGjyqtPZk06hr7UkwTI1GO0=
=exV9
-END PGP SIGNATURE-

Re: Bug#156407: ITP: free-java-sdk -- Complete Java SDK environment consising of free Java tools

[Tomas Pospisek]

On 12 Aug 2002, Grzegorz Prokopski wrote:

> Facts that caused that I have choosen this set of tools.

It'd be nice if you kept this comparison list somewhere (and up to date
;-) - at an URL or in the README, so the "measurement" can be repeated, 
verified,
criticised, enhanced...
*t

-------
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: Convenient way to enable IDE DMA

[tomas p]

On Mon, 26 Aug 2002, Nate Eldredge wrote:

> Thoughts?

Propose a patch against the hdparm package?

Re: Terraform up for adoption

[Tomas Guemes]

Hi,

On Sun, 1 Sep 2002 23:04:08 +1000
Ben Burton <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> So I have less and less to do with GNOME anything and I suspect the
> terraform package would really be better off with someone else. 
> Anyone wants to adopt it, be my guest.  There's a new upstream
> version, and hopefully the povray patches can be removed since povray
> 3.1 has finally been uploaded.
> 
> If anyone does adopt it please drop me an email to let me know.  The
> wnpp bug is #156372.

I will like to adopt it, i'm still in the process of being a dd.

if no ones has any complain, i will close the bug and try to package 
the new upstream version as soon as posible.

greetings

Tomas



pgplNpWdgQKRo.pgp
Description: PGP signature

Re: Terraform up for adoption

[Tomas Guemes]

Hi Mike,

On 01 Sep 2002 11:47:04 -0400
Mike Furr <[EMAIL PROTECTED]> wrote:

> On Sun, 2002-09-01 at 09:49, Tomas Guemes wrote:
> > if no ones has any complain, i will close the bug and try to package
> > 
> > the new upstream version as soon as posible.
> Don't close the bug.  Retitle to an ITA and then close it when you
> upload your new package.

Ok, thanks for the advice 

I will wait until tonite to retitle the bug to an ITA, maybe somebody
has another suggestion :)

greetings

Tomas
> 
> 
> -m
> 



pgp2guZ2bhu9Z.pgp
Description: PGP signature

Re: Debian Accessibility Project was: Re: linux for blinds

[Tomas Cerha]

Andreas Tille wrote:
Sorry, I do not have the time to cooperate with any further project.
I will do all the best to make Debian the best distribution for all
purposes I could think off.  That's why I tried to convince other
projects which tried to build a Debian based distribution for a
special field to include their stuff into Debian and make Debian itself
better for special purposes.  In my opinion it is a plain waste of
resources to follow Debian development and adapt all your special
stuff again and again while not profitting from the great Debian
Bug Tracking System and the Security infrastructure.
Hello, I am one of the people involved in Free(b)soft (and Free(b)deb) 
project.  Thank you for your comments.  I would like to clarify some 
details.  The goal of Free(b)deb project is not a separate distribution. 
The final goal is inclusion of accessibility enhancements and modifications 
into Debian (we are focused on accessibility for blind and visually 
impaired).  Free(b)deb project is here to enable the concentrated 
development of those modifications (modified packages, some additioal 
packages and some meta packages).  When these modifications are ready to 
take place in upstream Debian, the goal of Free(b)deb is finished.

Maybe the fact, that we want to make a Free(b)deb bootable CD-ROM is 
confusing.  This CD-ROM is what we need right now to be able to bring Debian 
installations to our blind users.  People in Brailcom (the non-profit 
organisation, which initiated this project) have 5 years of experience in 
providing Linux based services to blind users in Czech republic.  We think, 
that incorporating all the changes into Debian itself is a long-term job but 
we need to make many installations right now and with current Debian it 
requires a lot of effort (but still Debian is the best of all solutions :-). 
 This is why we want a special CD-ROM and this is also why we managed to 
get the sponsorship for it...

A more detailed description about Debian Internal Projects (which is
the right way to go for those tasks like yours in my opinion) is given
at
 http://www.debian.org/devel/debian-med/talks/200210_lux_internal
Please read this carefully.  At least I will add
 Debian-Accessibility
as further potential internal project for my next talk in this field ...
Yes, it is surely a good idea.  We are ready to cooperate, however 
"accessibility" is quite a general goal (we are focussed on accessibility 
for blind and visually impaired people).  Hopefully people concerned with 
other aspects of accessibility will join the project, when we start it.

We are ready to use all the advantages of "great Debian resources" and we 
appreciate any suggestions how to do it any better.

Thank you, best regards, Tomas Cerha.
--
PGP keyID: 0x0C441CA3
Looking for a *real* RAD tool? Try Emacs!

Re: description writing guide

[tomas pospisek]

On Thu, 5 Dec 2002, Matt Zimmerman wrote:

> On Thu, Dec 05, 2002 at 01:58:43PM -0500, Joey Hess wrote:
>
> > Matt Zimmerman wrote:
> > > I'd be willing to invest some time in co-maintenance of a package
> > > description override list.
> >
> > I've had a pretty good amount of response to my description bug reports.
>
> But do your bug reports keep up with the flow of new packages into the
> archive?  That is, is the overall description quality increasing or
> decreasing?

There are others that are writing bugreports against package descriptions.
I do it about every second time I do an package list update.

I fear being too pedantic, but I haven't met any angrynes yet. So far
positive.
*t

--
  to
ma  will kill for oil
  s
p

Re: bill gates Linux

[tomas pospisek]

On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote:

>  The response I got to a simple
>  request for an DOS or Windows
>  based "SETUP.EXE" program which
>  loads Linux onto my hard drive,

What you want is not a technical problem. So now, that you know it's
feasible you have at least the following alternatives:

1) You go and implement it -> "Go spiratec, go!!" We're all happy to see
   you do it.
2) You wait untill it happens, maybe by trolling around here and there.
3) You let someone else do it for free or for pay. We're a small company
   and would happily accept such a job, like there are many others I'm
   sure here that would be willing to do it.

Btw. here is a SETUP.BAT that does what you need:

rem SETUP.BAT
rem Installation program for Linux
rem
echo Linux has been installed. Please insert the Debian Install CD into
echo your CD drive now and reboot to complete the Linux installation.

I'm serious. That's the cycle that many "SETUP.EXE"s will provide you
with. I certain the installation could be refined a bit to ask you
"Do you want to reboot now?" and reboot automatically.
*t

--
  to
ma  will kill for oil
  s
p

Re: started to make changelogs and copyright file online available

[tomas pospisek]

On 8 Dec 2002, Noèl Köthe wrote:

> I started to make the changelog and copyright file of the Debian
> packages online

Ah! Wondeful. Would be nice to have it integrated in the frontends ... "do
I want/need to update this to the latest unstable version yet - let's
check the changelog ..."?

Very nice!
*t

--
  to
ma  will kill for oil
  s
p

Re: sysctl should disable ECN by default

[Tomas Pospisek]

Zitiere Eduard Bloch <[EMAIL PROTECTED]>:

> > Can we just choose option (a) and be done with it?
> > If Debian isn't going to choose option (a), why are we
> > talking about option (c)?
> 
> See Herbert's mail. IMHO we need a good place to disable it and notify
> the user.

Since the beginning of this discussion the solution is there, available, and
has been presented here. I just need to find the time to ask for inclusion.
Or if someone wants to do that for me please go for it. *Please* check:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862&msg=4&repeatmerged=yes

*t

reopening ECN bugreport/netbase

[Tomas Pospisek]

reopen 110862

# Here with I am reopening this bug.
#
# On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
#
# > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
# > >
# > > I don't know if this is the right place to assign the bug. Maybe the
# > > right place for this is netbase, ifupdown or kernel-package - I
# > > don't know. Please reassign the bug as you wish.
# >
# > This is certainly not the right place.  Anyway, it's your job to
# > decide, not mine.
#
# As it's up to me to decide: Yes, this is the right place. This *is* a
# bug of this kernel-image package. ECN is *not* a standard setting. It
# is marked experimental and is off by default in the upstream default
# config. The reason for this is wellknown and has been discussed in the
# ECN thread on debian-devel.
#
# I do agree with you that by not compiling ECN into the kernel module
# users will not be able to use it and will have to recompile their
# kernel.
#
# So the problem is upstream - ECN should be either a module or off by
# default even if compiled into the kernel.
#
# A workaround, which would be also to some extend cleaner would be to
# enable or disable ECN in netbase. A patch to netbase has been proposed
# in this same bugreport:
#
#   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862&msg=4
#
# There's a whishlist pending against netbase reporting the same problem:
#
#   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98228
#
# So I am going to follow up on that report now, which means that it is up
# to Anthony to hopefully include that patch in netbase allthough it is
# frozen.
#
# *t

---
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: reopening ECN bugreport/netbase

[Tomas Pospisek]

On Wed, 5 Sep 2001, Anthony Towns wrote:

> severity 110892 wishlist
> thanks
>
> On Wed, Sep 05, 2001 at 02:42:23PM +0200, Tomas Pospisek wrote:
> > # On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
> > # > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
> > # > > I don't know if this is the right place to assign the bug.
>
> It's not a bug at all really, and it's certainly not a "critical" one.

>From the docu:

critical   makes unrelated software on the system (or the whole system)
   break, [...]

This is *exacly* what happens after an update from a vanilla 2.2.x kernel
to a 2.4. Some sites plain disapear from the internet, which is not a
catastrophy. What's worse is that with some routers you will *completely*
loose TCP network connectivity. If you happen to be using your box as a
firewall it's the whole LAN that'll be dropped.

How does this differ from the phrasing ".. or the whole system) break"?
Does there need some physical violence be involved to fullfill the
requirements for a critical bugreport?

> If
> you happen not to like ECN on your systems add "sys/net/ipv4/tcp_ecn=0"
> to /etc/sysctl.conf (which is a much better place for such things than
> /etc/network/options) and be done with it.

I couldn't care less about ECN or whatever acronym. The problem is that
"the whole system) break"s. That's a problem. And this will happen at
every single site that f.ex. is using an mildly old Zyxel router.

> AFAIC, the default settings'll remain exactly as they are in the kernel.

There's a problem and no one feels responsible. Well, so I reiterate from
the begining. If netbase is not responsible and that setting has to be
set through /etc/sysctl.conf and since the procps package is not supposed
to know what possible kernel-feature-configuration combinations are
possible/allowed (check this output:

error: '/proc/sys/net/ipv4/tcp_ecn' is an unknown key
(when starting from a 2.2.x kernel)

) then it's the kernel-image package that needs to make sure it's runing
in a sane environment. So *please* can we add something like:

if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
fi

to the kernel-image-2.4.x postinst.

*t

---
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: reopening ECN bugreport/netbase

[Tomas Pospisek]

On Wed, 5 Sep 2001, Scott Dier wrote:

> working fine.  The really broken part is firewalls and tcp/ip stacks on
> the internet that do things to TCP that they shouldn't and break your
> experience.
>
> Go bugreport those instead.

Never mind the users: they will be happy to spend two days debuging the
network to find out that "Ahhh, Debian is defending the flag of the true
IP compliance", where as *all* the other box he knows just work.

And yes, Debian can be proud to be right.
*t

-------
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: dpkg logging

[Tomas Pospisek]

On Sun, 23 Sep 2001, Massimo Dal Zotto wrote:

> > > Previously Steve Greenland wrote:
> > > > Stdout and stderr from the maintainer scripts. (This may be obvious, but
> > >> you didn't explicitly list it.)
> > >
> > > No, they should use debconf.
> >
> > Regardless of whether packages are using debconf, I have wondered for 
> > *years*
> > why we didn't at least have the option of logging stdout and stderr from
> > everything in the install/update process.  I think it's a good idea.
> >
> > Bdale
>
> I have proposed this two years ago and implemented it in my automatic
> installer for slink. The idea is to start a script session from an
> initscript hook for vt1 and have all the debian installation started
> automagically by the shell run by script with all output logged into
> a logfile.
>
> Since all can be done with shell script hacks this solution is very
> easy to implement and requires very few changes to the installation
> program. A simple shell wrapper should work.

Yes please. Where can I find it?
*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: JIFFIES in userspace

[Tomas Pospisek]

Tach Joël,

Am 13.08.2014 05:42, schrieb Joël Krähemann:
> Hi I develop an audio sequencer:
> http://ags.sf.net
> 
> Now, what values would you recommend as JIFFIEs for the following
> threads:
> 
> * AgsAudioLoop
> * AgsTaskThread
> * AgsGuiThread
> * AgsDevoutThread

the topic of the debian-devel mailing list is the development of the
Debian Linux distribution. It's not about application or more
specifically sound application development. You might want to search the
internet for more specific mailing lists, that concern themselves with
audio on Linux. They should be more qualified to help you.

Greets,
*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/53eb5ec0.8020...@sourcepole.ch

Re: Bugs which do not belong to console-setup

[Tomas Pospisek]

Am 07.08.2014 12:32, schrieb Anton Zinoviev:

> I have two bugs reported against console-setup about keybord not working 
> properly under X Window.  In both cases I have asked the reportes to 
> provide the file /etc/default/keyboard and in both cases the file was 
> correct.  Therefore, the bugs are not related to console-setup in any 
> way.
> 
> Unfortunately X Window and the various desktop environments are 
> something I don't understand well enough, so I have no idea where to 
> reassign these bugs.  In result, at the moment both bugs are completely 
> ignored.
> 
> Please advise what should I do in such cases.
> 
> The bugs are: 
> #709883 - reported 14 months ago and #724869 - reported 10 months ago.

Wrt. #709883 the original bug reporter (OBR) wrote:

> [...]
> I tried with gdm3/ligthdm/only startx, and the problems is still
> here. It seems related to X or udev since the upgrade, because gnome
> is well set and gives a french keyboard (macbook pro one), and for
> awesome, my main wm, i have to setxkbmap fr in ~/.xsession to get a
> french keyboard layout
> [...]
> I'm still trying to figure out how to get french back at dm greeter

So most window managers and login managers don't get the keyboard right,
however gnome does.

The correct/wrong keyboard setup/information must come from *somewhere*,
but from where?

So one thing the OBR could do to figure out what's going on is to
"strace -f" startx and the gnome startup, figure out which files are
being accessed (only stat, open and mmap calls are of interest I guess)
and then compare the produced lists.

Otherwise, if nobody can figure out what's going on, or the OBR doesn't
care any more either the OBR or the console-setup maintainers can decide
to close the bug, since no way forward can be made unless there's more
info. Or leave it open.

HTH a bit,
*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/53ebd7b4.8050...@sourcepole.ch

Re: Applying to Become a Maintainer

[Tomas Pospisek]

Am 03.09.2014 22:59, schrieb FERNANDO CROWLEY:
> Hello ,
> want to help i am  novice Linux love to learn more on the OS debian
> please direct me

https://www.debian.org/devel/join/newmaint


-- 
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/54082e90.5040...@sourcepole.ch

Bug#760615: general: Shell scripts do not execute in gui.

[Tomas Pospisek]

Hello Kenji,

On 6.9.2014 Kenji Takashima wrote:

I have been trying to execute multiple shell scripts in gui with no 
avail. The scripts succesfully executed in a terminal, however in the 
gui, the files would not execute when clicked on, and, when 
right-clicked, did not have a "run" option. Other types of executables 
have worked, though I have not tested that many.


In my GUI scripts *can* be executed by double clicking! But maybe 
my "GUI" is not the same as your GUI? That's why o it would be good if you 
could tell us, what "GUI" that GUI of yours is? What is the name of the 
programm/application, in which you are trying to execute the script?


My GUI is XFCE and in XFCE I open the "Thunar" file browser. I double- 
click a script in Thunar, but nothing happens. That is because usually 
scripts write to the "standard out" channel. If you do not run a script in 
a terminal, then it does not have a "standard out" channel. That's why 
you will not seem anything happen when the script is executed.


In order to veryfiy that Thunar actually *does* execute a script when I 
double-click it I did the following, which you can do as well:


Open a terminal and in the terminal write the following:

cd /tmp
echo "#!/bin/sh" > foobar
echo "touch foobar.touched" >> foobar
chmod +x foobar

Now doublecklick that script. Has the file "foobar.touched" been created 
on your machine?


Greets,
*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/alpine.DEB.2.02.1409062051060.29858@hier

patch to remove 'base' pseudo package

[Tomas Pospisek]

Hello,

the attached patch implements the removal of the 'base' pseudo package 
from reportbug.


Additionally I'd like to ask if it'd be OK to at the same time reassign 
the existing few bug reports from the 'base' package to the 'general' 
package or to more specific packages (most of the 'base' bugs seem to 
concern the kernel).


Thanks,
*tcommit 8019e48
Author: Tomas Pospisek 
Date:   Thu Sep 11 17:59:34 2014 +0200

remove 'base' package

Fixes #734053

diff --git bin/reportbug bin/reportbug
index 127cbda..80155b4 100755
--- bin/reportbug
+++ bin/reportbug
@@ -483,7 +483,7 @@ def get_package_name(bts='debian', mode=MODE_EXPERT):
  'bug tracking system itself.'):
 package = 'reportbug'
 
-if package in ('general', 'project', 'debian-general', 'base'):
+if package in ('general', 'project', 'debian-general'):
 ui.long_message(
 "If you have a general problem, please do consider using "
 		'the available Debian support channels to narrow the problem '
diff --git reportbug/debbugs.py reportbug/debbugs.py
index ce21ba4..0e4abb6 100644
--- reportbug/debbugs.py
+++ reportbug/debbugs.py
@@ -160,7 +160,6 @@ def convert_severity(severity, type='debbugs'):
 
 # These packages are virtual in Debian; we don't look them up...
 debother = {
-'base' : 'General bugs in the base system',
 'bugs.debian.org' : 'The bug tracking system, @bugs.debian.org',
 'buildd.debian.org' :  'Problems and requests related to the Debian Buildds',
 'buildd.emdebian.org' :  'Problems related to building packages for Emdebian',

Re: patch to remove 'base' pseudo package

[Tomas Pospisek]

On Thu, 11 Sep 2014, Holger Levsen wrote:


Hi Tomas,

thanks for having jumped in dealing with these kinds of bugs. Much
appreciated!


:-)! Thanks Holger!


On Donnerstag, 11. September 2014, Tomas Pospisek wrote:

the attached patch implements the removal of the 'base' pseudo package
from reportbug.


cool, thanks! (Though this should probably be re-send as a new wishlist bug
against reportbut. #734053 is about removing the "base" pseudo package from
the BTS.)


Done, see #761206 [1]. Thanks for letting me know about my mistake!


Additionally I'd like to ask if it'd be OK to at the same time reassign
the existing few bug reports from the 'base' package to the 'general'
package or to more specific packages (most of the 'base' bugs seem to
concern the kernel).


rather assign them to the right package(s), those bugs don't belong to
"general". Ping me if you have questions about how to handle specific bugs.


Thanks, I will. However, for today I had my share of BTS work, I'll see 
when I'll continue.


Liebe Grüsse!
*t

[1] http://bugs.debian.org/761206

Bug#769187: general: Entries in system log for failed services refer to FreeDesktop.ORG for support

[Tomas Fasth]

Package: general
Severity: normal

I use Virtualbox to run test environments for the packages I maintain
(just a few really). I install virtualbox-guest-utils in my guest
installations to adjust system clock after hibernation.

In Jessie, there seem to be a problem with the virtualbox guest service.
It fails to start and, as usual, I look in the system log for clues.

Now, as a DD I am of course very much aware of the highly debated
change in Jessie to a new default init process. I have had no strong
feelings about this so far, other than that in general, as a user, I
very much value the freedom of choice. That is why I choose to use free
and open source software when available in the first place.

Any way, back to the failed start of the virtualbox service. I went to
the system log for clues, in this case using 'journalctl -x'. To my
surprise, where ever there was a problem reported, there was also a
reference to systemd-devel mailing list at FreeDesktop.ORG for support.

In my particular case it looked like this:

// log extract begins
nov 10 01:36:47 debian-systemd sudo[1429]: tomfa : TTY=pts/0 ; PWD=/home/tomfa 
; USER=root ; COMMAND=/usr/sbin/service virtualbox-guest-utils start
nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session 
opened for user root by tomfa(uid=0)
nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: Starting 
VirtualBox AdditionsNo suitable module for running kernel found ... failed!
nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: failed!
nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session 
closed for user root
nov 10 01:36:47 debian-systemd systemd[1]: virtualbox-guest-utils.service: 
control process exited, code=exited status=1
nov 10 01:36:47 debian-systemd systemd[1]: Failed to start LSB: VirtualBox 
Linux Additions.
-- Subject: Unit virtualbox-guest-utils.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit virtualbox-guest-utils.service has failed.
-- 
-- The result is failed.
nov 10 01:36:47 debian-systemd systemd[1]: Unit virtualbox-guest-utils.service 
entered failed state.
// log extract ends

I don't understand why there should be a reference to an external support
entity when the issue obviously is Debian related and should be reported
as such in Debian-related forums. My specific issue has nothing to do
with systemd or FreeDesktop.ORG. I want the external reference removed.
If it stays it will only create confusion and misunderstanding.

Thank you,

Tomas Fasth

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/1 CPU core)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20141110011332.1314.27239.report...@debian-systemd.malforsdata.se

Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?

[Tomas Pospisek]

Hello all,

since

1. I need signatures on my all new fresh key 0x29774B39 and
2. I would love to meet all the local Debianistas

would any of you come and sign my key when in Zürich/SH/Winti?

Anybody interested in going out for a beer? We could also have a
bugfixing evening.

Wink,
*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/5462c30f.3090...@sourcepole.ch

Re: Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?

[Tomas Pospisek]

Thanks for all the nice info Paul!
*t

Am 12.11.2014 um 06:59 schrieb Paul Wise:
> On Wed, Nov 12, 2014 at 10:16 AM, Tomas Pospisek wrote:
> 
>> would any of you come and sign my key when in Zürich/SH/Winti?
> 
> In case folks from these places aren't reading this list, some possibilities:
> 
> https://db.debian.org/search.cgi?country=ch&dosearch=Search
> https://wiki.debian.org/Keysigning/Offers#CH
> https://wiki.debian.org/LocalGroups#Switzerland
> http://debian.ch/
> 
> This info brought to you by DebianLocations:
> 
> https://wiki.debian.org/DebianLocations


-- 
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/54634e30.7030...@sourcepole.ch

Re: [MIA?] Tomas Fasth, Maintainer of Termit et al

[Tomas Fasth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas Koch skrev 2012-05-22 09:18:
> Hi,
>
> I'm not sure, whether I should ask here. I already wrote a mail to
Tomas Fasth
> some weeks ago (I believe, can't find it anymore). I'd like to fix some
of the
> issues in the termit package.
>
> But there's no sign of life of him.
>
> Regards,
>
> Thomas Koch, http://www.koch.ro

Hi Thomas,

I sent you an answer 7th of May, see below.

Regards, Tomas

-  Ursprungligt meddelande 
Ämne: Re: NMU for termit Debian package?
Datum: Mon, 07 May 2012 13:58:06 +0200
Från: Tomas Fasth 
Svar till: to...@debian.org
Organisation: Debian
Till: tho...@koch.ro
Kopia: Nobuhiro Iwamatsu , Julian Taylor
, Martintxo ,
Tomas Fasth 



Den Mon May  7 06:58:10 2012 skrev Thomas Koch:
> Hi Tomas,
>
> the termit Debian package maintained by you has accumulated a few easy
issues
> and could also be updated. Would you mind me preparing an NMU?
> Did you use a VCS for the packaging? The VCS-* fields in debian/control
point
> to the upstream's Git repository, not to the repository used for the
> packaging.
>
> Regards,
>
> Thomas Koch, http://www.koch.ro

Hi Thomas,

I don't mind you preparing a NMU at all. I welcome your initiative. As
a matter of fact, I'm considering to put the package out for adoption,
since I have don't have time to actively maintain it. I uploaded the
package at first to bring it into the Debian proper. It deserve a DD
with more time at hand.

Regards

- -- 
Tomas Fasth 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+8C8wACgkQwYdzVZ/o1QQQuQCbB7e3qz0b8oCTORmCqKcibtPT
iZIAnRbyDP6Zb/lL3/VPMJhY47rLi9JT
=DAU/
-END PGP SIGNATURE-


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

Announce: script to automatically restart services after update of dependencies

[Tomas Pospisek]

I want to announce restart-services here [1][2]. It's a script
that tries to restart all services that have had their
dependency packages updated. This is primarily useful when
security-relevant libraries get security releases.

It's using checkrestart from the debian-goodies package to do
most of its work.

Together with the unattended-upgrades package it is saving me
a lot of system maintenance time, thus I am announcing it here
in the hope that it will save others a lot of time as well.

Thanks,
*t

[1]
http://sourcepole.ch/2012/6/7/automatically-restarting-services-after-upgrades-on-debian-and-ubuntu
[2] https://github.com/tpo/debian-goodies


-- 
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/7f19c94095a8d9d9467cfbd176b45...@mail.sp-metanet

Re: Announce: script to automatically restart services after update of dependencies

[Tomas Pospisek]

On Mon, 18 Jun 2012 14:10:46 +0100, Ben Hutchings 
wrote:
> On Mon, 2012-06-18 at 20:40 +0800, Paul Wise wrote:
>> On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote:
>> 
>> > I want to announce restart-services here [1][2]. It's a script
>> > that tries to restart all services that have had their
>> > dependency packages updated. This is primarily useful when
>> > security-relevant libraries get security releases.
>> >
>> > It's using checkrestart from the debian-goodies package to do
>> > most of its work.
>> >
>> > Together with the unattended-upgrades package it is saving me
>> > a lot of system maintenance time, thus I am announcing it here
>> > in the hope that it will save others a lot of time as well.
>> 
>> Sounds useful, maybe put it in the debian-goodies package?

I've proposed this to Javier [3] and it's been quite well received :-)

> What, yet another feature reserved for those in the know?  Surely we
> should be doing this by default.

I agree. Could you suggest a way forward? Currently I'm aiming for
debian-goodies, however maybe unattended-upgrades would be a better fit.
However I think really it should go into apt-level inftrastructure.

?

>> Also, please blacklist gdm3 and dbus since restarting them currently
>> kills GNOME sessions (and probably other user desktop sessions started
>> by gdm3).

Noted. I'll discuss this with Javier.

PS: Sorry Ben for also replying in private to you. I'll have to get used
to mailing lists (and my web mail client) again :-o
 
[3] http://bugs.debian.org/676509


-- 
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/dd2dff74094493356b2da0485cc34...@mail.sp-metanet

Re: Announce: script to automatically restart services after update of dependencies

[Tomas Pospisek]

On Tue, 19 Jun 2012 12:23:45 +0200, Goswin von Brederlow wrote:
> Tomas Pospisek writes:
> 
>> On Mon, 18 Jun 2012 14:10:46 +0100, Ben Hutchings  wrote:
>>> On Mon, 2012-06-18 at 20:40 +0800, Paul Wise wrote:
>>>> On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote:
>>>> 
>>>> > I want to announce restart-services here [1][2]. It's a script
>>>> > that tries to restart all services that have had their
>>>> > dependency packages updated. This is primarily useful when
>>>> > security-relevant libraries get security releases.
>>>> >
>>>> > It's using checkrestart from the debian-goodies package to do
>>>> > most of its work.
>>>> >
>>>> > Together with the unattended-upgrades package it is saving me
>>>> > a lot of system maintenance time, thus I am announcing it here
>>>> > in the hope that it will save others a lot of time as well.
>>>> 
>>>> Sounds useful, maybe put it in the debian-goodies package?
>>
>> I've proposed this to Javier [3] and it's been quite well received :-)
>>
>>> What, yet another feature reserved for those in the know?  Surely we
>>> should be doing this by default.
>>
>> I agree. Could you suggest a way forward? Currently I'm aiming for
>> debian-goodies, however maybe unattended-upgrades would be a better
fit.
>> However I think really it should go into apt-level inftrastructure.
> 
> I want to automatically restart services so that / and /usr can be
> remounted read-only again. But I don't want unattended upgrades. So for
> me debian-goddies is a better fit. Easy enough to add it then to the
> apt config.


Point taken.

However Ben argued, if I interpret him correctly, that services that
depend
on something (a library), should be restarted by default if that
dependency gets
updated and the user should not be required to install an "obscure"
package to
have that sane default behavior.

This implies that an "apt-get install library" needs to trigger that
restart.
Which means that apt-get needs to depend on restart-services. So either
restart-services and checkrestart should go into the apt package, or apt
needs
to depend on/recommend debian-goodies, which would currently pull in
python,
perl, curl, dialog and their respective dependencies.

The later may be a technically working solution, but from a conceptual and
a
KISS point of view doesn't make sense to me.

Is my conclusion correct so far?

So if we want a "clean" solution, then checkrestart/restart-services would
need
to move into apt and get rid of the non-essential dependencies (get
rewritten in
shell or C).

?

*t

>> [3] http://bugs.debian.org/676509


-- 
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/dd25736bb03f21cb838910bbfd35c...@mail.sp-metanet

Re: About Re-Distribution

[Tomas Pospisek]

Am 10.06.2013 14:13, schrieb Shivam Pandya:
> Hello sir/ Ma'm
> 
> I'm Shivam Pandya, and study in my last year, I want to develop a OS
> in my final year project, I found debian from wiki, Can you help me
> out from this. can you please guide me that how could I develop (re
> distribute) my own one, what steps needed if I use Windows.?

I'd suggest to start by installing Debian on some PC or laptop and then
see what you want to change in Debian.
*t


-- 
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/51b72f74.3020...@sourcepole.ch

Re: Bugs filed in unexpected places

[Tomas Pospisek]

Hello Andrei and all,

On Fri, 26 Oct 2012 16:24:59 +0300, Andrei POPESCU wrote:

> The discussion about ITO made me think: wouldn't it make more sense to 
> also have RFH, RFA, and O filled against the package itself and not 
> wnpp? One has to be quite familiar with Debian to check wnpp for RFH, 
> RFA or O. Maybe having these bugs "in the face" of people interested in 
> the package (i.e. on the package's bug page) can help attract 
> contributions.
> 
> Additionally for some packages it might make sense to remove them from 
> testing and raise the severity of the O bug to serious to signal that 
> the package should not be included in the next release unless someone is

> willing to commit to maintain it.
> 
> An immediate solution would probably be to 'affects ' so the 
> bugs at least shows up on the package's bug page. Maybe the BTS 
> could/should do this automatically?
> 
> 
> One a somewhat related note, I also notice confusion is created by the 
> removal bugs being filed against ftp.debian.org. When people not 
> familiar with Debian are looking into why a package has been removed 
> they look at the (archived) package's bugs. Not a biggie, but might help

> users or prospective ITPers (e.g. if the removal reasons still apply). 
> Not sure if 'affects' can help here.
> 
> I'm guessing the current procedures were created because at the time the

> BTS did not have the 'affects ' feature.

Have you tried to hack anything yet? I've seen that Don Armstrong seens to
be open to these ideas.

I've also been roaming around http://bugs.debian.org/bugs.debian.org and
I'm also encountering the same problems you describe above.
*t


-- 
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/394759cd3e5b59c9f637b444f3df3...@sourcepole.ch

Re: systemd-fsck?

[Tomas Pospisek]

Am 15.05.2014 01:42, schrieb Marc Haber:
> On Tue, 13 May 2014 17:28:27 +0200, Vincent Bernat 
> wrote:
>> ? 13 mai 2014 15:01 +0200, Marc Haber  :
 Thank you so much for volunteering to contribute to GNOME packaging and
 to make it work on configurations nobody will actually ever use.

 We are eagerly waiting for your patches.
>>>
>>> This sort of behavior is precisely why many users are migrating away
>>> from Debian.
>>
>> Could you please stop FUD? Do you have some reference for this claim?
> 
> I know at least two of them. And I, for myself, have greatly reduced
> my efforts to report bugs in Debian since I alredy know the reaction
> of many maintainers.

Oh, please don't. When I have a problem, searching the BTS is one of the
most efficient ways to improve my knowledge. Please also for the sake of
me and maybe also of other users, please do report bugs, even if you
expect the maintainer to ignore you.

*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/5376637c.80...@sourcepole.ch

Re: systemd-fsck?

[Tomas Pospisek]

Am 13.05.2014 21:49, schrieb Cyril Brulebois:
> Thibaut Paumard  (2014-05-13):
>> Le 13/05/2014 17:36, Russ Allbery a écrit :
>>> Right, which I've been arguing for already in this thread.  I don't think
>>> we should force this on upgrades.  There should be a prompt and an
>>> opportunity to not change init systems.
>>
>> Instead of or in addition to such prompting, I expect this switch will
>> be documented in the Release Notes so that people who really care are
>> aware of the risks and the cases which are known to break.
> 
> The sad thing is: almost nobody reads the release notes.

Are you saying this just like that or can you back it up with facts somehow?

As far as I have read in this thread, the only reported problem with
upgrading from sysv to systemd concerns remote virtual machines that
won't boot.

Remote virtual machines are a problem that will mostly concern
sysadmins. Me as a responsible sysadmin am reading the release notes,
because I do not want to have downtimes with my machines and so I want
to know beforehand if there are any known problems that I should be
aware of. And I have trouble imagining that other people that call
themselves sysadmins do not act the same. Or do they?

*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/53765d0c.1000...@sourcepole.ch

Re: Technical committee acting in gross violation of the Debian constitution

[Tomas Pospisek]

Am 27.11.2014 um 01:19 schrieb Josselin Mouette:
> Yes, yes, and yes. This needs to be put in a frame and bashed in the
> head of anyone who keeps repeating that systemd is about GNOME.

What about the idea of being mindful of the tone of your conversation
and keeping it conciously moderate, Josselin?

When you are asking for something to be "bashed in the head" of people
other than you, then I think it is trivial to understand that you are
setting the response to be of the same tone with respect to agressivity
and intollerance.

That kind of tone will evidently not contribute to keeping the
conversation constructive.

If there's something to be learned from the mailing list traffic here
then it seems crystal clear to me that the *way* people interact with
each other is *the* determining factor of the future of Debian as a project.

You must accept that there will be different opinions never mind how
stupid they are. If you react with violence and bash people on their
heads then that might work for small, fearful minorities, which you will
beat out of the project or into silence. But it will not work in a
situation like this, where a large and strong part of the project has a
different oppinion than you.

Technical correctnes and excellence and correct and excellent
interaction are conditions sine non qua for a good and excellent project
and product.

All of these are of course platitudes that you, being a brilliant mind,
have no problem to understand. Therefore I want to suggest to you to
please to take one step back before pressing reply and to choose the
words that you are using here in conversations conciously.
*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/5477053b.4000...@sourcepole.ch

successful upgrade to jessie - thanks!

[Tomas Pospisek]

Hello list,

I hope it's appropriate here, I just wanted to say *thanks to
everybody*, in particular the low level package and infrastructure
maintainers for the excellent work they've done.

Yesterday I've upgraded my laptop with quite massive foreign package
sources and installations (qgis packages, backports, stuff from ubuntu
PPAs, nodejs, a dozen packages from jessie etc.) from wheezy to jessie.

Allthough apt-get dist-upgrade broke half way through due to
unresolvable package dependencies, I was able to finish the upgrade via
aptitude's ncurses interface.

One problem when upgrading via apt-get is that if it breaks then I think
there's no way a user that is not *very much* knowledgeable will be ever
able to get his system back together.

apt-get with or without -f will (in my case) flood the user with a
broken dependencies listing which is far, far beyond trivial to act upon.

So I think if Debian wants to embrace the "normal" desktop end user,
then it *can not* point him to apt-get as the upgrade method of choice.

I am not sure how pervasive non-debian package sources (mind you Debian
backports are officially listed at Debian, but can break the upgrade
none the less!) are in our install base, but there are a lot of upstream
projects that do provide Debian packages and respective advice is easily
found on the intertubes.

I do not know how other Debian users handle tech, but my way of
approaching technology is "just try". In the case of a Debian
installation with foreign package sources that "apt-get dist-upgrade"
approach will quite likely end with a broken system.

So I think it'd be good to add a big fat warning to "apt-get
dist-upgrade" if it finds non canonical sources to tell the user "you
want to break your system now? Please go ahead and type 'YES' now" or
have a different way for upgrading for "end users".

Another point to note is that the migration to systemd went very
smoothly - very few things broke - so applause to all the burned out
parties out there and those that are sill holding out: you did a very
good job. Thanks a lot!
*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/54772586.9060...@sourcepole.ch

upgrading to jessie broke usb_storage on a mode switched device

[Tomas Pospisek]

Hello,

after upgrading to jessie(-with systemd) connecting my mobile to the
latop as a usb storage device stopped working.

I do have to "rmmod usb_storage && modprobe usb_storage" in order for
the usb storage devices to become visible every time.

What is the suggested procedure from here on short of filing a bug
against "general"? I do not have an idea which component between
systemd/udev/usb_modeswitch/the kernel/or other is at fault here, if
even it's the fault of a single package at all. Where does the bug
belong to? Is this more appropriate for debian-user?

?

Thanks,
*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/54772708.1060...@sourcepole.ch

Re: upgrading to jessie broke usb_storage on a mode switched device

[Tomas Pospisek]

Am 27.11.2014 um 17:12 schrieb Thomas Goirand:
> On 11/27/2014 09:28 PM, Tomas Pospisek wrote:
>> Hello,
>>
>> after upgrading to jessie(-with systemd) connecting my mobile to the
>> latop as a usb storage device stopped working.
>>
>> I do have to "rmmod usb_storage && modprobe usb_storage" in order for
>> the usb storage devices to become visible every time.
>>
>> What is the suggested procedure from here on short of filing a bug
>> against "general"? I do not have an idea which component between
>> systemd/udev/usb_modeswitch/the kernel/or other is at fault here, if
>> even it's the fault of a single package at all. Where does the bug
>> belong to? Is this more appropriate for debian-user?
> 
> This sounds like an udev/systemd issue. Do you have any kind of logs to
> provide? Does "dmesg" says something? Anything in the syslog^W systemd
> journal?

Yes, /var/log/messages looks like this:

Nov 27 13:46:41 hier kernel: [28652.975203] usb 4-1.1: new high-speed USB 
device number 26 using ehci-pci
Nov 27 13:46:41 hier kernel: [28653.068821] usb 4-1.1: New USB device found, 
idVendor=12d1, idProduct=1037
Nov 27 13:46:41 hier kernel: [28653.068831] usb 4-1.1: New USB device strings: 
Mfr=2, Product=3, SerialNumber=4
Nov 27 13:46:41 hier kernel: [28653.068836] usb 4-1.1: Product: Android
Nov 27 13:46:41 hier kernel: [28653.068840] usb 4-1.1: Manufacturer: Android
Nov 27 13:46:41 hier kernel: [28653.068844] usb 4-1.1: SerialNumber: 
4C8BEFBC3276
Nov 27 13:46:41 hier kernel: [28653.069822] usb-storage 4-1.1:1.0: USB Mass 
Storage device detected
Nov 27 13:46:41 hier kernel: [28653.070344] scsi15 : usb-storage 4-1.1:1.0
Nov 27 13:46:41 hier mtp-probe: checking bus 4, device 26: 
"/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.1"
Nov 27 13:46:41 hier mtp-probe: bus: 4, device: 26 was not an MTP device
Nov 27 13:46:42 hier usb_modeswitch: switch device 12d1:1037 on 004/026

And that's that. Now when I do "rmmod usb_storage && modprobe usb_storage" the 
log continues like this:

Nov 27 13:46:55 hier kernel: [28666.858764] usbcore: deregistering interface 
driver usb-storage
Nov 27 13:47:01 hier kernel: [28672.635113] usb-storage 4-1.1:1.0: USB Mass 
Storage device detected
Nov 27 13:47:01 hier kernel: [28672.635615] scsi16 : usb-storage 4-1.1:1.0
Nov 27 13:47:01 hier kernel: [28672.635915] usbcore: registered new interface 
driver usb-storage
Nov 27 13:47:02 hier kernel: [28673.633832] scsi 16:0:0:0: Direct-Access 
LinuxFile-CD Gadget    PQ: 0 ANSI: 2
Nov 27 13:47:02 hier kernel: [28673.634382] scsi 16:0:0:1: Direct-Access 
LinuxFile-CD Gadget    PQ: 0 ANSI: 2
Nov 27 13:47:02 hier kernel: [28673.634813] scsi 16:0:0:2: CD-ROM
LinuxFile-CD Gadget    PQ: 0 ANSI: 2
Nov 27 13:47:02 hier kernel: [28673.636127] sd 16:0:0:0: Attached scsi generic 
sg2 type 0
Nov 27 13:47:02 hier kernel: [28673.636856] sd 16:0:0:1: Attached scsi generic 
sg3 type 0
Nov 27 13:47:02 hier kernel: [28673.637294] sd 16:0:0:0: [sdb] Attached SCSI 
removable disk
Nov 27 13:47:02 hier kernel: [28673.640180] sr1: scsi3-mmc drive: 0x/0x caddy
Nov 27 13:47:02 hier kernel: [28673.641721] sr 16:0:0:2: Attached scsi generic 
sg4 type 5
Nov 27 13:47:02 hier kernel: [28673.642690] sd 16:0:0:1: [sdc] Attached SCSI 
removable disk
Nov 27 13:47:11 hier kernel: [28682.358352] sd 16:0:0:0: [sdb] 2310144 512-byte 
logical blocks: (1.18 GB/1.10 GiB)
Nov 27 13:47:11 hier kernel: [28682.363018]  sdb:
Nov 27 13:47:13 hier kernel: [28684.404459] sd 16:0:0:1: [sdc] 62333952 
512-byte logical blocks: (31.9 GB/29.7 GiB)
Nov 27 13:47:13 hier kernel: [28684.411152]  sdc: sdc1
Nov 27 13:47:23 hier kernel: [28695.050516] FAT-fs (sdc1): utf8 is not a 
recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Nov 27 13:47:23 hier kernel: [28695.075737] FAT-fs (sdc1): Volume was not 
properly unmounted. Some data may be corrupt. Please run fsck.



-- 
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/5477652f.1030...@sourcepole.ch

Re: Javascript trigger design

[Tomas Pospisek]

Am 28.11.2014 um 00:04 schrieb Thomas Goirand:
> Hi,
> 
> Web application have evolved into monsters that needs lots of
> javascript. It's very common that these javascript applications are
> collecting all the .js library they use, concatenate them into a single
> file, and compress the result using all sorts of tools (node uglify is
> one of the implementation, but that's not the only one).
> 
> As much as possible, as good Debian citizens, we do package each and
> every javascript library into a separate package. But then, if there's
> an update of that JS library, the Web application package has to somehow
> know about it, and redo the concatenate & compress job. Otherwise, the
> web app would continue to use the old version.
> 
> I have this issue with the OpenStack dashboard (ie: Horizon), but also
> with a second web app which I'm currently packaging (OpenStack Fuel,
> which is a deployment software for OpenStack). Though this could of
> course be generalize to any JS app.
> 
> It's been a long time I've been thinking about it, and I believe that
> the only way to do this, would be to use triggers. Though I have never
> used triggers, and I thought it was a good idea to ask my DD friends and
> this list about it. Should there be one trigger per web app? How would
> this work?
> 
> Thoughts anyone? Jonas maybe, who did lots of JS packaging?

At least the Ruby On Rails framework notices an updated JS and will
re-compress the whole JS blob from its parts. I don't know about other
server side frameworks, but they _should_ be able to do the same. - ? Or
there shoould be some switch or some additional plugin or such that
enables the same functionality.

Or do I missunderstand you?
*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/5477c7b4.90...@sourcepole.ch

Re: Technical committee acting in gross violation of the Debian constitution

[Tomas Pospisek]

It took me time to realize why writing the below didn't feel right in
some uneasy way. That's because, allthough being logically completely
correct (I boldly assert here...), what I wrote below completely misses
the essence and is therefor just bullshit, which we can have a good
laugh about. And that actually *does* expresses the essence: we _should_
be laughing!

So, dear Josselin, sorry for confronting you with that nonsense, I hope
you can chuckle about it gleefully!
*t

Am 27.11.2014 um 12:04 schrieb Tomas Pospisek:
> Am 27.11.2014 um 01:19 schrieb Josselin Mouette:
>> Yes, yes, and yes. This needs to be put in a frame and bashed in the
>> head of anyone who keeps repeating that systemd is about GNOME.
> 
> What about the idea of being mindful of the tone of your conversation
> and keeping it conciously moderate, Josselin?
> 
> When you are asking for something to be "bashed in the head" of people
> other than you, then I think it is trivial to understand that you are
> setting the response to be of the same tone with respect to agressivity
> and intollerance.
> 
> That kind of tone will evidently not contribute to keeping the
> conversation constructive.
> 
> If there's something to be learned from the mailing list traffic here
> then it seems crystal clear to me that the *way* people interact with
> each other is *the* determining factor of the future of Debian as a project.
> 
> You must accept that there will be different opinions never mind how
> stupid they are. If you react with violence and bash people on their
> heads then that might work for small, fearful minorities, which you will
> beat out of the project or into silence. But it will not work in a
> situation like this, where a large and strong part of the project has a
> different oppinion than you.
> 
> Technical correctnes and excellence and correct and excellent
> interaction are conditions sine non qua for a good and excellent project
> and product.
> 
> All of these are of course platitudes that you, being a brilliant mind,
> have no problem to understand. Therefore I want to suggest to you to
> please to take one step back before pressing reply and to choose the
> words that you are using here in conversations conciously.
> *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/5477cbd9.10...@sourcepole.ch

Re: Javascript trigger design

[Tomas Pospisek]

Am 28.11.2014 um 08:19 schrieb Matthias Urlichs:
> Hi,
> 
> Tomas Pospisek:
>> At least the Ruby On Rails framework notices an updated JS and will
>> re-compress the whole JS blob from its parts.
> 
> Does it call stat() on every constituent of these packed JS files on every
> web request, or does it do that with a periodic background checker?

I do not know. Now that I am reading the answers in this thread I'm
noticing that RoR might be checking the newness of JS scripts depending
on the mode it's running in (production, testing, dev). In which case
the trigger mechanism could come into play again. So maybe my statement
was mistaken. In case anybody intends to make conclusions, s/he really
needs to look these detail up in the RoR docu.
*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/547840c0.4050...@sourcepole.ch

Re: upgrading to jessie broke usb_storage on a mode switched device

[Tomas Pospisek]

So, since there hasn't been any reaction to this, let me try to ask a
few additional questions, that might help me to find out where to dig next:

Am 27.11.2014 um 18:53 schrieb Tomas Pospisek:
> Am 27.11.2014 um 17:12 schrieb Thomas Goirand:
>> On 11/27/2014 09:28 PM, Tomas Pospisek wrote:
>>> Hello,
>>>
>>> after upgrading to jessie(-with systemd) connecting my mobile to the
>>> latop as a usb storage device stopped working.
>>>
>>> I do have to "rmmod usb_storage && modprobe usb_storage" in order for
>>> the usb storage devices to become visible every time.
>>>
>>> What is the suggested procedure from here on short of filing a bug
>>> against "general"? I do not have an idea which component between
>>> systemd/udev/usb_modeswitch/the kernel/or other is at fault here, if
>>> even it's the fault of a single package at all. Where does the bug
>>> belong to? Is this more appropriate for debian-user?
>>
>> This sounds like an udev/systemd issue. Do you have any kind of logs to
>> provide? Does "dmesg" says something? Anything in the syslog^W systemd
>> journal?
> 
> Yes, /var/log/messages looks like this:
> 
> Nov 27 13:46:41 hier kernel: [28652.975203] usb 4-1.1: new high-speed USB 
> device number 26 using ehci-pci
> Nov 27 13:46:41 hier kernel: [28653.068821] usb 4-1.1: New USB device found, 
> idVendor=12d1, idProduct=1037
> Nov 27 13:46:41 hier kernel: [28653.068831] usb 4-1.1: New USB device 
> strings: Mfr=2, Product=3, SerialNumber=4
> Nov 27 13:46:41 hier kernel: [28653.068836] usb 4-1.1: Product: Android
> Nov 27 13:46:41 hier kernel: [28653.068840] usb 4-1.1: Manufacturer: Android
> Nov 27 13:46:41 hier kernel: [28653.068844] usb 4-1.1: SerialNumber: 
> 4C8BEFBC3276
> Nov 27 13:46:41 hier kernel: [28653.069822] usb-storage 4-1.1:1.0: USB Mass 
> Storage device detected
> Nov 27 13:46:41 hier kernel: [28653.070344] scsi15 : usb-storage 4-1.1:1.0
> Nov 27 13:46:41 hier mtp-probe: checking bus 4, device 26: 
> "/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.1"
> Nov 27 13:46:41 hier mtp-probe: bus: 4, device: 26 was not an MTP device
> Nov 27 13:46:42 hier usb_modeswitch: switch device 12d1:1037 on 004/026
> 
> And that's that. Now when I do "rmmod usb_storage && modprobe usb_storage" 
> the log continues like this:
> 
> Nov 27 13:46:55 hier kernel: [28666.858764] usbcore: deregistering interface 
> driver usb-storage
> Nov 27 13:47:01 hier kernel: [28672.635113] usb-storage 4-1.1:1.0: USB Mass 
> Storage device detected
> Nov 27 13:47:01 hier kernel: [28672.635615] scsi16 : usb-storage 4-1.1:1.0
> Nov 27 13:47:01 hier kernel: [28672.635915] usbcore: registered new interface 
> driver usb-storage
> Nov 27 13:47:02 hier kernel: [28673.633832] scsi 16:0:0:0: Direct-Access 
> LinuxFile-CD Gadget    PQ: 0 ANSI: 2
> Nov 27 13:47:02 hier kernel: [28673.634382] scsi 16:0:0:1: Direct-Access 
> LinuxFile-CD Gadget    PQ: 0 ANSI: 2
> Nov 27 13:47:02 hier kernel: [28673.634813] scsi 16:0:0:2: CD-ROM
> LinuxFile-CD Gadget    PQ: 0 ANSI: 2
> Nov 27 13:47:02 hier kernel: [28673.636127] sd 16:0:0:0: Attached scsi 
> generic sg2 type 0
> Nov 27 13:47:02 hier kernel: [28673.636856] sd 16:0:0:1: Attached scsi 
> generic sg3 type 0
> Nov 27 13:47:02 hier kernel: [28673.637294] sd 16:0:0:0: [sdb] Attached SCSI 
> removable disk
> Nov 27 13:47:02 hier kernel: [28673.640180] sr1: scsi3-mmc drive: 0x/0x caddy
> Nov 27 13:47:02 hier kernel: [28673.641721] sr 16:0:0:2: Attached scsi 
> generic sg4 type 5
> Nov 27 13:47:02 hier kernel: [28673.642690] sd 16:0:0:1: [sdc] Attached SCSI 
> removable disk
> Nov 27 13:47:11 hier kernel: [28682.358352] sd 16:0:0:0: [sdb] 2310144 
> 512-byte logical blocks: (1.18 GB/1.10 GiB)
> Nov 27 13:47:11 hier kernel: [28682.363018]  sdb:
> Nov 27 13:47:13 hier kernel: [28684.404459] sd 16:0:0:1: [sdc] 62333952 
> 512-byte logical blocks: (31.9 GB/29.7 GiB)
> Nov 27 13:47:13 hier kernel: [28684.411152]  sdc: sdc1
> Nov 27 13:47:23 hier kernel: [28695.050516] FAT-fs (sdc1): utf8 is not a 
> recommended IO charset for FAT filesystems, filesystem will be case sensitive!
> Nov 27 13:47:23 hier kernel: [28695.075737] FAT-fs (sdc1): Volume was not 
> properly unmounted. Some data may be corrupt. Please run fsck.

So in these logs we see that:

1. when I plug in my smartphone
2. the kernel tells me he has noticed it and correctly reports the
   newly discovered device to the log
3. also the usb-storage module reports that it is seeing a new storage
   device on the USB bus. Also correct.
4a. next the mtp-probe reports that the new device is not a MTP 

Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)

[Tomas Pospisek]

Am 29.11.2014 um 22:01 schrieb Philipp Kern:
> On 2014-11-29 21:30, Steve Langasek wrote:
>> Debian releases when it's ready.  If large numbers of our users are
>> going to
>> have a bad experience with jessie as a result of being switched to
>> systemd,
>> then we should take appropriate steps to address that, even if that means
>> unfreezing the installer.
> 
> Sure. But where is the evidence for that? Is there a bug that has been
> agreed upon to be RC?

Whoever upgrades their lxc guests without taking further informed action
(such as switching back to sysv), will not be able to start their LXC VM
at the next reboot( #766233 [1]).

This is currently classified as "a bug which has a major effect on the
usability of a package, without rendering it completely unusable to
everyone." and thus not RC, so if being RC is currently the precondition
to fix stuff in jessie, then you are right.

Unless at least respective documentation gets included in the release
notes (#762194 [2]) I think there will be some future unhappiness.

At this moment it's a trap waiting to be walked into.
*t

[1] http://bugs.debian.org/766233
[2] https://bugs.debian.org/762194


-- 
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/547c9de8.5020...@sourcepole.ch

Re: DE features dependent on Systemd

[Tomas Pospisek]

Am 06.12.2014 um 00:55 schrieb Svante Signell:
> On Fri, 2014-12-05 at 15:22 -0800, Russ Allbery wrote:
>> Svante Signell  writes:
>>> On Wed, 2014-12-03 at 16:55 +, Simon McVittie wrote:
 On 03/12/14 14:46, Svante Signell wrote:
>>
> If more granularity is needed, what's hindering introduction of even
> more groups: like an image group and splitting the fb0 to more devices?
> Or even subdirectories like /dev/snd/* for audio etc.
>>
 This does not actually solve the same problem as logind's "uaccess", or
 ConsoleKit's "udev ACL" (which was an older version of the same general
 idea): it just splits it up into a larger number of orthogonal instances
 of the same problem, which is that group membership makes a poor
 encoding for temporary permissions.
>>
>>> Have you ever heard about openafs?
> 
>> When NFSv4 development
>> sparked the modern Linux keyring data model, we were delighted to switch
>> (and then got very frustrated by the GPL-only tags on various keyring
>> features, but that's another argument).
> 
> So I wish you a happy life with current (Debian chosen) technology, it
> is perfect! No more problems with bugs popping up or people being unable
> to boot their desktop computers/servers. Merry Christmas :) 

So in apparently yet another tantrum you threw a buzzword ("OpenAFS") in
the face of the audience, Russ actually managed to (miraculously) make
sense of seeing that single word, answered and explained in detail. And
the reply you produce is yet more polemic and snide and there's not a
single (!) word of appreciation and acknowledgement of the argument of
yours that Russ put in perspective or maybe refuted?

It makes the impression on me that your goal is to prevent systemd by
whatever means available you. It seems to be a holy grail of yours:
total destruction of systemd and all of its misguided "followers".

You very much make the impression of an adrenaline saturated teenager
having realized that everything is the adults' fault. And now the
anti-systemd religion has enlightened you and you are glowing with the
joy of knowing that you are ready to die for THE TRUTH.

Sure it's worth destroying, wearing out, burning out all those idiots
blinded by Satan-d if they are not ready to convert to the one and only
TRUTH, right? You can not get out of this Jihad until the reign of Go-d
is reinstalled on earth, right?

Is my impression correct?

If you are unable to realize the problem with acting like this, then I'd
rather put you in a killfile and wait a few years for the adrenaline to
level down and to allow for balanced thoughts about the Linux landscape
again.

I've ddg'd a bit but was unable to find a killfile for Thunderbird yet.
Does anybody know of such functionality for Thunderbird?

*t

PS: Initially I was happy to see a person (you) contribute to #762194 to
try to move it further, but given your seeming inability to finding
consensus I think the only effect of your contributions there is driving
the participants' adrenaline up and thus clouding their ability to
decide in a calm, thoughtful and differentiated manner.


-- 
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/5482dea7.3030...@sourcepole.ch

Re: DE features dependent on Systemd

[Tomas Pospisek]

Am 06.12.2014 um 13:39 schrieb The Wanderer:
> On 12/06/2014 at 05:47 AM, Tomas Pospisek wrote:
> 
>> Am 06.12.2014 um 00:55 schrieb Svante Signell:
>>
>>> On Fri, 2014-12-05 at 15:22 -0800, Russ Allbery wrote:
> 
>>>> When NFSv4 development sparked the modern Linux keyring data
>>>> model, we were delighted to switch (and then got very frustrated
>>>> by the GPL-only tags on various keyring features, but that's
>>>> another argument).
>>>
>>> So I wish you a happy life with current (Debian chosen) technology,
>>> it is perfect! No more problems with bugs popping up or people
>>> being unable to boot their desktop computers/servers. Merry
>>> Christmas :)
>>
>> So in apparently yet another tantrum you threw a buzzword ("OpenAFS")
>> in the face of the audience, Russ actually managed to (miraculously)
>> make sense of seeing that single word, answered and explained in
>> detail. And the reply you produce is yet more polemic and snide and
>> there's not a single (!) word of appreciation and acknowledgement of
>> the argument of yours that Russ put in perspective or maybe refuted?
>>
>> It makes the impression on me that your goal is to prevent systemd
>> by whatever means available you. It seems to be a holy grail of
>> yours: total destruction of systemd and all of its misguided
>> "followers".
> 
> I don't think this last is entirely fair; I don't think (she?)'s
> interested in the total destruction of systemd, only in restoring it to
> a niche off in the metaphorical corner - to a status of "if you want to
> use it yourself, or advocate for others to use it, feel free - but don't
> do anything that makes it harder for others *not* to use it".

Might be you're right, and I've exagerated yet once again.

> Which I would actually agree with, albeit not with the type of vocal
> attitude towards it which (she?) apparently brings to the table. I like
> to think I'm both more rational and more reasonable than that.
> 
>> I've ddg'd a bit but was unable to find a killfile for Thunderbird
>> yet. Does anybody know of such functionality for Thunderbird?
> 
> Tools -> Message Filters. I don't use it for killfile purposes in
> E-mail, but I've used it that way (in "mark read" form, at least) on
> Usenet, with reasonably good effect.

Thanks a lot,
*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/5483812d.6030...@sourcepole.ch

Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

[Tomas Pospisek]

Am 18.01.2015 um 17:41 schrieb Andreas Tille:
> On Sun, Jan 18, 2015 at 01:07:35PM +, Mark Brown wrote:
>> On Sun, Jan 18, 2015 at 10:09:34AM +0100, Andreas Tille wrote:
>>> On Fri, Jan 16, 2015 at 04:48:33PM +, Steven Capper wrote:
>>
 we have had no discussion
 over #773359; your response is effectively placing words in my mouth
 and I will not tolerate that. To confound matters, I wasn't even CC'ed
 in on the response!
>>
>>> Usually it is expected that the maintainer receives every posting to the
>>> bugs of the package he maintains.  So there was no real point to add an
>>> additional CC.
>>
>> The followups were sent to -submitter which unfortunately explicitly
>> doesn't CC the maintainer (I guess the main intended use case is for the
>> maintainer to talk to the submitter), an extra CC needs to be added to
>> include the maintainer.
> 
> OK, that's a bit unfortunate.  On the other hand the fact that Steven as
> maintainer did not checked the bug log of an RC bug for nearly one month
> (and he received the original bug report) remains a good reason for
> anybody else who is interested in the Jessie release to react.

I think the semantics of x...@bugs.debian.org are very unfortunate. My
*intuition* is always making me believe that everything sent to
bugnum...@bugs.debian.org should go to /everbody involved in the
bugreport's thread/.

But that's no so.

>From that fact stem (as far as my understanding goes) a lot of rules who
gets what when sending email to bugnumber-someth...@bugs.debian.org.

And additionally there's the subscription to a bug as well.

I have regularly problems with people posting to bugreports I'm
participating in, that I don't get, because I'm not subscribed to them
(so now I should be managing subscriptions to all bugs I've ever
participated in...) or because reporters didn't write to the right
bugnumber-***@bugs.debian.org and Cc: addresses, or because they didn't
care or because...

That's bad, because - as shown in the thread off which this posting is
forking off - reasoning about and discussion in bugreports fades off
into interpretations about why one did or did not get an email and
that's not helpful when dealing with potentially (emotionally) sensitive
bugs.

I guess, changing semantics of bugnumber[-something]@b.d.o yet again
will not be considered. But I think a lot of unnecessary friction stems
from the unclear or unintuitive or "not defined where people would see
them" semantics.

I do not want this observation be understood as a critique of the people
who are involved in the creation of those rules. There might be many
reason for them being so, many of which I have no insight into (but I am
certainly appreciating that work very much).
*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/54bc1734.5050...@sourcepole.ch

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

[Tomas Pospisek]

Am 19.01.2015 um 02:03 schrieb Ben Hutchings:
> On Mon, 2015-01-19 at 08:37 +0800, Paul Wise wrote:
>> On Mon, Jan 19, 2015 at 8:06 AM, Don Armstrong wrote:
>>
>>> I'm going to put together a bit more firm of a proposal in the next few
>>> weeks, but I think that basically everything but nnn-done@ and
>>> nnn-submitter@ should be no different from mailing nnn@, and until I
>>> allow submitters to opt out of e-mail, mailing nnn-submitter@ should be
>>> no different from e-mailing nnn@ either.
>>
>> I'd very much appreciate the ability to not be auto-subscribed to
>> every bug so please do implement the opt-out thing, preferably before
>> this change is rolled out.
>>
>> Personally, I think subscriptions should work like this:
>>
>> The default should be to auto-subscribe submitters and contributors to bugs.
> [...]
> 
> No, this would turn the BTS into a (worse) spam vector.
> 
> But the acknowledgement mail should tell you how to subscribe, if you
> aren't already subscribed.

But isn't subscribing participants "natural"? Posting to a bug report
means participation and thus you'd get the follow-ups. Why would you
post to a bug report if you aren't interested in what happens with it,
how things proceed/evolve?

I can understand your point of view and I think also the why but isn't
that position the exception from the rule? That is shouldn't the process
be optimized for the "common" case and allow the exception?

Technically the exception could be implemented by adding a further
pseudo header to the message body:

  Subscribe: false

Another technical solution could be as noted in a different mail in this
thread to allow submitters to set a global flag that says don't
automatically subscribe me on participation.

?

Thanks
*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/54bcc865.4090...@sourcepole.ch

Re: jessie not mounting all filesystems

[Tomas Pospisek]

Am 29.01.2015 um 20:52 schrieb Daniel Pocock:

> I just upgraded a system with many filesystems to jessie
> 
> On many occasions when I boot this system it is failing to mount one of
> the filesystems and systemd gives the emergency login prompt
> 
> It is not always the same filesystem though, it seems to be random.
> Most are ext4 on LVM, there are a couple of BtrFS.
> 
> In every case I've been able to log in, fsck the filesystem and mount it
> manually.
> 
> Is there any problem that anybody is already aware of?
> 
> Looking at journalctl output I couldn't see any reason why the mount
> failed, do I have to enable something else to get more helpful log data
> about the problem?

Hearing this, the first thought that came to my mind is: timeouts.

Maybe systemd is trying to mount the FS's in parallel or maybe you get
contention on IO buffers and stuff takes too long for systemd's taste
and it switches into the "sky is falling" mode? (As can be seen from the
wording I have no solid knowledge of the real workings of that system).

*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/54cb4a3c.2040...@sourcepole.ch

Bug#777700: (no subject)

[Tomas Pospisek]

reassign 00 linux-image-3.2.0-4-amd64
thanks

Since Debian is preparing to release the next version of its distribution 
I guess that the linux-image-3.2.0-4-amd64 from the Debian wheezy 
distribution will very probably not ever backport support for and thus 
autodetect your RTL8723AE wireless lan card.


As such I think this bugreport could be closed as is, since there's 
nothing else to do.


What you, perihana, could however do, is to test the coming "Debian 
jessie" release whether it works with your card.


You can find installation and live media for that purpose here:

https://www.debian.org/CD/

Please report back on whether you had success with your card with jessie

Alternatively you could try a backports kernel and respective realtek 
firmware, which *does* support your card:


https://packages.debian.org/wheezy-backports/firmware-realtek

Please let us know, thanks,
*t

perih...@openmail.cc wrote on 2015-02-11:


Package: general
Severity: important

i have a laptop toshiba sattelite pro C850 - 1HG with the
RTL8723AE wireless lan card. Problem: Wireless Lan card not detected by 
kernel


-- System Information:
Debian Release: 7.8
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


*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/alpine.DEB.2.11.1502111734420.5972@hier

Re: Should we mark #388141 as jessie-ignore?

[Tomas Pospisek]

Am 13.02.2015 um 21:15 schrieb Riley Baird:
> On Thu, 12 Feb 2015 21:16:39 +0100
> Tomas Pospisek  wrote:
>> Am 12.02.2015 um 20:59 schrieb Riley Baird:
>>
>>> Bug #388141 [RC] refers to the relicensing of the debian www pages.
>>> After contacting debian-www, it seems that there isn't much interest in
>>> fixing it.
>>
>> I interpret the relative silence in #388141 differently then you. I'd
>> say that everybody is busy with doing other stuff. So if you want the
>> state of affairs to change, just go after it, bit by bit. As you
>> describe here:
>>
>>> The next step would involve compiling a list of website
>>> lines which are still active yet which relicensing permission has not
>>> been received.
>>
>> And then just ask for permission, line by line.
> 
> Surprisingly not! Everyone who has been contacted has already been contacted. 
> The reason for collecting these lines is that we need to determine whether 
> the lines in question are copyrightable, and whether they are still in use.
> 
>> In the end I think it's work and if it should be accomplished then
>> someone has to do that work. Since you are interested, just go and hit
>> the work, it may well be that people will join or help you along the way.
> 
> I've always been happy to do the work, but I thought that access to the wiki 
> databases was necessary to compile such a list. Or is it possible to compile 
> such a list with just a user account on the wiki?

I'm not sure I really understand what you want to do.

Is something like this:

  https://wiki.debian.org/LXC?action=info

not what you need?
*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/54e22944.2030...@sourcepole.ch

Re: setlocale doesn't change the language. Why?

[Tomas Pospisek]

Am 12.03.2015 um 06:50 schrieb Joerg Desch:
> Am Wed, 11 Mar 2015 21:16:20 +0500 schrieb Andrey Rahmatullin:
> 
>> On Wed, Mar 11, 2015 at 01:27:21PM +, Joerg Desch wrote:
>>> Switch to 'en'
>>> New LOCALE: 'C'
>>> Hello World Switch to 'de'
>>> New LOCALE: 'C'
>>> Hello World
>> So these cases are expected to you?
> 
> No. I expect the same output as shown by the other example. I expected 
> that either "de_DE" or "de_DE.UTF8" should fit.
> 
> 
>> You don't have 'de.utf8' locale on this system.
> 
> How can I check which locales are available?

/etc/locale.gen

Also 'man locale'
*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/55014e4d.8030...@sourcepole.ch

Bug#787239: Too little specific information in bug report

[Tomas Pospisek]

Hello Shaman,

I'd suggest you go to a debian support channel to discuss/solve your 
problem:



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

As is your bug report contains far too little specific information (for 
example - what init system are you using?) to be able to meaningfully act 
on it.


If you are able to make some progress on your problem then please report 
back to this bug report and/or close it.


Thanks,
*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/alpine.DEB.2.11.1506040931280.5760@hier

Bug#787239: Too little specific information in bug report

[Tomas Pospisek]

reassing 787239 systemd
thanks

This email is going Bcc: to control@b.d.o - now on to further feedback:

Hello Shaman,

On Thu, 4 Jun 2015, Shaman wrote:


"what init system are you using?" - carefully look above: "Init: systemd (via 
/run/systemd/system)"


Ah, sorry, I didn't look carefully before...


After hang PC I can reboot only through press "Reset" button. After boot I see 
in log only last boot info.

I noticed that if before start GDM Manager I login to Console mode and 
enter 'reboot' command, then reboot success, but if GDM Manager start 
and press CTRL+ALT+F1 and login to Console mode and enter 'reboot' 
command then reboot process hang ;(


I don't know how to diagnose this problem...


This looks like a systemd problem so I am reassigning it to the systemd 
package.


What you can do is to look at the allready existing "reboot" bug reports 
against systemd (search for "reboot" on those pages):


  https://bugs.debian.org/systemd
  https://bugs.debian.org/systemd-sysv

In particular the following bug reports:

  https://bugs.debian.org/776171
  https://bugs.debian.org/780636
  https://bugs.debian.org/756725
  https://bugs.debian.org/763028

Are they similar to yours?

Is it maybe the same problem and thus this bug report can be merged with 
an existing one?


The bug reports contain some infos about how the reporters should go about 
(or went about) debugging their problems. Can you use that knowledge to 
further analyse your problem?


Greets,
*t


--

Hello Shaman,

I'd suggest you go to a debian support channel to discuss/solve your
problem:


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

As is your bug report contains far too little specific information (for
example - what init system are you using?) to be able to meaningfully act
on it.

If you are able to make some progress on your problem then please report
back to this bug report and/or close it.

Thanks,
*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/alpine.DEB.2.11.1506041225070.7922@hier

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

Re: Bug#765953: Wifi issues. Firmware package not fixed in testing release

[Tomas Pospisek]

Am 10.06.2015 um 19:10 schrieb Acommon LinuxUser:
> Hi,
> I submitted a bug about 8 months ago, but I didn't receive any reply. I
> updated my Debian system to the testing release ("stretch") because a
> new version of the firmware-realtek package has been released for it,
> but it didn't solve the issues.
> This is the link to the reported bug:
> 
> https://lists.debian.org/debian-kernel/2014/10/msg00413.html
> 
> Since I didn't receive any response I would know if I made some mistake
> in the bug report or if the bug is not related to the firmware package,
> and so I ask to you for a suggestion about the Debian team to which
> forward the bug.

The problem with your bug report is, that it does not contain any
actionable information. It says "it doesn't work", but doesn't say what
the circumstances are, what "work" would look like, what exactly you are
doing etc.

Some informations that would be useful:

- what does "the wireless interface fails" mean? You can't ping an
  IP address? You can't ping your router? If you look at interface
  statistics, then you see they are not changing? The interface is
  physically off? And so on.

- what brand and type is your wifi *exactly*

- how do you "shutdown" and "restart" your wifi interface?

- what do the relevant logs say (kernel log, system log)

And so on.

I think it would be best if you'd contact some Debian support
channel where people can potentially guide you along. I suggest:


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

*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/55796de2.3010...@sourcepole.ch

Re: Xen PVUSB - Debian 8

[Tomas Pospisek]

Am 16.06.2015 um 11:19 schrieb pietrop:
> Hi all,
> 
> I am trying to setup a Debian 8 machine running XEN, which I've
> installed from the package manager, to use the USB passthrough.
> 
> It looks like I need to use the module xen-usbfront and xen-usbback,
> which I can't find in the /lib/modules/(my kern)/*
> 
> 
> Are there ways to get around this ?

This is possibly not the right list to ask this question. You could try on:

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

But probably it's better to go to an even more specialized list f.ex.
for sysadmins or for Xen itself.
*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/5581d694.3060...@sourcepole.ch

Re: Status on ddeb support in Debian

[Tomas Pospisek]

May I suggest you add:

What is it?
===

* ddeb's are Debian packages with the extenstion .ddeb that
  contain debugging symbols and are built implicitly.
  - A package foo_1.23.deb will receive a corresponding
foo_1.23-dbgsym.ddeb package.
  - ddebs are built automatically by dh_strip.

Or such. The above info is deduced from random bits. I haven't
really read the whole thread closely, so my blurp above might
be wrong.
*t

Am 29.06.2015 um 18:17 schrieb Niels Thykier:
> Here is another short update on ddeb support in Debian.
> 
> What is missing?
> 
> 
>  * Only known blocker is missing archive/dak support.
> 
>  * Once DAK support is implemented, I intend to enable ddebs
>unconditionally in debhelper.
> 
> Where are we?
> =
> 
>  * debhelper in unstable can now build ddebs - disabled by default.
>- Test with env DH_BUILD_DDEBS=1, but please don't upload ddebs to
>  any Debian archive.
> 
>  * lintian gives no remarks to the new ddebs.
> 
>  * dh_strip can now be asked to /not/ build ddebs, if your package for
>some reason cannot use them.
>- Known cases are: linux (build-id based debug symbols not supported)
>  and possibly other kernels
> 
> 
> How can I help?
> ===
> 
>  * Please review the documentation in dh_strip(1) and help me improve it
>where needed.
> 
>  * [Toolchain maintainers] If you maintain that might need to handle
>ddebs /differently/ than a regular ddeb (e.g. reprepro), please
>look into implementing that.
> 
>  * [Derivatives] Please consider upgrading your infrastructure /
>tooling if/where needed.
> 
> FAQ
> ===
> 
>  Q: What if my distribution/use-case is ready to build ddebs?
>  A: Please import debhelper 9.20150628 with the attached patch
> cherry-picked.
> - Note, if your developers/users moonlight as DDs, please remind
>   them to build their Debian packages in a clean unstable chroot
>   with the regular debhelper! They should be doing that already,
>   but a reminder cannot hurt.
> 
>  Q: What happens if I upload a ddeb to unstable?
>  A: Either dak unconditionally rejects your upload (if you are lucky)
> OR it ends up in NEW (if you are unlucky).  Note that once your
> package is in NEW, subsequent upload will /also/ end up in NEW.
> Even if they do /not/ include the ddeb package.
> 
> Thanks,
> ~Niels
> 
> 


-- 
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/5592270f.7080...@sourcepole.ch

Re: Bug#790933: ITP: drive - Google Drive tool

[Tomas Pospisek]

Am 05.07.2015 um 09:15 schrieb Jackson Doak:
> It might be possible to rename the binary and symlink "drive" to it,
> which would allow you to give the binary name over easier


Top-posting in a thread breaks the flow of the messages - as you can see
here.

The way to go here would be the alternatives mechanism, which serves
this purpose.
*t

> On 5 Jul 2015 9:11 am, "Clint Byrum"  > wrote:
> 
> Excerpts from Joachim Breitner's message of 2015-07-04 13:45:40 -0700:
> > Hi,
> >
> > Am Samstag, den 04.07.2015, 17:16 +0200 schrieb Sophie Brun:
> > > Le 03/07/2015 21:46, Guillem Jover a écrit :
> > > > drive is an extremely generic name in tech, please use something
> > > > else
> > > > when packaging this, both for the source/binary packages and the
> > > > executables and other related files. Prefixing it with «google-»
> > > > could
> > > > be an option, perhaps. Doing this upstream would be preferable.
> > >
> > > I followed your suggestion and opened this issue:
> > > https://github.com/odeke-em/drive/issues/271
> > > But upstream doesn't seem to be agreed. What do you suggest?
> >
> > you are free to choose your source and binary package name independent
> > from upstream’s choice. For example, all Haskell packages are named
> > haskell-foo, where upstream calls it just foo. So let upstream do what
> > he likes and do what you think is best within Debian with the Debian
> > package.
> >
> 
> Indeed. However, they've selected 'drive' as their binary command name..
> so following upstream's rather unfortunate namespace grab might actually
> be the right way to go, to make sure it's clear 'this is the package
> that owns drive in the execution path'.
> 
> 
> --
> 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/1436050805-sup-4...@fewbar.com
> 


-- 
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/559997c1.7090...@sourcepole.ch

Re: BUG: Debian Jessie as KVM guest on GlusterFS backend

[Tomas Pospisek]

Hello Roman,

debian-devel is not the right place to ask support questions. Please try
any of Debian's official support channls:


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

*t

Am 14.07.2015 um 11:16 schrieb Roman:
> Hi,
> 
> I'm having problems with installing D8 as KVM guest on GlusterFS storage
> backend.
> I run 4 different proxmox (debian based with RH kernel) nodes and got
> this problem on every of them.
> 
> Versions:
> 
> qemu-server: 3.4-6
> pve-qemu-kvm: 2.2-10
> glusterfs-client: 3.6.4-1
> 
> No matter what I do, I'm not even able to complete the installation
> process, it stops on random step:
> 
> 1. on mirror select (just suddenly says, that mirror is not accessible
> or there is no right version of Debian located)
> 2. on package installation step (just says that it is not able to solve
> deps as some pkg was not configured, usually it is python-gtk2 or smt
> like that).
> 
> Once I was lucky enough to install the base system, but ended up with
> unstable system: apache did't run due to missing modules, while they
> were at their places, seemed to me like corrupted. Also it seems to me,
> that files are getting corrupted while installed on glusterfs storage
> backend.
> 
> I can install D8 on local storage without problems. 
> 
> There are no error logs on glusterfs side.
> 
> Debian 7 installs and runs fine. Ubuntu 14.04 LTS installs and runs
> fine. Centos 6 installs an runs fine.
> 
> Any ideas? This has to be solved somehow. I'm also in contact with
> GlusterFS users list and wrote to devel list, but was not able to solve it.
> 
> I used glusterfs 3.5.4 before, was the same problem.
> 
> Where should I report this issue to get it solved? 
> 
> -- 
> Best regards,
> Roman.


-- 
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/55a60010.5070...@sourcepole.ch

Re: Bug#798202: ITP: fonts-leckerli-one -- Leckerli One font

[Tomas Pospisek]

The URL entry below is broken.
*t

Am 06.09.2015 um 20:05 schrieb Gioele Barabucci:
> Package: wnpp
> Severity: wishlist
> Owner: Gioele Barabucci 
> 
> * Package name: fonts-leckerli-one
>   Version : 2011
>   Upstream Author : Gesine Todt
> * URL : 
> http://www.example.org://www.google.com/fonts/specimen/Leckerli+One
> * License : OFL-1.1
>   Description : Leckerli One font
> 
> Leckerli One is a free Open Type font designed by Gesine Todt.
> It is a fat display typeface with irregular brush shapes and a
> handwritten feeling.
> 

Bug#922712: general: Freezing on log-in screen when booting laptop on battery power

[Tomas Pospisek]

Hi,

the main problem here is that you are reporting the problem against 
"general", since that will probably not lead to the bug being acted upon.



"Hewlett Packard Pavilion g6 2239-sr reffered as "laptop" later
after clean Debian stable install (with Xfce DE, but i assume it's not 
important as it has problems with most if not all DEs)

and instalation of "firmware-linux" metapackage and tlp


What does "tlp" mean?

The outcome was that it rendered system unusable when booting on battery 
power, as it freezed system on Log-in screen with slight graphical 
glitches appearing on screen like broken mouse cursor/pointer/arrow as a 
mess of ASCII characters (not letters but symbols rather) and the part 
of input field(s) becomes a little bigger than another making a slight 
aliasing effect


* does the problem not happen when connected to power?
* when you switch back to CTRL-ALT-F1, do you get to the login prompt?

I assume that the problem is with the graphics system. Can you please find 
out what graphics driver is being used? Have a look at 
/var/log/Xorg.0.log.


Do you see any problems reported there?

Once you have determined what graphics driver is being used, then can you 
please find out to which package that driver belongs and reassign this bug 
report to the relevant package? Better yet, make a new bug report against 
the respective graphics driver package, since that should collect a lot more 
informations and add them to the report. Once you have created the new bug 
report, then please merge this bug report with the newly created bug 
report.


Did you google around for the type of your laptop and the graphics chip 
whether there are maybe other bug reports and or solutions?

*t

Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

[Tomas Pospisek]

Am 25.06.19 um 08:08 schrieb Ansgar:

> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes?  We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
> 
> Related to that I would like to be able to write something like
> 
>   deb http://deb.debian.org/debian debian11 main
>   deb http://security.debian.org/debian-security debian11-security main
> 
> in sources.list as codenames confuse people.
> 
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).

TLDR; year based release identifiers should be prefered since they are
much more intuitive to reason about than codenames and sequentialy
numbered release identifiers.

If Debian should improve/change release identifiers, then I'd suggest to
ponder a year based versioning scheme (as Ubuntu is using).

As others here I am starting to get confused by the release code names,
as are my peers that are not that much into Debian. And sequential
release numbers are devoid of any semantics except for their
monotonically increasing character.

On the other hand, using year numbers as release identifiers has the
advantage of:

* getting rid of the need to remember arbitrary names and their sequence
* being linked to and rooted in everyday human experience, which makes
it intuitive and easy to reason about releases

When reasoning about an installation of Ubuntu "14.04" one can easily
come to the conclusion, that it's probably wise to upgrade, that release
being 5 years old, whereas an "16.04" might still smell reasonably fresh
and is probalby still OK to run.

Let's seriously consider using year based release identifiers.
*t

Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

[Tomas Pospisek]

Am 29.06.19 um 14:41 schrieb Jeremy Stanley:
> On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote:
> [...]
>> As others here I am starting to get confused by the release code
>> names, as are my peers that are not that much into Debian. And
>> sequential release numbers are devoid of any semantics except for
>> their monotonically increasing character.
> [...]
> 
> And yet you *wouldn't* be confused when Debian 2019.7 is released in
> 2021?

That's right, I don't think that'd confuse me. The reason it wouldn't
confuse me, is that I expect releases to be updated eventually and that
can happen at any time in the future - f.ex. in 2021.
*t

Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

[Tomas Pospisek]

Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin:
> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote:
>> TLDR; year based release identifiers should be prefered since they are
>> much more intuitive to reason about than codenames and sequentialy
>> numbered release identifiers.
>>
>> If Debian should improve/change release identifiers, then I'd suggest to
>> ponder a year based versioning scheme (as Ubuntu is using).
> This only works with Ubuntu because they set the release date in advance.

You assign the year to the release identifier when the release is ready:
release_id = now().year(). There's certainly some infrastructure stuff
that needs that release_id that needs to be prepared in advance, but I
think that can be done pragmatically, when the release is "99%" ready.
Am I missing something?
*t

Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

[Tomas Pospisek]

Hi,

Am 29.06.19 um 23:32 schrieb Thomas Goirand:
> On 6/29/19 3:33 PM, Tomas Pospisek wrote:
>> Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin:
>>> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote:
>>>> TLDR; year based release identifiers should be prefered since they are
>>>> much more intuitive to reason about than codenames and sequentialy
>>>> numbered release identifiers.
>>>>
>>>> If Debian should improve/change release identifiers, then I'd suggest to
>>>> ponder a year based versioning scheme (as Ubuntu is using).
>>> This only works with Ubuntu because they set the release date in advance.
>>
>> You assign the year to the release identifier when the release is ready:
>> release_id = now().year(). There's certainly some infrastructure stuff
>> that needs that release_id that needs to be prepared in advance, but I
>> think that can be done pragmatically, when the release is "99%" ready.
>> Am I missing something?
>> *t
[...]
> 
> In some software we have in buster, they already have hard-wired the
> names of the 2 next Debian releases. How would you do this with years if
> we don't know the release dates in advance?

Allow me to start with the inverse question: should the fact that
software makes assumptions about the future preclude humans from shaping
that future as they deem best?

Now what if there was a way to have both: a better naming scheme *and*
compatibility with software that hard codes the future?

Lets see - one possibility would be to have both year based release
identifiers and code name based ones. That could possibly solve both
issues (better naming + compatibility).

Or maybe there are yet other ways to solve the supposed contradiction?
F.ex. updating the hard-coded SW comes to my mind.

> Besides this, I very much dislike the way it sounds. :)

The way what sounds?
*t

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

One more question. When you say VNWare integrated product. AFAIK vmware 
have their own networking module in the kernel? Can you reproduce this 
with some other virtualisation technology like kvm, qemu?


And one more question: do depending on who does the DHCP receival in the 
VM (systemd? isc-dhcp-client? [...]?): shouldn't there be some rate 
limiting sanity check in the DHCP client?

*t

On Tue, 23 Jul 2019, Tomas Pospisek wrote:


Package: general
Followup-For: Bug #932769

Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.

Is it possible to reduce the problem to something easily demonstratable?

This seems to be an important issue to me.

I think the problem here *might* be a kernel problem? Re-assign this to
kernel package?

When you say that it DoS'es the server then what does "top" say? What is
being DoS'ed? Is it the CPU?
*t

It would be truly cool, if you could provide more infos.
*t


To: Debian Bug Tracking System 
Subject: general: DHCP request bug when storage lost
Date: Mon, 22 Jul 2019 14:48:00 -0600

Package: general
Severity: important
Tags: l10n

Dear Maintainer,

While doing unrelated storage testing for our VMware integrated product, we 
purposefully recreated
a storage outage by removing the iSCSI initiators from the backing array 
hosting the vmdk disk
images for the virtual machine.

Upon removal of uplinks to storage, the VM goes into a R/O file system state 
after 5-10 minutes.
When storage initiators are brought back up and the LUNs are rescanned, the VM 
begins to
rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server in 
a way due
to the number of DHCPDECLINE errors, and the interface attempts to take and 
discard IP's in a
rapid fashion.

This only seems to appear on this distribution, and I can't replicate the 
behavior on Debian 9
or in a desktop environment.



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled






-- System Information:
Debian Release: 10.0
 APT prefers stable
 APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

Package: general
Followup-For: Bug #932769

Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.

Is it possible to reduce the problem to something easily demonstratable?

This seems to be an important issue to me.

I think the problem here *might* be a kernel problem? Re-assign this to
kernel package?

When you say that it DoS'es the server then what does "top" say? What is
being DoS'ed? Is it the CPU?
*t

It would be truly cool, if you could provide more infos.
*t

> To: Debian Bug Tracking System 
> Subject: general: DHCP request bug when storage lost
> Date: Mon, 22 Jul 2019 14:48:00 -0600
> 
> Package: general
> Severity: important
> Tags: l10n
> 
> Dear Maintainer,
> 
> While doing unrelated storage testing for our VMware integrated product, we 
> purposefully recreated
> a storage outage by removing the iSCSI initiators from the backing array 
> hosting the vmdk disk 
> images for the virtual machine.
> 
> Upon removal of uplinks to storage, the VM goes into a R/O file system state 
> after 5-10 minutes.
> When storage initiators are brought back up and the LUNs are rescanned, the 
> VM begins to 
> rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server 
> in a way due
> to the number of DHCPDECLINE errors, and the interface attempts to take and 
> discard IP's in a
> rapid fashion. 
> 
> This only seems to appear on this distribution, and I can't replicate the 
> behavior on Debian 9
> or in a desktop environment.
> 
> 
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled





-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: Notes on packaging PCYNLITX

[Tomas Pospisek]

Hi,

I have a few rather higher level questions about PCYNLITX.

* are there any known users of PCYNLITX, in the sense of, does
  there exist an application, that actually uses PCYNLITX?

* I have read through the web page of PCYNLITX. I can not
  make up my mind. The web page is talking about how well
  documented PCYNLITX is, but there's no code examples of
  how PCYNLITX is used, as far as I could find. Without
  that it's too hard for me to make up my mind about it.
  I find the concept interesting, but without seeing
  code - hmmm...

?
*t

Am 12.07.19 um 08:52 schrieb Bagas Sanjaya:
> Hello,
> 
> I've filed RFP for PCYNLITX sometimes ago [1]:
> 
> In PCYNLITX download page [2], it can be installed by using installation 
> script. However, after examining install
> script, I noticed following:
> - PCYNLITX doesn't employ version numbering like any other project/packages. 
> It would be difficult to identify
> which is the latest version. So I use version number 0.0~git20190606 in RFP 
> report.
> - The script install wxWidgets library from third-party repository, not from 
> Debian. It use codelite repo (for Stretch):
>> apt-add-repository 'deb http://repos.codelite.org/wx3.0.4/debian/
>> stretch libs'
> - Evince will be installed as runtime dependency, possibly for documentation. 
> For non-GNOME users (KDE, XFCE, etc.)
> which use different readers (like Okular and Atril) this can bloat their 
> system and become unnecessary.
> - All steps are performed using sudo. If the script is run by root user, this 
> will be redundant, since the installation
> is done by root privileges.
> 
> If I will packaging PCYNLITX for Debian, any suggestions, assuming that I 
> have read New Maintainers Guideline and
> related Debian packaging documentation?
> 
> Cheers, Bagas
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931400
> [2]: http://www.pcynlitx.tech/the-installation-of-pcynlitx/
> 
> -- 
> An old man doll... just what I always wanted! - Clara
> 

Re: Comparing/Using Conda with Debian

[Tomas Pospisek]

Am 11.07.19 um 06:53 schrieb Steffen Möller:

> On an project-internal mailing list the thread "Conda vs Debian"
> [etc.]

What's Conda?
*t

Bug#931296: general: Camera flash drive mount does not show up on desktop

[Tomas Pospisek]

Package: general
Followup-For: Bug #931296

Hi Roger,

Roger wrote:

> Plugging in camera in Buster does not show flash storage on desktop as
> it did in previous versions with Xfce DE.

There was no reply to this bug report. The problem is, that debugging
this involves some work, which you need to do. Such as going through
the logs on your machine and trying to see whether there's some
interesting info there related to the problem you are seeing.

Also googling around if you find some reports about this problem on the
net might be useful.

Without that info this bug report will have to be closed, since
there's not much we can do.
*t

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

So my interpretation of your initial bug report, that the VM would DoS the 
host on which it was running via fast changing of IP addresses on its 
interface was completely off the track?


So what you wanted in fact wanted to say by "DoS'ing the server" was that 
the VM sends huge amounts of DHCP requests to the DHCP server (possibly 
also in addition depleting IP addresses from the DHCP server's IP address 
pool) and *that* amounts to a DoS? Is my interpretation correct?


If that's the case, then I'm reassinging this bug report to 
isc-dhcp-client and merging it with the mentioned bug report #888209.


*t

On Tue, 23 Jul 2019, Mark Hutchison wrote:


Hi fellas,
Apologies for the brevity in the initial bug report.  I was using the reportbug 
tool directly from the console of the VM I was working on, small resolution.  
Allow me to elaborate...

We initially discovered this bug testing our storage product, we had a Debian 
10 VM running in a typical ESXi 6.7 environment with iSCSI backed storage.  The 
VM ran in a VMDK file on a VMFS datastore volume.  While the
VM was running in memory, we removed the storage initiators from ESXi 
purposefully to test something unrelated, to simulate a storage outage.  After 
a couple of minutes the OS will go into R/O mode without its disk,
and at that time dhclient will rapidly request IP's from our ISC DHCP server.  
dhclient will take the IP, consume it from the DHCP pool and then request 
another.  After some period of time this depletes the DHCP pool,
several hours to days depending on the scopes size.  This could also be 
replicated by deleting the hard disk from a running VM in a virtual environment.

When I look at systemctl for the dhclient service, I can see that there's an error, "can't 
create /var/lib/dhcp/dhclient.intname.leases Read Only file system", and then the 
DHCPREQUEST > DHCPACK > DHCPDECLINE sequence
starts every few seconds, and occasionally the service will show "RTNETLINK answers: 
File Exists."

I'm guessing from the error that dhclient has a problem with not being able to 
read / write to the client leases file, declines the IP and requests another, 
but secretly holds on to the IP.

The DHCP server logs will show a final DHCPDECLINE after the ACK, and mark the 
address as abandoned.  The VM will still have the address leased however.  
After a period of time VMware's guest tools will show all the
consumed IP's belonging to that MAC address and virtual interface.  Network 
gear ARP shows the IP's belonging to the same MAC as well.

We've consistently reproduced this bug in our lab, and performed the test 
simultaneously with a Debian 9, Centos and Ubuntu 16 instance to make sure it 
wasn't some kind of NetworkManager thing, or a broader Linux
issue.  

I see that someone reported this similar bug back in 2018 as well, I think they 
may be the same thing.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888209

Thanks, just let me know if you have any questions.



On Tue, Jul 23, 2019 at 4:23 PM Tomáš Pospíšek  wrote:
  Am 23.07.19 um 17:57 schrieb Ben Hutchings:
  > On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
  >> Package: general
  >> Followup-For: Bug #932769
  >>
  >> Could you privide a recipe on how to reproduce this? There's a lot of
  >> very special setup below, that someone wwould need large amounts of 
time
  >> to reporoduce I feel.
  >>
  >> Is it possible to reduce the problem to something easily 
demonstratable?
  >>
  >> This seems to be an important issue to me.
  >>
  >> I think the problem here *might* be a kernel problem? Re-assign this to
  >> kernel package?
  > [...]
  >
  > So far as I know, the kernel only ever does DHCP if you net-boot
  > without an initramfs.

  My focus was more on this issue here - aparenty:

  Mark Hutchison wrote:

  >> This DoS's the server [due to DHCP changing IPs rapidly
  >> - my interpretation] and the interface attempts to take and discard
  >> IP's in a rapid fashion.

  -> changing IPs of an interface of a *VM* can DoS the server. Which I
  think is not expected, and not terribly funny. It takes a bit of not so
  straightforward circumstances (as far as I can understand the bug
  report), but then an attacker can DoS the server via DHCP. Which is uh,
  I mean ah, um.

  Information is a bit sparse here, though.

  If I may shoot completely off topic for a second: Woah, many thanks
  for your terrific kernel maintenance work Ben. Truly amazing :-o!!!
  Thanks so may times a lot! Woah :-) Thank you! (this doesn't exclude
  the rest of the kernel team - my thanks extend to you all - it's just
  that I have the honor to say thanks to a participating party in this
  email exchange 8v)!
  *t

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Tomas Pospisek]

Am 07.08.19 um 19:00 schrieb Marc Haber:
> On Wed, 7 Aug 2019 14:44:01 +0100, Ian Jackson
>  wrote:
>> Marc Haber writes ("Re: do packages depend on lexical order or 
>> {daily,weekly,monthly} cron jobs?"):
>>> We have already thrown sysvinit away.
>>
>> No, we have not.
> 
> We have given up on so many ideas that sysvinit has come with that it
> doesn't make sense to stick to Tradition on this count.

FWIW (I mean it, this is just anecdotical evidence): I have been
recently upgrading a lot of containers and host and I have been unable
to make lxc guest with systemd inits even start.

Also, I have been having problems with ssh sessions taking 25 seconds to
start on the remote side because of systemd and pam trying to initialize
some systemd user session.

I gave up on understanding both of those problems after an hour or two
of research on each. After all, machines were down, automation was not
working I had to get the stuff running again.

So at this instant I can't see sysv going away because there's too many
things not working in practice on my systems with systemd.
*t

Re: help

[Tomas Pospisek]

Am 15.08.19 um 21:09 schrieb seydi mouhamadou moustapha ndiaye:

> I'm a student in computer engineering field from africa and I look for a
> mentor who can  help me to accurate my computer skills mainly on coding.

Learn by doing. Install Debian on your laptop. Then pick a package you
like or that you think could use improvement. Improve it. Send a bug
report with a patch.
*t

Bug#1036077: please reassign to xserver

[Tomas Pospisek]

Since this seems to be a xserver problem, could you please reassign the 
ticket to the correct xserver package?

*t

Re: About i386 support

[Tomas Pospisek]

Hi Maite, hi Rhys,


don't top-post. That breaks the flow of the arguments being argued about.


*From:* Johannes Schauer Marin Rodrigues 
*Sent:* Friday, May 17, 2024 15:48
*To:* Victor Gamper; debian-devel@lists.debian.org
*Subject:* Re: About i386 support

Quoting Victor Gamper (2024-05-17 21:58:58)
> Is there a reason to do this? If so, what would be required to keep 
the i386

> version, seeing as it still is important and used?

anything can be done if there are enough contributors who care.

For i386 there is a severe lack of person-power. Do you want to start
contributing your free-time for several years to come to d-i and other 
areas

which are needed to keep i386 more alive for longer?


> On 18.05.24 03:15, r...@neoquasar.org wrote:
>> That depends. What would be required of such a person? I also have
>> several i386-class machines that run Debian (though only one that can
>> run Debian 12).

On 18.05.24 15:16, Maite Gamper wrote:

> Whilst I can't for sure say how much free time I'll have, I'd like
> to try and contribute. How would you get started with that?

There's somewhere a page that is showing how much of the archive is 
built by architecture. A search engine should help you finding that 
page. Pick the package that is furthest down the stack of package 
dependencies that is not building on i386. Find out why. Fix the bug. 
Check if there's a bug report about the problem. Send a patch. If the 
maintainer doesn't have time then become a Debian Maintainer oder 
Developer yourself consult with the package's maintainers and upload 
fixed packages.

*t

Re: Split Packages files based on new section "buildlibs"

[Tomas Pospisek]

Hi Antonio (and anybody else that understands the technical problem 
involved here),


I've been reading the whole thread and it seems to me that the reason, 
why Rust/Go build-time "libraries" need to be handled differently from 
all the other existing stuff in the world and that "no user ever wants 
to use" the Debian-provided build-time Rust/Go libraries has not been 
spelled out in plain, comprehensible english yet.


So since you seem to understand a bit about the technical problem 
involved here and I'd very much appreciate if you could spell it out. I 
think it would benefit the project as then everybody would be able to 
understand what this new section is about.


So let me ask a question that could maybe clear things up:

On 11.11.20 14:39, Antonio Terceiro wrote:


In the Rust world there is no such thing as installing a library
globably. A crate that provides a library can only be used to build
other stuff, and is never made available globally. "cargo install" only
applies to creates that provide binaries:

https://doc.rust-lang.org/cargo/commands/cargo-install.html


[I've read the cargo-install.html document in the past but not re-read 
it now]


So let's say user joe wants to code Go software that depends on Go's 
third party github.com/tazjin/kontemplate/templater package ("package" 
in Go's taxonomy not in Debian's!).


Then he'd `export GOPATH=~/src/go` and `go get 
github.com/tazjin/kontemplate`. Go would then `git clone` everything 
under  `~/src/go/src/github.com/tazjin/kontemplate/`.


So far so good and I think Rust has a similar mechanisms with cargo, right?

Now given that alice wants to package joe's software. She'll do the 
above plus `go get github.com/joe/joes_app`. All will be under 
`~/src/go/src/github`.


The naive thing to do now would be to move `~/src/go/src/` to 
`/usr/lib/go` and package that as `go-tazjin-kontemplate-dev_0.1.deb` or 
similar.


Debian's automatic build process for "joes_app" would first install 
`go-tazjin-kontemplate-dev_0.1.deb`, then make a symlink from 
`~/src/go/src/github.com/tazjin` (or `~/.local/go` or whereever Go 
expects its stuff by default) to `/usr/lib/go/src/github.com/tazjin` and 
build and be done.


A user wanting to develop software based on tazjin's stuff would do the 
same: `apt-get install go-tazjin-kontemplate-dev`, symlink, done.


This solution seems to be too trivial that nobody would have though of 
it, so what is it that I (and I guess many Debianers) are missing?

*t