Bug#403434: mantis: [INTL:fr] French debconf templates translation
Hi Christian, Christian Perrier wrote: > Package: mantis > Version: N/A > Severity: wishlist > Tags: patch l10n > > Please find attached the french debconf templates update, proofread by the > debian-l10n-french mailing list contributors. thanks for the updated .po File. It will be included in the next upload, which is expected to happen soon. Best Regards Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309238: ITP: password-gorilla -- A cross-platform Password Manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 retitle 309238 ITP: password-gorilla -- A cross-platform Password Manager owner 309238 [EMAIL PROTECTED] Hi, the package sounds interesting and therefore I'm willing to package it. I will start with the work on it in a short. Best Regards Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFhSPxTKIzE6LY9r8RAnPAAJ9r91JG4grDpa5W0FqoYSC7KLp4ywCeN0Jw fHSPp8OKvav92uTK9IGfE70= =Hie8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403580: Hello, maintainer of mantis~
Hi, first to note: I have opened up a bugreport for this issue at bugs.debian.org. So please CC every answer to [EMAIL PROTECTED], as I do, so that others can get up-to-date information about this issue, too. 김진욱 Jinwook Kim wrote: > I tried to reinstall mantis. But I just get some error msg like this > > migraing old settings into dbconfig-common: done > cat: /etc/mailname: No such file or directory > dpkg: error processing mantis (--configure): I have checked this and this is (seems to be) a bug in the configuration scripts of the packages. In fact i did not check if this file exists and handle the situation gracefully if it doesn't. I will fix this with the next upload which will be in a few days, together with updated translations. > In my opinion 'mantis package' need more dependency or '/etc/mailname' > requirement. Is that right? To get your package running for now, you will have to do a touch /etc/mailname just for it to exist (it doesn't matter if it is empty, cause it is only used to suggest you an administrator email address), so that maintainer script will not fail. After that run: dpkg-reconfigure mantis It should finish installation then. Please test that to see if my assumption about the bug is write in your case. > sorry that my short english. Not that bad. I'm not a native speaker as well, therefore my english isn't the best neither. Best Regards Patrick signature.asc Description: OpenPGP digital signature
Bug#401844: Package smstools should provide a debconf configuration
Package: smstools Version: 3.0-1 Tags: pending Severity: wishlist The current smstools package does not provide the user with an ability to configure package during installation. Instead a default configuration is installed, that may not match a majority of use cases. This behavior can (but doesn't always do) break functionality unless user creates/modifies smsd.conf himself. Therefore a debconf-based configuration should be provided which enables the user to configure basic aspects via debconf that do enable it to run smsd after installation. This feature is work-in-progress and is almost finished. It will be included in another upload if the main-maintainer approves it. Best Regard Patrick Schönfeld signature.asc Description: OpenPGP digital signature
Bug#401996: init script fails to stop smstools under some conditions
Package: smstools Version: 3.0-1 Tags: pending Severity: normal The init script in the current version of smstools fails to stop smstools under some conditions. That is because of some peculiarities, the smsd has, which need to be handled. This problem was reported by the upstream author, who suggested to use his sms3 script instead of the debian init script. But this script will not work for us, therefore a new init script should an will be implemented *based* on the sms3 script the upstream author provides in the next version of the smstools package. signature.asc Description: OpenPGP digital signature
Bug#401996: Severity upgraded to serious: Possible data-loss
After posting the bug the upstream author contacted me and we were in talk about the init script. We came to conclusion, that the script might produce a possible data loss (e.g. SMS sent or received while stopping the daemon *could* be lost!)! Therefore i upgraded the severity of this package and fixed it for the next upload. signature.asc Description: OpenPGP digital signature
Bug#292639: smstools: smsd segfaults on amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, i have build a new version, which reached unstable a few days ago. I have did a limited testing on amd64 and did not have any problem. Maybe you could try current unstable version and tell me if you still have the same problems. If so, then i will try to reproduce it. But as the smsd has been changed and improved slightly, hopefully the problem will disappear. Best Regards Patrick Schönfeld -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZft4TKIzE6LY9r8RAo7CAJ9TF0b6JuDh/JVDzFBLGbLHYE/99QCfYQg4 pfao/IqehKpsAC6RSCWwyRY= =OiBJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#169114: Package in preparation!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as the new co-maintainer of smstools i wanted to drop a note about this bug: In the current unstable version of smstools its not yet packaged. But the new upstream author prepared a beta for me, which i will test carefully and as soon as possible. We wanna have a stable version with this new feature added, so it may take some days more until we both reach a new stable version, which will close this issue. Best Regards Patrick Schönfeld -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZfqMTKIzE6LY9r8RAmY1AKCBVGagq52hAuzcyFdkmenSlsf3ogCfbbJY 22ZydcLrz8PC20ttgp/Et8o= =Ldpt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400120: Current state of a new mantis package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi people interested in mantis, i've adopted the mantis package and want to tell people, who are interested in a new version, the current state of things. Package is in preparation. It's already packaged at ~ 80%. ToDo: A bit about upgrading the database tables (which have been slightly changed) and about creating databases via dbconfig-common. I will hopefully have the package ready this weekend. Best Regards Patrick Schönfeld -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFZqqQTKIzE6LY9r8RAnIeAKCGecd2X9gKSJd5i5y3E3KjxBfWHACfRiJb mO9cEjSo4t6g313RP5xJeJM= =+mgU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385163: Fixed in current version
Version: 1.0.6+dfsg-1 In the new package version 1.0.6+dfsg-1 several things has been totally rewritten. So the build scripts. They should not contain any bashisms anymore. I just forgot to close it in my changelog. Best Regards Patrick Schönfeld signature.asc Description: OpenPGP digital signature
Bug#284551: mantis: php files don't execute
Hi, in my opinion this is not an issue with the mantis package, but maybe (if not solved already) a problem with the apache versions prior to apache2. Anyways i can really recommend to use the apache2 branch and there you don't have such problems. For me this is not solvable with mantis. I therefore tag it as 'wontfix' Best Regards Patrick signature.asc Description: OpenPGP digital signature
Bug#414796: Default apache.conf doesn't work
Frank Lichtenheld schrieb: >>> though (or change the require calls for these libraries). >> Are you sure there is a bug? In a default debian installation my >> packages are running without any problems. And they do use the systems >> libphp-phpmailer and libphp-adodb as the mantis package does not install >> the packages adodb and phpmailer files with it. > > Ok, the latter path (/usr/share) was from the sarge version of > libphp-adodb and is indeed not needed in etch/sid. > > The former path (/usr/share/php) seems indeed not to be needed > with php5, but with php4 I can reproduce my problems even on a > "cleaner" system. I guess you used php5 in your tests? Ok, i will test it with these path added with PHP5. If it works, I'll add it. Greets Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#784014: Fwd: Feature wish: detox and non-existent files
Package: detox 2015-04-23 11:02 GMT+02:00 Ari Moisio : > Hi > > May i suggesta new functionality on detox: > > a new parameter, for example -N that will pass the command line argument > thru defined sequence but does not care if the file exists and of course > will not try to rename it, olyn outputs a cleaned filename to the stdout. > > I'm asking this for a CD ripping script wwhere the filename comes from > cddb and i would like to pass already valid file name for the lame encoder. > > Best regards > -- > Terveisin > Ari Moisio > Atk-suunnittelija > Tiedonhallintapalvelut > Näkövammaisten Keskusliitto ry. > 050 401 5875 > ari.moi...@thp.nkl.fi >
Bug#804018: dpkg: provide options to avoid service startup on package installation
Package: dpkg Severity: wishlist Hi, as of today services a started once they are installed. This is a problem in some cases, e.g. when installing and configuring a service via puppet and/or in preparation for a HA setup. We had a lot of discussions around this design decision in the past and I do not want to restart that. Instead I'd like to propose a feature to opt-out from automatic service startup by introdocution of a new dpkg option, e.g. Dpkg::StartServices with a truthy default. RATIONALE: By adding a configuration option for this, we allow the administrator of a Debian system to decide if services are started after installation or not. It is superior to adding a command line switch only, since it allows the admin to set this permanent and system-wide (with all its disadvantages) or on a per-installation base (which would be suitable to be used by configuration management systems). Possible implementation: Per policy 9.3.3.2 have to interface with init via invoke-rc.d for service startup. A possible (and admittedly naive) implementation which does not involve changes in each and every package, could possibly just let dpkg install a policy.d layer and ensure its absence on process end. Though some sort of IPC between invoke-rc.d and dpkg that does not involve filesystem modifications would probably be better. Best Regards, Patrick
Bug#804018: Fwd: Bug#804018: dpkg: provide options to avoid service startup on package installation
-- Forwarded message -- From: Patrick Schönfeld Date: 2015-11-04 18:27 GMT+01:00 Subject: Re: Bug#804018: dpkg: provide options to avoid service startup on package installation To: Holger Levsen Hi, thanks for thinking about my proposal and commenting on it. 2015-11-04 13:19 GMT+01:00 Holger Levsen : > > you are aware of > > echo -e '#!/bin/sh\nexit 101' > /usr/sbin/policy-rc.d > yes, I'am aware of the policy-rc.d mechanism, see my naive implementation proposal (it's what I meant with policy.d layer - a misnomer of mine). However, that would effect all service starts, not only the start after the package installation, which my proposal aims at. Of course I could write some policy-rc.d script checking an environment variable, blacklist or a like and set it before the package installation, but that somehow feels like a hack, considering that this is just a distribution decision I want to overrule as an admin (on a case-by-case basis). Maybe it helps understanding my proposal, if I describe a use case: Let's say I'd like to install serviceX, which shall be managed by pacemaker. Since pacemaker will manage the runtime status of the service this means to install, disable (and currently) stop the service (which is a hack in declarative configuration management systems since there is no state to describe "install package with service disabled"). Providing a standard way to not start a certain service after package installation seems a lot of cleaner. And that is what my proposal aims at. Apart from that our distribution decision to start services after installation is quiet controversial to some people anyway and my proposal would provide a standard way for those people to opt-out from this choice. 2015-11-04 14:08 GMT+01:00 Guillem Jover : > This all feels very out of scope for dpkg. More so when policy-rc.d > already supports what you seem to be asking for (as Holger also > pointed out)? > I don't think so, because after all its the package manager which starts the maintainer scripts which in turn starts the service. Apart from that it's _the_ place where I consciously choose to install a package and if I want it to be running afterwards. And in case of configuration management systems: the interface it communicates with. > > Possible implementation: > > Per policy 9.3.3.2 have to interface with init via invoke-rc.d for > service > > startup. A possible (and admittedly naive) implementation which does not > > involve changes in each and every package, could possibly just let dpkg > > install a policy.d layer and ensure its absence on process end. Though > some > > sort of IPC between invoke-rc.d and dpkg that does not involve filesystem > > modifications would probably be better. > > Something like this would mean encoding extremely system specific > policy into the dpkg C codebase, when dpkg has no knowledge whatsoever > on what is happening on maintainer scripts or how init scripts are > invoked or managed etc. It does not feel right. > Yeah, I admit that the implementation idea has all sorts of problems (which is why I called it naive in the first place). But I really think dpkg is the right place for the flag (to start services or not), while invoke-rc.d is the tool called by the maintainer scripts and therefore responsible for the actual doing. What's missing is the glue between these components. Maybe a better implementation would be an environment variable respected by invoke-rc.d and passed-thru by dpkg? Best Regards, Patrick Schönfeld
Bug#804018: dpkg: provide options to avoid service startup on package installation
Hi, 2015-11-05 2:38 GMT+01:00 Guillem Jover : > > That's really what policy-rc.d is for. > and I think that is not the right interface for such cases or at least it's not the best interface we can can provide for such cases. It's certainly good enough for the admin who wants to overrule our policy permanently, although letting the admin write a script for such a simple decision still feels kind of clumsy. IMHO it has probably been designed for build chroots and that's absolutely the purpose it fits best. But let's have a deeper look at the configuration management case. If they wanted to provide a way to say "install that package, but make sure that the service is not started afterwards", they could either a) Permanently install a policy-rc.d layer, letting it interface with the package install (e.g. by the env variable you said and another one set by the configuration management to tell the policy-layer which service the policy applies to) b) Install a policy-rc.d layer before each package installation, removing it afterwards c) Let each user handle installing a policy-rc.d layer either permanently or before each package installation Each of this option has several disadvantages: With a) the admin is no longer able to install another policy-rc.d script, apart from that it's a quiet invasive from a configuration management system to put a script in place that is permanently interfered with for every service that is ever started. With b) the door is widely opened for all kind of trouble, e.g. leaving mess around after package installation. Sure there can be put safety measures into place to avoid that, but overall it increases complexicity - for a Debian specific solution, since other distributions just don't start services after installation. With c) everything applies which applies to b), additionally each user has to implement this himselves and need to workaround the fact, that the configuration management system is not aware of his implementation. Thats where we are today: Some people employ exec-handlers to kill the service after install, some put a policy-rc.d layer in place. All of these solutions have in common that they workaround a decision that we as a project have made (to provide "default" configurations for services and start them after package installations), which is fine in some cases (e.g. software I *want* to be running after installation like sshd) and not so fine in others (installing services I want to manage via a clusterstack for example). Feels somewhat like giving the user some nails, but expect him to build the hammer on his own. > dpkg has no idea nor control over what happens inside maintainer scripts, > those are exclusively under the package domain. Starting services is > just one of the actions that can be done there, if any other policy > would require making dpkg aware of it, then dpkg would suddenly have > to know about tons of things it has no control over. But that place > already exists anyway, per above. :) > > And it does not have to have an idea what happens inside maintainer scripts. But since it's responsible for installation of those packages, it is also responsible for providing the environment in which the maintainer scripts run. Seems absolutely legit to restrict what the maintainer scripts are allowed to do, even if that restriction is soft, in a way that could be ignored by the maintainer scripts. In that specific case, however, we absolutely do have control over what happens. We have a policy in place that maintainer scripts have to interface with invoke-rc.d, so if we'd decide on a flag, we could very well set it in dpkg and let invoke-rc.d respect it. It would be cheap and solving a problem in a way that other tools (like configuration management) can rely on. And if the maintainer script does not run an init script at all, this flag does no harm either. Best Regards, Patrick
Bug#876202: O: vimoutliner - script for building an outline editor on top of Vim
Package: wnpp Severity: normal Hi, I'm no longer interested in maintaining this package and so I'm orphaning it. Best Regards, Patrick
Bug#876201: O: dnsproxy - proxy for DNS queries
Package: wnpp Severity: normal Hi, I'm now longer maintaining the above package and so I'm orphaning it. Best Regards, Patrick
Bug#876203: O: xml2 - Convert between XML, HTML, CSV and a line-oriented format
Package: wnpp Severity: normal Hi, I'm no longer interested in maintaining this package and so I hereby orphan it. Note to the prospective maintainer: It seems to me as if the software is not actively maintained by its upstream developer anymore and it has some serious issues like missing utf8 support. I'd probably request removal of the package if there weren't some users that are still interested in the package (as indiciated in the bug reports). Nevertheless I would not recommend taking over maintenance of this package without knowledge in C. Best Regards, Patrick
Bug#876206: RM: libdpkg-log-perl -- ROM
Package: ftp.debian.org Severity: normal Hi, as the current maintainer of libdpkg-log-perl I'm in the process of orphaning my packages, with this package being the only one where I am the upstream author as well. Since I'm not planning to maintain this library anymore and it actually does have a very few users [1] I think it's better to remove the package from Debian and thus I hereby request that. I may note that back when I wrote this lib (for my purposes) there were a request to include a-kind-of library (and its associated tool dpkg-report) directly with dpkg. But the changes as requested by the dpkg maintainers were basically a complete rewrite of the lib, so it probably doesn't even serve as a starting point if anyone is interested in doing that. The discussion of this changes can be seen in the bug report at [2]. Best Regards, Patrick [1] https://qa.debian.org/popcon.php?package=libdpkg-log-perl [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608930
Bug#821177: dpkg: please make dpkg perl libraries available on cpan
Hi, I understand that it would be bothersome and therefore I understand your position, yet I ask to reconsider my request :) 2016-04-16 12:56 GMT+02:00 Guillem Jover : > > Which means many if not most major distributions (and their > derivatives) already provide them: > Indeed and I did not notice that it's even available on OSX where I could have needed it. So thanks for the hint. Still, I see value in providing Debian-specific libraries via CPAN. The tools available in the packaging ecosystem allow installing packages independently from the system package manager, apart from that they can manage several different versions of a library for different perl versions, which is quiet handy as a developer. Consider the following use case: A developer want's to write a tool to query depends of a perl application from debian/control files, so that this can be the source of truth for what dependency the application has, even when developing and therefore running it on a developers OSX notebook (where he'd use the tools in perl ecosystem to manage the depends). Since the application itself can run on OSX just fine, there is no reason why this tool couldn't run on OSX. It would also help to manage dependencies for various target platforms, keeping them in sync. There is a library for this and maybe other use cases and it is most likely to be in sync with the policy. It would be quiet cool if a random perl developer could use it and get it via standard means, e.g. cpanm. Currently there is no library for parsing Debian dependencies on CPAN (at least I haven't found one that doesn't depend on other Dpkg::* libraries) and even if there were one, it wouldn't be the reference implementation. I agree that something like that will always have limitations, e.g. if the libraries in fact require dpkg binaries, but not all of the dpkg perl libraries do have those limitations, do they? Best Regards, Patrick
Bug#428159: mantis: [debconf_rewrite] Debconf templates review
Kevin Coyner schrieb: > Does that sound O.K. to you ... namely that we add in an "Other" > choice, which you'd have to provide code for in the maintainers' > script? Yes, almost. I will only support apache2 for the next release, cause the apache variants are ruled out. Also it will take me some time to provide the lighttpd configurator. So, if I add lighttpd to the automatic configuration we need to change the text, cause it is to apache-specific currently. But as it *is* apache-only for now, i think it is better to keep it like this. So go on in the process. Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500778: libnss-ldapd: groups resolve to nogroup after boot
Hi, 2008/10/3 Arthur de Jong <[EMAIL PROTECTED]>: > Patrick, does adding "Cache-Expiration = 10" to /etc/idmapd.conf in the > [General] section help at all in your setup? (the correct values should > be loaded sooner) very good. This betters the situation a lot. Its a good workaround. Now if you'd find the reason why the behaviour differs from libnss-ldap and could enhance libnss-ldapd in this way, this would be great :-)) Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500231: mouse (buttons) not properly working in gnome
> Nothing, if your mouse is actually /dev/input/mouse0 at every boot (look > at /proc/bus/input/devices) Well, there is and there has always been: I: Bus=0011 Vendor=0002 Product=0006 Version= N: Name="ImExPS/2 Generic Explorer Mouse" P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input5 U: Uniq= H: Handlers=mouse0 event5 B: EV=7 B: KEY=1f 0 0 0 0 0 0 0 0 B: REL=143 Also udev creates devices for it: [EMAIL PROTECTED]:~# ls -l /dev/input/mouse0 crw-rw 1 root root 13, 32 6. Okt 13:33 /dev/input/mouse0 Additional, changing it to /dev/input/mice (which also exists) does not work either.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500231: mouse (buttons) not properly working in gnome
Hi, 2008/10/6 Julien Cristau <[EMAIL PROTECTED]>: > OK this is odd, the keyboard and mouse get added twice according to the > log. Well, the question is: Why? > Why are the CorePointer and CoreKeyboard options commented out? > Uncommenting them should fix this. It does. xorg.conf(5) says: Option "Core Pointer" When this is set, the input device is installed as the core (primary) pointer device. There must be exactly one core pointer. *If this option is not set here, or in the ServerLayout section, or from the -pointer command line option, then the first input device that is capable of being used as a core pointer will be selected as the core pointer.* Please note the part which has been enclosed by asterisks. According to this the options are _not needed_ because Xorg should be able to find it out itself and apart from this I guess that Xorg think this, too: (==) The core pointer device wasn't specified explicitly in the layout. Using the first mouse device. (==) The core keyboard device wasn't specified explicitly in the layout. Using the first keyboard device. After this is says: (**) Configured Mouse: always reports core events And as already said it worked in Etch so this is clearly a regression (from the documented behaviour). Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501434: Fails to work with current phpmailer in sid
(CC'ing the maintainer of libphp-phpmailer, because I have questions about this upload to sid) Hi Michal, 2008/10/7 Michal Čihař <[EMAIL PROTECTED]>: > after upgrade of libphp-phpmailer (1.73-6 -> 2.1-1), mantis fails to > send emails: OK, thanks for the bug report. I'll investigate on it. Kevin, your upload of the new upstream version happened very current. I wonder if this is supposed to migrate to lenny?! I can't imagine that, because its unlikely that new releases get the OK from the release team, but in that case I don't understand why this uploads happen in this phase of our release cycle. Please comment on this. Thanks and best Regards, Patrick
Bug#420841: mantis should depend from mysql-client
Hi, Luca Falavigna wrote: > mantis needs mysql-client in order to complete installation, but it is > not listed in its dependencies. If such package is not installed, mantis > returns with this error message: "No mysql client to execute. Have you > installed mysql-client?" I am wondering of which installation you are talking. If you mean the web-based installation i don't see a need to install mysql-client, as mantis is setup during the package installation w/o the mantis installer (which has been tested and should be working fine as is). If it now fails under some circumstances, then i think we should check dbconfig-common for missing depends, cause that is what is used for installing the database. Could you supply me with further information? > This bug was initially reported in Ubuntu: > https://launchpad.net/bugs/105567. Uh.. didn't even know that ubuntu contains a current mantis package. But as far as I see they imported them into their distribution. Best Regards Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428159: [BTS] templates://mantis/{templates} #428159
Kevin Coyner schrieb: > Patrick, O.K.? Yes. -Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429374: smstools can not decode received messages but I can manualy...
Hi, thanks keke for your feedback about this issue. Michelle, is this thing solved for you, now? Or does this need further investigation? Best Regards Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433682: Add a console viewer for revelation files
Package: revelation Version: 0.4.11-1 Severity: wishlist It would be quiet useful if a non-x11 viewer would exist to access revelation data. Read-Only access would be sufficient, but write access would be a big plus. Best Regards Patrick -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.21.5 (PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages revelation depends on: ii cracklib2 2.7-19pro-active password checker librar ii gconf2 2.18.0.1-3GNOME configuration database syste ii gnome-icon-theme 2.18.0-3 GNOME Desktop icon theme ii libc6 2.5-9+b1 GNU C Library: Shared libraries ii python 2.4.4-6 An interactive high-level object-o ii python-central 0.5.14register and build utility for Pyt ii python-crypto 2.0.1+dfsg1-2 cryptographic algorithms and proto ii python-gnome2 2.18.2-1 Python bindings for the GNOME desk ii python-gnome2-extras 2.14.3-1 Python bindings for the GNOME desk ii python-gtk22.10.6-1 Python bindings for the GTK+ widge ii python-xml 0.8.4-7 XML tools for Python ii python2.4 2.4.4-4 An interactive high-level object-o ii shared-mime-info 0.21-2FreeDesktop.org shared MIME databa revelation recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#884857: developers-reference: clarify process on retirement/improve wording
Package: developers-reference Severity: normal Hi, while the whole process of retiring is mostly well documented, I felt somewhat insecure what's the right way to inform the account managers of my retirement. The current wording is: > Notify the Debian key ring maintainers that you are leaving by opening a ticket in Debian RT by sending a mail to &email-keyring; with the words 'Debian RT' somewhere in the subject line (case doesn't matter). The confusing bit (for me) is the request to just sent a mail with the words "Debian RT" which is somewhat like confirming a mailinglist subscription but doesn't really feal like the right way to open a ticket. I guessed that the mail should actually contain a *request* to lock my account / move it to emeritus state and to include my account name, but that isn't really clear from the wording as _seemingly_ it puts emphasis on some technical detail of the process (spam protection?). I guess the devref could be somewhat more fool-safe (;) by changing the wording for example like this: "Notify the Debian key ring maintainers that you are leaving by opening a ticket in the Debian RT by sending a mail to &email-keyring; with the request to move your account to emeritus state. Please ensure to include your account name in the mail and the words 'Debian RT' somewhere in the subject line (case doesn't matter)." Second, I signed my mail to the RT with PGP/MIME, which I learned from Gunnar Wolf is troublesome because RT mangles the mail. I'm not sure if the mail needs to be signed anyway (the devref doesn't say so) but if it should, then noting that technical restriction could probably safe DAM some time. :) If it is required, I'd change the above suggested wording like this: "Notify the Debian key ring maintainers that you are leaving by opening a ticket in the Debian RT by sending a mail to &email-keyring; with the request to move your account to emeritus state. Please ensure to include your account name in the mail and the words 'Debian RT' somewhere in the subject line (case doesn't matter) and that you are using inline-signing instead of PGP/MIME (which is mangled by RT)." Hope, opening the ticket is helpful. Best Regards, Patrick
Bug#1000238: dnsproxy: Packaging licensing incompatible with upstream
Hello, are you writing me to ask if I am in agreement with changing the Licensing of the packaging? If yes, I hereby agree to change the Licensing of my contributions to the packaging to a compatible license. Best Regards, Patrick Am Samstag, 20. November 2021 schrieb Marcos Talau : > I received an Undelivered for Patrick Schoenfeld < > schoenf...@in-medias-res.com>, > so in Cc I am trying another contact with Patrick. > > Patrick, below the original message. > > > Cheers, > mt > > On Fri, Nov 19, 2021 at 11:02:43PM -0300, Marcos Talau wrote: > > Package: dnsproxy > > Version: 1.17-1 > > Severity: normal > > X-Debbugs-Cc: mar...@talau.info > > > > The current packaging licensing (GPL-2) is incompatible with upstream > > licensing (MIT). It is a hampering condition to submit patches from > > Debian to upstream. > > > > I am adopting the package and I intend to change the packaging licensing > > to MIT. > > > > I will wait 15 days to know if anyone has any objections. > > > > > > Cheers, > > mt > -- LargePrefPlaceholder-XKUz1MEJBwkOM
