[Mageia-dev] urpmi searchmedia and 32-bit packages installation
I am trying to install 32-bit packages using urpmi: # urpmi --searchmedia distrib31 mesa # distrib31 media is 32-bit Core packages, is there a way to force installation? (64-bit version is installed which I think prevent 32-bit installation)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release ivtv-utils-1.4.0-1.mga3
On 9 February 2013 00:47, tmb wrote: > tmb 1.4.0-1.mga3: > + Revision: 397259 > - clean spec > - fix string format (P0) > - import from fedora Care to add the proper line to rpmsrate, so that it get automatically installed? eg: DRIVER"ivtv" ivtv-utils (providing ivtv is the driver seen by ldetect for that)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xkeyboard-config-2.8-1.mga3
On 1 February 2013 17:44, guillomovitch wrote:
> Name: xkeyboard-config Relocations: (not relocatable)
(...)
> Description :
> Xkeyboard-config provides consistent, well-structured, frequently released of
> X
> keyboard configuration data (XKB) for various X Window System implementations.
Humm, btw we should stop "renaming" it, aka:
%define old_name x11-data-xkbdata
%files -f %{name}.lang -n %{old_name}
And just add the proper obsoletes/provides tags:
%rename: x11-data-xkbdata
The description being bogus b/c of that name change.
> luigiwalser 1:2.8-1.mga3:
> + Revision: 393912
> - 2.8
> - rediff zapping patch
> - remove no longer needed pre script
> - add man page to files list
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libx11-1.5.0-4.mga3
On 9 February 2013 01:04, luigiwalser wrote: > luigiwalser 1.5.0-4.mga3: > + Revision: 397145 > - remove obsolete pre script BTW, thx for killing those years old obsolete scriptlets
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libx11-1.5.0-4.mga3
--- On Sat, 2/9/13, Thierry Vignaud wrote: > From: Thierry Vignaud > Subject: Re: [changelog] [RPM] cauldron core/release libx11-1.5.0-4.mga3 > To: "Mageia development mailing-list" , "David Walser" > > Date: Saturday, February 9, 2013, 4:55 AM > On 9 February 2013 01:04, luigiwalser > > wrote: > > luigiwalser 1.5.0-4.mga3: > > + Revision: 397145 > > - remove obsolete pre script > > BTW, thx for killing those years old obsolete scriptlets You're quite welcome. :o) Thanks to you for helping find them.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xkeyboard-config-2.8-1.mga3
--- On Sat, 2/9/13, Thierry Vignaud wrote:
> From: Thierry Vignaud
> Subject: Re: [changelog] [RPM] cauldron core/release
> xkeyboard-config-2.8-1.mga3
> To: "Mageia development mailing-list" , "David Walser"
>
> Date: Saturday, February 9, 2013, 4:54 AM
> On 1 February 2013 17:44,
> guillomovitch
> wrote:
> > Name :
> xkeyboard-config
> Relocations: (not relocatable)
> (...)
> > Description :
> > Xkeyboard-config provides consistent, well-structured,
> frequently released of X
> > keyboard configuration data (XKB) for various X Window
> System implementations.
>
> Humm, btw we should stop "renaming" it, aka:
> %define old_name x11-data-xkbdata
> %files -f %{name}.lang -n %{old_name}
> And just add the proper obsoletes/provides tags:
> %rename: x11-data-xkbdata
>
> The description being bogus b/c of that name change.
That might make sense to have it match the upstream name, although since Fedora
uses the same name as we do, it makes it easier to keep track of. It appeared
on the youri-check page, and that was how I knew it needed to be updated in the
first place. I'd say keep the Fedora name for now.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xkeyboard-config-2.8-1.mga3
Le 09/02/2013 11:00, David Walser a écrit : The description being bogus b/c of that name change. That might make sense to have it match the upstream name, although since Fedora uses the same name as we do, it makes it easier to keep track of. It appeared on the youri-check page, and that was how I knew it needed to be updated in the first place. I'd say keep the Fedora name for now. You don't need to rename package for this latest point, you just need to define aliases in your-icheck configuration. -- BOFH excuse #364: Sand fleas eating the Internet cables
Re: [Mageia-dev] freeze push: perl-URPM & urpmi
On 8 February 2013 23:26, Pascal Terjan wrote: > please let in perl-URPM & urpmi > perl-URPM fixes a bug regarding installing delta rpm > urpmi fixes counting erasures in progress bar. I think urpmi should probably not count erasures at all in the $cur/$total number, since IMHO the count should be for the packages installed instead of applied transactions, and package removal is usually much faster than installation. >>> >>> >>> Try that on texlive-texmf :-) >>> >>> This does what you want, a separate counter for erasures >> >> Nice :) >> >> Probably should see if others agree with me or not before applying I >> guess... >> >> Everyone, WDYT? > > I thought of requesting such change when I ran the new version but > then decided it was not important :) Should I wait for one more vote before dcommiting & releasing?
Re: [Mageia-dev] freeze push: perl-URPM & urpmi
09.02.2013 12:23, Thierry Vignaud skrev: On 8 February 2013 23:26, Pascal Terjan wrote: please let in perl-URPM & urpmi perl-URPM fixes a bug regarding installing delta rpm urpmi fixes counting erasures in progress bar. I think urpmi should probably not count erasures at all in the $cur/$total number, since IMHO the count should be for the packages installed instead of applied transactions, and package removal is usually much faster than installation. Try that on texlive-texmf :-) This does what you want, a separate counter for erasures Nice :) Probably should see if others agree with me or not before applying I guess... Everyone, WDYT? I thought of requesting such change when I ran the new version but then decided it was not important :) Should I wait for one more vote before dcommiting & releasing? Go ahead and add it, I liked it too :) -- Thomas
[Mageia-dev] Huh? Urpmi package numbers . . .
Since latest Cauldron updates - the urpmi process seems to be lying about the number of packages - In this example, it say "293" packages - but when it starts, it says 1/582 -?? Huh? urpmi --auto-update -v SNIP: 71MB of additional disk space will be used. 174MB of packages will be retrieved. Proceed with the installation of the 293 packages? (Y/n) SNIP: 2/582: lib64okteta1core1 ## 3/582: lib64kasten2gui2 ## 4/582: lib64okteta1gui1 ## 5/582: lib64kasten2okteta1core1 ## 6/582: lib64kasten2okteta1 Is this by design? Cheers, Robert
Re: [Mageia-dev] Huh? Urpmi package numbers . . .
Le 09/02/2013 12:58, Robert Fox a écrit : > Since latest Cauldron updates - the urpmi process seems to be lying > about the number of packages - > In this example, it say "293" packages - but when it starts, it says > 1/582 -?? > > Huh? > > urpmi --auto-update -v > > SNIP: > 71MB of additional disk space will be used. > 174MB of packages will be retrieved. > Proceed with the installation of the 293 packages? (Y/n) > > SNIP: > 2/582: lib64okteta1core1 > ## > 3/582: lib64kasten2gui2 > ## > 4/582: lib64okteta1gui1 > ## > 5/582: lib64kasten2okteta1core1 > > ## > 6/582: lib64kasten2okteta1 > > Is this by design? > > Cheers, > Robert > See the other thread about urpmi
Re: [Mageia-dev] freeze push: perl-URPM & urpmi
On 9 February 2013 12:06, Thomas Backlund wrote: > Try that on texlive-texmf :-) > > This does what you want, a separate counter for erasures Nice :) Probably should see if others agree with me or not before applying I guess... Everyone, WDYT? >>> >>> >>> I thought of requesting such change when I ran the new version but >>> then decided it was not important :) >> >> >> Should I wait for one more vote before dcommiting & releasing? >> > > Go ahead and add it, I liked it too :) then push it please
Re: [Mageia-dev] freeze push: perl-URPM & urpmi
09.02.2013 14:22, Thierry Vignaud skrev: On 9 February 2013 12:06, Thomas Backlund wrote: Try that on texlive-texmf :-) This does what you want, a separate counter for erasures Nice :) Probably should see if others agree with me or not before applying I guess... Everyone, WDYT? I thought of requesting such change when I ran the new version but then decided it was not important :) Should I wait for one more vote before dcommiting & releasing? Go ahead and add it, I liked it too :) then push it please Submitted. -- Thomas
Re: [Mageia-dev] urpmi searchmedia and 32-bit packages installation
On 9 February 2013 09:50, Adrien Guichard wrote: > I am trying to install 32-bit packages using urpmi: > # urpmi --searchmedia distrib31 mesa > # > > distrib31 media is 32-bit Core packages, is there a way to force > installation? (64-bit version is installed which I think prevent > 32-bit installation) how about "urpmi libdri-drivers" ...
Re: [Mageia-dev] [RFC] rsyslog vs journalctl
Are you sure that there still is a problem? There were some bugs that have been fixed months ago. Aside from that the memory usage could be off as journal uses mmap. But systemd always uses the journal (not runtime configurable IIRC), so best to make it efficient. It should also somehow be low maintenance. Meaning: maybe it will use less memory when there is less available (guessing)? I don't know about mmap, but that's what a top gives on the current cooker: 326 root 1 0 1064m 37m 36m S0 1.9 0:14.73 systemd-journal even though it is only virtual, that's sound crazy to go up 1GB. rsyslog never goes above 1M. Cheers, Chris.
Re: [Mageia-dev] [RFC] rsyslog vs journalctl
On Sat, Feb 09, 2013 at 04:18:32PM +0100, eatdirt wrote: > > >Are you sure that there still is a problem? There were some bugs that > >have been fixed months ago. Aside from that the memory usage could be > >off as journal uses mmap. > > > >But systemd always uses the journal (not runtime configurable IIRC), so > >best to make it efficient. It should also somehow be low maintenance. > >Meaning: maybe it will use less memory when there is less available > >(guessing)? > > > > > I don't know about mmap, but that's what a top gives on the current cooker: > > 326 root 1 0 1064m 37m 36m S0 1.9 0:14.73 systemd-journal > > even though it is only virtual, that's sound crazy to go up 1GB. > rsyslog never goes above 1M. I already mentioned the usage of mmap. -- Regards, Olav
Re: [Mageia-dev] urpmi searchmedia and 32-bit packages installation
2013/2/9 Thierry Vignaud : > On 9 February 2013 09:50, Adrien Guichard wrote: >> I am trying to install 32-bit packages using urpmi: >> # urpmi --searchmedia distrib31 mesa >> # >> >> distrib31 media is 32-bit Core packages, is there a way to force >> installation? (64-bit version is installed which I think prevent >> 32-bit installation) > > how about "urpmi libdri-drivers" ... # LANGUAGE=C; urpmi libdri-drivers To satisfy dependencies, the following packages are going to be installed: PackageVersion Release Arch (medium "Core 32bit Release (distrib31)") libdri-drivers 9.1.00.git2013020> i586 libdricore19.1.00.git2013020> i586 libdrm22.4.42 1.mga3i586 libdrm_intel1 2.4.42 1.mga3i586 libdrm_nouveau22.4.42 1.mga3i586 libdrm_radeon1 2.4.42 1.mga3i586 libexpat1 2.1.04.mga3i586 libffi63.0.11 2.mga3i586 libllvm3.2 3.2 4.mga3i586 libllvmradeon9.1.0 9.1.00.git2013020> i586 libpciaccess0 0.13.1 2.mga3i586 50MB of additional disk space will be used. 9.7MB of packages will be retrieved. Proceed with the installation of the 11 packages? (Y/n)
[Mageia-dev] freeze push: perl-URPM-4.26 & urpmi-7.19
Hi Please let in perl-URPM-4.26 & urpmi-7.19 I got rid of playing with rpm -Uvh --oldpackage foobar*rpm libfoobarX*rpm, so I added basic support for --downgrade (mga#6655). What's supported is eg: - enabling updates_testing - installing foobar from updates_testing - disabling updates_testing - running "urpmi --downgrade foobar" which will revert back to version from updates or release Thx eg: # urpmi --downgrade null The following package has to be removed for others to be upgraded: null-9-22.mga3.x86_64 (in order to install null-9-21.mga3.x86_64) (y/N) y To satisfy dependencies, the following packages are going to be installed: PackageVersion Release Arch (medium "temp45") lib64null1 921.mga3 x86_64 null 921.mga3 x86_64 0B of additional disk space will be used. 2.8KB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) y installing lib64null1-9-21.mga3.x86_64.rpm null-9-21.mga3.x86_64.rpm from /home1 Preparing... # 1/2: lib64null1# 2/2: null # csh sux 1/1: removing null-1:9-22.mga3.x86_64 # # urpme --auto-orphans writing /var/lib/rpm/installed-through-deps.list To satisfy dependencies, the following package will be removed (0B): (orphan package) lib64null2-9-22.mga3.x86_64 Remove 1 package? (y/N)
Re: [Mageia-dev] freeze push: perl-URPM-4.26 & urpmi-7.19
On 9 February 2013 22:35, Thierry Vignaud wrote: > Please let in perl-URPM-4.26 & urpmi-7.19 > I got rid of playing with rpm -Uvh --oldpackage foobar*rpm libfoobarX*rpm, > so I added basic support for --downgrade (mga#6655). > > What's supported is eg: > - enabling updates_testing > - installing foobar from updates_testing > - disabling updates_testing > - running "urpmi --downgrade foobar" which will revert > back to version from updates or release and of course both testsuites pass
Re: [Mageia-dev] freeze push: perl-URPM-4.26 & urpmi-7.19
Op zaterdag 9 februari 2013 22:35:47 schreef Thierry Vignaud: > Hi > > Please let in perl-URPM-4.26 & urpmi-7.19 > I got rid of playing with rpm -Uvh --oldpackage foobar*rpm libfoobarX*rpm, > so I added basic support for --downgrade (mga#6655). [...] ooh, this is nice!
Re: [Mageia-dev] Huh? Urpmi package numbers . . .
On 09/02/13 11:58, Robert Fox wrote: Since latest Cauldron updates - the urpmi process seems to be lying about the number of packages - In this example, it say "293" packages - but when it starts, it says 1/582 -?? Huh? urpmi --auto-update -v SNIP: 71MB of additional disk space will be used. 174MB of packages will be retrieved. Proceed with the installation of the 293 packages? (Y/n) SNIP: 2/582: lib64okteta1core1 ## 3/582: lib64kasten2gui2 ## 4/582: lib64okteta1gui1 ## 5/582: lib64kasten2okteta1core1 ## 6/582: lib64kasten2okteta1 Is this by design? Cheers, Robert Yes a removal is now counted as well as an installation, so it's double - I don't see the point, I think it was better as it was : \
Re: [Mageia-dev] bumblebee in mageia (and mentoring)
Luca Olivetti wrote: > Al 15/04/12 07:08, En/na simple w8 ha escrit: > >>> I have revised the specs and here they are attached. >>> >>> Is anyone available that could help me in the mentoring proccess? >> >> Well seams that last bumblebee spec missed the scriplets to handle >> systemd services. > > I've been given a laptop with optimus technology. > I took the following SRPMS and rebuilt them for mageia 2: > > bumblebee-3.0-11.mga3.src.rpm > dkms-acpi_call-0.1-2.mga3.src.rpm > dkms-bbswitch-0.4.2-1.mga3.src.rpm > libbsd-0.4.1-1.mga3.src.rpm > virtualgl-2.3.1-1.mga3.src.rpm > > > I have two issues (just FYI): Hi Luca, I don't know if simple w8 is with us still, I haven't seen him active in a while. Would you be interested in getting more directly involved, such that you could fix any issues yourself? If so, see the information on the Mageia Wiki about packaging mentoring, and come see us on IRC.
Re: [Mageia-dev] freeze push: perl-URPM-4.26 & urpmi-7.19
On 09/02/13 21:35, Thierry Vignaud wrote: > Hi > > Please let in perl-URPM-4.26 & urpmi-7.19 > I got rid of playing with rpm -Uvh --oldpackage foobar*rpm libfoobarX*rpm, > so I added basic support for --downgrade (mga#6655). > > What's supported is eg: > - enabling updates_testing > - installing foobar from updates_testing > - disabling updates_testing > - running "urpmi --downgrade foobar" which will revert > back to version from updates or release > > Thx > > eg: > # urpmi --downgrade null > The following package has to be removed for others to be upgraded: > null-9-22.mga3.x86_64 > (in order to install null-9-21.mga3.x86_64) (y/N) y > To satisfy dependencies, the following packages are going to be installed: > PackageVersion Release Arch > (medium "temp45") > lib64null1 921.mga3 x86_64 > null 921.mga3 x86_64 > 0B of additional disk space will be used. > 2.8KB of packages will be retrieved. > Proceed with the installation of the 2 packages? (Y/n) y > > > installing lib64null1-9-21.mga3.x86_64.rpm null-9-21.mga3.x86_64.rpm from > /home1 > Preparing... # > 1/2: lib64null1# > 2/2: null # > csh sux > 1/1: removing null-1:9-22.mga3.x86_64 > # > > # urpme --auto-orphans > writing /var/lib/rpm/installed-through-deps.list > To satisfy dependencies, the following package will be removed (0B): > > (orphan package) > lib64null2-9-22.mga3.x86_64 > Remove 1 package? (y/N) That will be really useful, thanks for adding it Thierry Claire
[Mageia-dev] GNOME apps
tmb recently requested that the vinagre, vino, and eog apps (currently development 3.7 versions) be rolled back to the stable versions. This sounds sensible to me, but what is the plan for GNOME for Mageia 3? I had been under the impression that we would stick with 3.6, but Sebastian insisted on IRC that the Council had decided to go with 3.8. I don't know how that would work as it would mean it would be updated at the last minute and not tested. Whatever will be done, rolling back these three apps, or updating things, who will be responsible for this? Just trying to get some clarity on this. Thanks. PS - if we do roll back vino, please be careful to include the security fix we recently pushed in Mageia 2 if relevant.
Re: [Mageia-dev] Beta32 and Broadcomm WiFi
Maurice Batey wrote: > On Wed, 30 Jan 2013 18:40:39 +, Maurice Batey wrote: > >> it connects and works! > > Though Network Center still doesn't immediately change 'Connect' to > 'Disconnect' after a successful connect... https://bugs.mageia.org/show_bug.cgi?id=3888
