Re: Javascript trigger design
On Sat, 29 Nov 2014, Thomas Goirand wrote: > 2/ in debian/openstack-dashboard.postinst, implement something like: > > if [ "$1" = "triggered" ] ; then > /usr/share/openstack-dashboard/manage.py compress --force > fi > > Is it *that* simple? No, triggers unfortunately are not that simple: if you install/upgrade openstack-dashboard together with some of the packages it wants a trigger on, $1="triggered" will sometimes not happen, only "configure". Have a look at these: • https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=evolvis-platfrm/evolvisforge.git;a=blob;f=mw-plugin/debian/triggers;h=723d1c077e3cf10350952cf9ded297b85cfde812;hb=HEAD • https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=evolvis-platfrm/evolvisforge.git;a=blob;f=mw-plugin/debian/postinst;h=fa480512bf5b32bcfe5412544159a158e6cfab08;hb=HEAD The thing to call when triggered is the upgrade_mediawikis shell function, it’s called from the “triggered” case, but also from the regular “configure” case. This is suboptimal, but apparently needed. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1412010922450.1...@tglase.lan.tarent.de
Re: Technical committee acting in gross violation of the Debian constitution
On Fri, 28 Nov 2014, Philipp Kern wrote: > On Fri, Nov 28, 2014 at 04:40:50PM +0100, Thorsten Glaser wrote: > > Hey, there are *still* bugs found because of s390 (not s390x). > > Uhm. s390x is 64bit BE; ppc64 and sparc64 never made it into the archive. Sure, but I was thinking of other issues, like ptrdiff_t. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1412011037570.1...@tglase.lan.tarent.de
Re: Technical committee acting in gross violation of the Debian constitution
On Sat, 29 Nov 2014, Svante Signell wrote: > The best for kFreeBSD and Hurd would be to abandoning the Debian ship. No. > It is sinking It has sunk, but not gone underwater yet completely. > (just let the devuan people get things in order first) And can you *please* *stop* the devuan trolling? Thanks. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1412011044080.1...@tglase.lan.tarent.de
Re: Technical committee acting in gross violation of the Debian constitution
On Sat, 29 Nov 2014, Axel Wagner wrote: […] > Axel Wagner *plonk* Congrats, you’re the second person, after Josselin. (No, this eMail was not the only one, just the one to trigger overflow.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1412011045510.1...@tglase.lan.tarent.de
Re: Technical committee acting in gross violation of the Debian constitution
Hi, Thorsten Glaser: > > Axel Wagner > *plonk* There have been much worse emails here than calling somebody a troll for intentionally posting misleading information. If it quacks like a duck, and all that. The only other reason for you to plonk Axel I could find (after reading the last couple of his mails here) is that he happens to disagree with you. If you intend to appear unreasonable, then I suppose this helps. Otherwise, not so much. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bug#771668: RFP: etherpad -- edit documents collaboratively in real-time in your browser
Control: reassign -1 wnpp Control: severity -1 wishlist On Lu, 01 dec 14, 13:05:32, Pander wrote: > Package: etherpad Is this the same as #576998 ITP: etherpad-lite -- web based collaborative real-time editor ? > Severity: RFP > > See also and link to https://bugs.launchpad.net/ubuntu/+bug/1397373 > > description: Etherpad allows you to edit documents collaboratively in > real-time, much like a live multi-player editor that runs in your > browser. Write articles, press releases, to-do lists, etc. together with > your friends, fellow students or colleagues, all working on the same > document at the same time. > > url: http://etherpad.org > > license: Apache License (AL) 2.0 > > (Please let me know if I am using the correct format for RFP because my > previous requests were added additional control tags.) As per[1] you want 'Package: wnpp' and 'Severity: wishlist' (mind the "and their corresponding severities to be used are:"). Any particular reason for not using 'reportbug'[2]? [1] http://www.debian.org/devel/wnpp/#l2 [2] http://www.debian.org/devel/wnpp/#l1 Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: [Pkg-javascript-devel] Javascript trigger design
On 11/29/2014 06:10 PM, Jérémy Lal wrote: > Le vendredi 28 novembre 2014 à 20:46 +0100, Jonas Smedegaard a écrit : >> Quoting Thorsten Glaser (2014-11-28 13:20:36) >>> On Fri, 28 Nov 2014, Thomas Goirand wrote: >>> It's been a long time I've been thinking about it, and I believe that the only way to do this, would be to use triggers. Though I have never >> >>> Look at libjs-protoaculous which combines prototype and scriptaculous >>> into one (possibly minified) js file. In (our inhouse version of) >>> FusionForge, we just depend on it, and it contains all the trigger and >>> dependency magic needed for that. >> >> Just looking at the package name that seems not an ideal aproach: Should >> we then make packages for each combination of libraries to be merged >> together, or am I missing a more clever logic? Or do you perhaps point >> at that package not suggesting duplicating it but instead cherry-picking >> triggers for a system-wide structure? > > I suggest bundling javascript, stylesheets, images, assets in general > should be done using a custom, per-package, makefile (or makefile > target). Something in postinst ? > You can't standardize upon absence of standard. > > Jérémy. That's what I'm doing already, it's just that I *also* need to do it when a javascript package is upgraded. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547c608c.7000...@debian.org
Re: [Pkg-javascript-devel] Javascript trigger design
Le vendredi 28 novembre 2014 à 07:04 +0800, Thomas Goirand a écrit : > Hi, > > Web application have evolved into monsters that needs lots of > javascript. It's very common that these javascript applications are > collecting all the .js library they use, concatenate them into a single > file, and compress the result using all sorts of tools (node uglify is > one of the implementation, but that's not the only one). > > As much as possible, as good Debian citizens, we do package each and > every javascript library into a separate package. But then, if there's > an update of that JS library, the Web application package has to somehow > know about it, and redo the concatenate & compress job. Otherwise, the > web app would continue to use the old version. > > I have this issue with the OpenStack dashboard (ie: Horizon), but also > with a second web app which I'm currently packaging (OpenStack Fuel, > which is a deployment software for OpenStack). Though this could of > course be generalize to any JS app. > > It's been a long time I've been thinking about it, and I believe that > the only way to do this, would be to use triggers. Though I have never > used triggers, and I thought it was a good idea to ask my DD friends and > this list about it. Should there be one trigger per web app? How would > this work? > > Thoughts anyone? Jonas maybe, who did lots of JS packaging? Instead of triggers, i'd rather make sure the web application package is rebuilt whenever one of its Build-Depends package is updated. That way, updates of bundled assets would be handled by the same migration process as library updates. Is it possible ? Jérémy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417438946.27821.14.ca...@melix.org
floating point testsuites on softfloat buildds
Hi, some of my packages (e.g. nwchem, but others as well) have floating-point heavy testsuites becuse they are scientific computing applications. The current state on mips (but not mipsel) is that the testsuite routinely takes too long on some autobuilders, so that sbuild kills it after a testcase has not finished in the configured timeout (up to 5 hours). I had another look today, and it seems this is due to most of the mips autobuilders not having an FPU. The same testcase (cosmo_h3co): mips (mips-aql-01): 524.3u 4873.9s 1:30:56.17 98.9% (0t+0ds+0avg+31986max)k 0i+0o 0pf 0swaps mips (ball): 76.5u 1.9s 1:18.45 100.0% (0t+0ds+0avg+27876max)k 0i+286136o 0pf 0swaps armel (hartmann): 395.8u 1.7s 6:37.76 99.9% (0t+0ds+0avg+31418max)k 0i+291224o 0pf 0swaps i386 (brahms): 10.9u 0.5s 0:11.43 100.0% (0t+0ds+0avg+27026max)k 0i+285672o 0pf 0swaps As you can see, the system is below 2 seconds for all buildds, except for mips-aql-01, where it is almost 5000 seconds. Obviously, this is due to floating point emulation in the kernel. So far, I have been requesting a give-back each time it FTBFS on a mips autobuilder and hoped that it might hit ball next time, but this is not a sustainable approach in my opinion. So I think there are some things to consider here: 1. Is it OK for an autobuilder not to have an FPU? 2. Is it OK for an architecture to only have autobuilders without FPUs? 3. If 1 but not 2 are OK, should there be a way for packages to say "I should really be built on a buildd without softfloat"? One proposal might be to add something like "XS-Buildd-Flags: hardfloat" to debian/control for packages, which ship a floating-point heavy testsuite as a first step. This could possibly be extended for other buildd machine-specific features (though I am not sure off-hand which would benefit). Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201132211.gh1...@raptor.chemicalconnection.dyndns.org
Re: floating point testsuites on softfloat buildds
Hi,
Quoting Michael Banck (2014-12-01 14:22:12)
> 3. If 1 but not 2 are OK, should there be a way for packages to say "I should
>really be built on a buildd without softfloat"?
>
> One proposal might be to add something like "XS-Buildd-Flags: hardfloat"
> to debian/control for packages, which ship a floating-point heavy
> testsuite as a first step. This could possibly be extended for other
> buildd machine-specific features (though I am not sure off-hand which
> would benefit).
I was recently told in #debian-mentors that one can mail
${arch}@buildd.debian.org to restrict the buildd's on which a package is built
for architecture ${arch}. This might be able to solve your problem for now.
I would welcome a way that allows adding metadata to my source packages which
restricts the selection of buildd's it's built on.
For example I recently removed the --parallel argument from the dh invocation
in the d/rules of my package "vcmi" because individual calls to c++ easily eat
up to 2.3 GB of memory which leads to failures due to heavy swapping on buildds
that set DEB_BUILD_OPTIONS=parallel=5 but only have 4 GB of physical RAM.
So in addition to asking for "hardfloat" it would be handy if one could specify
the required memory consumption as a function of parallel jobs such that either
the right buildd can be selected or the number of jobs can be reduced
accordingly.
cheers, josch
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141201144756.6173.44130@hoothoot
Re: Architectures where unaligned access is (not) OK?
Usually when you're loading an unaligned value you're also loading a
particular representation and endianness, which might not be the
native one, so I've often written code like this:
uint32_t load32(void *p)
{
unsigned char *c = p;
return
c[0] | (uint32_t)c[1] << 8 | (uint32_t)c[2] << 16 | (uint32_t)c[3] << 24;
}
(The first of the three casts isn't really necessary ...)
Unfortunately, GCC doesn't seem to turn that into a single load
instruction even when it could be. (Why not?)
If you know that you want the native representation and endianness
there's this possibility:
uint32_t load32(void *p)
{
uint32_t r;
memcpy(&r, p, sizeof(r));
return r;
}
GCC turns that into a single load instruction on i386, amd64 and arm64.
Edmund
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAHDciUexgfHwWX_ijWrC1NWqhX7sc_3ktGwU8Ya4Ntjq_UX=f...@mail.gmail.com
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, Nov 29, 2014 at 12:30 -0800, Steve Langasek wrote: > On Sat, Nov 29, 2014 at 08:14:07PM +0100, Philipp Kern wrote: > > That's even more unlikely than to add a debconf message (which would be > > package-owned). Yes, debian-installer is frozen. This would add new > > udebs, new strings, new everything. We're actually trying to release. > > Debian releases when it's ready. If large numbers of our users are going to > have a bad experience with jessie as a result of being switched to systemd, > then we should take appropriate steps to address that, even if that means > unfreezing the installer. Indeed. Jessie should be released once "large numbers of our users [will] no longer have a bad experience as a result of being switched to systemd [because all relevant bugs have been fixed]". As somebody who is active in user support on IRC I dread the jessie release if it means that we will ask people for years to come if they have switched to systemd after their upgrade and, if not, walk them through the process. So far most users who had a bad experience with jessie did so because they did *not* switch and the fact that -shim wasn't ready. "having a bad experience" should directly translate into bugs that can, and have to, be fixed before the release. I would welcome a more technical discussion at this point rather than an emotional one. Thank you and everybody else for their wonderful work and patience. -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: [Pkg-javascript-devel] Javascript trigger design
On Mon, 1 Dec 2014, Jérémy Lal wrote: > Instead of triggers, i'd rather make sure the web application package is > rebuilt whenever one of its Build-Depends package is updated. No, that’s too fragile and ties up way too many resources. It’s fully OK to compose the final version on the users’ systems, and use rather broad versioning to restrict the acceptable versions of the external things, if at all needed. > That way, updates of bundled assets would be handled by the same > migration process as library updates. Actually no: they would be handled as *static* libraries. The postinst/trigger method would be the same as dynamic libraries. > Is it possible ? Yes, but who’d be doing the work? bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1412011749030.1...@tglase.lan.tarent.de
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
Am 29.11.2014 um 22:01 schrieb Philipp Kern: > On 2014-11-29 21:30, Steve Langasek wrote: >> Debian releases when it's ready. If large numbers of our users are >> going to >> have a bad experience with jessie as a result of being switched to >> systemd, >> then we should take appropriate steps to address that, even if that means >> unfreezing the installer. > > Sure. But where is the evidence for that? Is there a bug that has been > agreed upon to be RC? Whoever upgrades their lxc guests without taking further informed action (such as switching back to sysv), will not be able to start their LXC VM at the next reboot( #766233 [1]). This is currently classified as "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone." and thus not RC, so if being RC is currently the precondition to fix stuff in jessie, then you are right. Unless at least respective documentation gets included in the release notes (#762194 [2]) I think there will be some future unhappiness. At this moment it's a trap waiting to be walked into. *t [1] http://bugs.debian.org/766233 [2] https://bugs.debian.org/762194 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547c9de8.5020...@sourcepole.ch
Re: floating point testsuites on softfloat buildds
On Mon, Dec 1, 2014 at 2:22 PM, Michael Banck wrote: > Hi, > > some of my packages (e.g. nwchem, but others as well) have > floating-point heavy testsuites becuse they are scientific computing > applications. > > The current state on mips (but not mipsel) is that the testsuite > routinely takes too long on some autobuilders, so that sbuild kills it > after a testcase has not finished in the configured timeout (up to 5 > hours). > > I had another look today, and it seems this is due to most of the mips > autobuilders not having an FPU. The same testcase (cosmo_h3co): > > mips (mips-aql-01): > 524.3u 4873.9s 1:30:56.17 98.9% (0t+0ds+0avg+31986max)k 0i+0o 0pf 0swaps > > mips (ball): > 76.5u 1.9s 1:18.45 100.0% (0t+0ds+0avg+27876max)k 0i+286136o 0pf 0swaps > > armel (hartmann): > 395.8u 1.7s 6:37.76 99.9% (0t+0ds+0avg+31418max)k 0i+291224o 0pf 0swaps > > i386 (brahms): > 10.9u 0.5s 0:11.43 100.0% (0t+0ds+0avg+27026max)k 0i+285672o 0pf 0swaps > > As you can see, the system is below 2 seconds for all buildds, except > for mips-aql-01, where it is almost 5000 seconds. Obviously, this is > due to floating point emulation in the kernel. > > So far, I have been requesting a give-back each time it FTBFS on a mips > autobuilder and hoped that it might hit ball next time, but this is not > a sustainable approach in my opinion. > > So I think there are some things to consider here: > > 1. Is it OK for an autobuilder not to have an FPU? > > 2. Is it OK for an architecture to only have autobuilders without FPUs? > > 3. If 1 but not 2 are OK, should there be a way for packages to say "I > should really be built on a buildd without softfloat"? > > One proposal might be to add something like "XS-Buildd-Flags: hardfloat" > to debian/control for packages, which ship a floating-point heavy > testsuite as a first step. This could possibly be extended for other > buildd machine-specific features (though I am not sure off-hand which > would benefit). float are emulated on kernel. Maybe a partial subarch building with softfloat will be worthwhile. Bastien > > Michael > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > https://lists.debian.org/20141201132211.gh1...@raptor.chemicalconnection.dyndns.org > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAE2SPAbDprdg-gy2RU9XPatZCM-T59e=wpzu5yh7ef-0bkf...@mail.gmail.com
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
Quoting Tomas Pospisek (2014-12-01 17:57:12) > Am 29.11.2014 um 22:01 schrieb Philipp Kern: >> On 2014-11-29 21:30, Steve Langasek wrote: >>> Debian releases when it's ready. If large numbers of our users are >>> going to have a bad experience with jessie as a result of being >>> switched to systemd, then we should take appropriate steps to >>> address that, even if that means unfreezing the installer. >> >> Sure. But where is the evidence for that? Is there a bug that has >> been agreed upon to be RC? > > Whoever upgrades their lxc guests without taking further informed > action (such as switching back to sysv), will not be able to start > their LXC VM at the next reboot( #766233 [1]). > > This is currently classified as "a bug which has a major effect on the > usability of a package, without rendering it completely unusable to > everyone." and thus not RC, so if being RC is currently the > precondition to fix stuff in jessie, then you are right. > > Unless at least respective documentation gets included in the release > notes (#762194 [2]) I think there will be some future unhappiness. > > At this moment it's a trap waiting to be walked into. > *t > > [1] http://bugs.debian.org/766233 > [2] https://bugs.debian.org/762194 What does "evidence" even mean here? I expect systemd itself to be in good shape, not buggy. But I do suspect that Debian-with-systemd is in lesser good shape, especially on existing systems some of which were creating by standards now discouraged (e.g. / and /usr on separate partitions). By switching init system we are "shaking the tree", revealing bugs in other code which lay dormant till now. Molly-guard seems to now fail on systems with separate / and /usr due to /usr being unmounted before molly-guard is called (bug#771572) - smells like broken init system interactions, but likely an old bug in Molly-guard just not revealed until exposed to a modern init system. Should that bug be RC? How to collect potential evidence, while playing nice with systemd maintainers, release team and others who are less worried? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: curl and certificate verification in jessie
On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote: > > > Is this intentional, or is that a bug in either gnutls, curl, or the > > > software > > > using these libraries? > > > > AFAICT this is due to the gnutls26 -> gnutls28 switch. Using libgnutls-dev > > to > > build curl instead of libgnutls28-dev makes it possible to point > > CURLOPT_CAINFO > > to a single leaf certificate and have the verification succeed. > > > > FWIW the current behaviour is the same with openssl. I don't know if > > there's a > > reason for it though. > > Can we get it reverted/fixed? If you are asking if curl is gonna go back to gnutls26, I don't think that's gonna happen. AFAICT it's not maintained upstream anymore and gnutls28 provides stuff like ECC support that's IMO more important. As for fixing it, you need to discuss this with the gnutls maintainers. > We consider it a security-related regression compared to wheezy and while we > could run private builds of the code on debian.org, that'd be pretty silly > (and a waste of manpower). What does "security-related regression" mean? (if anything this makes security checks tighter). The problem, I think, is that you provide curl (and thus gnutls) with a CA certificate that doesn't actually sign the end certificate of the site you are trying to connect to (even if the two are the same certificate). Again, I don't know if this is intended or not, you need to talk with the gnutls maintainers. Cheers signature.asc Description: Digital signature
Re: curl and certificate verification in jessie
On 12/01/2014 01:50 PM, Alessandro Ghedini wrote: > On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote: Is this intentional, or is that a bug in either gnutls, curl, or the software using these libraries? >>> >>> AFAICT this is due to the gnutls26 -> gnutls28 switch. Using libgnutls-dev >>> to >>> build curl instead of libgnutls28-dev makes it possible to point >>> CURLOPT_CAINFO >>> to a single leaf certificate and have the verification succeed. >>> >>> FWIW the current behaviour is the same with openssl. I don't know if >>> there's a >>> reason for it though. >> >> Can we get it reverted/fixed? > > If you are asking if curl is gonna go back to gnutls26, I don't think that's > gonna happen. AFAICT it's not maintained upstream anymore and gnutls28 > provides > stuff like ECC support that's IMO more important. I agree with Alessandro here: we definitely don't want to revert to GnuTLS the 2.x series (gnutls26). gnutls 3.x (gnutls28) is the only viable option for jessie. > What does "security-related regression" mean? (if anything this makes security > checks tighter). I'm not convinced by this argument. Saying "i'll only accept the following end-entity cert" is a tighter check than "i'll only accept a cert for the end-entity certified by this CA". However, the semantics of the CURLOPT_CAINFO call are squishy on whether it can be used to mean the former. And CURLOPT_ISSUERCERT appears to have the same constraint. Modern versions of GnuTLS have a TOFU facility [0] (similar to known_hosts of Openssh) which could be used for the former approach, but i don't see any way to reach that mechanism from curl. --dkg [0] http://gnutls.org/manual/gnutls.html#Trust-on-first-use signature.asc Description: OpenPGP digital signature
Bug#771708: ITP: mrtdreader -- Machine-readable travel document library and example program
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: mrtdreader Version : 0.1.0 Upstream Author : Ruben Undheim * URL : https://github.com/rubund/mrtdreader * License : GPL-3+ Programming Lang: C Description : Machine-readable travel document library and example program This package contains the library libmrtd and the command line tool mrtdreader. Machine-readable travel documents such as passports nowadays usually contain an RFID chip for storing various data. This library provides useful functions for reading out the data from these documents. This version of the library supports the Basic Access Control (BAC). It uses several cryptographic functions from either libgcrypt or libtomcrypt (depending on compile-time options - for debian currently libgcrypt) in order to do the necessary decryption of the content of the MRTDs. The key for the BAC-scheme is derived from the Machine-readable zone (MRZ) which is printed on the MRTD. The library depends on libnfc for the hardware interaction and only devices supported by libnfc will therefore work. I think such a library is a useful addition to the debian package repository. It is a good example for using the libnfc library on which there are still rather few packages that depend. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201200252.2223.87389.report...@miniserver.beebeetle.com
Re: curl and certificate verification in jessie
On Mon, 1 Dec 2014, Alessandro Ghedini wrote: On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote: Is this intentional, or is that a bug in either gnutls, curl, or the software using these libraries? AFAICT this is due to the gnutls26 -> gnutls28 switch. Using libgnutls-dev to build curl instead of libgnutls28-dev makes it possible to point CURLOPT_CAINFO to a single leaf certificate and have the verification succeed. FWIW the current behaviour is the same with openssl. I don't know if there's a reason for it though. Wild guess: a certificate may indicate, in optional extra fields, if the signer intended it to act as CA. For example in Firefox certificate details, these are listed under "Extensions" as "Certificate Basic Constraints", "Certificate Key Usage" and/or "Netscape Certificate Type". It might be that modern gnutls/openssl are actually enforcing these fields, which would cause a single-server certificate to be considered invalid for CA purposes. And there might possibly be some way to override that decision. Just my 2c, Anne Bezemer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.lnx.4.64.1412012029400@wormhole.robuust.nl
Bug#771718: general: Screen blanks and does not come back up unless system is suspended
Package: general Severity: normal Hi, I was thus far unable to pinpoint which component causes this behaviour as I can not find anything in my logs (and/or journal). I have therefore assigned it to general. Feel free to change to a more appropriate package. I'm using KDE on Jessie with gdm3 as the login manager. The system has systemd installed. When the system is idle for few minutes (but before the limit set in the KDE screensaver settings), the screen will blank and will not come back on keypress or mouse movements. I have to close the lid of the laptop to let the system suspend. After resume I will get the unlock window of the screensaver and can continue working. I can login using SSH when this happens but couldn't find anything in the logs that could explain this. Any ideas on how to further debug this issue is appreciated. Are there any other reports about similar behaviour? Regards, Rik -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201210250.5522.37293.reportbug@earth
Re: curl and certificate verification in jessie
]] Alessandro Ghedini > On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote: > > > > Is this intentional, or is that a bug in either gnutls, curl, or the > > > > software > > > > using these libraries? > > > > > > AFAICT this is due to the gnutls26 -> gnutls28 switch. Using > > > libgnutls-dev to > > > build curl instead of libgnutls28-dev makes it possible to point > > > CURLOPT_CAINFO > > > to a single leaf certificate and have the verification succeed. > > > > > > FWIW the current behaviour is the same with openssl. I don't know if > > > there's a > > > reason for it though. > > > > Can we get it reverted/fixed? > > If you are asking if curl is gonna go back to gnutls26, I don't think that's > gonna happen. AFAICT it's not maintained upstream anymore and gnutls28 > provides > stuff like ECC support that's IMO more important. I'm not asking for a particular course of action, I'm asking for a specific goal to be reached. (I otherwise agree that going back to gnutls26 isn't a good idea.) > As for fixing it, you need to discuss this with the gnutls maintainers. That's why they are copied on the mail too. > > We consider it a security-related regression compared to wheezy and while we > > could run private builds of the code on debian.org, that'd be pretty silly > > (and a waste of manpower). > > What does "security-related regression" mean? (if anything this makes security > checks tighter). No, it doesn't necessarily. As dkg points out, I can no longer say «this service should have this particular cert». This makes us vulnerable to compromises of the CA that provides the cert for a given service and a lowering of the overall security in this particular setup. > The problem, I think, is that you provide curl (and thus gnutls) with > a CA certificate that doesn't actually sign the end certificate of the > site you are trying to connect to (even if the two are the same > certificate). Well, it's not a CA certificate. :-) > Again, I don't know if this is intended or not, you need to talk with the > gnutls > maintainers. Again, they're Cc-ed. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oarngjv0@aexonyam.err.no
Bug#771718: general: Screen blanks and does not come back up unless system is suspended
On Mon, Dec 1, 2014 at 22:02:50 +0100, Rik Theys wrote: > Package: general > Severity: normal > > Hi, > > I was thus far unable to pinpoint which component causes this behaviour as I > can > not find anything in my logs (and/or journal). I have therefore assigned it > to general. Feel free to change to a more appropriate package. > > I'm using KDE on Jessie with gdm3 as the login manager. The system has > systemd installed. When the system is idle for few minutes (but before the > limit set in the KDE screensaver settings), the screen will blank and will not > come back on keypress or mouse movements. I have to close the lid of the > laptop > to let the system suspend. After resume I will get the unlock window > of the screensaver and can continue working. > > I can login using SSH when this happens but couldn't find anything in the logs > that could explain this. > > Any ideas on how to further debug this issue is appreciated. Are there any > other reports about similar behaviour? > The debian bug tracking system is not a user support forum. The 'general' pseudo package even less so. There are other places for this, such as the debian-user list. Cheers, Julien signature.asc Description: Digital signature
Using USB serial device with a cdc-acm driver
Hello everyone, we have a small device of our own, which communicates through serial USB on Windows. Now we need it to work on Raspberry (yes, I know this is Debian, which is Raspberry based on). USB descriptors configured as a modem, so, when I connect it to Linux, cdc-acm module is loaded. However, there is apparently some process which is watching modems, so on connection I got some info on my device - on Ubuntu it is AT commands, for which I have adapted firmware (seems ModemManager is running), but on Raspberry I cannot find out what process attaches to my "modem" and what it wants. It sends a data similar to terminal control sequence. Where should I look at? I want to turn this process off. Ubuntu does not use inittab anymore, but Raspberry seems still uses. I do not see anything suspicious in /etc/inittab: # /etc/inittab: init(8) configuration. # $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $ # The default runlevel. id:2:initdefault: # Boot-time system configuration/initialization script. # This is run first except when booting in emergency (-b) mode. si::sysinit:/etc/init.d/rcS # What to do in single-user mode. ~~:S:wait:/sbin/sulogin # /etc/init.d executes the S and K scripts upon change # of runlevel. # # Runlevel 0 is halt. # Runlevel 1 is single-user. # Runlevels 2-5 are multi-user. # Runlevel 6 is reboot. l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Normally not reached, but fallthrough in case of emergency. z6:6:respawn:/sbin/sulogin # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now # Action on special keypress (ALT-UpArrow). #kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work." # What to do when the power fails/returns. pf::powerwait:/etc/init.d/powerfail start pn::powerfailnow:/etc/init.d/powerfail now po::powerokwait:/etc/init.d/powerfail stop # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # ::: # # Note that on most Debian systems tty7 is used by the X Window System, # so if you want to add more getty's go ahead but skip tty7 if you run X. # 1:2345:respawn:/sbin/getty --noclear 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 4:23:respawn:/sbin/getty 38400 tty4 5:23:respawn:/sbin/getty 38400 tty5 6:23:respawn:/sbin/getty 38400 tty6 # Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100 # Example how to put a getty on a modem line. # #T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3 #Spawn a getty on Raspberry Pi serial line #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/99ff66e5-df2b-4a64-b62d-2ff35526e...@radier.ca
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Mon, Dec 01, 2014 at 04:55:55AM +0100, Christoph Anton Mitterer wrote: > On Sat, 2014-11-22 at 11:42 +0100, Wouter Verhelst wrote: > > Except that if a firewall "protects" a user from using their printer > > (random example, not sure how likely) > Well most security guys are probably sceptical about any automagical > confiugration of things like a printer... so "protects" can actually > really mean protect here. > > But apart from that, other distros seem to manage that problem (simply > allowing the CUPS ports?) As said, "cups" is an example. It's not about cups specifically, it's about the fact that you want a computer to *do something*, not break because "firewall!" > > and they have no way of fixing > > that (or even understanding what's wrong), that's not very helpful. This > > is why I said "with the current state of affairs". > > > > Before we enable a firewall by default, we should, IMO, have the > > following: > > > > - A way for a user to configure it without understanding iptables. > IMHO, this is a bad idea. If a user doesn't know what he's doing that he > usually makes more harm than good. I didn't say "without knowing what they're doing", I said "without understanding iptables". There's a difference, and it's not subtle. > People probably have to accept the fact that they cannot blindly act > without any knowledge and this still work. Not in all cases, no, that much is true. However, there are a few common configurations where we *can* usefully provide a default configuration for the system. When my father uses his laptop, he never uses it for anything but "browsing the web", "printing out his writings", and "reading his mail". Any kind of server on such a machine is most likely *wrong*. This configuration is common, and easy to configure. Yes, there may be a few corner cases where the default firewall config will not do what is expected. That's not necessarily a problem. > > - A way for a user to debug (without understanding iptables) if things > > don't work. > Mhh, that I agree,... OTOH, having some basic knowledge on iptables and > debuggin is rather easy, at least speaking about simple cases like "I > block my CUPS port"... other cases like IPv6 needs ICMPv6 to work or > things that require protocol level knowledge are nothing that one can > really automagical debug for a user without the willingness to learn > about these things. I'm not talking about a default firewall that will interfere with ICMPv6 (or ICMPv4, for that matter; blocking ICMP is evil). I'm talking about a default firewall that will do things like close ports 80, 22, 25, etc. If a user tries to connect to port 22 from a remote machine and it doesn't work, this user should have an easy way of figuring out "why doesn't my SSH connection work". That's not too difficult to accomplish. > > - A way for a package maintainer to assert that this particular package > > needs a hole in the firewall to be useful, and that this hole needs to > > be available to a particular group of remote machines. E.g., cups > > would not expect connections from the other end of the world, while > > webservers would. > This is really a bad idea. Most sysadmins probably wouldn't want their > firewall rules to be automagically changed by some pseudo-smart > mechanism. Who said anything about "automatigically changing" or "pseudo-smart mechanism"? I'm suggesting that a package be able to communicate to some other part of the system that it needs a hole in the firewall. That other part of the system can then decide (based on user configuration or interactive input) to ignore the request, change the firewall (with a better understanding of how the firewall is configured), mail root, segfault, or spawn nasal daemons. Or just not exist, if the local sysadmin decides not to allow firewalls. > In fact, no one can really know how fire wall rules are set up, and even > the placement of a rule make completely change the semantics. Well, no, that's true. If we ship a default firewall, we know what the firewall looks like. If the user installs a different piece of firewall software, and that piece has understanding of this proposed mechanism, then it may assume it knows what the firewall rules look like. If the local sysadmin wrote their own scripts to handle firewall, and they incorporated support for this proposed mechanism, then they should damn well understand what they did. Here's what I'm suggesting: User: apt-get install apache Apache package: "Hello system. If you're a server, you will probably want to open port 80/tcp in the firewall." System firewall: "here you go." User: apt-get install cups Cups package: "Hello system. If you're a user machine and you're on something resembling a 'home network', you will probably want to open port 631/tcp". System firewall: "we're not on a home network, but I've stored that information for later reference, thanks." User: apt-get install ntpd Ntpd package: "Hello system. There
Re: Javascript trigger design
On 12/01/2014 04:26 PM, Thorsten Glaser wrote: > On Sat, 29 Nov 2014, Thomas Goirand wrote: > >> 2/ in debian/openstack-dashboard.postinst, implement something like: >> >> if [ "$1" = "triggered" ] ; then >> /usr/share/openstack-dashboard/manage.py compress --force >> fi >> >> Is it *that* simple? > > No, triggers unfortunately are not that simple: if you install/upgrade > openstack-dashboard together with some of the packages it wants a > trigger on, $1="triggered" will sometimes not happen, only "configure". > > Have a look at these: > > • > https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=evolvis-platfrm/evolvisforge.git;a=blob;f=mw-plugin/debian/triggers;h=723d1c077e3cf10350952cf9ded297b85cfde812;hb=HEAD > • > https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=evolvis-platfrm/evolvisforge.git;a=blob;f=mw-plugin/debian/postinst;h=fa480512bf5b32bcfe5412544159a158e6cfab08;hb=HEAD > > The thing to call when triggered is the upgrade_mediawikis shell > function, it’s called from the “triggered” case, but also from > the regular “configure” case. This is suboptimal, but apparently > needed. > > bye, > //mirabilos Hi Thorsten, First, thanks a lot for your help here. It's really appreciated. I hope I'll get it this time... I did get the point I needed to do it on my postinst too, and I am doing it already. So let me rephrase, just to make sure I got it: So if I understand well (by reading your example package), the only thing I have to do (for horizon) is: 1/ Create a debian/openstack-dashboard.triggers that would contain a list of "interest /usr/share/javascript/", for example: interest /usr/share/javascript/jsencrypt then I'd get triggered in my postinst, and then I should do: 2/ in debian/openstack-dashboard.postinst, implement something like: if [ "$1" = "configure" ] ; then /usr/share/openstack-dashboard/manage.py compress --force fi if [ "$1" = "triggered" ] ; then /usr/share/openstack-dashboard/manage.py compress --force fi Is it *that* simple? I'm surprised by the "interest" thing just being hinted with a directory. Does this mean that if anything changes in that directory, then there's a trigger, and the openstack-dashboard compress stuff will happen? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547cefc9.1080...@debian.org
Re: Javascript trigger design
On 2 December 2014 at 09:46, Thomas Goirand wrote: > > if [ "$1" = "configure" ] ; then > > /usr/share/openstack-dashboard/manage.py compress --force > > fi > if [ "$1" = "triggered" ] ; then > /usr/share/openstack-dashboard/manage.py compress --force > fi > > Is it *that* simple? I'm surprised by the "interest" thing just being > hinted with a directory. Does this mean that if anything changes in that > directory, then there's a trigger, and the openstack-dashboard compress > stuff will happen? > There might be times when compress is run twice. e.g. when upgrading openstack-dashboard and /usr/share/javascript/jsencrypt at the same time. However I cannot think of anyway to fix this in a way that doesn't create other problems. So this might actually be the best solution. (e.g. you could explicitly raise the trigger inside the configure event, however that will trigger all applications that have an interest in /usr/share/javascript/jsencrypt which is probably not desirable) -- Brian May
Re: Embedded systems and systemd
On 29/11/14 13:30, Vincent Bernat wrote: > ❦ 29 novembre 2014 12:41 GMT, Alastair McKinstry > : >> One concern I'd have is the lack of flexibility to produce a cut-down >> system. The option of "a dedicated init=/custom-program", but lack of >> an ntpd, for example, because ntp has been absorbed into systemd's >> orbit and other ntpd's bitrotted. > > Unlikely to happen since systemd-timesyncd is not a full NTP daemon. It > lacks ability to act as a server. And it doesn't appear to regulate the system clock frequency, which basically makes it an inaccurate dumb SNTP client which steps the clock when it synchronises. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6e8vkb-j33@silverstone.rilynn.me.uk
Re: Technical committee acting in gross violation of the Debian constitution
On Sunday, 30 de November de 2014 18:05:54 Neil Williams escribió: [...] > Contribute code or stop wasting everyone's time on the mailing lists. Contributing code is not the only way to contribute to Debian. At least to the Debian I love. Please come out of the developer shell. Translators, e.g. are a very important part of the project, even if they have not been give the same voting status as so-called "Debian Developers". Please stop THAT. > > Nothing will change without someone doing the work - whatever the issue. That is true. But no work can be done if nobody realizes that it needs to be done. > If that isn't you, then do everyone a favour and stop posting to these > endless threads. True, these posts are becoming endless. If you read my posts on them, you'll notice I acknowledge for systemd being the default on Jessie. It was our TC decision and I can not do anything but acknowledge it. It does not matter if I like systemd or not. And it does not mater if systemd is buggy or not, fit for release or not. But still there is place to decide a lot of other things about systemd. The GR did not resolve the issue of switching by default or not, to name one. This is my contribution now, to try to raise issues in a calm manner. Exactly the same issues most of our users have and some of our maintainers seem to not address properly. It has been expressed before: This is not only a discussion about technical issues. Regards er Envite signature.asc Description: This is a digitally signed message part.
Re: Embedded systems and systemd
On Mon, Dec 01, 2014 at 10:58:45PM +, Roger Lynn wrote: > On 29/11/14 13:30, Vincent Bernat wrote: > > ❦ 29 novembre 2014 12:41 GMT, Alastair McKinstry > > : > >> One concern I'd have is the lack of flexibility to produce a cut-down > >> system. The option of "a dedicated init=/custom-program", but lack of > >> an ntpd, for example, because ntp has been absorbed into systemd's > >> orbit and other ntpd's bitrotted. > > > > Unlikely to happen since systemd-timesyncd is not a full NTP daemon. It > > lacks ability to act as a server. Yes, one of the explicit design goals of timesyncd it to be a simple client, without server functionality. The assumption is that if you need a full NTP server, that are excelent choices available (ntpd and chronyd). > And it doesn't appear to regulate the system clock frequency, which > basically makes it an inaccurate dumb SNTP client which steps the clock when > it synchronises. Please see http://cgit.freedesktop.org/systemd/systemd/tree/src/timesync/timesyncd-manager.c?id=HEAD#n326 (manager_adjust_clock). timesync will adjust clock frequency unless the offset is too big. Zbyszek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141202021452.ga24...@in.waw.pl
Re: Technical committee acting in gross violation of the Debian constitution
On Tue, Dec 2, 2014 at 8:52 AM, Noel Torres wrote: > Contributing code is not the only way to contribute to Debian. At least to the > Debian I love. Please come out of the developer shell. Translators, e.g. are a > very important part of the project, even if they have not been give the same > voting status as so-called "Debian Developers". Please stop THAT. Indeed, there are many ways to help Debian: https://www.debian.org/intro/help FYI, translators (and other contributors) always were eligible to become Debian members and now we explicitly encourage them to do so: https://www.debian.org/vote/2012/vote_002 https://www.debian.org/vote/2010/vote_002 -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6GJJc4hadJ1_=fffozbk7njb5ctioq2qf0ezhlkkwd...@mail.gmail.com
Re: Technical committee acting in gross violation of the Debian constitution
On 27.11.2014 02:18, Josh Triplett wrote: > gnome Depends: gnome-core, which Depends: gnome-user-share, which > Depends: apache2-bin (or apache2.2-bin in stable, which is a > transitional package depending on apache2-bin in unstable). gnome depends on apache ? seriously ? cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547d44b3.6030...@gr13.net
Re: Technical committee acting in gross violation of the Debian constitution
On Tue, Dec 2, 2014 at 12:48 PM, Enrico Weigelt wrote: > On 27.11.2014 02:18, Josh Triplett wrote: > >> gnome Depends: gnome-core, which Depends: gnome-user-share, which >> Depends: apache2-bin (or apache2.2-bin in stable, which is a >> transitional package depending on apache2-bin in unstable). > > gnome depends on apache ? gnome-user-share uses apache2 to share files on the local network via WebDAV. http://sources.debian.net/src/gnome-user-share/3.14.0-1/src/http.c/#L270 http://sources.debian.net/src/gnome-user-share/3.14.0-1/src/user_share-webdav.c/#L161 http://sources.debian.net/src/gnome-user-share/3.14.0-1/src/user_share-webdav.c/#L65 > seriously ? Sharing files with other computers on the local network seems like perfectly reasonable and useful feature to me. In the past I have done it with the busybox httpd but the gnome-user-share implementation seems to be much more user friendly. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6F--6Ym2bOyy+C0yGN+btimb8WezZaK=gmhburomqo...@mail.gmail.com
Re: Using USB serial device with a cdc-acm driver
Dmitriy Fitisov wrote: > USB descriptors configured as a modem, so, when I connect it to Linux, > cdc-acm module is loaded. > However, there is apparently some process which is watching modems, so on > connection > I got some info on my device - on Ubuntu it is AT commands, for which I have > adapted firmware > (seems ModemManager is running), but on Raspberry I cannot find out what > process attaches > to my "modem" and what it wants. > It sends a data similar to terminal control sequence. Possibly 'getty'? > Where should I look at? I want to turn this process off. Look in /var/log/syslog and hopefully something will be logged there. Look in 'ps -ef' and see if anything is shown associated with the tty device. Bob signature.asc Description: Digital signature
Bug#771767: ITP: java-allocation-instrumenter -- A Java agent which causes a callback to be invoked on each memory allocation
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: java-allocation-instrumenter Version : 2.1 Upstream Author : Jeremy Manson * URL : http://code.google.com/p/java-allocation-instrumenter/ * License : Apache-2.0 Programming Lang: Java Description : A Java agent which causes a callback to be invoked on each memory allocation The Allocation Instrumenter is a Java agent written using the java.lang.instrument API and ASM. Each allocation in your Java program is instrumented; a user-defined callback is invoked on each allocation. Bytecode rewriting is used to invoke the callback at the site of each allocation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201121112.7.87701.reportbug@02ed91797728
