Re: [Mageia-dev] [RPM] cauldron core/release meta-task-1-14.mga1
Thierry Vignaud writes: > On 28 March 2011 05:01, Mageia Team wrote: >> blino 1:1-14.mga1: >> + Revision: 78203 >> - remove duplicate package entries (it breaks clean-rpmsrate), by removing >> META_CLASS check > > was it not caught by check_rpmsrate which is supposed to be run in %check? Nope, it wasn't. check_rpmsrate only uses DrakX's rpmsrate parser, not mkcd's one which is stricter (and used by the final clean-rpmsrate) -- Olivier Blin - blino
[Mageia-dev] Tainted Software - once more
Hi, since the package version freeze is coming nearer (April, 20th), perhaps we should discuss the "tainted" issue once more. What is our policy about "tainted packages"? It's quite clear we have to check every one of them, if they can be distributed by us, but do we have any guidlines? What about packages, we need twice, once in core, once in tainted (media player come to mind)? Will the buildsystem be able to create both out of one single src.rpm? If not, how else to do it? Oliver
Re: [Mageia-dev] [RPM] cauldron core/release meta-task-1-14.mga1
On Mon, Mar 28, 2011 at 10:06:17AM +0200, Olivier Blin wrote: > Thierry Vignaud writes: > > > On 28 March 2011 05:01, Mageia Team wrote: > >> blino 1:1-14.mga1: > >> + Revision: 78203 > >> - remove duplicate package entries (it breaks clean-rpmsrate), by removing > >> META_CLASS check > > > > was it not caught by check_rpmsrate which is supposed to be run in %check? > > Nope, it wasn't. > check_rpmsrate only uses DrakX's rpmsrate parser, not mkcd's one which > is stricter (and used by the final clean-rpmsrate) is there a reason to have 2 parsers ? -- Michael Scherer
Re: [Mageia-dev] [RPM] cauldron core/release poppler-0.16.3-3.mga1
On 28 March 2011 10:14, Mageia Team wrote: > blino 0.16.3-3.mga1: > + Revision: 78257 > - add back conflicts, needed because of girepository-1.0/Poppler-0.16.typelib Then fix installation on a biarch machine...
Re: [Mageia-dev] [RPM] cauldron core/release meta-task-1-14.mga1
On 28 March 2011 10:32, Michael scherer wrote: >> >> - remove duplicate package entries (it breaks clean-rpmsrate), by >> >> removing META_CLASS check >> > >> > was it not caught by check_rpmsrate which is supposed to be run in %check? >> >> Nope, it wasn't. >> check_rpmsrate only uses DrakX's rpmsrate parser, not mkcd's one which >> is stricter (and used by the final clean-rpmsrate) > > is there a reason to have 2 parsers ? We'd a forker in the team :-)
Re: [Mageia-dev] Tainted Software - once more
On Mon, Mar 28, 2011 at 10:17, Oliver Burger wrote: > What is our policy about "tainted packages"? It's quite clear we have to check > every one of them, if they can be distributed by us, but do we have any > guidlines? The guidelines should be progressive: what goes into core, what goes into nonfree, what goes into tainted, and the rest (if there is). I guess that's what's needed? As for guidelines regarding tainted, there's this draft relative to sw patents that did not make a lot of progress so far: http://mageia.org/wiki/doku.php?id=software_patents_policy . As a more general guideline, I'd suggest to wait at least for this evening meeting since we will discuss/clear out the issue regarding core/nonfree (and hopefully of their respective inclusion on some of our releases ISOs). Romain
Re: [Mageia-dev] [RPM] cauldron core/release poppler-0.16.3-3.mga1
Thierry Vignaud writes: > On 28 March 2011 10:14, Mageia Team wrote: >> blino 0.16.3-3.mga1: >> + Revision: 78257 >> - add back conflicts, needed because of girepository-1.0/Poppler-0.16.typelib > > Then fix installation on a biarch machine... There is no file conflicts between libpopppler i586 and x86_64 packages of same major -- Olivier Blin - blino
Re: [Mageia-dev] [RPM] cauldron core/release poppler-0.16.3-3.mga1
On 28 March 2011 11:31, Olivier Blin wrote: >>> blino 0.16.3-3.mga1: >>> + Revision: 78257 >>> - add back conflicts, needed because of >>> girepository-1.0/Poppler-0.16.typelib >> >> Then fix installation on a biarch machine... > > There is no file conflicts between libpopppler i586 and x86_64 packages > of same major blino, you're experienced and you know better than that. Upgrade did failed b/c they didn't ended in the same transaction.
Re: [Mageia-dev] [RPM] cauldron core/release poppler-0.16.3-3.mga1
Thierry Vignaud writes: > On 28 March 2011 11:31, Olivier Blin wrote: blino 0.16.3-3.mga1: + Revision: 78257 - add back conflicts, needed because of girepository-1.0/Poppler-0.16.typelib >>> >>> Then fix installation on a biarch machine... >> >> There is no file conflicts between libpopppler i586 and x86_64 packages >> of same major > > blino, you're experienced and you know better than that. > Upgrade did failed b/c they didn't ended in the same transaction. You did not mention upgrade first. Any log for the failed upgrade? -- Olivier Blin - blino
Re: [Mageia-dev] [RPM] cauldron core/release poppler-0.16.3-3.mga1
On 28 March 2011 13:13, Olivier Blin wrote: > blino 0.16.3-3.mga1: > + Revision: 78257 > - add back conflicts, needed because of > girepository-1.0/Poppler-0.16.typelib Then fix installation on a biarch machine... >>> >>> There is no file conflicts between libpopppler i586 and x86_64 packages >>> of same major >> >> blino, you're experienced and you know better than that. >> Upgrade did failed b/c they didn't ended in the same transaction. > > You did not mention upgrade first. > Any log for the failed upgrade? Not anymore. Sorry
Re: [Mageia-dev] RPM5 AND MAGEIA
Le mercredi 2 mars 2011 16:29:20, Anne nicolas a écrit : > So I guess rpm5 is not for now a priority given the size of pending > todo list. Also If we do have a look on it, we will for better have a > team on it rather than one guy to avoid single point of failure. > Clever decision, I fully agree. Switching to rpm5 was weeks of discussions, troubles and works for Mandriva. I can guess that rpm5 is better... but better for who ? Users see only a system which works without problems. Note: this is my first post on Mageia. I have installed alpha one on a PC and I find the result is very good. For example I succeded to have the sound on my external Delta44 card. It doesn't work since Mdv 2010.0... I have however found some bugs. Where and how can I report them? -- Pierre Jarillon - http://pjarillon.free.fr/ Vice-président de l'ABUL : http://abul.org/ Microsoft est à l'informatique ce que McDonald est à la gastronomie.
Re: [Mageia-dev] RPM5 AND MAGEIA
Le jeudi 3 mars 2011 10:53:25, Buchan Milne a écrit : > rpm5 has wasted more than half of the time I could afford to contribute to > Mandriva. It seems Mandriva has resources to waste, I don't think we have. I fully agree. The users don't bother if it works with rpm4 or rpm5 or rpm17, they want only a working system! A part of the success of Ubuntu is that it works. Even if it is not always the best technical choice, the best choice is always the choice which works. -- Pierre Jarillon - http://pjarillon.free.fr/ Vice-président de l'ABUL : http://abul.org/ Microsoft est à l'informatique ce que McDonald est à la gastronomie.
[Mageia-dev] RPM5 AND MAGEIA
Hi to Mageia I am part of rpm5 (but I follow rpm from more than 10 years) and recently I did join Mageia, although I almost always used for work other distros and OS (AIX, SVR4) that I also deal with Mandriva and security (CEH) https: / / www.redhat.com/wapps/training/certification/verify.html?certNumber=805007215126804&verify=Verify Apart from the rest - of which i will ask for sponsorship when it will be - I wanted to know if there are plans to move to rpm5 by Mageia, such as Mandriva has been doing lately. Rpm5 already has a builtbot with Magela and rpm5. I can, if you can think useful or have plan for this, lay the necessary modification to enter into rpm5 Mageia, with the features of Mandriva cooker - fingerprint, syslog, etc. without trademark ecc- and produce a first rpm rpm5 for mageia , which also contains the functionality required by the passage dell'rpmdb "RPM ACID ", among others, in this rpm5. There is interest? Then if someone wants to directly participate in rpm5 I think that there should also be no problem. Opinions ? TIA Regards
Re: [Mageia-dev] RPM5 AND MAGEIA
Thanks. -Original Message- From: Raphaël Jadot Sent: 02/03/2011, 17:41 To: Mageia development mailing-list Subject: Re: [Mageia-dev] RPM5 AND MAGEIA 2011/3/2 devzero2000 : > Hi to Mageia Hi :) > > > is there interest? Then if someone wants to directly participate in > rpm5 I think that there should also be no problem. > > Opinions ? > > TIA I have no opinion about rpm5 vs rmp.org as i don't really know the differences, but as it may help you, i looked for old discussions about it. I did not find a complete topic about rpm5 vs rpm, but some topic that also talked about it. jan 9 discussion about compatibility between mdv and mga https://www.mageia.org/pipermail/mageia-dev/20110109/002024.html jan 18 Compatibility: %mdkversion macro https://www.mageia.org/pipermail/mageia-dev/20110118/002215.html feb 11 triggers in rpm5 and rpm.org https://www.mageia.org/pipermail/mageia-dev/20110211/002535.html There are sometimes some discussions that are more or less in relation with mandriva's rpm5 migration, including policies, triggers, rubygem etc. Maybe it can help :) Raphaël
[Mageia-dev] USB 3G modem configuration for Peru
Hello, I thought it would be a good idea to include the list of ISP for Peru in the first Mageia. There are three companies here for 3G USB modem Internet connections: Claro, Nextel and Movistar. Claro configuration is: APN: claro.pe (no longer tim.com.pe, as it says in Mandriva 2010.2) user name: [none] password [none] Nextel configuration is: APN: datacard.nextel.com.pe user name: i.e. u...@nextel.com.pe (include i.e., else it won't work) password: 12345 I'll try to find out which is Movistar information so you can include it as well. Regards, -- Jorge Enrique Aguayo —Tedel http://heptagrama.com
Re: [Mageia-dev] Grub version
Le 21/03/2011 16:10, Stefano Negro a écrit : > > > 2011/3/21 Thorsten van Lil mailto:tv...@gmx.de>> > > The last time I installed Ubuntu (one year ago, i think) it detected my > mandriva installation and set it up in the grub. Nevertheless it doesn't > worked and I had to manipulate grub2 according to boot mandriva. But that > was/is a known bug in (ubuntus) grub2. > > Regards, > Thorsten > > Ok, I will have a look at the bugs in ubuntu and try to understand it. I've posted a patch about this sometime ago : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566102 > > > -- > Thanks > Stblack
[Mageia-dev] dropbox daemon sync issue - doesnt install or start correctly
hello everyone, i've been testing the mageia alpha-1 and -2 and i stumbled over a weird behaviour of my lovely dropbox client. (dropbox is a sync service) the client is available for fedora and ubuntu and as tar archive for compilation. the package as the comiled sources don't do very much, they only download and install the actual dropbox daemon which is closed source. it works fine on ubuntu but not on mageia :/ the installed menuitem doesn't do anything and the console application is just acting weird. the command list: $ dropbox Dropbox command-line interface commands: Note: use dropbox help to view usage for a specific command. status get current status of the dropboxd help provide help puburl get public url of a file in your dropbox stop stop dropboxd running return whether dropbox is running startstart dropboxd filestatus get current sync status of one or more files ls list directory contents with current sync status autostartautomatically start dropbox at login exclude ignores/excludes a directory from syncing i think the daemon wasn't installed correctly ( although i tried it several times ) because every command just throws errors. e.g.: $ dropbox start Dropbox isn't responding! Dropbox is already running! $ dropbox filestatus Traceback (most recent call last): File "/usr/bin/dropbox", line 1242, in ret = main(sys.argv) File "/usr/bin/dropbox", line 1231, in main result = commands[argv[i]](argv[i+1:]) File "/usr/bin/dropbox", line 604, in newmeth return meth(*n, **kw) File "/usr/bin/dropbox", line 860, in filestatus status = dc.icon_overlay_file_status(path=fp).get(u'status', [u'unknown'])[0] File "/usr/bin/dropbox", line 575, in __spec_command return self.send_command(unicode(name), kw) File "/usr/bin/dropbox", line 533, in send_command ok = self.__readline() == u"ok" File "/usr/bin/dropbox", line 509, in __readline raise DropboxCommand.BadConnectionError() __main__.BadConnectionError or my favorite: $ dropbox start --install Dropbox isn't running! Dropbox is already running! does anybody maybe have the same problems or any solution hints for this? thank you. lb
[Mageia-dev] dropbox daemon sync issue - doesnt install or start correctly
hello everyone, i've been testing the mageia alpha-1 and -2 and i stumbled over a weird behaviour of my lovely dropbox client. (dropbox is a sync service) the client is available for fedora and ubuntu and as tar archive for compilation. the package as the comiled sources don't do very much, they only download and install the actual dropbox daemon which is closed source. it works fine on ubuntu but not on mageia :/ the installed menuitem doesn't do anything and the console application is just acting weird. the command list: $ dropbox Dropbox command-line interface commands: Note: use dropbox help to view usage for a specific command. status get current status of the dropboxd help provide help puburl get public url of a file in your dropbox stop stop dropboxd running return whether dropbox is running startstart dropboxd filestatus get current sync status of one or more files ls list directory contents with current sync status autostartautomatically start dropbox at login exclude ignores/excludes a directory from syncing i think the daemon wasn't installed correctly ( although i tried it several times ) because every command just throws errors. e.g.: $ dropbox start Dropbox isn't responding! Dropbox is already running! $ dropbox filestatus Traceback (most recent call last): File "/usr/bin/dropbox", line 1242, in ret = main(sys.argv) File "/usr/bin/dropbox", line 1231, in main result = commands[argv[i]](argv[i+1:]) File "/usr/bin/dropbox", line 604, in newmeth return meth(*n, **kw) File "/usr/bin/dropbox", line 860, in filestatus status = dc.icon_overlay_file_status(path=fp).get(u'status', [u'unknown'])[0] File "/usr/bin/dropbox", line 575, in __spec_command return self.send_command(unicode(name), kw) File "/usr/bin/dropbox", line 533, in send_command ok = self.__readline() == u"ok" File "/usr/bin/dropbox", line 509, in __readline raise DropboxCommand.BadConnectionError() __main__.BadConnectionError or my favorite: $ dropbox start --install Dropbox isn't running! Dropbox is already running! does anybody maybe have the same problems or any solution hints for this? thank you. lb
Re: [Mageia-dev] [RPM] cauldron core/release mga-mirrors-0.05-2.mga1
Thierry Vignaud writes: > On 21 March 2011 23:16, Mageia Team wrote: >> Mageia Mirrors management > > Please can we've a real description? > We mere mortals cant understand what this package is about... It's the web software (Catalyst) behind mirrors.mageia.org, written by Nanar -- Olivier Blin - blino
Re: [Mageia-dev] RPM5 AND MAGEIA
'Twas brillig, and Pierre Jarillon at 02/03/11 21:11 did gyre and gimble: > Le mercredi 2 mars 2011 16:29:20, Anne nicolas a écrit : >> So I guess rpm5 is not for now a priority given the size of pending >> todo list. Also If we do have a look on it, we will for better have a >> team on it rather than one guy to avoid single point of failure. >> > > Clever decision, I fully agree. > Switching to rpm5 was weeks of discussions, troubles and works for Mandriva. > I can guess that rpm5 is better... but better for who ? Users see only a > system which works without problems. > > Note: this is my first post on Mageia. I have installed alpha one on a PC and > I find the result is very good. For example I succeded to have the sound on > my > external Delta44 card. It doesn't work since Mdv 2010.0... > I have however found some bugs. Where and how can I report them? Wow, that message must have taken a while to come through :) The bugzilla is here: http://bugs.mageia.org/ Cheers :) Col -- Colin Guthrie mageia(at)colin.guthr.ie 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] Non-free firmwares in installer
Hello On lundi 28 mars 2011 at 00:33, andre999 wrote : > If we want to avoid the situation where people are dissatisfied because > the DVD they install produces a Mageia system where the hardware doesn't > work properly, we have to provide a single DVD that is complete, in > terms of hardware drivers. > Such cases will produce a lot of negative reaction to Mageia among many > users. > Saying that users should install with 2 ISOs may sound great, but many > will forget the secondary ISO. Why would they expect to need it ? And > why would they want the hassle of a second ISO, when one is a DVD ? > A much simpler, ergonomic solution is make space (you suggest 60 M) on > the DVD for the necessary drivers. > (That might mean removing 1 or 2 packages that few users would want > anyway.) At least we will have a product much less likely to give a > negative reaction. > Let's face it. The DVD will contain proprietary firmware/drivers > anyway, so why not include all that is necessary for a properly running > system ? > Excluding these drivers just ensures that we will have the reputation of > not supporting all hardware. > > If the community really wants to produce a totally free DVD, it should > be called "free for experts" accompanied with a "drivers for free for > experts" CD. > Of course this DVD will have to have a special kernel, compiled without > proprietory firmware/drivers. Otherwise it is just an exercice in > hypocracy. > But that is another question. > > Then we could call the normal DVD "free with proprietory drivers". > Of course this normal DVD would only include such proprietory drivers > where there is not a reliable open source equivalent available. > We could consider this a sort of "as free as possible in practice" for a > fully working system, in terms of hardware. > > (If we go for the alternate DVD solution, the easiest way is to produce > the normal DVD with all the drivers, and just exclude the proprietory > drivers on the other, putting them on the CD. But such as DVD would't > be totally free.) > > BTW, the Mandriva free DVD lacks some necessary drivers, which is really > a hassle if one doesn't have internet access during install, even for > advanced Mandriva Linux users. How about adding an initial check to the installer? A "grey list" of hardware wich requires non-free/tainted components would be created, associating the hardware ID with the package(s) containing the required components to make it work. Maybe that list could be created automatically from the packages? Then the installer check the detected hardware against that list before asking any other question. Then if there is some hardware from the list it will check on its current media if the required packages are available, if so the install can go on normally, if not the installer inform the user that it is missing some driver/firmware/something else to support some hardware, then the user could either: - immediately add another install media, which would be added to the list of available media and the check done again - continue anyway (if the user know that he can go on without that hardware) - immediately stop the install to go fetch another install media, or an add- on driver media. This way the user does not risk to discover that something doesn't work after the install, when it may be too late. The list could eventually be split between "must have" hardware (network, maybe some RAID controller?) and "nice to have hardware" (anything that can be configured after install). Maybe it is too late in the development cycle of the first release to have such a change in the installer. -- Renaud Michel
[Mageia-dev] Request for ruby modules suggestions
Hello, Version freeze is in 3 weeks. In the meantime, I need to package some other ruby modules, but I would like to hear about your needs concerning these modules. At the moment I plan to do the following packages: - passenger (a must have IMHO) - thin - rainbows - unicorn - gem2rpm (need to integrate the mageia template properly) - selenium-webdriver (missing dep, help would be welcome) - gitorious and its dependencies - highline - hmac - geoip - stompserver - ultrasphinx I’m not sure I will have time to have gitorious ready, and I wonder if there is much interest in it. Best regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpLyyREF3tso.pgp Description: PGP signature
Re: [Mageia-dev] Request for ruby modules suggestions
Le lundi 28 mars 2011 à 22:21 +0200, Remy CLOUARD a écrit : > Hello, > > Version freeze is in 3 weeks. Did we prevent in the past from uploading new packages during version freeze ? > In the meantime, I need to package some > other ruby modules, but I would like to hear about your needs concerning > these modules. > > At the moment I plan to do the following packages: > - passenger (a must have IMHO) > - thin > - rainbows > - unicorn > - gem2rpm (need to integrate the mageia template properly) > - selenium-webdriver (missing dep, help would be welcome) > > - gitorious > and its dependencies > - highline > - hmac > - geoip > - stompserver > - ultrasphinx > > I’m not sure I will have time to have gitorious ready, and I wonder if > there is much interest in it. Gitorious is a huge package indeed, with lots of stuff required for integration. Personally, I would be interested in shapado, but I guess I can do the work by myself so maybe it is better to find what others want :). -- Michael Scherer
Re: [Mageia-dev] RPM5 AND MAGEIA
On Tuesday, March 08, 2011 11:38:21 am Anne nicolas wrote: > 2011/3/8 Per Øyvind Karlsen : > > 2011/3/3 Buchan Milne : > >> - "devzero2000" wrote: > >>> Apart from the rest - of which i will ask for sponsorship when it > >>> will > >>> be - I wanted to know if there are plans to move to rpm5 by Mageia, > >>> such as Mandriva has been doing lately. > >>> > >>> > >>> Rpm5 already has a builtbot > >>> with Magela and rpm5. I can, if you can think useful or have plan for > >>> this, lay the necessary modification to enter into rpm5 Mageia, with > >>> the features of Mandriva cooker - fingerprint, syslog, etc. without > >>> trademark ecc- and produce a first rpm rpm5 for mageia , which also > >>> contains the functionality required by the passage to the "RPM > >>> ACID " feauture (berkeley db conversion) > >> > >> But, can you: > >> -ensure that all valid packages that build under rpm-4.x (e.g. in > >> Mandriva 2010.x) will build under rpm5? -ensure that all valid packages > >> that install under rpm-4.x will install under rpm-4.x? > > > > No and no (I'm assuming you mean "install under rpm5 will install > > under rpm-4.x"). > > Such guarantees has never been provided with any other rpm versions > > either and would effectively prevent the possibility of doing any > > serious development > > and improvement on rpm itself and packaging. > > > > There's a reason for having backports and why we don't even try aiming > > at such goals either. > > > > If able to give any such guarantees with rpm.org on Mageia you gotta be > > either stupid, insane or a damn liar! ;p > > > > The guarantees and priorities is as always: > > * legacy compatibility for older packages > > (opposed to future compatibility gets kinda hard with the the whole > > time travelling issue and limitations attached to it making future > > hard to reliably > > define;) > > * backportability of current packages > > packages needs to be adapted to follow current policies, practice, > > functionality etc. in the current distribution, while efforts in > > ensuring > > possibility of backports > > needs to be invested in the packaging and adopting along the way rather > > than keep adapting rpm to stay compatible with the packaging which gets > > rather backwards. > > > > Very few changes results in breakage for backports, and where it happens > > it's easy enough to add conditional behaviour, nothing new forcing any > > real changes in long-established practices here.. > > Much of the same breakages and issues you hit, you'll hit just as well in > > newer versions from rpm.org as well.. > > > >> There is no document specifying what has changed, or even when > >> highlighting changes, no-one (@rpm5.org, or @mandriva.com) has bothered > >> to list them so that contributors can save time instead of > >> troubleshooting breakage. > >> > >> Some issues that have impacted me so far: > >> -changed behaviour of %exclude > > > > Ambiguity on %exclude usage is a clear bug, %exclude which is solely > > intended for > > excluding files from a specific package (rather than from being packaged > > at all. removing files at end of %install already fit this purpose > > sufficiently, which should > > make it obvious to most people with understanding of doing technical > > designs in general that wiring already existing functionality into an > > existing function with > > different functionality wouldn't make sense. Also this bug was fixed > > since in later > > releases such as 4.4.6 & 4.4.8 shipped before the rpm.org change, and > > should rather be treated as a regression.) predates the unpackaged files > > check and should *not* be used for other purposes. > > Fixing this is in packaging is *very* trivial and fully backwards > > compatible, not > > fixing this OTOH breaks compatibility. > > > >> -new reserved macros (%sql) > > > > all new macros introduced has the potential of conflicting with others > > and should > > always be fixed, it being reserved is more a benefit IMO as it prevents > > such incidents to go unnoticed (using very generic naming for macros is > > a bad practice in general anyways).. > > fixing this does not break any compatibility either ;) > > > >> -possible race condition between %__os_install_post and processing of > >> %files (.lzma man pages reported missing where they are in fact .xz) > > > > your own packaging mistake independent of rpm version, explained on > > cooker and fixed for you already ;) > > > >> (and of course, the unavailability of the build system - during one of > >> the periods I had the most time to work on packages - due to the rpm5 > >> "upgrade") > >> > >> rpm5 has wasted more than half of the time I could afford to contribute > >> to Mandriva. It seems Mandriva has resources to waste, I don't think we > >> have. > > > > you gotta put short-term and long-term effects up against eachother. > > breakages were already expected long before starting the upgrade, and > > the > > majority of these > > w
