Bug#573345: ITP: radare2 -- free advanced command line hexadecimal editor
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: radare2 Version : 0.4 Upstream Author : pancake * URL : http://www.radare.org/ * License : LGPL, imported GPL and BSD code Programming Lang: C; Bindings for: Perl, Python, Ruby, Vala Description : free advanced command line hexadecimal editor The project aims to create a complete, portable, multi-architecture, unix-like toolchain for reverse engineering. It is composed by an hexadecimal editor (radare) with a wrapped IO layer supporting multiple backends for local/remote files, debugger (osx,bsd,linux,w32), stream analyzer, assembler/disassembler (rasm) for x86,arm,ppc,m68k,java,msil,sparc code analysis modules and scripting facilities. A bindiffer named radiff, base converter (rax), shellcode development helper (rasc), a binary information extracter supporting (pe, mach0, elf, class, ...) named rabin, and a block-based hash utility called rahash. Note: radare2 coexists with radare1 and the binary of this package is called radare2, so I name the source package radare2, too. But I don't plan to continue maintaining radare1. I will ask for removal once radare2 is in the repository. -- Sebastian -- 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/20100310180618.12109.34456.report...@earth.universe
Bug#573501: ITP: valaswig -- generate swig interface files from vala/vapi files
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: valaswig Version : 0.1 Upstream Author : pancake * URL : http://hg.youterm.com/valaswig/summary * License : GPLv3 Programming Lang: Vala Description : generate swig interface files from vala/vapi files ValaSwig is a tool to parse vala or vapi files to transform them into swig interface files. With swig, you can create language bindings for any API written in vala or C with a vapi interface. This package is needed to build radare2. -- 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/20100311224231.8525.4901.report...@earth.universe
Bug#583845: ITP: mdbus -- DBus introspection utility
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: mdbus Version : 2.0.1~git20100529 Upstream Author : Michael 'Mickey' Lauer * URL : http://www.freesmartphone.org/ * License : GPL Programming Lang: Vala Description : DBus introspection utility mdbus allows to list DBus methods, call them and listen to DBus events. Is easier to use then standard DBus commands. Extra functionality is interactive mode with tab completion. -- 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/20100531020720.15690.66071.report...@earth.universe
Bug#584553: ITP: shr-specs -- SHR DBus XML specification & documentation
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: shr-specs Version : 0.1+git20100511 Upstream Author : Klaus Kurzmann * URL : http://www.shr-project.org/ * License : CC-BY-SA Programming Lang: XML Description : SHR DBus XML specification & documentation The Desktop-Bus prepares applications to communicate with another by the sending of predefined signals. The process is agnostic about programming languages, but the collaborating tools need to agree on a common set of signals and their interpretation. This package provides the DBus specifications of the SHR software stack, which sits on top of the freesmartphone.org software stack. Process these with a dbus binding generator to create stubs for your program. -- 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/20100604141656.11163.40823.report...@earth.universe
Bug#586588: ITP: fso-gsmd -- freesmartphone.org GSM daemon
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: fso-gsmd Version : 0.5.0+git20100602 Upstream Author : Michael 'Mickey' Lauer * URL : http://www.freesmartphone.org/ * License : LGPL Programming Lang: Vala Description : freesmartphone.org GSM daemon This daemon implements the freesmartphone.org GSM API This package is part of the freesmartphone.org software stack and is targeted for smartphones. -- 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/20100620194506.16984.626.report...@earth.universe
Bug#590457: ITP: libphone-ui-shr -- SHR library for user interface, EFL backend
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: libphone-ui-shr Version : 0.1+git20100726 Upstream Author : SHR Project * URL : http://www.shr-project.org * License : GPLv3 Programming Lang: C Description : SHR library for user interface, EFL backend This package provides the EFL phone ui from the SHR project. It is a backend for libphone-ui. -- 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/20100726131751.2826.38454.report...@earth.universe
Bug#590458: ITP: phoneuid -- SHR daemon for user interaction
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: phoneuid Version : 0.1+git20100502 Upstream Author : SHR Project * URL : http://www.shr-project.org * License : GPLv3 Programming Lang: C Description : SHR daemon for user interaction This package provides the SHR daemon showing the user interface. It can be controlled with the utilities from phoneui-apps and will show up automatically on incoming calls. -- 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/20100726132801.3015.53782.report...@earth.universe
Bug#590495: ITP: phoneui-apps -- SHR applications
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: phoneui-apps Version : 0.1+git20100303 Upstream Author : SHR project * URL : http://www.shr-project.org/ * License : GPLv3, CC-BY-SA Programming Lang: C Description : SHR applications This package contributes to the SHR mobile phone suite. It offers SHR's applications, which start the appropriate views in phoneuid. The package provides the following applications: * dialer * contacts * messages * phone log * settings -- 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/20100726194350.6532.6984.report...@earth.universe
Bug#518230: ITP: nbc -- Compiler for LEGO Mindstorms NXT
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: nbc Version : 1.0.1.b35 Upstream Author : John Hansen * URL : http://bricxcc.sourceforge.net/nbc/ * License : MPL Programming Lang: Pascal Description : Compiler for LEGO Mindstorms NXT Next Byte Codes (NBC) is a simple language with an assembly language syntax that can be used to program LEGO's NXT programmable brick (from the new LEGO Mindstorms NXT set). Not eXactly C (NXC) is a high level language, similar to C, built on top of the NBC compiler. It can also be used to program the NXT brick. NXC is basically NQC for the NXT. To compile NXC programs just use the NBC compiler from this package with source code files that have a .nxc file extension. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518343: ITP: talk2nxt -- upload/download files from or to LEGO Mindstroms NXT
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: talk2nxt Version : 0.2 Upstream Author : Pascal Raymond * URL : http://www-verimag.imag.fr/~raymond/edu/lego/t2n/ * License : GPL-3 Programming Lang: C++ Description : upload/download files from or to LEGO Mindstroms NXT This is a small CLI program for uploading files to your LEGO Mindstorms NXT and downloading others from it using the USB cable. .. Apart from that you can check the battery level and get basic information about the NXT. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521626: ITP: libchamplain -- libchamplain is a map widget for your applications
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: libchamplain Version : 0.2.9 Upstream Author : Pierre-Luc Beaudoin * URL : http://projects.gnome.org/libchamplain/index.html * License : LGPL Programming Lang: C Description : libchamplain is a map gtk widget written in C libchamplain is a clutter based map gtk widget. By default it supports OpenStreetMap, OpenAerialMap and MapsForFree. It will be needed to package eog-plugins. A full feature list is available under the project's url. This also fixes bug #498369 "RFP: libchamplain" -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522079: ITP: gstreamer0.10-rtsp -- GStreamer based RTSP server
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: gstreamer0.10-rtsp Version : 0.10.1.0 Upstream Author : Wim Taymans * URL : http://people.freedesktop.org/~wtay/ * License : LGPL Programming Lang: C Description : GStreamer based RTSP server GstRTSP is an RTSP server built on top of GStreamer. The library is needed by gnome-dvb-daemon. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523338: ITP: radare -- Free advanced command line hexadecimal editor
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: radare Version : 1.2.3 Upstream Author : pancake * URL : http://radare.org * License : GPL Programming Lang: C + scripts in various languages Description : Free advanced command line hexadecimal editor The project aims to create a complete free *nix-like toolchain for working with binary files. Its core is a commandline block-based hexadecimal editor which handles everything as a file. A process, file, disk, memory... This flexibility offers nice scripting features which can be mixed with lua, ruby, perl, python and Vala. A data block can be visualized in the way you want, making easier to recognize data structures. One of them is a disassembler print format which currently supports intel, arm, powerpc, m68k and java architectures. Here's a pseudocode representation of an intel program. radare comes with some other utilities: * radare command line hexadecimal editor with IO plugin extensions * rabin get info from ELF/MZ/PE/CLASS files * radiff offers different binary diffing functionalities * rasc shellcode generator and tester (outputs in raw, hexpairs or C) * rasm commandline assembler and disassembler * xrefs find crossed references on raw images for ppc, arm and x86 * rahash calculate different algorithms over data blocks of a file or stream * rsc command line helpers written in shellscript or perl * javasm minimalistic java assembler/disassembler/classdumper * armasm minimalistic arm assembler * rax converts between multiple radix numeric bases -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian maintainers for Enlightenment?
On Fri, Apr 13, 2012 at 11:48:22AM +0200, Cyril Brulebois wrote: > Adding said list to Cc… > > Svante Signell (13/04/2012): > > Are the Debian Maintainers for Enlightenment packages active? There has > > not been any packaging updates since 2011-04-25 (almost a year) while > > upstream has made several releases since then. > > > > http://packages.qa.debian.org/e/e17.html gives two names and a link to > > the "Debian Pkg-e Team". Looks like the team is an alias for an email > > address: Debian Pkg-e Team How to > > find out who they are and the current status? > > > > Sorry if this is the wrong forum. In case it is, please let me know > > where to address my question. > > Go to http://alioth.debian.org/ search for pkg-e, click the “Debian > Enlightenment Packages” link, and check the project members list. > Probably what you're looking for (there might be different subscribers > on the list, you probably would have to be list admin to see them > though). It may be a good idea to write directly who Albin Tonnerre, who does all the work. Last status I know is, that he wants to wait for a new stable release before updating the packages. -- Sebastian signature.asc Description: Digital signature
Bug#717428: ITP: libgisi -- communication library for isi modems
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: libgisi Version : 0.1.0 Upstream Author : freesmartphone.org Team * URL : http://www.freesmartphone.org/ * License : GPL Programming Lang: C, Vala Description : communication library for isi modems This project contains the following parts: * libgisi (standalone), a low level library for communicating with ISI devices, such as the modem found in some Nokia devices. * vala bindings for libgisi. * protocol definitions and enumerations. * libgisicomm, a high level library for communicating with ISI modem devices. -- 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/20130720195037.6581.27659.reportbug@earth.universe
Re: Switch to OpenJDK 7
On Sat, Aug 03, 2013 at 09:47:59AM +1000, Gerry Butler wrote: > Good morning Sylvestre > > Might I be impacted by the switch to OpenJDK7? > > (1) I am still using squeeze as, for various reasons, I am not yet ready to > move to wheezy. > > (2) I am using OpenJDK6 with the latest updates. > > (3) I am using Netbeans 6.0.1 from the release prior to squeeze, as squeeze > did not contain Netbeans. (My old Netbeans remained in place when I > switched to squeeze.) > > (4) A couple of weeks ago, with the latest update of OpenJDK6, a Netbeans > feature stopped working; it's annoying but not critical, and I can live > with it. > > My configuration is not ideal, but it mostly does what I need. I intend to > move to wheezy soon, but at the moment I do not want any disruption and, if > there is any risk of problems, I would prefer to keep everything the same > until I move to wheezy. > > What do you recommend? You will be only be "impacted" once you switch to jessie (wheezy+1). Wheezy has already been released using OpenJDK6 as default JDK. -- Sebastian signature.asc Description: Digital signature
Bug#647755: ITP: radare2-bindings -- bindings for radare2
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: radare2-bindings Version : 0.8.8 Upstream Author : pancake * URL : http://www.radare.org * License : LGPL Programming Lang: many Description : bindings for radare2 The project aims to create a complete, portable, multi-architecture, unix-like toolchain for reverse engineering. It is composed by an hexadecimal editor (radare) with a wrapped IO layer supporting multiple backends for local/remote files, debugger (osx,bsd,linux,w32), stream analyzer, assembler/disassembler (rasm) for x86,arm,ppc,m68k,java,msil,sparc code analysis modules and scripting facilities. A bindiffer named radiff, base converter (rax), shellcode development helper (rasc), a binary information extracter supporting (pe, mach0, elf, class, ...) named rabin, and a block-based hash utility called rahash. The bindings consist of vapi bindings for vala, which are converted to bindings for many other languages by valabind and swig. They are not part of the radare2 core package, because they depend on libradare2-dev being installed into the system. -- 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/2005203818.3015.70052.reportbug@earth.universe
Bug#696006: ITP: tinyos -- operating system for sensor motes and embedded devices
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: tinyos Version : 2.1.2 Upstream Author : TinyOS Team * URL : http://tinyos.net/ * License : BSD Programming Lang: nesC Description : operating system for sensor motes and embedded devices TinyOS is an open source, BSD-licensed operating system designed for low-power wireless devices, such as those used in sensor networks, ubiquitous computing, personal area networks, smart buildings, and smart meters. .. The package will generate a tinyos-source binary package. -- 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/20121215170327.12682.48006.reportbug@earth.universe
Bug#696007: ITP: tinyos-tools -- development tools for TinyOS
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: tinyos-tools Version : 1.4.2 Upstream Author : TinyOS Team * URL : http://tinyos.net * License : BSD Programming Lang: C, Perl, Python Description : development tools for TinyOS TinyOS is an open source, BSD-licensed operating system designed for low-power wireless devices, such as those used in sensor networks, ubiquitous computing, personal area networks, smart buildings, and smart meters. .. This package contains the development tools for TinyOS. -- 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/20121215170703.13047.44348.reportbug@earth.universe
Re: Bug#696006: ITP: tinyos -- operating system for sensor motes and embedded devices
On Sat, Dec 15, 2012 at 07:06:01PM +0100, John Paul Adrian Glaubitz wrote: > On Sat, Dec 15, 2012 at 06:03:27PM +0100, Sebastian Reichel wrote: > > The package will generate a tinyos-source binary > > package. > > What exactly does the package do? Does it download the current > upstream source and builds it for deployment? No. The source is included in the package. Similar to the linux-source package. > What's the advantage of having this as a package in Debian? Can it be > used for something on a running Debian system? In short: The package is needed for developing TinyOS based applications for small embedded devices as found in sensor networks. A bit more descriptive: TinyOS is not like a normal operating system. As mentioned in the description it's intended to be used on very small devices. Since these have very little memory/processing power a normal operating system kernel (e.g. Linux) cannot be used on them. The solution of TinyOS is having a very small operating system, which is statically linked together with the user written software into one big binary. This binary is then uploaded to the microcontroller. -- Sebastian signature.asc Description: Digital signature
Re: wxwidgets 3.0
Hi Olly, On Wed, Nov 13, 2013 at 03:43:49PM +, Olly Betts wrote: > I'll be at the mini-debcamp in Cambridge, UK at the end of this week > (14th and 15th November) and plan to make a start checking packages > with the new release. I'd welcome local and/or remote assistance. I just arrived in Cambridge. I plan to update aegisub to newest upstream (using wxWidgets 2.9) during the mini-debconf. -- Sebastian signature.asc Description: Digital signature
Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz
Hi, There have been multiple new upstream releases for stunnel4 and the package has gathered quite some bugs without any feedback from its maintainer. Looking at Rodrigo's QA page [0] his last actions were quite some time ago (2012) and most packages would have gathered RC bugs without the help of some fellow Debian Developers doing NMUs. Lennart Weller has prepared an updated package for stunnel4, which does not fit the default NMU criteria (e.g. being minimal) and is also willing to take over the package. I would sponsor the package for him once Rodrigo's status is clear. So here are my questions: * Does anyone know Rodrigo's whereabouts/status? * Can the MIA team take this over? [0] http://qa.debian.org/developer.php?login=rodrigo&comaint=yes -- Sebastian signature.asc Description: Digital signature
Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz
On Thu, Feb 06, 2014 at 03:27:51PM -0500, Chris Knadle wrote: > On Thursday, February 06, 2014 13:59:59 Sebastian Reichel wrote: > [...] > > NMUs don't necessarily need to be minimalistic -- for instance packaging new > versions is something that can be done with NMUs. This is admittedly not > terribly clear and I raised this question in #672198 which hasn't had any > activity for almost two years. Yes, but its advised to change as little as possible. I think changing the packaging style from cdbs to debhelper and similar changes are not ok (note: this is just an example). > For cases where the maintainer is unresponsive for an extended period, I'd > recommend requesting a new version via a 'wishlist' bug, then releasing a new > version as a -0.1 NMU. Others (myself included) have done this successfully. I opened the wishlist bug entry for that (#723781) in September and agree, that uploading a -0.1 NMU would solve the issue of the new upstream version. OTOH having an active maintainer is more helpful than lots of NMUs IMHO. Thus it makes more sense to take over packages or add at least add a Co-Maintianer for this. > As always, thanks for your continued work in Debian. ;-) You are welcome. -- Sebastian signature.asc Description: Digital signature
Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz
On Thu, Feb 06, 2014 at 06:56:04PM -0500, Chris Knadle wrote: > I know; I agree with you and I think the text is a bit misleading -- by > stating that you shouldn't change the packaging style it seems to indicate > that NMUs are supposed to be minimalistic, but a situation in which the > maintainer of a package disappears for an extended period is exactly a > situation in which a minimalistic change approach won't work. Right. So just take over the package and do normal uploads? By uploading normal changes as NMU this is what you effectively do anyways. > > > For cases where the maintainer is unresponsive for an extended period, I'd > > > recommend requesting a new version via a 'wishlist' bug, then releasing a > > > new version as a -0.1 NMU. Others (myself included) have done this > > > successfully. > > > > I opened the wishlist bug entry for that (#723781) in September and > > agree, that uploading a -0.1 NMU would solve the issue of the new > > upstream version. > > When I last did this in #728545 for mumble, the situation was rather serious > because it had been removed from jessie due to package dependency issues and > needed to get fixed ASAP. So I opened a wishlist bug, then waited about a > week, then uploaded a package for review to mentors.debian.net and started > hunting for a DD sponsor. > > I contacted the prior maintainer, who examined the package and decided it was > good enough and uploaded it to the DELAYED/5 queue. Then I wrote to the bug > to notify the maintainer in case he needed more time to respond and review > the > package if needed. > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728545 > > I didn't change the packaging style in doing this, but just about everything > else did. ;-) Obviously I was willing to support the package if there were > problems brought by my sponsored upload, and as long as you keep this in mind > as well then I think this practice should work. I think its okay for stunnel to simply follow the steps described in the MIA section of the developers reference [0]. > > OTOH having an active maintainer is more helpful than lots of NMUs > > IMHO. Thus it makes more sense to take over packages or add at least > > add a Co-Maintianer for this. > > Right, exactly. But to start with you may not want to do that; the > maintainer > normally gives approval for adding a co-maintainer. After you've done > several > NMU uploads and tried to contact the maintainer via the MIA team, then after > that I think the next logical step I think is to add one's self onto the list > of Uploaders... basically only because I know of no better option rather than > that being "the right thing to do". Because it's not reasonable to be > expected to do minimalistic changes for long periods of time. The MIA team can orphan packages if the maintainer is MIA, see [0]. Having a ghost-maintainer doing NMUs while the maintainer is MIA feels wrong to me. > So NMUs can solve things in the short-term, but between NMUs and "where to go > from there" is still a limbo I haven't yet gotten good answers for. There's > been a lot of debate on [debian-devel] about this and NMUs are generally one > of the answers, but there are situations that don't quite fit any standard > situation. Like for instance a maintainer might be MIA but ignoring one > particular package for a long period of time, thus the MIA team can't say > that > the maintainer is really MIA, yet the package isn't getting maintenance, and > thus no next logical step to take. That's why I'm suggesting that adding > one's self to Uploaders after some number of NMUs seems to make sense. :-/ > Again not necessarily right, just "the least worst" next step I can think of. If the maintainer is still working on some packages he should be contactable. Thus one can simply ask the maintainer if he/she wants to give the package to another maintainer or get a co-maintainer. [0] https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa -- Sebastian signature.asc Description: Digital signature
Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz
Hi Rodrigo, On Fri, Feb 07, 2014 at 10:21:12AM -0800, Rodrigo Gallardo wrote: > I do! ah, nice to hear from you. > I have been extremely remiss in my duties, and I have let ego keep > me from accepting it. > > I have orphaned stunnel and all of my other packages. Feel free to > NMU/take over as needs be. I will submit my formal resignation as > soon as I get the machine with my private key out of from under all > those half-read books. > > Meanwhile, please accept my apologies for not doing this earlier. No harm done. Thanks for the work you did for the Debian project :) It's really appreciated. -- Sebastian signature.asc Description: Digital signature
Re: How to provide support for -i386 utilities within -amd64 packages?
Hi Carl, On Wed, May 21, 2014 at 03:41:44PM -0700, Carl Worth wrote: > I'm interested in packaging (or helping to package) several programs and > libraries related to OpenGL, (such as apitrace, vogl, fips, and waffle). > > For each of these packages I have a question about best practices > related to supporting 32-bit libraries and binaries within a 64-bit > system. > > [...] I suggest using a bin directory in a multiarchified /usr/lib path, like e.g. wine and qt4 are doing. Example files are: /usr/lib/x86_64-linux-gnu/qt4/bin/qmake (package is qt4-qmake:amd64) /usr/lib/x86_64-linux-gnu/wine/bin/wine (package is wine64:amd64) In addition you can put a wrapper script in /usr/bin, which calls the binary in /usr/lib accordingly. Maybe something like 1. extract target file from parameters 2. determine target file's architecture from ELF headers 3. translate ELF architecture into gnu triplet 4. call matching binary in /usr/lib/ -- Sebastian signature.asc Description: Digital signature
Bug#633752: ITP: swtcalendar -- GUI date picker for Java using SWT
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: swtcalendar Version : 0.5 Upstream Author : Sergey Prigogin * URL : http://swtcalendar.sourceforge.net * License : MIT Programming Lang: Java Description : GUI date picker for Java using SWT SWTCalendar is a port of Kai Toedter's JCalendar to Eclipse's SWT. It is a GUI date picker for Java using SWT as the GUI toolkit. SWTCalendar was designed to be a flexible component so developer can embed a date picker in their application or create their own standalone date picker dialog. This is a dependency of jameica (Debian Bug #562862). -- 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/20110713122341.19864.2.reportbug@earth.universe
Bug#633763: ITP: swt-paperclips -- Simplified Java Printing Support for SWT
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: swt-paperclips Version : 1.0.4 Upstream Author : Matthew Hall * URL : http://code.google.com/p/swt-paperclips/ * License : EPL Programming Lang: Java Description : Simplified Java Printing Support for SWT Simple, light weight, extensible Java printing plug-in for SWT. PaperClips hides the complexity of laying out and rendering documents on the printer, helping you focus on what to print instead of how to print it. In a nutshell, PaperClips provides an assortment of document "building blocks," which you can tweak and combine to form a custom document. The assembled document is then sent to PaperClips for printing. PaperClips includes support for printing text, images, borders, headers and footers, column layouts and grid layouts, to name a few. It can also be extended with your own printable classes. With PaperClips you do not have to track cursors, calculate line breaking, fool around with font metrics, or manage system resources--it's all handled internally. And unlike report-generation tools, you are not constrained to a predefined document structure (like report bands). Every document is custom and the layout is up to you. This is a dependency of jameica (Debian Bug #562862). -- 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/20110713132133.21490.99012.reportbug@earth.universe
Bug#640076: ITP: fso-deviced -- freesmartphone.org device daemon
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: fso-deviced Version : 0.9.5+git20110805 Upstream Author : FSO Team * URL : http://www.freesmartphone.org/ * License : GPL, LGPL & Apache Programming Lang: Vala Description : freesmartphone.org device daemon fsodeviced implements the freesmartphone.org Device API. This API allows peripheral control, such as managing audio, backlight brightness, LEDs, Vibrator, Accelerometer, and power control for devices without dedicated controlling daemon. It can deal with charging notification and RTC, forwarding button events and notifying about the system's idleness status. This package is part of the freesmartphone.org software stack and is targeted for smartphones. -- 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/20110901231526.19694.17505.reportbug@earth.universe
Bug#640721: ITP: xf86-video-omap -- X.Org X server -- OMAP display driver
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: xf86-video-omap Version : 0.0.1~git20110717 Upstream Author : Rob Clark * URL : https://github.com/robclark/xf86-video-omap * License : MIT/X Programming Lang: C Description : X.Org X server -- OMAP display driver This driver for the X.Org X server (see xserver-xorg for a further description) provides support for OMAP2 and newer devices. The code depends on omapdrm support in the kernel, which is not yet mainline. The driver is still experimental and needs a patched kernel, but will probably take over omapfb in the long term. The advantages over omapfb are: * kernel part supports KMS using GEM * X driver supports XRandR (no more sysfs magic!) * 2D EXA acceleration of future OMAP chips (current ones do not have a 2D accelerator) * optional 2D and 3D acceleration of current OMAP chips via non-free PVR libs * clean code strucutre The kernel code is available from [0]. I plan to package it as DKMS package until is merged into the mainline kernel. [0] http://lists.freedesktop.org/archives/dri-devel/2011-September/014087.html -- 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/20110906201635.18920.94208.reportbug@earth.universe
Re: Bug#640721: ITP: xf86-video-omap -- X.Org X server -- OMAP display driver
On Wed, Sep 07, 2011 at 03:32:08PM +0200, Paul Wise wrote: > On Tue, Sep 6, 2011 at 10:16 PM, Sebastian Reichel wrote: > > > Description : X.Org X server -- OMAP display driver > > How does this package related to these two existing packages? > > http://packages.debian.org/sid/xserver-xorg-video-omap3 > http://packages.debian.org/sid/xserver-xorg-video-omapfb xserver-xorg-video-omapfb is using the omapfb kernel interface, it's a slighly advanced omap specific version of xserver-xorg-video-fbdev (which also works on omap). xserver-xorg-video-omap3 is omapfb, but with enabled NEON instruction set during compilation. It has been introduced before armhf existed. None of these support KMS, XRandR or EXA. On x86 you can compare them with xserver-xorg-video-vesa. The new driver supports KMS, XRandR, EXA & 3D (but needs a non-free plugin for some of these tasks, like 3D). -- Sebastian signature.asc Description: Digital signature
Re: Bug#640721: ITP: xf86-video-omap -- X.Org X server -- OMAP display driver
On Wed, Sep 07, 2011 at 04:07:18PM +0200, Cyril Brulebois wrote: > Sebastian Reichel (06/09/2011): > > Description : X.Org X server -- OMAP display driver > > FWIW: http://x.debian.net/reference/dependencies.html Thanks for writing the page. It's very useful. I would be glad if you can give the package (available from [0]) a quick review before I upload it to experimental. You can change Architecture to any if you want to build it on a x86 system for testing purposes (OMAP chips are ARM based, but the code can be compiled on other platforms, too). [0] http://anonscm.debian.org/gitweb/?p=collab-maint/xf86-video-omap.git -- Sebastian signature.asc Description: Digital signature
Re: Bug#640721: ITP: xf86-video-omap -- X.Org X server -- OMAP display driver
On Thu, Sep 08, 2011 at 02:23:51PM +0200, Cyril Brulebois wrote: > Sebastian Reichel (07/09/2011): > > I would be glad if you can give the package (available from [0]) a > > quick review before I upload it to experimental. You can change > > Architecture to any if you want to build it on a x86 system for > > testing purposes (OMAP chips are ARM based, but the code can be > > compiled on other platforms, too). > > You may want to expand the “need opendrm” bits. Mentioning the relevant > package might help users to get stuff they need. I guess you'll mention > that once you have a DKMS-enabled module? I will add a Recommends statement and update the description when the DKMS package is ready. > You should specify a versioned build-dep on xserver-xorg-dev (>= 2:1.9.4) > to use the xsf sequence. That would work without it on wheezy or sid, but > would fail on squeeze. > You probably want “mkdir -p m4”. If one interrupts the build, and starts > it again, running “mkdir m4” again will fail. OK. > Looks good otherwise. thanks for the review. -- Sebastian signature.asc Description: Digital signature
Re: Can/should we have an efi/efi-any platform architecture?
Hi, On Thu, Dec 11, 2014 at 06:08:58PM +, Leif Lindholm wrote: > When working on UEFI kernel support, for both armhf and arm64, we came > across packages (in several distributions) that were manually set to > build for architectures where UEFI was available - and so would not be > built for the ARM architectures. > > These are some obvious utilites such as: > - efibootmgr > - efivar/libefivar > - future versions of gnu-efi (upstream support for arm* has not > trickled back down yet) > > But also installer-specific ones like: > - partman-efi > > And some weakly related-to, but not really part of: > - dmidecode > > ... and definitely other ones I haven't come across yet. > > The point is, when we add support for another architecture which > supports UEFI, there are a number of packages that you will want to > enable for that architecture. Currently, this means trawling through > all of the packages and explicitly adding entries for > If we could transition this to be able to specify efi-all (or > whatever) instead of an explicit list of certain architectures, this > would be a lot more straightforward operation. > > Most, if not all, of these tools use only standard posix interfaces, > so will build cleanly for any architecture. > > An alternative would of course be to simply do like with acpica-tools, > and build all of these tools for all architectures. The problem there > would be with packages which depend on packages that only exist on > architectures that have UEFI - i.e. partman-efi vs. efi-modules. > > Would this be useful, desirable, an accident waiting to happen? How about building for "arch: any" and adding a build dependency on a new "efi-support" package, that is only available for architectures with efi available? -- Sebastian signature.asc Description: Digital signature
Bug#789284: ITP: libcmtspeechdata -- library for handling the Nokia N900's modem speech data
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: libcmtspeechdata Version : 2.1.1+git20150211~9206835 Upstream Author : Kai Vehmanen Pavel Machek * URL : https://gitlab.com/libcmtspeechdata/libcmtspeechdata * License : LGPL-2.1+ Programming Lang: C Description : library for handling the Nokia N900's modem speech data libcmtspeechdata is the userspace side for Nokia's CMT Speech Data SSI protocol. The library provides an application interface for implementing the speech data path for cellular voice calls. IT does not contain any functionality for setting up and managing the call signaling path. The /dev/cmtspeech kernel interface used by the Nokia N900 is supported in the mainline kernel since 4.1 [0]. This library is used by all existing open source implementations handling the speech path of the Nokia N900's modem (fso-audiod and pulseaudio-module-cmtspeech-n9xx). This library will be maintained using a git repository, that can be found at [1] shortly. [0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f62fe8a5851db94e10d8d956c123d4011aaeed9 [1] https://anonscm.debian.org/cgit/pkg-n900/libcmtspeechdata.git/ -- Sebastian -- 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/20150619135400.14335.61366.reportbug@earth
Bug#789440: ITP: fso-audiod -- freesmartphone.org Audio daemon
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: fso-audiod Version : 12.0 Upstream Author : FSO team * URL : http://www.freesmartphone.org/ * License : GPL Programming Lang: Vala Description : freesmartphone.org Audio daemon fsoaudiod implements the freesmartphone.org Audio API. It takes care of Audio related functions, particularly routing the speech data between the soundcard and the modem. Currently fsoaudiod has support for the Openmoko Freerunner, its inofficial successor - the GTA04 as well as Nokia's N900. The fso-audiod is part of the freesmartphone.org software stack and will be maintained via the pkg-fso team. It's packaging has already prepared some time ago in [0]. The audio daemon is really important at least on the N900, since a custom modem interface is used for the speech data. While the daemon implements an FSO specific API and interacts with e.g. fso-gsmd, it should be possible to use it in conjunction with ofono with a small plumbing script. [0] https://anonscm.debian.org/cgit/pkg-fso/fso-audiod.git/ -- Sebastian -- 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/20150621003232.13493.60253.reportbug@earth
Re: Key collisions in the wild
Hi, On Wed, Aug 10, 2016 at 12:47:43AM +0200, Samuel Thibault wrote: > As a late follow-up of the gpg key collision thread from debian-private > (but posted on debian-devel, there is nothing private here, I prefer to > see this information publicized actually): > > € gpg --search-key samuel.thiba...@gnu.org > ... > (1) Samuel Thibault > 4096 bit RSA key 7D069EE6, created: 2014-06-16 > (2) Samuel Thibault > 4096 bit RSA key 7D069EE6, created: 2010-09-14 > > So somebody *does* try to fake my gpg key too... Looks like somebody uploaded the evil32 (https://evil32.com/) data to public keyservers. $ gpg --search-key 0xC83BFA9A gpg: searching for "0xC83BFA9A" from hkp server pgp.mit.edu (1) Sebastian Reichel 4096 bit RSA key 0xB19B33F7C83BFA9A, created: 2014-06-16 (2) Sebastian Reichel Sebastian Reichel ... 4096 bit RSA key 0xD8EED7F3C83BFA9A, created: 2010-10-11 Keys 1-2 of 2 for "0xC83BFA9A". Enter number(s), N)ext, or Q)uit > q $ wget "https://raw.githubusercontent.com/thingless/evil32/gh-pages/cloneset.tar.gz"; $ tar xf cloneset.tar.gz $ gpg --list-packets cloneset/B19B33F7C83BFA9A.pgp :public key packet: version 4, algo 1, created 1402941352, expires 0 pkey[0]: [4096 bits] pkey[1]: [32 bits] keyid: B19B33F7C83BFA9A :user ID packet: "Sebastian Reichel " :signature packet: algo 1, keyid B19B33F7C83BFA9A version 4, created 1407200484, md5len 0, sigclass 0x13 $ date --date="@1402941352" Mon Jun 16 19:55:52 CEST 2014 $ date --date="@1407200484" Tue Aug 5 03:01:24 CEST 2014 -- Sebastian signature.asc Description: PGP signature
Re: removal instead of orphaning?
Hi, On Fri, Aug 26, 2016 at 09:47:39PM +0200, Adam Borowski wrote: > On Fri, Aug 26, 2016 at 09:38:02PM +0200, Guus Sliepen wrote: > > > Should unrelated people spend time on packages they don't care about? > > > > No, that's why they are orphaned in the first place. > > You can run the attached script to see if there are any RC bugs on an > orphaned package you might give a damn about. > rc-alert -dU "$@" \ > `wget -qO- http://www.debian.org/devel/wnpp/orphaned| > sed -ne 's/.* href="https\?:\/\/bugs.debian.org\/\([0-9]*\)">\([^:<]*\)[: > ]*\([^<]*\)<\/a>.*/O \1 \2 -- \3/; T d; p; : d'| > cut -d' ' -f 3` I was a bit scared by the length of the list on my system, but it seems to list all RC bugs for all orphaned packages, not just those being installed. This is because of rc-alert's behaviour: $ dpkg -l bootchart dpkg-query: no packages found matching bootchart $ rc-alert -dU bootchart Package: bootchart Bug: 731669 Title: bootchart: outdated version should not be shipped with jessie Flags: [] (none) Dists: [U] (unstable) Package: src:bootchart Bug: 817382 Title: bootchart: Removal of debhelper compat 4 Flags: [] (none) Dists: [U] (unstable) This modification should output only rc-bugs of orphaned and installed packages, which ony my system is just a single bug instead of houndreds: rc-alert -dU `wnpp-alert | grep "^O " | cut -d' ' -f 3` -- Sebastian signature.asc Description: PGP signature
Bug#842298: ITP: california -- calendar application for GNOME 3
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: california Version : 0.4.0 Upstream Author : Jim Campbell * URL : https://wiki.gnome.org/Apps/California * License : LGPL-2.1 Programming Lang: Vala Description : calendar application for GNOME 3 California is a calendar built for GNOME 3. It allows you to view and manage your online calendars with a simple and modern interface. It uses EDS (Evolution Data Server) as the back-end for managing your calendars. If you've already added calendars to EDS via another application (such as Evolution), you should be able to see those calendars in California as well. I have packaging ready at [0] and intend to upload it, if it turns out to be useful on small screens as found in smartphones. [0] https://anonscm.debian.org/cgit/pkg-gnome/california.git -- Sebastian
Re: What's a safe way to have extensions in chromium in Debian?
Hi, On Wed, Mar 22, 2017 at 12:03:02PM +0100, Enrico Zini wrote: > now we have extensions disabled in Chromium by default. If I did my > homeworks correctly, that prevents Chromium from phoning home by > default, and prevents a previous scenario where extensions could be > installed but not upgraded, becoming security issues over time. > > Now, suppose I need an extension, what is the proper way to have it in > Debian, so that it gets upgraded when needed? With that proper way, what > amount of phoning home is going to happen? > > Since this looks like it's going to be a major issue with stretch, can I > have some authoritative wiki page / FAQ entry that tells me how I can > deal with it cleanly, and that I can easily send to confused people? I wonder if we could just add a boolean debconf question for this. It could setup /etc/chromium.d/remote-extensions based on the answer and provide some (dis)advantages info for selecting either option. -- Sebastian signature.asc Description: PGP signature
Re: What's a safe way to have extensions in chromium in Debian?
Hi, On Thu, Mar 23, 2017 at 12:03:00PM +0100, Martin Bagge / brother wrote: > On 2017-03-23 07:50, Sebastian Reichel wrote: > > I wonder if we could just add a boolean debconf question for this. > > It could setup /etc/chromium.d/remote-extensions based on the answer > > and provide some (dis)advantages info for selecting either option. > > Probably hard to do that without violating the importancy level of a > debconf message. > > "Copyright messages do not count as vitally important (they belong in > /usr/share/doc/package/copyright); neither do instructions on how to use > a program (these should be in on-line documentation, where all the users > can see them)." > - 3.9.1 in policy My proposal is not an instruction how to use the program, but an option changing the usability VS security aspect of the program. The information is just there, so that the user knows what his choice implies. I wasn't aware, that the graphical software installation solutions do not ask debconf questions, though. -- Sebastian signature.asc Description: PGP signature
Bug#860283: ITP: xwallpaper -- utility for setting X wallpaper
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: xwallpaper Version : 0.2 Upstream Author : Tobias Stoeckmann * URL : https://github.com/stoeckmann/xwallpaper * License : ISC Programming Lang: C Description : utility for setting X wallpaper Hi, While reviewing feh (and imlib2 dependency) from security aspect Tobias found a few issues in it. While those were fixed upstream, imlib2 is marked as legacy and no release is expected soon. As alternative to feh Tobias decided to write an even simpler tool for setting the wallpaper, which is conveniently named xwallpaper (with xsetwallpaper already being used by NetBSD people). It has minimal dependencies (libxcb, libjpg, libpng, libxpm) and is just above 1000 lines of code. Regarding to background setting support it supports all of feh's modes while using less resources and being faster. Compared to feh unsupported features are image loading from URLs and automatic creation of a status file. Also parameter syntax is slightly different following the syntax of xrandr. -- Sebastian
Bug#860322: ITP: tt-rss-notifier-chrome -- Chromium extension providing toolbar button for TT-RSS installations
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: tt-rss-notifier-chrome Version : 0.5.2 Upstream Author : Andrew Dolgov * URL : https://tt-rss.org/gitlab/fox/tt-rss-notifier-chrome/ * License : GPLv3 Programming Lang: JS Description : Chromium extension providing toolbar button for TT-RSS installations This extension adds a toolbar button which changes color when unread articles are available in your Tiny Tiny RSS installation and displays the number of unread entries in a tooltip and, optionally, using a badge. The server's URL and the username are changeable in the extension's option page.
Bug#861810: ITP: virtme -- tool for disk-less Linux emulation using qemu
Package: wnpp Severity: wishlist Owner: Sebastian Reichel * Package name: virtme Version : 0.0.3+git20170420 Upstream Author : Andy Lutomirski * URL : https://git.kernel.org/pub/scm/utils/kernel/virtme/virtme.git/ * License : GPL-2 Programming Lang: Python Description : tool for disk-less Linux emulation using qemu Virtme is a set of simple tools to run a virtualized Linux kernel that uses the host Linux distribution or a simple rootfs instead of a whole disk image. Virtme is tiny, easy to use, and makes testing kernel changes quite simple. Some day this might be useful as a sort of sandbox. Right now it's not really configurable enough for that. The tool is really useful for kernel testing.
Re: binNMU or reproducible builds (choose only one)
Hi, On Thu, Sep 24, 2015 at 11:56:56AM +0100, Colin Watson wrote: > On Thu, Sep 24, 2015 at 12:29:59PM +0200, Santiago Vila wrote: > > But once we are able to trigger a rebuild with sourceful NMUs, as > > Ubuntu does, binNMUs will hopefully be a thing of the past. > > Amusingly, the way we do it in Ubuntu is a huge hassle in some cases, > and at least some of us would rather have binNMUs. (That's partly > because it's a manual process; if it were automated it would be better, > but it still wouldn't solve the problem that in some cases you really do > want to do single-architecture rebuilds without having to rebuild a > stack of packages on slower architectures entirely unnecessarily. Hi, > Haskell.) Maybe one could generate a pseudo binary package for architectures not included in the binNMU, so that all architectures provide their binary packages with the same version. I think it easier to understand by giving an example: Let's assume a binNMU is needed for "demopkg" in version "23.42-1" for i386 and amd64. Current behaviour would result in: [amd64, i386]: 23.42-1+b1 [armel, armhf, arm64, mips, ...]: 23.42-1 The binNMU process could now prepare 23.42-1+b1 for all unaffected platforms automatically by downloading the existing binary package, updating the changelog file, increasing the version and saving it again. That would result in: [all architectures]: 23.42-1+b1 That should make it possible to have symlinks for /usr/share/doc/$pkgname from all to $arch (assuming "all" is also regenerated) and fixes the version mismatch problem regarding multi-arch. The obvious disadvantage is, that users will have to download a more or less unchanged package again. -- Sebastian signature.asc Description: Digital signature
