Re: init system policy
Philip Hands wrote: > Not if you take into account the fact that someone will have had to do > something like :wq! to get past the read-only state of the file. > > vim put's a [RO] after the filename when you open it, and says this when > you try to write it: > > E45: 'readonly' option is set (add ! to override) > > in emacs, you get %% in the status line, and it tells you the file's > read-only when you start trying to edit it, and refuses to do so until > you type C-x C-q to flip it's read-only status. > > nano sadly doesn't seem to notice :-/ I just tried this, when you open a read-only file as a normal user it gives you a warning. edward@x230:~$ touch test edward@x230:~$ chmod 400 test edward@x230:~$ nano test Nano says: [ Read 0 line ( Warning: No write permission) ] It won't let me save the file with the same name, I get this error: [ Error writing test: Permission denied ] When running as root the warning and error disappear, there is no indication that the file is read-only. -- Edward. -- 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/20141123092558.GA12017@x230
Re: systemd, fstab, noauto and nofail
* Simon McVittie [141122 20:36]: > Perhaps more to the point, Debian's initramfs-generator has been > modified to mount /usr as well as the root, so only systems that have no > initramfs *and* split /usr will get as far as exec()ing systemd without > first mounting /usr (which is a situation considered to be unsupported > by systemd upstream). I'd like to point out that this hasn't made it into jessie so far, as there are outstanding bugs. Help with those is certainly appreciated. C. -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- -- 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/20141123115925.GA12322@sx.local
Re: New pre-depends: python pre-depends python-minimal
On Sat, Nov 22, 2014 at 05:06:25PM +0100, Jakub Wilk wrote: > * Wouter Verhelst , 2014-11-22, 08:25: > >>It appears that the appropriate resolution of #769106 [1] is to add a > >>new pre-depends on python-minimal in python. > >> > >>This issue at hand is that at the time python2.7-minimal is configured, > >>python is unpacked, but python-minimal is not. Since python-2.7-minimal > >>doesn't have a direct depends on python-minimal, this is allowable > >>(policy 7.2, Depends). > >> > >>In order for python2.7-minimal to configure, python-minimal needs to be > >>at least unpacked to provide /usr/bin/pycompile. The only way for > >>python to ensure this is the case is to declare a pre-depends relation > >>(also policy 7.2). > > > >This is inaccurate. > > s/inaccurate/confusing as hell/ :-P Right :-) > >A python2.7-minimal pre-depends on python-minimal ensures that > >python-minimal is unpackaged _and configured_ before python2.7-minimal is > >unpacked. > > There are three packages involved is this mess: > > python2.7-minimal > python-minimal > python > > python depends on python-minimal. > python2.7-minimal does NOT depend on python or python-minimal (that'd be a > dependency loop). > python2.7-minimal tries to run a hook shipped by python, which might not > work when python is not configured yet. > > Hence the proposed Pre-Depends: python -> python-minimal. As I understand the situation, that won't solve your problem. If python pre-depends on python-minimal (and the rest of the dependencies stay in place), then you have the following situation: - python2.7-minimal and python-minimal are unpacked (in undefined order) - python2.7-minimal is configured - python-minimal is configured - python can now be unpacked As such, rather than fixing your problem, it would make matters worse; today it sometimes fails, depending on the exact decisions that apt and dpkg take when installing packages. With a pre-depends, it would *always* fail on new installs, because python would then not be *allowed* to be unpacked if python2.7-minimal isn't on the system, whose postinst would fail, which would forbid the installation of python (the step necessary to configure python2.7-minimal). It looks to me like the only solution here is to split off whatever it is that python2.7-minimal needs from the python package into a separate package, and have python2.7-minimal depend on that separate package. Call it "python-base" or "python-common" or something. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: Age of built packages to be part of the jessie release?
On Sat, Nov 22, 2014 at 03:36:36PM +, Neil Williams wrote: > (arm64 & ppc64el are both release arches for Jessie but FTBFS in > packages which have never built on either of those are not RC.) To be exact, FTBFS in a package on an architecture for which it is not *currently* built is not RC. If a package *used* to work on a given architecture but now (because of whatever reason) upstream has decided that supporting said architecture is a problem and won't be done anymore, then failure to build that package on that architecture is not an RC bug (though the maintainer should file a proper RM bug against ftp.debian.org to clarify that the other architectures are no longer supported). -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Bug#770704: ITP: wcwidth -- determine printable width of a string on a terminal
Package: wnpp Severity: wishlist Owner: Sebastian Ramacher * Package name: wcwidth Version : 0.1.4 Upstream Author : Jeff Quast * URL : https://pypi.python.org/pypi/wcwidth/0.1.4 * License : Expat Programming Lang: Python Description : determine printable width of a string on a terminal wcwidth allows to determine the printable width of a string on a terminal. It provides functions similar to wcwidth(3) and wcswidth(3) for Python programs. -- Sebastian Ramacher signature.asc Description: Digital signature
Re: Help to review a patch in ELisp
Hello, Thank you very much for your accurate answers. I forwarded to the author for a decision knowingly. Regards, -- Stéphane Aulery -- 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/20141123134253.ga2...@free.fr
Re: Age of built packages to be part of the jessie release?
Svante Signell wrote: > I wonder how old a package build can be to be part of the release. Some > packages are built up to a year ago, and rebuilding them now FTBFS. As others have noted already, there are period archive rebuilds to check what would now ftbfs. Slightly orthogonal to your question, "up to a year ago" doesn't come close, actually... 42% of source packages in jessie were uploaded over a year ago, 25% over two years ago, 15% over three years ago, 9% over four years ago. Fun fact: there are 64 source packages in jessie that are over 10 years old. Age of source packages in each release: http://ircbots.debian.net/stats/package_ages.png (note: this is based on source package uploads; binNMUs not included) -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- 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/m4sqt2$kk3$1...@ger.gmane.org
Re: Bug#770704: ITP: wcwidth -- determine printable width of a string on a terminal
On Sun, Nov 23, 2014 at 01:58:09PM +0100, Sebastian Ramacher wrote: > * Package name: wcwidth > * URL : https://pypi.python.org/pypi/wcwidth/0.1.4 > * License : Expat > Programming Lang: Python > Description : determine printable width of a string on a terminal > > wcwidth allows to determine the printable width of a string on a > terminal. It provides functions similar to wcwidth(3) and wcswidth(3) > for Python programs. Contrary to the name and description, it's not an end-user utility but only a library. Shouldn't it thus be named python-wcwidth or something, to convey it's useful only from python? I'd reserve the name "wcwidth" to something usable from the shell. Also, it contains hardcoded data from an ancient version of Unicode. What about generating this data instead (such as Marcus Kuhn's code, which this library is lifted from, does)? Even better, it would be better to call libc's wcwidth() instead of reinventing the wheel -- as a bonus, the data would be current without need for manual intervention. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20141123151235.gb2...@angband.pl
Re: systemd, fstab, noauto and nofail
On 20/11/2014 21:44, Simon McVittie wrote: > noauto is appropriate for detachable/removable media that are not > normally present. The other option for such media is to leave them out > of fstab altogether, and use something like udisks to mount them > on-demand: that's what you'd typically do in GNOME or KDE or whatever. I found another issue with systemd and noauto. I've a card reader that export various hardware port as different devices. As, when I use it, I want to see my photo in /media/photos whatever physical card type I use (it depends from which camera the card come from), I have several lines in /etc/fstab : /dev/disk/by-id/usb-Generic_USB_SM_Reader_058F412D8PB1-0:2-part1 /media/photos vfat noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,flush 0 0 /dev/disk/by-id/usb-Generic_USB_SD_Reader_058F412D8PB1-0:0-part1 /media/photos vfat noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,flush 0 0 /dev/disk/by-id/usb-Generic_USB_SM_Reader_100-0:3-part1 /media/photos vfat noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,flush 0 0 /dev/mmcblk0p1 /media/photos vfat noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,flush 0 0 It always worked for me. I never put several cards at the same time and I always found my photos under /media/photos. But, with systemd, I get at boot time a warning about systemd not being able to correctly create generators (or something like that) and, at runtime, my photos are not mounted under /media/photos or not with the options I specify (I need to check that exactly) Do you think I should do a bugreport ? Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/5471f8c1.3000...@free.fr
Bug#770731: ITP: symlookup -- Utility for object symbol search in installed libraries
Package: wnpp Severity: wishlist Owner: Dmitry Yu Okunev * Package name: symlookup Version : 0.5.2 Upstream Author : Andrew A Savchenko * URL : http://sourceforge.net/projects/symbol-lookup/ * License : GPL-3 Programming Lang: C (gnu99) Description : Utility for object symbol search in installed libraries This program searches for both dynamic and static libraries, looking those ones which provide given object symbols. It will assist you in undefined symbol errors eliminating. > why is this package useful/relevant? It sometimes saves a lot of time while running closed source applications > is it a dependency for another package? No. > do you use it? Yes. > if there are other packages providing similar functionality, how does it > compare? I don't know such packages. -- 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/20141123172930.15930.75838.report...@imperium.ut.mephi.ru
Re: Architectures where unaligned access is (not) OK?
On 21/11/14 13:31, Bernhard R. Link wrote:
> Otherwise that memory
> might afterwards be regarded as lzo_memops_TU2_struct
lzo_memops_TU2_struct is declared with __attribute__((__may_alias__)),
so actually the right thing should be happening WRT aliasing in this case.
On 21/11/14 13:21, Thorsten Glaser wrote:
> • for i386 and especially amd64, all subarchitectures supported
> by Debian/Linux jessie suffer so much from unaligned access,
> speed-wise, that it’s worth the overhead of forcing aligned
> access (i386, i486 maybe were not as badly affected)
I was hoping this statement was correct, because if it was, avoiding
unaligned accesses would be a clear win regardless, and the right thing
to do would be entirely uncontroversial.
Unfortunately, on my x86-64 laptop, my patched liblzo2 with
-DLZO_CFG_NO_UNALIGNED on all architectures seems to be half as fast as
the unpatched one for a simple test-case (uncompress
linux_3.17.orig.tar.xz to linux_3.17.orig.tar in a tmpfs, time lzop -c <
linux_3.17.orig.tar > /dev/null, repeat 3 times; results agree within 10%).
I'm trying out a slightly different approach: keeping the unaligned
accesses via casts like *(uint16_t *) on architectures where lzodefs.h
specifically allows them, but disabling the casts via
struct { char[n] } conditional on alignof(that struct) == 1, which seem
to be the problematic ones.
The CPUs for which lzodefs.h uses those casts are amd64, arm*
conditional on target CPU (so armel but not armhf in Debian terms),
arm64, cris, i386, m68k conditional on target CPU (__mc68020__ but not
__mcoldfire__), powerpc* if big-endian, and s390*.
S
--
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/54721f74.7010...@debian.org
Re: Bug#770704: ITP: wcwidth -- determine printable width of a string on a terminal
* Adam Borowski , 2014-11-23, 16:12: Even better, it would be better to call libc's wcwidth() instead of reinventing the wheel -- as a bonus, the data would be current without need for manual intervention. Beware that wcwidth(2) is locale-dependent, which might or might not be desirable. -- Jakub Wilk -- 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/20141123184543.ga6...@jwilk.net
packaging diaspora, final steps, looking for collaborators
Hi, We've been working on packaging diaspora since last 2+ years. It is written in ruby on rails framework and has 206 dependencies https://people.debian.org/~praveen/diasbar/ So far we packaged around 86% of the dependencies. Now I created a diaspora package with remaining dependencies uploaded in my people.debian.org account. You can follow the steps listed at https://wiki.debian.org/Diaspora to install it right now. I'm looking for some help to complete this packaging. Some tasks I need help are, 1. Complete packaging of remaining gem dependencies 2. Test the installation by going ahead with next steps listed at diaspora installation manual 3. Create debconf templates for pod configuration. 4. Help keep the gem versions in sync. If deb version of a library is older than required by diaspora (run 'bundle install --local' on a develop branch checkout of diaspora upstream), update the deb version. If debian already has a new version of a library, update the corresponding gem version in diaspora. 5. Create a tracker to check the dependency status in debian with diaspora develop branch. Once diaspora package is completed, this will be a boost to Freedom Box efforts. Hoping to get some collaborators in this final push. We hangout at #debian-diaspora on oftc. Thanks Praveen signature.asc Description: OpenPGP digital signature
Re: New pre-depends: python pre-depends python-minimal
On Sunday, November 23, 2014 13:41:47 Wouter Verhelst wrote: > On Sat, Nov 22, 2014 at 05:06:25PM +0100, Jakub Wilk wrote: > > * Wouter Verhelst , 2014-11-22, 08:25: > > >>It appears that the appropriate resolution of #769106 [1] is to add a > > >>new pre-depends on python-minimal in python. > > >> > > >>This issue at hand is that at the time python2.7-minimal is configured, > > >>python is unpacked, but python-minimal is not. Since python-2.7-minimal > > >>doesn't have a direct depends on python-minimal, this is allowable > > >>(policy 7.2, Depends). > > >> > > >>In order for python2.7-minimal to configure, python-minimal needs to be > > >>at least unpacked to provide /usr/bin/pycompile. The only way for > > >>python to ensure this is the case is to declare a pre-depends relation > > >>(also policy 7.2). > > > > > >This is inaccurate. > > > > s/inaccurate/confusing as hell/ :-P > > Right :-) > > > >A python2.7-minimal pre-depends on python-minimal ensures that > > >python-minimal is unpackaged _and configured_ before python2.7-minimal is > > >unpacked. > > > > There are three packages involved is this mess: > > > > python2.7-minimal > > python-minimal > > python > > > > python depends on python-minimal. > > python2.7-minimal does NOT depend on python or python-minimal (that'd be a > > dependency loop). > > python2.7-minimal tries to run a hook shipped by python, which might not > > work when python is not configured yet. > > > > Hence the proposed Pre-Depends: python -> python-minimal. > > As I understand the situation, that won't solve your problem. > > If python pre-depends on python-minimal (and the rest of the dependencies > stay in place), then you have the following situation: > > - python2.7-minimal and python-minimal are unpacked (in undefined order) > - python2.7-minimal is configured > - python-minimal is configured > - python can now be unpacked > > As such, rather than fixing your problem, it would make matters worse; > today it sometimes fails, depending on the exact decisions that apt and > dpkg take when installing packages. With a pre-depends, it would > *always* fail on new installs, because python would then not be > *allowed* to be unpacked if python2.7-minimal isn't on the system, whose > postinst would fail, which would forbid the installation of python (the > step necessary to configure python2.7-minimal). > > It looks to me like the only solution here is to split off whatever it > is that python2.7-minimal needs from the python package into a separate > package, and have python2.7-minimal depend on that separate package. > Call it "python-base" or "python-common" or something. Why would python-minimal be configured at unpack time for python? AIUI, the pre-depends would just require python-minimal to be unpacked prior to configure, not unpack. Did you mean python can now be configured? I think pre-depends would solve the problem at hand, but I'm also interested in feedback on the alternative proposed in the bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769106#31 Scott K signature.asc Description: This is a digitally signed message part.
Re: Architectures where unaligned access is (not) OK?
On 23/11/14 17:55, Simon McVittie wrote:
> Unfortunately, on my x86-64 laptop, my patched liblzo2 with
> -DLZO_CFG_NO_UNALIGNED on all architectures seems to be half as fast as
> the unpatched one
[...]
> I'm trying out a slightly different approach: keeping the unaligned
> accesses via casts like *(uint16_t *) on architectures where lzodefs.h
> specifically allows them, but disabling the casts via
> struct { char[n] } conditional on alignof(that struct) == 1, which seem
> to be the problematic ones.
That fixed the performance regression on amd64 while still working
correctly on armv5tel, so I've uploaded it as a DELAYED/7 NMU. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757037 for nmudiff.
If anyone has better ideas, I'm happy to cancel the delayed upload and
let someone take over fixing the bug.
S
--
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/54725b89.5020...@debian.org
Re: Architectures where unaligned access is (not) OK?
On 23.11.2014 23:11, Simon McVittie wrote:
> On 23/11/14 17:55, Simon McVittie wrote:
>> Unfortunately, on my x86-64 laptop, my patched liblzo2 with
>> -DLZO_CFG_NO_UNALIGNED on all architectures seems to be half as fast as
>> the unpatched one
> [...]
>> I'm trying out a slightly different approach: keeping the unaligned
>> accesses via casts like *(uint16_t *) on architectures where lzodefs.h
>> specifically allows them, but disabling the casts via
>> struct { char[n] } conditional on alignof(that struct) == 1, which seem
>> to be the problematic ones.
>
> That fixed the performance regression on amd64 while still working
> correctly on armv5tel, so I've uploaded it as a DELAYED/7 NMU. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757037 for nmudiff.
>
> If anyone has better ideas, I'm happy to cancel the delayed upload and
> let someone take over fixing the bug.
>
what works well is just replacing the offending memory loads with the
memcpy call. As the size of the memcpy call is constant the compiler
will take care of emitting code appropriate for the platform.
It doesn't help speed up the code on the trapping arches but at least
one does not penalize the ones where it is allowed.
--
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/54725fea.8050...@googlemail.com
Re: Architectures where unaligned access is (not) OK?
On 23/11/14 22:30, Julian Taylor wrote: > what works well is just replacing the offending memory loads with the > memcpy call. As the size of the memcpy call is constant the compiler > will take care of emitting code appropriate for the platform. Ah, even better; the timing on x86-64 comes out the same. I'll cancel the NMU and retry. S -- 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/547262e4.40...@debian.org
Re: Architectures where unaligned access is (not) OK?
On Sun, 2014-11-23 at 23:30 +0100, Julian Taylor wrote:
> On 23.11.2014 23:11, Simon McVittie wrote:
> > On 23/11/14 17:55, Simon McVittie wrote:
> >> Unfortunately, on my x86-64 laptop, my patched liblzo2 with
> >> -DLZO_CFG_NO_UNALIGNED on all architectures seems to be half as fast as
> >> the unpatched one
> > [...]
> >> I'm trying out a slightly different approach: keeping the unaligned
> >> accesses via casts like *(uint16_t *) on architectures where lzodefs.h
> >> specifically allows them, but disabling the casts via
> >> struct { char[n] } conditional on alignof(that struct) == 1, which seem
> >> to be the problematic ones.
> >
> > That fixed the performance regression on amd64 while still working
> > correctly on armv5tel, so I've uploaded it as a DELAYED/7 NMU. See
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757037 for nmudiff.
> >
> > If anyone has better ideas, I'm happy to cancel the delayed upload and
> > let someone take over fixing the bug.
> >
>
>
> what works well is just replacing the offending memory loads with the
> memcpy call.
[...]
That is not necessarily true, e.g. in this function
void copy_foo(struct foo *dst, const struct foo *src)
{
memcpy(dst, src, sizeof(*dst));
}
the compiler is still allowed to assume that src has the proper
alignment for struct foo and to optimise the memcpy() accordingly. And
yes, this is something that gcc really does.
Pointers to an unaligned instance of a structure generally need to be
declared as void *, char * or unsigned char * (or const-qualified
versions).
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
signature.asc
Description: This is a digitally signed message part
Re: Architectures where unaligned access is (not) OK?
On 23/11/14 22:54, Ben Hutchings wrote:
> in this function
>
> void copy_foo(struct foo *dst, const struct foo *src)
> {
> memcpy(dst, src, sizeof(*dst));
> }
>
> the compiler is still allowed to assume that src has the proper
> alignment for struct foo and to optimise the memcpy() accordingly.
I don't *think* lzo relies on that; the struct assignment I mentioned in
a previous mail is part of its fallback implementation of what is
basically 1-, 2-, 4- and 8-byte memcpy. The arguments seem to be
unsigned char * in practice.
liblzo2 seems to be one of these codebases that bases its idea of how C
works on portability folklore and the assumption that the compiler and
standard C library are the most naive implementation possible :-(
S
--
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/5472686e.5040...@debian.org
Re: systemd, fstab, noauto and nofail
On Sunday, 23 de November de 2014 15:09:53 Vincent Danjean escribió: > On 20/11/2014 21:44, Simon McVittie wrote: > > noauto is appropriate for detachable/removable media that are not > > normally present. The other option for such media is to leave them out > > of fstab altogether, and use something like udisks to mount them > > on-demand: that's what you'd typically do in GNOME or KDE or whatever. > > I found another issue with systemd and noauto. > I've a card reader that export various hardware port as different devices. > As, when I use it, I want to see my photo in /media/photos whatever > physical card type I use (it depends from which camera the card come > from), I have several lines in /etc/fstab : > /dev/disk/by-id/usb-Generic_USB_SM_Reader_058F412D8PB1-0:2-part1 > /media/photos vfat > noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,f > lush 0 0 /dev/disk/by-id/usb-Generic_USB_SD_Reader_058F412D8PB1-0:0-part1 > /media/photos vfat > noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,f > lush 0 0 > /dev/disk/by-id/usb-Generic_USB_SM_Reader_100-0:3-part1 > /media/photos vfat > noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,f > lush 0 0 /dev/mmcblk0p1 /media/photos vfat > noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,f > lush 0 0 > > It always worked for me. I never put several cards at the same time > and I always found my photos under /media/photos. > > But, with systemd, I get at boot time a warning about systemd > not being able to correctly create generators (or something like > that) and, at runtime, my photos are not mounted under > /media/photos or not with the options I specify (I need to check > that exactly) > > Do you think I should do a bugreport ? > > Regards, > Vincent Yes, please do so. Admin should be able to point several media to be mounted to the same mountpoint, and if systemd can not cope with that, it is a bug in systemd. Anyway I see that you do not use the noauto option. Is that on purpose? Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Bug#770783: ITP: libtest-perl-critic-progressive-perl -- gradually enforce coding standards
Package: wnpp Severity: wishlist Owner: Robin Sheat * Package name: libtest-perl-critic-progressive-perl Version : 0.03 Upstream Author : Jeffrey Thalhammer * URL : https://metacpan.org/release/Test-Perl-Critic-Progressive * License : Artistic or GPL-1+ Programming Lang: Perl Description : gradually enforce coding standards Test::Perl::Critic::Progressive allows Perl coding standards to be enforced in a gradual way. With it hooked into a continuous integration system, it will fail any changes that increase the number of policy violations, as judged using Perl::Critic. -- 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/20141124012400.14230.2534.report...@debmaker32.wgtn.cat-it.co.nz
Re: New pre-depends: python pre-depends python-minimal
On Sun, Nov 23, 2014 at 03:29:29PM -0500, Scott Kitterman wrote: > On Sunday, November 23, 2014 13:41:47 Wouter Verhelst wrote: > > As I understand the situation, that won't solve your problem. > > > > If python pre-depends on python-minimal (and the rest of the dependencies > > stay in place), then you have the following situation: > > > > - python2.7-minimal and python-minimal are unpacked (in undefined order) > > - python2.7-minimal is configured > > - python-minimal is configured > > - python can now be unpacked > > > > As such, rather than fixing your problem, it would make matters worse; > > today it sometimes fails, depending on the exact decisions that apt and > > dpkg take when installing packages. With a pre-depends, it would > > *always* fail on new installs, because python would then not be > > *allowed* to be unpacked if python2.7-minimal isn't on the system, whose > > postinst would fail, which would forbid the installation of python (the > > step necessary to configure python2.7-minimal). > > > > It looks to me like the only solution here is to split off whatever it > > is that python2.7-minimal needs from the python package into a separate > > package, and have python2.7-minimal depend on that separate package. > > Call it "python-base" or "python-common" or something. > > Why would python-minimal be configured at unpack time for python? AIUI, the > pre-depends would just require python-minimal to be unpacked prior to > configure, not unpack. No, that's what a regular depends does. A pre-depends requires a package to be configured before unpack. Policy 7.2: "This field is like Depends, except that it also forces dpkg to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency, as follows: When a package declaring a pre-dependency is about to be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or [special case for upgrade rather than install]" > Did you mean python can now be configured? > > I think pre-depends would solve the problem at hand, Unless I misunderstand the situation and your proposed solution, it most certainly will not. If what you mean is: python pre-depends python-minimal python-minimal depends python2.7-minimal Then a pre-depends is *not* what you need. If you mean something else, a Pre-Depends is probably still not what you need, because the cases in which a Pre-Depends is useful are actually pretty rare (I suspect that's why policy tells you to ask on this list before using it...). They are limited to two cases: - Your preinst (as opposed to your postinst) wants to use something that is *not* in the set of Essential packages, or - Your package wants to install files in a "special" directory which only exists in a "working" state if another package was installed first (e.g., multiarch-support) > but I'm also interested in feedback on the alternative proposed in the > bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769106#31 As long as an installation of python2.7-minimal without python2.7 will not break if the "rtinstall" script isn't run, that really looks like an alternate proposal of my "python-base"/"python-common" suggestion. What you need is for any scripts or binaries which you run in your postinst to be installed by packages that are either available in the Essential set, or in the set of packages that you depend on, directly or indirectly, through a depends or pre-depends. As long as you follow that rule, you're safe. A _reverse_ dependency (i.e., a package that depends on _your_ package) cannot safely provide a script or binary to be used in your postinst; and it does not matter whether you're using Depends or Pre-Depends in that case, because for postinst there is no difference. Regards, -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- 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/20141124021551.ga26...@grep.be
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Sat, Nov 22, 2014 at 11:42:41AM +0100, Wouter Verhelst wrote: > [...] > Before we enable a firewall by default, we should, IMO, have the > following: > > - A way for a user to configure it without understanding iptables. > - A way for a user to debug (without understanding iptables) if things > don't work. > - 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. > [...] I think ufw was built to accomplish all of the above goals. I'm not sure how well it works though -- I prefer to disable ufw and just do my own thing with iptables. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: systemd, fstab, noauto and nofail
Hi, Noel Torres: > Anyway I see that you do not use the noauto option. Is that on purpose? > What? It's the very first option. In any case, I can see why three entries for the same mountpoint don't exactly fit systemd's view of the world -- I wouldn't get that idea either, since "mount /media/photos" doesn't know which device to check. Thus, I'd fix this problem in a different way -- either with an udev rule that sets an appropriate symlink and/or outright mounts the volume when something gets inserted, or with udisksctl, or by telling your desktop environment to auto-mount. -- -- Matthias Urlichs signature.asc Description: Digital signature
