Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kmod-virtualbox-4.1.8-17.mga2
On 5 March 2012 22:44, tmb wrote: > tmb 4.1.8-17.mga2: > + Revision: 219296 > - rebuild for kernel-3.3.0-0.rc6.1.mga2 BTW there's a bug: when we update kernel, we install new kmd-vbox but we remove the one installed for the currently installed kernel. If we don't reboot immediately and try to use vbox it may fail...
Re: [Mageia-dev] qt3-devel
On Sat, Mar 3, 2012 at 10:24 AM, Colin Guthrie wrote: > 'Twas brillig, and Kamil Rytarowski at 02/03/12 19:43 did gyre and gimble: > > On 02.03.2012 19:55, Thomas Backlund wrote: > >> 02.03.2012 20:49, Kamil Rytarowski skrev: > >>> Hello! > >>> > >>> Is possible to ship qt3-devel with Mageia? Half of the the Polish > >>> community is demanding it, and because of lack of qt3-devel people > can't > >>> switch from other Well Known Distros to Mageia. > >>> > >> NO. > >> > >> As stated a million times before... > >> > >> qt3 is obsolete > >> > >> The only reason we have some qt3 runtime support is because of LSB > > Sad.. > >> > >> Any stuff needed should be ported to qt4. > > Actually this is not true. One of our Mageia users (who introduced > > Mageia on a dozen of machines) can't switch the next dozen because of > > lacking Rivendell Radio Broadcasting software ( > > http://www.rivendellaudio.org/index.shtml ), the other can't use his > > favourite qt3 apps, and a few others (including RH employee) are forced > > to use Fedora or KDE4. > > > > If the "obsolete" part is the only reason, then it's not too strong.. > > the package is maintained and there is *upstream*. > > > > As of the 3.5.13 release the Trinity project has taken over maintenance > > of Qt3. > > > > This means we are the new "upstream" location for up-to-date Qt3 > > source code. > > Since there have been no updates or stable releases from > > Nokia/Trolltech in many years and there are literally hundreds patches > > floating around, there was a significant need for a central location. > > By maintaining Qt3 it will allow us to continue to improve Qt3 > > outside the scope of Trinity. It will also provide a central location > > for Linux distributions to build packages from, and contributers to > > submit code to. > > For obvious reasons any Qt3 version released by this project is > > licensed under the GPL only; holders of Trolltech Qt licenses may not > > use these versions in their proprietary projects. > > > > > http://www.trinitydesktop.org/wiki/bin/view/Documentation/Releases_3_5_13#Qt3 > > > > > > Trinity is currently packaged for Mandriva, OpenSUSE and available for > > the main distros. > > I am thoroughly unimpressed with this trinity stuff. Open Source > software gives people freedoms and that's good, but it doesn't stop them > making bad decisions. > > Times move on. Why take a legacy bit of software and keep on developing > it? If they *really* cared so much for the KDE3 interface they would > port it to qt4 or even qt5, not limp on with outdated base layers. > Funny you say that. I believe they tried with a pkg called qtinterface. Don't quote me, but the gist of it was that qt4 has performance issues in many areas. It's all POV... I wouldn't call kde4 the panacea of DEs either... so in a sense I agree with you in that it doesn't stop a group of ppl from making a long set of bad decisions > > > 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] Deprecating startx
On Thu, 08 Mar 2012 02:08:03 + Colin Guthrie wrote: > > You can also add me to that 'small' list. > > You seem unconvinced due to your use of quotes. It's very hard to > evaluate this kind of thing, but obviously "developery" types are a > skewed source of information. I was being facetious.. There in no doubt that this places me in a minuscule minority. But I can/will adapt and either find/develop a work-a-round or learn to live with using a dm. Charles -- Schapiro's Explanation: The grass is always greener on the other side -- but that's because they use more manure. -- Mageia release 2 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.2.9-server-2.mga2 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Wed, 07 Mar 2012 21:00:38 -0500, wrote: As far as I understand there is frame buffer support in the 3.3 kernel for the GMA 3600 so in theory it should work. Oops. Sorry, that second one should have been i915.modeset=0 Regards, Dave Hodgins
Re: [Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
On Wed, 07 Mar 2012 21:00:38 -0500, wrote: On Thu, 8 Mar 2012 tux99-...@uridium.org wrote: Hi, I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it would have framebuffer support for the GMA 3600, but the attached monitor goes into standby (no signal) as soon as the frame buffer gets activated during boot. Try disabling kms by adding either nokmsboot or modeset.i915=0 to the kernel options. Regards, Dave Hodgins
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Charles A Edwards at 08/03/12 01:20 did gyre and gimble: > On Wed, 07 Mar 2012 22:06:19 + > Colin Guthrie wrote: > >> The actual use case of using a text login and then starting X is quite >> small. Of course some people (like Wobo) do use this but it's >> definitely the exception rather than the rule. > > > You can also add me to that 'small' list. You seem unconvinced due to your use of quotes. It's very hard to evaluate this kind of thing, but obviously "developery" types are a skewed source of information. Believe me, I frequently design out approaches that I myself use because they are quite simply the wrong approach and I refuse to let my own personal habits get in the way of correct design. This is why I give far less credence to "old habits" and "how it's been done in the past" and much more to "what would my mum expect" or "what would a novice computer user expect". >From this viewpoint the problems some developer types (myself included) attach to some issues simply vanish. 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] Mageia support for GMA 3600 (Cedar Trail Atom)
On Thu, 8 Mar 2012 tux99-...@uridium.org wrote: > > Hi, > I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it > would have framebuffer support for the GMA 3600, but the attached > monitor goes into standby (no signal) as soon as the frame buffer gets > activated during boot. > > As far as I understand there is frame buffer support in the 3.3 kernel > for the GMA 3600 so in theory it should work. > > Are you aware of this issue or should I do a bug report? > > Has anyone else tested a GMA 3600 (the GPU that's in all Cedar Trail > Atom cpus) with Mageia so far? > > Regards, > tux99 Just to add: I have tried all grub opptions (normal, non-fb and failsafe) on each of them the same thing happens. with non-fb I can see the boot process until almost the end, I guess it's the start of the dm that triggers the loss of signal in that case. I tried editing the grub line adding a "3" at end hopeing to get it to boot to runlevel 3 but that doesn't seem to work as the behaviour doesn't change. Is "3" on the grub line still supposed to work? I imagine this GMA3600 issue needs solving before the final release as CedarTrail Atoms will be in most Netbooks sold this year, and even though netbooks are less popular then they used to be, they are still selling by the milions especially in Asia. Let me know what I could do to help debug this.
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Juan Luis Baptiste at 07/03/12 23:45 did gyre and gimble: > On Wed, Mar 7, 2012 at 6:34 PM, Colin Guthrie wrote: >> As I said last time to this question, I'd certainly be extremely annoyed >> if mga2 does not default to systemd. I've given up a massive amount of >> my free time over this cycle working towards this. I would be massively >> annoyed if this effort was ultimately towards a secondary option. >> >> > > Don't worry, no one has said that it shouldn't :), but it's clear > there's a confusion as you have seen, many people understood that > systemd would come as an alternative to mga2 and sysvinit as default, > and systemd as default in mga3. I also remember reading last year this > but never the change of plans, maybe it was decided on the meetinfgs, > but as I can't attend to them because of the schedule I missed the > announcement. Well that's just the thing, I don't see it as a change... As far as I'm concerned I've always been targeting a systemd-by-default mga2. 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] Deprecating startx
On Wed, 07 Mar 2012 22:06:19 + Colin Guthrie wrote: > The actual use case of using a text login and then starting X is quite > small. Of course some people (like Wobo) do use this but it's > definitely the exception rather than the rule. You can also add me to that 'small' list. Charles -- Let the meek inherit the earth -- they have it coming to them. -- James Thurber -- Mageia release 2 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.2.9-server-2.mga2 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] Release_blocker bugs
On 07/03/12 20:43, Manuel Hiebel wrote: Hello, How can we (the bugsquad or other people) determinate what can be a release_blocker bug ? in the triage guide we can see: "The release_blocker priority is only relevant to bugs filed on Cauldron or beta releases, and should only be used for issues which are sufficiently critical that it would severely impair the overall quality of a release if it were made available without the issue being resolved." That is not clear for me. And the only mail relating to that, was from Anne in May and not useful for me. So what about for release blockers: An default installed soft not working out of the box ? Any soft that cannot be launched ? Issue that a lot people can have ? something other ? Comments is welcome, thanks BTW: The current one are: https://bugs.mageia.org/buglist.cgi?priority=release_blocker&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED And related to trackers (also set to release blocker) https://bugs.mageia.org/showdependencytree.cgi?id=1994&hide_resolved=1 Could bug 2317 please be added as a release blocker for final release.
[Mageia-dev] Mageia support for GMA 3600 (Cedar Trail Atom)
Hi, I just tried Mageia 2 beta 1 on a Intel DN2800MT board hoping that it would have framebuffer support for the GMA 3600, but the attached monitor goes into standby (no signal) as soon as the frame buffer gets activated during boot. As far as I understand there is frame buffer support in the 3.3 kernel for the GMA 3600 so in theory it should work. Are you aware of this issue or should I do a bug report? Has anyone else tested a GMA 3600 (the GPU that's in all Cedar Trail Atom cpus) with Mageia so far? Regards, tux99
Re: [Mageia-dev] Deprecating startx
On Wed, Mar 7, 2012 at 6:34 PM, Colin Guthrie wrote: > As I said last time to this question, I'd certainly be extremely annoyed > if mga2 does not default to systemd. I've given up a massive amount of > my free time over this cycle working towards this. I would be massively > annoyed if this effort was ultimately towards a secondary option. > > Don't worry, no one has said that it shouldn't :), but it's clear there's a confusion as you have seen, many people understood that systemd would come as an alternative to mga2 and sysvinit as default, and systemd as default in mga3. I also remember reading last year this but never the change of plans, maybe it was decided on the meetinfgs, but as I can't attend to them because of the schedule I missed the announcement. -- Juancho
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Juan Luis Baptiste at 07/03/12 22:08 did gyre and gimble: > On Wed, Mar 7, 2012 at 4:34 PM, Samuel Verschelde wrote: >> >> I apparently missed a few meetings or e-mails where this was discussed, but >> wasn't the initial plan to keep sysvinit by default in mga2 and switch to >> systemd by default in mga3? Wasn't the switch to systemd by default in >> cauldron a temporary switch in order to get more testing? >> > > Yeah, many have asked about this, if this was decided it seems this > decision wasn't announced to this list, I can't find the email talking > about this, just about ppl like you and Maarten asking when did this > change. It's my understanding that it was always the intention to default to systemd in mga2. Certainly the last couple times people have asked exactly the same question on this list, this has been confirmed. As I said last time to this question, I'd certainly be extremely annoyed if mga2 does not default to systemd. I've given up a massive amount of my free time over this cycle working towards this. I would be massively annoyed if this effort was ultimately towards a secondary option. 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] Deprecating startx
On Wed, Mar 7, 2012 at 4:34 PM, Samuel Verschelde wrote: > > I apparently missed a few meetings or e-mails where this was discussed, but > wasn't the initial plan to keep sysvinit by default in mga2 and switch to > systemd by default in mga3? Wasn't the switch to systemd by default in > cauldron a temporary switch in order to get more testing? > Yeah, many have asked about this, if this was decided it seems this decision wasn't announced to this list, I can't find the email talking about this, just about ppl like you and Maarten asking when did this change. Cheers, -- Juancho
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Samuel Verschelde at 07/03/12 21:34 did gyre and gimble: > Le mercredi 7 mars 2012 17:56:46, Thomas Backlund a écrit : >> 07.03.2012 18:20, Colin Guthrie skrev: >>> No, they will get systemd. We just need to resolve an issue with the >>> upgrade to make this happen properly (could be a urpmi bug or something >>> similar). >> >> I have now renamed sysvinit to sysvinit-legacy >> >> And both sysvinit-legacy and systemd-sysvinit provides sysvinit. >> >> And we have systemd-sysvinit in prefer.vendor.list so upgrades will now >> choose systemd by default >> > > I apparently missed a few meetings or e-mails where this was discussed, but > wasn't the initial plan to keep sysvinit by default in mga2 and switch to > systemd by default in mga3? Wasn't the switch to systemd by default in > cauldron a temporary switch in order to get more testing? Nope, this was never the case. The idea was to switch to systemd in mga2, but still support sysvinit. By mga3 we'll drop sysvinit completely. We very much want to encourage the use of systemd in this release. 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] Deprecating startx
'Twas brillig, and Thomas Backlund at 07/03/12 16:56 did gyre and gimble: > 07.03.2012 18:20, Colin Guthrie skrev: >> >> No, they will get systemd. We just need to resolve an issue with the >> upgrade to make this happen properly (could be a urpmi bug or something >> similar). > > I have now renamed sysvinit to sysvinit-legacy > > And both sysvinit-legacy and systemd-sysvinit provides sysvinit. > > And we have systemd-sysvinit in prefer.vendor.list so upgrades will now > choose systemd by default Awesome, thanks :) 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] Deprecating startx
'Twas brillig, and Thomas Backlund at 07/03/12 19:41 did gyre and gimble: > 07.03.2012 21:32, Johnny A. Solbu skrev: >> On Wednesday 07 March 2012 17:16, Colin Guthrie wrote: What should we use instead? >>> >>> A graphical login agent - i.e gdm, kdm, lxdm etc. >> >> In other words, we should no longer use runlevel 3 as default? >> There are multiuser systems where running a graphical login agent is >> undesireable, for whatever reason. >> > > No. we need runlevel 3 to work too. > > It's insane to expect to have to run any graphical stuff on servers / > routers / ... > > But for most desktop users graphical login is wanted... Exactly. multi-user.target (aka runlevel 3) is still needed for servers. There is no problem in using this mode. graphical.target (aka runlevel 5) is for users who want a graphical system, again there is no problem with this mode and it is meant to run a graphical login agent. The actual use case of using a text login and then starting X is quite small. Of course some people (like Wobo) do use this but it's definitely the exception rather than the rule. That's why it's not too much of a problem overall IMO. And like I say, this is something other distros have already done (OpenSUSE, Fedora). 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/
[Mageia-dev] ANN: libtorrent and rtorrent reverted to their stable versions
libtorrent was reverted to version 0.12.9 and rtorrent to 0.8.9 Don't forget to downgrade those if you have them on your cauldron system. Regards Samuel
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
Le mercredi 7 mars 2012 22:41:52, nicolas vigier a écrit : > On Wed, 07 Mar 2012, nicolas vigier wrote: > > On Wed, 07 Mar 2012, Samuel Verschelde wrote: > > > libtorrent and rtorrent are ready in SVN to submit. Can someone remove > > > the old packages and submit the new ones? If someone wants to > > > double-check the changes to check we did no mistake, please do too. > > > > Ok, old packages removed, and resubmitted. > > rtorrent rebuild failed : > http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/201203072 > 13440.boklm.valstar.25249/log/ ok, looks like the rewind was too far in the past. I think I fixed it, it built. Samuel
Re: [Mageia-dev] soundwrapper
'Twas brillig, and zezinho at 06/03/12 20:49 did gyre and gimble: > Le mardi 6 mars 2012 21:41:10, Thierry Vignaud a écrit : >> On 6 March 2012 18:53, Colin Guthrie wrote: Is there a simple way to check if a game uses alsa-oss modules ? >>> >>> You can tell if an application uses oss by doing: >>> sudo fuser -v /dev/dsp >> >> You don't need to be root in order to do that: >> /sbin/fuser -v /dev/dsp > > Thanks guys. So far only clanbomber needs soundwrapper, I am cleaning all > other specs. Be careful with this test, as the games might not always have /dev/dsp open (i.e. they may only use it periodically). Also, there could be problems with e.g. mmap where they might open the device and then fail to use mmap in which case they close it again. So try not to rely on this test only. Also if the open calls have been hijacked (i.e. soundwrapper has been used and is doing it's job correctly) it will likely not show up. So when testing make sure you do NOT use soundwrapper before doing your test. 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] Deprecating startx
Op woensdag 07 maart 2012 22:34:50 schreef Samuel Verschelde: [...] > I apparently missed a few meetings or e-mails where this was discussed, but > wasn't the initial plan to keep sysvinit by default in mga2 and switch to > systemd by default in mga3? Wasn't the switch to systemd by default in > cauldron a temporary switch in order to get more testing? > > Samuel that is what i originally thought too, but i guess i was mistaken
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
On Wed, 07 Mar 2012, nicolas vigier wrote: > On Wed, 07 Mar 2012, Samuel Verschelde wrote: > > > > > libtorrent and rtorrent are ready in SVN to submit. Can someone remove the > > old > > packages and submit the new ones? If someone wants to double-check the > > changes > > to check we did no mistake, please do too. > > Ok, old packages removed, and resubmitted. rtorrent rebuild failed : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120307213440.boklm.valstar.25249/log/
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
Le mercredi 7 mars 2012 22:33:19, Anssi Hannula a écrit : > 07.03.2012 23:13, Samuel Verschelde kirjoitti: > > Le mercredi 7 mars 2012 20:48:26, Remco Rijnders a écrit : > >> On Wed, Mar 07, 2012 at 08:45:49PM +0100, nicolas wrote in > >> > >> <20120307194549.gc21...@mars-attacks.org>: > >>> On Wed, 07 Mar 2012, Samuel Verschelde wrote: > Should we increase the epoch to keep ugrade path from beta, or drop > and replace the package ? > >>> > >>> epoch should be used only to fix updates on stable releases. For > >>> cauldron, users should be asked to remove and reinstall the package. > >> > >> Out of interest and as learning experience... won't the buildsystem have > >> a fit over being given an older version to build than it has in its > >> repositories already? > > > > There must be a sysadmin intervention to remove the old packages before > > submitting the new ones. > > > > libtorrent and rtorrent are ready in SVN to submit. Can someone remove > > the old packages and submit the new ones? If someone wants to > > double-check the changes to check we did no mistake, please do too. > > You added SILENT to the commit messages while this is a major change, it > doesn't make sense. > > The rpms got "+ rebuild (emptylog)" as the log instead, which is not > what happened. Indeed, remmy will fix the commit messages and then I'll submit again to fix the changelogs. Samuel
Re: [Mageia-dev] Deprecating startx
Le mercredi 7 mars 2012 17:56:46, Thomas Backlund a écrit : > 07.03.2012 18:20, Colin Guthrie skrev: > > No, they will get systemd. We just need to resolve an issue with the > > upgrade to make this happen properly (could be a urpmi bug or something > > similar). > > I have now renamed sysvinit to sysvinit-legacy > > And both sysvinit-legacy and systemd-sysvinit provides sysvinit. > > And we have systemd-sysvinit in prefer.vendor.list so upgrades will now > choose systemd by default > I apparently missed a few meetings or e-mails where this was discussed, but wasn't the initial plan to keep sysvinit by default in mga2 and switch to systemd by default in mga3? Wasn't the switch to systemd by default in cauldron a temporary switch in order to get more testing? Samuel
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
On Wed, 07 Mar 2012, Samuel Verschelde wrote: > > libtorrent and rtorrent are ready in SVN to submit. Can someone remove the > old > packages and submit the new ones? If someone wants to double-check the > changes > to check we did no mistake, please do too. Ok, old packages removed, and resubmitted.
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
07.03.2012 23:13, Samuel Verschelde kirjoitti: > Le mercredi 7 mars 2012 20:48:26, Remco Rijnders a écrit : >> On Wed, Mar 07, 2012 at 08:45:49PM +0100, nicolas wrote in >> >> <20120307194549.gc21...@mars-attacks.org>: >>> On Wed, 07 Mar 2012, Samuel Verschelde wrote: Should we increase the epoch to keep ugrade path from beta, or drop and replace the package ? >>> >>> epoch should be used only to fix updates on stable releases. For >>> cauldron, users should be asked to remove and reinstall the package. >> >> Out of interest and as learning experience... won't the buildsystem have a >> fit over being given an older version to build than it has in its >> repositories already? > > There must be a sysadmin intervention to remove the old packages before > submitting the new ones. > > libtorrent and rtorrent are ready in SVN to submit. Can someone remove the > old > packages and submit the new ones? If someone wants to double-check the > changes > to check we did no mistake, please do too. You added SILENT to the commit messages while this is a major change, it doesn't make sense. The rpms got "+ rebuild (emptylog)" as the log instead, which is not what happened. -- Anssi Hannula
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
Le mercredi 7 mars 2012 20:48:26, Remco Rijnders a écrit : > On Wed, Mar 07, 2012 at 08:45:49PM +0100, nicolas wrote in > > <20120307194549.gc21...@mars-attacks.org>: > >On Wed, 07 Mar 2012, Samuel Verschelde wrote: > >> Should we increase the epoch to keep ugrade path from beta, or drop and > >> replace the package ? > > > >epoch should be used only to fix updates on stable releases. For > >cauldron, users should be asked to remove and reinstall the package. > > Out of interest and as learning experience... won't the buildsystem have a > fit over being given an older version to build than it has in its > repositories already? There must be a sysadmin intervention to remove the old packages before submitting the new ones. libtorrent and rtorrent are ready in SVN to submit. Can someone remove the old packages and submit the new ones? If someone wants to double-check the changes to check we did no mistake, please do too. Samuel
[Mageia-dev] Release_blocker bugs
Hello, How can we (the bugsquad or other people) determinate what can be a release_blocker bug ? in the triage guide we can see: "The release_blocker priority is only relevant to bugs filed on Cauldron or beta releases, and should only be used for issues which are sufficiently critical that it would severely impair the overall quality of a release if it were made available without the issue being resolved." That is not clear for me. And the only mail relating to that, was from Anne in May and not useful for me. So what about for release blockers: An default installed soft not working out of the box ? Any soft that cannot be launched ? Issue that a lot people can have ? something other ? Comments is welcome, thanks BTW: The current one are: https://bugs.mageia.org/buglist.cgi?priority=release_blocker&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED And related to trackers (also set to release blocker) https://bugs.mageia.org/showdependencytree.cgi?id=1994&hide_resolved=1
[Mageia-dev] deprecate text installer
considering https://bugs.mageia.org/show_bug.cgi?id=4724 and that it's likely not working in cauldron for months, and also considering it's beyond our perl guru jq and our drakx-guru tv, and considering it looks like google didn't help... and considering there's 4 or 5 text-installer bugs i wanted to test out... perhaps we should consider in fact that text installer does not work... after all, if we get this fixed, there's still the other text-installer bugs... maybe it's premature for me, but considering this is version freeze... we're getting closer to the end... WDYT?
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
On Wed, Mar 07, 2012 at 08:45:49PM +0100, nicolas wrote in <20120307194549.gc21...@mars-attacks.org>: On Wed, 07 Mar 2012, Samuel Verschelde wrote: Should we increase the epoch to keep ugrade path from beta, or drop and replace the package ? epoch should be used only to fix updates on stable releases. For cauldron, users should be asked to remove and reinstall the package. Out of interest and as learning experience... won't the buildsystem have a fit over being given an older version to build than it has in its repositories already? signature.asc Description: Digital signature
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
On Wed, 07 Mar 2012, Samuel Verschelde wrote: > > Should we increase the epoch to keep ugrade path from beta, or drop and > replace the package ? epoch should be used only to fix updates on stable releases. For cauldron, users should be asked to remove and reinstall the package.
Re: [Mageia-dev] Deprecating startx
07.03.2012 21:32, Johnny A. Solbu skrev: > On Wednesday 07 March 2012 17:16, Colin Guthrie wrote: >>> What should we use instead? >> >> A graphical login agent - i.e gdm, kdm, lxdm etc. > > In other words, we should no longer use runlevel 3 as default? > There are multiuser systems where running a graphical login agent is > undesireable, for whatever reason. > No. we need runlevel 3 to work too. It's insane to expect to have to run any graphical stuff on servers / routers / ... But for most desktop users graphical login is wanted... -- Thomas
Re: [Mageia-dev] Deprecating startx
On Wednesday 07 March 2012 17:16, Colin Guthrie wrote: > > What should we use instead? > > A graphical login agent - i.e gdm, kdm, lxdm etc. In other words, we should no longer use runlevel 3 as default? There are multiuser systems where running a graphical login agent is undesireable, for whatever reason. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
Le mercredi 7 mars 2012 17:10:32, Remco Rijnders a écrit : > On Wed, Mar 07, 2012 at 05:27:26PM +0200, Anssi wrote in > > <4f577e5e.5080...@mageia.org>: > >Hi! > > > >kharec updated our libtorrent to 0.13.0 two weeks ago. Wally updated > >rtorrent shortly after that as they are released in pairs. > > > >However, 0.13.0 (and rtorrent 0.9.0) are the unstable versions, as per > >http://libtorrent.rakshasa.no/ > > > >Stable ones are 0.12.9/0.8.9. > > > >I'm in favor of reverting back to the stable versions for mga2, but I'm > >not insisting in it if other people disagree. Or is there are a specific > >reason to have the unstable ones? > > > >And what do other people think? > > > >Stormi is the rtorrent pkg maintainer. > > Hi, > > Stormi grabbed maintainership of this package at my request (as I'm his > padawan). I'm also in favour of reverting to the previous stable version > unless kharec or wally had strong movating reasons for making this > change, but I didn't see it in their commit messages, nor do I see > anything pressing on the rtorrent site after a quick glance. > > Thanks, > > Remmy Should we increase the epoch to keep ugrade path from beta, or drop and replace the package ? Samuel
Re: [Mageia-dev] Deprecating startx
07.03.2012 18:20, Colin Guthrie skrev: > > No, they will get systemd. We just need to resolve an issue with the > upgrade to make this happen properly (could be a urpmi bug or something > similar). I have now renamed sysvinit to sysvinit-legacy And both sysvinit-legacy and systemd-sysvinit provides sysvinit. And we have systemd-sysvinit in prefer.vendor.list so upgrades will now choose systemd by default -- Thomas
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-2-9.mga2
Am 07.03.2012 17:47, schrieb Guillaume Rousse: Le 07/03/2012 17:20, Oliver Burger a écrit : You can of course try to fix it, if you like. I would be happy if we could divide that monster texlive-texmf package into several smaller ones, but... It's not, that I want to have beamer inside texlive-texmf, but it already is! It's a bit difficult to fix a package that just vanished :) Ok, I'll take care of it. I think the fix will have to be in texlive-texmf to patch the beamer things out of it... Have fun!
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-2-9.mga2
Le 07/03/2012 17:20, Oliver Burger a écrit : You can of course try to fix it, if you like. I would be happy if we could divide that monster texlive-texmf package into several smaller ones, but... It's not, that I want to have beamer inside texlive-texmf, but it already is! It's a bit difficult to fix a package that just vanished :) Ok, I'll take care of it. -- BOFH excuse #27: radiosity depletion
Re: [Mageia-dev] Deprecating startx
2012/3/7 Colin Guthrie : > 'Twas brillig, and Johnny A. Solbu at 07/03/12 13:53 did gyre and gimble: >> On Wednesday 07 March 2012 10:26, Colin Guthrie wrote: >>> I think we'll have to deprecate supporting startx >> >> What should we use instead? > > A graphical login agent - i.e gdm, kdm, lxdm etc. Nice try! What do I use on a minimal netbook installation where all I have in X is an Xterm and a few applications (using mc in the xterm as "menue" and application starter? Until today I'm using startx if I want to start X on this machine (most of the time I do not use X there). This is one of the new moves I have to learn (not mentioning the tty chaos). -- wobo
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
2012/3/7 Remco Rijnders : > On Wed, Mar 07, 2012 at 05:27:26PM +0200, Anssi wrote in > <4f577e5e.5080...@mageia.org>: > >> Hi! >> >> kharec updated our libtorrent to 0.13.0 two weeks ago. Wally updated >> rtorrent shortly after that as they are released in pairs. >> >> However, 0.13.0 (and rtorrent 0.9.0) are the unstable versions, as per >> http://libtorrent.rakshasa.no/ >> >> Stable ones are 0.12.9/0.8.9. >> >> I'm in favor of reverting back to the stable versions for mga2, but I'm >> not insisting in it if other people disagree. Or is there are a specific >> reason to have the unstable ones? >> >> And what do other people think? >> >> Stormi is the rtorrent pkg maintainer. > > > Hi, > > Stormi grabbed maintainership of this package at my request (as I'm his > padawan). I'm also in favour of reverting to the previous stable version > unless kharec or wally had strong movating reasons for making this change, > but I didn't see it in their commit messages, nor do I see anything pressing > on the rtorrent site after a quick glance. I'm not against reverting to stable version. I only updated rtorrent as libtorrent was updated earlier. I did notice that new version is unstable version, but didn't think more about it as I've been using unstable version (without any problems) much longer than it's been available on our repo.
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Zézinho at 07/03/12 15:32 did gyre and gimble: > Em 07-03-2012 10:26, Colin Guthrie escreveu: >> Hi, >> >> Unless someone comes along and does a reasonable amount of coding before >> mga2, I think we'll have to deprecate supporting startx (it can still be >> used in some circumstances, but audio and accelerated graphics will not >> be available). >> >> > Now I know where the same problem with autologin comes from ;-) Kinda, but really the autologin package should do the whole pam conversation stuff itself, so it *should* be possible to make that work. > I suppose using sysvinit allows to still use startx and autologin, so I > will work at least without systemd. For the time being, we will still support sysvinit and console-kit. Using console-kit will still work (although various caveats are still present in the way that console-kit "tracks" sessions (clue: It really doesn't do any tracking at all!). > Maybe we could only add this information to the Errata, along with an > howto use sysvinit? I'd rather not. We want people to use systemd by default and while sysvinit will still limp on in mga2 it's definitely going to be a second class citizen. > If I followed things well, upgrades from MGA1 will continue using > sysvinit, so people won't get this regression on upgrades? No, they will get systemd. We just need to resolve an issue with the upgrade to make this happen properly (could be a urpmi bug or something similar). 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 task-obsolete-2-9.mga2
Am 07.03.2012 17:14, schrieb Guillaume Rousse: Le 07/03/2012 14:13, Oliver Burger a écrit : Please, don't make texlive package even bigger than its current size ( 64891300) by including everything inside. Beamer is distributed separatly, please keep it separated. It makes tracking its version and updating it easier for everybody. The functionality of beamer is already included in texlive. Indeed last time I tried - though I had no time to investigate - when beamer was installed, tex files would not compile. just because 'it is already done this way' doesn't mean it is right. What's wrong with having beamer in a distinct package ? Fact is: - it is included in texlive-texmf and - the latex-beamer package does not workj with our texlive package. You can of course try to fix it, if you like. I would be happy if we could divide that monster texlive-texmf package into several smaller ones, but... It's not, that I want to have beamer inside texlive-texmf, but it already is! Oliver
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Johnny A. Solbu at 07/03/12 13:53 did gyre and gimble: > On Wednesday 07 March 2012 10:26, Colin Guthrie wrote: >> I think we'll have to deprecate supporting startx > > What should we use instead? A graphical login agent - i.e gdm, kdm, lxdm etc. 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 task-obsolete-2-9.mga2
Le 07/03/2012 14:13, Oliver Burger a écrit : Please, don't make texlive package even bigger than its current size ( 64891300) by including everything inside. Beamer is distributed separatly, please keep it separated. It makes tracking its version and updating it easier for everybody. The functionality of beamer is already included in texlive. Indeed last time I tried - though I had no time to investigate - when beamer was installed, tex files would not compile. just because 'it is already done this way' doesn't mean it is right. What's wrong with having beamer in a distinct package ? -- BOFH excuse #330: quantum decoherence
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
On Wed, Mar 07, 2012 at 05:27:26PM +0200, Anssi wrote in <4f577e5e.5080...@mageia.org>: Hi! kharec updated our libtorrent to 0.13.0 two weeks ago. Wally updated rtorrent shortly after that as they are released in pairs. However, 0.13.0 (and rtorrent 0.9.0) are the unstable versions, as per http://libtorrent.rakshasa.no/ Stable ones are 0.12.9/0.8.9. I'm in favor of reverting back to the stable versions for mga2, but I'm not insisting in it if other people disagree. Or is there are a specific reason to have the unstable ones? And what do other people think? Stormi is the rtorrent pkg maintainer. Hi, Stormi grabbed maintainership of this package at my request (as I'm his padawan). I'm also in favour of reverting to the previous stable version unless kharec or wally had strong movating reasons for making this change, but I didn't see it in their commit messages, nor do I see anything pressing on the rtorrent site after a quick glance. Thanks, Remmy signature.asc Description: Digital signature
Re: [Mageia-dev] Deprecating startx
2012/3/7 Zézinho : > Em 07-03-2012 10:26, Colin Guthrie escreveu: >> >> Hi, >> >> Unless someone comes along and does a reasonable amount of coding before >> mga2, I think we'll have to deprecate supporting startx (it can still be >> used in some circumstances, but audio and accelerated graphics will not >> be available). >> >> > Now I know where the same problem with autologin comes from ;-) > > I suppose using sysvinit allows to still use startx and autologin, so I will > work at least without systemd. > Maybe we could only add this information to the Errata, along with an howto > use sysvinit? > > If I followed things well, upgrades from MGA1 will continue using sysvinit, > so people won't get this regression on upgrades? Would it not be counterproductive, having 2 very different types of systems with lots of different possible causes for problems? -- wobo
Re: [Mageia-dev] libtorrent / rtorrent versions, revert to stable?
On Wed, 07 Mar 2012, Anssi Hannula wrote: > Hi! > > kharec updated our libtorrent to 0.13.0 two weeks ago. Wally updated > rtorrent shortly after that as they are released in pairs. > > However, 0.13.0 (and rtorrent 0.9.0) are the unstable versions, as per > http://libtorrent.rakshasa.no/ > > Stable ones are 0.12.9/0.8.9. > > I'm in favor of reverting back to the stable versions for mga2, but I'm > not insisting in it if other people disagree. Or is there are a specific > reason to have the unstable ones? > > And what do other people think? I also think we should revert to stable version. Unless there is a good reason to have the unstable one.
Re: [Mageia-dev] Gtk+3.0 bindings API break, what to do?
06.03.2012 20:34, Anssi Hannula kirjoitti: > Hi! > > As per https://bugzilla.gnome.org/show_bug.cgi?id=657385 > gtk_menu_popup_for_device() has been renamed to gtk_menu_popup() in > introspection, causing at least Menu.popup() in python-gi to break. > > Ubuntu has reverted it: > https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/923171 > > Attached are alternative one-liner patches to either revert the API > break in Gtk+3.0 (dont_rename_annotation.patch, from Ubuntu), or to > adapt python-gobject3 to the API change > (python-gi-adapt-for-gnome657385.patch, written by me). > > Since gtk+3.0 is unmaintained, I'm posting here to ask which way to go. For now I've patched python-gobject3. More GTK+3-knowledged people can feel free to revert it and use the other solution if they so wish... > This affects e.g. gcdemu, right-clicking the traybar icon causes this error: > Traceback (most recent call last): > File "/usr/bin/gcdemu", line 688, in on_popup_menu > self.menu.popup(None, None, status_icon.position_menu, self, button, > activate_time) > File "/usr/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line > 1381, in popup > self.popup_for_device(None, parent_menu_shell, parent_menu_item, > func, data, button, activate_time) > AttributeError: 'Menu' object has no attribute 'popup_for_device' > > -- Anssi Hannula
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lxdm-0.4.1-8.mga2
2012/3/7 wally : > Name : lxdm Relocations: (not relocatable) > Version : 0.4.1 Vendor: Mageia.Org > Release : 8.mga2 Build Date: Wed Mar 7 16:09:29 > 2012 > Install Date: (not installed) Build Host: ecosse.mageia.org > Group : Graphical desktop/Other Source RPM: (none) > Size : 304301 License: GPLv2+ > Signature : (none) > Packager : wally > URL : http://www.lxde.org > Summary : GUI login manager for LXDE > Description : > A lightweight dropped-in replacement for GDM or KDM. > > wally 0.4.1-8.mga2: > + Revision: 221103 > - add patch to source /etc/profile and/or ~/.profile instead of xprofile > ones when starting session to get more working > /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/games:/usr/lib/qt4/bin:/home/wally/.bin:/sbin:/usr/sbin > for desktop environment SVN commit msg is already propedited, so the %changelog should be OK when lxdm is build next time.
Re: [Mageia-dev] Deprecating startx
Em 07-03-2012 10:26, Colin Guthrie escreveu: Hi, Unless someone comes along and does a reasonable amount of coding before mga2, I think we'll have to deprecate supporting startx (it can still be used in some circumstances, but audio and accelerated graphics will not be available). Now I know where the same problem with autologin comes from ;-) I suppose using sysvinit allows to still use startx and autologin, so I will work at least without systemd. Maybe we could only add this information to the Errata, along with an howto use sysvinit? If I followed things well, upgrades from MGA1 will continue using sysvinit, so people won't get this regression on upgrades?
[Mageia-dev] libtorrent / rtorrent versions, revert to stable?
Hi! kharec updated our libtorrent to 0.13.0 two weeks ago. Wally updated rtorrent shortly after that as they are released in pairs. However, 0.13.0 (and rtorrent 0.9.0) are the unstable versions, as per http://libtorrent.rakshasa.no/ Stable ones are 0.12.9/0.8.9. I'm in favor of reverting back to the stable versions for mga2, but I'm not insisting in it if other people disagree. Or is there are a specific reason to have the unstable ones? And what do other people think? Stormi is the rtorrent pkg maintainer. -- Anssi Hannula
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Shlomi Fish at 07/03/12 14:09 did gyre and gimble: > Hello Colin, > > On Wed, 07 Mar 2012 11:15:29 + > Colin Guthrie wrote: > >> 'Twas brillig, and Wolfgang Bornath at 07/03/12 10:13 did gyre and gimble: >>> 2012/3/7 Guillaume Rousse : Le 07/03/2012 10:26, Colin Guthrie a écrit : > > Hi, > > Unless someone comes along and does a reasonable amount of coding before > mga2, I think we'll have to deprecate supporting startx (it can still be > used in some circumstances, but audio and accelerated graphics will not > be available). > > See this comment (and the link therein) for more info on the issue: > https://bugs.mageia.org/show_bug.cgi?id=4652#c9 What is the operational translation of 'deprecating support of foo' ? automatic answer "no support" to any user reporting issue with it ? removing it from the distribution ? While I don't care about the first one, I do care about the second interpretation. Given the very high fragility of the gnome environment nowadays, using old-days tools to workaround those various issues is frequently useful. >>> >>> Different from Guillaume I do care about the impact for the user. >>> There are many out there who are used to startx and also docs and >>> howtos which use it. Therefore we will need an explanation for >>> switching off startx. An explanation to be used in forums, which is a >>> bit more than just a link to a bug report. In other words: to be >>> understood by non-techie users. >> >> To answer Guillaume's question, I wasn't personally planning on removing >> it fully. Just documenting that it is broken and that users should not >> use this as a mechanism for starting X. >> >> I would propose just putting in "echo 'startx is deprecated. Here is >> why. Press any key to continue anyway.' >&2; read -n 1" in the >> startx script such that users using it will be warned. Does this seem >> sensible? > > Having to press this every time will drive me nuts. If you are going to do it, > please also use an optional environment variable to trigger it off. Env var or a switch to pass to it (and you could then put alias startx='startx --no-session-warning' or similar in your bashrc? Thinking about this, it might make more sense to warn the user AFTER they have logged in... e.g. via zenity or knotify or similar. But again with the option to hide it still) > Luckily for me (and for Mageia) I am a programmer and can write the required > code to make startx play nice with the rest of systemd again. I'll read the > URL > of the bug and see what is needed and hopefully with some guidance from the > people on Freenode, will make it work. If anyone wants to help, I'm "rindolf" > there and I'm also reachable by other forms of IM and by other means: It would be nice if you wanted to take on this project. Basically you'd be writing a DM (like gdm) which is able to talk to PAM and do all those things needed for proper session management. Of course your DM would be very much cut down - i.e. it would not actually have any UI, but just implement and autologin system. I'd imagine how it would work is that your program would be installed as setuid, thus regular users can run it, it can find the username who run it and store that, then call the necessary commands to gain root privileges, do the whole pam conversation and then login the user. This will require a specific PAM config (e.g. /etc/pam.d/startx) to allow passwordless authentication for your user. This is just a very rough overview of what would be needed. Good luck :) 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] Deprecating startx
Hello Colin, On Wed, 07 Mar 2012 11:15:29 + Colin Guthrie wrote: > 'Twas brillig, and Wolfgang Bornath at 07/03/12 10:13 did gyre and gimble: > > 2012/3/7 Guillaume Rousse : > >> Le 07/03/2012 10:26, Colin Guthrie a écrit : > >>> > >>> Hi, > >>> > >>> Unless someone comes along and does a reasonable amount of coding before > >>> mga2, I think we'll have to deprecate supporting startx (it can still be > >>> used in some circumstances, but audio and accelerated graphics will not > >>> be available). > >>> > >>> See this comment (and the link therein) for more info on the issue: > >>> https://bugs.mageia.org/show_bug.cgi?id=4652#c9 > >> > >> What is the operational translation of 'deprecating support of foo' ? > >> automatic answer "no support" to any user reporting issue with it ? > >> removing > >> it from the distribution ? > >> > >> While I don't care about the first one, I do care about the second > >> interpretation. Given the very high fragility of the gnome environment > >> nowadays, using old-days tools to workaround those various issues is > >> frequently useful. > > > > Different from Guillaume I do care about the impact for the user. > > There are many out there who are used to startx and also docs and > > howtos which use it. Therefore we will need an explanation for > > switching off startx. An explanation to be used in forums, which is a > > bit more than just a link to a bug report. In other words: to be > > understood by non-techie users. > > To answer Guillaume's question, I wasn't personally planning on removing > it fully. Just documenting that it is broken and that users should not > use this as a mechanism for starting X. > > I would propose just putting in "echo 'startx is deprecated. Here is > why. Press any key to continue anyway.' >&2; read -n 1" in the > startx script such that users using it will be warned. Does this seem > sensible? Having to press this every time will drive me nuts. If you are going to do it, please also use an optional environment variable to trigger it off. In any case, as an active user of startx, I do not appreciate the fact that it will get deprecated. I don't like to start X automatically on startup because that causes problem if there is problem with the X environment in general, or with the graphics' driver etc. I tried starting up kdm from the command line but could only start it as root, and it returned to the login screen after I exited X (which is expected, but undesirable), and could only be killed by root. Luckily for me (and for Mageia) I am a programmer and can write the required code to make startx play nice with the rest of systemd again. I'll read the URL of the bug and see what is needed and hopefully with some guidance from the people on Freenode, will make it work. If anyone wants to help, I'm "rindolf" there and I'm also reachable by other forms of IM and by other means: http://www.shlomifish.org/me/contact-me/ Regards, Shlomi Fish (who is frustrated at the amount of problems the transition to systemd has caused). -- - Shlomi Fish http://www.shlomifish.org/ Free (Creative Commons) Music Downloads, Reviews and more - http://jamendo.com/ I hope that you agree with me that 99.9218485921% of the users wouldn’t bother themselves with recompilation (or any other manual step for that matter) to make their games run 1.27127529900685765% faster ;-) — Nadav Har’El Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release p-uae-2.3.3-0.20120229git.1.mga2
Am 07.03.2012 12:05, schrieb Thierry Vignaud: On 7 March 2012 11:15, obgr_seneca wrote: [This is in an unofficial branch of UAE (the Ubiquitous Amiga Emulator) with the aim of bringing the features of WinUAE to non-Windows platforms such as Linux, Mac OS X and BeOS.] I think this has nothing to do in %description It's pretty obvious a Mageia RPM is targetting non Windows... It's an information, that this branch of uae is bringing features from WinUAE to non windows platforms. It's not saying, that this package is for non windows platforms, which really would be superfluous to say. Oliver
Re: [Mageia-dev] Deprecating startx
On Wednesday 07 March 2012 10:26, Colin Guthrie wrote: > I think we'll have to deprecate supporting startx What should we use instead? -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Deprecating startx
2012/3/7 Colin Guthrie : > 'Twas brillig, and Wolfgang Bornath at 07/03/12 12:02 did gyre and gimble: >> 2012/3/7 Colin Guthrie : >>> 'Twas brillig, and Wolfgang Bornath at 07/03/12 10:13 did gyre and gimble: Different from Guillaume I do care about the impact for the user. There are many out there who are used to startx and also docs and howtos which use it. Therefore we will need an explanation for switching off startx. An explanation to be used in forums, which is a bit more than just a link to a bug report. In other words: to be understood by non-techie users. >>> >>> To answer Guillaume's question, I wasn't personally planning on removing >>> it fully. Just documenting that it is broken and that users should not >>> use this as a mechanism for starting X. >>> >>> I would propose just putting in "echo 'startx is deprecated. Here is >>> why. Press any key to continue anyway.' >&2; read -n 1" in the >>> startx script such that users using it will be warned. Does this seem >>> sensible? >> >> It is sensible and enough for the situation at hand (when the user >> actually punches in "startx" and the command does not work as >> expected). In principle on the same level of information like "file >> not found". That's all which is needed from the technical side. >> >> People more close to the users will have to think of an explanation >> without tech-talk, understandable for the user who comes to the forum >> complaining that the command he had been using for many years (or >> which is written in a documentation) does not work. > > For the avoidance of doubt, I would expect that hitting return would > still end up starting X, just that the afore mentioned (and dutifully > explained to the user) problems with ACLs etc. will be present. > > I'll be able to write some text here that is concise, so I'll do this > shortly. Great! Now I'll have to teach this waltzing greybeard in the mirror some new moves :) -- wobo
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Wolfgang Bornath at 07/03/12 12:02 did gyre and gimble: > 2012/3/7 Colin Guthrie : >> 'Twas brillig, and Wolfgang Bornath at 07/03/12 10:13 did gyre and gimble: >>> >>> Different from Guillaume I do care about the impact for the user. >>> There are many out there who are used to startx and also docs and >>> howtos which use it. Therefore we will need an explanation for >>> switching off startx. An explanation to be used in forums, which is a >>> bit more than just a link to a bug report. In other words: to be >>> understood by non-techie users. >> >> To answer Guillaume's question, I wasn't personally planning on removing >> it fully. Just documenting that it is broken and that users should not >> use this as a mechanism for starting X. >> >> I would propose just putting in "echo 'startx is deprecated. Here is >> why. Press any key to continue anyway.' >&2; read -n 1" in the >> startx script such that users using it will be warned. Does this seem >> sensible? > > It is sensible and enough for the situation at hand (when the user > actually punches in "startx" and the command does not work as > expected). In principle on the same level of information like "file > not found". That's all which is needed from the technical side. > > People more close to the users will have to think of an explanation > without tech-talk, understandable for the user who comes to the forum > complaining that the command he had been using for many years (or > which is written in a documentation) does not work. For the avoidance of doubt, I would expect that hitting return would still end up starting X, just that the afore mentioned (and dutifully explained to the user) problems with ACLs etc. will be present. I'll be able to write some text here that is concise, so I'll do this shortly. 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 task-obsolete-2-9.mga2
Am 07.03.2012 13:05, schrieb Guillaume Rousse: Le 07/03/2012 12:03, Oliver Burger a écrit : Am 07.03.2012 11:59, schrieb Thomas Backlund: Claire REVILLET skrev 7.3.2012 12:27: Le 07/03/2012 11:21, obgr_seneca a écrit : Name : task-obsolete Relocations: (not relocatable) Version : 2 Vendor: Mageia.Org Release : 9.mga2 Build Date: Wed Mar 7 11:16:10 2012 Install Date: (not installed) Build Host: jonund.mageia.org Group : System/Base Source RPM: (none) Size : 3392 License: GPLv2+ Signature : (none) Packager : obgr_seneca Summary : Meta package obsoleting old packages Description : This package is used to obsolete packages that are no longer supported. obgr_seneca 2-9.mga2: + Revision: 220919 - obsolte latex-beamer since the functionality is part of texlive What about the documentation and all examples ? they were only in latex-beamer package. Maybe changing late-beamer into latex-beamer-doc will be better than obsoletting it. wdyt ? Not to mention.. if texlive has the functionality of -beamer, that package should obsolete this, not task-obsolete -- Yes, you are right. Sorry. I will work on a latex-beamer-doc package then. Please, don't make texlive package even bigger than its current size ( 64891300) by including everything inside. Beamer is distributed separatly, please keep it separated. It makes tracking its version and updating it easier for everybody. The functionality of beamer is already included in texlive. Indeed last time I tried - though I had no time to investigate - when beamer was installed, tex files would not compile. Oliver
[Mageia-dev] Packagers meeting
Hi there Last run before version freeze! Topics for tonight: - Organize version freeze (packagers) - reminder - Organize freeze with other teams - Beta 2 release - Mentoring progress Version freeze will be activated at the end of this meeting Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-2-9.mga2
Le 07/03/2012 12:03, Oliver Burger a écrit : Am 07.03.2012 11:59, schrieb Thomas Backlund: Claire REVILLET skrev 7.3.2012 12:27: Le 07/03/2012 11:21, obgr_seneca a écrit : Name : task-obsolete Relocations: (not relocatable) Version : 2 Vendor: Mageia.Org Release : 9.mga2 Build Date: Wed Mar 7 11:16:10 2012 Install Date: (not installed) Build Host: jonund.mageia.org Group : System/Base Source RPM: (none) Size : 3392 License: GPLv2+ Signature : (none) Packager : obgr_seneca Summary : Meta package obsoleting old packages Description : This package is used to obsolete packages that are no longer supported. obgr_seneca 2-9.mga2: + Revision: 220919 - obsolte latex-beamer since the functionality is part of texlive What about the documentation and all examples ? they were only in latex-beamer package. Maybe changing late-beamer into latex-beamer-doc will be better than obsoletting it. wdyt ? Not to mention.. if texlive has the functionality of -beamer, that package should obsolete this, not task-obsolete -- Yes, you are right. Sorry. I will work on a latex-beamer-doc package then. Please, don't make texlive package even bigger than its current size ( 64891300) by including everything inside. Beamer is distributed separatly, please keep it separated. It makes tracking its version and updating it easier for everybody. -- If all the cars are coming your way -- you're probably going the wrong way on a one-way street -- Murphy's Driving Laws n°9
Re: [Mageia-dev] Deprecating startx
2012/3/7 Colin Guthrie : > 'Twas brillig, and Wolfgang Bornath at 07/03/12 10:13 did gyre and gimble: >> >> Different from Guillaume I do care about the impact for the user. >> There are many out there who are used to startx and also docs and >> howtos which use it. Therefore we will need an explanation for >> switching off startx. An explanation to be used in forums, which is a >> bit more than just a link to a bug report. In other words: to be >> understood by non-techie users. > > To answer Guillaume's question, I wasn't personally planning on removing > it fully. Just documenting that it is broken and that users should not > use this as a mechanism for starting X. > > I would propose just putting in "echo 'startx is deprecated. Here is > why. Press any key to continue anyway.' >&2; read -n 1" in the > startx script such that users using it will be warned. Does this seem > sensible? It is sensible and enough for the situation at hand (when the user actually punches in "startx" and the command does not work as expected). In principle on the same level of information like "file not found". That's all which is needed from the technical side. People more close to the users will have to think of an explanation without tech-talk, understandable for the user who comes to the forum complaining that the command he had been using for many years (or which is written in a documentation) does not work. -- wobo
Re: [Mageia-dev] Deprecating startx
On 07/03/12 12:12, Colin Guthrie wrote: You can still debug X but only for an actual X server. Anyway even when I was maintaining X a few years back, I don't think I ever started it from the text console. I always used the official methods for starting X (service dm restart in those days). So not sure it's really all that needed for debugging. Thanks for the explanations. If this is a matter of ACL only, I would let startx existing even of sound or acceleration is not working. I also remember mandriva times for which the dm was not working. Or simple than that, when hald was switched off and autoadddevice=false, startx was usefull to open a X session. Cheers, Chris.
Re: [Mageia-dev] Deprecating startx
'Twas brillig, and Wolfgang Bornath at 07/03/12 10:13 did gyre and gimble: > 2012/3/7 Guillaume Rousse : >> Le 07/03/2012 10:26, Colin Guthrie a écrit : >>> >>> Hi, >>> >>> Unless someone comes along and does a reasonable amount of coding before >>> mga2, I think we'll have to deprecate supporting startx (it can still be >>> used in some circumstances, but audio and accelerated graphics will not >>> be available). >>> >>> See this comment (and the link therein) for more info on the issue: >>> https://bugs.mageia.org/show_bug.cgi?id=4652#c9 >> >> What is the operational translation of 'deprecating support of foo' ? >> automatic answer "no support" to any user reporting issue with it ? removing >> it from the distribution ? >> >> While I don't care about the first one, I do care about the second >> interpretation. Given the very high fragility of the gnome environment >> nowadays, using old-days tools to workaround those various issues is >> frequently useful. > > Different from Guillaume I do care about the impact for the user. > There are many out there who are used to startx and also docs and > howtos which use it. Therefore we will need an explanation for > switching off startx. An explanation to be used in forums, which is a > bit more than just a link to a bug report. In other words: to be > understood by non-techie users. To answer Guillaume's question, I wasn't personally planning on removing it fully. Just documenting that it is broken and that users should not use this as a mechanism for starting X. I would propose just putting in "echo 'startx is deprecated. Here is why. Press any key to continue anyway.' >&2; read -n 1" in the startx script such that users using it will be warned. Does this seem sensible? 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] Deprecating startx
'Twas brillig, and EatDirt at 07/03/12 10:18 did gyre and gimble: > On 07/03/12 10:26, Colin Guthrie wrote: >> Hi, >> >> Unless someone comes along and does a reasonable amount of coding before >> mga2, I think we'll have to deprecate supporting startx (it can still be >> used in some circumstances, but audio and accelerated graphics will not >> be available). >> >> See this comment (and the link therein) for more info on the issue: >> https://bugs.mageia.org/show_bug.cgi?id=4652#c9 > > > Hi there, > as many, I don't understand (yet, it not ever) systemd :) > But what do you mean? systemd tracks and manages user sessions. i.e. it takes over the role of console-kit which had many design flaws and generally makes a good job of managing sessions properly without any nasty hacks or work arounds. > An user could no longer starts in runlevel 3 and start an X session > directly ? This is the way we actually debug X, that sounds very > unreasonable to me. Users can still technically run startx, but the user session will not be seen as active and thus all sorts of things break with regards to setting ACLs on device nodes - e.g. on /dev/snd/* /dev/dri/* etc. Other things relating to session management will also likely break. You can still debug X but only for an actual X server. Anyway even when I was maintaining X a few years back, I don't think I ever started it from the text console. I always used the official methods for starting X (service dm restart in those days). So not sure it's really all that needed for debugging. 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 p-uae-2.3.3-0.20120229git.1.mga2
On 7 March 2012 11:15, obgr_seneca wrote: > [This is in an unofficial branch of UAE (the Ubiquitous Amiga Emulator) > with the aim of bringing the features of WinUAE to non-Windows platforms > such as Linux, Mac OS X and BeOS.] I think this has nothing to do in %description It's pretty obvious a Mageia RPM is targetting non Windows...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-2-9.mga2
Am 07.03.2012 11:59, schrieb Thomas Backlund: Claire REVILLET skrev 7.3.2012 12:27: Le 07/03/2012 11:21, obgr_seneca a écrit : Name : task-obsolete Relocations: (not relocatable) Version : 2 Vendor: Mageia.Org Release : 9.mga2 Build Date: Wed Mar 7 11:16:10 2012 Install Date: (not installed) Build Host: jonund.mageia.org Group : System/Base Source RPM: (none) Size : 3392 License: GPLv2+ Signature : (none) Packager : obgr_seneca Summary : Meta package obsoleting old packages Description : This package is used to obsolete packages that are no longer supported. obgr_seneca 2-9.mga2: + Revision: 220919 - obsolte latex-beamer since the functionality is part of texlive What about the documentation and all examples ? they were only in latex-beamer package. Maybe changing late-beamer into latex-beamer-doc will be better than obsoletting it. wdyt ? Not to mention.. if texlive has the functionality of -beamer, that package should obsolete this, not task-obsolete -- Yes, you are right. Sorry. I will work on a latex-beamer-doc package then. Oliver
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-2-9.mga2
Claire REVILLET skrev 7.3.2012 12:27: Le 07/03/2012 11:21, obgr_seneca a écrit : Name: task-obsoleteRelocations: (not relocatable) Version : 2 Vendor: Mageia.Org Release : 9.mga2Build Date: Wed Mar 7 11:16:10 2012 Install Date: (not installed) Build Host: jonund.mageia.org Group : System/Base Source RPM: (none) Size: 3392 License: GPLv2+ Signature : (none) Packager: obgr_seneca Summary : Meta package obsoleting old packages Description : This package is used to obsolete packages that are no longer supported. obgr_seneca 2-9.mga2: + Revision: 220919 - obsolte latex-beamer since the functionality is part of texlive What about the documentation and all examples ? they were only in latex-beamer package. Maybe changing late-beamer into latex-beamer-doc will be better than obsoletting it. wdyt ? Not to mention.. if texlive has the functionality of -beamer, that package should obsolete this, not task-obsolete -- Thomas
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-2-9.mga2
On Wed, Mar 7, 2012 at 10:21, obgr_seneca wrote: > Name : task-obsolete Relocations: (not relocatable) > Version : 2 Vendor: Mageia.Org > Release : 9.mga2 Build Date: Wed Mar 7 11:16:10 > 2012 > Install Date: (not installed) Build Host: jonund.mageia.org > Group : System/Base Source RPM: (none) > Size : 3392 License: GPLv2+ > Signature : (none) > Packager : obgr_seneca > Summary : Meta package obsoleting old packages > Description : > This package is used to obsolete packages that are no longer supported. > > obgr_seneca 2-9.mga2: > + Revision: 220919 > - obsolte latex-beamer since the functionality is part of texlive Then it should be obsoleted by texlive. task-obsolete is for old packages not replaced by anything.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-2-9.mga2
Le 07/03/2012 11:21, obgr_seneca a écrit : Name: task-obsoleteRelocations: (not relocatable) Version : 2 Vendor: Mageia.Org Release : 9.mga2Build Date: Wed Mar 7 11:16:10 2012 Install Date: (not installed) Build Host: jonund.mageia.org Group : System/Base Source RPM: (none) Size: 3392 License: GPLv2+ Signature : (none) Packager: obgr_seneca Summary : Meta package obsoleting old packages Description : This package is used to obsolete packages that are no longer supported. obgr_seneca 2-9.mga2: + Revision: 220919 - obsolte latex-beamer since the functionality is part of texlive What about the documentation and all examples ? they were only in latex-beamer package. Maybe changing late-beamer into latex-beamer-doc will be better than obsoletting it. wdyt ? Claire
Re: [Mageia-dev] Deprecating startx
On 07/03/12 10:26, Colin Guthrie wrote: Hi, Unless someone comes along and does a reasonable amount of coding before mga2, I think we'll have to deprecate supporting startx (it can still be used in some circumstances, but audio and accelerated graphics will not be available). See this comment (and the link therein) for more info on the issue: https://bugs.mageia.org/show_bug.cgi?id=4652#c9 Hi there, as many, I don't understand (yet, it not ever) systemd :) But what do you mean? An user could no longer starts in runlevel 3 and start an X session directly ? This is the way we actually debug X, that sounds very unreasonable to me. Cheers, Chris.
Re: [Mageia-dev] Deprecating startx
2012/3/7 Guillaume Rousse : > Le 07/03/2012 10:26, Colin Guthrie a écrit : >> >> Hi, >> >> Unless someone comes along and does a reasonable amount of coding before >> mga2, I think we'll have to deprecate supporting startx (it can still be >> used in some circumstances, but audio and accelerated graphics will not >> be available). >> >> See this comment (and the link therein) for more info on the issue: >> https://bugs.mageia.org/show_bug.cgi?id=4652#c9 > > What is the operational translation of 'deprecating support of foo' ? > automatic answer "no support" to any user reporting issue with it ? removing > it from the distribution ? > > While I don't care about the first one, I do care about the second > interpretation. Given the very high fragility of the gnome environment > nowadays, using old-days tools to workaround those various issues is > frequently useful. Different from Guillaume I do care about the impact for the user. There are many out there who are used to startx and also docs and howtos which use it. Therefore we will need an explanation for switching off startx. An explanation to be used in forums, which is a bit more than just a link to a bug report. In other words: to be understood by non-techie users. -- wobo
Re: [Mageia-dev] Deprecating startx
Am 07.03.2012 11:05, schrieb Guillaume Rousse: Le 07/03/2012 10:26, Colin Guthrie a écrit : Hi, Unless someone comes along and does a reasonable amount of coding before mga2, I think we'll have to deprecate supporting startx (it can still be used in some circumstances, but audio and accelerated graphics will not be available). See this comment (and the link therein) for more info on the issue: https://bugs.mageia.org/show_bug.cgi?id=4652#c9 What is the operational translation of 'deprecating support of foo' ? automatic answer "no support" to any user reporting issue with it ? removing it from the distribution ? While I don't care about the first one, I do care about the second interpretation. Given the very high fragility of the gnome environment nowadays, using old-days tools to workaround those various issues is frequently useful. Well, deprecating something usually means: "it's still there, but will be removed somewhen in the future. So find something else..." Doesn't it? Oliver
Re: [Mageia-dev] Deprecating startx
On 7 March 2012 11:05, Guillaume Rousse wrote: >> Unless someone comes along and does a reasonable amount of coding before >> mga2, I think we'll have to deprecate supporting startx (it can still be >> used in some circumstances, but audio and accelerated graphics will not >> be available). >> >> See this comment (and the link therein) for more info on the issue: >> https://bugs.mageia.org/show_bug.cgi?id=4652#c9 > > What is the operational translation of 'deprecating support of foo' ? > automatic answer "no support" to any user reporting issue with it ? removing > it from the distribution ? > > While I don't care about the first one, I do care about the second > interpretation. Given the very high fragility of the gnome environment > nowadays, using old-days tools to workaround those various issues is > frequently useful. Indeed. I don't care about a few missing ACLs that I can workaround. startx isn't for beginners anyway...
Re: [Mageia-dev] Deprecating startx
Le 07/03/2012 10:26, Colin Guthrie a écrit : Hi, Unless someone comes along and does a reasonable amount of coding before mga2, I think we'll have to deprecate supporting startx (it can still be used in some circumstances, but audio and accelerated graphics will not be available). See this comment (and the link therein) for more info on the issue: https://bugs.mageia.org/show_bug.cgi?id=4652#c9 What is the operational translation of 'deprecating support of foo' ? automatic answer "no support" to any user reporting issue with it ? removing it from the distribution ? While I don't care about the first one, I do care about the second interpretation. Given the very high fragility of the gnome environment nowadays, using old-days tools to workaround those various issues is frequently useful. -- Radios will fail as soon as you need fire support -- Murphy's Military Laws n°71
[Mageia-dev] Deprecating startx
Hi, Unless someone comes along and does a reasonable amount of coding before mga2, I think we'll have to deprecate supporting startx (it can still be used in some circumstances, but audio and accelerated graphics will not be available). See this comment (and the link therein) for more info on the issue: https://bugs.mageia.org/show_bug.cgi?id=4652#c9 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] soundwrapper
On 7 March 2012 00:13, Colin Guthrie wrote: Is there a simple way to check if a game uses alsa-oss modules ? >>> >>> You can tell if an application uses oss by doing: >>> sudo fuser -v /dev/dsp >> >> You don't need to be root in order to do that: >> /sbin/fuser -v /dev/dsp > > Hmm... but I think it only shows pid if it's another user... which is > why I always suggest sudo - mpd running as mpd user is a common cause of > the hogging and thus it's nice to see that rather than a number. For /dev/snd/*, it always worked the same way for me but Indeed I've nothing using the sound card as root, in which case it's hidden. Also one can use "sudo lsof /dev/snd/*"
Re: [Mageia-dev] Build system bugs
On Wed, Mar 7, 2012 at 03:12, Funda Wang wrote: > Well, here it is: > > http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120307030202.fwang.valstar.13118/log/kdenetwork4-4.8.1-1.mga2/install_deps-2.0.20120307030203.log Thanks, I uploaded the missing packages. It is the exact bug that should have been fixed by my change yesterday :(
