Bug#902263: Bug#905559: Bug#902263: Affecting Qt transition
El lunes, 6 de agosto de 2018 17:26:59 -03 Lisandro Damián Nicanor Pérez Meyer escribió: [snip] > /me facepalms > > Ah, indeed, my bad! It's frameworks, not PIM. Sorry about that. Paul, RT: my most sincere apologies. I don't know how but I got to mix frameworks with PIM. Frameworks is indeed another thing. I have just checked upstream's CI and they have not checked the tests against 5.11 (which is odd), but I'll file the bug as appropriate. Again, my apologies. -- Sobre Argentina: "sé que es uno de los países mas hospitalarios del mundo" Albert Einstein Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#902263: Bug#905559: Bug#902263: Affecting Qt transition
Hey, > That's totally understandable from your part. Now the test has clearly > failed. The regression could either be in Qt or in some part of the KDE PIM > stack (not the meta package). ktexteditor is KDE Frameworks and not KDE PIM. For KDE PIM the argument of not being up-to-date and not being ready for Qt 5.11 may be/is valid. But Framworks is uptodate with 5.47 (released in June) and it should be Qt 5.11 ready - So you should considering filing a bug about this regression upstream. hefee signature.asc Description: This is a digitally signed message part.
Bug#902263: Bug#905559: Bug#902263: Affecting Qt transition
El lun., 6 de ago. de 2018 17:23, Sandro Knauß escribió: > Hey, > > > That's totally understandable from your part. Now the test has clearly > > failed. The regression could either be in Qt or in some part of the KDE > PIM > > stack (not the meta package). > > ktexteditor is KDE Frameworks and not KDE PIM. For KDE PIM the argument of > not > being up-to-date and not being ready for Qt 5.11 may be/is valid. But > Framworks is uptodate with 5.47 (released in June) and it should be Qt > 5.11 > ready - So you should considering filing a bug about this regression > upstream. > /me facepalms Ah, indeed, my bad! It's frameworks, not PIM. Sorry about that. So yes, I'll file the bug. >
Bug#902263: Affecting Qt transition
El lunes, 6 de agosto de 2018 15:34:02 -03 Paul Gevers escribió: > Dear all, Hi Paul :-) > To be sure, I don't want to block/delay anything here, I just want > autopkgtests to be taken seriously. If you as the maintainer of > ktexteditor say please ignore my test for migration, who am I to say > you're wrong. However, you have also added that test for a reason. That's totally understandable from your part. Now the test has clearly failed. The regression could either be in Qt or in some part of the KDE PIM stack (not the meta package). > On 06-08-18 15:33, Lisandro Damián Nicanor Pérez Meyer wrote: > > I used i, d, v, y, shift+p. I even retried them just now in case I missed > > something. > > What does idvyP (insert mode; add characters d v y P) have to do with > the failing test case? Lot's of vim code seems to go all right, there is > only 1 regression. > With the above and... > As long as this is the only thing, I agree with you, but if you don't > know what's wrong you don't actually know. (Albeit the amount of passing > tests says something, but once you let this one into testing, the whole > autopkgtest of ktexteditor becomes worthless until this issue is fixed > somehow). ... considering it seems happens only in a certain specific case for a certain specific option that can be easily overridden by using the editor in it's normal, default mode: yes, even if there is a regression it's negligible enough to delay things further. So the autopkg tests did it's job, but the balance between pushing Qt or fixing the test/offending code makes it not worth the effort to wait. [snip] > I don't know which package you exactly mean with kdepim as that is a > meta-package that is the same in unstable and testing since 2018-06-10. KDE PIM is a big stack, which needs to be updated and possibly with a small transition involved. We do not want both things tangled together. > All source packages with kdepim in the name are also the same in > unstable and testing (haven't checked binary rebuilds). But if the > package you are really referring to is the same in unstable and testing, > it can't cause the regression. Is it the same? If so, than the > regression isn't a bug there. If not, maybe we can investigate (by > testing) and check if that needs its migration blocked or delayed. There have been fixes in Qt for bugs that might have been used as features, it's not the first time this happens. > > * If the bug is in kdepim then the best way to solve it would be to > > psuh a > > > > new version, for which we need a transition. > > And delay or prevent the version in unstable from migrating to testing? > Depending on severity I guess. Exactly, the severity of this bug is small enough to delay things further. > > - No users have complained about this so far, and we do have lots of users > > using unstable and reporting bugs. This has proven to be a nice regression > > method so far ;-) > > Of course. > > > So I think the best way to go here is just let Qt migrate. > > In 3 days that happens if we don't do anything. I'll let the RT judge if > that is worth waiting for or if migration is more urgent. Same here :-) -- Geek Inside! Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#902263: Affecting Qt transition
Dear all, To be sure, I don't want to block/delay anything here, I just want autopkgtests to be taken seriously. If you as the maintainer of ktexteditor say please ignore my test for migration, who am I to say you're wrong. However, you have also added that test for a reason. On 06-08-18 15:33, Lisandro Damián Nicanor Pérez Meyer wrote: > I used i, d, v, y, shift+p. I even retried them just now in case I missed > something. What does idvyP (insert mode; add characters d v y P) have to do with the failing test case? Lot's of vim code seems to go all right, there is only 1 regression. > I might be missing something, but at this point: > > - If there is a regression: > > * it would be small and can be worked around by using the normal editing > mode. As long as this is the only thing, I agree with you, but if you don't know what's wrong you don't actually know. (Albeit the amount of passing tests says something, but once you let this one into testing, the whole autopkgtest of ktexteditor becomes worthless until this issue is fixed somehow). > * odds are highly on the bug-on-kdepim side, as Qt 5.11.1 is just a patch > release of 5.11.0 which has been shipped in other distros for months > already (we skip even releases due to the fact that we need to do > transitions). I don't know which package you exactly mean with kdepim as that is a meta-package that is the same in unstable and testing since 2018-06-10. All source packages with kdepim in the name are also the same in unstable and testing (haven't checked binary rebuilds). But if the package you are really referring to is the same in unstable and testing, it can't cause the regression. Is it the same? If so, than the regression isn't a bug there. If not, maybe we can investigate (by testing) and check if that needs its migration blocked or delayed. > * If the bug is in kdepim then the best way to solve it would be to psuh a > new version, for which we need a transition. And delay or prevent the version in unstable from migrating to testing? Depending on severity I guess. > - No users have complained about this so far, and we do have lots of users > using unstable and reporting bugs. This has proven to be a nice regression > method so far ;-) Of course. > So I think the best way to go here is just let Qt migrate. In 3 days that happens if we don't do anything. I'll let the RT judge if that is worth waiting for or if migration is more urgent. Paul signature.asc Description: OpenPGP digital signature
Bug#902263: Affecting Qt transition
El lunes, 6 de agosto de 2018 09:39:48 -03 Paul Gevers escribió: > Dear Lisandro, > > On 06-08-18 13:35, Lisandro Damián Nicanor Pérez Meyer wrote: > > On one side Maxy told me that many autopkg tests would need fixing due to, > > if my mind does not fails, gcc 8. > > It may have slipped in, because the autopkgtests were so much broken for > a while that I didn't check carefully if a regression was in the Qt > stack. After a while, the abi-compliance check was broken in the > reference as well, so maybe regressions due to gcc are now hidden. > Luckily the abi-compliance checker is now fixed and there are very > limited regressions in the Qt stack at this moment, ktexteditor is the > only one I am aware of. I see, thanks! Note that I have almost no idea wrt autopkg tests as we don't use it in the Qt stack. > > On the other I took a look at the failed test (keys mapping in vi input > > mode) an tried with kate on my machine running Qt 5.11 without issues, so > > I'm suspecting the issue is indeed in the test itself. > > As I have kate on my system (buster, not fully up-to-date), I tried to > reproduce the reference as it seems that the test is doing something > simple. It appears to create a sting, executes some vim commands and > checks that the outcome is as expected. So it seems unlikely to me that > this should change. To me, either the old code was doing something > weird, or the new code is doing it wrong. The test says "Vim is weird" > so it really looks like the old result is correct. Weirdly enough I get > the same results as the "new" results of the test. So I suspect I am > doing something wrong, as I should get the reference. Which keys did you > press? Do you know what they _should_ do (my vim knowledge is close to > containing only ":q"). I used i, d, v, y, shift+p. I even retried them just now in case I missed something. I might be missing something, but at this point: - If there is a regression: * it would be small and can be worked around by using the normal editing mode. * odds are highly on the bug-on-kdepim side, as Qt 5.11.1 is just a patch release of 5.11.0 which has been shipped in other distros for months already (we skip even releases due to the fact that we need to do transitions). * If the bug is in kdepim then the best way to solve it would be to psuh a new version, for which we need a transition. - No users have complained about this so far, and we do have lots of users using unstable and reporting bugs. This has proven to be a nice regression method so far ;-) So I think the best way to go here is just let Qt migrate. Regards, Lisandro. -- lo cual parece incompatible. lógica, esa tendrá particiones dentro, si se transforma la extendida a tiene particiones lógicas, luego extendida. Una extendida estar dentro de una partición Una partición lógica necesita Diga NO al topposting. Matias Silva Bustos Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#902263: Affecting Qt transition
Dear Lisandro, On 06-08-18 13:35, Lisandro Damián Nicanor Pérez Meyer wrote: > On one side Maxy told me that many autopkg tests would need fixing due to, if > my mind does not fails, gcc 8. It may have slipped in, because the autopkgtests were so much broken for a while that I didn't check carefully if a regression was in the Qt stack. After a while, the abi-compliance check was broken in the reference as well, so maybe regressions due to gcc are now hidden. Luckily the abi-compliance checker is now fixed and there are very limited regressions in the Qt stack at this moment, ktexteditor is the only one I am aware of. > On the other I took a look at the failed test (keys mapping in vi input mode) > an tried with kate on my machine running Qt 5.11 without issues, so I'm > suspecting the issue is indeed in the test itself. As I have kate on my system (buster, not fully up-to-date), I tried to reproduce the reference as it seems that the test is doing something simple. It appears to create a sting, executes some vim commands and checks that the outcome is as expected. So it seems unlikely to me that this should change. To me, either the old code was doing something weird, or the new code is doing it wrong. The test says "Vim is weird" so it really looks like the old result is correct. Weirdly enough I get the same results as the "new" results of the test. So I suspect I am doing something wrong, as I should get the reference. Which keys did you press? Do you know what they _should_ do (my vim knowledge is close to containing only ":q"). j (one line down) V (not in the vim man but Kate says "visual line") j (one line down) ~ (not in the vim man but Kate capitalizes the by now two selected lines) u (undo last change) (switch back to normal mode, doesn't do anything AFAICT) ` (?, doesn't do anything AFAICT) [ (?, doesn't do anything AFAICT) r (replace one character at the current position) [ (this is now inserted as the first character of the third line for me, overwriting the x). Paul signature.asc Description: OpenPGP digital signature
Bug#902263: Affecting Qt transition
El lunes, 6 de agosto de 2018 06:28:21 -03 Paul Gevers escribió: > Dear all, > > On 06-08-18 11:16, Niels Thykier wrote: > > Could you please confirm that the autopkgtest regression for > > ktexteditor (marked on the excuses for qtbase-opensource-src) is benign? > > I believe there is a regression, at least in the autopkgtest. I filed > bug 905559 for that already. > > Paul > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905559 Thanks both for the ping! On one side Maxy told me that many autopkg tests would need fixing due to, if my mind does not fails, gcc 8. On the other I took a look at the failed test (keys mapping in vi input mode) an tried with kate on my machine running Qt 5.11 without issues, so I'm suspecting the issue is indeed in the test itself. So I would say please go ahead with the aging. Thanks!!! -- Alas, I am dying beyond my means. Oscar Wilde, as he sipped champagne on his deathbed Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#902263: Affecting Qt transition
Dear all, On 06-08-18 11:16, Niels Thykier wrote: > Could you please confirm that the autopkgtest regression for > ktexteditor (marked on the excuses for qtbase-opensource-src) is benign? I believe there is a regression, at least in the autopkgtest. I filed bug 905559 for that already. Paul https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905559 signature.asc Description: OpenPGP digital signature
Bug#902263: Affecting Qt transition
Lisandro Damián Nicanor Pérez Meyer: > Control: block 902263 by 904133 > > Hi! Please note that this is the only package stopping the Qt transition now. > Hi Lisandro, Could you please confirm that the autopkgtest regression for ktexteditor (marked on the excuses for qtbase-opensource-src) is benign? If it is, I am happy to age both qtbase-opensource-src and telegram-desktop. But otherwise, I would prefer not breaking ktexteditor in testing. Thanks, ~Niels References: * https://tracker.debian.org/pkg/qtbase-opensource-src * https://ci.debian.net/data/autopkgtest/testing/amd64/k/ktexteditor/776729/log.gz
Bug#902263: Affecting Qt transition
Control: block 902263 by 904133 Hi! Please note that this is the only package stopping the Qt transition now. -- El tiempo es un buen maestro, solo que lamentablemente, asesina a todos sus discípulos. Curt Goetz. (1888-1960). Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
