Bug#949950: ITP: libh5cpp-dev -- H5CPP is a novel approach to persistence in the field of machine learning and science, it provides high performance sequential and block access to HDF5 containers thro
Package: wnpp Severity: wishlist Owner: ste...@vargaconsulting.ca * Package name: libh5cpp-dev Version : 1.10.4.5 Upstream Author : Steven Varga * URL : http://h5cpp.org/ * License : MIT Programming Lang: C++ Description : H5CPP is a novel approach to persistence in the field of machine learning and science, it provides high performance sequential and block access to HDF5 containers through modern C++ templates. It supports major linear algebra libraries such as armadillo, eigen3, dlib, itpp, blaze, boost::ublas in addition to stl::vector. And it has an amitious plan to provide quality non-intrusive persistence for arbitrary C++ objects. H5CPP and its LLVM based companion the H5CPP-COMPILER was first introduced in Chicago C++ usergroup meeting in 2018 fall, has been presented at ISC'19 BOF and is a collaboration between The HDFGroup and the author. The package is to replace the somewhat outdated HDF5 C++ library. Its RAII enabled resource handles are fully interchangeable with HDF5 CAPI hid_t, and in most cases are binary compatible. The origins of H5CPP roots in High Frequency Trading data solutions, where having low latency high throughput sequential and block data access is critical. Since the inception of H5CPP the code has been used for general scientific purposes on supercomputers and workstations, is found to be useful in sensor networks and particle colliders. The following packages has been examined before development:HDF5 C++, ess-dmsc/h5cpp, HighFive by Blue Brain, H5TL, HDF5Wrapper, hdf5wrap, hdf5pp, H5Easy before the development of this project, and many of the shortcomings has been addressed. In terms of maintainability, functionality and performance it is found to be ahead of alternative solutions, with its companion package: H5CPP COMPILER, it provides assisted reflection based persistence bringing C++ planned reflection/introspection into today. H5CPP is constantly improved and may be influenced by attending the HDF5 C++ user group meetings, or through direct contact with author. Future plans: In the next release full STL object support with arbitrary POD and standard layout types; shifting towards template based introspection, sparse linear algebra support and interop with modern statistical platforms (julia, python, R), multi dataset support for complex object types. In the current research phase the author began collaborating with domain specific format authors to standardise and support higher level formats in fields such as genetics, visualisation/graphics, physics, ... . Maintenance and sponsor: the author, steven varga is to maintain the library, and yes looking for sponsor website: http://h5cpp.org documentation: http://sandbox.h5cpp.org/ ISC'19 Frankfurt presentation: http://isc19.h5cpp.org/ 2019 HDFGroup webinar: https://www.youtube.com/watch?v=7A5dPL7zrj0&t=56s webinar-slides: http://webinar.h5cpp.org/ HDFGroup blog(copy): http://sandbox.h5cpp.org/blog/ Repository: https://github.com/steven-varga/h5cpp
Bug#949951: ITP: h5cpp-compiler -- This LLVM/clang based C++ source code transformation tool automates the otherwise time consuming, error prone process of generating type descriptors for HDF5 Compoun
Package: wnpp Severity: wishlist Owner: ste...@vargaconsulting.ca * Package name: h5cpp-compiler Version : 1.10.4.5 Upstream Author : Steven Varga * URL : http://h5cpp.org/ * License : MIT Programming Lang: C++ Description : This LLVM/clang based C++ source code transformation tool automates the otherwise time consuming, error prone process of generating type descriptors for HDF5 Compound datatypes by building the AST of a given TU translation unit, and identifying all POD datatypes referenced from H5CPP operators/functions. The result is a seamless, non-intrusive persistence much similar to python, java or other interpreted languages. This LLVM/clang based C++ source code transformation tool automates the otherwise time consuming, error prone process of generating type descriptors for HDF5 Compound datatypes by building the AST of a given TU translation unit, and identifying all POD datatypes referenced from H5CPP operators/functions. The result is a seamless, non-intrusive persistence much similar to python, java or other interpreted languages. With its companion, the H5CPP C++ header library, provides high performance low latency, non-introusive persistence support for modern C++. Its application is to aid easy data transfer from memory and persistent storage by simply including the header files and calling one of the H5CPP CRUD like operators. AFAIK the author is not aware of the existence of similar packages, however is constantly monitoring the current state of C++ reflection and introspection with the intention of replacing the compiler once the new C++ features become available. This package depends on the LLVM/clang front end, and requires the companion libh5cpp-dev to perform compile time reflection/introspection. Much similar to libh5cpp package I intend to maintain the H5CPP COMPILER and looking for sponsor. website: http://h5cpp.org ISC'19 presentation: http://isc19.h5cpp.org/#/2 repository: https://github.com/steven-varga/h5cpp-compiler
Bug#950819: ITP: h5cpp-compiler -- LLVM based compiler assisted reflection for modern C++
Package: wnpp Severity: wishlist Owner: ste...@vargaconsulting.ca * Package name: h5cpp-compiler Version : 1.10.4.5 Upstream Author : Steven Varga * URL : http://h5cpp.org * License : MIT Programming Lang: C++ Description : LLVM based compiler assisted reflection for modern C++ H5CPP-compiler automates the tedious and error prone process of handwriting HDF5 compound type data descriptors providing similar level of data serialization/persistence experience of popular interpreted languages but compile time. This non-intrusive source code transformation tool is a companion to h5cpp template library it builds the AST of a specified translation unit, identifies arbitrary deep POD struct variables referenced/used by the template library operators: h5::create | h5::read | h5::write | h5::append h5::acreate | h5::aread | h5::awrite and generates the necessary HDF5 compound datatype descriptors. In the second phase, using system compiler gcc,clang,msvc, ... the user compiles this now complete translation unit into an object file. The h5cpp compiler assisted reflection and its companion header library was developed for low latency event stream recording arising in high frequency trading applications, Real Time Bidding and general machine learning. Primary competing idea to compiler assisted reflection is the recently developed purely template based introspection and reflection for C++ which is not yet available. While there are many related work based on runtime approach, or templates most of them requiring some modification to original code making it intrusive, or less performance oriented. Maintenance and sponsor: the author, steven varga is to maintain the h5cpp-compiler, and yes looking for sponsor
Re: Debian installation problem on Macbook pro from 2019
On 8/23/24 00:24, lina wrote: Hi, During the Debian (stable) installation on Macbook pro from 2019, my internal keyboard is not recognizable even I exhausted all possible keyboard options listed during dpkg-reconfiguration keyboard-configuration # more /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. *XKBMODEL="apple_laptop"* XKBLAYOUT="us" XKBVARIANT="dvorak-classic" XKBOPTIONS="lv3:ralt_alt" BACKSPACE="guess" I also tried *XKBMODEL="macbook79" XKBMODEL="macbook78" XKBMODEL="macintosh"** XKBMODEL="macintosh_old"* *XKBMODEL="apple"* *XKBMODEL="applealu_ansi"* # dmesg | grep -i keyboard [ 2.237578] usb 1-1.2: Product: Magic Keyboard [ 2.464951] usb 1-1.3: Product: USB Keyboard [ 2.466381] apple 0003:05AC:0267.0002: fixing up Magic Keyboard battery report descriptor [ 2.466464] apple 0003:05AC:0267.0002: Fn key not found (Apple Wireless Keyboard clone?), disabling Fn key handling [ 2.466485] input: Apple Inc. Magic Keyboard as /devices/pci:00/:00:14.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:0267.0002/input/input6 [ 2.466530] apple 0003:05AC:0267.0002: input,hiddev0,hidraw1: USB HID v1.10 Keyboard [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input0 [ 2.466686] input: Apple Inc. Magic Keyboard as /devices/pci:00/:00:14.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:05AC:0267.0003/input/input7 [ 2.471679] hid-generic 0003:2109:D101.0005: hiddev1,hidraw2: USB HID v1.10 Device [VIA Labs, Inc. USB Keyboard ] on usb-:00:14.0-1.3/input0 [ 2.523233] apple 0003:05AC:0267.0003: input,hiddev2,hidraw3: USB HID v1.10 Keyboard [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input1 [ 2.523305] apple 0003:05AC:0267.0004: hiddev3,hidraw4: USB HID v1.10 Device [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input2 [ 4.231170] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout... I have done a lot of installs on a 2011 iMac, and in my experience, you need to do it with a wired USB keyboard. After the install, you can manage the system with any keyboard you can manage to get working, but for the purposes of installation, the Debian Installer and the Macintosh together seem to need a wired USB keyboard.
Re: Please make Moria free (was: Moria, as in the Author of)
Robert Koeneke wrote: Ok, I am working on getting the correct GPL statement put together so this game on all the games based on it don't have any restrictions to distribution. It was never my intention to make it hard to share, just to make certain my name stayed with the game and future variants of it. This is really good news. Don't worry, your name will stay there forever. The really funny thing is that someone has done a survey of who has written what linux code... and your name appears 19th in the list of all authors in terms of numbers of lines of code. (And this is after only including two of the many games with the original Moria in their ancestry.) http://www.gnoppix.org/pages/rute/node51.html Sheesh, I should have gone into game design I guess. I had no idea people were still playing these games. Did anyone ever add the Moria V5.0 new features to the game? Liquids (pools, streams, lava, etc), orbs, and recipes for building magic weapons? There were other things but that's the stuff I remember off-hand. I don't think they ever made it into Moria. However, quite a few Angband variants have them. The liquids are in Zangband, and variants based on that, with a few exceptions in the geneological tree like Oangband. There aren't that many variants which allow building magic weapons. The most notable is Sangband, which has 'fenneling', which turned out to be a little unbalanced, which probably is why the idea didn't propagate. iirc, no variant has what you originally envisaged orbs to be... However, rings and amulets have exploded in variety in quite a few versions of the game, filling the design space with rough equivalents. Steven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#566126: ITP: openpgm -- Implementation of the Pragmatic General Multicast protocol
HI Adrian, A year later and I have a basic Autoconf/Automake system in trunk for OpenPGM ready to package for Debian. I have a machine readable copyright file ready but pretty much stuck on getting anything else working. The Autoconf system actually builds a libtool shared library in addition to the regular static library now. http://miru.hk/tmp/copyright I'm trying to get everything in order for a Debian package before my next release so the sources still need to be pulled from SVN until I can tag and upload a tarball. -- Steve-o
Re: Bug#95975: mutt: doesn't use charset anymore
On Fri, May 04, 2001 at 11:20:21PM +0200, Richard Atterer wrote: > While we're at it: How on earth can I get rid of those > > Warning: locale not supported by Xlib, locale set to C > > messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts etc in mutt. > Unfortunately, this produces the above error message with lots of X > programs - especially annoying when you use at(1); you always get a > mail with the error message. I got an error very similar to this. possibly that error, though not only for mutt. Basically it was for any X program pretty much. Back when I had an X installation I had compiled myself (4.0.2) on potato. I had compiled form the instructions with the X source, and got that error with all programs, it was not till I read the DRI compile howto page a few months later and saw this instruction in http://dri.sourceforge.net/doc/DRIcompile.html === 9.3 Update Locale Information To update your X locale information do the following: cd ~/DRI-CVS/build/xc/nls ../config/util/xmkmf -a make make install === once I did that it all worked fine and I have not seen the message since. See You Steve -- [EMAIL PROTECTED] http://wibble.net/~sjh/ Look Up In The Sky Is it a bird? No Is it a plane? No Is it a small blue banana? YES
Re: [woodm@equire.com: XFree86 common]
On Thu, Aug 30, 2001 at 08:34:45PM +0200, Marcus Brinkmann wrote: > Give a person a fish, and he will won't starve today. Teach him how > to fish, and he will never have to starve anymore. btw the use of person followed by he is kind of weird in the above. and it opens us up to lots of fun interpretations... Give a "man" a fish, and he wont starve today. Teach him how to fish, and he will sit in a boat and drink beer all day. Heard that from some comedian on the radio the other day AFAIR. See You Steve -- [EMAIL PROTECTED] http://wibble.net/~sjh Look Up In The Sky Is it a bird? No Is it a planeNo Is it a small blue banana? Yes
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 02:44:01PM +0200, Michael Bramer wrote: > On Wed, Sep 05, 2001 at 09:49:09PM +1000, Hamish Moffatt wrote: > > On Wed, Sep 05, 2001 at 12:11:56PM +0100, Nick Phillips wrote: > > > I'd have thought that the current situation re. maintainers putting > > > translations into .debs makes it blindingly obvious that requiring them > > > to do so in order for a translation to become available is a bad idea. > > > > Do package descriptions change so regularly that translated descriptions > > couldn't be submitted through the bug tracking system and included > > in the next upload? > > > > Most of my packages have never had their description changed from > > when I first wrote it. It would be better if we could just include > > translated descriptions in the debian/control file. > > See also the other mail: >50 changes in 10 days in main/sid > > But if you include the translation only in the debian/control you have > - delays (maybe we have a override file and can solve this) > - you will have outdated translations (like debconf now) > - you must patch dpkg etc. in a wide way > > We can include the translation in the package. This is not the > problem, but please not in the control file. The translation is no new > information of the package, it is only a translation. Only a other form of > the orignal text. > > Please read the last proposal, I explain a possibly solution in it. I wonder if the translators are over reacting here, yes people seem worried aboout the number of bug reports or whatever translations are generating. However this is because at the moment the translation effort is generating a lot of output. A lot of output is generated in some manner whenever there is a large addition to the distribution. Such as a new port. For example when ia64 porters did a whole lot of automatic bug submissions en masse a few months ago, some people got annoyed at the behavior, however that was an example of a new addition to debian generating a huge number of changes or needs for bug fixing. Thus it is obvious that when adding a lot of brand new shiny translations to packages a lot of bug reports would be generated (or translations notifications or whatever.) However once the translation effort settles down (which I assume will happen at some point, ie when the majority of packages have translated descriptions) the only times you get a whole lot of messages about translation is for each new package added to debian, or if description changes. The second is rare as has been pointed out, and new packages, well everything else about a packagve goes into the bts. Just because it seems at the moment that too many translation notifications are being generated for them to be placed into the bts I wonder if it is overkill/added complexity to try to use something else, as I would assume the number of translation notifications happening will not be so high permanently. As someone has pointed out the translation effort for the strings inside packages outputs to the bts, why not this, afterall once this settles down i would assume description translations would generate a much smaller stream of translations for packages already in debian. See You Steve -- [EMAIL PROTECTED] http://wibble.net/~sjh Look Up In The Sky Is it a bird? No Is it a planeNo Is it a small blue banana? Yes
Re: yes && bg
On Wed, Apr 10, 2002 at 12:01:57PM +0200, Michal Medvecký wrote: > Hi, > > anyone know about this problem in debian? > > yes > ^z > bg > > and the terminal ignore any pressed key || combination. Well, I don't see anything unexpected: [EMAIL PROTECTED]:~$ yes y y y y [lots of y's...] y y y [1]+ Stopped yes [EMAIL PROTECTED]:~$ bg y y y y y [lots more y's...] y y yf y y [...] y y yg y y [...] y y y y y y [...] y y y [I press ^C] [EMAIL PROTECTED]:~$ Nothing unusual as far as I can tell. I still have a working shell under all those y's. You could probably do some magic with bash's kill builtin command to stop that job too, if you wanted to. -- Steven Barker [EMAIL PROTECTED] QOTD: "Every morning I read the obituaries; if my name's not there, I go to work." Get my GnuPG public key at: http://www.blckknght.org/publickey.asc Fingerprint: 272A 3EC8 52CE F22B F745 775E 5292 F743 EBD5 936B pgpa2055NpuJm.pgp Description: PGP signature
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On 12/07/14 02:09, Steven Chamberlain wrote: > [...] these warnings would be treated as errors: > >> > In file included from md5/md5_locl.h:98:0, >> > from md5/md5_dgst.c:60: >> > md5/md5_dgst.c: In function 'md5_block_data_order': >> > ./md32_common.h:237:66: warning: right-hand operand of comma expression >> > has no effect [-Wunused-value] >> > # define HOST_c2l(c,l) ((l)=*((const unsigned int *)(c)), (c)+=4, l) >> > ^ A new upstream release LibreSSL 2.0.1 already addressed that: basically stop using -Werror in the portable library because many compilers have warnings that OpenBSD's compiler does not, and I guess they did not think the warnings legitimate or worth the effort of 'fixing' right now. This new version brings in many small changes from the still-ongoing cleanup. ABI versions bumped to libcrypto 30.0.0 and libssl 27.0.0. AFAICT only private_RC4_set_key was removed, and ssl_version_string added to the respective libraries' exported symbols. Am I right in thinking Debian would not bump its own SONAME if there were unimportant ABI changes, like these seem to be? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53c2ef58.4050...@pyro.eu.org
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On 14/07/14 21:08, Toni Mueller wrote: >> > You forget one of the big problems with OpenSSL that LibreSSL doesn't >> > fix: the license. > Granted. Due to the amount of inherited code, it can't. We'll see how > things evolve as the amount of inherited code will dwindle. So, merely as a result of the licensing, we could have a fascinating situation whereby: * BSD-licensed software contemplates switching from OpenSSL to LibreSSL * GNU-licensed software keeps using OpenSSL with license exception, or maybe someday switches to GnuTLS So, this reduces the amount of software that could potentially switch from OpenSSL from LibreSSL. And since BSD and GNU software are unable to link against each other, it reduces the likelihood that something will indirectly link against OpenSSL and LibreSSL at the same time (the situation Russ Allbery described). So actually I think this simplifies things. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53c43d49.6070...@pyro.eu.org
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On 16/07/14 03:06, Paul Tagliamonte wrote: > I didn't see this yet in the thread, so: > https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux What's most interesting is that someone spent such effort to look for this; that there are so many eyes now on both the original OpenSSL and the new LibreSSL code. Both projects ought to benefit from this. This was a real, but totally contrived issue with many preconditions: * initial 'grandparent' process initialises LibreSSL's PRNG, then forks * first-forked process does not use the PRNG yet, but forks again * grandparent uses the PRNG for things and then exits, freeing up the pid to be re-used * second-forked 'grandchild' process might coincidentally get the same pid as its grandparent * grandchild uses the PRNG for things; LibreSSL would not realise it has forked if the pid is the same, so does not reseed - PRNG output would be repeated from what the grandparent got before it exited - possibly having security impact The other major concern was about scary entropy-gathering code, implemented in LibreSSL Portable for Linux as a last resort for when /dev/urandom can't be read. I agree that it's too risky, or: too difficult to prove safe and robust in any conceivable situation. Debian's major OpenSSL bug was able to happen undetected for a while out of similar circumstances. A compile-time ifdef already allows to disable this fallback code and raise SIGKILL instead, crashing the calling process. As part of the LibreSSL port to GNU/kFreeBSD and Hurd I would actually have asked that we do this anyway in Debian, at least for those platforms. It seems extreme, but the point is that something must be wrong on the system if we get to the fallback code - /dev/urandom missing from a chroot, or fd's exhausted, and the kernel not having a reliable sysctl interface like OpenBSD's to get random bytes in the first place. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
(This may seem a little off-topic for the ITP but please bear with me...) On 16/07/14 21:13, Guillem Jover wrote: > kFreeBSD does have a supported sysctl for this: CTL_KERN KERN_ARND. > (As does NetBSD which has two, KERN_URND and KERN_ARND.) Actually yes, we would certainly want to use that. But is there any conceivable way it could fail? (sysctl calls can return an error code). What could we do then? We'd need to figure this out if we want the prospective libressl package to build on GNU/kFreeBSD on Hurd. Currently it won't build, because it needs either a kernel-specific getentropy implementation, or arc4random. libbsd's arc4random.c, I'm guessing was based on older OpenSSH Portable sources. If reading /dev/urandom fails, it uses only gettimeofday, getpid, and uninitialised bytes from the stack (as a seed to the PRNG). LibreSSL Portable on Linux has the new, scary fallback mechanism instead, more comprehensive, but I honestly don't like that approach. It's too difficult to estimate how much entropy it could really gather, or potential failure cases. And we wouldn't even know when the fallback was being used. Native OpenBSD would actually raise SIGKILL if their sysctl fails. (Their cvsweb is down - quoting inline from arc4random.c instead) : > _rs_stir(void) > [...] > if (getentropy(rnd, sizeof rnd) == -1) > raise(SIGKILL); libevent's arc4stir is different again; it's defined to return an int, with -1 indicating a failure of all attempts to seed: * from /dev/urandom * from /proc/sys/kernel/random/uuid * using a kernel-specific sysctl These arc4random implementations also differ in which stream cipher they use also (RC4 originally, ChaCha20 in newer OpenBSD code). As a result of all this mess, I think we should be looking to converge on a single arc4random implementation, in a place such as libbsd, but make sure it is up to the task first. If arc4random is available and LDFLAGS include -lbsd, LibreSSL Portable will actually use it instead of the bundled implementation. I'm guessing OpenSSH Portable would do this too (I can see it being tested for by ./configure in the buildd log). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53c6e74d.8080...@pyro.eu.org
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Oh, and note that OpenSSH Portable uses RAND_bytes from libssl to seed its arc4random implementation. So AFAICT if you were to link OpenSSH Portable against LibreSSL Portable, it would get really crazy: /dev/urandom or sysctl or scary fallback -> LibreSSL Portable getentropy -> LibreSSL Portable arc4random.c (ChaCha-20) -> LibreSSL RAND_bytes -> OpenSSH Portable arc4random.c (ChaCha-20) -> OpenSSH with the stream cipher, seeding and stirring all happening twice. So I really like the idea of both getting an arc4random implementation from one place, such as libbsd. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53c6ec32.9000...@pyro.eu.org
Re: Re: people.debian.org will move from ravel to paradis and become HTTPS only
Some sites (I mean, deployments) like to use a caching proxy, especially if many machines use the same resource, and/or bandwidth is scarce. Or even just one machine accessing the same resource often. Maybe this won't apply to anything particular on people.d.o, but certainly a lot of websites are breaking this recently by becoming HTTPS-only. In the case of people.d.o I guess most issues will arise from clients not having HTTPS support at all, or not being willing/able to follow a redirect. I'm curious to know the rationale for shutting down HTTP access, because if it is to generally protect web browsers doing web-based login and using cookies, that would typically be covered by HSTS. And the privacy-concious may be using the HTTPS Everywhere add-on. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53c70005.5020...@pyro.eu.org
Re: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi, > Steven Chamberlain writes: >> And since BSD and GNU software are unable >> to link against each other, [...] Oops, I should have said there that "BSD software *if now linking against LibreSSL*" couldn't link with GNU software any more. On Mon, 14 Jul 2014 13:32:40 -0700, Russ Allbery wrote: > I'm not sure that I understand your argument. In fact, this seems like a > rather strong argument *against* using LibreSSL. It is, and yet I hope that's some reassurance that packaging LibreSSL would not be harmful - if only certain packages are able to use it at all due to licensing - and still fewer packages are allowed to link against those packages in turn. The effect of licensing makes the problem of conflicting symbols much less likely to happen. Potential (someday) users of packaged libressl libraries may tend to be non-GPL, or BSD-specific, "leaf" packages. Some ideas: * openssh * nginx, lighttpd, stud * postfix or simpler MTAs * some basic FTPDs * bare-bones 'fetch'-type utilities * some of GNU/kFreeBSD's freebsd-utils, such as geom * things that people build on their own systems * embedded systems Using LibreSSL in something like libcurl is where it would be most at risk of symbols clashing with OpenSSL when linked with other things, but that seemingly should never happen due to licensing (too much software would be excluded from using it, for libcurl to switch). > In the world in which BSD software is linked with LibreSSL and the license > exceptions have not been changed to allow OpenSSL-derived software, now > (due to the way that Debian applies this rule transitively) GPL software > can't link against BSD-licensed libraries that link with LibreSSL Yes, exactly this. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53c70f0d.2030...@pyro.eu.org
Re: Jessie without systemd as PID 1?
Hi, On Fri, 29 Aug 2014 10:46:28 +0200, Svante Signell wrote: > [...] only way to do that now is to install with the installer, getting > systemd-sysv as PID 1, and later install sysvinit-core, systemd-shim > etc? I've been dreaming of #758116 (allowing to select Debian Blends selection during installation) and having as one of the options, a new Blend perhaps called "Debian alt-init", with one of more 'flavours' that each would install an alternative init system and its dependencies. That would happen after d-i has already installed the base system, including systemd packages, but the idea is that those would be removed before the installed system is booted for the first time. Could it really be this simple? Is anyone crazy enough to help make this happen? And a sponsor who could help with an ITP? I've put together the beginnings of a Blends package here, completely untested yet but just in the hope of maybe getting something started: http://pyro.eu.org/debian/pool/main/d/debian-altinit/ Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Jessie without systemd as PID 1?
Hello, On 01/09/14 11:42, Mike Gabriel wrote: > as I am currently working on a thinclient environment for X2Go which > needs such an alt-init approach beyond wheezy, I will be happy to > help-out with sponsoring and testing. Great! I was quite sure there will be users who need such a setup for backward-compatibility. d-i support for Blends sounds like a really easy way that doesn't require custom install discs. (If other people have good uses cases for this, please mention them). The systemd-must-die 'anti-package' tried to do this another way and was rejected. I hope a Blend would be a more constructive approach. I'm thinking sysvinit would be the easiest 'flavour' to implement for jessie, but others are possible, probably only using legacy Sys-V init compatibility rather than native service files, for now. sysvinit scripts will still be in use on the kfreebsd and hurd ports for jessie, so most packages will still ship them even if they have systemd units also. We have a tech-ctte resolution in our favour, that reasonable changes should be accepted into packages to make sure alternative init systems work. I don't currently expect GNOME to work properly without systemd, I'd prefer to focus on other desktops instead, but if GNOME's basic functionality still works that would be nice. (I wonder if the bugreport template could mention if a non-default init system is used). I'm going to have a read over ITP procedure, mentors.d.n and Blends documentation and then I will get back to you. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Pre-Depends changed for dpkg on GNU/kFreeBSD
Hi! On 19:34, Guillem Jover wrote: > In dpkg 1.17.13 I switched start-stop-daemon on GNU/kFreeBSD to use > the native kFreeBSD backend using libkvm instead of using the Linux > backend through linprocfs. Ahhh I did wonder about that. start-stop-daemon had problems inside of jails due to this; KVM needs /dev/mem, and that usually should not be available inside a jail. (netstat for example supports KVM but has a fallback method to be able to still work in jails, I think.) > Requiring linprocfs has always seemed > somewhat wrong to me, more so when on FreeBSD procfs is actually > optional. I'm usually uncomfortable seeing userland use libkvm to look at kernel internals, because unlike FreeBSD, we need to support mismatching versions of kernel and userland (e.g. sid chroot on the stable buildds). Most of Debian GNU userland expects linprocfs so, even though it seems kind of lame to a FreeBSD person, it's useful to us as a psuedo-standard interface that is always available (including jails and any properly- constructed chroot). > This means the library is now part of dpkg's Pre-Depends only on > GNU/kFreeBSD. But I forgot to bring it up here as per policy §3.5 > before the upload. Doing so now, but if there's no consensus, I'll > revert the change. Sorry about that. No problem. Does that mean you'd happily revert to using linprocfs? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141002210336.ga10...@squeeze.pyro.eu.org
Re: Pre-Depends changed for dpkg on GNU/kFreeBSD
On 08/10/14 11:47, Guillem Jover wrote: > I'm thinking that I could also make the code fallback to linprocfs at > run-time in case the ki_structsize member differs from the size known > at build time, which would give an additional safe guard, in case the > above does not hold true. In that case please also fall back to linprocfs if kvm is simply unavailable at run-time, e.g. no /dev/kmem, perhaps because in a chroot or jail. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/54352c88@pyro.eu.org
Re: Pre-Depends changed for dpkg on GNU/kFreeBSD
On 04/10/14 22:59, Guillem Jover wrote: > I've also fixed an issue when kvm_getprocs(3) does not find any pid, > which might have also been involved in the errors you where seeing. I've just observed this on kfreebsd-amd64, in 1.17.13 but it is fixed by upgrading to 1.17.16, thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/54372276.1070...@pyro.eu.org
Re: A small thanks to the kFreeBSD porters
Hi Tino, Tino Mettler wrote: > I also was bugged by a sockopt related FTBFS on kFreeBSD last weekend. Which package is that? I didn't notice anything like that on buildd status pages. > I tried my luck on #debian-kbsd which I was pointed to on a wiki page. > It was rather silent, though. I personally don't use IRC much; if nobody is around to answer questions there, please send a note to debian-...@lists.debian.org Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141104204144.gb23...@squeeze.pyro.eu.org
steven wu与您共享了照片
Hi,sir thank you very much for your time attached is shure mic , yamaha speaker and crown amp, dbx speaker andsenhiser mic prices list. if you are interest, can you contact us? Steven www.newplayaudio.net <>
Re: this bug .. bugs me
Hi, Please forgive me if this is the wrong place to ask (or if I'm completely wrong here). On Wed, 2012-06-06 at 11:15 +0200, Goswin von Brederlow wrote: [...] > > Juppey. Thanks to all the workers and the NMUers that made this > possible. > > Now if wine 1.4 enters unstable we are finaly ready to kill ia32-libs > for good. > Reading this I assume ia32-libs will be removed from Debian (with which I completely agree btw), what about packages outside of Debian that currently depend upon ia32-libs? To name a certain package: skype. Its AMD64 package from the official website depends on it. Can we work around this somehow? I'm in no way affiliated with upstream here, but looking at their particular history I don't expect any update soon with a proper solution. Regards, Steven signature.asc Description: This is a digitally signed message part
Re: Possible release note for systems running PHP through CGI.
On 20/08/12 08:02, Wouter Verhelst wrote: > On Sun, Aug 19, 2012 at 11:17:26AM +0900, Charles Plessy wrote: >> - In Squeeze, using default configurations, files with ".php" in their name >>such as "foo.php.jpeg" are executed as PHP scripts by the Apache web >> servers >>runing PHP scripts through php5-cgi. > > Maybe that's because it's expected they would be PHP scripts emitting > JPEG files, not plain JPEG files? This seems like a feature to me, not a > bug. Why was support for that removed? Yes it's possible some people rely on that behaviour, e.g. serving JPEG data from PHP scripts named like foo.php.jpeg. But some sites accept file uploads with arbitrary names, perhaps expected to be a JPEG image, but actually named bar.php.jpeg and containing malicious server-side PHP which they could execute from the browser. If that behaviour is changed, then where the PHP preprocessor was previously invoked because of the detected MIME type, it would now serve up the source code instead (leading to information disclosure). I imagine the 'safest' way to handle this is to preserve the original behaviour, still recognising *.php* as PHP scripts, but deny access to (through ACLs or a dummy handler) files containing ".php." in their name, unless the filename actually ends in ".php" /If/ that could work, it would limit any disruption to the two cases where it might be a security issue. Regards, -- Steven Chamberlain ste...@pyro.eu.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/50322951.30...@pyro.eu.org
Re: Possible release note for systems running PHP through CGI.
On 20/08/12 14:35, Wouter Verhelst wrote: > On Mon, Aug 20, 2012 at 01:10:57PM +0100, Steven Chamberlain wrote: >> Yes it's possible some people rely on that behaviour, e.g. serving JPEG >> data from PHP scripts named like foo.php.jpeg. Sorry, I was wrong. For extensions like .jpeg with a known MIME type it does not work. So, people are unlikely to be relying on this effect. http://lists.debian.org/caljhhg8dd+nv2uvgjbvrtubdna3m+o1afo0bqylyfpqkhuj...@mail.gmail.com >> But some sites accept file uploads with arbitrary names, [...] > > Don't Do That Then(TM). Yes I very much agree... > [...] write your upload scripts so that they > - Store uploads in a directory which is served by the webserver, but > without allowing any kind of script execution (i.e., "Options > -ExecCGI" and similar things for other scripting environments and/or > webservers) I believe -ExecCGI would work for php5-cgi but not for libapache2-mod-php5 (whose handler relies on MIME types). To protect against that, I notice our drupal6 packages create an .htaccess file in the file uploads directory, with: > SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006 (Advisory is at https://drupal.org/files/sa-2006-006/advisory.txt ) That also shows what a persistent problem this has been in the LAMP webserver stack for many years. I really hope FastCGI/FPM is an opportunity to put this right, among other things. Regards, -- Steven Chamberlain ste...@pyro.eu.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/503245be.8040...@pyro.eu.org
Re: Current and upcoming toolchain changes for jessie
Hi, On 13/06/13 13:51, Matthias Klose wrote: > GCC 4.8 is now the default on all x86 architectures, and on all ARM > architectures (the latter confirmed by the Debian ARM porters). I did not get > any feedback from other port maintainers, so unless this does change and port > maintainers get involved with toolchain maintenance, the architectures staying > at 4.6 or 4.7 shouldn't be considered for a successful release > (re-)qualification. I trust these are the architectures that are okay so far: | gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64 kfreebsd-i386 hurd-i386 So the following would be the architectures for which some response is requested urgently from port maintainers, to confirm they are ready for GCC 4.8 as default: Release arches: ia64 mips mipsel powerpc s390 s390x sparc All the above have built gcc-4.8.1-2 or higher. Other ports: alpha hppa* m68k powerpcspe ppc64 sh4* sparc64* * these ports don't appear to have successfully built GCC 4.8 yet. Regards, -- Steven Chamberlain ste...@pyro.eu.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/51b9db2c.2060...@pyro.eu.org
Re: Current and upcoming toolchain changes for jessie
Hi, On 13/06/13 20:47, Thorsten Glaser wrote: > From me nothing against switching C/C++ to 4.8 for m68k at > this point, but I’d like to hear at least Wouter’s opinion > on that, and possibly Mikael [...] Before that can be changed, I think the gcc-defaults package expects package version (>= 4.8.1-2) whereas m68k still has only the 4.8.0-7 you uploaded. You will also first need newer binutils (>= 2.23.52) which is still in the build queue. (This applies to ppc64 as well). Regards, -- Steven Chamberlain ste...@pyro.eu.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/51ba2417.9070...@pyro.eu.org
Re: how can we help DSA save money (was: bits from the DPL - June 2013)
Hello, On 09/07/13 10:40, Lucas Nussbaum wrote: > I approve the purchase of additional storage for backups (~2300 EUR) and > for our new hosting location at Bytemark, where snapshot.d.o will be moved > soon (~£7000). May I ask some more details about this please; what kind/amount of storage can DSA get for this, and are these costs for the hardware and warranty, or does it also include costs of setup, hosting, power or other ancillary bits? The reason I ask, is that a feature of Debian software and development work, is being able to derive more benefit from lower-cost, general-purpose hardware. (And also because this stood out as being quite a big purchase if it is just storage). This is somewhere that contributors could help instead of financially, but by designing, developing, or simply documenting solutions that would fulfill DSA needs. I know this happens a bit already, DSA heavily makes use of Debian software and there is even a list of relevant usertagged bugs[0]. But what things are we not using Debian for yet, and where could we save DSA some money? [0]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-ad...@lists.debian.org Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.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/51eae099.5040...@pyro.eu.org
Re: how can we help DSA save money
Hi! On 2013-07-21 08:09, Tollef Fog Heen wrote: > Backups is 8 x 4T Seagate Constellation drives. Bytemark is 24 x 4T > Seagate Constellation drives. We get setup, hosting, power, etc > donated, so that is not part of the cost there. Thanks; was this just a purchase of drives, or also a new storage appliance / enclosure for them? Having these numbers allows for some very rough estimates of cost saving from different ideas. > It's not really possible to code ourselves out of this one. It's a challenge of course. I think these are fun and educational; I like to keep things like this in mind over a period of months, while working on unrelated projects. This problem is unlimited in scope, and the benefit of any change could possibly extend beyond snapshot.d.o, e.g. to mirrors or end-users. * if maintainers knew the true cost of snapshot.d.o it may affect their upload habits * we can measure impact of xz and other compression of .debs * dedup.d.n seems it could help reduce unnecessary growth of the archive in future * de-duplicating between *versions* of a package is another area of interest; just one method of that is:- On 2013-07-22 09:31, Philipp Kern wrote: > Well, we could make snapshot store binary deltas. > [...] Just sayin', not suggesting that we should do that. Exactly, and with some numbers and costs we can evaluate if it's worthwhile or practical. That may change over time depending on compute/storage cost tradeoff or through different techniques. At a lower level we can consider the capabilities of the storage system, which is really software. Depending on that, it may have been practical to manage with just 6 disks initially and add more later (when they may be half the price or less). OTOH its performance may then be insufficient, but then it could be potentially fixed in software of the application. So yes, I think this certainly could be seen as a software challenge. Thanks again for all the details and your thoughts. Regards, -- Steven Chamberlain ste...@pyro.eu.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/51ed18a0.9090...@pyro.eu.org
Re: how can we help DSA save money
On 2013-07-22 14:50, Tollef Fog Heen wrote: > There are practical problems with your suggestions, such as resizing the > RAID taking a very long time when we add a new disk (you're looking at > weeks of seriously reduced performance). That seems like a limitation of software, at one of the lower layers. I did not mention ZFS until now, because I didn't want limit anyone's thinking to filesystems. But I did have it in mind all along. ZFS allows adding drives to an existing pool to increase its capacity when needed. That does not require a scrub/resync. They could be added as mirrored pairs somewhat like being able to extend a RAID10. Or you could add groups of disks at a time, each configured like RAID6. And ZFS can also take file-level snapshots, which would possibly allow for a simpler implementation of snapshot.d.o to be based on it... Regards, -- Steven Chamberlain ste...@pyro.eu.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/51ed325d.7060...@pyro.eu.org
Re: how can we help DSA save money
On 2013-07-22 15:49, Tollef Fog Heen wrote: > It's not, it's a limitation of resizing a raid and that requiring about > a billion seeks across the disk surface. I didn't realise it was hardware RAID. If for example it is possible to create multiple, smaller hardware RAIDs over time, then maybe all that is needed is a small code change to snapshot.d.o to spread files across multiple mountpoints, which would surely be worth it. But it seems to me that software RAID, probably running free Debian software, can someday reduce need of some hardware, if it were reliable, performed well and could be managed easily. (It seems DSA are now doing this for compute resources, through OpenStack and ganeti). I just like the idea that Debian can strive to develop such things for its own infrastructure needs. I think storage makes for a good long-term project, but there may be others that could yield higher savings. Regards, -- Steven Chamberlain ste...@pyro.eu.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/51ed43e4.9050...@pyro.eu.org
Re: How git performs when you throw all of Debian at it
Hi, > [...] using git instead of the file system for storing the contents > of Debian Code Search. The hope was that it would lead to fewer disk > seeks and less data due to gits delta-encoding Wouldn't ZFS be a more natural way to do something like this? A choice of gzip, lzjb and more recently lz4 compression; snapshots and/or deduplication both reduce the amount of disk blocks and cache memory needed. I've pondered before at this overlap in functionality between packing by Git, and those features of the ZFS filesystem. They are doing much the same thing but with different granularity. It would be neat if they could work together better. Regards, -- Steven Chamberlain ste...@pyro.eu.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/5220f898.6000...@pyro.eu.org
Re: How git performs when you throw all of Debian at it
On 30/08/13 21:49, Michael Stapelberg wrote: > Steven Chamberlain writes: >> Wouldn't ZFS be a more natural way to do something like this? > Possibly, but I have zero hopes of getting it set up and supported by > DSA, so we can’t use it for this service. Oh I see. That's fair enough, but there is some hope that could change someday: ZFS-on-Linux is making good progress recently, and we (GNU/kFreeBSD team and upstream developers of ZFS) can try to better educate folks on ZFS generally. Regards, -- Steven Chamberlain ste...@pyro.eu.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/52211337.7050...@pyro.eu.org
Re: DSA, kFreeBSD, and the Singularity (was: How git performs when you throw all of Debian at it)
Hi Luca! On Sat, 31 Aug 2013 16:12:11 +, Luca Filipozzi wrote: > We also run kfreebsd, with some challenge, but we have it. How can we help with that? e.g. Do you need it to better suit running as a virtualised guest, on KVM or Xen for example? virtio drivers should be forthcoming for jessie and a XENHVM flavour is possible if it seems worth it. I can only recall one wishlist bug from DSA at the moment which is #711247 requesting pflogd. I'd love to hear more wishlist kfreebsd ideas from DSA. I'd like it to be readily available whenever it might be a good fit for some internal project. Having as much Debian software as possible feeding back into Debian development systems, makes the project seem something of an unstoppable machine approaching the Singularity... Regards, -- Steven Chamberlain ste...@pyro.eu.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/5223a85...@pyro.eu.org
Re: DSA, kFreeBSD, and the Singularity
On 02/09/13 13:16, Peter Palfrader wrote: > syslog-ng on kfreebsd doesn't properly reconnect to logservers after > they went a way for a while or the network dropped. Was that on squeeze or wheezy? The versions of syslog-ng are quite different I think. Regards, -- Steven Chamberlain ste...@pyro.eu.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/52248217.1000...@pyro.eu.org
Re: Roll call for porters of architectures in sid and testing (Status update)
Hi, Nothing motivates like a deadline... I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For kfreebsd-amd64 and kfreebsd-i386, I - test many packages on this architecture - triage arch-specific bugs - fix arch-related bugs - keep an eye on buildds - stay current with debian-bsd@lists.d.o - help with wheezy security support for arch-specific packages Furthermore I run kfreebsd-amd64 on a development machine, and on a number of production servers. I use kfreebsd-i386 on some embedded systems in a production environment. I am not a DD/DM, but maybe someday... Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: ports and multiarch
Hi. On 02/10/13 12:56, Jonathan Dowland wrote: > Actually I wonder how many 32 bit powerpc > users there are compared to 64 bit. IN the mac world, I'd wager > more G4s than G5s (the mac pro or xserves), not sure about other > powerpc worlds. Maybe these figures from popcon are indicative; it seems to agree with what you said, only about a quarter of total powerpc systems seem to have a 64-bit kernel installed: wheezy kernels: http://qa.debian.org/popcon-graph.php?packages=linux-image-3.2.0-4-powerpc+linux-image-3.2.0-4-powerpc-smp+linux-image-3.2.0-4-powerpc64&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 squeeze kernels: http://qa.debian.org/popcon-graph.php?packages=linux-image-2.6.32-5-powerpc+linux-image-2.6.32-5-powerpc-smp+linux-image-2.6.32-5-powerpc64&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 Regards, -- Steven Chamberlain ste...@pyro.eu.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/524c7081.6010...@pyro.eu.org
Security process vs. pu (Re: Bug#723641: pu: package xen/4.1.4-5)
Hi Bastian, Would you say that for publicly disclosed issues, the 'open' approach of pu works better? Meaning: 1. debdiff gets reviewed on a public list, others have an opportunity to help review and point out a mistake, and the discussion is archived 2. the proposed updates queue has a public page[2] 3. buildd status and logs are public[3] 4. dak emails the maintainer and updates the PTS 5. the changelog can be found on packages.d.o [2]: http://release.debian.org/proposed-updates/stable.html [3]: https://buildd.debian.org/status/architecture.php?a=amd64&suite=wheezy Whereas the above is generally not true of the Security Team's process, which seems designed to be able to handle embargoed issues? Regards, -- Steven Chamberlain ste...@pyro.eu.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/524e0094.3060...@pyro.eu.org
Re: openpty under kFreeBSD
Hi Daniel, On 03/10/13 14:00, Daniel Lintott wrote: > I am currently in the process of packaging a piece of software over on > Mentors, but have run into a bug affecting only kFreeBSD. Thanks for your interest in making it work! > The software calls openpty, but this fails with the error > > No child processes I'd be interested to see output of running it under `ktrace -di -- ...` then `kdump -f ktrace.out`. In order to see if some system call fails prior to that, and where exactly that message is printed from. > The code in question can be found here [1] and the RFS bug report can > be found here [2] I found vpcs 0.4b2-1 on mentors, but it does not contain a source file called hv.c? Do I have the wrong version? Regards, -- Steven Chamberlain ste...@pyro.eu.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/524e0223.4080...@pyro.eu.org
Re: First autoremovals happen in about 8 days
Hi, On 06/10/13 08:52, Niels Thykier wrote: >kfreebsd-8: bugs 720470,717959,720476, flagged for removal in 14.7 days Not sure why that's appearing in this list because: 1. the package was removed from testing over a month ago at the request of the maintainer, and 2. when that happened the bugs listed were closed? Perhaps this is because the script does not notice 1. and therefore despite 2. it still thinks affected versions are in testing? Regards, -- Steven Chamberlain ste...@pyro.eu.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/525144dc.6090...@pyro.eu.org
Re: First autoremovals happen in about 8 days
On 06/10/13 08:52, Niels Thykier wrote: > Laszlo Boszormenyi (GCS) >vice: bugs 693641, flagged for removal in 8.3 days Bug #693641 is another interesting edge case: Found in version vice/2.3.dfsg-4 (testing, unstable, stable) Fixed in version vice/2.4.dfsg-1 (unstable) Marked as done But it didn't quite build everywhere - kfreebsd-amd64 and s390 still have out-of-date 2.3.dfsg-4 binaries in sid. I'm not sure if this logic was intended, but it actually makes sense: the fixed version cannot migrate to testing and replace the buggy one. Regards, -- Steven Chamberlain ste...@pyro.eu.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/5251bd46.8070...@pyro.eu.org
Re: First autoremovals happen in about 8 days
On 07/10/13 23:04, Bill Allombert wrote: > I am concerned that in the event a package is removed from testing, > the people most interested with restoring the package will miss the > removal, since the package will stay installed on their systems. > This, then, cause stable releases to be missing packages that users > are depending on, which reduce the value of the distribution. `aptitude search '?obsolete'` is useful after upgrading a system to a new stable release, a trick I learned from: http://raphaelhertzog.com/2011/02/07/debian-cleanup-tip-2-get-rid-of-obsolete-packages/ Not directly related to this: a side effect of running debsecan is that if I see security issues accumulating for some package, I would likely check the PTS to see why it remains unfixed, or decide to remove or replace the package with something else that's still maintained. So if `aptitude search '?obsolete'` was run periodically, like debsecan, it could email the system admin when new items appear on the obsoletes list. I imagine that'd be a good way to notify of the situation being described here? Regards, -- Steven Chamberlain ste...@pyro.eu.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/52549549.1050...@pyro.eu.org
Re: Bits from the Release Team (Jessie freeze info)
Hi Niels, This was quite interesting as it seems to tie in with some other projects that are already being pursued... On 21/10/13 16:42, Niels Thykier wrote: > I would love for us to have an automated system to give us a > "weather-report" on the toolchain for each architecture. It would be > nice both for us to see how ports are doing and for porters to spot and > fix problems early. That sounds a lot like the purpose of Jenkins[0], but I'm not sure if it's exactly suitable. It seems a little heavy, that someone could more easily be able to script some cron jobs for a task than learn how to use it. And Jenkins isn't available yet on all arches; some ports may not have hardware powerful enough to run it. Maybe that doesn't matter - a single Jenkins instance might be able to launch jobs via remote shells to other boxes, running the actual test suite there, or maybe just to fetch, analyse and report on the resulting log files. Ideally I'd like to see a set of command-line scripts runnable either from cron, or maybe someday by Jenkins jobs if someone wants to set that up. And packaged up for people to use at home! [0]: http://jenkins.debian.net/ > Which implies "a set of packages" being "the current version of the > overwhelming part of the archive" plus all of d-i. However, that is not > something you "just build", so having a smaller set as a basic test > would probably be way more useful. I am not aware of such a "basic test > set", so feel free to propose one. Some people have been trying to identify small sets of essential packages already, in the context of bootstrapping an architecture[1]. I wonder if that's likely to overlap with this? It encompasses toolchain and essential arch-specific packages. I imagine a healthy port should be able to bootstrap itself with only current package versions. If this was being tested regularly it could let porters know if circular dependencies are introduced, for example. [1]: https://wiki.debian.org/DebianBootstrap#Toolchain I would maybe take that a little further and say that a system is only stable if it can bootstrap itself, install and boot into the resulting system, and repeat the whole process again... > I like the "toolchain nightly" thing as well. I don't think it is > "required", but it sounds like the kind of thing that would help people > spot issues sooner rather than later! And this also ties in with the reproducible-builds project[2] (not sure if you were hinting at that before). The 'toolchain' is of particular concern because the security of the whole system depends on it. Differences in the output of builds needs to be avoided, or otherwise explained. It would help greatly if there were frequent builds happening so we could see unexpected changes occurring. [2]: https://wiki.debian.org/ReproducibleBuilds So if something can make something that fulfills all the above goals it would certainly be beneficial :) Regards, -- Steven Chamberlain ste...@pyro.eu.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/5266df9d.9040...@pyro.eu.org
Re: Bits from the Release Team (Jessie freeze info)
On 22/10/13 23:36, Stewart Smith wrote: > Jenkins can have slaves on remote hosts, via SSH. It runs a small java > app there, so as long as the arch has a JVM then you're pretty right. That may be useful to set up on some arches, for things where Jenkins needs direct control over CPU-intensive tasks. Building and testing d-i, for example. But for this, I would imagine only the test suite needs to run over SSH, and the master Jenkins instance just has to process the output? For the proposed test suite to be as accessible as possible to a new/upcoming port, the barrier to using it ought to be very low. A working JVM is quite a lot to ask, the current openjdk-7 is not even built for mipsel in more. mipsel buildds and porterboxes had only 1GB RAM maximum until now, and that is heavily used already for their current tasks. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Bits from the Release Team (Jessie freeze info)
On 23/10/13 12:55, Stewart Smith wrote: > Geert Uytterhoeven writes: >> On Wed, Oct 23, 2013 at 12:36 AM, Stewart Smith >> wrote: >>> Jenkins can have slaves on remote hosts, via SSH. It runs a small java >>> app there, so as long as the arch has a JVM then you're pretty right. >> >> For whatever definition of small. I've seen it consuming 1 GiB of >> memory... > > with 'm68k' in your email address your definition of small is likely > much different than my "many years in large scale databases" small :) Come to think of it, it must take a day or more for m68k to rebuild eglibc. This is a more serious problem than resources needed by Jenkins. We can't ask them to rebuild their entire toolchain each night! For the goal of software freedom, it shouldn't be too difficult for anyone to do that, though. We should be trying to make it easier. Maybe it would be permissible for the toolchain test suite to run on a faster platform, and cross-compile, or use any sort of emulation available in Debian free packages. If it were technically feasible for each Debian port to rebuild its toolchain and some essential packages, at least once per week, I think that would be an accomplishment. And the smaller the initial set of packages required to boostrap the process, the better. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Bits from the Release Team (Jessie freeze info)
On 22/10/13 21:27, Steven Chamberlain wrote: > Some people have been trying to identify small sets of essential > packages already, in the context of bootstrapping an architecture[1]. I > wonder if that's likely to overlap with this? It encompasses toolchain > and essential arch-specific packages. I had a play with the 'botch' tool (see description[1]) for determining build order when bootstrapping an architecture. To start off with it determines a minimum required set of packages - you'd normally cross-compile those from another system. This set (see attached example list for kfreebsd-amd64 wheezy) looks to me like what constitutes the 'toolchain'. The list will be different for each port, and change over time. This example included freebsd-libs, freebsd-utils and kfreebsd-kernel-headers but of course others won't. AIUI those packages should be able to rebuild each of themselves without any other dependencies. I think doing that regularly would be a good health check for a port's toolchain. Probably these packages would be the focus of the reproducible-builds project, at least from a security point-of-view. Any differences in output of subsequent builds are of interest, and would potentially reveal when significant changes or bugs were introduced too. [0]: https://gitorious.org/debian-bootstrap/botch [1]: http://blog.mister-muffin.de/2013/01/25/bootstrappable-debian---new-milestone/ Regards, -- Steven Chamberlain ste...@pyro.eu.org apt base-files base-passwd bash binutils bsdmainutils build-essential bzip2 coreutils dash db debianutils diffutils dpkg e2fsprogs eglibc expat file findutils freebsd-libs freebsd-utils gawk gcc-4.7 gcc-defaults gdbm gettext glib2.0 gmp gnupg grep groff gzip hostname html2text insserv kfreebsd-kernel-headers libbsd libcroco libffi libgssglue libpipeline libsigsegv libtirpc libunistring libusb libxml2 make-dfsg man-db mpclib mpfr4 ncurses pam patch pcre3 perl readline6 sed shadow slang2 sysvinit tar util-linux xz-utils zlib
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, 28 Oct 2013 16:40:09 -0400 Paul Tagliamonte wrote: >> Change your tone. Then please, try to show a better example of how that is done, instead of this: On Mon, 28 Oct 2013 17:07:59 -0400, Paul Tagliamonte wrote: > I mean, no offense, but I've never seen you involved in Debian before > [...] > I try to call everyone (regardless of membership) on their > s*** tone on MLs. I think I'd rarely call anyone on anything, but none of Kevin's comments sounded nearly as rude to me as that. Regards, -- Steven Chamberlain ste...@pyro.eu.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/526ede7a.6030...@pyro.eu.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi,
On Sun, 27 Oct 2013 02:47:56 +0800 Thomas Goirand wrote:
> Note that OpenRC already works on some (non-Debian) BSD platforms, and
> that it should be trivial to have it to build on kFreeBSD and Hurd,
And so I came up with the attached patch which gets it building on
GNU/kFreeBSD, and it passed whatever tests are run during build. I
actually chose Linux implementations for most things, which are really
provided by GNU libc or /proc.
Actually quite amazing how painless that was, though I most certainly
don't expect it to be functional yet. (For example, I expect it still
needs to know about linprocfs, linsysfs, tmpfs and maybe devfs).
I look forward to seeing OpenRC in the Debian archive. Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/etc/rc.conf.GNU-kFreeBSD b/etc/rc.conf.GNU-kFreeBSD
new file mode 100644
index 000..e138e3a
--- /dev/null
+++ b/etc/rc.conf.GNU-kFreeBSD
@@ -0,0 +1,12 @@
+##
+# GNU/kFreeBSD SPECIFIC OPTIONS
+
+# This is the subsystem type. Valid options on GNU/kFreeBSD:
+# ""- nothing special
+# "jail"- FreeBSD jails (not yet implemented)
+# If this is commented out, automatic detection will be used.
+#
+# This should be set to the value representing the environment this file is
+# PRESENTLY in, not the virtualization the environment is capable of.
+#rc_sys=""
+
diff --git a/mk/os-GNU-kFreeBSD.mk b/mk/os-GNU-kFreeBSD.mk
new file mode 100644
index 000..9fc9313
--- /dev/null
+++ b/mk/os-GNU-kFreeBSD.mk
@@ -0,0 +1,10 @@
+# Copyright (c) 2008 Roy Marples
+# Released under the 2-clause BSD license.
+
+# Generic definitions
+
+PKG_PREFIX?= /usr/local
+SFX= .BSD.in
+
+CPPFLAGS+= -D_BSD_SOURCE -D_XOPEN_SOURCE=700
+LIBDL= -Wl,-Bdynamic -ldl
diff --git a/mk/os.mk b/mk/os.mk
index 3e18962..6b2d428 100644
--- a/mk/os.mk
+++ b/mk/os.mk
@@ -3,7 +3,7 @@
# Generic definitions
-_OS_SH= uname -s
+_OS_SH= uname -s | tr '/' '-'
_OS:= $(shell ${_OS_SH})
OS?= ${_OS}
include ${MK}/os-${OS}.mk
diff --git a/src/librc/librc-daemon.c b/src/librc/librc-daemon.c
index 982da35..7a860c6 100644
--- a/src/librc/librc-daemon.c
+++ b/src/librc/librc-daemon.c
@@ -30,7 +30,7 @@
#include "librc.h"
-#if defined(__linux__)
+#if defined(__linux__) || defined (__GLIBC__)
static bool
pid_is_exec(pid_t pid, const char *exec)
{
diff --git a/src/rc/mountinfo.c b/src/rc/mountinfo.c
index eaace13..1006a0c 100644
--- a/src/rc/mountinfo.c
+++ b/src/rc/mountinfo.c
@@ -39,7 +39,7 @@
# include
# define statfs statvfs
# define F_FLAGS f_flag
-#elif defined (__linux__)
+#elif defined (__linux__) || defined (__GLIBC__)
# include
#endif
@@ -265,7 +265,7 @@ find_mounts(struct args *args)
return list;
}
-#elif defined (__linux__)
+#elif defined (__linux__) || defined (__GLIBC__)
static struct mntent *
getmntfile(const char *file)
{
diff --git a/src/rc/rc-logger.c b/src/rc/rc-logger.c
index 468225f..e8fb0ff 100644
--- a/src/rc/rc-logger.c
+++ b/src/rc/rc-logger.c
@@ -44,7 +44,7 @@
#include
#include
-#ifdef __linux__
+#if defined(__linux__) || defined(__GLIBC__)
# include
#elif defined(__NetBSD__) || defined(__OpenBSD__)
# include
diff --git a/src/rc/runscript.c b/src/rc/runscript.c
index e504e4a..f14db11 100644
--- a/src/rc/runscript.c
+++ b/src/rc/runscript.c
@@ -52,7 +52,7 @@
#include
#include
-#ifdef __linux__
+#if defined(__linux__) || defined(__GLIBC__)
# include
#elif defined(__NetBSD__) || defined(__OpenBSD__)
# include
Re: Re: Proposal: let’s have a GR about the init system
Hi Svante, On Tue, 29 Oct 2013 08:57:13 +0100 Svante Signell wrote: > Triggered by the good news about OpenRC for GNU/kFreeBSD > http://lists.debian.org/debian-devel/2013/10/msg00991.html I wouldn't get too excited just yet; with more work we might get OpenRC working on our ports, but some still insist on there being *only* systemd (and no ports). *sigh* I'm so glad for the existence of the ports right now. Or Debian might already have made this jump with eyes closed, into some vendor lock-in type of situation. > I would like to try to build it also for GNU/Hurd, save the PATH_MAX > stuff. Where is it? It is not in http://ftp-master.debian.org/new.html Packages in the NEW queue are not available to download from anywhere AFAIK. But you can clone the packaging repo from: http://anonscm.debian.org/git/git/collab-maint/openrc.git Regards, -- Steven Chamberlain ste...@pyro.eu.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/526f9392.1010...@pyro.eu.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, 28 Oct 2013 19:38:09 -0700, Russ Allbery wrote: > Brian May writes: >> My understanding is that init scripts will still be required for FreeBSD >> and The Hurd. > > I would not assume that. At least, I personally don't think that > switching to upstart or systemd as a default but requiring that everyone > provide both files for that system and init scripts for Hurd and kFreeBSD > to be a good outcome, since I don't think that will be something at which > Debian will be successful. But that seems like the easiest way to not break what is already working in GNU/kFreeBSD, Hurd - and on users' own Linux systems if they have non-Debian software using SysV init scripts. Do systemd/Upstart intend to rewrite inits cripts for all of the estimated up to 1200 packages that provide them currently? Or could they just as easily keep using some of those SysV scripts and keep them around? Dismissing the ports as toy projects is not a compelling argument to me. Not least because I think of a toy as something fun, educational and certainly not without any meaning; I wouldn't want commercial desires to get too much in the way of that. I could equally dismiss the plans for GNOME+systemd+Linux integration as hype/fantasy. But actually, I welcome people to try it and show us what it can do, as long as they do so without harming the rest of us. Having some fallback is beneficial not only to the ports but to Linux users who may not want, or are unable to use, the new init system. Just wondering, if systemd upstream cares only for Linux and that's considered okay, might they also start dropping support for architectures they stop caring about (or for commercial reasons)? Say MIPS, s390, SPARC. In that case, permanently ditching SysV init could put even some Linux ports in jeopardy. Perhaps Upstart carries the same risk if Ubuntu releases only for i386/amd64/arm. Regards, -- Steven Chamberlain ste...@pyro.eu.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/52702ed2.5060...@pyro.eu.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 29/10/13 01:34, Steven Chamberlain wrote: > Actually quite amazing how painless that was, though I most certainly > don't expect it to be functional yet. I have tested it now. It's actually running and doing 'something'! And it is colourful. I'm testing it inside of a BSD jail currently. This is a remarkably easy environment for debugging. I can alternatively enter a fully working bash shall or prod in the jail's chroot directly. > # jail -J /var/run/jail/$JID.jid -c jid=$JID name=jail$JID > path=/srv/jail/$JID host.hostname=$HOSTNAME ip4.addr=$IP > command=/sbin/rc sysinit > >OpenRC 0.10.9429351 is starting up GNU/kFreeBSD 9.0-2-amd64-xenhvm (x86_64) > > mdconfig: ioctl(/dev/mdctl): Device or resource busy > /libexec/rc/sh/init.sh: 18: /libexec/rc/sh/init-common-post.sh: newfs: not > found > mount: /dev/md0 : Operation not permitted I think it was trying to create a FreeBSD-style ramdisk, which is probably not possible inside a jail. May need to skip whatever it is trying to do there, or pre-create a tmpfs inside the jail before I try to boot it. # jail -J /var/run/jail/$JID.jid -c jid=$JID name=jail$JID path=/srv/jail/$JID host.hostname=$HOSTNAME ip4.addr=$IP command=/sbin/rc boot > * Checking local filesystems ... > /libexec/rc/sh/runscript.sh: 90: /libexec/rc/sh/runscript.sh: fsck: not found > * Filesystems couldn't be fixed > >[ !! ] > * rc: Aborting! > * fsck: caught SIGTERM, aborting Indeed I do not have an fsck, since util-linux depends on initscripts depends on sysv-rc so it disappeared. This is unnecessary inside a jail anyway. That's as far as I got with this tonight, but just to let you know that OpenRC is somewhat alive on GNU/kFreeBSD. Regards, -- Steven Chamberlain ste...@pyro.eu.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/527055be.6090...@pyro.eu.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
on Tue, 29 Oct 2013 15:08:01 -0700 Russ Allbery wrote: > However, I, as a packager, want to stop writing and maintaining SysV init > scripts because they're awful. I didn't really expect this. I'd assumed until now that most maintainers would be concerned that existing init scripts don't work properly on the new system, and having to fix them. But you actually want to do that, and get rid of SysV init scripts too. We now have at least one new option available to the ports which is OpenRC[0]. If for example it was supported alongside systemd (or substitute Upstart here if you prefer), each package's maintainer could: * keep their SysV init scripts and let both init systems use them * write a new systemd unit but keeping the init scripts for OpenRC * write a new OpenRC configuration (I don't even know what that looks like yet), keeping the SysV init scripts for systemd * write a new systemd unit and an OpenRC configuration, can then drop the SysV init scripts * write a new systemd unit and specifically depend on systemd, perhaps leaving the package unavailable to ports But I don't suggest this is only for the benefit of ports. Even Linux users have spoken concerns about systemd specifically. If it were introduced, I'd like to have a lightweight and less controversial alternative, and it's really convenient if it is portable. [0]: https://lists.debian.org/5270b735.8010...@debian.org Regards, -- Steven Chamberlain ste...@pyro.eu.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/5270fce2.3030...@pyro.eu.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 15:10:16 +0100 Helmut Grohne wrote: > Furthering this thought leads to turning non-Linux ports > into derivatives as presented by others in this thread. If packages are no longer required to provide SysV init scripts, producing a non-Linux Debian derivative would at least entail bringing back SysV init scripts in those packages, or perhaps adding new OpenRC runscripts. If that were to happen though, that same work could enable the use of OpenRC as an alternative init system, even on Linux. Regards, -- Steven Chamberlain ste...@pyro.eu.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/527127dc.6020...@pyro.eu.org
Re: Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 16:05:48 +, Thorsten Glaser wrote: > * Write scripts for one system and generate the other from it > or even > * Write “Debian init declaration” and let something take care > of generating an initscript and whatever the other systems > use out of it Perhaps an existing definition like Upstart's could become that? We'd want proper documentation and some reassurance it won't change drastically. Upstream might be open to suggestions for improvement. Any thoughts? Then try to add support for it wherever it is easiest to do so, like OpenRC (seems to be rather simply designed, ought to work on all ports, and is under a free license without CLA). It just depends how much functionality Upstart has, that most packages really need, which OpenRC doesn't already have. (The GNOME logind issue would have to be handled anyway for Upstart to be considered.) Regards, -- Steven Chamberlain ste...@pyro.eu.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/52713661.2090...@pyro.eu.org
Re: Re: Proposal: switch default desktop to xfce
Hi, On Fri, 25 Oct 2013 13:31:23 +0100 Steve McIntyre wrote: > We've had this discussion multiple times over the years. I've been > told multiple times that we still have a non-negligible set of users > owning/running hardware that can't do DVDs. I'm not 100% convinced > myself of how large or critical this use case is, but that's the > information I have. I still have such hardware lying around, I rarely use it, but a CD install might be the only way I could ever resurrect it for anything. During the final cdimage testing on Wheezy release day, I did test installs on a Compaq ProLiant DL360 (G1). They have a slim-line CD-ROM drive and AFAIK no way to boot from USB or the (non-free) onboard NICs. USB or network booting might fail for any number of reasons. This might be a standalone computer, not even networked to any others, and many will find it difficult setting up DHCP and a PXE server. If all options fail, one's only other option might be to install a different OS (at least, initially). A CD seems most likely to work, especially if the user doesn't know what type of optical drive they have. > We *could* just drop all the CD sets and be done > with it, just keeping the netinst CD and the DVDs. Is that what people > really want? Please consider keeping at least: * a minimal netinst CD - for those who want to download as little as possible; I have plenty of blank CDs at hand, and is permanent once written, whereas most of my USB keys are constantly in use for things or have data on that makes it awkward to reformat them as install media. The CD would also work in DVD-ROM drives, and the .iso might be useful for network booting. Perhaps it will even fit on some businesscard CD or DVDs. * a single CD containing as much as possible, perhaps XFCE - if you're limited to slow connectivity and old hardware, this may be the most compatible and 'shareable' Debian disc; it should have everything a novice user will need to get to a friendly graphical desktop, get online and be able to surf the web, after which they can install any other software on demand. However, I don't see much point any more in the sets which span multiple CDs - especially if using only CD-1 would leave out essential stuff for getting online and downloading the rest. The larger desktops environments probably have system requirements beyond the kind of hardware I've mentioned here anyway. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.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/52715d0c.4010...@pyro.eu.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 20:39:32 + Jonathan Dowland wrote: > [...] Debian without non-Linux ports prior to February > 2011, [...] That's only when a non-Linux Debian port (GNU/kFreeBSD) first became a _release architecture_; it existed as a port since May 2003. Hurd has been an official unstable port since before that I think. Debian is also upstream to more unofficial ports such as Dyson that many of us don't ever hear about. So clearly, Debian has always been a very portable OS; taking a very Linux-specific direction such as systemd would be significant. > Merely pronouncing our opinions does nothing to further the > debate. It wouldn't be much of a debate if people didn't speak their opinions. Others had already done so in the tech-ctte bug so I think he was justified in challenging this. And... if everyone was of the same opinion, there probably wouldn't have been a debate in the first place. Regards, -- Steven Chamberlain ste...@pyro.eu.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/527177cd.50...@pyro.eu.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote: > two places where to place systemd service files. One is located > below /usr/lib/systemd which is the directory where service files > provided by the package are placed, and one is /etc/systemd where > your own, custom service files are located. If you created a custom local script, just to append something to the daemon's command line, is that going to clobber the package's service file indefinitely? So if a new version or security update adds a "-s" flag telling the daemon to 'run in secure mode' your local definition might never pick that up? In this situation, I think I'd prefer to see a conffile prompt. And overriding the *entire* service file seems excessive if you wish to override just one line of the package's service file. Regards, -- Steven Chamberlain ste...@pyro.eu.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/52725f79.4020...@pyro.eu.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
> messed up custom code may end up rendering your whole system unusable
> if you are smart enough to mess up an rm command. Just have a look
> at this wonderful bug in upstart [1].
> [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
This doesn't appear to be a bug in Upstart. A service file assumed the
caller would set MOUNTPOINT=/tmp in the environment, and invoked this
(inline) shell script:
> cd "${MOUNTPOINT}"
> find . -depth -xdev $TEXPR $EXCEPT ! -type d -delete
I assume you could launch bad code from systemd just as easily.
(Actually, if you can't, that's probably a limitation).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.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/52726368.5060...@pyro.eu.org
Re: Bug#727708: init system question before the technical committee
On 31/10/13 15:01, Ian Jackson wrote: > This seems to have come along very well in the past few days. Yes. Things are very heated, but a lot of things have been researched and documented along the way. I've been learning a lot about init systems I wasn't familiar with and some differences in opinion (maintainers vs. administrators vs. casual users) I never even imagined. During the course of this even my own preferences have changed several times. > We now have five camps with pages with substantial content: This does not translate neatly into five possible courses of action though. Opting for 'multiple' init systems would still leave various combinations to decide upon. There is uncertainty about ideas brought up for future work that may not exist yet, such as a 'neutral meta-language definition' or perhaps extending an init system with features or syntax from another. > Perhaps it would be good if the camp leader(s) for each camp would > reply with a summary of: I could use help with the sysvinit page. I was hoping someone might step up as camp leader for it, someone who is fully behind it. All I've done is mention points raised in debian-devel and elsewhere. Regards, -- Steven Chamberlain ste...@pyro.eu.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/52727a3b.6090...@pyro.eu.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 03/11/13 10:54, Niels Thykier wrote: > Come to think of it; maybe we should have a BTS page for each of the > ports (e.g. a pseudo package in the BTS). We've had this on kfreebsd, due it to having been a release goal: http://udd.debian.org/bugs.cgi?release=jessie_or_sid&merged=ign&fnewerval=7&kfreebsd=1&sortby=severity&sorto=desc&cseverity=1&ctags=1 It uses usertags, but someone has to set those. Porters usually set them on bugs they file; but quite often "FTBFS on kfreebsd" bugs are filed without being tagged or Cc'd to our list, so someone has to periodically look for and tag things. Regards, -- Steven Chamberlain ste...@pyro.eu.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/527665af.2040...@pyro.eu.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Hi, On 05/11/13 18:50, Don Armstrong wrote: > On Tue, 05 Nov 2013, Don Armstrong wrote: >> This sounds like a case where we should turn these usertags into fully >> fledged tags. [Or alternatively, they should just be made usertags under >> the debian-po...@lists.debian.org user or similar.] Either of those sounds good. Fully-fledged tags would be the easiest for most reporters to remember to use, but I wonder if this pollutes the tag namespace. > [Or multiple pseudopackages.] > > Something like i386.ports.debian.org or similar would work, with each > current port getting a pseudopackage, and the maintainer of the > pseudopackage being the ports list. Would that be only for generic issues with a port, not specific to a package? I doubt this would be used much. These bugs might typically be reassigned to kernel packages or eglibc anyway. Regards, -- Steven Chamberlain ste...@pyro.eu.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/527949c5.8040...@pyro.eu.org
Bug#698013: ITP: ITP:rasterbator-ng -- Create rasterized versions of images
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: ITP:rasterbator-ng Version: 0.1 Upstream Author: [Tobias Jakobs http://code.google.com/p/rasterbator-ng/] License: [GPL] Description: [Create rasterized versions of images] -- 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/1358022101.24582.0.ca...@twoface.mooncitylabs.org
Re: Candidates for removal from testing (2013-01-24)
Hi there, On Thu, 24 Jan 2013 15:47:08 +0100 (CET) ni...@thykier.net (Niels Thykier) wrote: > # #696816 > remove jenkins/1.447.2+dfsg-2 Just for the information of anybody reading this thread, I have just submitted a fix for this bug. It was a trivial backport; the bug was already fixed in upstream git (and in experimental). Thanks, Steven. signature.asc Description: PGP signature
Re: openjdk maintenance for wheezy and squeeze
On 18/02/13 05:14, Christoph Egger wrote: > Matthias Klose writes: >> - Afaik openjdk-7 for kfreebsd does build on kfreebsd (according to Damien) >>with the kfreebsd kernel from wheezy. So maybe some commitment could be >>found to upgrade and maintain the kernels before wheezy is released? > > [...] I guess it would be somewhat hard to get a change in for wheezy and > it *should* work once wheezy is released (I'll try that again as soon as > I can -- but then I'm somewhat bussy right now and wheezy RC bugs have > priority). I wouldn't worry about this; there's no need to rush an OpenJDK into kfreebsd for wheezy. Even if we could, consider that OpenJDK and the reverse build-deps that will get built, have had almost zero testing on this arch. So I'd actually prefer the opposite - do whatever is quickest and easiest to get the release done. Then when testing re-opens we know we can get OpenJDK built, plus lots of new packages that have been waiting on it. Regards, -- Steven Chamberlain ste...@pyro.eu.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/51220f21.7040...@pyro.eu.org
Re: openjdk maintenance for wheezy and squeeze
On 18/02/13 08:01, Sylvestre Ledru wrote: > On 18/02/2013 07:26, Andreas Kuckartz wrote: >> My view as a user: >> [...] >> Oracle has announced that no more new public updates of Java SE 6 will >> be made available after February 2013: >> http://www.oracle.com/technetwork/java/eol-135779.html > Andrew from RedHat said that OpenJDK will still be maintained after that: > http://lists.debian.org/debian-java/2013/02/msg5.html So it still has upstream (as in OpenJDK) security support. I think the original rationale behind #675495 may have been a misunderstanding, or this wasn't known at the time. > OpenJDK6 therefore should be considered obsolete when Wheezy is released. I wouldn't use the word 'obsolete' so long as there are packages that *can* use it... I'd call it 'maintenance only'. Before deciding the post-wheezy fate of openjdk-6, why not wait, and see how well things work out over the next few months. Let's see what security issues affect openjdk-6 vs. openjdk-7. Let's see how Red Hat's security maintenance for openjdk-6 compares to Oracle's own Java 7 fixes being pulled into openjdk-7 (in terms of expediency, complexity of changes, regressions). For example, if I had some public-facing Java-based service, I would rather have been running it on openjdk-6 over the past months because it had fewer security issues and perhaps no regressions caused by fixes. OTOH some packages may switch to openjdk-7 post-wheezy or ship a new upstream version that has at least been fixed to be able to use it. Regards, -- Steven Chamberlain ste...@pyro.eu.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/512219ae.7090...@pyro.eu.org
Re: [debian-mysql] Will we see MariaDB in Jessie?
On 6 May 2013 18:54, Paul Tagliamonte wrote: > Meh. +1 to kill MySQL for MariaDB. It's got a much better future. I see > it more like a libc changeover. Who cares, it's got the same interface. > We only have things to gain (better upstream, upstream commited to real > f/oss, new features, etc.) Personally I think the users should have the flexibility to choose. Having a policy on how such packages can coexist could then allow other options to also be added cleanly (MySQL Cluster, Percona, Galera etc). That's not to say the recommended one can't switch to MariaDB, if the community decides that's the way to go. -- 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/cafiqyuk4ddszbo7yewtp-r6bo0gyomidqhdgeaw7bx4__7n...@mail.gmail.com
Re: [debian-mysql] Will we see MariaDB in Jessie?
> I've done my best to package MariaDB following best practices on > Debian control files and conflict/replace rules. So I am confident to > say we actually already have a way how to get MySQL flavors to > coexist. What we seem to lack is _resources_. I guess we could package > all of Percona, Galera etc is we had 15 team members to take care of > all testing, security patching etc. > > Would you like to join? For my own part I packaged MySQL Cluster some time ago, but missed the wheezy freeze and besides no one came forward as a sponsor (I'm not a DD). It's largely based on the mysql-5.5 packaging. https://github.com/SteveAyre/mysql-cluster Now the freeze is over I'll take a look at updating it following the meeting and raise it on debian-mentors again.
Re: Current and upcoming toolchain changes for jessie
Hi, On 07/05/13 14:25, Matthias Klose wrote: > == (e)glibc 2.17 == > > We had hoped that leaving > it FTBFS in experimental for several months and gently pinging [...] That was a bit unexpected, and I haven't seen it brought up on debian-bsd@ until now. > == GCC 4.8 == > > It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to > remove 4.4, 4.6 and 4.7 from jessie. At least this part was expected. If kfreebsd (kernels) are unable to build with these, we may be able to use clang-3.2 for that. In other packages we may see some GCC 4.8 issues in kfreebsd-specific bits of code, not noticed by rebuilds on linux, but should be easy to deal with. Regards, -- Steven Chamberlain ste...@pyro.eu.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/51899a7a.2060...@pyro.eu.org
Bug#707691: ITP: mr.rescue -- Mr. Rescue is an arcade styled 2d action game centered around evacuating civilians from burning buildings. The game features fast paced fire extinguishing action and lots
Package: wnpp Severity: wishlist Owner: Steven Hamilton * Package name: mr.rescue Version : 1.01 Upstream Author : Tangram Games * URL : http://tangramgames.dk * License : Zlib, BY-NC-SA 3.0 Unported License, Custom Public Domain Programming Lang: Lua, Love2d Description : Mr. Rescue is an arcade styled 2d action game centered around evacuating civilians from burning buildings. The game features fast paced fire extinguishing action and lots of throwing people around in pseudo-randomly generated levels. -- 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/20130510100424.9598.22422.report...@square.scorch.org
Re: sysvinit: moving the contents out of the Essential: yes package?
On 27/11/13 11:49, Marko Randjelovic wrote: > Then I don't understand why on 'multiple' page they say sysvinit+openrc > is infeasible. I was referring to the sysvinit program/package, which I think is made obsolete by OpenRC; the original SysV init scripts could still be used by OpenRC. It is infeasible for Debian to choose "sysvinit and OpenRC" as required-supported init systems (such that you could install either of these and get a working system). Because in that case, a package that chooses to provide a new OpenRC-style runscript, would still be required to maintain the original SysV init script, for sysvinit users, with no particular advantage of doing so. Regards, -- Steven Chamberlain ste...@pyro.eu.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/5295f2c9@pyro.eu.org
Re: sysvinit: moving the contents out of the Essential: yes package?
On 28/11/13 10:57, Thorsten Glaser wrote: > On Wed, 27 Nov 2013, Steven Chamberlain wrote: >> I was referring to the sysvinit program/package, which I think is made >> obsolete by OpenRC; the original SysV init scripts could still be used >> by OpenRC. > > I think you’re confusing sysvinit with sysv-rc here. Yes, I meant sysv-rc there. This has been confused throughout all of the Debate pages, where "sysvinit" is used to mean "the current init system, built from src:sysvinit" and mostly referring to the sysv-rc part. So there is already confusion due to that. On the 'multiple' page I used the same term for consistency, even if not completely specific/accurate. But it is a single bullet point in the document and it is not one of the options I'm proposing anyway. Regards, -- Steven Chamberlain ste...@pyro.eu.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/529787c5.2080...@pyro.eu.org
Re: default init on non-Linux platforms
Apparently sysvinit scripts must be retained anyway for a smooth migration to jessie; also for easy backporting of jessie packages to wheezy, and maybe other reasons. Non-Linux ports are likely to use those SysV init scripts, though we might invoke them from something other than sysvinit. I know some maintainers would like SysV init scripts to disappear, but the earliest I think that can happen for existing packages would be jessie+1. In that case, we should try to plan for a similar migration from jessie to jessie+1. It's difficult to predict so far ahead, but if it will be a migration to OpenRC, maybe jessie should try to have OpenRC already in place, so that it will be able to use jessie+1's runscripts when they appear and be able to shut down cleanly when SysV init scripts are gone. (I think Thomas was describing the same situation in the context of sid) Regards, -- Steven Chamberlain ste...@pyro.eu.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/5303f898.7070...@pyro.eu.org
Hardened OpenSSL fork
Hi, A few things led me to question whether it is safe for OpenSSL to enable so many features. The heartbeat extension was not likely being used by anyone for its stated legitimate purpose. I've yet to use/need DTLS. I wondered if we could have had something along the lines of an openssl-heavy and openssl-light. But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g. It's now using native malloc/free instead of its own allocator which allowed the Heartbleed bug to happen. From doing that, Ted Unangst found the cause of the bug now known as CVE-2010-5298. And obsolete code such as for SSLv2 or portability with ancient systems is being ripped out. I wonder if this might result in an alternate SSL/TLS library we could use in Debian? The effort curiously has its own fanpage in the style of the vulnerability that triggered it: http://opensslrampage.org Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53540cf1.5000...@pyro.eu.org
Re: Hardened OpenSSL fork
I agree it's not going to be portable in the near term, though there are interesting changes being made and good code review happening. Some dubious entropy sources were (only potentially?) used with RAND_seed/add: digests: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/dsa/dsa_asn1.c.diff?r1=1.7;r2=1.8 private key: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/rsa/rsa_crpt.c.diff?r1=1.2;r2=1.3 There is even a RAND_screen function on Win32 to use a screenshot of the desktop as an entropy source. I had a flashback to the Debian bug, and how uninitialised memory was being used for that purpose. They've ripped out this whole PRNG now to use the one from their own libc: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/rand/rand_lib.c.diff?r1=1.14;r2=1.15 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/535476ac.2050...@pyro.eu.org
Re: Hardened OpenSSL fork
On 21/04/14 09:21, Kurt Roeckx wrote: > OpenBSD also replaced RC4 with ChaCha20, while Linux probably still > uses RC4. We should stop using RC4. I figured OpenSSH must be already using arc4random, and sure enough it seems to bundle an implementation of ChaCha already: http://sources.debian.net/src/openssh/1:6.6p1-3/openbsd-compat/arc4random.c?hl=192#L192 There's an strlcpy implementation there too: http://sources.debian.net/src/openssh/1:6.5p1-6/openbsd-compat/strlcpy.c?hl=33#L33 The description of OpenSSL's PRNG[0] sounds similar to what /dev/random on FreeBSD already provides with Yarrow, and the kernel has access to more potential sources of entropy than userland, including hardware entropy generators (instead of OpenSSL engines having to reimplement support for those). [0]: https://www.openssl.org/docs/crypto/rand.html > So this might be a good thing on OpenBSD, but it's not a good > thing for something that needs to be portable. I'd say the code still looks quite 'portable' in that it is ANSI C and isn't using kernel-specific features. arc4random is just a library routine from their libc and I see no reason it can't be borrowed. OTOH some OpenSSL code tries to be 'portable' - but in really bad ways - trying to implement its own snprintf, bzero, malloc/free, etc., still having workarounds for bugs in ancient/obscure compilers (Visual C++ 5.0, Cray T3E), going out of its way to support big endian x86 and x86_64 systems that don't exist... Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53555b57.9090...@pyro.eu.org
mirror.debian.net down?
Dear DSA, I'm suddenly unable to resolve records under the mirror.debian.net DNS zone. It is apparently not a zone registered in Debian LDAP, so 'seems to be DSA territory' according to http://wiki.debian.org/DebianGeoMirror I couldn't find any announcement relating to it, so wonder if it is an outage or perhaps planned closure of the service? Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53601c56.8070...@pyro.eu.org
Re: Re: Hardened OpenSSL fork
On Mon, 28 Apr 2014 16:52:10 + (UTC), daThorsten Glaser wrote: > For their OpenSSL fork, specifically, they rely on some system > properties such as their RNG’s behaviour way too much [...] I would think Linux and FreeBSD have much better PRNGs now than what has been done until now in OpenSSL. In case seeding from /dev/urandom is not trustworthy, OpenSSL is resorting to mixing in uninitialised blocks of memory, the time, private key exponents, digests, in one case a structure returned by stat() If this had been overhauled earlier, the Debian OpenSSL bug might have never happened? (Use of uninitialised memory was causing valgrind warnings in applications using the library, and the mistake was made trying to work around that I think). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53602127.2020...@pyro.eu.org
Re: Hardened OpenSSL fork
Here's a good catch I think: http://freshbsd.org/commit/openbsd/b6c83fa20a2269dadd0a9a73049813c75c2bcbbb SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disables a workaround for the weakness described in https://www.openssl.org/~bodo/tls-cbc.txt which, I think, was exploited by the BEAST attack ~9 years later. Much software in Debian can be seen to use SSL_OP_ALL, which includes SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS which could disable that mitigation. This has been addressed in some Debian packages already, typically with &= (~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS): https://security-tracker.debian.org/tracker/CVE-2011-3389 But it looks like some packages have perhaps not addressed this yet? >From http://codesearch.debian.net/search?q=SSL_OP_ALL : neon27 nmap ruby1.8, ruby2.0 (possibly?) freerdp (perhaps necessary for compatiblity with some Windows versions?) cyrus-imapd-2.4 links2 w3m apache2 (mod_ssl) nginx stud postfix ...and many more. I wonder if a bug filing is sensible or if I missed something obvious. I'd like to establish exactly which SSL/TLS implementations are known to be incompatible with this workaround; I saw MSIE 6.0 mentioned somewhere. AIUI if using TLS >=1.1 this is already mitigated. Breaking compatibility with Windows XP or MSIE 6.0 should be increasingly viable nowadays, if it improves security for the rest of us. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53602ab9.7050...@pyro.eu.org
Re: mirror.debian.net down?
On 29/04/14 23:22, Luca Filipozzi wrote: > It should be mostly corrected now although one name server is still not > transferring properly. > > Technicians have been deployed. Thank you! So I presume it will be coming back. If there is any more you can tell me about this DNS zone, it would be nice to document it better at https://wiki.debian.org/DebianGeoMirror If it is deprecated (as is geomirror.debian.net) that could be mentioned there. I'm curious how the list of mirrors is maintained, too. I still find it very useful in combination with a caching web proxy (better than http.debian.net because that can vary the resultant object URI, and better than cdn.debian.net because that doesn't consider mirrors carrying only a subset of architectures). Just one other thing - gb..mirror.debian.net has two old records for servers that have been unreachable for many weeks now - I wonder if they should be updated/removed from the set? 163.1.2.224 163.1.2.231 Thanks again, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53602f27.3050...@pyro.eu.org
Re: Deprecating/removing racoon/ipsec-tools from Debian GNU/Linux and racoon from Debian/kfreebsd
Hello, I wish racoon/ipsec-tools could stay for just a little longer. I'd like some time to evaluate it, against the *SWAN implementations, for GNU/kFreeBSD jessie. IPSEC has not been enabled yet in Debian default kernels, but it is a personal goal to have it in the jessie release. When I last had the chance to work on this, racoon seemed like the best available candidate due in part to a spate of security problems in openswan/strongswan, and freeswan not being maintained any more IIRC. I don't think systemd support should cause an issue for any existing package until jessie+1. And then I think systemd proponents should help you with a unit file if one is needed. And finally, it might still be useful at least as a kfreebsd-any package. When I have some time to resume work on IPSEC I hope I can then give some helpful feedback. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/536f9e4d.2070...@pyro.eu.org
Re: mirror.debian.net down?
On 14/05/14 15:25, Luca Filipozzi wrote:
> In consultation with the mirror team, I will be dropping the mirror.debian.net
> zone, today.
Oh, that's unfortunate. And odd to remove the service on such short
notice, unless I'm really the only person using it.
It may have been preferable to replace the zone with CNAMEs (one
wildcard record for each country that existed before, i.e.
*.{$country}.mirror.debian.net.) all to any one mirror's hostname, e.g.
ftp.debian.org. Then it could stay functional in the long term for
anyone who might be using it.
Perhaps even http.debian.net, if Raphael wouldn't mind setting up the
(many) necessary wildcard virtual host to make it work.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
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/5373b878.2000...@pyro.eu.org
Re: mirror.debian.net down?
On 14/05/14 22:24, Raphael Geissert wrote:
> I don't think there are many users of $cc.$arch.mirror.debian.net, [...]
I don't think anyone can really know this currently?
> but if
> anyone fancies adding the DNS entries, http.d.n should now be accepting
> anything with *.mirror.debian.net, and mirror.debian.net itself.
Thanks, Raphael. Please Luca would you consider adding CNAMEs for the
deleted *.{$arch}.mirror.debian.net. RRSETs all to http.debian.net.?
(I was wrong in my last mail, it would be *.{$arch} not *.{$country})
If this was done, Raphael could probably check his logs to see how much
it is really being used nowadays. And it would continue working.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
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/5373e29b.4040...@pyro.eu.org
Re: mirror.debian.net down?
On 14/05/14 23:00, Luca Filipozzi wrote: > I looked at the logs on ns1.debian.org through ns4.debian.org for the last > week. Not a single request that wasn't for SOA or RRSIG or DNSKEY, all from > debian machines. > > Some may have gone to easydns' name servers, I suppose, but the debian > nameservers were still set as authoritative. Didn't that seem suspicious? In a whole week not even a single query by a webcrawler/spambot? AFAICT *only* easynet's and one rcode0.net nameserver serve as authoritatve nameservers for the debian.net SOA? So unless something changed recently, it is expected you would see ns[1-4].debian.org only doing zone transfers but not serving legitimate queries? In the last week at least 13 of my own servers/VMs at two sites (each site has a caching DNS resolver), my desktop and also my laptop from offsite have been querying this zone, every day. I debootstrapped a new chroot using this zone only two days ago. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5373eee7.7090...@pyro.eu.org
Re: mirror.debian.net down?
On 14/05/14 23:34, Luca Filipozzi wrote: >> In the last week at least 13 of my own servers/VMs at two sites (each >> site has a caching DNS resolver), my desktop and also my laptop from >> offsite have been querying this zone, every day. I debootstrapped a new >> chroot using this zone only two days ago. > > I'll put it back in for a week, see what queries we get. *Thank you*. There should have been queries already from at least 2 IPs (or possibly IPv6) where I have servers that have just done a successful 'apt-get update'. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5373fbd7.7050...@pyro.eu.org
Re: mirror.debian.net down?
Hi, On 16/05/14 00:00, Luca Filipozzi wrote: > I'm guessing the gb.* lookups are mostly you. The au.* lookups are DSA. > > That leaves somebody looking up nl*. You and he/she might be the last users > of > this zone. Why did you discount the fr., it. and us. queries? nl.arm. does not seem to resolve any more (maybe it really does mean old pre-squeeze ABI so is not on the mirrors now anyway), > I don't think this level of traffic (the TTL is 10m) justifies the maintenance > of this zone by either the mirror team (who don't want it ) or DSA (who don't > want to maintain it). If that's your position then I can't ask you to do otherwise. I've always thought it was a good design with certain advantages over http.debian.net [1][2][3] and even easier to use than looking through the list of mirror sites. Thanks Luca for re-checking the popularity of the zone. It seems sufficiently low that I don't object to its complete removal. Thanks also Raphael for offering to handle this traffic but it seems unnecessary now. [1]: mirror.debian.net was very decentralised due to DNS's nature; if using your ISP's resolvers perhaps all traffic would be within your country; http.debian.net is somewhat bottlenecked by the HTTP redirector[s] (currently just one, in Germany) [2]: mirror.debian.net's RRSETs allow automatic (without running apt-get again) retrying from other mirrors depending on their reachability *right now* from *your* network; periodic monitoring by http.debian.net may take other routes [3]: mirror.debian.net's URIs don't change, allowing caching proxies to work very effectively; if http.debian.net uses permanent HTTP redirects and those are cached, it could 'pin' to a bad host after it goes down [and the target object may have been evicted from cache]; not caching the redirect would mean URIs change and cache hit ratio is much lower as a result Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: so, systemd now and teh world still turns...
On 03/06/14 19:46, Steven Chamberlain wrote: > On Tue Jun 3 14:16:40 2014, Holger Levsen wrote: >> currently all major desktops in jessie depend on 'systemd-sysv' > > Ouch... really? (Is it not just a glitch evaluating OR'd dependencies > or something?) I've taken a look in linux-amd64 sid and it is mostly true. I agree none of these packages seem to be installable without bringing in systemd and systemd-sysv: gdm3 gnome-session gnome-shell gnome-core gnome gnome-desktop-environment task-gnome-desktop razorqt sucrose-0.96 xfswitch-plugin mate-core mate-desktop-environment task-kde-desktop kde-standard kde-plasma-desktop kde-plasma-netbook But the following *are* installable without any systemd packages; seemingly only if you specify --no-install-recommends for some reason: kde-baseapps kde-runtime kde-workspace plasma-desktop [I think that's all of task-kde-desktop except for udisks2] Most notably installable without any systemd packages: xfce4 task-xfce-desktop (XFCE is a major desktop, it is the second most-popular behind GNOME) http://qa.debian.org/popcon-graph.php?packages=gnome-shell+kde-plasma-desktop+xfce4+lxde-core+mate-desktop-environment&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 It may be that piuparts prefers to bring in systemd sometimes, but the dependency chain could still be satisfied some other way without it. If you agree, could you pretty-please amend the false statement in your blog post to at least mention XFCE does not depend on systemd? Because there is too much false information relating to systemd circulating already (for or against it), and it being such a hot issue, that I think we should be especially careful to avoid adding to it. > I'd be interested to know the dependency chain leading > up to this, in the hopes that at least one full desktop can be still > available for non-systemd installs. I notice gnome-session-bin recently gained a dependency on systemd libs; that may be significant for MATE, Cinnamon and other things. Originally only the full gnome-session with gnome-shell and gdm3 needed systemd. > It should be technically possible in time for release, because at least > kfreebsd won't have it or any kind of substitute. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/538e270c.8080...@pyro.eu.org
Re: MATE 1.8 has now fully arrived in Debian
On Tue, 03 Jun 2014 11:38:44 +, Mike Gabriel wrote: > the MATE Packaging Team is proud to announce that MATE 1.8 has now fully > arrived in Debian. Also on kfreebsd :) Thank you for this! Testers: please remember to let us know at debian-...@lists.debian.org if you find kfreebsd-specific bugs. Hurd support should be not far away, mate-menus is the main blocker: https://buildd.debian.org/status/package.php?p=pkg-mate-team%40lists.alioth.debian.org&suite=sid&compact=compact&a=amd64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,s390x,sparc Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/538e372d.9090...@pyro.eu.org
Re: so, systemd now and teh world still turns...
On 03/06/14 23:10, Holger Levsen wrote: > thanks for taking this to the list and for doing some further investigations. > That's quite among the best possible outcomes of that blog post of mine ;-) Just wait until the press get hold of it... > piuparts has not gotten this far with testing yet (other depends of these > packages are probably in the failed testing state), but I have added those to > my list. I didn't realise piuparts was such a slow-running batch job; I'd imagined it as something that tests new packages in real-time like lintian, or dependency sets of the whole archive within minutes like dose/edos-debcheck. > as well as ltsp-server-standalone which piuparts.d.o just found now also > depending on systemd-sysv It's good to learn something new every day - here's how to watch APT follow dependencies: apt-get -o Debug::pkgDepCache::AutoInstall=1 \ --no-install-recommends install ltsp-server-standalone It would seem to be due to gnome-session, but there are OR'd dependencies on other providers of x-session-manager such as xfce4-session. So this actually works in sid, without needing systemd or systemd-sysv: apt-get --no-install-recommends \ install ltsp-server-standalone xfce4-session >> kde-baseapps kde-runtime kde-workspace plasma-desktop >> [I think that's all of task-kde-desktop except for udisks2] >> >> Most notably installable without any systemd packages: >> >> xfce4 task-xfce-desktop > > those indeed aren't on my list, but "xfswitch-plugin" is, and that is part of > XFCE which is why stated what I staed. >> If you agree, could you pretty-please amend the false statement in your >> blog post to at least mention XFCE does not depend on systemd? I didn't think you'd be telling lies on purpose, but let's not overstate the extent of systemd's tentacles yet. > well, to me the current question here is how much is "xfswitch-plugin" > essential part of XFCE? It's only optional. It's a Suggests: of package xfce4-goodies, and that is a Recommends: of xfce4. This is why I was able to `apt-get install --no-install-recommends` either xfce4 or task-xfce-desktop To check there were no systemd dependencies, I had systemd-must-die metapackage installed and held ;) It's actually very useful for this: apt-get exits with status 100 if there's a dependency conflict, so I was able to test a batch of packages very easily. That's a rather strict interpretation of systemd dependency (I've seen Simon's comment that use of some systemd libs doesn't always mean they're needed/used). > Oh, and systemd-sysv should me made essential soon or sysvinit-core should be > made non-essential (or whatever the next steps are to implement the decision > from #727708) ASAP - because there will be this freeze in 5 months... Yeah I expect it will be an uphill struggle to keep many packages installable without systemd. I hope there will be still soem bits left though. And I think think all this analysis is useful information and not a completely pointless exercise. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: so, systemd now and teh world still turns...
On Wed, 4 Jun 2014 13:10:19 +0200, Holger Levsen: > No, piuparts tests packages. And if it package is buggy it wont test packages > which depend on this buggy package as it's very hard to decide where the kind > of buggyness piuparts detects comes from. So in order for task-xfce-desktop to get tested, we could do: > apt-get install --no-install-recommends task-xfce-desktop > [...] > The following NEW packages will be installed: And then make sure all packages listed there (244 currently) have no piuparts bugs? And those would be listed here? https://piuparts.debian.org/summary.json [warning: big file] > Are you implying that I could be telling lies because I was brainwashed by > the > systemd tentacles? No nooo, I meant two things: 1. assuming good faith: I don't expect you'd say something like "currently all major desktops in jessie ... depend on 'systemd-sysv'" if you knew it wasn't true; that you were mistaken otherwise 2. systemd tentacles not in your head, but appearing as a dependency in an increasing amount of packages; metaphor, scary monster you can't run away from > Many years ago there was this cabal conspirancy in Debian, > it seems a bit like some cabal conspirancy is back: the systemd cabal, > secretly or not so secretly ruling and dictating the linux^wunix world. > "Stand > up before its too late." - this really explains a lot of the traffic. It's quite fundamental that in free/libre open source you can prefer certain software and avoid others, and the reasons are left totally up to the user: technical, political, ethical? Debian is very accommodating of this by packaging software into smaller interchangeable pieces. That way whole alternate desktops are available, almost seamless alternate choice of text editors, MTAs, MUAs, browsers, webservers, compilers and nowadays even kernel. systemd is different because *if* you have issues with it, it's really difficult to avoid. It's not a simple apt-get remove any more, which leaves either heroic efforts or whining about it as the only options. Anyway, I didn't want to get too much into that subject (again)... > Sure (thats a nice thing). But that wasnt really my question: is xfswitch- > plugin considered to be part of XFCE? IOW: is XFCE without that package > working, but with less features than one would expect from XFCE? > XFCE without mutt is XFCE as it was intended. XFCE without this plugin? That suggests a very broad interpretation of "depend on 'systemd-sysv'". Either way I think it's fairly clear that xfswitch-plugin is not officially part of XFCE: Package: xfce4-goodies (4.10) Synopsis: enhancements for the Xfce4 Desktop Environment Description: > The "Goodies for Xfce" project includes additional software and > artwork that are related to the Xfce desktop, but not part of the > official release. > [...] > Some packages are only suggested because they bring too much > dependencies, but you may find them interesting: > * Fast-user switching plugin (xfswitch-plugin) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/538f102e.4070...@pyro.eu.org
Re: so, systemd now and teh world still turns...
Hi Svante, The official source of it is here: http://users.unixforge.de/~tglaser/debs/dists/etch/wtf/Pkgs/mirabilos-support/ That was announced in this thread (which you started!) : https://lists.debian.org/debian-devel/2014/05/msg00271.html Remember to also set the package as 'held', or else APT will try to remove it in order to satisfy a systemd dependency! It's also not needed at all on kfreebsd or hurd, since src:systemd is not built there. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#643326: ITP: digraphtools -- Python library for working with directed acyclic graphs
Package: wnpp Severity: wishlist Owner: Steven McDonald -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: digraphtools Version : 0.2.1 Upstream Author : David Basden * URL : http://pypi.python.org/pypi/digraphtools * License : BSD Programming Lang: Python Description : Python library for working with directed acyclic graphs Some tools for working with directed acyclic graphs, partial orders and topological sorting with Python digraphtools was written as a lightweight way of using DAGs and partial ordering to represent, sort and traverse dependency trees. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/kFreeBSD) iQIcBAEBCAAGBQJOgZtVAAoJEKvd3sj2L+2w0l8P/2tHIKb0k3HocHrmXSirZfcS m6SihJeJT3RvHYIRNQSVlkcZhCjG0NZjJUksupf69mZwwqJQfIpKosFUoMBsjIXn u8OmncZ/u/LsHybOv+VE3r28eRLkC4yvcAgFkrwp9k3bFaJrEz40b/q7UHi/Rq0N tdAZTDnejNucAA9hkgdjVWHEPnuCRAznMgDfShMUYHz8cGP5kndac1Oz7wP8pi6M ZCIY4hRbvm47eKIGor0TAlbjUlFVKqz4DbVJJ3Fsc7mOhGz/cDHosmBoFhxxHCBb WxOaFkMIhjNRcATTRay3bwIG++IjZ/ysVTGzrKZHNssdJg7LmwCMvQ5O/u/MzORR wrWQ+QP+SwN00LT3kLBHeo1xWiL6atHI/SQCEhZ6OJaNedgk7ynUrio+Lr3DxaEQ uZq5jVehpou6o7NP2Ad4Exn9upEVMGwWnrUTruPqMjRQe+AU/h0WUwIoUoCXgBHW yHBUu2fWEEnhauUNw4gWK8dRps0LZkY4YIpCWAENawDqWbgpk2TT2v73yRUFhwVy 8EFhTSxbqAbibxpKK23ePTebxS3tZwACdWTwOZJ/czJhz9FC9hpMv1zN1U8qIcTC JGUb6L8n2jiugLh1ui+Q4EeXSXe9gDi7gYcn+rIzWnEttRVdSw81A1jIDJALXQ8F LXmo8Ay2gkirUUPKne/k =r1qV -END PGP SIGNATURE- -- 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/20110927094617.29786.91262.report...@luke.steven-mcdonald.id.au
Re: Announcing a Debian Hamradio Blend
Hi, > [Forwarding to d-d-a on behalf of Iain since he can not sign as DD] The quoted message was addressed *to* Iain and didn't make much sense to me. Isn't this the announcement here? https://lists.debian.org/debian-blends/2014/12/msg0.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141211140833.ga5...@squeeze.pyro.eu.org
Unauthorised activity surrounding tbb package
Mathieu, I'm writing to express my increasing frustration at activities you've instigated surrounding the tbb package that I maintain. Over the Christmas period a bug report was raised: #773359 "package tbb_4.2~20140122-4 FTBFS on mips and mipsel" and answered by yourself: "While I do understand the bug severity, our intention with Steve Capper was to only support upstream arch." Whilst I may agree with your sentiments, we have had no discussion over #773359; your response is effectively placing words in my mouth and I will not tolerate that. To confound matters, I wasn't even CC'ed in on the response! Then there's: #775506 "unblock: tbb/4.2~20140122-4" and, #775263 "RM: tbb [s390x mips mipsel] -- ANAIS; #768040" Both of which have been raised without any discussion with me; I am the maintainer for tbb! The technical work is hard enough, and I'm new to Debian and am learning the ropes still; it is not helpful to keep me in the dark over my own package. I appreciate that you are trying to help, but I cannot maintain this package whilst continually looking over my shoulder. I welcome help, but I must insist that maintainer related tasks surrounding tbb are discussed with me before they are instigated. [ I've CC'ed in debian-devel@lists.debian.org, as this is the second time I've had to bring this sort of thing up with you. ]. Best, -- Steve Capper -- 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/caekjja+sr+knpoq91zzkja9awtgfgff-kcjy9raa7hcucbd...@mail.gmail.com
Re: Unauthorised activity surrounding tbb package
On 19 January 2015 at 08:25, Mathieu Malaterre wrote: > Steven, Hi Mathieu, > > While being in terrible position to tell you what you should or should > not do, I'd still suggest you to read: > > https://www.debian.org/code_of_conduct > https://people.debian.org/~enrico/dcg/ > Thanks, I will give these a read. > > On Fri, Jan 16, 2015 at 5:48 PM, Steven Capper > wrote: >> Mathieu, >> I'm writing to express my increasing frustration at activities you've >> instigated surrounding the tbb package that I maintain. > > The wording 'frustration' is very accurate, see below. > >> Over the Christmas period a bug report was raised: >> #773359 "package tbb_4.2~20140122-4 FTBFS on mips and mipsel" >> >> and answered by yourself: >> "While I do understand the bug severity, our intention with Steve >> Capper was to only support upstream arch." > > Right, I did comment on the bug, which felt as if I had impersonate > you. Please also mention, this bug dates from Dec 17, and you've not > made any comment on an RC bug since. > >> Whilst I may agree with your sentiments, we have had no discussion >> over #773359; your response is effectively placing words in my mouth >> and I will not tolerate that. To confound matters, I wasn't even CC'ed >> in on the response! > > Again, this is very sorry, you did not include our private emails > surrounding #752820 (Jun 26). If I remember correctly I've sent you > multiple requests to have #752820 be fixed ASAP. > With your Makefiles talent, you quickly closed (Aug 21), thanks again > very much for this. > However this is where I failed to understand the following: why didn't > you request an unblock request at that point ? You knew Nov 5th was > coming quickly. That was a big mistake on my part. > >> Then there's: >> #775506 "unblock: tbb/4.2~20140122-4" >> and, >> #775263 "RM: tbb [s390x mips mipsel] -- ANAIS; #768040" >> >> Both of which have been raised without any discussion with me; I am >> the maintainer for tbb! > > While I do agree with you that I should not have requested 775506 > without contacted you first. Here is a linearized history of what > happen: > > 1) > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775262 > RM: openvdb [mipsel sparc] -- ANAIS; #768040 > > Before you were tbb maintainer I had to work on tbb fixed to have the > openvdb test suite to work on POWER arch. Therefore I'd appreciate > that only proper arches are available in tbb for any dependie package > to work correctly (openvdb maintainer hat on). > Now if you read this report, you'll think this is fairly dumb, since > there is only two options: source upload which will go against #773359 > at some point. Or as clarified a couple of minutes ago: > > block 775262 by 775263 > > 2) > Which leads to 775263 you mentionned above as me stepping on your > shoes. It happens to me a lot that a bug is reported in my package, > but quickly discover that the bug is within an underlying package. > This is *exactly* what happen, I even clarified this with my `block` > request. I do believe this was my right for 775263 to do so. > >> The technical work is hard enough, and I'm new to Debian and am >> learning the ropes still; it is not helpful to keep me in the dark >> over my own package. > > This is exactly what was depicted in our private emails surrounding > #752820, and this was also my *assomption* when you uploaded it in Aug > but never requested an unblock request. > So as said above, this is an incorrect assumption, and I should not > have reported this unblock request. However as explained above this > adds extra work for package depending on tbb since mips* and s390x are > non-functional on this arches (IMHO, again I am not tbb maintainer, > simply a tbb user) > >> I appreciate that you are trying to help, but I cannot maintain this >> package whilst continually looking over my shoulder. I welcome help, >> but I must insist that maintainer related tasks surrounding tbb are >> discussed with me before they are instigated. > > Since our discussion about #752820, you've never ever mentionned this. > So I (incorrectly) assumed you appreciated my help on bug triaging. I'm happy for any help I can get, I just need to be CC'ed into responses to bugs (the system didn't send me feedback) and a quick heads-up if something does need doing and I've obviously not noticed. > >> [ I've CC'ed in debian-devel@lists.debian.org, as this is the second >> time I've had to bring this sort
Googletest 1.13 requires at least C++14
Hi, Please CC me in any reply. A new googletest package for 1.13.0 just hit unstable and I now realise it requires at least C++14. From autopkgtests, I noted at least one build failure because of this. I'm hoping most code can simply opt to build at C++14 or later. However, I'm willing to re-introduce a googletest 1.12 if need be. Please get in touch if you have a package that cannot be made to build with googletest 1.13. Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Bug#1051939: ITP: ubpm - Universal Blood Pressure Manager
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: ubpm Version : 1.9.0 Upstream Contact: Thomas Löwe * URL : https://codeberg.org/LazyT/ubpm * License : GPL v3 Programming Lang: C++ Description : Universal Blood Pressure Manager The UBPM manages blood pressure readings, imported directly from supported devices, from files (CSV, JSON, XML, SQL), or entered manually. Readings may be viewed, printed, or mailed as a chart, table, or statistics. Features: * export data to CSV, JSON, XML, SQL or PDF format * migrate data from vendor software * analyze data via SQL queries * plugin interface for blood pressure monitors with a computer interface (USB, Bluetooth) My intention is to maintain this under the Debian-med umbrella https://salsa.debian.org/med-team signature.asc Description: This is a digitally signed message part.
Re: Bits from the Release Team: Cambridge sprint update
On Saturday, December 16, 2023 12:23:46 P.M. CST Paul Gevers wrote: > Another topic we covered is the volume and purpose of our mail list > (debian-devel@lists.debian.org). We recognize that that list mostly just > mirrors BTS traffic. The BTS already archives all information, and there are > multiple ways anyone can subscribe to the Release Team bugs, so this > mirroring seems unnecessary. More importantly it inhibits the list from > being a more useful discussion channel that we like it to be. Hence, we'll > try to work with the BTS maintainers to direct the traffic away Does that mean ceasing the "ITP" messages in debian-devel? I'd certainly welcome that! -Steve signature.asc Description: This is a digitally signed message part.
64-bit time_t transition: cargo needs manual intervention
Peter convincingly argues (details in bug) that manual intervention is needed for package "cargo": On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green wrote: > This will require manual intervention to resolve, either through > cross-building or through building manually in a hacked-up build > environment. > > I've certainly seen mention of rustc on #debian-devel recently, > so I think the people handling the time_t transition are already > aware of this. I'm wondering if the time_t people or the rust people could comment on this? This build failure has a surprisingly (to me) long chain of casualties. Is this an easy thing to fix or is going to take weeks? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
