Re: [gentoo-dev] Re: don't rely on dynamic deps
Martin Vaeth wrote:
The user's vardb could then automatically receive the last state of
the ebuild, before it was removed.
It doesn't help reliably, either, since the last state of the ebuild,
before it was removed, will be outdated at some point, too.
Sorry, I don't see how. Can you give an example? Thanks!
1. foo depends on bar
2. user installs foo
3. foo is treecleaned
4. bar ebuild is replaced by the pair bar-base and bar-gui to
allow for finer dependency. All ebuilds in the tree take
care about this new structure (possibly with revbumps).
Of course, the dependency for an already removed package
is not fixed.
5. bar{-base,gui} gets several upgrades.
6. foo on user's system still blocks bar from being removed
and thus blocks the installation of bar-base and bar-gui
forever.
Thanks for spelling it out!
This suggests another data model bug to me: that dependencies belong
to the dependent packages, rather than to dependency providers.
What I mean is that in the above example, bar knows that bar has
turned into bar-{base,gui}, but foo doesn't.
Note that 4. cannot be replaced by any pushing mechanism,
since only the maintainer of the ebuild can know which is
the right dependency for the new tree structure. Such a
maintainer does not exist for treecleaned packages (which
is the purpose of treecleaning, after all...)
If the user updates their package database things would still work
if 4 modifies the effective dependencies for foo to reflect the new
reality of bar - bar-{base,gui}.
foo is not being maintained, but bar is. It might be incorrect to say
that foo depends on both bar-base and -gui (foo might just need -base)
but it is perfectly safe to automatically make the most pessimistic
assumption when upgrading the outdated dependency on bar in all
installed-but-outdated-ebuilds.
The code required for this would even allow to partially automate
dependency changes like bar - bar-{base,gui} across the tree.
Maintainers could get notified when a package they depend on change,
and the safe default is to just roll along. Less dev work! \o/
The more I think about dependencies the more convinced I am that
dependency information must be versioned, ie. dependencies only
matter in the context of the particular package database snapshot
they came from, and that installed dependencies must be kept up to
date as the package database evolves.
Otherwise there's just a pile of heuristics, which throw people,
which I guess is why dynamic-deps cause problems and ire.
Rich Freeman wrote:
This is really the crux of these sorts of issues. It doesn't matter
if dependencies are static or dynamic - if you hang onto orphans then
you're going to have cruft in your vdb which is going to lead to
blockers of some kind eventually.
I think the vdb can and should be updated according to portage changes.
Someone just needs to code it. ;)
//Peter
Re: [gentoo-dev] Re: don't rely on dynamic deps
On 29 July 2014 19:33, Peter Stuge pe...@stuge.se wrote: I think the vdb can and should be updated according to portage changes. Someone just needs to code it. ;) And an appropriate method for doing this must be decided upon. And that part entails 70% of the discussion dispute :) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
[gentoo-dev] Re: don't rely on dynamic deps
Peter Stuge pe...@stuge.se wrote:
This suggests another data model bug to me: that dependencies belong
to the dependent packages, rather than to dependency providers.
Sometimes it is this way, sometimes the opposite.
It would not be natural to associate to a huge library like openssl
the packages which use it (or can make use of it if compiled with
certain ./configure options).
What I mean is that in the above example, bar knows that bar has
turned into bar-{base,gui}, but foo doesn't.
But this is not always so.
I could also have given the example that bar is replaced by
another library which perhaps is (mainly) API but not ABI compatible
but nevertheless provides the same command line tools.
(Perhaps openssl and some of the planned successors are such an
example?)
So the installations of bar and bar-successor must block each other,
but nevertheless package foo would need to be recompiled if you want
to use the modern (presumably safer) bar-successor - which cannot
be done for foo.
Again, in this situation the user relies on the outdated bar and
does not know it. Or - if something else needs bar-successor -
the user gets blockers.
If the user updates their package database things would still work
if 4 modifies the effective dependencies for foo to reflect the new
reality of bar - bar-{base,gui}.
I would be very careful with such magic modifications:
It is always dangerous if you rely on a heuristic which needs to
be smarter than the developer; no matter how many cases you
cover in the heuristic, sooner or later there will be some
split/replacement/alternative/merge of packages which cannot be treated
by the cases covered through the heuristics and which needs
some form of manual treatment in some cases.
The more I think about dependencies the more convinced I am that
dependency information must be versioned, ie. dependencies only
matter in the context of the particular package database snapshot
they came from, and that installed dependencies must be kept up to
date as the package database evolves.
Yes, this is exactly the problem with static dependencies.
Regular revbumps *might* be a solution to this, but there is a
certain danger that due to certain (e.g. circular) static dependencies
blocking updates on certain user's systems the revbumps remain
invisible to these users.
This is probably not very likely, but I think I could construct
realistic such cases (with a bug in a dependency, such cases
are very easy to construct: Some =... instead of ~... is sufficient).
Otherwise there's just a pile of heuristics, which throw people,
which I guess is why dynamic-deps cause problems and ire.
This is exactly the main problem with dynamic dependencies.
To summarize a bit differently:
The issue is caused by gentoo being a rolling release distribution.
This causes permanent tree restructuring, and the latter is
incompatible with the idea that a package, once installed,
should remain working, unconditionally on the tree changes.
Users may expect and wish for the latter, but fact is that these
two requirements are in some situations incompatible with each other.
If you want a completely safe solution which in no special cases
can ever cause any problems, after every sync you would have to
unmerge every package and then remerge it again (resolving circular
deps by temporary removing of USE-flags and recompiling).
The other extreme are dynamic deps without any revbumps ever
which take only the rolling release character into account.
You have immediately the most current tree information,
but in some cases this contradicts the actual installed packages.
Now static-deps with many revbump and dynamic-deps with only a
revbumps for essential changes are two compromises between these
two extremes.
Nothing is safe *and* up-to-date in all cases, but both work
up to a reasonable number of exceptions:
The static-deps are on the safe solution side with more recompilations
but still possibly outdated information, the dynamic-deps are on the
rolling release side, requiring the user to take more responsibility
if he wants to avoid a broken system.
The highly emotional reactions on the topic are probably due to the
fact that corresponding users have systems which for some reason or
another should emphasize more the static or rolling release type
of gentoo: Shifting this emphasis is a politicial issue and
fundamental decision, of course.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Tue, Jul 29, 2014 at 3:33 AM, Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: This is really the crux of these sorts of issues. It doesn't matter if dependencies are static or dynamic - if you hang onto orphans then you're going to have cruft in your vdb which is going to lead to blockers of some kind eventually. I think the vdb can and should be updated according to portage changes. Someone just needs to code it. ;) So, I'll agree that vdb should change when portage changes (and we should manage portage changes so that this can be done reliably), but we're talking about orphans here. Portage is only going to get one side of the story when dealing with an orphan. In your example of a package split the original package went away, and perhaps with some mechanism we could get portage to update all former dependencies to use both sides of the split. But, how about virtualization of a package? Your orphan depends on non-virtual udev, but now you want to install systemd which of course blocks udev. Maybe your package really does depend on the real udev (probably not a good example here - think ffmpeg instead perhaps), or maybe it can use the virtual. Just telling portage that the virtual replacement has been made is one problem, but figuring out whether to use it is going to be a wild guess for a PM. And there are likely other variations as well. Rich
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Mon, 28 Jul 2014 23:23:04 -0500 James Potts are...@gmail.com wrote: Paludis has an elegant solution for this situation (-F/-A), but afaik portage doesn't. I'd not call -F / -A elegant... It's a nasty trick that we only added because || dependencies are such a pain. They shouldn't be necessary. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Mon, Jul 28, 2014 at 6:49 PM, Alex Xu alex_y...@yahoo.ca wrote: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/x265/x265-.ebuild?revision=1.9view=markup#l9 Thanks, Alex. This makes more sense now. Denis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Mon, Jul 28, 2014 at 8:41 PM, Duncan 1i5t5.dun...@cox.net wrote: AFAIK, gentoo policy is that live ebuilds should always be masked so as never to be automatically pulled in without a deliberate unmasking of the live ebuild, but whether that's masked due to lack of keywords (ebuild), or due to hard-mask (package.mask) is I believe up to the maintainer. The policy apparently disappeared in the shuffling of documentation which occurred over the years. But here is what I was instructed to teach recruits back when I became a recruiter in 2006 or 2007, and what competent developers have been doing since even before I was a developer: The package.mask file is only for temporary masking, even if more or less long term. Anything that should be permanently masked has no place in the tree. Live ebuilds should not be keyworded, reflecting the fact that the code they're pulling has not be tested for any architecture due to it being live. Moreover, live ebuilds should not be masked as this results in unnecessary cruft in the package.mask file. Denis.
Re: [gentoo-dev] About current ppc/ppc64 status
On 07/26/14 18:01, Pacho Ramos wrote: El sáb, 26-07-2014 a las 16:29 -0400, Anthony G. Basile escribió: On 07/26/14 09:44, Pacho Ramos wrote: El sáb, 26-07-2014 a las 09:37 -0400, Anthony G. Basile escribió: On 07/26/14 09:28, Pacho Ramos wrote: El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: I guess we will need to wait for the next Council to officially decide to do this as it will be a big change for ppc* users :/ (I remember their action was needed for the move to testing of some arches and the package-by-package proposal for others) Also, I am not sure if any other arch teams (sparc, ia64?) would want to get this policy too :| (I got ppc* because this concrete case ;)) At first this is an arch team decision. No need for the council. (Given that in this case there is a responsive and addressable arch team...) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ The problem is that blueness looks to be the only member currently replying :/, I have checked their page and I see no team lead or similar. Then, I am not sure how to get the ok to proceed or not :| (to prevent this from getting stalled and we keep trying stabilizing all the things). I remember from older thread (one related with udev stabilization), that blueness was also the only one replying. Yeah, not having a clear lead is a problem. No one wants to just make a big decision on behalf of the team without making sure everyone is on board. Pacho, do you have access to timberdoodle? If so, join both teams and just take the initiative and let any other claimants step forward now. BTW, taking the lead doesn't mean doing all the work yourself. I want to see ppc/ppc64 in good shape. I'll be happy to write scripts to do the demoting to ~ etc etc. I don't even know about timberdoodle :( I forwarded the mail to both alias (as I forgot first time), then, hopefully they will review it :/ Will CC them again to this just now with this link to allow all to read the full thread: http://comments.gmane.org/gmane.linux.gentoo.devel/92151 I think its clear who cares about ppc/ppc64. If there are no objections, I'll take the lead of those teams and see this plan through. I'll wait a few days for people to voice concerns. Then I'll start by generating a list of all stable and testing packages on ppc and ppc64. I'll post then and then continue the conversation on just the ppc and ppc64 lists. Don't worry, I won't start dropping to ~ until we have a concise plan and we're all on board. OK, please feel free to contact me whenever you want. Usually via mail. I will have restricted internet access during most August but should be ok again in September :) Okay step 1. Get a list with all packages stable on ppc. Please see: http://dev.gentoo.org/~blueness/ppc/ We need to decide which of the packages in ppc-stable.txt and ppc64-stable.txt we want to *keep* stable. While people look over that list, I'll write a script to drop whatever is in those two files from ppc to ~ppc and ppc64 to ~ppc64. I'll wait a week or so and the poke people. I'm still not sure how to do such a massive commit safely. Does one just run repoman full on the entire tree and then repoman commit -m OMG! Huge commit. ? I think I may want infra around just in case. When I did this for selinux, I did one package at a time, but there were no complex dependencies. Also, I think a news item is prudent. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x
On Wed, Jul 23, 2014 at 1:48 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Looks like www-client/chromium is going to start using c++11 seriously and require gcc-4.8+, see thread https://groups.google.com/a/chromium.org/d/msg/chromium-packagers/fvJvPG8fa7I/iWPEsUxhKikJ This is in the dev channel for now, but given the 6 weeks release cycle it'll go to stable in about 3 months, and every time it's a security update. I'm trying to get Gentoo prepared now, and so what are our chances to get gcc-4.8 to stable by that time? Possible alternative solutions: 1. Depend on clang, and force the build to use it. Possible problem with this is that since chromium uses very bleeding edge clang, this can put some strain on our system clang just as well. 2. Patch chromium to make it compile with gcc-4.7. This is almost always technically possible, but can be a maintainability burden, especially if upstream doesn't accept some parts of the patches. Also, there are known problem with chromium, c++11 and gcc-4.7 (https://groups.google.com/a/chromium.org/d/msg/chromium-dev/NrtrEnoMH6g/ERRiVAQcE18J , although Gentoo is not affected by this one because we have newer dbus). WDYT? A third option that comes from the chromium-packagers ML: 3. Download and use the pre-built clang binaries from the Chromium project. I know we frown upon bundled binaries. However, I think that's really more a problem if the bundled code is used at runtime; maybe it would be ok to utilize pre-built build tools? The same could be applied to the [p]nacl toolchains; if I recall correctly, we currently disable nacl due to problems creating these from source.
Re: [gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x
2014-07-29 20:28 GMT+04:00 Mike Gilbert flop...@gentoo.org: A third option that comes from the chromium-packagers ML: 3. Download and use the pre-built clang binaries from the Chromium project. As a proxy maintainer of a package that also utilizes C++11 extensively in late releases, I'm also rather interested in having gcc-4.8 in stable, or, otherwise, in solution #1 from the original mail. I remember though when I wrote in this maillist a few months ago about having a build dep on clang I got an impression that it would be rather inconvenient and discouraged, though feasible. -- Georg Rudoy
Re: [gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x
Dnia 2014-07-23, o godz. 19:48:17 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a): Looks like www-client/chromium is going to start using c++11 seriously and require gcc-4.8+, see thread https://groups.google.com/a/chromium.org/d/msg/chromium-packagers/fvJvPG8fa7I/iWPEsUxhKikJ This is in the dev channel for now, but given the 6 weeks release cycle it'll go to stable in about 3 months, and every time it's a security update. I'm trying to get Gentoo prepared now, and so what are our chances to get gcc-4.8 to stable by that time? For the record: https://bugs.gentoo.org/show_bug.cgi?id=516152 I think 4.8 should be our current choice for stable since 4.7 is unsupported upstream and 4.7.4 (4.7.3 is stable now) has known unfixed bugs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On 29/07/14 03:15, Denis Dupeyron wrote: On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild:KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild Wait, what? Live ebuilds are keyworded now? Denis. I should have propably only mailed this to maekke, but CC'd the mailing list because this has been a trend lately, people outright ignore * ebuilds and the preparations done there for the upcoming releases when they commit non-maintainer bumps like, well, I don't want to give examples as that'd be pointing fingers Just that some people think it's better to have poorly done version bump to get latest, than live with *correct* older version, and thiskind of thinking really needs to die... There is nothing wrong with old, long as it works - Samuli
Re: [gentoo-dev] About current ppc/ppc64 status
On Sat, Jul 26, 2014 at 04:29:51PM -0400, Anthony G. Basile wrote: On 07/26/14 09:44, Pacho Ramos wrote: El sáb, 26-07-2014 a las 09:37 -0400, Anthony G. Basile escribió: On 07/26/14 09:28, Pacho Ramos wrote: El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: I guess we will need to wait for the next Council to officially decide to do this as it will be a big change for ppc* users :/ (I remember their action was needed for the move to testing of some arches and the package-by-package proposal for others) Also, I am not sure if any other arch teams (sparc, ia64?) would want to get this policy too :| (I got ppc* because this concrete case ;)) At first this is an arch team decision. No need for the council. (Given that in this case there is a responsive and addressable arch team...) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ The problem is that blueness looks to be the only member currently replying :/, I have checked their page and I see no team lead or similar. Then, I am not sure how to get the ok to proceed or not :| (to prevent this from getting stalled and we keep trying stabilizing all the things). I remember from older thread (one related with udev stabilization), that blueness was also the only one replying. Yeah, not having a clear lead is a problem. No one wants to just make a big decision on behalf of the team without making sure everyone is on board. Pacho, do you have access to timberdoodle? If so, join both teams and just take the initiative and let any other claimants step forward now. BTW, taking the lead doesn't mean doing all the work yourself. I want to see ppc/ppc64 in good shape. I'll be happy to write scripts to do the demoting to ~ etc etc. I don't even know about timberdoodle :( I forwarded the mail to both alias (as I forgot first time), then, hopefully they will review it :/ Will CC them again to this just now with this link to allow all to read the full thread: http://comments.gmane.org/gmane.linux.gentoo.devel/92151 I think its clear who cares about ppc/ppc64. If there are no objections, I'll take the lead of those teams and see this plan through. I'll wait a few days for people to voice concerns. Then I'll start by generating a list of all stable and testing packages on ppc and ppc64. I'll post then and then continue the conversation on just the ppc and ppc64 lists. Don't worry, I won't start dropping to ~ until we have a concise plan and we're all on board. I don't think you can/should just take over the leadership of an arch. Why not have meeting/discussion for team members. Especially since you are proposing such a big change. Thanks, -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A signature.asc Description: Digital signature
Re: [gentoo-dev] Restructuring the ppc/ppc64 profiles to be better multilib
On Sat, Jun 28, 2014 at 02:46:43PM -0400, Anthony G. Basile wrote: Hi everyone, This is a ppc/ppc64 issues, but I'm sending this to gentoo-dev@ because it seems to me that those herds are pretty scattered right: 1) The issue came up about restructuring the arch/powerpc profiles. There we have some ancient stuff like ppc64/32ul. I don't know why that's needed and it doesn't make much sense wrt the new direction multilib is going. I'd like to clean up those profiles. Any objections to removing ppc64/32ul, coalescing ppc64/64ul into just ppc64 and making whatever other tweaks are needed? 2) Can we try to get the ppc/ppc64 herds communicating more. I don't believe every team needs a lead but at least have a point of reference so we can communicate. What is the status of this? I've been away for a few months but am back now. Do you need help with this? Thanks, -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A signature.asc Description: Digital signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
В Sun, 27 Jul 2014 14:42:24 +0300 Samuli Suominen ssuomi...@gentoo.org пишет: On 26/07/14 15:49, Ciaran McCreesh wrote: On Sat, 26 Jul 2014 12:41:16 + (UTC) Martin Vaeth mar...@mvath.de wrote: hasufell hasuf...@gentoo.org wrote: Dynamics deps are already broken, not consistently enabled (e.g. when subslots are in use) Just to make it clear: No, dynamic deps are not broken. Yes they are. We just succesfully converted ~300 ebuilds in tree without revision bumps from virtual/udev[gudev,introspection,static-libs] to virtual/libudev and virtual/libgudev Tested it on multiple boxes, went fine. Nobody has filed bugs at http://bugs.gentoo.org/, nobody has filed a single forums post, nobody has said anything at #gentoo, Freenode Only one person said he had to manually build 2 GNOME related packages, simple-scan and something else As Michał already noted in this thread, dynamic deps does not play nice with slot operators. So I had the same problem with 2 GNOME related packages: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: virtual/udev:0 (virtual/udev-208-r2::gentoo, installed) pulled in by =virtual/udev-171:0/0=[gudev] required by (media-video/cheese-3.12.2::gentoo, installed) virtual/udev:0/0=[gudev] required by (x11-misc/colord-1.2.1::gentoo, installed) (virtual/udev-215::gentoo, ebuild scheduled for merge) pulled in by =virtual/udev-215 required by (games-util/xboxdrv-0.8.5-r1::gentoo, installed) (and 22 more with the same problem) So, broken? Far from it. More like essential feature. People have just listed some known races dynamic deps have, and I take those races anyday over an regression that causes endless rebuilding... - Samuli -- Alexander Tsoy
Re: [gentoo-dev] Re: don't rely on dynamic deps
On 30/07/14 07:45, Alexander Tsoy wrote: В Sun, 27 Jul 2014 14:42:24 +0300 Samuli Suominen ssuomi...@gentoo.org пишет: On 26/07/14 15:49, Ciaran McCreesh wrote: On Sat, 26 Jul 2014 12:41:16 + (UTC) Martin Vaeth mar...@mvath.de wrote: hasufell hasuf...@gentoo.org wrote: Dynamics deps are already broken, not consistently enabled (e.g. when subslots are in use) Just to make it clear: No, dynamic deps are not broken. Yes they are. We just succesfully converted ~300 ebuilds in tree without revision bumps from virtual/udev[gudev,introspection,static-libs] to virtual/libudev and virtual/libgudev Tested it on multiple boxes, went fine. Nobody has filed bugs at http://bugs.gentoo.org/, nobody has filed a single forums post, nobody has said anything at #gentoo, Freenode Only one person said he had to manually build 2 GNOME related packages, simple-scan and something else As Michał already noted in this thread, dynamic deps does not play nice with slot operators. So I had the same problem with 2 GNOME related packages: I've revision bumped x11-misc/colord and media-gfx/simple-scan because of this reason, I'll do media-video/cheese as well If it's 2-3 packages out of ~300, I'd rather pick them out than revision bump all ~300 for the 2-3. Or not pick them out at all and let users do the rebuild (which is the obvious answer to the output you posted) !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: virtual/udev:0 (virtual/udev-208-r2::gentoo, installed) pulled in by =virtual/udev-171:0/0=[gudev] required by (media-video/cheese-3.12.2::gentoo, installed) virtual/udev:0/0=[gudev] required by (x11-misc/colord-1.2.1::gentoo, installed) (virtual/udev-215::gentoo, ebuild scheduled for merge) pulled in by =virtual/udev-215 required by (games-util/xboxdrv-0.8.5-r1::gentoo, installed) (and 22 more with the same problem)
