Re: New ksh/ksh93 package, half the size, ten times the features!!!!
Thorsten, thanks for the review, but the package was not intended for
official review yet. I only send it around, to find a mentor, and then
weed out the bugs, one by one, and some one else leaked that posting
to debian-devel, before the work was ready.
The package was intentionally AMD64 only for now, to simplify testing.
I already have a better, more cross platform version, but still would
prefer to work out the dependencies one, by one, as you already found
out.
Olga
On Fri, Nov 8, 2013 at 1:05 AM, Thorsten Glaser wrote:
> Thorsten Glaser mirbsd.de> writes:
>
>> No, it isn’t – but you could build-depend on mksh, if the script
>> can be run with it (haven’t tested it), possibly with a few changes
>
> OK, I’ve tried with the following patch:
>
> diff -Nru ksh-93v-20131010/debian/control ksh-93v-20131010/debian/control
> --- ksh-93v-20131010/debian/control 2013-01-07 16:58:44.0 +0100
> +++ ksh-93v-20131010/debian/control 2013-11-08 00:58:27.0 +0100
> @@ -3,7 +3,7 @@
> Priority: optional
> Maintainer: Oliver Kiddle
> Homepage: http://www.kornshell.com/
> -Build-Depends: dpkg-dev (>= 1.16.1), debhelper (>= 7)
> +Build-Depends: dpkg-dev (>= 1.16.1), debhelper (>= 7), mksh
> Standards-Version: 3.9.4
>
> Package: ksh
> diff -Nru ksh-93v-20131010/debian/rules ksh-93v-20131010/debian/rules
> --- ksh-93v-20131010/debian/rules 2013-11-05 01:41:56.0 +0100
> +++ ksh-93v-20131010/debian/rules 2013-11-08 00:57:58.0 +0100
> @@ -24,7 +24,7 @@
> build-arch: build-stamp
> build-indep: build-stamp
> build-stamp:
> - /usr/bin/ksh debian/buildksh93.sh build.opt.linux.i386.64bit.gcc.c99
> + mksh debian/buildksh93.sh build.opt.linux.i386.64bit.gcc.c99
> touch build-stamp
>
> clean:
>
> This scared me a bit already: “build.opt.linux.i386.64bit.gcc.c99”
>
> Trying to build it in a clean cowbuilder environment spits out things like:
>
> package: warning: yacc: not found -- some make actions may fail
> package: warning: bison: not found -- some make actions may fail
>
> These are more missing Build-Depends.
>
> Then, it fails:
>
> package: gcc -std=gnu99 -D_GNU_SOURCE=1 -m64 -fPIC -lm -ldl: failed to
> compile this program:
> int main(){return 0;}
> In file included from :0:0:
> /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file
> or directory
> #include
> ^
>
> This is only natural because I’m building for i386, where -m64 is
> utterly wrong.
>
> In short, your package will not work for Debian as-is and needs,
> possibly major, rework.
>
> Sorry,
> //mirabilos
>
>
> --
> 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/loom.20131108t010231-...@post.gmane.org
>
--
, __ ,
{ \/`o;-Olga Kryzhanovska -;o`\/ }
.'-/`-/ olga.kryzhanov...@gmail.com \-`\-'.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
--
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/ca+oh3v2k8jpkgeogip_1bexd8fgqxopi5xgvydai4snumvq...@mail.gmail.com
Re: New ksh/ksh93 package, half the size, ten times the features!!!!
Hi Olga! On 11/08/2013 09:44 AM, ольга крыжановская wrote: > Thorsten, thanks for the review, but the package was not intended for > official review yet. I only send it around, to find a mentor, and then > weed out the bugs, one by one, and some one else leaked that posting > to debian-devel, before the work was ready. I'd highly suggest that you use Debian Mentors (mentors.debian.net) as a hosting platform for the packages to be tested. This is a very common practice in Debian for working on packages and also my preferred way. Uploading packages to Mentors is very fast and easy, so you don't lose time messing around with FTP servers and such. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/527cb66e.9070...@physik.fu-berlin.de
Bug#729048: ITP: catkin -- Low-level build system macros and infrastructure for ROS
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: catkin Version : 0.1.23 Upstream Author : Dirk Thomas * URL : https://github.com/ros/catkin/tags * License : BSD-3-clause Programming Lang: Python Description : Low-level build system macros and infrastructure for ROS Catkin contains CMake macros that are useful in the development of ROS-related systems. In ROS Fuerte and later, many of the lower-level ROS libraries are being migrated to be CMake only. -- 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/20131108100318.6043.81893.report...@soho.upc.es
Bug#729057: ITP: catkin-pkg -- Low-level build system macros for ROS -- Python module
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: catkin-pkg Version : 0.1.23 Upstream Author : Dirk Thomas * URL : https://github.com/ros/catkin/tags * License : BSD-3-clause Programming Lang: Python Description : Low-level build system macros for ROS -- Python module Catkin contains CMake macros that are useful in the development of ROS-related systems. ROS (Robot Operating System) provides libraries and tools to help software developers create robot applications. . This package is a Python module needed to use Catkin. -- 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/20131108120718.6709.57672.report...@soho.upc.es
Re: New ksh/ksh93 package, half the size, ten times the features!!!!
ольга крыжановская dixit: >Thorsten, thanks for the review, but the package was not intended for >official review yet. I only send it around, to find a mentor, and then >weed out the bugs, one by one, and some one else leaked that posting >to debian-devel, before the work was ready. Ah, okay. But on the other hand, early review is good too ☺ I just saw the point of the build script being a Korn Shell script being rised and thought to try whether it works with mksh as build dependency, and if not, maybe whether I could change the script so it does because, obviously, I know the mksh specifics best ;) >The package was intentionally AMD64 only for now, to simplify testing. >I already have a better, more cross platform version, but still would OK. I can test on i386 and m68k ;) >prefer to work out the dependencies one, by one, as you already found >out. Sure. As I said, cowbuilder helps with this. Good luck, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh -- 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/pine.bsm.4.64l.1311081242050.8...@herc.mirbsd.org
Re: Init system deba{te|cle}
On Mon, 04 Nov 2013 10:44:23 -0600 Conrad Nelson wrote: > Not everyone is a programmer, but a lot of non-programmers are still > admins but are not interested in working with shell scripts if they > don't have to. We already have: skeleton, /etc/default. I agree it's poor, but as I said, and at least for me, the right way is to extend existing software: (1) add new features to sysvinit (2) add new software in addition to sysvinit (3) make init scripts more correct (abstraction) (4) extend configurability (more options in /etc/default/*) (3) makes (4) easily possible And if sysvinit is in accord with UNIX philosophy, and as they say it is, than I don't see why (1) and (2) would not be possible, too, and with not to much effort. About what they say as disadvantages of sysvinit (lack of features), is not really to blame sysvinit, because it does one thing and do it right[1]. Other features could be implemented as additional software. On the other hand, what actually was done was writing new software that make old software obsolete and that do *many* things, which is not in accord with UNIX philosophy (and is in accord with authoritarian philosophy). > Further, shell scripts can have any number of bugs in > them that are harder to find than unit files which rarely have more than > a dozen lines in them. Every complex software has bugs, including complex init system. [1] https://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy rule 2 -- http://mr.flossdaily.org -- 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/20131108134841.71563...@eunet.rs
Bug#728606: general: Keyboard shortcuts for Volume, keyboard backlight no longer work. Shortcut for brightness works, but OSD does not
Jonathan Dowland wrote (03 Nov 2013 14:44:49 GMT) : > What desktop environment are you using: E.g., GNOME3, KDE, XFCE, LXDE… > If GNOME 3, do you know whether you are using it in "normal" mode or > "classic" mode (aka fallback mode, sometimes)? I experience exactly the same behavior on current sid with the "GNOME with Xmonad" session. xev shows XF86AudioLowerVolume, XF86MonBrightnessDown etc. events. I have verified in the GNOME keybinding prefs that the correct keys are assigned. GNOME maintainers, please reassign to the relevant component (I've no idea which one it is in GNOME flashback 3.8, sorry) -- and many thanks for maintaining the flashback session! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85li0zgk14@boum.org
Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
Additional arguments in favor of sysvinit: * systemd and upstart lead to vendor lock-in; it will be complicated later to return back or change to third option, as well to change from first to second option * I don't have a feeling that configuration can be very simpler than shell scripts; there are things such as 'events' and such things have to be properly defined) * If OpenRC's development continues in good direction, Debian could switch to OpenRC * If our shell scripts are a mess, then we should clean up the mess, not trying to escape it by changing whole init system; more precisely, we should correct mistakes we made in past, such as not enough abstraction * existing software (sysvinit+initscripts) can be enhanced: (1) add new features to sysvinit; e.g. start-stop-daemon could be extended, to return only when service is ready, or if timeout exceeds to return with error status (2) add new software in addition to sysvinit (3) make init scripts more correct (abstraction) (4) extend configurability (more options in /etc/default/*) (3) makes (4) easily possible If sysvinit is in accord with UNIX philosophy, and as they say it is, than I don't see why (1) and (2) would not be possible, too, and with not to much effort. * What is alleged to be disadvantages of sysvinit (lack of features), is not really to blame sysvinit, because it does one thing and do it right. Other features could be implemented as additional software. On the other hand, what actually was done was writing new software that make old software obsolete and that do *many* things, which is not in accord with UNIX philosophy. * More complex software has more bugs, old software is cleaned out of original bugs, and new software is not. * Software that is not well commented is hard to understand and find bugs For more details: http://lists.debian.org/20131108125545.1b43f...@eunet.rs http://lists.debian.org/20131108134841.71563...@eunet.rs http://lists.debian.org/20131105234316.4407f...@eunet.rs http://lists.debian.org/20131106135535.7d091...@eunet.rs http://lists.debian.org/20131103102302.42493...@eunet.rs -- 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/20131108145437.62663...@eunet.rs
Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
On 11/08/2013 02:54 PM, Marko Randjelovic wrote: > Additional arguments in favor of sysvinit: > > * systemd and upstart lead to vendor lock-in; it will be complicated > later to return back or change to third option, as well to change from > first to second option Exactly what vendor would we be locked into with systemd? > * I don't have a feeling that configuration can be very simpler than > shell scripts; there are things such as 'events' and such things have > to be properly defined) A bash script as glue code between the init daemon is simpler than the simple descriptive XDG format used for systemd's unit files? I don't think so. > * If OpenRC's development continues in good direction, Debian could > switch to OpenRC The word here is "if". It's not going to happen. OpenRC has fundamental issues which haven't been resolved for years now: > https://bugs.gentoo.org/show_bug.cgi?id=391945 I don't think this is a viable alternative to anything. We can't work with vaporware, we need software that actually works. > * If our shell scripts are a mess, then we should clean up the mess, > not trying to escape it by changing whole init system; more precisely, > we should correct mistakes we made in past, such as not enough > abstraction And who is going to do it? Are you? People constantly stating that systems like OpenRC and sysvinit are actually viable alternatives if someone improved them without actually stepping forward themselves leaves me up to the impression that those people actually don't have interests in pushing sysvinit or OpenRC but just blocking the adoption of systemd or upstart. > * existing software (sysvinit+initscripts) can be enhanced: > > (1) add new features to sysvinit; e.g. start-stop-daemon could be > extended, to return only when service is ready, or if timeout exceeds > to return with error status (2) add new software in addition to sysvinit > (3) make init scripts more correct (abstraction) > (4) extend configurability (more options in /etc/default/*) > > (3) makes (4) easily possible The X.org developers were thinking to do the same with X.org but at some point figured out that the sources they are dealing with were such a mess that it's better to start over altogether and started Wayland, see: > http://www.youtube.com/watch?v=RIctzAQOe44 > If sysvinit is in accord with UNIX philosophy, and as they say it is, > than I don't see why (1) and (2) would not be possible, too, and with > not to much effort. No one cares about the "Unix philosophy" (TM), it's not some super holy cow we're not allowed to touch. Additionally, original Unix sucks, it's all the GNU- and Linux-specific extensions that actually made it usable. > * What is alleged to be disadvantages of sysvinit (lack of features), > is not really to blame sysvinit, because it does one thing and do it > right. No, sysvinit doesn't even do the one thing it does right. It has been explained many many times before why that isn't the case. > * More complex software has more bugs, old software is cleaned out of > original bugs, and new software is not. If that should be a dogma we should always stick to, we should immediately abandon all efforts to improve software and go back to Linux 0.01. > * Software that is not well commented is hard to understand and find > bugs Your last statement doesn't hold at all without actually giving a couple if examples where you think that systemd or upstart are poorly documented. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/527d0394.3010...@physik.fu-berlin.de
Re: Bug#727708: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
This has now been discussed ad nauseam. Can we please stop posting about this on -devel and let the tech-ctte work? Thanks, Paul On Fri, Nov 8, 2013 at 10:30 AM, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > On 11/08/2013 02:54 PM, Marko Randjelovic wrote: > > Additional arguments in favor of sysvinit: > > > > * systemd and upstart lead to vendor lock-in; it will be complicated > > later to return back or change to third option, as well to change from > > first to second option > > Exactly what vendor would we be locked into with systemd? > > > * I don't have a feeling that configuration can be very simpler than > > shell scripts; there are things such as 'events' and such things have > > to be properly defined) > > A bash script as glue code between the init daemon is simpler than the > simple descriptive XDG format used for systemd's unit files? I don't > think so. > > > * If OpenRC's development continues in good direction, Debian could > > switch to OpenRC > > The word here is "if". It's not going to happen. OpenRC has fundamental > issues which haven't been resolved for years now: > > > https://bugs.gentoo.org/show_bug.cgi?id=391945 > > I don't think this is a viable alternative to anything. We can't work > with vaporware, we need software that actually works. > > > * If our shell scripts are a mess, then we should clean up the mess, > > not trying to escape it by changing whole init system; more precisely, > > we should correct mistakes we made in past, such as not enough > > abstraction > > And who is going to do it? Are you? > > People constantly stating that systems like OpenRC and sysvinit > are actually viable alternatives if someone improved them without > actually stepping forward themselves leaves me up to the impression > that those people actually don't have interests in pushing sysvinit > or OpenRC but just blocking the adoption of systemd or upstart. > > > * existing software (sysvinit+initscripts) can be enhanced: > > > > (1) add new features to sysvinit; e.g. start-stop-daemon could be > > extended, to return only when service is ready, or if timeout exceeds > > to return with error status (2) add new software in addition to sysvinit > > (3) make init scripts more correct (abstraction) > > (4) extend configurability (more options in /etc/default/*) > > > > (3) makes (4) easily possible > > The X.org developers were thinking to do the same with X.org but > at some point figured out that the sources they are dealing > with were such a mess that it's better to start over altogether and > started Wayland, see: > > > http://www.youtube.com/watch?v=RIctzAQOe44 > > > If sysvinit is in accord with UNIX philosophy, and as they say it is, > > than I don't see why (1) and (2) would not be possible, too, and with > > not to much effort. > > No one cares about the "Unix philosophy" (TM), it's not some super > holy cow we're not allowed to touch. Additionally, original Unix > sucks, it's all the GNU- and Linux-specific extensions that > actually made it usable. > > > * What is alleged to be disadvantages of sysvinit (lack of features), > > is not really to blame sysvinit, because it does one thing and do it > > right. > > No, sysvinit doesn't even do the one thing it does right. It has been > explained many many times before why that isn't the case. > > > * More complex software has more bugs, old software is cleaned out of > > original bugs, and new software is not. > > If that should be a dogma we should always stick to, we should > immediately abandon all efforts to improve software and go back > to Linux 0.01. > > > * Software that is not well commented is hard to understand and find > > bugs > > Your last statement doesn't hold at all without actually giving a > couple if examples where you think that systemd or upstart are > poorly documented. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > -- > To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/527d0394.3010...@physik.fu-berlin.de > > -- :wq
Bug#729075: ITP: qcustomplot -- a Qt C++ widget for plotting
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: qcustomplot Version : 1.1.0 Upstream Author : Emanuel Eichhammer * URL : http://www.qcustomplot.com/ * License : GPL-3 Programming Lang: C++ Description : QCustomPlot is a Qt C++ widget for plotting It has no further dependencies and is fully documented. This plotting library focuses on making good looking, publication quality 2D plots, graphs and charts, as well as offering high performance for realtime visualization applications. QCustomPlot can export to various formats such as vectorized PDF files and rasterized images like PNG, JPG and BMP. All outputs look identical and the generated PDF files can be imported and edited by vector editors like Inkscape, without trouble. So QCustomPlot is useful for both displaying of realtime data inside the application as well as producing high quality plots for other media. The package will be maintained in Debian Science Team. -- 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/20131108170436.20098.52213.reportbug@debian
Bug#729086: ITP: vtk6 -- Visualization Toolkit (VTK) version 6
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: vtk6 Version : 6.0.0 Upstream Author : Kitware * URL : http://www.vtk.org/ * License : BSD Programming Lang: C++ Description : Visualization Toolkit (VTK) version 6 The Visualization Toolkit (VTK) is an open-source, freely available software system for 3D computer graphics, image processing and visualization. VTK consists of a C++ class library and several interpreted interface layers including Tcl/Tk, Java, and Python. Kitware, whose team created and continues to extend the toolkit, offers professional support and consulting services for VTK. VTK supports a wide variety of visualization algorithms including: scalar, vector, tensor, texture, and volumetric methods; and advanced modeling techniques such as: implicit modeling, polygon reduction, mesh smoothing, cutting, contouring, and Delaunay triangulation. VTK has an extensive information visualization framework, has a suite of 3D interaction widgets, supports parallel processing, and integrates with various databases on GUI toolkits such as Qt and Tk. VTK is cross-platform and runs on Linux, Windows, Mac and Unix platforms. The package will be maintained in Debian Science Team. -- 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/20131108213254.24085.76516.reportbug@debian
Re: Arguments for tech-ctte
Marko Randjelovic writes: > Additional arguments in favor of sysvinit: [...] Hi Marko, The pro-sysvinit page on https://wiki.debian.org/Debate/initsystem currently doesn't even a maintainer, and at least some members of the tech committee have said that they'll make their decision mostly based on the arguments presented there. So I think the best way to make your case would be to work on https://wiki.debian.org/Debate/initsystem/sysvinit. Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« -- 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/87li0ygnlj@vostro.rath.org
