[00:06] Sorry I'm late [00:07] is the ubuntu beginners team here right now? [00:07] I don't know PabloRubianes [00:08] weird [00:16] hi [00:16] hm exciting meeting :D [00:17] coalwater; meeting in 45 mins. [00:17] o [00:17] hm [00:17] so i messed up the time zones? [00:17] Nope, google did [00:18] how? [00:18] o btw, forgot to tell u good job on webupd8 workspaces thing :P [00:20] i should sleep, it's 2:20 am here :D im sacrificing my nice sleep for this meeting , hope i's worth it :P [01:04] Meeting? [01:04] Objection! [01:04] Overruled? [01:04] :p [01:12] #startmeeting [01:12] Meeting started at 19:12. The chair is cprofitt. [01:12] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [01:12] hello all [01:13] Will all Ubuntu Beginners Team members please say her [01:13] Aloha oukou [01:13] here [01:13] here [01:13] here [01:14] I think this is it [01:14] I'm here [01:14] * cprofitt nods [01:14] :) hey cprofitt how you doing sir [01:14] here [01:14] [TOPIC] re-structure of UBT [01:14] New Topic: re-structure of UBT [01:14] [LINK] https://wiki.ubuntu.com/cprofitt/sandbox [01:14] LINK received: https://wiki.ubuntu.com/cprofitt/sandbox [01:15] those ideas are some rough ideas that will be discussed by the current council next week. [01:15] the suggestions come as a result of the meeting about the UBT at UDS-O [01:16] the goal (which may or may not be clear from the document linked) is to reduce redtape [01:16] and make the team more open and friendly to new folks. [01:16] at the same time there is a desire to ensure that mentors are well qualified to give people advice and guidance [01:17] I will be honest -- I think the current team is mired in muck right now [01:17] and less functional and effective than it could be. [01:17] * zkriesse nods [01:17] That, in my opinion, has nothing to do with the general membership, but the structure and lack of effective leadership [01:18] There's definitely a lack of activity and cohesive "administration" [01:18] no offense to those that are not here, but it bothers me that I am the only 'council' member here [01:18] sorry im late [01:18] and I was late due to a child falling out of bed [01:18] I apologize [01:18] for my tardiness [01:19] cprofitt: is your child oK/ [01:19] yes, the bed is not to high [01:19] That kind of thing isn't exactly something you need to apologize for [01:19] but they are always a bit shaken [01:19] zkriesse, +1 [01:19] And glad kiddie is ok :) [01:19] Children before UBT, I like that :) [01:19] so... [01:19] there are really two things... [01:20] 1) Jono and the community team would like the UBT to become an effective part in the community on-boarding process [01:20] * hakimsheriff thought the meeting wasnt happeing [01:20] 2) That process should be as red-tape free as possible while maintaining quality [01:20] is there anyone that has any objection to those two items? [01:21] The red-tape was put up to ensure quality right? [01:21] I have no objection [01:21] cprofitt, I think one thing is to welcome people inside the community and other is to let people easily in the team [01:21] Or was it just for laughs? [01:21] MrChrisDruif: the red-tape was the result of a poorly executed attempt to ensure quality [01:22] If you make it too hard to contribute to a supposedly OPEN community there will be a lack of desire to contribute [01:22] I will not go any further in to detail other than to say it was due to a non-functional council and a great deal of compromise [01:22] PabloRubianes: yes [01:22] Not saying I feel we should just go away with the red tape it's just it needs to be as minimalistic as possible [01:22] one of the items listed on the link [01:22] [LINK] https://wiki.ubuntu.com/cprofitt/sandbox [01:22] LINK received: https://wiki.ubuntu.com/cprofitt/sandbox [01:22] is to open the FGs up [01:23] and allow anyone to join them to receive guidance [01:23] being an FG member means you want help in that area [01:23] to learn more and potentially contribute to the community in that area [01:23] It's a group with a focus, not a hard core team that only experts can join, am I correct cprofitt ? [01:23] there should be no hoops or jumps to get to that [01:23] And you also go "upstream" sorta say.. [01:23] +1 zkriesse [01:24] Like joining the Contributor FG [01:24] In that case I say +1 to making them open [01:24] yes... that is the intent [01:24] zkriesse, +1 [01:24] then the core team -- will be those of us that are making the UBT run [01:24] There would still have to be some sort or leadership over them to ensure non-rampant craziness for lack of a better word [01:24] yeah, I agree that they should be open [01:24] there may even be mentors who are not UBT members [01:25] if a Bug-Control member wants to mentor -- I see no reason to make them join the UBT [01:25] * nlsthzn gets shoved into the room [01:25] but if you want to work on the UBT core, work with teams, etc... that is the core UBT team [01:25] cprofitt, so to join the core team, you still need to go throught the long process? [01:26] cprofitt, but if mentor arent from the UBT what's the importance to have the team [01:26] you need to go through a process... [01:26] I would hope to not make it a long one [01:26] PabloRubianes: its to help organize the process - to make a single point of entry for new contributors [01:26] for new users [01:27] * zkriesse will return in a minute or two [01:27] many teams have no mentorship process [01:27] so for those teams we can help them develop one [01:27] cprofitt, sure but if mentors aren't part of the team I think the spirit will be lost with the time [01:27] for the teams that do have a mentorship process we can be a portal [01:27] PabloRubianes: perhaps [01:28] having people involve and contributing will lead to more members [01:28] So in this new structure, being in the FG means that you'll get helped by a mentor if you want to...or that you mentor others? [01:28] I would actually hope that mentors that are not UBT members will see the value in the UBT and join, but to restrict a qualified mentor from helping because they are not a UBT member seems a bit foolish [01:28] being in a FG means you are either getting help or being a mentor [01:29] FGs will contain both [01:29] they would be open teams [01:29] to be a mentor will require membership in another team you are mentoring for... or approval to be a mentor by the UBT leadership [01:29] cprofitt, and if you want to be in the support fg than you dont really need to go through any process? [01:29] that process to become a mentor will not be a three month circus though [01:30] hakimsheriff: no FG will have a process [01:30] cprofitt, Great! :) [01:30] if you want to offer support to people you will not need to be a mentor though [01:30] you can just offer help [01:30] great! [01:30] if you want to mentor for bugs in the Contributor FG you would need to be a member of bug-control or approved by UBT leadership [01:31] some control on quality, but not some official process that takes weeks or months [01:31] cprofitt, maybe a good idea, but in my experience the richest part of joining the Ubuntu community was the "membership circus to UBT" [01:32] PabloRubianes: I hope that we can replace that 'richness' with the same feeling of accomplishment, but w/o the red tape and frustration some have felt [01:32] cprofitt, sure [01:32] * zkriesse is ack [01:32] the goal is to become a more integrated part of the greater community [01:32] PabloRubianes: what FGs did you become a part of? [01:33] cprofitt, LP and wiki on those days [01:33] * cprofitt nods [01:33] so... to take your use case [01:33] under the potential structure [01:33] you would join the contributor FG [01:34] learn how to contribute to the LP and Wiki teams [01:34] potentially get membership in the documentation team [01:34] become approved to be a mentor for the Contributor FG [01:34] and if you felt motivated and had time to devote join the UBT Core [01:35] And for questions and mentoring you also join wiki FG? [01:35] the difference is you would not have to go through a 1-3 month process for joining the UBT before you could work on the documentation stuff [01:35] and join the FG [01:35] cprofitt, yes is a good idea [01:35] sounds good [01:36] Great! ;) [01:36] pleia2: thanks.... [01:36] I just hope it works... [01:36] the team has incredible potential [01:36] and some very energetic members [01:36] it's the right direction based on feedback from folks I've spoken to [01:36] as always we can adjust as needed :) [01:36] as always... we need to be agile :-) [01:36] so I will know more next week after the council meeting [01:37] and will post to the email list about that [01:37] the next topic is a tough one [01:37] one I would prefer not to be brining up, but I feel I must [01:37] [TOPIC] UBT leadership [01:37] New Topic: UBT leadership [01:38] I do not feel the council (regardless of membership or time) has been an effective leadership structure for the UBT [01:38] It sounds quite good [01:38] how many people in the core UBT and how many people present in this meeting? [01:39] I think that primarily it is because the council was originally not given any real power and at many times council members were away for extended periods of time [01:39] nlsthzn: the UBT core does not exist yet [01:39] in the future the UBT core would likely be fairly small [01:39] and highly motivated [01:39] cprofitt: sorry, then what I mean how many in the council and how many present in the meeting(s)? [01:40] there is no issue with people not being able to give lots of their time [01:40] cprofitt: I think it's worth visiting what the team expects out of a leadership council/person/ewok, the role has changed significantly over the years [01:40] I am the only current council member that I am aware is at their keyboard [01:40] pleia2: I agree [01:40] +1 @ pleia2 [01:40] others may be here via bouncers [01:41] I know for a fact that DarkwingDuck is almost never on IRC or anything else [01:41] I've seen him from time to time zkriesse [01:41] the first real question -- is how do you feel about the leadership participation over the last 12-18 months [01:41] DarkWingDuck is currently busy for good reason [01:41] MrChrisDruif: meaning he's "on" but inactive IE bouncer or the similar [01:41] I've only been around since December or something... [01:41] I will not fault him for that. [01:42] Duane as well [01:42] cprofitt: Oh I know he is I'm just commenting on active/non-active council members regardless of the reason [01:42] * cprofitt nods [01:42] I think the members of the council have done the best they can, I think it's the expectations that need changing [01:43] * cprofitt nods [01:43] +1 pleia2 [01:43] almost by definition members of leadership councils tend to be the busiest people around [01:43] I think the most important thing is that at least one council member should be contactable....via IRC, email or pidgin-carrier [01:43] * nlsthzn was just curious as he doesn't know the team/council/set up but wants to learn / help / assist [01:43] I agree... I think there was an expectation that the council was going to provide a huge amount of hands-on activity [01:43] and we all here have a real life out there [01:43] (really, you should see the CC try to arrange a conference call for when none of us are traveling, it's literally not possible) [01:44] For when you've got issues with something, or questions [01:44] MrChrisDruif: I think at that the council has been very good [01:44] we have had several full-scale rather involved issues the past 18 months that we have handled [01:44] and tried to keep negative side effects away from the team in general [01:44] I know, I was just pointing out my number one for the council [01:45] I agree with pleia2 you guys have done a spot on job with all that you do, [01:45] pleia2: would it be fair to say that the team still bears the burden of providing direction and effort? [01:46] or is there some expected from the council on that? [01:46] cprofitt: I feel that the leadership bears the burden of making sure the team feels empowered to pour effort and direction into their interests and goals [01:46] +1 pleia2 [01:46] I think there has been a lot of waiting around to see what we "should" be doing rather than just moving foward [01:46] +1 plars [01:46] argh tab fail, I meant pleia2 [01:47] so the council should set the direction, clarify it when needed, resolve disputes and empower people to go! [01:47] it should shift to leadership empowering and checking in to make sure FG leads and others are doing ok, not being the ones doing all the driving [01:47] * cprofitt nods [01:47] we often mistake leaderhip for managment... [01:47] nlsthzn: indeed [01:47] indeed [01:47] +1 pleia2 [01:48] alright... [01:48] it sounds as though we have a fairly good picture of what the council is expected to do from you guys [01:49] I will work to try to make that a reality [01:49] * pleia2 hugs cprofitt [01:49] I do think, as pleia2 pointed out, that the true key to the UBT is going to be the FG leaders [01:49] Indeed [01:49] they and their teams will be critical to success [01:50] I'll be honest, the support team does a great job and I don't even know who their leaders are (are there leaders? I just give support when I'm around and give an answer) [01:50] that's probably the way it should be [01:50] +1 pleia2 [01:50] last topic [01:50] [TOPIC] Monthly meetings [01:50] New Topic: Monthly meetings [01:50] there is a suggestion to end monthly meetings of the general team... [01:50] What about those meetings? [01:51] I am not sure about that, at least until the structure is set [01:51] and FGs are up and running [01:51] I can see it being a case of each FG having its own meetings [01:51] and FG leaders working with the council [01:51] -- do you guys think that would work [01:51] Well I did run weekly/bi-weekly wiki meetings and it seemed to work fairly well [01:51] I still find them valuable for now (I don't think we should expect everyone to attend though, that's just setting us up for disappointment) [01:51] or would you prefer to have a FG meeting and a General Team meeting? [01:52] People showed up, we discussed wiki happenings/new stuff we could do, I posted results etc [01:52] +1 pleia2 [01:52] +1 zkriesse [01:52] pleia2: I think a general team meeting is a must until the FG teams are established [01:52] after that -- I might consider not having a general team meeting... [01:52] yeah, it can be talked about after that [01:53] but I still think a general team meeting has usefulness [01:53] that is just me [01:53] I also am sensitive to having too many meetings [01:53] Yeah, true [01:53] * cprofitt nods [01:53] Holland is famous for it...afaik [01:54] lol [01:54] I want to thank each of you for coming. Making the time to be present. For all the efforts you have put in to making Ubuntu and the Ubuntu community better. [01:54] But I'm with the rest; general meetings until FG's are properly running [01:54] Hey, thanks to you man cprofitt [01:54] I hope that we all move this team forward and help it grow to its potential. [01:54] Thank You!! [01:54] * nlsthzn is happy to have seen the UBT in action... [01:54] That would be awesome cprofitt :) [01:54] Goodbye everyone [01:54] bye hakimsheriff ! [01:54] Please feel free to make comments too https://wiki.ubuntu.com/cprofitt/sandbox [01:54] thanks cprofitt! :) [01:55] have a great night all [01:55] Great meeting cprofitt spot-on job [01:55] * hakimsheriff did nothing this meeting [01:55] #endmeeting [01:55] Meeting finished at 19:55. [01:55] hakimsheriff: showing up is something [01:55] trust me [01:55] * MrChrisDruif is off to bed; sleep well everyone [01:55] bye MrChrisDruif 1 [01:55] * Unit193 gets one point for showing up [01:55] cprofitt, you are right, hehe [01:57] Unit193: looses his point for showing up after the meeting has ended (or at the very least staying silent until then) ;) [01:57] I never think I should speak at the first team meeting I attend [01:59] Unit193: I noramlly only get to speak at the first one :p === Adri2000 is now known as Guest22931 === zkriesse_ is now known as zkriesse [08:53] hello all === Guest22931 is now known as Adri2000 [12:00] #startmeeting [12:00] Meeting started at 06:00. The chair is barry. [12:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:01] hello everyone and welcome to this week's udd steering meeting. who's here today? [12:01] [TOPIC] agenda [12:01] New Topic: agenda [12:01] [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110615 [12:01] LINK received: https://wiki.ubuntu.com/DistributedDevelopment/20110615 [12:04] hello all [12:04] jam: hi. any sign of jelmer or poolie? [12:04] jelmer was around earlier [12:04] and poolie is at velocity conf [12:04] so won't be here [12:05] * jelmer waves [12:05] jelmer: hi! [12:05] [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110615 [12:05] LINK received: https://wiki.ubuntu.com/DistributedDevelopment/20110615 [12:06] i guess we should start [12:06] [TOPIC] action items [12:06] New Topic: action items [12:06] * jelmer to study the feasibility of merge helper ([[https://bugs.launchpad.net/bzr-builddeb/+bug/608675|bug 608675]]) as an intermediate step for quilt support [12:06] [12:06] Ubuntu bug 608675 in bzr-builddeb "merge-package should have support for manipulating quilt v3 patch stacks" [High,In progress] [12:06] jelmer and I still have it in the queue, but he got pre-empted with getting Launchpad using bzr-2.3.3 [12:07] that's a good thing :) np, we'll just carry it over [12:07] so I would say, still in progress [12:07] what John said :) [12:08] fwiw, we had a lot of buzz about udd+quilt these past two weeks. getting a good story here will go a long way toward satisfying experienced packagers [12:08] * poolie to send condensed summary of uds sessions [12:08] [12:08] i'm not sure if this is still relevant, but we'll leave it on here until poolie gets back [12:09] * jelmer to look into [[https://bugs.launchpad.net/udd/+bug/609187|bug 609187]] (warn when package import is out of date) [12:09] Ubuntu bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Triaged] [12:09] barry: same as above, I believe [12:09] sure thing, np [12:10] yep, both are in progress.. moving along slowly [12:10] jelmer: no worries [12:10] [TOPIC] * How can we better handle "native" packages, e.g. lp:software-center vs. ubuntu:software-center? [12:10] New Topic: * How can we better handle "native" packages, e.g. lp:software-center vs. ubuntu:software-center? [12:10] barry: this is, getting the package importer to play nicely when we also have upstream source? [12:10] mvo brought this up, and i just wanted to put it on the agenda. i think jelmer is familiar with the issue. [12:11] or just packaging in general? [12:11] the former [12:11] the problem is that mvo gets lots of bogus merge proposals because they're against the wrong branch [12:11] jam: in its simplest form, contributors sending in patches against the UDD branches while upstream uses a different branch [12:12] this could be a launchpad issue, in that perhaps we need a way to say "don't mp against the source branch, use the upstream branch over here" [12:12] but i'm not sure, so i'd love to get your thoughts! [12:13] I think there's two sides to this - in the short term, we should make sure users get warned about not proposing mps against the udd branch [12:13] jelmer: ah, that one [12:13] perhaps that's related to bug 609187 [12:13] Launchpad bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Triaged] https://launchpad.net/bugs/609187 [12:13] jelmer: is this to make 'lp-propose' determine the right target? [12:13] jam: that's already happening afaik (proposing a packaging branch now goes against ubuntu:) [12:14] jam: well, i think there's also a bug out there that lp-propose doesn't work with source branches [12:14] barry: it does, but that requires bzr 2.4 [12:14] jelmer: on the client side, or is server side support required? [12:14] jelmer: what you brought up above, is that lp-propse should propose towards lp:package [12:14] barry, client side [12:14] (1:11:40 PM) jelmer: jam: in its simplest form, contributors sending in patches against the UDD branches while upstream uses a different branch [12:14] jelmer: awesome! [12:15] jam: I think the issue at heart is that there are two histories when really there should just be one [12:15] the UDD branch is pointless if everybody should be using the upstream branch [12:16] except that the upstream branch may have unreleased changes, and the packaging branch only has released changes, right? but i guess the upstream branch can just be further along in that case [12:16] (i.e. they'd share history) [12:16] barry: Hmm, yeah [12:16] barry, So I guess you'd want two branches but have related history [12:17] and the packaging branches would be differenter for older distro versions [12:17] jelmer: i think so [12:17] barry, jelmer: that would be my understanding. The real trick is figuring out where the seams are [12:18] what lp:package revision matches ubuntu:package @ rev-1.2.2 [12:18] jam: as the package is native, the upstream branch should have the correct tags already [12:18] jelmer: if upstream does the tagging [12:19] bzr does, but it doesn't use the debian syntax, AFAIK (maybe we do) [12:19] I know some of the bzr plugins use "release-XXX" [12:19] so we should have sufficient information to match things up, and there is a link in Launchpad from the packaging to the upstream branch [12:19] and certainly, there is still the fact that *packaging artifacts* are in the packaging branch [12:19] like "Makefile" vs "Makefile.in" changes [12:20] (in bzr's case, bzr-2.3.3 won't have foo_pyx.c versioned, but it *is* in the tarball) [12:20] jam: We'll likely still need the pristine tar revisions that add files like that, but they could have the upstream revision as one of their parents [12:21] jelmer: sure. So at that point you just hope syntax matches? [12:21] jam: that's how bzr-builddeb already works if you have an upstream branch specified - e.g. see one of the branches maintained by the pkg-bazaar team (http://bzr.debian.org/bzr/pkg-bazaar/bzr-svn/unstable) [12:22] anyway, we don't have to solve it today, but i think it would be a useful thing to keep on the radar (not as critical as the other issues we've identified) [12:22] for the immediate problem doesn't launchpad just need clearer wording on the packaging branch page to say that isn't where primary development happens? [12:23] the general problem of matching upstream branch history and tags to packaging ones seems very hard to solve but not necessarily specific to software that happens to be developed in launchpad [12:23] Riddell: i think part of the problem is that once you've done `bzr branch ubuntu:foo` you'll be working on the packaging branch, when upstream really wants to work against the upstream branch [12:24] at least for the currently in-dev version of ubuntu [12:24] barry: right, so launchpad needs clearer lableing there [12:24] jam: upstream is on Launchpad in this case, so I think it's reasonable to ask them to use a particular syntax if they want related history in the UDD branch [12:24] (e.g. `bzr branch ubuntu:natty/foo` still needs to give you the packaging branch) [12:24] Riddell, jelmer agreed [12:25] jam: It would be nice to create related history for arbitrary packages too (e.g. where upstream is in git), and the tag scheme can be pretty weird in some of those cases; I think we can leave that for another day [12:25] Riddell: going further, the parallel import file-id issue means that patches against the packaging branch can't be merged into the upstream branch. [12:26] jelmer: I was wondering if a 'similarity' metric would be reasonable (all files that are present have the same contents) [12:26] it might be a bit expensive to compute across history, though [12:26] I would propose filing a bug saying that packaging branch pages on code.lp.net should be better labeled [12:27] Riddell: would you like to file that bug? :) [12:27] can do [12:28] Riddell: thanks [12:29] [ACTION] Riddell to file bug saying that packaging branch pages on code.lp.net should be better labeled [12:29] ACTION received: Riddell to file bug saying that packaging branch pages on code.lp.net should be better labeled [12:29] this leads me to the next topic: [12:29] [TOPIC] * Topics for Dublin [12:29] New Topic: * Topics for Dublin [12:30] you guys will be in dublin right? (fsvo "you guys") [12:30] my train is booked [12:31] I'm scheduled [12:31] nice. i think it'll be a good opportunity to get the bzr+lp and platform guys together to discuss issues. i'll send an email about it, but i wanted you to think of useful topics we might discuss or look into together [12:32] [ACTION] barry to send email on dublin topics to platform and bazaar/lp mlists [12:32] ACTION received: barry to send email on dublin topics to platform and bazaar/lp mlists [12:32] if you have anything in particular you'd like to get input on from platform folks, please send me email [12:32] [TOPIC] * Package importer progress [12:32] New Topic: * Package importer progress [12:33] btw, thanks for fixing sysvinit! [12:33] anything new on importer progress? [12:33] barry: big kick in the crotch from launchpad removing ~ubuntu-branches support [12:33] but I think there are workarounds for some patches now [12:33] *for some projects* [12:33] jam: yeah [12:33] package-importer super-user status got revoked, but nobody supplied another way in [12:34] that + planned downtime meant a rough week [12:35] I think we are at 525 failures, which is up from 485 last week [12:35] jam: is that the aftermath of the big backlog or are there new failures now? [12:36] I'm guessing it is the ~ubuntu-branches thing, but I haven't followed it closely to know what 40 packages are now failing [12:36] that weren't before [12:37] jam: what's the longer term solution? [12:38] [LINK] https://bugs.launchpad.net/launchpad/+bug/797088/comments/1 [12:38] LINK received: https://bugs.launchpad.net/launchpad/+bug/797088/comments/1 [12:38] Ubuntu bug 797088 in Launchpad itself "Launchpad has removed privileges that UDD importer requires to function" [Critical,In progress] [12:39] just says there may be a code solution [12:39] which sounds like "don't create old branches if the series is now frozen" [12:39] " obsolete is obsolete" [12:39] though IMO, if we import them to get good history, we might as well publish that history [12:40] jam: thanks. i've subscribed [12:40] jam: yeah, they're particularly useful when e.g. creating SRUs for older distroseries [12:41] jelmer: which, imo, is a very important use case to preserve [12:41] I'm not sure how obsolete things have to be for it to fail [12:41] It seems to need to be a new package with old history [12:42] though fixing bugs in the importer allowing it to import something that used to fail [12:42] would suck to trip over this [12:42] from what I understand, flacoste wants to strictly have the importer use the Ubuntu upload rights [12:43] (so the importer can publish a branch, if an equivalent developer could upload a .deb ) [12:43] but that doesn't seem to account for the fact that a developer *did* upload .deb or the importer wouldn't have anything to do. [12:44] jam: I think the UDD branches should reflect what's in the archive as much as possible; only allowing updates where an ubuntu developer would be able to do an upload means we'll have more out of date branches. [12:45] jelmer: i completely agree [12:45]