Bug#810602: ITP: argon2 -- memory-hard hashing function
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: argon2 Version : 0~20151206-1 Upstream Author : D. Dinu, D. Khovratovich et al. * URL : https://github.com/P-H-C/phc-winner-argon2 * License : CC0 Programming Lang: C Description : memory-hard hashing function Argon2 is a password-hashing function that can be used to hash passwords for credential storage, key derivation, or other applications. . There are two main versions of Argon2: Argon2i and Argon2d. Argon2i is the safest against side-channel attacks, while Argon2d provides the highest resistance against GPU cracking attacks. . Argon2i and Argon2d are parametrized by: * A time cost, which defines the amount of computation realized and therefore the execution time, given in number of iterations * A memory cost, which defines the memory usage, given in kibibytes * A parallelism degree, which defines the number of parallel threads
Bug#793759: ITP: pytoml -- A Python parser for TOML
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: pytoml Version : 0.1.2 Upstream Author : Martin Vejnár * URL : https://github.com/avakar/pytoml * License : MIT Programming Lang: Python Description : A TOML parser and emitter for Python This project aims at being a specs-conforming and strict parser and writer for TOML files. . The library currently supports version 0.4.0 of the specs and runs with Python 2.7 and 3.4+. This package will be maintained under the Debian Python Modules Team umbrella. -- 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/20150727081750.3463.97796.reportbug@localhost
Re: Non-DD Access to a devel machine
On Wednesday 08 July 2015 11:32:46 Alastair McKinstry wrote: > I am debugging an issue in libdap, where a new release breaks on > big-endian architectures. > It looks like it is complex to debug and upstream doesn't have access to > big-endian hardware. > > Is it possible to arrange third-party login to Debian hardware? To the best of my knowledge, this is the current procedure to ask DSA for a guest account: https://dsa.debian.org/doc/guest-account/ Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#709480: ITP: libuv -- asynchronous event notification library
Package: wnpp Severity: wishlist Owner: Luca BRUNO -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libuv Version : 0.11.3 Upstream Author : Ben Noordhuis * URL : https://github.com/joyent/libuv * License : MIT Programming Lang: C Description : asynchronous event notification library Libuv is the asynchronous library behind Node.js. Very similar to libevent or libev, it provides the main elements for event driven systems: watching and waiting for availability in a set of sockets, and some other events like timers or asynchronous messages. However, libuv also comes with some other extras like: * files watchers and asynchronous operations * a portable TCP and UDP API, as well as asynchronous DNS resolution * processes and threads management, and a portable inter-process communications mechanism, with pipes and work queues * a plugins mechanism for loading libraries dynamically * interface with external libraries that also need to access the I/O This is going to be maintained within the javascript team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGeKxYACgkQRqobajv7n7MfMACfXnoqQUJYDb4BWdvoIU+kV+zf lK0An3oMSsSOrFFvrW1bzl7Sfrex4lkh =pAqX -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/20130523144334.16211.75158.reportbug@localhost
Bug#689207: ITP: rust -- a safe, concurrent, practical language
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: rust Version : 0.3.4 Upstream Author : Graydon Hoare et al. * URL : http://http://www.rust-lang.org/ * License : MIT Programming Lang: C/C++, Rust Description : a safe, concurrent, practical language Rust is a curly-brace, block-structured expression language. It visually resembles the C language family, but differs significantly in syntactic and semantic details. Its design is oriented toward concerns of "programming in the large", that is, of creating and maintaining boundaries - both abstract and operational - that preserve large-system integrity, availability and concurrency. . It supports a mixture of imperative procedural, concurrent actor, object-oriented and pure functional styles. Rust also supports generic programming and metaprogramming, in both static and dynamic styles. -- 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/20120930112201.8443.24969.reportbug@localhost
Re: Debian Project Leader Elections 2012: Second call for votes
Ahem, just forgot to properly set the recipient, sorry for the noise... Cheers, Luca signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2012: Second call for votes
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- da569edd-e41f-4ecd-b0d5-ce2848a777f9 [ 1 ] Choice 1: Wouter Verhelst [ 3 ] Choice 2: Gergely Nagy [ 1 ] Choice 3: Stefano Zacchiroli [ 2 ] Choice 4: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- Luca BRUNO (kaeso) : .''`. Email: lucab debian.org : : :' : GPG Key ID: 0x3BFB9FB3: `. `'` HAM-radio callsign: IZ1WGT:`- Networking sorcerer <%> Debian Developer signature.asc Description: PGP signature
Re: Bug#631743: O: gdb -- The GNU Debugger
Hector Oron scrisse: > I am planning to adopt gdb and I am looking for interested parties > to setup a team for gdb maintainance. If you are interested, please > let me know. Having a bunch of packages that strictly depend on it, I could help with occasional contributions (mostly from time to time). Please let me know once you have settled maintenance details with all interested parties. Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: PGP signature
Bug#626471: ITP: msp430mcu -- Spec files, headers and linker scripts for TI's MSP430 targets
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: msp430mcu Version : 0~20110512 (target suite: experimental) Upstream Author : Peter A. Bigot Texas Instruments Incorporated * URL : http://mspgcc.sourceforge.net/ * License : BSD-3 Programming Lang: C Description : Spec files, headers and linker scripts for TI's MSP430 targets This package provides specification files, C headers and linker scripts to be used with MSP430 cross-compilers. . Original MCU layouts, addresses and headers are provided and constantly updated by Texas Instruments; additional fixes are included to ensure full compatibility with MSP430 GCC toolchain. Resulting package is anyway useful with any proper cross-compiler. . This package is primarily intended to be used by MSP430 developers, in conjunction with a suitable toolchain. -- 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/20110512084610.5776.97917.reportbug@localhost
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
Stephen Kitt scrisse: > Would it be acceptable to introduce an exception to policy allowing > this? Something along the lines of > > An exception is granted for `Architecture: all' packages > containing libraries targeting platforms for which there is no Debian > architecture. Such packages may use their traditional triplet > as recognised by binutils and gcc. > > (The phrasing is certainly not perfect; this ends up being an > exception to an exception...) > > Policy also doesn't mention /usr/include/; I saw that > possibility referred to in http://bugs.debian.org/542865. > I'd appreciate your thoughts! While the wording may be refined for the final patch to policy, your proposed idea is good. Have you already opened a bug to track it? > PS. I realise some may find it odd to spend time on Windows support in > Debian, but it does come in handy, for instance for newer versions of > Wine, or for Windows versions of some tools used to install Debian > from a Windows environment. No need to feel alone in the dark, other compilers for bare-bone mcu are in the same conditions. avr and msp430 (experimental only right now) tool-chains will benefits from your proposal. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: PGP signature
Re: Bug#611880: ITP: webkit2pdf -- export web pages to PDF files
Ricardo Mones scrisse: > Package: wnpp > Severity: wishlist > Owner: Ricardo Mones > > * Package name: webkit2pdf > Version : 0.1 > Upstream Author : Colin Leroy > * URL : http://webkit2pdf.sourceforge.net/ > * License : GPLv2+ > Programming Lang: C > Description : export web pages to PDF files > > Webkit2pdf is a little GTK+ tool designed to fetch web pages and > export them to numbered PDF files (or to print them). > . > Specifying paper size and output directory is also supported. Have you seen cutycapt[0] already? I see no advantages in having webkit2pdf in Debian too, so far. Care to compare and expand your rationale? [0] http://packages.debian.org/squeeze/cutycapt Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: PGP signature
Bug#597753: ITP: mspdebug -- debugging tool for MSP430 microcontrollers
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: mspdebug Version : 0.11 Upstream Author : Daniel Beer * URL : http://mspdebug.sourceforge.net/ * License : GPLv2+ Programming Lang: C Description : debugging tool for MSP430 microcontrollers MSPDebug is a free debugger for use with MSP430 MCUs. It supports FET430UIF, eZ430, RF2500 and Olimex MSP-JTAG-TINY programmers. It can be used as a proxy for gdb or as an independent debugger with support for programming, disassembly and reverse engineering. . -- 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/20100922185318.27405.50189.report...@localhost
Re: RFC: Rules for distro-friendly packages
Enrico Weigelt scrisse: > I've collected several rules that upstreams should follow to make > distro maintainer's life much easier: You may also be interested in http://wiki.debian.org/UpstreamGuide Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpAoGnbGPUGK.pgp Description: PGP signature
Re: which gfortran version is used to compile liblapack.so.3gf.0
Kamaraju S Kusumanchi scrisse: > Is there a way to find out the version of gfortran compiler used to > build /usr/lib/lapack/liblapack.so.3gf.0 in the package liblapack3gf > 3.2.1-8 on i386 Debian testing machine? I tried looking at > https://buildd.debian.org/build.php?arch=i386&pkg=lapack . But it > does not have any build logs fro 3.2.1-8 It was built on maintainer's machine, so no public build-log. Anyway, assuming he had an up-to-date building environment at the time, you can check amd64 log[1], which shows gfortran-4.4_4.4.3-9. But you'd better ask the maintainer directly. Ciao, Luca [1] https://buildd.debian.org/fetch.cgi?pkg=lapack;ver=3.2.1-8;arch=amd64;stamp=1272412251 -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpUfuLKwocmv.pgp Description: PGP signature
Re: Improve support for installing 32-bit libraries on 64-bit systems
David Kalnischkies scrisse: > The biggest showstoppers are as far as i know that > a) dpkg doesn't support it > b) APT doesn't support it > c) (not many) packages use it (last time i check ~24) > > c) is likely caused by a) and b) which in fact decreases the > motivation for a) and b) to implement it as nobody use it… *** > dependency loop detected *** Goswin recently offered some help to improve the situation regarding a) and c) points, but I've seen no (public) answer from you: http://lists.debian.org/debian-devel/2010/04/msg00493.html Given that you say apt in experimental is semi-working, it would be interesting to join forces and see if something almost test-able can be provided. If so, it would also be useful to advertise it a bit more and hoping to gain some momentum... Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgp9Dkea2yZCS.pgp Description: PGP signature
Re: Preparing a Debian "e500" port/derivative (ABI-incompatible PowerPC variant)
Moffett, Kyle D scrisse: > I am currently preparing a Debian port to the "e500" architecture for > my employer eXMeritus, a subdivision of Boeing. [...] > * Are there any immediate recommendations or cautions regarding a > new architecture port? You may be interested in http://www.debian-ports.org/ For the other specific questions, if you get no answer you'd better address them directly to the relevant teams (ie. security, dpkg, buildd and such). Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpFUpGtDahn5.pgp Description: PGP signature
Re: tdpkg cache wrapper to dpkg
On Mon, Mar 15, 2010 at 10:59:25PM +0100, Mike Hommey wrote: > You should try the last version of dpkg in experimental, which improved > the way the .list files are read. (Also note this could be (slightly) > improved further). Thanks a lot for working on that! Yes dpkg from experimental is way faster than older. Now I get 3 seconds. With tokyocabinet and dpkg from experimental I get 1 second. Also consider that it's merely a wrapper, so it would be almost immediate to open a hdbm/rdbms. Best regards, -- http://www.debian.org - The Universal Operating System signature.asc Description: Digital signature
tdpkg cache wrapper to dpkg
Hello, it's since 2007 that cache for dpkg has been proposed but maintainers never replied. For this reason I've written a shared library libtdpkg.so to wrap open/fstat/rename/unlink calls from dpkg for .list files in order to cache the contents of those files. The result is quite impressive on how it boosts up cold startup of dpkg (from 14s to 2-3s here using tokyocabinet). Here's the homepage for reference: http://lethalman.hostei.com/tdpkg.html It's robust enough to not fuck up /var/lib/dpkg/info, the first time it should be run as root in order to create the cache in /var/lib/dpkg/info/tdpkg.cache. I'd like to hear your comments about any possibility to enhance the cache concept inside dpkg. Best regards, -- http://www.debian.org - The Universal Operating System signature.asc Description: Digital signature
Re: Allow package bug scripts to unconditionally stop reportbug
On Thu, Jan 07, 2010 at 02:35:47PM +0100, Sandro Tosi wrote: > Hello, > since version 4.10, reportbug checks the return code of the package > bug scripts and, it != 0, ask the user if to continue or stop. This is > the way we decided to fix #382010 . > > But now I'm wondering if there could be a use case of allowing the > scripts to unconditionally stop reportbug, for example using a > "special" exit code (140 f.e.) . > > I don't have a strong feeling about it, and letting a program abort > reportbug without a clear explanation to users might be bad, but I'd > like to hear what do you think about it. > > If a relevant number of you prefers to have this "fast way out", I'm > going and code it, else we can go on with the solution currently in > place. What's the use case of this? I've read the bug report saying "my /usr/share/bug script"... but which one? -- http://www.debian.org - The Universal Operating System signature.asc Description: Digital signature
Re: GDM, getty and VTs
Hello, I think the problem only happens for desktop startup. Say you _don't_ start X at boot, this is what happens: - 6 ttys are occupied - startx will use the next free tty7, which is what I expect if I don't specify vt to X. In this case dynamic allocation is good. Say instead you have *dm at startup: I think in this case dynamic allocation is not good, because it means X could be started on vt1, vt2, ... Actually on vt2. This is my proposal: I'd say to start X in a fixed tty _only_ when X is started at boot, in all other cases the tty will be chosen dynamically as next free or by whatelse policy. Of course, if the fixed tty is already in use, then it will use the next free; but that's not our case I think. The problem is: how to use a fixed-configurable tty "only at boot time"? I think this is the best compromise. I don't know if my English was clear enough. Best regards, -- http://www.debian.org - The Universal Operating System signature.asc Description: Digital signature
Bug#550155: ITP: anjuta-extras -- plugins and extras for anjuta
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: anjuta-extras Version : 2.28.0 Upstream Author : Naba kumar * URL : http://projects.gnome.org/anjuta * License : GPL2+ Programming Lang: C, C++, Python Description : plugins and extras for anjuta This package contains a set of plugins for the Anjuta IDE. (the long description will be expanded when the packaging is done, possibly with the list of plugins and what they do). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524710: ITP: python-box2d -- Python bindings for the 2D physics engine Box2D
Package: wnpp Severity: wishlist Owner: Luca Bruno * Package name: python-box2d Version : 2.0.2b1 Upstream Author : Ken Lauer * URL : http://code.google.com/p/pybox2d/ * License : zlib Programming Lang: C++, Python Description : Python Bindings for the 2D Physics Engine Box2D Python bindings for Box2D, a feature rich 2d rigid body physics engine. -- http://syx.googlecode.com - Smalltalk YX http://lethalman.blogspot.com - Thoughts about computer technologies http://www.debian.org - The Universal Operating System signature.asc Description: Digital signature
Bug#507176: ITP: freespeak -- A frontend to online translator engines for GNOME.
Package: wnpp Severity: wishlist Owner: Luca Bruno <[EMAIL PROTECTED]> * Package name: freespeak Version : 0.2.0 Upstream Author : Luca Bruno <[EMAIL PROTECTED]> * URL : http://freespeak.berlios.de/ * License : GPL Programming Lang: Python Description : A frontend to online translator engines for GNOME. With this program you can translate text and web pages using online translation engines. Currently supported translators are Google, Yahoo and FreeTranslation. Features include tabbed consulting, automatically copy and paste from/to clipboard, expandible in a very easy way by writing translator modules, easy to use and to configure, localized (currently English and Italian), good integration with free desktop environments (mostly in GNOME). signature.asc Description: Digital signature
Re: Change the format of /usr/share/bug/*/script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 11 Sep 2008 18:03:14 +0100
Neil Williams <[EMAIL PROTECTED]> wrote:
>> Making everything have to conform to GUI requirements is also
> non-friendly. reportbug must still be usable over SSH without requiring
> SSH -X. IMHO the GUI requirements should be lower priority than existing
> CLI behaviour.
>
Who said the CLI won't work?
> My own scripts don't use cat < to pass the file data into reportbug, that is cat "$file" >&3
>
Oh since you said about /etc/apt/sources.list I thought you were talking about
the apt package.
> Why is display() any better? How is reportbug CLI meant to implement
> display() ? The CLI doesn't want to display the file, it wants to read
> it in and put it into the temporary file.
>
display()
{
echo $@
}
Using a FIFO this means the script can output messages to the UI. There's not
only yesno() but also other information and messages that can be issued by the
script. If the problem was only yesno(), I wouldn't have the problem to
tricky-hack cat().
> I don't see the problem here, you call the bug script from another shell
> script that you write yourself. Your yesno() function does what is
> needed to ask the user and get the feedback then passes that back to the
> script and reads in the reply from the script. Then your own shell
> script can communicate with whichever GUI code you need - maybe by
> writing out a temporary file that the frontend adds to the displayed
> content.
>
In fact I've been talking about a FIFO in my previous mails.
> > Reportbug is ok with text and urwid (which also stops curses and
> > switches to text), but the coming GTK+ interface won't support it.
>
> Then the GTK+ frontend is broken and should be fixed so that it can
> support the existing format of the bug scripts.
>
Broken? Would you say it's broken because the script is text-only?
Fixing? The mostly sane fix is to embed a VTE.
> I don't see that at all. You simply wrap the existing shell code in your
> own shell wrapper that calls something like zenity or another bespoke
> interface that raises the necessary dialog, get the result and continues
> within shell. Then when the sourced bug script has processed the results
> of the bug script, it simply writes that out to a temporary file - or
> appends it to whatever temporary file is currently in use.
>
Ah ok so reportbug should (e.g.) have multiple handling scripts for the
different UIs, and not relying to the UI layer but to a yet another script for
dialogs. That's a good solution.
- --
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.ammazzatecitutti.org - Ammazzateci tutti
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkjJW8oACgkQw9Qj+8Kak3ElkQCfbBbjSnU+gkSvst2TeMyt+Fem
cykAnjSwAbqujOAWi/08TOb2umr91DNa
=TJQr
-END PGP SIGNATURE-
Re: Change the format of /usr/share/bug/*/script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 11 Sep 2008 17:09:26 +0100 Neil Williams <[EMAIL PROTECTED]> wrote: > On Thu, 2008-09-11 at 15:35 +0200, Josselin Mouette wrote: > > Le jeudi 11 septembre 2008 à 14:39 +0200, Luca Bruno a écrit : > > > The proposal: > > > I know it's bad to break compatibility but I also think keeping things > > > with hacks and far from the GUI prospective can become obsolete and > > > non user-friendly. > > > > > > First solution: change the scripts to use a bash function instead of > > > cat < > > cat() and keep going using a FIFO to deal with the UI > > I can't speak for others but my scripts use yesno(): > yesno "May I include your sources.list (/etc/apt/sources.list)? " yep > > The frontend could execute their own shell wrapper that implements yesno > and sources the bug script (as reportbug does). The other yesno function > can do whatever is necessary to callback into the frontend, get the user > response and feed it back to the script. > > If the frontend can use yesno(), I think it's perfectly reasonable to > expect all packages using bug scripts to use yesno() and not cat < > > > Second solution: I don't know, I'm asking to you > > > > The second solution is to specify that these scripts should not be > > interactive. I don’t think there is much point in it, and it would > > simplify things a lot. > > We've been here before. Some people might value the opportunity to > refuse permission to include sources lists and other data - any > non-interactive frontend must make it absolutely clear that this data > has been included and it is up to the user to delete it. > > Cannot the other frontends do what reportbug does and implement a bash > function that scripts can call? The terminal can be hidden or run via > internal calls, just as long as it pauses and allows the user to make a > decision. > > I suspect the problem with using debconf will be that debconf a) expects > to be run as root and b) is too specialised in how it wants to store > data (which we don't want to do at this point). However, something that > implements a choice of frontends *without losing functionality* is the > best bet. > The problem comes also with yesno(), because the more sane (as far as I know) way to communicate is FIFO. You call the yesno() function, then it writes to the FIFO and request ui.yes_no() from python. But for cat <http://syx.googlecode.com - Smalltalk YX http://lethalman.blogspot.com - Thoughts about computer technologies http://www.ammazzatecitutti.org - Ammazzateci tutti -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjJRXQACgkQw9Qj+8Kak3Gy4ACgh8JtNMg4Sq1qssrLX/zCPdOS BqQAoIMwV6L733xl7VI9AilNdnaczyZO =+UvB -END PGP SIGNATURE-
Change the format of /usr/share/bug/*/script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'd like to suggest changing the format of the bug scripts for allowing non-text user interfaces to display important information. This is the history: 1. I'm writing a GTK+ UI for reportbug, now landed in trunk thanks to Sandro Tosi 2. When filing in bugs for packages having bug scripts, the information don't show up in GTK+ because it's fully shell script, so the user needs to switch to the terminal (if he can guess he has to) 3. Talking in #debian OFTC we discussed about reportbug-ng to have problems in handling those scripts The problem: The bug script can ask twice for input and display output Current solutions: reportbug-ng: opens a terminal and popup-ups it to the user running the script reportbug gtk2 ui: uses FIFO and exports an hacked cat() function and the result is pretty good the UI (not applied) The proposal: I know it's bad to break compatibility but I also think keeping things with hacks and far from the GUI prospective can become obsolete and non user-friendly. First solution: change the scripts to use a bash function instead of cat
Re: RFH: curl, c-ares and ipv6
Yves-Alexis Perez scrisse: > On jeu, 2008-06-26 at 08:41 +0200, Yves-Alexis Perez wrote: > > Here it seems to work fine even with curl 7.18.2-1: > > Hmhm well. Ok. With curl 7.8.12-1e1 and libcares: > So it seems to work. Rebuilt from incoming for i386, it seems to work here too: [EMAIL PROTECTED]:~$ curl -v -o /dev/null http://www.sixxs.net * About to connect() to www.sixxs.net port 80 (#0) * Trying 2001:838:1:1:210:dcff:fe20:7c7c... connected * Connected to www.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g > zlib/1.2.3.3 c-ares/1.5.2 libidn/1.8 libssh2/0.18 [snip] with: ii curl 7.18.2-1e1 ii libcurl3 7.18.2-1e1 ii libcurl3-gnutls7.18.2-1e1 ii libc-ares2 1.5.2-2 I've also seen that -4 doesn't really force ipv4 resolution and connection: [EMAIL PROTECTED]:~$ curl -4 -v -o /dev/null http://www.sixxs.net * About to connect() to www.sixxs.net port 80 (#0) * Trying 2001:838:1:1:210:dcff:fe20:7c7c... connected * Connected to www.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g > zlib/1.2.3.3 c-ares/1.5.2 libidn/1.8 libssh2/0.18 is that normal? > Cheers, Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpNRMIXAa36E.pgp Description: PGP signature
Bug#316503: ITP: istanbul -- Desktop session recorder
Package: wnpp Severity: wishlist Owner: Luca Bruno <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: istanbul Version : 0.1.0 Upstream Author : Zaheer Abbas Merali <[EMAIL PROTECTED]> * URL : http://live.gnome.org/istanbul * License : GPL Description : Desktop session recorder Istanbul is a desktop session recorder for the Free Desktop. It records your session into an Ogg Theora video file. To start the recording, you click on its icon in the notification area. To stop you click its icon again. .. It works on Gnome, KDE, XFCE and others. - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.9 Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCxTJeRqobajv7n7MRAlj2AJ4wIcCvz19JdVMsFXyHkKy8HqdeEQCfWBCO ZoDyPoVBDfGa9DjEHfv7p2g= =iyY8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
Joey Hess <[EMAIL PROTECTED]> scrisse: > Martin Michlmayr wrote: > > gkdial -- PPP dial-up configuration and dialing tool [#287992] > > * Orphaned 164 days ago > > * 1 RC bugs. > > Does any graphical ppp frontend exist that can be used instead of > this? Under gnome you can find gpppkill and gpppon, but they can't manage provider setting. However you can find the modem-light applet for the gnome panel. Gkdial is a great tool, but ATM is really buggy :( Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S.| luca.br(AT)uno.it `. `'` | GPG Key ID: 0x3BFB9FB3 `- http://www.debian.org | Proud Debian GNU/Linux User -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
