Re: [Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel
Le Vendredi 05 Août 2011 13:12:20 Florian Hubold a écrit : > Am 05.08.2011 11:39, schrieb Thierry Vignaud: > > On 5 August 2011 11:03, Luis Daniel Lucio Quiroz wrote: > >> Well i've only tried in *-desktop kernels > >> in > >> > >> 2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module > >> 3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in > >> pcmcia slot but after that nothing happens, I've tried loading by > >> hand ath5k module, but it doesnt works. iwconfig or ifconfig -a > >> commands doesnt shows nothing eighter. > >> > >> Just for your knowledge > > > > Please open a bug report instead of sending a mail. > > Paste output of "lspcidrake -v|egrep -i 'net|ath'" > > Also attach (ie do not paste) your dmesg output to the BR. > > There was a similar forum post for atk_htc, it just needed a newer firmware, > maybe you can adapt that to ath5k module: > https://forums.mageia.org/en/viewtopic.php?f=15&t=842 OK, before breaking my cauldron, what RPM shall i update so everybody getes beneficied of this LD
Re: [Mageia-dev] Cauldron Install borked
On 08/05/2011 03:12 PM, Thierry Vignaud wrote: Just fixed in SVN Thanks !
Re: [Mageia-dev] Newly added requires not getting satisfied. Bug 2097
On 08/05/2011 04:13 PM, David W. Hodgins wrote: On Fri, 05 Aug 2011 15:55:37 -0400, nicolas vigier wrote: On Fri, 05 Aug 2011, David W. Hodgins wrote: One user has reported in the usenet newsgroup alt.os.linux.mageia, that the update for kipi-plugins is failing with kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied hugin No problem installing this package for me. Do you have the full error message ? Just the above. I'll try to get more info from the user. The purpose of the update was to add a requires on hugin. When I was qa testing the update, I used urpmi to test that the install picked up hugin. Does mgaapplet only allow requires from the updates respository? No. Thanks, I was getting a little worried about that. The update tool doesn't pickup requires from core for an update package. Bug was already opened on an earlier update with the same issue (nothing done to fix it yet) https://bugs.mageia.org/show_bug.cgi?id=2155 Update is still blocked here on a machine if I only use the GUI tools (urpmi of course handles it ok) -- Stew Benedict
Re: [Mageia-dev] Newly added requires not getting satisfied. Bug 2097
On Fri, 05 Aug 2011 15:55:37 -0400, nicolas vigier wrote: On Fri, 05 Aug 2011, David W. Hodgins wrote: One user has reported in the usenet newsgroup alt.os.linux.mageia, that the update for kipi-plugins is failing with kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied hugin No problem installing this package for me. Do you have the full error message ? Just the above. I'll try to get more info from the user. The purpose of the update was to add a requires on hugin. When I was qa testing the update, I used urpmi to test that the install picked up hugin. Does mgaapplet only allow requires from the updates respository? No. Thanks, I was getting a little worried about that.
Re: [Mageia-dev] Newly added requires not getting satisfied. Bug 2097
On Fri, 05 Aug 2011, David W. Hodgins wrote: > > One user has reported in the usenet newsgroup alt.os.linux.mageia, > that the update for kipi-plugins is failing with > > kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied hugin No problem installing this package for me. Do you have the full error message ? > > The purpose of the update was to add a requires on hugin. > > When I was qa testing the update, I used urpmi to test that the install > picked up hugin. > > Does mgaapplet only allow requires from the updates respository? No.
[Mageia-dev] Re : Re: new samba-squid subpackage proporsal
Why condicional suggest? All what i'm asking is ti do that subpackage and then i place Suggests: samba-squid-helper At squid's spec I don't get your point. Connectés par MOTOBLUR™ -Message d'origine- De : Maarten Vanraes À : mageia-dev@mageia.org Envoyé : ven., 05 août 2011, 17:48:34 UTC+00:00 Objet : Re: [Mageia-dev] new samba-squid subpackage proporsal Op vrijdag 05 augustus 2011 19:05:43 schreef Luis Daniel Lucio Quiroz: > Le Vendredi 05 Août 2011 18:17:15 Maarten Vanraes a écrit : > > Op woensdag 03 augustus 2011 14:01:16 schreef Buchan Milne: > > > On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote: > > > > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne: > > > > > Samba-common is the right package for this. I see no need to > > > > > have a > > > > > squid- specific subpackage (and then samba-apache, > > > > > samba-freeradius, > > > > > with the same content, or all virtual packages just pulling > > > > > samba-common). > > > > > > > > > > Feel free to mess up your squid package by adding suggests on > > > > > samba-common, but since installing the right package is > > > > > trivially > > > > > solved by the admin and is a small portion of the work required, > > > > > I > > > > > would personally prefer not to increase the default footprint of > > > > > any > > > > > installation that pulls in squid. > > > > > > > > this is really imho an example where conditional suggests could work > > > > well: if you have squid already installed and you're installing > > > > samba, > > > > this subpackage could then be suggested. (and vice versa). > > > > > > But, it is irrelevant. samba-common is required by both samba-client > > > and samba-server, so you can't install samba without getting > > > ntlm_auth. > > > > there is definately a misunderstanding here, conditional suggests are not > > usefull for requires, only for suggests > > > > > This is really about whether squid should pull in any pieces of samba > > > by default, and could be solved by adding: > > > Suggests: samba-common > > > > > > to squid. But, I don't see much value, as this is a small part of the > > > work required to get a single-sign on authentication solution for squid > > > against AD. The default squid.conf already has example configs showing > > > that ntlm_auth is required, and all we are saving the user is a 'urpmf > > > ntlm_auth' and a 'urpmi samba-common'. However, there are many > > > scenarios squid can be deployed (e.g. SSO with GSSAPI, basic auth with > > > LDAP, PAM, NIS etc., no authentication, peer cache only etc.), and I > > > don't see a reason to pull in samba-common by default, when it saves > > > the admin very little effort. > > > > > > Regards, > > > Buchan > > > > well if it was in a separate package (and not in samba-common), it would > > be interesting to have conditional suggests. because then samba would > > pull it in; and squid too, without needing samba if you don't have it. > > > > but, maybe i'm misunderstanding this thread > > That's what i was asking > to create a new subpckage samba-helper-squid to stor ntlm_auth since > ntlm_auth is not linked with other lib it can stand by itself in a > independend subpackage to make a suggest from squid. But it seems Buchan > refuses. > > LD well, it's possible, but since there is no conditional suggests yet, i agree with Buchan. if there was conditional suggests, that would be better...
Re: [Mageia-dev] Cauldron Install borked
On 5 August 2011 18:24, Frank Griffin wrote: > Doing a fresh install, after partitioning but before package selection (last > popup shows "looking for installed packages"), you get an error panel > saying: > > An error occurred > rm of /mnt/var/cache/urpmi/mirrors.cache failed: No such file or directory > > Clicking OK sends you back to disk partitioning again. > > Why should a failed rm halt the install ? Just fixed in SVN
[Mageia-dev] Newly added requires not getting satisfied. Bug 2097
One user has reported in the usenet newsgroup alt.os.linux.mageia, that the update for kipi-plugins is failing with kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied hugin The purpose of the update was to add a requires on hugin. When I was qa testing the update, I used urpmi to test that the install picked up hugin. Does mgaapplet only allow requires from the updates respository? Should hugin be copied to the updates repository?
Re: [Mageia-dev] qt4 macros naming
On Fri, Aug 5, 2011 at 7:43 PM, Zé wrote:
> Hi,
>
> I have added qt macros with a more correct naming, but the old ones
> continue existing to avoid any breakage.
>
> The new qt4 macros (qt4.macros file):
>
> # New qt4 macros
> %_qt4_datadir %{_prefix}/lib/qt4
> %_qt4_bindir %{_qt4_datadir}/bin
> %_qt4_docdir %{_docdir}/qt4
> %_qt4_libdir %{_libdir}
> %_qt4_includedir %{_qt4_datadir}/include
> %_qt4_plugindir %{_libdir}/qt4/plugins
> %_qt4_demodir %{_qt4_datadir}/demos
> %_qt4_exampledir %{_qt4_datadir}/examples
> %_qt4_importdir %{_qt4_datadir}/imports
> %_qt4_translationdir %{_qt4_datadir}/translations
>
> If anyone with any suggest suggestion, please help improve
>
> regards,
> --
> Zé
>
you should not do such big commits at once because on your commit you
have not only changed the macros.
I am not a kde expert but i speak on rpm POV.
Has mikala reviewed all before you commited ?
Re: [Mageia-dev] new samba-squid subpackage proporsal
Op vrijdag 05 augustus 2011 19:05:43 schreef Luis Daniel Lucio Quiroz: > Le Vendredi 05 Août 2011 18:17:15 Maarten Vanraes a écrit : > > Op woensdag 03 augustus 2011 14:01:16 schreef Buchan Milne: > > > On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote: > > > > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne: > > > > > Samba-common is the right package for this. I see no need to > > > > > have a > > > > > squid- specific subpackage (and then samba-apache, > > > > > samba-freeradius, > > > > > with the same content, or all virtual packages just pulling > > > > > samba-common). > > > > > > > > > > Feel free to mess up your squid package by adding suggests on > > > > > samba-common, but since installing the right package is > > > > > trivially > > > > > solved by the admin and is a small portion of the work required, > > > > > I > > > > > would personally prefer not to increase the default footprint of > > > > > any > > > > > installation that pulls in squid. > > > > > > > > this is really imho an example where conditional suggests could work > > > > well: if you have squid already installed and you're installing > > > > samba, > > > > this subpackage could then be suggested. (and vice versa). > > > > > > But, it is irrelevant. samba-common is required by both samba-client > > > and samba-server, so you can't install samba without getting > > > ntlm_auth. > > > > there is definately a misunderstanding here, conditional suggests are not > > usefull for requires, only for suggests > > > > > This is really about whether squid should pull in any pieces of samba > > > by default, and could be solved by adding: > > > Suggests: samba-common > > > > > > to squid. But, I don't see much value, as this is a small part of the > > > work required to get a single-sign on authentication solution for squid > > > against AD. The default squid.conf already has example configs showing > > > that ntlm_auth is required, and all we are saving the user is a 'urpmf > > > ntlm_auth' and a 'urpmi samba-common'. However, there are many > > > scenarios squid can be deployed (e.g. SSO with GSSAPI, basic auth with > > > LDAP, PAM, NIS etc., no authentication, peer cache only etc.), and I > > > don't see a reason to pull in samba-common by default, when it saves > > > the admin very little effort. > > > > > > Regards, > > > Buchan > > > > well if it was in a separate package (and not in samba-common), it would > > be interesting to have conditional suggests. because then samba would > > pull it in; and squid too, without needing samba if you don't have it. > > > > but, maybe i'm misunderstanding this thread > > That's what i was asking > to create a new subpckage samba-helper-squid to stor ntlm_auth since > ntlm_auth is not linked with other lib it can stand by itself in a > independend subpackage to make a suggest from squid. But it seems Buchan > refuses. > > LD well, it's possible, but since there is no conditional suggests yet, i agree with Buchan. if there was conditional suggests, that would be better...
[Mageia-dev] qt4 macros naming
Hi,
I have added qt macros with a more correct naming, but the old ones
continue existing to avoid any breakage.
The new qt4 macros (qt4.macros file):
# New qt4 macros
%_qt4_datadir %{_prefix}/lib/qt4
%_qt4_bindir%{_qt4_datadir}/bin
%_qt4_docdir%{_docdir}/qt4
%_qt4_libdir%{_libdir}
%_qt4_includedir%{_qt4_datadir}/include
%_qt4_plugindir %{_libdir}/qt4/plugins
%_qt4_demodir %{_qt4_datadir}/demos
%_qt4_exampledir%{_qt4_datadir}/examples
%_qt4_importdir %{_qt4_datadir}/imports
%_qt4_translationdir%{_qt4_datadir}/translations
If anyone with any suggest suggestion, please help improve
regards,
--
Zé
Re: [Mageia-dev] Cauldron Install borked
On 08/05/2011 12:24 PM, Frank Griffin wrote: Doing a fresh install, after partitioning but before package selection (last popup shows "looking for installed packages"), you get an error panel saying: An error occurred rm of /mnt/var/cache/urpmi/mirrors.cache failed: No such file or directory Clicking OK sends you back to disk partitioning again. Why should a failed rm halt the install ? Switching to VC2 (busybox) and doing a "cp /dev/null /mnt/var/cache/urpmi/mirrors.cache" allows the install to proceed. "OK" sends you back to disl partitioning, and as long as you don't reformat the root partition (which would delete mirrors.cache), you're good to go.
Re: [Mageia-dev] Proposal for backport process and policy
Le vendredi 5 août 2011 19:05:21, nicolas vigier a écrit : > On Tue, 26 Jul 2011, Samuel Verschelde wrote: > > *** Old backports *** > > Remove old backports when newer ones are submitted > > - otherwise we let people use old bugged or plagged with security issues > > packages, when they don't necessarily know that there are problems with > > them - simpler choice : users have to choose between the version in > > updates and the one in backports, not more > > rpmdrake shows older versions too ? Yes. Samuel
Re: [Mageia-dev] new samba-squid subpackage proporsal
Le Vendredi 05 Août 2011 18:17:15 Maarten Vanraes a écrit : > Op woensdag 03 augustus 2011 14:01:16 schreef Buchan Milne: > > On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote: > > > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne: > > > > Samba-common is the right package for this. I see no need to > > > > have a > > > > squid- specific subpackage (and then samba-apache, > > > > samba-freeradius, > > > > with the same content, or all virtual packages just pulling > > > > samba-common). > > > > > > > > Feel free to mess up your squid package by adding suggests on > > > > samba-common, but since installing the right package is > > > > trivially > > > > solved by the admin and is a small portion of the work required, > > > > I > > > > would personally prefer not to increase the default footprint of > > > > any > > > > installation that pulls in squid. > > > > > > this is really imho an example where conditional suggests could work > > > well: if you have squid already installed and you're installing > > > samba, > > > this subpackage could then be suggested. (and vice versa). > > > > But, it is irrelevant. samba-common is required by both samba-client and > > samba-server, so you can't install samba without getting ntlm_auth. > > there is definately a misunderstanding here, conditional suggests are not > usefull for requires, only for suggests > > > This is really about whether squid should pull in any pieces of samba by > > default, and could be solved by adding: > > Suggests: samba-common > > > > to squid. But, I don't see much value, as this is a small part of the > > work required to get a single-sign on authentication solution for squid > > against AD. The default squid.conf already has example configs showing > > that ntlm_auth is required, and all we are saving the user is a 'urpmf > > ntlm_auth' and a 'urpmi samba-common'. However, there are many > > scenarios squid can be deployed (e.g. SSO with GSSAPI, basic auth with > > LDAP, PAM, NIS etc., no authentication, peer cache only etc.), and I > > don't see a reason to pull in samba-common by default, when it saves > > the admin very little effort. > > > > Regards, > > Buchan > > well if it was in a separate package (and not in samba-common), it would be > interesting to have conditional suggests. because then samba would pull it > in; and squid too, without needing samba if you don't have it. > > but, maybe i'm misunderstanding this thread That's what i was asking to create a new subpckage samba-helper-squid to stor ntlm_auth since ntlm_auth is not linked with other lib it can stand by itself in a independend subpackage to make a suggest from squid. But it seems Buchan refuses. LD
Re: [Mageia-dev] Proposal for backport process and policy
On Tue, 26 Jul 2011, Samuel Verschelde wrote: > > *** Old backports *** > Remove old backports when newer ones are submitted > - otherwise we let people use old bugged or plagged with security issues > packages, when they don't necessarily know that there are problems with them > - simpler choice : users have to choose between the version in updates and > the > one in backports, not more rpmdrake shows older versions too ?
[Mageia-dev] Cauldron Install borked
Doing a fresh install, after partitioning but before package selection (last popup shows "looking for installed packages"), you get an error panel saying: An error occurred rm of /mnt/var/cache/urpmi/mirrors.cache failed: No such file or directory Clicking OK sends you back to disk partitioning again. Why should a failed rm halt the install ?
Re: [Mageia-dev] new samba-squid subpackage proporsal
Op woensdag 03 augustus 2011 14:01:16 schreef Buchan Milne: > On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote: > > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne: > > > Samba-common is the right package for this. I see no need to have a > > > squid- specific subpackage (and then samba-apache, samba-freeradius, > > > with the same content, or all virtual packages just pulling > > > samba-common). > > > > > > Feel free to mess up your squid package by adding suggests on > > > samba-common, but since installing the right package is trivially > > > solved by the admin and is a small portion of the work required, I > > > would personally prefer not to increase the default footprint of any > > > installation that pulls in squid. > > > > this is really imho an example where conditional suggests could work > > well: if you have squid already installed and you're installing samba, > > this subpackage could then be suggested. (and vice versa). > > But, it is irrelevant. samba-common is required by both samba-client and > samba-server, so you can't install samba without getting ntlm_auth. there is definately a misunderstanding here, conditional suggests are not usefull for requires, only for suggests > This is really about whether squid should pull in any pieces of samba by > default, and could be solved by adding: > Suggests: samba-common > > to squid. But, I don't see much value, as this is a small part of the work > required to get a single-sign on authentication solution for squid against > AD. The default squid.conf already has example configs showing that > ntlm_auth is required, and all we are saving the user is a 'urpmf > ntlm_auth' and a 'urpmi samba-common'. However, there are many scenarios > squid can be deployed (e.g. SSO with GSSAPI, basic auth with LDAP, PAM, > NIS etc., no authentication, peer cache only etc.), and I don't see a > reason to pull in samba-common by default, when it saves the admin very > little effort. > > Regards, > Buchan well if it was in a separate package (and not in samba-common), it would be interesting to have conditional suggests. because then samba would pull it in; and squid too, without needing samba if you don't have it. but, maybe i'm misunderstanding this thread
Re: [Mageia-dev] RM replacement
Le Vendredi 05 Août 2011 08:58:12 andre999 a écrit : > Colin Guthrie a écrit : > > 'Twas brillig, and andre999 at 05/08/11 06:50 did gyre and gimble: > >> Luis Daniel Lucio Quiroz a écrit : > >>> Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit : > Luis Daniel Lucio Quiroz a écrit : > > Helo, > > > > As my experience in security field, to make Mageia more > > available in > > enterprise environments, and specially those that are security > > paranoid, i'm planning to port SRM. SRM is a package that does > > a > > "secure" file deleting according some security standards (i dont > > remember right now names, i guess it is something in NIST, but > > that > > doesnt matter really). > > > > My question is, what should be the procedure that when you > > install srm, then the normal rm command could be replaced? i > > was thinking in pushing an alias but what other alternatives do > > i have? > > > > please comment, > > > > LD > > At first glance that sounds like a reasonable approach EXCEPT -- a > system-level alias would be over-ridden by a user alias. > A user could innocently have an alias such as : > alias rm="rm -i" > > rm is in /bin > - /bin/rm could be replaced with a link to srm, but I don't know > if that would be considered acceptable. > rm would have to be restored if srm were uninstalled > > - wouldn't a link in /usr/bin/rm be executed first ? > Of course that doesn't cover execution with root privileges. > An alias in root wouldn't necessarily work, as an admin could > inadvertantly > replace it with another. (By loading a new file with some changed > alias, > for example.) > But probably less likely than some user doing the same on their > profile. > > There could be other approaches as well ... :) > >>> > >>> You are right! :) > >>> > >>> Well another option could be this: > >>> > >>> a. we change coreutils to install /bin/rm as /bin/rm.vanilla (or > >>> other name, > >>> that really doesnt matter), > >>> b. i change srm to install itself in /bin instead of /usr/bin > >>> c. we place alternatives in both packages to provide /bin/rm, giving > >>> preference to srm if installed, otherwise it will use rm of > >>> coreutils > >>> > >>> LD > >> > >> That would probably be the ideal approach. But it might take a while > >> to > >> get the changes accepted in coreutils. > >> > >> Maybe it could be all done from srm ? > >> On srm install, > >> a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?) > >> b. create /bin/rm link to /bin/srm > > > > Definitely not. It's against the commandments: Thou shalt not mess with > > another packages' files. > > ok. I suspected that. > It would be nice to have a list of these points for newer packagers. > > >> On srm uninstall, we ensure that > >> a. rm /bin/rm link > >> b. rename /bin/rm.vanilla to /bin/rm > >> > >> Hopefully that could be done reliably, with an uninstall script. > > > > No, this is very bad. > > > > It's what the alternatives system was designed to do for you, but I > > really don't think that something as fundamental as rm should be messed > > with in this way as I mentioned in my own email. > > > > srm is an add on userspace tool. To implement secure deletes properly, > > you would want support at a lower level (i.e in the kernel/fs). > > makes sense. > > > I think srm should just be a tool people use explicitly when they want > > to. > When I think about it, deleting with a pattern instead of just zeros is > probably only advantageous when a disk is being disposed of -- in which case > srm being a userspace tool is not a disadvantage. > > > Col Good point
Re: [Mageia-dev] Remove noarch packages in x86_64
On Tue, 26 Jul 2011, Thomas Spuhler wrote: > Can someone that has the powers please remove these noarch packages in the 64 > bit repos Why do they need to be removed ?
Re: [Mageia-dev] RM replacement
Am 05.08.2011 14:58, schrieb andre999: Colin Guthrie a écrit : I think srm should just be a tool people use explicitly when they want to. When I think about it, deleting with a pattern instead of just zeros is probably only advantageous when a disk is being disposed of -- in which case srm being a userspace tool is not a disadvantage. Col Well, if you want to dispose the disk, then i'd use something like Dariks Boot and Nuke (DBAN): http://www.dban.org/ It offers really secure methods of overwriting your data with varying patterns, and if you want to dispose a whole disk. then maybe an userspace tool to delete single files is not the best suited tool, IMHO.
Re: [Mageia-dev] RM replacement
Colin Guthrie a écrit : 'Twas brillig, and andre999 at 05/08/11 06:50 did gyre and gimble: Luis Daniel Lucio Quiroz a écrit : Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit : Luis Daniel Lucio Quiroz a écrit : Helo, As my experience in security field, to make Mageia more available in enterprise environments, and specially those that are security paranoid, i'm planning to port SRM. SRM is a package that does a "secure" file deleting according some security standards (i dont remember right now names, i guess it is something in NIST, but that doesnt matter really). My question is, what should be the procedure that when you install srm, then the normal rm command could be replaced? i was thinking in pushing an alias but what other alternatives do i have? please comment, LD At first glance that sounds like a reasonable approach EXCEPT -- a system-level alias would be over-ridden by a user alias. A user could innocently have an alias such as : alias rm="rm -i" rm is in /bin - /bin/rm could be replaced with a link to srm, but I don't know if that would be considered acceptable. rm would have to be restored if srm were uninstalled - wouldn't a link in /usr/bin/rm be executed first ? Of course that doesn't cover execution with root privileges. An alias in root wouldn't necessarily work, as an admin could inadvertantly replace it with another. (By loading a new file with some changed alias, for example.) But probably less likely than some user doing the same on their profile. There could be other approaches as well ... :) You are right! :) Well another option could be this: a. we change coreutils to install /bin/rm as /bin/rm.vanilla (or other name, that really doesnt matter), b. i change srm to install itself in /bin instead of /usr/bin c. we place alternatives in both packages to provide /bin/rm, giving preference to srm if installed, otherwise it will use rm of coreutils LD That would probably be the ideal approach. But it might take a while to get the changes accepted in coreutils. Maybe it could be all done from srm ? On srm install, a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?) b. create /bin/rm link to /bin/srm Definitely not. It's against the commandments: Thou shalt not mess with another packages' files. ok. I suspected that. It would be nice to have a list of these points for newer packagers. On srm uninstall, we ensure that a. rm /bin/rm link b. rename /bin/rm.vanilla to /bin/rm Hopefully that could be done reliably, with an uninstall script. No, this is very bad. It's what the alternatives system was designed to do for you, but I really don't think that something as fundamental as rm should be messed with in this way as I mentioned in my own email. srm is an add on userspace tool. To implement secure deletes properly, you would want support at a lower level (i.e in the kernel/fs). makes sense. I think srm should just be a tool people use explicitly when they want to. When I think about it, deleting with a pattern instead of just zeros is probably only advantageous when a disk is being disposed of -- in which case srm being a userspace tool is not a disadvantage. Col -- André
Re: [Mageia-dev] Problems with dbus
On 5 August 2011 00:23, JA Magallon wrote: > Hi... > > I'm on limited internet connection, so I'll be quick and dirty. > Plz, take a look at this mdv bug: > https://qa.mandriva.com/show_bug.cgi?id=63728 > > (copy) > the problem is a bug in > libdbus-glib-1_2 package, it is necessary a Debian patch > http://patch-tracker.debian.org/package/dbus-glib/0.94-4 > > I suffer it for Usb modem, and mdv package made it work. > Probably hurts more apps... > Patch added from upstream GIT https://bugs.freedesktop.org/show_bug.cgi?id=37852 (same patch). Please test. (I didn't see any rebuild of network*manager-* in Debian, so I am not sure a rebuild is required). And a bug report would have worked to track the issue. -- Ahmad Samir
Re: [Mageia-dev] [126688] - 0.94
On 19 July 2011 21:12, wrote:
> Revision 126688 Author cjw Date 2011-07-19 21:12:55 +0200 (Tue, 19 Jul 2011)
>
> Log Message
>
> - 0.94
>
> Modified Paths
>
> cauldron/dbus-glib/current/SPECS/dbus-glib.spec
>
> Modified: cauldron/dbus-glib/current/SPECS/dbus-glib.spec
> ===
> --- cauldron/dbus-glib/current/SPECS/dbus-glib.spec 2011-07-19 19:12:47 UTC
> (rev 126687)
> +++ cauldron/dbus-glib/current/SPECS/dbus-glib.spec 2011-07-19 19:12:55 UTC
> (rev 126688)
> @@ -1,13 +1,6 @@
> -#if %mandriva_branch == Cooker
> -# Cooker
> -%define release %mkrel 2
> -#%else
> -# Old distros
> -#define subrel 2
> -#define release %mkrel 1
> -#endif
> -%define glib2_version 2.6.0
> -%define dbus_version 0.94
> +%define release %mkrel 1
> +%define glib2_version 2.26.0
> +%define dbus_version 1.2.16
>
> %define lib_major 2
> %define lib_api 1
> @@ -18,13 +11,12 @@
>
> Summary: D-Bus message bus
> Name: dbus-glib
> -Version: 0.88
> +Version: 0.94
> Release: %release
> URL: http://www.freedesktop.org/Software/dbus
> Source0:
> http://dbus.freedesktop.org/releases/%name/%{name}-%{version}.tar.gz
> License: AFL and GPLv2
> Group: System/Libraries
> -BuildRoot: %{_tmppath}/%{name}-%{version}-root
> BuildRequires: glib2-devel >= %{glib2_version}
> BuildRequires: dbus-devel >= %{dbus_version}
> BuildRequires: libxml2-devel
> @@ -63,7 +55,7 @@
> %setup -q
>
> %build
> -
> +autoreconf -fi
Hello,
The issue or running autoreconf in spec files is still unresolved, either:
- We only run it when needed (i.e. a patch that modifies configure.ac,
Makefile.{am,in}, building with a newer/older libtool) OR
- We run it in all the specs of packages that use libtool
Right now in most specs we only run it when needed, except some specs
you modified (like this one).
I am not with or against (don't have enough knowledge about libtool),
just pointing out that if autoreconf should be run for all packages
using libtool, then the policy should be clarified and applied to all
specs.
> %configure2_5x \
> --disable-tests \
> --disable-verbose-mode \
> @@ -99,9 +91,9 @@
> %{_libdir}/pkgconfig/dbus-glib-%{lib_api}.pc
> %{_includedir}/dbus-1.0/dbus/dbus-glib-bindings.h
> %{_includedir}/dbus-1.0/dbus/dbus-gtype-specialized.h
> -%{_includedir}/dbus-1.0/dbus/dbus-glib-error-enum.h
> %{_includedir}/dbus-1.0/dbus/dbus-glib-lowlevel.h
> %{_includedir}/dbus-1.0/dbus/dbus-glib.h
> +%{_includedir}/dbus-1.0/dbus/dbus-gvalue-parse-variant.h
> %{_datadir}/gtk-doc/html/dbus-glib/
> %{_mandir}/man1/*
>
>
>
--
Ahmad Samir
Re: [Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel
Am 05.08.2011 11:39, schrieb Thierry Vignaud: On 5 August 2011 11:03, Luis Daniel Lucio Quiroz wrote: Well i've only tried in *-desktop kernels in 2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module 3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in pcmcia slot but after that nothing happens, I've tried loading by hand ath5k module, but it doesnt works. iwconfig or ifconfig -a commands doesnt shows nothing eighter. Just for your knowledge Please open a bug report instead of sending a mail. Paste output of "lspcidrake -v|egrep -i 'net|ath'" Also attach (ie do not paste) your dmesg output to the BR. There was a similar forum post for atk_htc, it just needed a newer firmware, maybe you can adapt that to ath5k module: https://forums.mageia.org/en/viewtopic.php?f=15&t=842
Re: [Mageia-dev] RM replacement
Buchan Milne skrev 5.8.2011 13:42: On Friday, 5 August 2011 12:14:14 Colin Guthrie wrote: Otherwise users may be duped into a false sense of security by installing the "secure deletes" package and then delete files thorough Nautilus or Konq under the false impression they are securely deleted. Or from another Mageia host with a stock rm over NFS or similar, or from a non-Mageia client via Samba, sftp or fish etc., DAV or any of the non- commandline ways of deleting a file. And another problem with "secure erase" both on tool and filesystem level... It wont work on SSDs due to their firmware implemented wear leveling ... really think srm should stay as parallell installable with original rm intact. -- Thomas
Re: [Mageia-dev] RM replacement
On Friday, 5 August 2011 12:14:14 Colin Guthrie wrote: > Otherwise users may be duped into a false sense of security by > installing the "secure deletes" package and then delete files thorough > Nautilus or Konq under the false impression they are securely deleted. Or from another Mageia host with a stock rm over NFS or similar, or from a non-Mageia client via Samba, sftp or fish etc., DAV or any of the non- commandline ways of deleting a file. Regards, Buchan
Re: [Mageia-dev] new samba-squid subpackage proporsal
On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote: > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne: > > Samba-common is the right package for this. I see no need to have a > > squid- specific subpackage (and then samba-apache, samba-freeradius, > > with the same content, or all virtual packages just pulling > > samba-common). > > > > Feel free to mess up your squid package by adding suggests on > > samba-common, but since installing the right package is trivially solved > > by the admin and is a small portion of the work required, I would > > personally prefer not to increase the default footprint of any > > installation that pulls in squid. > this is really imho an example where conditional suggests could work well: > if you have squid already installed and you're installing samba, this > subpackage could then be suggested. (and vice versa). But, it is irrelevant. samba-common is required by both samba-client and samba-server, so you can't install samba without getting ntlm_auth. This is really about whether squid should pull in any pieces of samba by default, and could be solved by adding: Suggests: samba-common to squid. But, I don't see much value, as this is a small part of the work required to get a single-sign on authentication solution for squid against AD. The default squid.conf already has example configs showing that ntlm_auth is required, and all we are saving the user is a 'urpmf ntlm_auth' and a 'urpmi samba-common'. However, there are many scenarios squid can be deployed (e.g. SSO with GSSAPI, basic auth with LDAP, PAM, NIS etc., no authentication, peer cache only etc.), and I don't see a reason to pull in samba-common by default, when it saves the admin very little effort. Regards, Buchan
Re: [Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel
On 5 August 2011 11:03, Luis Daniel Lucio Quiroz wrote: > Well i've only tried in *-desktop kernels > in > > 2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module > 3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in pcmcia > slot but after that nothing happens, I've tried loading by hand ath5k module, > but it doesnt works. iwconfig or ifconfig -a commands doesnt shows nothing > eighter. > > Just for your knowledge Please open a bug report instead of sending a mail. Paste output of "lspcidrake -v|egrep -i 'net|ath'" Also attach (ie do not paste) your dmesg output to the BR.
Re: [Mageia-dev] RM replacement
05.08.2011 13:17, Colin Guthrie kirjutas: I think srm should just be a tool people use explicitly when they want to. Col +1 -- Sander
Re: [Mageia-dev] RM replacement
'Twas brillig, and andre999 at 05/08/11 06:50 did gyre and gimble: > Luis Daniel Lucio Quiroz a écrit : >> Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit : >>> Luis Daniel Lucio Quiroz a écrit : Helo, As my experience in security field, to make Mageia more available in enterprise environments, and specially those that are security paranoid, i'm planning to port SRM. SRM is a package that does a "secure" file deleting according some security standards (i dont remember right now names, i guess it is something in NIST, but that doesnt matter really). My question is, what should be the procedure that when you install srm, then the normal rm command could be replaced? i was thinking in pushing an alias but what other alternatives do i have? please comment, LD >>> >>> At first glance that sounds like a reasonable approach EXCEPT -- a >>> system-level alias would be over-ridden by a user alias. >>> A user could innocently have an alias such as : >>> alias rm="rm -i" >>> >>> rm is in /bin >>> - /bin/rm could be replaced with a link to srm, but I don't know if that >>> would be considered acceptable. >>> rm would have to be restored if srm were uninstalled >>> >>> - wouldn't a link in /usr/bin/rm be executed first ? >>> Of course that doesn't cover execution with root privileges. >>> An alias in root wouldn't necessarily work, as an admin could >>> inadvertantly >>> replace it with another. (By loading a new file with some changed >>> alias, >>> for example.) >>> But probably less likely than some user doing the same on their profile. >>> >>> There could be other approaches as well ... :) >> >> You are right! :) >> >> Well another option could be this: >> >> a. we change coreutils to install /bin/rm as /bin/rm.vanilla (or >> other name, >> that really doesnt matter), >> b. i change srm to install itself in /bin instead of /usr/bin >> c. we place alternatives in both packages to provide /bin/rm, giving >> preference to srm if installed, otherwise it will use rm of coreutils >> >> LD > > That would probably be the ideal approach. But it might take a while to > get the changes accepted in coreutils. > > Maybe it could be all done from srm ? > On srm install, > a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?) > b. create /bin/rm link to /bin/srm Definitely not. It's against the commandments: Thou shalt not mess with another packages' files. > On srm uninstall, we ensure that > a. rm /bin/rm link > b. rename /bin/rm.vanilla to /bin/rm > > Hopefully that could be done reliably, with an uninstall script. No, this is very bad. It's what the alternatives system was designed to do for you, but I really don't think that something as fundamental as rm should be messed with in this way as I mentioned in my own email. srm is an add on userspace tool. To implement secure deletes properly, you would want support at a lower level (i.e in the kernel/fs). I think srm should just be a tool people use explicitly when they want to. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] RM replacement
'Twas brillig, and Luis Daniel Lucio Quiroz at 05/08/11 02:16 did gyre and gimble: > Le Vendredi 05 Août 2011 02:03:22 nicolas vigier a écrit : >> On Fri, 05 Aug 2011, Colin Guthrie wrote: >>> 'Twas brillig, and Luis Daniel Lucio Quiroz at 04/08/11 21:26 did gyre >>> >>> and gimble: Helo, As my experience in security field, to make Mageia more available in enterprise environments, and specially those that are security paranoid, i'm planning to port SRM. SRM is a package that does a "secure" file deleting according some security standards (i dont remember right now names, i guess it is something in NIST, but that doesnt matter really). My question is, what should be the procedure that when you install srm, then the normal rm command could be replaced? i was thinking in pushing an alias but what other alternatives do i have? >>> >>> Well you could theoretically use alternatives, but I would suspect that >>> such a fundamental tool as rm would probably be very dangerous to >>> package in that way (the alternatives scripts themselves may use rm!) >>> >>> So I think an alias would be best, but it'll only cover users/scripts >>> calling rm and not general unlinking... It likely won't cover GUIs and >>> other deletion methods. With that in mind, is it work aliasing rm at all >>> seeing as it'll only catch a subset of "delete" operations? You wouldn't >>> want to give a false sense of security after all... >> >> Yes, this would be better done on filesystem/kernel. Like this : >> http://thread.gmane.org/gmane.comp.file-systems.ext4/26548 > > I got your poing, however i remember that SRM uses some specific algorithmis > that are recomended in NIST, thats why i remember we chose SRM and we void > zero filling techniques. Even still, Nicolas's point remains that this system (even if it uses special algorithms rather than just zero'ing) would be better implemented somewhere lower rather than in a single userspace tool. I'm not saying the userspace tool is not useful in the event that the underlying system does not have the capabilities, but using an alias or otherwise making the standard rm command == srm, is IMO just a token gesture and does not really address wider security concerns. IMO it would be better to just provide the tool and let people who specifically want secure delete use it manually when needed. Otherwise users may be duped into a false sense of security by installing the "secure deletes" package and then delete files thorough Nautilus or Konq under the false impression they are securely deleted. That's just my thoughts on it tho'. :) Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
[Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel
Helo Well i've only tried in *-desktop kernels in 2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module 3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in pcmcia slot but after that nothing happens, I've tried loading by hand ath5k module, but it doesnt works. iwconfig or ifconfig -a commands doesnt shows nothing eighter. Just for your knowledge LD
