Re: bash exorcism experiment ('bug' 762923 & 763012)
On Mon, 2014-09-29 at 08:03 +0200, Matthias Urlichs wrote:
> Russell Stuart:
> >
> > > > - array variables.
> >
> > No workaround for this one? Pity. This is what usually prevents
> > conversion.
>
> Well, you could use $ary_len to remember the length of the array,
> "$(eval "echo \"\$ary_$pos\"")"
> for retrieving values, and
> val="some random value which probably requires quoting when eval'd"
> eval "ary_$pos=\"\$val\""
> for assigning to individual members.
>
> Package that in a couple of helper functions and it looks almost sane. :-/
For some versions of sane I guess.
The major reason for having an array is to be able to go "${array[@]}"
somewhere, and have the quoting automagically work.
Like all successors of the original /bin/sh, dash does have to support
arrays for its argument processing: supporting "$*", "$@", "$#" and
shift off the top of my head. You can bend it to your own purposes to
some extend using "set --- val1 val2 ...".
I suspect some think adding arrays is a big change, introducing new
concepts to dash. But it isn't really. All it really does is allow you
to have named argument lists in addition to the built in one. And most
uses I have found for them are in that vein as well - building up
argument lists for commands, without having to descend into eval/quoting
hell.
signature.asc
Description: This is a digitally signed message part
Bug#763326: ITP: libbssolv-perl -- compute package dependencies (Open Build Service backend)
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: libbssolv-perl Version : 0.02 Upstream Author : Michael Schroeder * URL : https://github.com/openSUSE/perl-BSSolv * License : GPL-1+ or Artistic Programming Lang: Perl Description : compute package dependencies (for Open Build Service backend) Satisfyability Solver based on LibSolv to compute package dependencies. . This is a support Perl module for the OBS backend. It contains functions for repository management, dependency solving, package ordering, and meta file creation. This Perl module is an add-on to the Open Build Server software. -- 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/20140929105950.29292.34833.report...@minobo.das-netzwerkteam.de
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Mon, 29 Sep 2014, Christoph Anton Mitterer wrote: > Now to deal with your concern of larger outages: > 2) Just because there are no valid [In]Release* files, it doesn't mean > that those mirrors and their repositories can't be used any longer. The > data is still there as it was before. > An application like apt/aptitude/etc. could simply give the user an > error, telling that the files have expired for hh:mm and could give the > user and option to nevertheless trust them. > And the same options could be provided for batch modes. This is not making any sense anymore. Step back and think about your threat model in the first place. The *entire* threat model, not whatever small part of it that looks easily fixable by a severe reduction to the inrelease validity period (which you have already been told by several Debian archive ops _and_ mirror ops people to be very much a Bad Idea). Now, if you want us to add per-repository validity overrides to source.lists that can *reduce* the range APT will accept, so that the local admin can tighten things, that's fine. If you're going to propose some sort of tiered system and a way for apt to actually know it is OK to use this "updates not often at all" fallback mirror as long as it also has a mirror from the "fresh stuff only" tier, that would be at least sensible... Would those help? I don't know, that's what the full threat model analysis is for. > IMHO it's quite dangerous if people start to negotiate security for > technical reasons, the wellness-factor of users or for historical > reasons. Attackers simply don't care about this. "secure" means "available to those that should be able to access it, when they should be able to access it, in the way they should be able to access it", just as much as the negative forms. So, can we get now some alternative proposals that address the fact that some mirrors need >48H validity, and many leaf mirrors really want at least a week? Or to help apt detect it is using a mirror that is more outdated than expected, which *is* the reason 99,999% of our users ever suffer an "unintended downgrade attack" ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20140929110845.ga20...@khazad-dum.debian.net
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
Hi, > So, can we get now some alternative proposals that address the fact that > some mirrors need >48H validity, and many leaf mirrors really want at least > a week? How about "Security updates are published on security.d.o, so _that_ archive's validity might as well be 50h or so; anything else will have to live with at least two weeks' validity"? A mirror who needs more than a day to sync up to our security archive deserves to lose. -- -- Matthias Urlichs signature.asc Description: Digital signature
Fwd: open-axiom is marked for autoremoval from testing
Is it really a good idea to remove packages which FTBFS because of *internal compiler error*? Shouldn't GCC be removed instead? :-) -- Forwarded message -- From: Debian testing autoremoval watch Date: 2014-09-29 8:39 GMT+04:00 Subject: open-axiom is marked for autoremoval from testing To: open-ax...@packages.debian.org open-axiom 1.5.0~svn3056+ds-1 is marked for autoremoval from testing on 2014-10-13 It is affected by these RC bugs: 761549: open-axiom: FTBFS: internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2066 -- 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/CALL-Q8z9xhoaHfM6T+fgTZmyRLr4vDc+dkVunrX7XrduNxA=j...@mail.gmail.com
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Mon, 29 Sep 2014, Matthias Urlichs wrote: > > So, can we get now some alternative proposals that address the fact that > > some mirrors need >48H validity, and many leaf mirrors really want at least > > a week? > > How about "Security updates are published on security.d.o, so _that_ > archive's validity might as well be 50h or so; anything else will have > to live with at least two weeks' validity"? > > A mirror who needs more than a day to sync up to our security archive > deserves to lose. Sure, 48H or 24H refresh requirements for anything that is mirroring s.d.o is a restriction we could deploy. But there's the DoS concern if there is a problem refreshing s.d.o from ftp-master. At least, s.d.o. is a lot more controllable than the normal mirror network. IMHO, s.d.o would be a very good place to start desining a more resilient two-path system for. Maybe we could get away with flooding the normal mirror network with a delayed dump of s.d.o, so that you get fresh data from s.d.o, and it also gets mirrored to the normal mirrors "soon" so that they can be used as fallbacks? This solution is s.d.o. specific, but might be worth thinking about. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20140929120540.gc20...@khazad-dum.debian.net
MBF: libjpeg-turbo transition started (if you depend on libjpeg8-dev please read)
Hi, I will be filling bug reports on packages explicitly depending on libjpeg8-dev. The text of bug report can be found here: https://wiki.debian.org/LJTTransition I have already rebuild several packages and it mostly looks OK, the results of the rebuild can be found at the same place in the wiki. Affected maintainers: Agustin Henze crrcsim Alastair McKinstry libterralib (U) ncl Alessandro Ghedini mpv (U) Alessio Treglia harvid (U) Andreas Metzler sdop Andreas Rönnquist allegro5 (U) Andy Hawkins flactag (U) Axel Beckert dillo Bas Couwenberg libgaiagraphics (U) Bernd Zeimetz rawstudio (U) Bertrand Marc libextractor Bruno "Fuddl" Kleinert ioquake3 (U) Damien Raude-Morvan openjdk-6 (U) openjdk-7 (U) openjdk-8 (U) Daniel Pocock flactag Daniel Walrond wv Darren Salt xine-ui David Paleino libgaiagraphics (U) Debian Erlang Packagers wings3d Debian FlightGear Crew flightgear simgear Debian Games Team allegro5 aseprite freeorion ioquake3 Debian GIS Project libgaiagraphics Debian GIS Team libterralib Debian Krap Maintainers libindi Debian Multimedia Maintainers harvid libquicktime mpv Debian Perl Group libalien-sdl-perl Debian PhotoTools Maintainers rawstudio Debian Science Maintainers openctm Debian Shotwell Maintainers libraw Debian Squeak Team squeak-vm Dmitry Smirnov abiword Dmitry Smirnov wv (U) Dominique Dumont libalien-sdl-perl (U) Eugene V. Lyubimkin fbreader Georges Khaznadar gtkextra Giovanni Mascellani mandelbulber Guenter Geiger (Debian/GNU) gem (U) Hubert Chathi ufraw IOhannes m zmölnig gem (U) Jari Aalto jpegjudge Jonas Smedegaard squeak-vm (U) José L. Redrejo Rodríguez squeak-vm (U) Lennart Weller nvidia-texture-tools Loic Minier libquicktime (U) Markus Koschany freeorion (U) Markus Wanner flightgear (U) simgear (U) Matteo F. Vescovi libraw (U) Matthias Klose pillow Matthias Klose openjdk-6 (U) openjdk-7 (U) openjdk-8 (U) Maximiliano Curia libindi (U) OpenJDK Team openjdk-6 openjdk-7 openjdk-8 Ove Kaaven flightgear (U) simgear (U) Paul Brossier gem Petter Reinholdtsen libterralib (U) Pino Toscano libindi (U) Reinhard Tartler libquicktime (U) mpv (U) Robin Gareus harvid (U) Roland Stigge jasper Sergei Golovan wings3d (U) Simon McVittie ioquake3 (U) Teemu Ikonen openctm (U) Tobias Hansen allegro5 (U) aseprite (U) Torsten Werner openjdk-6 (U) Євгеній Мещеряков swi-prolog Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- 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/1411997061.2736076.172953677.7ac72...@webmail.messagingengine.com
Re: open-axiom is marked for autoremoval from testing
On Mon, 29 Sep 2014 15:54:37 +0400
Игорь Пашев wrote:
> Is it really a good idea to remove packages which FTBFS because of
> *internal compiler error*?
There's a comment and a link to the gcc upstream bug but the bug report
in Debian hasn't been tagged or cloned or reassigned to reflect this.
There is currently no way for the gcc maintainer to close this bug with
a gcc upload, no way for any automated check to know which package is
actually affected.
> Shouldn't GCC be removed instead? :-)
This would not appear to be an RC bug in gcc. As it apparently hasn't
been filed against gcc, I can't be sure what the gcc maintainer thinks
though.
In the absence of changes to the bug which would allow an automated
process to handle the actual issue, it would seem appropriate that the
automated removal blames the package, not the compiler. Therefore, to
fix the RC bug, work with the gcc maintainer to get it cloned,
reassigned, tagged etc. with an appropriate severity.
Independent of the compiler issue, your package FTBFS with the current
default compiler - either the package needs to be removed from testing
or the package needs a (temporary) patch to allow the build to complete.
BTW: there seems to be a different problem on armhf:
configure: error: in
`/«BUILDDIR»/open-axiom-1.5.0~svn3056+ds/build-tree': configure: error:
C preprocessor "/lib/cpp" fails sanity check See `config.log' for more
details dh_auto_configure: ../configure --build=arm-linux-gnueabihf
--prefix=/usr --includedir=${prefix}/include
--mandir=${prefix}/share/man --infodir=${prefix}/share/info
--sysconfdir=/etc --localstatedir=/var --disable-silent-rules
--libexecdir=${prefix}/lib/open-axiom --disable-maintainer-mode
--disable-dependency-tracking --with-lisp=sbcl --with-x --disable-gcl
returned exit code 1 make: *** [configure-stamp] Error 2
debian/rules:45: recipe for target 'configure-stamp' failed
https://buildd.debian.org/status/package.php?p=open-axiom&suite=unstable
So maybe the compiler error results from a bug elsewhere in the package
or is simply masking a bug elsewhere in the package. Either way, the
package does still have RC issues independent of the compiler. Fixing
those would be more useful than escalating to -devel when the
maintainer for the compiler hasn't even been asked what he thinks.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
Bug#763345: ITP: git-hub -- Git command line interface to GitHub
Package: wnpp Severity: wishlist Owner: Maximiliano Curia * Package name: git-hub Version : 0.7.2 Upstream Author : 2013, Sociomantic Labs GmbH * URL : https://github.com/sociomantic/git-hub * License : GPL-3+ Programming Lang: Python Description : Git command line interface to GitHub git hub is a simple command line interface to GitHub, enabling most useful GitHub tasks (like creating and listing pull request or issues) to be accessed directly through the Git command line. . Although probably the most outstanding feature (and the one that motivated the creation of this tool) is the pull rebase command, which is the rebasing version of the GitHub Merge (TM) button. This enables an easy workflow that doesn't involve thousands of merges which makes the repository history unreadable. . Another unique feature is the ability to transform an issue into a pull request by attaching commits to it (this is something offered by the GitHub API but not by the web interface). -- 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/20140929135512.30070.25240.report...@amadeus.maxy.com.ar
Bug#763355: ITP: node-yazl -- yet another zip library for Node.js
Package: wnpp Severity: wishlist Owner: Andrew Kelley X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-yazl Version : 2.0.1 Upstream Author : Josh Wolfe * URL : https://github.com/thejoshwolfe/yazl * License : Expat Programming Lang: JavaScript Description : yet another zip library - Node.js module yazl is a Node.js module which provides the ability to generate zip files. It uses async APIs to avoid blocking the JavaScript thread, avoids buffering entire files in RAM, and opens input files one at a time to avoid EMFILE errors. yazl supports adding files, buffers, and streams. The output is a stream. If all the files in the zip file are uncompressed, the final size is known before the stream starts. . Node.js is an event-based server-side JavaScript engine.
Bug#763364: ITP: node-yauzl -- yet another unzip library for Node.js
Package: wnpp Severity: wishlist Owner: Andrew Kelley X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-yauzl Version : 2.0.0 Upstream Author : Josh Wolfe * URL : https://github.com/thejoshwolfe/yauzl * License : Expat Programming Lang: JavaScript Description : yet another unzip library - Node.js module yauzl is a Node.js module which provides the ability to read from zip files. It follows the spec by reading the central directory for file metadata instead of scanning for local file headers which might be deleted. yauzl also keeps memory usage low by not attempting to buffer entire files in RAM at once. yauzl is designed to generate an error instead of crashing when encountering corrupted or malicious zip files and has a robust test suite to ensure this. . Node.js is an event-based server-side JavaScript engine.
Bug#763368: general: Bluetooth file transfer fails.
Package: general Severity: important Dear Maintainer, I can't transfer files via bluetooth with KDE. root@serkan-pc:/home/serkan# service bluetooth status bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled) Active: active (running) since Pzt 2014-09-29 19:24:35 EEST; 1h 34min ago Docs: man:bluetoothd(8) Main PID: 614 (bluetoothd) Status: "Running" CGroup: /system.slice/bluetooth.service └─614 /usr/lib/bluetooth/bluetoothd Eyl 29 19:24:27 serkan-pc systemd[1]: Starting Bluetooth service... Eyl 29 19:24:28 serkan-pc bluetoothd[614]: Bluetooth daemon 5.23 Eyl 29 19:24:35 serkan-pc systemd[1]: Started Bluetooth service. Eyl 29 19:24:35 serkan-pc bluetoothd[614]: Starting SDP server Eyl 29 19:24:36 serkan-pc bluetoothd[614]: Bluetooth management interface 1.6 initialized Eyl 29 19:24:36 serkan-pc bluetoothd[614]: Sap driver initialization failed. Eyl 29 19:24:36 serkan-pc bluetoothd[614]: sap-server: Operation not permitted (1) Eyl 29 19:27:31 serkan-pc bluetoothd[614]: Endpoint registered: sender=:1.37 path=/MediaEndpoint/A2DPSource Eyl 29 19:27:31 serkan-pc bluetoothd[614]: Endpoint registered: sender=:1.37 path=/MediaEndpoint/A2DPSink Eyl 29 20:36:39 serkan-pc systemd[1]: Started Bluetooth service. Eyl 29 20:41:40 serkan-pc bluetoothd[614]: Endpoint unregistered: sender=:1.37 path=/MediaEndpoint/A2DPSource Eyl 29 20:41:40 serkan-pc bluetoothd[614]: Endpoint unregistered: sender=:1.37 path=/MediaEndpoint/A2DPSink Eyl 29 20:41:42 serkan-pc bluetoothd[614]: Sap driver initialization failed. Eyl 29 20:41:42 serkan-pc bluetoothd[614]: sap-server: Operation not permitted (1) Eyl 29 20:41:42 serkan-pc bluetoothd[614]: Endpoint registered: sender=:1.37 path=/MediaEndpoint/A2DPSource Eyl 29 20:41:42 serkan-pc bluetoothd[614]: Endpoint registered: sender=:1.37 path=/MediaEndpoint/A2DPSink root@serkan-pc:/home/serkan# lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 003: ID 0a5c:2101 Broadcom Corp. BCM2045 Bluetooth -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=tr_TR.UTF-8, LC_CTYPE=tr_TR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20140929180830.14629.62836.reportbug@serkan-pc
Re: MBF: libjpeg-turbo transition started (if you depend on libjpeg8-dev please read)
Ondřej Surý wrote: [...] > I will be filling bug reports on packages explicitly depending on > libjpeg8-dev. [...] > Andreas Metzler >sdop [...] Fixed yesterday. ;-) BTW: What is the correct package to build-depend on - libjpeg62-dev or libjpeg-dev? cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- 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/jhkofb-48k@argenau.downhill.at.eu.org
Re: MBF: libjpeg-turbo transition started (if you depend on libjpeg8-dev please read)
On Mon, Sep 29, 2014 at 20:21:09 +0200, Andreas Metzler wrote: > BTW: What is the correct package to build-depend on - libjpeg62-dev or > libjpeg-dev? > libjpeg-dev, please. Cheers, Julien signature.asc Description: Digital signature
Re: Allow encfs into jessie?
On Mon, Sep 29, 2014 at 06:43:38AM +0200, Christian PERRIER wrote: > Quoting Eduard Bloch (e...@gmx.de): > > > Template: encfs/security-information > > Type: note > > _Description: Encfs Security Information > > Besides using an Evil Debconf Note (;-) ), is there a reason for > capitalizing every noun in the note title ? That style of title capitalization is very common in the United States (and Canada, it appears). It's less common in British English. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#763368: general: Bluetooth file transfer fails.
severity 763368 normal reassign 763368 bluetooth merge 763368 757292 thanks Hey, A short summary of the original filling: Kurt is running testing and using Broadcom Corp. BCM2045 Bluetooth. He is unable to transfer files via bluetooth with KDE. The following error appears in his logs: bluetoothd[614]: Sap driver initialization failed. bluetoothd[614]: sap-server: Operation not permitted (1) More information is available in his original filling at [1]. Regards, T. [1] https://bugs.debian.org/763368 signature.asc Description: OpenPGP digital signature
Bug#763368: general: Bluetooth file transfer fails.
Hey, Your bug seems to be a duplicate of bug #757292 [1]. Since the general pseudo-package [2] is not related in any way to bluetooth, I'm reassigning your bug to the correct package. I'm also merging it with #757292 so that both of them can be dealt at once. If you think that your problem is not related to #757292, feel free to unmerge it (see [3] for details on how to do it or simply send me an email and I'll do it or you). Thanks for your report! Regards, T. [1] https://bugs.debian.org/757292 [2] https://www.debian.org/Bugs/pseudo-packages [3] https://www.debian.org/Bugs/server-control#unmerge signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#763368: general: Bluetooth file transfer fails.
Processing commands for cont...@bugs.debian.org: > severity 763368 normal Bug #763368 [general] general: Bluetooth file transfer fails. Severity set to 'normal' from 'important' > reassign 763368 bluetooth Bug #763368 [general] general: Bluetooth file transfer fails. Bug reassigned from package 'general' to 'bluetooth'. Ignoring request to alter found versions of bug #763368 to the same values previously set Ignoring request to alter fixed versions of bug #763368 to the same values previously set > merge 763368 757292 Bug #763368 [bluetooth] general: Bluetooth file transfer fails. Bug #763368 [bluetooth] general: Bluetooth file transfer fails. Marked as found in versions bluez/5.21-2. Bug #757292 [bluetooth] [bluetooth] Error in Sap Merged 757292 763368 > thanks Stopping processing here. Please contact me if you need assistance. -- 757292: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757292 763368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763368 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.141203428216180.transcr...@bugs.debian.org
Bug#763209: general: laptop panel no longer powers off
tags 763209 - moreinfo reassign 763209 src:linux found 763209 linux-image-3.14-2-amd64 thanks Hey, I'm reassigning your bug to Debian Kernel Team (src:linux). Just on a sidenote - yes, xserver-xorg-core was updated on 22 September but then it was updated again on 28 September :) A short summary of the original filling: Allan is running testing. Since he upgraded kernel to linux-image-3.14-2-amd64, DPMS can no longer power the monitor off. Running 'xset dpms force off' doesn't work either. There are no visible errors in his dmesg output. More information is available in his original filling at [1]. Regards, T. [1] https://bugs.debian.org/763209 signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#763209: general: laptop panel no longer powers off
Processing commands for cont...@bugs.debian.org: > tags 763209 - moreinfo Bug #763209 [general] general: laptop panel no longer powers off Removed tag(s) moreinfo. > reassign 763209 src:linux Bug #763209 [general] general: laptop panel no longer powers off Bug reassigned from package 'general' to 'src:linux'. Ignoring request to alter found versions of bug #763209 to the same values previously set Ignoring request to alter fixed versions of bug #763209 to the same values previously set > found 763209 linux-image-3.14-2-amd64 Bug #763209 [src:linux] general: laptop panel no longer powers off The source 'linux' and version 'linux-image-3.14-2-amd64' do not appear to match any binary packages Marked as found in versions linux/linux-image-3.14-2-amd64. > thanks Stopping processing here. Please contact me if you need assistance. -- 763209: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763209 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.141203565723554.transcr...@bugs.debian.org
Bug#763416: ITP: xia -- Application to convert svg to html5 interactive pictures
Package: wnpp Severity: wishlist Owner: Francois Lafont * Package name: xia Version : 1.0~alpha7-2 Upstream Author : Pascal Fautrero * URL : http://images-actives.crdp-versailles.fr/beta/index_en.html * License : GPL-3.0+ Programming Lang: Python, JavaScript, html5 Description : Application to convert svg to html5 interactive pictures Source : http://mentors.debian.net/debian/pool/main/x/xia/ Dear Debian developpers, Xia is a software which converts svg files into full html5 interactive pictures. The building of the source package generates two binary packages: 1. "xia-converter" which is the software itself; 2. "xia" which is an Inkscape plugin and which enables to launch xia-converter directly inside Inkscape The documentation of Xia is available for downloading on this page: http://images-actives.crdp-versailles.fr/beta/index_en.html Sorry, at the present time there is a pdf documentation in french only but the english version is coming soon. However, in the page above, you can find also a 7-minutes "getting started" video in english. I would be very happy if the software could integrate the official Debian repositories. Obviously, in case this package did not exactly respect the Debian policy, I would accept with pleasure (and with great interest) any remarks which could help me correct my mistakes. Thank you in advance for your attention. Regards. François Lafont PS1: if you want, you can quickly test and install Xia on Wheezy or Jessie. You just need to launch these commands as root: wget -q "http://repository.crdp.ac-versailles.fr/crdp.gpg"; -O - | apt-key add - echo "deb http://repository.crdp.ac-versailles.fr/debian xia main" > /etc/apt/sources.list.d/xia.list apt-get update apt-get install xia PS2: you one can download the source package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/x/xia/xia_1.0~alpha7-2.dsc To access further information about this package, please visit the following URL: http://mentors.debian.net/package/xia -- 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/20140930025811.13335.83919.report...@flpc.athome.priv
Re: Allow encfs into jessie?
Quoting brian m. carlson (sand...@crustytoothpaste.net): > > Besides using an Evil Debconf Note (;-) ), is there a reason for > > capitalizing every noun in the note title ? > > That style of title capitalization is very common in the United States > (and Canada, it appears). It's less common in British English. ...but is actually nearly never used in existing debconf templates even though we mostly standardized on US English style when doing reviews in debian-l10n-english. signature.asc Description: Digital signature
Bug#763419: snapshot.debian.org: add an overlay for updates to Valid-Until, OpenPGP signatures
Package: snapshot.debian.org Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org On Sun, Sep 28, 2014 at 4:34 AM, Peter Palfrader wrote: > On Fri, 26 Sep 2014, Paul Wise wrote: > >> On Thu, Sep 25, 2014 at 11:21 PM, Christoph Anton Mitterer wrote: >> >> > Well I think snapshot is it's own construction site, isn't it? >> >> snapshot is a read-only (modulo cosmic rays and removal of >> non-redistributable things) historical record, files in it will not be >> modified to re-sign with newer keys nor to update Valid-Until. > > That doesn't mean one couldn't consider providing an overlay of sorts, > that provides re-signed release files if the original ones verified. > Under a different path obviously. We could look at patches if they > somehow appeared. Excellent idea, documenting it in the bug tracker. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Mass "do not use bash" bug filing
On gum, 2014-09-26 at 11:28 +0100, Adam D. Barratt wrote:
> Hi,
>
> I noticed that you appear to be filing several RC bugs against packages
> which use /bin/bash shebangs in their scripts.
>
> These bugs are *not* RC. The packages themselves do not have security
> issues. The interpreter they choose to use {may,does}, but that is not a
> bug in grep, xz-utils or gzip.
>
> You should also know by now that mass bug filing without prior
> discussion is discouraged, regardless of the severity.
>
> Finally, the rationale presented for the bugs - "against the debian
> policy to use /bin/sh if possible" - is bogus. Debian Policy makes no
> such requirement or even suggestion. It spells out what functionality
> scripts using /bin/sh may rely on, it in no way implies that other
> shells may not be used if appropriate shebangs and dependencies are in
> place.
>
> Regards,
>
> Adam
>
>
I don't know what you're doing. Since I use bash I'm scared about this
news. But doesn't the Unix specification explain how to reset terminals?
Have you ever read this sentence: Read the fucking manual.
If you have the manual could you send me a link to it? It's a kind of
already seen something like this years ago.
kind regards
Joël
--
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/1412060131.3467.22.camel@helix
