Re: Location for Fortran90 module files
Am 25.07.2013 14:25, schrieb Michael Banck: > What to do about the compatibilty is a different matter, did this come > up before? looks like one hand in the debian-science team doesn't know what the other hands are doing ... See #714730, even on the debian-science ML. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f26d7b.7060...@debian.org
Re: Location for Fortran90 module files
Hi Matthias, On Fri, Jul 26, 2013 at 02:37:15PM +0200, Matthias Klose wrote: > Am 25.07.2013 14:25, schrieb Michael Banck: > > What to do about the compatibilty is a different matter, did this come > > up before? > > looks like one hand in the debian-science team doesn't know what the other > hands > are doing ... > > See #714730, even on the debian-science ML. Thanks for the information. BTW, it would have been perceived even without the unfriendly tenor. In case you might not know the team is maintaining a wide range of packages and so there is not always a need to know about specific Fortran issues. It even might happen that not everybody does read each mail on the list. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726133540.gb26...@an3as.eu
Re: Location for Fortran90 module files
Am 26.07.2013 15:35, schrieb Andreas Tille: > BTW, it would have been perceived even without the unfriendly tenor. In > case you might not know the team is maintaining a wide range of packages > and so there is not always a need to know about specific Fortran issues. well, apparently you did perceive it as unfriendly. However in the past I did point out many issues with (unaddressed) build failures for packages maintained by the -science (and the -med) team, which didn't get any feedback. Which I do perceive as unfriendly. So apparently this team does have a size where it cannot manage the maintained packages any more, or where not everybody in the team is interested in every package. Other teams do have this problem too (which form my point of view is a problem). Sorry, but it is not the first time that I see this with the -science team. > It even might happen that not everybody does read each mail on the list. well, why not, and who else should be addressed? Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f27fc6.40...@debian.org
Re: Location for Fortran90 module files
Hi Matthias, On Fri, Jul 26, 2013 at 03:55:18PM +0200, Matthias Klose wrote: > Am 26.07.2013 15:35, schrieb Andreas Tille: > > BTW, it would have been perceived even without the unfriendly tenor. In > > case you might not know the team is maintaining a wide range of packages > > and so there is not always a need to know about specific Fortran issues. > > well, apparently you did perceive it as unfriendly. However in the past I did > point out many issues with (unaddressed) build failures for packages > maintained > by the -science (and the -med) team, which didn't get any feedback. I admit that this might happen to some degree. I do not agree that this is an excuse to do some bashing of teams who try their best with the avialable manpower. Please note that we tried to pick up packages which would be orphaned otherwise. So your situation would not be different if your requests would be ignored by MIA maintainers instead of no response from a team mailing list. > Which I do perceive as unfriendly. Not getting feedback is for sure frustrating. I'm not sure whether it can be called unfriendly if volunteers have set priorities in a way that they just do not manage to answer what you would call "right in time". > So apparently this team does have a size where it > cannot manage the maintained packages any more, If you are interested you could try to seek the list archive how often I tried to create more focussed teams in specific sciences. Even if there is some agreement you need some volunteer to do the needed work - I guess you know the principle, right? > or where not everybody in the team is interested in every package. Yes. This is definitely no singularity amongst several teams inside Debian. In all teams I know there is some overlap between maintainers and packages but no full coverage. IMHO this can not be reached in teams of volunteers. > Other teams do have this problem too > (which form my point of view is a problem). Do you have a suggestion how to solve this problem? And what exactly is the problem? > Sorry, but it is not the first time > that I see this with the -science team. I remember you told me so at all occurences when we met and I'm sure you will tell me at next DebConf. > > It even might happen that not everybody does read each mail on the list. > > well, why not, and who else should be addressed? You did perfectly well to respond to the e-mail from Michael and providing the information he needed. I just insist that it is no excuse for becoming unfriendly to a respected DD and member of several teams if he has not perceived a detail which for a moment might have seemed irrelevant for him. In general I'd like to repeat my advise that in contrast to having a MIA maintainer where you are not allowed to change a package you can always dch --team a Debian Science maintained package if you have a certain problem with it. I do not say that you should do all the fixing work - but if you really want to let something happen sometimes the fastest way to realise it is to simply do it yourself quickly rather than waiting ages. I know that you are perfectly aware how Free Software works and we try to open the doors for it. Feel free to take this chance but please stop blaming people who while trying to do their best fail to cope with your requirements. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726144905.gd26...@an3as.eu
Re: [PATCH] netplug - Allow to specify custom script file via param '-s'
On Sunday 21 April 2013 13:23:49 Paul Wise wrote: > On Sun, Apr 21, 2013 at 6:11 PM, Pali Rohár wrote: > > But why Debian cannot review and include this my patch? > > Now is the time for fixing RC bugs, not for including patches, > please wait until wheezy is released and then give the > maintainer some time to review it and prepare a new package. Wheezy was already released. Can anybody look at my patch now? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Shared memory attack on exponentiation crypto
This paper just came out: http://eprint.iacr.org/2013/448.pdf It's quite exciting, really. In summary, by running another process which maps the gnupg executable and plays tricks to detect L3 cache fills, they can recover the private key used in a gnupg signature operation. This is a threat in any multi-user system. It's also a threat in a VM scenario if you have a page-sharing system. I think in Debian our responsibility is at least to try to fix the multi-user problem. The simplest way seems to be to avoid having crypto processes share their pages with other processes. I wrote a simple function which unshares all of the relevant file mappings: http://www.chiark.greenend.org.uk/ucgi/~ian/git/map-unshare.git/ It seems to work in the simple test program, for me, on i386. It's not threadsafe (and making it threadsafe would be quite tricky). It's also Linux-only, but I guess FreeBSD must have ways to do this. Is trying to plumb this into various crypto executables a reasonable approach ? Doing this to ssh, sshd, gpg, etc., would seem quite straightforward and probably reasonable from a performance point of view. (Single-user embedded systems should have a way to turn it off.) Web browsers might be a problem because you probably don't want to unshare the whole of the executable and libraries. Another possibility would be to try to provide a set of LD_PRELOAD-based hooks, thus providing a toolkit for retrofitting the page-unsharing without having to patch and rebuild everything of interest. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20978.41094.663790.937...@chiark.greenend.org.uk
Bug#717926: ITP: swiftsc -- simple client library of OpenStack Swift
Package: wnpp Severity: wishlist Owner: Kouhei Maeda * Package name: swiftsc Version : 0.5 Upstream Author : Kouhei Maeda * URL : https://github.com/mkouhei/swiftsc * License : GPL Programming Lang: Python Description : simple client library of OpenStack Swift This tool is simple client library of OpenStack Swift. This tool is intended to be used in the module and Python script other. The main purpose of this tool is used as a core module for backup tool. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726163910.1549.98188.report...@vmdeb.cyberagent.co.jp
Bug#717927: ITP: backup2swift -- backup data to OpenStack Swift
Package: wnpp Severity: wishlist Owner: Kouhei Maeda * Package name: backup2swift Version : 0.8 Upstream Author : Kouhei Maeda * URL : https://github.com/mkouhei/backup2swift * License : GPL Programming Lang: Python Description : backup data to OpenStack Swift This tool is that backup data to OpenStack Swift. provides features are command line interface, and backup rotatition. This is depend on swiftsc, that is simple client library of OpenStack Swift. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726164425.1850.9461.report...@vmdeb.cyberagent.co.jp
Bug#717935: ITP: snmpsim -- SNMP agent simulator
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: snmpsim Version : 0.2.3 Upstream Author : Ilya Etingof * URL : http://snmpsim.sourceforge.net/ * License : 2-clause BSD Programming Lang: Python Description : SNMP agent simulator SNMP Simulator is a software that would act like a multitude of real physical devices from SNMP Manager's point of view. Simulator builds and uses a database of physical devices' SNMP footprints to respond like their real counterparts do. Typical use case for this software starts with recording a snapshot of SNMP objects of donor agents into text files. Once you have your snapshots at hand, a simulator script could be run over the snapshots responding to SNMP queries in the same way as donor SNMP agents did at the time of recording. Technically, SNMP Simulator is a multi-context SNMP agent. That means that it handles multiple sets of managed object all at once. Each device is simulated within a dedicated SNMP context. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJR8uCeAAoJEJWkL+g1NSX5UE8QAJHFPHG49wxOVJxpoqUHFA5Y eDDev7oUy2nBtkPavyq2KlZz1FLve4AQAyUwV5LRx964y3YQte1tjwHVoHVXwt5r o3y2w5D0F9/qBToVlSxz96JtYCJzMty6MigWzxaBO80/nOcgjYVegY69OjkSC4iP vTt6IhYv2gMKQqGmXCMAc5bS+YUxt2x1OsVXH3J+uzJAYrUnHGOVx5MGuKVu+qVU qufnkDDcRfvn3gu/aD82U0tCisbR3itPS2BsCOP5RccrZfWjI07FQwaY7zb2yltz GipHDWEn9RxHzC1vPtN7kfPjyX7uZ3ZA5fPsjh2I98ef25CMQnxIoCbh8Uuu/HY9 z3tRBPtja2QOBUJcvEZEhbGfnp/WYkKBjlNotw6ry88lXZTJn8XhezqI+6ABvQXW 5YiKg4qRbw81bS47oWiKbpxXtT3fwbI9ZhM+z7Pk4j34VTU4Gr9Sle/3T1I0ZZs2 UC+w3C36laKn4Ak3h3ZtxADMkQrLub8cVvEZeICnNKNJvGmOpXYUtZLwr6E3ohES Nr8Hgvy9MzfoBB6Upf3z6WpMYBgRMEGSr7TMCY9+Ji4X5OUD9b7GpXIBTFtDUGDw X735wMSZyjRXUavH5N2B8lJUa4is4kj5f87EyumtRRqJRDGySLslQ6u1qiiVHsDm mNm1cyWFDPHTpz4pHnxx =s4YF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726204835.30435.31968.report...@guybrush.luffy.cx
Re: Bug#717824: anonscm.debian.org needs a feedback channel
anatoly techtonik gmail.com> writes: > http://anonscm.debian.org/viewvc/python-modules/packages/python-pyftpdlib/ trunk/debian/watch?r1=13515&r2=13521 I think that got fixed in a post-release subversion update. But it can also be worked around by patching FusionForge’s copy of the ViewVC code. Roland probably knows. As for footers… dpkg-divert on the .ezt file, edit it to provide such information? bye, //mirabilos (hat: Evolvis/FusionForge developer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130727t001402-...@post.gmane.org
