Bug#276276: qemu: mouse not working
On Thu, Nov 24, 2005 at 05:40:53PM +0100, Gunter Ohrner wrote: > Am Donnerstag, 24. November 2005 00:38 schrieb Elrond: > > Can you see, if > > http://lilly.csoft.net/~jeffryj/cgi-bin/moin.cgi/FrequentlyAskedQuesti > >ons#head-402b0eec8e9c44cf4f819ecdd7db37be8153c20c fixes your problem? > > > > (basicly, put "SDL_VIDEO_X11_DGAMOUSE=0" in your > > environment) > > Right, that fixes it for me as well. > > Maybe this should somehow be pointed at more prominently... > > Should I close this bug or keep it open as an reminder to add a pointert > to this FAQ somewhere? Let it open, so we can see, what we'll do next. First step is probably to add a ref to that FAQ to README.Debian. Elrond p.s.: I haven't found a tag for "workarround known". ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276276: qemu: mouse not working
On Sat, Nov 26, 2005 at 04:07:50PM -0800, Ryan Lovett wrote: [...] > I'm no longer in a position to test this, unfortunately, so you needn't > wait for me to test. > > Ryan Should we set the owner of the bug to Gunter Ohrner then? Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276276: qemu: mouse not working
package qemu submitter 276276 Gunter Ohrner <[EMAIL PROTECTED]> thanks On Mon, Nov 28, 2005 at 10:04:26PM +0100, Gunter Ohrner wrote: > ! 276276 [EMAIL PROTECTED] > thanks > > Curious if this works. ;) There are two tricks: a) send the mail to control@ (done in this mail via Bcc, so replies don't annoy the control processor) b) use the "submitter" command, see above. Using "package" is just good style and helps avoid errors. [...] > Making me the bug's owner (instead of reporter) seems not correct to me [...] You're right. > However I should be able to perform tests with qemu on AMD64 and i386 in > the forseeable future. [...] Nice to hear. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344601: libgnomevfs2-common: Extract optional modules
Package: libgnomevfs2-common Version: 2.10.1-5 Severity: wishlist Hi, Can you try to extract modules, that have costly dependencies into an extra package, that is Recommended by this package? Simple example: /usr/lib/gnome-vfs-2.0/modules/libsmb.so seems to implement the smb vfs layer and uses libsmbclient. I don't need smb in my gnome based apps. And I don't want libsmbclient on my system. Recommends would be the right thing, as it means "You really should install it. If you don't install it, expect missing features." Here's a quick list of modules, that I'd move into such a package: libcdda.so libsmb.so libvfs-test.so (whatever that one is good for?) Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276276: qemu: mouse not working
package qemu tags 276276 +confirmed retitle 276276 [hw/mouse] (SDL-problem?) mouse not working thanks Can you see, if http://lilly.csoft.net/~jeffryj/cgi-bin/moin.cgi/FrequentlyAskedQuestions#head-402b0eec8e9c44cf4f819ecdd7db37be8153c20c fixes your problem? (basicly, put "SDL_VIDEO_X11_DGAMOUSE=0" in your environment) At least, that helped me. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313123: allow mounting local directories as qemu hard disks
On Sat, Jun 11, 2005 at 07:23:49PM -0400, Michael Gilbert wrote: > Package: qemu > Version: 0.6.1+20050407-1 > Severity: wishlist > > it would be very useful to be able to mount local directories within the > qemu guest OS (rather than only being able to mount local disk images as > qemu hard disks or using samba). for example, > > qemu -hda /home/tux/os.img -mounthdb /home/tux/files How should this be done? The guest OS can only work with stuff, that looks like "real hardware" to it. It needs something, that looks like a "real harddisk". With a "real partition table" and a "real filesystem". Of course you can create a full fs image from the specified directory, put it in /tmp and let qemu work against that. qemu-make-debian-root is doing something like that for a debian install. For windows, you'd need to create a vfat image (as ntfs support is still an issue). Any changes to the temporary image would be lost after shutting down qemu. Unless you unpack the image after shutdown of qemu and put it back in the real fs. All of the above sounds like a big script, that should be put around qemu. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313104: qemu: allow mouse over mode along with standard mouse capture
On Sat, Jun 11, 2005 at 03:18:32PM -0400, Michael Gilbert wrote: > Package: qemu > Version: 0.6.1+20050407-1 > Severity: wishlist > > presently, if you move the mouse over the qemu window, the cursor within the > qemu emulated OS does not move. when you click, you take over the qemu > cursor, > and the X cursor is hidden (i call this mouse capture mode). it would be > very useful if the qemu cursor could perhaps track the X cursor as it > moves over the window. when clicking in this mode, the qemu OS should > be made aware of the click; however, the X cursor should not be captured > (i call this mouse over mode). vmware (commercial emulator) has this mode. BUT it only works, if you install special software inside the guest os! Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310587: rageircd uses too much CPU
Package: rageircd
Version: 2.0.0-3
Hi,
A completely idle rageircd (no clients connected) raises
the number of context switches on my smaller box from about
50switches/sec to about 250switches/sec.
Running strace scrolls with this:
gettimeofday({1116938814, 401190}, NULL) = 0
select(7, [4 5 6], [], NULL, {0, 1000}) = 0 (Timeout)
gettimeofday({1116938814, 406871}, NULL) = 0
select(7, [4 5 6], [], NULL, {0, 1000}) = 0 (Timeout)
gettimeofday({1116938814, 416843}, NULL) = 0
select(7, [4 5 6], [], NULL, {0, 1000}) = 0 (Timeout)
Maybe the --with-engine option, which was mentioned in the
other bugreport, helps getting this better?
Elrond
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304804: saods9: Crash at "Horizontal Cut Graph"
Package: saods9 Version: 3.0.3-1 Thanks for packaging ds9, gave me an easy chance of testing it. I converted a color .jpeg to .fits using gimp. Then loaded it into ds9. Finally selected "Analysis -> Horizontal Cut Graph" Sometimes I have to move the mouse over the picture to "enforece" the crash, but ultimately is ends with: % ds9 alloc: invalid block: 0x8df2820: 0 0 0 zsh: abort ds9 I doubt this is expected behaviour. I guess, this is an upstream problem, but I leave that decision to the maintainer. Elrond ii libtk-img 1.3-13 Extended image format support for Tcl/Tk ii blt2.4z-3 the BLT extension library for Tcl/Tk - run-t ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries and Timezone ii libgcc13.4.1-4sarge1 GCC support library ii libstdc++5 3.3.4-11 The GNU Standard C++ Library v3 ii tcl8.4 8.4.5-1Tcl (the Tool Command Language) v8.4 - run-t ri tk8.4 8.4.6-1Tk toolkit for Tcl and X11, v8.4 - run-time ii zlib1g 1.2.1-3compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305357: sasl2-bin: Provide sample-{server,client} for testing
Package: sasl2-bin Version: 2.1.19-1.5 Severity: minor Hi, Many docs in sasl2 (for example testing.txt and gssapi.html) refer to sample-server and sample-client. Building it from libsasl2-dev isn't straight forward either. (it requires a non-shipped config.h) Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305900: gimp: Warnings with Histogram
On Fri, Apr 22, 2005 at 10:41:23PM -0400, Ari Pollak wrote: > I cannot reproduce this using the instructions you have provided. I asked three people (ranging from normal user to DD) to try this on their machines. It "worked" for all of them (they got the warning). - Make sure to start gimp from inside the xterm and don't close the xterm - Maybe you have some theme/render engines installed? They might mitigate the problem? (guessing from the error, which has some "default" and "render" in it) Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306625: pdftk: Suggest xpdf-utils
Package: pdftk Version: 1.12-3 Severity: wishlist Hi, xpdf-utils really helps in dealing with pdf files. What I often do: extract a page using pdftk, then using pdfimages to get the pictures from that single page. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306624: xpdf-utils: Suggest pdftk
Package: xpdf-utils Version: 3.00-13 Severity: wishlist Hi, pdftk really helps in dealing with pdf files. What I often do: extract a page using pdftk, then using pdfimages to get the pictures from that single page. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308494: qemu: New upstream version available (0.70)
package qemu tags 308494 + confirmed merge 308494 308459 thanks Thanks for re-reporting this. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309999: rageircd: Looks for ircd.motd in /usr at SIGHUP
Package: rageircd Version: 2.0.0-3 Hi. When I send rageircd a SIGHUP, it looks for ircd.motd in /usr. Easily tested by putting a unique text file /usr/ircd.motd, doing /etc/init.d/reagircd reload, and reconnecting or using /motd. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309919: bacula-sd: Wrong dependency of libpq3
On Fri, May 20, 2005 at 03:35:38PM +0200, Nicolas Raspail wrote: > Package: bacula-sd > Version: 1.36.3-1 > Severity: normal > > Hi, > > as you can see in the informations below, bacula-sd depends on libpq3, > and I wonder why :) Maybe an old forgotten dependency lying around or a > secret feature (tell me which one please :D) ? It's bcopy, that's linked to postgres: # ldd /usr/sbin/bcopy libpq.so.3 => /usr/lib/libpq.so.3 (0x4001f000) I don't know, why it's linked to it. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#251924: heimdal-kdc: heimdal kinit fails with heimdal server
Hi, Is anything happening regarding this bug? Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308459: qemu: new upstream version 0.7.0 available
package qemu
tags 308459 +confirmed
thanks
On Tue, May 10, 2005 at 01:00:02PM +0200, Szymon Janc wrote:
[...]
> new version 0.7.0 is available, please update debian package.
[...]
Yeah, we know, it's on our list.
Elrond
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#264192: RFP: greylist-milter -- grey listing filter for sendmail
package wnpp tags 264192 +patch thanks milter-greylist 2.0 has just been released. Attached is very simplistic debian packaging for it. Some notes about it: - I am NOT going to act as the maintainer for it. (I don't have the time.) - This needs testing - Fix up the "copyright" file - The init script probably has problems stopping the milter on 2.4 kernels, see bugs.debian.org/278198 - To repeat: I'm not going to maintain it. If you have improvements for the packaging, don't send them to me, you'd better send them to this bug. Elrond milter-greylist_2.0-0.diff.gz Description: Binary data
Bug#318509: monotone statically links to libsqlite3
On Tue, Jul 19, 2005 at 12:13:05AM +0200, Tomas Fasth wrote: [...] > I want monotone to use the shared libraries of sqlite, popt, lua, > etc as distributed with Debian. Good! Until then, I'd suggest, you let the security team know, that your package has local versions due to above mentioned reasoning. So they can decide, what to do, if and when those packages have issues. Some time after filing the bug, I finally found out some details of the local changes, and I have some possible ideas to get them done in other ways: * sqlite: As I understand, there's only an addition. - It might be put in an extra .c, so that it's only used in monotone. - The code using it might be rewritten to use a loop with sqlite3_prepare (It's not faster than sqlite3_exec, as that uses the former.) * lua: As I understand it, the changes are only to remove a function for the interpreter, that basicly does system() (as in libc). So one can't accidentally pass filenames with wildcards/backticks into the shell. - Instead, one could just register a failing function by that name into the interpreter. * popt: I don't know. Of course, the sqlite changes should be proposed to upstream for inclusion. > But it is not currently possible > according to upstream. I should have mentioned this in more detail > in the changelog, so thanks for pointing this out. Yep, that would have been helpful. Maybe better put this into a README.Debian or TODO.Debian. (while there: /usr/share/doc/monotone/README currently does not give any vital information to the user, really) Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301515: maxima: Rebuild with libreadline5
Package: maxima Version: 5.9.1-9 Severity: wishlist testing has libreadline5 for a while now. Can you try to rebuild maxima using it? It should be as simple as putting "libreadline5-dev | libreadline-dev" in the Build-Depends and purging libreadline4-dev from your system. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301516: maxima grouches at Ctrl-D
Package: maxima Version: 5.9.1-9 Starting maxima interactively and pressing Ctrl-D (EOF) twice gives this: $ maxima Maxima restarted. (%i1) (^D,^D) in getOneChar, fd=0,fp=0x401ffee0 Maxima encountered a Lisp error: Error in CATCH [or a callee]: Unexpected end of #. Automatically continuing. To reenable the Lisp debugger set *debugger-hook* to nil. (%i1) I doubt, this is really expected behaviour. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301515: maxima: Rebuild with libreadline5
On Wed, Mar 30, 2005 at 09:20:54PM -0500, Camm Maguire wrote: > Greetings, and thanks for your report! Are there benefits to be had > here? Incompatibilities? benefits: Giving libreadline4 a chance of not being needed installed. ;) Incompatibilities: I haven't heard of any. My personal packages were as flawless to migrate as purging libreadline4-dev and installing libreadline5-dev. All of that makes up for "Severity: wishlist". (as in: "no problems will exist, if not caring about the bug."). > Still, a good idea. Commited to CVS and errata page -- will Stupid question: Where is the errata page? > incorporate into next Debian upload. Should we mark the bug "pending" then? > Take care, Thanks for the nice maxima package and your quick response! Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301516: maxima grouches at Ctrl-D
On Wed, Mar 30, 2005 at 09:13:48PM -0500, Camm Maguire wrote: > Greetings, and thanks for your report! This bug is specific to GCL in > readline mode. Okay, should this bug then be reassigned to gcl? > An immediate workaround is to turn readline off, for > example, via :lisp (si::readline-off) in maxima. A fix has been *g* I can live with typing "quit();". ;) > posted to the 2.6.6 errata page found at > http://www.gnu.org/software/gcl. It will take some considerable time Ahh, thanks! > to rebuild GCL, maxima, acl2, and axiom on all Debian machines, so I > will delay this pending any more serious issues that may arise in the > future. You probably should take the sarge release timeline (I don't know the current status of my head) in consideration. > Take care, Thanks, go on! Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302848: qemu-make-debian-root requires dependency on debootstrap
On Sun, Apr 03, 2005 at 01:05:15PM +0200, Jonas Smedegaard wrote: [...] > qemu-make-debian-root is installed into /usr/sbin . > > Please either have the package recommend debootstrap or move that script Would Suggests be okay? As it's not a core feature of the debian qemu package (yet). So we don't "loose major functionality", as Recommends usually means. > out as an example script below /usr/share/doc/qemu/examples/ . > > If hacking the script is expected (as it seems from README.Debian) then > perhaps putting it as an example script is the best option. Hmm. As I don't know anything about the script (not my area), I don't want to mess that "massively" with it. I will happily add the Suggest to the control file though. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302866: qemu: FTBFS in sarge: /usr/bin/ld: cannot find -lartsc
On Sun, Apr 03, 2005 at 03:52:50PM +0200, Kurt Roeckx wrote: > Package: qemu > Version: 0.6.1-1 > Severity: serious > Tags: sarge Check bug #298532. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302866: qemu: FTBFS in sarge: /usr/bin/ld: cannot find -lartsc
On Sun, Apr 03, 2005 at 04:46:33PM +0200, Kurt Roeckx wrote: > On Sun, Apr 03, 2005 at 04:27:33PM +0200, Elrond wrote: > > > > Check bug #298532. > > Oh, I didn't notice that one. I should probably have reopened > that one and tagged it sarge instead. Will you close this bug, when arts has propagated to testing? And: Should this bug be moved over to that package? Please do as needed. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305900: 305900: Fixed in testing
package libgtk2.0-0 tags 305900 - fixed-in-experimental + sarge thanks This bug has been fixed in testing. I can confirm that. I've retagged it "sarge", as it still affects sarge. I leave the decision of closing it to the maintainers. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309999: #309999: rageircd only finds MOTD file after SIGHUP has been received
package rageircd tags 30 + fixed-in-experimental thanks 2.0.0.2.0.1pre2-2 from experimental solves this issue. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317675: Support security-freeze in hdparm.conf
Package: hdparm Version: 6.1-2 Severity: wishlist Hi, The subject says it all, but: It would really be nice to be able to use --security-freeze from hdparm.conf instead of having to do it in my own init scripts / use "command_line" in hdparm.conf. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318509: monotone statically links to libsqlite3
Package: monotone Version: 0.20-1 Severity: serious Hi, monotone on i386 has sqlite3 statically linked into the binary. And I can't find any hints in either the upstream changelog nor debian's changelog for a good reason to do this. Normally, this is a NO-NO due to support/security issues. (The security team would need to update your package, if sqlite3 has a problem). It also looks like monotone has lua in it, can't tell for sure now. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303507: Fixed bug in svn
package qemu tags 303507 + pending thanks Guilherme de S. Pastore applied submitted patch to SVN repos. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296114: Updated copyright file
Hi everybody, Paul Wise's mail is down. He sent me the updated copyright file via irc/http. I changed the formatting slightly for readability, he was okay with my edits. So it's available to everybody, I've appended it to this mail. Elrond This package was debianized by Elrond <[EMAIL PROTECTED]> and Mario Holbe <[EMAIL PROTECTED]>. It was downloaded from http://cgiirc.sourceforge.net/download/ Upstream Author: David Leadbeater Copyright: For CGI:IRC Copyright 2002-2004 David Leadbeater <[EMAIL PROTECTED]> For modules/IRC/UniqueHash.pm Copyright 1999 Jay F. Kominek <[EMAIL PROTECTED]> Licence: For CGI:IRC This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. On Debian GNU/Linux systems, the complete text of the GNU General Public License version 2 can be found in `/usr/share/common-licenses'. For modules/IRC/UniqueHash.pm Use, modification and distribution is allowed without limitation, warranty, or liability of any kind, with the single exception that you may not distribute a derived work of this work under a license more restrictive than this and at the same time describe that work as "free software" in its documentation, source code, or license. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Bug#334458: sysctl patch doesn't byte-swap name values
On Mon, Oct 17, 2005 at 06:25:53PM -0700, Josh Triplett wrote: > Package: qemu > Version: 0.7.0-4 > Tags: patch > > The patch to handle the kernel version sysctl correctly runs tswapl on > all the arguments to sysctl, but does not run tswapl on the contents of > the name array. The attached patch fixes this problem. > > - Josh Triplett > Do you happen to know, if this is fixed upstream in 0.7.2? Thanks in advance for your answer. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296114: Updated copyright file
On Tue, Oct 18, 2005 at 02:11:09AM +0800, Paul Wise wrote: [...] > > Should we ask debian-legal@ for that? > > Elrond thought that it wouldn't be an issue, because UniqueHash.pm is > just distributed alongside cgiirc (under a different licence). Even if we assume, that both licenses are incompatible (we have evidence for that, I think): I have asked on #d-d, and here are the most relevant answers I got: 12:35 Elrond: not if they aren't linked together, no. 12:35 Elrond: do they link to each other? ... 12:37 Elrond: it's widely agreed that the interfaces of perl modules are abstract enough to not pose license-compatibility issues If anyone still feels like contacting debian-legal, they can, of course. > Anyways, even if it is not an issue for debian, it would be good to have > it fixed, so I've filed a bug upstream: > http://cvs.cgiirc.org/tktview?tn=73,1 Good idea! Any point in tracking this whole license issue in an independant debian bug? Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302035: Bug#51869: New package splitting scheme for teTeX in Debian
On Fri, Oct 21, 2005 at 04:28:25PM +0200, Frank Küster wrote: [...] > 3. Some possible splitting schemes >=== [...] > 3.2 tetex-base > > For tetex-base, the additional splitting-off of a type1-fonts-x11 > package can be added to both following splitting schemes: Do we talk about TrueType or PS Type1 fonts here? Both of which might be useful to other systems, including X11, ghostscript, openoffice, etc. For truetype, the current naming scheme seems to be "ttf-*", so that could be something like "ttf-cm" or so. No idea. For Type1, I can only see a very few t1-* packages. The next interesting question here is: How much of the fonts is needed by the typical debian-build? Will it need all the .mf sources? Will it be happy with T1 fonts? Is it worthwhile to split off all the unneeded fonts into tetex-fonts? > In any case, I suggest that tetex-base should create a tetex-complete > package that installs everything (maybe except the X11 fonts). Sounds good to me! Elrond
Bug#100332: Bug#51869: New package splitting scheme for teTeX in Debian
On Mon, Oct 24, 2005 at 01:32:08PM +0200, Frank Küster wrote: [...] > > This might be an important question in a sensible split. > > For example the big modularized xlibs was done in parts to > > help migrating from xfree to xorg. > > Please note that we do not plan to "transition" from tetex to texlive; > as far as we can tell both will continue to (co)exist upstream, and the > same we want to accomplish for Debian. This was just as a "more modular design can sometimes help" heads up. > But I am not familiar to the > problems that the X people tried to solve with the modularized xlibs wrt > this transition; I haven't followed it too deeply either. But the generic idea I can see: Have small packages with clear functionality, that then can be easily replaced by a "from scratch" new package from the to-be-transitioned-to package. > can you elaborate on how this might affect TeX? It depends on how tetex and texlive want to coexist. If they're not intended to coexist at all, this does not affect TeX at all. Each does its own job and decides on how to rule the world, and conflicts with the other. Job done. The other extreme: if they should coexist and be interchangeable and stuff, it might for example make sense to have bunches of virtual packages, which either of the both can provide. Like tex-ctan-PACKAGE or tex-xdvi, etc... So that other packages can depend on the feature they need. Say tetex-beamer needs pstricks, it would then depend on tex-ctan-pstricks, which would be provided by texlive-pstricks and the tetex-*, that is going to have it. So I think, the question is: What is the intended audience of tetex vs. texlive? One part of this answer has already been given: For build-dependencies, tetex should be the choice. But what about the rest? Elrond
Bug#330464: procps: init-script: please be more verbose if $VERBOSE
package procps tags 330464 + patch thanks On Wed, Sep 28, 2005 at 09:54:55AM +0200, Mario 'BitKoenig' Holbe wrote: [...] > I personally think it's really helpful to see which kernel parameters > are changed during boot. Therefor, please use -q only if $VERBOSE=no. As the original author of the init script, I have to say, that I agree with this. If people want a silent boot, they are free to set VERBOSE=no. On the other hand, I see no point in having extra config support for this in /etc/default/procps or the like. Just my two dirhem. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332521: Split xbase-clients
Package: xbase-clients Version: 6.8.2.dfsg.1-8 Severity: wishlist Hi, xbase-clients by now has an installed size of 4,5MB. Quite a lot for a "base" package. One, that nearly every X workstation has installed. It has a lot of specific add-ons, that not everyone needs. I've tried to create some categories of tools in xbase-clients: - diagnostics / debugging: xev, xfd, xrandr, xtrap*, xlsatoms, dpsexec, dpsinfo, xprop, xdpyinfo, xwininfo, glxinfo, xvinfo, appres, editres, listres, viewres, Xmark, x11perf, and x11perfcomp - management tools: xvidtune, atobm, bmtoa, fstobdf, - desktop utilities: (see Bug#199675) beforelight, oclock, xclock, xmag, xload, xeyes, xconsole, xbiff, - demos xgc, dga, ico, glxgears, texteroids, xlogo, - basic tools: xset, xsetroot, xrefresh, xkill, xauth, startx, xinit. (for xauth see Bug#151613) - discouraged tools both xorg*config tools The intention of this list is to serve as a starting point. There are surely hundreds of things, that need to be changed in it, and it misses some tools from xbase-clients, that I do not use nor do I have an idea, what they _really_ could do. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326406: qemu: snapshot mode should prompt for commit on APM/ACPI power off
package qemu tag 326406 +upstream thanks Tagging upstream, as this isn't an issue in debian specifically. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317145: qemu: FTBFS on sparc
package qemu severity 317145 minor thanks Hi, "alpha sparc arm s390" are on the "Architecture" list so we can easily see, if qemu builds on those hosts _at all_. These architectures are listed as "testing" on the qemu web site. We have tried to find people who test a build for us, but finally, it was just way simpler to let the build farm do the trick for us. All of that said, this is more or less an expected problem, so I'm downgrading the bug to "minor". I was considering setting "wontfix", but that's too harsh. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322344: Use qvm86 instead
package qemu retitle 322344 enable qvm86/kqemu support thanks On Tue, Sep 13, 2005 at 05:53:02PM +0100, Paul Brook wrote: > qvm86 support would be more appropriate. qvm86 is a GPL replacement for kqemu. > > http://www.qvm86.org/ > > Paul Hi Paul, I took a quick look at your qvm86 source tarball (daily snapshot from dad-answers). It's currently intended to be bundled directly into qemu. Is it possible to unbundle it somewhat? The idea is: - Only kqemu.h will be needed to build qemu with qvm86 support. - qemu-qvm86-miniminal.patch does only as few mods to the qemu tree as necessary. This probably means basicly checking for kqemu.h existing, defining ENABLE_KQEMU in config.h, and changing device names. - The qvm86 tree itself can be used standalone to build the kernel module. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295019: New qemu: -user-net does not work?
Hi, Stuart Prescott: If you are more interested in this bug, can you discuss with James Stone, if you can take this bug over? I've already asked on 28 May 2005, if you could retest this problem with the current qemu. Could you please retest with 0.7.0-4 from testing? I've tagged this bug "moreinfo". If we don't hear anything from you within about two or three months, we'll close the bug, as we can't do anything without your help. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333423: linphonec doesn't like Ctrl-D
Package: linphone-nox Version: 1.1.0-2 Install linphone-nox, start "linphonec", press Ctrl-D (the usual EOF key to get out of interactive shell-like programms) gives weird characters. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333428: slapd.schema.conf?
Package: slapd Version: 2.2.26-4 Severity: wishlist What about moving all the "include /etc/ldap/schema/*" into thwir own /etc/ldap/slapd.schema.conf? This would make it far easier for add-on packages (like gforge or Samba-TNG) to add their own schemas straight into the (already installed) slapd configuration. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333423: linphonec doesn't like Ctrl-D
On Tue, Oct 11, 2005 at 11:40:38PM +0200, Samuel Mimram wrote: > % linphonec > Ready. > ' : Cannot understand this. ^ | Your terminal ate part of the weird characters. Run it in "script". I've attached my run from inside script to this mail. (The "ESC [ ." and "^M" are terminal control charachters.) > It would be nice if it exited the program though (may I downgrade this > bug to wishlist?). Well, I presume, there's some memory corruption going on, or so. So I would not like wishlist. I could accept minor. Elrond [m[m[m[JRivendell:~% [Klinphonec Ready. linphonec> 'ºøÿ¿Æy Õii ' : Cannot understand this. linphonec> quit linphonec> [m[m[m[JRivendell:~% [K Script done on Wed Oct 12 12:29:01 2005
Bug#334071: missing '-' and '=' keycodes for sendkey command
On Sat, Oct 15, 2005 at 02:18:32PM +0200, Robert Millan wrote: > Package: qemu > Version: 0.7.0-4+kbsd > Severity: normal > Tags: patch > > Keycodes '-' and '=' for sendkey command are missing, so one cannot do > combinations like: [...] Do you happen to know, if 0.7.2 is also affected or this has been fixed-upstream? (so that we can just fix this bug by upgrading) Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330024: gnuplot: buffer overflow in debian patch
Package: gnuplot Version: 4.0.0-2 Severity: important There's a buffer overflow in one part of the patch: +++ gnuplot-4.0.0/src/term.c ... + char *binname = "/gnuplot_x11"; + char *fullname; ... + fullname = (char*)malloc(sizeof(X11_DRIVER_DIR) + sizeof(binname) + 1); + strcat(fullname, X11_DRIVER_DIR); + strcat(fullname, binname); sizeof(binname) will return only 4. (the size of the poiner) So strcat() will write over unallocated memory. Please either use strlen() for binname and X11_DRIVER_DIR, or just asprintf(). I am not sure, if this can be exploited and if it could, if it is a security issue. Elrond p.s.: Can you please remove changelog.latin1 from the debian .diff.gz? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323184: valgrind does not work for simplest programs
Hi, This problem has been partly fixed in 3.0.1-1. Partly means, that a) programs now mostly run under valgrind b) valgrind now throws loads of warnings against me (probably some suppressions are needed, maybe some fixes to libc6 are still needed, whatever) c) some programs SEGV after running. Simple hello world programs just generated bunches of warnings and then execute. More complex thingies like /bin/ls or /usr/bin/id generate more warnings, then print their output, more warnings and finally report a SIGSEGV. Current environment: valgrind: 3.0.1-1 libc6: 2.3.5-6 kernel: 2.4.29 Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323184: valgrind does not work for simplest programs
Package: valgrind
Version: 3.0.0-1
Severity: serious
Hi,
starting the new valgrind on simplest programs (like one
printf("Hello %s\n", "world");) just goes this:
==1366== Process terminating with default action of signal 4 (SIGILL)
==1366== Illegal operand at address 0xB0039D4C
==1366==at 0x1B8E4C20: (within /lib/ld-2.3.2.so)
Same for /bin/ls from coreutils from stable.
valgrind 2.4.0 works happily on this box.
System characteristics:
libc6: 2.3.2.ds1-21 or 2.3.5-3
coreutils: 5.2.1-2
gcc: 3.3.5-8
kernel: 2.4.29
Elrond
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397074: stun setup fails with "No primary IP given. Exiting."
package stun severity 397074 serious thanks Hi, This bug affected me yesterday. After short discussion on #d-d, we concluded, that this is an RC bug. As it looks, the server should not be started without configuration, so the suggestion is not to try to start it in postinst, and ignoring failures to stop in prerm. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305357: closed by Fabian Fagerholm <[EMAIL PROTECTED]> (Bug#190658: fixed in cyrus-sasl-2.1 2.1.22-0~pre01)
package libsasl2-dev sasl2-bin cyrus-sasl-2.1-bin
unmerge 305357
reassign 305357 cyrus-sasl-2.1-bin
thanks
(let's see, if unmerging is enough to reopen)
On Wed, Oct 25, 2006 at 07:06:38AM -0700, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #305357: sasl2-bin: Provide sample-{server,client} for testing,
[...]
> - Added necessary config.h and Makefile to build samples (Closes:
> #190658)
[...]
Shipping config.h and Makefile are a good thing, no question.
But for a normal admin, sample-server and sample-client are
really good debugging tools, and they should be shipped in
sasl2-bin (or cyrus-sasl-2.1-bin), because the normal admin
does not want to build them just to use them.
Elrond
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289202: CAN-2004-1235: uselib() privilege escalation
Hi, Is this bug really pending? That is: Is it really fixed in svn? Or did it just inherit the pending due to the clone? Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#283166: Assigning back to qemu
package bochsbios qemu reassign 283166 qemu thanks Well, the idea is, that these three bugs are on qemu, while the fourth bug is on bochsbios directly. So that the three are "symptom"-bugs. Moving back, so they're in the right package (and people can actually see them and read the solution at the end. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288997: Should use versioned depends to ensure consistency
tags 288997 + pending thanks Okay, fixed it in svn. I used the following versions: vgabios: 0.4c+20041014-1 bochsbios: 2.1.1+20041109-3 Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290643: dcc-milter init.d script?
Package: dcc-milter Version: 1.2.66-1 Severity: wishlist Hi, The dcc-client package starts dccifd fine (despite me needing it, but that's _my_ problem). But dcc-milter does not come with a startup cscript at all. Not even /etc/default/dcc-milter does exist, which is referenced from /usr/share/doc/dcc-milter/README.Debian. Is everyone using dcc from spamassassin anyway and nobody uses the milter at all? Anyway, you might want to look at clamav-milter fof a mature start/stop-script for milters (it's not as easy as it seems at the start). Maybe it's possible to share some common code nd put it in the libmilter0 package or so. Just some ideas. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290669: qemu package doesn't have dhelp entries
package qemu tags 290669 + confirmed thanks On Sun, Jan 16, 2005 at 12:11:47AM +0300, Serge Matveev wrote: [...] > Qemu package doesn't install eny dhelp entries, but habe two html > documentation files - "Documentstion" and "QEMU Internals" [...] I guess you talk about some file for qemu in /usr/share/doc-base/ ? If so, are you willing to write two of those and submit them? I or some one else can then add them to the repos and you'll have your entries with the next qemu version in debian. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290713: qemu-mkcow script missing
package qemu severity 290713 minor tags 290713 + confirmed upstream fixed-upstream thanks On Sun, Jan 16, 2005 at 12:15:32PM +0800, Enrico Zini wrote: > Package: qemu > Version: 0.6.1-1 > Severity: normal > > Hello, > > thanks for packaging qemu! > > The /usr/share/doc/qemu/qemu-doc.html manual, in the section "3.6.3 > Copy On Write disk images", mentions the script qemu-mkcow. However, You might want to look at the updated docs at the upstream website: http://fabrice.bellard.free.fr/qemu/qemu-doc.html We already have an open bug for updating our shipped docs at http://bugs.debian.org/286931 > that script is not included in the qemu package, although a manpage is > provided for it: > > $ dlocate qemu-mkcow > qemu: /usr/share/man/man1/qemu-mkcow.1.gz We probably should remove the manpage before the next debian upload, but I don't know, if we really want to take the trouble or just hope for the next upstream release. > There is a qemu-img command that seems to do the same things but with a > different syntax, though. Right, that's the one, that should be used now. qemu is changing rapidly, so things really change. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290669: qemu package doesn't have dhelp entries
On Sun, Jan 16, 2005 at 03:57:14AM +0300, Serge Matveev wrote: [...] > > If so, are you willing to write two of those and submit > > them? > > Something like this. My english isn't good, so please check it. something like this, starts to look good. First fixup the paths, they look a bit wrong. Then you need to add a "Document: " at the beginning, I believe. Finally try putting them in your /usr/share/doc-base and run "install-docs -i /usr/share/doc-base/qemu" and "install-docs -i /usr/share/doc-base/qemu-tech" and see, if the entries pop up in dhelp and if you like them. [...] > Title: QEMU System emulator > Author: Fabrice Bellard > Abstract: The HTML documentation of the QEMU System emulator. This is the Users' Manual for QEMU. QEMU is a system emulator. > Section: System > > Format: HTML > Index: /usr/share/doc/qemu-doc.html > Files: /usr/share/doc/qemu-doc.html Those look wrong to me. > Title: QEMU Internals > Author: Fabrice Bellard > Abstract: QEMU System emulator Internals > Section: System > > Format: HTML > Index: /usr/share/doc/qemu-tech.html > Files: /usr/share/doc/qemu-tech.html Those look wrong too. If you have fixed and tried them, send them again. :) (I don't have doc-base nor dhelp, so I need your help in trying this. And you're the one wanting the entries. ;-) ) Oh, and please keep [EMAIL PROTECTED] in replies (you can even only send there, I'll get it anyway.) Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290669: qemu package doesn't have dhelp entries
package qemu tags 290669 + pending thanks On Sun, Jan 16, 2005 at 11:15:15PM +0300, Serge Matveev wrote: > On Sun, Jan 16, 2005 at 08:19:33PM +0100, Elrond wrote: > > > > If you have fixed and tried them, send them again. :) > > (I don't have doc-base nor dhelp, so I need your help in > > trying this. And you're the one wanting the entries. ;-) ) > > Sorry for all of this. Nothing to be sorry for, really. > This is "new version". Corrected and checked. I Thanks for it. I've added it as is to the pkg-qemu repository, including a changelog entry refering to you. It's going to be in the next upload and that will finally close the bug. > think, must be only one file - only for user manual. Well, if someone wants an entry for the tech docs, they'll have to send it in. Very simple. ;) Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296337: Possible inclusion of kqemu (qemu accelerator for x86 on x86) in Debian ?
On Sun, Mar 06, 2005 at 11:36:09AM -0300, Guilherme de S. Pastore wrote: [...] > But anyway, the problem here is another one. I myself am totally > against non-free software, and am really sorry for Debian still > distributing this kind of thing, and having it on its servers. I personally have to say, that I'm okay with non-free existing. Some software is "free enough" for some people, but not free enough for the DFSG. No, I don't want a discussion on non-free or not. I don't have the time for it, and I'm not fully informed on it either. I just wanted to say, that the current Debian QEMU Team has diverse opinions on _this_ particular point. > Apparently, the other members of the Debian QEMU Team think just > the same. Consequently, it's not a matter of not being able to > put kqemu on non-free: it's us who don't have any interest in > maintaining non-free software in Debian. Basicly, that's the point. I'm not going to put my free time into non-free software. Not to mention, that qemu as is makes enough trouble to the debian qemu team. > That means if any person is willing and is able to maintain kqemu in > non-free, they're free to do it. Right. Interested parties can try to file a RFP (Request For Package or so) bug on the wnpp pseudo package. Check www.debian.org for "work needing and prospective packages". I don't have an URL handy. > I was even going to write I would be > against its inclusion in the team repositories, when I remembered we > use Alioth structure, which doesn't allow hosting of non-free stuff. > =) A downloader/installer framework as such could be free. But I'd highly recommend hosting it in a distinct space, read: Not on the normal debian qemu space. > In the hope of having been clear enough, I think yes. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296114: cgiirc: new upstream version available
package cgiirc tags 296114 + confirmed thanks On Sun, Feb 20, 2005 at 07:26:31PM +0800, pabs wrote: > Package: cgiirc > Version: 0.5.4-6 > Severity: wishlist > > Upstream released 0.5.6! Changes include: Basicly we know about it. And when we have more time, we will try to update the package. (my "debian time" was consumed by fixing qemu problems. ;) ) The hardest part of the update is to find out, which of our patches are already included in upstream, and which patches need to be updated to still apply to current upstream. When we know that, we're much closer to updating the packages, I think. Unless upstream change something dramatically. > This release fixes more UTF-8 bugs and adds a /charset command to make > it easier to change character sets (see the FAQ for details), the list > of non-supported browsers was also updated. Yes, charsets are a problem, but seemingly not a killer one. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416677: python-numpy: array indexing memory corruption
Package: python-numpy Version: 1:1.0.1-1 Severity: important Hi, The following should be obvious enough: bug-thingies$ cat crash2.py from numpy import array sel = array([False,True]) p1 = array([11.]) p1[sel] = p1 bug-thingies$ python crash2.py *** glibc detected *** free(): invalid next size (fast): 0x081f6938 *** Aborted Note: Yes, I'm fully aware of the fact, that the above python program is bad/wrong code! Nevertheless, it should not crash like this. It really should give an exception. I have set the severity to important, as this bug could have security implications. At least, with the following assumptions: 1) The arrays could have been read from (untrusted) data files. Note: They only contain data, nothing more, one should not assume, that this data comes from a trusted source! 2) The glibc issue really means some memory corruption, so if the above (malicous) data would be constructed with more care, an exploit might be possible. I leave tagging as RC/security to the maintainers or other interested parties. Elrond -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Versions of packages python-numpy depends on: ii atlas3-base [liblapack.so.3 3.6.0-20.6 Automatically Tuned Linear Algebra ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libg2c0 1:3.4.6-5Runtime library for GNU Fortran 77 ii libgcc1 1:4.1.1-21 GCC support library ii python 2.4.4-2 An interactive high-level object-o ii python-central 0.5.12 register and build utility for Pyt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408942: matplotlib and numpy in testing
Package: python-matplotlib Version: 0.87.7-0.1 Severity: serious matplotlib in testing defaults to numpy. But it does not work with the numpy in testing: >>> import pylab RuntimeError: module compiled against version 109 of C-API but this version of numpy is 102 I have marked this bug as RC, because the package does not work in its default installation, and fixing it isn't even simple for the average user/admin. They have to find the config and switch from numpy to numarray/numeric. The solutions to this problem include: - Unfreeze numpy - Change the default, and document, that matplotlib and numpy-on-testing is b0rked. - Rebuild on testing Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408944: matplotlib: Missing Tk dependency
Package: python-matplotlib Version: 0.87.7-0.1 Severity: important matplotlib now defaults to TkAgg. But there is no dependency on python-tk. I mark this as important, as it makes the package unusable by default, but it's easy to fix by the average admin (apt-get install python-tk). Others might consider it RC. YMMV. What to do: - Put "python-tk |" in front of the dependency on python-gd. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408955: matplotlib: rescaling in logscale breaks
Package: python-matplotlib
Version: 0.87.7-0.1
Setting logscale on an axes breaks rescaling sometimes.
Here's a simple example script:
import pylab
f = pylab.figure()
ax = f.gca()
ax.plot([1, 10, 100], [1,2,3])
ax.set_xscale('log')
ax.cla()
ax.plot([1, 10, 100], [1,2,3])
pylab.show()
This gives:
Traceback (most recent call last):
File "resize.py", line 9, in ?
ax.plot([1, 10, 100], [1,2,3])
File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line
2131, in plot
self.autoscale_view(scalex=scalex, scaley=scaley)
File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 985,
in autoscale_view
self.set_xlim(XL)
File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line
1220, in set_xlim
raise ValueError('Cannot set nonpositive limits with log transform')
ValueError: Cannot set nonpositive limits with log transform
Elrond
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383189: xaralx: New upstream and some ideas
Package: xaralx Version: 0.6r1442-4 Severity: wishlist As you probably already noticed, 0.7 has been released. While you're at packaging it, I have some ideas for your consideration: 1) Quote from the announcement: * Product rename: Now that the product is increasingly close in functionality to the original Xara Xtreme, we're renaming the product Xara Xtreme for Linux or (Linux Edition). So you might consider renaming the debian package, letting the new one "Replaces: xaralx (<<0.7)" and making xaralx a dummy package, that depends on the new one. I have not yet checked, what the autopackage calls itself now. 2) Split out examples into an "Architecture: all" package. This should reduce the main binary package by a few MB hopefully. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383189: xaralx: New upstream and some ideas
package xaralx retitle 383189 xaralx: Rename package to follow upstream thanks On Tue, Aug 15, 2006 at 02:10:02PM +, Joachim Breitner wrote: > Hi Elrond, > > couldn't you have filed it three hours earlier, then I could have > included the bugnumber in the changelog, as closed :-) Huh. I forgot to check NEW. ;) > 0.7 has been uploaded today and is in the NEW queue, because of the > extra binary packages, including examples. > > Note that I'll do the name change as soon as xaralx is completely free > software, together with the move to main. So the extra packages are currently named xaralx-*? That means, that the upcoming name change involves even more packages. Do you think, that this is a good idea? (meaning more transitional packages, etc.) > You can either close this bug, if you think this is therefore obsolete, > or retitle it to remind me of the renaming... I've retitled it. Thanks for your quick response, Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394529: xorg.conf(5): Please mention APM/ACPI in NoPM option
Package: xserver-xorg-core Version: 2:1.1.1-10 Severity: wishlist xorg.conf(5) is long, being able to search for keywords is important. In my case I was looking on how to disable xorg's usage of APM. (Disabling it makes X more reliable on my box). So please add something like "On Linux this disables APM and ACPI." to the >>Option "NoPM" "boolean"<< stanza. I admit, searching for "power" would also have helped me. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#733905: easy-rsa: More secure defaults
Package: easy-rsa Version: 2.2.0-1 Hi, bettercrypto.org suggests a bunch of changes to make easy-rsa create better certificates. The most important changes are included in the new 2.2.2 release. So, could you at least upgrade to the next upstream release? Relative to 2.2.2, they suggest a default keylength of 4096 instead of 2048 and shorter key-expiration. Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733905: closed by Alberto Gonzalez Iniesta (Bug#733905: fixed in easy-rsa 2.2.2-1)
Thanks for this quick response! On Tue, Jan 07, 2014 at 12:36:25 +, Debian Bug Tracking System wrote: [...] > easy-rsa (2.2.2-1) unstable; urgency=low > . >* New upstream release. (Closes: #733905) [...] >* Add suggestions to improve defaults' security to README.Debian. [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734999: [security] https-everywhere might allow spoofing
Package: xul-ext-https-everywhere
Version: 3.4.1-1~bpo70+1
Tags: wheezy jessie
According to
https://trac.torproject.org/projects/tor/ticket/5477
when using https-everywhere on firefox before 20 might
allow spoofing of some domains.
I am not sure, whether current https-everywhere versions
have any workarounds for earlier firefox versions. If they
actually have, please excuse this bugreport!
This bug mainly affects stable/bpo and testing, as unstable
has firefox>=20.
Elrond
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691770: freeradius: Helping package 2.2.2
Hi, 2.2.2 has been released by now on the 2.x branch. It contains some fixes/improvements that we likely need on our systems (we're investigating some issues currently). Please let me know, if you need help packaging 2.2.2. I am prepared to offer some of my work time to help get this packaged. Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692888: glib-networking-common: Please rename
Package: glib-networking-common Version: 2.32.3-1 Hi, As glib-networking-common only contains locales files, it should be renamed into glib-networking-locales. Also as a second step, it would be great if glib-networking would only Recommends glib-networking-common. As locales are a good thing, but one can use packages without their locales. Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688911: icinga-common: check_apt for localhost
Package: icinga-common
Version: 1.7.1-3~bpo60+1
Severity: wishlist
Hi,
I think, it would be a nice idea to have check_apt in the
default shipped localhost_icinga.cfg. It's quite a simple
test for a machine. People can still disable it anyway.
ckeck_apt is in nagios-plugins-basic, which is installed
anyway. So no extra dependency either.
I would suggest the following entry, because there is no
point in running check_apt every 5 minutes:
define service{
use generic-service
host_name localhost
service_description Updates Available
check_command check_apt
check_interval 720 # 12 hours
max_check_attempts 2 # Retry once
retry_interval 60# an hour later
}
Cheers
Elrond
p.s.: Thanks for the backport package!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688911: icinga-common: check_apt for localhost
Hi, On Thu, Sep 27, 2012 at 06:53:24 +0200, Alexander Wirt wrote: [...] > In fact the plugin is useless unless you setup automatic updates of the apt > index (see /etc/cron.daily/apt). So just adding this can leads to false > results. Therefore I don't think its a good idea to add this by default. Yep, right! It would lead to false sense of security alone, yeah. What about adding the entry commented out and the notice to create /etc/apt/apt.conf.d/02periodic with some useful content before enabling this service check? > Alex Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694049: maxima-share: Do not depend on tex-common
Package: maxima-share Version: 5.27.0-3 Hi, maxima-share currently depends on tex-common. Basicly, there are no .sty files or alike in it. There are a few .tex files in it. But they're in maxima's directories, where the usuel tex-infrastructure wont find them. So no need to run mktexlsr or whatever. Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683080: [pkg-bacula-devel] Bug#683080: Bug#683080: Bug#683080: Bug#683080: bacula-fd: Please build with libcap-dev
Hi, On Sat, Aug 11, 2012 at 09:37:31 +0400, Alexander Golovko wrote: > Yes, this option look what we need. > At least, bacula-fd binary, builded with this option, don't linked to > libcap. Well, linked to libcap, so that people can use -k. Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671886:
Dear Maintainer, I think this bug is related to https://bugbase.adobe.com/index.cfm?event=bug&id=3161034 See also bug report for Ubuntu on Launchpad: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/968759 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682966: bconsole: Please provide better default config
Package: bacula-console Version: 5.2.6+dfsg-1~bpo60+1 Severity: wishlist Hi, For most other bacula packages you substitute `hostname` into the generated config files. bconsole.conf contains localhost-dir instead. Can you please use a consistent way of doing it? Could you also please substiture the correct dir password into the generated bconsole.conf? Having mostly working defaults would be great. Thanks Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683080: bacula-fd: Please build with libcap-dev
Package: bacula-fd Version: 5.2.6+dfsg-1~bpo60+1 Severity: wishlist Hi, Could you allow the "-k" option to bacula-fd? Starting with -k gives the following error: "Keep readall caps not implemented this OS or missing libraries." My current guess: bacula-fd is not linked to the libcap library. After a quick look at bacula's configure.in and src/lib/priv.c this seems to really be the case. So probably just having libcap-dev installed while building bacula should solve this. Thanks Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682966: [pkg-bacula-devel] Bug#682966: bconsole: Please provide better default config
Hi, On Mon, Jul 30, 2012 at 14:14:22 +0100, Bart Swedrowski wrote: > Hi, [...] > This change has now been incorporated into master branch. It should > be making its way to backports starting with backport of 5.2.6+dfsg-3 > release (not next one but the one after next one). > > Thanks for reporting that, > Regards, Bart Great! Thanks! Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683080: [pkg-bacula-devel] Bug#683080: bacula-fd: Please build with libcap-dev
Hi, On Mon, Jul 30, 2012 at 14:31:15 +0100, Bart Swedrowski wrote: [...] > By default, Debian installation of bacula-fd runs it as root user so > having that option is pointless in current state of things. However, > the benefits of it are quite obvious and can potentially be useful for > quite a wide range of users in my opinion. Exactly right. I only want the ability for admins to use the -k option. I don't want this option enabled by default. But the current build does not allow the -k option, because bacula-fd is not linked with libcap-dev. So my only request is: Please build with libcap-dev. Admins can then change /etc/default/bacula-fd on their own. I *think* this should be as easy as adding libcap-dev to Build-Depends: in the config? Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684203: bacula-dir.conf log in /var/lib
Package: bacula-common Version: 5.2.6+dfsg-1~bpo60+1 Severity: minor Hi, I hope it is okay for nitpicking on the default config. I just realize those bits while improving my complete new setup. Anyway, the default config has the log in /var/lib: /usr/share/bacula-common/defconfig# grep -w log bacula-dir.conf append = "/var/lib/bacula/log" = all, !skipped append = "/var/lib/bacula/log" = all, !skipped /var/log/bacula is completely unused on my system. Wether there should be some default log rotation, is an added bonus question. I personally would vote for it. Thanks Elrond p.s.: Thanks for the great backport package! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683080: [pkg-bacula-devel] Bug#683080: Bug#683080: bacula-fd: Please build with libcap-dev
On Mon, Aug 06, 2012 at 10:52:31 +0400, Alexander Golovko wrote: [...] > Yes, but enabling this feature cause all bacula binaries and libraries > link with libcap2. So, i need some more investigation for add > capabilities support In a perfect world it would only add this dependency to bacula-fd. Possibly an upstream wishlist bug? That said, libcap2 is on many systems anyway and probably wouldn't hurt on the director or a storage server a lot. Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683080: [pkg-bacula-devel] Bug#683080: Bug#683080: bacula-fd: Please build with libcap-dev
On Fri, Aug 03, 2012 at 16:12:58 +0200, Luca Capello wrote: [...] > I would go even further: if I read it correctly, this should improves > security, so I was wondering if it would be better to have it by > default... This is quite attractive, I can understand that. Really I would love to see this. BUT ... ... it will stop nice restores. You have to restore to /tmp and all the restored files will be owned by nobody and not the original owner. I don't know if people are ready for this. In a first step, I would suggest to add the capability support, so that users can play with this feature and learn. In a second step, I would suggest making it easy for users to enable this feature (maybe commented version in /etc/default/bacula-fd?) Or maybe add a debconf knob directly? So that people can enable it easily while installing bacula-fd on all of their client machines? Just my personal thoughts. Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684203: [pkg-bacula-devel] Bug#684203: bacula-dir.conf log in /var/lib
Hi, On Tue, Aug 07, 2012 at 23:20:43 +0400, Alexander Golovko wrote: > tags 684203 + upstream > -- > > Hi! > > this is a upstream bug 1911 > http://bugs.bacula.org/view.php?id=1911 Ohh, great. > Fix is not included into git master branch yet, but i plan to include it > before next upload to sid. > It is possible, that in backports will be fixed not nearest > uploaded version, but next after nearest. There is no rush for me. I fixed it locally. Just a nice fix for future installations. > thank you for bugreport! Thanks for the fast reaction! Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683080: [pkg-bacula-devel] Bug#683080: bacula-fd: build with libcap-dev, don't enable it by default
Hi, On Fri, Aug 10, 2012 at 15:40:18 +0200, Luca Capello wrote: > Hi there! > > Re-adding Enlrond to the Cc:, I am sorry if you are subscribed to > pkg-bacula-devel@ and thus get this twice. I am not on pkg-bacula-devel. So thanks for re-adding me! [...] > >> In a first step, I would suggest to add the capability > >> support, so that users can play with this feature and > >> learn. > >> > >> In a second step, I would suggest making it easy for users > >> to enable this feature (maybe commented version in > >> /etc/default/bacula-fd?) > >> Or maybe add a debconf knob directly? So that people can > >> enable it easily while installing bacula-fd on all of their > >> client machines? > > Good options, even if I now fails to see who would like to use such an > option if it renders restoring harder. Well, there are various scenarios, where people would like to try -k and see how it works for them. I could describe some of them, if needed. That's why I suggested the first step: Give people the option to try -k. If this actually turns out to be a great thing, a debconf knob can be added later. > Thx, bye, > Gismo / Luca Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683080: [pkg-bacula-devel] Bug#683080: Bug#683080: Bug#683080: bacula-fd: Please build with libcap-dev
Hi, On Fri, Aug 10, 2012 at 15:55:39 +0200, Luca Capello wrote: [...] > > In a perfect world it would only add this dependency to > > bacula-fd. > > Possibly an upstream wishlist bug? > > IMHO this is not a wishlist bug, we have plenty of such unneeded linking > in Bacula, see: > > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646730#31> What's about the -Wl,--as-needed? That should help, I'd guess? > > That said, libcap2 is on many systems anyway and probably > > wouldn't hurt on the director or a storage server a lot. > > libcap2 is a dependency for ntp, not essential (standard), but still > IMHO highly recommended in a backup infrastructure (you want all your > machines to be synchronized WRT time). And its Installed-Size: is only > 55k on sid, so adding it *where it is needed* is not a problem. ACK. Cheers Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665881: [wheezy] module ath5k is blocking wlan-card
According to this thread [1], these two patches [2][3] should fix the issue. Can you backport to Wheezy kernel? Cheers [1] https://bbs.archlinux.org/viewtopic.php?id=139270 [2] http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=62e2c102cc1d2600381410c089ca9a37359577d2 [3] http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=5c17ddc4a047c59638c7eb8537aa887a1ddb9b0b -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709297: nagios-plugins-basic/mail.cfg/check_smtp: starttls
Package: nagios-plugins-basic
Version: 1.4.16-1
Severity: wishlist
Tags: patch
Hi,
could you add the following to
/etc/nagios-plugins/config/mail.cfg?
I think, it's a reasonable setting:
- People running an smtp server with login want starttls
- I think the 30 days for warning are a good compromise. If
it takes a few weeks to buy a new cert, that seems okay.
Feel free to lower to 21,5.
define command {
command_namecheck_smtp_starttls
command_line/usr/lib/nagios/plugins/check_smtp -H '$HOSTADDRESS$'
--starttls -D 30,10
}
I leave it to you, if you want to add an additional version
for doing the same thing on port 587 (submission).
Cheers
Elrond
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#642453: pidgin-data: Please split locales
Package: pidgin-data Version: 2.7.3-1+squeeze1 Severity: wishlist Hi, pidgin-data is quite large. 22 MB of its 26 MB are locales. Other packages have also already started to split out the locales and only Recommend them. So could you please split the /usr/share/locale/ part of pidgin-data into a new pidgin-locales package and let pidgin-data "Recommends: pidgin-locales"? Thanks Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#642458: libgstfarsight: Please only recommend gstreamer*bad,good
Package: libgstfarsight0.10-0 Version: 0.0.20-2 Severity: wishlist Hi, libgstfarsight0.10-0 is often installed as a dependency of libpurple0 (pidgin and friends). Not everybody wants/uses the full feature set of libgstfarsight0.10-0. See bugs.debian.org/550918 as an example. That said, I would suggest to * As a minimum: Change the Depends on gstreamer0.10-plugins-bad to a Recommends. gstreamer*bad is named *bad for a reason. So only recommending this seems very reasonable. * Better: Change both gstreamer0.10-plugins-good and -bad to Recommends. I have tested this. It does not break most of the functionality of libpurple0. Note: Recommends means "You REALLY should install this. If you don't do it, expect missing functionality" which seems appropiate here? Thanks for your considerations Elrond -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#822792: marked as pending
Hi, I think, the main "include apps.d/*.conf" is missing? Cheers Elrond On Thu, Nov 10, 2016 at 07:27:53 +, Michael Lustfield wrote: > tag 822792 pending > thanks > > Hello, > > Bug #822792 reported by you has been fixed in the Git repository. You can > see the changelog below, and you can check the diff of the fix at: > > http://git.debian.org/?p=collab-maint/nginx.git;a=commitdiff;h=c87b640
Bug#822792: your mail
Hi,
On Wed, Nov 09, 2016 at 18:47:15 -0600, Michael Lustfield wrote:
[...]
> "Example: /etc/nginx/conf.d/pkg_drupal8.conf"
>
> In this case, I'd say go ahead and provide /etc/nginx/conf.d/pkg_php-fpm.conf
> which would include "upstream _provider_php { ... }". This shouldn't be a
> problem unless someone tries to install multiple "php providers."
>
> I'd like to get something like _provider_php available via php-fpm as well as
> uwsgi-plugin-php.
Okay, so if an admin only wants to handle local .php files
on the default server they have to:
1. Install php-fpm, which then would hopefully bring
/etc/nginx/conf.d/pkg_php-fpm.conf
2. Create /etc/nginx/apps.d/local_php.conf
containing a global .php -> _provider_php entry
Did I get that right?
> Doing it this way would reduce security, but I'm thinking it's to a very
> negligible degree and not very concerned.
Could you elaborate on the security issues?
> > 2. Do we have recommended naming for files added by the
> >local admin to apps.d?
>
> We could suggest custom_.conf.
local_.conf?
Cheers
Elrond
Bug#826145: letsencrypt.sh: Ship lighttpd module?
Package: letsencrypt.sh Version: 0.1.0-3 Severity: wishlist Hi, could you consider to provide the attached file as /etc/lighttpd/conf-available/10-letsencrypt.sh-challenge.conf You might leave activating it to the admin. But having the file already in place might make the admin's live easier. If you want to, you could add something like this to README.Debian: """ Letting lighttpd serve the ACME challenges can be accomplished by enabling the letsencrypt.sh-challenge module on most setups: lighty-enable-mod letsencrypt.sh-challenge """ I don't think, it's needed to put this in its own package like the -apache2 one. It's just a file you ship, that wont hurt anyone. Cheers Elrond alias.url += ( "/.well-known/acme-challenge" => "/var/lib/letsencrypt.sh/acme-challenges" )
Bug#826145: letsencrypt.sh: Ship lighttpd module?
Hi, On Thu, Jun 02, 2016 at 19:57:23 +, Mattia Rizzolo wrote: > On Thu, Jun 02, 2016 at 06:25:48PM +0200, Elrond wrote: > > could you consider to provide the attached file as > > /etc/lighttpd/conf-available/10-letsencrypt.sh-challenge.conf > > Yes! we were waiting for somebody to provide such file :) Cool! > > You might leave activating it to the admin. But having the > > file already in place might make the admin's live easier. > [..] > > I don't think, it's needed to put this in its own package > > like the -apache2 one. > > the apache2 one activates itself when installing, and I find that a > feature. I think, both views are possible. For nginx (I *might* provide the snippet in an upcoming wishlist bug) the case is ever harder: The admin needs to add a "include ..." by hand. > > It's just a file you ship, that wont > > hurt anyone. > > and I find shipping unused/useless files in /etc sad. /etc is already > bloated enouhg. Well, they are there to "enhance" another package, namely lighttpd. Most packages having an "Enhances:" tag ship stuff that only gets used, if the appropiate enhanced package is installed. > Is there some thing like dh-apache2 to enable/deal with that conf, etc? Sadly, there is not. BUT: javascript-common:postinst,prerm,postrm have snippets for lighttpd to do what you want! > > alias.url += ( > > "/.well-known/acme-challenge" => > > "/var/lib/letsencrypt.sh/acme-challenges" > > ) > > I'm not a lighttpd guy, is this apache2 conf snippet needed/wanted here > too? > > > Options FollowSymlinks > Options -Indexes > AllowOverride None > Require all granted > I *think* most of those should be the default. I will check that and let you know. That said, I wonder, whether FollowSymlinks is needed at all? /var/lib/letsencrypt.sh/acme-challenges should be a normal directory and the created files in there are files, not symlinks? Cheers Elrond
Bug#827028: openssl: Consider adding Multi-Arch: foreign
Package: openssl Version: 1.0.2h-1 Severity: wishlist Hi, It looks like openssl offers an architecture independent (process/cli/network level) interface to its users. Could you consider setting it to Multi-Arch: foreign? It's usually a matter of adding one line to debian/control. This would hopefully improve install options for different architectures. Like for example using the x32 variant of the package on a mixed amd64/x32 system. Cheers Elrond
Bug#826145: letsencrypt.sh: Ship lighttpd module?
Hi,
On Fri, Jun 10, 2016 at 19:58:55 +, Mattia Rizzolo wrote:
> On Fri, Jun 10, 2016 at 01:31:29PM +0200, Elrond wrote:
> > On Thu, Jun 02, 2016 at 19:57:23 +, Mattia Rizzolo wrote:
> > > On Thu, Jun 02, 2016 at 06:25:48PM +0200, Elrond wrote:
> > For nginx (I *might* provide the snippet in an upcoming
> > wishlist bug) the case is ever harder: The admin needs to
> > add a "include ..." by hand.
>
> I don't even know what you're talking about here :)
> I always only limited myself to apache2 ^^
The current configuration scheme of nginx is mostly manual.
That is: The admin has to edit (or replace) config files,
always.
What we can do: Provide a config snippet (for
letsencrypt.sh) that the admin can reference in his/her
manually edited config file.
There currently is no way to auto-activate that snippet.
I have filed a debian bug to create a directory for
snippets that are auto-activated in the default virtual
host. #822792
> > > Is there some thing like dh-apache2 to enable/deal with that conf, etc?
> >
> > Sadly, there is not.
> >
> > BUT:
> >
> > javascript-common:postinst,prerm,postrm have snippets for
> > lighttpd to do what you want!
>
> Yeah, why not ^^
> Even if I quite hate having manually placed mainter scripts...
>
> > I *think* most of those should be the default.
> > I will check that and let you know.
>
> thanks.
dir-listings are disabled by default.
symlinks are enabled by default.
That said, it's probably better to enforce things, just in
case.
I have attached a new version of the config snippet.
Note: I have renamed it from 10-* to 50-*, so that it gets
loaded much later and has a good chance of overriding most
things.
> > That said, I wonder, whether FollowSymlinks is needed at
> > all? /var/lib/letsencrypt.sh/acme-challenges should be a
> > normal directory and the created files in there are files,
> > not symlinks?
>
> you can never know. The sysadmin my had removed /var/lib/letsencrypt.sh
> and placed it as a symlink towards something, I want to support such a
> setup.
Good point.
Cheers
Elrond
alias.url += (
"/.well-known/acme-challenge" =>
"/var/lib/letsencrypt.sh/acme-challenges"
)
$HTTP["url"] =~ "^/.well-known/acme-challenge" {
server.dir-listing = "disable"
server.follow-symlink = "enable"
}
Bug#827371: letsencrypt.sh: Use hook.d folder?
Package: letsencrypt.sh Version: 0.1.0-3 Severity: wishlist Hi, I am starting to test hook scripts to deploy the certificates into appropiate places. One idea I got while doing that: Have a hook.d folder with scripts that get all executed. Plan: - Add the attached script to /etc/letsencrypt.sh - Add HOOK="/etc/letsencrypt.sh/run-hookd.sh" to the main config or a conf.d/00-debian.sh. - Create a /etc/letsencrypt.sh/hook.d - I am not entirely sure about the options to run-parts. What do you think? Cheers Elrond run-hookd.sh Description: Bourne shell script
