epoch bump request for protracker
Emailing only debian-devel, replies with cc to me please. protracker [1], version 2.b37-1 now release a non-beta version called 1.01. Instead of permanently using 2.b37+really1.01, I'd go for 1:1.01, and renaming protracker to pt2-clone [2] (as upstream calls it) (the source+bin pkg rename at a later time) So is it appropriate to bump an epoch in Debian to fix the versioning of protracker? Kind regards, [1] https://packages.debian.org/sid/protracker [2] https://github.com/8bitbubsy/pt2-clone
Re: RFH: drawxtl seg-faulting (#853829)
On Mon, 2019-12-23 at 00:58 +0100, Daniel Leidert wrote:
> Hi,
>
> I'm in need of assistance to fix #853829. The issue is that drawxtl segfaults
> on exit. The offending lines are 350 and/or 356 (and similar) in
> source/DRAWxtl55/CrystalView.cxx. I get the gut feeling that calling the
> delete() function on the Fl_Window objects (Configure->ConfigWindow), for
> which
> the destructor (~Fl_Window()) already has been called, might be the issue
> here:
>
> > if (Configure) {
> > Configure->ConfigWindow->~Fl_Window ();
> > delete (Configure->ConfigWindow);
> > delete (Configure);
> > Configure = NULL;
> >
>
> But I'm not experienced with FLTK and I even cannot find a description of the
> delete() function to judge,
That's because delete is an operator, not a function.
> if this method is safe or unsafe to call here. If
> I'm right, the fix is as easy as commenting out the relevant delete() calls.
>
> Any help is appreciated.
If Configure->ConfigWindow has been allocated with the new operator,
the direct call to the destructor is wrong and the delete is correct.
If it has been allocated in some unusual way, then the direct call to
the destructor is probably correct and the delete is wrong.
Ben.
--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.
signature.asc
Description: This is a digitally signed message part
RFH: drawxtl seg-faulting (#853829)
Hi,
I'm in need of assistance to fix #853829. The issue is that drawxtl segfaults
on exit. The offending lines are 350 and/or 356 (and similar) in
source/DRAWxtl55/CrystalView.cxx. I get the gut feeling that calling the
delete() function on the Fl_Window objects (Configure->ConfigWindow), for which
the destructor (~Fl_Window()) already has been called, might be the issue here:
> if (Configure) {
> Configure->ConfigWindow->~Fl_Window ();
> delete (Configure->ConfigWindow);
> delete (Configure);
> Configure = NULL;
>
But I'm not experienced with FLTK and I even cannot find a description of the
delete() function to judge, if this method is safe or unsafe to call here. If
I'm right, the fix is as easy as commenting out the relevant delete() calls.
Any help is appreciated.
Regards, Daniel
signature.asc
Description: This is a digitally signed message part
Re: default firewall utility changes for Debian 11 bullseye
On 7/16/19 11:07 AM, Arturo Borrero Gonzalez wrote: > For the next release cycle I propose we move this default event further. > As of this email, iptables [0] is Priority: important and nftables [1] is > Priority: optional in both buster and bullseye. The important value means the > package gets installed by default in every Debian install. > > Also, I believe the days of using a low level tool for directly configuring > the > firewall may be gone, at least for desktop use cases. It seems the industry > more > or less agreed on using firewalld [2] as a wrapper for the system firewall. Gosh, no... The industry agrees to use whatever is convenient for the application it is maintaining. Let me give an example. In OpenStack, Neutron does the networking. It is supposed to handle *all* of what goes in iptables, via neutron-openvswitch-agent. At no point, I have read anyone proposing to switch away from using iptables directly, and using firewalld instead. Please do not try to imagine what people do with iptables. You'd be wrong in many cases. BTW, when using Neutron with Buster, I was very surprised that *in some cases*, it completely breaks if we don't have iptables-legacy as the installed alternatives. It took me a long time to figure out that the iptables-nft implementation, if looking similar, isn't producing the same output, and therefore, breaking Neutron is some corner cases. Hopefully, upstream will work on that, but this was a very bad surprise that I had to address when running in production (as it *looks like* working at first, but in fact doesn't in the long run). > There are plenty of system services that integrate with firewalld anyway [3]. > By the way, firewalld is using (or should be using) nftables by default at > this > point. I have no experience running firewalld myself, but my only message is: please don't break other people's computer. Hopefully, having firewalld by default will not (but you never know, when these ...d services rush into Debian too fast...). > 2) introduce firewalld as the default firewalling wrapper in Debian, at least > in > desktop related tasksel tasks. I don't mind for desktop cases much, I know how to fix things. I'm more scared if this breaks newbies, and server side. For servers, maybe don't install stuff by default, and let the admin decide? Hopefully, both will be taken care of, right? Cheers, Thomas Goirand (zigo)
Bug#947187: ITP: citop -- Monitor CI pipelines from the command line
Package: wnpp Severity: wishlist Owner: Sebastien Delafond * Package name: citop Version : 0.2.0 Upstream Author : Nicolas Bedos * URL : https://github.com/nbedos/citop * License : BSD Programming Lang: Go Description : Monitor CI pipelines from the command line A UNIX program to monitor Continuous Integration pipelines from the command line. citop stands for Continous Integration Table Of Pipelines. . List pipelines associated to a commit of a GitHub or GitLab repository: pipelines are shown in a tree view where expanding a pipeline will reveal its stages, jobs and tasks . Integration with Travis CI, AppVeyor, CircleCI, GitLab CI and Azure DevOps: citop is targeted at open source developers . Monitor status changes in quasi real time . Open the web page of a pipeline by pressing a single key: for quick access to the website of your CI provider if citop does not cover a specific use case.
Bug#947180: ITP: qjoypad -- map gamepad/joystick events to mouse/keyboard event
Package: wnpp Severity: wishlist Owner: Adam Borowski I'd like to reintroduce this package -- it went from being maintained to RMed without orphaning or pinging bug correspondents first. While its original upstream is gone, there are live forks, that include QT5 support. * Package name: qjoypad Version : 4.3.1 Upstream Author : Mathias Panzenböck and others * URL : https://github.com/panzi/qjoypad * License : GPL=2 Programming Lang: C++ Description : map gamepad/joystick events to mouse/keyboard event QJoyPad takes input from a gamepad or joystick and translates it into key strokes or mouse actions, letting you control any X-Windows program with your game controller. This lets you play all those games that for some reason don't have joystick support with your joystick.
Bug#947160: ITP: sk1 -- advanced vector graphics editor
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: sk1 Version : 2.0~rc4 * URL : https://sk1project.net/sk1/ * License : GPL-3 Programming Lang: Python Description : advanced vector graphics editor Inkscape is good and I like it. This alternative may look good as well. I'll decide whether to really package it after trying it out.
