Re: [Mageia-dev] Please remove qemu, and qemu-img from Mageia 3.
- Original Message - On Sun, 03 Feb 2013 04:16:54 -0500, Pascal Terjan pter...@gmail.com wrote: On Sun, Feb 3, 2013 at 9:45 AM, David W. Hodgins davidwhodg...@gmail.com wrote: During testing of updates to qemu, and x11-driver-video-qxl, it has become very clear that no-one could possibly be using these packages, as they are so slow, as to be useless. Try loading kvm module and selecting the fast drivers for network/disk/... lsmod|grep kvm kvm_amd 55516 0 kvm 413942 1 kvm_amd Whether it's loaded or not doesn't seem to make any difference. If I add the -enable-kvm option, it fails with ... KVM not supported for this target No accelerator found! There isn't much point letting it proceed. Checking under htop shows it's clearly cpu bound, using 2 of my 4 cores. The command I used to run qemu was ... qemu-system-x86_64 -cdrom $Iso -hda mageia$Arch.qcow2 -boot d -net nic -net user,net=192.168.10.0/16,host=192.168.10.3 -m 4096 -vga qxl with the Iso and Arch variables set appropriately. Suggestions for faster disk/network options? It's significantly easier with libvirtd and virt-manager, but there's not much point if you haven't got hardware virtualisation enabled. Given that other people do find it useful, it's obvious there's something wrong either with the options I'm using (or not using), or my hardware or bios settings. Hopefully it's not the hardware. The cpu is an AMD FX(tm)-4170 Quad-Core Processor, with the following flags shown in /proc/cpuinfo ... flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr core arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold svm is the flag in question for basic hardware virtualisation on AMD (vmx for Intel), however many BIOSs ship with hardware virtualisation disabled by default. Regards, Buchan
Re: [Mageia-dev] web virtual management solution
On 08/01/2013 17:50, Armando B. wrote: Hi friends, i looking in svn repo for some solution about KVM web management solution, but i haven't founded applications. I used, for a little virtual cluster, VirtualBox + VbTool + phpVirtualbox (all presents in our repo). For KVM there is great virt-manager for cli gui but nothing for web gui. Searching online i saw: http://www.openqrm-enterprise.com http://www.ovirt.org/Home https://www.webvirtmgr.net http://archipelproject.org http://karesansui-project.info/ https://code.osuosl.org/projects/ganeti-webmgr packaging of some of these is difficult for dependencies not already in our repo, perhaps ganeti could be more simple to package (in repo missing only 2 packages: python-whoosh and django-fields) what do you think about ? Would we have a web management solution for KVM in Mageia ? I started packaging ovirt, but on my Mageia 2 system, and I got stuck on a java dependency. I should probably import the packages that succeeded so far. Regards, Buchan
Re: [Mageia-dev] db5.3 rebuilds still needed
On Thursday, 2 August 2012 01:34:17 Charles A Edwards wrote: The following is a list of the apps which still require libdb-5.2.so()/(64bit) that need a rebuild for db5.3 apr-util-dbm-db c-icap-client c-icap-modules c-icap-modules-extra cyrus-imapd cyrus-imapd-murder cyrus-imapd-nntp cyrus-imapd-utils cyrus-sasl dsniff evolution-data-server evolution-exchange evolution-exchange heimdal-libs hotkeys inn iproute2 lib64ebackend1.2_4 libreoffice-core libreoffice-core mutt mutt-utf8 netatalk ocaml-dbm ocaml-ocsigenserver openldap-servers pam_abl perl perl-BDB perl-BerkeleyDB perl-Cyrus perl-DB_File php-dba poedit python ruby-bdb satsolver-demo satsolver-tools sendmail squid squidguard Warning: If you have any of the above installed and have task-obsolete installed it Will remove the above listed apps. Why? Isn't that a bit premature? Especially considering it seems almost everyone will have perl and task-obsolete (I didn't ask for it, and I have it). IOW, this will break any systems where users aren't looking carefully. Regards, Buchan
Re: [Mageia-dev] db5.3 rebuilds still needed
On Thursday, 2 August 2012 01:34:17 Charles A Edwards wrote: The following is a list of the apps which still require libdb-5.2.so()/(64bit) that need a rebuild for db5.3 apr-util-dbm-db c-icap-client c-icap-modules c-icap-modules-extra cyrus-imapd cyrus-imapd-murder cyrus-imapd-nntp cyrus-imapd-utils cyrus-sasl dsniff evolution-data-server evolution-exchange evolution-exchange heimdal-libs hotkeys inn iproute2 lib64ebackend1.2_4 libreoffice-core libreoffice-core mutt mutt-utf8 netatalk ocaml-dbm ocaml-ocsigenserver openldap-servers pam_abl perl perl-BDB perl-BerkeleyDB perl-Cyrus perl-DB_File php-dba poedit python ruby-bdb satsolver-demo satsolver-tools sendmail squid squidguard Warning: If you have any of the above installed and have task-obsolete installed it Will remove the above listed apps. Why? Isn't that a bit premature? Especially considering it seems almost everyone will have perl and task-obsolete (I didn't ask for it, and I have it). IOW, this will break any systems where users aren't looking carefully. Regards, Buchan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-3-21.mga3
On Wednesday, 1 August 2012 05:29:55 fwang wrote: fwang fwang 3-21.mga3: + Revision: 277136 - obsolete db5.2 in favour of db5.3 Funda, Before you push a change like this, you should ensure you aren't going to break people's machines and make cauldron uninstallable. Regards, Buchan
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On Thursday, 5 July 2012 20:34:02 David Walser wrote: Guillaume Rousse wrote: So, before any further contribution from my side, I'd like the people in charge of security updates to find some internal agreement about what kind of help they expect from other people exactly. If that's just to push a non-discussable list of changes into spec files, they could as well ask for SVN commit and package submission rights, to do it directly. This would avoid a large amount of anger and frustration for everyone. Nobody is in charge, which is part of the problem. I think a lot of us packagers come from Mandriva where we were used to Oden being in charge of updates for stable distros, and therefore not having to worry about it. While Mandriva had a security team (before Oden, Stew, and before that Stew and Vince). However, that doesn't mean you never had to worry about anything. We are a community distro, we have no paid security manager. It is all of our responsibility to do security updates for stable distros. As far as what kind of help is expected, it varies per bug really. Some of them have maintainers that might want to give input. Some I would like to know from someone else more experienced or who has more at stake in a package how to handle an update when there are choices. Sometimes other distros have pushed an updated (bugfix-only) version, or patched other bugs as well, rather than just patched the security bug. IMHO, for a security, the priority is to get the patched binaries out to vulnerable users as soon as possible. If there is a pre-existing minor issue with the originally released package which an experienced user of the software in question can get around without any problems, a separate bug should be filed, but the minor issue should *NEVER* delay the update. If the software doesn't start with the default config, the user isn't vulnerable, and we can take more time to fix their problem. If the admin has fixed the default config issue, then THEY ARE VULNERABLE. For *SECURITY* bugs, addressing their vulnerability is the priority. Otherwise, we may as well not distinguish between bugfix and security updates. My expectation is that: 1)Old security fixes should have the highest priority 2)Any new security fix should have higher priority than any bugfix 3)Security updates should be provided within 1 week max Yes, QA team doesn't have enough resources. Guess what, neither do other teams. But, for me, it was frustrating to dedicate time (when I really didn't have it) to provide packages within 48 hours (24 for Mageia 2), and then have a 3-4 week delay in validation, mainly because of some minor pre-existing issues with the Mageia 1 package (which had been solved in the Mageia 2 relase package). Regards, Buchan
Re: [Mageia-dev] Backports Summary
On Tuesday, 26 June 2012 22:25:10 Thomas Backlund wrote: So, we have been discussing this many times, and not gotten any satisfactory decision to go ahead yet... Sorry for the late reply, but as some of you are aware, I have had some problems replying to Mageia-related mails (which are finally resolved). First off, we decided long ago that backports will be better supported than during mdv times, This may be an unfair generalisation. meaning security and bugfixes and has to pass QA. In some cases, this is a basic feature of backports. For example, the primary targets of my backports typically ship new releases for any security fix, and bugfixes are typically released in new releases (and only in severe cases do we cherry-pick the bugfix from a new release for a bugfix update). In the case of samba, openldap etc., my primary motivation for wanting backports is so that we can provide early bugfixes (which in most cases have been well tested by the rest of the upstream community) with less delay than cherry-picking bugfixes, QA, etc. The other motivation for me, is to make newly packaged software in cauldron available to stable releases. The probability of a security update being required is usually quite low in this case. Now for references: * we have the backports policy: https://wiki.mageia.org/en/Backports_policy I think we are over-engineering everything here. See for example: https://www.google.com/search?q=%22main/backports%20openldap-2.4%22%20site:lists.mandriva.com For openldap, since upstream doesn't really look at bugs on old releases, I backported every new release to every version that had a build system available. In all that time, there was only ever one bug reported on the backports, due to a NMU backport. * Last discussions started by Stormi: * [Mageia-dev] Backports policy clarification (and discussion) https://www.mageia.org/pipermail/mageia-dev/2012-June/016265.html * [Mageia-dev] Proposed Feature:Backports_update_applet https://www.mageia.org/pipermail/mageia-dev/2012-June/016263.html * It also came up in the discussion about fixing bug 2317: * [Mageia-dev] bug 2317 revisited: --update option should behave like --search-media https://www.mageia.org/pipermail/mageia-dev/2012-June/016692.html People seem to agree on most things, but there is a few questions that need to be decided how to handle. Lets start with the summary and suggestion of how to get it started: (addendum / refinements / important points of current backports policy) * backports is supported as long as the rest of the release But this is not a committment to always backport every already-backported package. * packages must always be in cauldron first Of course. * if you want to backport a package someone else is maintainer for, you need to discuss with maintainer first. if he dont want the package to be backported _and_ have valid reasons, respect that. (if you disagree, you can still ask council) * if you backport anything, (regardless if you are the real maintainer or not) you accept the responsibility of handling the bugreports against the backport and make sure it gets patched (or upgraded) to get security fixes. * cherrypicking backports must work, so requires need to be checked and be strict to make sure they work Agreed, but it is not critical to QA every possible combination of packages. Users are able to resolve these problems themselves, and report the problem. * nothing in backports must require the use of --nodeps or --force to get it to install * QA will do basic tests to make sure it works and obeys the rules * QA can deny package(s) to be backported if it breaks the policy * QA has /updates as priority, and /backports will be handled if/when there is time, so if you want faster response, join QA to help out with the workload. Hmm, in many cases, I actually test backports on the stable release myself before submitting them ... I am concerned QA will become a bottle-neck that doesn't necessarily always add much value. Now a point that got raised during discussion of bug 2317: * if a backport break because of something ending up in /updates it's a bug to be reported against the backport (and not against the released update) as packages ending up in /updates are only validated against /release and /updates (and rightfully so as thats how they are built too) And some important points to avoid making backports_testing a dumping ground for package(r)s trying to avoid the policy: * after submitting anything to backports_testing you have 48 hours to file/assign a Backport to validate at bugs.mageia.org. * package needs to be validated within 1 month (or shorter/longer time if QA wants that) * failure to match any of the two timelimits will get the package removed from updates_testing again. (I understand this will
Re: [Mageia-dev] Please push openldap
On Sunday, 29 April 2012 19:49:07 Sander Lepik wrote: 28.04.2012 15:04, Thierry Vignaud kirjutas: On 28 April 2012 07:04, Luis Daniel Lucio Quiroz dlu...@okay.com.mx wrote: Please push openldap, it fixes #5605 That is? Please describe the bug next time instead of forcing everyone to go look at bugzilla. Thx Can someone try to resubmit this one. mga#5605 is about broken init script (wrong syntax for awk). I thought I had fixed this one, but I guess not ... I was hoping to look at other systemd stuff. For some reason it failed build (test054 failed). Tho' it builds on my local iurt. I have added one patch that reverts some commits that might fix this failing test. More about it here: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7162;page=3 I did actually have a fix for this queued up in my local checkout, along with some other important fixes from git, but then 2.4.30 release (including these fixes) was imminent, and then after that some regressions in 2.4.30 meant 2.4.31 was about to be released, but that missed version freeze. Please try and use patches from git (whether from gitweb or git itself). The patches you included in openldap-2.4.29-fix-test054.patch are actually the following two commits: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=a255e44bf0fcb703a3a5ac58117fd54a00727fd1 http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=10c81e2a46c9b603ba1dfcf53422573d5068ba04 Regards, Buchan
Re: [Mageia-dev] bug, omission or feature
On Sunday, 3 June 2012 17:52:47 Colin Guthrie wrote: On the whole, this kind of security is basically bullshit anyway. You can't make that assessment without understanding the rest of the security environment. It might make things a tiny bit harder, but if you can get into the bootloader to append a 1 on the command line, Maybe you *can't* append anything you like to the command-line. Maybe the bootloader configuration has a 'boot single' option, which should require entry of the root password to access the system. you can also append init=/bin/bash too which totally bypasses everything too. Not if the bootloader configuration is password protected (IOW, you can boot any configured option, but if you want to modify anything, you need to provide a password, different from the root password). So while it's maybe a nice idea, for all practical purposes, it's not any kind of real security anyway, so don't rely on it! No security implementation relies on a single control being in place. A numebr of modern security best practices have thousands of controls, and the requirement for a password to be entered to boot single is almost always one of them, and a requirement for a bootloader password is usually another. Regards, Buchan
Re: [Mageia-dev] List of packages on svn but not in the packages repository
On Wednesday, 2 May 2012 00:21:06 nicolas vigier wrote: Hello, The following list of packages are on the svn in the cauldron directory, but are not in the packages repository. This should be packages that have been renamed, obsoleted, or imported but never submitted. I plan to move them to the directory obsolete, unless someone notice an error and think some of them should be resubmitted. evolution-mapi This requires some packages from samba4 (see below) to build. openldap-smbk5pwd I thought I had submitted, but it needs to be updated to 2.4.29 anyway. Please don't remove it, I will try and update it today. samba4 This one I haven't been able to fix an undefined symbols issue: [3297/3845] Linking default/source4/heimdal_build/libroken-samba4.so [3298/3845] Linking default/lib/ccan/libccan.so [3299/3845] Linking default/nsswitch/libwinbind-client.so [3300/3845] Linking default/source3/libsmbd_shim.so [3301/3845] Linking default/lib/socket_wrapper/py-socket-wrapper.so [3302/3845] Linking default/lib/util/libwrap_xattr.so default/lib/socket_wrapper/py_socket_wrapper_1.o: In function `py_socket_write': py_socket_wrapper.c:(.text+0x6b): undefined reference to `swrap_send' default/lib/socket_wrapper/py_socket_wrapper_1.o: In function `py_socket_sendall': py_socket_wrapper.c:(.text+0x115): undefined reference to `swrap_send' default/lib/socket_wrapper/py_socket_wrapper_1.o: In function `py_socket_send': py_socket_wrapper.c:(.text+0x1b5): undefined reference to `swrap_send' [...] Please don't remove it. Regards, Buchan
[Mageia-dev] Freeze push: cifs-utils
We update to 5.4 to address CVE-2012-1586 (bug for Mageia 1: 5714). r234507 Regards, Buchan
[Mageia-dev] Freeze push: samba 3.6.5
Please push samba-3.6.5, it fixes CVE-2012-2111 (no other changes). The current package also now has samba-virusfilter enabled (replacing samba- vscan that has been disabled for a long time), but this has no impact on users who don't install the packages and explicitly enable the VFS modules. However, if this change isn't desired, the 3.6.5 update was committed separately in r234445 Regards, Buchan
Re: [Mageia-dev] No time right now
On Saturday, 28 April 2012 19:26:37 Luis Daniel Lucio Quiroz wrote: I will have a very bussi weekend, can anyone help me to fix openldap? Enviado desde mi teléfono Verizon Wireless If the bug had been assigned to me, I would have looked at it, as I would have seen it (as I saw other openldap bugs with new comments over the weekend), but I didn't have time to read all of my mailing lists ... and skimming wouldn't have helped, since you didn't include 'openldap' in this subject ...
Re: [Mageia-dev] Please push openldap
On Sunday, 29 April 2012 19:49:07 Sander Lepik wrote: 28.04.2012 15:04, Thierry Vignaud kirjutas: On 28 April 2012 07:04, Luis Daniel Lucio Quiroz dlu...@okay.com.mx wrote: Please push openldap, it fixes #5605 That is? Please describe the bug next time instead of forcing everyone to go look at bugzilla. Thx Can someone try to resubmit this one. mga#5605 is about broken init script (wrong syntax for awk). I thought I had fixed this one, but I guess not ... I was hoping to look at other systemd stuff. For some reason it failed build (test054 failed). Tho' it builds on my local iurt. I have added one patch that reverts some commits that might fix this failing test. More about it here: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7162;page=3 I did actually have a fix for this queued up in my local checkout, along with some other important fixes from git, but then 2.4.30 release (including these fixes) was imminent, and then after that some regressions in 2.4.30 meant 2.4.31 was about to be released, but that missed version freeze. Please try and use patches from git (whether from gitweb or git itself). The patches you included in openldap-2.4.29-fix-test054.patch are actually the following two commits: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=a255e44bf0fcb703a3a5ac58117fd54a00727fd1 http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=10c81e2a46c9b603ba1dfcf53422573d5068ba04 Regards, Buchan
Re: [Mageia-dev] Removing Core 32bit from x86_64
On Friday, 24 February 2012 13:09:45 Pierre Jarillon wrote:
I have just installed Mga2b1 x86_64 and it is already a great distro. But
once more, I was annoyed with an unuseful bunch of rpm in rpmdrake which
make the list less readable.
Then rpmdrake shouldn't be showing libraries by default.
For a beginner, this is more annoying.
So, I have unselected Core 32 bit and everything seams to be ok. As pcpa
said in [Cooker] Multilib next steps?, the only reason to run in 32 bit
mode is legacy binaries that cannot be rebuilt.
Or to run wine on x86_64.
Or to run other proprietary applications/libraries provided by vendors (not
necessarily apps we have in non-free).
IMHO, Mandriva is going backwards in this regard.
$ rpm -qa --qf '%{ARCH} %{NAME}\n'|grep -Ev '(^x86_64|noarch|i586 lib|
\(none\))'
i586 wine32
i586 opera
i586 googleearth
i586 playonlinux
i386 teamviewer6
i586 skype
i586 acroread
i586 wine
i386 oracle-xe
i586 python-psyco
i586 wine-gecko
i386 ICAClient
IMO, the last useful binary was flashplugin, now the adobe 64bit binary
works fine. Is it still useful to keep this outgrowth alive?
Provide good, in-distro documentation on how to resolve 32-bit dependencies,
or IMHO removing the 32bit repos is a regression. We are a *very* long way
from adequate documentation.
Regards,
Buchan
Re: [Mageia-dev] Removing Core 32bit from x86_64
On Friday, 24 February 2012 13:14:30 nicolas vigier wrote: On Fri, 24 Feb 2012, Pierre Jarillon wrote: I have just installed Mga2b1 x86_64 and it is already a great distro. But once more, I was annoyed with an unuseful bunch of rpm in rpmdrake which make the list less readable. For a beginner, this is more annoying. I have also noticed that some people are confused by x86_64 and i586 packages in rpmdrake. Maybe instead rpmdrake should only show one entry in the table per package name, and in the detail, show releases and architectures, allowing the user to choose, but defaulting to e.g. x86_64 on x86_64, and allowing the user to specify their preference for non-free, tainted etc.? I think rpmdrake should only show x86_64 packages on x86_64 by default. So, rpmdrake shouldn't show get-skype or wine32? That sounds less usable to me. Regards, Buchan
Re: [Mageia-dev] Removing Core 32bit from x86_64
On Friday, 24 February 2012 14:30:10 Antoine Pitrou wrote: On Fri, 24 Feb 2012 14:26:04 +0200 Buchan Milne bgmi...@staff.telkomsa.net wrote: I think rpmdrake should only show x86_64 packages on x86_64 by default. So, rpmdrake shouldn't show get-skype or wine32? That sounds less usable to me. I guess it could hide 32-bit packages when there's a 64-bit counterpart. (or gray them out, or something) That is similar to what I said in the part you cut out, but it doesn't provide any benefit for packages that appear in multiple 'sections', e.g. a tainted vs free version of vlc or something. Regards, Buchan
Re: [Mageia-dev] Error message while trying checkout a package?with mgarepo
On Saturday, 11 February 2012 16:22:52 Dimitrios Glentadakis wrote: Στις Σάββατο 11 Φεβρουάριος 2012 15:00:42 nicolas vigier γράψατε: On Sat, 11 Feb 2012, Dimitrios Glentadakis wrote: Στις Σάββατο 11 Φεβρουάριος 2012 14:41:59 nicolas vigier γράψατε: On Sat, 11 Feb 2012, Dimitrios Glentadakis wrote: What could be wrong ? Did you try to do a checkout on packages svn repository without mgarepo to see if that works ? svn co svn+ssh://svn.mageia.org/svn/packages/cauldron/null/current it works, it gave me this: [dglent@localhost mgarepo]$ svn co svn+ssh://svn.mageia.org/svn/packages/cauldron/null/current Password: Password: It shouldn't ask you for password if you uploaded your ssh key on https://identity.mageia.org/ in https://identity.mageia.org/ i choose sshPublicKey i add my key , i clic ok but there is no field added Hmm, works for me on my unprivileged test account. Was any error message displayed? - (also i did it a second time and i did nt see that was the field Mobile, and i added in the mobile field. Now impossible to delete it. I have the message page not fount) - The sshPublicKey attribute is currently present, with this value: ssh-dss B3NzaC1kc3MAAACBALDU48OvlZuu+bgoFkNFrFX9IFm/4NfS2ykhjSYzcqOjPICmPBA8E6ilNqin11Hr5S/YdN74W9VhqLU2GQMRIwj9lnPnjUkmsDZPTvGrqB7EDGPuEGJ49z/ftCaIlUxO9nRa+6A4CViMpFVK+XppDfwyDFYT6F4/E10kHw3wAg5bFQCCJ3+u8ioy2BqJoljV9OhzcCctKwAAAIBuxwSP+CUZrzMSe1LN5Bd2W1Jlam0ctCn8Bti8XNelyXCkaFUhqz1m3f/NLMYhldQVICGYeeRPELb/9HWLHLIihXODta4xTgVauSokJduusBQxfZ5S7jJC53eQmfs/98QbGAuWfWJO0Y4BnHc3rSpmL/E8lbVMJ6gTlECA3F9fqIBzR5dMT+v1znesQasj7t4XpB7gFUVSZOO17Fm225i40Bj0viDl3m+q9oMXhxOw3lbuGClKAaD1CnGjR+mGRG+/blUI6yusmVkBn+P0zONGInSftwwzi3HMjGoacbgVXGa5qvEXQcfLlXTRii74Xzna8Xx54TdG2rygi2efzDPmBw== dglent@localhost I have deleted the 'mobile' attribute on your account. I tested with my unprivileged test account, and I could add and remove 'mobile' without problems. However, I could not remove an existing sshPublicKey, in which case I get the 'Page not found' message. But I could change the value of the existing sshPublicKey value. i tried again to see if the key was applied somehow in the background of the identity.mageia.org but it asks me always for a password You may want to provide output of ssh-add -l, and 'ssh -v svn.mageia.org' ? Regards, Buchan
Re: [Mageia-dev] Official VM images for Mageia 2?
On Wednesday, 25 January 2012 17:30:23 Romain d'Alverny wrote: Hi there, I'd like to discuss/plan how we can build and distribute ready to use VM images of Mageia 2 along with original ISOs, from our download pages. Generic VM images, or ones targetted at specific uses? If specific uses, it might be worthwhile considering live ISOs targetted at the use case with installation support. In my case, I would consider looking at a minimal XBMC-based (possibly with samba and a few other tools as well) live ISO/USB. Target VMs: Xen, VMWare, Virtualbox, Vagrant (with a minimal install + specific config), other, you name it, as long as it can be managed (best would be to have these build automatically from source ISOs + ad-hoc auto_install.cfg + post install conf). Most of these tools support OVF, so do we have tools that can generate OVF easily? BTW., I have access to a VMWare vSphere environment with capaticy to run a few extra VMs (for testing images). For images for VMWare, it may also be worthwhile including some of the VMWare tools (there are open-source versions, and I believe Ubuntu ships these): http://sourceforge.net/projects/open-vm-tools/ (We have X11 driver and mouse input driver, but these should provide drag 'n' drop, window resize, memory ballooning, guest shutdown etc.). What about publishing official images to Amazon EC2? Uses can be: evaluation, development/staging environments, you name it too. hurdman has some experience and is a first volunteer to work on this; others? (input, recipes, hands). I don't know if there is that much value in providing specific VM images, when instead we may want to look at providing good tools for sharing VM configs and tools for easily generating images from those configs. Some interesting tools which we don't seem to have yet: http://libguestfs.org/ http://libguestfs.org/virt-v2v/ http://libguestfs.org/virt-copy-in.1.html http://libguestfs.org/virt-tar-in.1.html http://libguestfs.org/febootstrap.8.html Regards, Buchan
Re: [Mageia-dev] Build system currently broken
On Thursday, 26 January 2012 11:03:09 Pascal Terjan wrote: Hi everyone, I don't have time to restore previous systemd package currently, but the new one broke the build system: Installation failed: lockdev is needed by systemd-39-2.mga2.x86_64 Do we need more validation on packages that are dependencies of the build system?
Re: [Mageia-dev] Official VM images for Mageia 2?
On Thursday, 26 January 2012 13:37:38 Romain d'Alverny wrote: On Thu, Jan 26, 2012 at 11:16, Buchan Milne bgmi...@staff.telkomsa.net wrote: On Wednesday, 25 January 2012 17:30:23 Romain d'Alverny wrote: Generic VM images, or ones targetted at specific uses? If specific uses, it might be worthwhile considering live ISOs targetted at the use case with installation support. In my case, I would consider looking at a minimal XBMC-based (possibly with samba and a few other tools as well) live ISO/USB. I would consider at least those 3: - a generic minimal system install ISO (quick to download and base from which we can generate more elaborate images) - equivalent generic minimal system VM - derivatives: - a Vagrant image (same as above + a specific user/packages setup) - your XBMC-based one I started playing with a boot.iso + auto_inst.cfg (this is really great, we ought to document it better somewhere about it) + Vagrant a few weeks ago, but didn't make it yet. Will clean this up and post it somewhere. Target VMs: Xen, VMWare, Virtualbox, Vagrant (with a minimal install + specific config), other, you name it, as long as it can be managed (best would be to have these build automatically from source ISOs + ad-hoc auto_install.cfg + post install conf). Most of these tools support OVF, so do we have tools that can generate OVF easily? No idea. What about publishing official images to Amazon EC2? Yes! I don't know if there is that much value in providing specific VM images, when instead we may want to look at providing good tools for sharing VM configs and tools for easily generating images from those configs. I'd say both. Sharing configs and tools is great, having a few small images available is great too for those that prefer to focus on using it at once (and for cloud hosts too). If we were to automate the process, could we chain somehow this: - bcd with a minimal system image Why? Do you want to provide an installable (ie, drakx) ISO, that requires the user to click through the installation? If not, skip this. - isocheck - vmbuild? foreach each vm config provided (we can store all this in svn), does: - push specific auto_inst script into the install ISO Rather: 1)Install -use virt-install to boot a VM with auto_install pointing to official repo or -modify draklive to install into raw volumes (which also uses auto_install) 2)Convert raw volumes to OVF - run the ISO into the virtual environment - package the VM - checks - deliver to download Regards, Buchan
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Thursday, 12 January 2012 22:25:51 Christian Lohmaier wrote: Hi Florian, On Thu, Jan 12, 2012 at 8:42 PM, Florian Hubold doktor5...@arcor.de wrote: Am 12.01.2012 19:01, schrieb Christian Lohmaier: [..] PS: Maybe next time you could improve on your wording, the policy may currently be incorrect, not reflecting good packaging practices, but as it's only a policy written by humans, it's not dumb. Just a hint. ;) No, I disagree. The policy as written is dumb in my opinion. I wouldn't say it is dumb, I would say it is conservative. Can you off-hand provide a list of which of our ~10 000 packages have a 'maintained bugfix only branch with regular releases' policy? I would expect it is less than 5%. Granted, this may include a number of large/important packages. But, I can also post some counter-examples: -samba (but, it may be useful to have some not-strictly-bugfix changes, as some are 'compatability with the new SP of some other popular OS') -openldap If you publish a policy, and the policy is incorrect, the whole process of using policies is worthless. So I /have/ to assume that the policy reflects the decisions/conclusions from the discussions by people running the project. I think some of the existing policies may have been done in haste. IMHO, there should be a policy on policies, covering how they are agreed upon, how amendments are agreed up etc. To me it stays a silly/stupid policy. Please provide a proposal for changes to the policy. Regards, Buchan
Re: [Mageia-dev] Existing Cauldron VM users willing to test gnome-boxes?
On Friday, 13 January 2012 11:47:39 Olav Vitters wrote: On Thu, Jan 12, 2012 at 06:14:46PM -0500, Scott Chevalley wrote: I'm using KVM for a windows 7 vm and I just tried to use gnome-boxes to create, I guess, a vm for a drbl live cd and it created it but when I launch it the app just shows a black screen and doesn't do anything. Thanks for testing! I'm getting the same black screen. Have you tried connecting with spicec ? So it seems it doesn't work anyone :-( Did you launch it from the terminal? Any debug output? There's not much documentation so I'm not sure exactly what's supposed to happen versus what is happening. You should be seeing the VM. It uses something new called 'splice'. I think that is where the error lies. The Fedora version of qemu 0.15 had some patches which they dropped in qemu 1.0. I'm hoping qemu 1.0 solves the issues, but wasn't able to compile it yesterday. Splice is pretty nice as you can e.g. share your USB somehow between the host and the VM (gnome-boxes has a checkbox, but no clue about the technical details). I think you mean 'spice', which is a remote desktop protocol, which covers display, sound, device sharing, printing etc. (AFAIU). I am more interested in the spice support in the libvirt/virt-manager tools ... but I am not running cauldron. I'll be happy to do some more testing if you can give me some pointers as to what I'm looking for. The debug output from the terminal would be nice, as well as $HOME/.libvirt/qemu/log/*. I really want to get this working before the next Mageia testversion is released.. I would like to see virt-manager with spice support, and support in the distribution for spice when a VM under qemu with spice support (spice-vdagent stuff). Regards, Buchan
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wednesday, 11 January 2012 20:22:23 Antoine Pitrou wrote: On Wed, 11 Jan 2012 12:43:35 -0500 Juan Luis Baptiste juan...@mageia.org wrote: Sure, you cannot be save of regressions, but what makes you think you are smarter than upstream? What makes you so sure that not the one commit you add as a patch to your package is the one that causes the regressions? Because as I said earlier, we backport the commit that fixes that single issue, based on the info found on the bugzilla report of the upstream project. But how do you choose which patches you want to backport from the stream of bugfixes done by upstream? Speaking for myself, and using openldap as an example: 1)I am active on the mailing lists (e.g. openldap-technical) 2)I am subscribed to the bugs mailing list (openldap-its) 3)I check commits in git for the OPENLDAP_REL_ENG_2_4 branch Typically, if I see 'crasher' in the commimt, I'll look at using that patch for an update. Should the packager monitor all bug fixing activity? (sure (s)he *can*, but that's a lot of work) Just because someone doesn't file a bug against Mageia doesn't mean the bug doesn't bother anybody, because many users don't report upstream bugs to the distro's tracker. (also, other users don't bother reporting bugs at all :-)) And this is the reason I would like to see backports, so I can: 1)Provide bugfix and security updates with no regressions, in updates 2)Provide latest upstream stable release in backports, so a user can conveniently contribute (e.g. bug reports) upstream. But, note that pushing unwanted packages to 99% of our users is not a solution either, we don't want to be Fedora, where every month you effectively have a new distribution ... Regards, Buchan
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wednesday, 11 January 2012 22:05:53 Antoine Pitrou wrote: On Wed, 11 Jan 2012 14:41:54 -0500 Juan Luis Baptiste juan...@mageia.org wrote: As I said, when there's a bug report on mga, we start investigating the problem and go and look at upstream for a bug report there for *that* particular bug. So let me repeat myself from two messages above (!): “Just because someone doesn't file a bug against Mageia doesn't mean the bug doesn't bother anybody, because many users don't report upstream bugs to the distro's tracker.” Why not? IMHO, a user who experiences a bug has two effective paths they can follow to get a bugfix: 1)File a bug with the distribution, and have the distribution worry about reporting or fixing the bug and providing an update 2)File a bug upstream, when the bug is fixed uptream, file a bug with the distributor, referencing the upstream bug An approach that doens't include a bug filed with the distribution means the user doesn't really seem interested in receiving an update from the distribution. If you just want every new piece of software as soon as possible, you should run Cauldron. If you believe every bugfix-only-release from every piece of software should be pushed out by distributions, can you clarify: 1)Why users who are not affected by some obscure bug (e.g. typo in a man page they will never read) should be forced to download unnecessary packages (at high cost in some cases) 2)How you will identify all upstreams which have a good history of bugfix-only releases, and how you will automate the selection of these packages to go to updates, and how you will streamline this process through QA. Anyway, you seem to be of the assumption that all the contributors to the distribution you are using have so much more time on their hands than you do, while in actual fact I believe almost all contributors are *very* contstrained on time. If you don't think it is worth your time to help out, why should we waste time (which could be used to ensure the next release has all bugfixes) on new bugfix releases we don't need? Regards, Buchan
[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
I am trying to get rt (3.8.11) into the distro (a package that I am using on a different distro in a production environment), to be followed up with the rt (4.0.4) I have queued (which I am testing in preparation for upgrading our production environment). I would really like to get this package into the distro, but it is being rejected (http://pkgsubmit.mageia.org/uploads/rejected//cauldron/core/release/20120110140334.buchan.valstar.18287.youri) due to: Submission errors, aborting: - rt-3.8.11-1.mga2.noarch: - dir-or-file-in-usr-local /usr/local/lib/rt/plugins - dir-or-file-in-usr-local /usr/local/lib/rt - dir-or-file-in-usr-local /usr/local/lib/rt/po - dir-or-file-in-usr-local /usr/local/lib/rt/lib - dir-or-file-in-usr-local /usr/local/etc/rt - dir-or-file-in-usr-local /usr/local/lib/rt/html The documented way for extending RT is by installing files in this location. We can either: 1)Make it more difficult for users to extend RT with local plugins etc. 2)Fix rpmlint 3)Not have RT misc, you have experience of both rt and rpmlint, can you provide an opinion? Would it be possible to separate 'dir-or-file-usr-local' into separate rules (one for files, one for dirs)? While I agree we shouldn't ship files in /usr/local, I don't see why we shouldn't ship dirs in /usr/local ... Regards, Buchan
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Thursday, 12 January 2012 11:27:59 Antoine Pitrou wrote: On Thu, 12 Jan 2012 11:05:34 +0200 Buchan Milne bgmi...@zarb.org wrote: An approach that doens't include a bug filed with the distribution means the user doesn't really seem interested in receiving an update from the distribution. Do note there are bugs that may go unnoticed by the user even though they are affected (for example if they have to do with resource consumption or subtle data corruption or other reliability stuff). Right, and in most cases, upstreams should make enough noise about issues like that so maintainers know to push an update. Upstreams that don't are irresponsible, or have their heads in the ground. If you just want every new piece of software as soon as possible, you should run Cauldron. Obviously, that's not what I want. 1)Why users who are not affected by some obscure bug (e.g. typo in a man page they will never read) should be forced to download unnecessary packages (at high cost in some cases) This is already the case. Regularly Mageia suggests me updates that I have not asked for since I have not filed a bug for them (and may not even be affected). 'users who are unaffected' and 'I didn't ask for an update' are vastly different things. But, it seems you also don't want to get an unnecessarily huge volume of updates ... Besides, your example is silly: I don't know of a software project that makes new releases only to fix typos in man pages. Bugfix releases *do* contain worthwhile fixes. Sure, but on average, probably 75% or more of the software in a release will have some upstream release that has at least one bugfix in it per year, does that mean that we should ship updates to 75% of the packages for each supported distro every year? 2)How you will identify all upstreams which have a good history of bugfix-only releases, and how you will automate the selection of these packages to go to updates, and how you will streamline this process through QA. Each packager can decide if their upstream package is well-behaved or not. Of course, better be conservative and not package bugfix releases if you aren't totally confident. Still, some upstream teams *are* well-behaved. Right, and this is (mostly) done, although IMHO the updates policy needs to be updated to make this more explicit. Anyway, you seem to be of the assumption that all the contributors to the distribution you are using have so much more time on their hands than you do, while in actual fact I believe almost all contributors are *very* contstrained on time. Relying on upstream for bug fixes may actually free some of the time spent doing custom patching and testing. You assume: 1)Upstream and packager have no relationship 2)Bugfixes are done in isolation But I agree volunteer time is a big blocker in most open source projects. If you don't think it is worth your time to help out, why should we waste time (which could be used to ensure the next release has all bugfixes) on new bugfix releases we don't need? Usually bugs are fixed for a reason (i.e. they affect someone somewhere). Why you think people don't need bug fixes is beyond me: That wasn't the argument. The argument is that there is a cost to every update, and the question that has to be answered is whether the minimal improvement in some package is worth the time, effort, resource, bandwidth involved, or whether the user is better served by having a completely up-to- date minimal-bug-affected-release 2 months later, than having 1000 updates shipped every month and a new low quality release in 2 months, which forces more updates down their expensive internet connection, leaving them with a high cost, low quality experience. Mageia users aren't, presumably, more stupid / more careless than users of other distributions. No, but the point of Mageia is to provide a usable distribution, not one where you get breakage every 2nd week due to supposed 'bugfix' releases of new software. Regards, Buchan
Re: [Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
On Thursday, 12 January 2012 11:55:07 Colin Guthrie wrote: 'Twas brillig, and Buchan Milne at 12/01/12 09:12 did gyre and gimble: I don't see why we shouldn't ship dirs in /usr/local ... I don't really see the point in shipping the dirs personally. Any separate extension that is packaged should not go into /usr/local anyway, No one ever said they would, you snipped the part of my mail saying that 'locally installed' customisations, IOW, ones not managed by the package manager etc., go there. so these folders are purely for users doing this manually. Yes. And that's why we provide /usr/local/share/applications? /me wonders if 'filesystem' would make it through the BS. I would expect that the make install stage of any extension installation would automatically create those folders anyway, so I really don't see the benefit of adding these empty folders into a package. So, why would 'make isntall' of rt, which has been configured to itself live in a system location, explicitly create these directories? The gain in doing so seems minimal to the point of useless. I can remove the dirs in the package, but also, what is the benefit? On a system dedicated to running a request tracking system, should we explicitly make it more difficult to run said system that it would be if installed from source? Of course if extensions do not have installer scripts then the user will have to create those folders themselves, but if they are following a manual recipe anyway, what's an extra mkdir during that process going to cost them? Very little IMO. Disclaimer: I have no experience of rt itself, so I could be missing something contextual here. Well, I haven't myself used extensions that live here, because I have to be careful not to deliver something one of our vendors is contracted to deliver. I'll test one on my laptop ... Regards, Buchan
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Thursday, 12 January 2012 16:45:39 Johnny A. Solbu wrote: On Thursday 12 January 2012 10:05, Buchan Milne wrote: many users don't report upstream bugs to the distro's tracker.” Why not? Why should they? As far as the average Joe is concerned they should only have to file a bug one place. This is how many of them think. And I agree with them. 1)File a bug with the distribution, and have the distribution worry about reporting or fixing the bug and providing an update 2)File a bug upstream, when the bug is fixed uptream, file a bug with the distributor, referencing the upstream bug My experience is that if they file a bug report in the first place, they Either contact the upstream developer or the distribution's bugzilla team. I covered this in (1). They never do both, as they believe that doing both is a waste of time, since the fixed version eventually find it's way to the distribution anyway. Sure, it will, on the next release of the distribution, assuming the new upstream release was before version freeze. An approach that doens't include a bug filed with the distribution means the user doesn't really seem interested in receiving an update from the distribution. Incorrect assumption. As someone who is the support service for some users I have some experience with this. They assume that any serious bug will be fixed in one of the next releaces, But this *is* the case. What we are talking about *here*, is that the bugfix update be shipped to old releases. because that's how it works with Microsoft. Yes, non-critical release will be shipped in next SP, a year or so later. And they haven't heard of anyone filing any bug at Microsoft. Just because they haven't, doesn't mean it doesn't happen. The bugs just get fixed without them ever repporting anything, and they assume that this is how things are supposed to work. Sometimes they even think that what we consider as bugs, they believe it is how things are supposed to work. If they're not happy with how the system works, they often conclude that Linux Sucks Ass, and move back to Windows or OS X. But, your comparison is invalid. Users must pay for the privilege of upgrading to get non-critical bugfixes the latter, and wait quite some time for the former. Regards, Buchan
[Mageia-dev] Signature verification of sources
I think we should be in the position to be able to verify the origin of any
software we provide to users.
While we have cryptographic verification of the RPMS (both 'binary' and src),
and we store the hashes of the sources, AFAIK we do very limited verification
of any signatures provided by upstream.
Now, unfortunately, not all upstreams provide useful signatures:
1)Not all upstreams provide signatures (some even say that there is no point,
as no-one verifies them)
2)Some upstreams (such as kernel) use automated mechanisms to generate
signatures (and in the case of kernl explicitly state that they are only
useful for verifying that they match what is on kernel.org, not necessarily
that they match what linus generated)
3)Some upstreams do provide signatures, but sometimes the signing identity
changes, or the mechanism (sign gzipped tarball once, unzipped tarball next
time)
It seems difficult to argue for upstreams to provide good signatures if no-one
is verifying them
So, I have started adding signature verification to my packages where upstream
provides signatures:
-tevent
-tdb
-ldb
-samba
In the past few weeks, I have been moving to defining and using a 'check_sig'
macro, and I wonder if it would be useful to move it to spec-helper, and start
using it wherever possible.
This is the version in the ldb spec:
%define check_sig() export GNUPGHOME=%{_tmppath}/rpm-gpghome \
if [ -d $GNUPGHOME ] \
then echo Error, GNUPGHOME $GNUPGHOME exists, remove it and try again; exit
1 \
fi \
install -d -m700 $GNUPGHOME \
gpg --import %{1} \
gpg --trust-model always --verify %{2} %{?3} \
rm -Rf $GNUPGHOME \
Used as follows:
Source: http://samba.org/ftp/ldb/ldb-%{ldbver}.tar.gz
Source1: http://samba.org/ftp/ldb/ldb-%{ldbver}.tar.gz.asc
Source2: jelmer.asc
[...]
%prep
%check_sig %{SOURCE2} %{SOURCE1} %{SOURCE0}
Producing:
+ export GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
+ GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
+ '[' -d /home/bgmilne/tmp/rpm-gpghome ']'
+ install -d -m700 /home/bgmilne/tmp/rpm-gpghome
+ gpg --import /home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/jelmer.asc
gpg: keyring `/home/bgmilne/tmp/rpm-gpghome/secring.gpg' created
gpg: keyring `/home/bgmilne/tmp/rpm-gpghome/pubring.gpg' created
gpg: /home/bgmilne/tmp/rpm-gpghome/trustdb.gpg: trustdb created
gpg: key 1EEF5276: public key Jelmer Vernooij jel...@samba.org imported
gpg: key D729A457: public key Jelmer Vernooij jel...@samba.org imported
gpg: Total number processed: 2
gpg: imported: 2 (RSA: 1)
gpg: no ultimately trusted keys found
+ gpg --trust-model always --verify
/home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/ldb-1.1.4.tar.gz.asc
/home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/ldb-1.1.4.tar.gz
gpg: Signature made Sat 03 Dec 2011 01:14:25 SAST using RSA key ID D729A457
gpg: Good signature from Jelmer Vernooij jel...@samba.org
gpg: aka Jelmer Vernooij jel...@sernet.de
gpg: aka Jelmer Vernooij jel...@apache.org
gpg: aka Jelmer Vernooij jel...@debian.org
gpg: aka Jelmer Vernooij jel...@ubuntu.com
gpg: aka Jelmer Vernooij jel...@vernstok.nl
gpg: aka Jelmer Vernooij jel...@canonical.com
gpg: aka Jelmer Vernooij jel...@openchange.org
gpg: aka Jelmer Vernooij jrverno...@tigris.org
gpg: aka Jelmer Vernooij jelmer.verno...@canonical.com
gpg: WARNING: Using untrusted key!
gpg: Signature made Sat 03 Dec 2011 01:14:25 SAST using DSA key ID 1EEF5276
gpg: Good signature from Jelmer Vernooij jel...@samba.org
gpg: aka Jelmer Vernooij jel...@fsfe.org
gpg: aka Jelmer Vernooij jel...@sernet.de
gpg: aka Jelmer Vernooij jel...@debian.org
gpg: aka Jelmer Vernooij jel...@ubuntu.com
gpg: aka Jelmer Vernooij jrver...@cs.uu.nl
gpg: aka Jelmer Vernooij jel...@vernstok.nl
gpg: aka Jelmer Vernooij jel...@openchange.org
gpg: aka Jelmer Vernooij jrverno...@tigris.org
gpg: aka Jelmer Vernooij jel...@a-eskwadraat.nl
gpg: WARNING: Using untrusted key!
+ rm -Rf /home/bgmilne/tmp/rpm-gpghome
Tampering with the source results in:
+ export GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
+ GNUPGHOME=/home/bgmilne/tmp/rpm-gpghome
+ '[' -d /home/bgmilne/tmp/rpm-gpghome ']'
+ install -d -m700 /home/bgmilne/tmp/rpm-gpghome
+ gpg --import /home/bgmilne/Download/source/svn/mageia/ldb/SOURCES/jelmer.asc
gpg: keyring `/home/bgmilne/tmp/rpm-gpghome/secring.gpg' created
gpg: keyring `/home/bgmilne/tmp/rpm-gpghome/pubring.gpg' created
gpg: /home/bgmilne/tmp/rpm-gpghome/trustdb.gpg: trustdb created
gpg: key 1EEF5276: public key Jelmer Vernooij jel...@samba.org imported
gpg: key D729A457: public key Jelmer Vernooij jel...@samba.org imported
gpg: Total number processed: 2
gpg: imported: 2 (RSA: 1)
gpg: no ultimately trusted keys found
+ gpg --trust-model
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wednesday, 11 January 2012 06:32:50 Johnny A. Solbu wrote: On Wednesday 11 January 2012 03:28, Luis Daniel Lucio Quiroz wrote: I mean, stop asking updates for mageia 1 just because there is another newversion. May I suggest that next time, say it in so many words. Some of us are not good at reading between the lines, and your original post was written in a way that indicated that it was not clear on that you where talking about just what you said you where talking about in your last post. :-)= And I agree with you. Updating packages in a released product just because a new version is out is not a valid reason by itself. If on the other hand it fixes some bugs or security holes, it's worth considering. Resolving the backports situation would however provide a means for users who want to track upstream (for various reasons, such as being able to get support from upstreams who don't really want to support 'historic' releases) without: 1)Forcing all users to get the update 2)Requiring excessive QA work 3)Requiring bug reports for each update Regards, Buchan
Re: [Mageia-dev] references to outside web sites/wiki
On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote: On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu coo...@solbu.net wrote: On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote: wiki.mandriva.com may be shut down for good in just a few days What? Are Mandriva serisouly considering closing down the Wiki? Mandriva is on the path to filing for bankruptcy on January 16th. There may be more consequences / preparation than ensuring our web content is fully independant. We may need to consider: 1)Prepare for upgrading our servers from Mandiva 2010.x to Mageia (1?). However, I know for a fact that some packages we have on them are not available in Mageia yet. 2)Ensuring we are ready for users who are still on Mandriva to migrate to Mageia. IMHO, this should mean: -Backports media resolved -Highlighting documentation on upgrading / switching (e.g. downgrading from Mandriva 2011 to Mageia 1, even if it is by exporting package leaf list and backing up /etc, /usr/local/ etc. and re-install keeping /home) such as http://www.mageia.org/en/1/migrate/ on the Wiki and website/blog post -Forum section dedicated to assisting users migrating? -Blog post prepared, something that commenters on various news sites can point to in replies? -Possibly considering contacting large mirror sites (e.g. mirrors.kernel.org) who currently mirror Mandriva, but not Mageia? -A concerted effort to start producing comprehensive documentation, as soon we may not be able to point users to online copies of Mandriva documentation (I personally need to upgrade 3 of my machines and a few machines of friends/family/colleagues) Regards, Buchan
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On Sunday, 11 December 2011 19:43:35 Florian Hubold wrote: \ Whatever the decision is, maybe we could tie this to some conditions: Only allow backports if there are near-zero security/critical bugs for the stable release or if there are no open bugs for the package in question? Well, my first question is, *who* is *responsible* for security updates? This is not specified in the updates policy (the role assigned to build the security update is named 'Maintainer (or any interested packager)', but who is responsible for checking that we have all applicable updates? In Mandriva, it was the responsibility of the security team (with cooperation from the maintainer in some cases). At some stage we also need to look at providing vulnerability data in a suitable format that supports automated validation (e.g. OVAL?), and a site able to browse advisories. Just some random crazy idea ... IMHO we should focus on security and bugfixes for the stable release, and there are currently too many security bugs open, some for a really long time, where nothing is happening for months, yet we still talk and concern about opening backports. FYI: the reason I have been slow on updates for Mageia is that I still have systems running Mandriva, precisely because the bacports situation has not been finalised, and I don't want to submit all missing packages in Mageia 1 to updates. Once backports is open, I can drop some Mandriva packages, and spend more time contributing to Mageia. So, you can't necessarily say that backports steals time from updates ... Regards, Buchan
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On Saturday, 10 December 2011 13:32:12 Michael Scherer wrote:
Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
Well, the backport issue ( ie :
- no garantee of keep the distribution upgradable
Backports will probably provide a better probability of upgradability than
3rd-party repos.
- no security )
No means to provide a security updates that has followed a QA process in the
event package version Z no longer builds on distribution with version X in
release and version Y in backports.
But, note that without backports, users who wanted version Y would either:
-Switch to a distro that has version Y (worse) - I would guess 20%
-Switch to using cauldron, and start contributing (better) - I would guess 5%
or less
-Use Cauldron package on stable release (worse) - I would guess about 30%
-Build package from source (worse) - I would guess about 20%
-Rebuild cauldron package on stable release (same) - I wold guess about 10%
-Keep version X (better) and eventually become upset about age of software
(worse) - I would guess about 15%
So, only one outcome would be better, one would be the same, and the other 3
outcomes would be worse, and probably be the majority of outcomes.
In the case where there is no problem with providing the update, backports is
superiour, and would provide a better outcome in every case.
Do we have any idea on how many packages this ever affected in Mandriva?
have also not been fixed, so that's rather unfair to
... ?
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1/package/{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
I thought the whole point of Backports was to provide a streamlined way to
provide newer versions of packages that already exist in Cauldron, with
minimal effort, to stable releases. This increases the incentive for users on
stable releases to contribute to Cauldron in some way, and doesn't increase
the burden on the maintainer significantly. There should be no need to have
distribution release-specific content in any of the packages.
In the rare case a package can't be provided like this, maybe it isn't a good
candidate for backports?
Then in practice, that mean having a 2nd/3rd distribution ( because
there is a separate 2nd svn branch, and a 3rd one for later ) and so
that's a big no for me. Having 2+ branchs is just asking for trouble
when they are not in sync ( and since keeping everything in sync
properly with svn is a pain if there is a divergence, this will not be
done ).
Worst, if we do like in mdv and propose 2 way of backporting ( submit
from cauldron, submit from a branch ), this will create a mess of having
some packages from cauldron, some from the branch, and people having no
way from knowing where does a package come from. This also make the
system harder to maintain and to follow, and rather impossible to script
properly.
So that's also to be avoided.
Having a separate branch where people can write also remove the only
incentive I have seen for backports, ie, wider testing of our packages,
because they may not really the same as in cauldron.
So here is what I propose :
- have X branchs, but do not let anyone commit on it, besides a system
user. When a package is submitted to cauldron, it is also copied to this
branch, ie, we make sure current is in sync. The same goes for version
N-1 being copied from N once a backported rpm have been submitted to be
used by people. Once a distribution is no longer supported, we close the
branch, and disable the sync.
- backports are only submitted from the branch, with separate
markrelease, tags, whatever. This let us have proper audit of backports,
and who did what.
- packagers still need to commit and submit on cauldron before any
backports. So we miss no fixes or anything by mistake. We also make sure
that cauldron is always the highest version possible, thus permitting at
least some form of upgrade. ( either stable to stable, provided
backports are used, or stable to cauldron ). And we also ensure that
backports are done first on the most recent stable version, for the same
reason ( ensure some form of upgrade path, as asked several time by
users ).
So, we have two copies of identical packages, that are always in sync, and can
never diverge.
What is the point then? Just to allow
Re: [Mageia-dev] How broken are RPM dependencies allowed to be?
On Wednesday, 14 December 2011 04:04:39 Liam R E Quin wrote: On Tue, 2011-12-13 at 16:31 -0800, Dan Fandrich wrote: I raised a bug ticket on drakxtools (#3731) because the RPM in Cauldron installs without complaints in Mageia 1 but won't work there because it requires a newer version of perl. This is unsupported. Maybe you should instead contribute documentation that makes this more explicitly obvious, but it is a well-known rule in Mandriva and Mageia (and usually applies to other distros as well). If this weren't the case, there wouldn't be a need for backports ... The perl dependency in the RPM is listed as perl-base when it should really be something like perl-base = 5.14.2 (Mageia 1 ships with version 5.12.3). The response I got was that such an upgrade (from release to Cauldron) wasn't supported and this bug was likely a wontfix. Installing packages individually from one release on another release is not supported. Either upgrade the entire distro first, or stick to packages from the version you are on. However 'upgrade from release to Cauldron', when done correctly, should usually work as expected. It's really hard to test for dependencies like this, as the person building the package will have working versions of everything. Worse, in two years' time, perl-base of 5.14.3 will be hopelessly outdated (we all expect, at least). So it becomes one more thing to maintain. But it's also a problem worth solving for some of the system-critical components such as perl, urpmi and drak*. I don't think wontfix is a good answer here. But, in supported use cases, urpmi *does* ensure that all the pieces to keep urpmi are upgraded in one transaction. Supporting the use case of installing any random package from a different release will take more effort than just adding and maintaining a version on one perl-base dependency. Regards, Buchan
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
On Saturday, 12 November 2011 22:11:31 Kamil Rytarowski wrote: On 12.11.2011 20:20, Michael Scherer wrote: Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit : There is also one important patch missed in Mageia - http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html it's dependency for the GNS3 simulator. OpenSUSE already includes it https://build.opensuse.org/package/files?package=qemuproject=openSUSE%3 ATools If nobody is against I will do it and contact the maintainer (misc). I prefer to wait on the stable release ( ie, no rc1 ). We will wait on stable version of qemu. OK And no patch unless it comes from upstream ( and even, I am not keen on backporting feature, better wait for stable release ). GNS3 is already in stable! This package is broken - no dynamips (=no router emulation at all...), Well, for me, I upgraded from Mandriva, and AFAIK there has been no new release of dynamips in the past year = grab the package from Mandriva for nwo, and log an enhancement bug (you can assign to me) for dynamips. no patched qemu (no virtualization support at all...) According to the developers and their online documentation for package maintainers http://forum.gns3.net/post11571.html UDP patched Qemu is dependency/very important. Can you provide a bit more information on what GNS3 feature needs this patched qemu? I have in the past hooked up my kvm VMs to dynamips routers (before GNS3). Is this for Pix emulation, or just for launching generic virtual machines/emulated hardware as part of your lab? I really don't think the Pix emulation (I have never seen a maintained patch) is ready for anyone to include it ... but I haven't looked recently. We must fix the package and provide at least not so heavy broken ones... I've prepared new version of GNS3, included into svn dynamips Did you base it on the existing Mandriva package? and xdotool (this one suggested) - these I can maintain with my mentor, so I ask for patch qemu in stable versus UDP support. Regards, Buchan
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
On Sunday, 13 November 2011 23:32:45 Kamil Rytarowski wrote: On 13.11.2011 10:58, Michael Scherer wrote: Le samedi 12 novembre 2011 à 21:11 +0100, Kamil Rytarowski a écrit : On 12.11.2011 20:20, Michael Scherer wrote: Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit : There is also one important patch missed in Mageia - http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html it's dependency for the GNS3 simulator. OpenSUSE already includes it https://build.opensuse.org/package/files?package=qemuproject=openSUS E%3ATools If nobody is against I will do it and contact the maintainer (misc). I prefer to wait on the stable release ( ie, no rc1 ). We will wait on stable version of qemu. OK And no patch unless it comes from upstream ( and even, I am not keen on backporting feature, better wait for stable release ). GNS3 is already in stable! This package is broken - no dynamips (=no router emulation at all...), no patched qemu (no virtualization support at all...) According to the developers and their online documentation for package maintainers http://forum.gns3.net/post11571.html UDP patched Qemu is dependency/very important. The fact that someone pushed a broken package is not a good reason to add patches to qemu. OK, but I don't understand this. Why to keep defunct packages (this could be at least major+ issue on our bugzilla) in stable and don't even want to fix, ignore this academic software (with maybe overall 1 000 000* downloads and 100 000 regular users), and to support... the inadvisable opinion of Mageia around.. at least the GNS3 users. * 799 968 Windows Downloads (just from the sourceforge mirrors) of the latest Windows binary of GNS3 (source http://sourceforge.net/projects/gns-3/files/GNS3/0.7.4/) We have too many patches on a general scale, and I do not want to end with a 2nd package like gdb. Patches make harder to upgrade, harder to make sure security is done correctly, and harder to ensure stuff are working ( since we are on our own when we patch something ). So for the patches, make sure it is upstream It's not qemu upstream, it's GNS3 and its community upstream. ( and given the discussion on ml, it should be soon ) When I ask the developers, they don't know if qemu will include the patch at all and when (now or after one year) and they suggested to do the openSUSE way (today the most recommended and full featured Linux distro for GNS3). [...] OK. So if gns3 can't be fixed for the stable - than should be removed from the repos (for ISOs is to late). If we don't provide qemu patch, then gns3 should be removed from Cauldron as well. I believe removing GNS3 is better than keeping it broken and.. irritate people (I don't count the opinion of our quality). Later some 3rd party repos can provide GNS3 and its dependencies. You seem to imply that the only use of GNS3 is with this qemu patch. But I used GNS3 with just dynamips, and this issue of GNS3 not being usable at all due to missing dynamips can really be solved quite quickly just by shipping dynamips to updates. But, it looks like someone blindly imported gns3 and dynagen from Mandriva without even understanding the use of these tools: $ rpm -q --suggests dynagen dynamips = 0.2.8 xterm (dynamips isn't explicitly required to be installed on the host with gns3 or dynagen, as the hypervisor can be run on a different host than dynagen/GNS3). Regards, Buchan
Re: [Mageia-dev] About syslinux libpng
On Monday, 3 October 2011 15:58:36 Michael Scherer wrote: Except if I start to replace this by here is a nice syslinux boot image with a duck. And then my code is run by syslinux, just because someone took my png picture. And the same person could say, Here is my cool plymouth splash screen, use my initrd, and there are 1000 easier ways to exploit this (than trying to generate a PNG image with exploit code that someone would like enough to use syslinux). troll Maybe we need to adopt secure UEFI, and sign our kernels and initial ram disks ... /troll So no, bundling is not without causing trouble. So if we take this road of removing bootloader's libs, shall we also remove the jpeg/gz/gcc/... libs too, and maybe for other bootloaders too ? I do understand the need for the application that runs under linux... but about the bootloaders... Unless I am wrong, a bootloader run on ring 0 or can even ( like xen ) be used to run the kernel in a specific separate memory space ( ie, virtualisation ). This could open a whole new range of problem ( like the Blue Pill concept code published 5 years ago by Joanna Rutkowska ) So I think that bootloader requires more consideration than regular application. What's your thoughts about it ? Would you agree on keep syslinux untouched regarding the png lib ? For reasons explained before, I would rather disagree. But, users foolish enough to be tricked into booting malicious code can't really be helped. I think it would be better if syslinux was compatible with current upstream libpng, so, if: 1)There is an upstream bug filed regarding support for current libpng 2)We have a registry of software building statically or with internal copies of libraries, and syslinux is added with a reference to the upstream bug then I think it is reasonable to build syslinux with internal libpng. Unless you are going to mitigate *all* other attack vectors based on 'here, boot my random binaries on your system'. Regards, Buchan
Re: [Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update.
On Thursday, 1 September 2011 12:12:46 Samuel Verschelde wrote:
Le jeudi 25 août 2011 11:03:42, David W. Hodgins a écrit :
If the Mandriva way is kept, we must ensure all needed dependencies
are available in Updates (Testing too).
I note that the exception given for Mageia 1 to have packages that were in
Mandriva, but weren't available at Mageia 1 release be available in updates
makes this more difficult.
My laptop, upgraded from Mandriva 2010.1, still has 143 non-library packages
with 'mdv' in the release tag. I would hate to have all the dependencies of
all these 143 packages have to be copied to updates ...
In addition, all packager must
be willing to copy the dependencies from Core Release to Core Updates
Testing, and the sysadmin team must push them.
If changing mgaapplet is chosen, that must be given a very high priority.
Either way, a decision is needed quickly.
Thanks, Dave Hodgins
A decision was finally taken yesterday during packager meeting : we would
like to change MageiaUpdate's behaviour, but before this is done we have
to copy the dependencies from Core Release to Core Updates.
What hasn't been decided is whether the packager must submit to
updates_testing or the sysadmin copy the package from Core Release to Core
Updates. Can we decide it quickly so that the pending updates can be
validated ?
IMHO, the identical package should be in updates (possibly hard-linked), as:
1)Users who already had the dependency installed should not have to upgrade it
2)Package %{NAME} and EVR should be unique.
So, IMHO, sysadmins need to sync/hardlink dependency packages to updates-
testing, and move to updates once validated.
Regards,
Buchan
Re: [Mageia-dev] [135989]
On Thursday, 1 September 2011 01:46:17 Zé wrote: 2011/8/31 Balcaen John mik...@mageia.org: The main point here was how your attitude changed from a certain day. You started rising tone everytime i didnt agree, like you owned kde But, he is the maintainer: $ mgarepo maintdb get kdebase4-workspace mikala $ mgarepo maintdb get soprano mikala $ mgarepo maintdb get qt4 mikala (Granted, the maintainers database currently doesn't cater to teams, and I have no background of how the KDE team is working at present). While we don't have a finalised packager's policy, the conventional meaning of the 'maintainer' is he/she who has final authority over a package. This is implied by some of the existing policies which assign specific responsibilities to the maintainer: http://www.mageia.org/wiki/doku.php?id=updates_policy http://www.mageia.org/wiki/doku.php?id=bug_policy While mikala is the maintainer of the packages, and until the packager's policy is completed, common courtesy dictates that you respect the decisions of the person who is impacted more (due to having more responsibilities) by changes you want. and i was forced to follow your ideas. As it should be at persent, based on the output above. It would much more productive if we could all use our efforts to develop instead other things. I note that to someone who hasn't been following everything in detail, that it seems you need to communicate better with, and respect the decisions of, the people whose packages (and contribution) you are affecting. Regards, Buchan
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On Tuesday, 23 August 2011 17:15:44 Michael Scherer wrote: Le mardi 23 août 2011 à 15:28 +0200, Thierry Vignaud a écrit : What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. On the server side, we still manage RHEL networking through old style ifcfg* config files Some people do actually use vms, where boot speed could be important if created on demand ( and where the reactivity would warrant something more than shell script, and where a better API to get interface information wuld be nice ). We have netcf in the distribution ... https://fedorahosted.org/netcf (required for network configuration from virt-manager). Regards, Buchan
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On Tuesday, 23 August 2011 15:30:45 Colin Guthrie wrote:
'Twas brillig, and Guillaume Rousse at 23/08/11 12:16 did gyre and gimble:
On 23/08/2011 12:26, Colin Guthrie wrote:
How would removing initscripts support helps enhancing networkmanager
integration ?
Because the current philosophy of the Unix legacy is lots of individual
utils from various packages cobbled together with some glue shell
scripting code... and it's dying.
The things that these individual tools implement are a few relatively
simply commands to the kernel and it doesn't make sense to do all this
in shell. It makes much more sense to do all these jobs in efficient
code that runs *quickly* without forking hundreds of times. The code is
still perfectly visible and easily hackable, but now things are much
more robust and efficient.
Booting faster makes sense on desktops, not on servers.
Agreed, but on servers additional capabilities are added that I very
much care about (much more than I care about boot speed on my laptop if
I'm honest - with my SSD I'm looking at a 1 or 2 second boots - who
cares about that!). I'm actually much more excited about systemd on the
server than I am on a desktop.
The cgroup management
We don't even have libcgroup or equivalent in the distribution yet ... so I
would say is is a bit premature to show this as an advantage IMHO ...
and the ability to restart network services
without losing a single connection is a revelation for me.
Have all the services got support for this yet?
I will no
longer worry about restarting apache because it might mess up a
webservice request or similar. And if I get rooted and find rogue
processes running, I'll be able to know exactly what service actually
started that process which is incredibly useful when dealing with the
mess left by intrusions.
My general
impression in this new trend (systemd, networkmanager, etc...) is the
need to compete with proprietary system (macos, windows) on end-user
segment, at the cost of genericity and simplicity.
I think the simplicity argument is bogus. You are (IMO) confusing
simplicity with ease of readability. Sure you can read through a script,
but the process of starting and maintaining services now becomes
*standard*. I don't have to read scripts for every single one of the
1000s of init'ed services,
I really don't read the scripts for every service, but quite often I do need
to adjust some setting catered for in the script, so I read
/etc/sysconfig/foo, and adjust it there.
Although I have read a number of the systemd blogs, there are still some
unanswered questions. Such as, what should happen to utility functions in the
init scripts (e.g. 'service apache configtest' or 'service ldap check'), or
other checks that are done in the init script before starting the service
(such as ensuring ownership of files by the ldap user, which is a common trap
users fall into after doing an import, or re-indexing).
I just need to understand the process of
services management in general and I can pretty much work with
everything.
Surely 'service foo {start|stop|restart|reload}' is also a generic approach to
services management?
When you appreciate that, you'll see that systemd makes
things much simpler overall. Sure you can't read a script, but that, in
itself, has nothing to do with simplicity. Individual scripts tweaking
certain things and adding secret arguments and such like is far, far
more complex than a unified and defined way of working.
But, sometimes they are required, and what is the replacement for the
functionality?
And yes, if we're honest, MacOS has a far superior boot system in
launchd and the networking support is also better with it's fast-start
DHCP and other such nice things.
And MacOS has good server market share?
I'm not suggesting network manager on servers here FWIW, but I think
your reluctance to change should be massively outweighed by the benefits
these changes bring, both to the server platform and to desktop systems.
The rest of the discussion in this mail by now was about systemd. For
NetworkManager, I have some more questions.
At present, a number of my machines have scripts that hook into the network
scripts. For example, one to update the bind forwarders from the DNS IPs
returned by pppd when the interface comes up. On another machine, a script
that unloads the wireless broadband driver when the interface goes down (I
think this modem has buggy firmware). Then, there are the existing scripts
shipped in the distribution (e.g. to reload squid).
In the NetworkManager world, are all of these taken care of? If not, and I
have to script them myself, now I guess I have to hook in to NM via dbus?
Regards,
Buchan
Re: [Mageia-dev] new samba-squid subpackage proporsal
On Friday, 5 August 2011 19:05:43 Luis Daniel Lucio Quiroz wrote:
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.
??
For a working solution, you need:
-ntlm_auth (currently in samba-common)
-winbindd (currently in samba-winbind)
-net (to join the domain, currently in samba-common)
-/etc/samba/smb.conf (currently in samba-common)
Please compare the output of 'ldd /usr/bin/ntlm_auth /usr/sbin/winbindd
/usr/bin/net' and 'rpm -qR samba-common samba-winbind'. You will notice that
there are really no unnecessary dependencies:
Let me do it for you:
$ rpm -qR samba-common samba-winbind|awk -F '(' '/^lib/ {print $1}'|sort -u
/tmp/samba-common-libs
$ ldd /usr/bin/net /usr/bin/ntlm_auth /usr/sbin/winbindd | awk '/lib/ {print
$1}'|sort -u /tmp/ntlm_auth_libs
$ diff -u /tmp/samba-common-libs /tmp/ntlm_auth_libs
--- /tmp/samba-common-libs 2011-08-10 11:41:43.0 +0200
+++ /tmp/ntlm_auth_libs 2011-08-10 11:41:45.0 +0200
@@ -1,18 +1,24 @@
+/lib64/ld-linux-x86-64.so.2
libcap.so.2
libcom_err.so.2
+libcrypto.so.1.0.0
libc.so.6
libdl.so.2
libgssapi_krb5.so.2
libk5crypto.so.3
libkrb5.so.3
+libkrb5support.so.0
liblber-2.4.so.2
libldap-2.4.so.2
+libncurses.so.5
libnsl.so.1
-libpam.so.0
libpopt.so.0
+libpthread.so.0
libreadline.so.6
libresolv.so.2
librt.so.1
+libsasl2.so.2
+libssl.so.1.0.0
libtalloc.so.2
libtdb.so.1
libwbclient.so.0
(All we find is that we could theoretically have ntlm_auth and winbindd
without libpam, but, well, you can't easily have a system without it anyway
...)
Feel free to make squid suggest samba-winbind, but there is very little
benefit to splitting ntlm_auth out of samba-common. To use it for SSO against
AD, you will need /usr/bin/net to join the domain, and you will need an
smb.conf file. Both of these are in samba-common. Then you will probably need
samba-winbind for winbindd. About the only things we can do to have *any*
impact at all on the footprint of squid+ntlm_auth would be to:
1)move rpcclient, smbcacls, smbcquotas and smbtree out of samba-common (e.g.
RH has these in samba-client, but these tools are more useful on servers than
e.g. smbspool, so I would prefer it to be a package that doesn't require
pulling in all the contents of samba-client)
2)split winbindd/ntlm_auth/nss_winbind/pam_winbind (RH has winbindd and
nltm_auth in samba-winbind, and nss_winbind and pam_winbind in samba-winbind-
clients). But, nss_winbind and pam_winbind together are under 100kB, and
winbindd is 7.8MB, so again there is little benefit.
Nothing else makes any sense.
But, since ntlm_auth is commonly used in at least 3 different scenarios with 3
different packages *in the distribution*, making a *squid-specific* package is
just ridiculous.
I am open to useful, logical proposals, see above. However, there are some
issues (e.g. pam_winbind and nss_winbind aren't really that useful
individually, they are typically used together, hence RH shipping them
together in samba-winbind-clients), so please discuss the issues in advance,
after having at least having familiarised yourself with *all* the tools in
question.
Regards,
Buchan
Re: [Mageia-dev] Re : Re: new samba-squid subpackage proporsal
On Saturday, 6 August 2011 20:20:39 andre999 wrote: Samuel Verschelde a écrit : Le vendredi 5 août 2011 21:19:06, Luis Daniel Lucio Quiroz a écrit : 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. I don't see either the need for a conditional suggest, what I understood is : samba-common would require samba-squid-helper squid would suggest samba-squid-helper thus allowing squid to use the helpers without the need for the full samba- common package. Now, bgmilne seems to think that there's no need to split samba-common for that, for a reason that I haven't understood but maybe I don't know the subject enough to understand it. My point is that splitting ntlm_auth out samba-common would make no difference, as: -ntlm_auth requires smb.conf, in samba-common -ntlm_auth (at least for this scenario) requires samba-winbind, which requires smb.conf, which is in samba-common -/usr/bin/net is required (at least once) to join the domain, it is in samba- common Exactly how I understand it, as well. At 50M, samba-common isn't tiny. Unfortunately, due to samba's migration to auto-generated code based on IDL files, binaries have been growing substantially. It may be worthwhile to split other less commonly used binaries out of samba-common. But, the purpose samba-common serves, having binaries and configuration files which are *required* by many different scenarios, should not be changed to fit squid. We could migrate ntlm_auth out of samba-common, but whatever package it is in would require samba-common anyway ... If there is reluctance to have a subpackage for squid alone, maybe a subpackage which is a superset for all packages wanting approximately the same components ? Why specific to squid, when 3 packages in the distribution are commonly used with ntlm_auth? Possibly making this subpackage parallel to samba-common, created from the same srcrpm, with mutual declared conflicts, so the subpackage is only installed if samba-common isn't, and that those installing samba-common install a single package. What is the cost/benefit of this? Both seem better options than an independant samba-squid-helper package, which would require mutual conflicts with samba-common. Just some random ideas ... I would like to understand the motivation first. What are we trying to achieve, besides more work for the samba maintainer? If we are trying to reduce the disk footprint of a squid+ntlm_auth setup, the best approach is to move some binaries out of samba-common. 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] 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 Monday, 1 August 2011 22:34:55 Luis Daniel Lucio Quiroz wrote: Le Lundi 01 Août 2011 12:36:47 Buchan Milne a écrit : On Friday, 29 July 2011 20:52:14 Luis Daniel Lucio Quiroz wrote: Helow Specially tu buchan, in my experince, when trying to making work a Squid with an ugly wik2k8 we realize that the squid helper is not working. I had no problems with this in providing one of the two sets of squid proxy servers that had a role in presenting the 2010 FIFA World Cup. (The other set of proxies used Basic authentication against OpenLDAP). After doing research we realize that samba has a helper that works You mean ntlm_auth, which has been in samba-common for years, and works with Squid, Apache and FreeRADIUS ? , i was wondering if you can do a subpackage of that helper so the squid may do a suggests to that only. I need more details ... so far this sounds like a question, not a proposal. Regards, Buchan Yes, itis a prposal if you can add a subpackage like samba-helpers inwher eyou place tthe ntlm_auth and others from samba and i then do a suggest from squid to ask for them 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. Regards, Buchan
Re: [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.
On Monday, 1 August 2011 20:21:21 Maarten Vanraes wrote: Op maandag 01 augustus 2011 11:42:26 schreef Thomas Lottmann: Hello, I should have written this mail much sooner, but finally, I am totally, completely and starting to be hatefully fed up of these tools. The Mandriva/Mageia tools that manage the network on computers, especially the wireless networks are completely dysfunctional. While the Network Center does not seem to even communicate with the system tools to know what is happening during the link setup, it does not auto-refresh network lists properly. Since 2010.1 now even mixes up itself in it's own network scripts (the ones stored in wireless.d). This maxes it wrongly detect numerous wireless points (he seen WPA2 Enterperise hotspots as opened or WEP, or more nerving, becomes incapable or storing the right authentication information). My production laptop is still currently running Mandriva 2010.x, and I don't have problems like this. Work networks run WPA2-Enterprise with EAP-PEAP- MSCHAPv2, home runs WPA2-Personal. In the cases I have seen this, it is typically a buggy AP (and in some cases, other platforms have also mis- detected the network details). In some cases, upgrading the AP firmware has resolved the problem. But, these are *specific* issues, and need bug reports with detailed information. A tool that breaks itself is a complete shame! The GUI is also appalling. Despite it's numerous possibilities, it is a mess and 60% of it cannot be used by something else than the system or a network expert. There are some deficiencies, but in many cases it does at least work. And at least my network comes up regardless of how I boot, where I booted to, whether a user is logged in to a desktop or not (which is not the case on e.g. Fedora). The code itself is undocumented and it extremely difficult to read. The few times I looked at the code, it was quite readable. Unfortunately, the pieces I wanted to do something about ended up requiring changes in non-perl parts. These tools are getting really bad and not working properly anyway since a long time now. So either we fix it and improve it (recoding?), either we definitely switch to Network Manager. Please no. The biggest frustrations I personally have have nothing to do with net_applet vs NM. My current biggest frustrations are: 1)That wpa_supplicant doesn't return different results on incorrect (WPA2- Enterprise EAP-PEAP) passwords: http://hostap.epitest.fi/bugz/show_bug.cgi?id=399 2)That net_applet doesn't prompt for passwords if wpa_supplicant says it needs a password. I filed a bug for this against Mandriva: https://qa.mandriva.com/show_bug.cgi?id=51705 Implementing the required dbus communication would allow a number of other improvements (e.g. not having to restart wpa_supplicant for configuration changes, possibly avoid manual parsing/writing of the configuration etc.). I am ready to participate if necessary (despite my lack of competence), but I do not want to see these tools 'as is' on my computer anymore, and no longer want to see these issues that down Mageia's reputation in comparison to other popular projects here such as Arch, Fedora or Ubuntu, who do have proper tools delivered by default. I disagree with your statement. For example, while Fedora may seem to have proper tools, there are many use cases that aren't considered, and a number of issues are still experienced (at least according to my colleagues reports). Allowing NM or non-NM, and having both improved would be win-win. This is not the first time I complain about this tool. We should not leave this unchanged. It is far too annoying and pushing to so much loss of time. Yours sincerely,. Thomas. personally, alot of problems could likely be attributed to using all those several of those apps together. imho, the network tools should be redesigned a bit, according to good usability, but mostly, either they should all be nicely integrated which each other, or we should just have one that does all nicely. personally, i find the netapplet the best working and use that exclusively to avoid issues. but sadly, even netapplet is far from complete. as some kind of start, we should have an app that exists in drakconf, but also accessible via an applet, but again, perhaps we should have multiple applets, with one for each connection. I don't think this is necessary, the 'Network Center' does an adequate job (taking into account some limitations in the network scripts). eg: a wifi access link, 2 network connections (one of which goes to internet), and 3 openvpn tunnels (as an example) it would even be better, if bluetooth networking could also be included. Bluetooth networking *can* be included, but there is an artificial limitation on only one ppp connection, so you wouldn't be able to have a Bluetooth SPP- based ppp connection as well as a
Re: [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.
On Tuesday, 2 August 2011 10:56:55 Thomas Lottmann wrote: You are right in several points, but... :-) Le 01/08/2011 15:59, Thierry Vignaud a écrit : On 1 August 2011 15:29, Thomas Lottmannskipercoo...@gmail.com wrote: The other main issue I see si that Drakxnet is coded in Perl and uses a lot of perl scripts, like the drakxtools. This makes it hard to maintain, and to improve. That's just your own POV. Not the POV of maintainers. Are there other maintainers for this tool than it's creators or long-time maintainers? This is not only my POV, but also what I have heard from a variety of people since the time I participate a little. Anyway... I know it works fine for several people. Personally, I am often having issues because it's disconnects on it's own, This has nothing to do with drakconnect that don't handle that. If the network disconnected, that's the issue between the routers, the network, the kernel, and no longer sees any networks when it should. which points to either network issue or kernel driver issue, not drakconnect. Other people not using Mageia do not get as often disconnected as me when using public hotspots. Sure, this should be investigated, however it could be due to things besides the network GUI tools etc. For example, if using wpa_supplicant, once you have selected a wireless network, the Mandriva tools do virtually nothing. BTW., I notice (from wpa_gui, *not* net_applet, and even without net_applet running) that my machine re-associates to our WPA2-Enterprise network more frequently than other operating systems. Mageia wireless tools seem to have more difficulty to connect and keep the connections to hotspots that have a low (not bad, low) quality signal, while Windows keeps connected, or, quickly reconnects automatically. These symptoms don't appear to be related to which GUI tool configures wpa_supplicant, but rather points to wpa_supplicant or driver/firmware problems. Meanwhile, I have to reconnect manually and, more frustrating, it seems the wireless utility sometime attempts to reconnect automatically, but I can't clearly know. The other bizarre thing I often see is when the hotspots he sees fall from 35 to 0 (or 1, the hotspot he's tryign to connect). This is not normal, I have not observed this NM, Windows or Mac OS X tools. Then it has difficulty reconnecting. Same, reconnecting is the job of dhcp-client, ifplugd and the like. Not drakconnect's job. I can't tell. I can only observe and I do not invent what I describe (and have already described in the past). :-) You could investigate by connecting manaully (iwconfig, wpa_cli, wpa_gui etc.) and report whether doing so solves your problems. If not, you are blaming the wrong thing. Windows, Fedora and Ubuntu's wireless tools work absolutely smoothly at my school. And now, other people testing Mageia as school are having the same issues I have. This is frustrating and I can assure you these home-made network tools have to be improved and fixed. Well, Fedora tool (really NM) has its own bugs. True. And I'm pretty sure people who've used MS, Apple or whatever OS/tool they're used to, have also encountered issues True. But these issues are less evident to find apparently, and do not affect that much user experience. When a user wants to connect to a wireless hotspot, he should just click connect, enter his IDs and it should work fluently. This works for me (except I don't want my Single-Sign-On password in a clear- text configuration file, but it seems no distro has fixed all the issues with this yet). If it is often the case with Mageia tools with a personal hotspot and when you're next to it, it is not always the case when you use it everyday, and, sadly, other tools do better and have a more stable and smooth wireless connectivity, even if they also encournter issues. Their issues are not that much affecting user experience like the ones I have described. If you want to, I can attempt to make a list of the isses and incoherencies I find, although they are not hard to see. Indeed, please just fill in _several_ bugs (one report per issue) against drakx-net I will do one report for each issue I find in drakxnet, with as much details as possible, yes. I shall also do a video capture of the issue if it can help. I would rather spend the time testing whether the behaviour is the same without e.g. net_applet. Videos showing nothing that can help find the problem is just a waste of time. this will take me a lot of time, but I will do it. But as I mentionned earlier, this is a tool that is hard to maintain, and I cannot learn perl right now. Who says your issues are in this tool? That's just _your_ personnal though, not his maintainer's. aka this is a tool that is hard to maintain really means you would not be able to maintain it Right. If NetworkManager
Re: [Mageia-dev] new samba-squid subpackage proporsal
On Friday, 29 July 2011 20:52:14 Luis Daniel Lucio Quiroz wrote: Helow Specially tu buchan, in my experince, when trying to making work a Squid with an ugly wik2k8 we realize that the squid helper is not working. I had no problems with this in providing one of the two sets of squid proxy servers that had a role in presenting the 2010 FIFA World Cup. (The other set of proxies used Basic authentication against OpenLDAP). After doing research we realize that samba has a helper that works You mean ntlm_auth, which has been in samba-common for years, and works with Squid, Apache and FreeRADIUS ? , i was wondering if you can do a subpackage of that helper so the squid may do a suggests to that only. I need more details ... so far this sounds like a question, not a proposal. Regards, Buchan
Re: [Mageia-dev] openldap-server needs rebuild agains new db51
On Thursday, 7 July 2011 06:38:44 Thomas Spuhler wrote: openldap-server needs rebuild against new db51 otherwise a lot of packages want to be uninstalled Please wait for 2.4.26 which is in progress (well, submitted to Mandriva cooker, building on my internal build system for RH-based systems, to be synced to Mageia as soon as I have time). Regards, Buchan
Re: [Mageia-dev] Backports policy proposal
On Friday, 24 June 2011 08:30:15 Maarten Vanraes wrote: Op vrijdag 24 juni 2011 02:10:14 schreef Michael Scherer: [...] Another rule that we could add is that cauldron should always be newer than backports, in order to ensure upgradability. The same goes for n-2 and n-1 release. While this seems innocent, do not forget this will have a impact when we do the version freeze. [..] This seems hard to enforce... i can imagine if you make backport, it has essentially the same version as in cauldron, i can think that there is a few spec file changes that are only for backports, Why should it need spec file changes? and thus the release becomes newer than the one in cauldron If it requires spec file changes, why should cauldron not get a new release that includes the changes? Sorry, but a number of my packages were regularly backported, and I never needed cooker to be older ... Regards, Buchan
Re: [Mageia-dev] why not disable bytecode interpreter in freetype2 ?
On Friday, 13 May 2011 11:12:41 Zé wrote: 2011/5/13 Zé mmode...@gmail.com: 2011/5/13 Dimitrios Glentadakis dgl...@gmail.com: Στις Παρασκευή 13 Μάιος 2011 00:39:55 Zé γράψατε: 2011/5/12 Dick Gevers dvgev...@xs4all.nl: On Thu, 12 May 2011 13:20:39 +0200, Dimitrios Glentadakis wrote about perl -pi -e 's|#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER|/\* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER \*/|' include/freetype/config/ftoption.h dont forget to also increase Release to avoid conflicts with existant freetype2, and then build the package. Why do all these things when you can simply add an entry in the font.conf file ? Thats a fact, but hat should happen is that freetype2 should have bytecode interpreter disabled by default, since so far users prefer it. Seams Fedora choosed to finally fix it, it reverted freetype2 with a patch to disable bytecode interpreter. - https://bugzilla.redhat.com/show_bug.cgi?id=547532 No, this is not what is covered in this bug report. Firstly, here are the non-problems: 1)The bytecode interpreter *can* make fonts look better, *if* they have hinting in the fonts. Not all ttf fonts have hinting, but AFAIK all the MS fonts *do* have hinting. So, historically, the recommended approach was to use the PLF freetype *if* you had imported MS fonts (e.g. from a dual-boot Windows installation). 2)The Freetype autohinter was implemented later, and improves things for unhinted fonts, but hinted fonts still looked better with the bytecode interpreter. This is the problem: 3)If the bytecode interpreter was enabled, auto-hinting was disabled (or, could be, for 'medium' and 'heavy' hinting settings) for unhinted fonts. The Fedora bug isn't about disabling the bytecode interpreter, but by still allowing auto-hinting for unhinted fonts if the bytecode interpreter. *This* is the right fix. Your insistence to *disable* the bytecode interpreter (leaving users with *no* options, in case they need hinted fonts) is the wrong fix. But, thanks for the pointer to the bug, which points to the patches. Why dont we also do the same thing? Since theres users complaining about it, why not solve it once for all? Regards, Buchan
[Mageia-dev] Samba update to 3.5.8
I have finally got a bit of time to get busy with Mageia packaging (my first VM was on virtio disk on Mandriva 2010.1/kvm, and there seem to be some corruption problems, I finally got time to reinstall it yesterday). Since I have just finished samba/samba4 updates in Cooker, I would like to update Cauldron to the same. Specifically, what we miss between 3.5.5+CVE is: New in 3.5.8: o Fix Winbind crash bug when no DC is available (bug #7730). o Fix finding users on domain members (bug #7743). o Fix memory leaks in Winbind (bug #7879). o Fix printing with Windows 7 clients (bug #7567). New in 3.5.6: o Fix smbd panic on invalid NetBIOS session request (bug #7698). o Fix smbd crash caused by %D in printer admin (bug #7541). o Fix crash bug with invalid SPNEGO token (bug #7694). o Fix Winbind internal error (bug #7636). Unfortunately, samba features, if absent, are usually samba bugs, such as printing with Windows 7 clients etc. If this is viable, I will try and commit updates to the following in svn between now and 15h00 UTC: -tdb 1.2.9 (done) -ldb 1.1.0 (import) -samba-3.5.8 -samba4alpha15 (alpha11 was imported about 2 days before I finished alpha15 in Mandriva) Please let me know if I should go ahead. tdb should be pushed in the meantime in this case. Regards, Buchan
Re: [Mageia-dev] Samba update to 3.5.8
On Friday, 13 May 2011 12:28:45 Colin Guthrie wrote: 'Twas brillig, and Buchan Milne at 13/05/11 11:16 did gyre and gimble: I have finally got a bit of time to get busy with Mageia packaging (my first VM was on virtio disk on Mandriva 2010.1/kvm, and there seem to be some corruption problems, I finally got time to reinstall it yesterday). Since I have just finished samba/samba4 updates in Cooker, I would like to update Cauldron to the same. Specifically, what we miss between 3.5.5+CVE is: New in 3.5.8: o Fix Winbind crash bug when no DC is available (bug #7730). o Fix finding users on domain members (bug #7743). o Fix memory leaks in Winbind (bug #7879). o Fix printing with Windows 7 clients (bug #7567). New in 3.5.6: o Fix smbd panic on invalid NetBIOS session request (bug #7698). o Fix smbd crash caused by %D in printer admin (bug #7541). o Fix crash bug with invalid SPNEGO token (bug #7694). o Fix Winbind internal error (bug #7636). Unfortunately, samba features, if absent, are usually samba bugs, such as printing with Windows 7 clients etc. If this is viable, I will try and commit updates to the following in svn between now and 15h00 UTC: -tdb 1.2.9 (done) -ldb 1.1.0 (import) I could probably submit this now, but it (build)requires tdb-1.2.9. Its other requirement, fixed package names/provides for talloc, has just finished building. -samba-3.5.8 -samba4alpha15 (alpha11 was imported about 2 days before I finished alpha15 in Mandriva) Please let me know if I should go ahead. tdb should be pushed in the meantime in this case. While this is very late in the cycle, the changes to samba look like bugfixes to me and the samba4alpha package is likely one we can push through the freeze anyway due to it's nature. So IMO the only question is the tdb and ldb. Are these just bug fixes too? (as ldb is an import it's less of an issue - is it just needed for samba4?) Both samba3 and samba4 require newer versions of tdb, and ldb, I've switched to using standalone versions of all the common libraries (talloc,tdb,tevent,ldb) now that they actually seem to be released before versions of samba3/samba4 that need them. (By default, without the libraries, both versions of samba would build static- only copies, or you can choose to build shared libraries, but it ends up being more convoluted having them in one or the other of samba3 or samba4). Regards, Buchan
Re: [Mageia-dev] why not disable bytecode interpreter in freetype2 ?
On Friday, 13 May 2011 17:28:24 Zé wrote: 2011/5/13 Buchan Milne bgmi...@staff.telkomsa.net: On Friday, 13 May 2011 11:12:41 Zé wrote: 2011/5/13 Zé mmode...@gmail.com: 2011/5/13 Dimitrios Glentadakis dgl...@gmail.com: Στις Παρασκευή 13 Μάιος 2011 00:39:55 Zé γράψατε: 2011/5/12 Dick Gevers dvgev...@xs4all.nl: On Thu, 12 May 2011 13:20:39 +0200, Dimitrios Glentadakis wrote about perl -pi -e 's|#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER|/\* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER \*/|' include/freetype/config/ftoption.h dont forget to also increase Release to avoid conflicts with existant freetype2, and then build the package. Why do all these things when you can simply add an entry in the font.conf file ? Thats a fact, but hat should happen is that freetype2 should have bytecode interpreter disabled by default, since so far users prefer it. Seams Fedora choosed to finally fix it, it reverted freetype2 with a patch to disable bytecode interpreter. - https://bugzilla.redhat.com/show_bug.cgi?id=547532 No, this is not what is covered in this bug report. Yes, correct i miss understood what as the bug report about. Firstly, here are the non-problems: 1)The bytecode interpreter *can* make fonts look better, *if* they have hinting in the fonts. Not all ttf fonts have hinting, but AFAIK all the MS fonts *do* have hinting. So, historically, the recommended approach was to use the PLF freetype *if* you had imported MS fonts (e.g. from a dual-boot Windows installation). Well i always avoid using PLF freetype and for what i have read in ML's all the users that answered to it said that also avoid PLF freetype. So far for hat i have seen, all users prefered like fonts were rendered wen patents were still valid... Were *all* these users using *hinted* fonts? I think they weren't using hinted fonts at all. 2)The Freetype autohinter was implemented later, and improves things for unhinted fonts, but hinted fonts still looked better with the bytecode interpreter. This is the problem: 3)If the bytecode interpreter was enabled, auto-hinting was disabled (or, could be, for 'medium' and 'heavy' hinting settings) for unhinted fonts. The Fedora bug isn't about disabling the bytecode interpreter, but by still allowing auto-hinting for unhinted fonts if the bytecode interpreter. *This* is the right fix. Your insistence to *disable* the bytecode interpreter (leaving users with *no* options, in case they need hinted fonts) is the wrong fix. Well this way users cant also set to have autohint, seams theres always some app failing. ? We need to apply the patch that enables the autohinter for unhinted fonts, even if the bytecode interpreter is enabled, that is available from the bug report for which you provided the link. Why not having it disabled by default? So, you haven't read what I wrote in (3)? users will always be able to set their preferences about using or not autohint, but that way ensures that all fonts are better rended. No, you ignore the case where some hinted fonts are almost unusable without the bytecode interpreter, and others where they are rendered better. All this came up after patents end in wich showed users how fonts appear poor rended, until that point i didnt saw any complains about fonts, and this is what should be fixed. You contradict yourself ... and you can't make blanket statements of how fonts appear poor rended, as it depends on the font (and whether it is hinted or not). Regards, Buchan
Re: [Mageia-dev] 3G usb pen
On Tuesday, 10 May 2011 13:50:42 Stefano Negro wrote: 2011/5/9 Stefano Negro stbl...@gmail.com The USB pen is recognized if I mount the /dev/sr0 as usb disk and I do an eject. You should get the same effect by running 'eject /dev/sr0' without having to mount the device first. At this stage the pen is recognized. So, could be someone helping on that and suggesting how to patch the beta 2 to solve this failed auto eject. I believe it's matter of USB_modeswitch. Please see http://www.draisberghof.de/usb_modeswitch/ then. If you have a patch to the usb_modeswitch data that makes it work, we can do something about it. Until then, only people with device can do anything about it. Regards, Buchan
Re: [Mageia-dev] Non-free firmwares in installer
- andre999 and...@laposte.net wrote: Wolfgang Bornath a écrit : 2011/3/24 Olivier Blinmag...@blino.org: Thorsten van Liltv...@gmx.de writes: Am 24.03.2011 09:57, schrieb Wolfgang Bornath: 2011/3/24 Ahmad Samirahmadsamir3...@gmail.com: On 24 March 2011 02:58, Dexter Morgandmorga...@gmail.com wrote: On Thu, Mar 24, 2011 at 1:38 AM, Ahmad Samirahmadsamir3...@gmail.comwrote: Has the Free DVD in Mandriva ever contained non-free firmware? No, but the question is more , will we provide a non free dvd iso, and this question is i think interesting. A possible solution for people with such a setup could be a non-free driver cd ISO which they could include in the installation process. What about a DVD including non-free packages but has the option to not install them? I think the majority of the users don't care that much about proprietary issues, they just need them for using there wireless card or graphic card. Those how do care can just uncheck the non-free part of the DVD. :) Yep, it could just be an option. The desktop selection step seems to be a good place in the installer to include it, it is visible enough, and right before packages installation. Though it would have to be renamed. We could have a checkbox Install proprietary drivers if needed (non-free software), ticked by default. perfect solution :) Maybe for you. Maybe for me. But, the *real* question is, would this discourage some of our target market from using our distribution. IOW, we *must* get community input (after documenting some proposals). Are you aware that this would mean that Mageia is not a free distribution as planned? No matter how you phrase the question and how many checkboxes a user would have to check, if non-free contents is included in an ISO it is not a free ISO anymore. Mageia the distribution includes non-free software. We are talking about what we include on the ISO. If users want to exclude installing any non-free packages, this check-box solution solves the problem nicely. Depends on what guidelines you follow. E.g., some might say there shouldn't be a checkbox at all. Some might say the checkbox should be disabled by default. Some might say that there should be no non-free software on the default media. So users that want to ensure that their installation works out of the box will be satisfied. And purists that don't mind some things not working, can avoid installing non-free drivers. Can avoid and guaranteed to never occur are not the same, and some users may want the latter. Sounds like a win-win solution to me :) But, again, this is subjective, you are presenting your preference, and yours may not be the only one we should cater to. Regards, Buchan
Re: [Mageia-dev] Non-free firmwares in installer
- Maarten Vanraes maarten.vanr...@gmail.com wrote: Op donderdag 24 maart 2011 11:18:03 schreef Olivier Blin: Wolfgang Bornath molc...@googlemail.com writes: It can't be free and have non-free firmware... previously the firmware only were on the Live CD's. I am not sure anything has been changed in that regard (i.e. I didn't see the matter get discussed yet). They were also on the PowerPack images, and they are installed automatically over a network install But to be installed via network you have to have a network connection first, n'est-ce pas? That's what this thread is about. It is now also about in which media should we include non-free packages? :) no, about if they are really non-free... stuff released as BSD is free in my book. if they don't comply, they could be sued for all i care, but it's still free. Well, even if they say the source code is BSD, if: 1)The source is not provided (under a free license) 2)The source can't be compiled with a free toolchain then it is non-free, and most likely the license is wrong, and they have chosen to relicense from BSD to a proprietary licence (which BSD of course allows). Compare e.g. Darwin and Mac OS X. Since Mac OS X is has some originally BSD source code, must Apple provide me with complete Mac OS X source code? If they don't, do I have grounds to sue? No. Is it Free? Most definitely not. Regards, Buchan
Re: [Mageia-dev] Non-free firmwares in installer
- Tux99 tux99-...@uridium.org wrote: Quote: andr55 wrote on Fri, 25 March 2011 01:29 My though was essentially that firmware is so close to hardware that its actual free/non-free status shouldn't apply - we should treat it like (almost) part of the hardware. I agree with that. After all nobody (apart from R. Stallmann) questions the fact that the BIOS of their PC is non-free or all the other firmware or microcode on various chips on the motherboard and on expansion cards and peripherals. Firmware belongs into 'core', You mean, firmware which has an unrestricted distribution licence? Nvidia/ATI drivers and the Flash plugin belong into 'non-free'. Actually, for Flash, we need a redistribution license. Has someone contacted Adobe about this? Redistribution of Flash without a licence is prohibited[1]. We can apply for a licence to redistribute[2]. Regards, Buchan 1. http://www.adobe.com/products/players/fpsh_faq.html#section-1-5 2. http://www.adobe.com/go/fp_apply_dist
Re: [Mageia-dev] Non-free firmwares in installer
On Thursday, 24 March 2011 12:48:22 Romain d'Alverny wrote: On Thu, Mar 24, 2011 at 11:39, Wolfgang Bornath molc...@googlemail.com wrote: But I don't think it would be a good idea to include non-free contents in the distribution ISOs at all. That this assumed majority does not care about the issue does not mean we should not care either. We should rather stress the point. We already made such a difference by using different repositories, we not continue this in our product line? We use a different repo for non-free, we also should use a different ISO for non-free. Well, that's precisely debatable (and why I'll try to setup a relevant survey through marcom). The ISO can be seen as a static commodity storage; that it holds core and nonfree makes no such difference as that those two media are available from the network without discrimination. So yes, the ISO in itself would not be free anymore; but as long as the install process does not pick into the nonfree media unless the user asks to, what does it make an issue (not that I have no idea about that, just that I'd like to see it expressed again from a different POV of mine - and that will help for the survey definition too). The question is, why do we want to have a free distribution? What are suitable guidelines? The users who want a Free distribution, would probably choose one that adheres to the FSF free distribution guidelines: http://www.gnu.org/distros/free-system-distribution-guidelines.html I think we already don't meet them, with or without a Free DVD, even if we were to remove non-free firmware in the kernel, because we have non-free repos. And that would make the case for a consistent installing experience that, no matter you're doing an exclusively ISO-based install or a network-based install, you get through the same steps (with a consistent opt-in or opt-out, clearly explained). It would only happen that non-free media is available locally if asked for. The alternative, if we're not to mix things on the static media, is to have distinct ISOs: free and nonfree/tainted ones. Times the format: DVD/CD/arch/USB through which we would have to decide to ease: building, qa and distribution (we will have to choose a default one to provide to visitors on the download page for instance). Is there a real benefit? Or, is usability more important? Or, do we want to discuss with FSF the guidelines and whether it is possible for a distribution project to both meet their guidelines (e.g., if user chooses X media, they will never be prompted for non-free software, repositories etc.) and be useful for real-world-users who can't always choose hardware based on open-ness alone? Regards, Buchan
Re: [Mageia-dev] Non-free firmwares in installer
On Thursday, 24 March 2011 13:03:08 Wolfgang Bornath wrote: 2011/3/24 Romain d'Alverny rdalve...@gmail.com: Well, that's precisely debatable (and why I'll try to setup a relevant survey through marcom). The ISO can be seen as a static commodity storage; that it holds core and nonfree makes no such difference as that those two media are available from the network without discrimination. So yes, the ISO in itself would not be free anymore; but as long as the install process does not pick into the nonfree media unless the user asks to, what does it make an issue (not that I have no idea about that, just that I'd like to see it expressed again from a different POV of mine - and that will help for the survey definition too). In the public appearance this would make a difference. As soon as there is non-free contents on the ISO it is a non-free ISO. That we provide non-free on the mirrors doesn't make Mageia a non-free distro, only what we offer as products. According to which definition/guidelines? According to FSF, we are probably currently non-free. Regards, Buchan
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
On Thursday, 3 March 2011 22:43:25 Maarten Vanraes wrote: I think we need to have a name and email address. however, some options: A. possibly cn could be editable in identity Please stop referring to possibilities that exist as if they don't ... it is depressing that people keep assuming things don't work, when one has put effort into making them work ... (IOW, if users should *not* be able to edit cn, then there is one configuration entry to edit) == this will allow people to fill in what they want, be it full name, nickname, or full name AND nickname cn could then be used as the name field That is the current situation, at least in bugzilla, and should be in forum. B. an email address is required IMHO, and preferably a @mageia.org email address however, if people wouldn't want to have their email address listed, an extra option is this: C. how about we make packagename@packages.mageia.org, which could use the maintainers database to forward the email to maintainers (in case of more) (this could also be a packagegroup. eg: fire...@packages.mageia.org could refer to maintainers of firefox, xulrunner, etc...) (this option might just be too complex) /me notes that this might be easier done in LDAP, as a postfix alias map. Which begs the question ... should the maintainer database be in LDAP instead? (BTW., I was thinking along the lines of package groups, with multi-valued attribute for package name and maintainer. e.g.: dn: cn=firefoxteam,ou=Packages,dc=mageia,dc=org objectClass: mageiaPackageGroup cn: firefox-team mail: fire...@packages.mageia.org mageiaPackage: firefox mageiaPackage: firefox-en_gb mageiaPackage: firefox-ext-firebug mageiaMaintainer: f...@mageia.org mageiaMaintainer: b...@mageia.org owner: uid=xxx,ou=People,dc=mageia,dc=org D. if people really want to use their own personal email address, perhaps one can be opted-in to use that one. (but this should be decided in a policy and be strict on it either YES/NO) Per-user options are difficult to administer, I would prefer the same behaviour for everyone, and the choice to provide data at the user's discretion. E.g., the current situation, where contributors are requested to provide real givenName,sn, but are free to use whatever cn they prefer, and all external tools use cn. sn and givenName are only used for account/identity validation, legal requirements etc. and all uses of the data must respect privacy policy. personally, i like: A, B, C, but vote NO for D. i would like to use AL13N al...@mageia.org being used. my real name is kind of not linked the the email address. Well, I haven't seen any authoritative statement on whether all contributors will have @mageia.org aliases, and some work needs to be done for this if it will be provided. Regards, Buchan
Re: [Mageia-dev] RPM5 AND MAGEIA
- devzero2000 devzero2...@rpm5.org wrote: Apart from the rest - of which i will ask for sponsorship when it will be - I wanted to know if there are plans to move to rpm5 by Mageia, such as Mandriva has been doing lately. Rpm5 already has a builtbot with Magela and rpm5. I can, if you can think useful or have plan for this, lay the necessary modification to enter into rpm5 Mageia, with the features of Mandriva cooker - fingerprint, syslog, etc. without trademark ecc- and produce a first rpm rpm5 for mageia , which also contains the functionality required by the passage to the RPM ACID feauture (berkeley db conversion) But, can you: -ensure that all valid packages that build under rpm-4.x (e.g. in Mandriva 2010.x) will build under rpm5? -ensure that all valid packages that install under rpm-4.x will install under rpm-4.x? There is no document specifying what has changed, or even when highlighting changes, no-one (@rpm5.org, or @mandriva.com) has bothered to list them so that contributors can save time instead of troubleshooting breakage. Some issues that have impacted me so far: -changed behaviour of %exclude -new reserved macros (%sql) -possible race condition between %__os_install_post and processing of %files (.lzma man pages reported missing where they are in fact .xz) (and of course, the unavailability of the build system - during one of the periods I had the most time to work on packages - due to the rpm5 upgrade) rpm5 has wasted more than half of the time I could afford to contribute to Mandriva. It seems Mandriva has resources to waste, I don't think we have. (At present, I am not sure if I will continue to maintain packages in Mandriva, the ones where I need newer packages on non-Mandriva at work which I currently maintain in Mandriva and then rebuild I will maintain for the present, but ones I don't need for work may languish ...) Regards, Buchan
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
- Romain d'Alverny rdalve...@gmail.com wrote: * packagers/contributors [sh|w]ould use publish their real name (as registered in identity), I would just like to note that, during registration on identity, we only prompt for a 'First name' and 'Surname', however we populate the LDAP attributes 'givenName' and 'sn' respectively, but also populate 'cn' with the concatenation of these. For promoted accounts, we populate 'gecos' as well (which is typically displayed by the operating system) from cn. So far, I think all applications we have deployed or plan to deploy soon will use 'cn' as the user's real name (e.g. bugzilla). So, we should possibly distinguish more clearly between what names are in identity, and also distinguish between: * Package info (incl. changelog From header) should contain only organisation details * Package info should contain username * Package info should contain alias (e.g. cn) * Package info should contain real names according to identity (givenName,sn) This would possibly need to be considered for other cases such as forum, bugzilla, blog, wiki etc. etc. (although, ideally they would be consistent, so we can keep software configuration consistent). * packagers/contributors [sh|w]ould publish their contact email (same), * in their contributions to the project (here, in the changelog), * if it should be strictly enforced or not, and why. Is there any legal requirement, specifically in terms of proving copyright ownership of files contributed by users who have no legal connection to the association? Regards, Buchan
Re: [Mageia-dev] time to switch from raw partitions to lvm?
- Wolfgang Bornath molc...@googlemail.com wrote: 2011/2/21 Buchan Milne bgmi...@staff.telkomsa.net: On Monday, 21 February 2011 11:49:27 Thomas Lottmann wrote: I am still not convinced of how easy this can be. For having attempted to manage (and learn) how to manage LVM partitons with CentOS, it is quite complicated. So it certainly has many advantages, but I'm awaiting an intuitive disk manager like Diskdrake to manage this stuff without the need of preliminary knowledge. Yes, with diskdrake, it's no problem. Anaconda's LVM interface is quite confusing and complex. After installation, AFAIK, you can't access the same interface. system-config-lvm (if it's still around) was also pretty unusable. But, we have diskdrake, so why are the problems of CentOS an issue? Because (as I remarked earlier) there are people who have other Linux flavors on their harddisk before they try Mageia - what if they do their partitioning with those (i.e. CentOS)? Irrelevant. If there is free space, you can use LVM or not. Note CentOS defaults to LVM as of 5.x. If the whole disk is partitioned as a PV (likely with CentOS), then you will be forced to use LVM anyway ... Again, people do not work all the same. Irrelevant. If this was the case, we would *FORCE* everyone to use LVM, or a large single root filesystem, or a complex layout, or something else. But we aren't discussing forcing of anything, just what the *default* option should be. There are people who do their partitioning with 3rd-party apps like gparted or others. Then they should not use the default, if they think they know better. There are people who like to have a bootloader in the root partition of each Linux they install (using chainloader in the first Linux' grub), etc. Shame, IMHO putting bootloader in root partition is a bad idea. But, they can still do this. They can even install a bootloader in the boot partition of each distro, and use chainloader (which is what I do). No one is proposing preventing them from doing this. IMHO it is a bad idea to make LVM default, because there are too many cases around where people would not want LVM. IMHO, the majority of users *should* use LVM. The 10% who have specific reasons not to, will of course still be able to use normal partitions. The problem currently is that I suspect 90% of the users who should be using LVM, don't. Then, they need assistance from others to resize their /, or /home, or another filesystem that they sized incorrectly during installation. Users shouldn't need to learn to partition, or practice installing, by doing installations over and over until they figure out that / should be at least 10GB, but most likely not larger than 30GB, depending on whether they compile a lot (e.g. build packages or not). Is this really user-friendly? By this I mean, friendly to users who *haven't* used Linux before, not those who are installing their 10th distro on the same machine for the 15th time. LVM as an option is a far better solution and let the user decide what he wants. The user will still *always* be able to decide what he wants. The question is, what to do for users who don't know what to decide. IMHO, for a first time user, it is *much* better to give them a Use available space, with growable filesystems or similar, than a statically partitioned, based on difficult-to-get-right heuristics. Regards, Buchan
Re: [Mageia-dev] time to switch from raw partitions to lvm?
- Thorsten van Lil tv...@gmx.de wrote: Am 22.02.2011 09:07, schrieb Buchan Milne: The user will still *always* be able to decide what he wants. The question is, what to do for users who don't know what to decide. IMHO, for a first time user, it is *much* better to give them a Use available space, with growable filesystems or similar, than a statically partitioned, based on difficult-to-get-right heuristics. That's a good point. The step for partitioning is still the most complex one during the installation. There are really often questions and discussions how to partition the hard disk. Exactly. Dispensing with this requirement would make installation much easier, and still put the user in a position where they aren't setup for failure (all other solutions do, IMHO). But, as a user who doesn't know anything about LVM, we should only switch if the algorithm for LVM works really really stable and is easy With static partitions, the heuristics have to be good. For LVM, they just have to: -Ensure enough space for installation to succeed -Ensure a large percentage of the VG is not allocated (as growing is easier than shrinking) to use. It seems to me positive to switch to LVM for default but it's not really important, You obviously haven't seen how many users have questions about shrinking / from 50GB because they need more space for /home, or similar questions, on IRC. so we don't should risk to much and take the time it needs, instead of forcing it to be finished for the next release, for example. I listed the issues that I believe block switching to LVM by default. If they are fixed, I would think it would be an idea to launch the first stable release with LVM by default. Regards, Buchan
Re: [Mageia-dev] Test upgrade of server, second try
On Tuesday, 22 February 2011 18:54:06 Michael Scherer wrote: And for the missing rpms that are important : Maybe it is time to try and assign maintainers? tcpdump For the following, I don't currently have a mageia installation to package on. I *may* be able to try and solve this this week (involves a number of ssh tunnels ...), otherwise about March 15 is the first time I will have real bandwidth. nss_ldap pam_ldap ldapvi Regards, Buchan
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On Tuesday, 22 February 2011 20:09:17 andre999 wrote: Maarten Vanraes a écrit : Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer: Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit : If there are two packages, one in core and another in tainted, then doesn't urpmi need a way to recognise that the tainted package is newer than (an update to) the corresponding core package? I believe that this is achieved in Mandriva, because plf is greater than mdv. That's abusing release tag and it work by pure chance ( ie, had the plf decided to be called the guillomovitch liberation front, it would not have worked ). And this is quite inflexible, since people will always have plf packages, leading to users adding some rpm in skip.list with a regexp. This doesn't make much sense to treat tainted rpm as update to core, this is not the same notion. But we cannot express this in urpmi for the moment, as this would requires some way to say if you need to install something, prefer this source rather than this one. We can imagine a priority system, or we can simply say that if there is the same rpm on 2 media, we ask to the user ( except this would requires IMHO a better system than the current path based one to see what is in a rpm, but that's a rather long proposal to make ). But you are right this another set of issues to solve for dual life packages. after sleeping on this, i've had this idea: why don't we rename packages in tainted? keeping them in the same name, perhaps has issues with search engines, (ie: which version do you get?) i proposed renaming packages in tainted,(but not the release tag). would it be a good compromise if we named packages: orig_packagename-tainted-version-release ? the benefit of this could be adding an Obsoletes and Provides on the original package with the identical version. for building, i may have this solution: %tainted(%_optional_feature1 %optional_feature2 %optional_feature3) this would allow the buildbot to look for %tainted and if it does, it could rebuild it for tainted and add the particulars itself. this would simplify the whole plf/tainted thing easily. and since all 4 rpms are being built at the same time, you have no srpm problem either. WDYT? aside First of all, tainted in English implies that the software doesn't work. I have never seen that interpretation. Tainted is a synonym for contaminated. Contaminated doesn't mean that it doesn't work, it means that you should exercise caution in using it (e.g. you may not want to drink it, but you can use it to wash your car). http://www.encyclopedia.com/doc/1O999-taint.html (Unless it refers to food, in which case it means poisonous.) So we should choose a more appropriate name, such as constrained, or use the Ubuntu approach and use a name which doesn't literally describe the contents. (Multiverse, in their case.) Anything but something that implies that there is something inherently wrong with the package in question. There is something wrong with the package, it is contaminated by software patents. Regards, Buchan
Re: [Mageia-dev] time to switch from raw partitions to lvm?
On Monday, 21 February 2011 18:56:22 Jeff Robins wrote: Michael Scherer wrote: For a linux system, a lvm logical volume is just another disk. I've had issues in the past because Linux considered LVM just one logical disk and I think the average user would eventually have the same problem as well. I think moving to LVM as the default will create too many complaints and support requests in the end. A long time ago I had a system with 6 SCSI disks, each 1.2GB. The system was fairly useless with the single disks, but using LVM I had 1 disk of reasonable size. I ran the system for about a year with no problems, but then 1 of the disks failed. Normally this would be a medium inconvenience, because I would just have to restore the files from that one drive to another drive. However, with the LVM, ... or RAID0 ... I lost the ability to read the entire LVM. VG. I had to restore the entire system, which was a much bigger pain. I also could not obtain a disk of the same small size for a reasonable price, which I was told would make the problem even bigger. Irrelevant for LVM. Only partly relevant for RAID0. If I had used some redundancy, then I might have been able to restore the one disk, but I was a novice user and didn't understand the need. I think that most users who use the defaults and probably novice users, or at least will be after Mageia takes off. I think LVM support is a must, but I think making it the default, without also making some redundancy the default, will cause more problems than it solves. For single-disk systems, there is no difference. For multi-disk systems, whether it would have been any different depends on whether you had a single VG or multiple VGs. But, by the time you talk about 6 disks, we're not talking about a default anymore. Regards, Buchan
Re: [Mageia-dev] time to switch from raw partitions to lvm?
On Monday, 21 February 2011 14:19:23 Michael Scherer wrote: Le lundi 21 février 2011 à 10:56 +0100, Wolfgang Bornath a écrit : Another part of the discussion may be the fact that a large number of users are running dual (or multiple) boot systems, keeping the pre-installed Windows and adding Linux. Others will have Windows and Mandriva, adding Mageia. While LVM may be nice if you are running one OS on one harddisk, it may be not so easy when running 3 OS on one harddisk. Or different installations of the same Linux (like stable version and cauldron). IMHO, it is *easier* to run multiple distributions on one machine with LVM, as you don't have the problem of having to statically pre-assign partitions to different distributions, and then have to image one filesystem to enlarge the filesystem before it, shrink the one after it, and put it back ... The only complication is where to put bootloaders, multiple distros sharing /boot is not great, so I just make a few small boot partitions before my PVs. I do run lvm on Fedora and mac os x without any trouble. Windows out-the-box will not support any linux file system more than lvm, There are third-party drivers/software for accessing ext2/ext3 partitions under Windows, even LUKS+ext2/ext3. But, on LVM, I don't think there are any options. and the same goes for os x. I thought Mac OS X had ext2/ext3 read support? For a linux system, a lvm logical volume is just another disk. That's a bit of an over-simplification. Hot-plugged LVM systems (I have a 2*2TB external disk enclosure, running in SAFE50 mode, AKA half RAID0, half RAID1, RAID1 is a PV in a separate VG) don't auto-mount like hot-plugged non- LVM disks, rescue still have problems activating VGs until recently (may still be present), kernel upgrades may still mess up root= parameter on LVM etc. etc. I have been using LVM with online resizing in diskdrake since about Mandrake 8.2 (with XFS), and I think for users without non-Linux installations, it should be made more prominent or the default ... but only when all the remaining issues are addressed. Regards, Buchan
Re: [Mageia-dev] time to switch from raw partitions to lvm?
On Monday, 21 February 2011 11:49:27 Thomas Lottmann wrote: I am still not convinced of how easy this can be. For having attempted to manage (and learn) how to manage LVM partitons with CentOS, it is quite complicated. So it certainly has many advantages, but I'm awaiting an intuitive disk manager like Diskdrake to manage this stuff without the need of preliminary knowledge. Yes, with diskdrake, it's no problem. Anaconda's LVM interface is quite confusing and complex. After installation, AFAIK, you can't access the same interface. system-config-lvm (if it's still around) was also pretty unusable. But, we have diskdrake, so why are the problems of CentOS an issue? Regards, Buchan
Re: [Mageia-dev] time to switch from raw partitions to lvm?
On Sunday, 20 February 2011 17:51:27 Thierry Vignaud wrote: Hi What do you think about switching from defaulting to installing on raw partitions to lvm installing on LVs like fedora does ? It does help brings more flexibility. Sure, but it can still introduce boot problems after kernel upgrade. The bug about kernel commandline containing 'root=/dev/' seems to still occur (at least on Mandriva 2010.x). However, it would be nice to have it, leaving some space on the VG, and possibly have urpmi prompt to extend filesystems if it is required for software installation/upgrade. Regards, Buchan
