Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies
Package: wnpp Severity: wishlist Owner: Michael Prokop <[EMAIL PROTECTED]> * Package name: ha-prosper Version : 4.21 Upstream Author : Hendri Adriaens <[EMAIL PROTECTED]> * URL : http://stuwww.uvt.nl/~hendri/Downloads/haprosper.html * License : LaTeX Project Public License Description : improved LaTeX class for writing transparencies The HA-prosper package for LaTeX provides a way to make nice looking slides using LaTeX. This gives you the opportunity to copy and paste formulas from your papers directly into the presentation. The package has been based on the prosper class but offers a lot of new possibilities and some bug fixes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies
* Josselin Mouette <[EMAIL PROTECTED]> [20050313 00:37]: > Le samedi 12 mars 2005 à 23:44 +0100, Michael Prokop a écrit : > > * Package name: ha-prosper > > Version : 4.21 > > Upstream Author : Hendri Adriaens <[EMAIL PROTECTED]> > > * URL : http://stuwww.uvt.nl/~hendri/Downloads/haprosper.html > > * License : LaTeX Project Public License > > Description : improved LaTeX class for writing transparencies > > The HA-prosper package for LaTeX provides a way to make nice > > looking slides using LaTeX. This gives you the opportunity to > > copy and paste formulas from your papers directly into the > > presentation. The package has been based on the prosper class > > but offers a lot of new possibilities and some bug fixes. > Is it compatible with prosper? If it is, maybe it would be better to > simply replace the prosper package with this version. | This is the last release of the package HA-prosper. All future | developments in the line of this package will be collected in a new | class called TeXciting. The reason that this package will be | converted into a class is that some ideas for improvements (like A4 | paper support) can only be realized when stepping away from prosper. | The conversion will take some time and any bugs in HA-prosper will | be dealt with in the meantime. Changes necessary for presentations | to step from HA-prosper to TeXciting will be kept to a minimum. -- http://stuwww.uvt.nl/~hendri/Downloads/haprosper.html I think replacing the prosper-package with ha-prosper wouldn't be a good choice. I'd like to provide ha-prosper in a separate package so when TeXciting is available there aren't any breakages with prosper. regards, -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299257: ITP: xkeyval -- extension of the keyval package
Package: wnpp Severity: wishlist Owner: Michael Prokop <[EMAIL PROTECTED]> * Package name: xkeyval Version : 2.3 Upstream Author : Hendri Adriaens <[EMAIL PROTECTED]> * URL : http://stuwww.uvt.nl/~hendri/Downloads/xkeyval.html * License : LaTeX Project Public License Description : extension of the keyval package This package is an extension of the keyval package by David Carlisle and offers additional macros for setting keys and declaring and setting class or package options. This distribution also includes the pst-xkey package which is a specialization of the xkeyval package for PSTricks packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies
* Andreas Tille <[EMAIL PROTECTED]> [20050313 18:15]: > On Sun, 13 Mar 2005, Michael Prokop wrote: > > I think replacing the prosper-package with ha-prosper wouldn't be > > a good choice. I'd like to provide ha-prosper in a separate > > package > > so when TeXciting is available there aren't any breakages with > > prosper. > Recently I investigated some time in LaTeX based presentation tools. > The consequence was: > 1. Prosper is nice but development tsopped since about 3 years. > 2. HA-prosper was kind of continuing the work of prosper. It is >more enhanced and I even builded some packages for my private >use of it until I noticed latex-beamer (see below). My impression >was that while it is superior about prosper and should prosper >replace regarding to this fact it is not really worth packaging >because development is stalled as well because of the new >TeXciting project. > 3. LaTeX-Beamer has compatibility modes for prosper and ha-prosper. >It is much more feature complete and flexible than both above. >There is absolutely no reson to investigate time into any >*prosper package because LaTeX-Beamer is the package your >really want. For an example see > http://people.debian.org/~tille/talks/200503_peking_cdd/index_en.html >I do not know anything about TeXciting and thus I can not compare >but before crowding the archive with a package like ha-prosper >try LaTeX-Beamer. I do know many people who are used to ha-prosper and haven't switched to LaTeX-Beamer yet. ha-prosper needs less space than latex-beamer (not taking care of dependencies but ratio should be equalent): [EMAIL PROTECTED] ~ # apt-cache show ha-prosper | grep Installed-Size Installed-Size: 516 [EMAIL PROTECTED] ~ # apt-cache show latex-beamer | grep Installed-Size Installed-Size: 3364 [EMAIL PROTECTED] ~ # And TeXciting might never be released, quoting Hendri - the author of ha-prosper: | I have reconsidered whether it will be possible | to finish this project. Taking into account also | the work that I'm doing on other packages and | my involvement in LaTeX3, I conclude that it will | unfortunately be very unlikely, that I will ever | finish that project. See his posting on ha-prosper-mailinglist for more details: http://listserv.surfnet.nl/scripts/wa.exe?A2=ind0503&L=ha-prosper&F=&S=&P=777 So in my opinion it would be useful to provide a debian package of ha-prosper. regards, -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312660: ITP: shish -- the diet shell
Package: wnpp Severity: wishlist Owner: Michael Prokop <[EMAIL PROTECTED]> * Package name: shish Version : 0.7-pre3 Upstream Author : Roman Senn <[EMAIL PROTECTED]> * URL : http://www.blah.ch/shish/ * License : GPL Description : the diet shell shish is a shell language interpreter and an interactive command line interpreter. This shell aims at being very small and doing its tasks in efficient ways (and not through 100 abstraction layers), which is mainly done by using the dietlibc and libowfat libraries. shish will be a POSIX compatible shell language interpreter according to the IEEE P1003.2 Draft 11.2 by its 1.0 release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383191: ITP: iwatch -- realtime filesystem monitoring program using inotify
Package: wnpp Severity: wishlist * Package name: iwatch Version : 0.0.5 Upstream Author : Cahya Wirawan <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/iwatch * License : GPL Description : realtime filesystem monitoring program using inotify iWatch is a realtime filesystem monitoring program. It's a simple perl script to monitor changes in specific directories/files and can send email notification immediately. In daemon mode it reads the dir/file list from a xml config file but can be used and controlled via commandline mode as well. Please notice that it needs inotify support in kernel (Linux Kernel >= 2.6.13). . Homepage: http://sourceforge.net/projects/iwatch Notice: currently iwatch depends from libstring-format-perl which is not available in the Debian package pool. I'm in contact with upstream and an upcoming version should fix this issue. In the meantime a preleminary package (inlcuding a libstring-format-perl.deb) is available through the grml-repository: http://grml.org/repos/ Thanks to Alexander 'formorer' Wirt, who will sponsor the package. regards, -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts
Hello, this issue has been discussed some time ago: http://lists.debian.org/debian-devel/2004/08/msg00299.html http://lists.debian.org/debian-devel/2004/08/msg00298.html I would like to hear your current opinion about this topic. IMHO removing a package should "just work" and currently this doesn't always. Details: several packages use something like: # Automatically added by dh_installinit if [ -x "/etc/init.d/$PACKAGE" ]; then if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then invoke-rc.d $PACKAGE stop || exit $? else /etc/init.d/$PACKAGE stop || exit $? fi fi inside their prerm maintainer scripts. If stopping $PACKAGE through invoke-rc.d/init-script fails, removing the package fails as well. Using: invoke-rc.d $PACKAGE stop || true /etc/init.d/$PACKAGE stop || true would be a replacement already used in some packages like for example at, binfmt-support, dnsmasq, drbd0.7-utils, freeradius, hal, scanlogd, sl-modem-daemon, snort. I scanned through a pool of about 2400 packages and found the following packages using the "stop || exit $?" construct: 915resolution: Steffen Joeris <[EMAIL PROTECTED]> apcupsd: Samuele Giovanni Tonon <[EMAIL PROTECTED]> atop: Edelhard Becker <[EMAIL PROTECTED]> bacula-fd: John Goerzen <[EMAIL PROTECTED]> brltty:Mario Lang <[EMAIL PROTECTED]> cfengine2: Andrew Stribblehill <[EMAIL PROTECTED]> clamav-daemon: Stephen Gran <[EMAIL PROTECTED]> ddclient: Torsten Landschoff <[EMAIL PROTECTED]> dirmngr: Peter Eisentraut <[EMAIL PROTECTED]> fnfxd: Agney Lopes Roth Ferraz <[EMAIL PROTECTED]> fwlogwatch:Alberto Gonzalez Iniesta <[EMAIL PROTECTED]> gsm-utils: Mark Purcell <[EMAIL PROTECTED]> hddtemp: Aurelien Jarno <[EMAIL PROTECTED]> icecast2: Debian Icecast team <[EMAIL PROTECTED]> ifplugd: Oliver Kurth <[EMAIL PROTECTED]> installation-report: Debian Install System Team laptop-mode-tools: Bart Samwel <[EMAIL PROTECTED]> libdevmapper1.02: Debian LVM Team <[EMAIL PROTECTED]> lighttpd: Debian lighttpd maintainers <[EMAIL PROTECTED]> makedev: Bdale Garbee <[EMAIL PROTECTED]> netperf: Erik Wenzel <[EMAIL PROTECTED]> nscd: GNU Libc Maintainers openafs-client:Sam Hartman <[EMAIL PROTECTED]> pcscd: Ludovic Rousseau <[EMAIL PROTECTED]> pdns-backend-ldap: Debian PowerDNS Maintainers <[EMAIL PROTECTED]> pdns-backend-pgsql:Debian PowerDNS Maintainers <[EMAIL PROTECTED]> pdns-backend-sqlite: Debian PowerDNS Maintainers <[EMAIL PROTECTED]> pdns-recursor: Debian PowerDNS Maintainers <[EMAIL PROTECTED]> plptools: John Lines <[EMAIL PROTECTED]> postgresql-7.4:Martin Pitt <[EMAIL PROTECTED]> preload: Kari Pahula <[EMAIL PROTECTED]> procps:Craig Small <[EMAIL PROTECTED]> quota: Michael Meskes <[EMAIL PROTECTED]> racoon:Ganesan Rajagopal <[EMAIL PROTECTED]> samba: Eloy A. Paris <[EMAIL PROTECTED]> sensord: Aurelien Jarno <[EMAIL PROTECTED]> slapd: Debian OpenLDAP Maintainers <[EMAIL PROTECTED]> sleepd:Joey Hess <[EMAIL PROTECTED]> smartmontools: Guido Guenther <[EMAIL PROTECTED]> smokeping: Jose Carlos Garcia Sogo <[EMAIL PROTECTED]> spamassassin: Duncan Findlay <[EMAIL PROTECTED]> sqlrelay: Matthias Klose <[EMAIL PROTECTED]> sudo: Bdale Garbee <[EMAIL PROTECTED]> sysfsutils:Martin Pitt <[EMAIL PROTECTED]> x11-common:Debian X Strike Force xfs: Debian X Strike Force xinetd:Thomas Seyrat <[EMAIL PROTECTED]> regards, -mika- pgpstSn1FIoTn.pgp Description: PGP signature
Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts
* Bernd Schubert <[EMAIL PROTECTED]> wrote: >> inside their prerm maintainer scripts. If stopping $PACKAGE through >> invoke-rc.d/init-script fails, removing the package fails as well. >> Using: >> invoke-rc.d $PACKAGE stop || true >> /etc/init.d/$PACKAGE stop || true > We are using chroot environments (e.g. with sid) where no daemon is running > and invoke-rc.d will only do an "exit 0" in those chroots. How do you achieve that? For example symlinking invoke-rc.d to /bin/true is a workaround, but I'm searching for a general solution to avoid that daemons are started when upgrading even though they did not run before the upgrade (or don't start any service at all, e.g. in chroots - as you mentioned). > Using the method above, wouldn't there be any chance that a bad > init script could kill daemons started outside the chroot? The init script would be broken then. Anyway, I don't see the difference between "stop || exit $?" and "stop || true" in this case. -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts
* Bernd Schubert <[EMAIL PROTECTED]> wrote:
> Michael Prokop wrote:
>> How do you achieve that? For example symlinking invoke-rc.d to
>> /bin/true is a workaround, but I'm searching for a general solution
>> to avoid that daemons are started when upgrading even though they
>> did not run before the upgrade (or don't start any service at all,
>> e.g. in chroots - as you mentioned).
> Via /usr/sbin/policy-rc.d, e.g.:
> #!/bin/sh
> # are we on hamilton?
> WHERE=$(hostname -s|cut -b 1-8) # cut to remove {1,2} from hamilton{1,2}
> if [ "$WHERE" = "hamilton" ]; then
> # notify invoke-rc.d that nothing should be done -- we are in a chroot
> exit 101
> else
> # allow it
> exit 0
> fi
> (This chroot is used on the clients as their root environment)
Thanks.
>> The init script would be broken then.
>> Anyway, I don't see the difference between "stop || exit $?" and
>> "stop || true" in this case.
> What I mean is that the call of
> invoke-rc.d $PACKAGE stop || true
> is fine, but the second call
> /etc/init.d/$PACKAGE stop || true
> will not using policy-rc.d and therefore might be a possible problem. Given
> the fact that we have a sid chroot on a high availibilty system and a sid
> package always might cause some trouble, I don't like the idea that a
> malformed script is able to stop programs outside its chroot.
But /etc/init.d/$PACKAGE is executed only, if "[ -x "`which
invoke-rc.d 2>/dev/null`" ]" fails. And I still don't see what's the
relation to "stop || true". ;) I don't insist on the "stop || true"
way of life, I'd just like to make sure that removing packages
always works.
-mika-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts
* Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [20060523 21:59]: > On Tue, 23 May 2006, Michael Prokop wrote: > > way of life, I'd just like to make sure that removing packages > > always works. > If you are going to ignore a failing initscript in order to remove a > package, and that leaves a daemon running, then expect to get a very nasty > bug report... Yes, for sure. But IMO it's the initscript which should make sure that the daemon is stopped when running the stop-rule. regards, -mika- pgph0UX3EtppX.pgp Description: PGP signature
Bug#319383: ITP: minised -- a smaller, cheaper, faster SED implementation
Package: wnpp Severity: wishlist Owner: Michael Prokop <[EMAIL PROTECTED]> * Package name: minised Version : 1.5 Upstream Author : Rene Rebe <[EMAIL PROTECTED]> * URL : http://www.exactcode.de/oss/minised/ * License : GPL Description : a smaller, cheaper, faster SED implementation This sed implementation is based on the one by Eric S. Raymond. It is a very small and fast implementation of sed. Statically compiled against the dietlibc the binary has less than 35kB. . Homepage: http://www.exactcode.de/oss/minised/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#536493: ITP: xmount -- tool to crossmount between multiple input and output image files
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: xmount Version : 0.3.1 Upstream Author : Gillen Daniel * URL : https://www.pinguin.lu/ * License : GPL Programming Lang: C Description : tool to crossmount between multiple input and output image files xmount allows you to convert on-the-fly between multiple input and output image types. xmount creates a virtual file system using FUSE (Filesystem in Userspace) that contains a virtual representation of the input image. The virtual representation can be in raw DD or in VirtualBox's virtual disk file format. Input images can be raw DD or EWF (Expert Witness Compression Format). In addition, xmount also supports virtual write access to the output files that is redirected to a cache file. This makes it for example possible to use VirtualBox to boot an OS contained in a read-only EWF image. regards, -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is Ayman Negm MIA?
[Cc-ing Ayman] Sandro Tosi wrote: > On Mon, Apr 20, 2009 at 07:46, Rince wrote: >> Ayman Negm is the maintainer of, among others, the gddrescue package. >> The package hasn't been touched by him since 2006, and several bugs >> about it have required NMUs by other people. > Ayman is been tracked in MIA database, and he's quite busy these days. [...] No news/changes since then. > Please do this statement on a public place easily reachable when > someone searches for information about the package; the best place is > the BTS, for example replying to this bug: #460946 . > Moreover, have you tried to contact the maintainer himself? I'm adding > him here in CC. > If the situation does not evolve in 1/2 week, please contact us back > and we'll see what we can do. AFAICT Ayman is MIA and doesn't respond to mails. I just prepared NMU for ddrescue package (see #533483). I'm working on NMU for gddrescue (see #460946) as well. I'd volunteer in taking over maintenance for the ddrescue and gddrescue packages if there aren't any objections. Does anyone know how to reach Ayman Negm? What's the proper way to take over the packages if Ayman doesn't respond? regards, -mika- signature.asc Description: Digital signature
Bug#551809: ITP: stressapptest -- stress test application for simulating high load situations
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: stressapptest Version : 1.0.0 Upstream Author : Nick Sanders + Rapahel Menderico (Google Inc) * URL : http://code.google.com/p/stressapptest/ * License : Apache Programming Lang: C++ Description : stress test application for simulating high load situations Stressful Application Test (or stressapptest, its unix name) tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation in order to test the existing hardware devices in a computer. . Stressapptest may be used for various purposes: . * stress test * hardware qualification and debugging * memory interface test * disk testing regards, -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#440279: ITP: op -- sudo like controlled privilege escalation
Package: wnpp Severity: wishlist Owner: Michael Prokop <[EMAIL PROTECTED]> * Package name: op Version : 1.32 Upstream Author : Alec Thomas <[EMAIL PROTECTED]> * URL : http://swapoff.org/wiki/op * License : BSD Programming Lang: C Description : sudo like controlled privilege escalation The op tool provides a flexible means for system administrators to grant access to certain root operations without having to give them full superuser privileges. Different sets of users may access different operations, and the security-related aspects of each operation can be carefully controlled. . Homepage: http://swapoff.org/wiki/op Notice: a preliminary Debian package is available at http://deb.grml.org/pool/main/o/op/ regards, -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Call for Testing: initramfs-tools 0.97
Hi, we - the initramfs-tools maintainers in Debian - want to provide a solid initramfs-tools version for squeeze. The new release 0.97 is expected to fix many longstanding problems. It would be great if we could receive feedback from testers. The new release is available from Debian/unstable and is expected to install without problems in at least lenny, squeeze and sid: http://cdn.debian.net/debian/pool/main/i/initramfs-tools/initramfs-tools_0.97_all.deb SHA256:56eb56d472d0dd24c8f2fd030222586e258ec882b716f02d114865cef9c19639 No matter how your partition layout looks like (rootfs on lvm, crypto, sw-raid,...), if you're booting on physical hardware or a virtualized system (Xen, openvz, kvm,...) - please give it a shot and report any possible problems. thanks && regards, -mika- signature.asc Description: Digital signature
Re: Call for Testing: initramfs-tools 0.97
* Joachim Wiedorn [Sun Jun 27, 2010 at 05:03:02PM +0200]: > Michael Prokop wrote on 2010-06-18 23:48: > > we - the initramfs-tools maintainers in Debian - want to provide a > > solid initramfs-tools version for squeeze. The new release 0.97 is > > expected to fix many longstanding problems. It would be great if we > > could receive feedback from testers. > > The new release is available from Debian/unstable and is expected to > > install without problems in at least lenny, squeeze and sid: > > > > http://cdn.debian.net/debian/pool/main/i/initramfs-tools/initramfs-tools_0.97_all.deb > > SHA256:56eb56d472d0dd24c8f2fd030222586e258ec882b716f02d114865cef9c19639 > > No matter how your partition layout looks like (rootfs on lvm, > > crypto, sw-raid,...), if you're booting on physical hardware or a > > virtualized system (Xen, openvz, kvm,...) - please give it a shot > > and report any possible problems. > I have checked the scripts and I was very happy to see that lilo is > furthermore supported by initramfs-tools (script update-initramfs). > Can I be sure that this support stay in your package? Because of changes > in some other packages this would be nearly an existential question. Sorry for the delay in answering, we discussed that in the team. Conclusion: no, we - as in initramfs-tools maintainers - won't support that. The mechanism will change with run-parts execution of /etc/initramfs hooks - the bootloader will add initramfs hooks. As explanation for the "no" see thread with subject "[DRAFT] Policy for Linux kernel, initramfs, boot loader update process" (Message-ID: <1277690555.26161.532.ca...@localhost>) on debian-devel. (I'm aware that you - Joachim - already mailed in that thread and are aware of it therefore, I'm mentioning it here JFTR.) regards, -mika- signature.asc Description: Digital signature
Request for Comments: Planned removal of ddrescue
Hi, I'm the maintainer of the ddrescue and gddrescue packages. I plan to drop the ddrescue package. Background: ddrescue provides the dd_rescue binary, gddrescue provides the ddrescue binary. As you might notice this is far from a perfect situation and confuses users. * ddrescue = http://www.garloff.de/kurt/linux/ddrescue/ * gddrescue = http://www.gnu.org/software/ddrescue/ddrescue.html Popcon currently lists more ddrescue installations than gddrescue: http://qa.debian.org/popcon-graph.php?packages=gddrescue+ddrescue&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 But this is very probably caused by the (misleading) package names and users not being fully aware of the ddrescue (dd_rescue) vs. gddrescue (ddrescue) issue. I'd like to get rid of this confusion now. AFAICT gddrescue provides all the features (and even more) ddrescue does. Also from a forensic and data rescue POV gddrescue works pretty well and I'm not aware of any issues with it. Related: Ubuntu had a similar discussion in https://bugs.launchpad.net/ubuntu/+source/gddrescue/+bug/161126 Suggestion: I propose the removal of the ddrescue package. If anyone has any objections against the removal of ddrescue please share why you think it's worth supporting it, otherwise I'd file a request for removal of ddrescue. thanks && regards, -mika- signature.asc Description: Digital signature
Re: Request for Comments: Planned removal of ddrescue
* Luca Capello [Thu Feb 17, 2011 at 12:05:18AM +0100]: > On Wed, 16 Feb 2011 23:17:58 +0100, Michael Prokop wrote: > > I'm the maintainer of the ddrescue and gddrescue packages. > > I plan to drop the ddrescue package. > [...] > > I'd like to get rid of this confusion now. AFAICT gddrescue provides > > all the features (and even more) ddrescue does. Also from a forensic > > and data rescue POV gddrescue works pretty well and I'm not aware of > > any issues with it. > Without having checked at dd_rescue, but having used gddrescue various > times and being a bit too lazy now to check the following, I guess that > your past concerns do not stand anymore, do they? > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537697#10> Correct, I consider gddrescue a full replacement for ddrescue nowadays. > > I propose the removal of the ddrescue package. > +1, I was myself confused while looking at `apt-cache search ddrescue`. Thanks for the feedback, Luca. regards, -mika- signature.asc Description: Digital signature
Re: Request for Comments: Planned removal of ddrescue
* Antonio Diaz Diaz [Fri Feb 18, 2011 at 05:58:22PM +0100]: > Michael Prokop wrote: >> I'm the maintainer of the ddrescue and gddrescue packages. >> I plan to drop the ddrescue package. > IMHO dropping the gddrescue package and moving GNU ddrescue to the > ddrescue package (replacing dd_rescue) is the least confusing solution > for the users in the long term. > I suppose such replacement may be complicated and create a lot of > problems in the short term, but I still think it is the best solution in > the long term. Ok, I'll think about that. > I guess many people expect to find GNU ddrescue in the ddrescue package, > and if this package is dropped they may wrongly conclude that Debian does > not provide GNU ddrescue instead of searching for the, unknown to them, > gddrescue package. Valid point. > And as 1) the executable names are different, and 2) ddrescue is mainly > used by humans instead of scripts, maybe the short term problems created > by the proposed replacement aren't so serious after all. Thanks for your feedback, Antonio. regards, -mika- signature.asc Description: Digital signature
"Debian is switching to EGLIBC"
| Debian is switching to EGLIBC | | I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is | currently waiting in the NEW queue), which will soon replace the GNU | C Library (GLIBC). | [...] -- http://blog.aurel32.net/?p=47 Where did this decission (and the discussion around it) took place? I can't find anything neither on debian-devel nor on debian-devel-glibc. -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Debian is switching to EGLIBC"
* Josselin Mouette wrote: > Le mercredi 06 mai 2009 =C3=A0 18:18 +0200, Michael Prokop a =C3=A9crit : >> Where did this decission (and the discussion around it) took place? >> I can't find anything neither on debian-devel nor on debian-devel-glibc. > Do all maintainers need your approval before switching to another branch > for packages they maintain? No. Though I think that for essential packages like libc it could be worth a public discussion. regards, -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Debian is switching to EGLIBC"
* Aurelien Jarno wrote: > Michael Prokop a écrit : >> * Josselin Mouette wrote: >>> Le mercredi 06 mai 2009 =C3=A0 18:18 +0200, Michael Prokop a =C3=A9crit : >>>> Where did this decission (and the discussion around it) took place? >>>> I can't find anything neither on debian-devel nor on debian-devel-glibc. >>> Do all maintainers need your approval before switching to another branch >>> for packages they maintain? >> No. Though I think that for essential packages like libc it could be >> worth a public discussion. > Should we also ask permission to everybody before uploading a new > version of the libc? No need to become cynical. I didn't intend to put your technical decission into question. I highly appreciate Debian libc maintainer's work. I was just wondering that reddit, LWN,... had the news but debian-devel not. -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531077: ITP: anytun -- secure anycast tunneling protocol
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: anytun Version : 0.3 Upstream Author : Othmar Gsenger, Erwin Nindl, Christian Pointner * URL : http://www.anytun.org/ * License : GPL Programming Lang: C++ Description : secure anycast tunneling protocol Anytun is an implementation of the secure anycast tunneling protocol. It uses an easy openvpn style interface and makes it possible to build redundant VPN clusters with load balancing between servers. VPN servers share a single IP address. Adding and removing VPN Servers is done by the routing protocol, so no client changes have to be made when additional VPN servers are added or removed. It is possible to realise global load balancing based on shortest BGP routes by simply announcing the address space of the tunnel servers at multiple locations. . Currently ethernet, ipv4 and ipv6 tunnels are supported by the implementation. However the protocol allows to tunnel every ETHERTYPE protocol. regards, -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531082: ITP: uanytun -- tiny implementation of the secure anycast tunneling protocol
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: uanytun Version : 0.3 Upstream Author : Christian Pointner * URL : http://www.anytun.org/ * License : GPL Programming Lang: C Description : tiny implementation of the secure anycast tunneling protocol uAnytun is a tiny implementation of SATP (Secure Anycast Tunneling Protocol). Unlike Anytun which is a full featured implementation uAnytun has no support for multiple connections or synchronisation. It is a small single threaded implementation intended to act as a client on small platforms. SATP defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It has less protocol overhead than IPSec in Tunnel mode and allows tunneling of every ETHER TYPE protocol (e.g. ethernet, ip, arp ...). SATP directly includes cryptography and message authentication based on the methodes used by SRTP (Secure Real-time Transport Protocol). It is intended to deliver a generic, scaleable and secure solution for tunneling and relaying of packets of any protocol. regards, -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757193: ITP: libnumber-phone-perl -- base class for parsing and dealing with phone numbers
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: libnumber-phone-perl Version : 3.0001 Upstream Author : David Cantrell * URL : http://search.cpan.org/~dcantrell/Number-Phone-3.0001/ * License : Artistic / GPLv2 Programming Lang: Perl Description : base class for parsing and dealing with phone numbers This Perl module and its sub-classes provides support for parsing and dealing with phone numbers, e.g. Number::Phone::Country looks up the country based on a telephone number. Note: One of the companies I'm working for uses this package and we want to contribute this package back to Debian, I plan to do the actual packaging work under the wonderful Perl pkg group umbrella, as usual. regards, -mika- -- 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/2014-08-06t08-25...@devnull.michael-prokop.at
Bug#671517: ITP: carton -- Perl module dependency manager (aka Bundler for Perl)
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: carton Version : 0.9.5+git8e653 Upstream Author : Tatsuhiko Miyagawa * URL : https://github.com/miyagawa/carton * License : GPL-1+ or Artistic Programming Lang: Perl Description : Perl module dependency manager (aka Bundler for Perl) carton is a command line tool to track the Perl module dependencies for your Perl application. The required dependencies are managed through a file named cpanfile and tracked through the carton.lock file. It makes deployments easier and allows other developers of your application to have the exact same versions of the modules. I already talked to Gregor Herrmann, the package will probably become part of the perl group. regards, -mika- -- 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/2012-05-04t20-46...@devnull.michael-prokop.at
Re: Packaging on GitHub ?
* Thomas Goirand [Sun May 27, 2012 at 11:52:27PM +0800]:
> On 05/27/2012 02:42 PM, olivier sallou wrote:
> > Keeping an updated mirror is not a good method for me, it is a painful
> > task and you are never sure of the status
> Isn't it possible to keep this repo up-to-date using
> some of the git hooks? Like, when you push to your
> repo on Alioth, it would automatically push on github.
> I didn't try, but I don't think it would be hard to
> do that.
Yes, it's possible. In the Grml team we're hosting our repositories
on our own git server (http://git.grml.org/) and have a copy of it
available at Github within our "Grml Organization" account
(https://github.com/grml).
That's the code which does the mirror job inside our shared-hooks:
, [ github mirror ]
| copy_to_github()
| {
| echo -n "Making backup to github: "
| if git push --mirror g...@github.com:grml/${projectname} >/dev/null 2>&1 ;
then
| echo "done"
| else
| echo "Warning: Could not copy repo to github"
| fi
| }
`
You get the benefit of having a maximum of flexibility/customization
thanks to the selfhosted repositories with access to e.g. Github's
pull-request workflow at the same time.
regards,
-mika-
--
http://michael-prokop.at/ || http://adminzen.org/
http://grml-solutions.com/ || http://grml.org/
signature.asc
Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Thorsten Glaser [Thu Oct 31, 2013 at 01:27:12PM +0100]:
> On Thu, 31 Oct 2013, Florian Weimer wrote:
> > Curiously, a lot of system administrators do not do this correctly
> > using sysvinit, causing system daemons to start unexpectedly after
> > installing package updates.
> What *is* the correct way, anyway?
> My coworkers tell me to delete the symlinks in /etc/rc*.d/
> but that’s sysv-rc specific,
[...]
And wrong, you'll get the symlinks restored on package upgrades.
| Disabling a daemon service is quite simple. You either remove the
| package providing the program for that service or you remove or
| rename the startup links under /etc/rc${runlevel}.d/. If you rename
| them make sure they do not begin with 'S' so that they don't get
| started by /etc/init.d/rc. Do not remove all the available links or
| the package management system will regenerate them on package
| upgrades, make sure you leave at least one link (typically a 'K',
| i.e. kill, link).
--
http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s-disableserv
So "mv /etc/rc#.d/S*foo /etc/rc#.d/K*foo" is supposed to do the
trick for sysv-rc.
regards,
-mika-
signature.asc
Description: Digital signature
Re: Bug#705954: ITP: ms-sys -- writes Microsoft compatible boot records
* Joao Eriberto Mota Filho [Mon Apr 22, 2013 at 01:57:16PM -0300]: > * Package name: ms-sys > Version : 2.3.0 > Upstream Author : Henrik Carlqvist > * URL : http://ms-sys.sf.net > * License : GPL2 > Programming Lang: C > Description : writes Microsoft compatible boot records > Does the same as Microsoft "fdisk /mbr" to a hard disk or "sys d:" to a floppy > or FAT32 partition except that it does not copy any system files, only the > boot > record is written. > The current version supports up to Windows 7. We've had this package already in Debian once but it was removed because of copyright issues as noted in #470678, JFYI. regards, -mika- signature.asc Description: Digital signature
Join the #newinwheezy game
Hi, according to UDD we've 4451 new source packages in Debian/wheezy[1]. Plenty of them are worth noting and a good way to present the interesting new packages to our users could be if package maintainers/teams just write about them. Would be nice if we get something similar to the dpl game up and running. Francesca came up with hashtag #newinwheezy for it, so maybe some of you join me with the #newinwheezy game and blog/tweet/identica/... about (your) new package(s). I just started with http://michael-prokop.at/blog/2013/04/29/the-newinwheezy-game-new-forensic-packages-in-debianwheezy/ [1] http://people.debian.org/~mika/new_source_packages_in_wheezy.txt regards, -mika- signature.asc Description: Digital signature
Re: Bug#736416: ITP: debci -- continuous integration system for Debian
* Antonio Terceiro [Thu Jan 23, 2014 at 10:08:25AM -0300]: > * Package name: debci > Version : 0.4.0 > Upstream Author : Antonio Terceiro > * URL : http://ci.debian.net/ > * License : GPL-3 > Programming Lang: Mostly POSIX Shell. a little bit of (or a rewrite > in) a saner language (Ruby|Perl|Python) might be > needed down the road > Description : continuous integration system for Debian > debci will scan the Debian archive for packages that contains DEP-8 > compliant test suites, and run those test suites whenever a new version > of the package, or of any package in its dependency chain (modulo the > base system), is available. Sounds promising, thanks for your work, Antonio. (As Martin Pitt already wrote in #736416 it would be great if the existing efforts could be shared.) I'm a bit unhappy about the naming though, because currently it's running DEP-8 tests only and "continuous integration system for Debian" and its project name "debci" are a bit missleading from my PoV. Do you have any further things in mind for debci? regards, -mika- signature.asc Description: Digital signature
Bug#746653: ITP: libcatalyst-plugin-email-perl -- module to send emails with Catalyst
Package: wnpp Owner: Debian Perl Group Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcatalyst-plugin-email-perl Version : 0.08 Upstream Author : Sebastian Riedel * URL : https://metacpan.org/release/Catalyst-Plugin-Email * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to send emails with Catalyst Send emails with Catalyst and Email::Send and Email::MIME::Creator. Actual packaging work is by Victor, and the current state of packaging is living at git://anonscm.debian.org/pkg-perl/packages/libcatalyst-plugin-email-perl.git / ssh://git.debian.org/git/pkg-perl/packages/libcatalyst-plugin-email-perl.git thanks to gregor herrmann. regards, -mika- signature.asc Description: Digital signature
Buildd vs. Cowbuilder: broken symlink in procps dev package on one architecture
Hi, Christian Hofstaedtler prepared a stable update for procps regarding #632749 (with ACK from Craig as the procps maintainer and from Adam from the release team - Cc-ing both of them therefore FYI). While reviewing the package I noticed an interesting bug, causing procps in squeeze to have an accidental hidden Build-Depend on itself, which only influences the -dev package. The issue turns up as follows: | % dpkg -c libproc-dev_3.2.8-9squeeze1_amd64.deb | grep libproc.so | lrwxrwxrwx root/root 0 2011-08-22 00:19 ./usr/lib/libproc.so -> /lib/libproc-*.so This bug is caused by the following lines in debian/rules: | PROCLIB = $(shell basename proc/libproc-*.so) | [...] | ( cd static && ln -s /lib/$(PROCLIB) libproc.so ) *But*: e.g. the amd64 binary package in the Debian squeeze repository doesn't suffer from this problem: | % dpkg -c libproc-dev_3.2.8-9_amd64.deb | grep libproc.so | lrwxrwxrwx root/root 0 2010-05-04 13:26 ./usr/lib/libproc.so -> /lib/libproc-3.2.8.so My assumption: it's because this (amd64) version has been built by buildds. But Craig (as the maintainer) uploaded the i386 version which was built in a clean environment without having procps installed: | % dpkg -c libproc-dev_3.2.8-9_i386.deb | grep libproc.so | lrwxrwxrwx root/root 0 2010-05-04 13:44 ./usr/lib/libproc.so -> /lib/libproc-*.so Questions: 1) What's the proper way to address this issue in squeeze? a) Build a i386 package with broken symlink? b) Build whatever-arch package with working symlink? 2) How can we make sure such a bug doesn't happen again (besides working towards source-only uploads :))? Bugreport against buildd.debian.org? regards, -mika- signature.asc Description: Digital signature
Re: Buildd vs. Cowbuilder: broken symlink in procps dev package on one architecture
* Cyril Brulebois [Mon Aug 22, 2011 at 12:02:17PM +0200]: > Michael Prokop (22/08/2011): > > 1) What's the proper way to address this issue in squeeze? > >a) Build a i386 package with broken symlink? > >b) Build whatever-arch package with working symlink? > Stop using basename on what's in /lib, and do that on what's under > debian/tmp. So 1b, thanks. > > 2) How can we make sure such a bug doesn't happen again > >(besides working towards source-only uploads :))? > >Bugreport against buildd.debian.org? > Same answer as for 1). Hehe sure. But that the procps package is non-essential but seems to be installed on (some?) buildds is irrelevant? regards, -mika- signature.asc Description: Digital signature
Re: Buildd vs. Cowbuilder: broken symlink in procps dev package on one architecture
* Adam D. Barratt [Mon Aug 22, 2011 at 07:11:08PM +0100]: > On Mon, 2011-08-22 at 12:19 +0200, Michael Prokop wrote: > > * Cyril Brulebois [Mon Aug 22, 2011 at 12:02:17PM +0200]: > > > Michael Prokop (22/08/2011): > > > > 1) What's the proper way to address this issue in squeeze? > > > >a) Build a i386 package with broken symlink? > > > >b) Build whatever-arch package with working symlink? > > > Stop using basename on what's in /lib, and do that on what's under > > > debian/tmp. > > So 1b, thanks. > Looking at the procps source package in unstable, it appears to have the > same issue. If that's the case, then I'm afraid your question should > really have been "what's the proper way to address this issue in > unstable and subsequently in squeeze". Sure, but fixing the package in unstable doesn't modify the behaviour within the stable release, which was the rationale behind my question towards the issue in squeeze. :) Since there are no objections against solution 1b we'll provide a working package for squeeze. Craig, maybe you could contact Christian and me regarding the package for unstable so we avoid duplicate efforts? Thanks to everyone, regards, -mika- signature.asc Description: Digital signature
Join the #newinjessie game
Hi, I'm repeating what I did with the #newinwheezy game for the wheezy release[1] now for the Debian/jessie release (jey!). According to UDD we've 4841 new source packages in Debian/jessie[2]. A list of the source packages expanded with maintainer names is available at well[3]. Plenty of those packages are worth noting and a good way to present the interesting new packages to our users could be if package maintainers/teams just write about them. I just started with http://michael-prokop.at/blog/2015/04/24/the-newinjessie-game-new-forensic-packages-in-debianjessie/ Maybe some of you join me with the #newinjessie game and blog/tweet/... about (your) new package(s) as well. [1] https://lists.debian.org/debian-devel/2013/04/msg00870.html [2] https://people.debian.org/~mika/jessie/new_source_packages_in_jessie.txt [3] https://people.debian.org/~mika/jessie/new_source_packages_in_jessie_by_maintainer.txt regards, -mika- signature.asc Description: Digital signature
Re: Handling of entropy during boot
* Raphael Hertzog [Thu Jan 10, 2019 at 12:24:45PM +0100]: > On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote: > > Pointers, please? Let's see them and investigate. The primary issue > > I've been aware of to date has been on Fedora systems, and it's due to > > some Red Hat specific changes that they made for FEDRAMP compliance > > --- and Red Hat has dealt with those issues. > In Kali I had to install haveged by default due to this problem. > We got reports of having to wait up to 5 minutes to get to their desktop. > We got reports of sshd not working on first boot (in fact just taking too > long to start). ACK, we also had to do the same in Grml[.org] and our latest release (2018.12). Now we automatically enable haveged when users boot using the ssh boot option (which is something Grml specific, taking care of setting user password and invoking the ssh service). We saw exactly what Daniel documented at https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html regards, -mika- -- https://michael-prokop.at/ || https://adminzen.org/ https://grml-solutions.com/ || https://grml.org/ signature.asc Description: Digital signature
Bug#919692: ITP: golang-github-leodido-ragel-machinery -- Machineries for development of ragel parsers
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: golang-github-leodido-ragel-machinery Version : 0.0~git20181214.299bdde-1 Upstream Author : Leo Di Donato * URL : https://github.com/leodido/ragel-machinery * License : MIT/Expat Programming Lang: Go Description : Machineries for development of ragel parsers Machineries to speed up and facilitate the development of ragel parsers able to accept streaming inputs. It is only intended for use with ragel parsers. This is a build-dependency of golang-github-influxdata-go-syslog. I'll package + maintain this under the go-team umbrella.
Re: [RFC] locking down rsyslog.service
* Michael Biebl [Tue Oct 10, 2023 at 08:22:26PM +0200]: > I intend to lock down rsyslog.service in Debian in one of the next > uploads using the following systemd directives That's great to hear, thanks for working on this. > PrivateTmp=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp= > > PrivateDevices=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateDevices= > > ProtectHome=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome= > > ProtectSystem=full > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem= > > ProtectKernelTunables=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelTunables= > > ProtectKernelModules=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelModules= All those work fine for rsyslog within a platform of a customer of mine, for whom I implemented the systemd hardening back in 2020. Same also for: | NoNewPrivileges=yes | ProtectControlGroups=yes which are mentioned elsewhere in this thread. You might also consider enabling the following options: # Service cannot create writable executable memory mappings that are writable and executable at the same time MemoryDenyWriteExecute=yes # Service may execute system calls only with native ABI SystemCallArchitectures=native # Service cannot change ABI personality LockPersonality=true # Restrict access to the various process namespace types the Linux kernel provides RestrictNamespaces=true regards -mika- signature.asc Description: PGP signature
Re: [RFC] locking down rsyslog.service
* Michael Biebl [Wed Oct 11, 2023 at 12:14:47PM +0200]: > Am 11.10.23 um 08:03 schrieb Simon Richter: > > On 10/11/23 03:22, Michael Biebl wrote: > > > > > I intend to lock down rsyslog.service in Debian in one of the next > > > uploads using the following systemd directives > > > > > CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE > > > CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_RESOURCE > > > CAP_SYSLOG > > > > Does it actually need CAP_NET_ADMIN and CAP_SYS_ADMIN? > > > > Everything else looks good to me. > > The list is based on > https://github.com/rsyslog/rsyslog/pull/4999#issuecomment-1313362425 > > - CAP_NET_ADMIN: use of setsockopt() > - CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit on the > number of open files, in system calls that open files (e.g. accept execve), > use of setns(),... > > I trimmed stuff like CAP_SETGID and CAP_SETUID, which the Debian package > doesn't need. Just in case you haven't seen it yet, be aware of the CAP_DAC_OVERRIDE change for omprog module usage at https://github.com/rsyslog/rsyslog/pull/5223 regards -mika- signature.asc Description: PGP signature
Epoch version for golang-github-gomodule-redigo-dev?
Hi, we have a rather unfortunate situation with the golang-github-gomodule-redigo-dev package, see #974550 for the details. tl;dr: upstream released v2.0.0 on 2018-03-14, though went downwards with version numbers afterwards and we're at v1.8.3 for the latest upstream release now. In Debian we currently have v2.0.0 in buster/testing/unstable. It looks like upstream isn't willing to raise the version number (see https://github.com/gomodule/redigo/issues/532, and a somewhat related discussion took place also in https://github.com/gomodule/redigo/issues/366), so if we want to fix the situation for bullseye, we need a workaround/solution soonish. Since the problem exists due to the way go module versioning works, it might make sense to discuss, how to handle it a) now for golang-github-gomodule-redigo-dev, but also b) apply the same decision whenever the issue comes up again? The situation is related to the fact how go module versioning works: * `go get github.com/gomodule/redigo/redis` currently points at v1.8.3 * https://pkg.go.dev/github.com/gomodule/redigo/redis?tab=versions says v1, both for v1.8.3 but also v2.0.0+incompatible AFAICS we could: 1) use 2.0.0+really1.8.3 pattern for our Debian package version 2) introduce an epoch 3) any further trick/workaround? Thoughts? Thanks to Clément Hermann, Tianon Gravi and Shengjing Zhu for their feedback on #debian-golang. regards -mika- signature.asc Description: Digital signature
Re: Epoch version for golang-github-gomodule-redigo-dev?
* Clément Hermann [Thu Nov 26, 2020 at 02:19:38PM +0100]: > On 26/11/2020 09:31, Paul Gevers wrote: > > As it seems not unreasonable to expect the upstream version to go past > > 2.0.0 in the not infinite future, this is the approach I would take. > > Because you ask here, it suggests to me that doing this has some pain > > for the packaging that you didn't elaborate on. Why do you even raise > > the question here on debian-devel and don't just do this established way > > of fixing these kind of temporarily versioning issues in Debian? > Well, I was the one suggesting Michael start a discussion on > debian-devel about it, so I thought I'd chime in. [...] > An epoch might be overkill here, but also seems more appropriate to me > since we have to work around upstream decision in this case. And since > the Policy states it needs to be discussed first here, I suggested to do > just that. ACK and thanks. > I do agreee that the best and most logical thing would be for upstream > to start using 3.0, as Simon pointed out. Michael, did you bring this > issue upstream ? Would you suggest this option to them ? If they're > willing to do that in a reasonable timeframe, we could go the +really > route and wait until 3.0 is available upstream. Otherwise, we can go for > an epoch if we reach consensus here. Yes, raising the version to v3.0 was brought up within https://github.com/gomodule/redigo/pull/440, which was referred to from https://github.com/gomodule/redigo/issues/532, quoting Steven Hartland (one of the upstream maintainers of redigo) from there: | See the conversation on #440 but in short major version bumps in gomod are painful for users :( So I'm afraid this won't happen "soon". :-/ > Thanks to everyone participating, by the way! +1 also from my side, great feedback - thanks Paul, Holger, Mattia and Simon! So AFAICS we agree to fix the situation via an epoch upload. regards -mika- signature.asc Description: Digital signature
Re: MariaDB 10.11 in Bookworm - call for contributions
* Thomas Goirand [Fri Feb 24, 2023 at 04:00:43PM +0100]: > On 2/23/23 17:22, Otto Kekäläinen wrote: > > I am currently preparing the upload of MariaDB 10.11.2-2 to Debian > > unstable and aim for the highest possible quality. I am currently > > doing the bulk of the testing and packaging alone and to make sure > > that the quality is top notch, I would be glad to see more people > > contribute. [...] > Another issue, > My package depends on default-mysql-server, which doesn't pull > mariadb-server 10.11, but 10.6. As a result, I can't install both... :/ > Can this be fixed? This is #1029092 and Otto just marked the blocking bug as resolved (thanks Otto!), so this should hopefully be fixed soon: | % grep-excuses mysql-defaults | mysql-defaults (1.0.8 to 1.1.0) | Maintainer: Debian MySQL Maintainers | Migration status for mysql-defaults (1.0.8 to 1.1.0): BLOCKED: Rejected/violates migration policy/introduces a regression | Issues preventing migration: | ∙ ∙ Updating mysql-defaults would introduce bugs in testing: #1029092 | Additional info: | ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/m/mysql-defaults.html | ∙ ∙ 38 days old (needed 10 days) regards -mika- signature.asc Description: PGP signature
Bug#960920: ITP: libanyevent-forkmanager-perl -- simple parallel processing fork manager with AnyEvent
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: libanyevent-forkmanager-perl Version : 0.07 Upstream Author : Kenta Sato * URL : https://metacpan.org/release/AnyEvent-ForkManager * License : Artistic or GPL-1+ Programming Lang: Perl Description : simple parallel processing fork manager with AnyEvent AnyEvent::ForkManager is much like Parallel::ForkManager, but supports non-blocking interface with AnyEvent. . Parallel::ForkManager is useful, but it is difficult to use in conjunction with AnyEvent, because Parallel::ForkManager's some methods are blocking the event loop of the AnyEvent. The package will be maintained under the pkg-perl umbrella. signature.asc Description: Digital signature
Bug#960921: ITP: libtest-sharedobject-perl -- Data sharing in multi processes
Package: wnpp Severity: wishlist Owner: Michael Prokop * Package name: libtest-sharedobject-perl Version : 0.01 Upstream Author : Kenta Sato * URL : https://metacpan.org/release/Test-SharedObject * License : Artistic or GPL-1+ Programming Lang: Perl Description : Data sharing in multi processes Test::SharedObject provides atomic data operation between multiple processes. This package is a (Build-)dependency of libanyevent-forkmanager-perl and will be maintained under the pkg-perl umbrella. signature.asc Description: Digital signature
Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade
* David Kalnischkies [Wed Feb 22, 2017 at 10:28:33PM +0100]:
> On Wed, Feb 22, 2017 at 09:04:16PM +0100, Luca Capello wrote:
> > ...it will break existing practices, e.g.:
> > DEBIAN_FRONTEND=noninteractive apt-get upgrade -y
> > FYI, I would call it a regression.
> That specific invocation can "fail" for all sorts of interesting reasons
> like dpkg config files or apt hooks. "fail" as in apt (and debconf) does
> what it was told to do, but that doesn't say dpkg what it is supposed to
> do. Or apt-list{changes,bugs} or …
With the according options all of that can be controlled as needed, e.g.:
APT_LISTBUGS_FRONTEND=none
APT_LISTCHANGES_FRONTEND=none
APT_PARAMS="--no-install-recommends -y -o DPkg::Options::=--force-confask -o
DPkg::Options::=--force-confdef -o DPkg::Options::=--force-confmiss -o
DPkg::Options::=--force-confnew"
DEBIAN_FRONTEND=noninteractive
(Disclaimer: especially the quoted "APT_PARAMS" is highly
environment specific of course and the environment variable is just
named by me/us as such. I know that you - David - know all of that
and that you wrote "[with] That specific invocation can "fail", so
consider it JFTR :))
> Ignoring that reading the apt output even in such invocations isn't
> a bad idea as it will e.g. tell you which packages it can't upgrade
> – I kinda hope you aren't performing a release upgrade unattended…
Several customers of mine have fully automated upgrade procedures,
without any manual intervention needed and I'm sure there are
several other folks doing similar stuff. In big environments with
many systems and also products based on Debian which require easy
upgrade procedures (possibly even by the enduser) I'm actually
expecting to see such practices, since the process to get there can
be automated + tested in advance (that's what we're doing).
regards,
-mika-
signature.asc
Description: Digital signature
Re: Known issues with automatic dbgsym packages (Was: Automatic dbgsym packages built by default as of today!)
* Lars Wirzenius [Tue Dec 22, 2015 at 06:36:55PM +0100]: > On Sun, Dec 20, 2015 at 10:35:05AM +, Niels Thykier wrote: > > * reprepro rejects upload with automatic debug symbols as it does not > >support them yet[1]. (#730572) > >- Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs > >- Workaround #2: Pass --ignore=surprisingbinary to reprepro if you > > can trust all uploaders (and their tools) to behave. > I haven't gotten --ignore=surprisingbinary to actually do what it's > meant to do, at least with "reprepro processincoming". I get this: [...] > > To ignore use --ignore=surprisingbinary. > This is reprepro 4.16.0-1 from jessie (though it seems sid has the > same version). Am I doing something otterly stupid? > I can get it to work by ignoring that reprepro failed, and then > running "reprepro export" afterwards. > Suggestions, anyone? This is #808558. regards, -mika- signature.asc Description: Digital signature
Re: support for merged /usr in Debian
* Stephan Seitz [Fri Jan 08, 2016 at 11:18:41AM +0100]: > On Fri, Jan 08, 2016 at 10:11:07AM +, Jonathan Dowland wrote: > >grml is packaged and is an apt-get away. It's third-party in just the > >same way that the linux kernel, or exim are. > Wrong. You have a wrapper package that adds grml iso from /boot/grml > to the grub.cfg. You have to download the grml images yourself and > you need the space to save the images in /boot/grml. We've an open wishlist bug report for the "download the Grml ISO" part (#754393) which we plan to resolve soonish, jfyi. regards, -mika- signature.asc Description: Digital signature
Re: support for merged /usr in Debian
* Ian Campbell [Fri Jan 08, 2016 at 10:22:01AM +]: > On Fri, 2016-01-08 at 10:11 +, Jonathan Dowland wrote: > > On Fri, Jan 08, 2016 at 10:21:00AM +0100, Marc Haber wrote: > > > The upside of this is that this will free up space in / which will be > > > needed for a dedicated recovery image. Too bad that we don't have such > > > a thing ourselves and have to recommend third-party products like grml > > grml is packaged and is an apt-get away. It's third-party in just the > > same way that the linux kernel, or exim are. > What is the package called? By coincidence I was looking for it the other > day and all I found was: > $ apt-cache search grml > grml-debootstrap - wrapper around debootstrap for installing pure Debian > grml-rescueboot - Integrates Grml ISO booting into GRUB > grml2usb - install Grml system / ISO to usb device The grml-rescueboot package is the one which is meant here. > The first and last are not relevant and AFAICT the middle one is support > for creating grub entries from files in /boot/grml which appear to get > there by some out of band means (i.e. by hand AFAICT). The > Depends/Recommends/Suggests of that package don't mention any other package > which might provide the actual download. Exactly. Once #754393 has been resolved the download of the ISO straight to /boot/grml should be trivial. I'm even considering providing packages named like grml-rescueboot-grml64-small which just execute the said script with according parameters inside their postinst - so once you install grml-rescueboot-grml64-small the ISO is put automatically in place for you. (I highly appreciate any feedback, further wishes, approaches + ideas regarding that.) regards, -mika- signature.asc Description: Digital signature
Request for feedback: systemd backport for jessie
Hi, here at DebConf I've been working on a backport of systemd for jessie. If you're interested in all the new features, bugfixes and changes that systemd received since its version 215-17+deb8u4 (the one available from jessie) you might wanna give it a try. The backport is based on what will be released as v230-6 for Debian unstable soonish. Once systemd v230-6 migrated to testing and if I receive enough feedback I'll upload systemd v230-6 officially towards jessie-backports then. In the meanwhile packages (source + binaries for amd64) and usage instructions are available at: https://people.debian.org/~mika/systemd/jessie/ I'd appreciate any testing and feedback. Special thanks to Michael Biebl for assistance and feedback with the backport. regards, -mika- -- http://michael-prokop.at/ || http://adminzen.org/ http://grml-solutions.com/ || http://grml.org/ signature.asc Description: Digital signature
Re: Request for feedback: systemd backport for jessie
* Brian [Tue Jul 05, 2016 at 08:16:34PM +0100]: > On Tue 05 Jul 2016 at 20:46:07 +0200, Elimar Riesebieter wrote: > > * Michael Prokop [2016-07-05 17:34 +0200]: > > > here at DebConf I've been working on a backport of systemd for jessie. [...] > > Are you aware of the 'Thinking about a "jessie and a half" release' > > thread at debian-devel [0]? > > [0] https://lists.debian.org/debian-devel/2016/07/msg00054.html I am aware, though my work started before the "jessie and a half" thread was started on debian-devel. It's also not yet clear to me what a "jessie and a half" release would mean in terms of package version selection (will packages be uploaded explicitly to p-u or s-p-u, or are backports automatically chosen etc?). But: > I am aware of it. What bearing has it on working on providing a backport > of systemd for jessie (which I would agree with)? Improving the systemd > experience on Jessie can only be for the good of its users. ... was my point about it, to improve the ecosystem and experience for systemd on jessie. regards, -mika- -- http://michael-prokop.at/ || http://adminzen.org/ http://grml-solutions.com/ || http://grml.org/ signature.asc Description: Digital signature
