Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-tmb-3.6.5-1.mga3
On Thu, 1 Nov 2012 02:02:25 +0100 (CET) tmb wrote: > Name: kernel-tmb Relocations: (not > relocatable) Version : 3.6.5 Vendor: > Mageia.Org Release : 1.mga3Build Date: > Thu Nov 1 01:19:16 2012 Install Date: (not installed) > Build Host: ecosse.mageia.org Group : System/Kernel and > hardwareSource RPM: (none) Size: > 70209353 License: GPLv2 Signature : (none) > Packager: tmb > URL : http://www.kernel.org This kernel fails to boot for me. It freezes during cpu stage (last portion before freeze) "perf: AMD core performance detected AMD PMV driver version:0 bitwidth48 generic reg 6 Value mask: blah max period: blah Fixed purpose events0 smpboot: Booting Node , Processors #1" it freezes at this point CPU is fx8150 8 core Both linus-2.6.5 and kernel-server-3.6.5 boot without issue. Charles -- A boy gets to be a man when a man is needed. -- John Steinbeck -- Mageia release 3 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.6.5-server-1.mga3 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] [packages-commits] [311714] revert rubygems_dir dir
On Wed, 31 Oct 2012 10:04:34 +0100 (CET)
r...@mageia.org wrote:
> Name:ruby
> -Epoch: 1
the devel pkg is still using the require %{epoch} which now
is not defined.
Charles
--
Got Mole problems? Call Avogadro at 6.02 x 10^23.
--
Mageia release 3 (Cauldron) for x86_64$
On SuperSizehttp://www.eslrahc.com
Registered Linux user #182463
3.6.5-1.mga3 x86_64
--
signature.asc
Description: PGP signature
Re: [Mageia-dev] please remove all ruby related packages from cauldron core/updates_testing for landing into release
01.11.2012 01:38, Funda Wang skrev: Thanks, but still some of them are left now: libqtruby4shared2, libruby1.9, ruby, Oops, sorry. removed now. -- Thomas
Re: [Mageia-dev] please remove all ruby related packages from cauldron core/updates_testing for landing into release
Thanks, but still some of them are left now: libqtruby4shared2, libruby1.9, ruby, 2012/10/31 Thomas Backlund > 31.10.2012 17:26, Funda Wang skrev: > >> ping? >> >> >> > Removed... > > -- > Thomas > > 2012/10/31 Funda Wang mailto:fundaw...@gmail.com>> >> >> >> Hello, >> >> Could somebody remove all ruby 1.9 related packages in >> core/updates_testing, so that we could land it into core/release. >> >> The package lists goes (in format of srpm:rpm): >> ruby-1.9.3.p194-2.mga3.src.**rpm:ruby-rake >> ruby-1.9.3.p194-2.mga3.src.**rpm:ruby-RubyGems >> ruby-1.9.3.p194-8.mga3.src.**rpm:ruby-bigdecimal >> ruby-1.9.3.p194-8.mga3.src.**rpm:ruby-io-console >> ruby-1.9.3.p194-8.mga3.src.**rpm:ruby-json >> ruby-1.9.3.p194-8.mga3.src.**rpm:ruby-minitest >> ruby-1.9.3.p194-8.mga3.src.**rpm:ruby-rake >> ruby-1.9.3.p194-8.mga3.src.**rpm:ruby-rdoc >> ruby-1.9.3.p286-1.mga3.src.**rpm:libruby1.9 >> ruby-1.9.3.p286-1.mga3.src.**rpm:ruby >> ruby-1.9.3.p286-1.mga3.src.**rpm:ruby-devel >> ruby-1.9.3.p286-1.mga3.src.**rpm:ruby-doc >> ruby-1.9.3.p286-1.mga3.src.**rpm:ruby-irb >> ruby-1.9.3.p286-1.mga3.src.**rpm:ruby-tk >> ruby-hiera-0.3.0-1.mga3.src.**rpm:ruby-hiera >> ruby-hiera-0.3.0-1.mga3.src.**rpm:ruby-hiera-doc >> ruby-qt4-4.9.1-2.mga3.src.rpm:**libqtruby4shared2 >> ruby-qt4-4.9.1-2.mga3.src.rpm:**ruby-qt4 >> ruby-qt4-4.9.1-2.mga3.src.rpm:**ruby-qt4-devel >> ruby-RubyGems-1.8.24-4.mga3.**src.rpm:ruby-RubyGems >> ruby-rubytree-0.8.3-1.mga3.**src.rpm:ruby-rubytree >> ruby-rubytree-0.8.3-1.mga3.**src.rpm:ruby-rubytree-doc >> weechat-0.3.8-1.mga3.src.rpm:**weechat-ruby >> The reason why I couldn't load it directly into release, is that I >> introduced unwanted epoch for ruby packages when doing testing. >> >> >> >
Re: [Mageia-dev] Distrib-coffee big failure of the century
On Wednesday 31 October 2012 23:29, Barry Jackson wrote: > I wrote the attached script. It checks several mirrors until it finds > one that has the normal number of files and does not fail for any other > reason. > If you feel inclined to use it please feel free to suggest any improvements. The script was caught in one of my spam and attachment protection cript, Anomy. One of the first lines was mangled. So if you could repost that second line, I'd be gratefull. === #!/bin/sh echo DEFANGED.266 exit === -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Distrib-coffee big failure of the century
On 30/10/12 21:49, Barry Jackson wrote:
On 30/10/12 21:29, Johnny A. Solbu wrote:
On Tuesday 30 October 2012 22:21, Barry Jackson wrote:
I will set --max-delete=500 locally in future.
Any better ideas?
I always run rsync manually twice. The first run I use «-n» to make
sure my mirror isn't wiped, and then run rsync normally.
I run it from a cron job via a script, so I could parse the output of a
dry run and count deletes for example, then let it decide whether to run
or not.
Thanks - worth investigating :)
I wrote the attached script. It checks several mirrors until it finds
one that has the normal number of files and does not fail for any other
reason.
Currently I have distrib-coffee at the top of the possible mirror list,
but it is skipped because it only has a fraction of the files yet.
It creates a couple of logs and runs as a cron job (or manually).
If you feel inclined to use it please feel free to suggest any improvements.
I certainly feel safer now.
Barry
#!/bin/bash
# ~/cronsync
# Run with e.g. crontab:- 30 * * * *$HOME/cronsync
# Set using crontab -e
###
# List of mirrors in preference order to use:-
mymirrors=( \
"rsync://distrib-coffee.ipsl.jussieu.fr:/pub/linux/Mageia/distrib" \
"rsync://ftp.LinuxCabal.org/Mageia/distrib" \
"rsync://ftp.acc.umu.se/mirror/mageia/distrib" \
"rsync://mirrors.kernel.org:/mirrors/mageia/distrib" \
"rsync://mageia.c3sl.ufpr.br/mageia/distrib" \
)
# Set limit for loss of # of files on server before it is skipped
allowdropfiles=100
###
# Personal config:-
myexcludes="--exclude=debug --exclude=SRPMS --exclude=barjac"
mydestination="/zmrepo/pub/linux/Mageia/"
###
# Get minimum file count for mirror (set at allowdropfiles files less than the
last actual file count)
[[ -f .cronsync ]] || echo "14" > $HOME/.cronsync
minfiles=$(cat .cronsync)
((actualfiles = $minfiles + $allowdropfiles))
# Check a mirror
chk_mirror()
{
echo "Checking $1 ..."
chkout=$(rsync -rlptgoDhHSn \
--stats \
--delete-after \
--delete \
--delete-excluded \
--protect-args \
$myexcludes \
"$1" \
"$mydestination" | grep "Number of files:" )
status1="$?"
files=$(echo $chkout | cut -d' ' -f4)
[[ $files -lt $minfiles ]] && echo "$(date +%d/%m/%Y-%H:%M): Only
$files/$actualfiles files in $1 !" | tee -a $HOME/cronsync_error.log
[[ $status1 > 0 ]] && echo "$(date +%d/%m/%Y-%H:%M): Error: $status1 while
checking $1" | tee -a $HOME/cronsync_error.log
([[ $status1 = 0 ]] && [[ $files -gt $minfiles ]]) || return 1
((chkcount = $files - $allowdropfiles))
echo $chkcount > $HOME/.cronsync
return 0
}
# Loop through mirror list checking until one succeeds
find_good_mirror()
{
for mirr in ${mymirrors[@]}; do
chk_mirror $mirr
[[ $? = 0 ]] && { echo "Found good mirror - $mirr"; return 0; }
done
return 1
}
#===Main Program starts here=
# Check if rsync is already running (maybe last cron sync taking for ever?)
ps aux | grep -q [r]sync
if [[ $? > 0 ]]; then
# Find a good mirror from the list (with files in it)
find_good_mirror || { echo "$(date +%d/%m/%Y-%H:%M) Can't find a good mirror -
aborting" | tee -a $HOME/cronsync_error.log; exit 1; }
echo "Syncing from $mirr ..."
# Live run with --max-delete set to 1000 just in case ;)
rsync -rlptgoDhHS \
--progress \
--stats \
--delete-after \
--delete \
--max-delete=1000 \
--delete-excluded \
--protect-args \
$myexcludes \
"$mirr" \
"$mydestination" | tee $HOME/cronsync_last.log
status=$?
[[ $status = 0 ]] && { echo "Update complete"; exit 0; }
[[ $status > 0 ]] && { echo "Live run error - $(date +%d/%m/%Y-%H:%M) =
$status" >> $HOME/cronsync_error.log; exit 1; }
else
echo "rsync already running, skipping update - $(date +%d/%m/%Y-%H:%M)" >>
$HOME/cronsync_error.log
exit 1
fi
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.6.4-1.mga3
31.10.2012 23:09, Charles A Edwards skrev: On Wed, 31 Oct 2012 18:15:52 +0200 Thomas Backlund wrote: Of course the bug could be another one too, but that one was the first that came to mind An other thought... IIRC you are a fglrx user. Partly true. I'm using fglrx on an older mandriva system but this system uses nvidia. Whatever the cause it appears to have been patched/fixed in 3.6.5 This is your latest linus and it booted without issue. Great, thanks for the info. -- Thomas
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.6.4-1.mga3
On Wed, 31 Oct 2012 18:15:52 +0200 Thomas Backlund wrote: > > > > Of course the bug could be another one too, but that one was the > > first that came to mind > > An other thought... > > IIRC you are a fglrx user. Partly true. I'm using fglrx on an older mandriva system but this system uses nvidia. Whatever the cause it appears to have been patched/fixed in 3.6.5 This is your latest linus and it booted without issue. Charles -- 'Oh, them as makes the endings don't get them,' said Granny. (Maskerade) -- Mageia release 3 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.6.5-1.mga3 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] cinelerra/audiokonverter/arista (war Re: rehashing the faac issue)
On Wed, 31 Oct 2012, PhilippeDidier wrote: I don't know actually how to create *.aac files or *.mp4 files with Mageia... if you help me I will be happy... ffmpeg -i foo.mp3 -strict -2 -codec:a aac -format adts foo.aac But AFAIK this uses the ffmpeg internal aac codec which isn't very good. -codec:a libvo_aacenc produces garbage, no idea why About arista: someone decided to use the internal ffmpeg lib from gstreamer-ffmpeg for gstreamer0.10-ffmpeg which broke arista. Now arista must be ported to gstreamer1.0 . Christiaan
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
Christiaan Welvaart a écrit : > On Wed, 31 Oct 2012, PhilippeDidier wrote: > >> Christiaan Welvaart a écrit : >>> We are not going to carry faac just for convenience to build >>> applications locally. Handbrake, another application that supposedly >>> needs faac, is also GPL licensed so cannot be distributed linked against >>> faac. Arista in mageia supports encoding AAC without faac. >>> Audiokonverter appears to use mplayer for encoding so it should be able >>> to use ffmpeg for AAC. Anything else? > >> You're wrong about audiokonverter : >> it uses faac to encode into *.aac files > > I don't know what .aac files are (format), will check. That's compressed audio files (for ipod for instance) That's also the audiotrack format for MPEG4 > >> I proposed the two patches to have it in Mageia: > > Saw that in the bugreport (: > >> About Arista : >> I tried Arista to create an *.aac file : it complains about missing >> elements... >> Could you really create *.aac files ? or did you only read what it is >> supposed to do. > I only tried to transcode video with aac audio track, not audio only. > Do you mean transcode video with aac audio track into other format (that's already allowed, thanks to faad provided by Mageia) or transcode an existing video (with mp3 audio track for instance) into video with aac audio track (that is not allowed with Mageia2 whichever software you use : avidemux, vlc, mencoder, gstreamer, ffmpeg) >> Arista uses gstreamer... and, in Mageia, gstreamer-plugins in tainted >> are built without faac, I wonder what is missing on my computer to be >> able to do what you did !!! > libavcodec from tainted and gstreamer-ffmpeg/gstreamer-libav >- this depends on libvo-aacenc > + arista 0.9.7-4 So you use cauldron ;) Mageia2 has arista 0.9.7.2 I have too libavcodec from tainted, libvo-aaenc, gstreamer-ffmpeg (can't find any gstreamer-libav on Mageia2) Is the new built gstreamer on cauldron allowing to create mp4 or aac files now ? > >> About Cinelerra and Handbrake : everything is GPL licensed except the >> ISO specification they need to be built ... >> provided as bundled in hanbrake (reason why it was banned from >> Mageia-tainted) >> and required as BuildRequire : faac-devel for cinelerra, preventing to >> build it for Mageia >> >> And Yes absolutely there's a contamination with a non-free source (how >> the hell an ISO MPEG4 norma could be GPL ? ) > AFAIK it's code, not the standard itself > > > Christiaan > Perhaps Cauldron provides something now for this aac encoding problem... that's good news for Mageia3 but I will have to wait and see : I must use the stable Mageia2 on my everyday computer... (with some workarounds ;) ) until Mageia3 appears Regards Philippe
Re: [Mageia-dev] saslauthd + systemd + postfix
Ok, i will fix it. Driving... Enviado desde mi DROID 4G LTE de Verizon Wireless Colin Guthrie escribió: >'Twas brillig, and Luis Daniel Lucio Quiroz at 31/10/12 12:58 did gyre >and gimble: >> Yes i know it uses hardlink, what i mean what advantages do you see by >> changing to bind mount. >> >> >> I mean if it works, why shall we fix it? > >That's the problem, it doesn't work anymore in cauldron as /var/run is >on a different filesystem to /var/spool/postfix/var/run and hardlinks >only work within the same filesystem. > >Even the old way would have been broken if /var/lib was mounted >separately (although this would be very rare indeed!). > >So as I stated originally, hardlinks simply won't work as a solution any >more. > >I was thinking of bind mounting only the individual mux socket. > >It's not ideal, but I can't think of a nicer way. > >Col > > >-- > >Colin Guthrie >colin(at)mageia.org >http://colin.guthr.ie/ > >Day Job: > Tribalogic Limited http://www.tribalogic.net/ >Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ >Email Shield provided by NOCWorldWide.com
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
On Wed, 31 Oct 2012, PhilippeDidier wrote: Christiaan Welvaart a écrit : We are not going to carry faac just for convenience to build applications locally. Handbrake, another application that supposedly needs faac, is also GPL licensed so cannot be distributed linked against faac. Arista in mageia supports encoding AAC without faac. Audiokonverter appears to use mplayer for encoding so it should be able to use ffmpeg for AAC. Anything else? You're wrong about audiokonverter : it uses faac to encode into *.aac files I don't know what .aac files are (format), will check. I proposed the two patches to have it in Mageia: Saw that in the bugreport (: About Arista : I tried Arista to create an *.aac file : it complains about missing elements... Could you really create *.aac files ? or did you only read what it is supposed to do. I only tried to transcode video with aac audio track, not audio only. Arista uses gstreamer... and, in Mageia, gstreamer-plugins in tainted are built without faac, I wonder what is missing on my computer to be able to do what you did !!! libavcodec from tainted and gstreamer-ffmpeg/gstreamer-libav - this depends on libvo-aacenc + arista 0.9.7-4 About Cinelerra and Handbrake : everything is GPL licensed except the ISO specification they need to be built ... provided as bundled in hanbrake (reason why it was banned from Mageia-tainted) and required as BuildRequire : faac-devel for cinelerra, preventing to build it for Mageia And Yes absolutely there's a contamination with a non-free source (how the hell an ISO MPEG4 norma could be GPL ? ) AFAIK it's code, not the standard itself Christiaan
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
Christiaan Welvaart a écrit : > On Wed, 31 Oct 2012, Guillaume Rousse wrote: > >> Le 31/10/2012 12:57, Christiaan Welvaart a écrit : >>> On Wed, 31 Oct 2012, Guillaume Rousse wrote: >>> Le 31/10/2012 10:23, Christiaan Welvaart a écrit : > On Tue, 2 Oct 2012, Guillaume Rousse wrote: > >> Given the importance of this package for several multimedia-related >> software (it is a mandatory dependency for cinerella, for >> instance), I >> think it's time > > Do you have a cinelerra source rpm that builds against cauldron > ffmpeg? > And we can build it without AAC encoding support I think. No. Otherwise, I wouldn't have opened this painful discussion again. >>> >>> Isn't cinelerra licensed under the GPLv2+, which means we are not >>> allowed to distribute binaries linked against a non-free library? It >>> looks like the faac discussion is not painful but completely useless. >> I wasn't aware of such kind of restriction, but it reminds me of >> similar cases in the past. Anyway, faac isn't only used for cinelerra, >> and even if we can't distribute it, having one less ancestor to >> rebuild manually is still a gain. > > We are not going to carry faac just for convenience to build > applications locally. Handbrake, another application that supposedly > needs faac, is also GPL licensed so cannot be distributed linked against > faac. Arista in mageia supports encoding AAC without faac. > Audiokonverter appears to use mplayer for encoding so it should be able > to use ffmpeg for AAC. Anything else? > > > Christiaan > You're wrong about audiokonverter : it uses faac to encode into *.aac files I proposed the two patches to have it in Mageia: one to build it without using lame and faac for core repo (patent problem for both of them) one to build it with using lame but without using faac for tainted repo (as soon as faac is not provided) NB for my personal use I packaged audiokonverter without patch, and installed faac from blogdrake's repo ! About Arista : I tried Arista to create an *.aac file : it complains about missing elements... Could you really create *.aac files ? or did you only read what it is supposed to do. Arista uses gstreamer... and, in Mageia, gstreamer-plugins in tainted are built without faac, I wonder what is missing on my computer to be able to do what you did !!! About Cinelerra and Handbrake : everything is GPL licensed except the ISO specification they need to be built ... provided as bundled in hanbrake (reason why it was banned from Mageia-tainted) and required as BuildRequire : faac-devel for cinelerra, preventing to build it for Mageia And Yes absolutely there's a contamination with a non-free source (how the hell an ISO MPEG4 norma could be GPL ? ) For example : is UTF8 GPL ? is ISO-8859 GPL : nevertheless you use these nonGPL specifications to read this thread in your webbrowser) I don't know actually how to create *.aac files or *.mp4 files with Mageia... if you help me I will be happy... Philippe
Re: [Mageia-dev] saslauthd + systemd + postfix
'Twas brillig, and Luis Daniel Lucio Quiroz at 31/10/12 12:58 did gyre and gimble: > Yes i know it uses hardlink, what i mean what advantages do you see by > changing to bind mount. > > > I mean if it works, why shall we fix it? That's the problem, it doesn't work anymore in cauldron as /var/run is on a different filesystem to /var/spool/postfix/var/run and hardlinks only work within the same filesystem. Even the old way would have been broken if /var/lib was mounted separately (although this would be very rare indeed!). So as I stated originally, hardlinks simply won't work as a solution any more. I was thinking of bind mounting only the individual mux socket. It's not ideal, but I can't think of a nicer way. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.6.4-1.mga3
30.10.2012 04:38, Thomas Backlund skrev: Of course the bug could be another one too, but that one was the first that came to mind An other thought... IIRC you are a fglrx user. The 9.002 driver did not work properly with x11-server despite the fact it was supposed to :/ But the 9.01 I just uploaded should work better... -- Thomas
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
On Wed, 31 Oct 2012, Guillaume Rousse wrote: Le 31/10/2012 12:57, Christiaan Welvaart a écrit : On Wed, 31 Oct 2012, Guillaume Rousse wrote: Le 31/10/2012 10:23, Christiaan Welvaart a écrit : On Tue, 2 Oct 2012, Guillaume Rousse wrote: Given the importance of this package for several multimedia-related software (it is a mandatory dependency for cinerella, for instance), I think it's time Do you have a cinelerra source rpm that builds against cauldron ffmpeg? And we can build it without AAC encoding support I think. No. Otherwise, I wouldn't have opened this painful discussion again. Isn't cinelerra licensed under the GPLv2+, which means we are not allowed to distribute binaries linked against a non-free library? It looks like the faac discussion is not painful but completely useless. I wasn't aware of such kind of restriction, but it reminds me of similar cases in the past. Anyway, faac isn't only used for cinelerra, and even if we can't distribute it, having one less ancestor to rebuild manually is still a gain. We are not going to carry faac just for convenience to build applications locally. Handbrake, another application that supposedly needs faac, is also GPL licensed so cannot be distributed linked against faac. Arista in mageia supports encoding AAC without faac. Audiokonverter appears to use mplayer for encoding so it should be able to use ffmpeg for AAC. Anything else? Christiaan
Re: [Mageia-dev] please remove all ruby related packages from cauldron core/updates_testing for landing into release
31.10.2012 17:26, Funda Wang skrev: ping? Removed... -- Thomas 2012/10/31 Funda Wang mailto:fundaw...@gmail.com>> Hello, Could somebody remove all ruby 1.9 related packages in core/updates_testing, so that we could land it into core/release. The package lists goes (in format of srpm:rpm): ruby-1.9.3.p194-2.mga3.src.rpm:ruby-rake ruby-1.9.3.p194-2.mga3.src.rpm:ruby-RubyGems ruby-1.9.3.p194-8.mga3.src.rpm:ruby-bigdecimal ruby-1.9.3.p194-8.mga3.src.rpm:ruby-io-console ruby-1.9.3.p194-8.mga3.src.rpm:ruby-json ruby-1.9.3.p194-8.mga3.src.rpm:ruby-minitest ruby-1.9.3.p194-8.mga3.src.rpm:ruby-rake ruby-1.9.3.p194-8.mga3.src.rpm:ruby-rdoc ruby-1.9.3.p286-1.mga3.src.rpm:libruby1.9 ruby-1.9.3.p286-1.mga3.src.rpm:ruby ruby-1.9.3.p286-1.mga3.src.rpm:ruby-devel ruby-1.9.3.p286-1.mga3.src.rpm:ruby-doc ruby-1.9.3.p286-1.mga3.src.rpm:ruby-irb ruby-1.9.3.p286-1.mga3.src.rpm:ruby-tk ruby-hiera-0.3.0-1.mga3.src.rpm:ruby-hiera ruby-hiera-0.3.0-1.mga3.src.rpm:ruby-hiera-doc ruby-qt4-4.9.1-2.mga3.src.rpm:libqtruby4shared2 ruby-qt4-4.9.1-2.mga3.src.rpm:ruby-qt4 ruby-qt4-4.9.1-2.mga3.src.rpm:ruby-qt4-devel ruby-RubyGems-1.8.24-4.mga3.src.rpm:ruby-RubyGems ruby-rubytree-0.8.3-1.mga3.src.rpm:ruby-rubytree ruby-rubytree-0.8.3-1.mga3.src.rpm:ruby-rubytree-doc weechat-0.3.8-1.mga3.src.rpm:weechat-ruby The reason why I couldn't load it directly into release, is that I introduced unwanted epoch for ruby packages when doing testing.
Re: [Mageia-dev] please remove all ruby related packages from cauldron core/updates_testing for landing into release
ping? 2012/10/31 Funda Wang > Hello, > > Could somebody remove all ruby 1.9 related packages in > core/updates_testing, so that we could land it into core/release. > > The package lists goes (in format of srpm:rpm): > ruby-1.9.3.p194-2.mga3.src.rpm:ruby-rake > ruby-1.9.3.p194-2.mga3.src.rpm:ruby-RubyGems > ruby-1.9.3.p194-8.mga3.src.rpm:ruby-bigdecimal > ruby-1.9.3.p194-8.mga3.src.rpm:ruby-io-console > ruby-1.9.3.p194-8.mga3.src.rpm:ruby-json > ruby-1.9.3.p194-8.mga3.src.rpm:ruby-minitest > ruby-1.9.3.p194-8.mga3.src.rpm:ruby-rake > ruby-1.9.3.p194-8.mga3.src.rpm:ruby-rdoc > ruby-1.9.3.p286-1.mga3.src.rpm:libruby1.9 > ruby-1.9.3.p286-1.mga3.src.rpm:ruby > ruby-1.9.3.p286-1.mga3.src.rpm:ruby-devel > ruby-1.9.3.p286-1.mga3.src.rpm:ruby-doc > ruby-1.9.3.p286-1.mga3.src.rpm:ruby-irb > ruby-1.9.3.p286-1.mga3.src.rpm:ruby-tk > ruby-hiera-0.3.0-1.mga3.src.rpm:ruby-hiera > ruby-hiera-0.3.0-1.mga3.src.rpm:ruby-hiera-doc > ruby-qt4-4.9.1-2.mga3.src.rpm:libqtruby4shared2 > ruby-qt4-4.9.1-2.mga3.src.rpm:ruby-qt4 > ruby-qt4-4.9.1-2.mga3.src.rpm:ruby-qt4-devel > ruby-RubyGems-1.8.24-4.mga3.src.rpm:ruby-RubyGems > ruby-rubytree-0.8.3-1.mga3.src.rpm:ruby-rubytree > ruby-rubytree-0.8.3-1.mga3.src.rpm:ruby-rubytree-doc > weechat-0.3.8-1.mga3.src.rpm:weechat-ruby > > The reason why I couldn't load it directly into release, is that I > introduced unwanted epoch for ruby packages when doing testing. >
Re: [Mageia-dev] GDM Configuration
On 10/30/2012 05:15 AM, Olav Vitters wrote: An example is given of using gconf-edit to access apps/gdm, but no such key exists. Mention is made of using a "gdm3setup" executable that we don't seem to have. GDM has been migrated to gsettings (in practice: dconf). I found and installed dconf-editor, and opened it, but the key index doesn't have a whisper of GDM. Still, the filelist for the GDM RPM has filenames related to XDMCP. Is this possibly a build option that isn't getting set, or maybe a pam.d setting that is turning it off ?
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
Le 31/10/2012 12:57, Christiaan Welvaart a écrit :
On Wed, 31 Oct 2012, Guillaume Rousse wrote:
Le 31/10/2012 10:23, Christiaan Welvaart a écrit :
On Tue, 2 Oct 2012, Guillaume Rousse wrote:
Given the importance of this package for several multimedia-related
software (it is a mandatory dependency for cinerella, for instance), I
think it's time
Do you have a cinelerra source rpm that builds against cauldron ffmpeg?
And we can build it without AAC encoding support I think.
No. Otherwise, I wouldn't have opened this painful discussion again.
Isn't cinelerra licensed under the GPLv2+, which means we are not
allowed to distribute binaries linked against a non-free library? It
looks like the faac discussion is not painful but completely useless.
I wasn't aware of such kind of restriction, but it reminds me of similar
cases in the past. Anyway, faac isn't only used for cinelerra, and even
if we can't distribute it, having one less ancestor to rebuild manually
is still a gain.
Who wants to maintain this package? I built it and it appears to work
but complains a bit - maybe due to cauldron ffmpeg - and crashes when
trying to output AAC ("mp4a") because I forgot to remove that UI option.
This is a distinct issue.
--
BOFH excuse #14:
sounds like a Windows problem, try calling Microsoft support
Re: [Mageia-dev] saslauthd + systemd + postfix
On Wed, Oct 31, 2012 at 06:58:55AM -0600, Luis Daniel Lucio Quiroz wrote: > Yes i know it uses hardlink, what i mean what advantages do you see by > changing to bind mount. > > > I mean if it works, why shall we fix it? As explained by Colin, the hardlink solution won't work anymore. Please read the email by Colin thoroughly... -- Regards, Olav
Re: [Mageia-dev] saslauthd + systemd + postfix
Le 31/10/2012 13:58, Luis Daniel Lucio Quiroz a écrit : Yes i know it uses hardlink, what i mean what advantages do you see by changing to bind mount. Consistency with similar cases, such as the incoming bind chroot setup script (adapted from fedora). -- BOFH excuse #69: knot in cables caused data stream to become twisted and kinked
Re: [Mageia-dev] saslauthd + systemd + postfix
Yes i know it uses hardlink, what i mean what advantages do you see by changing to bind mount. I mean if it works, why shall we fix it? Enviado desde mi DROID 4G LTE de Verizon Wireless Olav Vitters escribió: >On Wed, Oct 31, 2012 at 05:59:12AM -0600, Luis Daniel Lucio Quiroz wrote: >> Please explain me why you want to change the current bind mount of >> sasl for postfix? What you propose? > >If you read the thread you'll notice that Colin said it uses hard link >and that I suggested bind mounts. If it is already using bind mounts >instead of hard links, cool. > >-- >Regards, >Olav >Email Shield provided by NOCWorldWide.com
Re: [Mageia-dev] saslauthd + systemd + postfix
On Wed, Oct 31, 2012 at 05:59:12AM -0600, Luis Daniel Lucio Quiroz wrote: > Please explain me why you want to change the current bind mount of > sasl for postfix? What you propose? If you read the thread you'll notice that Colin said it uses hard link and that I suggested bind mounts. If it is already using bind mounts instead of hard links, cool. -- Regards, Olav
Re: [Mageia-dev] saslauthd + systemd + postfix
Please explain me why you want to change the current bind mount of sasl for postfix? What you propose? Enviado desde mi DROID 4G LTE de Verizon Wireless Olav Vitters escribió: >On Tue, Oct 30, 2012 at 04:55:28PM +, Colin Guthrie wrote: >> So, what should we do? Should we switch to bind mounts? Should we make >> saslauthd/postfix use abstract sockets instead to get around the chroot? > >bind mount for just saslauth seems cleanest to me. Don't bind mount >entire /run or /var/run, could impact security of the chroot somehow. > >-- >Regards, >Olav >Email Shield provided by NOCWorldWide.com
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
On Wed, 31 Oct 2012, Guillaume Rousse wrote:
Le 31/10/2012 10:23, Christiaan Welvaart a écrit :
On Tue, 2 Oct 2012, Guillaume Rousse wrote:
Given the importance of this package for several multimedia-related
software (it is a mandatory dependency for cinerella, for instance), I
think it's time
Do you have a cinelerra source rpm that builds against cauldron ffmpeg?
And we can build it without AAC encoding support I think.
No. Otherwise, I wouldn't have opened this painful discussion again.
Isn't cinelerra licensed under the GPLv2+, which means we are not allowed
to distribute binaries linked against a non-free library? It looks like
the faac discussion is not painful but completely useless.
Who wants to maintain this package? I built it and it appears to work but
complains a bit - maybe due to cauldron ffmpeg - and crashes when
trying to output AAC ("mp4a") because I forgot to remove that UI option.
Christiaan
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
Le 31/10/2012 10:23, Christiaan Welvaart a écrit : On Tue, 2 Oct 2012, Guillaume Rousse wrote: Given the importance of this package for several multimedia-related software (it is a mandatory dependency for cinerella, for instance), I think it's time Do you have a cinelerra source rpm that builds against cauldron ffmpeg? And we can build it without AAC encoding support I think. No. Otherwise, I wouldn't have opened this painful discussion again. -- BOFH excuse #16: somebody was calculating pi on the server
Re: [Mageia-dev] Reminder: Mageia 3 alpha 3
On Wed, Oct 31, 2012 at 02:16:31AM +0200, Thomas Backlund wrote: > Consider Friday 2nd Oct 2012 as 21.00 UTC as a "soft freeze" for > avoiding breakages until alpha3 is released... Ok! -- Regards, Olav
Re: [Mageia-dev] Reminder: Mageia 3 alpha 3
Johnny A. Solbu skrev 31.10.2012 03:06: On Wednesday 31 October 2012 01:16, Thomas Backlund wrote: Consider Friday 2nd Oct 2012 as 21.00 UTC as a "soft freeze" You mean 2nd _Nov_, right? :-)= (Which is friday this week.) Yeah, that's what I meant :) (thats what I get for posting in the middle of the night) -- Thomas
Re: [Mageia-dev] saslauthd + systemd + postfix
On Tue, Oct 30, 2012 at 04:55:28PM +, Colin Guthrie wrote: > So, what should we do? Should we switch to bind mounts? Should we make > saslauthd/postfix use abstract sockets instead to get around the chroot? bind mount for just saslauth seems cleanest to me. Don't bind mount entire /run or /var/run, could impact security of the chroot somehow. -- Regards, Olav
[Mageia-dev] cinelerra (war Re: rehashing the faac issue)
On Tue, 2 Oct 2012, Guillaume Rousse wrote: Given the importance of this package for several multimedia-related software (it is a mandatory dependency for cinerella, for instance), I think it's time Do you have a cinelerra source rpm that builds against cauldron ffmpeg? And we can build it without AAC encoding support I think. Christiaan
[Mageia-dev] please remove all ruby related packages from cauldron core/updates_testing for landing into release
Hello, Could somebody remove all ruby 1.9 related packages in core/updates_testing, so that we could land it into core/release. The package lists goes (in format of srpm:rpm): ruby-1.9.3.p194-2.mga3.src.rpm:ruby-rake ruby-1.9.3.p194-2.mga3.src.rpm:ruby-RubyGems ruby-1.9.3.p194-8.mga3.src.rpm:ruby-bigdecimal ruby-1.9.3.p194-8.mga3.src.rpm:ruby-io-console ruby-1.9.3.p194-8.mga3.src.rpm:ruby-json ruby-1.9.3.p194-8.mga3.src.rpm:ruby-minitest ruby-1.9.3.p194-8.mga3.src.rpm:ruby-rake ruby-1.9.3.p194-8.mga3.src.rpm:ruby-rdoc ruby-1.9.3.p286-1.mga3.src.rpm:libruby1.9 ruby-1.9.3.p286-1.mga3.src.rpm:ruby ruby-1.9.3.p286-1.mga3.src.rpm:ruby-devel ruby-1.9.3.p286-1.mga3.src.rpm:ruby-doc ruby-1.9.3.p286-1.mga3.src.rpm:ruby-irb ruby-1.9.3.p286-1.mga3.src.rpm:ruby-tk ruby-hiera-0.3.0-1.mga3.src.rpm:ruby-hiera ruby-hiera-0.3.0-1.mga3.src.rpm:ruby-hiera-doc ruby-qt4-4.9.1-2.mga3.src.rpm:libqtruby4shared2 ruby-qt4-4.9.1-2.mga3.src.rpm:ruby-qt4 ruby-qt4-4.9.1-2.mga3.src.rpm:ruby-qt4-devel ruby-RubyGems-1.8.24-4.mga3.src.rpm:ruby-RubyGems ruby-rubytree-0.8.3-1.mga3.src.rpm:ruby-rubytree ruby-rubytree-0.8.3-1.mga3.src.rpm:ruby-rubytree-doc weechat-0.3.8-1.mga3.src.rpm:weechat-ruby The reason why I couldn't load it directly into release, is that I introduced unwanted epoch for ruby packages when doing testing.
