[Mageia-dev] freeze push: tt-rss-1.7.8
Hi, Please push tt-rss-1.7.8 This is a webapp, no package depends on it, and the previous release was a git snapshot. Thanks -- Olivier Blin - blino
Re: [Mageia-dev] Update to boost-1.53 ?
Barry Jackson writes: > On 04/04/13 16:29, Olivier Blin wrote: >> Did you try the one I already mentionned in this thread earlier? >> >> Quoting below: >> >> We could backport this in boost 1.53 to fix libyui: >> https://svn.boost.org/trac/boost/changeset/82103 >> > Those two patches are already applied in 1.53 Right :-/ Maybe you ca push boost 1.53 to svn so that we can help? -- Olivier Blin - blino
Re: [Mageia-dev] Update to boost-1.53 ?
Angelo Naselli writes: >> Hi, The problem is in this build log:- >> http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/libyui-2.42.4-0.git20130107.3.mga3.src.rpm/build.0.20130328124443.log > > Barry i cannot test this now, but if i understood correctly the problem > and talking to libyui developer this patch should work. > > Can you test it and tell me if it's ok please? Hi, It does not seem your patch will fix this build issue, there is no error in YUIException.h Did you try the one I already mentionned in this thread earlier? Quoting below: We could backport this in boost 1.53 to fix libyui: https://svn.boost.org/trac/boost/changeset/82103 See https://svn.boost.org/trac/boost/ticket/7809 (libyui is built with -std=c++0x) -- Olivier Blin - blino
Re: [Mageia-dev] Update to boost-1.53 ?
Barry Jackson writes: >> Could someone try this patch from upstream? >> http://vegastrike.svn.sourceforge.net/viewvc/vegastrike/trunk/vegastrike/src/networking/lowlevel/packetmem.cpp?r1=12089&r2=13530 >> > Thanks Oliver - no idea how you dug that out! I just followed on upstream svn the history of the file that failed to build. Upstream is sometimes picking up quickly new versions of external librarie. Upstream svn/git/bzr/... is always worth a look when trying to fix something :-) -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release firefox-17.0.5-1.mga3
Thierry Vignaud writes: > On 3 April 2013 10:58, guillomovitch wrote: >> fwang 0:17.0.5-1.mga3: >> + Revision: 407104 >> - new version 17.0.5esr > > BTW, gfx acceleration has been disabled for mesa by ff devs in 17esr... > See https://bugzilla.mozilla.org/show_bug.cgi?id=838413 Can't we revert that? Was is the ANGLE bug they are mentioning? -- Olivier Blin - blino
Re: [Mageia-dev] Update to boost-1.53 ?
Anssi Hannula writes: > 31.03.2013 12:47, Barry Jackson kirjoitti: >> As mentioned in last week's packager's meeting, there is a problem with >> our gnuradio package, because upstream have blacklisted boost-1.52. >> https://bugs.mageia.org/show_bug.cgi?id=8789 >> >> I have spent considerable time test rebuilding all packages from current >> svn that BuildRequire boost, against boost-1.53 to see if an update of >> boost is viable. (x86_64 only so far) >> >> Fixes have been applied to some packages and now there are just two >> remaining that fail to build:- >> >> libyui [...] >> The alternative to updating boost would be to drop gnuradio from Mageia3. > > Third alternative is to backport the boost fix to 1.52: > https://svn.boost.org/trac/boost/changeset/81289 Going back to first alternative, we could backport this in boost 1.53 to fix libyui: https://svn.boost.org/trac/boost/changeset/82103 See https://svn.boost.org/trac/boost/ticket/7809 (libyui is built with -std=c++0x) -- Olivier Blin - blino
Re: [Mageia-dev] [packages-commits] [407099] fix build with recent automake
Charles A Edwards writes: > On Tue, 2 Apr 2013 08:10:56 +0200 (CEST) > r...@mageia.org wrote: > > >> syncevolution-1.3.99.3/src/synthesis/configure.in >> 2013-04-02 00:21:58.192768860 +0200 +@@ -5,7 +5,7 @@ >> + # four digit upstream version, one additional digit for >> + # Linux/SyncEvolution specific extensions: >> + AM_INIT_AUTOMAKE(synthesis, 3.4.0.16.8) >> +-AM_CONFIG_HEADER(config.h) >> ++AC_CONFIG_HEADER(config.h) > > Was this a typo? > > Shouldn't it be AC_CONFIG_HEADERS(config.h) No, it is not a typo, this is defined in /usr/share/autoconf/autoheader.m4 Though, it does not seem to be documented -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lxc-0.8.0-1.mga3
Thierry Vignaud writes: > On 1 April 2013 15:07, tv wrote: >> tv 1:0.8.0-1.mga3: >> + Revision: 407033 >> - new release >> - disable apparmor (fix build) >> - adjust filelist >> - add epoch due to bogus prior packaging > > BTW never put "rcX" or "betaX" in version. > That breaks updates as eg "0.8.0" is lesser than "0.8.0rc2" for rpm > such details go in %release such as "0.1rc2" Maybe we could have a rpmlint rule to prevent having alpha/beta/rc/svn/git in version tags -- Olivier Blin - blino
Re: [Mageia-dev] Update to boost-1.53 ?
David Walser writes: > Barry Jackson wrote: >> As mentioned in last week's packager's meeting, there is a problem with >> our gnuradio package, because upstream have blacklisted boost-1.52. >> https://bugs.mageia.org/show_bug.cgi?id=8789 >> >> I have spent considerable time test rebuilding all packages from current >> svn that BuildRequire boost, against boost-1.53 to see if an update of >> boost is viable. (x86_64 only so far) >> >> Fixes have been applied to some packages and now there are just two >> remaining that fail to build:- > > Now that it's down to these two, I think this should be done. libyui > is only here for the new MCC which won't be ready at least until mga4, > and it seems this gnuradio is important to some people, while > vegastrike is just a game I think. Even if "just a game", it may be of some importance to our users :-) Could someone try this patch from upstream? http://vegastrike.svn.sourceforge.net/viewvc/vegastrike/trunk/vegastrike/src/networking/lowlevel/packetmem.cpp?r1=12089&r2=13530 -- Olivier Blin - blino
Re: [Mageia-dev] Freeze Push: libva
Colin Guthrie writes: [...] > Wayland support can now be compiled if we want it (tested that it > builds) but I did not enable it to avoid adding a further automatic dep > on wayland-client libs for now. If we want it it can either just be > enabled, or enabled and packaged as a sub-package. Hi, wayland-client libs are anyway already pulled by lib64gtk+3_0, gstreamer1.0-plugins-bad and lib64mesaegl1 (pulled by many graphics stack packages), so I guess you can keep wayland enabled in libva. -- Olivier Blin - blino
Re: [Mageia-dev] drakxtools & drakx-installer-stage2 (mga#9428)
Glen Ogilvie writes: > I guess someone must know how Mageia-3-beta3-x86_64-DVD.iso, and the > other images get created. I don't want to rebuild all the packages that go > in > them, just assemble one with the same packages as > Mageia-3-beta3-x86_64-DVD.iso, and a updated install/stage2/mdkinst.sqf > file. Hi, These are created with the bcd tool. -- Olivier Blin - blino
Re: [Mageia-dev] No package named nss_ldap
Colin Guthrie writes: > 'Twas brillig, and R James at 13/03/13 21:48 did gyre and gimble: >> I'd like to test LDAP client authentication hit a roadblock: >> >> [root@localhost ~]# urpmi pam_ldap >> A requested package cannot be installed: >> pam_ldap-186-4.mga3.x86_64 (due to unsatisfied nss_ldap[>= 217]) >> Continue installation anyway? (Y/n) n [...] > It's been reported before, but basically the solution is to not use > nss_ldap or pam_ldap but alternative packages nss-pam-ldapd and sssd. Shouldn't we drop pam_ldap then? -- Olivier Blin - blino
Re: [Mageia-dev] Freeze push: worldofpadman and worldofpadman-data
Juan Luis Baptiste writes: > That's strange... I did a mgarepo sync with no errors, and if I run it > now it doesn't try to upload the sources as they seem to be already > uploaded: > > [mageia@dci-laptop worldofpadman-data]$ mgarepo sync > [mageia@dci-laptop worldofpadman-data]$ > > But the sources don't seem to be recognized by svn: > > [mageia@dci-laptop SOURCES]$ ls > README.install.urpmi sha1.lst wop-1.5-unified.zip > wop-1.5.x-to-1.6-patch-unified.zip > [mageia@dci-laptop SOURCES]$ svn status > ? wop-1.5-unified.zip > ? sha1.lst > ? wop-1.5.x-to-1.6-patch-unified.zip > > How to fix this ? a svn add on those files ? You just have to svn add sha1.lst, the other files are binaries that should not be hosted on the svn repository. boklm: mgarepo sync should really do this automatically for us :-) -- Olivier Blin - blino
Re: [Mageia-dev] Bug #7633
Thierry Vignaud writes:
> On 28 February 2013 22:18, Olivier Blin wrote:
>>> https://bugs.mageia.org/show_bug.cgi?id=7633
>>>
>>> Can we do something about this bug? 80+ people in CC getting spammed
>>> every second day. If we can't fix it then let's drop it.
>>
>> Hi,
>>
>> Just putting an eval {} block like this in lib/MDV/Snapshot/Hal.pm
>> should be enough:
[...]
>> We just won't be able to automatically detect the backup disk mount point.
>
> Or someone should do the same thing as for perl-Hal-Cdroms (should be
> easy, just needs time):
> http://svnweb.mageia.org/soft/perl-Hal-Cdroms/trunk/lib/Hal/Cdroms.pm?view=log
Or even better, port to udisks2 (and not udisks1) :-)
--
Olivier Blin - blino
Re: [Mageia-dev] Bug #7633
Sander Lepik writes:
> Hi!
>
> https://bugs.mageia.org/show_bug.cgi?id=7633
>
> Can we do something about this bug? 80+ people in CC getting spammed
> every second day. If we can't fix it then let's drop it.
Hi,
Just putting an eval {} block like this in lib/MDV/Snapshot/Hal.pm
should be enough:
sub find_removable_volumes {
my ($dbus) = @_; # perl_checker: $dbus = Net::DBus->new
eval {
my $hal = $dbus->get_service($hal_dn); # perl_checker: $dbus =
Net::DBus->new
my $manager = $hal->get_object($manager_path, $hal_manager); #
perl_checker: $manager = Net::DBus::RemoteObject
grep { is_proper_device($_, 1) } map { $hal->get_object($_,
"$hal_dn.Device") } @{$manager->GetAllDevices};
}
}
We just won't be able to automatically detect the backup disk mount point.
--
Olivier Blin - blino
Re: [Mageia-dev] Help needed: rpmlint checks not working
nicolas vigier writes: >> > > The file distribution.error.list from rpmlint-mageia-policy is not used >> > > by the buildsystem to reject uploads. Instead it is using a list of >> > > rpmlint errors defined in youri configuration. I added them now : >> > > http://svnweb.mageia.org/adm/puppet/modules/buildsystem/templates/youri/submit-upload.conf?r1=2928&r2=2963 >> > > >> > > Maybe we could change it to use distribution.error.list file instead. [...] > This should now be fixed. > > http://svnweb.mageia.org/adm/puppet/modules/buildsystem/templates/youri/submit-upload.conf?r1=2963&r2=2967 This is still an hardcoded list that does not reflect the default Mageia policy from rpmlint-mageia-policy, and this is quite a maintenance burden. Why don't we use rules from these packages directly? If needed, we could maybe have setup per-distro extraction of rpmlint policy on upload of the rpmlint-mageia-policy package. -- Olivier Blin - blino
Re: [Mageia-dev] Help needed: rpmlint checks not working
Thierry Vignaud writes: > My point is we just added to _CAULDRON_ == mga3 a lot of rules that were > missed, > just after mass rebuild, and I fear that when we'll try to issue > updates to _mga3_, > we may see some being rejected, this is why I ask we check current cauldron > with upload server rpmlint config... Right, we need to schedule a new mass rebuild, to check packages against the real rpmlint rules. -- Olivier Blin - blino
Re: [Mageia-dev] Trying to install Google Musicmanager under Cauldron
Donald Stewart writes: > On 14 January 2013 20:27, Robert Fox wrote: >> A requested package cannot be installed: >> google-musicmanager-beta-1.0.54.4672-0.x86_64 (due to unsatisfied >> qtwebkit) >> Continue installation anyway? >> >> [root@ThinkFox Downloads]# rpm -qa | grep qtwebkit >> libqtwebkit2.2_4-2.2.2-5.mga3 >> qtwebkit-qmlplugin-2.2.2-5.mga3 >> lib64qtwebkit2.2_4-2.2.2-5.mga3 > > I just forced the install without the deps... Hi, If it works fine after installing with --nodeps, maybe we could add "qtwebkit" provides in the matching package. Do you know if this application is linked against libQtWebKit.so.4? -- Olivier Blin - blino
Re: [Mageia-dev] /usr/bin/file broken on cauldron
Luc Menut writes: > Thanks to all for the fix. > I confirm that file-5.12-6 fixes the problem. > After some quick tries, it seems that file 5.12 gives now the same > results as file 5.11. Actually, there is one patch I reverted, thinking it was merged because patch detected it as reversed, but it was again because of a modified RCSID in the new 5.12 tarball. I'll add the patch back, this should fix "file -i" for ELF shared libraries and executables. -- Olivier Blin - blino
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
Maurice Batey writes: > On Wed, 09 Jan 2013 14:35:41 -0500, Frank Griffin wrote: > >> bug 8614 for all this was just fixed. > > It says: "Fixed with: glibc-2.17-2.mga3 and util-linux-2.22.2-2.mga3" > > but in my (newly-recovered from Kernel Panic) Mga3-A2, > MCC/SW/Update shows the following packages available: > > glib v2.17 > glibc-devel v2.17 > meta-task v3 You might need to run this command to update initrds: bootloader-config --action rebuild-initrds -- Olivier Blin - blino
Re: [Mageia-dev] /usr/bin/file broken on cauldron
Luc Menut writes: > It's better, but file-5.12-5 still mis-detects some script files; I > can see that some Perl or shell scripts are reported as 'assembler > source text' with 5.12-5. [...] > /usr/bin/automake: assembler source text > /usr/bin/iurt: assembler source text > It's very annoying because /usr/bin/file is used by find-requires and [...] > find-provides, and if we do the mass rebuild with a broken > /usr/bin/file, we will build some rpms with incorrect provides and > requires. Hi again, This might be this one: http://mx.gw.com/pipermail/file/2013/001026.html Which is claimed to be fixed by the maintainer: http://mx.gw.com/pipermail/file/2013/001040.html Can you try with upstream git? https://github.com/glensc/file/commits/master -- Olivier Blin - blino
Re: [Mageia-dev] /usr/bin/file broken on cauldron
Luc Menut writes: > Hi all, > > /usr/bin/file is broken on cauldron (file-5.12-4.mga3). > It gives weird bogus results (i586 and x86_64), and breaks some builds. > eg. file /usr/bin/xdg* > /usr/bin/xdg-desktop-icon: , 28265 > /usr/bin/xdg-desktop-menu: , 28265 > /usr/bin/xdg-email:, 28265 > /usr/bin/xdg-icon-resource:, 28265 > /usr/bin/xdg_menu: assembler source text > /usr/bin/xdg-mime: , 28265 > /usr/bin/xdg-open: , 28265 > /usr/bin/xdg-screensaver: , 28265 > /usr/bin/xdg-settings: , 28265 > /usr/bin/xdg-user-dir: , 28265 > /usr/bin/xdg-user-dirs-gtk-update: ELF 64-bit LSB executable, ... > /usr/bin/xdg-user-dirs-update: ELF 64-bit LSB executable, ... Hi, Upstream file 5.12 looks quite broken :-/ They updated the 5.12 release tarball (!) on the FTP site with a collection of fixes, that's quite a bad practice... See this thread about your issue: http://mx.gw.com/pipermail/file/2013/001019.html It should be fixed in 5.12-5.mga Cheers -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release wireshark-1.8.4-2.mga3
wally writes: > Name: wiresharkRelocations: (not relocatable) > Version : 1.8.4 Vendor: Mageia.Org > Release : 2.mga3Build Date: Sat Dec 1 17:48:14 > 2012 > Install Date: (not installed) Build Host: jonund.mageia.org > Group : MonitoringSource RPM: (none) > Size: 24192404 License: GPLv2+ and GPLv3 > Signature : (none) > Packager: wally > URL : http://www.wireshark.org > Summary : Network traffic analyzer > Description : > Wireshark is a network traffic analyzer for Unix-ish operating systems. It is > based on GTK+, a graphical user interface library, and libpcap, a packet > capture and filtering library. > > wally 1.8.4-2.mga3: > + Revision: 324195 > - install dumpcap setuid root as upstream suggests (to allow to start > wireshark as normal user) > - drop run-as-root hacks Hi, It seems you introduced a security flaw: now all users are able to capture the network traffic. This should be reverted, or restrictions should be added (maybe by making consolekit add acls if possible). -- Olivier Blin - blino
Re: [Mageia-dev] [soft-commits] [6689] Get rid of cache
Pascal Terjan writes: > On Mon, Dec 10, 2012 at 9:26 PM, Thierry Vignaud > wrote: >> On 10 December 2012 21:50, wrote: >>> Get rid of cache >> >> meaning we now rely on btrfs snapshots? > > This cache was a cache of the list of package that had been built / had failed > It was used when iurt was used to build x86_64 packages when i586 were > newer, it allowed to restart iurt without needing to scan the mirror > again + had a feature to run several iurt on different machines with a > cached shared over nfs. > > I am also planning to get this whole way of using it out of iurt and > make it only rebuild the packages requested on command line. Does this mean you will break/remove the dkms rebuild support? -- Olivier Blin - blino
Re: [Mageia-dev] New install repo options
Frank Griffin writes: > I just did a new install and noticed the panel for the addition of the > nonfree and tainted repos. Kudos to Thierry for this! :-) -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.7.0-0.rc8.1.mga3
Thierry Vignaud writes: > On 7 December 2012 00:08, tmb wrote: >> tmb 3.7.0-0.rc8.1.mga3: >> + Revision: 327546 >> - add perf bash_completion >> - more filelist updates >> - add 3.7 buildfixes for alx, IFWLOG, mach64, ndiswrapper >> - pull in more upstream git fixes >> - rediff disable-mrproper patch >> - update to current rc8+ git >> - update filelists >> - update defconfigs >> - restore patch preferring ata over ide drivers > > BTW kernel-linus is still affected. > Of course this conflicts with the policy patch... Maybe something worth being submitted upstream then? -- Olivier Blin - blino
Re: [Mageia-dev] new environment variable for rpmbuild?
Jerome Quelin writes: > On 12/12/06 19:45 +0100, nicolas vigier wrote: >> On Thu, 06 Dec 2012, Jerome Quelin wrote: >> > Would it be possible to add a new environment variable for rpmbuild to >> > use when building rpms? >> > >> > new variable: PERL_AUTOINSTALL=--skipdeps >> >> If it's needed in %install, it can be added to %__spec_install_pre : >> http://svnweb.mageia.org/soft/rpm/rpm-setup/trunk/build.macros.in?revision=6508&view=markup#l288 >> >> Is it needed in %prep or %build ? > > Sorry for the delay before answering - it's needed in %build. Can't we add some %__spec_build_pre macro with these then? -- Olivier Blin - blino
Re: [Mageia-dev] [soft-commits] [6573] Add script to rebuild a list of packages
r...@mageia.org writes: > Revision: 6573 > Author: boklm > Date: 2012-12-04 22:15:33 +0100 (Tue, 04 Dec 2012) > Log Message: > --- > Add script to rebuild a list of packages > > Added Paths: > --- > release/trunk/rebuild-packages Hi, Isn't this duplicate with the magpie tool? http://jquelin.blogspot.fr/2011/02/magpie-mageia-perl-integration-easy.html -- Olivier Blin - blino
Re: [Mageia-dev] [soft-commits] [6562] Allow setting some env variables to define and default to setting PERL_EXTUTILS_AUTOINSTALL and PERL_AUTOINSTALL to --skipdeps
Pascal Terjan writes:
> On Tue, Dec 4, 2012 at 11:10 PM, Olivier Blin wrote:
>> r...@mageia.org writes:
>>
>>> Revision: 6562
>>> Author: pterjan
>>> Date: 2012-12-04 14:22:38 +0100 (Tue, 04 Dec 2012)
>>> Log Message:
>>> ---
>>> Allow setting some env variables to define and default to setting
>>> PERL_EXTUTILS_AUTOINSTALL and PERL_AUTOINSTALL to --skipdeps
>>
>> Why is this in iurt?
>
> Because rebuild of the distro was strongly slowed down due to this
> (current build is running with default timeout meaning that each perl
> package which had this problem caused us to lose 6 hours) so
> preventing it from happening in iurt is something I want whatever is
> done in general. I have also added some code in iurt to detect stalled
> builds.
But will the timeout be big enough to let WebKit link go through? :-)
>> Shouldn't it be the default in our default rpmbuild setup?
>
> Probably
Maybe we should have a macro for "perl Makefile.PL" with your variables
exported, if this is where the hang happened.
perl-HTML-Parser even has the following...
# compile with default options (prompt() checks for STDIN being a terminal).
# yes to not ask for automate rebuild
yes | %{__perl} Makefile.PL INSTALLDIRS=vendor
%make OPTIMIZE="%{optflags}"
--
Olivier Blin - blino
Re: [Mageia-dev] [soft-commits] [6562] Allow setting some env variables to define and default to setting PERL_EXTUTILS_AUTOINSTALL and PERL_AUTOINSTALL to --skipdeps
r...@mageia.org writes: > Revision: 6562 > Author: pterjan > Date: 2012-12-04 14:22:38 +0100 (Tue, 04 Dec 2012) > Log Message: > --- > Allow setting some env variables to define and default to setting > PERL_EXTUTILS_AUTOINSTALL and PERL_AUTOINSTALL to --skipdeps Why is this in iurt? Shouldn't it be the default in our default rpmbuild setup? -- Olivier Blin - blino
Re: [Mageia-dev] Clanlib2 and SSE2 on i586
Guillaume Rousse writes: > Le 03/12/2012 23:42, zezinho a écrit : >> Trying to launch openalchemist gave me a crash because Clanlib2 uses >> SSE2 on SSE2 systems for software rendering, while we disabled it at >> configure. >> >> What should we do? I think enabling it is better, as all i586 CPU with >> less than 10 years come with SSE2. But our policy forbids it ;-) > Cool. Now we have software crashing because they don't use available > features, what a nice idea... Recent CPUs also all come out with x86_64 support, so the i586 port is basically only used for older CPUs. It makes sense to not enable SSE* optimizations for i586, to be compatible with Geode/VIA/etc processors. -- Olivier Blin - blino
Re: [Mageia-dev] Utter frustration
AL13N writes: > Op donderdag 29 november 2012 23:39:23 schreef Olivier Blin: >> AL13N writes: >> > Op donderdag 29 november 2012 21:14:18 schreef Donald Stewart: >> >> On 29 November 2012 21:11, AL13N wrote: >> >> > is there a reason you have installed packagekit? >> >> > >> >> > it's an alternative for package management, (it should run on top of >> >> > urpmi), but i don't think it even works right... >> >> > >> >> > if i was you, i'd start to get rid of at least all that is packagekit >> >> > >> >> > no idea if it'll help your issue though... >> >> >> >> It gets pulled as a suggests to handle various codecs, I think from >> >> either the phonon-gstreamer or just gstreamer packages. >> > >> > that's too bad, it should be removed imho. >> >> No, packagekit is a good package manager abstraction that makes possible >> to share work among distributions. >> >> It should be improved to work better with urpmi instead. > > i have no troubles with that... but if we're trying to fix bugs, maybe we can > start by stripping what is known to be not working well atm... > > i don't think anne is a dev and plans on fixing packagekit integration It is not for developers, it is useful for end users. -- Olivier Blin - blino
Re: [Mageia-dev] Utter frustration
AL13N writes: > Op donderdag 29 november 2012 21:14:18 schreef Donald Stewart: >> On 29 November 2012 21:11, AL13N wrote: >> > is there a reason you have installed packagekit? >> > >> > it's an alternative for package management, (it should run on top of >> > urpmi), but i don't think it even works right... >> > >> > if i was you, i'd start to get rid of at least all that is packagekit >> > >> > no idea if it'll help your issue though... >> >> It gets pulled as a suggests to handle various codecs, I think from >> either the phonon-gstreamer or just gstreamer packages. > > that's too bad, it should be removed imho. No, packagekit is a good package manager abstraction that makes possible to share work among distributions. It should be improved to work better with urpmi instead. -- Olivier Blin - blino
Re: [Mageia-dev] NetworkManager vs initscripts
Colin Guthrie writes: > I thought the default had flipped to being "if the NM_CONTROLLED does > not exist, then assume it's true" before mga2 came out. > > I'm maybe mis-remembering tho'. Blino can you correct me?? It looks to be the case in network-functions from initscripts, but is this the case in NetworkManager ifcfg plugin? -- Olivier Blin - blino
Re: [Mageia-dev] NetworkManager vs initscripts
JA Magallón writes: > Network starts and stops ok, but on reboot, some process inists on creating > a ifcfg-eth0 file, with this setup: > > DEVICE=eth0 > BOOTPROTO=dhcp > ONBOOT=yes > > which breaks networking on systems that have a fixed IP, and works by chance > if you use DHCP. > > Who creates that ? This is created by udev rules. > How can I kill it ? You can just set NM_CONTROLLED=yes in the generated ifcfg files. -- Olivier Blin - blino
Re: [Mageia-dev] OpenVPN missing PID dir
Colin Guthrie writes: > 'Twas brillig, and Olivier Blin at 25/11/12 15:19 did gyre and gimble: >> Colin Guthrie writes: >> >>> 1. "systemd-tmpfiles --create" is not run in the %post (before >>> add-service helper) (note that on cauldron the command must be: >>> "systemd-tmpfiles --create openvpn.conf"). This means that you'll need a >>> reboot before openvpn will work on mga2 after installing it. >> >> Hi, >> >> Shouldn't this be done through a rpm filetrigger? > > I don't think there is a way to specify which files triggered the file > trigger is there? > > Basically we'd need to know the basename of the file that changed, also > there are times when it has to be excluded (e.g. some files should not > be run except at boot). Looks like this list is available to the script from stdin, see /var/lib/rpm/filetriggers/httpd.script or /var/lib/rpm/filetriggers/pear.script -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] 2 core/updates_testing firefox-17.0-3.mga2
Thierry Vignaud writes:
> On 25 November 2012 16:15, Olivier Blin wrote:
>>>> This looks strongly like #6299 (symbols conflicts between firefox's
>>>> mozjs and mozjs185 pulled by libproxy).
>>>> It did not occur with the initial firefox version from Mageia 2, I think
>>>> it started with firefox 13.
>>>>
>>>> I suggest pushing to Mageia 2 updates libproxy-0.4.7-9 (or why not
>>>> 0.4.10-1 since it fixes more issues).
>>>
>>> It fixed this crash
>>> Now just add the proper conflict tag in order to have a smooth upgrade:
>>> Conflicts: %{_lib}proxy1 < 0.4.10
>>>
>>> (also in cauldron)
>>
>> Great!
>> Which conflict is this supposed to fix?
>
> .
> $ rpm -qR firefox |grep proxy
> libproxy.so.1()(64bit)
>
> However it won't run without latest libproxy and will just segfault with older
> libraries.
> Having proper versionned requires will ensure it will pull a working set of
> packages.
> Also having proper versionned requires in cauldron package means
> that we'll know what to backport when pushing such an update.
It should be a Requires then, not a Conflicts, since firefox already
requires libproxy.
--
Olivier Blin - blino
Re: [Mageia-dev] OpenVPN missing PID dir
Colin Guthrie writes: > 1. "systemd-tmpfiles --create" is not run in the %post (before > add-service helper) (note that on cauldron the command must be: > "systemd-tmpfiles --create openvpn.conf"). This means that you'll need a > reboot before openvpn will work on mga2 after installing it. Hi, Shouldn't this be done through a rpm filetrigger? -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] 2 core/updates_testing firefox-17.0-3.mga2
Thierry Vignaud writes:
> On 24 November 2012 17:01, Olivier Blin wrote:
>>> Much to the despair of my young nephews, it segfaults on :
>>> http://www.youtube.com/watch?v=fhCIDe92iKQ
>
> (...)
>
>> This looks strongly like #6299 (symbols conflicts between firefox's
>> mozjs and mozjs185 pulled by libproxy).
>> It did not occur with the initial firefox version from Mageia 2, I think
>> it started with firefox 13.
>>
>> I suggest pushing to Mageia 2 updates libproxy-0.4.7-9 (or why not
>> 0.4.10-1 since it fixes more issues).
>
> It fixed this crash
> Now just add the proper conflict tag in order to have a smooth upgrade:
> Conflicts: %{_lib}proxy1 < 0.4.10
>
> (also in cauldron)
Great!
Which conflict is this supposed to fix?
--
Olivier Blin - blino
Re: [Mageia-dev] Utter frustration
Frank Griffin writes: > Do you have an I-take-everything cauldron or a pick-and-choose > cauldron ? Nobody ever seems to announce policy changes on this ML, > but I gather that the winds of favor have moved from ConsoleKit to > PolicyKit (or maybe it's the other way around), so if, for example, > ConsoleKit is now deprecated but you still have packages installed > that want it, you might be getting the errors you mention below. We had a thread about deprecating hal (replaced by udisks2), policykit (replaced by polkit) and consolekit (replaced by systemd logind). Before obsoleting these, we made sure that all packages requiring them had been fixed to use the replacement. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] 2 core/updates_testing firefox-17.0-3.mga2
Thierry Vignaud writes: > On 24 November 2012 01:51, dmorgan wrote: >> dmorgan 0:17.0-3.mga2: >> + Revision: 321475 >> - Fix xml file >> - Enable Opus support >> - New version 17.0esr > 0 > Much to the despair of my young nephews, it segfaults on : > http://www.youtube.com/watch?v=fhCIDe92iKQ > > Program received signal SIGSEGV, Segmentation fault. > 0x003afe4a88cd in ?? () from /usr/lib64/libmozjs185.so.1.0 > (gdb) bt > #0 0x003afe4a88cd in ?? () from /usr/lib64/libmozjs185.so.1.0 [...] > #6 0x7fab95ae in js::IndirectProxyHandler::call(JSContext*, > JSObject*, unsigned int, JS::Value*) () >from /usr/lib64/firefox-17.0/libxul.so Hi, This looks strongly like #6299 (symbols conflicts between firefox's mozjs and mozjs185 pulled by libproxy). It did not occur with the initial firefox version from Mageia 2, I think it started with firefox 13. I suggest pushing to Mageia 2 updates libproxy-0.4.7-9 (or why not 0.4.10-1 since it fixes more issues). -- Olivier Blin - blino
Re: [Mageia-dev] Can't win - or, best of both worlds . . .!
Frank Griffin writes: > On 11/23/2012 03:46 AM, Robert Fox wrote: >> There has been much discussion over the KDE NetApplet and the lack of >> reliability with it - on my laptop (Thinkpad X220) it crashes regularly >> and I can't get it to switch between WWAN0 and WLAN0 without failing. >> Strangely, under Gnome - the Gnome network manager works flawlessly. I >> can easily start and stop the WiFi or UMTS connection without problems. >> > "Can't win" is appropriate. You may want to check the comments in bug#8169. > > Apart from any net-applet crash, ifplugd is failing to start wireless > interfaces with current kernels Hi, Do you have any more details about this? It works fine here. Also check that you are using initscripts 9.34-30.mga3 -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release totem-3.6.3-2.mga3
Olivier Blin writes: > JA Magallón writes: >>> ovitters 3.6.3-2.mga3: >>> + Revision: 318912 >>> - requires gstreamer1(element-scaletempo) (mga#8088) >> >> Mmm, something is wrong: >> >> pandora:~# rpm -q --provides gstreamer1.0-plugins-bad | grep scale >> libgstscaletempoplugin.so()(64bit) >> gstreamer1(element-scaletempo)()(64bit) >> >> pandora:~# urpmi totem >> A requested package cannot be installed: >> totem-3.6.3-2.mga3.x86_64 (due to unsatisfied gstreamer1(element-scaletempo)) > > We need something like the %arch_tagged macro, but adding the (64bit) > suffix instead of (lib64) > See /etc/rpm/macros.d/20build.macros for its definition. > > Or maybe just change %arch_tagged to use (64bit) instead of (lib64), it > would be a lot more consistent. Just done in new rpm-setup > This requires rebuilding all packages using this macro, is it just about > mageia-release? Actually, this does not require rebuilding them, the arch_tagged provides/requires are currently just used in packages from the same src.rpm (mageia-release, postgresql) -- Olivier Blin - blino
Re: [Mageia-dev] KDE 4.9.3 is landing
Funda Wang writes: > Suggestion, do you want to put qt5 libs into /usr/lib directly after lib > rename? Hi, I talked about this with Nicolas, and this is not really necessarily easy to do, because we still need different prefixes for per-version includes or share directory, so just installing all of qt in /usr/lib/qt is easier. > 在 2012年11月17日星期六，Nicolas Lécureuil 写道： >> Le vendredi 16 novembre 2012 19:46:53 John Balcaen a écrit : >>> 2012/11/15 Nicolas Lécureuil >>> >>> > Le jeudi 15 novembre 2012 20:57:36 John Balcaen a écrit : >>> > > Hello, >>> > > >>> > > I'm pushing KDE 4.9.3 on cauldron. >>> > > After we'll certainly switch to KDE 4.10 beta1 >>> > > >>> > > Regards, >>> > >>> > yes :) as it should be available on wednesday :) >>> >>> Yep. >>> I'll start tonight to work on new tarballs :) >>> >>> Regards, >> >> btw tell if needed ( i will have time after qt5 split ) >> > > Suggestion, do you want to put qt5 libs into /usr/lib directly after > lib rename? > > 在 2012年11月17日星期六，Nicolas Lécureuil > 写道： >> Le vendredi 16 novembre 2012 19:46:53 John Balcaen a écrit : >>> 2012/11/15 Nicolas Lécureuil >>> >>> > Le jeudi 15 novembre 2012 20:57:36 John Balcaen a écrit : >>> > > Hello, >>> > > >>> > > I'm pushing KDE 4.9.3 on cauldron. >>> > > After we'll certainly switch to KDE 4.10 beta1 >>> > > >>> > > Regards, >>> > >>> > yes :) as it should be available on wednesday :) >>> >>> Yep. >>> I'll start tonight to work on new tarballs :) >>> >>> Regards, >> >> btw tell if needed ( i will have time after qt5 split ) >> > -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release urpmi-7.10-1.mga3
Thierry Vignaud writes: > On 19 October 2012 14:53, Olivier Blin wrote: >>> tv 7.10-1.mga3: >>> + Revision: 307687 >>> - do not offer to remove DKMS modules for current kernel (mga#5092) >> >> Hi, >> >> Now urpme orphans tries to remove the current kernel, and prebuilt dkms >> packages for the latest kernel. > > Fixed Thanks dear, you deserve a lot of "dentifrice au sucre"! My cauldron has been running with its booted kernel uninstalled for a while now :-) -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release totem-3.6.3-2.mga3
Olav Vitters writes: > On Fri, Nov 16, 2012 at 01:42:54PM +0100, JA Magallón wrote: >> Mmm, something is wrong: > > Ok, should've checked if that was allowed I guess.. > > I'll fix this weekend unless someone beats me. Anything that does not use a proper arch tagging macro is at best a hack :) -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release totem-3.6.3-2.mga3
JA Magallón writes: > On 11/16/2012 11:35 AM, ovitters wrote: >> Name: totemRelocations: (not relocatable) >> Version : 3.6.3 Vendor: Mageia.Org >> Release : 2.mga3Build Date: Fri Nov 16 11:33:14 >> 2012 [...] >> ovitters 3.6.3-2.mga3: >> + Revision: 318912 >> - requires gstreamer1(element-scaletempo) (mga#8088) > > Mmm, something is wrong: > > pandora:~# rpm -q --provides gstreamer1.0-plugins-bad | grep scale > libgstscaletempoplugin.so()(64bit) > gstreamer1(element-scaletempo)()(64bit) > > pandora:~# urpmi totem > A requested package cannot be installed: > totem-3.6.3-2.mga3.x86_64 (due to unsatisfied gstreamer1(element-scaletempo)) We need something like the %arch_tagged macro, but adding the (64bit) suffix instead of (lib64) See /etc/rpm/macros.d/20build.macros for its definition. Or maybe just change %arch_tagged to use (64bit) instead of (lib64), it would be a lot more consistent. This requires rebuilding all packages using this macro, is it just about mageia-release? -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release supertux-0.3.3-39.mga3
Jose Jorge writes: > Le 12/11/2012 15:48, Guillaume Rousse a écrit : >> Le 12/11/2012 13:16, Olivier Blin a écrit : >>> This looks wrong, the data package does not require the main package. >> Is it really necessary to have a cyclic dependency here ? I don't >> imagine anyone installing 'supertux-data' alone by mistake. Agreed, that was my point. > Well, without this cyclic dependency, uninstalling supertux does not > remove supertux-data. This is why I added it. That's why we have the auto-orphans feature of urpme. Yes, the feature might be unavailable in the GUI, but we should not add cyclic deps just because of that. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release supertux-0.3.3-39.mga3
zezinho writes: > Name: supertux Relocations: (not relocatable) [...] > + Revision: 317165 > - make data sub package require main package Hi, This looks wrong, the data package does not require the main package. -- Olivier Blin - blino
Re: [Mageia-dev] xfce / lxde live cd / dvd for Mageia 3
"Armando B." writes: > i would like to use draklive but i had some problems to use. does it ( > https://wiki.mageia.org/en/Draklive ) works ? Yes, it's still the tool used to build official Mageia live CDs. -- Olivier Blin - blino
Re: [Mageia-dev] [soft-commits] [6430] Do not mix tabs and spaces
r...@mageia.org writes: > Revision: 6430 > Author: neoclust > Date: 2012-11-09 21:44:52 +0100 (Fri, 09 Nov 2012) > Log Message: > --- > Do not mix tabs and spaces > > Modified Paths: > -- > drakx/trunk/mdk-stage1/adsl.c .. IIRC, the initial style was to use tabs, not spaces. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] cauldron core/release slim-1.3.3-3.mga3
Colin Guthrie writes: > 'Twas brillig, and blino at 05/11/12 22:38 did gyre and gimble: >> Name: slim Relocations: (not relocatable) >> Version : 1.3.3 Vendor: Mageia.Org >> Release : 3.mga3Build Date: Mon Nov 5 23:34:14 >> 2012 [...] >> blino 1.3.3-3.mga3: >> + Revision: 314544 >> - buildrequire freeglut-devel >> - add tmpfiles.d config file (from Fedora) >> - add systemd unit (from Fedora) >> - revert using consolekit's ck-launch-session for login_cmd (to drop >> consolekit dep, we will use systemd) > > For what it's worth, I think the PAM changes are wrong here. There were no PAM changes here :-) -- Olivier Blin - blino
Re: [Mageia-dev] Fwd: fallback mode
Olav Vitters writes: > On Mon, Nov 05, 2012 at 07:27:26PM +0100, Olivier Blin wrote: >> Even an Intel Core2 Duo (E8400) from 2008 + Intel Q35 chipset from 2007 >> can not handle the load with Gnome Shell on a 1920x1080 display, using >> accelerated GL drivers. > > Sure it is not using llvmpipe accidentally? What kind of driver does > that Q35 use? I have an intel chipset in my old laptop, no clue what, > but it is really smooth. Q35 has an Intel GMA3100 chipset, it is using i915. I don't think it is using llvmpipe, since /usr/lib64/gnome-session-check-accelerated-helper succeeds. Is there a better way to check that? Which Intel chipset is your old laptop using? -- Olivier Blin - blino
Re: [Mageia-dev] Fwd: fallback mode
Olav Vitters writes: > From: Matthias Clasen > > I'm writing to inform you that the release team discussed > https://live.gnome.org/ThreePointSeven/Features/DropOrFixFallbackMode > yesterday. We've come to the conclusion that we can't maintain > fallback mode in reasonable quality, and are better off dropping it. Ouch, many systems will become unusable in Gnome because of that. Even an Intel Core2 Duo (E8400) from 2008 + Intel Q35 chipset from 2007 can not handle the load with Gnome Shell on a 1920x1080 display, using accelerated GL drivers. The overview with just 5 windows is extremly slow to appear or disappear, and animations are about 2 frames per second... -- Olivier Blin - blino
Re: [Mageia-dev] Weird memory leak in X
Olav Vitters writes: > On Fri, Nov 02, 2012 at 10:36:35AM +0200, Sander Lepik wrote: >> I'm having that bug on mga2, if someone can test it on cauldron too it >> would be great. And all ideas on how to trace this weirdness are also >> very welcome! > > xrestop Running xrestop makes my X session crash (Gnome Shell on Intel HD 3000). Am I the only one? -- Olivier Blin - blino
Re: [Mageia-dev] cinelerra/audiokonverter/arista (war Re: rehashing the faac issue)
Christian Lohmaier writes: > Hi Wolfgang, *, > > On Thu, Nov 1, 2012 at 1:56 PM, Wolfgang Bornath > wrote: >> [...] >> After reading all arguments again I must confess that I changed my >> opinion: Being consequent and following our road we need a >> /tainted-free and a /tainted-nonfree branch. > > I still think this would be a very user-*un*friendly way to handle it. > > You cannot put packages that itself is "free", but depends on > "tainted&nonfree" packages into the "free" repo, since the core repos > need to be self-contained. [...] > Much better would then be to create an "ugly" repo (in the spirit of > gstreamer) that contains the "doesn't fit into the other repos" stuff. That's just a naming issue then, are you just suggesting to rename the "tainted-nonfree" repository proposal as "ugly"? This crossed my mind too, but the name is less understandable by users not necessarily familiar with the gstreamer naming. If we go for the "tainted + nonfree" way, its definition should be that it contains packages that: (1) are both tainted and not free software or (2) packages having a hard requirement on packages from (1) -- Olivier Blin - blino
Re: [Mageia-dev] Distrib-coffee big failure of the century
Olivier Thauvin writes: > Yesterday, the two power supplies of the distrib-coffee's disk array > failed at the same time. > > This mean we lost access to our 10TB of data including mirrors. > > Currently distrib-coffee is syncing again data from mirrors and > restoring backup (for our own data, but yes we have backup !). > > Sadly, the switch to another storage array was planed in two or three > weeks... > > I do my best to restore the service as soon as possible. > At time, 26GB of Mageia are restored. Thanks Olivier, that's much appreciated. Your mirror is of a huge use for most of us! -- Olivier Blin - blino
Re: [Mageia-dev] rehashing the faac issue
Wolfgang Bornath writes: > 2012/10/30 Olivier Blin : >> Wolfgang Bornath writes: >> >>> There has been a wide consensus for the solution to put it into >>> tainted as has been said in this thread as well. >> >> The consensus was maybe not so clear then. > > Maybe not so clear for those whose opinion differs from the consensus, > understandable. I did not write about a consensus as first one, it has > been written repeatedly by others. My opinion does not differ from the "consensus": - I don't have a strong opinion on this - I just did not see a clear consensus after carefully re-reading all the thread (from the beginning of the month) yesterday >>> Sorry if it is too offending for one or the other if I call this >>> procedure "ridiculous". >> >> Where do you see a procedure here? :-) >> Offer one if you think that's needed. > > Ah, in case you have missed all those mails in the devel list: > 1. The issue was brought to the attention of the people, including the > developers. > 2. The issue has been discussed at length including mantra-like repetitions. > 3. Several people suggested the same solution (we did not start a poll > but to me it looked like a large part of the participants of the > discussion). If I am wrong here then all others who saw it like me are > wrong as well > 4. All it needed now was action according to that consensus. > > This is what I call a procedure and how issues have been treated many > times. May be your definition is different. What I call a procedure is a documented way of doing things before we actually do them :-) > After the discussion reached this state everybody waited for action, > which may have ver well have been delayed because of other more > important work. That was the subject/contents of the opening mail and > first answers of this thread. Until somebody started to open the > discussion again. > > Another option would have been to bring the issue to the council after > the first discussion ended but I haven't yet read any mail about such > a move during the months since then. > Is that what you were waiting for? If things don't move on, yes, we should bring this to the council. >> It could be up to the council or board to chose the lesser evil between: >> - picking tainted for non-free + tainted packages like faac, and thus >> forbid mirroring tainted packages that are only free-software >> (but maybe that's the hypothetical 'selective mirror admin' from Guillaume) > > yes, you've been calling those existing mirror maintainers > "hypothetical" before. Very good argument. If I don't like something I > just pretend it isn't there. This looks like a misunderstanding, again. The hypothetical selective mirror admin was about an admin selectively picking sub-trees (free, non-free) of PLF. Do you know of any admin doing this? -- Olivier Blin - blino
Re: [Mageia-dev] rehashing the faac issue
Malo writes: > On 30/10/12 08:20, Guillaume Rousse wrote: >> Le 30/10/2012 01:34, Frank Griffin a écrit : >>> On 10/29/2012 06:20 PM, Olivier Blin wrote: >>>> I would prefer B: adding a nonfree-tainted repo (+ its >>>> updates/testing/backports/debug brothers). [...] >>> I don't know what's involved in this, but it is certainly the optimal >>> solution. >> Creating a specific workflow (a new buildsystem queue, a new entry in >> package manager configuration, etc...) for a category of packages with a >> unique candidate is not precisely something I'd call 'optimal'. Unless >> in term of complexity. >> >> Morevoer, unless someone volonteers to actually implement it in our >> buildsystem, that's a purely hypothetical solution. That's pretty easy to add in the BS, IIRC, it's about creating the dirs in the repo, modifying media.cfg, and youri + iurt config files. And maybe one-line to patch in Rpmdrake::Gui to recognize that nonfree-tainted is not free software (but it looks already broken anyway). > I'd have to go with Guillaume on that one. > The inclusion of faac came up a long time ago, and the simple logical > answer is to created a tainted-non-free repos. > > However, the three problems with that solution are: > - there is only a handful of people at Mageia who can do that, and > none of them actually did it. Maybe because Mageia sysadmins are not always dictators and act upon the input of other teams. Pascal and I will be able to do it. > - there is only faac, so why bother? (fuelling the first reason) > - the reason that philippe mentioned: is having 3 versions of each > multimedia package really worth it? ... Yep, it's only worth the clarity it offers in media descriptions... -- Olivier Blin - blino
Re: [Mageia-dev] rehashing the faac issue
Wolfgang Bornath writes: > There has been a wide consensus for the solution to put it into > tainted as has been said in this thread as well. The consensus was maybe not so clear then. > Sorry if it is too offending for one or the other if I call this > procedure "ridiculous". Where do you see a procedure here? :-) Offer one if you think that's needed. It could be up to the council or board to chose the lesser evil between: - picking tainted for non-free + tainted packages like faac, and thus forbid mirroring tainted packages that are only free-software (but maybe that's the hypothetical 'selective mirror admin' from Guillaume) - adding a new nonfree-tainted repository, just for faac for now, despite the relative media clutter that it would add, but for the sake of clear definitions of the media content -- Olivier Blin - blino
Re: [Mageia-dev] rehashing the faac issue
Christiaan Welvaart writes: > The problem is the following: > > 1. faac cannot go into main (see 2 & 3) > 2. faac cannot go into tainted (it is not free software) > 3. faac cannot go into nonfree (patented in some countries) > > so we only have 2 options: > A. ban faac and use the AAC encoder(s) we already have in mageia >or another one that can go into tainted > B. add a special repository for faac > > I prefer option A and I patched a gstreamer based video encoding app > to use vo-aacenc instead of faac a while ago. I would prefer B: adding a nonfree-tainted repo (+ its updates/testing/backports/debug brothers). See https://bugs.mageia.org/show_bug.cgi?id=2833 for a list of packages needing faac. Yes, that's overkill, it will clutter the urpmi media config UI, but that's the only clean way we have. I guess a simple way to unclutter the drakrpm-edit-media UI would be to add a drop-down menu to select between "Release + Updates" (default and most commonly used media), "Updates Testing", "Backports" (whenever it gets in), and "Debug" (for debug packages of all aforementioned groups). -- Olivier Blin - blino
Re: [Mageia-dev] Mageia versus Mageia.
jpbfree writes: > I have a desktop machine installed with mga2 > and a test machine installed with cauldron > both machines are up to date (according to distrib-coffee) and are > time-synced with fr.pool.ntp.org. > this morning the cauldron machine is one hour in advance (and wrong). Does one system have windows installed as well? If so, it might have been configured automatically at install to use the BIOS time as local time (instead of UTC time), and depend on Windows handling it. You might need to reboot into Windows one time, so that it syncs again your BIOS time. -- Olivier Blin - blino
Re: [Mageia-dev] Notes about live CD
Rémi Verschelde writes: >> Some installed packages may not be needed on your computer. >> You can remove them to save space. >> [ ] Remove unused hardware support >> [ ] Remove unused language support > > Sounds good, though now it is opt-in whereas it was opt-out up to now. > So we should wonder, what we do want as default behaviour. Yep, it's just a matter of default values, it should actually be the following: Some installed packages may not be needed on your computer. You can remove them to save space. [x] Remove unused hardware support [x] Remove unused language support And we do not even have to change the strings if we want to modify the default settings. -- Olivier Blin - blino
Re: [Mageia-dev] Notes about live CD
Wolfgang Bornath writes: > Some installed packages (hardware and language support) may not be > needed on your computer. > [ ] Check to remove unused hardware support > [ ] Check to remove unused language support > > Here the option tells exactly and with no room for misunderstanding in > one line what it is doing when checked or unchecked. The "Check to" words are a bit too much, it's a checkbox, there should be no need to say how to interact with it. And specifying the "hardware and language" in the introduction sentence will make harder to add more items later, since it would break the string. How about this? Some installed packages may not be needed on your computer. You can remove them to save space. [ ] Remove unused hardware support [ ] Remove unused language support -- Olivier Blin - blino
Re: [Mageia-dev] Notes about live CD
JA Magallón writes: > - the installer asks to remove the unused harware support, but the > wording for the choice is misleading: > > [ ] Unsued hardware support > > What does it really mean if I tick this, I want to keep the unused > hw support or to remove it ? The text reads this way: We will remove the following packages, unless you choose otherwise: [ ] Unused hardware support [ ] Unused localization -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release tsocks-1.8-0.beta5.10.mga3
Thierry Vignaud writes: > On 24 October 2012 18:58, blino wrote: >> Description : >> tsocks' role is to allow these non SOCKS aware applications (e.g >> telnet, ssh, ftp etc) to use SOCKS without any modification. It does >> this by intercepting the calls that applications make to establish >> network connections and negotating them through a SOCKS server as >> necessary. > > for work obviously :-) Yep, to push on github over ssh, so that I can make pull requets. -- Olivier Blin - blino
Re: [Mageia-dev] Minimal mageia install
Pascal Terjan writes: > On Tue, Oct 23, 2012 at 1:53 PM, Bruno Cornec wrote: >> Helo, >> >> I'm in the process of redeploying automatically my firewall machine, >> using Mageia. For that I'd like to have a very minimal install. >> >> However, I'm ending up with 580 packages, among them a lot of X11 >> content, whereas I want a text base install only. >> >> If I try to remove some of them, I end up having to remove basesystem >> which isn't an option. >> >> So why is libdrakx-kbd-mouse mandatory e.g. in basesystem ? libdrakx-kbd-mouse is required by drakxtools-backend, which is required for bootloader-utils, pulled by kernel (required to build initrd). But this one is not too bad. >> Another question is I could urpme lib64xrandr2 (and erase as a >> consequence 26 packages, none of them being in my list). >> Why did they came on my install first ?? Which packages did this uninstall? > Suggests? > There is an option to not use them That's more complicated than that. A big issue to me is the following dep chain: dracut -> plymouth -> desktop-common-data -> xdg-utils -> xprop -> libx11 You can test some of the issues by just doing this: mkdir chroot-minimal-cauldron urpmi --no-suggests --root ./chroot-minimal-cauldron basesystem urpmi -- Olivier Blin - blino
[Mageia-dev] Welcome Götz!
Hi, After uncountable years as a packager and maintainer in the Mandriva Linux distribution, providing a huge number of impeccable contributions, Götz Waschk is now joining us as a Mageia packager. Please welcome him aboard! -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release taskcoach-1.3.20-1.mga3
Thierry Vignaud writes: > On 22 October 2012 13:18, dams wrote: >> Description : >> Task Coach is a simple open source todo manager to keep track of personal >> tasks and todo lists. It grew out of a frustration that most task managers >> do not provide facilities for composite tasks. Often, tasks and other >> things todo consist of several activities. Task Coach is designed to deal >> with composite tasks. In addition, it offers effort tracking, categories, >> and notes. >> Task Coach is available for Windows, Mac OS X, Linux, BSD, and iPhone and >> iPod Touch. > > This is Mageia Linux, we don't care about other OSes, especially in > description No, this is Mageia :-) -- Olivier Blin - blino
Re: [Mageia-dev] Removing ConsoleKit
Thomas Backlund writes: > 22.10.2012 01:45, Olivier Blin skrev: >> Olav Vitters writes: >> >>> Also noticed GNOME >>> live dvd (Mageia 3) having xdm + gdm.. seems a bit of a waste. >> >> Weird, we should investigate that. >> >> Thomas, I couldn't find the build data of latest live releases, probably >> because /home/draklive/var-data is on a tmpfs. >> After a build is completed, we should backup the content of the matching >> /home/draklive/var-data directories on disk. > > I do store those that I give to QA, so alpha2 is here: > > /home/draklive/ISOs/mageia3-alpha2/round6/ Thanks! So xdm seems to be pulled from rpmsrate when CAT_X is selected. Maybe task-x11 should instead require the dm virtual package? But then we may also need to add "xdm" to /etc/urpmi/prefer.vendor.list, so that it gets preferred over other dms for minimal installs. -- Olivier Blin - blino
Re: [Mageia-dev] Removing ConsoleKit
Olav Vitters writes: > Seriously, IIRC udisks v1. I try to avoid lower level stuff, so looked > through the alpha live dvd to figure out more… Well, we just migrated away from hal, and some of the migration was about merging udisks v1 patches. Maybe a bit early to drop it? > Stuff that should > eventually be removed is gnome-keyring (in favour of the freedesktop > libsecret). Yep > Aside from that gconf, gstreamer 0.10, bonobo+orbit. Can't we have thirdparty depending on gstreamer 0.10? Like Fluendo apps? > Wonder about: usermode (no clue what it does :P). We use consolehelper heavily in drakxtools. > Also noticed GNOME > live dvd (Mageia 3) having xdm + gdm.. seems a bit of a waste. Weird, we should investigate that. Thomas, I couldn't find the build data of latest live releases, probably because /home/draklive/var-data is on a tmpfs. After a build is completed, we should backup the content of the matching /home/draklive/var-data directories on disk. -- Olivier Blin - blino
Re: [Mageia-dev] Removing ConsoleKit
Olav Vitters writes: > On Fri, Oct 19, 2012 at 01:24:11AM +0200, JA Magallón wrote: >> xinit > > Dropped it here as well. Might break stuff, Colin gave a +1 on this. So, with policykit, consolekit and hal having been obsoleted in the past month, do we have any other deprecated freedesktop/gnome *kit/*d stuff to remove? :) -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release urpmi-7.10-1.mga3
tv writes: > Name: urpmiRelocations: (not relocatable) > Version : 7.10 Vendor: Mageia.Org > Release : 1.mga3Build Date: Wed Oct 17 17:33:26 > 2012 > > tv 7.10-1.mga3: > + Revision: 307687 > - do not offer to remove DKMS modules for current kernel (mga#5092) Hi, Now urpme orphans tries to remove the current kernel, and prebuilt dkms packages for the latest kernel. # LC_ALL=C urpme --auto-orphans To satisfy dependencies, the following 2 packages will be removed (40MB): (orphan packages) kernel-desktop-3.5.5-0.rc1.1.mga3-1-1.mga3.x86_64 virtualbox-kernel-3.6.2-desktop-1.mga3-4.2.0-4.mga3.x86_64 Remove 2 packages? (y/N) y removing kernel-desktop-3.5.5-0.rc1.1.mga3-1-1.mga3.x86_64 virtualbox-kernel-3.6.2-desktop-1.mga3-4.2.0-4.mga3.x86_64 Removal failed: virtualbox-kernel-3.6.2-desktop-1.mga3 = 4.2.0-4.mga3 is needed by (installed) virtualbox-kernel-desktop-latest-4.2.0-4.mga3.x86_64 kernel-desktop-3.5.5-0.rc1.1.mga3 is needed by (installed) virtualbox-kernel-3.5.5-desktop-0.rc1.1.mga3-4.2.0-3.mga3.x86_64 # uname -r 3.5.5-desktop-0.rc1.1.mga3 # ls -1 /boot/vmlinuz-3* /boot/vmlinuz-3.5.4-desktop-1.mga3 /boot/vmlinuz-3.5.5-desktop-0.rc1.1.mga3 /boot/vmlinuz-3.6.2-desktop-1.mga3 -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release squashfs-tools-4.2-3.mga3
Thierry Vignaud writes: > On 18 October 2012 22:31, Thierry Vignaud wrote: >>> No it's not useless. >>> squashfs3-tools is still useful to generate squashfs3 images for other >>> systems with older kernels, and this is still used for some embedded >>> devices, I use this at work. >> >> Humm >> Kernel didn't support squashfs3 for years when we were still >> working at mdv... >> No Mageia release ever had support for reading squashfs3 in >> its kernel. >> But you can still generate images for such older systems. >> I won't oppose a revert. > > Though I would question developing for a target using squashfs3 > whereas we switched to v4 in 2009 when it was officially included in > kernel... > That means targeting 2.6.28 at most... Then you feel my daily pain. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release squashfs-tools-4.2-3.mga3
tv writes: > Name: squashfs-tools Relocations: (not relocatable) > Version : 4.2 Vendor: Mageia.Org > Release : 3.mga3Build Date: Thu Oct 18 16:53:26 > 2012 > > tv 4.2-3.mga3: > + Revision: 307990 > - obsoletes squashfs3-tools which is useless for years No it's not useless. squashfs3-tools is still useful to generate squashfs3 images for other systems with older kernels, and this is still used for some embedded devices, I use this at work. Please revert -- Olivier Blin - blino
Re: [Mageia-dev] Deprecating pm-utils
Colin Guthrie writes: > 'Twas brillig, and Olav Vitters at 17/10/12 23:49 did gyre and gimble: >> On Thu, Oct 18, 2012 at 12:36:47AM +0200, Olivier Blin wrote: >>> It does not seem to provide a replacement for pm-suspend-hybrid. >> >> That will likely be in a newer systemd once they figured out what to >> call it. > > Yeah being discussed now. As this is now in-kernel as of 3.6, systemd > will support this within a very short time frame. Is it equivalent? Can the kernel hibernate support write a compressed and encrypted image to swap? Does it allow showing a splash for suspend progress? >>> And what about all the hooks that used to be run by pm-utils? >>> How will they be run now? > > Not 100% sure but as mentioned in another thread I think many of the > quirks are likely outdated. Certainly graphical quirks that used to be > present on my hardware have not been needed for many years since KMS > came along. So this is likely an opportunity to tidy it up and get rid > of the kruft. > > But overall some of the quirks are likely still needed, so I've started > a discussion upstream with a view to gathering feedback from how other > distros are planning to handle this. That's not only about video quirks. This one is required to forbid messing with the suspend image in swap by rebooting in another kernel: /usr/lib64/pm-utils/sleep.d/01bootloader There may be some other useful ones, notifying apps about resume, like: /usr/lib64/pm-utils/sleep.d/95packagekit -- Olivier Blin - blino
Re: [Mageia-dev] Broken wayland in cauldron
Funda Wang writes: > Hello, > > It seems that latest wayland is breakking libEGL with: > /lib64/libEGL.so.1: undefined reference to `wl_display_bind' > /lib64/libEGL.so.1: undefined reference to `wl_display_iterate' > /lib64/libEGL.so.1: undefined reference to `wl_display_sync' > /lib64/libEGL.so.1: undefined reference to `wl_display_get_global' > > Is there anybody willing to fix it? Backporting and testing the 3 patches from krh was in my todo list for tonight, but you beat me at it. I've just uploaded mesa in tainted/release, try to remember this one next time :) Thanks -- Olivier Blin - blino
Re: [Mageia-dev] Deprecating pm-utils
Olav Vitters writes: > On Wed, Oct 17, 2012 at 11:10:35AM +, David Walser wrote: >> So if you get rid of pm-utils, what's the new alternative to the pm-suspend >> command if you want to suspend from the command line? > > No clue about pm-utils, but guess you're after: > # systemctl suspend > > see systemctl --help for various alternatives It does not seem to provide a replacement for pm-suspend-hybrid. And what about all the hooks that used to be run by pm-utils? How will they be run now? -- Olivier Blin - blino
Re: [Mageia-dev] Mageia 2 - Security issiue
"Johnny A. Solbu" writes: > I have a guest computer, that also operates as a file server. > Up until recent weeks, it ran Mandriva 2010.2, and various mdv versions > before that. > It was configured to disallow any user except root from reboting or > shutting it down. If any user managed to figure out how to shut it > down, it would prompt for the root password. > > In Mageia 2 this does not work, and it creates a security issiue for me, as > it is critical that this computer is always running. > > I have done the same in Mageia that I did in Mandriva: > systemsettings --> Login-screen --> Shutdown --> Allow shutdown > Select "Only Root" in Loal, and "Nobody" for remote, and press Apply. When i > launch systemsettings again to check, the changes are still there. > I restart X, to have the settigns take effect. It does not change anything. > Users can still reboot or shutdown the system. > When the computer is rebooted, the settings are reset to default, which is > "Everybody" > > Has anyone else seen this? Hi, You can probably configure this with msecgui, there's an ALLOW_REBOOT setting there. -- Olivier Blin - blino
Re: [Mageia-dev] iDevices support (was Re: [changelog] [RPM] cauldron core/release libimobiledevice-1.1.4-2.mga3)
Thierry Vignaud writes: > On 10 October 2012 00:24, Olivier Blin wrote: >>> blino 1.1.4-2.mga3: >>> + Revision: 303682 >>> - fix crash in upowerd when run from systemd (from upstream git, Bastien >>> Nocera) >> >> I've fixed a few things to get iDevices (iPod, iPhone, iPad) detected >> again in Cauldron. >> >> But in a default install, it still won't be recognized in nautilus, >> because we don't install gvfs-iphone by default. >> Is this something that we can suggest in libimobiledevice or nautilus? >> >> We already pull a bunch of libimobiledevice things anyway (thanks >> upower, er?!...), and having iDevices working out of the box is >> probably something that is expected by end-users. >> >> Any opinions about that? > > Suggests means not having it on install DVD... Can't we fix bcd to handle suggests? Suggests usually pull in important features. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drakx-net-1.16-1.mga3
tv writes: > Name: drakx-netRelocations: (not relocatable) > Version : 1.16 Vendor: Mageia.Org > Release : 1.mga3Build Date: Fri Oct 12 09:13:00 > 2012 [...] > - fix device path for "cdc_acm" (mga#3841) Fix? No, that's not a fix. my $tty_interface = 0; ... $self->get_driver eq "cdc_acm" ? - "/dev/ttyACM" . $tty_interface : + "/dev/ttyACM0" . $tty_interface : You hardcoded the "0", while it was supposed to be the content of the tty_interface variable. Instead, the tty interface detection code should be fixed. But I don't understand how it could be broken, we already default to "0" for tty_interface. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] 2 core/updates_testing drakx-installer-images-1.75-5.mga2
Thierry Vignaud writes: > Also I've backported fixing NTFS resizing (got gratuitously broken when > ntfs-3g > obsoleted ntfsprogs w/o including our patch) > > I wonder why nobody reported this for Mageia2 I experienced the bug a while back (or maybe saw somebody on IRC having the bug, trem?), but never found time to fix it. Thanks for having fixed this longstanding one! -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release tcp_wrappers-7.6-42.mga3
Thierry Vignaud writes: > On 12 October 2012 11:51, fwang wrote: >> blino 7.6-42.mga1: >> + Revision: 2907 >> - remove old ldconfig scriptlets >> - imported package tcp_wrappers > > Why? This is more or less deprecated with systemd... See the tagged release in the changelog, it reads mga1: blino 7.6-42.mga1 I did not submit it this time (it was Funda), I don't know why it appears this way, maybe because of a missing release bump. Though, it is still required by tons of packages, and provides hosts* manpages. -- Olivier Blin - blino
Re: [Mageia-dev] The shiny new Control Center
Per Øyvind Karlsen writes: > The drakx tools's perl code should really be considered as legacy, I can't > think of anyone who has deeper insight on it who'd ever find anything but > som sentimental value from it.. How can you expect cooperation by saying blunt things like this? Don't you think you make the "politics" issues bigger just by yourself? > PS: considering your drakx branch is a fork of the original upstream drakx > project and that these two have heavily diverged since, established > etiquete would dictate that the forket project should change.. Well, many authors of DrakX have switched to Mageia, making it a natural host. -- Olivier Blin - blino
[Mageia-dev] iDevices support (was Re: [changelog] [RPM] cauldron core/release libimobiledevice-1.1.4-2.mga3)
blino writes: > Name: libimobiledevice Relocations: (not relocatable) > Version : 1.1.4 Vendor: Mageia.Org > Release : 2.mga3Build Date: Tue Oct 9 00:24:27 > 2012 [...] > blino 1.1.4-2.mga3: > + Revision: 303682 > - fix crash in upowerd when run from systemd (from upstream git, Bastien > Nocera) Hi, I've fixed a few things to get iDevices (iPod, iPhone, iPad) detected again in Cauldron. But in a default install, it still won't be recognized in nautilus, because we don't install gvfs-iphone by default. Is this something that we can suggest in libimobiledevice or nautilus? We already pull a bunch of libimobiledevice things anyway (thanks upower, er?!...), and having iDevices working out of the box is probably something that is expected by end-users. Any opinions about that? Thanks -- Olivier Blin - blino
Re: [Mageia-dev] GNOME llvmpipe rendering in gnome-session-3.6.0-2.mga3
Olav Vitters writes: > On Mon, Oct 08, 2012 at 02:32:24PM +0200, ovitters wrote: >> Name: gnome-sessionRelocations: (not relocatable) >> Version : 3.6.0 Vendor: Mageia.Org >> Release : 2.mga3Build Date: Mon Oct 8 14:26:33 >> 2012 > >> ovitters 3.6.0-2.mga3: >> + Revision: 303504 >> - add patch to unblacklist llvmpipe > > I've unblacklisted llvmpipe like Fedora has done for a few releases. In > some cases I noticed my normal driver not working (reason unknown), so > in case GNOME is sometimes slow, check if it isn't rendering using > llvmpipe. > > This should make it easier to run GNOME in a VM or any case where > hardware acceleration is missing. And this will make Gnome3 awfully slow on aging systems running high resolution displays. Even on a Core2 Duo (whose graphics chipset does not support a recent enough OpenGL version), a 1920x1080 display is extremly slow with llvmpipe. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mesa-9.0.0-1.mga3
Thierry Vignaud writes: > On 9 October 2012 12:54, Olivier Blin wrote: >>> tv 9.0.0-1.mga3: >>> + Revision: 303797 >>> - fix blino packaging so that stable is newer than git snapshot >> >> It was not my packaging, you changed yourself the version from 9.0.0 to >> 9.0 in your initial 9.0 final commit... > > B/c it's really mesa-9.0 not 9.0.0... Well, configure.ac reads 9.0.0, and has been like this during the all the dev cycle IIRC. And minor releases will be named 9.0.x -- Olivier Blin - blino
Re: [Mageia-dev] [soft-commits] [6180] make sure shared-mimoe-info is installed so . desktop files work in atleast GNOME
zago writes: > On Mon, Oct 08, 2012 at 01:09:07AM +0200, Olivier Blin wrote: >> Don't you have gnome-vfs2 on a default Gnome install? > > That has been deprecated for many years. I hope by now nothing requires > it. Right, it seems nothing pulls gnome-gvfs2 from a default install, only: lib64gnome-vfs2_0:gnome-vfs2[>= 2.24.4-3.mga2] gnome-python-gnomevfs:gnome-vfs2[>= 2.0.2] lib64gnome-vfsmm2.6-devel:gnome-vfs2-devel[>= 2.8.1] sugar-log-activity:gnome-vfs2 gstreamer0.10-gnomevfs:gnome-vfs2[> 1.9.4.00] Shouldn't we drop gnome-gvfs2 + these then? And add a shared-mime-info require in a core Gnome package? (as Thierry said) It seems lib64gio2.0_0 might be the proper place Try strings /usr/lib64/libgio-2.0.so | grep mime -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mesa-9.0.0-1.mga3
tv writes: > Name: mesa Relocations: (not relocatable) > Version : 9.0.0 Vendor: Mageia.Org > Release : 1.mga3Build Date: Tue Oct 9 08:28:25 > 2012 > Install Date: (not installed) Build Host: jonund.mageia.org > Group : System/Libraries Source RPM: (none) > Size: 5889346 License: MIT > Signature : (none) > Packager: tv > URL : http://www.mesa3d.org > Summary : OpenGL 3.0 compatible 3D graphics library > Description : > Mesa is an OpenGL 3.0 compatible 3D graphics library. > > tv 9.0.0-1.mga3: > + Revision: 303797 > - fix blino packaging so that stable is newer than git snapshot It was not my packaging, you changed yourself the version from 9.0.0 to 9.0 in your initial 9.0 final commit... -- Olivier Blin - blino
Re: [Mageia-dev] [soft-commits] [6180] make sure shared-mimoe-info is installed so . desktop files work in atleast GNOME
Thomas Backlund writes: > 08.10.2012 01:26, Olivier Blin skrev: >> r...@mageia.org writes: >> >>> Revision: 6180 >>> Author: tmb >>> Date: 2012-10-07 15:17:33 +0200 (Sun, 07 Oct 2012) >>> Log Message: >>> --- >>> make sure shared-mimoe-info is installed so .desktop files work in atleast >>> GNOME >> >> Hi, >> >> This seems unneeded, shared-mime-info is already required by gnome-vfs2, >> so it should be already be on live CDS. >> Maybe you had another install issue? >> > > Heh, > You mean besides nothing requiring it :) > > It's not on any of the current Gnome live medias :/ > (and no mention in any ddebug.log) Don't you have gnome-vfs2 on a default Gnome install? -- Olivier Blin - blino
Re: [Mageia-dev] [soft-commits] [6180] make sure shared-mimoe-info is installed so . desktop files work in atleast GNOME
r...@mageia.org writes: > Revision: 6180 > Author: tmb > Date: 2012-10-07 15:17:33 +0200 (Sun, 07 Oct 2012) > Log Message: > --- > make sure shared-mimoe-info is installed so .desktop files work in atleast > GNOME Hi, This seems unneeded, shared-mime-info is already required by gnome-vfs2, so it should be already be on live CDS. Maybe you had another install issue? -- Olivier Blin - blino
Re: [Mageia-dev] systemd and non-systemd services question
Colin Guthrie writes: >> Issuing "systemctl start oracle-xe.service" issues no output. Running it >> under strace shows an execve for /bin/systemctl, and later on an execve >> for /usr/bin/systemd-tty-ask-password-agent, but very little else, and >> nothing that even hints at actually trying to execute any oracle code. > > Keep in mind that when running under strace, systemctl will be > contacting PID 1 and asking it to start the service for you so you won't > see any direct attempts to to start your service. To debug an initscript, you can also use this option: service --skip-redirect oracle-xe start Or run it this way: SYSTEMCTL_SKIP_REDIRECT=1 /etc/init.d/oracle-xe start -- Olivier Blin - blino
Re: [Mageia-dev] ncurses ABI breakage (Re: [changelog] [RPM] cauldron core/release iftop-0.17-9.mga3)
Thierry Vignaud writes: > On 25 September 2012 21:59, Olivier Blin wrote: >>> blino 0.17-9.mga3: >>> + Revision: 297720 >>> - rebuild for new ncurses ABI (broken by #7235) >> >> Hi, >> >> After a configuration change in ncurses (from bug #7235), it seems that >> the ncurses ABI has been broken. >> >> Thierry, any plan/roadmap for a mass rebuild of ncurses users? > > No, will be done when someone will do the mass rebuild for the new > build chain It would be better to rebuild all ncurses programs before alpha2, because this change broke most of them. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.83-1.mga3.nonfree
Thierry Vignaud writes: > On 17 September 2012 21:37, Olivier Blin wrote: >>> tv 1.83-1.mga3: >>> + Revision: 295551 >>> - fix modules.order so that cciss got detected (mga#5833) >>> - use new hotplug (mga#6323) >> >> You are duplicating (with full knowledge it seems) the /sbin/hotplug >> script written by make_boot_img. As you noticed, it relied on /bin/sh. >> The shell used to be provided not only for KA, but also to provide a >> convenience shell in stage1. >> Couldn't we add a shell back? > > For years, we only add this shell if DEBUGSTAGE1 was set. > This is still the case > Then for a couple years, stage1 got bloated with KA stuff including busybox > (and thus a shell) by Antoine. But when KA has been merged in stage1, we meant to keep the shell. > We're just back at prior state. > If you need to debug, you can still rebuild stage1 package with the debug > option. It's not only me, it is also to ease reporting bugs about stage1. Otherwise, there is no way to get a look at the debug log from stage1. -- Olivier Blin - blino
[Mageia-dev] ncurses ABI breakage (Re: [changelog] [RPM] cauldron core/release iftop-0.17-9.mga3)
blino writes: > Name: iftopRelocations: (not relocatable) > Version : 0.17 Vendor: Mageia.Org > Release : 9.mga3Build Date: Tue Sep 25 17:51:25 > 2012 > > blino 0.17-9.mga3: > + Revision: 297720 > - rebuild for new ncurses ABI (broken by #7235) Hi, After a configuration change in ncurses (from bug #7235), it seems that the ncurses ABI has been broken. Thierry, any plan/roadmap for a mass rebuild of ncurses users? -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-3-27.mga3
Frederik Himpe writes: > On Tue, 25 Sep 2012 12:03:18 +0200, Olivier Blin wrote: > >> Fedora removed it one year ago already: >> http://fedoraproject.org/wiki/Features/HalRemoval >> >> Do you have any example of such thirdparty software using it? > > Flash DRM: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682370 > > Although one can discuss whether you need to keep hal just for such > questionable goals... Well, Fedora is living with this issue too. And it seems Adobe has no plan to change that :-/ http://forums.adobe.com/message/4574892 -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-3-27.mga3
Sander Lepik writes: > 25.09.2012 13:03, Olivier Blin kirjutas: >> Do you have any example of such thirdparty software using it? > No. But draksnapshot was a good example for quite sometime. If there > are no packages that require it and it is removed from mga3 repos then > i see no reason to add it as obsolete and stop those using it who need > it for some reason. To me it seems like overusing task-obsolete. > But don't get me wrong, i want it to be dead :) The reason is automatically removing hal from upgraded systems, and not having an obsolete daemon running for nothing. -- Olivier Blin - blino
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-3-27.mga3
Sander Lepik writes: > 25.09.2012 01:17, blino kirjutas: >> Name: task-obsoleteRelocations: (not relocatable) >> Version : 3 Vendor: Mageia.Org >> Release : 27.mga3 Build Date: Tue Sep 25 00:12:29 >> 2012 >> >> >> blino 3-27.mga3: >> + Revision: 297306 >> - obsolete policykit, replaced by polkit >> - obsolete hal and hal-info, replaced by udisks and later by udisks2 > I would question obsoleting hal here. Is there a serious reason to do > that? What if there are 3rd party packages that still need it? Or > isn't it working at all on mga3? If it still works i wouldn't obsolete > it that way. hal removal has been discussed here a few weeks go and got no objections: https://www.mageia.org/pipermail/mageia-dev/2012-July/017430.html hal has been first replaced by DeviceKit, which has then been replaced by udev + udisks, the later being again replaced by udisks2. We are many architecture cycles away from hal already. Fedora removed it one year ago already: http://fedoraproject.org/wiki/Features/HalRemoval Do you have any example of such thirdparty software using it? See also http://en.wikipedia.org/wiki/HAL_%28software%29#Deprecated -- Olivier Blin - blino
[Mageia-dev] halectomy and policykitectomy (Re: [changelog] [RPM] cauldron core/release task-obsolete-3-27.mga3)
blino writes: > Summary : Meta package obsoleting old packages > Description : > This package is used to obsolete packages that are no longer supported. > > blino 3-27.mga3: > + Revision: 297306 > - obsolete hal and hal-info, replaced by udisks and later by udisks2 hal was pulled by: - sugar: dropped the dep, since sugar is using gio/gvfs - usb-imagewriter: added a patch from Ubuntu to use udisks instead (no udisks2 yet...) - draksnapshot: fixed a crash when hal was not running (#3032) and opened a reminder bug about migration to udisks2 (#7565) > - obsolete policykit, replaced by polkit policykit has been replaced by polkit quite some time ago. We still had a few users: - python-slip (pulled by sectool, which is used by msec): only a requires had to be fixed - hal: taken care of above So, both hal and policykit are now obsoleted by task-obsolete. I guess policykit could be made obsolete by the polkit package instead, but hal has no real full replacement, so the obsolete tag can belong to task-obsolete. Should we explicitely obsolete the library packages as well or should we let them be handled by the orphans feature of urpme? Next step will be udisksectomy! (udisks1) -- Olivier Blin - blino
Re: [Mageia-dev] Problems with gnome-shell and polkit
JA Magallón writes: > On 09/24/2012 07:51 PM, Olav Vitters wrote: >> On Mon, Sep 24, 2012 at 12:42:58AM +0200, JA Magallón wrote: >>> Perhaps polkit-gnome is out of sync ? >> >>>From the .spec: >> >> # install the autostart file manually, since upstream doesn't ship it any >> more >> # and decided that it's the job of each DE to start >> polkit-gnome-authentication-agent-1 >> # this doesn't seem to apply to gnome-session in GNOME 2.32 >> # ACK'ed by pterjan >> # >> # this file was nicked from the gnome-polkit-0.99 binary rpm, to get all the >> translations >> # (ahmad) 02-05-2011 >> >> >> I removed the autostart file in a newly submitted polkit-gnome. >> > > Thanks !! > BTW, do we need both polkit and policykit installed ? > I can remove libpolkit2-0.9-8.mga1,policykit-0.9-8.mga1 without any problem. > Should new version obsolete old one ? I was in the process of obsoleting it, a few things had to be done, like fixing a sectool dep, and ... killing hal :) I'll do a recap mail later. -- Olivier Blin - blino
