Update Lenny to Squeeze
Hello, I have upgrade my Debian Lenny to Debian Squeeze and I don't know if it's only on my case but Imust upgrade grub, linux-image (2.6.26 to 2.6.32) and udev in this order. grub before linux-image because linux-image-2.6.32 don't upgrade /boot/grub/menu.list linux-image before udev because udev (158-1) return error if the kernel is 2.6.26. I don't know where is the work on upgrade documentation but I wanted underline this order. _____ Michel BARRET
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
Re: /sbin/hwclock and /etc/init.d/boot
>My immediate problem is that I have the hardware clock set to GMT and >my system clock is never getting set to the local timezone. Do you see "/etc/localtime" when you type "date +%Z" ? If so, then I'd say that you ran in a bug with the timezones package. Just purge it and install it again Michel "Walken" LESPINASSE - Student at Ecole Centrale Paris (France) www email : [EMAIL PROTECTED] (o o)www : http://www.via.ecp.fr/~walken/ --oOO--(_)--OOo-- C0 9B E8 D8 44 43 D3 63 5A B4 BA 55 57 5B 19 6D "Just say know" finger [EMAIL PROTECTED] for complete PGP key -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
FTP Tracking software
Hi, I need to find FTP Tracking software for our linux server and am having trouble finding anything to fit the bill, can you help? The actual request I received was to be able to: 1) Directory access for organizing files remotely (from win95 pc's) 2) FTP Tracking software. 3) password protected FTP access accounts. Thanks, Michel West Kenwood ISD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Thu, 2006-08-24 at 16:51 +0200, Luca Capello wrote: > > If it's not my fault, however, I think we need a new package in > experimental... Already uploaded. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Update release management
Hello, I apologise if this is considered off-topic - might be barking up the wrong tree in the wrong forest here - but bringing up an old issue here of release frequency, once the transition to using package pools and the new debian-installer is done, would it be reasonable to expect Debian releases more often - say, once every quarter like FreeBSD already does? The comparison with FreeBSD is rather apt as both are community projects working on whole OSes, although FreeBSD has a principal sponsor (BSDi, then WindRiver) and positions itself more commercially than does Debian (selling official CDs) and thus perhaps having more to benefit from frequent releases? That asides, with the avalanches of release in the last few days (RH 7.1, Mdk 8.0, FreeBSD 4.3) leading me to think about the future of Debian - note that last week also sees the update of the Unofficial Debian CD sets (by Attila Nagy - many thanks!), one sets to ponder certain points of matter: - it should be easier maintaining the new modular installer in-between releases (considering the present one looks very much similar to FreeBSD's spartan interface, and *that* installer has not changed in ages it seems, it would be nice if our next installer can be that dependable) - Package pools allowing easy roll-out of custom-made mini-distributions Take the two together and certain possibilities arise: 1. Frequent releases made possible for the benefit of people without blazing-fast connection 2. This frequent release should allow Debian to generate more revenue 3. A sort of package rating system, allowing a core nucleus of important libraries and programs to coalesce. Since these packages are those most likely to change and thus most noticeable when they become out of date, having frequent releases would help, and doing so would be easier with less packages to concentrate bug-fixing on 4. Inter-release update CDs could be issued ala Microsoft's Service Packs with updated packages only - so it might depend on previous release CDs. Should be simple enough to automate, does not even need an installer. I am sure all these points have been raised before, or even seem obvious and if anyone think this posting is a waste of time and space, my apologies. Just thought to appease my curiousity about Debian's future plans since I am in the process of joining it. Warm regards, -- Michèl Alexandre Salim
ITP: fam (but not a developer yet)
fam, the File Alteration Monitor from SGI, will be used by both E 0.17 and the upcoming Nautilus 1.0.3 / 1.2, whatever they will finally call it. http://oss.sgi.com/projects/fam Guess I'll take a stab at this. Will post the URL when done - I don't intend to jumpstart anything, just avoiding duplication of efforts :) -- Michèl Alexandre Salim
Re: Update release management
Petr Cech wrote: > > > 4. Inter-release update CDs could be issued ala Microsoft's Service > > you volunteer? > Once I find a place to host it, why not :) Michel
Bug#321886: ITP: driconf -- DRI configuration GUI
Package: wnpp Severity: wishlist Owner: Michel Dänzer <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: driconf Version : 0.2.6 Upstream Author : Felix Kühling <[EMAIL PROTECTED]> * URL : http://dri.freedesktop.org/wiki/DriConf * License : GPL Description : DRI configuration GUI Driconf is a graphical configuration tool for the Direct Rendering Infrastructure (DRI). It allows customizing performance and visual quality settings of OpenGL drivers on a per-driver, per-screen and/or per-application level. The settings are stored in a system wide or per-user XML configuration file which is parsed by the OpenGL drivers on startup. Preliminary packages available at http://people.debian.org/~daenzer/driconf/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC9qW5WoGvjmrbsgARAiLXAKCR2RTyVkW8+JAtB2jmjfosEc+ragCgpob4 lpnUNPB9dCIMB1nnYK1lpDE= =ngCl -END PGP SIGNATURE-
Re: mesag3 <-> xlibmesa-gl / libgl1-mesa-dri <-> xlibmesa-dri / libglu1-mesa <-> libglu1-xorg
On Wed, 2005-08-31 at 17:25 -0600, Marcelo E. Magallon wrote:
> On Wed, Aug 31, 2005 at 02:41:05AM +0200, Michael Biebl wrote:
>
> The GLU package is, uhm, I don't know. At some point I talked with
> Branden about it, but we never did anything. The xfree86 (and now the
> x.org) are the ones duplicating that code. And this has nothing to do
> with some "my turf/your turf" thing. It was more of a "this code
> works, that code doesn't" thing. All three packages (libglu1-mesa,
> libglu1-xorg, xlibmesa-glu) are optional. The -xorg thing is cute, but
> someone missed the point of -mesa (and I'm probably to blame). -mesa
> is there because at some point there were two implementations shipped
> with Mesa. The one by Brian Paul and the one from the OpenGL SI
> provided by SGI, so there were two packages (libglu1-mesa and
> libglu1-sgi). The -sgi one was provided by a package that never made
> it thru the NEW queue and after some months I got sick of waiting and
> removed the package from the queue, so it never actually made it to the
> archive. Anyways, it happened that at some other point Brian removed
> his implementation, fixed bugs in the SGI one and shipped that with
> Mesa. That's why nowadays the -mesa package provides the SGI
> implementation.
>
> AFAIK, the -xorg package is byte for byte the same thing as the -mesa
> package.
And I've suggested getting rid of xlibmesa-glu{,-dbg,-dev} several
times, without success. However, this will happen automatically with
X.Org 7.0, see below.
> > Why this duplication of code and which of this two implementations is
> > the preferred one?
>
> "It depends"
>
> What hardware do you have and what do you want to do?
>
> On some machines I have NVIDIA hardware because it's the only hardware
> that supports current OpenGL features both in the hardware and in its
> driver (a recent Radeon card is useless to me if it supports OpenGL 1.5
> but its driver doesn't, which is the case with the DRI drivers).
There's a vendor provided driver for these cards that supports
current OpenGL features as well.
> > Could I replace the xorg packages with the mesa packages without ill
> > effects resp. without loss of functionality?
>
> You mean replacing xlibmesa-gl by libgl1-mesa-dri? It should work, but
> haven't tested it.
It would have to Conflicts-Replaces-Provides libgl1 for that to work.
> > Is this an attempt to smooth the transition from the xorg packages to
> > the mesa ones and in the course of the X modularisation to get
> > completely rid of the GL/GLU code in xorg (and the libgl*-xorg
> > packages) and use mesa directly as an external library? If there is
> > such a transition how will it take place?
>
> Not currently, or at least not one that I know of.
X.Org will indeed no longer ship copies of the Mesa bits as of 7.0.
That'll be an automatic transition so to speak. :)
> 2) Someone with the proper hardware should test the several (there's at
> least 8 of them IIRC) drivers that ship inside the -dri package with
> the current (6.8) and future (6.9, 7.0) x.org server.
I'll gladly test the r200 driver once it's built on powerpc and the
libgl1 issue mentioned above is solved.
> My interest in the mesa package comes from the fact that I develop
> OpenGL-based applications, which is why I picked it up when it was
> orphaned and why I've been maintaining it for the last few years.
And you've been doing a great job, keep it up. But if you could use a
helping hand, I wouldn't mind co-maintaining or something. No request,
just an offer.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: mesag3 <-> xlibmesa-gl / libgl1-mesa-dri <-> xlibmesa-dri / libglu1-mesa <-> libglu1-xorg
On Wed, 2005-08-31 at 21:55 -0600, Marcelo E. Magallon wrote:
> On Wed, Aug 31, 2005 at 10:35:55PM -0400, Michel Dänzer wrote:
>
> > > 2) Someone with the proper hardware should test the several
> > > (there's at least 8 of them IIRC) drivers that ship inside the
> > > -dri package with the current (6.8) and future (6.9, 7.0) x.org
> > > server.
> >
> > I'll gladly test the r200 driver once it's built on powerpc and the
> > libgl1 issue mentioned above is solved.
>
> Can you just try the drivers? I mean "dpkg -x" or something like that.
I tried building from SVN:
[...]
mkdir -p debian/stamp/ && touch debian/stamp/target-gl-debian-debug
dh_testdir
chmod +x debian/shadowtree
rm -f -rf build/gl-debian-debug-i386
debian/shadowtree build/gl-debian-debug-i386
ln -sf debian-debug-i386 build/gl-debian-debug-i386/configs/current
if test gl != gl ; then mkdir -p build/gl-debian-debug-i386/lib/ ; ln
-sf ../../gl-debian-debug-i386/lib/libGL.so
build/gl-debian-debug-i386/lib/ ; fi
make -C build/gl-debian-debug-i386/src SRC_DIRS=mesa
make[1]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src'
Making sources for debian-debug-i386
mkdir ../lib
make[2]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa'
make[3]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa'
make[4]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa/x86'
cc -I../../../include/GL -I../../../include -I.. -I../main -I../math
-I../glapi -I../tnl -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L
-D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DUSE_XSHM -DPTHREADS
-I/usr/X11R6/include -DDEBUG -DMESA_DEBUG -ansi -pedantic -Wall -fPIC
-std=c99 -mcpu=i686 -msse -mfpmath=sse -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM gen_matypes.c -o gen_matypes
cc1: error: invalid option ‘sse’
cc1: error: invalid option ‘fpmath=sse’
gen_matypes.c:1: error: bad value (i686) for -mcpu= switch
[...]
(Keep in mind this is on powerpc)
I took a look at debian/rules, but it isn't obvious to me what the best
way to fix this is.
> I just need to know if they work fine with the current X server in
> unstable or if I need to wait for the 6.9 X server.
FWIW, we generally try to preserve backwards compatibility, so they
*should* work with the X server in sid. The r200 driver from Mesa CVS
certainly works here, although I'm not using the DDX driver from
xserver-xorg either. :)
> SVN is svn://svn.debian.org/svn/pkg-mesa/mesa/trunk and patches are
> most welcomed (BTS is easier, but my @d.o address should be fine).
The attached patch adds the IMO appropriate Conflicts:, Replaces: and
Provides: for libgl1-mesa-dri{,-dev}.
> And since I've got your attention Michel, if you figure there's an
> optimization for PowerPC that actually has some visible impact, I'll be
> glad to include that, too. Please read debian/README.build.
Thanks for the pointer, but unfortunately, I can't think of anything
offhand.
> I really wish I had a PowerPC where I could port the optimized T&L
> functions, PowerPC asm is *really* nice :-)
Yeah, that'd be very cool. :)
> And co-maintaining is always welcomed.
Okay, do you intend to use the pkg-mesa-devel list?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Index: debian/control
===
--- debian/control (revision 26)
+++ debian/control (working copy)
@@ -52,6 +52,9 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, libglu1-mesa | libglu1
+Conflicts: libgl1
+Replaces: libgl1
+Provides: libgl1
Description: A free implementation of the OpenGL API -- DRI runtime
This version of Mesa provides hardware accelerated rendering
capabilities via the Direct Rendering Interface (DRI) infraestructure.
@@ -62,6 +65,9 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, libc6-dev, mesa-common-dev (= ${Source-Version}), libgl1-mesa-dri (=${Source-Version})
+Conflicts: libgl-dev
+Replaces: libgl-dev
+Provides: libgl-dev
Description: A free implementation of the OpenGL API -- DRI development support files
This version of Mesa provides hardware accelerated rendering
capabilities via the Direct Rendering Interface (DRI) infraestructure.
Re: mesag3 <-> xlibmesa-gl / libgl1-mesa-dri <-> xlibmesa-dri / libglu1-mesa <-> libglu1-xorg
[ Moving to pkg-mesa-devel, please follow up there only ] On Sun, 2005-09-04 at 11:12 -0600, Marcelo E. Magallon wrote: > On Sat, Sep 03, 2005 at 05:30:52PM -0400, Michel Dänzer wrote: > > > I tried building from SVN: > > > > [...] > > mkdir -p debian/stamp/ && touch debian/stamp/target-gl-debian-debug > > dh_testdir > > chmod +x debian/shadowtree > > rm -f -rf build/gl-debian-debug-i386 > > debian/shadowtree build/gl-debian-debug-i386 > > Ah, sorry about that. > > I reworked a few parts of debian/rules and forgot to take the optimized > builds into account. > > It's fixed now. Indeed, thanks. However, building the i8* drivers doesn't make much sense on powerpc, how about something like the attached patch? Also, I think the mach64 (and possibly r300) driver(s) should be in a separate package with a strong warning about the security risks. For mach64, the DRI support in the DDX won't be enabled by default in the foreseeable future anyway. > > > I just need to know if they work fine with the current X server in > > > unstable or if I need to wait for the 6.9 X server. > > > > FWIW, we generally try to preserve backwards compatibility, so they > > *should* work with the X server in sid. The r200 driver from Mesa CVS > > certainly works here, although I'm not using the DDX driver from > > xserver-xorg either. :) > > Ok, I'll try that on the hardware I have (i815 I think). The drivers don't seem to get linked against libdrm, so its symbols are unresolved. The r200 driver works fine with LD_PRELOAD=/usr/lib/libdrm.so.1 though. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
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#510408: ITP: biew -- console hex viewer/editor with disassembler
Package: wnpp Severity: wishlist Owner: Michel Loos * Package name: biew Version : 5.7.1 Upstream Author : Nick Kurshev * URL : http://sourceforge.net/projects/biew/ * License : GPL Programming Lang: C Description : console hex viewer/editor with disassembler BIEW (Binary vIEW) is a free, portable, advanced file viewer with built-in editor for binary, hexadecimal and disassembler modes. It contains a highlight AVR/Java/i86-AMD64/ARM-XScale/PPC-64 and other disassembler, full preview of MZ,NE,PE,ELF and other. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510408: ITP: biew -- console hex viewer/editor with disassembler
Em Qui, 2009-01-01 às 21:52 +0200, Faidon Liambotis escreveu: > Michel Loos wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Michel Loos > > > > * Package name: biew > > Version : 5.7.1 > > Upstream Author : Nick Kurshev > > * URL : http://sourceforge.net/projects/biew/ > > * License : GPL > > Programming Lang: C > > Description : console hex viewer/editor with disassembler > biew was already part of the archive in the past and it was, in fact, > released with etch. > > See #460636 for the bug that requested its removal. > > That isn't to say that you shouldn't package it; I just think that you > should be aware of it. > > Regards, > Faidon Thanks, I am aware of that. It happens that I am one of the few biew users, and perceived today, on upgrade to lenny, that it is no more part of the distribution. Michel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: using freedesktop.org libs
On Tue, 2003-11-11 at 00:39, Andrew Suffield wrote: > On Mon, Nov 10, 2003 at 09:44:20PM +, Anthraxz __ wrote: > > > The freebsd developpers are making some changes to the XFree86 ports to > > reduce the pain associated with upgrading and maintaining XFree86. > > > > http://www.freebsdforums.org/forums/showthread.php?threadid=16052 > > Debian doesn't share freebsd's bug of building everything on the > target system, so this doesn't really apply. That's not the only point, there's also 'I also expect the freedesktop.org libraries to stay better maintained and release more frequently than XFree86's', e.g. > > I found this idea very interesting. I think that the debian project should > > take more advantage of the freedesktop.org libs. > > Glancing briefly at the packages in sid, we've been using the ones > they have released for a while. Unreleased libraries do not belong in > unstable. It's not about released vs. unreleased but XFree86 vs. freedesktop.org. > Please at least make an effort at some research in future, it took me > barely five minutes to note all this stuff and write this mail. And it shows, I'm afraid... -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: using freedesktop.org libs
On Tue, 2003-11-11 at 13:11, Andrew Suffield wrote: > On Tue, Nov 11, 2003 at 01:14:30AM +0100, Michel D?nzer wrote: > > > > I found this idea very interesting. I think that the debian project > > > > should > > > > take more advantage of the freedesktop.org libs. > > > > > > Glancing briefly at the packages in sid, we've been using the ones > > > they have released for a while. Unreleased libraries do not belong in > > > unstable. > > > > It's not about released vs. unreleased but XFree86 vs. freedesktop.org. Actually, I misread your paragraph above and drew the wrong conclusions. Sorry about that. I agree that unreleased libraries aren't for sid, but maybe for experimental? :) -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: dm management of wm listings (kdm/gdm/etc..)
Sven LUTHER wrote: > > On Thu, May 03, 2001 at 03:11:19AM -0600, Ivan E. Moore II wrote: > > Hi, > > > > Branden and I discussed the issue of dm's that have wm lists to choose > > from several months ago. At that time he thought that maybe the > > update-menu type of approach would be a good way to solve this. I'd like > > to restate what my understanding of the problem and current suggested > > solution and see what people think. (and then find out where we go next > > from here) > > > > Problem: Desktop Managers like kdm and gdm support Window Manager > > listing so that users can choose what they want to login in > > using. There currently is no common way for wm's to register > > themselves with each/any/all dm's that may be installed on the > > system. > > mmm, here you are talking the graphical login prompt (don't know it's > propper name) Display Manager (dm) > who ask for what kind of session you are wanting. As an example, gdm > currently proposes to launch gnome-session, whatever is in Xsession or xsm. > > Note that these are no window managers? For the gnome session, you can then > choose the window-manager in the control center. gnome-session, startkde and whatnot _are_ window managers as far as the dm is concerned. AFAICT Ivan's approach is good if menu can't be (ab)used for this purpose. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Re: dm management of wm listings (kdm/gdm/etc..)
"Noah L. Meyerhans" wrote: > > On Thu, May 03, 2001 at 03:11:19AM -0600, Ivan E. Moore II wrote: > > Problem: Desktop Managers like kdm and gdm support Window Manager > > listings so that users can choose what they want to login in using. > > There currently is no common way for wm's to register themselves with > > each/any/all dm's that may be installed on the system. > > Since every window manager / session manager is already registered with > the alternatives system, I see no reason why the other display managers > can't do what wdm already does. It includes a script, update_wdm_wmlist > which essentially just greps the output of 'update-alternatives > --display x-window-manager' and 'update-alternatives --display > x-session-manager' and populates its menu based on that. Does this handle window managers which are installed after wdm, and if yes how? -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Re: xfs,powerpc, gcc (was Re: RaiserFS PPC status)
Just a friendly Jedi Knight wrote: On Mon, May 07, 2001 at 04:27:18PM +0200, Just a friendly Jedi Knight wrote: === mkfile === gcc -g -DDEBUG -funsigned-char -Wall -I../include '-DVERSION="1.2.4"' -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c -o xfs_mkfile.o xfs_mkfile.c xfs_mkfile.c: In function `main': xfs_mkfile.c:144: `O_DIRECT' undeclared (first use in this function) This one bites me a bit. O_DIRECT is missing from bits/fcntl.h on powerpc (at least on my installation and i sure i didn't mess with libc6-dev). It's sid/unstable branch. I don't remeber if the intel box i compiled xfsprogs was running sid/unstable or woody/testing (and this box is down right now) but there was no problem in compiling xfs_mkfile.. Please submit a bug against libc6-dev, maybe we'll get an explanation then. ;) Is this another wierdo of PowerPC arch? (as is with varargs). varargs isn't weird on powerpc, it just happens that incorrect usage of it works on i386 (like too much else, e.g. its wrong endianness hides type size mismatches, ...) but not for us. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Gtranscript et. al. [Was: searching for Michel Onstein]
Hi, first of all... always pay attention when modifying your alias file... sorry for that one... ANywyas... recently i have received a few bug reports regarding gtranscript and it's dependend packages.. As i do no longer use it.. and it is not being maintained (for new versions of postgress e.g.) if decided to give it up for grabs... Anyone who is interested in taking over this, and related pacakges: gtranscript libgtrans-ifase libgtrans-mysql libgtrans-postgresql Please do so.. i'll give it a week... if noone wants them i'll fix the outstanding bugs for woody... And make sure the package will be removed in unstable (which has the new postgres ;- For my C++ database needs i've switched to the Generic SQL Library: http://gql.sourceforge.net/ Grtz -- Michel Onstein Next Element B.V. pgpoiVOzvfjlr.pgp Description: PGP signature
Re: xfree86 unbuildable on ppc
On Thu, 2002-04-04 at 20:34, Branden Robinson wrote: > On Thu, Apr 04, 2002 at 10:37:52AM +0100, Philip Blundell wrote: > > About the only thing you can do is to discontinue use of the kernel > > headers altogether and provide your own, unconditional, definitions > > (with different names if there is any danger that the kernel's version > > of them might become visible under some conditions). This obviously > > sucks quite a lot, but less than the alternatives. After a quick look at this thread in the -devel archive, I basically agree with this. The interface won't change in incompatible ways so XFree86 can safely have its own copy of the definitions, as it should. > This means forking from XFree86 upstream in a way that I'm not entirely > comfortable with. Is there anyone around who is familiar with DRM > innards who would be willing to work with me and upstream to get this > fix implemented in the proper place? I'm here. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (COMPATIBILITY) Correct non-US solution
> Simpler: instead of requiring people to add /etc/LEGAL, either add it by > default or require them to add /etc/ILLEGAL. No reason to have illegal be > the default, might get someone sued. (Actually, the whole scheme might be > considered "hooks" for encryption and be illegal in some countries; beats > me. Too bad only lawyers understand the law. :-( ) The more politically correct way to handle this would be to have /etc/LEGAL-RESTRICTIONS or something like that, that would include a single line like "France" or "United States". If this file is not present, the system would rightfully assume that you live in a free country. -- Michel "Walken" LESPINASSE - Development Engineer at Wind River Systems [EMAIL PROTECTED] - http://www.via.ecp.fr/~walken/ DNA is the software of Life. Did you realize you can have that much fun for a code merge ?
Re: better /etc/init.d/network
On Sun, 16 May 1999, Massimo Dal Zotto wrote: > Hi, > > # /etc/network/eth0 > IPADDR=192.168.0.1 > NETMASK=255.255.255.0 > NETWORK=192.168.0.0 > BROADCAST=192.168.0.255 > GATEWAY=192.168.0.1 > As we're discussing things here... i think it's important that we add the possbility to attach IPv6 addresses to an interface. Since you can have multiple IPv6 addresses on an interface i was thinking of something like this: IPADDR = 192.168.2.1 IP6ADDR = 3ffe:604:5:4::1/80 IP6ADDR = 5ffe:12:2::1/80 Taking the current IPv6 aggregatable addressing scheme in mind it might be better to seperate the prefixes from the addresses, something like: PREFIX6 = 3ffe:604:5:4/80 PREFIX6 = 5ffe:12:2/80 HOST6 = 1 If there's noone objecting to the addition of IPv6 stuff to the interface we could work out a proper way of specifying it on the debian-ipv6 list. Comments? Michel Onstein | CistroN Group| Linux-, Internet- [EMAIL PROTECTED] || Telecom specialists
Re: mass-installing Debian
On Mon, May 24, 1999, Goswin Brederlow wrote: > Wouldn't it be nice if dpkg would tell you what exactly has changed > between the packages config file and what the difference to your > config is? > > I allways wonder what has changed, since I normally haven't changed > those files dpkg askes me about. Everything already exists in dpkg to perform this comparison : when dpkg prompts me for a config file replacement, I type `Z' to get a shell, and I use `diff package.conf package.conf.dpkg-new' to find out the differences between the two files... I think that making this step automatical would make a dpkg session too verbose and too prompting. -- MaXX
Bug#934733: ITP: webots -- Webots is robot simulator providing a complete development environment to model, program and simulate robots, vehicles and biomechanical systems.
Package: wnpp Severity: wishlist Owner: Olivier Michel * Package name : webots Version : R2019b Upstream Author : Olivier Michel * URL : https://github.com/omichel/webots * License : Apache 2.0 Programming Lang: C++ Description : Webots is robot simulator providing a complete development environment to model, program and simulate robots, vehicles and biomechanical systems. Webots is an open-source robot simulator. It is widely used in industry, education and research. The Webots project started in 1996, initially developed by Dr. Olivier Michel at the Swiss Federal Institute of Technology (EPFL) in Lausanne, Switzerland. Since December 2018, it is released under the Apache 2 license. Webots uses a fork of the ODE (Open Dynamics Engine) for detecting of collisions and simulating rigid body dynamics. The ODE library allows one to accurately simulate physical properties of objects such as velocity, inertia and friction. A large collection of freely modifiable robot models comes in the software distribution. In addition, it is also possible to build new models from scratch. When designing a robot model, the user specifies both the graphical and the physical properties of the objects. The graphical properties include the shape, dimensions, position and orientation, colors, and texture of the object. The physical properties include the mass, friction factor, as well as the spring and damping constants. Simple fluid dynamics is present in the software. Webots includes a set of sensors and actuators frequently used in robotic experiments, e.g. proximity sensors, light sensors, touch sensors, GPS, accelerometers, cameras, emitters and receivers, servo motors (rotational & linear), position and force sensor, LEDs, grippers, gyros, compass, etc. The robot controller programs can be written in C, C++, Python, ROS, Java and MATLAB using a simple API. Webots offers the possibility to take PNG screen shots and to record the simulations as MPEG (Mac/Linux) and AVI (Windows) movies. Webots worlds are stored in cross-platform .wbt files which format is based on the VRML language. It is also possible to import and export Webots worlds or objects in the VRML format. Another useful feature is that the user can interact with a running simulation at any time, i.e., it is possible to move the robots and other object with the mouse. Webots can stream a simulation on web browsers using WebGL. Webots is used in several online robot programming competitions including https://robotbenchmark.net This package is useful as it is often recognized as the best tool for simulating mobile robots. It is used by thousands of research labs worldwide in both academia and industry. Another package providing a similar functionality is Gazebo. Comparing to Gazebo, Webots is easier-to-use and more powerful on a large number of features: 3D rendering, sensor modeling, physics simulation acuracy, transfer to real robots, etc. We plan to maintain it on the long term as we are receiving European funding for that purpose. We do not need co-maintenainers, we would welcome volunteer :). We need a sponsor to get into debian.
Fwd: Dynamic linker support for FPC.
Link loadbalance Registre you free https://www.linkedin.com/in/michel-de-cerqueira-96b20a233 -- Mensagem encaminhada -- De: *Andrey Rakhmatullin* Data: domingo, 28 de maio de 2023 Assunto: Dynamic linker support for FPC. Para: debian-devel@lists.debian.org On Sun, May 28, 2023 at 06:53:51PM +0200, Abou Al Montacir wrote: > One year ago, glibc 2.32 2.32 was released in 2020 though? Unless you mean some Debian-specific changes, happened in 2021, in which case please be more specific? > introduced a change in the dynamic linker removing the functions > calloc/malloc/realloc/free. What do you mean by this?
Bug#1065462: ITP: netconsd -- The Netconsole Daemon
Package: wnpp Severity: wishlist Owner: Michel Lind X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: netconsd Version : 0.4 Upstream Contact: Dave Jones * URL : https://github.com/facebook/netconsd * License : BSD Programming Lang: C Description : The Netconsole Daemon This is a daemon for receiving and processing logs from the Linux Kernel, as emitted over a network by the kernel's netconsole module. It supports both the old "legacy" text-only format, and the new extended format added in v4.4. The core of the daemon does nothing but process messages and drop them: in order to make the daemon useful, the user must supply one or more "output modules". These modules are shared object files which expose a small ABI that is called by netconsd with the content and metadata for netconsole messages it receives.
Re: Need advice on coordinating libkdumpfile update and introducing pykdumpfile
On Thu, Feb 13, 2025 at 03:21:04PM -0700, Soren Stoutner wrote: > Michel, > > On Thursday, February 13, 2025 2:36:26 PM MST Michel Lind wrote: > > Ah, OK, so these uploads all require FTP master review right? > > > > - soname bump to 0.5.5 in experimental > > - initial upload of the new pykdumpfile in experimental > > - dropping python bindings in experimental > > - 0.5.5 without python in unstable (or can I as a DM do this myself?) > > - pykdumpfile in unstable > > > > If a package that's been cleared for experimental can be uploaded to > > unstable without FTP master review, even if it has binary subpackage > > name changes, that would simplify this quite a bit (but if it requires > > re-review, that's fine too, I just have to know how much to coordinate > > with the DD sponsoring the upload) > > FTP master review is only required when the name of a binary package changes. > Any > other change inside the binary package does not require their review. > > Because FTP master review can take an unpredictable amount of time, usually > the best > course of action in this case would be to make all such changes in > experimental (because > it is OK for packages in experimental to not be coinstallable or otherwise > introduce > breakage with other packages). Once everything is settled, you can upload a > version of > these experimental packages that only changes the target to unstable and they > will all > drop in immediately. > Ah, great, thank you! Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README signature.asc Description: PGP signature
Re: Need advice on coordinating libkdumpfile update and introducing pykdumpfile
On Thu, Feb 13, 2025 at 09:23:49AM +0100, Emilio Pozuelo Monfort wrote: > On 12/02/2025 23:57, Michel Lind wrote: > > Dear all, > > > > libkdumpfile has recently released version 0.5.5, which despite the > > version number, actually contains an soname bump from 0.5.4 > > > > https://github.com/ptesarik/libkdumpfile/releases/tag/v0.5.5 > > > > See e.g. the relevant Fedora packaging change > > https://src.fedoraproject.org/rpms/libkdumpfile/c/c0097ea1c69462b6bb151d186ff4856663c5b7e4?branch=rawhide > > > > The soname bump is fine in itself - I'll change the name of the binary > > subpackage containing the shared library files, and the upload will need > > to be done by a full Debian Developer and subject to FTP master review > > (IIRC, please correct me if I'm wrong). > > > > *But* upstream also decided to drop the legacy Python bindings right > > after 0.5.5 is out, and instead recommending the separate pykdumpfile > > (which they also maintain) > > > > https://github.com/ptesarik/pykdumpfile > > https://src.fedoraproject.org/rpms/python-pykdumpfile > > > > So rather than keeping the Python bindings in 0.5.5 I figured might as > > well drop the Python bindings immediately and package the new one. > > > > This needs to be built against the correct libkdumpfile, so I'm a bit > > unsure about the sequencing - in Fedora my sequence was: > > > > - package the new libkdumpfile, make it obsolete the old Python > >subpackage so upgrades work but result in the Python subpackage being > >removed > > - then package pykdumpfile > > > > I could have done both in a side tag and avoided having a time where the > > Python bindings are not available, but the way Python packages are > > generated in Fedora, if the package name changes the virtual provides > > they generate change anyway, so pykdumpfile won't be a drop in > > replacement even though it ships exactly the same Python module names. > > > > For Debian - since we already require FTP master review for the soname > > bump, it seems to make even more sense to also drop the old Python > > bindings and avoid requiring a re-review when 0.5.6 comes out. > > > > The question is - is it OK to have unstable temporarily miss the Python > > bindings? And should I preserve the upgrade path or let people keep the > > old Python bindings? (so apt-upgrade will skip updating libkdumpfile)? > > > > Or is there a way, say build the new libkdumpfile in experimental with > > the Python bindings disabled, get the new pykdumpfile reviewed and also > > built in experimental, then get them both promoted to unstable? > > That is exactly how you should do it. > > Alternatively: > > - upload the new libkdumpfile with python bindings to experimental > - once it clears new, upload to unstable (beware of the transition, so maybe > request a transition slot by doing `reportbug release.debian.org') > - upload libkdumpfile again to experimental without python bindings > - upload pykdumpfile to experimental > - once pykdumpfile clears NEW, upload both to unstable > Ah, OK, so these uploads all require FTP master review right? - soname bump to 0.5.5 in experimental - initial upload of the new pykdumpfile in experimental - dropping python bindings in experimental - 0.5.5 without python in unstable (or can I as a DM do this myself?) - pykdumpfile in unstable If a package that's been cleared for experimental can be uploaded to unstable without FTP master review, even if it has binary subpackage name changes, that would simplify this quite a bit (but if it requires re-review, that's fine too, I just have to know how much to coordinate with the DD sponsoring the upload) Thanks Emilio! -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README signature.asc Description: PGP signature
Need advice on coordinating libkdumpfile update and introducing pykdumpfile
Dear all, libkdumpfile has recently released version 0.5.5, which despite the version number, actually contains an soname bump from 0.5.4 https://github.com/ptesarik/libkdumpfile/releases/tag/v0.5.5 See e.g. the relevant Fedora packaging change https://src.fedoraproject.org/rpms/libkdumpfile/c/c0097ea1c69462b6bb151d186ff4856663c5b7e4?branch=rawhide The soname bump is fine in itself - I'll change the name of the binary subpackage containing the shared library files, and the upload will need to be done by a full Debian Developer and subject to FTP master review (IIRC, please correct me if I'm wrong). *But* upstream also decided to drop the legacy Python bindings right after 0.5.5 is out, and instead recommending the separate pykdumpfile (which they also maintain) https://github.com/ptesarik/pykdumpfile https://src.fedoraproject.org/rpms/python-pykdumpfile So rather than keeping the Python bindings in 0.5.5 I figured might as well drop the Python bindings immediately and package the new one. This needs to be built against the correct libkdumpfile, so I'm a bit unsure about the sequencing - in Fedora my sequence was: - package the new libkdumpfile, make it obsolete the old Python subpackage so upgrades work but result in the Python subpackage being removed - then package pykdumpfile I could have done both in a side tag and avoided having a time where the Python bindings are not available, but the way Python packages are generated in Fedora, if the package name changes the virtual provides they generate change anyway, so pykdumpfile won't be a drop in replacement even though it ships exactly the same Python module names. For Debian - since we already require FTP master review for the soname bump, it seems to make even more sense to also drop the old Python bindings and avoid requiring a re-review when 0.5.6 comes out. The question is - is it OK to have unstable temporarily miss the Python bindings? And should I preserve the upgrade path or let people keep the old Python bindings? (so apt-upgrade will skip updating libkdumpfile)? Or is there a way, say build the new libkdumpfile in experimental with the Python bindings disabled, get the new pykdumpfile reviewed and also built in experimental, then get them both promoted to unstable? Thanks in advance, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README signature.asc Description: PGP signature
Re: Need advice on coordinating libkdumpfile update and introducing pykdumpfile
Hi all, On Thu, Feb 13, 2025 at 04:26:12PM -0600, Michel Lind wrote: > On Thu, Feb 13, 2025 at 03:21:04PM -0700, Soren Stoutner wrote: > > Michel, > > > > On Thursday, February 13, 2025 2:36:26 PM MST Michel Lind wrote: > > > Ah, OK, so these uploads all require FTP master review right? > > > > > > - soname bump to 0.5.5 in experimental > > > - initial upload of the new pykdumpfile in experimental > > > - dropping python bindings in experimental > > > - 0.5.5 without python in unstable (or can I as a DM do this myself?) > > > - pykdumpfile in unstable > > > > > > If a package that's been cleared for experimental can be uploaded to > > > unstable without FTP master review, even if it has binary subpackage > > > name changes, that would simplify this quite a bit (but if it requires > > > re-review, that's fine too, I just have to know how much to coordinate > > > with the DD sponsoring the upload) > > > > FTP master review is only required when the name of a binary package > > changes. Any > > other change inside the binary package does not require their review. > > > > Because FTP master review can take an unpredictable amount of time, usually > > the best > > course of action in this case would be to make all such changes in > > experimental (because > > it is OK for packages in experimental to not be coinstallable or otherwise > > introduce > > breakage with other packages). Once everything is settled, you can upload > > a version of > > these experimental packages that only changes the target to unstable and > > they will all > > drop in immediately. > > > Ah, great, thank you! > Thanks to everyone's feedbacks. I have uploaded this to mentors.debian.net https://mentors.debian.net/package/libkdumpfile/ Git repo: https://mentors.debian.net/package/libkdumpfile/ Changes requiring FTP master re-review: - drop Python subpackage (I was initially going to do this later, but there are already a lot of other changes - see below - that need re-review anyway just to make the transition works) - libkdumpfile10 -> libkdumpfile12 - stop bundling libaddrxlat.so.3 with libkdumpfile10 - it did not get a soname bump, so having it bundled means you can't have libkdumpfile10 and libkdumpfile12 installed at the same time. Followed https://wiki.debian.org/PackageTransition for instructions on how to split libkdumpfile10 -> libkdumpfile12 *and* libaddrxlat3 - ship out kdumpid in a new utils subpackage After this is in experimental I'll package the new Python bindings (pykdumpfile) and ask for that to be sponsored, then get those both into unstable. Thanks, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README signature.asc Description: PGP signature
Re: Need advice on coordinating libkdumpfile update and introducing pykdumpfile
Hi Breno, On Sun, Mar 9, 2025, at 12:29 PM, Breno Leitao wrote: > Hello Michel, > > On Tue, Feb 25, 2025 at 12:37:06PM -0600, Michel Lind wrote: >> Hi all, >> >> On Thu, Feb 13, 2025 at 04:26:12PM -0600, Michel Lind wrote: >> > On Thu, Feb 13, 2025 at 03:21:04PM -0700, Soren Stoutner wrote: >> > > Michel, >> > > >> > > On Thursday, February 13, 2025 2:36:26 PM MST Michel Lind wrote: >> > > > Ah, OK, so these uploads all require FTP master review right? >> > > > >> > > > - soname bump to 0.5.5 in experimental >> > > > - initial upload of the new pykdumpfile in experimental >> > > > - dropping python bindings in experimental >> > > > - 0.5.5 without python in unstable (or can I as a DM do this myself?) >> > > > - pykdumpfile in unstable >> > > > >> > > > If a package that's been cleared for experimental can be uploaded to >> > > > unstable without FTP master review, even if it has binary subpackage >> > > > name changes, that would simplify this quite a bit (but if it requires >> > > > re-review, that's fine too, I just have to know how much to coordinate >> > > > with the DD sponsoring the upload) >> > > >> > > FTP master review is only required when the name of a binary package >> > > changes. Any >> > > other change inside the binary package does not require their review. >> > > >> > > Because FTP master review can take an unpredictable amount of time, >> > > usually the best >> > > course of action in this case would be to make all such changes in >> > > experimental (because >> > > it is OK for packages in experimental to not be coinstallable or >> > > otherwise introduce >> > > breakage with other packages). Once everything is settled, you can >> > > upload a version of >> > > these experimental packages that only changes the target to unstable and >> > > they will all >> > > drop in immediately. >> > > >> > Ah, great, thank you! >> > >> >> Thanks to everyone's feedbacks. I have uploaded this to >> mentors.debian.net >> >> https://mentors.debian.net/package/libkdumpfile/ > > I had a look at the package above, but I got the following message when > build. After the test passes, it shows: > > dh_missing: error: missing files, aborting > > Have you seen anything similar? > > Here is the rest of the log, afte the tests passed. > > Looks like you ran the build on a system with Python headers installed so it built the Python bindings, then it failed because there are unpackaged files It should not fail in sbuilder or pbuilder, but just in case I can explicitly disable Python bindings from being built so it’s easier to do a test build Best regards, > Making check in python > make[2]: Entering directory > '/home/leitao/source/libkdumpfile-0.5.5/python' > /usr/bin/python ./setup.py build > make _test_addrxlat.la \ > test_addrxlat.py > make[3]: Entering directory > '/home/leitao/source/libkdumpfile-0.5.5/python' > /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H > -I. -I.. -I../include -Wdate-time -D_FORTIFY_SOURCE=2 > -I/usr/include/python3.11 -I/usr/include/python3.11 -Wsign-compare -g > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -fcf-protection -DNDEBUG -g -fwrapv -O2 -Wall > -g -O2 -Werror=implicit-function-declaration > -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -fcf-protection -c -o test_addrxlat.lo > test_addrxlat.c > make[3]: Nothing to be done for 'test_addrxlat.py'. > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include > -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/python3.11 > -I/usr/include/python3.11 -Wsign-compare -g -fstack-protector-strong > -fstack-clash-protection -Wformat -Werror=format-security > -fcf-protection -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 > -Werror=implicit-function-declaration > -ffile-prefix-map=/home/leitao/source/libkdumpfile-0.5.5=. > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -fcf-protection -c test_addrxlat.c -fPIC -DPIC > -o .libs/test_addrxlat.o > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include > -Wdate-time -D_FORTIFY_SOURCE=2 -I
Bug#1101787: ITP: plymouth-theme-hot-dog -- Plymouth Happy Hot Dog Theme
Package: wnpp Severity: wishlist Owner: Michel Lind X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: plymouth-theme-hot-dog Version : 0.5 Upstream Contact: Will Woods * URL : https://wwoods.fedorapeople.org/hot-dog/ * License : CC-BY-SA-3.0 Programming Lang: N/A Description : Plymouth Happy Hot Dog Theme This package contains the Happy Hot Dog boot splash theme for Plymouth. The mustard indicates progress. Major Hayden wrote a great backstory of this, the beloved Fedora 17 boot splash: https://major.io/p/bring-back-fedora-beefy-miracle-boot-splash/ It's still working fine in Fedora but we want to bring the joy to other distributions. I am a Debian Maintainer, I need to be sponsored for the original upload but can maintain it myself afterwards.
Re: Need advice on coordinating libkdumpfile update and introducing pykdumpfile
On Sun, 2025-03-09 at 16:39 -0700, Michel Lind wrote: > Hi Breno, > > On Sun, Mar 9, 2025, at 12:29 PM, Breno Leitao wrote: > > Hello Michel, > > > > On Tue, Feb 25, 2025 at 12:37:06PM -0600, Michel Lind wrote: > > > Hi all, > > > > > > On Thu, Feb 13, 2025 at 04:26:12PM -0600, Michel Lind wrote: > > > > On Thu, Feb 13, 2025 at 03:21:04PM -0700, Soren Stoutner wrote: > > > > > Michel, > > > > > > > > > > On Thursday, February 13, 2025 2:36:26 PM MST Michel Lind > > > > > wrote: > > > > > > Ah, OK, so these uploads all require FTP master review > > > > > > right? > > > > > > > > > > > > - soname bump to 0.5.5 in experimental > > > > > > - initial upload of the new pykdumpfile in experimental > > > > > > - dropping python bindings in experimental > > > > > > - 0.5.5 without python in unstable (or can I as a DM do > > > > > > this myself?) > > > > > > - pykdumpfile in unstable > > > > > > > > > > > > If a package that's been cleared for experimental can be > > > > > > uploaded to > > > > > > unstable without FTP master review, even if it has binary > > > > > > subpackage > > > > > > name changes, that would simplify this quite a bit (but if > > > > > > it requires > > > > > > re-review, that's fine too, I just have to know how much to > > > > > > coordinate > > > > > > with the DD sponsoring the upload) > > > > > > > > > > FTP master review is only required when the name of a binary > > > > > package changes. Any > > > > > other change inside the binary package does not require their > > > > > review. > > > > > > > > > > Because FTP master review can take an unpredictable amount of > > > > > time, usually the best > > > > > course of action in this case would be to make all such > > > > > changes in experimental (because > > > > > it is OK for packages in experimental to not be coinstallable > > > > > or otherwise introduce > > > > > breakage with other packages). Once everything is settled, > > > > > you can upload a version of > > > > > these experimental packages that only changes the target to > > > > > unstable and they will all > > > > > drop in immediately. > > > > > > > > > Ah, great, thank you! > > > > > > > > > > Thanks to everyone's feedbacks. I have uploaded this to > > > mentors.debian.net > > > > > > https://mentors.debian.net/package/libkdumpfile/ > > > > I had a look at the package above, but I got the following message > > when > > build. After the test passes, it shows: > > > > dh_missing: error: missing files, aborting > > > > Have you seen anything similar? > > > > Here is the rest of the log, afte the tests passed. > > > > > > Looks like you ran the build on a system with Python headers > installed so it built the Python bindings, then it failed because > there are unpackaged files > > It should not fail in sbuilder or pbuilder, but just in case I can > explicitly disable Python bindings from being built so it’s easier to > do a test build > Hi Breno, The hypothesis is correct; by explicitly passing `--with-python=no` my test build succeeded even when I added python3-dev and python3- setuptools in debian/control Uploaded to mentors as #2 https://mentors.debian.net/package/libkdumpfile/#upload-2 The Salsa CI passed (the previous one has some non-critical failures but I suspect it's due to testing being in flux anyway) https://salsa.debian.org/michel/libkdumpfile/-/pipelines/832412 This is the commit corresponding to the upload https://salsa.debian.org/michel/libkdumpfile/-/commit/2ae62580da65df96c6d5bfe1aeb092cdd57b8acd and this is the added commit disabling Python for inspection https://salsa.debian.org/michel/libkdumpfile/-/commit/9d08aada535d863990a5c293f6e649f61042b6b2 Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README signature.asc Description: This is a digitally signed message part
Optimisations query
Hello, I was just thinking about one thread of discussion that happens quite some time ago on having optimised Debian packages, which resulted in the conclusion that it 1. not enough speed benefit 2. uses up too much bandwith However Red Hat seems to have solved the same problem with RH 7.0 - despite whatever else that release is. They do this by compiling to a target CPU of i686 but keeping the target platform to i386. Not too ideal for AMD users I suppose (I have one Intel and one AMD box myself) but better than nothing? This comes to mind when thinking about some assertions I've seen made that glibc 2.2 only works on i486 and better on Intels. If so, all the better - since Woody will be based on it why not compile all to a target CPU of i686 and target platform of i486? The 2 cents of a Debian user. Regards, Michel Salim PS Please include my address in your reply - not subscribed to DDML -- A classic is something that everyone wants to have read and nobody wants to read. -- Mark Twain, "The Disappearance of Literature"
Re: Optimisations query
> However Red Hat seems to have solved the same problem with RH 7.0 - > despite whatever else that release is. They do this by compiling to a > target CPU of i686 but keeping the target platform to i386. Not too > ideal for AMD users I suppose (I have one Intel and one AMD box myself) > but better than nothing? > The optimised binaries are still supposed to run on standard i386 systems. This is the setting used to compile the majority of Red Hat packages - all of those with the i386.rpm extension, basically. A few packages are compiled with a target platform of i586 and i686 - the various kernel images for example, only those would not work on a lower CPU. I have not actually tried running RH 7 on an i486 but I'm sure it would work. So the question is, why not adopt this for Debian too? Regards, Michel PS *please* use Reply-All when responding to this
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.
Very urgent
Hi, It is my humble pleasure to introduce myself to you. However, I would need your attention for a moment. My name is Koudou Michel Gbagbo, age 29 the son of president Laurent Gbagbo, I am from Abidjan (Côte d'Ivoire) West Africa, I would like to use your relationship with me to pull my wealth out of the future problems my father is creating for himself and the family name. My father lost the election to his rival and refused to step down from power resisting all international pressures and warnings. If I don't safe guide my account to another name, soon I may be at my own risk because government will freeze every bank account in our family last name including properties. I promise you will not regret this relationship with me. If you can help me with this, please let me Know. Thank you Koudou Michel Gbagbo -- 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/qq6kirfo5o00glqupdukpqlatuae68fixhktqwug7...@yahoo.co.jp
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
Bug#1037157: ITP: damo -- Data Access Monitoring Operator
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: damo Version : 1.8.3 Upstream Contact: SeongJae Park * URL : https://damonitor.github.io/ * License : GPL Programming Lang: Python Description : Data Access Monitoring Operator damo is a user space tool for DAMON. Using this, you can monitor the data access patterns of your system or workloads and make data access-aware memory management optimizations. - what it does: https://sjp38.github.io/post/damon/ -- basically you can optimize how the kernel manages memory based on how often pages are accessed - recent LWN article: https://lwn.net/Articles/931769/ - Will be maintained as part of the Debian Python Team. I am a Debian Maintainer so this will need an initial sponsor.
Bug#1008291: ITP: distrobox -- Another tool for containerized command line environments on Linux
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: distrobox Version : 1.2.14 Upstream Author : Luca Di Maio * URL : https://distrobox.privatedns.org/ * License : GPL Programming Lang: Bash Description : Another tool for containerized command line environments on Linux Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. - usefulness Much more flexible than Toolbx, which inspires it: https://fedoramagazine.org/toolbx-a-developers-new-best-friend/ - Toolbx requires specialized containers which currently are only available for Fedora. - not a dependency for another package - I use it everyday, for compatibility testing on different distributions and releases - comparison with similar packages - more flexible than Toolbx - this wraps Podman and Docker and preconfigure the containers (e.g. giving them home directory access, installing the shell you use on the host on the container too) so it's much easier to use - maintenance - no packaging team seems to match, so I plan to maintain this individually. I'm new to Debian packaging (coming from Fedora where I'm the equivalent of a Debian Developer), so will be using https://mentors.debian.net/. I do have more packages to ITP, but want to start small with a package where the upstream author has expressed an interest in getting this packaged: https://github.com/89luca89/distrobox/issues/153 - yes, I will need a sponsor
Bug#1010778: ITP: psi-notify -- Alert when your machine is becoming over-saturated
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: psi-notify Version : 1.2.1 Upstream Author : Chris Down * URL : https://github.com/cdown/psi-notify * License : MIT Programming Lang: C Description : Alert when your machine is becoming over-saturated psi-notify is a minimal unprivileged notifier for system-wide resource pressure using PSI. This can help you to identify misbehaving applications on your machine before they start to severely impact system responsiveness, in a way which MemAvailable, CPU graphs, I/O utilisation graphs and other metrics cannot. Features - Runs unprivileged - Minimal resource usage - Works with any notifier using Desktop Notifications I use this daily on my Fedora and CentOS machines, and would like to have this in Debian too. I plan to maintain this myself - I'm new to Debian packaging, this is my second package (currently also working on getting distrobox sponsored)
Bug#1010829: ITP: libkdumpfile -- Kernel coredump file access
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: libkdumpfile Version : 0.4.1 Upstream Author : Petr Tesarik * URL : https://github.com/ptesarik/libkdumpfile * License : LGPL-3+ or GPL-2+ Programming Lang: C Description : Kernel coredump file access libkdumpfile is a library to read kdump-compressed kernel core dumps. It is an optional dependency for packaging drgn (ITP: #1001581). I work with the drgn author, we already maintain libkdumpfile and drgn in Fedora and would like to make sure they are available in Debian as well.
Bug#1016094: ITP: archlinux-keyring -- Arch Linux PGP keyring
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: archlinux-keyring Version : 20220713 Upstream Author : Christian Hesse * URL : https://gitlab.archlinux.org/archlinux/archlinux-keyring * License : GPL-3+ Programming Lang: Python Description : Arch Linux PGP keyring The archlinux-keyring project holds PGP packet material and tooling (keyringctl) to create the distribution keyring for Arch Linux. The keyring is used by pacman to establish the web of trust for the packagers of the distribution. The PGP packets describing the main signing keys can be found below the keyring/main directory, while those of the packagers are located below the keyring/packager directory. Having this packaged in Debian (and other distributions) will allow mkosi, which is already in Debian, to generate Arch Linux images without hardcoding the keyring. I need a sponsor.
Bug#1016908: ITP: zcfan -- Zero-configuration fan daemon for ThinkPads
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: zcfan Version : 1.2.0 Upstream Author : Chris Down * URL : https://github.com/cdown/zcfan * License : Expat Programming Lang: C Description : Zero-configuration fan daemon for ThinkPads ## Features - Extremely small (~250 lines), simple, and easy to understand code - Sensible out of the box, configuration is optional (see "usage" below) - Strong focus on stopping the fan as soon as safe to do so, without inducing throttling - Automatic temperature- and time-based hysteresis: no bouncing between fan levels - Watchdog support - Minimal resource usage - No dependencies Per the author, this is a much simpler alternative to thinkfan. I will need to be sponsored.
Bug#1018193: ITP: the-foundation -- Opinionated C11 library for low-level functionality
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: the-foundation Version : 1.4.0 Upstream Author : Jaakko Keränen * URL : https://codeberg.org/skyjake/the_Foundation * License : BSD Programming Lang: C Description : Opinionated C11 library for low-level functionality An object-oriented C library whose API is designed for a particular coding style, taking cues from C++ STL and Qt. This is a dependency for Lagrange, a desktop Gemini client: https://codeberg.org/skyjake/lagrange I already maintain both in Fedora, and would be nice to be able to use them as native packages when on Debian.
Bug#1021743: ITP: sugarjar -- A Git/GitHub helper
Package: wnpp Severity: wishlist Owner: Michel Alexandre Salim X-Debbugs-Cc: debian-devel@lists.debian.org, mic...@michel-slm.name * Package name: sugarjar Version : 0.0.11 Upstream Author : Phil Dibowitz * URL : https://github.com/jaymzh/sugarjar * License : Apache Programming Lang: Ruby Description : A Git/GitHub helper SugarJar is a git/github helper. It needs one of the GitHub CLI's: the current default is hub, but there is experimental support for gh. SugarJar is inspired by arcanist, and its replacement at Meta, JellyFish. Many of the features they provide for the Phabricator workflow this aims to bring to the GitHub workflow. In particular there are a lot of helpers for using a squash-merge workflow that is poorly handled by the standard toolsets. If you miss Mondrian or Phabricator - this is the tool for you! I plan to maintain it myself, though I'd explore joining the Debian Ruby team or granting them upload rights. I'm a Debian Maintainer so I would initially need a sponsor to do the initial FTP upload.
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
IceCat package request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, Could somebody add/cerate a IceCat package? https://www.gnu.org/software/gnuzilla/ Thanks in advance. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBCAAGBQJWOh2CAAoJEJZMH2xih1JpafQH/Au7wBTjJXV059vuyySUnM70 WjtbqVdUibVjOClD9lOpJf2ewADK9CeQbyBkGJnAEwt//Pe/0mscktcsK9fQ4Djd q9Bj+ihIJbGNNmnqSM6jUEJ2dqFWEYe+ZPwbGvNmdS3Fd5N4oCIIgqGnLdCB1hP6 mlQgLjz+RiIvVgX+HxyHx4Wi+RUGvcU1cZ0uy8WSTMNWdSX5bE+/Xds8eYjZlfcr GpdcIlvZY9wkqVpJe6UoORZCtXwVZL+GxUyXJDqCG/y4nnVuLze7CA1LH5G8K329 3hXUyy+KjHr4zh3TbQkwEvkkG7ahbpsXBMlF5ejG/xuZCzaHDmTn2Q5LfjfL4b0= =nOlA -END PGP SIGNATURE- 0x62875269.asc Description: application/pgp-keys
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#324861: ITP: pptpproxy -- a small app that forwards PPTP VPN connections through a Linux firewall
Package: wnpp Severity: wishlist Owner: Michel van der Klei <[EMAIL PROTECTED]> * Package name: pptpproxy Version : 2.0 Upstream Author : Emmanuel Mogenet <[EMAIL PROTECTED]> * URL : http://www.mgix.com/pptpproxy * License : Public Domain Description : a small app that forwards PPTP VPN connections through a Linux firewall pptpproxy is a good old forwarder daemon. It's most probably not as elegant as a kernel+iptables based solutions, but it has the very sizeable advantage of Working For Me. It's a "timesaver" for those who are getting tired of trying to get iptables, ipchains or whatever it's called this week to properly forward PPTP through a Linux firewall. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#324861: ITP: pptpproxy -- a small app that forwards PPTP VPN connections through a Linux firewall
On Wed, 2005-08-24 at 09:47 -0500, Graham Wilson wrote: > X-Mitch IT-MailScanner: Found to be clean > X-MailScanner-From: [EMAIL PROTECTED] > > On Wed, Aug 24, 2005 at 03:41:10PM +0200, Michel van der Klei wrote: > > * Package name: pptpproxy > > Version : 2.0 > > Upstream Author : Emmanuel Mogenet <[EMAIL PROTECTED]> > > * URL : http://www.mgix.com/pptpproxy > > * License : Public Domain > > Description : a small app that forwards PPTP VPN connections through > > a Linux firewall > > > > pptpproxy is a good old forwarder daemon. It's most probably not as > > elegant as a kernel+iptables based solutions, but it has the very > > sizeable advantage of Working For Me. It's a "timesaver" for those who > > are getting tired of trying to get iptables, ipchains or whatever > > it's called this week to properly forward PPTP through a Linux > > firewall. > > The Debian iptables package has existed since Mar 2000, which, if my > math is correct, is a bit longer than a week. You'll proably want to > change your long description. That won't be that much of a problem I will change it in: pptpproxy is a good old forwarder daemon. It's most probably not as elegant as a kernel+iptables based solutions, but it has the very sizeable advantage of Working For Me. It's a "timesaver" for those who are getting tired of trying to get iptables to properly forward PPTP through a Linux firewall. Michel van der Klei signature.asc Description: This is a digitally signed message part
Re: Bug#324861: ITP: pptpproxy -- a small app that forwards PPTP VPN connections through a Linux firewall
Hi, On Thu, Aug 25, 2005 at 12:45:52AM +0200, Thomas Viehmann wrote: > Michel van der Klei wrote: > > I will change it in: > > > > pptpproxy is a good old forwarder daemon. It's most probably not as > > elegant as a kernel+iptables based solutions, but it has the very > > sizeable advantage of Working For Me. It's a "timesaver" for those who > > are getting tired of trying to get iptables to properly forward PPTP > > through a Linux firewall. > > While you at it, could you please switch the text type from an anecdote > to tell someone over beer to a matter-of-fact package description? > The process of installing a Debian system is not the quite time to be > inspired by humorous descriptions appearing on the screen. Yes is will Thomas, i've changed the control file already. pptpproxy is a small forwarder deamon which forwards pptp traffic to a Windows VPN server through an iptables firewall. I supose this will do. Kind regards, Michel van der Klei signature.asc Description: Digital signature
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
Bug#771853: ITP: gnucheese -- Modern chess engine based on GNU Chess 5.07.
Package: wnpp Severity: wishlist Owner: Michel Van den Bergh * Package name: gnucheese Version : 1.0.0 Upstream Author : Michel Van den Bergh * URL : http://hardy.uhasselt.be/GnuCheese * License : GPL Programming Lang: C Description : Modern chess engine based on GNU Chess 5.07. GnuCheese is an independent fork of the venerable GNU Chess 5.07 chess engine. GnuCheese is unrelated to GNU Chess 6 which has been released by the Free Software Foundation and which is a rebranded Fruit engine. Currently GnuCheese is about 180 elo stronger than GNU Chess 6 at the time control of 40 moves per 60 seconds. This project was originally started as an attempt to fix a number of well-known bugs in GNU Chess 5.07 which dragged down its intrinsic strength. A number of updated versions were released, the most recent one being GNU Chess 5.60. To reduce the possibility of confusion with GNU Chess 6, the engine has now been renamed as GnuCheese 1.00. This is the name under which the 5.xx versions have been playing 24/7 on FICS since 2009. GnuCheese supports both the UCI and the CECP (xboard) protocol for seamless integration with chess GUIs such as xboard. -- 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/20141202213640.4878.86309.reportbug@pn
