You are not logged in.
Getting the new libjpeg to extra, was a correct and wise decision.
Offline
Why were no issues apart from konqueror reported while the packages were still in [testing]? Not much we can do if no-one makes bug reports. Also, note a bug report was never made about konqueror... we only know about because we happened on a thread in the forums, which is far from guaranteed.
No-one reported any further issues.
You keep saying about a "konqueror error". I think that as a developer, you ought to know that because of kparts, almost every bug in konqueror will affect all KDE applications.
They will not affect all usage of those programs and both have simple work-arounds (use another browser or jre/jdk).
Is this a serious work-around; Change my browser, my torrent client, my mail application, my rss feeder and my audio player? And why? I understand being bleeding edge with a kernel update even if this has some minor issues, because it will also bring some major advantages (although until now, never a kernel update had a "choose another application" solution). But why the hurry with libjpeg, even if the bugs were only with konqueror and openjdk. What are the advantages after this update so that I have to change a lot of my applications? The only problem was rebuilding a lot of packages?
If we chose to leave libjpeg in [testing], then we would have two choices. No longer update packages in [extra], or build everything twice. Jan was nice with the firefox update and rebuilt everything for both [extra] and [testing]. Probably not just to be nice, but because we know how much complaining there would be if firefox-3.5 sat in [testing].
So all this hurry because of firefox. Right? I have to change 4 or 5 of the applications i use, because of firefox.
Arch is rolling release. We get exposed to upstream bugs first. If no-one reports them (both to us and upstream), then there is absolutely nothing we can do.
Here you are absolutely right. None will complain about this.
But in this case, you were informed about two bugs, you ignored that the first will affect a lot of KDE applications and you decided to proceed because you believed that almost nobody uses this applications or because you don't use them. Am I wrong? Is this why arch has a testing repo? To see if the bugs are in popular applications or not?
Sorry but I use arch for years and this is the first time that the developers decide to remove support for one of the major desktop environments.
Expanding your way of thinking, seems kind like:
"also 99% don't use arch anyway".
So move to extra everything that works for you and if someone complains, the problem has
"simple work-arounds (use another distro)"
I understand that there is no way back.
I don't understand why you keep refusing that this move had some major problems and that was a bit hasty.
Offline
Hello,
I'm quite happy with this libjpeg update that went smooth.
I just want to point out something about the usability of the testing repo :
If someone is using kdemod, he will be in troubles using the [testing] repo, because the kdemod team does not provide packages compiled against [testing].
I'm not a kde user, but I do use some kde apps, and some of them that are only pacakged by kdemod (eg: kdenlive) so that it is much more convenient for me to use kdemod. When I switched to kdemod, I also had to turn off [testing] ...
Offline
Getting the new libjpeg to extra, was a correct and wise decision.
please can you inform us what are the advantages of new libjpeg that we needed so much and we couldn't wait?? Was there a security hole in the previous version?
I am sure that the problems are not only with the programs mentioned and that if we test programs others will have issues too.
Not nowing that a library or other package will cause some programs is lack of knowledge, but when knowing the problems and also upgrading is lack of respect to the arch user.
Mikes on AUR
Offline
Why were no issues apart from konqueror reported while the packages were still in [testing]? Not much we can do if no-one makes bug reports. Also, note a bug report was never made about konqueror... we only know about because we happened on a thread in the forums, which is far from guaranteed.
And why push libjpeg to [extra]? Well, we only knew about two issues, konqueror and openjpg6. They will not affect all usage of those programs and both have simple work-arounds (use another browser or jre/jdk). No-one reported any further issues. If we chose to leave libjpeg in [testing], then we would have two choices. No longer update packages in [extra], or build everything twice. Jan was nice with the firefox update and rebuilt everything for both [extra] and [testing]. Probably not just to be nice, but because we know how much complaining there would be if firefox-3.5 sat in [testing]. So the choice comes down to either moving libjpeg to [extra] and having what were reported as relatively minor annoyances or leaving libjpeg in [testing] and having [extra] stagnate (because we are not going to double our workload).
Arch is rolling release. We get exposed to upstream bugs first. If no-one reports them (both to us and upstream), then there is absolutely nothing we can do.
Αllan, I made this thread and we finally had a bug report made. If I had done a bug report in the bugs.archlinux.org site, that may have ended the same way.
The wise move would be to make an announcement in the first page of archlinux.org so that you would encourage some KDE (even GNOME users) to upgrade to testing and help you. Except for that, we hadn't no help in the [kde-unstable] upgrade (even for the users that can handle the problems that may occur), only messages in the arch-dev mail list where we, the users, cannot answer.
What would have happened if I hadn't noticed this bug ? Would you have informed bugs.kde.org with a bug report or not ?
And I should remind you of such "big" updates: Xorg 1.5, readline/bash4. When these happened to be declared "upstream stable", the first one stayed in [testing] for months. The second one wasn't even in [testing] (too risky). Why did you care more for these issues and not for that one ? Isn't it not right to not care for the KDE/Konqueror users ? Why ? Because they are the 1% or something more ? And there are not only the Konqueror users affected. Check what's going on with some GTK apps in the other subforums.
Linux users in the whole earth are about the 1% according to the statistics. Would you like the devs worldwide to have such attitude against Linux the same way ("Oh, who cares" or "I need bug reports" --> even though there was a bug report) ? No
In my opinion: libjpeg 7 issue ought to have been in testing mode more and more in [testing].
Offline
please can you inform us what are the advantages of new libjpeg that we needed so much and we couldn't wait?
We needed Firefox 3.5.
Not nowing that a library or other package will cause some programs is lack of knowledge, but when knowing the problems and also upgrading is lack of respect to the arch user.
Keeping everything back, simply because of a single application whose devs are notorious for their lack of organization, lack of priorities, sloppyness and irresponsibility (Konqueror), is lack of respect to the arch user.
Offline
...this is the first time that the developers decide to remove support for one of the major desktop environments.
KHTML is a web rendering engine.
Nothing more, nothing less.
It has nothing to do with what DE a user uses.
Offline
And I should remind you of such "big" updates: Xorg 1.5, readline/bash4. When these happened to be declared "upstream stable", the first one stayed in [testing] for months. The second one wasn't even in [testing] (too risky).
You facts are way wrong here... both (but especially readline) were delayed due to lack of developer time. Especially readline, which was built very quickly and sat in a separate repo while Aaron was busy.
I think that as a developer, you ought to know that because of kparts, almost every bug in konqueror will affect all KDE applications.
I have never used KDE, mainly because I can't be bothered dealing with themes and I hate the default qt look. So I have no idea what KDE does and it was only ever reported here and in the upstream bug report that konqueror.
When I moved the packages from [testing], it was after notice on arch-dev-public saying we know about only two bugs (konq and openjdk6) which were both assessed not to be blockers. Note there is not even a bug report in our tracker about either issue. So as far as we know, [testing] users were happy apart from those two issues. Then we move it to [extra] to the uproar on multiple fronts. How would leaving it in [testing] help us any more? We got very little feedback as it was.
I think people have forgotten what rolling release is all about. We aim to package the latest upstream stable version of a package. Things break. That is part of the joy of Arch. We get to see the bugs before everybody else. You want completely stable, go elsewhere.
Anyway, I am glad kde users don't like updates. I have lost all motivation to finish patching makepkg for the pacman release and kde-4.3 requires the new makepkg for split package support... Instead, I am going to concentrate on the job I am paid for.
Offline
Allan, you disappoint me, even though I know what you have done for Arch. Two statements:
You want completely stable, go elsewhere.
What ? What ? *facepalm*
If you don't like to have bug reports, close ALL the bug reports and so this subforum since you don't want to see users disappointed.
I have once (ONCE) been disappointed by an update, and it was an upstream Xorg bug.
With this statement, you seem to want to make Arch --> Debian Unstable like ? It has never been like that, Αrch Linux was always in a very, VERY stable distribution, against your statement.
The other one:
Anyway, I am glad kde users don't like updates. I have lost all motivation to finish patching makepkg for the pacman release and kde-4.3 requires the new makepkg for split package support... Instead, I am going to concentrate on the job I am paid for.
So, if you don't like Arch development any more, why do you continue ?
Why should we, the users, been affected by the fact that you are bored ?
Have you thought what you have written ?
No.
This bug report, not only should make you lose your interest, but it should make you hunt for the bug and solve it.
I supervise 4 unofficial Arch repos here, and I maintain 1 of them, with other 4 Arch users. I really know about Arch package making and I 'm not paid for that, instead I sacrifice my spare time for Arch packaging. I sometimes have complaints about package making and git packages. Sometime they are even rants about nothing. What should I do ? Just ..." lose my motivation" ? NO. I hunt the problem and solve it. So that's what you should do and continue your voluntary job as you did, but much more carefully.
Last edited by flamelab (2009-07-15 12:37:06)
Offline
I think people have forgotten what rolling release is all about. We aim to package the latest upstream stable version of a package. Things break. That is part of the joy of Arch. We get to see the bugs before everybody else. You want completely stable, go elsewhere.
This is NOT rolling release. This is bleeding edge.
Since when rolling release means "I update the package even if I KNOW that there is a bug that affects a WHOLE desktop environment" ??
Or better ""I update the package even if I KNOW that there is a bug that affects a WHOLE desktop environment as far as this bug doesn't affect me because I use another desktop environment. And the rest of you, go **** yourself, I don't care. Change browser, move your mails to another client, move your rss feeds" etc
Anyway, I am glad kde users don't like updates. I have lost all motivation to finish patching makepkg for the pacman release and kde-4.3 requires the new makepkg for split package support... Instead, I am going to concentrate on the job I am paid for.
OMG. Does this threat means that KDE will be completely removed from arch repos?
I think that linux is community based project and people contribute to it because they like to.
If you don't want to admit your mistakes and maybe learn something for the future, good luck with your job.
Offline
warlord wrote:...this is the first time that the developers decide to remove support for one of the major desktop environments.
KHTML is a web rendering engine.
Nothing more, nothing less.
It has nothing to do with what DE a user uses.
And what about the kparts?
ktorrent? linux has a few *good* torrent clients and now, one of them has *broken* search function.
We needed Firefox 3.5.
Are you serious?
firefox 3.5 is in extra since 07/03
Offline
This is NOT rolling release. This is bleeding edge.
No, this is by definition, rolling release.
The latest upstream stable, release, code.
Bleeding edge would be cvs / svn / git.
We are not talking about that here.
Since when rolling release means "I update the package even if I KNOW that there is a bug that affects a WHOLE desktop environment" ??
Or better ""I update the package even if I KNOW that there is a bug that affects a WHOLE desktop environment as far as this bug doesn't affect me because I use another desktop environment.
1. If no bugs are filed (when it was in testing) -> then, simply, there are NO bugs. Allan is right.
2. With complexity also comes sensitivity. This is a law of nature. You want to make a very complex ("intergrated" you call it) DE. Fine. Then be ready to deal with such breakages. The more complex you make the DE, the more prone to errors, bugs, and breakage it is. If you cannot make something right, with organization, responsibility, and prioritization, then do not make it at all. The new libjpeg has been out for more than 3 weeks now. What have the KHTML devs been doing for so long?
If you don't want to admit your mistakes and maybe learn something for the future, good luck with your job.
He has not made any mistakes.
Offline
warlord wrote:This is NOT rolling release. This is bleeding edge.
No, this is by definition, rolling release.
The latest upstream stable, release, code.
Bleeding edge would be cvs / svn / git.
We are not talking about that here.
You should see the definition of wikipedia about rolling release. Rolling release refers to the upgrade method.:/
But this is not the point.
warlord wrote:Since when rolling release means "I update the package even if I KNOW that there is a bug that affects a WHOLE desktop environment" ??
Or better ""I update the package even if I KNOW that there is a bug that affects a WHOLE desktop environment as far as this bug doesn't affect me because I use another desktop environment.1. If no bugs are filed (when it was in testing) -> then, simply, there are NO bugs. Allan is right.
2. With complexity also comes sensitivity. This is a law of nature. You want to make a very complex ("intergrated" you call it) DE. Fine. Then be ready to deal with such breakages. The more complex you make the DE, the more prone to errors, bugs, and breakage it is. If you cannot make something right, with organization, responsibility, and prioritization, then do not make it at all. The new libjpeg has been out for more than 3 weeks now. What have the KHTML devs been doing for so long?
1. The bug report opened when the package was in Testing. So simple there WAS a bug. So Allan is wrong.
2. The bug report opened 10 days ago and not 3 weeks. So the khtml developers were informed 10 days ago. You think that 10 days is enough for an open source project?
warlord wrote:If you don't want to admit your mistakes and maybe learn something for the future, good luck with your job.
He has not made any mistakes.
See 1. right above
Offline
You should see the definition of wikipedia about rolling release.
I do not care about the definition of wikipedia.
If wikipedia wrote "1+1=3", would that make it right?
Offline
I can no longer read those posts.
First, the move had nothing to do with Firefox. Firefox was built twice from Jan, first for [extra] (old libjpeg) and second for [testing] (new libjpeg). This was done by Jan that we can provide Firefox in [extra] without waiting for the libjpeg move to [extra]. So, Firefox has absolutly nothing to do with the libjpeg move.
Second, we have rebuilt all packages which we knew that needs a rebuild. We have test them in [testing] and decided that there is no showstopper for moving the packages. Pierre tested the KDE release and there were this small issue in Konqueror, but it wasn't critical and KDE worked here (on some devs' machines). So, we decided to move the packages. We got no further bug reports before we moved it and from our point of view we were clear to move the packages.
As you can see, we have tested the packages as good as we can. It's normal that other packages from community/AUR/Kdemod breaks after such a big move, so we can't do anything here. We just have to wait that our TUs rebuild those packages and the kdemod devs do their job.
Complaining about single devs is completly wrong and nobody has made any mistake. If you complain about one dev, you are complaining about all devs.
This is my private opinion and is no official ArchLinux developer team view.
Offline
Ι can't no longer continue argue about this. I didn't want to look mean, since I really like this distro, which I have been using since 2007.
My duty as an Arch user was to report what happened, and I reported it when it was in testing.
Last edited by flamelab (2009-07-15 13:03:50)
Offline
Please, would you mind lock the thread since it's no longer a [testing] issue.
If someone wants to discuss anything with me, peacefully, he/she may contact me (my email is on AUR, I have the same nickname there).
Last edited by flamelab (2009-07-15 13:25:21)
Offline
warlord wrote:You should see the definition of wikipedia about rolling release.
I do not care about the definition of wikipedia.
If wikipedia wrote "1+1=3", would that make it right?
And why do I have to care about yours definition of rolling release?
@ise,
I think that nobody is complaining about the update. It is logical for a package to break.
But I really cant accept the "change browser" explanations and the threats.
I am not used to this kind of behavior here.
Yes, lock the thread. This is the best to be done. The facts are clear.
Offline
We needed Firefox 3.5.
you know you 're wrong and that firefox 3.5 ran well with previous libjpeg.
Keeping everything back, simply because of a single application......
i do not remember amsn(which does not even start if it's not recompiled.) using khtml.
Anyway, I am glad kde users don't like updates. I have lost all motivation to finish patching makepkg for the pacman release and kde-4.3 requires the new makepkg for split package support... Instead, I am going to concentrate on the job I am paid for.
of course, you don't use kde, so YOU decide what archlinux community needs, because community=YOU....
I hope the rest of archlinux developers don't have the same opinon with you.
Last edited by mechmg93 (2009-07-15 13:35:14)
Mikes on AUR
Offline
of course, you don't use kde, so YOU decide what archlinux community needs, because community=YOU....
I hope the rest of archlinux developers don't have the same opinon with you.
Read my post above. This was a decision of all devs, not from one.
Offline
Thread closed.
Offline