Bug#279983: general: /dev/cdrom does not work.
Package: general Followup-For: Bug #279983 The cdrom doesnot work too. One of them randomly works. This happend with two computers with about same debain version, but different cdrom boxes. chypre:~# mount /cdrom/ mount: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so chypre:~# dmesg | tail sr0: rw=0, want=68, limit=4 isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 SMB connection re-established (-5) SMB connection re-established (-5) attempt to access beyond end of device sr0: rw=0, want=68, limit=4 isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 attempt to access beyond end of device sr0: rw=0, want=68, limit=4 isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 chypre:~# cat /etc/fstab | grep cdrom /dev/sr0/cdrom iso9660 ro,user,noauto 0 0 chypre:~# ls -l /dev/cdrom lrwxrwxrwx 1 root root 4 2005-12-09 19:06 /dev/cdrom -> scd0 chypre:~# mount /dev/scd0 /cdrom/ mount: you must specify the filesystem type chypre:~# sudo mount -t iso9660 /dev/scd0 /cdrom/ mount: block device /dev/scd0 is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/scd0, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so chypre:~# ls /dev/disk/* /dev/disk/by-id: ata-Maxtor_6Y080L0_Y2LT5GPEata-Maxtor_6Y080L0_Y2LT5GPE-part2 ata-Maxtor_6Y080L0_Y2LT5GPE-part4 ata-Maxtor_6Y080L0_Y2LT5GPE-part6 ata-Maxtor_6Y080L0_Y2LT5GPE-part1 ata-Maxtor_6Y080L0_Y2LT5GPE-part3 ata-Maxtor_6Y080L0_Y2LT5GPE-part5 ata-Maxtor_6Y080L0_Y2LT5GPE-part7 /dev/disk/by-label: DONNEESWIN /dev/disk/by-path: pci-:00:1f.1-ide-0:0pci-:00:1f.1-ide-0:0-part2 pci-:00:1f.1-ide-0:0-part4 pci-:00:1f.1-ide-0:0-part6 pci-:00:1f.1-ide-0:0-part1 pci-:00:1f.1-ide-0:0-part3 pci-:00:1f.1-ide-0:0-part5 pci-:00:1f.1-ide-0:0-part7 /dev/disk/by-uuid: 40447DC2447DBB6C F4DF-2018 f533c798-c5a0-4670-a10b-a5b7f88715a0 6b7529e3-1f18-4f28-a04d-a06ff4db5d57 f501c01a-7fbe-4dcb-bed1-8cd737c930ae chypre:~# cat /proc/scsi/sg/device_strs TSSTcorpDVD-ROM TS-H352ATS03 chypre:~# cat /proc/ide/hdc/model TSSTcorpDVD-ROM TS-H352A chypre:~# cat /proc/ide/hdc/driver ide-scsi version 0.92 cypre:~# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: TSSTcorp Model: DVD-ROM TS-H352A Rev: TS03 Type: CD-ROM ANSI SCSI revision: 02 chypre:~# cat /proc/scsi/sg/version 30533 3.5.33 [20050328] chypre:~# cat /proc/scsi/sg/devices 0 0 0 0 5 1 5 0 1 chypre:~# cat /proc/scsi/sg/device_hdr hostchanid lun typeopens qdepth busyonline chypre:~# cat /proc/scsi/sg/device_hdr chypre:~# ls -F /dev adsp mixer1ptyc0 ptyec ptyr8 ptyu4 ptyx0 ptyzc tty18 tty58 ttyc2 ttyee ttyra ttys4 ttyu2 ttywe ttyza agpgart net/ ptyc1 ptyed ptyr9 ptyu5 ptyx1 ptyzd tty19 tty59 ttyc3 ttyef ttyrb ttyS4 ttyu3 ttywf ttyzb audio null ptyc2 ptyee ptyra ptyu6 ptyx2 ptyze tty2 tty6 ttyc4 ttyp0 ttyrc ttyS40 ttyu4 ttyx0 ttyzc audio1parport0 ptyc3 ptyef ptyrb ptyu7 ptyx3 ptyzf tty20 tty60 ttyc5 ttyp1 ttyrd ttyS41 ttyu5 ttyx1 ttyzd cdrom@parport1 ptyc4 ptyp0 ptyrc ptyu8 ptyx4 ram0tty21 tty61 ttyc6 ttyp2 ttyre ttyS42 ttyu6 ttyx2 ttyze console parport2 ptyc5 ptyp1 ptyrd ptyu9 ptyx5 ram1tty22 tty62 ttyc7 ttyp3 ttyrf ttyS43 ttyu7 ttyx3 ttyzf core@ parport3 ptyc6 ptyp2 ptyre ptyua ptyx6 ram10 tty23 tty63 ttyc8 ttyp4 ttys0 ttyS44 ttyu8 ttyx4 urandom disk/ port ptyc7 ptyp3 ptyrf ptyub ptyx7 ram11 tty24 tty7 ttyc9 ttyp5 ttyS0 ttyS45 ttyu9 ttyx5 vcs dsp ppp ptyc8 ptyp4 ptys0 ptyuc ptyx8 ram12 tty25 tty8 ttyca ttyp6 ttys1 ttyS46 ttyua ttyx6 vcs1 dsp1 psaux ptyc9 ptyp5 ptys1 ptyud ptyx9 ram13 tty26 tty9 ttycb ttyp7 ttyS1 ttyS47 ttyub ttyx7 vcs2 dvd@ ptmx ptyca ptyp6 ptys2 ptyue ptyxa ram14 tty27 ttya0 ttycc ttyp8 ttyS10 ttys5 ttyuc ttyx8 vcs3 fd@ pts/ ptycb ptyp7 ptys3 ptyuf ptyxb ram15 tty28 ttya1 ttycd ttyp9 ttyS11 ttyS5 ttyud ttyx9 vcs4 fd0 ptya0 ptycc ptyp8 ptys4 ptyv0 ptyxc ram2tty29 ttya2 ttyce ttypa ttyS12 ttys6 ttyue ttyxa vcs5 full ptya1 ptycd ptyp9 ptys5 ptyv1 ptyxd ram3tty3 ttya3 ttycf ttypb ttyS13 ttyS6 ttyuf ttyxb vcs6 hda ptya2 ptyce ptypa ptys6 ptyv2 ptyxe ram4tty30 ttya4 ttyd0 ttypc ttyS14 ttys7 ttyv0 ttyxc vcs7 hda1 ptya3 ptycf ptypb ptys7 ptyv3 ptyxf ram5tty3
Bug#407442: general: few free disk detection
Package: general Severity: wishlist On a filesystem which might fragment on low disk space(such as ext2/ext3), might be the system should detect this condition, and inform, in some way, the root, and the user who tries to write on this disk, or the user which has moste data on this disk, that unusefull files should be removed. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407446: general: automatic mount network share in filesystem.
Package: general Severity: wishlist samba network share might be automagically mouted in file system. share partage on computer machine from domain domaine, with user utilisateur shoud be available in filesystem throw: /network/samba/domaine/machine/utilisateur/partage/SomeFoldersFromRemoteComputer In the same way that processes are available with /proc. The only technical issue I see is when to provide password, and how to store them. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407446: [Fwd: Re: Bug#407446: general: automatic mount network share in filesystem.]
Sujet: Re: Bug#407446: general: automatic mount network share in filesystem. Expéditeur: Josselin Mouette Date: Fri, 19 Jan 2007 11:14:53 +0100 Destinataire: Jean-Michel <>, [EMAIL PROTECTED] Delivered-To: Le jeudi 18 janvier 2007 à 14:55 +0100, Jean-Michel a écrit : Package: general Severity: wishlist samba network share might be automagically mouted in file system. share partage on computer machine from domain domaine, with user utilisateur shoud be available in filesystem throw: /network/samba/domaine/machine/utilisateur/partage/SomeFoldersFromRemoteComputer In the same way that processes are available with /proc. The only technical issue I see is when to provide password, and how to store them. This is already possible: * at the system level using the BSD automounter, see the example in the am-utils package; This seems to works with NFS. But what's about Samba? * in KDE using kioslaves; I do not know it. * in GNOME with gnome-vfs. This allows to browse the network, but is not compatible with every application. Is it?
Bug#203004: ITP: superkaramba -- A program based on karamba improving the eyecandy of KDE
Package: wnpp Version: unavailable; reported 2003-07-27 Severity: wishlist * Package name: superkaramba Version : 0.29 Upstream Authors: Adam Geitgey <[EMAIL PROTECTED]>, Hans Karlsson <[EMAIL PROTECTED]> * URL : http://netdragon.sourceforge.net/ * License : GPL Description : A program based on karamba improving the eyecandy of KDE SuperKaramba is a tool based on karamba that allows anyone to easily create and run little interactive widgets on a KDE desktop. Widgets are defined in a simple text file and can be augmented with Python code to make them interactive. Here are just some examples of the things that can be done: * Display system information such as CPU Usage, MP3 playing, etc. * Create cool custom toolbars that work any way imaginable. * Create little games or virtual pets that live on your desktop. * Display information from the internet, such as weather and * headlines. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux uranus 2.4.20 #6 Fri May 30 16:01:55 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- Jean-Michel Kelbert pgpoBR4CTIwqn.pgp Description: PGP signature
kbiff.mo should be removed from kde-i18n-*
Hi, I made a package from kbiff : a mail notification utility. The source code include locales files : kbiff.mo However this file is also in kde-i18n-*. Then when I tried to installed the package I made, dpkg stop because it tried to overwrite kbiff.mo from kde-i18n-fr. I asked the upstream author to know why he provide this files, here is his answer : "The file in kde-i18n is old. KBiff *used* to be included in kdenetwork a long time ago and there was some translations in kde-i18n as a result. When I removed KBiff from kdenetwork, those .mo files were never removed." So to my mind kbiff.mo should be removed from kde-i18n-* package, isn't it ? Thanks -- Jean-Michel Kelbert pgpqsgFsNLdb2.pgp Description: PGP signature
Re: Compatibility of libs for Berkeley DB (libdb5.1-dev or libdb4.8-dev)
On Tuesday 08 October 2013 09:14:36 Просветов Евгений wrote: > I'm going to install Bitcoin daemon on Debian wheezy. bitcoin has been in sid since a very long time. I'm using it without problem. The maintainers refuse to let it migrate to testing because it _might_ contain an unknow bug. See #718272. Quite frustrating, but I have no time to step in... So if you can monitor security issues, you can get a pre-packaged version from http://snapshot.debian.org/package/bitcoin/ (or from ubuntu repository since it ignores migration to testing ) -- 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/201310131730.40218.jmv_...@nirgal.com
Re: (seemingly) declinging bug report numbers
On Friday 19 October 2012 00:53:43 Christoph Anton Mitterer wrote: > Another reason could be, that people have problems with the BTS. > Don't get me wrong, I personally like it a lot... and I wouldn't want to > have e.g. launchpad (if at all,... I'm quite a bugzilla fan)... but > especially for end-users BTS might be tricky to use and I know even some > fellow computer scientists which complained about it (and asked whether > there was a more bugzilla-ish web interface or so). In the last 18 monthes, about half my bug reports were lost during reporting. I could work around using -ui text, but sometimes I had to rewrite them from scratch. Many people would give up I suppose. I'm talking about bug #620225 in reportbug. If you look at the merge count, you can see many people are affected. There already was a hot discussion about the priority of that bug, and I don't want to add oil on the fire. It has been partially fixed. But if someone read this and have time to help fixing it for good, that would really help the project IMHO, because it affects its overall quality, by preventing bugs to be reported. Cheers -- Jean-Michel Vourgère signature.asc Description: This is a digitally signed message part.
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Thursday 25 October 2012 19:09:55 Michael Gilbert wrote: > (...) > I would prefer to see even more autonomy for the salvager and less > bugging of various lists (ITPs on -devel are already distracting > enough). With that, I would like to suggest rewriting steps 2-4 as: > 2. Salvager uploads liberal (10-day delayed) nmus as needed to bring > the package into a better maintained state. > 3. After a period of 3 months of contributing as an nmuer or with > maintainers approval prior to that, salvager is free to add > himself/herself as a package uploader. > (...) I feel that would make it quite difficult for a non-DD to salvage a package. Remember finding a sponsor can be hard. When fixing non important bugs, or improving the package quality, like switching to format 3 source, arranging the rules file, and so on, I fear it will be very difficult to find a sponsor for these nmus. Having 3/1 (1/0?) *DD* approving the orphaning will be more easy in these cases. After it's done, one can work on more radical changes, that are more likely to get sponsored. I find it sad to see patches hanging for years in the bug tracker. Cheers. Jean-Michel Vourgère, sponsored only DM signature.asc Description: This is a digitally signed message part.
Re: Unreleased libraries
On Saturday 08 February 2014 09:01:46 Tzafrir Cohen wrote: > On Fri, Feb 07, 2014 at 10:41:56AM -0600, Michael Shuler wrote: > > On 02/07/2014 10:25 AM, Pau Garcia i Quiles wrote: > > >Is there a policy on how to package software that does not make releases? > > > > A version similar to skia_0.0-1~svnr1234 would allow an upstream > > version of i.e. 0.1 (if they ever release) to supersede your > > packaged version. It should also allow you to upgrade via new svn > > version (0.0-1~svnr1235), as well as new packaging of same svn > > version (0.0-2~svnr1234). Please, correct me, if there is a better > > method, here! > > One other thing to keep in mind: what if they switch to git? You could use a more generic prefix like vcs, I guess. Something like 0+vcs20140212-1 would use the snapshoot as "upstream", while allowing you to change the debian part, unlike a native package. Using the ~ non-trivial system is not needed, since any release version would be greater than "0" anyways. Still, ~ shows it's a pre-release, so it makes sense too. Just my noob 2 cents. ^^ signature.asc Description: This is a digitally signed message part.
Re: Making a .deb file to be added into the debian repository.
Hi Simon Richter wrote: > A good document about web application packaging is > https://webapps-common.alioth.debian.org/draft/html/ Well, there may be a few interesting pieces left, but it's heavily outdated: - /var/www is no longer the default docroot - It is no longer recommended to create a conf in /etc/PKG/ and a link to it from /etc/apache2/conf.d/ Actually, that directory doesn't even exist any more, so this is a really bad idea... I would rather suggest reading https://wiki.debian.org/Apache/PackagingFor24 The new system is more complex, but it includes a lot of nice features, like preserving the links removals by a local administrator upon package upgrades, dependencies between modules, debhelper integration to generate maintainer scripts snippets, and so on... (Thanks Arno!) Cheers -- Nirgal -- 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/5570752c.4060...@debian.org
Re: [DDEB] Status on automatic debug packages (2015-08-24)
Hi Nikolaus Rath wrote: > On Aug 24 2015, Sebastian Ramacher wrote: >> What's the plan for python(3)-*-dbg packages that include both Python >> extensions >> built for the python-dbg interpreter and debug symbols? Should they also >> change >> their Section to something else? > > > .. and will they also be build automatically? Or rather, when relying on > the automatic building, will they include the extension for the debug > interpreter or just the debugging symbols for all extensions (built for > debugging and regular interpreter)? The question is also valid for python2: When using dh --with python2 *and* build-depending on python-all-dbg, I'm getting [1]: * Some files like /usr/lib/debug/.build-id/*.debug * Some files like /usr/lib/python2.7/dist-packages/rrdtool.x86_64-linux-gnu_d.so Am I correct in assuming that this need to be split? * Each arch:any binary package will get its own -dbgsym package, like python-rrdtool-dbgsym_1.5.4-6_amd64.deb, lua-rrd-dbgsym_1.5.4-6_amd64.deb, ... * The python debug $(arch)_d.so generated by dh_auto_build will need its own package. (See questions of Nikolaus and Sebastian). The main question is whether or not these -dbgsym package is only of debug symbols. Assuming this is split, should one make a recommends: towards these non-main packages? Finally, if the current -dbg packages are moved out of main, either the buildd's will need to have them in their source list, or the section of the python tools to generate the debug _d.so thingies need to be changed. [1] https://packages.debian.org/sid/amd64/rrdtool-dbg/filelist -- Nirgal
Re: Security concerns with minified javascript code
Vincent Bernat wrote: > (...) > It has already been said numerous time in the past, for some Javascript > code, we don't really have the tools in Debian to easily go from the > source to the minified version. It's possible, but without the > appropriate tools, it's painful. I've been using yui-compressor to get the minified javascript. I never add any issue this it. Now if you are talking about generating one big javascript file containing different fragments in the correct order, that's another story. But that last issue is not really related to minified js. You can compress the javascript either before or after yui. -- Nirgal
watch files and .gitattributes export-ignore
Hello Upstream of phppgadmin has nice unit tests in its github.com repository, but they use a .gitattributes file [1] to strip these tests files from the distributed tar files: All the unit tests are missing from the orig.tar. I wonder how to proceed: I don't think there is an option in github.com to ignore the "export-ignore" in .gitattributes, that would have been perfect in my case. Ideally, I'd like to generate the orig.tar from a "git clone". But uscan don't support that. Debian policy 4.1.4 did remove the get-orig-source target from debian/rules. I guess I'll go for a manual build of the orig.tar, with a d/README.source. Or a script. Any better idea? To make things worse, I think I'll keep the d/watch file so I get warning when upstream releases a new version. But that's pretty bad because then one has to be careful not to use uscan! :/ Any insight would be appreciated. Thanks! [1] https://github.com/phppgadmin/phppgadmin/raw/master/.gitattributes signature.asc Description: This is a digitally signed message part.
Re: watch files and .gitattributes export-ignore
Here's the result of my research: uscan does support git clone. But it won't ignore the .gitattributes file. I opened https://bugs.debian.org/947317 I went for an ugly README.source using "git deborig" for now. Thank you everyone for the help! signature.asc Description: This is a digitally signed message part.
Bug#843699: ITP: opensvc -- Tools to drive OpenSVC services
Package: wnpp Severity: wishlist Owner: "Jean-Michel Kelbert" * Package name: opensvc Version : 1.8 Upstream Author : Christophe Varoqui * URL : http://www.opensvc.com * License : GPL Programming Lang: Python Description : Tools to drive OpenSVC services OpenSVC is a 'service' manager, as in clustered service manager, designed for real-world heterogeneous datacenters and large-scale operations orchestrator (disaster recovery, for example). Services are collections of resources (virtual machine, ip, disk groups, filesystems, file synchronizations, and application launchers). Services can be started, stopped and queried for status, providing a consistent command set for wildly different service integration types. Service configurations, status and logs are pushed to a central database coupled to a web front-end (collector). Services can be administered using the stand-alone GPLv2 software stack deployed on the nodes (nodeware), or through the web-front end.
Bug#843708: ITP: openha -- Easy high availability clustering
Package: wnpp Severity: wishlist Owner: "Jean-Michel Kelbert" * Package name: openha Version : 0.5.0 Upstream Author : Christophe Varoqui * URL : http://www.opensvc.com * License : GPL Programming Lang: C Description : High availability clustering hearbeat OpenHA heartbeat daemon which proposes multiple multicast heartbeat paths using a mix of IP and SCSI, and has a flexible trigger support It can be used with OpenSVC to build and High Availibity solution. -- Jean-Michel Kelbert signature.asc Description: PGP signature
Bug#823416: ITP: libjs-jquery-migrate -- Migrate older jQuery code to jQuery 1.9+
Package: wnpp Severity: wishlist Owner: "Jean-Michel Vourgère" * Package name: libjs-jquery-migrate Version : 1.2.1 Upstream Author : jQuery Foundation, Inc. and other contributors * URL : https://plugins.jquery.com/migrate/ * License : MIT Programming Lang: Javascript Description : Migrate older jQuery code to jQuery 1.9+ That small javascript library is already used by a few packages: dokuwiki: /usr/share/dokuwiki/lib/scripts/jquery/jquery-migrate.js dokuwiki: /usr/share/dokuwiki/lib/scripts/jquery/jquery-migrate.min.js dotclear: /usr/share/dotclear/web/admin/js/jquery/jquery-migrate-1.2.1.js galette: /usr/share/galette/includes/jquery/jquery-migrate-1.2.1.min.js moodle: /usr/share/moodle/lib/jquery/jquery-migrate-1.2.1.js moodle: /usr/share/moodle/lib/jquery/jquery-migrate-1.2.1.min.js opennebula-sunstone: /usr/share/opennebula-sunstone/public/vendor/4.0/jquery-migrate.min.js otrs2: /var/lib/otrs/httpd/htdocs/js/thirdparty/jquery-migrate-1.2.1/jquery-migrate.js owncloud: /usr/share/owncloud/core/js/jquery-migrate-1.2.1.js owncloud: /usr/share/owncloud/core/js/jquery-migrate-1.2.1.min.js python-xstatic-jquery-migrate: /usr/lib/python2.7/dist-packages/xstatic/pkg/jquery_migrate/data/jquery-migrate.js python-xstatic-jquery-migrate: /usr/lib/python2.7/dist-packages/xstatic/pkg/jquery_migrate/data/jquery-migrate.min.js wordpress: /usr/share/wordpress/wp-includes/js/jquery/jquery-migrate.js wordpress: /usr/share/wordpress/wp-includes/js/jquery/jquery-migrate.min.js
Bug#755186: ITP: django-session-security -- Django module to log a user out after X minutes
Package: wnpp Severity: wishlist Owner: "Jean-Michel Nirgal Vourgère" X-Debbugs-Cc: debian-devel@lists.debian.org Package name: django-session-security Version : 2.2.0 Upstream Author : James Pic URL : http://django-session-security.rtfd.org/ License : MIT Programming Lang: Python Description : Django module to log a user out after X minutes A little javascript and middleware work together to ensure that the user was active during the past X minutes in any tab he has open. Otherwise, display a warning leaving a couple of minutes to show any kind of activity like moving the mouse. Otherwise, logout the user. http://django-session-security.rtfd.org/ I tried it on both python 2 & 3. I found it trivial to deploy on existing projects. Would the package have been available in Debian, I would have it on most of my projects. So I fell other people might like it too. :) signature.asc Description: OpenPGP digital signature
Re: default messaging/VoIP client for Debian 8/Jessie
Empathy was lacking OTR encryption for text, last time I checked. Jitsi does support it ok, so I can continue to do secure chat with my existing contacts from pidgin (previously known as gaim). signature.asc Description: OpenPGP digital signature
